Segment Routing Troubleshooting: SRGB, SID Allocation, Policies

MPLS L3VPN Debugging gehört zu den anspruchsvollsten Aufgaben im Provider- und Enterprise-WAN-Betrieb, weil die Störung häufig „wie Routing“ aussieht, die Ursache aber in der Segmentierung liegt: VRFs trennen Routing-Tabellen, RD/RT definieren, wie VPN-Routen eindeutig werden und wie sie zwischen Standorten importiert/exportiert werden. Wenn hier etwas schiefgeht, ist das Fehlerbild oft selektiv und damit tückisch: Standort A erreicht Standort B nicht, aber C schon; nur ein Subnetz fehlt; oder plötzlich „leaken“ fremde Präfixe in ein VPN, wodurch Firewalls, NAT oder Applikationen unerwartet reagieren. Genau in solchen Situationen hilft ein systematisches Vorgehen: Sie trennen Underlay (MPLS/Transport) von Overlay (BGP VPNv4/VPNv6), prüfen VRF-Instanzen und deren Interfaces, validieren RD/RT-Logik und kontrollieren Route Target Leaks mit harten Nachweisen. Dieser Artikel zeigt Ihnen ein praxisbewährtes Debugging-Framework für MPLS L3VPN: Wie Sie VRFs, RD/RT und Route Target Leaks sauber identifizieren, wie Sie mit Evidence statt Vermutung arbeiten und wie Sie nachhaltige Fixes umsetzen, ohne im Blindflug an Policies oder Labels zu drehen.

Architekturmodell: Underlay, Overlay und VRF als drei separate Fehlerdomänen

Ein stabiler L3VPN-Betrieb entsteht aus drei Schichten, die Sie im Troubleshooting strikt trennen sollten. Wenn Sie diese Trennung nicht konsequent einhalten, verlieren Sie Zeit: Sie debuggen VPN-Routen, obwohl das Underlay keine LSPs hat – oder Sie optimieren LDP, obwohl die eigentliche Ursache ein falsches Route Target in einer VRF ist.

• Underlay: IP-Routing (OSPF/IS-IS/BGP), MPLS-Transport (LDP/RSVP/SR), Label Switched Paths (LSPs) bis zum Egress-PE
• Overlay: MP-BGP für VPNv4/VPNv6 (Control Plane der VPN-Routen), Next-Hop-Reachability, Label-Distribution für VPN-Labels
• VRF-Ebene: getrennte Routing-Tabellen pro Kunde/Segment, RD für Eindeutigkeit, RT für Import/Export, ggf. VRF-Leaking

Für MPLS-Grundlagen sind RFC 3031 (MPLS Architecture) und RFC 3032 (Label Stack Encoding) hilfreich. Für MPLS L3VPN ist RFC 4364 (BGP/MPLS IP VPNs) die zentrale Referenz.

VRF verstehen: Warum ein „Ping im globalen Routing“ nichts beweist

Eine VRF (Virtual Routing and Forwarding) ist eine eigenständige Routing-Instanz mit eigener RIB/FIB. Das bedeutet operativ: Ein Prefix kann in VRF-A existieren und in VRF-B nicht – selbst auf dem gleichen Router. Und ein „ping“ im globalen Routing beweist keine Erreichbarkeit im VPN, weil die Forwarding-Entscheidung im VRF-Kontext fällt.

• Interface-Zuordnung: Ein CE-Link muss der richtigen VRF zugeordnet sein. Eine falsche Zuordnung wirkt wie „VPN down“.
• Default Route pro VRF: VRF kann (und soll) eigene Defaults haben; falsche Defaults erzeugen Blackholes oder Asymmetrien.
• Route Leaks: VRF-Leaking ist bewusst möglich, aber extrem fehleranfällig, wenn RTs oder Policies zu breit sind.

RD und RT: Eindeutigkeit vs. Policy – nicht verwechseln

