OpenStack SDN in 2026: Neutron, OVN and When You Still Need an External Controller

OpenStack SDN means Neutron: the networking service that turns API calls for networks, routers, floating IPs and security groups into switch and router configuration on every host. In 2026 most installers and vendor distributions deploy Neutron's ML2/OVN driver by default, where OVN acts as the SDN controller and Open vSwitch moves the packets, so distributed routing, overlays and L3 high availability come without a separate controller. An external controller is now a deliberate choice, made because you already own a Cisco ACI fabric, want Calico's routed model or run a Contrail estate that lives on as OpenSDN. Several controllers that older guides still recommend are deprecated or retired.

Where things stand in October 2026:

• ML2/OVN is the default in DevStack and OpenStack-Ansible. Kolla-Ansible still defaults to Open vSwitch, so decide before your first deploy.
• The Linux bridge driver was removed in 2025.1 Epoxy. ML2/OVS is still maintained and has no deprecation notice.
• OpenDaylight's Neutron driver was deprecated in 2023.2, Tungsten Fabric was archived in 2023 and continues as the OpenSDN fork, and Dragonflow was retired in 2020.
• BGP is now built into Neutron's OVN driver, with FRR on each node doing the actual peering.
• Current versions: OpenStack 2026.2 Hibiscus (30 September 2026) with Neutron 29.0.0, OVN 26.03 LTS and Open vSwitch 4.0.0.

What is SDN in OpenStack?

Software-defined networking (SDN) separates the control plane, which decides where traffic goes, from the data plane, which forwards it, and lets software set those decisions through an API. In OpenStack that API is Neutron. Underneath it sits ML2, the Modular Layer 2 plugin, which splits the work in two:

• Type drivers define what a network is built from: flat, vlan, vxlan, gre or geneve.
• Mechanism drivers program the hosts: ovn, openvswitch, sriovnicswitch for SR-IOV, or a vendor driver that hands the work to an external controller.

Routers, BGP and VPN arrive as service plugins on top, while load balancing moved out to Octavia, covered in our guide to Octavia load balancing in OpenStack. That is why "which SDN does OpenStack use?" has more than one answer: Neutron is the API every user sees, and the mechanism driver decides who programs the switches.

The SDN stack, layer by layer

On an ML2/OVN cloud a new router passes through five layers, and knowing them tells you where to look when a ping fails:

1. The Neutron API server accepts the call and stores it in the Neutron database.
2. The OVN mechanism driver writes logical switches, routers and ports into the OVN Northbound database.
3. ovn-northd compiles them into logical flows in the Southbound database.
4. ovn-controller on every compute and gateway node reads those flows and programs the local Open vSwitch.
5. Open vSwitch forwards the packets and tunnels them between hosts with Geneve.

Until Ussuri (2020) the OVN driver lived in a separate networking-ovn repository. It was merged into Neutron 16.0.0 and the old repository retired, so any guide that tells you to install networking-ovn predates 2020. The first version of this page made the same mistake, which is one reason it was rewritten.

What SDN controller does OpenStack use?

By default, OVN, which is developed next to Open vSwitch rather than inside OpenStack. Its current long-term support series is 26.03 and its newest release 26.09, according to the OVN release page, and Open vSwitch reached 4.0.0 on 17 August 2026. An OpenStack blog explainer on OVS and OVN (29 June 2026) says ML2/OVN had become the default in most deployment tools and vendor products by 2023.1 Antelope, citing ML2/OVS's scaling limits and its full-sync problem. What you get depends on the installer:

• DevStack uses OVN, according to the Neutron documentation.
• OpenStack-Ansible documents ML2/OVN as its default since 2023.1 Antelope.
• Kolla-Ansible still uses openvswitch unless you set neutron_plugin_agent: "ovn" in /etc/kolla/globals.yml.

That last one catches people. Moving a live cloud from ML2/OVS to ML2/OVN later is a planned migration with a maintenance window, not a config flag, so pick on day one.

Check what your own cloud runs

If you inherited a cloud and nobody remembers, the agent list answers it:

# as the admin user
openstack network agent list -c "Agent Type" -c Host -c Alive

On ML2/OVN you will see OVN Controller agents, OVN Controller Gateway agents on the nodes that carry router traffic and OVN metadata or Neutron agents, but no L3 or DHCP agents. On ML2/OVS the list shows Open vSwitch, L3, DHCP and Metadata agents instead.

OVN vs OVS in OpenStack: is ML2/OVS finished?

