Hi
> But, why do you need conntrack in the container netns?
Container can hold a default installation of a linux distro, that often enables firewall and adds rules
that trigger conntrack. But, that is inside container's netns. That is accounted separately and is not
part of the issue being discussed.
The issue is that traffic directed to container(s) eats out host's conntrack limit, and causes the host
to be inaccessible via network.
>> Do you know perhaps some alternative solution?
>
> If you need conntrack in init_net, then no.
I suppose this can be fixed by something like:
- adding some "window" on top of host's conntrack limit,
- if out of conntracks, but still within window, conntrack shall be created but marked,
- mark could be removed by a dedicated netfilter rule,
- attaching more than one skb to marked conntrack shall be blocked (i.e. packet dropped instead),
- if skb pointing to a marked conntrack is about to leave the stack (that is, either being delivered
locally, or queued for transmitting out), it shall be dropped instead, and conntrack removed.
This shall give host's admin a way to explicitly configure a packat path to use as a host management
interface, that will stay accessible even if containers eat out conntrack limit.
Is that reasonable? Maybe I can try to implement that...
Nikita
