We have an MLAG pair of CRS518-16XS-2XQ switches. One of the two units has been crashing repeatedly with kernel failures, while the peer unit (same model, same config) has never crashed.
Symptoms on the affected unit:
After each crash, the log on next boot shows: "router was rebooted without proper shutdown, probably kernel failure" and "kernel failure in previous boot"
An automatic supout.rif ("service malfunction") is generated each time
Six occurrences between 2026-08-05 and 2026-08-08, all on RouterOS 7.23.2, then a further four occurrences on 2026-08-08 after we updated to 7.23.3 on our own initiative
"out of memory condition was detected" also appears in the log around these crashes
CPU/LED finding (partially resolved by 7.23.3): Before updating, /tool profile showed the led task using ~57% CPU continuously on the affected unit. After updating to 7.23.3, this dropped to ~0.5%, so that specific issue appears fixed by the firmware update.
Remaining issue — crashes continue after the fix above: The affected unit still crashes during periods of high traffic (specifically, large backup transfers running across the MLAG-bonded link through this switch). During these periods cpu-load hits 100% (single-core device), with /tool profile showing load concentrated in networking, bridging, kernel and prestera_dx_mac (the switch-chip driver). We also see repeated bridge,warning no buffer space available for fdb notify entries in the log around these periods.
Importantly, we compared this against the peer unit during the same backup transfer: it also reaches 100% cpu-load with a very similar /tool profile breakdown, but does not crash. This suggests 100% cpu-load under this traffic pattern is normal for this switch model, and points instead to a hardware-specific defect in the affected unit.
Support status: We opened a support ticket on Wednesday, August 5th, and have since submitted several follow-up updates as the issue kept recurring (each with a fresh supout.rif attached). We have not received any response from MikroTik support since then.
Has anyone seen similar kernel failures on a CRS518-16XS-2XQ under high traffic load, or has any insight into what prestera_dx_mac / networking / bridging load at 100% cpu could be doing differently on a unit that crashes versus one that doesn't? Any pointers would be appreciated.
Hi,
Opened at 5th of August ... we have 10th ... that the pace of Support usually is not counted in days rather in weeks per ticket
I suggest fresh clean netinstall of the device + configuration with CLI applied line by line from the current configuration . No binary backup/restore.
We've been having the exact same issue: two CRS518-16XS-2XQ switches in an MLAG pair, running firmware and RouterOS 7.23.2.
I created a ticket yesterday with MikroTik support, attached the autosupout.rif, and referenced this forum post.
Our primary peer crashes due to a kernel failure during increased network load. These units are brand new. We also have an older pair running RouterOS 7.15.2, which has been stable for two years without a single issue. We tried 7.15.2 on the new units, but ran into strange MLAG-related issues and broadcast storms. Because of that, we decided to upgrade to the latest firmware a few weeks ago, but haven't updated since.
I agree that this seems to be a hardware-related issue involving the CPU. Since hardware offloading is active on all MLAG member ports, I would expect virtually all traffic to pass through the switch chip without putting significant load on the CPU. While that holds true most of the time, the management CPU randomly spikes to 100%, causing a crash and reboot. In our case, this leads to a full network outage—defeating the entire purpose of an MLAG setup. During a graceful reboot, there is only minimal interruption while the peer takes over. During a crash, however, the behavior is completely different.
Beyond these crashes, we occasionally see strange behavior when rebooting or shutting down a server: when a port briefly toggles down and up, it triggers a short interruption across the entire network. Unfortunately, we haven't found any log entries that explain this.
We've double- and triple-checked our entire configuration and found no misconfigurations. I hope a fix is released soon, as this setup is scheduled for production next month. Fortunately, it is still in our testing environment for now.
Thanks for confirming this — good (well, unfortunately) to know we're not alone with this.
Small update from our side: we had a spare unit available, so we swapped it in for the switch that kept crashing, just to get production stable again while this gets sorted out.
Following @BartoszP's suggestion further up this thread, we also did a fresh netinstall on that spare unit and reapplied the configuration via CLI rather than a binary restore.
Separately, we ran into live-migration errors for some of our VMs and ended up updating to 7.24 to address that (unrelated to the crash issue itself). While we were at it, we also netinstalled 7.24 onto the original, crash-prone unit and have been running it isolated on the bench with synthetic traffic-generator load (sustained 100% CPU for close to a day, including overnight) to try to reproduce the kernel failure — so far without success.
That actually lines up with what you're describing: since hardware offloading normally keeps most traffic off the management CPU, a synthetic single-flow load test apparently isn't enough to trigger it. It seems to need something more specific to real MLAG/production traffic conditions, not just raw CPU load.
Support status: our ticket has meanwhile grown to around ten further occurrences, each with a fresh supout.rif attached — still no response from MikroTik support so far
