I want to configure VLANs+MLAG+VRRP but it doesn’t work correctly. When a physical network change occurs at the router level, the MLAG works correctly. But if I make a physical change in the bonding with the idea that traffic starts at CRS-4, go to CRS-2, continue to CRS-1 and arrive at RTR-1. It does not work.
But when I deactivate the MLAG all the configuration works correctly.
Also, if I deactivate the VRRP of one of the routers to force the change, the VRRP makes the change, but the traffic does not go to the other router that activated the floating IP.
I think that the failure is that the host tables in the Bridges are not updated until there is a physical change in the network of those directly responsible for the VRRP. For example :
*Floating IP of VRRP VL101 = 00:00:5E:00:01:70
At this moment the traffic goes from CRS4 to CRS-1 and arrives at RTR-1 (floating IP is in router 1) and everything is fine. But if I force the floating IP to now be active on RTR-2 but continue to pass CRS-4 - CRS-1 - (MLAG) - CRS-2 and reach RTR-2, the traffic no longer passes.
CRS-1
The floating IP is now on RTR-2 but the CRS-1 keeps registering that the floating IP is on RTR-1. I think that’s why the np traffic goes to the RTR-2.
CRS-2
Does anyone have an opinion on how to fix this?
In order for the traffic to pass from CRS-4 —> CRS-1 —> CRS-2—RTR-2, the host table in the CRS-1 bridge must be updated and remain in this way.
But this update takes time to perform between the CRS bridges that are configured in MLAG.
One of the fundamental operational elements for most other network vendors when running MLAG + VRRP is to set the RSTP root to the same switch as the VRRP Master (or in this case - the path to it) and the other switch as a secondary root.
Curious if you’ve tried this and if it made a difference?
Typically, most vendors synchronize the RSTP bridge ID between the 2 MLAG peers so they are BOTH the RSTP root. This would be the realistic case because they are functioning as if they are the same switch from a forwarding POV. Most vendors make VRRP work in active-active mode for MLAG so they both accept traffic destined to the virtual MAC. Again, this makes the most sense because they are operating as if they are the same switch from a forwarding POV.
