On 15 September 2011 18:12, Brian Seklecki (Mobile) <laval...@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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
