IPF is limited in several ways...

For one, the state table is hard-coded to 2048 states max.  With a
busy server, one incoming TCP connection can easily generate:

	1 state for the TCP connection itself,
	1 state for a reverse DNS lookup (assuming the first DNS
	  server hit had the answer, which is unlikely.  More like
	  2-3 here.)
	1 state for a forward DNS lookup (once again, often 2-3)
	-
	3 minimum, 5-8 typical.

So, for that single incoming connection, for a short while I've
allocated a whole lot of state, and I'm limiting how many clients I
can serve now.

I have always thought that the way ipf tracks state by looking at the
packets is wrong.  It seems like a better way would be to attach a
little bit of state glue to the socket structure, or the udp/tcp
control blocks.  State only makes sense on UDP and TCP anyway,
presently.

As for the 1000 entry limit for counting, wow.  That's a lot of rules
to look through anyway ;)  It seems that the rules are dynamically
allocated, however.  I suspect you're hitting a different limit, that
of CPU searching through a 1000 element linked list.

Can you perhaps break them into groups to speed things up?  The syntax
here might be wrong, but here goes.  I have two IP addresses on my
machine, each of which has different purposes.  Here's what I might
try later today:

pass in from any to 204.152.184.79 head 100
pass in from any to 204.152.184.80 head 200

count in proto tcp all port = 80 group 100

count in proto tcp all port = 80 group 200

This makes one top-level comparison, and if that fails, the (perhaps
hundreds) of count statements won't need to run.

You might need to use

count in proto tcp from any to 204.152.184.79 port = 80 group 100

to make that count line "unique" though, I dunno.

Erik Rungi <blackbox@openface.ca> writes:

> I'm finding that on NetBSD-1.3/i386 after about 1000 IPF "count" rules, my
> NetBSD router box will grind to a halt if I try to forward any significant
> amount of traffic through it.  The box seems fine at low levels of traffic,
> but in combination with 4-5Mbps of packet forwarding, things go bad quickly.
> 
> Are there any OS compile-time parameter limitations to IPFILTER rules that I
> should know about? Lets say I wanted to do byte counts on several thousand
> individual hosts, using a NetBSD ipf configured gateway.  From what I can
> see, this just won't work because the kernel gacks.  This is on a P166 with
> 32MB ram, fully dedicated to doing routing and nothing else. Symptoms include
> nasty packet loss and unresponsive consoles The machine doesn't actually crash
> or anything.
> 
> In my kernel config I previously had a MAXUSER setting of 2, which I
> subsequently changed to 64. This seemed to help, which is why I suspect there
> may be some kernel size limitations at work, but it didn't bring performance
> up enough to make the machine useable with the filter rules I was trying to
> use.
> 
> Am I missing something here?
> 
> Erik