11efd5cb04
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 following high leve APIs are provided to the userspace:
- OVS_CT_LIMIT_CMD_SET:
* set default connection limit for all zones
* set the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_DEL:
* remove the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_GET:
* get the default connection limit for all zones
* get the connection limit for a particular zone
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
76 lines
2.3 KiB
Plaintext
76 lines
2.3 KiB
Plaintext
#
|
|
# Open vSwitch
|
|
#
|
|
|
|
config OPENVSWITCH
|
|
tristate "Open vSwitch"
|
|
depends on INET
|
|
depends on !NF_CONNTRACK || \
|
|
(NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
|
|
(!NF_NAT || NF_NAT) && \
|
|
(!NF_NAT_IPV4 || NF_NAT_IPV4) && \
|
|
(!NF_NAT_IPV6 || NF_NAT_IPV6) && \
|
|
(!NETFILTER_CONNCOUNT || NETFILTER_CONNCOUNT)))
|
|
select LIBCRC32C
|
|
select MPLS
|
|
select NET_MPLS_GSO
|
|
select DST_CACHE
|
|
select NET_NSH
|
|
---help---
|
|
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
|
|
environments. In addition to supporting a variety of features
|
|
expected in a traditional hardware switch, it enables fine-grained
|
|
programmatic extension and flow-based control of the network. This
|
|
control is useful in a wide variety of applications but is
|
|
particularly important in multi-server virtualization deployments,
|
|
which are often characterized by highly dynamic endpoints and the
|
|
need to maintain logical abstractions for multiple tenants.
|
|
|
|
The Open vSwitch datapath provides an in-kernel fast path for packet
|
|
forwarding. It is complemented by a userspace daemon, ovs-vswitchd,
|
|
which is able to accept configuration from a variety of sources and
|
|
translate it into packet processing rules.
|
|
|
|
See http://openvswitch.org for more information and userspace
|
|
utilities.
|
|
|
|
To compile this code as a module, choose M here: the module will be
|
|
called openvswitch.
|
|
|
|
If unsure, say N.
|
|
|
|
config OPENVSWITCH_GRE
|
|
tristate "Open vSwitch GRE tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on NET_IPGRE
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create GRE
|
|
vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|
|
|
|
If unsure, say Y.
|
|
|
|
config OPENVSWITCH_VXLAN
|
|
tristate "Open vSwitch VXLAN tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on VXLAN
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create vxlan vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|
|
|
|
If unsure, say Y.
|
|
|
|
config OPENVSWITCH_GENEVE
|
|
tristate "Open vSwitch Geneve tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on GENEVE
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create geneve vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|