The Overlay and Underlay Split in Virtual Networks

A physical network has one address plan. Every host gets an address from a block that the routers agree on, and forwarding works because each router knows which direction leads to which block. That model fails as soon as the addresses stop describing location. Two tenants both want 10.0.0.0/8, a virtual machine moves from one rack to another without changing its address, and a workload is created on a host that has never been part of the subnet it belongs to. None of those are possible if the address that identifies a host is also the address the fabric uses to reach it.

Network virtualization resolves this by running two address spaces at once. The virtual network, called the overlay, has its own addresses, its own subnets, and its own forwarding rules. The physical network, the underlay, forwards only by its own addresses and never sees the overlay’s. A packet crossing from one to the other is wrapped in an outer header whose addresses belong to the underlay, carried as ordinary traffic, and unwrapped at the far side. The inner packet is unchanged throughout, which is what allows an address to mean the same thing in two different places.

Two address spaces that never meet

The boundary is a pair of tunnel endpoints. Each host that participates in the overlay runs a function that owns an underlay address and can add and remove the outer header; the usual name for the VXLAN case is a VTEP, and the generic term is a tunnel endpoint. When a guest sends a frame, the endpoint on its host looks at the inner destination, decides which remote endpoint should receive it, and emits a UDP datagram to that endpoint’s underlay address. The datagram’s payload is the guest’s frame, unmodified. The underlay routers forward the datagram by its outer destination exactly as they forward any other UDP traffic, with no knowledge that a second network is inside.

At the far end the receiving endpoint strips the outer headers and delivers the original frame to the guest that owns the inner destination. Between the two endpoints, nothing in the underlay has read an inner address, and nothing in the overlay has formed an opinion about the path. That division is the entire design: the overlay decides which endpoint, the underlay decides how to get there.

The cost is a second header on every packet. For VXLAN over IPv4 the additions are 8 bytes of VXLAN header, 8 bytes of UDP header, 20 bytes of IPv4 header, and a 14-byte outer Ethernet header, for 50 bytes total; over IPv6 the outer IP header is 40 bytes, raising the total to 70. Geneve uses a variable-length option area but the same shape of stack. Those bytes are pure overhead on the wire and, more importantly, they are bytes that no longer fit inside the underlay’s MTU, a constraint treated in tunnel encapsulation overhead and path MTU.

The mapping is the whole system

Encapsulation alone does not constitute a virtual network. The part that does the work is the mapping from an inner destination to an outer endpoint, and that mapping has to be consistent across every host in the overlay.

The key is a pair: the inner address, plus an identifier for which virtual network the packet belongs to. The identifier is necessary because inner addresses are not unique across tenants. VXLAN calls it a VNI and gives it 24 bits, so roughly 16.7 million identifiers exist; VLAN tags in 802.1Q carry 12 bits, of which 4,094 values are usable, which is the limit that pushed data centres toward encapsulation in the first place. Two tenants can therefore both use 10.0.0.0/8 with no conflict, because the VNI disambiguates them before the address is examined.

The lookup is per-host and local. A host knows the endpoints for the virtual networks its guests are attached to, and for each it holds a table of inner address to outer endpoint. When a guest’s frame misses that table, the host has to find out, and how it finds out is the difference between the two families of overlay control planes. One floods the request through the overlay and learns from the reply; the other distributes the mapping as routing information, which is the approach taken by an EVPN control plane. Either way, the data plane at the moment of forwarding is a single table lookup keyed by virtual network and inner destination.

This placement of state matters for scale. In a routed network, every router holds a route for every destination prefix, so the total state is the size of the address plan. In an overlay, the underlay holds a route per endpoint, and the number of endpoints is the number of hosts running the overlay, not the number of guests. The per-tenant address tables live only on the hosts that need them, distributed rather than concentrated. A fabric with a few thousand hosts and a few hundred thousand virtual machines has an underlay routing table sized by the first number and overlay tables sized by the second, and that asymmetry is why the design scales.

What the underlay is allowed to know

The underlay’s indifference is not free of obligations. It must deliver the outer packet, so it must have a route to every endpoint address, and it must do so without depending on any property of the inner packet. Three consequences follow.

First, the underlay must be converged and stable at the endpoint level. A host that is up but whose endpoint address is not reachable is indistinguishable, from the overlay’s point of view, from a host whose guests have all gone silent. Failures are visible only as packet loss on a tunnel, not as a routing change, which is a real loss of diagnosability compared with a flat network.

Second, the underlay cannot use the inner flow identity for its own load balancing unless the encapsulation carries it outward. A five-tuple hash over the outer headers sees the same source and destination for every flow between two endpoints, so all traffic between two hosts collapses onto one path. The standard remedy is to derive the outer UDP source port from a hash of the inner headers, which restores the entropy that ECMP needs; UDP source port entropy and underlay ECMP covers the mechanics and the cases where it fails.

Third, the underlay’s MTU must accommodate the outer headers. If the physical links carry 1500-byte frames, an inner frame of 1500 bytes plus 50 bytes of encapsulation is 1550 and does not fit. Either the endpoints advertise a smaller inner MTU to their guests, or the underlay is built with a larger MTU, or the outer packet is fragmented, which is the option that behaves worst. Data centre fabrics commonly configure jumbo frames for this reason, and the exact figure is a design choice rather than a protocol constant.

Where the separation leaks

The clean story is that the layers never interact. In practice they interact at four points, and each is a source of subtle failure.

The first is the mapping itself. A mapping that is stale is worse than a mapping that is missing, because a missing entry triggers a lookup and a stale one silently delivers traffic to an endpoint that no longer hosts the destination. Any control plane that distributes mappings therefore needs a way to withdraw them, and any implementation that caches them needs an expiry. The failure appears as intermittent delivery to a host that has just migrated.

The second is the boundary between overlay broadcast and underlay multicast. Early VXLAN deployments replicated broadcast, unknown unicast, and multicast frames by sending them to every endpoint in the VNI, either by unicast replication or by joining an underlay multicast group. Unicast replication costs one copy per endpoint, so the cost of a broadcast frame grows linearly with the size of the virtual network. Multicast requires the underlay to run a multicast routing protocol that many fabrics avoid. This is the pressure that made a routing-protocol control plane attractive.

The third is the interaction between the two forwarding tables when the same host is both a router for the overlay and a participant in it. A packet that must cross from one virtual network to another passes through a router function that is itself inside a host, so it is encapsulated, decapsulated, routed, and encapsulated again. Each hop through that function is a place where the VNI can be dropped or rewritten incorrectly, and the resulting packet is well-formed and delivered to the wrong tenant.

The fourth is observability. A traceroute from inside the overlay reports inner hops; a traceroute from the underlay reports endpoints. Neither shows the whole path, and the outer header’s TTL, not the inner one, is what the underlay decrements, so a loop in the underlay is visible only as the outer TTL expiring. Protocols that carry the underlay’s error information back to the inner sender, such as ICMP responses to the outer packet, have no natural way to identify which inner flow was affected. Implementations handle this by correlating on the outer five-tuple, which is ambiguous whenever the encapsulation does not preserve per-flow identity.

None of these leaks argues against the split. They are the price of address independence, and the alternative designs pay differently. A flat Layer 2 network with a single large broadcast domain avoids encapsulation entirely but is bounded by spanning tree and by the size of the broadcast domain. An MPLS-based design pushes the multiplexing identifier into a label stack and avoids the IP outer header, at the cost of requiring label-switched paths in the underlay. The encapsulated overlay wins because it runs over an underlay that is already understood, already routed, and already capable of carrying anything.