[Openstack-operators] mitigating issues with kernel-level connection tracking

Ahmed RAHAL arahal at iweb.com
Wed Jul 9 14:34:25 UTC 2014


Hi Arne,

Le 2014-07-09 04:42, Arne Wiebalck a écrit :
> Hi,
>
> We recently had a case of the kernel dropping packets due to a full connection tracking table ("kernel: nf_conntrack: table full, dropping packet.”).
>
> How do people usually deal with this:
>
> - increase the buffer size (which is what I did for now)?
> - reduce tracking timeouts?
> - remove connection tracking altogether?
>

Actually, we're testing these as well.

We already increased conntrack_max to evade the problem temporarily.

Reducing tracking timeouts is a good step, but still, in case of massive 
connection surges, it won't help, so not a solution in the long run.

Removing connection tracking has been attempted. Beware, this has 
pitfalls. Mainly, if you're really using security-groups you'll find the 
old way of stateless firewalls very depressing.
I am unaware of any issues that could arise with the metadata service 
(as we're not using it).

Hint: iptables has a magic table called 'raw'.
There you can add a NOTRACK target in the PREROUTING/OUTPUT chains.
This permits to not track connections that you know will not be harmed 
by not getting into the conntrack table.

Finally, 2 very nice tools:
conntrack: similar command line options than iptables, to show, filter, 
alter and delete connections in conntrack
(http://conntrack-tools.netfilter.org/)

iptstate: top-like tool for conntrack table
(http://www.phildev.net/iptstate/)

Bye

-- 
Ahmed



More information about the OpenStack-operators mailing list