removing carp(4)

[David Young]

***
*** Sorry, I sent too soon. This time with a more appropriate subject.
***

Is it ok to remove carp(4)? I ask because it seems like a peculiar
function for the kernel to provide, it may already be bitrotten, and the
implementation will be difficult to maintain for the future.

The automated tests have recently detected a regression in carp(4),
possibly my fault, so I have been trying to figure out what this
creature is and how it works.

I learned from the carp(4) manual page that it is not a fish. I found a
more helpful description of carp(4) in an old email of Liam J. Foy's,
and now I think that I understand what it is trying to do.

I have reproduced the ATF test-case failure, and I have had a look at
the code, and experimented with it on a dev box of mine. No kernel
but i386/ALL actually contains carp(4), and carp(4) is not built as a
module, so I had to add it to my GENERIC-derived kernel configuration
in order to begin experimenting. The ATF test runs in the RUMP
environment, not the test-host environment.

During my experiments, I ran across a bug where 'ifconfig carp0 destroy'
causes a panic in callout_destroy(). That is not the same bug that ATF
trips over. I have a hunch that it has been there for a long time, but
I don't see a PR for it. That makes me wonder whether anyone is using
carp(4) on -current? Is anyone using it at all?

The code for carp(4) seems to have grown roots deep into the kernel. I
see code that fiddles with ifnet internals and with routes, and I see
that carp(4) has its own protocol-switch entry.
I anticipate it causing trouble for developers who would try to keep it
up-to-date with changing/disappearing kernel APIs (such as they are) and
a more modular, more SMP-friendly network stack.

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.

Dave

[Hubert Feyrer]

I haven't played with pkgsrc/net/ucarp on NetBSD...

After updating it, I can confirm that it does work.
The only thing that didn't work out of the box was forcing one machine as
the master with --preempt.


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Hubert Feyrer

I haven't played with pkgsrc/net/ucarp on NetBSD...

After updating it, I can confirm that it does work.
The only thing that didn't work out of the box was forcing one
machine as the master with --preempt.

Thanks.

I have found another bug in carp(4): it calls the subordinate
interface's output method, sc_carpdev->if_output, on its own ifnet. I
wouldn't expect for that to work reliably if the subordinate was an
ethernet, but breaks *very* badly if the subordinate is a gre(4).

Dave

[Hubert Feyrer]

Post by David Young
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.

There's ucarp (www.ucarp.org) as a userspace CARP implementation.
I've only used it on Linux, and it worked OK for the job.
Providing more than one virtual IP was a bit of a hassle, but it worked
out.

I haven't played with pkgsrc/net/ucarp on NetBSD...


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Hubert Feyrer

I haven't played with pkgsrc/net/ucarp on NetBSD...

After updating it, I can confirm that it does work.
The only thing that didn't work out of the box was forcing one
machine as the master with --preempt.

Do people think that it works well enough to replace carp(4)?

Dave

[Alexander Nasonov]

Post by David Young
Do people think that it works well enough to replace carp(4)?

By how much a packet can be delayed without causing a failover? Is it
1/256 of a second? Can the kernel guarantee that a process can process
a packet within that limit regardless of how busy the box is?

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by David Young

Post by Hubert Feyrer

I haven't played with pkgsrc/net/ucarp on NetBSD...

After updating it, I can confirm that it does work.
The only thing that didn't work out of the box was forcing one
machine as the master with --preempt.

Do people think that it works well enough to replace carp(4)?

I'd encourage you to try it out and report back.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by David Young

Post by Hubert Feyrer

I haven't played with pkgsrc/net/ucarp on NetBSD...

After updating it, I can confirm that it does work.
The only thing that didn't work out of the box was forcing one
machine as the master with --preempt.

Do people think that it works well enough to replace carp(4)?

I will miss the interface abstraction, and the pfsync integration:

http://www.openbsd.org/faq/pf/carp.html

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by David Young
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.

[Darren Reed]

Post by Daniel Carosone

Post by David Young
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.

The Solaris implementation of VRRP does have a user space daemon that
handles
the configuration. This is detailed in the design document for the
project at:

http://hub.opensolaris.org/bin/view/Project+vrrp/

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de