Fault Domain schnell bestimmen: Underlay vs. Overlay mit OSI

Die Frage „Fault Domain schnell bestimmen: Underlay vs. Overlay mit OSI“ entscheidet im Betrieb oft darüber, ob ein Incident in Minuten oder in Stunden gelöst wird. In modernen Rechenzentren und Cloud-Umgebungen liegen zwischen Anwendung und physischer Infrastruktur mehrere Abstraktionsschichten: VLANs, VRFs, Load Balancer, Tunnel (z. B. VXLAN), Service Mesh, DNS, TLS und Applikationsprotokolle. Wenn ein Alarm wie „Packet Loss“, „Service unreachable“ oder „Intermittierende Timeouts“ eintrifft, ist die eigentliche Herausforderung selten das Messen – sondern das Einordnen: Liegt der Fehler im Underlay (physische und IP-Transportbasis) oder im Overlay (virtuelle Netze, Tunnels, Control Plane, Policies, Services)? Das OSI-Modell liefert dafür eine robuste Denkschablone. Es hilft, Symptome den Schichten zuzuordnen, Abhängigkeiten sichtbar zu machen und mit wenigen gezielten Checks die Fault Domain einzugrenzen. In diesem Artikel lernen Sie, wie Sie Underlay und Overlay sauber voneinander trennen, wie Sie OSI als Entscheidungssystem nutzen, welche Signale „Underlay“ schreien und welche typisch „Overlay“ sind – und wie Sie Ihre Ergebnisse so dokumentieren, dass Eskalationen an Netzwerk, Plattform oder Applikation ohne Reibungsverluste funktionieren.

Underlay vs. Overlay: Begriffe, die im Incident-Chat oft durcheinandergehen

Bevor OSI ins Spiel kommt, lohnt sich eine klare Arbeitsdefinition. Im Betrieb ist nicht wichtig, ob Underlay und Overlay „wissenschaftlich“ definiert sind, sondern ob Teams dieselben Dinge meinen.

• Underlay: Die physische und IP-basierte Transportinfrastruktur, die Paketweiterleitung ermöglicht. Typisch: Links/Interfaces, L2-Switching in der Fabric, L3-Routing (z. B. Spine-Leaf), MTU, ECMP, physische Provider- oder WAN-Strecken, Basispolicys, die den Transport betreffen.
• Overlay: Virtuelle Netze und Dienste, die auf dem Underlay aufsetzen. Typisch: Tunnels (z. B. VXLAN), Control Plane (z. B. EVPN), virtuelle Segmentierung (VRF/Tenant), Security Policies, Load Balancing, Service Discovery, DNS, TLS, L7-Routing und Applikations-Dependencies.

Ein guter Einstieg für das OSI-Modell ist der Artikel zum OSI-Modell. Für VXLAN als verbreitete Overlay-Technologie ist RFC 7348 (VXLAN) eine hilfreiche Referenz, und für EVPN als Control-Plane-Ansatz RFC 7432 (EVPN).

Warum OSI beim Bestimmen der Fault Domain so gut funktioniert

Underlay/Overlay-Diskussionen scheitern oft an zwei Dingen: unklaren Symptomen und „Tool-Hopping“. Das OSI-Modell bringt beides in Form, weil es den Kommunikationsfluss schichtweise betrachtet. Wenn Sie wissen, an welcher Schicht der erwartete Ablauf zuerst bricht, können Sie sehr schnell entscheiden, ob Underlay oder Overlay wahrscheinlicher ist.

• OSI zwingt zur Reihenfolge: Erst Transport-Basis validieren, dann Tunnels, dann Services.
• OSI schafft gemeinsame Sprache: „L3-Path unplausibel“ ist präziser als „Netzwerk spinnt“.
• OSI reduziert false positives: DNS-Fehler werden nicht als „Connectivity“-Ausfall missverstanden.
• OSI macht Abhängigkeiten sichtbar: Overlay ist ohne Underlay nicht stabil, aber Underlay-Probleme äußern sich häufig zuerst als Overlay-Symptome.

Die Schnellregel: Wo bricht der erwartete Ablauf zuerst?

Für die Triage im NOC oder On-Call ist eine einfache Regel extrem effektiv: Der Fault Domain-Kandidat ist dort am wahrscheinlichsten, wo der erwartete Ablauf zuerst zuverlässig scheitert. Das klingt banal, verhindert aber typische Irrwege, bei denen Teams lange im Overlay suchen, obwohl der Underlay-Link flappt.