No, and the names confuse people because both drivers run Open vSwitch on the hosts. The difference is the control plane: ML2/OVS uses Neutron's own agents, which talk to the server over the message queue, while ML2/OVN replaces them with OVN's databases and ovn-controller. ML2/OVS is still maintained; 2026.1 even added a trunk_enabled option to its agent, and no release note from 2025.1 to 2026.2 deprecates it. What did go is Linux bridge, removed in Neutron 26.0.0 (2025.1 Epoxy) with advice to move to OVS or, preferably, OVN before upgrading.

Read the Neutron page listing ML2/OVN gaps before you migrate. Instances' DHCP traffic must be allowed by their security group rules, since OVN does not add the automatic exception ML2/OVS does, and OVN's built-in DNS answers only UDP queries without EDNS. There is no IPv6 NDP proxy, neutron-metering-agent needs the L3 agent, floating IP port forwarding breaks when VLAN or flat networks are attached to a router as internal networks with distributed floating IPs enabled, and QoS packet-rate rules are missing. If none of that touches you, choose OVN.

Status of every OpenStack SDN controller in 2026

Search for "openstack sdn controller" and a 2018 OpenDaylight deployment page and a Dragonflow architecture page still sit near the top, neither mentioning that its project is gone. Here is where each option stands:

OpenDaylight: alive, just not for OpenStack

OpenDaylight itself is fine: Chromium went GA on 29 July 2026, and the managed release still covers NETCONF, OpenFlow, OVSDB, BGP-PCEP and TransportPCE. The OpenStack half is what disappeared. NetVirt and Neutron Northbound, which made ODL a Neutron backend, are not in the current managed release, and the Neutron driver, networking-odl, was deprecated in the 2023.2 Bobcat cycle with no maintainers left and CI stuck on the old ODL Sodium release. Its last commit is dated 22 June 2023, and Kolla-Ansible had already dropped ODL in Ussuri; the kolla page that still ranks was last updated in November 2018. If someone proposes ODL for a new cloud, ask who maintains the driver. Upstream, nobody does.

Tungsten Fabric became OpenSDN

Tungsten Fabric, the open-source form of Juniper's Contrail, paired a centralised controller with a vRouter on each compute node and spoke BGP and EVPN to physical routers, which carriers liked. According to OpenSDN's account, LF Networking shut it down in summer 2023 after its technical steering committee, mostly Juniper employees, voted to archive it. OpenSDN is the community fork. Its 24.1 release (27 August 2024) was the first it called production-ready and supports OpenStack up to 2023.2 Bobcat; we found no later release, so confirm support before planning around Gazpacho or Hibiscus. Mirantis now documents it in MOSK as "OpenSDN, formerly Tungsten Fabric", and Juniper has belonged to HPE since 2 July 2025.

Calico: routing instead of overlays

Calico has no tunnels. Each compute host routes its own VMs' addresses and announces them with BIRD over BGP, the Felix agent enforces policy, and a Neutron driver keeps state in etcd. Tigera's Calico 3.33 requirements page says active support and testing is with 2024.1 Caracal, with Gazpacho next. It suits clouds where every VM address should be visible to the physical network, but it is a different model from overlay Neutron, so test the API calls your users rely on first.

Dragonflow and MidoNet: retired, whatever the search results say

Dragonflow ran its control logic on every compute host for local routing and DHCP. The idea was sound, and OVN ended up delivering it. The Dragonflow repository now says the project is no longer maintained, with the retirement commit dated 23 June 2020. MidoNet's Neutron plugin carries the same notice, last touched in July 2021.

Vendor fabrics: Cisco ACI, NSX and the rest

Cisco's APIC OpenStack plug-in 6.1(5), released on 25 November 2025, added Red Hat OpenStack Services on OpenShift 18, which is based on upstream 2023.1 Antelope. That lag is typical, because vendor plug-ins follow commercial distributions, so check the support matrix against your planned release. NSX now belongs to Broadcom; if VMware licensing pushed you towards OpenStack, see why teams migrate from VMware to OpenStack.

When do you need an external SDN controller, and when is OVN enough?

An external controller once bought you distributed routing, scale and BGP. OVN now does all three in-tree, so what a controller still buys is integration with something you already own. Our rule of thumb:

How does BGP work in OpenStack now?

There are three ways to get cloud prefixes into your routers.

The oldest is neutron-dynamic-routing, a BGP speaker that uses only the os-ken driver, advertises project network prefixes and floating IP host routes over IPv4 or IPv6, and still ships through 2026.2. Its documentation is written around the L3 agent and DVR.

