IPFilter practical limits?

On Mon, Mar 27, 2006 at 12:14:28PM -0600, Peter Eisch wrote:
> 
> Short of reading source, is there a practical guide for
how to tune ipfilter
> or how to use each of the configurable parameters?

Unfortunately no.

> Also, for higher utilization systems (ones with lots of
state entries) would
> pf be a better solution?  Or, put another way, if I
have an infinite amount
> of RAM and the kernel can have it, is there a practical
point where using pf
> would be better?

No, there isn't.  IPFilter uses hash tables for its
storage/lookup and
if you had infinite amounts of RAM, you could always
guarantee that a
lookup would hit or miss on first try (rather than work your
way through
a tree like pf uses.)  So if you like, you could tune
ipfilter towards
using more RAM in a manner that suited quicker lookups.  You
can tell pf
it can make the tree bigger, but it will never get you an
O(1) lookup
like you can do with a hash table.

I think the inverse might be true - if you could only have a
small hash
table and you wanted to put lots of things in it, searching
that could
be worse than a tree.  But then I'd argue that you're
dimensioning the
system incorrectly.

Darren

On 3/27/06 2:32 PM, "Darren Reed"
<darrenrNetBSD.org> wrote:

> On Mon, Mar 27, 2006 at 12:14:28PM -0600, Peter Eisch
wrote:
>> 
>> Short of reading source, is there a practical guide
for how to tune ipfilter
>> or how to use each of the configurable parameters?
> 
> Unfortunately no.
> 

When the state table is full or when the bucket usage
reaches 100% (not sure
which), what happens to subsequent connections?  I was
observing that
sessions that should have had state were simply getting
blocked with -AP
once the session no longer matched the 'flags S/SA' in the
rules.

Should there have been a message somewhere that the insert
into the state
table failed or there was no more memory available?

Are you aware of any institutions that use ipfilter as a
firewall appliance
as opposed to a local host interface?  I am using it in a
configuration
where a Big IP or cisco director system might be used (lots
of round-robin
definitions).  

Would pf get me an interface to introduce a shared state
table across
multiple systems?  (Redundancy has been my next road to
travel.)  I need to
protect servers of lots of low-bandwidth connections
(>6000) and I've been
looking at options for growing.

I guess I should fire up a system with pf and take it for a
drive.  I see it
more as a tool for honeypot scripters or for people who have
trouble getting
around ipf.conf rulesets.  (which could have been me 4 years
ago -- not
claiming any elitist status)  Maybe its more flexible for
what I need.  (?)

Thank you for your time, Darren (and software),

peter

On Mon, Mar 27, 2006 at 09:47:14PM +0000, Darren Reed
wrote:
> When the limits are reached, you'll see a non-zero
number next to the
> line with "maximum" in it from running
"ipfstat -s".

If you do see a number next to the line with
"maximum" (as I have just
witnessed on our last "network is slow" session)
what can you do about
it?

Cheers,

Patrick

On Sat, Feb 17, 2007 at 06:46:19PM +0000, Patrick Welche
wrote:
> On Mon, Mar 27, 2006 at 09:47:14PM +0000, Darren Reed
wrote:
> > When the limits are reached, you'll see a non-zero
number next to the
> > line with "maximum" in it from running
"ipfstat -s".
> 
> If you do see a number next to the line with
"maximum" (as I have just
> witnessed on our last "network is slow"
session) what can you do about
> it?

So "maximum" corresponds to fr_statemax being
full? So the answer is
increase fr_statemax and fr_statesize to prime numbers with
fr_statemax ~= 0.7 fr_statesize.

I assume that if this is wrong, someone will tell me...

Cheers,

Patrick

On Sat, Feb 17, 2007 at 06:46:19PM +0000, Patrick Welche
wrote:
> On Mon, Mar 27, 2006 at 09:47:14PM +0000, Darren Reed
wrote:
> > When the limits are reached, you'll see a non-zero
number next to the
> > line with "maximum" in it from running
"ipfstat -s".
> 
> If you do see a number next to the line with
"maximum" (as I have just
> witnessed on our last "network is slow"
session) what can you do about
> it?

You need to increase the hash table size.

IPSTATE_SIZE and IPSTATE_MAX are what need to be increased.

If you're building your own kernel,
/sys/dist/ipf/netinet/ip_state.h
is the file to change.

darren

On Tue, Feb 27, 2007 at 03:50:03PM +0000, Darren Reed
wrote:
> On Sat, Feb 17, 2007 at 06:46:19PM +0000, Patrick
Welche wrote:
> > On Mon, Mar 27, 2006 at 09:47:14PM +0000, Darren
Reed wrote:
> > > When the limits are reached, you'll see a
non-zero number next to the
> > > line with "maximum" in it from
running "ipfstat -s".
> > 
> > If you do see a number next to the line with
"maximum" (as I have just
> > witnessed on our last "network is slow"
session) what can you do about
> > it?
> 
> You need to increase the hash table size.
> 
> IPSTATE_SIZE and IPSTATE_MAX are what need to be
increased.
> 
> If you're building your own kernel,
/sys/dist/ipf/netinet/ip_state.h
> is the file to change.

Is

  ipf -T fr_statemax=...,fr_statesize=...

equivalent? And should I worry about non-zero "max
bucket" ? e.g.:

IP states added:
        7144663 TCP
        224870 UDP
        134908 ICMP
        1101070506 hits
        7975148 misses
        74 maximum
        0 no memory
        3 max bucket
        74 maximum
        0 no memory
        15749 bkts in use
        27899 active
        0 expired
        25422 closed
State logging enabled

State table bucket statistics:
        15749 in use    
        31.48% bucket usage
        0 minimal length
        7 maximal length
        1.393 average length


Cheers,

Patrick