Overlay vs. Underlay: Wo liegt die Störung wirklich?

Overlay vs. Underlay ist eine der wichtigsten Denkfragen im modernen Network Troubleshooting, weil immer mehr Produktionsnetze aus zwei (oder mehr) logisch getrennten Ebenen bestehen: einem Underlay, das zuverlässige IP-Connectivity liefert, und einem Overlay, das darauf Segmentierung, Virtualisierung oder Services abbildet. Wenn es „nicht geht“, ist die Störung selten eindeutig sichtbar. Ein VXLAN/EVPN-Fabric kann BGP-Sessions „up“ zeigen, während einzelne VNIs blackholen, weil MTU oder UDP/4789 im Underlay selektiv droppen. Ein MPLS L3VPN kann alle VRFs korrekt befüllt haben, während ein LDP-Neighbor flapped und damit der Transport-LSP instabil ist. Ein SD-WAN kann Tunnel „up“ melden, obwohl die Underlay-Paths Jitter und Loss erzeugen, die Echtzeitverkehr zerstören. Genau deshalb scheitert Troubleshooting ohne eine klare Trennmethodik: Teams springen zwischen Tools, sehen viele grüne Statusanzeigen und übersehen, dass die eigentliche Ursache in einer anderen Ebene liegt. In diesem Artikel lernen Sie ein praxiserprobtes Vorgehen, um Overlay- und Underlay-Störungen sauber zu unterscheiden, Beweisketten aufzubauen und mit wenigen Checks eine hohe Trennschärfe zu erreichen – unabhängig davon, ob Ihr Overlay VXLAN/EVPN, MPLS L3VPN, GRE/IPsec, WireGuard, Geneve, SD-WAN oder ein Cloud-Overlay ist.

Begriffe sauber trennen: Underlay, Overlay und Control Plane vs. Data Plane

Im Alltag werden „Overlay“ und „Underlay“ oft unscharf verwendet. Für Troubleshooting ist eine präzise Definition entscheidend:

• Underlay: Das physische und logische Transportnetz, das IP-Konnektivität zwischen Endpunkten (z. B. VTEPs, PEs, Tunnel-Endpunkten) bereitstellt. Typisch: Ethernet/Optik, IP-Routing (OSPF/IS-IS/BGP), ECMP, MTU, QoS.
• Overlay: Eine virtuelle Ebene, die über dem Underlay läuft und zusätzliche Logik transportiert: Segmentierung (VNIs/VRFs), virtuelle L2/L3-Domänen, Verschlüsselung, Service-Chaining. Typisch: VXLAN/EVPN, MPLS L3VPN, GRE/IPsec, SD-WAN-Tunnel.
• Control Plane: Protokolle, die Zustände aushandeln und Routen/Labels/Mappings verteilen (BGP EVPN, MP-BGP VPNv4, LDP, IKE, SD-WAN Orchestrator).
• Data Plane: Der tatsächliche Paketpfad (Forwarding) inklusive Kapselung/Labels/Verschlüsselung und der realen Drops/Latenzen.

Die wichtigste Konsequenz: „Control Plane up“ bedeutet nicht automatisch „Data Plane ok“. Und „Underlay IP pingbar“ bedeutet nicht automatisch „Overlay forwardet korrekt“, insbesondere wenn Kapselungs-Overhead, MTU, Fragmentation oder Policy-Filter eine Rolle spielen.

Warum die Frage „Overlay vs. Underlay“ so oft falsch beantwortet wird

In der Praxis führen drei Denkfehler besonders häufig zu Fehldiagnosen:

• Status-Falle: Tunnel/BGP/LDP zeigt „Established“, also müsse das Problem „woanders“ liegen. In Wahrheit sind selektive Drops, MTU-Blackholes oder Congestion im Underlay möglich, ohne dass Sessions sofort fallen.
• Ping-Falle: Ein ICMP-Ping (klein, tolerant) geht durch, also sei die Strecke gesund. In Wahrheit scheitern große Pakete, UDP-Fragmente oder TCP-Flows unter Loss/Jitter.
• Ein-Ebenen-Denken: Teams debuggen nur „Routing“ oder nur „EVPN“, obwohl das Problem an der Schnittstelle liegt: z. B. Next-Hop-Reachability (Underlay) für Overlay-Routen oder Label-Stack-Handling (Underlay/Transport) für VPN-Forwarding.

