Subject: Re: IPF accounting rule limits
To: Erik Rungi <firstname.lastname@example.org>
From: Michael Graff <email@example.com>
Date: 04/27/1999 13:24:11
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
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,
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 184.108.40.206 head 100
pass in from any to 220.127.116.11 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 18.104.22.168 port = 80 group 100
to make that count line "unique" though, I dunno.
Erik Rungi <firstname.lastname@example.org> 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
> Am I missing something here?