February 15, 2026

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

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.

Table of Contents

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:

Control Plane: Routing-Protokolle und deren Zustände (Adjacencies/Neighbors, LSDB, BGP Sessions, Timers, Policies), aus denen Routen entstehen.
Data Plane: tatsächliche Weiterleitung von Paketen anhand von FIB/TCAM und Next-Hop-Resolution (ARP/ND, L2-Adjacency, ECMP-Hashing).
Underlay: physische und logische Transportbasis, auf der der Datenpfad läuft: Interfaces, Links, Optik, MTU, QoS/Queues, Congestion, Fehlerzähler, L1/L2-Stabilität.
Overlay: logisches Netz über dem Underlay (z. B. VXLAN), das zusätzliche Encapsulation und Endpunktauflösung einführt.

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:

Deterministische Zustandsbelege: Nachbarzustände, RIB/FIB-Einträge, Next-Hop-Resolution, Interface-Status, Fehlerzähler.
Empirische Pfadbelege: aktive Messungen (Ping, Traceroute, TCP-Handshake-Tests), passive Telemetrie (Flow, Packet Drops, Queueing), korrelierte Zeitachsen.

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.

Ist das Problem einseitig oder beidseitig? Nur Client → Server oder auch Server → Client.
Betrifft es ein Subnetz, eine VRF, eine Zone oder alles? Segmentierung hilft, Underlay vs. Routing einzugrenzen.
Ist es protokollspezifisch? ICMP ok, TCP nicht; IPv4 ok, IPv6 nicht; UDP ok, DNS nicht.
Ist es zeitabhängig? nur bei Last, nur nach Changes, nur sporadisch in Bursts.

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?

Neighbor-Zustände: OSPF Full, IS-IS Up, BGP Established – plus Flap-Historie und Timer.
Route-Existenz: Präfix ist in der RIB vorhanden, korrektes Next-Hop, korrekte Preference/Metric.
Policy/Filter: Route Maps, Prefix Lists, Communities, Redistribution-Regeln – „Route da“ ist nicht gleich „Route verwendet“.
Convergence-Indikatoren: häufige SPF-Läufe, BGP-Update-Stürme, Route Churn, CPU-Spikes.

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:

FIB-Programmierung: Route ist zwar in der RIB, aber nicht (oder falsch) in die FIB/TCAM programmiert (z. B. Ressourcenknappheit, Softwarebug, Partial Programming).
Next-Hop-Resolution: Next-Hop ist erreichbar laut RIB, aber ARP/ND ist unvollständig oder instabil.
ECMP-Hashing: nur bestimmte Flows treffen einen „schlechten“ Pfad; dadurch wirkt es sporadisch.
VRF/Policy-PBR: Traffic wird umgeleitet oder in eine falsche Instanz geschickt; Traceroute wirkt unerwartet.

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.

ICMP mit definierter Größe: MTU-Probleme zeigen sich oft erst bei großen Paketen und DF/PMTUD.
TCP-Handshake-Tests: validieren Statefulness und erlauben genauere Aussagen zu Firewalls/Policies.
Multiple Quellen: testen Sie aus verschiedenen Segmenten/ToRs/Access-Switches, um ECMP- und Lokalitätsprobleme zu entlarven.
Bidirektional: Source → Dest und Dest → Source, um asymmetrische Pfade oder Stateful Drops zu erkennen.

Loss Rate als einfaches, reproduzierbares Maß

$LossRate = \frac{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:

ICMP- vs. UDP- vs. TCP-Traceroute: unterschiedliche Behandlung durch Policies und Geräte.
Paris Traceroute Prinzip: konstante 5-Tuple Parameter, um ECMP konsistent zu halten und Pfadwechsel durch Hashing zu vermeiden.
Hop-by-Hop Counter-Korrelation: „Traceroute zeigt Hop X“ ist weniger wert als „Interface Counter auf Hop X steigen/droppen passend zum Testtraffic“.

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:

Physische Fehler: CRC/FCS, Alignment, Symbol Errors, Rx/Tx Errors – Hinweis auf L1/L2-Probleme (Optik, Kabel, Port, Interferenzen).
Queueing/Buffer Drops: Output Drops, Tail Drops, WRED-Drops – Hinweis auf Congestion oder QoS-Mismatch.
Discards ohne Fehler: Input/Output Discards – häufig Ressourcen- oder Policy-bedingt (ACL, policer, punt, feature interaction).
Link-Flaps und Lane-Instabilität: up/down Events, PCS/PHY Events, LACP Member Flaps – häufig Ursache für sporadische Loss-Spikes.

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:

Gezielte Tests mit DF: bei IPv4 „Don’t Fragment“ erzwingen, um PMTUD-Verhalten zu sehen.
Jumbo Frames bewusst prüfen: End-to-End MTU ist nur so groß wie das kleinste Glied im Pfad.
Overlay-Overhead berücksichtigen: VXLAN/GRE/IPsec reduzieren die nutzbare MTU im Payload.

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:

BFD down bei Interface up: deutet auf Forwarding-Probleme, asymmetrische Pfade oder Underlay-Instabilität hin.
BFD Flapping: korreliert häufig mit Microbursts, Congestion, QoS/Policer-Fehlern oder intermittierenden L1-Problemen.
BFD ok, aber Traffic kaputt: spricht eher für Policy/ACL/PBR/MTU oder anwendungsspezifische Probleme.

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:

Teilweiser Paketverlust: keine vollständige Down-Situation, sondern z. B. 5–20% Loss in bestimmten Tests.
Flow-Spezifität: manche Quell-/Ziel-Kombinationen sind stabil, andere nicht.
Uneinheitliche Counter: nur ein Member-Link zeigt Drops oder Fehlerzähler.

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.

Tunnel-Endpunkte prüfen: VTEP-to-VTEP Reachability, MTU, ECMP-Pfade, QoS-Klassen.
Control-Plane im Overlay: EVPN-Routen und Type-2/Type-5-Informationen vorhanden, aber Datenpfad fehlt.
Unterlay-Korrelation: Drops/Errors auf Underlay-Uplinks der Leafs korrelieren mit Overlay-Loss.

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

Scope definieren: welche VRF/VLAN/Zone, welche Quellen, welche Ziele, welcher Zeitraum.
Control Plane verifizieren: Neighbors stabil, Route in RIB, Policy korrekt, kein massiver Churn.
Data Plane verifizieren: Route in FIB, Next-Hop aufgelöst, ARP/ND stabil, Counter steigen passend.
Aktive Tests variieren: klein/groß, ICMP/TCP, bidirektional, mehrere Quellen (ECMP entlarven).
Underlay-Counter prüfen: Fehlerzähler, Drops, Queueing, Flaps entlang des Pfades, zeitlich korreliert.
MTU gezielt testen: DF/PMTUD, Overlay-Overhead, kleinste MTU im Pfad finden.
BFD/Health Signals nutzen: BFD-Flaps oder Down-Events als Forwarding-Beleg, nicht nur Protokollstatus.

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:

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.