Vasily Averin <vvs@xxxxxxxxxx> 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?
