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
Far be it from me to get involved in a private pissing match, but...
Owen wrote:
Perhaps we should ask IETF/IANA to allocate a group of protocol numbers
to "the wild west". A protocol-number equivalent of RFC-1918 or private ASNs.
You can use these for whatever you want, but so can anyone else and if you
do, you do so at your own risk.
This won't entirely solve the problem, but at least it would provide some
level of shield for protocol numbers that are registered to particular
purposes through the IETF/IANA process.
Would that be 253 and 254 "Use for experimentation and testing" per RFC 3692?
Of course, no-one like to see their pet protocol designated as an experiment
(unless they really believe it is something that should be carefully researched
and tried out in a controlled environment), but the garden-walling that you
describe seems to fit exactly within the 3692 definitions.
"Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.
When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly."
Of course the use of 'must' or 'must not' in an RFC never stopped anyone from doing the exact opposite.