Re: troubles caused by conntrack overlimit in init_netns

[Florian Westphal <fw@strlen.de>]

Vasily Averin <vvs@openvz.org> wrote:
> There is an old issue with conntrack limit on multi-netns (read container) nodes.
> 
> Any connection to containers hosted on the node creates a conntrack in init_netns.
> If the number of conntrack in init_netns reaches the limit, the whole node becomes
> unavailable.

Right, from inet_net p.o.v. connections coming from container netns is
no different from different physical host on pyhsical network.

> To avoid it OpenVz had special patches disabled conntracks on init_ns on openvz nodes, 
> but this automatically limits the functionality of host's firewall.
> 
> This has been our specific pain for many years, however, containers are now 
> being used much more widely than before, and the severity of the described problem
> is growing more and more.
> 
> Do you know perhaps some alternative solution?

If you need conntrack in init_net, then no.

If you don't (or only for connections that won't be rerouted to
container netns) you could -j NOTRACK traffic coming from/going to
container.

But, why do you need conntrack in the container netns?
Normally I'd expect that if packet was already handled in init_net,
why re-run skb through conntrack again?