Site icon bintorosoft.com

Layer-3-Fault-Isolation: Routing vs. Underlay nachweisen

Red Snapper

Layer-3-Fault-Isolation: Routing vs. Underlay nachweisen ist im Betrieb großer Netzwerke eine Kernkompetenz, weil Layer-3-Incidents häufig „wie alles“ aussehen: Applikationen melden Timeouts, Monitoring zeigt Paketverlust, Nutzer berichten über langsame Verbindungen – aber die eigentliche Ursache kann in sehr unterschiedlichen Schichten liegen. Besonders tückisch wird es in modernen Umgebungen mit Overlays (z. B. VXLAN/EVPN), Anycast-Gateways, ECMP und stark dynamischen Workloads. Dann stellt sich im Incident fast immer dieselbe Frage: Ist das Routing-Problem real (Control Plane oder FIB), oder ist das Underlay instabil (Physik, Links, Optik, Congestion), sodass das Routing zwar korrekt wirkt, der Datenpfad aber nicht zuverlässig liefert? Genau hier setzt Fault Isolation an: Sie müssen mit belastbaren Belegen zeigen können, ob ein Fehler in der Routing-Ebene (Protokoll, Neighbors, Routen, Policy, Convergence) oder im Underlay (Link, MTU, Latenz, Drops, Queues, Hardware) entsteht. „Nachweisen“ bedeutet dabei nicht, eine Vermutung zu formulieren, sondern anhand von Telemetrie, Kontroll- und Datenpfadtests sowie reproduzierbaren Messpunkten zu belegen, wo das Problem beginnt und wie groß der Blast Radius ist. Dieser Artikel führt praxisnah durch Methoden, mit denen Sie Layer-3-Fault-Isolation sauber durchführen: von Baseline-Checks über Control-Plane-Validierung bis zur Underlay-Diagnose mit Countern, BFD, Traceroute-Varianten und gezielter Paketbeobachtung. Ziel ist, dass Sie im Incident nicht zwischen Teams pingpong spielen, sondern innerhalb kurzer Zeit eine beweisbare Eingrenzung liefern.

Begriffsrahmen: Was „Routing“ und „Underlay“ in der Praxis bedeuten

Im operativen Alltag wird „Routing“ oft als Sammelbegriff verwendet. Für eine saubere Layer-3-Fault-Isolation lohnt sich eine präzisere Trennung:

Ein entscheidender Punkt: Routing kann „gesund“ aussehen (BGP up, OSPF full, Routen vorhanden), während die Data Plane trotzdem Pakete verliert, weil Underlay-Links droppen oder MTU nicht passt. Umgekehrt kann das Underlay stabil sein, während Routing-Policies oder Convergence fehlerhaft sind und Traffic falsch oder gar nicht geroutet wird.

Das Kernziel: Beweisführung statt Bauchgefühl

„Routing vs. Underlay nachweisen“ heißt, zwei Arten von Belegen zu kombinieren:

Wenn beide Belegtypen in dieselbe Richtung zeigen, wird Fault Isolation belastbar. Wenn sie widersprechen, ist das ein starkes Signal, dass Control Plane und Data Plane auseinanderlaufen (klassisch: „Routen da, Traffic tot“).

Schritt eins: Den Blast Radius auf Layer 3 strukturieren

Bevor Sie tief in Protokolle gehen, definieren Sie die Reichweite des Problems. Das spart Zeit und verhindert, dass Sie „global“ debuggen, obwohl der Fehler lokal ist.

Aus diesen Fragen entsteht ein erstes Hypothesenraster: Ein reines Subnetzproblem deutet eher auf Routing/Policy/ARP/ND hin, ein lastabhängiges Problem eher auf Congestion/Queues, ein IPv6-only Problem eher auf ND/RA/MTU oder IPv6-Routing.

Control Plane nachweisen: Ist das Routing-Protokoll wirklich stabil?

Control-Plane-Checks sind notwendig, aber nicht hinreichend. Sie liefern die Basis: Gibt es überhaupt eine gültige Topologie und gültige Routen?

Für BGP als Referenz sind RFC 4271 (BGP-4) und für OSPF RFC 2328 (OSPFv2) nützlich. Für IS-IS bietet sich RFC 1195 (IS-IS for IP) als Einstieg an.

Data Plane nachweisen: RIB ist nicht FIB

Ein häufiger Irrtum: Wenn die Route in der Routing-Tabelle steht, muss der Traffic funktionieren. In der Praxis gibt es mehrere Stellen, an denen das auseinanderlaufen kann:

Beweisbare Data-Plane-Checks sind daher: FIB-Eintrag vorhanden, Next-Hop aufgelöst, ARP/ND stabil, Zähler am Next-Hop-Interface steigen konsistent mit dem Traffic an.

