charm-deployment-guide/deploy-guide/source/app-ovn.rst

Appendix O: Open Virtual Network (OVN)

Overview

As of the 19.10 charm release, with OpenStack Train or later, support for integration with Open Virtual Network (OVN) is available.

OVN charms:

• neutron-api-plugin-ovn
• ovn-central
• ovn-chassis
• ovn-dedicated-chassis

Warning

The OVN charms are considered preview charms, still in development.

Deployment

OVN makes use of Public Key Infrastructure (PKI) to authenticate and authorize control plane communication. The charm requires a Certificate Authority to be present in the model as represented by the certificates relation.

Follow the instructions for deployment and configuration of Vault in Appendix E.

OVN can then be deployed:

juju config neutron-api manage-neutron-plugin-legacy-mode=false

juju deploy cs:~openstack-charmers/neutron-api-plugin-ovn
juju deploy cs:~openstack-charmers/ovn-central -n 3 --config source=cloud:bionic-train
juju deploy cs:~openstack-charmers/ovn-chassis

juju add-relation neutron-api-plugin-ovn:certificates vault:certificates
juju add-relation neutron-api-plugin-ovn:neutron-plugin \
    neutron-api:neutron-plugin-api-subordinate
juju add-relation neutron-api-plugin-ovn:ovsdb-cms ovn-central:ovsdb-cms
juju add-relation ovn-central:certificates vault:certificates
juju add-relation ovn-chassis:ovsdb ovn-central:ovsdb
juju add-relation ovn-chassis:certificates vault:certificates
juju add-relation ovn-chassis:nova-compute nova-compute:neutron-plugin

The OVN components used for the data plane is deployed by the ovn-chassis subordinate charm. A subordinate charm is deployed together with a principle charm, nova-compute in the example above.

If you require a dedicated software gateway you may deploy the data plane components as a principle charm through the use of the ovn-dedicated-chassis charm.

Note

You can also make use of an OVN overlay bundle in conjunction with the openstack base bundle.

Configuration

OVN integrates with OpenStack through an ML2 driver as provided by networking-ovn. General Neutron configuration is still done through the neutron-api charm, and the subset of configuration specific to OVN is done through the neutron-api-plugin-ovn charm.

Internal DNS resolution

OVN supports Neutron internal DNS resolution. To configure this:

juju config neutron-api enable-ml2-dns=true
juju config neutron-api dns-domain=openstack.example.
juju config neutron-api-plugin-api dns-servers="1.1.1.1 8.8.8.8"

Note

The value for the dns-domain configuration option must not be set to 'openstack.local.' as that will effectively disable the feature.

It is also important to end the string with a '.' (dot).

When you set enable-ml2-dns to 'true' and set a value for dns-domain, Neutron will add details such as instance name and DNS domain name to each individual Neutron port associated with instances. networking-ovn will then read instance name and DNS domain name from ports and populate the DNS table of the Northbound and Southbound databases:

# ovn-sbctl list DNS
_uuid               : 2e149fa8-d27f-4106-99f5-a08f60c443bf
datapaths           : [b25ed99a-89f1-49cc-be51-d215aa6fb073]
external_ids        : {dns_id="4c79807e-0755-4d17-b4bc-eb57b93bf78d"}

records             : {"c-1"="192.0.2.239", "c-1.openstack.example"="192.0.2.239"}

On the chassis, OVN creates flow rules to redirect UDP port 53 packets (DNS) to the local ovn-controller process:

cookie=0xdeaffed, duration=77.575s, table=22, n_packets=0, n_bytes=0, idle_age=77, priority=100,udp6,metadata=0x2,tp_dst=53 actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,23)
cookie=0xdeaffed, duration=77.570s, table=22, n_packets=0, n_bytes=0, idle_age=77, priority=100,udp,metadata=0x2,tp_dst=53 actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,23)

The local ovn-controller process then decides if it should respond to the DNS query directly or if it needs to be forwarded to the real DNS server.

External connectivity

Interface and network to bridge mapping is done through the ovn-chassis charm.

Networks for use with external Layer3 connectivity should have mappings on chassis located in the vicinity of the datacenter border gateways. Having two or more chassis with mappings for a Layer3 network will have OVN automatically configure highly available routers with liveness detection provided by the Bidirectional Forwarding Detection (BFD) protocol.

