SDN using OVN and OVS (Part 5)

Welcome to part five of what was originally a four-part series, now extended to six parts.

In this section, we will focus entirely on uplink configuration, using the following scenario to guide our walkthrough.

To connect the logical router (lgr-external) to the outside world, we need to examine the switch ls-external closely. This switch contains key elements that facilitate the external connection or uplink for VMs connected to ls-internal. Understanding these elements is crucial for establishing the connection.

External (UPLINK) Logical Switch

The two ports, 'localnet' and 'router', serve distinct purposes: 'localnet' connects to an interface in the host chassis, while 'router' is used for logical router connections. The output from ovn-nbctl list logical_switch for ls-external shows these ports referenced by their UUIDs (b00.. and b12..).

Here is the output from ovn-nbctl list logical_switch_ports.

The second port, ln-provider, is our localnet port with the option "network_name=UPLINK" set. It also has 'addresses' set to "unknown". This configuration instructs OVS to create a Patch Port between br-int and whatever UPLINK is mapped to under "ovn-bridge-mappings" at the appropriate time.

The 'addresses' setting is "unknown" because the IP addressing will be provided by lgr-external, which will communicate directly with the device connected to the provider bridge.

The Provider Bridge

The provider bridge is the second bridge needed in Open vSwitch (OVS). To recap, the integration bridge (br-int) is created by the ovn-controller, and all virtual machines (VMs), routers, and other network elements are connected to it. The provider bridge (named br-provider in my lab) connects the integration bridge to the physical network, allowing traffic to flow between the virtual and physical networks.

In the example above we've created br-provider (using ovs-vsctl) and attached eth1 to it.

eth1 is the Provider network and eth0 in this lab would be my Management network (see Part Two). eth1 therefor is unnumbered (not configured with any IP address), and eth0 numbered (with an IP) so we can get to the internet and do things like update our host chassis. Our VMs are going to be communicating over Provider.

To connect ls-external to br-provider we need to tell OVS how to make the right connections.

ovn-bridge-mappings

ovn-bridge-mappings is an 'external_id' registered in each openvswitch Chassis that maps a bridge network reference in OVN to an interface in the chassis used for the uplink. That will probably become a bit more obvious as we continue below, but here is an extract from running ovs-vsctl list open_vswitch in my lab to show that part of the configuration.

Under 'external_ids' you can see ovn-bridge-mappings="UPLINK:br-provider" that maps the bridge reference name 'UPLINK' to our OVS bridge, br-provider. This allows each Chassis to define the name of the physical uplink and map it to a consistent reference in OVN.

Patch Port

Setting the port type to 'localnet' and providing a valid network_name option triggers OVS to create a Patch Port between ls-external's UPLINK port (which is technically connected to br-int) and a port on br-provider.

Here's that all in action, starting with creating the 2 switches and the router.

Next lets add the localnet port to ls-external, excuse the typo in the example.

Next we connect lgr-external to ls-external.

To complete the connection we now need to schedule the localnet port for lgr-external on a Chassis. To do this we either 'redirect' that port to the Chassis by running something like ovn-nbctl set logical_router_port lgr-external-povider options:redirect-chassis=66758773-283d-4c37-afe7-1128469959d3 or we set priority values for one or more Chassis for high availability.

In my case here's the output from my lab of ovn-nbctl lrp-set-gateway-chassis lgr-external-provider 66758773-283d-4c37-afe7-1128469959d3 10 (66758773-... is my Chassis UUID in the lab)

When I run ovs-vsctl show on my Chassis now, you see that the port "patch-br-int-to-ln-provider" has been created automatically by OVS. In an HA setup you would only find this port patch created on the active chassis and it will move as the port is rescheduled according to the priority setting.

Wrapping up

And that really is about it. In the above example any VMs connected to ls-internal will be able to use lgr-external as their gateway router. lgr-external will have an IP address on the provider network as 172.16.0.1 and so a pathping or something similar will show that as a 'bump in the wire' or 'hop' to wherever your destination is.

Parts 1-5 of this series have gone into a lot of detail, part 6 will string it all together in a working lab configuration.