MPLS OAM: LSP Ping, Traceroute und Fault Isolation

MPLS OAM (Operations, Administration and Maintenance) ist das Werkzeugset, mit dem du Label Switched Paths (LSPs) im Betrieb überprüfst: Stimmt der Forwarding-Pfad wirklich? Wo endet das Label-Switching? Welcher Hop verursacht Drops oder Fehlleitungen? Dafür sind LSP Ping und MPLS Traceroute die zentralen Methoden. Sie testen nicht „IP-Reachability“, sondern die MPLS-Forwarding-Ebene (LFIB) und helfen dir, Fehler schnell einzugrenzen – besonders bei LDP-, RSVP-TE- oder SR-MPLS-Transport. Dieser Artikel zeigt, wie du LSP Ping/Traceroute auf Cisco nutzt und wie du Fault Isolation systematisch aufbaust.

Warum MPLS OAM anders ist als normales Ping/Traceroute

Ein normales ping beweist IP-Erreichbarkeit. Es sagt dir aber nicht, ob Traffic tatsächlich label-switched läuft oder ob irgendwo PHP, LFIB-Lücken oder ein Punt-Path greift. MPLS OAM adressiert genau diese Lücke, indem es MPLS-spezifische Return-Codes und Hop-Informationen liefert.

• IP Ping: „Ziel antwortet“ (Layer-3 Sicht)
• LSP Ping: „LSP existiert und ist konsistent“ (Label-Sicht)
• MPLS Traceroute: „welche LSRs/Labels wurden wirklich genutzt?“

Grundbegriffe: FEC, LSP, LFIB und PHP

LSP Ping arbeitet gegen eine FEC (Forwarding Equivalence Class), also z. B. ein IGP-Prefix oder eine VPNv4 Route. Daraus ergibt sich der LSP. Die LFIB ist die Tabelle, die Label-Swaps/Pop/Push definiert. PHP (Penultimate Hop Popping) ist oft aktiv und beeinflusst, wie viele Label-Hops du siehst.

• FEC: Zielklasse (z. B. 10.255.0.2/32)
• LSP: label-switched Pfad zur FEC
• LFIB: Label Forwarding Entries (Swap/Pop/Out-IF)
• PHP: Outer Label wird am vorletzten Hop gepoppt (normal)

Merker

$\text{LSP Ping} \to \text{prüft LFIB-Konsistenz entlang der FEC}$

LSP Ping: Was genau getestet wird

LSP Ping (RFC-style MPLS Echo Request/Reply) prüft, ob ein LSP zur Ziel-FEC existiert und ob Zwischenrouter die FEC korrekt auflösen. Das Ergebnis liefert oft direkt Hinweise, ob ein Label fehlt, die FEC anders interpretiert wird oder ein Hop nicht im MPLS-Forwarding ist.

• Existiert ein LSP zur FEC?
• Kann jeder Hop die FEC korrekt mappen?
• Gibt es LFIB-/Label-Inkonsistenzen?

LSP Ping auf Cisco: Praxisbefehle

Je Plattform/Release gibt es Variationen, das Grundmuster ist aber: du pingst eine FEC (meist ein Loopback/Prefix) und lässt optional Details ausgeben.

Ping einer IGP-FEC (Beispielpattern)

ping mpls ipv4 10.255.0.2/32

Mit Wiederholungen/Timeout (Pattern)

ping mpls ipv4 10.255.0.2/32 repeat 20 timeout 2

MPLS Traceroute: Fault Isolation Hop für Hop

MPLS Traceroute zeigt dir den LSP hop-by-hop. Das ist ideal, wenn LSP Ping fehlschlägt oder wenn du vermutest, dass der Pfad nicht der erwartete ist. In der Praxis nutzt du MPLS Traceroute, um den „Break Point“ zu finden.

MPLS Traceroute (Beispiel)

traceroute mpls ipv4 10.255.0.2

Interpretation

• Hops erscheinen mit Labels/Return Codes (je nach TTL-Mode)
• Ein „*“ oder Timeout zeigt den Problemhop oder eine TTL/Policy-Thematik
• Wenn du nur wenige Hops siehst, kann PHP/TTL-Handling die Ursache sein

Fault Isolation Workflow: So findest du den Fehlerpunkt

