SDN using OVN and OVS (Part 1)

OVN and OVS are opensource solutions to providing an SDN (Software Defined Network) that I have been using extensively lately for a live customer project. Having started out using LXD and Microcloud (inc. microovn) from the folks at Canonical, I wanted to share some of the learning I've built up given that many of the steps and overall solutions don't really take the time to explain what's happening under the hood.

Hopefully this is all accurate as it's taken from my lab but do please comment if you find inaccuracies!

Part One - Architecture and Overview

Let's start with the architecture. There's excellent documentation available on ovn.org and openvswitch.org, but I'll break down the core components here. I'll keep this as distribution-independent as possible, though my later posts on configuration will focus on SUSE.

Most SDNs I've worked with use databases and agents to manage the configuration of host servers participating in the SDN. OVN/OVS follows a similar approach, and the diagram below illustrates its major components.

ovn-northd and the Northbound / Southbound DBs

At the core of OVN is NorthD, officially labeled ovn-northd but also referred to as ovn-central in Ubuntu and LXD/Microcloud. This is essentially an SDN controller service and should not be confused with the similarly named ovn-controller service, which I will discuss shortly.

ovn-northd contains two databases: the Northbound DB, where you or a CMS (Cloud Management System) like OpenStack writes the desired state of your SDN configuration, and the Southbound DB, which stores the interpreted set of OpenFlow rules to be applied to hosts running ovn-controller.

Between these databases is ovn-northd, a daemon that converts the human-readable configuration in the Northbound DB into OpenFlow rules in the Southbound DB.

It's important to note that this is a one-way process. The data flows from the top down and not the other way around, for the most part.

This setup, using databases, can be seen as a 'state-based' approach to configuration management. Instead of relying on messaging services to send updates, everything is committed to a database. Agents like ovn-controller then work to achieve a consistent state within their domain. This approach is reliable and should meet operational demands.

ovn-northd can theoretically run on any server(s) in the environment, including virtualization hosts, dedicated servers (preferable in some scenarios), or containers running on Docker/Kubernetes. The key factors are ensuring high availability (three hosts) and carefully managing security and access to both the Northbound and Southbound DBs.

ovn-controller (ovn-host)

Running on each virtualization host in your environment is ovn-controller. I'm fairly sure this was once called ovn-host (definitely is in Ubuntu), but in the current iteration of my SUSE lab, it's called ovn-controller. This is confusing because it's not the SDN controller.

ovn-controller is installed on each virtualization host and is responsible for connecting to the Southbound DB to retrieve the OpenFlow configuration and then applying it to the local instance of Open vSwitch.

It really is as simple as that. There's essentially nothing to configure except how to connect to the Southbound DB. It doesn't manage any other hosts and can't be installed centrally, so it doesn't need much further explanation.

openvswitch

From a virtualization perspective, this is where all the magic happens. Open vSwitch is a software-defined switch that allows data center operators to virtualize several important network functions.

These include: Layer-2 network overlays that enable the creation of virtual networks, each decoupled from the underlying physical topology of switches and routers in the data center; Layer-3 routers that support interconnecting virtual networks and providing connectivity into/out of the SDN; Load balancers (basic Layer-4) to support application publishing; and various other security and policy features that I won't delve into in detail.

To familiarize yourself with some of these concepts, it's worth looking into topics such as VXLAN and network overlay technologies applied in SDN environments.

Open vSwitch supports both VXLAN and Geneve for its encapsulation protocols. In layman's terms, virtual networks defined in OVN are encapsulated as they move around the physical network. Essentially, two VMs connected to the same virtual network overlay, but running on different hosts, potentially in different parts of the data center, on separate switches, etc., are oblivious to the underlying network topology. All they see is the Layer-2 network defined in ovn-northd and implemented in Open vSwitch by ovn-controller, as shown in the diagram below.

When VMs communicate, the virtualization hosts use Open vSwitch to encapsulate the traffic, allowing it to be routed around the data center, and potentially even across WAN connections (with caution), before being delivered to the destination.

Rules in the Open vSwitch Flow Tables enable the virtualization hosts to identify which host is running the target of a flow or packet, and then use the underlying layer-3 network to route it accordingly.

This is a simplified explanation of some complex topics, but it should give you an idea of how overlay and underlay networks interact.

Eventually, traffic needs to exit the overlay and be routed independently of the SDN. This is where OVN routers, routes, NAT, and load balancers come into play, which I'll cover in more detail later in the series.

Wrapping up Part One

That should give a high-level overview of the major components involved in the OVS/OVN solution. In the next part, I will focus on some of the physical aspects of the design, which I feel are often underserved in discussions about this solution.