Underlay vs. Overlay: Fehl-Diagnosen mit OSI vermeiden

Underlay vs. Overlay ist in modernen Rechenzentren und Cloud-Architekturen mehr als ein Designkonzept – es ist eine der häufigsten Ursachen für Fehl-Diagnosen im Betrieb. Wenn „das Netzwerk langsam“ ist, wird oft vorschnell am Overlay (VXLAN, GRE, IPsec, Service Mesh) gesucht, obwohl der Underlay (physische Links, MTU, ECMP, Routing, Queues) die eigentliche Fehlerquelle ist. Umgekehrt können Underlay-Metriken sauber aussehen, während eine Overlay-Control-Plane (z. B. EVPN, Tunnel-Endpoints, Policies) Routen nicht korrekt verteilt und dadurch Blackholes erzeugt. Genau hier hilft das OSI-Modell als Denkwerkzeug: Nicht als starres Lehrbuch, sondern als praktische Methode, Symptome sauber einer Schicht zuzuordnen, Abhängigkeiten zu prüfen und Hypothesen zu falsifizieren. Dieser Artikel zeigt, wie Sie Underlay- und Overlay-Probleme systematisch trennen, typische Fehlinterpretationen vermeiden und mit einem OSI-orientierten Vorgehen schneller zur Root Cause gelangen – ohne sich von „Ping ist grün“ oder „BGP ist up“ in falscher Sicherheit wiegen zu lassen.

Begriffe klären: Was Underlay und Overlay im Betrieb bedeuten

Im Data Center ist der Underlay das IP-Transportnetz, das physische Konnektivität, Routing und Forwarding zwischen den Tunnel-Endpunkten bereitstellt. Dazu zählen Layer 1–3 (Kabel/Optik, Switchports, MTU, Buffering, Routing-Protokolle, ECMP-Pfade). Das Overlay ist eine logische Netzwerkebene, die über den Underlay „drübergelegt“ wird, um Segmentierung, Multi-Tenancy und flexible Topologien zu ermöglichen. Typische Overlays sind VXLAN, GRE, Geneve, IPsec-Tunnel oder auch anwendungsnahe Overlays wie Service-Mesh-MTLS und Sidecar-Proxys.

Wichtig: Underlay und Overlay sind nicht „entweder oder“, sondern eine Abhängigkeit. Das Overlay kann nicht stabiler sein als der Underlay, auf dem es läuft. Gleichzeitig kann ein perfekt funktionierender Underlay trotzdem keinen funktionierenden Service liefern, wenn die Overlay-Control-Plane falsche Informationen verteilt oder Policies den Traffic auf höheren Schichten blockieren.

OSI als Diagnose-Raster: Schichten, Signale und typische Fallen

Das OSI-Modell wird im Betrieb oft belächelt („zu akademisch“). Praktisch eingesetzt ist es jedoch ein äußerst wirksames Raster, um Fehl-Diagnosen zu verhindern: Jede Schicht liefert andere Signale, und jedes Signal kann täuschen, wenn man es aus dem Kontext reißt. Eine einfache Leitfrage lautet: Auf welcher OSI-Schicht kann dieses Symptom überhaupt entstehen? Ein „TLS-Handshake hängt“ ist selten ein Layer-2-Problem – aber ein Layer-1/2-Problem kann den Handshake indirekt verursachen, indem Retransmissions und Timeouts eskalieren.

• Layer 1–2 (Underlay-Nähe): Link-Fehler, Duplex/Autoneg, CRC, Microbursts, LACP, VLAN/Trunk, MTU auf Port/Link.
• Layer 3 (Underlay-Transport): Routing, ECMP, Asymmetrien, ICMP, Fragmentierung/PMTUD, Underlay-ACLs.
• Layer 4–7 (Overlay-/Service-Nähe): Ports, Session-States, TLS, HTTP, Proxies, Service Mesh, Policies, Timeouts.

Für ein robustes mentales Modell hilft es, Underlay als „Transportverfügbarkeit“ und Overlay als „logische Konnektivität“ zu verstehen. Sobald Sie diese Trennung verinnerlichen, erkennen Sie viele irreführende Symptome schneller.

