Site icon bintorosoft.com

MPLS Troubleshooting: LDP, Label Switched Paths und PHP Issues

Red Snapper

Dynamic infographic style image depicting the flow of data through a network, with arrows and icons representing different devices --ar 16:7 --style raw --stylize 250 --v 6.1 Job ID: ae452118-d163-4f61-8e30-4e03480abf7a

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

Runbook-Baustein: MPLS Troubleshooting in 15 Minuten

Stabile Baselines: Damit MPLS im Betrieb „langweilig“ bleibt

Weiterführende Quellen für Standards und Praxis

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