CARP interfaces and mastership issue

[Damien Fleuriot]

On 15 September 2011 18:12, Brian Seklecki (Mobile)
<lavalamp at probikesllc.com> wrote:
>> Things went smoothly but when we brought the production VLANs up again
>> at layer 2 on the switches, when spanning-tree converged we had again a
>> double MASTER problem.
>>
>
>
> In older versions of FBSD, creating logical interfaces like vlan(4) and
> carp(4) had an nasty inadvertent side effect of toggling the state of the
> underlying phyiscal interface.
>

We're running quite the recent version really:
FreeBSD 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu Sep  1 15:51:49 CEST
2011     root at pf2-dmz:/usr/obj/usr/src/sys/FW  amd64


> This may be fixed in newer version.
>
> This would then then cause STP to reset on the switchport which can take up
> to 50 seconds to restore.
>

Switchports are running portfast trunk with RPVST, this was a good
candidate but sadly not the cause here.
Also, physical interfaces do not get reset, dmesg is clean.

> In the mean time, the backup host hasn't heard from the master and assume
> the role of master.
>
> You can try turning on switchport spanning-tree portfast on your backup
> system which should cut down this time signifantly.
>
> If you can assure that no STP BPDUs will be announced from your CARP system,
> then its probably safe to run PortFast on a trunk.
>

This is already done on all non-uplink ports, with portfast trunk as
appropriate for servers that tag VLANs.

> The same is true after a reboot.
>
> Maybe hack the RC script to force the CARP interfaces on your backup to stay
> down at boot time for an extra 10/15 seconds
>

Even then, once we bring the interface up (or create it), it seems to
immediately assume mastership, breaking existing sessions on the main
firewall, THEN it says it's received a more frequent advertisement and
swaps to backup.

What would help here, is for a carp interface to wait a given delay
(tunable through a sysctl ?) after creation or after being brought up
from down.

This would allow the server to receive VRRP advertisements and
immediately assume a BACKUP carp role upon boot or interface
creation/up.

This would also retain CARP's high reactivity to network failures and
outages since this would only apply to a newly created/up'ed
interface, not an already running one.