IP_conntrack table full

[thewebhosting]

Hi,

I have a problem with IP_conntrack table. It gets full frequently and resultantly the server is unreachable. The current value is set to 34576 (which is default value I think) in ip_conntrack_max. Below is the logs provided by DC technicians:

servers kernel: ip_conntrack: table full, dropping packet.
servers kernel: printk: 19 messages suppressed.

Can someone help me to resolve this issue. I have REDHAT Enterprise 5.1 i686 with WHM 11.15.0 cPanel 11.18.5-S24225.

Thanks,

[jayh38]

Sure, here are some guidelines for adjustments:

Rule of thumb 7000 * 64meg ram = 437500 max for 4GB ram 218750 for 2GB ram

This tells you how many sessions arte open right now.
cat /proc/net/ip_conntrack | wc -l

This tells you the maximum number of conntrack entries you can have in total
cat /proc/sys/net/ipv4/ip_conntrack_max

Once the current open sessions go beyond the maximum number of entries, you should start seeing these messages by running dmesg
"ip_conntrack: table full, dropping packet"

Increase the maximum entries:
echo "some_bigger_number>" /proc/sys/net/ipv4/ip_conntrack_max

or if you want it to span reboots, you can place the following in /etc/sysctl.conf
sys.net.ipv4.ip_conntrack_max =3D some_big_number

Hope this helps

[thewebhosting]

Hi jayh38,

Thanks for the detailed information.

Is it normal if the server exceeds to 34576 sessions?

Thanks,

[jayh38]

Normal? hmmmm... I think its safe to say that most servers would not need an adjustment unless they are run high traffic. I have several servers that exceed this and currently I have them set at 65536 and at peak traffic time it will get close to 50k or a bit higher.

It would be safe to assume you got some traffic there eh?

[arn]

hey all,

I'm running into the same problems. I had made the changes and even added it to my sysctl.conf file but the changes don't seem to "take".

In that, it's ok when I manually change it, but at around 4-5am it resets back to the 31k number. CPanel seems to be running a script (cpaddons_report.pl) around that time. Not sure if directly related, but something is resetting it.

any ideas?

arn