Support set of virtual IP addresses

[AlexMarlo]

From carp FreeBSD man page:
"CARP allows multiple hosts on the same local network to share a set of IP addresses."
This will be very good to support this feature.

[roeme]

You can already do this by firing up multiple instances (which is what we do).

[AlexMarlo]

This will take more traffic, but as quick solution is good enough

[petiepooo]

The debianized release uses the following vip-up script:

#!/bin/sh
/sbin/ifup $1:ucarp

and a sample /etc/network/interfaces contains the following configuration values:

auto eth0
iface eth0 inet static
    address 10.13.51.2
    netmask 255.255.255.248
    gateway 10.13.5.6
    broadcast 10.13.5.7
    ucarp-vid 23
    ucarp-vip 10.13.5.1
    ucarp-password S3kr!tPw
    ucarp-advskew 5
    ucarp-advbase 2
    ucarp-facility local7
iface eth0:ucarp inet static
    address 10.13.5.1
    netmask 255.255.255.248

There's a script at /etc/network/if-up.d/ucarp that translates all those ucarp-* settings into the call that starts the ucarp process. Of note is that, even though the VIP is required, is passed to ucarp on startup, and is again passed to the vip-up script as parameter $2, it's not used by the vip-up script. Instead, it just brings the ucarp sub-interface up.
If you want to bring multiple VIPs up and down together, there's no reason you couldn't name the subinterfaces ucarp0, ucarp1, etc., and just have the up/down scripts bring all your interfaces up or down at once.
With a setup like this, and also the multiple instances alternative workaround mentioned above, I don't see this as a feature requiring a code change. https://en.wikipedia.org/wiki/KISS_principle, right?

[ghost]

I'm not sure whether the OP had this in mind, but I originally started watching this because ucarp is missing an important feature that pertains to the management of sets of addresses, and that is preemption support. As the carp manpage states, "for most scenarios it is desirable to have a well-defined master, achieved by enabling the preempt option". Without this, it is hard to avoid various failure scenarios in which routing may be outright broken or - at best - asymmetric.

In my case, I had the task of replacing a group of FreeBSD hosts with Linux (nothing wrong with CARP but FreeBSD itself had reliability issues) and ended up approximating preempt in my up and down scripts, with the aid of the USR2 signal. The resulting code is brittle. In particular, preventing race conditions from occurring is tricky. The first instance of ucarp whose down script invokes pkill -x -USR2 ucarp must protect itself upon being re-entered, but only for as long as ucarp has duly spent its 3 seconds as a backup before re-assessing the situation. Dealing with this latter aspect from within the up/down scripts is impossible to do perfectly, because there is no intrinsic mechanism to support the co-ordination with ucarp that would be required.

As it stands, I use flock(1) to assert a lock, only dispatching the USR2 signal if the lock is obtained, in which case it also finishes with sleep 2.9. Ergo, just about long enough. Obviously, the sleep statement is a kludge but it's the best that I can do, given that ucarp supports no way of signalling my code that its post-demotion grace period is up.

As brittle as the approach may be, it has worked well over recent years - with a handful of exceptions. In any case, this may be something to consider for the future. Most people operating sets of addresses would, indeed, want a "well-defined master" to prevail, and approximating preempt with ucarp is awkward, as much as I otherwise enjoy its adherence to the KISS principle.

[petiepooo]

@kerframil, I want to make sure I understand what you're trying to do. You're managing more than one VIP between a set of hosts, and you want all the VIPs to switch between hosts together, and the way you're doing that is to send all ucarp pids a USR1 when any one ucarp process runs its vip-down script. Right?

Additionally, as long as your preferred master is up, it should hold all VIPs. How would preempt play into this, and why would a lower skew setting on your preferred master not do the trick?