neutron openvswitch #2

Supports: xenial bionic cosmic disco trusty


Neutron is a virtual network service for Openstack, and a part of Netstack. Just like OpenStack Nova provides an API to dynamically request and configure virtual servers, Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (e.g., virtual NICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities (e.g., QoS, ACLs, network monitoring, etc.) . This charm provides the OpenStack Neutron Open vSwitch agent, managing L2 connectivity on nova-compute services.


This subordinate charm provides the Neutron OpenvSwitch configuration for a compute node.

Once deployed it takes over the management of the Neutron base and plugin configuration on the compute node.


To deploy (partial deployment of linked charms only):

juju deploy rabbitmq-server
juju deploy neutron-api
juju deploy nova-compute
juju deploy neutron-openvswitch
juju add-relation neutron-openvswitch nova-compute
juju add-relation neutron-openvswitch neutron-api
juju add-relation neutron-openvswitch rabbitmq-server

Note that the rabbitmq-server can optionally be a different instance of the rabbitmq-server charm than used by OpenStack Nova:

juju deploy rabbitmq-server rmq-neutron
juju add-relation neutron-openvswitch rmq-neutron
juju add-relation neutron-api rmq-neutron

The neutron-api and neutron-openvswitch charms must be related to the same instance of the rabbitmq-server charm.


It should only be used with OpenStack Icehouse and above and requires a separate neutron-api service to have been deployed.

Disabling security group management

WARNING: this feature allows you to effectively disable security on your cloud!

This charm has a configuration option to allow users to disable any per-instance security group management; this must used with neutron-security-groups enabled in the neutron-api charm and could be used to turn off security on selected set of compute nodes:

juju deploy neutron-openvswitch neutron-openvswitch-insecure
juju set neutron-openvswitch-insecure disable-security-groups=True prevent-arp-spoofing=False
juju deploy nova-compute nova-compute-insecure
juju add-relation nova-compute-insecure neutron-openvswitch-insecure

These compute nodes could then be accessed by cloud users via use of host aggregates with specific flavors to target instances to hypervisors with no per-instance security.

Network Spaces support

This charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju. This is only supported with Juju 2.0 and above.

Open vSwitch endpoints can be configured using the 'data' extra-binding, ensuring that tunnel traffic is routed across the correct host network interfaces:

juju deploy neutron-openvswitch --bind "data=data-space"

alternatively these can also be provided as part of a juju native bundle configuration:

  charm: cs:xenial/neutron-openvswitch
    data: data-space

NOTE: Spaces must be configured in the underlying provider prior to attempting to use them.

NOTE: Existing deployments using os-data-network configuration options will continue to function; this option is preferred over any network space binding provided if set.

DPDK fast packet processing support

For OpenStack Mitaka running on Ubuntu 16.04, its possible to use experimental DPDK userspace network acceleration with Open vSwitch and OpenStack.

Currently, this charm supports use of DPDK enabled devices in bridges supporting connectivity to provider networks.

To use DPDK, you'll need to have supported network cards in your server infrastructure (see dpdk-nics[DPDK documentation]); DPDK must be enabled and configured during deployment of the charm, for example:

    enable-dpdk: True
    data-port: "br-phynet1:a8:9d:21:cf:93:fc br-phynet2:a8:9d:21:cf:93:fd br-phynet3:a8:9d:21:cf:93:fe"

As devices are not typically named consistently across servers, multiple instances of each bridge -> mac address mapping can be provided; the charm deals with resolution of the set of bridge -> port mappings that are required for each individual unit of the charm.

DPDK requires the use of hugepages, which is not directly configured in the neutron-openvswitch charm; Hugepage configuration can either be done by providing kernel boot command line options for individual servers using MAAS or using the 'hugepages' configuration option of the nova-compute charm:

    hugepages: 50%

By default, the charm will configure Open vSwitch/DPDK to consume a processor core + 1G of RAM from each NUMA node on the unit being deployed; this can be tuned using the dpdk-socket-memory and dpdk-socket-cores configuration options of the charm. The userspace kernel driver can be configured using the dpdk-driver option. See config.yaml for more details.

NOTE: Changing dpdk-socket-* configuration options will trigger a restart of Open vSwitch, which currently causes connectivity to running instances to be lost - connectivity can only be restored with a stop/start of each instance.

NOTE: Enabling DPDK support automatically disables security groups for instances.

DPDK bonding

For deployments using Open vSwitch 2.6.0 or later (OpenStack Ocata on Ubuntu 16.04 onwards), its also possible to use native Open vSwitch DPDK bonding to provide increased resilience for DPDK based deployments.

This feature is configured using the dpdk-bond-mappings and dpdk-bond-config options of this charm, for example:

    enable-dpdk: True
    data-port: "br-phynet1:dpdk-bond0"
    dpdk-bond-mappings: "dpdk-bond0:a8:9d:21:cf:93:fc dpdk-bond0:a8:9d:21:cf:93:fd"
    dpdk-bond-config: ":balance-slb:off:fast"

In this example, the PCI devices associated with the two MAC addresses provided will be configured as an OVS DPDK bond device named dpdk-bond0; this bond device is then used in br-phynet1 to provide resilient connectivity to the underlying network fabric.

The charm will automatically detect which PCI devices are on each unit of the application based on the dpdk-bond-mappings configuration provided, supporting use in environments where network device naming may not be consistent across units.

Port Configuration

NOTE: External port configuration only applies when DVR mode is enabled.

All network types (internal, external) are configured with bridge-mappings and data-port and the flat-network-providers configuration option of the neutron-api charm. Once deployed, you can configure the network specifics using neutron net-create.

If the device name is not consistent between hosts, you can specify the same bridge multiple times with MAC addresses instead of interface names. The charm will loop through the list and configure the first matching interface.

Basic configuration of a single external network, typically used as floating IP addresses combined with a GRE private network:

    bridge-mappings:         physnet1:br-ex
    data-port:               br-ex:eth1
    flat-network-providers:  physnet1

neutron net-create --provider:network_type flat \
    --provider:physical_network physnet1 --router:external=true \
neutron router-gateway-set provider external

Alternative configuration with two networks, where the internal private network is directly connected to the gateway with public IP addresses but a floating IP address range is also offered.

    bridge-mappings:         physnet1:br-data external:br-ex
    data-port:               br-data:eth1 br-ex:eth2
    flat-network-providers:  physnet1 external

Alternative configuration with two external networks, one for public instance addresses and one for floating IP addresses. Both networks are on the same physical network connection (but they might be on different VLANs, that is configured later using neutron net-create).

    bridge-mappings:         physnet1:br-data
    data-port:               br-data:eth1
    flat-network-providers:  physnet1

neutron net-create --provider:network_type vlan \
    --provider:segmentation_id 400 \
    --provider:physical_network physnet1 --shared external
neutron net-create --provider:network_type vlan \
    --provider:segmentation_id 401 \
    --provider:physical_network physnet1 --shared --router:external=true \
neutron router-gateway-set provider floating

This replaces the previous system of using ext-port, which always created a bridge called br-ex for external networks which was used implicitly by external router interfaces.


(string) Space-delimited list of ML2 data bridge mappings with format <provider>:<bridge>.
(string) Space-delimited list of bridge:port mappings. Ports will be added to their corresponding bridge. The bridges will allow usage of flat or VLAN network types with Neutron and should match this defined in bridge-mappings. . Ports provided can be the name or MAC address of the interface to be added to the bridge. If MAC addresses are used, you may provide multiple bridge:mac for the same bridge so as to be able to configure multiple units. In this case the charm will run through the provided MAC addresses for each bridge until it finds one it can resolve to an interface name. Port can also be a linuxbridge bridge. In this case a veth pair will be created, the ovs bridge and the linuxbridge bridge will be connected. It can be useful to connect the ovs bridge to juju bridge.
(boolean) Enable debug logging.
(boolean) Disable neutron based security groups - setting this configuration option will override any settings configured via the neutron-api charm. . BE CAREFUL - this option allows you to disable all port level security within an OpenStack cloud.
(string) A comma-separated list of DNS servers which will be used by dnsmasq as forwarders. This option only applies when the enable-local-dhcp-and-metadata options is set to True.
(string) Comma-separated list of key=value config flags with the additional dhcp options for neutron dnsmasq. Note, this option is only valid when enable-local-dhcp-and-metadata option is set to True.
(string) Space delimited list of bond:mode:lacp:lacp-time, where the arguments meaning is: . * bond - the bond name. If not specified the configuration applies to all bonds * mode - the bond mode of operation. Possible values are: - active-backup - No load balancing is offered in this mode and only one of the member ports is active/used at a time. - balance-slb - Considered as a static load-balancing mode. Traffic is load balanced between member ports based on the source MAC and VLAN. - balance-tcp - This is the preferred bonding mode. It offers traffic load balancing based on 5-tuple header fields. LACP must be enabled at both endpoints to use this mode. The aggregate link will fall back to default mode (active-passive) in the event of LACP negotiation failure. * lacp - active, passive or off * lacp-time - fast or slow. LACP negotiation time interval - 30 ms or 1 second
(string) Space-delimited list of bond:port mappings. The DPDK assigned ports will be added to their corresponding bond, which in turn will be put into the bridge as specified in data-port. . This option is supported only when enable-dpdk is true.
(string) Kernel userspace device driver to use for DPDK devices, valid values include: . vfio-pci uio_pci_generic . Only used when DPDK is enabled.
(int) Number of cores to allocate to DPDK per NUMA socket in deployed systems. . Only used when DPDK is enabled.
(int) Amount of hugepage memory in MB to allocate per NUMA socket in deployed systems. . Only used when DPDK is enabled.
(boolean) Enable DPDK fast userspace networking; this requires use of DPDK supported network interface drivers and must be used in conjunction with the data-port configuration option to configure each bridge with an appropriate DPDK enabled network device.
(boolean) Enable local Neutron DHCP and Metadata Agents. This is useful for deployments which do not include a neutron-gateway (do not require l3, lbaas or vpnaas services) and should only be used in-conjunction with flat or VLAN provider networks configurations.
(boolean) Enable SR-IOV NIC agent on deployed units; use with sriov-device-mappings to map SR-IOV devices to underlying provider networks. Enabling this option allows instances to be plugged into directly into SR-IOV VF devices connected to underlying provider networks alongside the default Open vSwitch networking options.
(string) Deprecated: Use bridge-mappings and data-port to create a network which can be used for external connectivity. You can call the network external and the bridge br-ex by convention, but neither is required A space-separated list of external ports to use for routing of instance traffic to the external public network. Valid values are either MAC addresses (in which case only MAC addresses for interfaces without an IP address already assigned will be used), or interfaces (eth0)
(string) Firewall driver to use to support use of security groups with instances; valid values include iptables_hybrid (default) and openvswitch (>= Mitaka on Ubuntu 16.04 or later).
(int) This option sets the maximum queue size for log entries. Can be used to avoid excessive memory consumption. WARNING: Should be NOT LESS than 25. (Available from Stein)
(string) This option allows setting a path for Firewall Group logs. A valid file system path must be provided. If this option is not provided Neutron will use syslog as a destination. (Available from Stein)
(int) Log entries are queued for writing to a log file when a packet rate exceeds the limit set by this option. Possible values: null (no rate limitation), integer values greater than 100. WARNING: Should be NOT LESS than 100, if set (if null logging will not be rate limited). (Available from Stein)
(string) Space-delimited list of Neutron flat network providers.
(int) Configure DHCP services to provide MTU configuration to instances within the cloud. This is useful in deployments where its not possible to increase MTU on switches and physical servers to accommodate the packet overhead of using GRE tunnels.
(string) IPFIX target wit the format "IP_Address:Port". This will enable IPFIX exporting on all OVS bridges to the target, including br-int and br-ext.
(string) The IP address and netmask of the OpenStack Data network (e.g., . This network will be used for tenant network traffic in overlay networks. . In order to support service zones spanning multiple network segments, a space-delimited list of a.b.c.d/x can be provided The address of the first network found to have an address configured will be used.
(boolean) Enable suppression of ARP responses that don't match an IP address that belongs to the port from which they originate. . Only supported in OpenStack Liberty or newer, which has the required minimum version of Open vSwitch. . NOTE: this feature is deprecated and removed in Openstack >= Ocata. As of that point the only way to disable protection will be via the port security extension (see LP 1691080 for info).
(string) Username used to access RabbitMQ queue
(string) RabbitMQ vhost
(int) This option sets the maximum queue size for log entries. Can be used to avoid excessive memory consumption. WARNING: Should be NOT LESS than 25.
(string) This option allows setting a path for Network Security Group logs. A valid file system path must be provided. If this option is not provided Neutron will use syslog as a destination. (Available from Queens)
(int) Log entries are queued for writing to a log file when a packet rate exceeds the limit set by this option. Possible values: null (no rate limitation), integer values greater than 100. WARNING: Should be NOT LESS than 100, if set (or, if null, logging will log unlimited.)
(string) Space-delimited list of SR-IOV device mappings with format . <provider>:<interface> . Multiple mappings can be provided, delimited by spaces.
(string) Number of VF's to configure each PF with; by default, each SR-IOV PF will be configured with the maximum number of VF's it can support. In the case sriov-device-mappings is set, only the devices in the mapping are configured. Either use a single integer to apply the same VF configuration to all detected SR-IOV devices or use a per-device configuration in the following format . <device>:<numvfs> . Multiple devices can be configured by providing multi values delimited by spaces. . NOTE: Changing this value will disrupt networking on all SR-IOV capable interfaces for blanket configuration or listed interfaces when per-device configuration is used.
(string) YAML-formatted associative array of sysctl key/value pairs to be set persistently e.g. '{ kernel.pid_max : 4194303 }'.
{ net.ipv4.neigh.default.gc_thresh1 : 128, net.ipv4.neigh.default.gc_thresh2 : 28672, net.ipv4.neigh.default.gc_thresh3 : 32768, net.ipv6.neigh.default.gc_thresh1 : 128, net.ipv6.neigh.default.gc_thresh2 : 28672, net.ipv6.neigh.default.gc_thresh3 : 32768, net.nf_conntrack_max : 1000000, net.netfilter.nf_conntrack_buckets : 204800, net.netfilter.nf_conntrack_max : 1000000 }
(boolean) This option controls a mode of the l3 agent when DVR is used. There are 2 modes 'dvr' (default) and dvr_snat (gateway mode). Neutron server (deployed by neutron-api charm) will schedule a network:router_centralized_snat port and a (centralized) snat namespace to dvr_snat mode agents only. If this option is enabled, all neutron-openvswitch nodes become candidates for being centralized snat nodes. If l3ha is enabled on neutron-api, relevant packages are also installed on every unit making them capable of hosting parts of an L3HA router. The min and max numbers of L3 agents per router need to be taken into account in this case (see max_l3_agents_per_router and min_l3_agents_per_router Neutron options). Practically, this option can be used to allow DVR routers (L3HA or not) to be scheduled without a requirement for a dedicated network node to host centralized SNAT. This is especially important if only floating IPs are used in the network design and SNAT traffic is minimal or non-existent.
(boolean) Setting this to True will allow supporting services to log to syslog.
(boolean) Enable verbose logging.
(string) Space-delimited list of <physical_network>:<vlan_min>:<vlan_max> or <physical_network> specifying physical_network names usable for VLAN provider and tenant networks, as well as ranges of VLAN tags on each available for allocation to tenant networks.
(float) The CPU core multiplier to use when configuring worker processes for this services e.g. metadata-agent. By default, the number of workers for each daemon is set to twice the number of CPU cores a service unit has. When deployed in a LXD container, this default value will be capped to 4 workers unless this configuration option is set.