• Bricht es bei Link/Errors/MTU/ECMP? → Underlay-Verdacht steigt.
• Bricht es bei Tunnel-Aufbau, VTEP-Erreichbarkeit, EVPN/Control-Plane? → Overlay-Verdacht steigt.
• Bricht es bei DNS/TLS/HTTP, während Transporttests stabil sind? → Overlay oder Applikation (L6/L7) wahrscheinlicher.

OSI-Mapping: Welche Layer eher Underlay sind – und welche eher Overlay

In vielen Architekturen lässt sich eine pragmatische Zuordnung treffen. Sie ist nicht absolut, aber nützlich als Startpunkt:

• Layer 1–3: meist Underlay-dominiert (Physik, Switching/Segment-Basis, IP-Transport).
• Layer 4–7: häufig Overlay-/Service-dominiert (Policies, Sessions, TLS, DNS, HTTP, Service Mesh).

Wichtig ist die Grauzone: Layer 2 kann im Underlay (Fabric-L2) oder im Overlay (virtuelles L2 über VXLAN) leben. Layer 3 kann sowohl Underlay-Routing als auch Overlay-Segmentierung (VRFs/Tenants) betreffen. Genau deshalb ist ein OSI-basierter Entscheidungsweg so wertvoll: Er zwingt zur Präzisierung, welches L2 oder welches L3 gemeint ist.

Layer 1: Underlay-Signale, die Sie ernst nehmen sollten

Wenn Layer 1 instabil ist, sind Overlay-Symptome fast garantiert. Eine schnelle Fault-Domain-Bestimmung beginnt daher oft mit einem Blick auf Link-Stabilität und Fehlerzähler.

• Typische Underlay-Indikatoren: Link down/down, Link flapping, CRC/FCS-Errors, steigende Drops, optische Pegel außerhalb Grenzwerte, Provider-Alarme.
• Typisches Fehlerbild im Overlay: sporadische Tunnel-Resets, „Host unreachable“, plötzliche Latenzspitzen, „random timeouts“.

Entscheidungsknoten für die Praxis

• Wenn Errors/Flaps zeitlich mit dem Incident korrelieren dann Underlay-Fault Domain priorisieren und Overlay nur als Symptom betrachten.
• Wenn Links stabil und counters ruhig sind dann weiter zu Layer 2/3 und Overlay-Checks einplanen.

Layer 2: Der Klassiker für Verwechslungen zwischen Underlay und Overlay

Layer-2-Probleme sind berüchtigt, weil sie sowohl in der physischen Fabric als auch in virtuellen Segmenten auftreten können. Im Underlay geht es typischerweise um VLAN-/Trunk-Themen, STP/Loop-Events oder MAC-Learning im physischen Netz. Im Overlay dagegen geht es um „virtuelles L2“: MAC-Advertisement über EVPN, Flood-&-Learn vs. Control Plane, VNI-Zuordnung und VTEP-Verhalten.

• Underlay-L2-Signale: STP-Topology-Changes, MAC-Flapping auf physischen Ports, Broadcast-Storm, Err-Disable durch Loop-Protection.
• Overlay-L2-Signale: MAC-Table-Inkonsistenzen pro VNI, falsche VNI-Zuordnung, EVPN-Route-Advertisement fehlt, unidirektionale Erreichbarkeit zwischen Endpunkten in gleichem Segment.

Pragmatischer Testpfad

• Test 1: Betrifft es nur ein virtuelles Segment/Tenant (ein VNI/VRF) oder mehrere? Ein einzelnes Segment deutet häufiger auf Overlay hin.
• Test 2: Treten STP/Loop-Indikatoren in der physischen Fabric auf? Wenn ja, Underlay.
• Test 3: Sind VTEPs stabil erreichbar und die Control Plane konsistent? Wenn nein, Overlay oder Underlay-L3 als Ursache.

ARP als Mechanismus zwischen L2 und L3 ist in RFC 826 (ARP) beschrieben und hilft bei der Begriffsklärung, wenn Teams über „ARP kaputt“ diskutieren.

Layer 3: Underlay-Routing vs. Overlay-Segmentierung

Layer 3 ist der Kern der Underlay-Stabilität (Fabric-Routing, ECMP, MTU/PMTUD), aber auch ein zentraler Bestandteil des Overlays (Tenant-Routing in VRFs, Routing zwischen Segmenten, Policies). Für die Fault Domain ist entscheidend, ob das Problem den Transportpfad betrifft oder die virtuelle Segmentlogik.