Then came ovn-bgp-agent, which runs on each node and exposes VM and floating IP addresses through kernel routing and FRR, with drivers for the Southbound database, the Northbound database, EVPN and stretched L2. It still has 2026.2 release notes, and we found no deprecation notice.

The new path is BGP inside the Neutron OVN driver, listed in the 2026.1 Gazpacho release highlights and designed to match ovn-bgp-agent without a BGP agent on the compute nodes. An ovn-bgp service plugin in neutron-server writes the BGP topology into the Northbound database, and an extension of the OVN Neutron agent programs each node. Neither part talks BGP: the Neutron OVN BGP documentation says FRR or a similar suite must run on every node to peer with your leaf switches. It targets spine-and-leaf fabrics where each rack is its own L3 domain, and once it is enabled, provider networks must be flat: VLAN provider networks are rejected, while Geneve project networks are unaffected. Neutron 29.0.0 (2026.2) added route leaking: set leak_routes on a Geneve subnet behind a router with an external gateway, and FRR advertises its CIDR. The known catch is that addresses from every subnet on that network then go out as host routes too.

Underneath, OVN learned to route for itself: 25.03 added route exchange with the kernel, 25.09 added EVPN, and 26.03 made EVPN stable and added IPv6 for overlay and underlay. A 2026.2 Neutron spec for EVPN Type-5 routes builds on that, but it did not land in 2026.2.

Our take: on a new spine-and-leaf build, start with the in-tree plugin and FRR, since it removes one agent from every node. If ovn-bgp-agent already works for you, nothing forces a move this year.

DVR, L3 HA and IPv6 under OVN

DVR, distributed virtual routing, belongs to ML2/OVS: L3 agents on every compute node, optionally paired with VRRP so SNAT fails over between network nodes. OVN makes most of that unnecessary. Its routers are distributed by design, L3 high availability needs no flags, gateway nodes are watched with BFD over the Geneve tunnels, and with distributed floating IPs enabled a VM's floating IP traffic leaves through its own host. Recent releases tuned this area: 2026.1 added BFD timing options and north/south routing for SR-IOV and bare metal ports, and 2026.2 moved the OVN L3 scheduler to HA chassis groups and made ovn_router_indirect_snat default to true.

IPv6 needs its own plan. Dibbler-based prefix delegation was removed from the L3 agent in 2025.1, leaving no in-tree driver for it, and OVN has no NDP proxy. What works is the plain design: give each project a /64 from your own allocation through a subnet pool and announce it with BGP.

Performance: DPDK, SR-IOV and hardware offload

Start with kernel Open vSwitch and measure. These three exist for workloads, usually virtual network functions, that need packet rates the kernel path cannot reach, and each costs something.

• OVS-DPDK moves the switch into user space with polling cores. Neutron supports it only with libvirt on KVM/QEMU, every instance needs huge pages, and vhost-user reconnect is not yet in the ML2/OVN driver, so guests do not reattach on their own if OVS restarts.
• SR-IOV hands the VM a slice of the physical NIC through the sriovnicswitch driver, with port types direct, direct-physical and macvtap. Security groups do not apply to these ports, so filtering happens elsewhere. Since 2026.1, ML2/OVN routes such external ports north/south, removing one old reason to stay on ML2/OVS.
• Hardware offload keeps the OVS model but pushes flows into a NIC in switchdev mode. Neutron's guide lists Mellanox ConnectX-4, 4 Lx and 5 and Broadcom NetXtreme-S and -E cards, needs kernel 4.13 and OVS 2.8 or newer, and turns it on with other_config:hw-offload=true. Its examples use ML2/OVS, so confirm OVN support with your NIC vendor before buying cards.

Can OpenStack do SD-WAN?

Not by itself. OpenStack has no SD-WAN project, and most results for "openstack sd wan" are vendors explaining how to run their virtual SD-WAN edge as an instance. Fortinet, for one, publishes an OpenStack administration guide for FortiGate-VM, the firewall that carries its SD-WAN features, including a user_data file that pre-configures the instance. That is the realistic pattern: the appliance is a VM on a provider network, or a box in front of the cloud, and OpenStack supplies the plumbing:

• VPNaaS for IPsec site-to-site tunnels, working with ML2/OVN since 2024.1 Caracal through a stand-alone VPN agent. Our OpenStack VPNaaS site-to-site guide explains the parts.
• networking-bgpvpn, which attaches Neutron networks to existing BGP/MPLS VPNs and still ships through 2026.2.
• BGP, so the edge learns cloud prefixes dynamically instead of from static routes.
• SR-IOV ports for an edge VM that needs line rate, with filtering inside the appliance.

