I have one network that various 2216 and 2116s, will start port flapping off the switch chip. Any ports connected to the CPU are fine, the router is RUNNING, but any ports connected to the switch chip start flapping, up/down. This happening since 7.15ish to current 7.18.2. Note we have tried to go back to 7.15.3 and it still occurs. So don’t really know when it started.
The routers are locked down to only a few IPs, no services are available, synflooding protection is enabled. We did install a new 2116, and moved the hotspot/queues from the 2216, since then the 2116 has had this issue but NOT the 2216. So its looking like its something to do with hotspot/queuing etc.. These units are at 4 different locations, they use both 100G and 10G fiber and DAC Cables to OLTs in most cases. If its local to the site, normally a DAC cable is used.
We did open a ticket with MikroTik and they have been responsive, but so far they are unable to reproduce the issue.
ccr2116 and 2216 does not have any external interface connected to the CPU (except 1 ethernet management port)
all interfaces depend of switch chip
with this clarified
if you use some copper connections i would point out to and electrical problem (induction, potential difference, lack of isolation), if you only exclusively use fiber, check power quality and stability
just in case, be aware, some sfp dac cables are copper
Correct, the ether1 management does not flap, we can access it locally and RouterOS is running just fine, just all of the switch ports are flapping..
here is a clippt from the log
Mar/14/2025 06:47:19 route,info L3HW Offloading OFF
Mar/14/2025 06:47:39 interface,info qsfp28-2-1--100g link up
Mar/14/2025 06:47:39 interface,info qsfp28-2-1--100g link down
Mar/14/2025 06:47:39 interface,info sfp28-1-to--10g link down
Mar/14/2025 06:47:40 interface,info sfp28-2-to--10g link down
Mar/14/2025 06:47:40 interface,info sfp28-11-olt2-data link down
Mar/14/2025 06:47:41 interface,info sfp28-12-olt1-data link down
Mar/14/2025 06:47:42 interface,info sfp28-11-olt2-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:42 interface,info sfp28-12-olt1-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:42 interface,info sfp28-1-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:42 interface,info sfp28-2-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:42 interface,info qsfp28-2-1--100g link up
Mar/14/2025 06:47:43 interface,info qsfp28-2-1--100g link down
Mar/14/2025 06:47:43 interface,info sfp28-1-to--10g link down
Mar/14/2025 06:47:43 interface,info sfp28-2-to--10g link down
Mar/14/2025 06:47:43 interface,info sfp28-11-olt2-data link down
Mar/14/2025 06:47:44 interface,info sfp28-12-olt1-data link down
Mar/14/2025 06:47:45 interface,info sfp28-11-olt2-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:45 interface,info sfp28-12-olt1-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:45 interface,info sfp28-1-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:45 interface,info sfp28-2-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:45 interface,info qsfp28-2-1--100g link up (speed 100G, full duplex)
Mar/14/2025 06:47:46 route,info L3HW Offloading ON
Mar/14/2025 06:47:53 route,info L3HW Offloading OFF
Mar/14/2025 06:47:54 interface,info qsfp28-2-1--100g link down
Mar/14/2025 06:47:54 interface,info sfp28-1-to--10g link down
Mar/14/2025 06:47:55 interface,info sfp28-2-to--10g link down
Mar/14/2025 06:47:55 interface,info sfp28-11-olt2-data link down
Mar/14/2025 06:47:56 interface,info sfp28-12-olt1-data link down
Mar/14/2025 06:47:57 interface,info sfp28-11-olt2-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:57 interface,info sfp28-12-olt1-data link up (speed 10G, full duplex)
Mar/14/2025 06:47:57 interface,info sfp28-1-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:57 interface,info sfp28-2-to--10g link up (speed 10G, full duplex)
Mar/14/2025 06:47:58 route,info L3HW Offloading ON
And that will continue, till the router is rebooted. Note that there is a 100gigE link in there as well… All of these are fiber connections. the OLTs are local, and several of them are dark fiber.
what makes me wonder is having the same issue with multiple devices at the same site, because of that i point towards an environment issue
just in case, be aware, some sfp dac cables are copper if you have some kind of grounding or isolation problem between devices one dac can be an electrical bonding between devices, some time ago i saw a dac catch fire because a grounding problem
Hey, having these issues with 2116 since its realease.
port flapping → HW replacement and new box dies within a month.
have other 2x 2116s in DC running on 7.5 with 2 years uptime. One box had one of the LACP ports flapping for a month and uptime timer reset after 1 year uptime but all good otherwise.
out of 20x CCR2116 I have seen more deaths then with 1000x CCR 1009.
We are moving to CHR heavily.
We have had discussions with MikroTik, does these have queues on them? The latest is they found the issue and the next beta version should have it in there.
Well 7.19b6 should fix it, well at least according to MikroTIk. We will see. I moved the hotspot from a 2216 to the 2116 and now the 2216 does not have the issue, but the 2116 does. Just a FYI.
Yes - I've been seeing this issue occuring on some CCR2116 and a CCR2216 since moving up to 7.21.5 - support suggested moving Routerboot firmware up, which didn't fix this, and then we moved the routers up to 7.23.2 and same routerboot version.
Each time the issue appears in the same fashion - all SFP interfaces on the affected device start flapping up and down repeatedly until the box is physically rebooted - device is still accessible via ethernet and can take a supout/reboot from there; hope this helps you while we waiti for MikroTik to sort the underlying issue.
Since upgrading to 7.21.4 and now 7.23.5, we are also having alot of issues with Port Flapping on CCR2116 routers.
No issues on 7.14.2 and 7.19.6.
Router lasts anywhere between 3-5 days then suddenly all ports except MGMT start flapping continuously and the only way to recover is a physical power cycle.
The Ethernet port should not be affected. I would recommend attempting out-of-band management if possible. Screenshots, videos, and console-cable access/output would all be very helpful for MikroTik support and troubleshooting.
I have not experienced this issue again on our CCR2216s or CCR2116s, but you never know.
We see a similar symptom on CCR2116-12G-4S+ (RouterOS 7.23.5, long-term). We do not know if it is the same fault. Has anyone tested 7.24.1 or later?
What we measured (supouts of units that were failing; all CCR2116-12G-4S+ on 7.23.5, all the primary unit of an HA/VRRP pair)
The kernel log repeats this sequence (timestamps removed). On average there is one reset every 14 s, 18 s and 26 s on the three units, with single gaps from 11 to 47 s:
switch0: mac:1 seems like rx hangup for 5s (not on every reset)
switch0: mac:1 initiates tx timeout
switch0: tx timeout @... (two tx timeout lines per reset)
switch0: restart_task
pdx: serdes disable ... and serdes init lines on the lanes
On one unit, a supout taken while the loop was still running shows 15 switch resets in 3.5 minutes (14 in the kernel log, the 15th in the live trace). The RouterOS log in the same file shows the SFP+ WAN port going down and up about every 13 seconds. Each of the 14 resets in the kernel log has a WAN link-down within 2 seconds; by chance we would expect about 3 of 14. The HA port flapped too. We do not know which comes first, the reset or the link-down: the log has 1 second resolution.
Two other units show the same sequence on a different switch port index (mac:2 and mac:3). The three units had been up between 2 and 12 days.
We compared hotspot, queue and queue-type settings, by name, between the three failing units and seven units without the loop in their supouts (three of the seven had been up only hours; one was a standby with the hotspot off). We found nothing in the configuration that separates them.
What we do not know: what triggers it, and exactly when it starts (the kernel log keeps only the last few minutes).
Why I am asking about 7.24.1. MikroTik's changelog for 7.24.1 (2026-Aug-21; the 7.24 series is now the stable channel) lists: "switch - fix possible Rx traffic stall on CPU for devices with Marvell Prestera switch chip". Our log line says rx hangup on a switch port that faces the CPU, so this could be related. That is a guess. Some other lines I found in the changelogs:
7.21.5 and 7.23.1: "switch - fixed rare possibility of tx-timeout or simultaneous flap of all switch ports on devices with Alpine CPUs". Our units run 7.23.5, so they already include this, and they still show the loop. (MikroTik's product page lists an Annapurna Labs Alpine CPU, AL73400, for the CCR2116.)
The long-term releases 7.23.4 to 7.23.8 do not list the 7.24.1 line.
Post 15 above reports flapping on 7.24.2, so 7.24.1 may not cure every case, or that report may have another cause.
Could you help?
If you run CCR2116 or CCR2216 on 7.24.1 or later: did the flapping stop, continue, or never happen? How long has the unit been up?
Do you see switch0 ... rx hangup, tx timeout or restart_task lines in a supout (kernel or debug log) from a failing unit? On which version?
Have you found anything that separates units that fail from units that do not (bridge hardware offload, hotspot, queues, transceivers or DAC, HA/VRRP, uptime)?