Chassis without direct external mapping to a external Layer3 network will forward traffic through a tunnel to one of the chassis acting as a gateway for that network.

Note

It is not necessary nor recommended to add mapping for external Layer3 networks to all chassis. Doing so will create a scaling problem at the physical network layer that needs to be resolved with globally shared Layer2 (does not scale) or tunneling at the top-of-rack switch layer (adds complexity) and is generally not a recommended configuration.

Example configuration:

juju config neutron-api flat-network-providers=physnet1
juju config ovn-chassis ovn-bridge-mappings=physnet1:br-provider
juju config ovn-chassis \
    bridge-interface-mappings='br-provider:00:00:5e:00:00:42 \
                               br-provider:00:00:5e:00:00:51'
openstack network create --external --share --provider-network-type flat \
                         --provider-physical-network physnet1 ext-net
openstack subnet create --network ext-net \
                        --subnet-range 192.0.2.0/24 \
                        --no-dhcp --gateway 192.0.2.1 \
                        ext

Networks for use with external Layer2 connectivity should have mappings present on all chassis with potential to host the consuming payload.

Usage

Create networks, routers and subnets through the OpenStack API or CLI as you normally would.

The networking-ovn driver will translate the OpenStack network constructs into high level logical rules in the OVN Northbound database.

The ovn-northd daemon in turn translates this into data in the Southbound database.

The local ovn-controller daemon on each chassis consumes these rules and programs flows in the local Open vSwitch database.

Information queries

Note

Future versions of the charms will provide information-gathering in the form of actions and/or through updates to the juju status command.

OVSDB Cluster status

juju run --application ovn-central 'ovs-appctl -t \
    /var/run/openvswitch/ovnnb_db.ctl cluster/status OVN_Northbound'
juju run --application ovn-central 'ovs-appctl -t \
    /var/run/openvswitch/ovnsb_db.ctl cluster/status OVN_Southbound'

Querying DBs

juju run --unit ovn-central/leader 'ovn-nbctl show'
juju run --unit ovn-central/leader 'ovn-sbctl show'
juju run --unit ovn-central/leader 'ovn-sbctl lflow-list'

Data plane flow tracing

juju run --unit ovn-chassis/1 'ovs-vsctl show'
juju run --unit ovn-chassis/1 'ovs-ofctl dump-flows br-int'
juju run --unit ovn-chassis/1 'sudo ovs-appctl -t ovs-vswitchd \
    ofproto/trace br-provider \
    in_port=enp3s0f0,icmp,nw_src=192.0.2.1,nw_dst=192.0.2.100'

State of OVN Charm development

One of the main drivers for this enablement work is the prospect of being able to hardware-offload everything. This is possible due to how OVN programs everything in Open vSwitch with OpenFlow rules. This in turn provides a uniform way of programming the hardware forwarding tables of supported NICs.

Another driver for it is upstream Neutron changes and during the Ussuri cycle the upstream Neutron project will switch to promote ML2+OVN as its default reference implementation, replacing the traditional ML2+OVS and ML2+OVS+DVR implementations. See the Toward Convergence of ML2+OVS+DVR and OVN Neutron specification for more information.

Hardware-offloading is a prerequisite for effective handling of workloads with high bandwidth consumption.

OVN also provides a more flexible way of configuring external Layer3 networking as OVN does not require every node (Chassis in OVN terminology) in a deployment to have direct external connectivity. This plays nicely with Layer3-only datacenter fabrics (RFC 7938).

East/West traffic is distributed by default. North/South traffic is highly available by default. Liveness detection is done using the Bidirectional Forwarding Detection (BFD) protocol.

Known feature gaps at this point in time:

• Validation of LBaaS has been done, but did unfortunately not make it into the 20.02 OpenStack Charms release. Experimental support for using OVN as transport for communication between Octavia units and its Amphorae as well as support for the native OVN provider driver for Octavia is available in the development version of Octavia (cs:~openstack-charmers-next/octavia).
• No validation has been done with DPDK, SR-IOV or hardware-offloading in the charms.
• Only limited validation has been done with other Neutron extensions, and it may be possible to configure unsupported combinations of features with undefined results.