After I stood up network performance testing with Prometheus and Grafana, the numbers started telling a story I did not expect. Inter-VLAN routing kept landing near 500 Mbps, with occasional dips. Same-VLAN traffic on VLAN 20 (for example between two hosts on that segment) was up around 830 Mbps. That pattern usually means the router path is the odd one out, not the switches.

This post is what I checked, what I got wrong at first, and what actually moved the needle.

The problem

• Same VLAN (e.g. VLAN 20 → VLAN 20): ~830 Mbps between test hosts
• Across VLANs (e.g. clients on VLAN 10 → servers on VLAN 20): ~500 Mbps from workstations and streaming boxes
• RouterOS bandwidth tests also looked capped near 500 Mbps
• Switch ports negotiated at 1 Gbps full duplex
• Router CPU sat around 47% with firewall accounting for a chunk of that

So the symptom was specific to traffic that had to be routed, not bridged locally within a VLAN.

What I suspected first

FastTrack placement

MikroTik’s docs and forum threads are clear that FastTrack has to match before a generic “accept established/related” rule eats the connection. If accept wins first, FastTrack never runs for those flows.

I had FastTrack after the accept rule (deep in the chain). Reordering so FastTrack came first was the right fix for that mistake, and FastTrack stats eventually showed real traffic (hundreds of thousands of packets, hundreds of MB fasttracked, F on connections in the connection table). That was worth doing.

It did not explain the hard ~500 Mbps ceiling by itself.

LAN interface list

Inter-VLAN traffic uses VLAN interfaces (for example vlan10-clients, vlan20-servers), not “the bridge” as an abstract blob. For FastTrack rules that key off interface lists, every VLAN that should count as “LAN” needs to be in that list. I added the VLAN interfaces to the LAN list. That was necessary for sane matching; it still did not unlock the missing throughput until the QoS issue below was fixed.

FastPath vs FastTrack

/ip settings print showed allow-fast-path: yes but ipv4-fast-path-active: no, while FastTrack showed active. With VLAN filtering on the bridge, FastPath being inactive is a known scenario; FastTrack can still help. I stopped treating “FastPath inactive” as the smoking gun.

Hardware expectations

An RB4011 does not do L3 hardware offloading the way a CRS326 does. Inter-VLAN routing is CPU-forwarded. That can cap you eventually, but it was not the primary story here once the real bottleneck was found.

What actually capped inter-VLAN traffic

The real issue was queue tree placement.

I run CAKE for bufferbloat work (see QoS for bufferbloat). A download queue was attached with bridge-lan as parent and a 500 Mbps max limit. That meant everything forwarded through that bridge—including inter-VLAN traffic—hit that cap. Same-VLAN traffic that never needed to hairpin through the router could still run near wire speed on the switch.

Prometheus backed this up: paths that traversed the router sat right under that 500 Mbps line; manual tests from the router to the performance-testing host showed the same neighborhood.

Fix: move WAN shaping so the download queue parents off the WAN interface (ether1 in my setup), not bridge-lan:

# Wrong for this symptom: bridge-lan parent + max-limit caps all bridged/routed traffic through that tree
/queue tree add name=queue-download parent=bridge-lan queue=cake-download max-limit=500M

# What I needed: shape at the WAN edge, not on the whole LAN bridge
/queue tree add name=queue-download parent=ether1 queue=cake-download max-limit=500M

Exact names depend on your config; the point is where the queue attaches.

Results after the change

• Workstation VLAN 10 → VLAN 20: about 900 Mbps (was ~500 Mbps)
• Apple TV on VLAN 10 → VLAN 20: about 820 Mbps (was ~500 Mbps)
• Same-VLAN VLAN 20: still ~830 Mbps (unchanged; expected)

FastTrack reordering stayed in place: less firewall work for established flows, and the connection table showed fasttracked traffic as expected.

Side quests that turned out to be real (but smaller)

While chasing numbers, I confirmed something easy to forget: not every “Gigabit” path is Gigabit end to end. One site still had a Fast Ethernet switch (100 Mbps ports). An Apple TV there topped out around 90 Mbps; another on a proper Gigabit path was fine. MoCA was not the limiter in that comparison—the switch was.

RouterOS’s built-in bandwidth-test is also easy to overread: it can be CPU-bound on smaller devices, so “what the test shows” and “what the fabric can forward” are not always the same thing.

Verification

• iperf3 across VLANs before/after the queue fix
• Prometheus trends for RouterOS and LAN tests (the same infra from the performance-testing post)
• MikroTik FastTrack counters and connection flags once ordering and interface lists were corrected

Lessons learned

1. When throughput hugs a round number (500, 950, 100), look for rate limits—including queue trees—not just routing features.
2. Queue parents matter: a limit on a bridge can punish all traffic that crosses the router, not only your WAN download.
3. FastTrack order still matters for CPU and firewall behavior, even when it is not the main throughput bug.
4. Same-VLAN vs inter-VLAN is the quickest sanity check: if same-VLAN is fast and routed paths are slow, suspect router policy before you blame the whole LAN.
5. End-to-end hardware: one slow switch or 100 Mbps port explains “slow in one room only” without touching router theory.

References

• Packet flow in RouterOS
• Fast Path (MikroTik Wiki)
• Connection tracking
• Forum: Very slow inter-VLAN routing
• Forum: How to speed up inter-VLAN routing
• Forum: FastPath discussion
• L3 hardware offloading

---

Disclosure: As an Amazon Associate, I earn from qualifying purchases.