Date: Thu, 15 Sep 2011 22:14:34 +0200 From: Damien Fleuriot <ml@my.gd> To: "Brian Seklecki (Mobile)" <lavalamp@probikesllc.com> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: CARP interfaces and mastership issue Message-ID: <CAE63ME4tLpSzfC1ENwaPs1iB-r1yHRs2Zj138iyM%2BW3s6vWyCA@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1109151208210.45497@vger.digitalfreaks.org> References: <4E71C059.5060404@hi-media.com> <4E7218A4.4000205@my.gd> <alpine.BSF.2.00.1109151208210.45497@vger.digitalfreaks.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 September 2011 18:12, Brian Seklecki (Mobile) <lavalamp@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE63ME4tLpSzfC1ENwaPs1iB-r1yHRs2Zj138iyM%2BW3s6vWyCA>