MLAG + VRRP failback issue: VRRP master does not process VIP traffic after recovery (RB4011, ROS 7.22.1)

RouterOS
1

Hello,

I am testing MLAG + VRRP setup using RouterOS 7.22.1 and I believe I have encountered a problem during failback scenario.

Topology

  • 2 × RB4011 (MLAG peers)

  • 1 × CRS326 (LACP client / ToR switch)

  • Host connected to CRS326

Connections:

  • CRS326 → RB4011-A (ether4)

  • CRS326 → RB4011-B (ether4)

  • RB4011-A ↔ RB4011-B via peer-link (ether10)

Configuration summary

  • MLAG configured on both RB4011 (same mlag-id)

  • LACP (802.3ad) between CRS326 and both RB4011

  • VLAN 100 used for L2 domain

  • VRRP configured on VLAN100:

VRRP VIP: 10.100.0.1
R1 priority: 150 (primary)
R2 priority: 100 (backup)
preemption-mode=yes

Expected behavior

  • When R1 fails → R2 becomes VRRP master → traffic continues

  • When R1 returns → R1 becomes VRRP master again → traffic continues

Actual behavior

1. Failover works correctly

  • R1 powered off

  • R2 becomes VRRP master

  • Host connectivity OK (only 1 ping lost)

2. Failback is broken

  • R1 powered back on

  • VRRP switches master back to R1
    BUT:

    • Host cannot ping 10.100.0.1

    • No connectivity through VRRP gateway

Critical observation (packet flow)

On R1 (VRRP master), I captured traffic:

On MLAG uplink:

/tool sniffer quick interface=lag-to-tor ip-protocol=icmp

I see incoming ICMP requests:

SRC: 10.100.0.150 → DST: 10.100.0.1
DST-MAC: 00:00:5E:00:01:64 (VRRP MAC)

On VLAN interface:

/tool sniffer quick interface=vlan100 ip-protocol=icmp

→ No packets at all

On peer-link:

/tool sniffer quick interface=ether10 ip-protocol=icmp

→ SAME ICMP packets are forwarded to peer:

SRC: 10.100.0.150 → DST: 10.100.0.1

Interpretation

  • R1 is VRRP master

  • Traffic to VIP arrives on R1

  • BUT instead of being processed locally, it is forwarded via MLAG peer-link to R2

  • R2 is VRRP backup → does not process VIP → packets are dropped

Additional verification

  • R1 responds correctly on its real IP 10.100.0.2

  • R1 can ping host from real IP

  • BUT cannot ping from VRRP IP:

/ping 10.100.0.150 src-address=10.100.0.1 → FAIL
/ping 10.100.0.150 src-address=10.100.0.2 → OK

Workaround

If I restart VRRP on R1:

/interface vrrp disable vrrp100
/interface vrrp enable vrrp100

→ immediately:

  • VIP becomes reachable

  • traffic starts working normally

Conclusion

It appears that after failback:

  • VRRP master role is correctly assigned

  • but MLAG/bridge forwarding still treats VRRP MAC as external

  • and forwards traffic via peer-link instead of local processing

Restarting VRRP fixes the issue, which suggests a state inconsistency.

Question

Is this:

  • a known limitation of MLAG + VRRP?

  • or a bug in RouterOS 7.22.1?

Can provide full configuration export if needed

2

I ran into an issue with VRRP in RouterOS (tested on 7.22.1 and 7.23beta5) in the following topology:

  • 2x RB4011 (VRRP, L3)

  • 1x CRS326 (L2, LACP)

  • MLAG between routers (peer-link)

  • VLAN filtering enabled

  • VRRP running over VLAN interface

Problem

VRRP state is correct (MASTER/BACKUP), but after failback:

  • VRRP VIP becomes unreachable

  • ICMP packets to VIP reach router but are not processed

  • Traffic is forwarded over MLAG peer-link instead of going to CPU

  • No packets appear on VLAN interface

  • /interface bridge host does not contain VRRP MAC as LOCAL

Key observation

Traffic to VRRP MAC:

DST-MAC: 00:00:5E:00:01:64

  • arrives on uplink

  • gets forwarded to peer-link

  • never reaches VLAN interface / CPU

Workaround

Restarting VRRP interface fixes the issue:

/interface vrrp disable vrrp100
/interface vrrp enable vrrp100

This suggests VRRP MAC is not properly registered in bridge/FDB after boot or failback.

Final workaround (stable)

Delayed VRRP restart on boot:

/system script add name=fix-vrrp-on-boot policy=read,write,test source={
    :delay 20;
    /log warning "VRRP restart workaround triggered";
    /interface vrrp disable [find name="vrrp100"];
    :delay 2;
    /interface vrrp enable [find name="vrrp100"];
}

/system scheduler add name=fix-vrrp-start start-time=startup on-event=fix-vrrp-on-boot

After applying this, VRRP works consistently.

Conclusion

Looks like a bug or race condition in:

  • VRRP MAC registration

  • Bridge host/FDB

  • MLAG synchronization

Triggered during boot or failback.

If anyone has a cleaner fix or confirmation from MikroTik — would appreciate feedback.

3

Confirmed the same behavior with 7.23.1

4

Confirming same behavior with 7.24.4

Attempting to raise a ticket with support....