carping about CARP

Nick Hilliard nick at foobar.org
Fri Nov 30 23:39:48 UTC 2012


On 30/11/2012 21:01, Claudio Jeker wrote:
> Still carp packets can coexist with vrrp packets. They use a different
> version numbers. 

And the same mac address pool, which means that if you use the same vhid as
vrrp group number, you will trash both your carp and vrrp virtual IPs.
Carp was coded explicitly knowing that this would happen, because it squats
the VRRP mac address ranges as well as protocol 112.

This isn't documented anywhere on the openbsd web site.  Not in the man
pages, not in the FAQs and not in the pf documentation.  It would be real
nice to think that this was an oversight.

Basic developer best practice involves not deliberately creating
loss-of-service style pitfalls for users to fall into, and the least I
expect from a developer is that if they're going to do write a "different"
protocol which poops all over a similar protocol and takes down peoples'
networks during deployment because it's squatting someone else's registered
space, the least they could do is document the problem clearly.

Regardless of any faux innocent pieties expressed by the openbsd people,
this protocol behaviour is astoundingly obnoxious.

Nick

Also you need to use a different vhid but the same thing
> is true if you have 2 groups of vrrp on the same lan. If you configure
> something like VRRP you should run a quick tcpdump first and check
> if there are not unexpected packets showing up. This is especially
> important for any protocol that does a link local multicast or broadcast.
> This is basic network admin best practice (at least I expect that from a
> network engineer).
> 
>>> we didn't have a choice but to ignore that industry-money-driven committee.
>>
>> Which 'industry-money-driven committee' would that be?
> 
> Did you ever read any of the IETF mailing lists and looked at the email
> addresses of those people pushing the hardest? At least in the ones I'm
> subscribed to the bias is obvious.
> 





More information about the NANOG mailing list