Site icon bintorosoft.com

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

Red Snapper

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:

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:

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)

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

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

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

Signalregeln: Indizien, die stark für Underlay sprechen

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

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:

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:

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:

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.

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.

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.

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.

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.

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

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

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

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:

Lieferumfang:

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.

 

Exit mobile version