On Wed, Oct 23, 2019 at 6:31 PM Florian Westphal <fw@xxxxxxxxx> wrote: > > xiangxia.m.yue@xxxxxxxxx <xiangxia.m.yue@xxxxxxxxx> wrote: > > nf_conntrack_max is used to limit the maximum number of > > conntrack entries in the conntrack table for every network > > namespace. For the containers that reside in the same namespace, > > they share the same conntrack table, and the total # of conntrack > > entries for all containers are limited by nf_conntrack_max. > > In this case, if one of the container abuses the usage the > > conntrack entries, it blocks the others from committing valid > > conntrack entries into the conntrack table. > > > > To address the issue, this patch adds conntrack counter for zones > > and max count which zone wanted, So that any zone can't consume > > all conntrack entries in the conntrack table. > > > > This feature can be used for openvswitch or iptables. > > Your approach adds cost for everyone, plus a 256kbyte 'struct net' > increase. > > openvswitch supports per zone limits already, using nf_conncount > infrastructure. This path limits the UNREPLIED conntrack entries. If we SYN flood one zone, the zone will consume all entries in table, which state SYN_SENT. The openvswitch limits only the +est conntrack. > nftables supports it using ruleset (via 'ct count'). > > If you need support for iptables, consider extending xt_connlimit.c > instead -- looking at the code it might already do all that is needed > if userspace passes a 0-length mask for the ip address, i.e. > > iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -m connlimit \ > --connlimit-above 1000 --connlimit-mask 0 -j REJECT
