On 2020/01/19 00:11, Sebastian Benoit wrote: > chr...@openbsd.org(chr...@openbsd.org) on 2020.01.18 06:18:21 +0100: > > On Wed, Jan 15, 2020 at 12:47:28PM +0100, Sebastian Benoit wrote: > > >Christopher Zimmermann(chr...@openbsd.org) on 2020.01.15 11:55:43 +0100: > > >>Hi, > > >> > > >>as far as I can see a dual stack carp interface does not care whether it > > >>receives advertisements addressed to IPv4 or IPv6. Any one will do. > > >>So I propose to send IPv6 advertisements only when IPv4 is not possible. > > >> > > >>Why? > > >> > > >>- Noise can be reduced by using unicast advertisements. > > >> This is only possible for IPv4 by ``ifconfig carppeer``. > > >> I don't like flooding the whole network with carp advertisements when > > >> I may also unicast them. > > > > > >Maybe i'm getting confused, but in the problem description you were talking > > >about v6 vs v4, and here you argue about unicast (vs multicast?) being > > >better. Thats orthogonal, isnt it? > > > > Yes, kind of. The point is we support ``carppeer`` for IPv4, but not for > > IPv6. > > > > >>- breaking IPv6 connectivity (for example by running iked without -6) > > >> will start a preempt-war, because failing ip6_output will cause the > > >> demote counter to be increased. That's what hit me. > > > > > >But the whole point of carp is to notice broken connectivity. If you run v6 > > >on an interface, you want to know if its working, no? > > > > I grant you that much. But what kind of failures do you hope to detect > > on the _sending_ carp master, that would not also affect the backup? > > sure: misconfigured pf. Missing routes. Buggy switch.
misconfigured mac address filter on switch. > > >At the very least, this needs some more thought and testing in all the ways > > >carp can be configured. > > > > Anyway, my main concern indeed is the broadcast noise generated by carp > > and I would be equally happy if we had a ``carppeer6`` option. Would > > that be considered? > > of course carppeer should work with v6, and as claudio says without an extra > keyword in ifconfig, but thats a trivial detail. > Currently carp only handles one address per af, setting carppeer twice changes the current peer address rather than adding another. A trivial implementation that sets the v4 peer address if a v4 address is passed in, and sets the v6 peer address if a v6 address is passed in, that would mean things work differently with ifconfig carp1 carppeer $foo ifconfig carp1 carppeer $bar depending on whether foo/bar are v4 or v6. Also removing a configured carppeer address to reset to multicast is just done with -carppeer with no way to indicate the af. It would work pretty nicely if you could set multiple carppeer addresses (of whatever af) and remove them individually. That's a more complex change (carp would need to keep a list of peers per af rather than a single address) but without something like that they can't really be equals and it feels like shoehorning both afs into the same keyword will just be confusing.
