LDP-to-SR Migration: Migrationspfad ohne Big Bang

Eine LDP-to-SR Migration ist selten ein „Feature-Upgrade“ – sie ist ein Underlay- und Betriebswechsel: Du ersetzt hop-by-hop Label-Signaling (LDP) durch Segment Routing (SR-MPLS) mit SIDs und SRGB. Der größte Fehler ist der Big-Bang-Ansatz („LDP aus, SR an“): In produktiven Backbones führt das schnell zu Label-Inkonsistenzen, unerwarteten Pfaden oder Blackholes. Ein sicherer Migrationspfad arbeitet stattdessen stufenweise: erst SR-Readiness herstellen, dann SR parallel ausrollen (ohne Traffic umzulegen), dann gezielt Services/Traffic auf SR schwenken und erst ganz am Ende LDP kontrolliert zurückbauen. Dieses Tutorial zeigt einen praxistauglichen Plan mit Pre-/Post-Checks und Guardrails.

Warum „parallel“ das Schlüsselwort ist

LDP und SR können in vielen Designs koexistieren, solange du klar definierst, wofür welches Labeling genutzt wird. Das Ziel der Migration ist nicht „SR sofort nutzen“, sondern „SR sicher verfügbar machen“ – damit du später kontrolliert umschalten kannst.

• Phase 1: SR-Fähigkeit herstellen (SIDs sichtbar, SRGB konsistent)
• Phase 2: Parallelbetrieb (LDP bleibt Transport, SR wird validiert)
• Phase 3: Service-by-Service Cutover (SR wird Transport/TE)
• Phase 4: LDP-Return/Retire (LDP kontrolliert abbauen)

Readiness Check: Voraussetzungen vor dem ersten SR-Rollout

Bevor du SR konfigurierst, prüfst du Plattformen und Design-Fitness: SRGB-Konsistenz, IGP-Topologie, MTU, Hardware-Forwarding und Observability. In der Praxis entscheidet Readiness über 80% des Migrationserfolgs.

• IOS XE Releases/Linecards: SR-MPLS Support und Feature-Parity
• IGP stabil (IS-IS/OSPF), Loopbacks sauber, keine Flaps
• MPLS MTU ausreichend (Label-Stack einplanen)
• Telemetry: Drops, CPU, MPLS Forwarding sichtbar

Baseline-Checks

show ip route <core-loopback>
show mpls interfaces
show mpls ldp neighbor
show mpls forwarding-table
show processes cpu sorted

Designentscheidung: SRGB und SID-Plan festlegen

Der SRGB muss domänenweit konsistent sein, damit gleiche SID-Indizes überall dieselben Labels ergeben. Zusätzlich brauchst du einen SID-Plan: welcher Router bekommt welchen Node-SID Index. Ohne Plan entsteht später Debug-Chaos.

SRGB-Formel

$\text{Label}=\text{SRGB\_Base}+\text{SID\_Index}$

• SRGB Base z. B. 16000, Range z. B. 8000
• Node-SID Index pro Router eindeutig (Registry!)
• Prefix-SIDs nur dort, wo sinnvoll (Anycast/Services)

Phase 1: SR aktivieren – ohne Traffic umzuschalten

Du aktivierst SR im Underlay-IGP und setzt Node-SIDs, lässt aber LDP weiterhin als Transport aktiv. In dieser Phase prüfst du nur: SIDs werden verteilt, Labels erscheinen in der Forwarding-Tabelle, und es gibt keine Nebenwirkungen.

SR-MPLS global + SRGB (Pattern)

segment-routing mpls
 global-block 16000 23999

IS-IS mit SR (Pattern)

router isis CORE
 is-type level-2
 segment-routing mpls
interface loopback0

ip address 10.255.0.1 255.255.255.255

isis enable CORE

isis prefix-sid index 1

Parallel: LDP bleibt aktiv (keine Änderung)

show mpls ldp neighbor

Phase 1 Verifikation: SIDs sichtbar, Forwarding plausibel

In dieser Phase musst du beweisen, dass SR „funktioniert“, ohne dass irgendein Service davon abhängt. Du prüfst SR SID-Datenbank, IGP-DB und MPLS Forwarding. Ziel: keine Überraschungen beim späteren Cutover.

SR Sichtbarkeit

show segment-routing mpls
show segment-routing mpls sid-database

Forwarding-Checks

show mpls forwarding-table | include 160
traceroute mpls ipv4 <remote-loopback>

Phase 2: SR-Transport für ausgewählte Flüsse testen (Pilot)

