Re: [ANNOUNCE] pending newnat kernel submission (was Re: [newbie] newnat + h323 + kernel 2.4.1[789])

2002-03-18 Thread Henrik Nordstrom
On Mondayen den 18 March 2002 16.35, Harald Welte wrote: Just as a small note to all people maintaining conntrack/NAT helpers: Please port your helpers to the newnat code, I will have to temporarily remove them from CVS as soon as newnat apprears in the mainstream kernel. This applies to all

Re: [Q] connection tracking scaling

2002-03-18 Thread Patrick Schaaf
I'm working on a proxy type program, using REDIRECT to catch (tcp) traffic, and I'm seeing severe network degradation above ~2000 connection. (computer: 1Gb p3, 2Gb memory, kernel 2.4.18 + aa1 patch) Two questions first: how many packets/second is these 2000 connections? And, do you have a

RE: New DSCP target in CVS

2002-03-18 Thread Matthew G. Marsh
On Sat, 16 Mar 2002, Takuya Satoh wrote: Hi, Does the old FTOS target zero the ECN bits? Quick Answer = YES Long Answer - FTOS takes whatever HEX code you specify and overwrites _all_ 8 bits of the TOS field. So if you only specify say 0xf0 then the ECN are overwritten with 0's. make sense?

Re: [Q] connection tracking scaling

2002-03-18 Thread Patrick Schaaf
Hello Martin, thanks for your numbers. with 16384 hashbuckets and a maximum of 131072 tracked connections it took 7.5 seconds to perform 1 million lookups in the hashtable (using __ip_conntrack_find from userspace). Was this 1 million lookups to a random hash bucket each, with guaranteed no

[PATCH] fix max() usage in string match

2002-03-18 Thread Martin Josefsson
Hi Harald, the SMP fixups for the string match changed the max() to a 2.4.9 style max() with 3 args... here's a patch to fix it. /Martin Never argue with an idiot. They drag you down to their level, then beat you with experience. --- netfilter/userspace/patch-o-matic/extra/string.patch.orig

Re: [Q] connection tracking scaling

2002-03-18 Thread Patrick Schaaf
with 16384 hashbuckets and a maximum of 131072 tracked connections it took 7.5 seconds to perform 1 million lookups in the hashtable (using __ip_conntrack_find from userspace). Was this 1 million lookups to a random hash bucket each, with guaranteed no match? Assuming this in the

Re: [Q] connection tracking scaling

2002-03-18 Thread Martin Josefsson
On Mon, 18 Mar 2002, Patrick Schaaf wrote: Hello Martin, thanks for your numbers. with 16384 hashbuckets and a maximum of 131072 tracked connections it took 7.5 seconds to perform 1 million lookups in the hashtable (using __ip_conntrack_find from userspace). Was this 1 million

Re: [Q] connection tracking scaling

2002-03-18 Thread Patrick Schaaf
grep conntrack /proc/slabinfo (about 4200 connections at the time) ip_conntrack4527 4532 352 412 412 1 8192 buckets, 65536 max I guess the hash function fails for my setup (note: this is a test setup, connection originating from a single ip to a single ip) ... and probably