Ein häufiges Missverständnis ist, RD (Route Distinguisher) und RT (Route Target) als „das gleiche“ zu betrachten. In der Praxis haben sie unterschiedliche Rollen:

• RD: macht identische IPv4/IPv6-Präfixe aus verschiedenen VRFs eindeutig, indem es sie zu VPNv4/VPNv6 „aufbläst“. RD ist primär ein Eindeutigkeitsmerkmal, nicht die Policy für Reachability.
• RT: steuert, welche VPN-Routen in eine VRF importiert oder aus ihr exportiert werden. RT ist die Policy-Schnittstelle und damit die häufigste Root Cause für „falsche“ oder fehlende Routen.

In RFC 4364 ist diese Trennung explizit beschrieben: RD für Uniqueness, RT als BGP Extended Community für Import/Export-Steuerung.

Typische Fehlerbilder im MPLS L3VPN Betrieb

MPLS L3VPN-Fehler sind selten „alles tot“. Meist sind es selektive Muster, die sehr viel diagnostische Information enthalten, wenn Sie sie richtig lesen.

• Nur ein Standort fehlt: häufig CE-Interface in falscher VRF, fehlende VRF-Route, eBGP/OSPF zum CE down, oder RT Import/Export fehlt nur auf einem PE
• Nur ein Subnetz fehlt: Prefix-Filter/Route-Map am CE oder PE, Redistribution-Fehler, oder ein RT wird nur für Teile gesetzt
• Fremde Routen tauchen in der VRF auf: Route Target Leak (zu breiter Import, falsches Shared-Services-Design)
• VPN-Routen sind da, aber Traffic blackholed: VPN-Label fehlt/inkonsistent, Next Hop nicht erreichbar, Underlay-LSP bricht, oder MTU/Fragmentation im Transport
• Nach Changes „sporadisch“: Control-Plane-Churn (RR/MP-BGP), unterschiedliche RR-Cluster/Policies, oder nicht konsistente Templates über PEs

Beweiskette: So debuggen Sie L3VPN ohne Blindflug

Ein professionelles Debugging beginnt mit einer Beweiskette, die jede Schicht separiert. Das vermeidet den Klassiker, bei dem Teams „am falschen Ende“ optimieren.

Schritt 1: Underlay bis zum PE-Egress beweisen

• Ist das IGP/Underlay stabil und sind die PEs untereinander erreichbar (Loopbacks)?
• Existiert ein MPLS-Transportpfad (LSP) zwischen Ingress-PE und Egress-PE (LDP/RSVP/SR, je nach Design)?
• Gibt es Hinweise auf selektive Drops (ECMP „schlechter Pfad“, CRC/Errors, MTU-Fallen)?

Wenn das Underlay nicht stabil ist, ist jedes VRF/RT-Debugging sekundär. Für LDP als häufiges Underlay-Control-Plane-Protokoll ist RFC 5036 relevant.

Schritt 2: MP-BGP Overlay beweisen

• Laufen BGP-Sessions zwischen PEs und RRs stabil (kein Flapping, keine max-prefix Events)?
• Werden VPNv4/VPNv6 Address Families tatsächlich ausgetauscht (AFI/SAFI korrekt)?
• Ist der BGP Next Hop (typisch PE-Loopback) im Underlay erreichbar?

Die BGP-Grundlagen stehen in RFC 4271. Route Reflection (wenn RRs im Einsatz sind) ist in RFC 4456 beschrieben.

Schritt 3: VRF-Routing beweisen

• Ist das CE-Interface im richtigen VRF gebunden und ist der VRF-Routing-Table plausibel?
• Existieren die benötigten CE-Routen (connected/static/IGP/eBGP) und werden sie exportiert?
• Werden die erwarteten Remote-Routen importiert (RT Match)?

VRF Debugging im Detail: Die drei schnellsten Fehlerquellen

Falsche VRF-Bindung am Interface

