{"id":4178,"date":"2015-01-27T19:33:38","date_gmt":"2015-01-27T11:33:38","guid":{"rendered":"http:\/\/rmohan.com\/?p=4178"},"modified":"2015-01-27T19:33:38","modified_gmt":"2015-01-27T11:33:38","slug":"ip_conntrack-table-full-dropping-packet","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=4178","title":{"rendered":"ip_conntrack: table full, dropping packet"},"content":{"rendered":"<p>ip_conntrack: table full, dropping packet<br \/>\nAt one point, there was high call volume into our support center of customers complaining about severe lag.  One common denominator was that the customer base who called in happened to all reside on the same server, so investigation into the matter focused on that one particular system.<\/p>\n<p>The server&#8217;s load average was really low, and had plenty of free RAM, though connectivity to customers hosted websites were lagging.  After running dmesg, I noticed &#8220;ip_conntrack: table full, dropping packet&#8221;.  After observing netstat -an for a bit, it was clear the server was being used to send SPAM.  After blocking the connections and securing the customer SMTP passwords, the counts came down and the lag ceased.<\/p>\n<p>The following command can be used to see what the max setting is for this kernel parameter:<\/p>\n<p>\/sbin\/sysctl net.ipv4.ip_conntrack_max<\/p>\n<p>or<\/p>\n<p>cat \/proc\/sys\/net\/ipv4\/ip_conntrack_max<\/p>\n<p>To see how many you are using at present:<\/p>\n<p>wc -l \/proc\/net\/ip_conntrack<\/p>\n<p>or<\/p>\n<p>cat \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_count<\/p>\n<p>The setting can be adjusted, and if to be made permanent, make the change in \/etc\/sysctl.conf.  In this example, the max setting is increased to 65535.<\/p>\n<p>echo &#8220;net.ipv4.ip_conntrack_max = 65535&#8221; > \/etc\/sysctl.conf<br \/>\n\/sbin\/sysctl -w<\/p>\n<p>To increase it temporarily (non-persistent across reboots)<\/p>\n<p>echo 131072 > \/proc\/sys\/net\/ipv4\/ip_conntrack_max<\/p>\n","protected":false},"excerpt":{"rendered":"<p>ip_conntrack: table full, dropping packet At one point, there was high call volume into our support center of customers complaining about severe lag. One common denominator was that the customer base who called in happened to all reside on the same server, so investigation into the matter focused on that one particular system.<\/p>\n<p>The server&#8217;s [&#8230;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,17],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4178"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4178"}],"version-history":[{"count":1,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4178\/revisions"}],"predecessor-version":[{"id":4179,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4178\/revisions\/4179"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}