Allowing CARP to use arbitrary OUI prefix and allocating block from FreeBSD's OUI space assignment for that

Eygene Ryabinkin rea at
Thu May 8 13:32:33 UTC 2014

Thu, May 08, 2014 at 12:08:28PM +0000, Bjoern A. Zeeb wrote:
> On 08 May 2014, at 09:50 , Eygene Ryabinkin <rea at> wrote:
> > No, we're conflicting with VRRP on the MAC address space.
> > 
> > And, as I understand, CARP in 10 hadn't changed protocol in any way,
> > it just refurbished now CARP instances are configured and attached to
> > the interfaces.  Could be wrong here, though.
> Yes, that is why the problem remains.
> #define CARP_VERSION            2
> vs.
> RFC 3768, Virtual Router Redundancy Protocol (VRRP),  5.3.1.  Version
>    The version field specifies the VRRP protocol version of this packet.
>    This document defines version 2.
> *boom*
> And the world is moving on ...
> RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6, 5.2.1.  Version
>    The version field specifies the VRRP protocol version of this packet.
>    This document defines version 3.

Oh, shit :(

> So, document CARP as Version 4 and then you have your own version of
> the protocol and a good reason to change the EUI-48 assignment
> within the IANA OUI maybe, maybe not.
> 00-01-00 to 00-01-FF	VRRP (Virtual Router Redundancy Protocol)	[RFC5798]
> 00-02-00 to 00-02-FF	VRRP IPv6 (Virtual Router Redundancy Protocol IPv6)	[RFC5798]
> Currently we are on Version 2 and VRRP (3768) is Version 2 and we
> share the OUI but speak a different language.  *boom*

More properly, we're on v2, VRRP 3768 is v2 and we share protocol
number (112).  And our data planes share the same OUI, but that's
has nothing to do with being on version X or Y on any side, that's
a different problem.

> Currently you are worried that “CARP" != “VRRP" and still uses the
> same EUI-64.  But that’s a management problem.  Server guys run
> Solaris and VRRP[1] in the Solaris group, and Linux and VRRP in the
> Linux Group, or FreeBSD and VRRP (yes people do) in the group that
> tries to talk to the other two.  If they don’t talk to each other
> and the networking guys put the servers in the same subnet, they
> probably conflict.  *boom*   Needless to say that if they don’t tell
> the networking guys they conflict with the routers as well
> *boom*boom*
> Two different networking groups do redundancy failover and years
> later connect their routers;  4 routers run VRRP, same VRID by
> default.  *boom*
> The samples you can find are plenty.

Multiple deployments of the same protocol need coordination, but
that's expected.  Multiple deployments of a different protocols might
(and as our case shows, do) need coordination, but that's an
unexpected thing.

Change of used OUI space for CARP will prevent at least the part of
the breakage, the most unexpected part of the whole drama.

> People need to talk.   The fact that your server guys use a
> non-unique Ethernet address for CARP without talking to their local
> authority who’s in charge of the network first is nothing you can
> fix changing the number.   The fact that multiple deployments on the
> same subnet might exist is nothing a number change will fix.   I
> think the RFC uses the word “coordinate”.

People need to talk, yes.  But do BGP heads will announce the
technical details of what they are doing to the Squid cluster guys
(picking protocol and software names arbitrary)?  Not sure.  Hell,
I am sure they won't.

And if we speak about RFCs: we need protocol specifications at all not
only because people should know how they work, but also to avoid
messing (perhaps unintentionally) some technical details of the
protocols making different ones to bring havoc if used together.

That's why VRRP for IPv6 has its own OUI space and that's why CARP
needs its own OUI space: it is a different protocol from VRRP, so we
should minimize clashes at all levels.  IANA/IETF could have said "oh
dear, L2 domain admins must coordinate their IPv4 and IPv6 VRRP
things, so let's reuse 00-00-5E-00-01 space".  But they minimised
confusion where they could and that's a good thing to do.

What you're saying is that "all involved people must be educated
enough to grok all details and share them with others".  What I am
saying is that "when we can eliminate potential for breakage, we
should".  My assertion doesn't contradict with your, but it tries to
make already complicated networking world to be slightly more
error-prone (at least, I hope so and that's my intention here).

> The thing you can change is to fix the version number for CARP,
> document the protocol (so your network guys become more aware of it
> though they probably won’t anyway);  then you can make sure it
> doesn’t conflict on as much as is possible with it---just that you
> cannot always (as described above) without talking.    So it’s about
> minimising the impact, reading your log files, and talking to
> people.

That is also a good thing to do, but it is a longer-term goal, because
putting CARP into RFC is, well, a loooong story.
Eygene Ryabinkin                                        ,,,^..^,,,
[ Life's unfair - but root password helps!           | ]
[ 82FE 06BC D497 C0DE 49EC  4FF0 16AF 9EAE 8152 ECFB | ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 358 bytes
Desc: not available
URL: <>

More information about the freebsd-net mailing list