As enterprise networks transition from traditional bare-metal deployments to densely packed KVM (Kernel-based Virtual Machine) hypervisors running on Ubuntu Server, standard Layer 2 VLAN routing becomes a massive bottleneck. Traditional VLANs are limited to 4,094 network segments, which is insufficient for large-scale multi-tenant cloud environments. Furthermore, routing Layer 2 traffic across physically disparate Layer 3 data centres requires complex hardware configurations. To resolve these limitations, cloud architects utilize VXLAN (Virtual Extensible LAN) overlay networks. By leveraging Open vSwitch (OVS) on Ubuntu, administrators can encapsulate Layer 2 Ethernet frames within standard UDP packets, allowing virtual machines to communicate seamlessly as if they were on the same physical switch, regardless of their actual geographic location.
The Architecture of Open vSwitch and VXLAN
Open vSwitch is a production-quality, multilayer virtual switch designed to enable massive network automation while supporting standard management interfaces. When a KVM virtual machine generates a network packet, OVS intercepts it. If configured for VXLAN, the OVS daemon takes that original Layer 2 frame, wraps it in a VXLAN header (which includes a 24-bit Virtual Network Identifier, allowing for 16 million unique networks), encapsulates it within a standard UDP packet, and routes it over the physical Layer 3 network to the destination hypervisor. The destination OVS daemon strips the encapsulation and delivers the raw frame to the receiving VM.
Installing Open vSwitch on Ubuntu
To begin, you must install the OVS packages on both of your Ubuntu KVM hypervisors (e.g., Host A and Host B). The packages are available directly from the standard Ubuntu repositories.
sudo apt update
sudo apt install openvswitch-switchEnsure the service is running and enabled on boot:
sudo systemctl enable --now openvswitch-switchCreating the Virtual Switch Infrastructure
On both Host A (IP: 10.0.0.51) and Host B (IP: 10.0.0.52), you must create a new virtual bridge. This bridge acts as the logical backplane that your KVM virtual machines will connect to. We will name this bridge ovs-br0.
sudo ovs-vsctl add-br ovs-br0At this point, if you attach a KVM virtual machine to ovs-br0 on Host A, it can only communicate with other VMs on Host A. To link the two hypervisors together, we must construct the VXLAN tunnel.
Configuring the VXLAN Tunnel Endpoints (VTEP)
On Host A, you must add a new VXLAN port to the ovs-br0 bridge and configure it to point to the physical IP address of Host B.
sudo ovs-vsctl add-port ovs-br0 vxlan0 \
-- set interface vxlan0 type=vxlan options:remote_ip=10.0.0.52Conversely, on Host B, you must configure the mirror image of this tunnel, pointing the VXLAN port back to the physical IP address of Host A.
sudo ovs-vsctl add-port ovs-br0 vxlan0 \
-- set interface vxlan0 type=vxlan options:remote_ip=10.0.0.51The options:remote_ip parameter is critical; it defines the destination endpoint for the UDP encapsulation. OVS handles the rest of the encapsulation logic entirely in the background.
Verifying the Overlay Network
You can verify the configuration of your Open vSwitch bridges and ports by running the show command on either host:
sudo ovs-vsctl showThe output will display the ovs-br0 bridge, containing the internal port (which the host OS uses) and the vxlan0 port with its remote IP configuration.
To test the overlay, you can assign IP addresses from a completely different subnet (e.g., 192.168.100.0/24) to the virtual machines connected to ovs-br0 on both hosts. When VM-1 (192.168.100.10) pings VM-2 (192.168.100.20), it behaves exactly as if they were plugged into an unmanaged desktop switch. Beneath the surface, OVS is intercepting the ARP requests and ICMP packets, wrapping them in UDP, and hurling them across the 10.0.0.0/24 physical network, establishing a highly scalable, isolated Layer 2 broadcast domain independent of the underlying physical infrastructure.