Warum „Ping ok“ keine Entwarnung ist: ICMP, ECMP und Schein-Stabilität

Eine der häufigsten Fehl-Diagnosen entsteht durch übermäßiges Vertrauen in ICMP. Ein Ping testet nur einen sehr kleinen Ausschnitt: ICMP kann priorisiert, anders gequeued oder sogar über andere Pfade geleitet werden als Applikationsverkehr. In ECMP-Umgebungen ist das besonders kritisch: ICMP-Flows können auf einem „guten“ Pfad landen, während ein Teil der Hash-Buckets auf einem fehlerhaften Link endet. Das Ergebnis ist ein klassischer Betriebsirrtum: „Netzwerk ist ok“ – obwohl TCP/UDP-Flows unter Last droppen oder jittern.

Praktische Konsequenz: Wenn Sie Underlay vs. Overlay sauber trennen wollen, ersetzen Sie „Ping“ durch Tests, die die gleichen Header-Merkmale erzeugen wie der betroffene Traffic (z. B. gleiche 5-Tuple-Muster) und achten Sie auf Pfaddiversität. In Fabrics mit ECMP ist das Hashing- und Pfadverhalten eine zentrale Variable, die Diagnosen verfälschen kann.

Overlay-Encapsulation und MTU: Der Klassiker hinter „mysteriösen“ Drops

Encapsulation erzeugt Overhead. VXLAN, Geneve oder GRE fügen zusätzliche Header hinzu, wodurch die effektive Nutzlast-MTU sinkt. Wenn Underlay-MTU, Overlay-MTU und Host-MTU nicht konsistent sind, entstehen schwer sichtbare Fehlerbilder: einzelne Paketgrößen droppen, Verbindungen sind instabil, oder Performance bricht nur bei bestimmten Payloads ein (z. B. bei großen TLS Records oder bestimmten gRPC-Nachrichten).

Ein häufiges Missverständnis ist, dass „Jumbo Frames eingeschaltet“ automatisch alles löst. Entscheidend ist, dass die MTU end-to-end passt: vom Host über vSwitch, Leaf, Spine bis zum entfernten VTEP. Zudem kann Path-MTU-Discovery (PMTUD) durch Firewalls/ACLs oder falsche ICMP-Behandlung scheitern – dann wird das Problem als „Overlay-Bug“ fehlgedeutet.

Als technische Referenz für VXLAN-Grundlagen eignet sich die Spezifikation RFC 7348 (VXLAN). Sie hilft, Overhead und Encapsulation-Mechanik korrekt einzuordnen, insbesondere wenn MTU-Fragen im Raum stehen.

Daumenregel: Effektive MTU nach Encapsulation abschätzen

Für eine grobe Abschätzung können Sie den Overhead vom physisch verfügbaren MTU-Wert abziehen. Beispielhaft (vereinfacht):

$\mathrm{MTU}\left(\mathrm{effektiv}\right)=\mathrm{MTU}\left(\mathrm{Underlay}\right)–\mathrm{Overhead}\left(\mathrm{Encapsulation}\right)$

Die exakten Werte hängen von Protokollen und Optionen ab (VLAN-Tagging, IPv6, Geneve-Options, IPsec). Entscheidend ist weniger die exakte Zahl, sondern die Disziplin: MTU als konkrete Hypothese zu behandeln und sie end-to-end zu verifizieren, statt sie vorauszusetzen.

Control Plane vs. Data Plane: Wenn „BGP ist up“ trotzdem Blackholes entstehen

Ein weiteres Feld für Fehl-Diagnosen ist die Verwechslung von Control-Plane-Health mit Data-Plane-Reachability. Ein BGP-Neighbor kann stabil „Established“ sein, obwohl relevante Routen nicht importiert werden (Policy), Next-Hops nicht auflösbar sind (Underlay) oder die Forwarding-Tabelle nicht programmiert wird (Ressourcen, Bugs, TCAM/Memory). In EVPN-VXLAN-Fabrics ist das besonders ausgeprägt: Die EVPN-Control-Plane kann „grün“ sein, während einzelne VNIs oder VRFs keine korrekten Route Targets importieren und damit Hosts unsichtbar bleiben.

