OVS and OVN Explained: The Networking Stack Behind OpenStack | OpenStack Blog | Open Infrastructure Foundation

The OpenStack Blog<br>Everything in & around OpenStack in written words.

OVS and OVN Explained: The Networking Stack Behind OpenStack

Thzuska Pico

June 29, 2026

Open vSwitch gave us a programmable dataplane. Open Virtual Network added a control plane. Together they power Neutron in most OpenStack clouds. This tutorial explains the architecture, compares OVS vs. OVN, and shows how to trace a packet from instance to instance in OpenStack.

You’ve deployed two instances on different compute nodes. Same tenant. Same network. They can’t ping each other. Security groups allow ICMP. The physical network is up. Sound familiar? In OpenStack Neutron with OVN, most cross-host packet losses are not bugs – they are logical flow denials waiting to be read.

When your OpenStack instances can ping each other on the same compute node but go silent across hypervisors, you’re dealing with a networking failure that spans two layers: the dataplane and the control plane. Understanding how OVS and OVN operate across those layers turns a frustrating mystery into a solvable problem — because that’s where most OpenStack networking issues actually hide.

What is SDN? (Software-Defined Networking)

Before we dive into OVS and OVN, it helps to understand why these technologies exist in the first place.

Traditional networking works like this: each switch and router has its own control plane deciding where packets go and data plane forwarding packets. To change how traffic flows, you reconfigure each device individually – often by using protocols like NETCONF or RESTCONF. This approach works until you need to scale. In a cloud environment with hundreds of hypervisors and thousands of VMs, manual per-device configuration becomes impossible.

Software-Defined Networking (SDN) changes the game by separating the control plane from the data plane. A central SDN controller decides where traffic should go, and the underlying switches and routers simply follow those instructions. This separation brings three major benefits to cloud environments:

Benefit Why it matters in cloud environmentsCentralized control You manage network policy centrally, not per-switch Programmability Networks adapt dynamically as VMs are created, migrated, or deletedAutomation No manual switch configuration

OVS and OVN are SDN technologies. OVS provides the high-performance data plane on each hypervisor. OVN provides the distributed control plane that tells OVS what to do. Together, they implement SDN for OpenStack Neutron.

What is Open vSwitch?

Open vSwitch (OVS) is an open source virtual switch that speaks OpenFlow, supports tunnel encapsulation (VXLAN, GRE, Geneve), and integrates with KVM, Xen, and other virtualization platforms. Unlike basic Linux bridges, OVS was built for large data center environments: it handles high throughput via a kernel module, gives you visibility with sFlow/NetFlow, and lets you apply QoS per flow.

OVS became the default switch for OpenStack Neutron back in 2012. But it had a limitation: it exposed low-level OpenFlow rules, not logical network abstractions like "virtual router" or "security group". Managing OVS directly at scale meant writing complex flows via CLI as Neutron OVS Agent did back in the days. And that was the point where OVN came in.

OVN – The Control Plane OVS was Missing

Open Virtual Network (OVN) started as part of the OVS project in 2013 and reached maturity by 2016. OVN does not replace OVS. It sits on top of it, providing a logical networking model – virtual switches, routers, ports and ACLs that are translated automatically into OpenFlow rules inside OVS.

Think of it this way:

OVS = the worker who moves packets<br>OVN = the manager who decides where packets should go and remembers the network topology

Today, OVN is the default Neutron driver in most OpenStack distributions. When you create a network, subnet, router, or security group in OpenStack, Neutron calls the OVN driver. That driver writes entries into OVN’s Southbound Database. OVN then programs every OVS instance on every hypervisor with the required flows.

OVS vs. OVN – Comparison Table

Aspect OVS alone OVS + OVN Control planeNone (you configure flows manually or via OpenFlow controller)Built-in distributed control planeLogical abstractionsNo – you work with ports, flows, tunnelsYes – logical switches, routers, ports, ACLsOpenStack integrationMapping from Neutron to OVS flowsNative driver (Neutron ML2/OVN) with automationScalabilityFlow table explosion in large environmentsSouthbound DB aggregates topology allowing larger scaleTypical use caseStandalone SDN dataplane or simple labs, old releases of OpenStack, ProxmoxOpenStack from Ussuri release, Kubernetes (OVN-K8s)Learning curveLow for basic switching, steep for OpenFlowModerate – you think in logical networks, not flows

Bottom line : OVS standalone can be used for small labs or test...