Recently, it has been documented by Mikrotik that the L3 hardware offloading feature is not yet compatible with the MLAG feature and that therefore “l3-hw-offloading” must be disabled globally at the switch level whenever MLAG is used.
This is very unfortunate because it’s a huge limitation of the usability of the (much appreciated) new MLAG feature (basically, it restricts it to a switching-only use-case then). I think many use-cases would benefit from being able to use MLAG and L3HW together and so I’d request implementing support for this. Thanks!
Which switch(es) are we talking about? You don’t say, either here or in the other thread. Lacking that detail, let’s look at the one the thread-starter is using, the netPower 16P, which has a lowly single-core 800 MHz processor. That’s not much for routing.
If you need L3HW to get acceptable performance on such low-end hardware, it’s a sign of this very problem: you’ve picked underpowered hardware. It’s a nice feature to have to keep CPU usage low, and it may be essential at the high end where no more CPU power is reasonably available, but to be utterly reliant upon it otherwise seems like you’re pinching pennies somewhere.
Lacking details of your reason to want this combination of features, I’ll offer a few alternative suggestions blindly:
First, router-on-a-stick: Add a proper router to the system — being one sized to carry your traffic at line rates — then configure bridge VLAN filtering on the switches to distribute traffic in hardware at line rates per the VLAN tags assigned by the router.
Second, if your purpose for MLAG is bonding switches together for manageability, the Controller Bridge and Port Extender feature may do what you want.
I have personally run into this limitation on the CRS3xx series of switches.
I would really like for Mikrotik to add this capability, with MLAG + L3HW + VRRP you can build a compact, high performance, low latency and redundant core switching/routing platform
I also run in this limitation while testing two CRS326-24S+2Q+ for a small cluster.
While MLAG alone works fine for storage and VM traffic, the combination of MLAG + L3HW + VRRP for the Hypervisor management would be much appreciated, since even for backup tasks the software routing capabilities of the CRS326-24S+2Q+ are too weak.
+1 for this as well. I’m using a pair of CCR2216s as the backplane for a hyperconverged ceph/kubernetes cluster with Cilium CNI using native routing (cilium providing routes via BGP (so layer 3)). Presently using jumbo frames and LACP, and able to get nearly 400 gbit through the router with some simple routes, bridges, iptables - which is amazing, but achieved via l3hw offloading.
I am building out this lab cluster to be n+1 highly available, but the lack of MLAG/l3hw offloading is a problem. I’m sure my throughput would plummet without it.
In the meantime, considering alternative architectures like: