Kernaali ToolsAn H flag on a bridge port proves neither hardware routing nor hardware FastTrack. Identify the exact model, switch chip and ports first; then check the acceleration mechanism used by your actual traffic. Enabling a setting on unsupported hardware cannot add the missing capability.
Applies to: RouterOS 7 on the models listed below, checked against the current MikroTik hardware tables. This is a capability and diagnostic guide, not a throughput benchmark. Per-VLAN L3 offload control is documented from 7.21; earlier v7 builds have different controls. SwOS, virtual CHR and Wi-Fi radio acceleration are outside this matrix.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Choose the correct mechanism
| Mechanism | What it accelerates | What does not follow |
|---|---|---|
| Bridge hardware offload / H flag | Layer-2 forwarding between eligible switch ports | Inter-VLAN routing is not necessarily offloaded |
| Software FastTrack | Eligible established IPv4 TCP/UDP connections through the CPU fast path | It does not turn an RB5009 into an L3HW switch |
| L3 hardware offload | Supported routed traffic in the switch ASIC | The normal CPU firewall may not see that traffic |
| Hardware FastTrack / NAT | Eligible connections in supported switch hardware after the policy path | Not every L3HW-capable CRS supports this |
These distinctions come from packet flow and FastTrack and the separate L3HW feature tables. A route H flag is also distinct from a bridge-port H flag.
Match the full model and port group
| Model | Documented switch path | Practical boundary |
|---|---|---|
| RB5009 series | 88E6393X: ether1–8 and SFP+ | Bridge/VLAN offload; not in the documented L3HW supported-device list |
| RB4011iGS+ | Two RTL8367 groups: ether1–5 and ether6–10 | Cross-chip traffic and SFP+ are not one hardware bridge path |
| CCR2004-16G-2S+ | Two 88E6191X groups: ether1–8 and ether9–16 | Do not infer CCR2116-style L3HW from the CCR name |
| hEX RB750Gr3 / hEX S RB760iGS | MT7621: ether1–5 | Match these model codes; SFP on this hEX S is outside that listed group |
| hEX refresh E50UG | EN7523: ether2–5 | ether1 is outside the listed switch-port group |
| hAP ax² / hAP ax³ | IPQ-PPE: ether1–5 | Do not disable loop protection just to obtain an H flag |
| L009 | 88E6190: ether2–8 and SFP | ether1 is not in this switch group |
Source: current switch-chip model and feature matrix. RouterOS bridge VLAN filtering and hardware offload can coexist on supported chips, including the listed Marvell, RTL8367, MT7621 and EN7523 families, subject to the running release and topology. Do not apply that conclusion to every hAP or hEX generation.
CRS L3 offload is not automatically FastTrack or NAT offload
| Exact model examples | L3HW | Hardware FastTrack / NAT |
|---|---|---|
| CRS326-24G-2S+, CRS305-1G-4S+, CRS328-24P-4S+ | Listed for IPv4/IPv6 routing | Not supported in the current L3HW table |
| CRS310-8G+2S+ | Listed for IPv4/IPv6 routing | Not supported in the current L3HW table |
| CRS309-1G-8S+, CRS317-1G-16S+ | Listed | Supported subject to feature/resource limits |
| CRS326-24S+2Q+ | Listed; different chip from CRS326-24G | Supported subject to feature/resource limits |
| CCR2116-12G-4S+, CCR2216-1G-12XS-2XQ | Listed | Supported subject to feature/resource limits |
Read the supported-device table and limitations for your exact suffix. Hardware route and connection capacities are finite. An eligible route or connection can fall back to the CPU; a checkbox alone is not evidence of sustained line-rate forwarding.
Inspect without changing the forwarding path
/system/resource/print
/interface/ethernet/switch/print
/interface/bridge/port/print
/interface/bridge/vlan/print
/ip/firewall/filter/print stats where action=fasttrack-connectionRecord the version and board name privately. Check which ports belong to each chip, whether the relevant bridge ports show H, and whether the VLAN is admitted along the complete path. Most supported chips offload one bridge per chip; adding bridges is not a general way to create more isolated hardware paths.
For an IPQ-PPE hAP ax, the bridge documentation discusses offload with protocol-mode=none but warns about issues and recommends retaining RSTP with software forwarding or disabling hardware offload. Keep a loop-safe design. See bridge hardware-offloading caveats.
Change only after deciding where policy must run
Do not enable full L3HW across an inter-VLAN security boundary merely to reduce CPU load. In supported designs, full offload with both ingress and egress enabled can bypass CPU filtering. The documentation warns that disabling only ingress offload is not a reliable firewall design. Follow the exact switch/port design for CPU policy plus eligible hardware FastTrack, and verify that unsupported traffic still reaches the intended policy.
Before a planned change, save the affected bridge, switch and port settings, retain console or independent management, and change one path in a maintenance window. Restore those exact settings if management or policy tests fail. This guide deliberately provides no universal activation command because the correct scope differs by chip and security design.
Verify the application and the security boundary
Use two external test hosts through the device; a bandwidth test generated by the router also consumes its CPU. Compare throughput, CPU load, port counters and relevant rule counters under the same workload. Test an allowed application and a deliberately denied new connection. Stop Torch and packet sniffers before final FastTrack measurements: diagnostic tools can change the path being measured. A lower CPU percentage with a bypassed deny policy is a failed test.
FastTrack, queues and non-main routing · Bridge VLAN and management path
Technical references
Found an issue? Send a correction with a reproducible example.