On Sat, May 23, 2020 at 01:55:54PM +1000, David Gwynne wrote:
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.
Yes that is a sensible and coherent setup where ipv4 and ipv6 are kept
completely separate.
But what I'm proposing to change is the dual stack mode of carp where
there is only one interface. There is no use for advertisements on two
address families, because in case of failure of only one address family
there is no sensible way to respond to that failure.
> >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
