On Tue, Nov 01, 2011 at 07:31:10PM -0500, David Young wrote: > Considering the function of carp(4), I wonder why it is a kernel > function instead of a user daemon? It seems that you could accomplish > the same thing with a daemon that runs the CARP protocol and > adds/removes a backup interface from a bridge(4) as it is necessary. > > In sum, I doubt that carp(4) provides enough utility to justify its > maintenance cost. If there are arguments to the contrary, I am > listening. FWIW, the solaris equivalent (which is VRRP rather than CARP, for whatever difference that really makes) does involve a kernel element. I'm not certain if it is entirely in the kernel or if there's a userspace element for protocol exchange, but the key point of having a kernel device and interface is that you can attach config and processes to a proper interface. This behaves like an interface is expected to for all other purposes, such as link state monitoring, routing daemons, bpf, ipfilter, passing through to VM platforms (xen), etc etc. Adding and removing an etherstub (tun/tap) to a bridge might not preserve the desired semantics in a predictable fashion for these corner cases. A you've already observed, it may work for ethernet but not so well on other link types. It might not converge fast enough if there's some dynamic bridge protocol (STP, TRILL) in use, either. So, I think there's a case for at least some of it to remain in kernel. -- Dan.
Attachment:
pgpqjkf_URWTO.pgp
Description: PGP signature