Daniel Hartmeier wrote:
> Yes, it will:
>
> net.inet.carp.preempt Allow virtual hosts to preempt each other.
> It is also used to failover carp interfaces
> as a group. When the option is enabled and
> one of the carp enabled physical interfaces
> goes down, advskew is changed to 240 on all
> carp interfaces. See also the first example.
> Disabled by default.
Whoops, thanks for pointing that out. I will re-do my tests (the setup is
at a remote site), and make sure that I'm done making things up.
I'm not sure where your quote came from; I see similar text in NetBSD docs,
but this is what I (now) find in the OpenBSD FAQ:
net.inet.carp.preempt Allow hosts within a redundancy group
that have a better advbase and advskew
to preempt the master. In addition, this
option also enables failing over a group
of interfaces together in the event that
one interface goes down. If one physical
CARP-enabled interface goes down, CARP
will increase the demotion counter,
carpdemote, by 1 on interface groups that
the carp(4) interface is a member of, in
effect causing all group members to fail-
over together.
http://www.openbsd.org/faq/pf/carp.html
I did establish an interface group for my two CARP interfaces, but I did
not do my failover tests while it was in that state. As I said, I clearly
need to re-do my tests.
> It does not cover the case where the link remains up, but the uplink
> switch stops forwarding, for instance, but...
At least for our case, a switch failure on either side of the firewall/router
represents a total loss of connectivity.
However, this does jog another potential failure mode. Some of our older
OpenBSD firewalls (going back to OpenBSD) will occasionally (maybe once a
year) "lose" a network interface. If you logged in at the console of a
host while it was in this state, the interface would look perfectly normal,
but it would not pass any traffic. I callously worked around this by
administratively cycling each network interface on the affected machine(s)
on a weekly basis.
If we ran into this failure mode with our CARP firewalls, I'm assuming the
master would keep right on thinking it was the master, and not attempt to
demote iteslf.
While it is certainly helpful for self-demotion of a master to occur,
it seems reasonable for self-promotion of a slave to also occur.
> ... see ifstated(8), which can ping uplink hops and issue ifconfig advskew
> changes to demote the master when appropriate.
Thanks, I'll look into that.
--Kyle
