Layer3 hardware offloading (otherwise known as IP switching or HW routing) will allow to offload some of the router features on to the switch chip. This allows reaching wire speeds when routing packets, which simply would not be possible with the CPU.
Starting with RouterOS v7.1beta4, both modes (l3hw=yes and l3hw=fw) merged, allowing to run full hardware routing on some ports and firewall-compatible mode on another. Also, l3hw renamed to l3-hw-offloading.
/interface/ethernet/switch set switch1 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=yes
Now Layer 3 Hardware Offloading can be configured for each physical switch port individually.
The existing connections are unaffected by the l3-hw-offloading setting change. Also, disabling l3-hw-offloading still may leave entries in the hardware memory. It is recommended to reboot the device after configuring Layer 3 Hardware Offloading.
Note that l3hw settings for switch and ports are different. Setting l3-hw-offloading=no on the switch completely disables offloading - all packets will be routed by CPU. However, setting l3-hw-offloading=no for a switch port only disables L3 packet forwarding from/to this particular port. Moreover, the port can still participate in Fastrack connection offloading.
Packets get routed by the hardware only if both source and destination ports have l3-hw-offloading=yes. If at least one of them has, packets will go through the CPU/Firewall while offloading only the Fasttrack connections.
To enable only fasttrack offloading, disable l3-hw-offloading on switch ports, but enable global l3-hw-offloading on the switch.
/interface/ethernet/switch set 0 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=no
Another example, enable hardware routing on all ports except the upstream port (sfp-sfpplus16). Packets going to/from sfp-sfpplus16 will enter the CPU and, therefore, subject to Firewall/NAT processing.
/interface/ethernet/switch set switch1 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=yes /interface/ethernet/switch/port set sfp-sfpplus16 l3-hw-offloading=no
Currently supported and unsupported feature list:
| Feature | Status | Description |
| IPv4 Unicast | HW | Depending on the complexity of routes in the routing table, the max HW accelerated route count could change (see hardware-specific limits below). Whole-byte IP prefixes (/8, /16, /24, etc.) occupy less HW space than others (e.g., /22). If the HW route limit is reached new routes will fall back to CPU, except cases when the newly added route overlaps with already existing routes processed by the hardware. In this case, destinations that were processed in hardware will continue to be processed in hardware. The user should choose the device with HW capability large-enough to store all the routes. |
| IPv6 Unicast | CPU | |
| IPv4 Multicast | CPU | |
| IPv6 Multicast | CPU | |
| ECMP | HW | See hardware-specific limits below |
| "blackhole" routes | HW | This feature enables the possibility to drop D/DOS attacks at wire speed |
| "prohibit" routes | CPU | |
| "unreachable" routes | CPU | |
| gateway=<interface_name> | HW/CPU | This works only for directly connected networks. Since HW does not know how to send ARP requests, CPU sends ARP request and waits for a reply to find out a DST MAC address on the first received packet of the connection that matches a DST IP address. After DST MAC is determined, HW entry is added and all further packets will be processed by the switch chip. |
| Bridge | HW | Routing from/to bridge interface |
| VLAN | HW | Routing between VLAN interfaces |
| LACP/Bonding | HW | |
| Firewall | FW | Only Fasttrack connections get processed by HW, which means that the CPU is processing packets until the connection gets fast-tracked. |
| NAT | FW | NAT rules applied to the offloaded Fasttrack connections are processed by HW. |
| QoS | N/A |
Where:
- CPU - feature is supported but processed by CPU
- HW - feature is supported and offloaded in hardware
- FW - feature is supported and offloaded in hardware (l3-hw-offloading=no for a specific switch port, l3-hw-offloading=yes must be enabled on switch level)
- N/A - feature is not available, meaning that L3 Hardware offloading MUST be disabled for these features to work
List of supported devices and their limits
DX8000 Series
The devices below are based on Marvell 98DX8xxx switch chips or the 98DX3257 model.
| Release | Routes | Nexthops | ECMP Groups | Fasttrack connections1,2 | NAT enties2 | |
| CRS317-1G-16S+ | 7.1beta1 | 150K - 240K | 8K | 4K | 4500 / 3750 3 | 8K 4 |
| CRS309-1G-8S+ | 7.1beta2 | 50K - 80K | 8K | 4K | 4500 / 3750 | 8K |
| CRS312-4C+8XG | 7.1beta2 | 50K - 80K | 8K | 4K | 2250 / 1500 | 8K |
| CRS326-24S+2Q+ | 7.1beta2 | 50K - 80K | 8K | 4K | 2250 / 1500 | 8K |
| CRS354-48G-4S+2Q+ | 7.1beta4 | 50K - 80K | 8K | 4K | 2250 / 1500 | 8K |
*1 When the HW limit of Fasttrack or NAT entries is reached, other connections will fall back to the CPU. MikroTik's smart connection offload algorithm ensures that the connections with the most traffic are offloaded to the hardware.
*2 Fasttrack connections share the same HW memory with ACL rules. Depending on the complexity, one ACL rule may occupy the memory of 3-6 Fasttrack connections.
*3 (Both MPLS and Bridge Port Extender are disabled) / (MPLS, Bridge Port Extender, or both are enabled). MPLS shares the HW memory with Fasttrack connections. Moreover, enabling MPLS requires the allocation of the entire memory region, which could store up to 750 Fasttrack connections otherwise. The same applies to Bridge Port Extender. However, MPLS and Bridge Port Extended may use the same memory region, so enabling them both doesn't double the limitation of Fasttrack connections.
*4 All NAT entries cannot be used due to the limited amount of Fasttrack connections.
DX3000/2000 Series
The devices below are based on Marvell 98DX224S, 98DX226S, or 98DX3236 switch chip model. Those devices do not support Fasttrack or NAT connection offloading.
These switch chips use different approach to offload IPv4 routes, instead of IP ranges used on DX8000 series chipsets, DX3000/2000 is using IP prefixes.
| Model | Release | IPv4 Route Prefixes1 | Nexthops | ECMP paths per prefix |
|---|---|---|---|---|
| CRS305-1G-4S+ | 7.1beta6 | 13312 | 4K | 8 |
| CRS318-1Fi-15Fr-2S | 7.1beta6 | 13312 | 4K | 8 |
| CRS318-16P-2S+ | 7.1beta6 | 13312 | 4K | 8 |
| CRS326-24G-2S+ | 7.1beta6 | 13312 | 4K | 8 |
| CRS328-24P-4S+ | 7.1beta6 | 13312 | 4K | 8 |
| CRS328-4C-20S-4S+ | 7.1beta6 | 13312 | 4K | 8 |
*1 Since total amount of routes are very limited, routes with higher netmask are preferred to be routed by hardware (e.g /32 /30 /29 etc, last route is 0.0.0.0/0 always processed by CPU).
Interface Lists
It is impossible to use interface lists directly to control l3-hw-offloading because an interface list may contain virtual interfaces (such as VLAN) while the l3-hw-offloading setting must be applied to physical switch ports only. For example, if there are two VLAN interfaces (vlan20 and vlan30) running on the same switch port (trunk port), it is impossible to enable hardware routing on vlan20 but keep it disabled on vlan30.
However, an interface list may be used as a port selector. The following example demonstrates how to enable hardware routing on LAN ports (ports that belong to the "LAN" interface list) and disable it on WAN ports:
:foreach i in=[/interface/list/member/find where list=LAN] do={
/interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=yes
}
:foreach i in=[/interface/list/member/find where list=WAN] do={
/interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=no
}
Please take into account that since interface lists are not used directly in the hardware routing control, modifying the interface list also does not automatically reflect into l3hw changes. For instance, adding a switch port to the "LAN" interface list does not automatically enable l3-hw-offloadingon that. The user has to rerun the above script to apply the changes.