From: Yi-Hung Wei <yihung....@gmail.com> Date: Thu, 24 May 2018 17:56:41 -0700
> Currently, nf_conntrack_max is used to limit the maximum number of > conntrack entries in the conntrack table for every network namespace. > For the VMs and containers that reside in the same namespace, > they share the same conntrack table, and the total # of conntrack entries > for all the VMs and containers are limited by nf_conntrack_max. In this > case, if one of the VM/container abuses the usage the conntrack entries, > it blocks the others from committing valid conntrack entries into the > conntrack table. Even if we can possibly put the VM in different network > namespace, the current nf_conntrack_max configuration is kind of rigid > that we cannot limit different VM/container to have different # conntrack > entries. > > To address the aforementioned issue, this patch proposes to have a > fine-grained mechanism that could further limit the # of conntrack entries > per-zone. For example, we can designate different zone to different VM, > and set conntrack limit to each zone. By providing this isolation, a > mis-behaved VM only consumes the conntrack entries in its own zone, and > it will not influence other well-behaved VMs. Moreover, the users can > set various conntrack limit to different zone based on their preference. > > The proposed implementation utilizes Netfilter's nf_conncount backend > to count the number of connections in a particular zone. If the number of > connection is above a configured limitation, OVS will return ENOMEM to the > userspace. If userspace does not configure the zone limit, the limit > defaults to zero that is no limitation, which is backward compatible to > the behavior without this patch. > > The first patch defines the conntrack limit netlink definition, and the > second patch provides the implementation. ... Series applied, thanks for sticking with it so long and responding to the feedback you received.
