MPLS Troubleshooting: LDP, Label Switched Paths und PHP Issues

MPLS Troubleshooting ist in Provider-, Campus-Backbone- und WAN-Umgebungen eine der schnellsten Möglichkeiten, große Störungen sauber einzugrenzen, weil MPLS (Multiprotocol Label Switching) oft das „Transportgewebe“ für L3VPN, L2VPN, Traffic Engineering oder Segmentierung bildet. Wenn MPLS hakt, wirkt das nach außen häufig wie ein Routing-, Firewall- oder Applikationsproblem: einzelne Sites sind nicht erreichbar, nur bestimmte VPNs brechen weg, Voice/Video bekommt plötzlich Jitter oder ein kompletter Bereich ist „schwarz“, obwohl Interfaces up sind und IGP/ BGP scheinbar stabil laufen. Genau deshalb braucht es ein systematisches Vorgehen: Sie prüfen zuerst das Underlay (IGP/Next-Hop-Reachability), dann LDP (Label Distribution Protocol) und seine Sessions, danach die Label Switched Paths (LSPs) im Datenpfad und erst zum Schluss Spezialthemen wie PHP (Penultimate Hop Popping), TTL-Propagation oder QoS/EXP/TC-Handling. Dieser Artikel zeigt praxisnahes MPLS Troubleshooting für LDP, Label Switched Paths und typische PHP Issues – inklusive High-Signal Indizien, Beweisketten und Fixes, die nicht nur „kurz wieder grün“ machen, sondern dauerhaft stabilisieren.

Grundlagen für die Fehlersuche: Underlay, Control Plane, Data Plane

In MPLS-Designs trennen Sie im Troubleshooting konsequent zwischen Underlay (IP-Routing), Control Plane (Label-Verteilung) und Data Plane (Label-Switching). Die häufigste Zeitverschwendung entsteht, wenn Teams direkt in Labels eintauchen, obwohl das Underlay einen Next Hop nicht mehr sauber erreicht oder IGP-Sicht inkonsistent ist. Umgekehrt kann IGP perfekt sein, während ein einzelner LDP-Nachbar down ist und dadurch Labels fehlen.

• Underlay: IGP (OSPF/IS-IS), Interfaces, MTU, ECMP, Next-Hop-Reachability
• Control Plane: LDP Sessions, Label Bindings, Label Retention, Targeted LDP (falls genutzt)
• Data Plane: LFIB/Label Forwarding Table, tatsächlicher LSP-Pfad, Drops/Errors/TTL/PHP-Verhalten

Für Norm- und Hintergrundwissen sind die Spezifikationen hilfreich: MPLS Architektur in RFC 3031, Label-Stack-Encoding in RFC 3032 und LDP in RFC 5036.

Symptome richtig lesen: Was „typisch MPLS“ ist

Viele MPLS-Störungen haben charakteristische Muster. Wenn Sie diese Muster früh erkennen, können Sie die Fehlerdomäne sofort eingrenzen.

• Nur VPN-Traffic betroffen, Underlay ok: häufig Label/VRF/BGP-VPN-Probleme, weniger Interface/IGP
• Nur ein Transit-Segment betroffen: oft LDP Adjacency down oder Label-Switching-Problem auf einem Knoten
• „Einige Ziele gehen, andere nicht“: fehlende Labels für bestimmte Präfixe, ECMP/Flow Pinning auf „schlechten“ Membern
• Plötzlicher MTU-/Fragmentations-Charakter: kleine Pakete ok, große hängen (MPLS Overhead, QoS, Tunnel-Kombinationen)
• Traceroute wirkt „komisch“: TTL-Propagation/PHP kann Hop-Sichtbarkeit verändern

Beweiskette im MPLS Troubleshooting: Erst beweisen, dann ändern

Ein praxiserprobtes Vorgehen ist eine kurze, reproduzierbare Beweiskette. Sie sparen Zeit, weil Sie nicht „im Kreis“ debuggen.

