On Tue, 19 Mar 2002, Patrick Schaaf wrote: > I agree that the hash function needs scrutiny. Do you (or somebody else > here) have a good collection of real world /proc/net/ip_conntrack excerpts, > maybe coming from the development of ctnetlink? I'll cook up a "hash > occupation simulator" for user level, where you can pipe in a conntrack > table, and get reports about the distribution of chain sizes. > > As I don't run realworld conntracking firewalls with lots of connections > (I'm using the stuff almost exclusively on servers), I need the help of > you all to get good input test data, here.
Just as a small sidenote... dumping the entire hashtable is very broken in ctnetlink, the patch in cvs will kill your kernel. I've fixed at least the bug that crashes kernel but the dumping still doesn't work, you only get the first 46 (or was it 47?) connections, one full skb so I need to implement multi packet responses... I've also fixed a few other bugs that could crash kernel and I've cleaned it up a bit. All the same bugs are present in nfnetlink, I'll supply a patch for cvs soon, there's an SMP race in ctnetlink that I'd like to fix first. And as Harald wrote, /proc/net/ip_conntrack is very slow, it's O(n^2). And theres no guarantee that you actually get all connections when reading it. I have a router with 73.000 entries in conntrack, I can see if I can copy /proc/net/ip_conntrack sometime during the night (it will disturb routing a _lot_, this was the reason I started playing with ctnetlink and fixing it up. I'm using oidentd on NAT routers here and every lookup took a very long time (several seconds) and during that time the routinglatency went up to 100-300ms through the router, now with ctnetlink and a hacked oidentd I don't see anything happening to the latency while serving a lot of ident requests) > > And real-world traffic usually means narrow source ip ranges > > (because most people firewall a couple of Class-C's) and narrow source > > port ranges (let's assume lots of users aren't causing too many connections > > and thus the source port range stays close to the startup default port (32k?)) > > The destination ports are most definitely also not very distributed, since > > most people will do the same services (http, ftp, smtp, or whatever is used > > from within this organization). I have 1000 clients in total behind three routers, we have 2 C-class subnets behind each router + an internal network thats NAT'd. /Martin Never argue with an idiot. They drag you down to their level, then beat you with experience.
