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
