LARTC - Feb 2007 - Conntrack table full and Heavy p2p loaded traffic manager ...

Hello

I''ve setuped a bridge with l7-filter and ipp2p.  We have every day  +
or
-  between 10Mbits and 30 Mbits P2P traffic from + or - 450 customers.
When traffic  increase. I''ve got this kind of error message :

Feb 23 14:26:19 gestor1 kernel: printk: 38 messages suppressed.
Feb 23 14:26:19 gestor1 kernel: ip_conntrack: table full, dropping packet.

The server is  celeron pentium 4 based 3Ghz + 512Mb ram
Does anyone could suggest me what are the best value for

net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established

Might be I can tune other kernel value ?
Thanks for your help

Regards





-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
L7-filter-users mailing list
L7-filter-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/l7-filter-users

> I''ve setuped a bridge with l7-filter and ipp2p.  We have every day
+ or
> -  between 10Mbits and 30 Mbits P2P traffic from + or - 450 customers.
> When traffic  increase. I''ve got this kind of error message :
> 
> Feb 23 14:26:19 gestor1 kernel: printk: 38 messages suppressed.
> Feb 23 14:26:19 gestor1 kernel: ip_conntrack: table full, dropping packet.
Not necessarily the answer you were looking for, but this is what
connlimit was written for. Connlimit will limit the number of parallel
TCP connections per host. Do something like:

iptables -t mangle -A PREROUTING -p tcp -i eth0 --dport 1024: \
	-m connlimit --connlimit-above 30 -j DROP

connlimit is not in the vanilla kernel at the minute; you need to patch
with pom. You can download pom from
http://ipset.netfilter.org/install.html, but you may need to patch pom
first! See
http://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025090.html

Andy Beverley

On Friday 23 February 2007 16:28, Sébastien CRAMATTE
wrote:
> Hello
>
> I''ve setuped a bridge with l7-filter and ipp2p.  We have every day
+ or
> -  between 10Mbits and 30 Mbits P2P traffic from + or - 450 customers.
> When traffic  increase. I''ve got this kind of error message :
>
> Feb 23 14:26:19 gestor1 kernel: printk: 38 messages suppressed.
> Feb 23 14:26:19 gestor1 kernel: ip_conntrack: table full, dropping packet.
>
> The server is  celeron pentium 4 based 3Ghz + 512Mb ram
> Does anyone could suggest me what are the best value for
>
> net.ipv4.netfilter.ip_conntrack_max
> net.ipv4.netfilter.ip_conntrack_tcp_timeout_established
leave the timeouts as is, and focus on the conntrack_max,
lnstat command is your friend, will help to find the magic numbers:

lnstat -f ip_conntrack -i 1 -c 1 

this will tell you the number of entries used in real time, so you can put a 
very large value in ip_conntrack_max and monitor with lnstat and crontab like 
this:
*/5 *    * * *    root  date >> /var/log/conntrack_watchdog.log; lnstat -f
ip_conntrack -i 1 -c 1 >> /var/log/conntrack_watchdog.log

After a couple of days you are ready to put the perfect number for you 
personal enviroment.

Each conntrack entrie is about 350bytes from non-swappable kernel memory, so 
you can make your maths to know how much RAM is consumed.
> Might be I can tune other kernel value ?
yes, in large setups is recommended to change the conntrack hash table size:
modrobe ip_conntrack hashsize=xxx

to avoid to have a large ammount of entries in the same bucket, this can have 
performmance issues, you can check your acctual hash table size looking at 
dmesg.


-- 
Luciano

On Monday 26 February 2007 06:07, you wrote:
> Hello,
cc to the list, it may help others.
> Thanks for your answer
> Do you know a method  to choose hashSize  as you explain me for
> conntrack max ?
Yes, the hash table size(search wikipedia if you do not know what a hash table 
is) is the numbers of bucket that you have. 
So if you have a table with 10 buckets and you put 160 conntrack 
entries(conntrack_max), then each bucket will have 16 average  entries. In 
practice can happens that a bucket has 0 and other has 30 or more, it depends 
on the eficency of the hash algorithm, but you can assume an average of 16 to 
do your maths.
After the bucket is found by the hash function, the entrie is searched 
lineary, so in our example with hash_size at 10 and conntrack_max at 160, the 
kernel will do at last an 16 items linear search, so just to simplify, whe 
can assume an average linear search of 8 items.

In a 1GB memroy i386PC, the linux kernel defaults to 8180 buckets and 65440 
entries, if you start reciving messages that conntrack table is full, you can 
just rise up the entries to an 1/16 ratio (as in the example above), this 
means set conntrack_max to 13088 and leave hash_size in 8180.
At 5000 searches per second you will have an average of 5000*8=40000 aditional 
operations to search an item, 40000 operations/second shure cost some cpu 
cycles.
But if you rise up the bucket as well to  65440(1/2 ratio) you will reduce the 
number to just 5000 operations per second.

To choose the rigth number just depends on how much RAM you have, how fast is 
you CPU, and how many searches are made in the conntrack table.
--
Luciano