Site icon bintorosoft.com

MPLS L3VPN Troubleshooting: „Customer Isolated“ debuggen (Runbook)

Red Snapper

MPLS L3VPN Troubleshooting gehört zu den Standardaufgaben im Provider-NOC – und gleichzeitig zu den frustrierendsten, wenn Kunden melden: „Customer Isolated“. Gemeint ist fast immer dasselbe Symptom: Ein Standort oder eine ganze Kundendomäne ist plötzlich von anderen Sites in derselben VPN nicht mehr erreichbar. Oft wirkt es selektiv (nur eine Richtung, nur bestimmte Prefixes, nur IPv6), manchmal vollständig (keine Reachability, keine ARP/ND-Auflösung, kein Routing). Der größte Fehler im Incident ist, sofort in „BGP ist kaputt“ oder „MPLS ist kaputt“ zu springen. In einer MPLS L3VPN sind die Abhängigkeiten mehrschichtig: Underlay (IGP/Transport), MPLS-Label-Switched-Path (LDP/RSVP/SR), Provider Edge (VRF, RD/RT, MP-BGP), Customer Edge (PE-CE Routing, VLAN, MTU), und zuletzt die Datenebene (FIB/Label-Stack, ECMP, QoS, Drops). Ein gutes Runbook reduziert das Problem auf eine klare Kette aus Nachweisen: Was fehlt – Route, Label, Forwarding oder Return Path? Dieser Artikel liefert ein praxistaugliches Runbook, um „Customer Isolated“ im MPLS L3VPN systematisch zu debuggen, ohne Zeit mit unproduktiven Vermutungen zu verlieren.

Begriffsklärung: Was „Customer Isolated“ technisch meist bedeutet

„Customer Isolated“ ist keine standardisierte Fehlermeldung, sondern eine operative Beschreibung. Häufige Interpretationen im MPLS L3VPN-Betrieb:

Als technischer Rahmen: MPLS Architektur ist in RFC 3031 beschrieben, BGP/MPLS IP VPNs (L3VPN) in RFC 4364. Diese Dokumente sind hilfreich, um Begriffe wie VRF, RD/RT, MP-BGP und Label-Stack korrekt einzuordnen.

Runbook-Strategie: Von außen nach innen – und immer in Nachweisen denken

Im Incident sind zwei Dinge entscheidend: Zeit und Klarheit. Dieses Runbook folgt einem einfachen Prinzip: Sie prüfen zuerst, ob es ein globales Problem ist oder nur eine Site, und dann arbeiten Sie die Kette Underlay → MPLS → VPN-Control-Plane → PE-CE → Data Plane ab. Jede Stufe liefert einen eindeutigen „Pass/Fail“-Nachweis, sodass Sie nicht gleichzeitig an fünf Stellen suchen.

Schritt 0: Scope und Impact schnell klassifizieren

Ein schneller Scope verhindert den Klassiker: ein lokaler CE-Fehler wird als Backbone-Outage eskaliert – oder ein Underlay-Problem wird fälschlich als VRF/RT-Thema behandelt.

Schritt 1: Underlay-Gesundheit prüfen (ohne Underlay keine VPN)

Auch wenn „MPLS L3VPN“ ein Service ist: Ohne stabile Transportkonnektivität zwischen PEs ist jede weitere Analyse wertlos. Ziel dieses Schritts ist, zu verifizieren, dass die beteiligten PEs sich im Underlay erreichen, und dass es keine offensichtlichen Drops/Errors gibt.

Wenn der Underlay-Ping zwischen PE-Loopbacks instabil ist, ist „Customer Isolated“ meist eine Folge, nicht die Ursache.

Schritt 2: MPLS Transport prüfen (Labels, LSP, LDP/RSVP/SR)

Der nächste Nachweis ist die Label-Switched-Path-Ebene: Können Pakete mit Label-Stack zuverlässig zwischen den PEs laufen? Abhängig vom Netzdesign nutzen Sie LDP, RSVP-TE oder Segment Routing. Typische Fehlerbilder sind „IGP ok, MPLS nicht“.

Für MPLS OAM ist RFC 4379 (LSP Ping/Traceroute) eine sehr nützliche Referenz, weil sie beschreibt, wie man LSP-Pfade unabhängig von klassischem IP-Traceroute validiert.