• Beweis 1: Underlay-IP-Reachability zwischen LSRs (Label Switch Routern) ist stabil (Ping/IGP/Adjacency)
• Beweis 2: LDP-Nachbarschaften sind up (Discovery + Session), und Label Bindings existieren
• Beweis 3: LFIB/Label Forwarding Table zeigt einen konsistenten Label-Swap/Pop-Pfad
• Beweis 4: Data Plane funktioniert: Traffic mit Labels wird korrekt weitergeleitet, Drops/Errors sind nicht erhöht
• Beweis 5: Spezialthemen (PHP, TTL, QoS/EXP/TC) passen zum Design und erzeugen keine Side Effects

LDP Troubleshooting: Discovery, Session, Label Bindings

LDP ist in vielen MPLS-Backbones die Control Plane für Label-Verteilung. LDP hat zwei große Phasen: Discovery und Session. Discovery nutzt in der Regel Link-local Hellos (multicast) auf direkten Links. Die Session selbst läuft über TCP (typisch Port 646) und ist deshalb empfindlich für Filter, MTU/PMTUD-Probleme und Control-Plane-Overload.

Wenn der LDP Neighbor gar nicht erscheint

• Interface/Link: Link up, korrekte VLAN/Trunk-Konfiguration, keine L2-Filter, die LDP Hellos verhindern
• IGP/Adressierung: korrekte IPs, keine Duplicate IPs, IGP-Adjacency stabil (nicht zwingend für Discovery, aber oft korreliert)
• Multicast/Control-Plane Policies: Discovery-Hellos können durch falsche Filter/Policer verschwinden
• Targeted LDP vs. Link LDP: wenn Targeted LDP genutzt wird, erwarten Sie Discovery auf IP-Ebene, nicht auf Link-local Multicast

Neighbor sichtbar, aber LDP Session kommt nicht hoch

Wenn Discovery funktioniert, aber die Session nicht, ist TCP der häufigste Engpass. Denken Sie wie beim BGP-Session-Debugging: TCP muss stabil sein, sonst bleibt LDP instabil.

• TCP/646: ACLs/Firewalls/Control-Plane-Policer prüfen
• LDP Transport Address: stimmt die Transportadresse (häufig Loopback) und ist sie im IGP erreichbar?
• Authentication: falls LDP Auth aktiviert ist, Key/Mode konsistent
• MTU/PMTUD: TCP kann bei großen Segments hängen; ICMP-Feedback nicht blocken
• Timer/Keepalives: aggressive Timer + Loss/CPU-Spikes führen zu Flaps

Session up, aber Labels fehlen oder sind „inkonsistent“

Das ist ein besonders häufiger Zustand: Alles sieht grün aus, aber ein Teil der Präfixe hat keine Label-Bindings. Die Ursachen sind oft Design- oder Policy-bedingt, nicht „LDP kaputt“.

• IGP synchronisiert nicht wie erwartet: LDP bindet Labels typischerweise an IGP-FECs (Forwarding Equivalence Classes). Wenn IGP-Routen fehlen, fehlen Labels.
• Label Retention Mode: liberal vs. conservative retention (plattformabhängig) beeinflusst, welche Labels Sie sehen; das ist nicht per se ein Fehler.
• Filtering/Policies: MPLS/LDP kann für bestimmte Interfaces/Areas/Levels deaktiviert sein; dann fehlen Labels in Segmenten.
• ECMP und per-next-hop Labels: je nach Plattform kann pro Next Hop ein anderes Label gelten; bei Drift wirkt das wie „sporadisch“.

Label Switched Paths (LSPs) prüfen: LFIB, Swap/Pop, End-to-End

Der Datenpfad in MPLS ist die Label Forwarding Information Base (LFIB). Im Troubleshooting möchten Sie nicht nur wissen, dass Labels „existieren“, sondern wie sie tatsächlich geswitched werden: welcher In-Label wird zu welchem Out-Label, über welches Out-Interface und zu welchem Next Hop. Eine konsistente LFIB ist der beste Beweis, dass ein LSP im Kern funktionieren sollte.

Der praktische LSP-Check

• Ingress (LER): wird ein Label korrekt „pushed“ (Label Stack) und passt es zur FEC?
• Transit (LSR): wird das Label korrekt „geswapped“ und ist der Next Hop plausibel?
• Egress (LER): wird korrekt „popped“ oder erwartet der Egress ein bestimmtes Label (implicit-null/explicit-null)?

