I doubt it because after a fresh reboot, we’re able to get that same issue to come back by disabling & re-enabling a port within a 30 second time frame. Our hosts table in the bridge never exceeded 670 at its peak.
For what it’s worth, 7.19.x (3-6) has been the most stable release for my entire network, both routing and switching.
Only a handful of redundant core routers are on 7.20.6 at the moment. None of my production switches are.
Updates for my MLAG switches lag (no pun intended) behind for a few releases, mostly because switching is pretty straightforward. Even if the release notes say that 7.2x “fixes” some bug with switching, unless I’m seeing it, it’s not worth the risk of destabilizing the various network cores.
As I said in the other thread…
If it works, breaks, works again, breaks again, based on various code releases, it’s not a production-ready feature.
Use at your own risk.
Hi, I did exactly the same Lab with 7.22.1. I get the same behavior, even worse. Did you ever manage to make it work? Working with claude, the only solution that i found is to put the edge=yes on the uplinks between MLAG pairs.
RouterOS version: 7.22.2
RouterBOARD firmware: 7.22.2
I’m running into an MLAG issue with a setup that has three MLAG pairs.
The issue only happens on the right-side MLAG pair (SW04: CRS520-4XS-16XQ + SW05: CRS520-4XS-16XQ) This pair is connected upstream to SW01/SW06 using bonding3.
When edge=no is configured on bonding3 on SW04/SW05, the MLAG pair breaks after a topology change or after rebooting one of the other switches in the topology, for example: SSW01 / SSW02 / SW01 / SW06.
After this happens, SW04/SW05 do not recover by themselves. The only way I have found to restore the MLAG pair is to reboot either SW04 or SW05.
If I set edge=yes on bonding3, the issue seems to be mitigated. However, I do not think this is the correct setting, because bonding3 is a core/uplink connection, not an edge/access port.
My questions:
-
Is
edge=nothe correct setting for an MLAG/core/uplink bond like this? -
Could this be a RouterOS MLAG/STP issue, or am I missing something in the configuration?
One thing I find really odd is that this only seems to happen with the MLAG pair that consists of 2x CRS520-4XS-16XQ.
The center MLAG pair, which is CRS520-4XS-16XQ + CRS326-24S+2Q+, does not show the same symptoms in the same topology.
So far the issue appears to be specific to the CRS520 + CRS520 MLAG pair. Any ideas or suggestions are welcome.
UPDATE(Official Mikrotik support reply):
"We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now.
The underlying issue is that RouterOS MLAG currently does not synchronize the STP port states on dual-connected bonds. Using edge=auto is workaround as you already found out"
Have you noticed it happening on older releases? For example, my MLAG stacks are all running 7.19.6 still.
We started in April'26 with using Mikrotik on v7.22.1, never worked with older versions so I honestly don't know.
Following up on this. I've downgraded both CRS520 switches to 7.19.6 and all my MLAG issues seem to have gone away.
Had similar problems - massive flooding to almost all ports for actually no reason - and downgraded to 7.19.6 as per your advice. That made the whole thing close to fine - just a handful of packets every 2-5 minutes at ports the were not supposed to appear. I created a bug report and after a while got the reccommendation to try 7.24rc3. Installed it to 2x CRS309-1G-8S+ yesterday. So far everything looks fine - no more flooding or the occasional wrongly delivered packets as under 7.19.6. Seems like this 7.2r release could be an option and worth a try.
Hi everyone,
Has anyone tested the latest RoOS?
According to the changelogs, version 7.24.2 should include the MLAG fixes from 7.24rc3.
I’ve already spent quite a few sleepless nights dealing with the MLAG issue... L2 loops, etc. I really hope it works now.
Thanks in advance
I have a stack of 8 MLAG switches LAG'd together (two at top, splits to one leg of two in a row and a second pair of switches on another leg).
I upgraded them all to 7.24.2 last week and had problems all week. Something was causing one pair of switches to lose hundreds of MAC addresses at a time, and then they'd eventually come back. It would remain stable for a few minutes to a couple hours, then do it over again.
I did change some of my STP settings, including changing priorities of the switches so they were all higher than anything plugged into them. I also changed more ports to Edge ports, but those things alone didn't keep the random MAC drop from happening.
I eventually moved three of the pairs to 7.23.5, and left my internal stack of switches (the second leg) on 7.24.2. After they all settled down from being rebooted, they've been stable ever since.
So, for you, it might work fine, or you might want to hold off.
Thank you very much!
That helps me assess the situation—I only have two switches in the MLAG cluster as core. Since the problems persist—and that’s really annoying with hypervisors—I’ll try version 7.24.2 and hope for the best 
. Thanks again!
It's been a few years now since I created this topic, and it's amazing that it is still going.
I think Mikrotik needs to be more honest with it's users about what the capabilities of the different hardware platforms really are.
For instance, they claim switches with lower-end CPU's like the CRS326-24S+ (single-core 650Mhz MIPS) are good for up to 1000 hosts in the FDB. But they don't really factor in STP technology or STP size in that calculation. Having several VLANs and access switches below a "core" of CRS326-24S+ switches running MLAG and MSTi instanaces, might fundamentally reduce the actual FDB size to say a couple hundred hosts.
Most likely a CRS317 with its more powerful dual-core 800Mhz ARM will handle a much larger L2 topology.
It's unfortunate that obviously capable switch hardware like the CRS326-24S+ and CRS504 are constrained by the relatively tiny 650Mhz MIPS core. It significantly reduces the capability of "whole" switch. It's kind of like having a giant truck chassis capable of towing tons of payload with a lawnmower engine.
Let's also not forget the small memory budget on these things. If you're going to have a "large-ish" network, in addition to more computational power, you probably need more storage capacity as well.
I think Mikrotik would do well to create a "datacenter" line of switches for this kind of task. Instead of a CRS-326 with a 650Mhz MIPS, a DCX-326 with the same switch-chip and quad core ARM or x86 clocked at 1Ghz+ Now you have enough computational horsepower to handle the CPU bound MLAG functions and some headroom for other tasks like SNMP.
Sadly, for the bulk of the CRS line, there's simply insufficient horsepower to to do the job for anything but the simplest of network topologies.
A further criticism is simply the huge array of CPU devices Mikrotik has in the product portfolio. While there are some cool processors out there, from a development perspective, supporting a dozen different CPU architectures and trying to test/certify all functions across all architectures moving forward is just problematic. At the very least its complicated, and for a smaller company, that's resources and effort that's not propelling the company forward, but rather creating "churn" inside the business.
All of this is of course my outside and (honestly) ignorant perspective of how they handle things internally, but I think there's no doubt that Mikrotik is struggling with this feature not only from a software perspective (handling actual function and interaction between MLAG and STP configurations, reference the recent 7.2x changelog for examples), but also from the complications of making this work across multiple CPU architectures and capabilities. Advertising that this "works" across the CRS3XX/5xx/8xx range is, in my opinion, very misleading with some real caveats posted about realistic performance levels.
As for me...I'm pulling out Mikrotik where I need MLAG and replacing with switches running Pica8.
Significantly more $$$, and hopefully no more headaches.
i think we would need all the mikrotik money on the MLAG to get fixed and just have it work and patching CVE's, all i ask mikrotik.
Well, that can also be solved by working with MLAG via hardware.
A CRS326, used solely for OSPF as an example, and configured directly on the purely L3 ports using hardware, works perfectly. The same applies to BGP and ISIS. However, this is only true if the limitations are respected. Using MLAG, which operates at the CPU level and, as we know, is very limited, will obviously lead to performance problems.
Similarly, I cannot guarantee at this time that integrating hardware with MLAG is compatible with switches like the CRS326, CRS328, and other models in that series.
I consider it an architectural problem with the CRS series in general.
Hugely capable switch chips, with tiny CPUs.
It's a pretty big mismatch if you want to get usable results outside of a homelab.
Take the same switch chip, give it a capable CPU, and I think some (if not all) of these FDB/STP issues go away.
Thus my suggestion to create a "DCX" series of the same hardware. Use the same switch chip and port configurations, give it a real CPU.
That would be a huge leap forward, and I completely agree. It could be revision 2 with those improvements, like the 326 series having fans. Perhaps a management port would finally be a big change, honestly. @normis
MT can add powerful cpu for sure but not on the current price point for sure on CRS3XX series, I hope one day if they put significant workhorse on these switches, they should consider Q-in-Q double/tripple tag in HW and the elusive MPLS in hardware
It seems that on some of the switches, they're just using whatever ARM/MIPS CPU comes with the Prestera chip, and others, they've added a CPU.
It's not too unlike other, more expensive L3 switches that have junk for CPU's because the ASIC does all the work (coughCisco*cough), although I'm sure lots of that has changed as SDN and VXLANs and other more CPU-intensive security needs shift into the network hardware.
Hello again,
Since upgrading to version 7.24.2, our ARP-related issues appear to be resolved.
However, one problem remains: we do not seem to have full redundancy with MLAG.
We are using CRS520 switches in the core as an MLAG pair, both upstream (towards the router) and downstream (towards the access switches).
We can see that the primary and secondary MLAG member negotiation is working correctly. However, if one switch-A goes offline, for example due to a reboot, the network does not become available again until switch-A is back online. The same with switch-B.
Has anyone experienced similar behavior or found a solution to this issue?