LDP vs. SR-MPLS: Operative Auswirkungen und Migrationsabwägungen

LDP vs. SR-MPLS ist für viele Provider keine rein technische Diskussion, sondern eine operative Grundsatzentscheidung: Wie wollen Sie Transportpfade im Backbone aufbauen, überwachen und verändern – und wie viel Komplexität akzeptieren Sie dafür? LDP (Label Distribution Protocol) ist seit Jahren der „Default“ in klassischen MPLS-Backbones: stabil, gut verstanden, breit implementiert. SR-MPLS (Segment Routing mit MPLS-Datenebene) verspricht dagegen weniger Protokolle, einfachere Traffic-Engineering-Workflows und eine engere Kopplung an das IGP. In der Praxis ist der Unterschied nicht „alt vs. neu“, sondern „automatische Labelverteilung pro FEC“ (LDP) versus „pfadbasierte Steuerung über Segmente“ (SR). Für den Betrieb ist entscheidend, wie sich das auf Fehlersuche, Konvergenz, OAM, Capacity-Management, Change-Risiken, Multi-Vendor-Interoperabilität und Migrationsstrategie auswirkt. Dieser Artikel beschreibt LDP vs. SR-MPLS aus Sicht des NOC und der Engineering-Teams: Welche operativen Auswirkungen Sie erwarten sollten, welche Pitfalls wiederkehrend auftreten und wie Sie eine Migration so planen, dass sie nicht zu Traffic Drops, Blackholes oder Second Outages führt.

Begriffe und Kontext: Was LDP und SR-MPLS im Backbone eigentlich tun

Beide Ansätze liefern dasselbe Ziel: MPLS-Transportlabels, mit denen Pakete über einen Label-Switched-Path (LSP) durch das Backbone laufen. Der Unterschied liegt in der Art, wie Labels entstehen, wie Pfade gewählt werden und wie viel „State“ im Netz verteilt werden muss.

• LDP: verteilt Labels für Forwarding Equivalence Classes (FECs), typischerweise IGP-Prefixe. Der Pfad folgt dem IGP-SFP (Shortest Path Forwarding) und ECMP-Regeln.
• SR-MPLS: nutzt Segment-IDs (SIDs), die aus dem IGP (IS-IS/OSPF) oder per Policy abgeleitet werden. Pfade können als SID-Listen beschrieben werden (Source Routing), ohne dass per Hop ein eigener TE-State (wie bei RSVP-TE) notwendig ist.

Für MPLS-Grundlagen ist RFC 3031 eine gute Referenz. LDP ist in RFC 5036 beschrieben. Segment Routing Architektur und SR-MPLS sind in RFC 8402 und RFC 8660 erläutert.

Operative Leitfrage: Was ändert sich im Alltag?

Im Tagesgeschäft geht es weniger um „wie Labels entstehen“ und mehr um Fragen wie:

• Wie schnell erkennen wir Fehler (und sind es echte Fehler oder Noise)?
• Wie beweisen wir Pfade (OAM) und finden Partial Failures bei ECMP/LAG?
• Wie kontrollieren wir Traffic Shifts bei Changes (Graceful Shutdown, Drain, Rehashing)?
• Wie schützen wir die Control Plane vor Churn und Skalierungsproblemen?
• Wie standardisieren wir Monitoring und Tickets, damit NOC-Teams konsistent handeln?

Die Antworten unterscheiden sich bei LDP und SR-MPLS teilweise deutlich, vor allem in den Bereichen State, Policy-Steuerung und Fehlersuche.

LDP im Betrieb: Stärken und typische Pain Points

LDP ist operativ attraktiv, weil es für viele Backbones „einfach läuft“. Labels werden automatisch verteilt, und solange IGP stabil ist, ist MPLS-Transport meist stabil. Genau diese Automatik hat aber auch Schattenseiten.

Stärken von LDP

• Einfaches Modell: IGP bestimmt den Pfad, LDP liefert die Labels – das ist leicht zu erklären und zu standardisieren.
• Breite Interoperabilität: LDP ist in Multi-Vendor-Umgebungen sehr gut unterstützt.
• Reife OAM-Werkzeuge: MPLS LSP Ping/Traceroute ist etabliert (RFC 4379).
• Geringe TE-Komplexität: Wenn Sie primär „IGP folgt der Topologie“ wollen, ist LDP ausreichend.

