Physical networks were built for a world that no longer exists. When VLANs emerged in the 1990s, the assumption was straightforward: workloads lived on dedicated servers, network boundaries aligned with physical locations, and the 4,094-VLAN limit seemed generous. That world is gone.

Today's data centers run thousands of tenants across pooled infrastructure, with workloads migrating between hypervisors in seconds. The physical network can't keep up with this pace—not because the hardware is slow, but because reconfiguring switches, VLANs, and ACLs requires coordination that software-defined workloads simply outpace.

Network virtualization overlays solve this mismatch by introducing a fundamental abstraction: the logical network is decoupled from the physical fabric. Virtual networks are constructed in software, encapsulated within IP packets, and tunneled across whatever underlay exists beneath. Understanding how overlays work—and the engineering trade-offs they impose—is essential for anyone designing modern network infrastructure.

An overlay network is a logical topology constructed atop an existing IP-routed underlay. The underlay's job is simple: forward packets between tunnel endpoints with low latency and reasonable bandwidth. The overlay handles everything else—tenant isolation, virtual segmentation, policy enforcement, and workload mobility.

The architectural primitive enabling this separation is the VTEP (Virtual Tunnel Endpoint). VTEPs sit at the boundary between virtual and physical networks, typically implemented in hypervisor vSwitches or top-of-rack switches. When a virtual machine sends a frame, the local VTEP encapsulates it with an outer IP header destined for the remote VTEP serving the target VM. The underlay routes this packet using standard IP forwarding, oblivious to the inner tenant traffic.

This indirection delivers three concrete capabilities. Multi-tenancy scales beyond VLAN limits because overlay identifiers are typically 24 bits, supporting roughly 16 million segments. Workload mobility becomes trivial since virtual networks aren't bound to physical ports—a VM can migrate across racks or data centers while retaining its IP and MAC. Network agility emerges because new segments are provisioned in software, not by reconfiguring switches.

The trade-off is operational complexity. You now manage two networks: the physical underlay and the logical overlay. Troubleshooting requires correlation across both layers, and encapsulation overhead consumes MTU budget that must be planned carefully across the entire path.

Takeaway

Overlays don't eliminate complexity—they relocate it. The physical network becomes simpler and more stable; the logical network becomes more dynamic and harder to inspect.

Three encapsulation formats dominate overlay deployments, each reflecting different design philosophies. VXLAN (RFC 7348) wraps the original Ethernet frame in a UDP packet, using a 24-bit VNI for segment identification. UDP was chosen deliberately—source port entropy enables ECMP load balancing across the underlay, and stateless encapsulation keeps the data path fast.

NVGRE takes a different approach, using GRE as the transport with a 24-bit Tenant Network Identifier embedded in the GRE key field. NVGRE avoids UDP overhead but suffers an operational disadvantage: many underlay devices struggle to compute hash entropy from GRE headers, leading to poor ECMP distribution. This limitation has marginalized NVGRE in modern deployments.

Geneve (RFC 8926) represents the convergence point. It retains VXLAN's UDP transport and 24-bit VNI but adds a variable-length options field allowing extensible metadata to travel with each packet. This matters because overlay networks increasingly need to carry context—security tags, telemetry, service chaining instructions—that fixed-format encapsulations cannot accommodate.

The encoding choice has real consequences. Header overhead ranges from 50 to 64 bytes, demanding underlay MTU of at least 1600 bytes to preserve the standard 1500-byte tenant MTU. Hardware offload support varies significantly across NICs, and adopting a format unsupported by your silicon means burning CPU cycles on every packet.

Takeaway

Protocol design is rarely about elegance—it's about extensibility. Geneve won not because it was simpler, but because it admitted that future requirements would demand metadata we hadn't yet imagined.

Encapsulation alone doesn't make an overlay useful—you need a control plane to tell VTEPs where to send packets. Early VXLAN deployments relied on multicast flooding for unknown destinations, which works in lab environments but collapses at scale. Modern overlays use SDN controllers to programmatically distribute forwarding state.

The controller maintains a global view of every virtual network, every workload, and every VTEP. When a hypervisor instantiates a new VM, it registers with the controller, which then pushes forwarding entries to all relevant VTEPs: VM X with MAC Y on virtual network Z is reachable via VTEP at IP A. This eliminates flooding and enables deterministic path selection.

Two control plane models dominate. Centralized controllers like VMware NSX and Cisco ACI maintain authoritative state and push updates via proprietary protocols. Distributed control planes use EVPN—an extension of BGP—to advertise MAC and IP reachability between VTEPs, leveraging decades of BGP scaling expertise. EVPN has become the standard for hardware VTEP integration because it works with existing routing infrastructure.

The engineering challenge is convergence time. When a workload migrates, every VTEP communicating with it must learn the new location quickly enough that traffic doesn't blackhole. Production deployments target sub-second convergence, which constrains controller architecture choices and demands careful attention to update propagation, state synchronization, and failure handling.

Takeaway

A network without a control plane is just wires. The intelligence that makes virtualization possible lives not in the packets but in the system that decides where they should go.

Network virtualization overlays represent one of the most significant architectural shifts in data center networking since the move to IP. By decoupling logical topology from physical infrastructure, they enable the elasticity that modern workloads demand without requiring the underlay to change at the same pace.

The technical decisions—encapsulation format, control plane model, VTEP placement—each carry trade-offs that compound at scale. There is no universally correct answer, only answers appropriate to specific operational contexts, hardware capabilities, and organizational expertise.

What remains constant is the underlying principle: abstraction creates flexibility, but only when the abstraction is built on a foundation stable enough to support it. Design the underlay to be boring, and the overlay can afford to be interesting.