Der nächste Schritt ist ein Pilot: du wählst eine kleine Domäne (z. B. ein PoP) oder einen definierten Traffic-Flow und steerst ihn über SR (z. B. SR Policy). LDP bleibt als Fallback im Netz. Du testest Failover, MTU und Drops.

• Pilot-Umfang klein halten (Blast Radius minimieren)
• SR Policy für einen Endpoint definieren
• Monitoring: Drops/CPU/Convergence messen

SR Policy (statisches Pattern)

segment-routing
 traffic-eng
  policy POL_TO_PE2
   color 100 end-point ipv4 10.255.0.2
   candidate-paths
    preference 200
     dynamic

Phase 3: Service-by-Service Cutover – ohne Big Bang

Jetzt schwenkst du schrittweise um. Welche „Services“? Typisch sind: Transport für L3VPN (BGP-LU/SR), L2VPN/EVPN Underlay, oder bestimmte TE-Flows. Der Kern ist: nie alles gleichzeitig, immer mit Rollback.

• Start: Backbone-Transport zu PE-Loopbacks (Core-Transport)
• Dann: TE-Policies/Traffic-Klassen
• Dann: VPN-Services, wenn Transport stabil ist

Cutover-Prinzip

• Ein Cluster/PoP nach dem anderen
• Pre-/Post-Checks automatisieren
• Rollback jederzeit möglich (LDP weiter vorhanden)

Phase 4: LDP zurückbauen – kontrolliert und messbar

Erst wenn SR als Transport für alle relevanten Pfade stabil läuft, beginnst du LDP zu deaktivieren. Das geschieht ebenfalls schrittweise: erst auf ausgewählten Links/Nodes, dann domänenweit. Wichtig ist, dass IGP/SR weiterhin alle notwendigen Label-Pfade liefert.

• Voraussetzung: SR Forwarding vollständig, keine Abhängigkeiten von LDP
• Rollback-Plan: LDP wieder aktivierbar, falls unerwartete Lücken
• Kontrolle: LFIB-Entries und End-to-End Tests

Typische Schritte beim LDP-Return (konzeptionell)

! Beispiel: LDP auf einem Interface deaktivieren (Pattern)
interface gigabitEthernet0/0
 no mpls ip

Wichtiges Guardrail: LDP/IGP Sync vs. SR-Konvergenz

In LDP-Netzen verhindert LDP/IGP Sync Blackholes. Bei SR brauchst du ähnliche Konvergenz-Governance: stabile IGP-Konvergenz, passende FRR-Mechanismen (z. B. TI-LFA) und Monitoring der Data Plane Drops. Sonst ersetzt du ein Guardrail durch Hoffnung.

• IGP-Konvergenz und FRR-Design vor Cutover prüfen
• TI-LFA/FRR nur nutzen, wenn Topologie es hergibt
• Data-Plane Drops (QFP/ASIC) beobachten

Typische Pitfalls in der Migration

Die häufigsten Migrationsprobleme sind wiederkehrend. Wenn du sie vorab adressierst, wird der Rollout deutlich ruhiger.

• SRGB inkonsistent → Label-Bedeutung stimmt nicht überall
• Node-SID Kollisionen → Pfade werden unvorhersehbar
• MTU nicht angepasst → Drops nach Cutover (Label-Stack größer)
• Observability fehlt → Fehler erst „im Traffic“ sichtbar
• Zu großer Cutover-Schritt → kein sauberer Rollback

Monitoring während der Migration: Was du messen musst

Migration ist ein Telemetrie-Projekt. Du brauchst Metriken, die „still“ zeigen, ob etwas schlechter wird, bevor Nutzer es melden: Drops, CPU, IGP Flaps, SR Policy State und MPLS Forwarding Health.

• SR Policy State (active candidate, switches)
• MPLS/SR Forwarding Table Änderungen
• Interface Drops/Errors und Plattform-Drops
• IGP Neighbor Stability

On-Box Monitoring Pack

show segment-routing mpls
show segment-routing mpls sid-database
show segment-routing traffic-eng policy
show mpls forwarding-table
show interfaces | include drops|error
show platform hardware qfp active statistics drop
show isis neighbors
show processes cpu sorted

Quick-Runbook: Migrationsschritt sicher durchführen

Diese Sequenz eignet sich für jeden kontrollierten Cutover-Schritt: Baseline, Change, Verifikation, Rollback-Kriterium.

! Pre
show ip route <remote-loopback>
show mpls forwarding-table
show segment-routing mpls sid-database
show interfaces | include drops|error
! Change (SR aktivieren / Policy setzen / LDP reduzieren)
! Post

show segment-routing traffic-eng policy

show mpls forwarding-table

traceroute mpls ipv4 

show platform hardware qfp active statistics drop

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.