Das ist banal, aber extrem häufig – vor allem nach Migrationen, Template-Drift oder wenn CE-Ports umgesteckt wurden. Der Link ist up, IP stimmt, aber die Pakete landen in der falschen Tabelle.

• Indiz: CE kann das PE-Interface pingen, aber Remote-Sites sind nicht erreichbar; oder Remote-Routen sind im „falschen“ VRF sichtbar.
• Nachweis: Routing/ARP/Neighbor-Tabellen zeigen Aktivität im falschen VRF-Kontext.
• Fix: Interface korrekt der VRF zuordnen, anschließend CE-Adjacency und VRF-Route Table verifizieren.

CE-PE Routing-Adjacency fehlt oder ist inkonsistent

Wenn CE-PE über OSPF/eBGP läuft, kann die Adjacency zwar up sein, aber Filter/Policies verhindern die richtigen Prefixes. Typisch: Default ist da, spezifische Prefixes fehlen (oder umgekehrt).

• Indiz: Nur ein Teil der Subnetze ist erreichbar; bestimmte Präfixe fehlen im VRF-RIB.
• Nachweis: Adj-RIB-In/Out am PE zeigt gefilterte Prefixes; CE sendet, PE verwirft (oder andersherum).
• Fix: Prefix-Listen/Route-Maps prüfen, Redistribution-Tags sauber setzen, CE-PE Policies versionieren.

VRF Default/Leak-Design ist falsch

Shared-Services (DNS, Proxy, Internet Breakout) werden häufig über VRF-Leaks abgebildet. Das ist legitim, aber riskant. Ein zu breiter Leak kann fremde Routen importieren; ein zu enger Leak kann Shared-Services unsichtbar machen.

• Indiz: DNS/Proxy/Internet geht nicht, obwohl Site-to-Site geht (oder umgekehrt).
• Nachweis: Shared-Services-Präfixe fehlen oder zu viele fremde Präfixe tauchen auf.
• Fix: Leak-Präfixe explizit, minimal und auditierbar halten; keine „import all“-Muster.

RD Debugging: Wann RD wirklich relevant wird

RD ist selten die direkte Root Cause für „Connectivity down“, kann aber sehr relevant sein, wenn identische Präfixe aus mehreren VRFs oder Standorten existieren (z. B. 10.0.0.0/24 in mehreren Tenants). Dann sorgt der RD dafür, dass diese Routen im VPNv4-Universum getrennt bleiben. Probleme entstehen typischerweise bei Migrationen oder bei bewusstem Multihoming/Anycast in VPNs.

• Symptom: „Falsche“ Route gewinnt, obwohl RT korrekt scheint (tatsächlich sind es zwei unterschiedliche VPNv4-NLRIs mit unterschiedlichen RDs).
• Nachweis: In der BGP VPNv4 Tabelle existieren mehrere Einträge für dasselbe IPv4-Präfix mit unterschiedlichen RDs.
• Fix-Richtung: RD-Strategie konsistent halten (z. B. per VRF- oder per PE-Loopback-Pattern), bei Migrationen die Auswirkung auf Bestpath und Import sauber planen.

RT Debugging: Die häufigste Root Cause für fehlende oder falsche VPN-Routen

Route Targets bestimmen, welche VPN-Routen in eine VRF importiert werden. Das ist powerful – und genau deshalb fehleranfällig. Ein einzelnes falsches RT kann eine komplette VPN-Topologie verändern.

RT-Mismatch: Route wird exportiert, aber nicht importiert

• Indiz: Route ist im Ursprung-PE in der VRF vorhanden und wird in VPNv4 exportiert, taucht aber im Ziel-PE nicht in der VRF auf.
• Nachweis: BGP VPNv4 Eintrag zeigt Export-RT(s), Ziel-VRF importiert diese RTs nicht.
• Fix: Import-RTs konsistent machen, idealerweise per Template/Source-of-Truth validieren.

Zu breiter Import: Route Target Leak

