Thanks for the recommendation, I have now also added aggressive optimization
on the backup firewall.
I just noticed also on the console following warning
messages:
pfsync: failed to receive bulk update
em7: watchdog timeout --
resetting
em7: watchdog timeout -- resetting
em7: watchdog timeout --
resetting
em7: watchdog timeout -- resetting
Does these have anything to do
with this bug or is it maybe another problem?
Regards,
ML
----- Original
Message -----
From: Maxim Bourmistrov <m...@alumni.chalmers.se>
To: ML mail
<mlnos...@yahoo.com>
Cc: "misc@openbsd.org" <misc@openbsd.org>
Sent:
Wednesday, November 9, 2011 11:37 AM
Subject: Re: pfsync states growing on
carp backup firewall
This bug will probably be fixed soon with a back-ported
solution from -current.
Meanwhile you can force all states on the
failover-side to expire quicker.
I had (pf.conf):
set limit { states 50000 }
- rise nr. of states from default 10000 to 50000
set optimization aggressive -
this sets exp. time for states to 5h
set timeout { adaptive.start 12000,
adaptive.end 50000 } - start reducing exp.time if nr. of states reached 12000
and expire(flush) all if we reach 50000.
You did not encounter it yet, but
you probably will soon as I did.
States did not flush then, with default
10000-limit I reached it. So adaptive.start/end did it for me.
P.S.
Downside
of this forced expire is if it flushes and you do failover and the same time
you'll lose all connections - no states.
//maxim
On Nov 9, 2011, at 10:58
AM, ML mail wrote:
> Hi Maxim,
>
> Thanks for your feedback. The firewall
setup is productive already so I don't really want to mess it up with
compiling right now. I'de rather wait for an official patch or upgrade to
OpenBSD 5.1 next May.
>
> So in the meantime and as suggested I have used
adaptive.start/.end to keep the states at a reasonable value on the on the
backup firewall with:
>
> set timeout { adaptive.start 10000, adaptive.end
30000 }
>
> So despite this small issue, is the fail-over with keeping states
still functional?
>
> Regards,
> ML
>
>
>
> ----- Original Message
-----
> From: Maxim Bourmistrov <m...@alumni.chalmers.se>
> To: ML mail
<mlnos...@yahoo.com>
> Cc: "misc@openbsd.org" <misc@openbsd.org>
> Sent:
Wednesday, November 9, 2011 10:30 AM
> Subject: Re: pfsync states growing on
carp backup firewall
>
>
> You might test to pull down if_pfsync.c from
-current
> or
> flush states much sooner on failover with pf.conf
(adaptive.start adaptive.end)
>
> //maxim
>
> On Nov 9, 2011, at 9:49 AM, ML
mail wrote:
>
>> Hi,
>>
>> I am running OpenBSD 5.0 amd64 on two firewalls
using CARP (one master
>> and one backup) for redundancy/fail-over purpose.
Now on the backup firewall I
>> noticed that the states synchronised using
pfsync on a dedicated NIC with a
>> cross-over cable are at least double as
much as on the master firewall. So for
>> example right now there are 15k
states on the master firewall and 40k on the
>> backup firewall. From my
understanding these numbers should pretty much
>> correlate.
>>
>> I don't
have the feeling I've been doing anything wrong neither as
>> I have
documented myself about how configuring CARP and have been running it
>>
successfully before using OpenBSD 4.4 (I just re-installed with OpenBSD 5.0).
>> Just in case here are the relevant hostname.* config files:
>>
>> #
>>
/etc/hostname.em7 (master fw)
>> inet 10.10.10.1 255.255.255.0
>>
>> #
>>
/etc/hostname.em7 (backup fw)
>> inet 10.10.10.2 255.255.255.0
>>
>>
>> #
>>
/etc/hostname.pfsync0 (master fw)
>> up syncpeer 10.10.10.2 syndev em7
>>
>>
#
>> /etc/hostname.pfsync0 (backup fw)
>> up syncpeer 10.10.10.1 syndev em7
>>
>> Could it
>> be that my cross-over cable is somehow faulty? or my config is
wrong?
>>
>> Thanks
>> for the feedback.
>>
>> Regards,
>> ML
