Network Engineers: VXLAN, Geneve, EVPN, OMP Operational TradeoffsThe underlay is the physical and routing plane that moves packets from one point to another, built from switches, routers, and protocols like BGP and OSPF. The overlay is the virtual network tunneled on top of it, handling tenancy, segmentation, and policy through encapsulation like VXLAN or IPsec. Design them separately: harden the underlay for raw reliability, and let the overlay carry the flexibility your applications actually need.
TL;DR:
- Using a reliable underlay with BGP and leaf-spine topology is essential for predictable overlay performance and scale.
- VXLAN is the default overlay protocol but may be supplemented by Geneve if extensive metadata, security, or telemetry are required.
- Overlays can fail silently from issues like MTU mismatches, ECMP hashing problems, or control-plane desynchronization, making comprehensive troubleshooting necessary.
- When latency, SLA, or rapid provisioning are critical, investing in the underlay is more effective than solely relying on overlay flexibility.
- Managed SD-WAN solutions leveraging carrier-neutral underlays and active monitoring can simplify deployment and increase network uptime.
Table of Contents
- Underlay vs Overlay Networking: Definitions and How They Connect
- Key Overlay Protocols: VXLAN, Geneve, GRE, IPsec, EVPN, and OMP
- Underlay Design: Topology, Routing, ECMP, and MTU
- Overlay Failure Modes and Troubleshooting Order
- SD-WAN and Cloud: Overlays in Action Across the WAN
- When to Fix the Overlay vs. Invest in the Underlay
- Author's Perspective on Underlay and Overlay Strategy
- How Californiatelecom Handles the Underlay So You Can Focus on the Overlay
- FAQ
Underlay vs Overlay Networking: Definitions and How They Connect
Underlay and overlay aren't competing technologies. They're different jobs stacked on the same infrastructure, and confusing the two is where most SD-WAN and data center troubleshooting goes sideways.
The underlay operates at Layers 1 through 3. It's the physical cabling, the switches, and the routing protocols, BGP, OSPF, IS-IS, that calculate how to get a packet from Point A to Point B. It doesn't know or care what's inside that packet. It just forwards.
The overlay lives on top, logically. It's a virtual network built by encapsulating traffic inside another packet, then sending that packet across the underlay like any other payload. The overlay carries the intelligence: which tenant owns this traffic, what policy applies, which segment it belongs to.
The connection point between the two is the tunnel endpoint, called a VTEP (VXLAN Tunnel Endpoint) or NVE (Network Virtualization Edge) depending on the protocol. This is where encapsulation and decapsulation happen.
A packet's actual journey looks like this:
- A host sends a frame destined for another host in the same virtual segment.
- The local VTEP wraps that frame in a VXLAN header, then in a UDP/IP header addressed to the remote VTEP.
- The underlay routes that outer packet using nothing but the outer IP addresses, unaware of the tenant traffic inside.
- The remote VTEP strips the outer headers and delivers the original frame to its destination.
The underlay never sees the tenant. The overlay never touches a routing table entry for the physical fabric. That separation is the entire point.
Key Overlay Protocols: VXLAN, Geneve, GRE, IPsec, EVPN, and OMP
Pick the wrong encapsulation or control plane and you'll spend months fighting problems that a different protocol choice would have avoided.
VXLAN remains the default data-plane encapsulation for data center overlays. It wraps Layer 2 Ethernet frames inside UDP/IP, using a 24-bit VXLAN Network Identifier (VNI) to scale tenant isolation well past the 4,096-VLAN ceiling of traditional Ethernet, according to the NVO3 / VXLAN specification. It's mature, widely supported, and the safe default for most leaf-spine fabrics.
Geneve takes a different approach. Defined in RFC 8926, it's also UDP-based, but it builds in an extensible metadata format so you can attach arbitrary information (security context, telemetry tags, policy identifiers) to each packet without redesigning the header. VXLAN wins on ubiquity; Geneve wins when your overlay needs to carry more than just a tenant ID.
GRE and IPsec solve a narrower problem: point-to-point tunneling, often with encryption. GRE alone adds no security; pairing it with IPsec is the common pattern for WAN links crossing untrusted transport. Both add encapsulation overhead that eats into usable MTU, a recurring theme you'll see again in the underlay section.
EVPN and OMP are the control planes, not the data planes. EVPN uses BGP to distribute MAC and IP reachability across VXLAN fabrics, replacing flood-and-learn behavior with actual routing intelligence. Cisco Catalyst SD-WAN uses OMP to distribute routing, policy, and security information between controllers and edge devices, while IPsec or GRE handles the actual encapsulation.