Ein Route Target Leak ist operativ und sicherheitstechnisch kritisch: Eine VRF importiert Routen, die nicht zu ihr gehören. Das kann Datenabfluss ermöglichen, aber auch „nur“ Betrieb stören (Traffic geht in falsche Services, Firewalls sehen unerwartete Flows, NAT kollidiert).

• Indiz: Fremde Präfixe erscheinen in einer VRF, die sie nie sehen sollte; plötzlich existieren „neue“ Routen ohne Change im CE.
• Nachweis: Die fremden Routen tragen ein RT, das die VRF importiert. Häufig sind es Shared-Services-RTs, die zu breit verteilt wurden.
• Fix: Import-RTs minimal halten; Shared-Services über dedizierte, eng gefilterte RTs und explizite Prefix-Policies lösen.

Zu breiter Export: Sie leaken selbst

• Indiz: Ihre VRF exportiert mehr Routen als erwartet, z. B. komplette interne Infrastruktur, oder Defaults in falsche Segmente.
• Nachweis: BGP VPNv4 Einträge tragen RTs, die in anderen VRFs importiert werden; Export-Policy ist zu generisch.
• Fix: Export-Policy präzisieren (Prefix-Listen), „Never-Export“ Regeln für Management/Infrastructure etablieren.

Route Target Leaks sicher finden: Muster und Hygiene Checks

RT Leaks lassen sich erstaunlich gut automatisiert erkennen, wenn Sie Baselines definieren. Im Incident helfen zwei Muster besonders:

• Muster 1: „Unerwartete Routen tauchen auf“ – prüfen Sie zuerst Import-RTs und Shared-Services-Konstrukte.
• Muster 2: „Viele VRFs gleichzeitig betroffen“ – häufig ein zentraler Template-Change oder ein RR/Policy-Change im VPNv4-Overlay.

• Hygiene Check: Pro VRF: Liste erlaubter RT Imports/Exports, versioniert und geprüft.
• Hygiene Check: „Top-N neue Routen pro VRF“ nach Changes, um Leaks früh zu erkennen.
• Hygiene Check: Shared-Services-RTs nur mit explizitem Prefix-Set nutzen, nie als „import all“.

VPN-Labels und Next-Hop: Wenn Routen da sind, aber Forwarding nicht geht

Ein klassisches L3VPN-Problem ist: Routen erscheinen korrekt in der VRF, aber Traffic geht ins Blackhole. Dann ist oft nicht RD/RT das Problem, sondern die Forwarding-Kette: Der BGP Next Hop ist nicht erreichbar oder das VPN-Label passt nicht. In MPLS L3VPN besteht der Datenpfad typischerweise aus zwei Labels: äußeres Transport-Label (bis zum Egress-PE) und inneres VPN-Label (zur Ziel-VRF).

• Indiz: VRF-Routen vorhanden, aber keine End-to-End Erreichbarkeit; Drops auf PEs oder fehlende LFIB-Einträge.
• Nachweis: Next-Hop-Reachability (PE-Loopbacks) und Label-Forwarding (LFIB) entlang des Pfades prüfen.
• Fix: Underlay stabilisieren (IGP/LDP), MP-BGP Next Hop korrekt (next-hop-self, RR-Design), Labels konsistent.

VRF, RD/RT und Route Reflection: Die häufigste Skalierungsfalle

In größeren Netzen laufen VPNv4/VPNv6 oft über Route Reflectors. Dann entstehen spezifische Fehlerklassen: RR reflektiert falsche AFI/SAFI, Policies am RR filtern VPN-Routen, oder Next-Hop-Handling ist inkonsistent. Für RR-Grundlagen ist RFC 4456 relevant; für L3VPN bleibt RFC 4364 zentral.