Die 10-Minuten-Trennmethode: Ein Ablauf mit hoher Trennschärfe

Wenn Sie in einem Incident schnell entscheiden müssen, wo die Störung wirklich liegt, hilft ein fester Ablauf. Die Idee ist nicht, alles zu prüfen, sondern die schnellsten Beweise zu sammeln.

Schritt 1: Scope und Symptomprofil (2 Minuten)

• Ist der Impact selektiv (nur bestimmte Segmente/VRFs/VNIs/Apps) oder breit (viele Ziele/Standorte)?
• Ist es Connectivity (keine Erreichbarkeit) oder Performance (Latenz/Jitter/Throughput)?
• Ist es stateful (TCP/TLS bricht) oder auch stateless (ICMP/UDP) betroffen?

Schritt 2: Underlay-Health schnell beweisen (3 Minuten)

• Erreichbarkeit der Underlay-Endpunkte: VTEP↔VTEP, PE↔PE, Tunnel-Endpunkt↔Tunnel-Endpunkt (IP).
• Interface-Health: Errors (CRC/Symbol), Drops, Queue Drops, Flaps.
• MTU-Realität: Ist die effektive MTU für gekapselte Pakete ausreichend? (Overlay-Overhead einkalkulieren.)

Schritt 3: Overlay-Control-Plane prüfen (3 Minuten)

• Session-Status: BGP EVPN / MP-BGP / LDP / IKE / SD-WAN Control Channel stabil?
• Route-/Label-/Mapping-Existenz: Werden die erwarteten Informationen verteilt (z. B. EVPN Type-2/3/5, VPNv4, Labels)?
• Next-Hop/Transport-Abhängigkeit: Ist der Next Hop im Underlay erreichbar? Gibt es rekursive Auflösung?

Schritt 4: Data-Plane-Verifikation mit einem konkreten Flow (2 Minuten)

• Ein betroffener Flow (5-Tuple) wird end-to-end beobachtet: Kommt er an? Gibt es Retransmissions? Geht er über den erwarteten Pfad?
• Wenn möglich: kurzer Capture nahe am Encapsulation-Punkt (z. B. VTEP/PE) und am Underlay-Interface.

Signalregeln: Indizien, die stark für Underlay sprechen

Ein Underlay-Problem ist wahrscheinlich, wenn mehrere dieser Signale zutreffen:

• Mehrere Overlays betroffen: z. B. VXLAN und IPsec zeigen gleichzeitig Probleme. Das deutet auf gemeinsamen Transport hin.
• Interface Errors/Drops: CRC/Symbol Errors oder starke Output Drops auf einem Underlay-Link.
• MTU-/Fragmentationsmuster: kleine Pakete gehen, große brechen; TCP wird „zäh“, Retransmissions steigen.
• ECMP „schlechter Pfad“: nur einige Flows sind betroffen, weil sie auf einem degradierten Member landen.
• Jitter/Loss unter Last: Control Plane bleibt oft stabil, Data Plane leidet (VoIP/Video zuerst sichtbar).

Für PMTUD-Kontext sind RFC 1191 (IPv4) und RFC 8201 (IPv6) hilfreiche Referenzen.

Signalregeln: Indizien, die stark für Overlay sprechen

Ein Overlay-Problem ist wahrscheinlich, wenn mehrere dieser Signale zutreffen:

• Nur ein Segment betroffen: z. B. nur VNI 10100, nur VRF „Customer-A“, nur ein Tenant.
• Underlay stabil und reproduzierbar: VTEP/PE Endpunkte sind sauber erreichbar, MTU passt, keine Drops – trotzdem fehlen Routen/Mappings.
• Control-Plane-Inkonsistenz: Route/Label/MAC wird auf einigen Nodes gelernt, auf anderen nicht (RR/RT/VNI-Drift).
• Policy- und Leak-Muster: Routen werden gefiltert, falsche RTs importiert, falsche Communities gesetzt.
• Anycast/VRF/Gateway-Symptome: ARP/ND-Blackholes, Gateway-MAC inkonsistent, VRF-Default falsch.

Die Schnittstelle: Wenn Underlay und Overlay „gleichzeitig“ schuld sind

Sehr viele Störungen liegen nicht eindeutig in einer Ebene, sondern an der Schnittstelle. Drei Klassiker:

• Next-Hop-Reachability: Overlay verteilt Routen, aber der Next Hop ist im Underlay nicht erreichbar. Ergebnis: Route im Control Plane sichtbar, aber nicht in FIB installiert oder Traffic blackholed.
• MTU-Overhead: Overlay-Control-Plane (BGP/LDP) funktioniert, aber gekapselte Data-Plane-Pakete sind zu groß und droppen selektiv.
• Stateful Service-Edges: Overlay/ECMP erzeugt asymmetrische Pfade über Firewalls/NAT, die ohne State-Sync droppen.

Praxisbeispiel 1: VXLAN/EVPN – VNI „ok“, aber Hosts nicht erreichbar

VXLAN kapselt in UDP, typischerweise Port 4789, und nutzt VTEP-IPs im Underlay. EVPN verteilt MAC/IP-Informationen via BGP. Typische Diagnose:

• Underlay prüfen: VTEP↔VTEP Reachability, MTU (VXLAN-Overhead), UDP/4789 nicht gefiltert.
• Overlay prüfen: EVPN Type-2 (MAC/IP) vorhanden? Type-3 (IMET) für BUM vorhanden? VNI↔VLAN Mapping korrekt?
• Anycast GW: Gateway-IP/MAC konsistent? ARP/ND-Suppression funktional?

Für VXLAN-Grundlagen ist RFC 7348 relevant, für EVPN RFC 7432.

Praxisbeispiel 2: MPLS L3VPN – VRF-Routen da, aber Traffic blackholed

In MPLS L3VPN ist es häufig, dass VRF-Routen korrekt im MP-BGP sichtbar sind, aber der Datenpfad scheitert, weil Transport-Labels oder LSPs fehlen oder instabil sind.

• Underlay prüfen: IGP stabil? LDP-Sessions up? LFIB konsistent? (Transport bis Egress-PE.)
• Overlay prüfen: VPNv4/VPNv6 Routen vorhanden, RT-Import korrekt, Next Hop erreichbar.
• Data Plane: Label-Stack korrekt (Transport + VPN Label)? MTU im Core ausreichend?

Primärquelle für L3VPN ist RFC 4364, für LDP RFC 5036.

Praxisbeispiel 3: SD-WAN/GRE/IPsec – Tunnel up, Anwendungen langsam

Viele Overlays zeigen „Tunnel up“, solange Keepalives/Control-Plane-Pakete ankommen. Anwendungen können dennoch leiden, wenn Underlay-Pfade Loss/Jitter erzeugen, MTU nicht passt oder QoS falsch greift.

• Underlay prüfen: Loss/Jitter/RTT per Pfad, nicht nur „up/down“. ECMP-Pfade einzeln betrachten.
• Overlay prüfen: Steering-Policies (PBR-artig), Pfadwahl-Algorithmen, Failover-Events, MTU/MSS-Clamping.
• Stateful Side Effects: Asymmetrische Pfade über zentrale Firewalls/NAT, wenn Breakout dynamisch wechselt.

Die unterschätzten Störungsquellen: MTU, PMTUD und Fragmentation

Overlay-Encapsulation vergrößert Pakete. Selbst wenn Underlay-Interfaces „1500“ anzeigen, kann die effektive Payload kleiner sein, wenn zusätzlicher Overhead (VXLAN, GRE, IPsec, QinQ) hinzukommt. Ergebnis: Große Pakete droppen, kleine funktionieren. Dieses Muster ist extrem häufig und wird oft fälschlich als „Applikation spinnt“ interpretiert.

• Indiz: TLS/HTTPS Handshakes hängen, große Transfers brechen, während kleine Requests ok sind.
• Nachweis: Captures zeigen Fragmentation oder ICMP „Packet Too Big“ (IPv6) / „Frag Needed“ (IPv4) fehlt.
• Korrektur: Underlay MTU erhöhen oder Overlay MTU/MSS korrekt clampen; ICMP für PMTUD gezielt erlauben.

Die unterschätzten Störungsquellen: ECMP, Hashing und „schlechter Pfad“

Underlays nutzen oft ECMP. Overlays nutzen oft zusätzlich LAG/Port-Channels. Ein einzelner fehlerhafter Member kann dann selektive Störungen erzeugen, weil Flows „gepinnt“ werden. Das wirkt wie ein Overlay-Problem, ist aber Underlay-Path-Health.

