That is a typical case for CPU, where each packet causes an interrupt, which, in turn, adds performance overhead. ASIC doesn't care much about the packet count.

Regarding small MTU tests (tests #1 and #2), I suppose that the bottleneck is on the packet generator or receiver side, not the CRS317. As you see, PPS (packets per second) value is almost the same in all three cases, and the transfer speed depends purely on packet size. That is a typical case for CPU, where each packet causes an interrupt, which, in turn, adds performance overhead. ASIC doesn't care much about the packet count.

Did some work on testing the L3 performance last week in 7.1beta2 and published it today.

https://stubarea51.net/2020/10/12/mikro ... e-testing/

Very very interesting.
Using RouterOS we could use BGP to have some internal routes (less than 1000).
we could route them L3 in hardware...
Is something related to fastpath here? Or can we use some firewall filters?
we wont need conntrack or something similar.

• l3hw=yes (a.k.a. full routing or l3-switching) - the entire routing table gets offloaded to the hardware; traffic gets routed entirely by HW; nothing goes though CPU, and therefore, ROS stateful firewall does not work.
• l3hw=fw - Firewall-compatible routing. Initially, packets go through CPU/Firewall, then Fasttrack connections get offloaded to the hardware. Consider this as a hardware-accelerated L4 stateful firewall. Unfortunately, the number of hardware connections is strictly limited by the capacity of the internal hardware memory.

/interface/ethernet/switch/rule/

In routerOS will be enabled fastpath then?

If we set some rules on the INPUT chain just to protect the router, we lose the hardware feature?

Is there a table? I have seen in the link at the first post, but it is not clear what the number means... 3750 connections, really? it is very low...

Thank you for you explanations.
The idea was to use a CRS to route l3 between interfaces at FAAAAST speed via BGP.
The issue is how can I protect the router itself then ?
Never tried the switch rules...

@raimondsp: can you kindly compare different modes of operation of l3hw to HW-offloaded L2? I can imagine many parallelisms, but as I don't have any experience with CRS3xx L3 offloading, I can't say if those parallelisms are real or imaginary.

• L2 HW offloading = bridging on the hardware level.
• L3 HW offloading = routing on the hardware level.

• VLAN100 on interfaces sfp-sfpplus1 - sfp-sfpplu4
• VLAN200 on sfp-sfpplu5 - sfp-sfppl8.

Hello and good morning.
I was not sure about your first claim about the input/output. Thank you very much for claryfing it.
So the CRS can be a full functional BGP router, with hw forwarding, I dont see the traffic passing by, it is not an issue, but I can protect the router itself.
At the moment I use a CCR1036+10G switch with fasttrack, It could be easily replaced with a CRS317 that has all the 10G ports on it.

@raimondsp: can you kindly compare different modes of operation of l3hw to HW-offloaded L2? I can imagine many parallelisms, but as I don't have any experience with CRS3xx L3 offloading, I can't say if those parallelisms are real or imaginary.

Basically:

From the wiki, I understand that L3 hardware offloading is currently only in the CRS317.

Recently one of MT support guys wrote that currently they're running feasibility study for supporting L3 switching on CRS328. He explicitly said that nothing is determined yet ... so it may end up with no L3 switching on this device ... and even if it does happen, it may take a while before it gets implemented.

Just to clearify all the doubts.

CRS317 with routeros 7 latest

sfpplus1 + 2 is a 802.3ad BOND (wan)
sfplus 15 +16 is a 802.3ad BOND (to backbone, towards users)
sfpplus 10 is a remote network
sfpplus 11 is a remote network

on all ports we have a /29 and we do plain BGP v4+v6, no filters on FORWARDED traffic
some users FROM the backbone (15+16) need to do a NAT src nat, very little traffic, mgmt traffic

is applicable the situation described above?
we currently have a 1072, and all the traffic !local is in slow-path no-track, we receive a l2tp vpn on the router with little traffic (mgmt). on peak hours evening we lost packets.
can we solve with the 317 hw forwarding?

• CRS317 switch chip supports hardware bonding, i.e., 802.3ad BOND can be offloaded to the hardware.
• CRRS317 supports up to 160-240k IPv4 routes prefixes. If that's enough for your BGP setup, the entire routing table can be offloaded to the hardware.
• IPv6 HW offloading is not supported yet. It is in development, though. But I wouldn't expect it sooner than by the end of the year. Until then, IPv6 routing is performed by the CPU, but CRS317's CPU is not sufficient to perform routing on a decent level.
• CRS317 is capable of doing NAT for FastTrack connections on the hardware level. The maximum number of offloaded FastTrack connections: 4608 (4.5K). To create a FastTrack connection, you need to redirect the initial packet to CPU/Firewall first. In your case, redirecting the entire port(-s) to the CPU is not an option because you will hit the FastTrack limit very quickly. But if it is possible to filter out the connections requiring NAT by IP, you can create switch ACL rules to do that on the hardware level. The next example redirects to the CPU traffic from 15 and 16 ports to the 10.1.0.0/16 subnet. Packets redirected to CPU go through the Firewall, and, therefore, may be subject to FastTrack/NAT, followed by HW offloading of the respective connections.
  
  Code: Select all

  interface/ethernet/switch/rule add ports=sfp-sfpplus15,sfp-sfpplus16 dst-address=10.1.0.0/16 redirect-to-cpu=yes
  

• Another option is to keep both CCR1072 (since you already have one) + CRS317, and forward packets that require NAT to CCR1072 while doing the rest of the routing on CRS317 hardware.

[*] IPv6 HW offloading is not supported yet. It is in development, though. But I wouldn't expect it sooner than by the end of the year.