I have pair of MX250's (single interface, warm spare configuration) as an SD-WAN hub site. We see the warm unit sending its management traffic (e.g traffic to dashboard) with the VRRP source MAC rather than its own burnt in MAC. I have had a TAC case open for a few weeks now which is with engineering again as an upgrade to 15.44 did not resolve.
I am interested to see if anyone else has experienced this VRRP bug?
We haven’t experienced this directly but a peer had this happen across a large sd-wan estate. From memory support made a vpn registry change?
Hi ,
I was curious about that behavior so I did a couple packet captures on both our MX450 and MX250 Warm Space ( LAN captures )
MX450 MX 15.40 :
Uses the burned-in MAC for the VRRP MAC ( not following the standard in RFC 5798 )
MX250 MX 14.53 :
Uses a special MAC CC:03:D9 + End of the burned-in MAC of the device ( not following the standard in RFC5798 )
I'm a little bit surprised to see that both MX450 and MX250 are not following the RFC AND they are not even using the same mecanic for the VRRP MAC selection....
Woops ! I just edited my post to include the firmware versions. I will have to test in my lab if bringing the MX250 to the MX450 version will change the behavior ( which is still not the one expected from the RFC )
I was expecting a MAC 00-00-5E-00-01-XX
Hi,
Yes, we've just downgraded all our MX 450 today from version 15.44 to 15.42. The support said that it impact only the management traffic but for us even the site-to-site tunnels were affected: it took hours to bring up a tunnel without any specific reason. As soon as we downgrade to version 15.42, all our site-to-site tunnels which were down went up.
Maybe some coincidence I dont' know 🙂
Where you able to confirm if the VRRP MAC between your MX450 and MX250 followed the same mechanic ?
Sorry to bring an old thread back to life , have you tried 15.44.1 which might solve this issue ?
Upgrading to MX 16.16 resolved the issue