Re: Recurring ip_conntrack table overflow

[Eric Leblond <eric@inl.fr>]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

Le mercredi 11 octobre 2006 à 15:39 -0500, Wilson, Richard E a écrit :
> All,
> 
> I have a server that is frequently running out of slots in the
> ip_conntrack table and have been trying to determine how best to handle
> it.  The ip_contrack_max sysctl parm is set to 65536 already (this
> server has 4GB of RAM) and the ip_conntrack slot count (determined by
> "cat /proc/net/ip_conntrack | wc -l") is both growing and decreasing.
> Apparently a "clean" disconnect frees a slot.
> 
> The server had to be rebooted this AM as the console was displaying a
> series of messages:
> 
> ip_conntrack: table full, dropping packet
> 
> After some research, I'd like to find out what my options are:
> 
> 1. Can the ip_contrack_max parm be set higher than 65536?  Is it
> desirable (how much RAM does each slot take)?

I recommend this reading this is really informative :
	http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
This documents the way you can *greatly* improve the conntrack
behaviour.

BR,

> 
> 2. I found a reference to a timeout value in Linuxquestions.org: 
> 
> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
> 
> This appears to be the amount of time to keep an entry in the conntrack
> table, and defaults to 6 days... This parm doesn't exist on my server
> (running RH EL 3.2.3-54, kernel 2.4.21-47 and iptables 1.2.8)   What
> would be involved in upgrading iptables to include this parm and would
> decreasing it to 1 or 2 days address the issue?
> 
> 3. I also found a reference to a "NOTRACK" target that appears to make
> packets to which it applies not get put into the conntrack table.  Could
> this be used to handle my loopback traffic?  I currently have an ACCEPT
> rule for any traffic on the loopback (127.0.0.1) and out of 17,485
> entries currently in my conntrack table, 6,216 have source and
> destination of 127.0.0.1 -- getting these out of the table would really
> help.  (I have verified that this is legitimate traffic for this server)
> 
> Where can I find more information out about the NOTRACK target and how
> is it implemented (does NOTRACK DROP, REJECT or ACCEPT packets)?
> 
> Thanks in advance,
> 
> 
> Richard Wilson
> Richard dot wilson at eds dot com
> 
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]