For most of MikroTik’s history, the deal was clear: the switch chip forwards Layer 2 at wire speed, and the moment a packet needs routing, it climbs to the CPU and your throughput becomes a function of processor horsepower. That’s why a CRS326 could switch 24 gigabit ports all day but wheezed the moment you inter-VLAN-routed on it.
L3 hardware offloading — arriving in RouterOS 7 and maturing across its releases — changes the deal on capable hardware: the switch ASIC learns routes and forwards routed traffic in silicon. A CRS317 doing near-wire-speed inter-VLAN routing, a CCR2216 pushing 100G routed in hardware. The catch is the asterisk in this article’s title: the ASIC does a subset of what RouterOS can express, and everything outside that subset silently takes the CPU path. Designing around the boundary is the entire skill.
Which Hardware
L3HW requires a switch chip with routing tables, which means: the CRS3xx family (Marvell Prestera-based — 98DX3xx chips), the newer CRS5xx, and the CCR2116/CCR2216 routers whose switch fabric shares the capability. Per-model support and limits differ (TCAM sizes vary meaningfully between a CRS305 and a CRS317), so the honest first step is the L3 Hardware Offloading page in the MikroTik docs with your exact model — the feature matrix there is the source of truth per RouterOS version. RB4011/RB5009-class devices and the smaller home units do not do L3HW; their routing is CPU, full stop.
Enabling It
Global switch on, then per-port control if needed:
# The whole switch/interface/ethernet/switch set 0 l3-hw-offloading=yes
# Optionally exclude specific ports from HW routing/interface/ethernet/switch/port set sfp-sfpplus1 l3-hw-offloading=noSemantics worth being precise about: the switch-level setting is the master — no there means everything routes via CPU regardless of port settings. Port-level no only forces traffic from/to that port onto the CPU path, which is occasionally useful when a port’s traffic needs a CPU-only feature.
After enabling, routing config doesn’t change at all — same /ip address, /ip route, same OSPF/BGP from earlier articles. The ASIC programs itself from the routing table. What changes is where forwarding happens, and you verify that rather than assume:
/ip route print detail# offloaded routes carry the H (hw-offloaded) flag/interface/ethernet/switch print# monitor totals: ipv4-routes-total / ipv4-routes-hw / ipv4-routes-cpuRoutes with H forward in silicon. Routes without it — and all traffic classes the ASIC can’t handle — take the CPU. Watch /system resource cpu under load for ground truth: wire-speed routed traffic with idle CPU means L3HW is working; a busy CPU under routed load means something in your config pushed traffic off the fast path.
What Offloads, What Doesn’t
The ASIC forwards based on routes and nexthops: connected routes, static routes, IGP/BGP-learned unicast routes, inter-VLAN routing on the VLAN-filtering bridge (the bridge article’s model — L3HW rides on one hardware bridge; extra software bridges are CPU territory on CRS3xx).
The boundary cases that define your design:
Firewall and NAT. This is the big one. Generic firewall filter rules are not executed by the routing ASIC. On several platforms, recent RouterOS releases can offload fasttracked connections and NAT for them into hardware within chip limits — connection establishment happens on CPU, then the flow is punted to silicon, and when the hardware’s connection/NAT table fills, additional flows fall back to CPU. Check the current per-model support in the docs before promising anyone “hardware NAT.” The design consequence: an L3HW switch is at its best as a pure router between trusted segments — the firewalling belongs on a box in front (or the flows must fit the fasttrack-offload model).
Route table capacity. ASIC route memory (TCAM/LPM) is finite and far smaller than RAM — thousands to low hundreds-of-thousands of prefixes depending on chip, not millions. Full internet BGP tables do not fit in a CRS3xx; the classic design is default-route-plus-specifics in hardware (the BGP article’s filtering discipline suddenly has a second purpose: keeping the hardware table small). When the table overflows, excess routes forward via CPU — the box keeps working, quietly slower for those prefixes. Monitor ipv4-routes-hw vs -total.
Everything exotic. Queues/QoS on transit traffic, mangle, per-packet policy decisions, tunnels originating/terminating on the box (WireGuard/GRE/VXLAN encap is CPU work — though VXLAN gained early HW support on some chips per the VXLAN article), IPv6 offload arriving later and narrower than IPv4 per platform. The pattern: if it needs per-packet intelligence beyond “match longest prefix, rewrite MACs, decrement TTL,” suspect the CPU path and verify.
Designing Around the Boundary
The successful L3HW deployments all look similar: the offload-capable box is the routing core — inter-VLAN, campus/DC aggregation, IGP underlay — doing exactly the things silicon does, at silicon speed. Stateful services (edge firewalling, NAT to the internet, VPN termination, queues) live on a CPU-router (an RB5009, a CCR, a CHR) hanging off it. Traffic between internal segments never touches the CPU box; traffic to the outside world flows through it and gets the full stateful treatment.
That’s the same separation big networks draw between core/aggregation switches and edge/services boxes — MikroTik just lets you draw it for a fraction of the price. Trying to make one CRS both wire-speed core and stateful edge is how people end up disappointed in a product that was never claiming to be an ASIC firewall.
One operational habit specific to L3HW: after any feature change, re-verify offload. Adding an innocuous-looking bridge setting or filter can silently disable hardware paths (the same trap as L2 offload in the bridge article). The H flags and switch counters are your regression test:
/ip route print detail # count the H flags on the routes that matter/interface/ethernet/switch print # ipv4-routes-hw vs ipv4-routes-cpu totalsVerification Under Load
Synthetic confidence, then real: run a routed iperf3 between hosts in different VLANs through the box. Expected result on a healthy L3HW setup: near-line-rate throughput with single-digit CPU. Then deliberately break it — set l3-hw-offloading=no, rerun, and watch the CPU pin and throughput drop. Now you know what both states look like on your hardware, and the next time a graph shows the CPU pattern, you’ll recognize that something fell off the fast path before users phrase it as “the network is slow.”
/tool profile duration=10s # cpu consumers - 'networking' pinned = CPU-path routing/system resource monitor # live cpu under test loadClosing Thoughts
L3HW offloading is MikroTik’s quiet killer feature: switch-priced hardware doing router work at wire speed, configured with the exact same routing you already know from this series. The asterisk never goes away — silicon routes, CPU thinks — but it’s a boundary you can design on purpose: hardware box for forwarding between segments, CPU box for stateful edge, BGP filters keeping the hardware table honest, and H flags checked after every change. Get the division of labor right and a two-box MikroTik setup outperforms gear at five times the price; get it wrong and you’ll blame the ASIC for promises it never made.