• Underlay-L3-Signale: Traceroute bricht an einem Spine/Transit ab, großflächige Reachability-Probleme, ECMP-Hashing erzeugt konsistent betroffene Pfade, MTU-Blackholing auf der Fabric.
• Overlay-L3-Signale: Nur ein Tenant/VRF betroffen, Inter-VRF-Routing bricht, Policies blockieren ost-west oder nord-süd, virtuelle Default Routes fehlen.

MTU als schneller Underlay-Indikator

MTU-Probleme wirken häufig wie „Overlay instabil“, weil große Pakete (z. B. mit Tunnel-Overhead) hängen bleiben. Ein klassisches Muster: kleine Requests funktionieren, große brechen ab. Das ist ein starker Underlay-Verdacht, weil Overlays zusätzlichen Overhead erzeugen und damit MTU-Mismatches sichtbar machen.

Für IPv4-Verhalten ist RFC 791 eine Basis, für Path MTU Discovery RFC 1191.

Layer 4: Wenn der Transport „geht“, aber der Dienst nicht

Layer 4 ist ein sehr guter Filter, um Underlay und Overlay zu trennen. Wenn Underlay-L1–L3 stabil sind, aber TCP/UDP-Verhalten auffällig ist, liegt die Fault Domain oft im Overlay oder in Policy-/Security-Schichten. Gleichzeitig kann ein Underlay-Problem auch Layer-4-Symptome erzeugen, etwa bei Paketverlust auf bestimmten Pfaden.

• Timeout (keine Antwort): häufig Drop/Filter, Blackhole, State-Problem, manchmal Underlay-Loss.
• RST/Refused: Host erreichbar, Dienst lehnt ab oder Listener fehlt (eher Overlay/Service).
• Nur bestimmte Ports: spricht häufig für Policy/Firewall/WAF/Load Balancer (Overlay-/Service-Domain).

Für die Semantik von TCP und typische Fehlersignaturen ist RFC 9293 (TCP) eine belastbare Referenz. Für Port-Referenzen hilft die IANA-Registry zu Service Names und Port Numbers.

Layer 5–7: Overlay-Domain, sobald Underlay stabil belegt ist

Wenn Sie Underlay-Stabilität durch klare Messpunkte belegen können (Links stabil, Pfade plausibel, MTU ok), verschiebt sich die Wahrscheinlichkeit deutlich in Richtung Overlay (Control Plane, Policies, Service Discovery) oder Applikation. Layer 5–7 sind dabei nicht „nur App“, sondern beinhalten viele typische Plattform-Komponenten: Session-Affinity am Load Balancer, Token-Refresh im Auth-System, TLS-Zertifikate, DNS-Auflösung und HTTP-Statuscodes.

• Layer 5: reproduzierbare Timeouts, Stickiness/Session-Affinity, State-Synchronisation zwischen Appliances.
• Layer 6: TLS-Handshake, Zertifikatsablauf, SNI-Mismatch, Chain-Probleme.
• Layer 7: DNS (NXDOMAIN/SERVFAIL), HTTP 4xx/5xx, API-Gateway-Fehler, Service Mesh Routing, Abhängigkeitsausfälle.

DNS-Grundlagen sind in RFC 1034 beschrieben, HTTP-Semantik in RFC 9110.

Der 3-Minuten-Decision-Tree: Fault Domain mit OSI festnageln

Ein praktischer Decision Tree für die Triage sollte kurz sein und mit klaren Konsequenzen arbeiten. Die folgende Abfolge eignet sich, um Underlay vs. Overlay schnell zu bestimmen, ohne Details zu überladen.

• Schritt 1: Gibt es Layer-1-Alarme oder steigende Interface-Errors/Flaps? Ja → Underlay priorisieren. Nein → Schritt 2.
• Schritt 2: Ist das Problem segmentweit (mehrere VNIs/VRFs/Services) oder auf einen Tenant begrenzt? Segmentweit → Underlay-L3/MTU/ECMP prüfen. Tenant-spezifisch → Overlay/Policy prüfen.
• Schritt 3: Traceroute/MTR zeigt Pfadbruch in der Fabric/Transit? Ja → Underlay. Nein → Schritt 4.
• Schritt 4: TCP-Port handshake ok, aber TLS/HTTP/DNS scheitert? Ja → Overlay/L6/L7. Nein → Layer 4 Policies/NAT/State prüfen.

Messpunkte, die Underlay von Overlay trennen

