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.