Für BGP-Grundprinzipien ist RFC 4271 (BGP-4) eine belastbare Quelle. Wer versteht, dass BGP deterministisch auf Policies reagiert, erkennt schneller, dass fehlende Reachability oft keine „mystische Overlay-Störung“ ist, sondern schlicht ein Import/Export-Thema.

Fehl-Diagnosen durch „Schichten-Sprünge“: Typische Irrtümer und wie man sie stoppt

In Incidents passieren Schichten-Sprünge: Man sieht ein Symptom auf Layer 7 und greift sofort zu Layer-7-Tools – ohne die darunterliegenden Schichten zu falsifizieren. Das führt zu langen, teuren RCA-Schleifen. Die folgenden Fehlmuster treten häufig auf:

• „HTTP 504“ => App ist schuld: Timeouts können durch Underlay-Jitter, MTU-Drops, ECMP-Teilpfadfehler oder Overlay-Policy-Lücken entstehen.
• „DNS sporadisch“ => Resolver instabil: UDP-Drops, Fragmentierung oder QoS/Queue-Engpässe können DNS ähnlich aussehen lassen wie ein Softwareproblem.
• „TLS Handshake langsam“ => Zertifikate/CPU: Retransmissions, Packet Loss oder asymmetrische Pfade verstärken Handshake-Latenz massiv.
• „Nur ein Service betroffen“ => nur L7: Häufig ist es eine einzige VRF/VNI/Policy-Kombination im Overlay oder ein spezifischer ECMP-Hash-Bucket im Underlay.

Die Gegenmaßnahme ist ein bewusstes Diagnose-Design: Sie müssen sich zwingen, Hypothesen schichtweise zu prüfen, bevor Sie tiefer in Tools und Logs gehen.

Ein OSI-orientiertes Troubleshooting-Playbook: Schrittfolge, die sich bewährt

Um Underlay vs. Overlay sauber zu trennen, braucht es eine reproduzierbare Schrittfolge. Das Ziel ist nicht, „alles zu prüfen“, sondern die wahrscheinlichsten Ursachen schnell zu falsifizieren und den Fehlerbereich einzugrenzen.

• Schritt 1: Symptom präzisieren – Welche Flows, welche Endpunkte, welche Ports/Protokolle, welche Zeitfenster?
• Schritt 2: Underlay-Transport verifizieren (L1–L3) – Link-Errors, Drops, MTU, Routing-Konsistenz, ECMP-Pfadgesundheit.
• Schritt 3: Overlay-Reachability prüfen – Tunnel-Endpoint-Erreichbarkeit, VTEP-Loopbacks, Encapsulation, VNI/VRF-Zuordnung.
• Schritt 4: Overlay-Control-Plane prüfen – EVPN/BGP-Routen vorhanden? Import/Export/RTs korrekt? Next-Hop auflösbar?
• Schritt 5: L4/L7-Indikatoren korrelieren – Retransmissions, RTO, TLS-Handshake-Zeiten, HTTP-Timeouts, Error-Spikes.
• Schritt 6: Packet Capture strategisch einsetzen – erst wenn klar ist, wo der Bruch zwischen Control und Data liegt.

Die Reihenfolge ist entscheidend: Wer Capture und L7-Debug zu früh macht, sammelt häufig Daten, die das Symptom beschreiben, aber keine Ursache belegen.

ECMP und Hashing: Wie Overlay-Design Underlay-Schwächen sichtbar macht

Overlays erhöhen oft die Anzahl paralleler Flows (Microservices, East-West-Verkehr, Sharded Backends). Dadurch wird ECMP stärker ausgenutzt – und Underlay-Schwächen werden sichtbarer. Ein einzelner fehlerhafter Link, eine Queue mit Drops oder ein optisches Problem auf einem Spine-Uplink kann sich dann als „zufällige“ Applikationsinstabilität zeigen. Besonders tückisch: Manche Verbindungen funktionieren stabil, andere droppen, je nachdem, wie der Hash fällt.