Aktive Pfadtests: Ping ist nicht gleich Ping

Aktive Tests sind in Fault Isolation zentral, aber sie müssen passend gewählt werden. Ein einzelner ICMP-Ping kann Underlay-Probleme verbergen oder Routing-Probleme fälschlich ausschließen.

Loss Rate als einfaches, reproduzierbares Maß

LossRate = Gesendet−Empfangen Gesendet

Wenn Sie LossRate mit unterschiedlichen Paketgrößen, aus unterschiedlichen Quellen und zu unterschiedlichen Zeiten messen, erhalten Sie ein Muster. Ein MTU-Problem erzeugt häufig Loss nur ab einer Schwelle, Congestion zeigt Loss primär unter Last, ECMP-Probleme zeigen Loss nur für bestimmte Flows.

Traceroute richtig interpretieren: Warum „Hop fehlt“ nicht automatisch Underlay ist

Traceroute ist hilfreich, aber in modernen Netzen auch missverständlich: ICMP Time Exceeded kann gefiltert, rate-limited oder auf anderen Pfaden beantwortet werden als der Nutztraffic. Fortgeschrittene Fault Isolation nutzt deshalb Varianten:

Wenn ein Hop im Traceroute „verschwindet“, kann das schlicht CoPP/Rate-Limiting sein. Ein Underlay-Problem ist eher dann wahrscheinlich, wenn der Nutztraffic gleichzeitig Loss zeigt und die Interface-Drops am relevanten Link korrelieren.

Underlay nachweisen: Die vier Zählerklassen, die fast immer helfen

Um Underlay-Probleme zu belegen, sind Interface-Zähler oft die schnellste Wahrheit. Entscheidend ist, die Zählerklassen zu unterscheiden:

Underlay gilt als „nachgewiesen instabil“, wenn diese Zähler zeitlich mit dem Incident korrelieren und entlang des betroffenen Pfades auftreten, nicht nur auf einem beliebigen Gerät.

MTU und PMTUD: Der Klassiker, der wie Routing aussieht

MTU-Probleme sind berüchtigt, weil sie sich wie „Routing kaputt“ anfühlen: Kleine Pings gehen, große Transfers hängen, manche Anwendungen funktionieren, andere nicht. In Overlay-Umgebungen ist das Risiko höher, weil Encapsulation zusätzliche Bytes benötigt. Fault Isolation braucht hier eine klare Testmethodik:

Für Path MTU Discovery ist RFC 1191 (PMTUD for IPv4) eine hilfreiche Grundlage, und für ICMP ist RFC 792 (ICMP) relevant.

BFD und schnelle Pfadbeweise: „Routing ist up, aber Forwarding ist tot“

Bidirectional Forwarding Detection (BFD) ist in vielen Netzen der Mechanismus, um Forwarding-Fehler schnell zu erkennen – unabhängig davon, ob das Routing-Protokoll selbst schnelle Timer hat. In Fault Isolation können BFD-Zustände ein starkes Indiz liefern:

Für BFD ist RFC 5880 (BFD) eine gute Referenz, um Zustände und Timer sauber einzuordnen.

ECMP-Fallen: Warum nur „ein Teil“ der Sessions bricht

ECMP ist hervorragend für Skalierung, aber schwierig für Troubleshooting, weil Fehlerbilder sporadisch wirken können. Wenn nur ein Next-Hop-Pfad defekt ist, werden nur die Flows getroffen, die auf diesen Pfad gehasht werden. Typische Indikatoren:

Beweisführung bedeutet hier: Identifizieren Sie den betroffenen ECMP-Next-Hop und belegen Sie, dass genau dieser Pfad underlayseitig dropt oder flapt, während andere Pfade stabil sind.

Overlay vs. Underlay: Wenn Routing „oben“ stimmt, aber der Tunnel leidet

In VXLAN/EVPN- oder GRE-Umgebungen gibt es zusätzlich die Tunnelperspektive: Underlay-IP-Erreichbarkeit kann stabil erscheinen, während der Overlay-Datenverkehr nicht korrekt läuft (z. B. wegen MTU, VTEP-Policy, Encapsulation-Handling, ARP/ND-Suppression-Fehlern). Umgekehrt kann ein Underlay-Problem als Overlay-Ausfall erscheinen, weil der Tunnel die Abhängigkeit versteckt.

Für EVPN als Grundlage eignet sich RFC 7432 (EVPN). VXLAN selbst ist herstellerübergreifend implementiert; als Überblick kann der Anchor-Text RFC 7348 (VXLAN) hilfreich sein.

Beweisorientierte Checkliste: Routing oder Underlay in Minuten eingrenzen

Outbound-Links für Standards und vertiefende Referenzen

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