On Mon, Apr 23, 2018 at 6:39 AM, David Miller <da...@davemloft.net> wrote: > From: Yi-Hung Wei <yihung....@gmail.com> > Date: Tue, 17 Apr 2018 17:30:27 -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. >>
Hi This looks like general problem related to nf zone usage limit, Did you considered changing nf-conntrack to have a per zone limit, so that all users of nf-filter can use it. I prefer this to adding a wrapper in OVS nf-filter layer. Thanks, Pravin. >> 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. > > Pravin, I need this series reviewed. > > Thank you.