In der Praxis ist es hilfreich, bei Verdacht auf ECMP-Probleme Tests zu nutzen, die mehrere Flows erzeugen, und die Ergebnisse zu streuen. Wenn nur ein Teil der Flows Fehler zeigt, ist das ein starkes Indiz für teildefekte Pfade oder Hash-Polarisation – ein Underlay-Thema, das im Overlay leicht falsch interpretiert wird.

QoS, Queues und Microbursts: Wenn Underlay „gesund“ wirkt, aber Latenz eskaliert

Viele Monitoring-Systeme sehen Link-Up/Down, Interface-Errors und vielleicht Bandbreite. Sie sehen aber nicht automatisch Microbursts, Queue-Drops oder Bufferbloat. Gerade in modernen Fabrics entstehen kurze, heftige Bursts (z. B. Incast), die Switch-Buffers überlaufen lassen. Das Ergebnis: Packet Loss und Latenzspitzen, die auf Layer 7 wie „random Timeouts“ aussehen.

Das Overlay ist hier häufig nur der Verstärker: Encapsulation und zusätzliche Hop-Ketten erhöhen Paketgrößen und Processing-Pfade. Wenn Sie dann ausschließlich Overlay-Logs betrachten, finden Sie keine Ursache. Die OSI-Perspektive zwingt Sie, L2/L3-Indikatoren wie Queue-Drops, WRED/ECN-Signale oder Output-Discard-Zähler einzubeziehen.

Overlay-Policies und Segmentierung: Wenn Underlay stimmt, aber der Traffic nie „darf“

Die umgekehrte Fehl-Diagnose ist ebenso verbreitet: Underlay ist stabil, aber Overlay-Policies verhindern Konnektivität. Beispiele sind falsche VRF-Zuordnungen, fehlende Route Targets, falsch gesetzte Security Groups, NetworkPolicies in Kubernetes oder Service-Mesh-Authorization-Policies. Solche Probleme äußern sich gern „wie Netzwerkfehler“: Timeouts statt klare Rejects, weil Pakete gedroppt werden.

Wenn Sie Policies als Ursache vermuten, hilft ein OSI-Trick: Prüfen Sie, ob ein „härteres“ Signal existiert. Ein TCP-RST oder ein ICMP-Administratively-Prohibited ist ein anderes Fehlerbild als ein stiller Drop. Stillen Drops begegnet man am besten, indem man die Policy-Kette systematisch rückwärts aufrollt: Welche Kontrollen wirken auf L3, welche auf L4, welche auf L7?

Tooling richtig einsetzen: Welche Werkzeuge zu Underlay und Overlay passen

Viele Incidents dauern länger, weil Tools falsch gemappt werden. Ein sauberer Underlay/Overlay-Fokus hilft, Werkzeuge gezielt einzusetzen:

• Underlay-Tools: Interface-Counter, Optical DOM, LACP-Status, Routing-Table/FIB, ECMP-Path-Checks, MTU-Tests, Queue/Drop-Metriken.
• Overlay-Tools: Tunnel-Status, VTEP-Reachability, EVPN/BGP-RIB, VNI/VRF-Maps, Policy-Hitcounts, Control-Plane-Events.
• L4–L7-Tools: TCP-Stats (Retransmissions, RTO), TLS-Metriken, HTTP-Logs, Traces, Service-Mesh-Telemetrie.

Eine robuste Praxis ist, Tool-Ausgaben immer in eine Hypothese einzubetten: „Wenn X die Ursache ist, müsste ich Y sehen.“ So vermeiden Sie, dass einzelne Metriken (z. B. „Session up“) eine falsche Sicherheit erzeugen.

Praxisbeispiele: Drei Szenarien, in denen OSI Fehl-Diagnosen verhindert

Szenario 1: Sporadische Timeouts in einer EVPN-VXLAN-Fabric

