I am reaching out to report a critical Layer 2 traffic isolation bug introduced in firmware version 5.12.0 regarding the handling of VLAN tagged frames over the SFP+ port on the Force 4600c.
Network Topology & Setup:
Routers: MikroTik CCR2116 (RouterOS v7.23.1) connected via SFP+ (Fiber) to the Master radio ↔ Slave radio connected via SFP+ to a remote MikroTik RB750.
Traffic Types: Mixed network running both Untagged PPPoE sessions (for clients) and Tagged 802.1Q VLANs (for node inter-routing).
The Issue:
After upgrading to v5.12.0 (to fix packet loss issues from v5.11.1), our inter-VLAN IP traffic became strictly unidirectional (one-way ping).
PPPoE traffic works perfectly in both directions.
Direct IP ping (ICMP) from the CCR2116 over any VLAN Tagged interface fails to reach the remote router. The remote router can ping back, but the CCR2116 never receives the return packets.
Disabling Hardware Acceleration or Hairpin Acceleration does not resolve the issue. Spanning Tree (STP) is completely Disabled.
The Workaround Found:
We discovered that assigning a native, untagged /30 IP subnet directly to the physical SFP+ interface on both MikroTik routers instantly “wakes up” the SFP+ driver on the Force 4600c. As soon as native untagged IP traffic flows through the interface, the ARP cache populates correctly, and the Tagged VLAN traffic magically starts working bidirectionally again.
Conclusion:
There is a bug in the SFP+ driver or hardware switch chip in v5.12.0 that drops or miscalculates hashes for Layer 2 Broadcast/ARP packets inside Tagged VLANs unless constant, native untagged IP traffic forces the SFP+ port to keep its MAC/VLAN table active.
Please forward this to the engineering team to be patched in the next firmware release.
I’ve briefly checked in my lab and vlan tagged traffic passes through SFP port without any issues.
It can be something environment specific. Let’s investigate!
Looking at this from the MikroTik perspective, would you be willing to share your configs? Obviously you can strip public IPs/Sensitive information, but I am curious if this could be a difference in the configuration between the MikroTik and the new ePMP firmware. I would like to compare your setup to similar router setups we have in the field since we are prepping to deploy 45/4600s attached to MikroTik routers/switches.
Also, are you using service tagging or customer tagging in the Tik? I believe it is service tagging by default. Do you or did you have L3 Hardware Offload enabled on the router? Bridge set to use IP firewall for bridge/vlans?
Thank you for the follow-up. I have gathered precise L2 laboratory data that confirms this is a regressions bug introduced in v5.12.0 (everything worked perfectly on v5.11.1 without any configuration changes on our MikroTik routers).
Here are the smoking-gun test results:
Static ARP Test (Success): If I manually add static ARP entries for the VLAN interfaces on both the CCR2116 and CCR1009, the ICMP ping remains 100% stable and never drops. This proves that the v5.12.0 SFP+ switch chip driver handles Unicast VLAN tagged traffic correctly, but completely drops or fails to forward Layer 2 Broadcast packets (ARP Requests) inside the 802.1Q tagged frames.
The Route Trigger: On the CCR1009, as soon as we disable the routing path, it triggers an ARP table flush/refresh. Because the Cambium SFP+ port drops the subsequent L2 ARP Requests, the CCR2116 instantly loses the MAC mapping, causing the ping to die immediately on the CCR2116 side while the CCR1009 remains active.
Environment: No MTU modifications or topology changes were made. The issue appeared strictly after upgrading the Force 4600c radios to v5.12.0.
Attached are the requested techsupport files from both the Master and Slave radios captured while the issue is active. Please forward these findings to the engineering team, as the bug strictly resides in the L2 MAC-learning / Broadcast forwarding mechanism of the SFP+ interface under mixed traffic (Untagged PPPoE + Tagged VLANs) in this firmware release.
