On 2012 May 02 (Wed) at 12:09:52 +0300 (+0300), Kapetanakis Giannis wrote:
:On 27/04/12 12:58, Kapetanakis Giannis wrote:
:>
:>>Hi,
:>>
:>>After upgrading today to latest -current (i386)
:>>(f1) OpenBSD 5.1-current (GENERIC.MP) #252: Tue Apr 24 15:58:54 MDT 2012
:>>(f2) OpenBSD 5.1-current (GENERIC) #209: Tue Apr 24 15:50:09 MDT 2012
:>>
:>>I still have the same problem.
:>>When the primary firewall reboots, It becomes MASTER on the carp
:>>interfaces
:>>before the pfsync bulk transfer ends:
:>>
:>
:>
:
:This might be related. I've seen it on the 5.1 announcement:
:
: o Many pfsync(4) fixes and improvements including jumbo frames and
: automatically requesting a bulk update after a physical interface
: comes online.
:
:
:When the secondary firewall is MASTER and sees link-up on the
:dedicated network interface to the primary firewall (which is
:booting) it issues pfsync bulk transfer start thus a carpdemote on
:carp and pfsync groups.
:
:So when the primary firewall comes online it takes over before even
:his bulk transfer ends.
:
No, that is not what that feature does.
When pfsync starts any sort of bulk update, it will increase the carp
demotion counter which makes it refuse MASTER. Only when the bulk
update finishes (or times out), will it decrease the carp demote
counter, which will allow it to take MASTER, subject to the normal rules.
:Giannis
:
--
Never offend people with style when you can offend them with substance.
-- Sam Brown, "The Washington Post", January 26, 1977
