I just wasted several days trying to figure out how to make the dozen (or so) platforms for which we implemented VRRPv3 in netlab work together. This

Sturgeon's Law, VRRPv3 Edition « ipSpace.net blog

submited by

Style Pass

2025-01-24 07:30:04

I just wasted several days trying to figure out how to make the dozen (or so) platforms for which we implemented VRRPv3 in netlab work together. This is the first in a series of blog posts describing the ridiculous stuff we discovered during that journey

When using an Arista EOS VM as the well-known probe, I discovered that it refuses to yield to a preempting attempt from numerous other devices (for example, Cisco IOS or Cisco Nexus OS) for the IPv4 address family1. The same devices preempted EOS for the IPv6 address family.

Having two (or more) VRRP masters on the same segment cannot be good. If nothing else, you might get duplicate MAC address or flapping MAC address messages on adjacent L2 switches, so it was time to figure out what was happening. I used tcpdump to see the VRRP packets and noticed the bad vrrp cksum diagnosis for the VRRP packets sent by Cisco IOS:

At that moment, I decided it was high time for another journey into the RFC land. VRRPv3 is defined in RFC 5798, which is obsoleted by RFC 9568 from April 2024. The latter RFC contains an interesting change from the RFC 5798: