On Wed, Oct 26, 2011 at 9:51 PM, Maxim Bourmistrov
<m...@alumni.chalmers.se> wrote:
>
> Well, it is idle so far as it is not able to take care of dhcp-clients -
dhcpd listens on CARP which is not available at the moment.
> This box is a slave to the named too, but updates of zone are not so
frequent due to the LAN-side.
>
> I'll try to boot back origin bsd, but as of my knowledge, lager updates
should not(if any) increase number of states on the other side,
> rather than remove many as requested and update many as requested.
>
> I had my thoughts about MCLBYTES affecting the rest of the code, but not
checked it out at all.
>
> pf.conf is ALLWAYS in sync on both sides. This is even stated clearly in
comments, incase any should take over after me.
>
> //maxim
>
>
> On Oct 26, 2011, at 8:50 PM, Camiel Dobbelaar wrote:
>
>> On 26-10-2011 20:32, Maxim Bourmistrov wrote:
>>> The side question, after observing 'systat -s1 states', is WHY
"failover"-side
>>> doubles exp. time??
>>> I'm more expected to have it like a "copy" of the current state of the
>>> master.
>>
>> Yes, the number of states should be roughly in sync on both firewalls.
>> I'd keep pf.conf in sync too (including all settings).
>>
>> Is the backup firewall really idle on all interfaces?
>>
>> Does it happen without the pfsync mtu changes too? What does "netstat
>> -s -p pfsync" say?
>>
>> What do you see if you capture "pfctl -ss | sort" on both firewalls (at
>> the same time) and diff the outputs?
>>
>
>
this has nothing to do with mtu. this bug^Wbehavior is there since
quite some time. but given the code like this:
st->expire = time_second;
if (sp->expire) {
/* XXX No adaptive scaling. */
st->expire -= r->timeout[sp->timeout] - ntohl(sp->expire);
}
st->expire = ntohl(sp->expire) + time_second;
this is not something we can't anticipate.
i've started looking into the problem, but it's not yet apparent as to
why it happens.
cheers