• Indiz: Nur einige Nutzer/Flows betroffen; nach Retry geht es manchmal; Monitoring wirkt widersprüchlich.
• Nachweis: Member-spezifische Errors/Drops, ungleichmäßige Auslastung, Retransmissions nur bei bestimmten Flows.
• Korrektur: fehlerhaften Member kontrolliert drainen, Hash-Policy prüfen, Telemetrie pro Member standardisieren.

Beweiswerkzeuge: Welche Tools pro Ebene wirklich „High-Signal“ sind

Tools sind nur dann hilfreich, wenn sie zur Ebene passen. Eine saubere Zuordnung verhindert Over-Tooling.

• Underlay High-Signal: Interface Counters (Errors/Drops), MTU-Tests, Path-Loss/Jitter, IGP Neighbor States, Traceroute/MTR (mit Vorsicht).
• Overlay Control Plane High-Signal: BGP EVPN/VPNv4 Route Presence, RT-Import/Export, LDP/RSVP/SR State, Tunnel SA/Child SA (bei IPsec), RR-Propagation.
• Data Plane High-Signal: Captures (Encap sichtbar), Flow Logs/NetFlow/IPFIX, LFIB/VTEP Table, konkrete End-to-End Flow-Beispiele.

Für Capture- und Protokollanalyse sind die Wireshark-Dokumentation und die tcpdump-Manpage zuverlässige Referenzen.

Runbook-Baustein: Overlay vs. Underlay in 15 Minuten zur wahrscheinlichsten Ebene

• Minute 0–3: Symptomprofil aufnehmen (selektiv vs. breit, stateful vs. stateless, Connectivity vs. Performance). 2–3 konkrete Flows (5-Tuple) sichern.
• Minute 3–6: Underlay beweisen: Endpunkt-IPs (VTEP/PE/Tunnel) erreichbar, keine offensichtlichen Errors/Drops, MTU plausibel, ECMP Member Health prüfen.
• Minute 6–9: Overlay-Control-Plane prüfen: Sessions stabil, relevante Routen/Labels/Mappings vorhanden (z. B. EVPN Type-2/3/5, VPNv4, LDP Labels), Next-Hop-Reachability validieren.
• Minute 9–12: Data Plane verifizieren: kurzer Capture am Encapsulation-Punkt oder Flow Logs; prüfen, ob Encap/Label/SA genutzt wird und ob Drops/Fragmentation auftreten.
• Minute 12–15: Entscheidung und Mitigation: Underlay-Fix (Member drain, MTU, QoS) oder Overlay-Fix (Mapping/RT/Policy/Next-Hop). Danach Verifikation mit denselben Flows.

Hygiene Checks: Damit die Frage „Overlay vs. Underlay“ selten eskaliert

• Baselines pro Ebene: Underlay (Loss/Jitter/MTU/Errors), Overlay (Route/Label Counts, RT/VNI Mappings), Data Plane (Flow KPIs, Retransmissions).
• Drift-Management: zentrale Source-of-Truth für VNI/VRF/RT/Policy; automatische Konsistenzchecks.
• Event-Korrelation: Changes als Events markieren (Policy Deploy, RR Änderungen, MTU-Änderungen), damit Incidents schneller zugeordnet werden.
• Member-Telemetrie: ECMP/LAG nicht nur als „Bundle ok“, sondern pro Member überwachen.
• MTU-Disziplin: Overhead einkalkulieren, PMTUD ermöglichen, MSS-Clamping bewusst und dokumentiert.

Weiterführende Quellen für Standards und vertiefende Lektüre

• RFC 7348 für VXLAN-Encapsulation (Overlay-Mechanik und Overhead)
• RFC 7432 für EVPN (Control-Plane-Route-Types und Verteilung)
• RFC 4364 für BGP/MPLS L3VPN (VRF/RD/RT im Overlay)
• RFC 5036 für LDP (Label-Verteilung als Underlay/Transport-Control-Plane)
• RFC 1191 und RFC 8201 für PMTUD (häufige Underlay/Overlay-Schnittstellenfalle)
• Wireshark Dokumentation für praktische Protokollanalyse und Encap-Nachweise
• tcpdump Manpage für effiziente Captures im Incident

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.