MPLS-Grundlagen für Betreiber: LSPs, Traffic-Engineering und Fehlersuche im SP-Umfeld

Wer im Provider- oder Carrier-nahen Umfeld Netze betreibt, merkt schnell: MPLS ist weniger „ein Protokoll“ als ein Betriebsmodell. Die MPLS-Grundlagen für Betreiber drehen sich daher nicht nur um Labels, sondern um saubere Pfadsteuerung (LSPs), kontrollierte Auslastung (Traffic-Engineering) und reproduzierbare Fehlersuche, wenn Kunden-VRFs, Pseudowires oder ganze Standorte „sporadisch“ Probleme zeigen. Dieser Beitrag richtet sich an Operatoren und Administratoren, die nicht jeden RFC auswendig können müssen, aber im Störungsfall belastbar entscheiden wollen: Liegt es am Underlay (IGP), an der Label-Signalisierung (LDP/RSVP), an BGP/VRF oder an einer MTU-/QoS-Kante?

Wichtig als Grundhaltung: In einem SP-Umfeld ist MPLS fast immer in mehrere Ebenen geschichtet. Underlay meint das IP-Routing im Core (typisch OSPF oder IS-IS als IGP, also Interior Gateway Protocol). Overlay</em meint Dienste wie L3VPN (VRF via MP-BGP) oder L2VPN (Pseudowire). Dazwischen liegen LSPs (Label Switched Paths) als transportierende „Schienen“. Wenn Sie diese Schichten getrennt prüfen, sinkt die Zeit zur Root Cause deutlich.

MPLS-Grundlagen für Betreiber: Warum MPLS im Betrieb anders tickt als „IP-Routing“

MPLS (Multiprotocol Label Switching) schaltet Pakete anhand kurzer Labels statt anhand der kompletten IP-Zieladresse weiter. Ein Router im MPLS-Core wird dabei zum LSR (Label Switch Router). Der Eintrittspunkt in den MPLS-Core ist der Ingress, der Austritt der Egress. Im Kunden- oder Edge-Umfeld sprechen Sie oft von PE (Provider Edge) und P (Core). Auf PE-Routern entstehen Dienste (VRFs, Pseudowires), während P-Router „nur“ transportieren.

Operativ entscheidend: MPLS trennt Weiterleitung (Forwarding) stärker vom Routing-Entscheid. Das Routing (Control Plane) berechnet Pfade (z. B. via IS-IS/OSPF). MPLS baut darauf eine Forwarding-Struktur (Data Plane) mit Label-Informationen auf. Wenn Routing „grün“ ist, kann MPLS trotzdem „rot“ sein – etwa, wenn LDP-Nachbarschaften fehlen, RSVP-TE nicht signalisiert oder der Label-Stack wegen MTU reißt.

LSPs verstehen: Was ein Label Switched Path wirklich ist

Ein LSP (Label Switched Path) ist der gerichtete Pfad, den MPLS-Pakete durch das Netz nehmen. „Gerichtet“ ist wichtig: Der Hinweg von A nach B ist ein eigener LSP, der Rückweg B nach A ebenfalls. Im Betrieb begegnen Ihnen zwei grundlegende Varianten:

• IGP-basierte LSPs (häufig via LDP): Der LSP folgt dem vom IGP berechneten kürzesten Pfad. Der Betreiber steuert indirekt über IGP-Metriken und Topologie.
• Explizite/TE-LSPs (klassisch via RSVP-TE oder modern via Segment Routing): Der Pfad wird gezielter gesteuert, z. B. um Engpässe zu umfahren oder Bandbreiten-/Latenz-Anforderungen zu erfüllen.

Der Kernmechanismus ist der Label-Stack: Ein Paket kann mehrere Labels tragen (oben „Transportlabel“, darunter z. B. ein VPN-Label für die Ziel-VRF). Im SP-Alltag erklärt das viele Symptome: Wenn das äußere Transportlabel stimmt, aber das innere Dienstlabel nicht, ist der Core meist gesund – das Problem liegt eher bei PE/BGP/VRF oder Service-Definition.

