Choosing Between Open vSwitch and Linux Bridge for OpenStack Neutron

Decision: Choose Neutron Network Backend

When deploying OpenStack Neutron you must select a mechanism driver that implements the Layer‑2 forwarding for tenant networks. The two most common, fully supported drivers are Open vSwitch (OVS) and Linux Bridge. The decision influences performance, feature set, operational complexity, and hardware requirements. This guide states the decision, lists constraints, compares the options in a compact table, explains the trade‑offs, and then shows a concrete validation workflow you can run on a test cluster.

Constraints and Requirements

• OpenStack version: The guidance assumes OpenStack 2025.1 (or later) where both drivers are maintained and SR‑IOV offload is available for OVS.
• Kernel: OVS requires the openvswitch kernel module and a recent enough kernel (≥5.4) for proper offload; Linux Bridge works with any modern kernel but may need tuning on very old releases.
• Hardware: To reap OVS throughput benefits the NIC should support Receive Side Scaling (RSS) and, ideally, SR‑IOV virtual functions. Linux Bridge does not depend on these features.
• Operational overhead: OVS introduces additional packages, daemon processes, and periodic kernel‑module updates; Linux Bridge is part of the base kernel and needs less frequent attention.
• Feature needs: If you require VLAN trunking, VXLAN/Geneve encapsulation with flexible MTU, OpenFlow-based security groups, or SR‑IOV integration, OVS is the only option that provides them out‑of‑the‑box.

Comparison of Options

Aspect	Open vSwitch (OVS)	Linux Bridge
Throughput (large flows)	Higher, especially with RSS/SR‑IOV offload	Lower; limited by single‑threaded bridge processing
CPU overhead	More due to userspace daemon and flow table	Less; processing stays in kernel
Feature set	VLAN, VXLAN, Geneve, OpenFlow, SR‑IOV, QoS, port mirroring	Basic VLAN bridging; VXLAN works but lacks flow‑based control
Stability on old kernels	May need newer kernel modules; occasional compatibility issues	Very stable; part of core kernel
Operational complexity	Requires ovs-vsctl, periodic package updates, monitoring of ovs-vswitchd	Managed via standard bridge utilities (brctl, ip link); fewer moving parts
MTU handling in tunnels	Handles jumbo frames gracefully; can fragment/reassemble	VXLAN MTU must match physical MTU; mismatches cause packet drops

Trade‑offs Summary

• Choose OVS when you need high throughput, advanced encapsulation (VXLAN/Geneve with flexible MTU), SR‑IOV workloads, or plan to use OpenFlow‑based security groups or QoS policies.
• Choose Linux Bridge for small‑scale deployments, legacy hardware, or environments where operational simplicity and low CPU overhead outweigh the need for advanced features.
• Both drivers can coexist in the same deployment; you can assign different compute hosts to different mechanism drivers via the ml2_conf.ini mechanism_drivers list and host‑specific bridge_mappings or local_ip settings.

Concrete Validation Workflow

The following steps let you verify that each backend works as expected in a minimal test environment (one controller, two compute nodes). All commands are run on the controller unless noted otherwise. You need administrative privileges in OpenStack (e.g., a user with the admin role or the neutron service token).

1. Prepare the test cluster
   • Install OpenStack 2025.1 on the controller.
   • On Compute A install the openvswitch package and enable the neutron-openvswitch-agent.
   • On Compute B install the bridge-utils package (provides Linux Bridge) and enable the neutron-linuxbridge-agent.
   • Ensure both computes have the same physical NIC (e.g., eth0) connected to a provider network.
2. Configure ML2 to allow both drivers Edit /etc/neutron/plugins/ml2/ml2_conf.ini on the controller:

   [ml2]
   mechanism_drivers = openvswitch,linuxbridge
   type_drivers = flat,vlan,vxlan
   tenant_network_types = vxlan
   
   [ml2_type_vxlan]
   vni_ranges = 1:1000
   
   [securitygroup]
   enable_ipset = true
   firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
   

   Restart the Neutron server: systemctl restart neutron-server.
