OpenStack Networking: Neutron and OVN Explained

Compute and storage tend to get the attention when people talk about private clouds, but networking is where a cloud quietly succeeds or fails. In OpenStack, networking is the job of Neutron — the service that lets tenants create their own networks, routers, and security rules through an API, without ever filing a ticket with the network team. Behind Neutron, in modern deployments, sits OVN: the Open Virtual Network backend that turns those logical requests into actual packet-forwarding rules across the datacentre. Understanding how the two fit together is the key to understanding software-defined networking in OpenStack.

This article walks through what Neutron does, why OVN has become its default backend, and how a packet actually finds its way from one virtual machine to another across the fabric. The goal is a mental model that holds up whether you are designing a deployment or debugging one at two in the morning.

What Neutron actually provides

Neutron is OpenStack's networking-as-a-service layer. Its whole reason for existing is to give each tenant the ability to build the network topology they need, on demand, in isolation from every other tenant sharing the same physical hardware.

Through Neutron, a tenant can create a private network, attach virtual machines to it, add a router to reach other networks or the internet, allocate floating IPs, and define security groups that act as per-instance firewalls. Crucially, two tenants can both use the same private address range — say 10.0.0.0/24 — without ever colliding, because their traffic is fully isolated. That isolation and self-service is what makes OpenStack feel like a cloud rather than a pile of VMs sharing a flat LAN.

The ML2 plug-in model

Neutron itself is deliberately a thin abstraction. The real work of programming the network is delegated to a plug-in, through the Modular Layer 2 (ML2) framework. ML2 separates two concerns: the type of network (the mechanism used to isolate traffic, such as VLAN, VXLAN, or Geneve overlays) and the mechanism driver (the technology that actually implements the forwarding).

This pluggable design is why OpenStack networking has evolved over the years without rewriting the tenant-facing API. The same Neutron API call — create a network, create a port — can be backed by very different underlying technologies. For a long time the default mechanism driver was Open vSwitch with a set of agents. The current default in modern OpenStack is OVN, and the shift is worth understanding.

Why OVN became the default

The earlier Open vSwitch driver relied on a collection of Python agents running on every node — an L2 agent, an L3 agent for routing, a DHCP agent, a metadata agent — coordinating through Neutron and the message queue. It worked, but it was operationally heavy: many moving parts, agents that could fall out of sync, and routing that funnelled through dedicated network nodes that became bottlenecks and single points of failure.

OVN, developed within the Open vSwitch project, rethinks this. Instead of a swarm of Python agents, OVN provides a compact, purpose-built control plane written in C, with much of the intelligence — routing, DHCP, security rules — pushed down into Open vSwitch flows on each hypervisor. The result is fewer components, distributed routing without a central choke point, and a cleaner mapping from logical intent to actual flows. For most new deployments, OVN is simply the better engineered choice, which is why it is now the reference backend.

Inside the OVN architecture

OVN has a small number of well-defined pieces, and once they click into place the whole system makes sense.

The two databases

At the heart of OVN are two databases. The Northbound database holds the logical, intent-level description of the network: logical switches, logical routers, ports, and ACLs — essentially a direct translation of what Neutron asked for. The Southbound database holds the physical realisation: which hypervisor each port lives on, and the logical flows that implement the desired behaviour.

ovn-northd and the controllers

A daemon called ovn-northd sits between the two databases, continuously translating the logical Northbound model into the physical Southbound flows. On every hypervisor, an ovn-controller process reads the Southbound database and programs the local Open vSwitch instance accordingly. The chain is elegant: Neutron writes intent, ovn-northd compiles it, and each node's controller enforces it locally.

Following a packet across the fabric

Concepts stick better when you trace a real path. Imagine VM-A on hypervisor 1 sending a packet to VM-B on hypervisor 2, both on the same tenant network.

VM-A emits the packet to its virtual NIC, which connects to the local Open vSwitch bridge. The OVN flows there, programmed by ovn-controller, recognise the destination as a logical port that lives on hypervisor 2. Rather than sending the raw frame, OVS encapsulates it in a Geneve overlay tunnel — wrapping the tenant packet inside a header that carries it across the physical underlay network to hypervisor 2. On arrival, the receiving OVS strips the tunnel header, identifies the correct logical port, applies any security-group rules, and delivers the packet to VM-B. The two virtual machines behave as though they share a simple switch, while underneath, the fabric carried encapsulated traffic between physical hosts. Security groups and routing are applied right at the source and destination hosts, which is exactly why OVN avoids the central network-node bottleneck of the older model.

Overlays, underlays, and the leaf-spine fabric

That Geneve tunnel is the overlay; the physical network it rides on is the underlay. This separation is the single most important idea in modern datacentre networking. The underlay — typically a leaf-spine fabric of high-speed switches running a routed design — only needs to move packets between hypervisor IP addresses efficiently and reliably. It does not need to know anything about tenants, virtual networks, or which VM lives where.

All the tenant-specific complexity lives in the overlay, programmed by OVN. This is what lets a private cloud scale: you can add racks and hypervisors to the underlay without reconfiguring tenant networks, and tenants can spin up and tear down networks freely without anyone touching a physical switch. The overlay/underlay split is also why technologies like BGP EVPN/VXLAN at the fabric layer pair so naturally with OVN overlays above them.

Operating OVN networking in production

A few realities matter once this is carrying production traffic. Geneve encapsulation adds overhead, so jumbo frames on the underlay are worth configuring to avoid fragmentation. The OVN databases are important state and benefit from running in a clustered, highly available configuration. And distributed routing, while a major improvement, means troubleshooting shifts from inspecting a central network node to reasoning about flows across many hypervisors — good observability with Prometheus and Grafana pays for itself quickly here.

This is also where a managed platform earns its keep. At clouditiv we run OpenStack 2025.2 with Neutron and OVN as the networking backbone of a sovereign private cloud, on a leaf-spine fabric built with Arista switches, with the database clustering, overlay tuning, and monitoring handled as part of the service. Tenants get clean self-service networking; the considerable operational detail underneath is someone else's full-time job.

Bringing it together

The elegance of OpenStack networking is in the layering. Neutron gives tenants a simple, self-service API. ML2 keeps that API stable while the implementation underneath evolves. OVN compiles tenant intent into distributed flows and carries traffic over Geneve overlays. And a clean underlay fabric moves the encapsulated packets without ever needing to understand them. Once you can trace a packet from a virtual NIC, through an overlay tunnel, across the fabric, and into another VM, software-defined networking stops being a black box — and that understanding is what lets you design, scale, and trust a private cloud network.