Label Operationen: Push, Swap, Pop – und warum PHP relevant ist

MPLS kennt drei Grundoperationen: Push (Label hinzufügen), Swap (Label austauschen) und Pop (Label entfernen). Viele Netze nutzen PHP (Penultimate Hop Popping): Der vorletzte Router entfernt das Transportlabel, damit der Egress weniger Arbeit hat. Das kann die Fehlersuche beeinflussen, weil am Egress weniger MPLS-Information „sichtbar“ ist und manche Tools/Telemetrie anders aussehen. Für Betreiber heißt das: Wenn Traces am Egress „plötzlich“ keine äußeren Labels mehr zeigen, ist das nicht automatisch ein Fehler – es kann PHP sein.

Control Plane im Überblick: LDP, RSVP-TE und Segment Routing

Damit ein LSP entsteht, müssen Router Labels verteilen oder Pfade signalisieren. In der Praxis treffen Sie am häufigsten auf diese Modelle:

• LDP (Label Distribution Protocol): Verteilt Labels entlang der IGP-Topologie. Einfach im Betrieb, wenig „Policy“, aber begrenztes klassisches TE.
• RSVP-TE (Resource Reservation Protocol – Traffic Engineering): Signalisiert explizite TE-LSPs und kann Bandbreite reservieren. Betrieblich mächtiger, aber zustandsbehaftet (State) und damit sensibler bei Skalierung/Fehlerszenarien.
• Segment Routing (SR-MPLS): Steuert Pfade über Segment-IDs (SIDs), meist eng integriert in IS-IS/OSPF. Weniger per-flow State im Netz, dafür andere Betriebslogik (Policies, SIDs, ggf. SR-TE).

Wichtig als Betreiberperspektive: Egal ob LDP, RSVP-TE oder SR – das Underlay muss stabil sein. Wenn IGP flapt, flappen LSPs. Wenn Adjazenzen instabil sind, sind TE-Entscheidungen und FRR (Fast Reroute) nur Symptombekämpfung.

Typische Stolperfallen bei LDP

• IGP-/LDP-Alignment: Wenn LDP nur auf einem Teil der Core-Interfaces läuft oder IGP und LDP unterschiedliche Interface-Auswahl haben, entstehen „LDP Holes“ – IGP reachability ja, Label-Switched Pfad nein.
• Transport über Loopbacks: Viele Designs nutzen Router-Loopbacks als LDP-Identität/Router-ID. Wenn Loopback-Reachability oder IGP-Policy fehlerhaft ist, kippen Nachbarschaften.
• Graceful Restart / Session Protection: Ohne saubere Restart-Mechanismen führen Control-Plane-Neustarts zu Traffic-Einbrüchen, obwohl der Datenpfad ggf. noch tragfähig wäre.

Typische Stolperfallen bei RSVP-TE

• State und Skalierung: RSVP hält pro LSP Zustand (Soft State). Viele LSPs oder kurze Refresh-Intervalle belasten CPU/Control Plane.
• Bandbreitenmodell: „Reserviert“ bedeutet nicht automatisch „garantiert“, wenn die QoS- und Queue-Architektur nicht dazu passt. Umgekehrt kann eine zu harte Admission Control LSPs verhindern, obwohl physisch Kapazität da wäre.
• Pfadberechnung vs. Realität: TE basiert auf IGP-TE-Information (z. B. verfügbare Bandbreite). Wenn diese Werte veraltet, falsch oder inkonsistent sind, lenkt TE falsch.

MPLS Traffic Engineering in der Praxis: Ziele, Voraussetzungen, Risiken

MPLS Traffic Engineering ist im Betrieb vor allem ein Werkzeug, um Lastspitzen, Engpässe oder Wartungsfenster kontrollierter zu beherrschen. Typische Ziele sind: Hotspots im Core entschärfen, definierte Pfade für latenzkritische Dienste nutzen oder Kapazität planbar ausnutzen, ohne „nur“ IGP-Metriken zu verbiegen.

Voraussetzungen, damit TE nicht zum Dauer-Brandherd wird:

