OpenStack Neutron networking with OVN

In an OVN-based Neutron deployment, the main change is where network state lives. The Neutron server no longer relies on a set of per-node agents to carry out L3 routing, DHCP and Open vSwitch programming. Instead, the Neutron ML2 driver for OVN translates Neutron API objects such as networks, ports, routers and security groups into rows in the OVN northbound database. That database holds the desired state: what the logical network should look like, expressed in logical switches, logical routers, logical ports and ACLs. The OVN northbound database is the layer your teams should treat as the record of intent for tenant networking.

The OVN northbound database does not configure the hosts directly. The ovn-northd service reads it and computes the logical flows and physical bindings that the data path needs, writing them to the OVN southbound database. The southbound database holds the realized state: which chassis (typically a compute or gateway node) hosts which logical port, the flow tables each chassis must install, and the encapsulation settings for tunnels. Each compute node runs ovn-controller, which subscribes to the southbound database, programs local Open vSwitch flows and reports port bindings back. Compute nodes therefore participate as OVN chassis rather than as hosts running a Neutron OVS agent. Confirm with your distribution and OVN version how gateway chassis, tunnel types and any hardware offload are configured in your environment.

For troubleshooting, this split changes the first questions. When a tenant reports a connectivity problem, the usual path is to compare the Neutron API view, the northbound rows, the southbound bindings and the flows on the relevant chassis, rather than to inspect agent heartbeats and namespaces on each network node. Teams moving from ML2/OVS should plan runbooks around the ovn-nbctl and ovn-sbctl tools, the health of the OVN database cluster and the ovn-controller logs on each chassis. Also decide early who can read and write the OVN databases, since direct edits can diverge from what Neutron expects. Confirm the database access model and backup approach with your OVN distribution documentation before go-live.

The most surprising change for teams coming from ML2/OVS is that the agents spread across network nodes are no longer the place where routing, DHCP and metadata happen. In an OVN deployment, the Neutron OVN mechanism driver writes intent into the OVN northbound database, ovn-northd translates it into logical flows in the southbound database, and ovn-controller on each compute node programs Open vSwitch on that host. Operators who expect to restart neutron-l3-agent or neutron-dhcp-agent on a network node when traffic fails will look in the wrong place. Before cutover, confirm in the OpenStack networking documentation for both your source and target releases which agents still run, where the metadata service runs, and which functions still depend on network namespaces.

Troubleshooting moves from agent status and namespace inspection toward the OVN databases and logical flow tracing. Operators will need to query the northbound and southbound databases, read ovn-northd and ovn-controller logs on the relevant hypervisor, and inspect the flow tables on the integration bridge. Logical topology tracing with ovn-trace is a common starting point, but command names, output formats and database schemas change between releases, so confirm them against the documentation for your target version. Write a runbook that maps common symptoms, such as a port without connectivity or a floating IP that does not answer, to the specific OVN queries your team will run, and test that runbook in a non-production cloud before go-live.

Monitoring also needs a new set of targets. Dashboards built on neutron agent heartbeats will show gaps or false alarms once those agents are gone. Plan alerts for the health and quorum of the OVN database cluster, the state of ovn-northd, ovn-controller on every compute node, chassis registration in the southbound database, and the metadata path that instances use to reach their configuration. Keep the Neutron API health checks and add log-based alerts for OVN errors that can precede a connectivity fault. Agree on these targets with the operations team before cutover so that the first production incident is not the first time the alerts fire.

Retention is where a migration can cause the most damage if it is treated as a background task. Build a complete inventory of networks, subnets, ports, floating IPs, routers and security group rules, including rules that reference remote security groups, and export it through the API before any change. Ask the owner of your chosen migration method whether resource IDs, fixed and floating addresses, and security group rule semantics are carried over for your release pair. Then compare the post-migration state with the inventory and test instance connectivity in a staging copy of production. Confirm the supported migration method in the OpenStack documentation for both releases before you set a cutover window.

The verification plan should show that tenant traffic, DHCP, DNS, security groups, provider reachability and floating IPs behave as designed on every compute node, not only on one test host. With the OVN driver, routing, DHCP and security group enforcement run in a distributed way on each hypervisor, so a test that passes from one node says little about the others. Build the test matrix before cutover. For each tenant network, list the source and destination hosts, the expected result, the project and the security group in use. Place test instances on different compute nodes, with and without a router attached, and cover every network type that will move off ML2/OVS. Confirm with the cloud team which Neutron and OVN versions are in scope, and take each command from the release documentation for that version.

For DHCP and DNS, boot instances on each compute node and confirm that they receive the expected address, gateway, DNS servers and lease options from the subnet configuration. Check that instance names resolve from another instance on the same network, and that the metadata path still returns data to cloud-init. For security groups, test each rule in both directions. Allowed ports should connect, and traffic outside the rule set should be dropped. Include the default group, a custom group and a rule change applied to a running instance, because OVN stores these rules as ACLs in its databases and the change must reach the hypervisor that hosts the port. Record which rule set was in effect at the time of each test so that results can be repeated later.

Provider network reachability needs tests from outside the cloud, from an instance and from the physical network side. Confirm that the physical network names in the Neutron configuration match the bridge mappings on each compute node, and test VLAN or flat networks where they are used. For floating IPs, assign and release addresses across different hosts, verify NAT from an external client, and confirm that the address follows the instance after a rebuild or migration. The operations team also needs to know where evidence lives: Neutron server logs, ovn-controller and Open vSwitch logs on each node, Nova compute logs, and the OVN northbound and southbound databases. Agree in advance which database entries are checked after each test, such as logical ports, chassis registrations and port bindings, so that a stale binding or missing entry is found quickly.

Failure tests show whether the distributed design degrades in a controlled way. Stop the OVN controller service on one compute node and confirm that instances on that host lose and regain connectivity as expected while other hosts are unaffected. Restart a controller node, and fail one member of the clustered OVN database, then verify that the cluster elects a leader and that the Neutron server reconciles pending changes. Reboot a compute node and confirm that its instances reattach and keep their addresses. For each test, the acceptance record should hold the requirement it proves, the software versions, the nodes and networks involved, the observed result, the log excerpts captured and the name of the person who signed off. Results that cannot be reproduced go back for investigation before sign-off, and the findings feed the operations runbook.