a network overlay

Imagine a country's physical road network — the actual asphalt connecting every place. Now imagine a courier company that draws its own private map of 'virtual routes' on top: 'Route Blue' might run from warehouse to warehouse along whatever real roads are convenient, and the drivers only think in terms of Blue and Green routes, not in terms of which specific streets carry them. The real roads are the underlay; the courier's private logical map is the overlay. A network overlay is exactly this: a virtual network built on top of a physical one.

In a datacenter, the underlay is the real fabric of switches, links, and IP addresses (the leaf-spine network). An overlay is a set of virtual networks layered on top, created by wrapping each tenant's packets inside an outer packet — encapsulation — that travels across the underlay and is unwrapped at the far end. A virtual switch in each server's hypervisor adds an outer header (using a protocol like VXLAN or GRE) carrying a virtual-network identifier, so two virtual machines that think they share one private LAN can actually sit on opposite ends of the building, on totally different physical subnets. The underlay just sees ordinary IP packets between physical servers and routes them with normal ECMP; it neither knows nor cares what is inside.

Why it matters: overlays decouple the logical network that tenants and applications see from the physical network the operator runs. That makes it possible to give thousands of cloud tenants their own isolated, private networks with overlapping address ranges, to move a virtual machine to another rack without changing its IP, and to spin up or tear down virtual networks in software without rewiring anything. The honest costs: encapsulation adds header bytes (lowering the effective MTU and so the goodput) and CPU overhead, debugging is harder because you must reason about two networks at once, and the overlay is only as reliable and fast as the underlay beneath it.