Ein Profi-Workflow isoliert systematisch: erst beweisen, dass die Ziel-FEC im IGP da ist, dann MPLS Forwarding, dann OAM. Das reduziert False Positives und spart Zeit.

• 1) IGP Reachability: Route zum Ziel-Loopback vorhanden?
• 2) MPLS aktiv: MPLS auf Interfaces und Nachbarn up?
• 3) LFIB: Gibt es einen Forwarding-Entry zur FEC?
• 4) OAM: LSP Ping/Traceroute, Break Point bestimmen

Command Pack (Workflow)

show ip route 10.255.0.2
show mpls interfaces
show mpls ldp neighbor
show mpls forwarding-table | include 10.255.0.2
ping mpls ipv4 10.255.0.2/32
traceroute mpls ipv4 10.255.0.2

Return Codes verstehen: Was die Antworten bedeuten

Die OAM-Antworten enthalten häufig Return Codes, die dir sofort sagen, ob das Problem „kein Label“, „FEC unbekannt“ oder „falscher Pfad“ ist. In der Praxis sind drei Kategorien besonders relevant.

• Success: LSP ist konsistent
• No Label / No Route: LFIB/LIB oder IGP fehlen
• Malformed/Unreachable: Control Plane/ACL/CoPP oder MTU

Typische Fehlerbilder und ihre Ursachen

MPLS OAM ist besonders hilfreich, weil viele MPLS-Probleme nicht wie klassische IP-Probleme aussehen. Diese Fehlerbilder treten im Betrieb häufig auf.

• LDP Neighbor down: Discovery/Hello/Interface MPLS fehlt
• LFIB Entry fehlt: IGP Route fehlt oder Label-Binding fehlt
• Blackhole nach IGP Change: LDP/IGP Sync fehlt oder Konvergenz-Lücke
• MTU-Probleme: MPLS Label-Stack verursacht Drops/Timeouts
• PHP/TTL: Traceroute zeigt weniger, als erwartet

OAM in L3VPN: Transport-LSP vs. VPN-LSP unterscheiden

In L3VPN gibt es mindestens zwei Ebenen: Transport zum Egress-PE (Outer Label) und VPN-Forwarding in die VRF (Inner Label). LSP Ping/Traceroute gegen die PE-Loopback prüft primär den Transport. Für VPN-spezifische Probleme prüfst du zusätzlich VPNv4/VRF Routen.

• Transport-Test: PE Loopback als Ziel
• VPN-Test: VRF-Routing + VPN-Labels prüfen
• Fehlertrennung: „Core Transport“ vs. „VPN Control Plane“

Ergänzende VPN Checks

show ip bgp vpnv4 all summary
show ip route vrf <VRF>
show mpls forwarding-table

SR-MPLS OAM: Gleicher Workflow, andere Labelquelle

Bei SR-MPLS kommen Labels aus SIDs statt aus LDP. Der OAM-Workflow bleibt ähnlich: IGP Reachability, SR SID-Sichtbarkeit, MPLS Forwarding, dann LSP Ping/Traceroute. Typische Fehler sind SRGB-Inkonsistenzen oder fehlende Node-SIDs.

SR Checks

show segment-routing mpls sid-database
show mpls forwarding-table | include 160
traceroute mpls ipv4 10.255.0.2

Best Practices: OAM als Standard in Runbooks

In produktiven Backbones sollte MPLS OAM Teil jedes Incident- und Change-Runbooks sein. Das gilt besonders bei Upgrades, LDP-to-SR Migrationen und IGP-Metrikänderungen.

• Pre-Change: LSP Ping/Traceroute Baseline
• Post-Change: gleiche Tests, Ergebnisse vergleichen
• Monitoring: Drops/Errors und LDP/SR Health kontinuierlich

Quick-Runbook: Fault Isolation in 5 Minuten

Diese Sequenz isoliert die meisten MPLS-Probleme zuverlässig, ohne Debugs.

show ip route 10.255.0.2
show mpls interfaces
show mpls ldp neighbor
show mpls forwarding-table | include 10.255.0.2
ping mpls ipv4 10.255.0.2/32 repeat 10 timeout 2
traceroute mpls ipv4 10.255.0.2
show interfaces | include drops|error

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.