3. Create a provider network and a tenant VXLAN network

   # Provider network (flat) – adjust PHYSNET and PHYSICAL_INTERFACE as needed
   openstack network create provider --provider-physical-network physnet1 \
     --provider-network-type flat --external
   openstack subnet create provider-subnet --network provider \
     --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 \
     --allocation-pool start=192.168.100.10,end=192.168.100.50 \
     --dhcp
   
   # Tenant VXLAN network
   openstack network create tenant-vxlan
   openstack subnet create tenant-vxlan-subnet --network tenant-vxlan \
     --subnet-range 10.0.0.0/24 --gateway 10.0.0.1 \
     --dhcp
   

4. Launch two test VMs, one on each compute

   # VM on Compute A (OVS)
   openstack server create --flavor m1.tiny --image cirrus-0.5.2 \
     --nic net-id=$(openstack network show tenant-vxlan -f value -id) \
     --availability-zone nova:compute-a \
     vm-ovs
   
   # VM on Compute B (Linux Bridge)
   openstack server create --flavor m1.tiny --image cirrus-0.5.2 \
     --nic net-id=$(openstack network show tenant-vxlan -f value -id) \
     --availability-zone nova:compute-b \
     vm-bridge
   

   Wait until both VMs reach ACTIVE status.
5. Verify basic connectivity
   • Log into vm-ovs (via console or SSH) and ping the fixed IP of vm-bridge (retrieve with openstack server show vm-bridge -c addresses -f value).
   • Repeat the ping from vm-bridge to vm-ovs.
   • Successful ping indicates that the VXLAN tunnel is working on both backends.
6. Measure throughput (optional but illustrative)
   • Install iperf3 on both VMs.
   • On vm-bridge run iperf3 -s.
   • On vm-ovs run iperf3 -c <bridge-vm-ip> -t 30.
   • Swap roles and repeat.
   • Compare the reported Mbits/sec; you should see higher and more stable numbers on the OVS path when the NIC supports RSS/SR‑IOV.
7. Check agent logs for errors

   # On Compute A (OVS)
   journalctl -u neutron-openvswitch-agent -f
   
   # On Compute B (Linux Bridge)
   journalctl -u neutron-linuxbridge-agent -f
   

   Look for lines containing ERROR or Traceback. Both agents should report a state of running and show successful VXLAN sync messages.
8. Confirm Neutron agent state Run on the controller:

   openstack network agent list
   

   Ensure that both the Open vSwitch Agent on compute‑a and the Linux Bridge Agent on compute‑b appear with State: up and Alive: :).

Limitations and Practical Verification

Even after the workflow above, keep the following caveats in mind:

• MTU mismatches: If you observe packet loss or ping failures despite the agents reporting success, verify that the physical MTU on the NICs matches the VXLAN MTU (typically 1500 bytes → VXLAN MTU 1450). Use ip link show eth0 on each compute and adjust ml2_conf.ini vxlan_udp_port or physical_network_mtus as needed.
• OVS kernel module version: On some distributions the packaged OVS module lags behind the userspace utilities, causing ovs-vsctl: Connection refused errors. Check modinfo openvswitch and compare the version with ovs-vswitchd --version; upgrade the kernel or the openvswitch-switch package if they differ.
• Linux Bridge scalability: With hundreds of VXLAN tenants on a single bridge, the bridge’s forwarding database (FDB) can become a bottleneck. Monitor bridge fdb show and consider enabling bridge ageing or splitting tenants across multiple bridge instances if needed.
• Feature parity: Some Neutron extensions (e.g., port-security with OVS-specific flow modifications) are not available when using Linux Bridge. If your deployment relies on those, you must standardize on OVS.

To confirm that your chosen backend is operating correctly in production, repeat the ping/iperf test between VMs placed on the same type of compute host (both OVS or both Linux Bridge) and compare the results to the cross‑backend test. Consistently higher throughput and lower CPU usage on OVS hosts, when the NIC supports RSS/SR‑IOV, validates the performance expectation.