[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PF and stalled connections



Right,
from the kernel:

The size of the state table (red black tree) is initially zero, and
grows until pool memory is exhausted, at which point the state-creating
packet is dropped, obviously that may, or may not, be retransmitted by
the sender and in effect "retry" later.

What else happens when pool memory is exhausted depends on "pfstatepl",
which I can't find (!). I would hope that the "drainback" has been set
to expire some states and release some memory, but it may not.
Pool memory *does* appear to be swappable, so it looks like the state
table could get real big, but if this is possible or practical, I don't
know.

As is the details of how big the pool can grow on a 64/128/256mb
machine,
doing nothing else....

Can anyone with a busy box post:
  pfctl -s state |wc -l ; vmstat
Mine is, for a 128mb machine:
# pfctl -s state |wc -l ; vmstat
      70
 procs   memory        page                    disks     faults     cpu
 r b w    avm    fre   flt  re  pi  po  fr  sr wd0 wd1   in    sy   cs
us sy id
 0 0 0  18432  92780   232   0   0   0   0   0   1   2  250   229   22
4  2 94

Can anyone 64mb, 128mb, or 256mb results?
Can anyone post "big" states table sizes?

Dom


Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto                                       Tel. 07855 805 271
http://www.devitto.com                         mailto:dom@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 


-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf
Of Henning Brauer
Sent: Thursday, January 02, 2003 10:04 AM
To: misc@openbsd.org
Subject: Re: PF and stalled connections


On Wed, Jan 01, 2003 at 09:04:02PM -0000, Dom De Vitto wrote:
> I think Henning means:
> The state table grows/shrinks appropriately.

yes. to exhaust the state table (which in theory is possible) without
setting a very low limit you'd have to have a _lot_ of connections.

> So (unlike other firewalls) you NEVER "run out" until you run out of 
> RAM (and maybe not even then - is the area swappable? Is any part of 
> the Obsd kernel swappable?)

well we acquire memory via pool(9), that is not swappable.