Symptom: Einige Microservices zeigen 1–2 % Request-Timeouts, verteilt über mehrere Pods. Erste Vermutung: Service Mesh oder Applikationsbug. OSI-Ansatz: Layer 4 prüfen – Retransmissions steigen. Layer 3 prüfen – nur bestimmte ECMP-Pfade betroffen. Root Cause: ein fehlerhafter Spine-Uplink mit Drops unter Microbursts. Overlay war nicht „schuld“, hat aber durch viele parallele Flows den Fehler sichtbar gemacht.

Szenario 2: „Nur große Requests“ schlagen fehl

Symptom: Kleine Requests funktionieren, große Uploads brechen ab. Erste Vermutung: App-Limits oder WAF. OSI-Ansatz: Layer 3/MTU prüfen – PMTUD blockiert, ICMP-Frag-Needed wird gedroppt. Ergebnis: Fragmentierung scheitert, große Pakete verschwinden. Fix: ICMP korrekt erlauben und MTU konsistent setzen. Overlay-Encapsulation war der Trigger, Underlay-Policy die Ursache.

Szenario 3: Einzelner Tenant ohne Reachability, Underlay komplett grün

Symptom: Ein Tenant-VRF kann seine Gateways nicht erreichen, andere Tenants sind ok. Erste Vermutung: Underlay-Problem. OSI-Ansatz: Layer 2/3 Underlay unauffällig, Tunnel ok. Overlay-Control-Plane: EVPN-Import-RT fehlt auf zwei Leafs nach Change. Fix: RT-Schema konsistent ausrollen. Hier wäre reines Underlay-Debugging Zeitverschwendung gewesen.

Operational Guardrails: Prozesse, die Underlay/Overlay-Verwechslungen reduzieren

Technik allein löst Fehl-Diagnosen nicht. Sie brauchen organisatorische und prozessuale Leitplanken, die OSI-Denken im Alltag verankern:

• Runbooks mit Schichtstruktur: Jede Störung beginnt mit L1–L3, bevor Overlay- und L7-Spezifika folgen (oder bewusst übersprungen werden, wenn falsifiziert).
• Standardisierte Metriken pro Schicht: Minimales Set an Signalen, die jedes Team kennt und schnell abrufen kann.
• Change-Checklisten: Bei Overlay-Änderungen zwingend MTU/Underlay-Abhängigkeiten prüfen; bei Underlay-Änderungen Overlay-Tunnel/Control-Plane validieren.
• Postmortems mit OSI-Mapping: Ursache und „Why it looked like X“ explizit je Schicht dokumentieren.
• Blast-Radius-Tests: Vor Rollouts repräsentative Flows und Paketgrößen testen, nicht nur Ping.

Outbound-Referenzen für belastbare Begriffe und Protokolle

Wenn Sie Begriffe, Header-Overheads oder Control-Plane-Mechanismen nachschlagen möchten, sind diese Quellen in der Praxis besonders hilfreich:

• RFC 7348 (VXLAN) für Encapsulation, VNI/VTEP-Grundlagen und Overhead-Orientierung.
• RFC 4271 (BGP-4) für deterministisches Verhalten von BGP, Sessions und Policy-Wirkung.
• RFC 7432 (EVPN) für EVPN-Route Types, Multihoming-Modelle und Control-Plane-Konzepte.

Ein praktischer Merksatz für Incidents: „Erst Transport, dann Logik, dann Anwendung“

Wenn Sie Underlay vs. Overlay sauber trennen wollen, hilft ein Merksatz, der OSI in eine alltagstaugliche Reihenfolge übersetzt: Erst Transport (Underlay), dann Logik (Overlay), dann Anwendung (L4–L7). Das bedeutet nicht, dass Sie immer unten anfangen müssen – aber dass Sie jede höhere Hypothese nur dann verfolgen, wenn die darunterliegende Schicht entweder plausibel stabil ist oder bereits falsifiziert wurde. So vermeiden Sie die typischen Fehl-Diagnosen, bei denen Teams stundenlang am Overlay schrauben, während ein einziger fehlerhafter Link, eine MTU-Inkonsistenz oder eine Queue mit Drops die eigentliche Ursache ist.

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.