Typische operative Pitfalls bei LDP

• Zusätzlicher Control-Plane-State: LDP ist ein eigenes Protokoll mit Nachbarschaften, Session-Flaps und eigener Fehlerdomäne. „IGP up“ heißt nicht automatisch „LDP ok“.
• LDP-IGP Sync-Themen: Wenn LDP nicht bereit ist, aber IGP bereits konvergiert, kann Traffic kurzzeitig in Blackholes laufen, sofern keine Schutzmechanik greift.
• Fehlerbild „MPLS kaputt, IP ok“: PE-Loopbacks pingbar, aber LSP bricht – häufig LDP/Label-Bindings oder Data-Plane-Programmierung.
• Skalierung/Churn: In sehr großen Netzen oder bei massiven Topology-Events kann LDP zusätzliches Churn erzeugen, das Troubleshooting erschwert.

SR-MPLS im Betrieb: Stärken und typische Pain Points

SR-MPLS verändert das Betriebsmodell: Statt eines separaten Label-Distributionsprotokolls wird SR-State primär über das IGP verteilt. Für viele Teams ist das der Hauptgewinn: weniger bewegliche Teile. Gleichzeitig bringt SR neue Konzepte (SIDs, Policies, SID-Stacks), die operativ sauber beherrscht werden müssen.

Stärken von SR-MPLS

• Weniger Protokolle: Kein LDP im klassischen Sinne nötig; SR-Informationen werden im IGP verteilt.
• Deterministischere Pfadsteuerung: Über Segment-Listen (und Policies) können Pfade gezielter gesteuert werden als über „nur IGP-Metriken“.
• Einheitlichere TE-Workflows: Traffic Engineering lässt sich stärker policy-basiert und zentral steuern (je nach Architektur).
• Potenzial für schnellere und stabilere Konvergenz: Weniger „zweite Ebene“ an Sessions kann Churn reduzieren, wenn das Design sauber ist.

Typische operative Pitfalls bei SR-MPLS

• SID-Planung und Drift: Wenn SIDs nicht konsistent geplant und dokumentiert sind (Node-SIDs, Adj-SIDs), wird Troubleshooting schnell unübersichtlich.
• Policy-Komplexität: SR Policies (insbesondere bei zentraler Steuerung) können neue Fehlerdomänen schaffen: falsche Policy, falscher Candidate Path, unerwartete Failover-Reihenfolge.
• Label-Stack-MTU: SR kann längere Label-Stacks erzeugen (mehr Labels), was MTU-Pitfalls wahrscheinlicher macht.
• Multi-Vendor-Interop: SR ist standardisiert, aber Detailverhalten (z. B. Policy-Implementierungen, OAM, TI-LFA-Varianten) kann je nach Hersteller variieren.

Control-Plane-Vergleich: State und Fehlerdomänen

Ein praktischer Vergleich hilft bei der Migrationsabwägung: Wie viele „bewegliche Teile“ müssen im Betrieb stabil sein?

• LDP: IGP + LDP + MPLS Data Plane. Fehlerdomäne umfasst zusätzlich LDP-Neighbor/Session-State.
• SR-MPLS: IGP + SR Extensions + MPLS Data Plane. Fokus auf IGP-Konsistenz und SR-Attribute.

Vereinfachte Risikoheuristik (MathML)

$\mathrm{FailureDomain}\approx \mathrm{Protocols}+\mathrm{Policies}+\mathrm{Platforms}$

Diese Heuristik ist bewusst grob: Operativ steigt die Komplexität nicht nur mit der Anzahl der Protokolle, sondern auch mit Policy-Schichten und Plattformunterschieden. SR reduziert häufig Protokollkomplexität, erhöht aber je nach Design die Policy-Komplexität.

Konvergenz und Fast Reroute: Was ändert sich wirklich?

Die reine Konvergenzzeit hängt primär von Failure Detection (z. B. BFD), IGP-Reaktion, FIB-Programmierung und Queueing ab – nicht allein von LDP oder SR. Dennoch gibt es praktische Unterschiede.

