Choose a Neutron ML2 Mechanism Driver

Neutron uses the ML2 plugin with a mechanism driver that handles L2 connectivity. The three main choices are ML2/OVS (Open vSwitch), ML2/OVN (Open Virtual Network), and ML2/Linux Bridge.

Feature Comparison

Feature	ML2/OVS	ML2/OVN	ML2/Linux Bridge
Performance	High	High	Medium
Distributed routing (DVR)	Yes (complex, DVR mode)	Yes (native, default)	No
Distributed DHCP	No (centralized DHCP agent)	Yes (native, no agent needed)	No
Security groups	iptables/conntrack or OVS firewall driver	Native OVN ACLs (no iptables)	iptables
DPDK support	Yes (OVS-DPDK)	Yes (OVN-DPDK)	No
SR-IOV support	Yes (with SR-IOV agent)	Yes (with OVN hardware offload)	No
Hardware offload	Yes (selected SmartNICs)	Yes (selected SmartNICs)	No
BGP dynamic routing	Yes (with neutron-dynamic-routing)	Yes (native BGP in OVN)	Limited
Trunk ports (802.1q)	Yes	Yes	Yes
QoS	Yes	Yes	Yes
IPv6	Yes	Yes	Yes
Agent count	Many (OVS + L3 + DHCP + metadata per node)	Few (ovn-northd, ovn-controller per node)	Many (Linux Bridge + L3 + DHCP + metadata)
Centralized L3 agent	Yes (unless DVR)	No (distributed by default)	Yes
Operational complexity	Medium	Medium-High	Low
Community direction	Maintenance mode	Active development (default since Yoga)	Legacy, minimal new features
Stability	Very mature	Mature (production since Train)	Very mature
Debugging tools	ovs-vsctl, ovs-ofctl, ovs-appctl	ovn-nbctl, ovn-sbctl, ovs-vsctl	brctl, ip, iptables

Recommendation by Use Case

Development and Learning

Use ML2/Linux Bridge. Simplest to understand, no OVS daemon required, easy to trace with standard Linux tools. Not suitable for production.

Small to Medium Production Cloud (< 50 compute nodes)

Use ML2/OVN. Default since Yoga (2022.1). Distributed routing and DHCP are built in — no need to scale out L3 and DHCP agents. Fewer moving parts than OVS with DVR.

Large Production Cloud (> 50 compute nodes)

Use ML2/OVN. OVN scales better than OVS+DVR because the control plane (ovn-northd) is centralized but the data plane is fully distributed. The OVN SB (Southbound) database synchronizes per-chassis state efficiently.

Existing OVS Deployment

Stay on ML2/OVS unless you have a clear migration window. OVS is in maintenance mode but fully functional. Plan migration to OVN on the next major upgrade.

DPDK Workloads (NFV, high throughput)

Use ML2/OVN with OVN-DPDK for new deployments. OVS-DPDK is also supported but OVN is the strategic direction. DPDK requires dedicated CPU cores (PMD threads) and huge pages.

Hardware Offload (SmartNIC)

Use ML2/OVN with OVN hardware offload. Better integration with NVIDIA/Mellanox BlueField and similar NICs.

Migration: OVS to OVN

Migrating an existing ML2/OVS cloud to ML2/OVN requires a maintenance window. There is no hot migration path.

Pre-migration Checks

# Verify OVN packages are available
apt-cache show ovn-central ovn-host 2>/dev/null || dnf info ovn 2>/dev/null

# Check current ML2 config
grep "mechanism_drivers\|type_drivers" /etc/neutron/plugins/ml2/ml2_conf.ini

# List all agents that will be replaced
openstack network agent list --agent-type "Open vSwitch agent"
openstack network agent list --agent-type "L3 agent"
openstack network agent list --agent-type "DHCP agent"

Migration Steps (Outline)

1. Deploy OVN (ovn-central on network/controller nodes, ovn-host on all nodes).
2. Run the Neutron OVN migration script to translate existing Neutron state to OVN NB/SB databases: neutron-ovn-migration-mtu.
3. Update mechanism_drivers = ovn in ml2_conf.ini.
4. Restart neutron-server.
5. Remove OVS agents and L3/DHCP agents from each compute node.
6. Start ovn-controller on each compute node.
7. Verify port bindings: openstack port list | grep binding_failed.
8. Validate connectivity from instances.

Refer to the official Neutron OVN migration documentation for the full procedure for your release.

Post-migration Verification

# All ports should be bound
openstack port list -f json | jq '[.[] | select(."Binding VIF Type" == "binding_failed")] | length'
# Should return 0

# OVN controller status on each compute node
sudo ovn-appctl -t ovn-controller connection-status

# Check logical flows
sudo ovn-sbctl lflow-list | wc -l

# Verify no legacy agents remain
openstack network agent list --agent-type "Open vSwitch agent"
openstack network agent list --agent-type "DHCP agent"
openstack network agent list --agent-type "L3 agent"

Configuration Quick Reference

ML2/OVN (new deployment)

# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
mechanism_drivers = ovn
type_drivers = local,flat,vlan,geneve
tenant_network_types = geneve

[ml2_type_geneve]
vni_ranges = 1:65536
max_header_size = 38

[ovn]
ovn_nb_connection = tcp:127.0.0.1:6641
ovn_sb_connection = tcp:127.0.0.1:6642
ovn_l3_scheduler = leastloaded

ML2/OVS (existing deployment)

# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
mechanism_drivers = openvswitch
type_drivers = local,flat,vlan,vxlan,gre
tenant_network_types = vxlan

[ml2_type_vxlan]
vni_ranges = 1:1000

[ovs]
bridge_mappings = provider:br-ex
local_ip = <TUNNEL_ENDPOINT_IP>

[securitygroup]
firewall_driver = openvswitch

ML2/Linux Bridge

# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
mechanism_drivers = linuxbridge
type_drivers = local,flat,vlan,vxlan
tenant_network_types = vxlan

[ml2_type_vxlan]
vni_ranges = 1:1000

[linux_bridge]
physical_interface_mappings = provider:eth1

[securitygroup]
firewall_driver = iptables