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

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:

• Site-Isolation: Ein einzelner Kundenstandort (eine PE-CE Anbindung) kann keine anderen Sites erreichen.
• Prefix-Isolation: Bestimmte Kundennetze fehlen oder werden nicht mehr verteilt (z. B. nur ein Subnetz oder nur v6).
• One-way-Isolation: Hinweg funktioniert, Rückweg nicht (asymmetrisches Routing, stateful Firewall beim Kunden, fehlender Return-Label).
• Control-plane-Isolation: MP-BGP/VRF hat die Route nicht, oder RT-Match fehlt.
• Data-plane-Isolation: Route ist vorhanden, aber Labels/Forwarding brechen (MTU, Label-Switched-Path, Drops auf Teilpfad).

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

• Welche Sites sind betroffen? Eine Site, mehrere Sites oder alle?
• Welche Richtung? A → B, B → A oder beide?
• Welche Protokolle? Nur IPv4, nur IPv6, oder beides?
• Welche Services? Nur bestimmte Applikationen (MTU/Fragmentation), oder alles?
• Wann begann es? Korrelation mit Change Window, Peering-Event, Backbone-Alarm.

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.

• IGP Reachability: Loopbacks der beteiligten PEs müssen erreichbar sein (v4/v6 getrennt, je nach Design).
• Interface/Optik: Errors (CRC/FEC), Discards, Queue Drops auf den relevanten Backbone-Links.
• ECMP/LAG: per-member Telemetrie prüfen, wenn selektiver Loss/„nur einige Sites“ auftritt.

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“.

• LDP-Status: Nachbarschaften up? Label-Bindings vorhanden?
• RSVP-TE/SR: Tunnels/Policies up? Schutzpfade aktiv?
• MPLS OAM: LSP Ping/Traceroute kann helfen, den Label-Pfad zu verifizieren.

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

• RT fehlt oder falsch: Export RT am Quell-PE oder Import RT am Ziel-PE stimmt nicht.
• RD/VRF-Verwechslung: Route ist im MP-BGP, aber in einer anderen VRF/RD-Instanz.
• Policy/Filter: Route-Policy filtert bestimmte Prefixes, Communities oder AFI/SAFI.

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:

• VPNv4 und VPNv6 getrennt: Session kann up sein, aber eine Address Family ist nicht aktiv oder hat 0 Prefixes.
• Prefix Counts: received/accepted/advertised pro AFI/SAFI in Erwartungsband?
• Churn: ungewöhnlich viele Updates/Withdraws können zu transienter Isolation führen.

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?

• Route vorhanden? Sieht der PE das Customer-Prefix vom CE (statisch, BGP, OSPF, IS-IS)?
• Richtung stimmt? Export vom PE zum CE funktioniert (Default Route oder Site-Routes werden angekündigt)?
• Flaps? CE-Session flapped (BGP), Adjacency instabil (IGP), oder BFD flapped (False Positives/Noise).

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)

