Lab 03-02 · Bridge performance: Fast Path, Fast Forward and hardware offloading¶

Think about airport security. A normal passenger queues, puts the bag on the belt, walks through the scanner and maybe gets searched. A frequent flyer uses the fast track: same checks, fewer of them. The crew walks through a staff door with a quick badge check. And a plane changing gates never enters the terminal at all: it is towed across the tarmac.

A RouterOS bridge has the same four lanes for every frame that crosses it. Which lane a frame takes decides how much work the router's processor does, and so how fast the bridge can go. In this lab you put two laptops on a bridge, push as much traffic as you can between them, and switch the lanes on and off one by one.

The analogy: four lanes through the airport¶

The slides summarise it on p156: Hardware offloading > Fast Forward > Fast Path > Slow Path.

The four lanes, one by one¶

Slow path: the full check¶

The slow path is the normal way a frame crosses a RouterOS bridge: it goes through the whole Linux network stack of the router, so every feature (firewall, queues, sniffer...) can see it.

It is the most flexible lane and the slowest. You fall back into it as soon as you use a feature that needs to inspect every frame.

Fast Path: the fast track¶

Fast Path forwards packets without the extra processing of the Linux kernel. The slides say it "significantly improves forwarding speeds".

It only works when the interfaces support it and nothing needs to look at the traffic. The slides (p152) list the conditions for routed (IPv4) traffic: no firewall rules, no simple queues, no torch or sniffer, no HotSpot. For bridged traffic the MikroTik manual (Packet Flow in RouterOS) gives its own list:

• no bridge firewall rules (bridge filter or NAT) are configured, and Use IP Firewall is off,
• sniffer, torch and traffic generator are not running,
• DHCP snooping is not enabled on the bridge, and a few more.

Fast Forward: the crew door¶

Fast Forward is a special case of Fast Path for a bridge with exactly two running ports. It can skip several bridge checks, including MAC address learning, so it is even faster.

The slides (p154) list every condition. The ones you will touch in this lab:

The full list also requires the flooding options at their defaults (unknown-unicast-flood, unknown-multicast-flood, broadcast-flood = yes), horizon=none on both ports, and the bridge's MAC address matching one of its ports (the default, auto-mac=yes, does that).

Hardware offloading: never entering the terminal¶

Hardware offloading lets the router's switch chip forward frames between its own ports. The CPU is not involved, so the speed is the full speed of the ports.

In RouterOS a bridge port shows the flag H (hardware-offloaded) when this is happening. It only works between ports of the same switch chip, and only on models whose chip RouterOS supports for it, which is why the slides (p140) call it limited. The slides (p155) also mention L3 hardware offloading (L3HW, "IP switching"): some bigger switch chips can even do routing in hardware. A hAP is not one of them.

A bridge with no ports: the loopback¶

Slide p157 shows a trick: a bridge with no ports at all. A real interface goes down when its cable is unplugged, taking its IP address with it. A port-less bridge is never "unplugged", so an address on it is always up. That is useful as a stable identity for the router, for example for routing protocols such as OSPF (MTCRE course). This bridge is called a loopback bridge.

The scenario¶

flowchart LR
    A["<b>Laptop A</b><br>172.16.0.1/24<br>iperf3 client"]
    subgraph HAP["hAP ac² · your router"]
        E4["ether4"]
        BT["<b>bridge-test</b><br>exactly 2 ports<br>fast-forward=yes"]
        E5["ether5"]
        LO["<b>loopback</b><br>no ports<br>10.255.255.1/32"]
        E4 --- BT --- E5
    end
    B["<b>Laptop B</b><br>172.16.0.2/24<br>iperf3 server"]
    A ---|"cable"| E4
    E5 ---|"cable"| B

Work in pairs: one hAP, two laptops with an Ethernet port (or a USB adapter), two cables.

Start the lab¶

Download the lab files and unzip them: 03-02-bridge-fast-forward.zip. Open a terminal inside the 03-02-bridge-fast-forward folder.

1. Reset the hAP to the factory configuration (System → Reset Configuration, keep "No Default Configuration" unticked), or start from the router you used in the previous labs.
2. Connect WinBox from a third device to ether2 (it stays in the factory bridge), or by MAC address.
3. Plug Laptop A into ether4 and Laptop B into ether5.