Pro Tip: If your overlay needs rich, variable metadata, per-tenant policy tags, telemetry markers, security context, Geneve's extensibility usually beats forcing that data into a VXLAN header it wasn't built to carry.
Underlay Design: Topology, Routing, ECMP, and MTU
The underlay's job is to be boring in the best possible way. Every clever thing your overlay does depends on the underlay behaving predictably underneath it.
- Build on leaf-spine (Clos) topology. It gives every leaf switch multiple equal-cost paths to every other leaf, which is exactly what overlay traffic needs to spread evenly across the fabric.
- Route with BGP, and use IGP sparingly. BGP scales better in large fabrics and gives you finer control over route advertisement timing, which matters when EVPN or OMP is layered on top.
- Verify ECMP hashing works with encapsulated traffic. Once a packet is wrapped in a VXLAN or GRE header, the underlay's hash algorithm may only see outer headers, not the inner five-tuple, and can send every conversation down the same link instead of spreading load. Hardware and controller-level hash preservation techniques exist, but you have to confirm they're enabled, not assume it.
- Plan MTU headroom before you deploy, not after. VXLAN adds 50 bytes of overhead; Geneve and IPsec vary but follow the same pattern. Cloud providers publish explicit MTU guidance for VPN gateways precisely because mismatched MTU causes silent fragmentation and packet loss that's brutal to diagnose after the fact.
Pro Tip: Set jumbo frames on underlay links wherever your hardware supports it. That headroom helps absorb encapsulation overhead without forcing every overlay packet through fragmentation.
Overlay Failure Modes and Troubleshooting Order
Overlays fail in ways that don't show up on a simple link-up/link-down check, which is exactly why they trip up teams that are used to underlay-only troubleshooting.
The usual suspects: encapsulation overhead pushing packets past MTU, ECMP hashing that ignores inner headers and creates flow imbalance, and control-plane partitions where EVPN or OMP loses synchronization between endpoints even though the physical links are fine. None of these show up in a basic ping test.
Work the problem in order, every time:
- Confirm underlay health first, link status, interface errors, routing table convergence.
- Check the overlay control plane next, is EVPN advertising routes, is OMP synchronized between controller and edge devices.
- Inspect tunnel endpoints and encapsulation behavior last, VTEP reachability, MTU on the tunnel interface, actual packet captures on both sides.
QoS deserves its own mention. The overlay expresses intent, this traffic is voice, this traffic is bulk data, but the underlay has to actually enforce it. An overlay tag with no matching underlay queue or policy is a wish, not a mechanism.
Pro Tip: When a tunnel "goes down" but the underlying link shows no errors, check MTU before anything else. It's the single most common cause of overlay symptoms that look like a routing problem but aren't.
SD-WAN and Cloud: Overlays in Action Across the WAN
SD-WAN is the clearest real-world overlay example most engineers will touch. It builds encrypted tunnels, IPsec or GRE, across whatever underlay transport is available: broadband, LTE, MPLS, dedicated fiber, treating all of it as interchangeable, and this transport independence is the core architectural idea behind the model. Cisco's OMP handles policy and route distribution between controllers and edge devices so the overlay stays consistent even as the underlying links change.
- Internet VPN overlays are cheap and flexible, and fine for sites where occasional latency spikes are tolerable.
- Carrier underlays or NaaS/middle-mile providers offer more predictable SLAs and faster provisioning than legacy telco circuit orders, worth it when a location can't absorb jitter.
- In cloud deployments, watch egress costs and MTU tuning closely, tunnel overhead, plus NAT traversal can quietly eat throughput you thought you had.
When to Fix the Overlay vs. Invest in the Underlay
Run through this before your next change window:
- SLA and latency needs are strict: invest in the underlay, better circuits, better peering, hardware QoS.
- Provisioning lead time is the bottleneck: an overlay change (new segment, new policy) ships in hours; new underlay capacity can take weeks.
- You need rapid segmentation or multi-tenancy: that's an overlay job, full stop.
- Observability gaps exist between physical links and tunnel state: fix that before touching either layer, you're diagnosing blind otherwise.
- In-house routing expertise is thin: a managed LAN/WAN approach with carrier diversity can shorten underlay provisioning and centralize visibility across sites.
Author's Perspective on Underlay and Overlay Strategy
Keep the underlay boring and reliable; spend your engineering effort on the overlay, where the actual business value lives. Before your next project, verify MTU end to end, test ECMP under real encapsulated load, and check whether a managed provider can absorb the underlay complexity you don't want to own.
— Jim
How Californiatelecom Handles the Underlay So You Can Focus on the Overlay
Every design decision above assumes you have a reliable, well-provisioned underlay to build on, and for multi-location businesses, that's usually the hardest part to get right in-house. A carrier-neutral sourcing approach avoids dependency on a single telco's install calendar and reduces the operational drag of managing multiple vendor relationships across sites.That carrier-neutral sourcing pairs with managed SD-WAN built on the same overlay principles covered here, encrypted tunnels, policy-driven routing, transport independence, backed by a 99.99% uptime SLA on data and a 24/7 U.S.-based NOC watching both the underlay links and the overlay control plane. If you're evaluating dedicated fiber for a site that needs predictable low latency, or you simply don't have the in-house routing bench to manage BGP and ECMP tuning across a growing footprint, request a free consultation and get a specific recommendation for your locations instead of a generic quote.
FAQ
Is MPLS an Overlay or Underlay?
MPLS is typically deployed as underlay transport, a carrier-provided path that other overlays (like SD-WAN's IPsec tunnels) run across. Some designs also use MPLS labels themselves as a form of overlay within a service provider's own network, so the answer depends on which side of the service boundary you're standing on.
Is VXLAN an Overlay or Underlay?
VXLAN is an overlay technology. It encapsulates Layer 2 frames inside UDP/IP packets and tunnels them across an IP underlay, using VNIs to scale tenant isolation as defined in the VXLAN/NVO3 specification.
What Is an Overlay in Networking?
An overlay is a virtual network built by encapsulating traffic and tunneling it across physical infrastructure it doesn't directly control. It handles tenancy, segmentation, and policy, using protocols like VXLAN, Geneve, or IPsec, while relying entirely on the underlay for actual packet delivery.
What Is the Underlay Network in Networking?
The underlay network is the physical and routing infrastructure, switches, routers, cabling, and protocols like BGP or OSPF, that moves packets between points without any awareness of tenant or application context. Overlays like SD-WAN or VXLAN depend on the underlay's stability to function correctly.
Does a managed network services provider manage both underlay and overlay components?
Yes. Californiatelecom sources underlay transport from over 50 carriers and layers managed SD-WAN on top for overlay policy and routing, with pricing available on request through a consultation.