Wenn Ihre Plattform MPLS OAM unterstützt, sind LSP-Ping und LSP-Traceroute sehr hilfreiche Werkzeuge, weil sie den Label-Pfad sichtbar machen, ohne dass Sie auf reine IP-Traceroute-Interpretation angewiesen sind. Für Hintergrundwissen zu MPLS OAM sind Dokumente rund um LSP Ping/Traceroute (z. B. auf IETF-Ebene) nützlich; ein Einstieg ist die Suche im RFC Editor nach „LSP Ping“.

Wenn LSP „teilweise“ kaputt ist

Teildefekte sind typisch: Ein einzelner Transit-LSR hat Drops oder eine falsche LFIB. Dann scheitert nur ein Teil des Verkehrs – besonders bei ECMP. In solchen Fällen ist die Kombination aus LFIB-Check, Interface Counters und einem gezielten Pfadvergleich entscheidend.

• Interface Errors: CRC/Symbol Errors (physisch) vs. Output Drops (Congestion/Queueing)
• ECMP/Hashing: nur Flows auf einem Pfad betroffen → „schlechter Member“
• MTU-Fallen: große Frames droppen auf einem Segment → TCP Retransmissions, selektive Timeouts

PHP Issues: Penultimate Hop Popping richtig interpretieren

Penultimate Hop Popping (PHP) bedeutet, dass der vorletzte Router (penultimate hop) das äußerste Label entfernt, bevor der Traffic den Egress erreicht. Das reduziert Load auf dem Egress (weniger Label-Processing) und ist in vielen LDP-Umgebungen Standard. PHP nutzt häufig das Konzept des „implicit-null“-Labels: Der Egress signalisiert dem Upstream, dass das Label vor dem Egress gepoppt werden soll. Das klingt harmlos, kann aber in bestimmten Designs Side Effects erzeugen.

Typische PHP-Fehlerbilder

• Egress erwartet Label, bekommt IP: selten, aber möglich bei inkonsistentem Label-Handling oder falscher Erwartung im Service-Design
• QoS/EXP/TC Mapping bricht: wenn QoS-Markierungen im MPLS-Header gebraucht werden, kann PHP Informationen „zu früh“ entfernen
• Troubleshooting-Visibility: TTL-Propagation und PHP verändern, wie Traceroute-Hops sichtbar werden; Teams interpretieren Pfade falsch
• Interaktionen mit VPN/Services: bei gestapelten Labels (Transport + VPN) muss klar sein, welches Label wo gepoppt wird

Implicit-null vs. Explicit-null: wann explicit-null hilft

Wenn Sie PHP vermeiden wollen, kann explicit-null genutzt werden: Der Egress fordert dann, dass der Upstream nicht poppt, sondern ein „null“-Label weitergibt. Dadurch bleibt der MPLS-Header bis zum Egress erhalten, was z. B. für QoS, TTL-Transparenz oder bestimmte OAM-Mechaniken nützlich sein kann. Das ist eine Designentscheidung und sollte bewusst pro Service/AFI/SAFI getroffen werden, nicht als „Incident-Hack“.

PHP und TTL: warum Traceroute manchmal „lügt“

MPLS kann TTL aus dem IP-Header übernehmen oder separat führen (TTL Propagation vs. No-Propagation). In Kombination mit PHP sehen Sie in Traceroutes manchmal weniger oder andere Hops. Das ist nicht zwingend ein Fehler, aber ein häufiges Missverständnis in Incidents. Stellen Sie sicher, dass Ihr Team weiß, welches TTL-Modell im Netz aktiv ist und wie MPLS OAM/Traceroute damit interagiert.

Die häufigsten Root Causes in MPLS/LDP-Netzen

Wenn Sie häufig MPLS Störungen sehen, lohnt es sich, einen Root-Cause-Katalog zu pflegen. Die folgenden Ursachen sind in der Praxis besonders häufig.

