--On 18 January 2012 19:27:46 +0100 fredrik danerklint <fredan-bird@fredan.se> wrote:

What I want to achieve is to only announce a carp interface if it is in the master state. Otherwise ignore it. Hopefully someone else is in the master state and do the announcement in that case.

We do this by rewriting the bird configuration file from the ucarp up/down scripts, and reloading, which is pretty efficient. Often you want to announce the slave interface with a lower priority (rather than not announce it at all), as if the master route disappears you want traffic to immediately switch over, not wait for a slave announcement. -- Alex Bligh

On Wed, Jan 18, 2012 at 07:27:46PM +0100, fredrik danerklint wrote:

Hi.

I've made an patch that I would like to know if this is how it should be done.

What I want to achieve is to only announce a carp interface if it is in the master state. Otherwise ignore it. Hopefully someone else is in the master state and do the announcement in that case.

I think that probably the better way would be to handle it in a similar manner as a link state. I.e. add some IF_* flags to interface (like IF_CARP_ACTIVE and IF_CARP_MASTER) and leave decision whether to use it to protocols. Some 'check carp' option to OSPF iface (like there is 'check link'). If i understand it correctly, CARP is implemented in a way that create a new virtual iface, which depends on some real iface, which may or may not have an IP address, while VRRP implementations on Linux just add or remove shared IP address on already existing iface. Is that true? So these VRRP interfaces probably would not need anything like this. The CARP iface, even in backup state, is reported as UP and retains shared IP. How much usable is that iface and IP in backup state? I guess that iface does not respond to ARP requests (to allow master to respond), so probably any locally originated communication through that iface would not really work. But i guess it is possible to forward traffic to that iface? Or it is possible/correct to accept communicaton to that shared IP received through other ifaces? It is possible (or expected) to use underlying 'real' iface (if it has assigned a different IP from that prefix) for communication regardles of the state of the CARP iface? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."