• Indiz: Nur bestimmte Regionen/Clients sehen VPN-Routen, andere nicht.
• Nachweis: VPNv4 Routes am RR vorhanden? Werden sie an alle Clients advertised? Stimmen Import-Policies?
• Fix: AFI/SAFI-Konsistenz, RR-Policies reviewen, Next-Hop-Reachability sicherstellen, max-prefix passend setzen.

PCAP und Forensik: Wann Mitschnitte wirklich helfen

In L3VPN-Incidents sind Captures nicht immer nötig, aber manchmal extrem effizient: insbesondere bei selektiven Drops, MTU-Fallen, oder wenn Sie beweisen müssen, dass Labels/Next-Hops korrekt genutzt werden. Für Analyse-Workflows eignen sich Wireshark und die tcpdump Manpage.

• Label Stack Sichtbarkeit: Transport- und VPN-Label vorhanden? Wird am Egress korrekt gepoppt?
• MTU/Fragmentation: große Pakete droppen nur auf bestimmten Pfaden; TCP Retransmissions steigen.
• Stateful Side Effects: Asymmetrische Pfade über Firewalls/NAT können trotz korrekter RTs Probleme erzeugen.

Runbook-Baustein: MPLS L3VPN Debugging in 15 Minuten

• Minute 0–3: Scope definieren: Welche VRF, welche Sites, welche Präfixe fehlen oder leaken? Underlay-Health grob prüfen (PE-Loopbacks erreichbar, keine großen Flaps).
• Minute 3–6: VRF-Check am Ingress-PE: CE-Interface in richtiger VRF? Lokale CE-Routen vorhanden? Wird der relevante Prefix exportiert?
• Minute 6–9: VPNv4/VPNv6-Overlay: Ist die Route im BGP-VPN-RIB sichtbar? Welche RD/RT trägt sie? Wird sie am Ziel-PE empfangen?
• Minute 9–12: Import/Export prüfen: Import-RT am Ziel korrekt? Gibt es zu breite Imports (Route Target Leak)? Prefix-Policies für Shared-Services kontrollieren.
• Minute 12–15: Data Plane verifizieren: Next-Hop-Reachability (Underlay), Label-Forwarding (Transport/VPN-Label), MTU-Fallen ausschließen. Danach Fix minimal anwenden und mit denselben Präfixen verifizieren.

Sichere Baselines: Damit VRF/RD/RT nicht zur Dauerbaustelle werden

• Source of Truth für RTs: Pro VRF klare Import-/Export-Listen, versioniert, automatisiert validiert.
• Shared-Services sauber modellieren: dedizierte RTs + explizite Prefix-Filter, keine „import all“-Konstrukte.
• RT Leak Monitoring: Alarme auf „unerwartete Präfixe pro VRF“ und plötzliche Route-Count-Sprünge.
• Template-Disziplin: VRF- und PE-Templates verhindern Drift (Interfaces, RD/RT, BGP AFI/SAFI, max-prefix).
• Underlay-Observability: LDP/SR Health, LSP-Verfügbarkeit, ECMP Member Errors/Drops, MTU-Konsistenz.
• Postmortem-Qualität: Evidence sichern (RD/RT der betroffenen Route, Import/Export-Settings, Zeitpunkt/Change-Korrelation).

Weiterführende Quellen für Standards und vertiefende Lektüre

• RFC 4364 für BGP/MPLS L3VPN (VRF, RD, RT, VPNv4/VPNv6 Grundmechanik)
• RFC 3031 für MPLS Architektur (Underlay-/Label-Grundlagen)
• RFC 3032 für MPLS Label Stack Encoding
• RFC 5036 für LDP (häufige Transport-Control-Plane in MPLS-Backbones)
• RFC 4271 für BGP-4 Grundlagen (Sessions/Attributes/Policies)
• RFC 4456 für Route Reflection (relevant bei skalierter VPNv4-Verteilung)
• Wireshark Dokumentation für MPLS/BGP-Forensik (Label Stack, Timing, Drops)
• tcpdump Manpage für effiziente Captures im Incident

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.