• Saubere IGP-Topologie mit stabilen Metriken und konsistenten TE-Attributen (wenn genutzt).
• Verlässliche Kapazitätsdaten (Interface-Bandbreite, Reservierungen, Overbooking-Regeln) und ein Monitoring, das nicht nur „Link up/down“ kann, sondern Auslastung, Drops, Queueing und Latenz beobachtet.
• Operationaler Lebenszyklus: TE-Policies brauchen Change-Control, Dokumentation, Review und eine klare Ownership. „Einmal schnell umleiten“ ist der Einstieg in Konfigurationswildwuchs.

Risiken und typische Betreiberfehler:

• TE als Ersatz für Kapazität: TE kann Engpässe verteilen, aber nicht wegzaubern. Wenn alle Pfade voll sind, verschiebt TE nur Schmerz.
• Unklare Failure-Domains: TE kann über gemeinsam genutzte Risiken (SRLG, Shared Risk Link Group – gemeinsame physische Abhängigkeiten wie Kabeltrassen) hinweg planen, wenn diese nicht modelliert sind. Dann führt „Diversity“ in der Theorie doch durch dieselbe Trasse.
• Asymmetrie: Der Hinweg wird optimiert, der Rückweg bleibt IGP-default. Das kann Latenz, Firewalls, Session-Stabilität und Messungen verfälschen.

FRR und lokale Reparatur: Warum „schnell“ nicht automatisch „sauber“ ist

FRR (Fast Reroute) soll bei Link-/Node-Ausfällen sehr schnell lokal umschalten, ohne auf die komplette IGP-Konvergenz zu warten. Das stabilisiert Kundenerfahrung, kann aber Troubleshooting erschweren: Direkt nach einem Ausfall sieht der Pfad „komisch“ aus, weil ein lokaler Umweg aktiv ist, bis der globale Recompute fertig ist. Betreiber-Tipp: Prüfen Sie im Störungsfenster, ob Sie gerade FRR-Pfade sehen, bevor Sie „Routing-Loops“ oder „falsche Metriken“ vermuten.

Dienste über MPLS: L3VPN (VRF) als häufigster Betriebsfall

Viele Teams sprechen im Alltag von „MPLS“, meinen aber eigentlich BGP/MPLS L3VPN. Hier ist die VRF (Virtual Routing and Forwarding) zentral: eine getrennte Routing-Tabelle pro Kunde/Service. Die Route-Verteilung läuft üblicherweise über MP-BGP (Multiprotocol BGP), oft mit Route Targets (RT) zur Import/Export-Steuerung. Das eigentliche Forwarding nutzt dann MPLS-Labels: außen Transport (Core), innen VPN-Label (richtige VRF am Egress-PE).

Praktische Konsequenz für die Fehlersuche: Wenn ein Kunde „kein Routing“ hat, kann der Core trotzdem perfekt funktionieren. Dann prüfen Sie zuerst: Kommen die VPN-Routen im MP-BGP an? Sind RTs korrekt? Ist das VPN-Label im LFIB (Label Forwarding Information Base) vorhanden? Und passt die MTU für den Label-Stack?

MTU und Label-Stack: Der stille Ausfallgrund

Ein MPLS-Label fügt typischerweise 4 Byte pro Label hinzu. Bei mehreren Labels (Transport + Service, ggf. weitere) wächst das Paket. Wenn Interfaces, LAGs oder Tunnelstrecken knapp konfiguriert sind, entstehen Fragmentierung oder Drops. Besonders tückisch: Viele ICMP-Meldungen (PMTUD – Path MTU Discovery) werden in Provider-Umgebungen gefiltert oder gehen in asymmetrischen Pfaden verloren. Ergebnis: „Große“ Pakete hängen, kleine gehen durch. Wenn Sie MTU-Probleme systematisch angehen wollen, ist ein eigener Leitfaden sinnvoll; als Anschluss passt der Beitrag MTU- und Fragmentierungsprobleme analysieren und über GRE/IPsec vermeiden, weil die Prüflogik (PMTUD, MSS, Drops) sehr ähnlich ist.

