> On 23 May 2020, at 8:44 am, Christopher Zimmermann <chr...@openbsd.org> wrote:
>
> On Sun, Jan 19, 2020 at 01:32:17PM +0000, Stuart Henderson wrote:
>> 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.
>
> I'm afraid you guys haven't yet got the point I'm trying to make.
>
> Current behaviour is that in a dual-stack carp setup failover only happens
> when advertisements on _both_ AFs fail to reach the backup.
> A node in backup state will stay in backup state as long as it receives _any_
> advertisements.
> In my mind this is the only sensible way for a backup node to react.
>
> If a backup node that fails to receive advertisements of only one AF would
> transition to master it would in most cases start a preempt war.
> So why do we even send dual-stack advertisements?
> The only effect those dual-stack ipv6 advertisements currently have is that
> they prevent failover when ipv4 connectivity breaks.
>
> I would propose to choose one "sentinel" AF (in this case ipv4) and failover
> whenever advertisements of this AF fail to reach the backup.
>
> Monitoring multiple AFs is not helpful, because there is no good way in which
> to react to a failure that affects only one AF.
I don't know if this helps, but at work we use separate carp interfaces for v4
and v6. It ends up looking a bit like this:
# cat /etc/hostname.vlan871:
parent aggr0 vnetid 871
inet alias 192.0.2.2/24
inet6 alias 2001:db8:871::2/64
up
# cat /etc/hostname.carp40871
carpdev vlan871 vhid 47
-inet6
-group carp
group ipv4g
inet alias 192.0.2.1/24
up
# cat /etc/hostname.carp60871
carpdev vlan871 vhid 61
-group carp
group ipv6g
inet6 alias 2001:db8:871::1/64
up
This let's us run a pair of firewalls one active for v4 and the other for v6.
We don't do any af-to in PF, so it works pretty well. But yeah, it means v4 and
v6 fail separately.
>
>>> > >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.
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
