tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: removing carp(4)

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


Attachment: pgpqjkf_URWTO.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index