Let us now turn our attention to the integration of OVN with OpenStack. The main element of this integration is the mapping of OpenStack Neutron objects to that of OVN. We will use DevStack to demonstrate different OpenStack operations and then show the corresponding OVN entities.
We will now show you how to install and use OVN using DevStack. OVN has been extensively tested on Ubuntu 14.04 so we recommend that as the version to try with these steps:
- The first step is to check out DevStack and OVN from GitHub.
- Copy the sample
local.conffrom OVN to DevStack. If you view thelocal.conffile you will notice that the Neutron L2 agent (q-agt) is disabled. This is because OVN does not rely on the Neutron L2 Agent. It directly programs Open vSwitch using OpenFlow and OVSDB.
- Run the
stack.shcommand from DevStack to set up your DevStack environment../stack.sh - Once DevStack runs successfully, we will open the contents of the Neutron ML2 configuration file to see that OVN is the ML2 driver. Note that OVN uses Geneve as the default tunneling/encapsulation technology to provide network segmentation. The ML2 configuration file is located at
/etc/neutron/plugins/ml2/ml2_conf.ini. The relevant snippet related to OVN ML2 configuration is shown here.
This completes the setup of OVN with OpenStack using DevStack. We will now focus on the mapping of Neutron objects to that of OVN.
As mentioned earlier, the OVN Northbound API receive, incoming requests from the OVN Neutron ML2 driver and translates the Neutron data model to the OVN data model. We will now see the objects in the OVN data model and how they are mapped to Neutron objects.
In a DevStack environment a few Neutron networks and a router is created automatically as part of DevStack setup, as seen from the output of neutron net-list and neutron router-list commands.
In order to view the OVN object, we will start with a simple ovn-nbctl show command that shows the summary of the entire OVN data model.
As you can see, similar to the Neutron command output, the OVN show command displays two switches (networks) and one router.
The Neutron network object is mapped to a logical switch object in OVN. The idea of a logical switch is to provide a unified layer 2 domain for VM instances, containers, and even legacy/physical devices.
To demonstrate this mapping, we will first create a network in Neutron using the CLI command.
Next, we will execute the OVN command for listing logical switches.
The ovn-nbctl ls-list displays all the logical switches in the OVN controller. The output shows two parameters in each row. The first one is the UUID assigned to the logical switch within OVN. The text in parentheses is the name of the logical switch. The name is derived by concatenating neutron- to the UUID of the Neutron network.
The Neutron subnet object is mapped to DHCP options in OVN. You can create a subnet using Neutron CLI and then using the ovn-nbctl command, as shown in the following example, to view the mapping.
The ovn-nbctl dhcp-options-list shows all the subnet mappings. You can use the dhcp-options-get-options sub-command to view the details of a specific subnet mapping.
The port object in Neutron is mapped to either a switch port or a router port in OVN. In Neutron you can use the device_owner attribute to distinguish between a network port versus a router port. In OVN they are two different port objects. This distinction is useful from a management perspective.
We will create a Neutron port and then show the OVN commands to view the corresponding OVN object.
If we execute the ovn-nbctl show command, we can see that a logical switch and a switch port corresponding to the Neutron network and port are displayed. We can see that the port has been assigned an IP address of 20.20.20.7.
The highlighted section also shows the MAC address of the port. You can explore the ovn-nbctl lsp-list and related commands to view OVN port information.
We have looked at the three important Neutron objects and their OVN mappings. The other important entities are routers and security groups.
The Neutron router is mapped to a logical router in OVN. This is a simple and direct mapping. You can use ovn-nbctl lr-list and related commands for the OVN logical router.
The security group is the next most important entity. In Neutron, users can create security groups and the corresponding rules independently and then apply them to VM at the time of instantiation. The corresponding port stores the security group reference.
In OVN security groups are mapped to an Access Control List (ACL) object and it has a direct relationship with the port as well as the logical switch. This makes it a more cohesive mapping when compared to Neutron.
OVN aims to be the next level replacement for the OVS plugin in OpenStack Neutron. By providing much more logical network constructs around Open vSwitch, OVN is simplifying the integration for the most widely deployed virtual switch. The project is most easily tested in a DevStack environment but full Linux packages are available already. We hope the introduction provided here will help readers explore this highly anticipated networking project within OpenStack.