Ever seen the error “ip_conntrack Table full. Dropping packet” in the log file /var/log/messages? You are likely to see it busy servers, or if your server is under some kind of a DDoS attack.

But then how and why do these connection tracking happen. As the KB explains, ip_conntrack is an iptables module that maintains a list of connections through router. Each connection tracking entry contains defined characteristics of the packet, including the source and destination IP address and port numbers. Entries are stored in a hash table with a fixed size.

If you have the module loaded, you may view the list of current entries in the conntrack database by viewing the file /proc/net/ip_conntrack

A sample output would look like the following, if you cat /proc/net/ip_conntrack :

tcp 6 27 TIME_WAIT src=xxx.192.57.168 dst=xxx.192.57.168 sport=56292 dport=8081 packets=5 bytes=1113 src=xxx.192.57.168dst=xxx.192.57.168 sport=8081 dport=56292 packets=5 bytes=506 [ASSURED] mark=0 secmark=0 use=1

Among the various information maintained in the database, some that help in analysing the nature of connections are :

TCP :it is the protocol

27 : the time in seconds after which the connection tracking entry expires

TIME_WAIT : state of the connection in real time

ASSURED : The ASSURED flag tells us that this connection is assured and that it will not be erased if we reach the maximum possible tracked connections. Thus, connections marked as ASSURED will not be erased.

Then the usual stuff like the source/destination, ports etc, which are not critical when things are all normal.

All these can be vital in analysing a DDoS attack that fills up the conntrack table.

How to raise the limit

The maximum size of the connection tracking table can be increased. The value is stored in the router’s proc filesystem in the file /proc/sys/net/ipv4/ip_conntrack_max. Increasing the maximum size of the connection tracking table to a value larger than the total number of connections will eliminate the error message and prevent the router from dropping connections due to a lack of space in the connection tracking table.

Now, as a generic rule, an approximate number of 65,500 per 1 GB of RAM can be raised. It implies a server having larger RAM can handle a larger conntrack database.