First, let me be clear: I understand these devices are intended to be used primarily as switches, not routers.
That said, both feature an AL52400 CPU running at 2 GHz, which on paper should give them enough processing power to compete with the CCR2004—a purpose-built router. That makes it reasonable to consider certain remote or edge use cases where they might handle some routing alongside their primary switching role.
And indeed, according to the routing benchmarks on MikroTik’s product pages, the CRS520 performs on par with—or even slightly better than—the CCR2004.
What I’m struggling to understand is why the CRS812 performs significantly worse at routing than the CRS520, again based on the published figures, even though they sport the same CPU. We’re talking roughly half the throughput if FastPath is excluded. I’m aware that the internal connection between the switch chip and the CPU is limited to 10 Gbps on the CRS812, versus 2×25 Gbps on the CRS520, but that alone doesn’t seem sufficient to explain such a large gap.
In fact, the CRS812 appears to perform slightly worse than the RB5009, which also has a 10 Gbps internal CPU bus, but also has an inferior CPU.
I hear you, but I don’t think that’s the cause. The routing figures Mikrotik shows with 25 firewall rules suggest that L3HW offload is not in use—at least as of the last time I checked, you can’t run hardware-accelerated routing and firewall/NAT simultaneously.
Additionally, and for reference, the CCR2004 does not support L3HW offload. It doesn’t have a true switch chip, only a “pipe” chip that funnels all traffic from every port to the CPU. Despite that, the CCR2004 and the CRS520 deliver roughly the same performance, which is consistent with the fact that both use four-core CPUs from the same family operating at similar clock speeds. This would suggest that the performance figures reported for the CRS520 are not making use of L3 hardware offload.
Yes, that’s what speedheed was saying as well. But again, it doesn’t add up since you can’t have L3HW offload with the “25 ip filter rules” benchmark they use, unless I’m completely off here. From the L3HW page, it’s clear FW/NAT and L3HW are mutually exclusive. See L3 Hardware Offloading - RouterOS - MikroTik Documentation
The next example enables hardware routing on all ports but 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 0 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
And again, the CCR2004 is a good reference for comparison purposes, it does not support L3HW offload and yet it performs similarly to the CRS520.
I know that the cx8500 is not the exact switch chip that the CRS520 have but i couldnt find the exact document for it.
As I read it out from the documents, the switch chip used in the CRS812 is more flexible, doesn’t have so many high-end features and is less power-hungry than the switch chip in the CRS520.
Not true. Some devices can offload fasttracked connections. So those can effectively do "25 filter rules" in hardware.
Official L3HW offload manual at L3 Hardware Offloading - RouterOS - MikroTik Documentation doesn't list any missing feature for CRS520 while it does state that fasttrack offload (and a few other features) is work in progress for CRS8xx.
Fasttrack connections actually bypass the whole packet inspection, i.e. no filter rules and no traffic shaping are applied, so no firewall for them. It’s either fasttrack or FW/CPU for a given connection.
At the end of the day, using fasttrack defeats the whole point of doing a “25 filter rules” test if the rules end up being bypassed…
Your interpretation is probably not aligned with what MT uses when writing about device performance. The stanza about "25 firewall rules" describes device configuration ... NOT the way things are handled behind the scenes. I've never seen any official explanation about what particular configuration is used (fasttrack rule or not), but real-life experience says that active fasttrack is required most of times to achieve performance anywhere near official numbers.
And no, fasttracking packets doesn't mean "no firewall". Initial packets of those connections have been classified and processed, subsequent packets have to meet strict criteria to be considered part of same connection. Yes, they are not subject to L6 or L7 firewall (but that's true for almost all packets passing ROS firewall).
Alright, I got tired of the theory and dropped one into the lab (CRS812). I’m seeing ~2.5 Gbps on a single connection (around 20% CPU so about one core) and about 6 Gbps with multiple connections (CPU pegged at nearly 100%). That’s with our standard 20 filter rules plus 30 raw rules. No fastpath, no fasttrack, no L3HW. Not too shabby.