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 |
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 |
By default all the routes are participating to be hardware candidate routes. To further fine-tune which traffic to offload, there is an option for each route to disable/enable suppress-hw-offload
.
For example if we know that majority of traffic flows to the network where servers are located, we can enable offloading only to that specific destination:
/ip/route set [find where static && dst-address!="192.168.3.0/24"] suppress-hw-offload=yes |
Now only route to 192.168.3.0/24 has H-flag, indicating that it will be the only one eligible to be selected for HW offloading.
[admin@MikroTik] > /ip route/print where static Flags: A - ACTIVE; s - STATIC, y - COPY; H - HW-OFFLOADED Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY D 0 As 0.0.0.0/0 172.16.2.1 1 1 As 10.0.0.0/8 10.155.121.254 1 2 AsH 192.168.3.0/24 172.16.2.1 1 |
H-flag does not indicate that route is actually HW offloaded, it indicates only that route can be selected to be HW offloaded. |
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 switch1 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:
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.
The devices below are based on Marvell 98DX224S, 98DX226S, or 98DX3236 switch chip model. Those devices do not support Fasttrack or NAT connection offloading.
The 98DX3257 model is an exception, which has a feature set of the DX8000 rather than the DX3000 series. |
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 prefix2 |
---|---|---|---|---|
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 that can be offloaded is very limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g /32 /30 /29 etc, last route is 0.0.0.0/0 always processed by CPU), any other prefix that does not fit in the HW table will be processed by the CPU.
*2 If a route has more paths than the hardware ECMP limit (X), only the first X paths get offloaded.
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-offloading
on that. The user has to rerun the above script to apply the changes.