For two or three offices, a VPNaaS tunnel or a WireGuard VM is usually enough. SD-WAN earns its licence when many branches each have several links and you want one place to set policy.

Where RS Computers fits

We sell KVM virtual servers, not a managed OpenStack cloud, so here is where they honestly help someone working on OpenStack networking.

Much SDN learning happens without VMs: an OVN control plane with ovn-northd and its two databases, network namespaces standing in for instances, FRR peers to practise BGP against. All of those are ordinary Linux processes. If SSH, systemd and a firewall are still new, start with our 30-day Linux and DevOps lab plan. Running guests inside a VPS depends on nested virtualization, so check with us before planning a compute node on one.

The servers around a cloud are often the hard ones to place: the Kolla or OpenStack-Ansible deployment host, a bastion, a package mirror, monitoring, a CI runner, a BGP peer in another city. Every VPS and VDS has its own IPv4 and IPv6 address, which helps when you test dual-stack paths end to end. Our vCPUs are shared, so treat lab numbers as functional tests rather than benchmarks; DPDK's busy polling makes no sense there.

Sometimes a private cloud is overkill, and a few servers joined by WireGuard cover a handful of services with far less to run. Our Proxmox vs OpenStack comparison helps you weigh it.

The servers run on NVMe storage in Amsterdam (Netherlands), Prishtina (Kosovo) and Dublin (Ireland), with a 1 Gb/s port on VPS plans, 10 Gb/s on VDS plans and free weekly backups. The same plans and prices apply in all three cities; the VPS and VDS plans page lists them. VPS Mini (4 vCPU, 4 GB RAM) is comfortable for an OVN and FRR lab; a deployment host that also builds container images should start at VDS Small (4 vCPU, 8 GB RAM, 240 GB NVMe).

Frequently asked questions

Is OpenStack still relevant in 2026?

Yes. It shipped 2026.1 Gazpacho on 1 April and 2026.2 Hibiscus on 30 September, with 2027.1 Indri due in March 2027 according to the OpenStack release schedule, and the OpenInfra Foundation that hosts it became part of the Linux Foundation in June 2025. Its networking work, such as BGP in the OVN driver, targets large production clouds.

What does SDN stand for in cloud networking?

Software-defined networking: the network's forwarding behaviour is set by software through an API instead of device by device. In OpenStack, Neutron is that API, and a controller such as OVN turns its requests into flows on each host's virtual switch.

Is SDN still relevant?

More than ever, just less visible. Every OpenStack and Kubernetes cluster network is software-defined; what faded is the separate SDN controller product, because platforms such as OVN now ship the controller built in.

Is OpenStack the same as AWS?

No. AWS is a public cloud you rent, while OpenStack is open-source software that you or a provider run to build a cloud. The concepts map closely (Nova to EC2, Neutron networks and routers to a VPC, Cinder to EBS, Swift to S3), but with OpenStack you own the hardware, the upgrades and the on-call rota.

Does OpenStack have a hypervisor?

Not one of its own. Nova, the compute service, drives existing hypervisors through drivers, with KVM through libvirt as the usual choice, and Ironic handles bare metal. Neutron then plugs each instance's virtual NIC into Open vSwitch on the same host.

Which is better, SD-WAN or MPLS?

They solve different problems. MPLS is a carrier's private network with predictable latency, while SD-WAN steers traffic across whatever links a site has, broadband and mobile included, with central policy and encrypted tunnels. Many companies keep MPLS for a few critical sites and use SD-WAN elsewhere; either way, the cloud end is usually a VPN or BGP session into Neutron.

Can RS Computers help me set up an OpenStack networking lab?

Yes. Message us on Telegram or email info@rscomputers-ks.com with what you want to test, such as an OVN control plane, FRR peering or a deployment host, and we will suggest a plan and quote the setup.

What we would build in October 2026

A new cloud on 2026.1 Gazpacho, a SLURP release that can upgrade straight to 2027.1, or on 2026.2 Hibiscus if you want route leaking. ML2/OVN from day one, set explicitly if the installer is Kolla. Geneve for project networks, Neutron's ovn-bgp plugin with FRR on a spine-and-leaf fabric, a routed IPv6 /64 per project, and SR-IOV only for the few VMs that prove they need it. No external controller unless an ACI fabric or a Contrail estate is already paying the bills.

← All articles