Fehlersuche im SP-Umfeld: Schichtenmodell und Prüfreihenfolge

In Störungen verlieren Teams Zeit, wenn sie quer durch alle Ebenen springen. Bewährt ist eine feste Reihenfolge, die Sie als Runbook dokumentieren. Ziel: Erst klären, ob das Underlay stabil ist, dann MPLS-Transport, dann Dienst-Overlay (VRF/BGP), dann kundennahe Themen (CPE, Firewall, NAT, Applikation).

1) Underlay prüfen: IGP, Nachbarschaften, Konvergenz

Underlay bedeutet: Können die Core-Router sich IP-seitig erreichen und sind IGP-Adjazenzen stabil? Typische Symptome bei Underlay-Problemen sind Link-Flaps, hohe CPU, Latenzspitzen und „random“ Paketverlust über viele Dienste gleichzeitig.

Praxis-Checks (vendor-neutral formuliert):

• IGP-Neighbor-Status: Up/Down, Flap-Zähler, Dead-Timer, Interface-Errors.
• Routen zur Loopback der PE/P-Router: Liegen sie im RIB/FIB? Ändert sich der Next Hop häufig?
• ECMP-Konsistenz: Bei Equal-Cost Multi-Path können einzelne Pfade fehlerhaft sein und nur einen Teil der Flows betreffen.

2) MPLS-Transport prüfen: LDP/RSVP/SR und LFIB

Jetzt prüfen Sie, ob die MPLS-Ebene durchgängig ist: Sind LDP- oder RSVP-TE-Nachbarschaften up? Gibt es Labels für die relevanten FECs (Forwarding Equivalence Classes – Gruppierung von Traffic, der gleich behandelt wird)? Stimmen die Label-Swaps im LFIB?

Wenn Ihre Plattform es unterstützt, sind LSP Ping und MPLS Traceroute sehr wertvoll: Sie testen nicht nur IP, sondern die MPLS-Forwarding-Kette. Wichtig: Diese Tools können durch PHP und durch ICMP-Filter beeinflusst werden. Ein „unvollständiger“ Trace ist nicht automatisch kaputtes MPLS – er kann auch Policy/ACL sein.

3) Dienst-Overlay prüfen: VRF, MP-BGP, RT/RD, Labels

Wenn Transport-LSPs stehen, prüfen Sie die Service-Schicht:

• VRF-Existenz und Interface-Bindings: Ist das Kunden-Interface wirklich in der richtigen VRF? Stimmen Subinterfaces/VLAN-Tags?
• MP-BGP Sessions: Up/Down, Route-Refresh, Flaps, Policy-Changes.
• Route Targets: Import/Export korrekt? Ein falsches RT führt zu „keine Routen“, wirkt aber wie Linkproblem.
• VPN-Labels: Egress-PE muss das korrekte Service-Label sehen/verteilen.

4) Kanten prüfen: QoS, Policing, ACLs, MTU, asymmetrisches Routing

Viele „MPLS-Probleme“ sitzen an den Grenzen: falsches Policing, Drops in einer Queue, ACL-Änderungen oder eine MTU, die nur in eine Richtung passt. Gerade im SP-Umfeld ist asymmetrisches Routing häufig (Hinweg über Pfad A, Rückweg über Pfad B). Das ist nicht per se falsch, kann aber Zustandsbehaftetes (Firewalls, NAT, Session-Pinning) brechen. Wenn Sie dafür ein methodisches Vorgehen brauchen, lohnt sich ein eigener Troubleshooting-Artikel zum Thema.

Praktisches Runbook: Von Symptom zu Ursache in 30–60 Minuten

Die folgende Checkliste ist bewusst operational formuliert. Passen Sie sie an Ihre Plattform (Cisco/Juniper/Nokia/Arista/FRR) und an Ihre Telemetrie an.

A) Symptomklassifikation (erste 5 Minuten)

• Ein Kunde/VRF betroffen oder viele gleichzeitig?
• Komplettausfall oder nur bestimmte Applikationen/Ports/Packet-Sizes?
• Seit wann (Change-Fenster, Wartung, Link-Events, DDoS-Events)?
• Nur ein Standort oder mehrere? Nur ein PE oder mehrere PEs?