• LDP: kann zusätzliche Synchronisationsaspekte haben (IGP-LDP Timing, LDP Session Recovery). In stabilen Netzen ist das unkritisch, in instabilen Netzen kann es Konvergenz verlängern.
• SR-MPLS: arbeitet enger mit IGP-Mechaniken zusammen; moderne FRR-Ansätze wie TI-LFA sind häufig im SR-Kontext präsent (Implementierungsdetails variieren).

BFD als Failure-Detection-Baustein ist in RFC 5880 beschrieben. Für LFA als FRR-Grundlage ist RFC 5286 relevant.

OAM und Nachweisführung: „Pfad validieren ohne Rätselraten“

Im NOC ist die Fähigkeit, Pfade schnell zu beweisen, entscheidend. Bei LDP ist MPLS LSP Ping/Traceroute seit Jahren Standard. Bei SR-MPLS bleibt das Prinzip gleich: Sie müssen die Datenebene validieren – aber je nach SR-Design müssen Sie zusätzlich Policy- und SID-Logik belegen.

• Für LDP: LSP Ping/Traceroute entlang der LDP-LSPs, Fokus auf Label-Bindings und LDP-Neighbors.
• Für SR-MPLS: OAM muss neben dem Transportpfad auch die Policy-/SID-Auswahl erklären: Warum wurde diese SID-Liste gewählt? Welche Candidate Path war aktiv? Wie war das Failover?

Als OAM-Referenz bleibt RFC 4379 wichtig. Der Unterschied ist operativ: Bei SR müssen Sie Ihre Beobachtbarkeit um „Policy-Ebene“ erweitern (Status, Telemetrie, Change-Historie).

Traffic Engineering und Policy-Steuerung: Der größte praktische Unterschied

Wenn Ihr Backbone heute bereits stark policy-getrieben ist (z. B. unterschiedliche Pfade für bestimmte Klassen, kontrollierte Inbound/Outbound Shifts, segmentierte Services), dann ist SR-MPLS häufig attraktiver, weil es Path-Intent besser ausdrücken kann. Wenn Ihr Ziel primär „klassischer Transport für L3VPN“ ist und TE hauptsächlich über BGP/IGP-Metriken geschieht, liefert LDP oft ausreichend Nutzen bei geringerem Einführungsrisiko.

• LDP: TE eher indirekt (IGP-Metriken, BGP-Policy, ggf. externe TE-Mechaniken).
• SR-MPLS: TE/Path Steering kann expliziter erfolgen (SIDs/Policies), aber muss operationalisiert werden (Guardrails, Monitoring, Change-Disziplin).

Migrationsabwägung: Wann lohnt sich SR-MPLS wirklich?

Eine Migration ist nur sinnvoll, wenn der betriebliche Gewinn größer ist als das Migrations- und Betriebsrisiko. In der Praxis sind dies häufige „Go“- und „No-Go“-Signale:

SR-MPLS ist oft sinnvoll, wenn …

• Sie Protokollkomplexität reduzieren wollen: weniger LDP-spezifische Fehlerdomänen, weniger Session-Troubleshooting.
• Sie stärker policy-basiert steuern müssen: planbare Pfade, klare TE-Workflows, segmentierte Services.
• Sie moderne FRR-Ansätze nutzen wollen: insbesondere, wenn Ihr Design SR-typische Mechaniken operational sauber unterstützt.
• Ihre Plattformen SR-ready sind: Hardware-FIB, Label-Stack-Kapazität, Telemetrie, OAM-Features.

LDP bleibt oft sinnvoll, wenn …

• Sie maximale Einfachheit priorisieren: etablierte Prozesse, reife Tooling-Landschaft, geringere Schulungslast.
• Ihre TE-Anforderungen überschaubar sind: IGP-basierter Transport mit klassischer Redundanz.
• Ihre Multi-Vendor-Interop sehr kritisch ist: und SR-Feature-Parität nicht durchgängig gesichert ist.
• Sie wenig Spielraum für Migration-Risiken haben: z. B. in sehr ausgelasteten Backbones ohne Headroom.

Operative Migration: Wie Sie LDP → SR-MPLS risikoarm planen

