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 \
    interface-bridge-mappings='00:00:5e:00:00:42:br-provider \
                               00:00:5e:00:00:51:br-provider'
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'

Appendix O: Open Virtual Network (OVN)

Appendix O: Open Virtual Network (OVN)¶

Overview¶

Deployment¶

Configuration¶

Internal DNS resolution¶

External connectivity¶

Usage¶

Information queries¶

OVSDB Cluster status¶

Querying DBs¶

Data plane flow tracing¶

charm-deployment-guide

Page Contents