Schritt 3: VPN-Control-Plane prüfen (MP-BGP, VRF, RD/RT)

Wenn Underlay und MPLS ok sind, liegt „Customer Isolated“ sehr häufig in der VPN-Control-Plane: Routen sind nicht in der VRF, RTs matchen nicht, oder MP-BGP verteilt nicht korrekt. Hier ist die wichtigste Frage: Hat der Ziel-PE die Route des Quell-Customer-Prefixes in der richtigen VRF?

VRF und Route Targets (RT) als häufigste Ursache

Die Rolle von RD/RT und MP-BGP in L3VPN ist in RFC 4364 gut beschrieben. In der Praxis lohnt es sich, RTs als „Schlüssel“ zu betrachten: Ohne korrekten Import/Export ist eine Site logisch isoliert, obwohl Transport funktioniert.

MP-BGP Session Health (VPNv4/VPNv6)

Ein häufiger Dual-Stack-Pitfall: VPNv4 läuft, VPNv6 nicht, weil nur IPv4-Address-Families aktiviert sind oder Policies v6 anders behandeln. Daher immer prüfen:

Schritt 4: PE-CE Ebene prüfen (Routing, VLAN, MTU, BFD)

Wenn die VPN-Routenverteilung korrekt aussieht, rutscht die Ursache oft an den Rand: CE-Routing, Interface-Fehler, VLAN/Tagging oder MTU. Gerade bei „Site isolated“ ist der CE-Link ein Hotspot für stille Degradationen.

PE-CE Routing: Was ist auf dem PE tatsächlich gelernt?

MTU am CE-Link und im VPN: „Alles pingt, aber Anwendungen brechen“

MTU-Probleme sind in MPLS L3VPN besonders tückisch, weil MPLS-Labels Overhead erzeugen. Wenn die Datenebene plötzlich ein größeres Label-Stack hat (z. B. zusätzliche Labels für VPN + TE + Entropy), kann eine vorher „gerade so passende“ MTU brechen. Das äußert sich häufig als „Customer Isolated“, obwohl es eigentlich ein Größenproblem ist.

Vereinfachte MTU-Überlegung mit Label-Overhead (MathML)

Payload_max = MTU_link − Labels×4 − L3_header − L4_header

Diese Formel ist eine Vereinfachung, aber sie macht den Effekt greifbar: Mehr Labels bedeuten weniger nutzbare Payload, wenn die physische MTU nicht angepasst ist.

Schritt 5: Data-Plane Beweis – Route vorhanden, aber Forwarding dropt

Der kritischste Fall ist: Control Plane sieht gut aus (Route in VRF, Labels vorhanden), aber der Kunde ist trotzdem isoliert. Dann ist es fast immer ein Data-Plane-Problem: Drops/Queues, fehlerhafte FIB-Programmierung, ECMP-Partial Failure oder ein stiller ACL/Policer.

Data-Plane Indizien, die „Isolation“ erklären

Schritt 6: Spezifischer Debug für „Customer Isolated“ Muster

In der Praxis wiederholen sich Muster. Dieser Abschnitt ordnet typische Symptome konkreten Ursachen zu, damit das NOC schneller „die richtige Schublade“ findet.

Muster: Nur eine Site isoliert, alle anderen Sites ok

Muster: Mehrere Sites isoliert, aber nur in einer Region/PoP

Muster: IPv4 ok, IPv6 isoliert (oder umgekehrt)

Muster: Ping geht, aber Anwendungen/TCP brechen (selektiv)

Muster: Nur eine Richtung funktioniert (one-way)

Operative Lösungen: Häufige Fixes und sichere Mitigation

Nachweis ist das eine, Mitigation das andere. Im Provider-Alltag müssen Fixes schnell, reversibel und risikoarm sein. Bewährte Maßnahmen, abhängig von der Ursache:

Evidence Pack: Pflichtdaten für RCA und Eskalation

Ein „Customer Isolated“ Incident wird schnell eskalationsintensiv. Ein standardisiertes Evidence Pack spart Zeit, verbessert die RCA-Qualität und reduziert Ping-Pong mit Field/Vendor/Peer.

Runbook-Checkliste: „Customer Isolated“ in MPLS L3VPN

Outbound-Ressourcen

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