$\mathrm{Payload}\_\max =\mathrm{MTU}\_\mathrm{link}-\mathrm{Labels}\times 4-\mathrm{L3}\_\mathrm{header}-\mathrm{L4}\_\mathrm{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

• Queue Drops auf Teilpfaden: nur bestimmte LSPs/Links droppen, daher selektive Reachability.
• LAG-Member defekt: Bundle up, ein Member dropt → nur bestimmte Flows betroffen.
• Policer/ACL hit: eine neue Policy filtert MPLS- oder VPN-Traffic (z. B. ICMP, BFD, TCP/179 oder Kundennetze).
• Asymmetrie: Hinweg ok, Rückweg blackholed (RT-Mismatch nur in einer Richtung, oder Return-Label fehlt).

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

• Wahrscheinlich: PE-CE Issue (Interface, MTU, CE Routing), falsches VRF Binding am PE-Port, lokaler RT-Fehler.
• Nachweis: PE sieht Customer-Routen? VRF am Interface korrekt? MPLS/MP-BGP im Core ok?

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

• Wahrscheinlich: PoP-spezifischer MPLS/IGP/ECMP-Defekt, Route Reflector-Problem für VPNv4/v6, lokale Policy-Änderung.
• Nachweis: RR-Connectivity, Prefix Counts pro RR/PoP, LSP-OAM zwischen betroffenen PEs.

Muster: IPv4 ok, IPv6 isoliert (oder umgekehrt)

• Wahrscheinlich: VPNv6 AFI/SAFI nicht korrekt aktiviert, v6 RTs fehlen, v6 CE-Routing fehlt, ICMPv6/PMTUD-Probleme.
• Nachweis: VPNv6 Prefixes in VRF vorhanden? v6 MPLS/Transport ok? v6 Policies/QoS identisch?

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

• Wahrscheinlich: MTU/Fragmentation, Policer auf größeren Paketen, ECMP-Teilpfad dropt Bursts.
• Nachweis: large vs. small Probes, Queue Drops, LAG-member Telemetrie.

Muster: Nur eine Richtung funktioniert (one-way)

• Wahrscheinlich: asymmetrische RT-Konfiguration, Return-Pfad über anderen PE/VRF, stateful Firewall/NAT beim Kunden, fehlender Label-Return.
• Nachweis: VRF-Routen und Labels in beide Richtungen, bidirektionale Probes, Flow-/Counter-Korrelation.

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:

• RT/RD-Korrektur: Import/Export RT konsistent setzen; Änderung mit Prefix Counts und Reachability validieren.
• PE-CE Stabilisierung: CE-Session fixen (BGP/IGP), Interface/Optik/Errors beheben, VLAN/VRF-Bindung korrigieren.
• MTU Standardisierung: MTU an CE/PE/Backbone konsistent, Label-Overhead einplanen, PMTUD nicht blocken.
• Partial Failure isolieren: defektes LAG-Member entfernen, congested Link entlasten (TE), Policer/ACL korrigieren.
• Graceful Changes: bei größeren Eingriffen Traffic drainen (Graceful Shutdown), um Drops durch Rehashing zu vermeiden.

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.

• Zeitlinie (UTC): Beginn, erste Detektion, Mitigation, Recovery, Stabilitätsfenster.
• Service-Identität: VPN/VRF-Name, RD, Import/Export RTs, betroffene Sites (PE/CE Identitäten).
• Routing-Snapshots: VRF-Routen (v4/v6), MP-BGP Status, Prefix Counts (received/accepted/advertised).
• Transport-Snapshots: PE-Loopback Reachability, MPLS/LSP Status, LSP OAM Ergebnisse (falls genutzt).
• Data-Plane: Interface/Queue Drops, LAG-member Counters, Errors/FEC/CRC, Policer/ACL Hits.
• Probes: bidirektionale Tests, multi-flow (ECMP), small vs. large (MTU-Indiz).

Runbook-Checkliste: „Customer Isolated“ in MPLS L3VPN

• Scope: eine Site oder mehrere? Richtung? v4/v6?
• Underlay: PE-Loopbacks erreichbar? keine Errors/Drops im Core?
• MPLS: LDP/RSVP/SR ok? LSP OAM (RFC 4379) erfolgreich?
• VPN-Control-Plane: Route in richtiger VRF? RT-Import/Export korrekt? VPNv4/VPNv6 getrennt geprüft?
• PE-CE: Customer-Routen gelernt? CE-Session stabil? VRF-Binding am Interface korrekt?
• MTU: Label-Overhead berücksichtigt? large vs. small Tests?
• Data Plane: Queue Drops/Member-Errors/ACL-Policer Hits?
• Validation: nach Fix End-to-End-Probes, Prefix Counts, Drops stabilisieren, dann erst „All Clear“.

Outbound-Ressourcen

• RFC 4364 (BGP/MPLS IP Virtual Private Networks – L3VPN Grundlagen)
• RFC 3031 (MPLS Architecture)
• RFC 4379 (Detecting MPLS Data Plane Failures – LSP Ping/Traceroute)
• RFC 4271 (BGP-4 – Basis für MP-BGP-Verständnis)
• RFC 5880 (BFD – schnelle Failure Detection, häufig in PE-CE/IGP genutzt)
• RFC 2991 (Multipath Issues – ECMP-Effekte, relevant bei selektiver Isolation)

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.