B) Transportpfad validieren (10–20 Minuten)

Arbeiten Sie sich hop-by-hop vor: Underlay bis Loopback, dann MPLS-Transport, dann Service.

• IP-Ping/Trace zwischen relevanten Loopbacks (PE↔PE).
• MPLS-spezifische Tests (LSP Ping/Trace), wenn verfügbar.
• LFIB/Label-Table prüfen: Gibt es Einträge für die Ziel-FEC? Zeigt der Outgoing-Label/Next-Hop plausibel?

C) Servicepfad validieren (10–20 Minuten)

• MP-BGP: Session stabil? Route-Anzahl plausibel? Letzte Policy-Änderungen?
• VRF-Routing: Default-Route vorhanden? Spezifische Prefixes da?
• ARP/ND an der Kundenkante (je nach L2/L3), um „Layer-2 sieht tot aus“ abzugrenzen.

D) Datenebene prüfen (10–20 Minuten)

• Interface-Counter: Drops, CRC, Input/Output Errors, Queue Drops.
• QoS/Policer: Trifft eine Police plötzlich? Haben sich Classifier geändert?
• MTU/MSS: Hinweise auf Fragmentation Needed? Korrelation mit „nur große Pakete“.

Typische Fehlerbilder und wie Sie sie erkennen

Die folgenden Muster kommen in SP- und Carrier-nahen Netzen regelmäßig vor. Entscheidend ist, dass Sie pro Muster einen „Beweis“ suchen, statt auf Bauchgefühl zu reagieren.

Fehlerbild 1: „Routing ist da, aber Traffic verschwindet“

Oft ist das ein MPLS-Transportthema (fehlendes Label) oder ein MTU-/QoS-Problem. Wenn IGP reachability stimmt, aber LFIB-Eintrag fehlt, ist die Control Plane zwischen Routern (LDP/RSVP/SR) der Hebel. Wenn LFIB stimmt, aber Counter Drops zeigen: Datenebene, nicht Routing.

Fehlerbild 2: „Nur eine VRF/Kunde betroffen“

Sehr häufig Overlay: falsche RTs, fehlende MP-BGP-Routen, falsches VRF-Binding am Interface oder ein einzelner PE mit defekter Policy. Der Core ist dann meistens gesund. Best Practice: Erst Service-Definition prüfen, dann Transport eskalieren.

Fehlerbild 3: „Nur bestimmte Anwendungen / nur große Pakete“

MTU/MSS oder fragmentationsbezogene Filter. In MPLS-Domains kann das durch zusätzliche Label-Overhead verstärkt werden. Wenn Sie in einem Runbook bereits festhalten, welche Links/Jumbo-Profile im Core gelten, sparen Sie viel Zeit.

Fehlerbild 4: „Nach Wartung: alles up, aber Latenz/Umwege“

Das ist oft TE/FRR-Nachlauf: Traffic läuft über Schutzpfade, weil ein Link zwar „up“ ist, aber TE-Attribute oder IGP-Adjazenz nicht sauber ist. Prüfen Sie: Ist der Link wirklich im IGP? Sind TE-Announcements wieder konsistent? Gibt es noch „hold-down“ Timer oder Admin-Gewichte, die den Pfad vermeiden?

How-to: Minimaler Tooling-Stack für Betreiber (ohne Vendor-Bindung)

Nicht jedes Team hat überall die gleichen Kommandos. Trotzdem lässt sich ein universeller Werkzeugkasten definieren: IP-Tests, MPLS-OAM, Counter/Telemetry, Paketmitschnitt an Kanten.

Für Linux-basierte Messpunkte oder Test-VMs (z. B. an PE-nahen Netzen) sind diese Basics hilfreich:

# Basis: Erreichbarkeit und Pfad (IP-Ebene)
ping -c 5 <ziel-ip>
traceroute -n <ziel-ip>

# MTU-Check (Beispiel IPv4, DF gesetzt):
ping -M do -s 1472 -c 3 <ziel-ip>