Die größte Qualität entsteht, wenn Sie Messpunkte so wählen, dass sie eindeutig einer Fault Domain zugeordnet werden können. Dafür eignen sich einige „High-Information“-Signale, die Sie in fast jeder Umgebung bekommen.

• Underlay-Messpunkte: Link-Status, Error Counters, Pfadbruch in Traceroute/MTR, MTU-Indikatoren, Verlust/Jitter auf Transitstrecken.
• Overlay-Messpunkte: Tunnel-Endpoint-Erreichbarkeit (VTEP), Control-Plane-Konsistenz (z. B. EVPN-Routen), VNI/VRF-spezifische Betroffenheit, Policy-Drops, LB-Health pro Pool, DNS-/TLS-Fehlerbilder.

Intermittierende Störungen: Erfolgsquote als objektiver Hinweis

„Manchmal geht es“ ist der Klassiker, bei dem Teams sich zwischen Underlay und Overlay festfahren. Eine simple Erfolgsquote macht solche Probleme messbar und hilft, Muster zu erkennen: Ist der Verlust pfad- oder regionenspezifisch (häufig Underlay) oder tritt er nur bei bestimmten Services/Ports/Policies auf (häufig Overlay)?

$\mathrm{Erfolgsquote}=\frac{\mathrm{erfolgreiche} \mathrm{Versuche}}{\mathrm{Gesamtversuche}}\times 100\%$

• Interpretation Underlay: Erfolgsquote sinkt parallel für viele Ports/Services, korreliert mit Loss/Jitter auf Pfaden.
• Interpretation Overlay: Erfolgsquote sinkt nur für bestimmte Ports/Services oder nur in einem Tenant/VNI/VRF.

Typische Incident-Muster und ihre wahrscheinlichste Fault Domain

Als schnelle Orientierung helfen wiederkehrende Muster. Sie ersetzen keine Messung, sind aber gute „Default Hypothesen“, die Sie anschließend belegen.

• Viele Services gleichzeitig in einer Region instabil: häufig Underlay (Fabric, Transit, MTU, Provider).
• Nur ein Tenant/VNI betroffen, andere stabil: häufig Overlay (VNI-Mapping, EVPN, Policy, VRF).
• Ping ok, TCP 443 Timeout: häufig Overlay/Policy (Firewall/WAF/LB) oder State/NAT (L4).
• TCP 443 ok, TLS-Handshake bricht: meist Overlay/L6 (Zertifikat, SNI, Chain).
• DNS SERVFAIL/NXDOMAIN: meist Overlay/L7 (Resolver/Zone), Underlay nur prüfen, wenn Resolver unreachable ist.
• Große Requests hängen, kleine gehen: häufig Underlay-MTU/PMTUD, oft sichtbar durch Tunnel-Overhead.

Dokumentation für schnelle Eskalation: OSI-Update, das Underlay/Overlay klar benennt

Wenn Sie die Fault Domain bestimmt haben, sollte das Update so geschrieben sein, dass das nächste Team sofort weiterarbeiten kann. Ein gutes Update verbindet OSI-Layer mit Underlay/Overlay und enthält reproduzierbare Messpunkte.

• Scope: Region/Standort, betroffene VNIs/VRFs/Services, Startzeit.
• Underlay-Status: L1/L3 kurz belegt (Links stabil? Pfad plausibel? MTU-Indizien?).
• Overlay-Status: VTEP/Control Plane/Policy/LB/DNS/TLS mit einem Hauptbeleg.
• Fault Domain: „Wahrscheinlich Underlay“ oder „Wahrscheinlich Overlay“ plus Begründung.
• Next Action: konkreter Owner (Netzwerk-Fabric, Plattform-Netz, Security, App) und nächster Test.

Praktischer OSI-Checklistenblock: Underlay vs. Overlay in einem Blick

Dieser Block lässt sich direkt in Runbooks oder Ticket-Templates übernehmen und zwingt zu einer schnellen, konsistenten Einordnung.

• Underlay (L1–L3) prüfen: Link up? Errors/Flaps? Traceroute/MTR Pfad plausibel? MTU-Indizien? Loss/Jitter auf Transit?
• Overlay (L2–L7) prüfen: VNI/VRF-spezifisch betroffen? VTEP erreichbar? Control Plane konsistent (z. B. EVPN-Routen)? Policy-Drops? LB-Health? DNS/TLS/HTTP Fehlerbild?
• Entscheidung: Erste Schicht, an der der Ablauf zuverlässig bricht, bestimmt die Fault Domain.

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.