...
Layer 3 Hardware Offloading (L3HW, otherwise known as IP switching or HW routing) allows to offload some router features onto the switch chip. This allows reaching wire speeds when routing packets, which would simply would not be possible with the CPU.
...
To enable Layer 3 Hardware Offloading, set l3-hw-offloading=yes for the switch:
| Code Block | ||
|---|---|---|
| ||
/interface/ethernet/switch set 0 l3-hw-offloading=yes |
...
Note that l3hw settings for switch and ports are different:
- Setting
l3-hw-offloading=nofor the switch completely disables offloading - all packets will be routed by CPU. - However, setting
l3-hw-offloading=nofor a switch port only disables hardware routing from/to this particular port. Moreover, the port can still participate in Fastrack connection offloading.
...
| Info |
|---|
Packets get routed by the hardware only if both source and destination ports have |
...
| Warning |
|---|
The existing connections may be unaffected by the |
L3HW Settings
Basic Settings
The L3HW Settings menu has been introduced in RouterOS version 7.6.
Sub-menu: /interface ethernet switch l3hw-settings
Property | Description |
|---|---|
| autorestart (yes | no; Default: no) | Automatically restarts the l3hw driver in case of an error. Otherwise, if an error occurs, l3-hw-offloading gets disabled, and the error code is displayed in the switch settings and #monitor. Autorestart does not work for system failures, such as OOM (Out Of Memory). |
| fasttrack-hw (yes | no; Default: yes (if supported)) | Enables or disables FastTrack HW Offloading. Keep it enabled unless HW TCAM memory reservation is required, e.g., for dynamic switch ACL rules creation. Not all switch chips support FastTrack HW Offloading (see hw-supports-fasttrack). |
| ipv6-hw (yes | no; Default: no) | Enables or disables IPv6 Hardware Offloading. Since IPv6 routes occupy a lot of HW memory, enable it only if IPv6 traffic speed is significant enough to benefit from hardware routing. |
| icmp-reply-on-error (yes | no; Default: yes) | Since the hardware cannot send ICMP messages, the packet must be redirected to the CPU to send an ICMP reply in case of an error (e.g., "Time Exceeded", "Fragmentation required", etc.). Enabling icmp-reply-on-error helps with network diagnostics but may open potential vulnerabilities for DDoS attacks. Disabling icmp-reply-on-error silently drops the packets on the hardware level in case of an error. |
...
Property | Description |
|---|---|
| hw-supports-fasttrack (yes | no) | Indicates if the hardware (switch chip) supports FastTrack HW Offloading. |
Advanced Settings
This menu allows tweaking l3hw settings for specific use cases.
...
| Warning |
|---|
It is |
...
NOT recommended to change the advanced L3HW settings unless instructed by MikroTik Support or MikroTik Certified Routing Engineer. Applying incorrect settings may break the L3HW operation. |
Sub-menu: /interface ethernet switch l3hw-settings advanced
Property | Description |
|---|---|
| route-queue-limit-high (number; Default: 256) | The switch driver stops route indexing when route-queue-size (see #monitor) exceeds this value. Lowering this value leads to faster route processing but increases the lag between a route's appearance in RouterOS and hardware memory. Setting route-queue-limit-high=0 disables route indexing when there are any routes in the processing queue - the most efficient CPU usage but the longest delay before hardware offloading. Useful when there are static routes only. Not recommended together with routing protocols (such as BGP or OSPF) when there are frequent routing table changes. |
| route-queue-limit-low (number; Default: 0) | Re-enable route indexing when route-queue-size drops down to this value. Must not exceed the high limit. Setting route-queue-limit-low=0 tells the switch driver to process all pending routes before the next hw-offloading attempt. While this is the desired behavior, it may completely block the hw-offloading under a constant BGP feed. |
| shwp-reset-counter (number; Default: 128) | Reset the Shortest HW Prefix (see ipv4-shortest-hw-prefix / ipv6-shortest-hw-prefix in #monitor) and try the full route table offloading after this amount of changes in the routing table. At a partial offload, when the entire routing table does not fit into the hardware memory and shorter prefixes are redirected to the CPU, there is no need to try offloading route prefixes shorter than SHWP since those will get redirected to the CPU anyway, theoretically. However, significant changes to the routing table may lead to a different index layout and, therefore, a different amount of routes that can be hw-offloaded. That's why it is recommended to do the full table re-indexing occasionally. Lowering this value may allow more routes to be hw-offloaded but increases CPU usage and vice-versa. Setting shwp-reset-counter=0 always does full re-indexing after each routing table change. This setting is used only during Partial Offloading and has no effect when ipv4-shortest-hw-prefix=0 (and ipv6, respectively). |
| partial-offload-chunk (number; Default: 1024, min: 16) | The minimum number of routes for incremental adding in Partial Offloading. Depending on the switch chip model, routes are offloaded either as-is (each routing entry in RouterOS corresponds to an entry in the hardware memory) or getting indexed, and the index entries are the ones that are written into the hardware memory. This setting is used only for the latter during Partial Offloading. Depending on index fragmentation, a single IPv4 route addition can occupy from -3 to +6 LPM blocks of HW memory (some route addition may lower the amount of required HW memory thanks to index defragmentation). Hence, it is impossible to predict the exact number of routes that may fit in the hardware memory. The switch driver uses a binary split algorithm to find the maximum number of routes that fit in the hardware. Let's imagine 128k routes, all of them not fitting into the hardware memory. The algorithm halves the number and tries offloading 64k routes. Let's say offloading succeeded. In the next iteration, the algorithm picks 96k, let's say it fails; then 80k - fails again, 72k - succeeds, 76k, etc. until the difference between succeeded and failed numbers drops below the partial-offload-chunk value. Lowering the partial-offload-chunk value increases the number of hw-offloaded routes but also raises CPU usage and vice-versa. |
| route-index-delay-min (time; Default: 1s) | The minimum delay between route processing and its offloading. The delay allows processing more routes together and offloading them at once, saving CPU usage. It also makes offloading the entire routing table faster by reducing the per-route processing work. On the other hand, it slows down the offloading of an individual route. If an additional route is received during the delay, the latter resets to the route-index-delay-min value. Adding more and more routes within the delay keeps resetting the timer until the route-index-delay-max is reached. |
| route-index-delay-max (time; Default: 10s) | The maximum delay between route processing and its offloading. When the maximum delay is reached, the processed routes get offloaded despite more routes pending. However, route-queue-limit-high has higher priority than this, meaning that the indexing/offloading gets paused anyway when a certain queue size is reached. |
| neigh-keepalive-interval (time; Default: 15s, min: 5s) | Neighbor (host) keepalive interval. When a host (IP neighbor) gets hw-offloaded, all traffic from/to it is routed by the switch chip, and RouterOS may think the neighbor is inactive and delete it. To prevent that, the switch driver must keep the offloaded neighbors alive by sending periodical refreshes to RouterOS. |
| neigh-discovery-interval (time; Default: 1m37s, min: 30s) | Unfortunately, switch chips do not provide per-neighbor stats. Hence, the only way to check if the offloaded host is still active is by sending occasional ARP (IPv4) / Neighbor Discovery (IPv6) requests to the connected network. Increasing the value lowers the broadcast traffic but may leave inactive hosts in hardware memory for longer. Neighbor discovery is triggered within the neighbor keepalive work. Hence, the discovery time is rounded up to the next keepalive session. Choose a value for neigh-discovery-interval not dividable by neigh-keepalive-interval to send ARP/ND requests in various sessions, preventing broadcast bursts. |
| neigh-discovery-burst-limit (number; Default: 64) | The maximum number of ARP/ND requests that can be sent at once. |
| neigh-discovery-burst-delay (time; Default: 300ms, min: 10ms) | The delay between ARP/ND subsequent bursts if the number of requests exceeds neigh-discovery-burst-limit. |
| Info |
|---|
Some settings only apply to certain switch models. |
Monitor
The L3HW Monitor feature has been introduced in RouterOS version 7.10. It allows monitoring of switch chip and driver stats related to L3HW.
| Code Block | ||
|---|---|---|
| ||
/interface/ethernet/switch/l3hw-settings/monitor
ipv4-routes-total: 99363
ipv4-routes-hw: 61250
ipv4-routes-cpu: 38112
ipv4-shortest-hw-prefix: 24
ipv4-hosts: 87
ipv6-routes-total: 15
ipv6-routes-hw: 11
ipv6-routes-cpu: 4
ipv6-shortest-hw-prefix: 0
ipv6-hosts: 7
route-queue-size: 118
fasttrack-ipv4-conns: 2031
fasttrack-hw-min-speed: 0
nexthop-cap: 8192
nexthop-usage: 93 |
Stats
Property | Description |
|---|---|
| ipv4-routes-total | The total number of IPv4 routes handled by the switch driver. |
| ipv4-routes-hw | The number of hardware-offloaded IPv4 routes (a.k.a. hardware routes) |
| ipv4-routes-cpu | The number of IPv4 routes redirected to the CPU (a.k.a. software routes) |
| ipv4-shortest-hw-prefix | Shortest Hardware Prefix (SHWP) for IPv4. If the entire IPv4 routing table does not fit into the hardware memory, partial offloading is applied, where the longest prefixes are hw-offloaded while the shorter ones are redirected to the CPU. This field shows the shortest route prefix (/x) that is offloaded to the hardware memory. All prefixes shorter than this are processed by the CPU. "ipv4-shortest-hw-prefix=0" means the entire IPv4 routing table is offloaded to the hardware memory. |
| ipv4-hosts | The number of hardware-offloaded IPv4 hosts (/32 routes) |
| ipv6-routes-total 1 | The total number of IPv6 routes handled by the switch driver. |
| ipv6-routes-hw 1 | The number of hardware-offloaded IPv6 routes (a.k.a. hardware routes) |
| ipv6-routes-cpu 1 | The number of IPv6 routes redirected to the CPU (a.k.a. software routes) |
| ipv6-shortest-hw-prefix 1 | Shortest Hardware Prefix (SHWP) for IPv6. If the entire IPv6 routing table does not fit into the hardware memory, partial offloading is applied, where the longest prefixes are hw-offloaded while the shorter ones are redirected to the CPU. This field shows the shortest route prefix (/x) that is offloaded to the hardware memory. All prefixes shorter than this are processed by the CPU. "ipv6-shortest-hw-prefix=0" means the entire IPv6 routing table is offloaded to the hardware memory. |
| ipv6-hosts 1 | The number of hardware-offloaded IPv6 hosts (/128 routes) |
| route-queue-size | The number of routes in the queue for processing by the switch chip driver. Under normal working conditions, this field is 0, meaning that all routes are processed by the driver. |
| fasttrack-ipv4-conns 2 | The number of hardware-offloaded FastTrack connections. |
| fasttrack-hw-min-speed 2 | When the hardware memory for storing FastTrack is full, this field shows the minimum speed (in bytes per second) of a hw-offloaded FastTrack connection. Slower connections are routed by the CPU. |
1 IPv6 stats appear only when IPv6 hardware routing is enabled (ipv6-hw=yes)
2 FastTrack stats appear only when hardware offloading of FastTrack connections is enabled (fasttrack-hw=yes)
Advanced Monitor
An enhanced version of Monitor with extra telemetry data for advanced users. Advanced Monitor contains all data from the basic monitor plus the fields listed below.
| Code Block | ||
|---|---|---|
| ||
/interface/ethernet/switch/l3hw-settings/advanced> monitor once
ipv4-routes-total: 29968
ipv4-routes-hw: 29957
ipv4-routes-cpu: 11
ipv4-shortest-hw-prefix: 0
ipv4-hosts: 3
ipv6-routes-total: 4
ipv6-routes-hw: 0
ipv6-routes-cpu: 4
ipv6-shortest-hw-prefix: 0
ipv6-hosts: 0
route-queue-size: 0
route-queue-rate: 0
route-process-rate: 0
fasttrack-ipv4-conns: 0
fasttrack-queue-size: 0
fasttrack-queue-rate: 0
fasttrack-process-rate: 0
fasttrack-hw-min-speed: 0
fasttrack-hw-offloaded: 0
fasttrack-hw-unloaded: 0
lpm-cap: 54560
lpm-usage: 31931
lpm-bank-cap: 2728
lpm-bank-usage: 46,0,0,0,2589,2591,1983,0,2728,2728,2728,2728,2728,2728,2728,2728,2728,170,0,0
pbr-cap: 8192
pbr-usage: 0
pbr-lpm-bank: 3
nat-usage: 0
nexthop-cap: 8192
nexthop-usage: 85 |
Stats
Property | Description |
|---|---|
| route-queue-rate | The rate at which routes are added to the queue for the switch driver processing. In other words, the growth rate of route-queue-size (routes per second) |
| route-process-rate | The rate at which previously queued routes are processed by the switch driver. In other words, the shrink rate of route-queue-size (routes per second) |
| fasttrack-queue-size | The number of FastTrack connections in the queue for processing by the switch chip driver. |
| fasttrack-queue-rate | The rate at which FastTrack connections are added to the queue for the switch driver processing. In other words, the growth rate of fasttrack-queue-size (connections per second) |
| fasttrack-process-rate | The rate at which previously queued FastTrack connections are processed by the switch driver. In other words, the shrink rate of fasttrack-queue-size (connections per second) |
| fasttrack-hw-offloaded | The number of FastTrack connections offloaded to the hardware. The counter resets every second (or every monitor interval). |
| fasttrack-hw-unloaded | The number of FastTrack connections unloaded from the hardware (redirected to software routing). The counter resets every second (or every monitor interval). |
| lpm-cap | The size of the LPM hardware table (LPM = Longest Prefix Match). LPM stores route indexes for hardware routing. Not every switch chip model uses LPM. Others use TCAM. |
| lpm-usage | The number of used LPM blocks. lpm-usage / lpm-cap = usage percentage. |
| lpm-bank-cap | LPM memory is organized in banks - special memory units. The bank size depends on the switch chip model. This value shows the size of a single bank (in LPM blocks). lpm-cap / lpm-bank-cap = the number of banks (usually, 20). |
| lpm-bank-usage | Per-bank LPM usage (in LPM blocks) |
| pbr-cap | The size of the Policy-Based Routing (PBR) hardware table. PBR is used for NAT offloading of FastTrack connections. |
| pbr-usage | The number of used PBR entries. pbr-usage / pbr-cap = usage percentage. |
| pbr-lpm-bank | PBR shares LPM memory banks with routing tables. This value shows the LPM bank index shared with PBR (0 = the first bank). |
| nat-usage | The number of used NAT hardware entries (for FastTrack connections). |
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:
| Code Block | ||
|---|---|---|
| ||
: |
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:
| Code Block | ||
|---|---|---|
| ||
: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 directly used directly in the hardware routing control., modifying the interface list also does not automatically reflect into in l3hw changes. For instance, adding a switch port to the "LAN" interface list does not automatically enable l3-hw-offloading on thatit. The user has to rerun the above script to apply the changes.
...
| Info |
|---|
It is recommended to disable l3-hw-offloading while changing the MTU/L2MTU values on the interfaces. |
...
- adding/removing/enabling/disabling bridge;
- adding/removing switch ports to/from the bridge;
- bonding switch ports / removing bond;
- changing VLAN settings;
- changing MTU/L2MTU on switch ports;
- changing ethernet (MAC) addresses.
In short, disable l3-hw-offloading while making changes under /interface/bridge/ and /interface/vlan/:
| Code Block | ||||
|---|---|---|---|---|
| ||||
/interface/ethernet/switch set 0 l3-hw-offloading=no /interface/bridge # put bridge configuration changes here /interface/vlan # define/change VLAN interfaces /interface/ethernet/switch set 0 l3-hw-offloading=yes |
...
There is a limitation for MAC telnet and RoMON when L3HW offloading is enabled on 98DX8xxx, 98DX4xxx, or 98DX325x switch chips. Packets from these protocols are dropped and do not reach the CPU, thus access to the device will fail.
...
/interface/vlan add interface=ether2 name=vlan20 vlan-id=20
Assign the VLAN interface to the bridge instead. This way, VLAN configuration gets offloaded to the hardware, and, with L3HW enabled, the traffic is subject to inter-VLAN hardware routing.
...
| Info |
|---|
For Inter-VLAN routing, the bridge interface must be a tagged member of every routable /interface/bridge/vlan/ entry. |
L3HW MAC Address Range Limitation (DX2000/DX3000 series only)
Marvell Prestera DX2000 and DX3000 switch chips have a hardware limitation that allows configuring only the last (least significant) octet of the MAC address for each interface. The other five (most significant) octets are configurated configured globally and, therefore, must be equal for all interfaces (switch ports, bridge, VLANs). In other words, the MAC addresses must be in the format "XX:XX:XX:XX:XX:??", where:
...
- Standalone switch ports (not bridge members) with hardware routing enabled (
l3-hw-offloading=yes). - Bridge itself.
- VLAN interfaces (those are using that use the bridge's MAC address by default).
...
For example, if we know that the majority of traffic flows to the network where servers are located, we can enable offloading only to that specific destination:
...
| Warning |
|---|
H-flag does not indicate that the route is actually HW offloaded, it indicates only that the route can be selected to be HW offloaded. |
...
First, not all devices support Fasttrack HW Offloading. And , and without HW offloading, Firewall Filter uses only software routing, which is dramatically slower than its hardware counterpart. Second, even if Fasttrack HW Offloading is an option, a rule of thumb is:
...
Of course, ACL rules cannot match everything. For instance, ACL rules cannot filter connection states: accept established, drop others. That is where Fasttrack HW Offloading gets into action - redirect the packets to the CPU by default for firewall filtering, then offload the established Fasttrack connections. However, disabling l3-hw-offloading for the entire switch, port is not the only option.
| Info |
|---|
Define ACL rules with |
...
- Within the same VLAN (e.g., sfp1-sfp4), traffic is forwarded by the hardware on Layer 2 (L2HW).
- Inter-VLAN traffic (e.g. sfp1-sfp5) is routed by the hardware on Layer 3 (L3HW).
- Traffic from/to the WAN port gets processed by the CPU/Firewall first. Then Fasttrack connections get offloaded to the hardware hardware (Hardware-Accelerated L4 Stateful Firewall). NAT applies both on CPU- and HW-processed packets.
- Traffic to the management port is protected by the Firewall.
...
Below are typical user errors of in configuring Layer 3 Hardware Offloading.
VLAN interface on a switch port or bond
| Code Block | ||
|---|---|---|
| ||
/interface vlan /vlan add name=vlan10 vlan-id=10 interface=sfp-sfpplus1 add name=vlan10vlan20 vlan-id=1020 interface=sfp-sfpplus1bond1 |
VLAN interface must be set on the bridge due to Layer 2 Dependency. Otherwise, L3HW will not work. The correct configuration is:
| Code Block | ||
|---|---|---|
| ||
/interface /bridge /port add bridge=bridge1 interface=sfp-sfpplus1 pvid=10 /interface bridge vlan frame-types=admit-only-vlan-tagged add bridge=bridge1 interface=bond1 frame-types=admit-only-vlan-tagged /interface/bridge/vlan add bridge=bridge1 tagged=bridge1,sfp-sfpplus1 vlan-ids=10 add bridge=bridge1 tagged=bridge1,bond1 vlan-ids=20 /interface vlan /vlan add name=vlan10 vlan-id=10 interface=bridge1 add name=vlan10vlan20 vlan-id=1020 interface=bridge1 |
Not adding the bridge interface to /
...
interface/
...
bridge/vlan/
For Inter-VLAN routing, the bridge interface itself needs to be added to the tagged members of the given VLANs. In the next example, Inter-VLAN routing works between VLAN 10 and 11, but packets are NOT routed to VLAN 20.
...
| Code Block | ||
|---|---|---|
| ||
[admin@crs312] /interface/ethernet/switch> print
Columns: NAME, TYPE, L3-HW-OFFLOADING
# NAME TYPE L3-HW-OFFLOADING
0 switch1 Marvell-98DX8212 yes
1 switch2 Atheros-8227 no
[admin@crs312] /interface/ethernet/switch> port print
Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
# NAME SWITCH L3-HW-OFFLOADING STORM-RATE
0 ether9 switch2
1 ether1 switch1 yes 100
2 ether2 switch1 yes 100
3 ether3 switch1 yes 100
4 ether4 switch1 yes 100
5 ether5 switch1 yes 100
6 ether6 switch1 yes 100
7 ether7 switch1 yes 100
8 ether8 switch1 yes 100
9 combo1 switch1 yes 100
10 combo2 switch1 yes 100
11 combo3 switch1 yes 100
12 combo4 switch1 yes 100
13 switch1-cpu switch1 100
14 switch2-cpu switch2 |
Relying on Fasttrack HW Offloading too much
100
13 switch1-cpu switch1 100
14 switch2-cpu switch2 |
Relying on Fasttrack HW Offloading too much
Since Fasttrack HW Offloading offers near-the-wire-speed performance at zero configuration overhead, the users are tempted to use it as the default solution. However, the number of HW Fasttrack connections is very limited, leaving the other traffic for the CPU. Try using the hardware routing as much as possible, reduce the CPU traffic to the minimum via switch ACL rules, and then fine-tune which Fasttrack connections to offload with firewall filter rules.
Trying to offload slow-path connections
Using certain configurations (e.g. enabling bridge "use-ip-firewall" setting, creating bridge nat/filter rules) or running specific features like sniffer or torch can disable RouterOS FastPath, which will affect the ability to properly FastTrack and HW offload connections. If HW offloaded Fasttrack is required, make sure that there are no settings that disable the FastPath and verify that connections are getting the "H" flag or use the L3HW monitor command to see the amount of HW offloaded connectionsSince Fasttrack HW Offloading offers near-the-wire-speed performance at zero configuration overhead, the users tempt to use it as the default solution. However, the number of HW Fasttrack connections is very limited, leaving the other traffic for the CPU. Try using the hardware routing as much as possible, reduce the CPU traffic to the minimum via switch ACL rules, and then fine-tune which Fasttrack connections to offload with firewall filter rules.
L3HW Feature Support
- HW - the feature is supported and offloaded to the hardware.
- CPU - the feature is supported but performed by software (CPU)
- N/A - the feature is not available together with L3HW. Layer 3 hardware offloading must be completely disabled (switch
l3-hw-offloading=no) to make this feature work. - FW - the feature requires
l3-hw-offloading=nofor a given switch port. On the switch level,l3-hw-offloading=yes.
...
| Feature | Support | Comments | Release | |||
|---|---|---|---|---|---|---|
| IPv4 Unicast Routing | HW | 7.1 | ||||
| IPv6 Unicast Routing | HW | /interface/ethernet/switch/l3hw-settings/set ipv6-hw=yes | 7.6 | |||
| IPv4 Multicast Routing | CPU | |||||
| IPv6 Multicast Routing | CPU | |||||
| ECMP | HW | Multipath routing | 7.1 | |||
| Blackholes | HW | /ip/route add dst-address=10.0.99.0/24 blackhole | 7.1 | |||
| gateway=<interface_name> | CPU/HW | /ip/route add dst-address=10.0.0.0/24 gateway=ether1 This works only for directly connected networks. Since HW does not know how to send ARP requests, | 7.1 | |||
| BRIDGE | HW | IP Routing from/to hardware-offloaded bridge interface. | 7.1 | |||
| VLAN | HW | Routing between VLAN interfaces that are created on hardware-offloaded bridge interface with vlan-filtering. | 7.1 | |||
| Bonding | HW | /interface/bonding | 7.1 | |||
| IPv4 Firewall | FW | Users must choose either HW-accelerated routing or firewall. Firewall rules get processed by the CPU. Fasttrack connections get offloaded to HW. | 7.1 | |||
| IPv4 NAT | FW | NAT rules applied to the offloaded Fasttrack connections get processed by HW too. | 7.1.1 | |||
| MLAG | N/A | |||||
| VRF | N/A | Only the main routing table gets offloaded. If VRF is used together with L3HW and packets arrive on a switch port with l3-hw-offloading=yes, packets can be incorrectly routed through the main routing table. To avoid this, disable L3HW on needed switch ports or use ACL rules to redirect specific traffic to the CPU. | ||||
| VRRPMLAG | N/AVRF | |||||
| Controller Bridge and Port Extender | N/A | |||||
| Only the main routing table gets offloaded. | VRRP | N/A | VXLAN | CPU | ||
| MTU | HW | The hardware supports up to 8 MTU profiles. | 7.1 | |||
| QinQ and tag-stacking | CPU | Stacked VLAN interfaces will lose HW offloading, while other VLANs created directly on the bridge interface can still use HW offloading. |
Only the devices listed in the table below support L3 HW Offloading.
...
| Model | Switch Chip | Release | IPv4 Route Prefixes1 | IPv6 Route Prefixes2 | Nexthops | ECMP paths per prefix3 |
|---|---|---|---|---|---|---|
| CRS305-1G-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS310-1G-5S-4S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS310-8G+2S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS318-1Fi-15Fr-2S | 98DX224S | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS318-16P-2S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS326-24G-2S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS328-24P-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
| CRS328-4C-20S-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
1 Since the total amount of routes that can be offloaded is limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g., /32, /30, /29, etc.), any other prefixes that do not fit in the HW table will be processed by the CPU. Directly connected hosts are offloaded as /32 (IPv4) or /128 (IPv6) route prefixes, the . The number of hosts is also limited by max-neighbor-entries in IP Settings / IPv6 Settings.
...
| Model | Switch Chip | Release | IPv4 Routes 1 | IPv4 Hosts 7 | IPv6 Routes8 | IPv6 Hosts7 | Nexthops | Fasttrack connections 2,3,4 | NAT entries 2,5 |
|---|---|---|---|---|---|---|---|---|---|
| CRS317-1G-16S+ | 98DX8216 | 7.1 | 120K - 240K | 64K | 30K - 40K | 32K | 8K | 4.5K | 4K |
| CRS309-1G-8S+ | 98DX8208 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 4.5K | 4K3.9K |
| CRS312-4C+8XG | 98DX8212 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
| CRS326-24S+2Q+ | 98DX8332 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
| CRS354-48G-4S+2Q+, CRS354-48P-4S+2Q+ | 98DX3257 6 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
| CRS504-4XQ | 98DX4310 | 7.1 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
| CRS510-8XS-2XQ | 98DX4310 | 7.3 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
| CRS518-16XS-2XQ | 98DX8525 | 7.3 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
...
4 MPLS shares the HW memory with Fasttrack connections. Moreover, enabling MPLS requires the allocation of the entire memory region, which could otherwise store up to 768 (0.75K) Fasttrack connections. The same applies to the Bridge Port Extender. However, MPLS and BPE may use the same memory region, so enabling them both doesn't double the limitation of Fasttrack connections.
...
8 IPv4 and IPv6 routing tables share the same hardware memory.
CCR2000
| Model | Switch Chip | Release | IPv4 Routes | IPv4 Hosts | IPv6 Routes | IPv6 Hosts | Nexthops | Fasttrack connections | NAT entries |
|---|---|---|---|---|---|---|---|---|---|
| CCR2116-12G-4S+ | 98DX3255 1 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
| CCR2216-1G-12XS-2XQ | 98DX8525 | 7.1 | 60K - 120K | 64K | 15K - 20K | 32K | 8k | 4.5K | 4K |
...