# Paketmitschnitt (Edge-nah, um Drops/ICMP zu sehen):
sudo tcpdump -ni <interface> host <ziel-ip> -vv

Warum das wirkt: Mit ping -M do (Do-not-fragment) erzwingen Sie, dass MTU-Probleme sichtbar werden, statt im Hintergrund zu fragmentieren. tcpdump zeigt, ob ICMP „Fragmentation Needed“ überhaupt zurückkommt. Grenzen: In vielen Provider-Kernen sehen Sie ICMP nicht oder es wird gefiltert; dann bleibt nur Messung an den Kanten oder per Router-OAM.

Änderungen, Rollback und Rückfallstrategie bei MPLS/TE

Betreiber denken nicht nur „wie repariere ich“, sondern auch „wie verhindere ich Folgeschäden“. Für MPLS/Traffic-Engineering gilt: Jede Änderung an IGP-Metriken, TE-Policies oder RSVP/SR-Parametern kann großflächig wirken.

Bewährte Vorgehensweise im Change-Fenster

• Vorher-Nachher-Messpunkte: Definieren Sie 2–3 Pfade (PE↔PE, kundenrelevant) und messen Sie Latenz, Loss, ggf. MTU.
• Scope begrenzen: Lieber zuerst einen LSP/Policy auf einem Paar PEs ändern als global.
• Rollback vorbereiten: Konfiguration und erwartete Rückkehr (z. B. IGP-Konvergenzzeit) dokumentieren. Rollback ist nicht „zurückspielen und fertig“ – Sie müssen prüfen, ob der Datenpfad wirklich zurück ist.
• Monitoring-Alarmierung temporär anpassen: Nicht abschalten, aber wartungsbedingt „noise“ reduzieren, damit echte Fehler sichtbar bleiben.

Rückfallstrategie, wenn TE unerwartet Probleme macht: Erst die TE-spezifische Steuerung zurücknehmen (Policy/LSP), dann auf IGP-Default (LDP/Shortest Path) zurückfallen, statt hektisch Metriken zu ändern. Metrik-Änderungen haben oft größere Blast Radius als das Deaktivieren einer einzelnen TE-Policy.

Sicherheit und Betrieb: MPLS ist kein VPN im kryptografischen Sinn

In vielen Unternehmen wird MPLS sprachlich als „VPN“ eingeordnet. Im Provider-Kontext bedeutet „VPN“ (z. B. L3VPN) aber primär logische Trennung (VRF/Label), nicht Verschlüsselung. Wenn Sie Schutz gegen Mitschnitt auf Transportstrecken benötigen, brauchen Sie zusätzliche Maßnahmen wie MACsec (Layer 2 Verschlüsselung) oder IPsec (Layer 3), oder Sie nutzen verschlüsselte Overlays auf Applikationsebene (TLS). Für Betreiber wichtig: Diese Entscheidung beeinflusst MTU, Monitoring (Encrypted Traffic), Fehlersuche und Performance-Planung.

Fazit: MPLS stabil betreiben heißt Schichten trennen und Pfade beweisen

Die wichtigsten MPLS-Grundlagen für Betreiber sind weniger „Label-Theorie“ als ein diszipliniertes Betriebsmodell: Underlay zuerst stabilisieren, dann MPLS-Transport (LSPs und Label-Forwarding) validieren, erst danach Services wie VRF/MP-BGP beurteilen. Traffic-Engineering ist ein starkes Werkzeug, wenn Voraussetzungen (IGP-Qualität, Kapazitätsmodell, Monitoring, Change-Prozess) stimmen – sonst wird es zur dauerhaften Sonderbehandlung.

Wenn Sie Ihr eigenes Runbook erstellen, halten Sie pro Schicht konkrete Beweise fest (Neighbor-Status, LFIB-Existenz, OAM-Ergebnisse, Counter/Drops, MTU-Tests). Das macht Störungen reproduzierbar, senkt Eskalationszeiten und verbessert die Zusammenarbeit zwischen NOC, Engineering und kundennahen Teams.

Für dieses Thema sind auch Mpls Lsp wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.