Recurring ip_conntrack table overflow
eric at inl.fr
Wed Oct 11 23:04:50 CEST 2006
Le mercredi 11 octobre 2006 à 15:39 -0500, Wilson, Richard E a écrit :
> 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 :
This documents the way you can *greatly* improve the conntrack
> 2. I found a reference to a timeout value in Linuxquestions.org:
> 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 at inl.fr>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: Ceci est une partie de message
Url : /pipermail/netfilter/attachments/20061011/21f2cfb3/attachment.pgp
More information about the netfilter