Eine saubere Migration ist weniger „Feature aktivieren“ und mehr Change-Programm mit strikten Validierungen. Bewährt hat sich ein stufenweises Vorgehen mit klaren Stop-Kriterien.

Phase 1: Readiness und Standards

• SID-Plan: Node-SIDs, Adj-SIDs, Reserven, Dokumentation und Ownership festlegen.
• MTU-Standard: Label-Stack-Overhead einkalkulieren, Tests mit großen Paketen durchführen.
• Monitoring-Parität: Telemetrie für SR (Policy-Status, SID-Stacks, Drops) genauso „first class“ wie LDP-Metriken.
• OAM-Runbook: standardisierte Path-Validation für SR definieren (was ist der Beweis für „Path ok“?).

Phase 2: Coexistence und kontrollierte Domänen

In vielen Netzen ist eine Koexistenzphase sinnvoll: Teile des Backbones sprechen SR, während andere noch LDP nutzen. Der kritische Punkt ist, dass die Interoperabilität und das Forwarding-Verhalten über Domänengrenzen klar definiert ist (und gut getestet).

• Domänen definieren: welche PoPs/Router/Services gehen zuerst?
• Blast Radius begrenzen: Start in einer Region oder in einem PoP-Cluster mit guter Observability.
• Traffic Shift kontrollieren: Graceful Vorgehen, um Rehashing- und Congestion-Risiken zu minimieren.

Phase 3: Service-by-Service Validierung

• L3VPN: Customer Reachability, VRF-Routen, MPLS OAM, MTU, Dual-Stack separat prüfen.
• Anycast/Edge Services: regionale Probes, Traffic-Share-Änderungen, Cold-Cache-Effekte berücksichtigen.
• Failure Drills: kontrollierte Link-Fails, um FRR und Konvergenz zu messen (Time-to-No-Impact).

Phase 4: Rückbau von LDP

Der Rückbau ist operativ oft der riskanteste Schritt, weil er die letzte „Fallback-Schiene“ entfernt. Er sollte erst erfolgen, wenn SR-Monitoring und Runbooks im Alltag nachweislich funktionieren.

Häufige Migrations-Pitfalls und wie Sie sie vermeiden

• MTU zu spät geprüft: Label-Stack wächst, Anwendungen brechen, „mysteriöse“ Drops nach Migration.
• Policy-Ebene nicht beobachtbar: SR Policies laufen, aber niemand sieht Candidate Paths/Failover – Troubleshooting wird langsamer.
• Dual-Stack vergessen: IPv4 ok, IPv6 broken (ICMPv6/PMTUD/QoS-Drift).
• ECMP- und LAG-Partial Failures: per-member Telemetrie fehlt, selektive Drops werden nicht erkannt.
• Zu große Schritte: „Big Bang“ ohne Headroom und ohne Stop-Kriterien erhöht Second-Outage-Risiko.

Operative Checkliste: Entscheidung und Umsetzung

• Ziele festlegen: Kosten, Latenz, Resilienz, TE-Fähigkeit – was ist der messbare Gewinn?
• Plattformfähigkeit prüfen: SR-Feature-Parität, OAM, Telemetrie, Label-Stack-Kapazität.
• Monitoring-Parität sicherstellen: SR muss genauso gut messbar sein wie LDP (Sessions, Drops, Pfade, Anomalien).
• Migration stufenweise: kleine Domänen, klare Stop-Kriterien, Rollback-Plan, Post-Validation.
• Runbooks aktualisieren: NOC braucht konkrete Nachweise (Path, Policy, Forwarding), nicht nur neue Begriffe.

Outbound-Ressourcen

• RFC 5036 (LDP Specification)
• RFC 3031 (MPLS Architecture)
• RFC 8402 (Segment Routing Architecture)
• RFC 8660 (SR-MPLS: Segment Routing with MPLS Data Plane)
• RFC 4379 (MPLS LSP Ping/Traceroute OAM)
• RFC 4364 (BGP/MPLS L3VPN, Kontext für Transportwahl)
• RFC 5880 (BFD: schnelle Failure Detection, relevant für Konvergenz)
• RFC 5286 (Loop-Free Alternates, FRR-Grundlage)

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.