4. On both Ubuntu laptops, install iperf3 and give the wired card a fixed address (find its name with ip -br link):

   sudo apt install -y iperf3
   sudo ip addr add 172.16.0.1/24 dev enp0s31f6     # Laptop B: 172.16.0.2/24 (use your card's name)
   

Step 1 · See why the factory bridge never uses Fast Forward¶

WinBox: Bridge → Bridge, double-click bridge, look at Fast Forward; then Bridge → Ports.

/interface bridge print
/interface bridge port print
/interface bridge monitor bridge once

Expected: fast-forward=yes is already set, but the bridge has ether2, ether3, ether4, ether5, wlan1 and wlan2: far more than two ports. Fast Forward can never be active on it.

Done when you can explain why the factory bridge cannot use Fast Forward.

Step 2 · Build a two-port test bridge¶

Take ether4 and ether5 out of the factory bridge and put them into a new bridge of their own. Set hw=no for now, so the switch chip stays out of the game and you can study the CPU lanes first.

WinBox: Bridge → Ports, remove ether4 and ether5; Bridge → +, Name bridge-test, Fast Forward ticked; Bridge → Ports → + twice, untick Hw. Offload.

/interface bridge port remove [find interface=ether4]
/interface bridge port remove [find interface=ether5]
/interface bridge add name=bridge-test fast-forward=yes
/interface bridge port add bridge=bridge-test interface=ether4 hw=no
/interface bridge port add bridge=bridge-test interface=ether5 hw=no
/interface bridge monitor bridge-test once

Expected: port-count: 2 and fast-forward: yes in the monitor. From Laptop A, ping -c 3 172.16.0.2 must answer.

Done when the monitor of bridge-test says fast-forward: yes.

Step 3 · Measure the four lanes¶

For every row of the table below: change one setting, run the test, read the counters, write the result.

On Laptop B (leave it running): iperf3 -s

On Laptop A, for each row: iperf3 -c 172.16.0.2 -t 10

On the router, during the test (WinBox Tools → Profile, and Bridge → Settings):

/tool profile duration=8s
/interface bridge settings print

The bridge settings show four counters that only ever grow: bridge-fast-path-packets, bridge-fast-forward-packets (and their -bytes). Note them before and after each test: the one that grew tells you which lane your frames took.

Undo row 3 with /interface bridge settings set use-ip-firewall=no and row 2 with /interface bridge set bridge-test fast-forward=yes.

Fill in your own table in the report:

Done when your table has all four rows filled in.

Step 4 · Create a loopback bridge¶

Create a bridge with no ports and give it an address. It is always running, even with every cable unplugged.

WinBox: Bridge → +, Name loopback; IP → Addresses → +, 10.255.255.1/32, Interface loopback.

/interface bridge add name=loopback
/ip address add address=10.255.255.1/32 interface=loopback
/interface print where name=loopback

Expected: the loopback interface has the flag R (running) although it has no ports.

Done when loopback is running with 10.255.255.1/32. Compare your router with final/hap-ac2.rsc.

If something goes wrong¶

Clean up¶

Put ether4 and ether5 back into the factory bridge and remove the test bridges:

/interface bridge remove [find name=bridge-test]
/interface bridge remove [find name=loopback]
/interface bridge port add bridge=bridge interface=ether4
/interface bridge port add bridge=bridge interface=ether5

Or simply restore the backup you made before the lab.

Key takeaways¶

• A bridge forwards a frame through one of four lanes: slow path, Fast Path, Fast Forward or hardware offloading, from slowest to fastest.
• Fast Path needs supporting interfaces and no feature that inspects traffic (bridge firewall rules, Use IP Firewall, sniffer, torch...).
• Fast Forward additionally needs a bridge with exactly two running ports and hardware offloading disabled.
• Hardware offloading (port flag H) lets the switch chip do the work; the CPU never sees the frame.
• Use IP Firewall on a bridge sends every frame down the slow path.
• A loopback bridge has no ports and is always up: a stable address for the router.

Quick check¶

Next module: routing. Instead of joining networks into one, you will keep them separate and teach the router how to travel between them.