Recurring ip_conntrack table overflow

Recurring ip_conntrack table overflow

[Wilson, Richard E]

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)?

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

Re: Recurring ip_conntrack table overflow

[Eric Leblond]

[-- 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 --]