pfsync errors

As far as I can tell, am having the same problem described
by bill
marquette. I have two firewalls using pfsync, where the
secondary
firewall just increases its state count steadily.

I created a simple libpcap program to watch the pfsync
headers flowing
by, and i see types 8, 4, 2, which are PFSYNC_ACT_UREQ,
PFSYNC_ACT_UPD_C, PFSYNC_ACT_UPD. I dont see any of type 3
or 5, which
are the ones that delete state. As far as i can tell, states
are
pumped across the link, but never removed and are left to
time out on
their own.

I'd like to add myself as another datapoint for this
problem.
Currently I am getting about 15k send errors per second, and
im up to
1.8 million states on the secondary firewall 

# while true; do netstat -s -p pfsync | grep send error;
sleep 1; done
                2096018860 send error
                2096036208 send error
                2096052950 send error
                2096070675 send error
                2096089621 send error
                2096106671 send error
                2096121646 send error
                2096138996 send error
                2096158012 send error
                2096177555 send error
                2096194727 send error
                2096216490 send error
                2096238626 send error

[rootsecondary /]# pfctl -si
Status: Enabled for 1 days 00:06:01           Debug: Urgent

Hostid: 0x97bb3fdc

State Table                          Total             Rate
  current entries                  1877429

[rootprimary /]# pfctl -si
Status: Enabled for 2 days 06:54:26           Debug: Urgent

Hostid: 0x85c326db

State Table                          Total             Rate
  current entries                   172889
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On 9/5/07, Rian Shelley <rianscc.usu.edu> wrote:
> As far as I can tell, am having the same problem
described by bill
> marquette. I have two firewalls using pfsync, where the
secondary
> firewall just increases its state count steadily.
>
> I created a simple libpcap program to watch the pfsync
headers flowing
> by, and i see types 8, 4, 2, which are
PFSYNC_ACT_UREQ,
> PFSYNC_ACT_UPD_C, PFSYNC_ACT_UPD. I dont see any of
type 3 or 5, which
> are the ones that delete state. As far as i can tell,
states are
> pumped across the link, but never removed and are left
to time out on
> their own.

I'll have to run our scripts again, but I'm pretty sure we
were seeing
state deletions.  But we certainly were not seeing 1 for 1
insert/deletion messages (one of our clusters frontends the
web
servers so we have LOTS of short lived states).

> I'd like to add myself as another datapoint for this
problem.
> Currently I am getting about 15k send errors per
second, and im up to
> 1.8 million states on the secondary firewall 

Nice.  How much RAM is that eating?  I'm happy to hear that
FreeBSD
seems to be able to handle a state count this high.  What's
the state
limit in your config?

--Bill
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On 9/5/07, Max Laier <maxlove2party.net> wrote:
>
> Another way to go is setting the queuelength for the
internal processing
> queue to something insanely high (1000+).  This will
most likely work
> around the problem at the cost of burning (mbuf)
memory.

Assuming mbuf memory is essentially free that's certainly
not a
problem for me.  Is this the max ifqlen patch you had me try
last
week?  If so, what's a reasonably (relative to insanely high
)
number to set that multiplier to?  2 times queue length
"helped".  I
don't want to set it so high that the box panics or
something silly 
 Or for that matter, stops forwarding traffic while
processing.  We'll
give these patches a try in our lab shortly.  We just
started getting
the Smartbits online to try and duplicate the errors
(straight up udp
testing can't replicate it).

--Bill
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Thursday 06 September 2007, Bill Marquette wrote:
> On 9/5/07, Max Laier <maxlove2party.net> wrote:
> > Another way to go is setting the queuelength for
the internal
> > processing queue to something insanely high
(1000+).  This will most
> > likely work around the problem at the cost of
burning (mbuf) memory.
>
> Assuming mbuf memory is essentially free that's
certainly not a
> problem for me.  Is this the max ifqlen patch you had
me try last
> week?  If so, what's a reasonably (relative to insanely
high )
> number to set that multiplier to?  2 times queue length
"helped".  I
> don't want to set it so high that the box panics or
something silly 
>  Or for that matter, stops forwarding traffic while
processing.  We'll
> give these patches a try in our lab shortly.  We just
started getting
> the Smartbits online to try and duplicate the errors
(straight up udp
> testing can't replicate it).

Try 1000 (or 20 * maxifqlen iirc).

-- 
/"  Best regards,                      | mlaierfreebsd.org
 /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.l
ove2party.net/  | mlaierEFnet
/   ASCII Ribbon Campaign              | Against HTML Mail
and News

On 9/6/07, Max Laier <maxlove2party.net> wrote:
> On Thursday 06 September 2007, Bill Marquette wrote:
> > On 9/5/07, Max Laier <maxlove2party.net> wrote:
> > > Another way to go is setting the queuelength
for the internal
> > > processing queue to something insanely high
(1000+).  This will most
> > > likely work around the problem at the cost of
burning (mbuf) memory.

I set it to 2000, and it doesn't appear to have fixed the
problem.

I suppose ill wait for the next release...
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"