• IGP Drift: IGP-Adjacency flaps, falsche Metriken, falsche Areas/Levels → LDP Bindings ändern sich, LSPs wandern
• LDP Session Flapping: TCP/646 instabil durch Loss, CoPP, Firewall, MTU/PMTUD
• Interface MTU inkonsistent: MPLS Overhead reduziert effektive Payload; große Pakete droppen selektiv
• ECMP „schlechter Pfad“: ein Next Hop hat Errors/Drops; nur Flows auf diesem Pfad betroffen
• PHP/QoS Mismatch: EXP/TC-Design erwartet MPLS-Header am Egress, PHP entfernt zu früh
• Targeted LDP Fehlkonfig: falsche Transportadresse, falsche IGP-Reachability, Filter auf TCP/646
• Policy/Feature Drift: MPLS auf einem Interface deaktiviert, LDP Discovery unterdrückt, oder Labels für bestimmte Präfixe gefiltert

Praktische Tests: Was Sie im Incident wirklich messen sollten

In produktiven MPLS-Backbones ist die größte Falle, nur „Ping“ zu machen. Ping zeigt IP-Reachability, aber nicht, ob der MPLS-Datenpfad korrekt arbeitet. Nutzen Sie daher Tests, die explizit Labels und Pfade sichtbar machen.

• Underlay-Ping: zwischen Loopbacks/Transportadressen (beweist IGP- und IP-Pfad)
• LDP-Status: Discovery + Session + Bindings (beweist Control Plane)
• LFIB-Check: In-Label → Out-Label/Out-IF (beweist Data Plane Logik)
• LSP Ping/Traceroute: belegt den Label-Pfad End-to-End (wenn verfügbar)
• Counter-Vergleich pro Pfad: Errors/Drops pro Interface und pro ECMP-Member

Runbook-Baustein: MPLS Troubleshooting in 15 Minuten

• Minute 0–3: Scope klären: Welche Services betroffen (L3VPN/L2VPN/Internet-Transit)? Ist Underlay-IP-Reachability zwischen relevanten Loopbacks stabil?
• Minute 3–6: LDP prüfen: Neighbor Discovery sichtbar? LDP Session up? Transportadresse erreichbar? TCP/646 Filter/CoPP Hinweise?
• Minute 6–9: Label Bindings/LFIB prüfen: existieren Labels für betroffene FECs? Sind Swap/Pop-Operationen konsistent entlang des Pfads?
• Minute 9–12: Data Plane verifizieren: LSP Ping/Traceroute (wenn möglich), Interface Counters (Errors/Drops), ECMP-Pfade vergleichen, MTU-Fallen ausschließen.
• Minute 12–15: PHP/Edge Cases prüfen: implicit-null/explicit-null passend? QoS/EXP/TC Erwartungen? TTL/Traceroute-Interpretation korrekt? Danach minimalen Fix anwenden und mit denselben Tests verifizieren.

Stabile Baselines: Damit MPLS im Betrieb „langweilig“ bleibt

• Underlay-Hygiene: IGP stabil, klare Metriken, saubere ECMP-Policies, Interface Health Monitoring
• LDP-Standards: konsistente Transportadressen (Loopbacks), Auth-Policy (falls genutzt), saubere CoPP-Profile für TCP/646
• MTU-Management: L2/L3 MTU konsistent, MPLS Overhead einkalkuliert, PMTUD/ICMP nicht blind blocken
• PHP-Governance: bewusst entscheiden, wo PHP erwünscht ist und wo explicit-null nötig ist (QoS/OAM/Visibility)
• Observability: LDP Session Flaps, Label Binding Counts, LFIB Consistency Checks, Drops/Errors pro ECMP-Pfad

Weiterführende Quellen für Standards und Praxis

• RFC 3031 für MPLS Architektur und Grundbegriffe
• RFC 3032 für MPLS Label Stack Encoding
• RFC 5036 für LDP (Discovery, Sessions, Label Distribution)
• RFC 1191 für Path MTU Discovery unter IPv4 (relevant bei MPLS Overhead und MTU-Blackholes)
• RFC 8201 für Path MTU Discovery unter IPv6
• Wireshark Dokumentation für Protokollanalyse (LDP über TCP, MPLS Label Stack, TTL/DSCP/EXP-Indizien)
• tcpdump Manpage für effiziente Captures und Filterpraxis 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.