Eine MPLS zu SR Migration ist für Telcos eine der wirkungsvollsten Modernisierungen im Backbone, weil Segment Routing (SR) viele klassische MPLS-Mechaniken vereinheitlicht und betriebliche Komplexität reduzieren kann – vorausgesetzt, die Migration ist sauber geplant. In Brownfield-Netzen läuft MPLS oft seit Jahren stabil: LDP oder RSVP-TE sind etabliert, FRR ist getuned, L3VPN/L2VPN-Services laufen, und die Betriebsprozesse sind eingespielt. Genau deshalb ist ein „Big Bang“ riskant: SR muss parallel eingeführt werden, ohne Routing-Chaos, ohne Serviceunterbrechung und ohne Control-Plane-Überlast. Der Kern einer erfolgreichen Umstellung ist ein Phasenplan, der Underlay, Traffic Engineering und Services getrennt behandelt, sowie eine Interop-Strategie, die Multi-Vendor-Realität und gemischte Feature-Stände berücksichtigt. In der Praxis bedeutet das: erst IGP/SR-Basics stabilisieren (SR-MPLS oder SRv6 als Ziel), dann Schutzmechanismen (FRR/TI-LFA) nachweisbar machen, anschließend TE/Policies kontrolliert aktivieren und erst zum Schluss Altmechanismen (LDP/RSVP-TE) dekommissionieren. Gleichzeitig müssen Guardrails aktiv sein: MTU-End-to-End, QoS an Engpässen, Max-Prefix/Control-Plane Protection, konsistente SRGB/SID-Strategien und Observability-by-Design. Dieser Artikel beschreibt einen praxistauglichen Phasenplan und zeigt, wie Sie Interoperabilität sicherstellen, wie Sie die Übergangsphase mit Dual-Stack im Label-Sinn (LDP + SR) beherrschen und mit welchen Metriken Sie Migrationserfolg objektiv messen.
Warum Segment Routing: Nutzen, der die Migration rechtfertigt
Segment Routing ist kein „neues MPLS“, sondern ein anderer Steuermechanismus für Pfade. Bei SR-MPLS werden Labels als Segmente genutzt, die von IGP oder Controller bereitgestellt werden. Das reduziert Abhängigkeiten von separaten Signalisierungsprotokollen für Pfadsteuerung und kann Design und Betrieb vereinfachen. Für viele Telcos ist der Hauptnutzen: weniger Protokolle, konsistentere Pfadsteuerung, bessere Automatisierbarkeit und klarere Failure Handling-Konzepte.
- Vereinfachung: SR-MPLS kann LDP ersetzen; bei SR-TE entfallen RSVP-TE-spezifische Tunnel-Signalisierungsaspekte.
- Bessere Automatisierung: Policies und SIDs lassen sich intentbasiert verwalten und versionieren.
- Resilienz: TI-LFA lässt sich gezielt designen und liefert schnelle Recovery, wenn die Topologie passt.
- Skalierung: Weniger State in einzelnen Protokollschichten und klarere Hierarchien, wenn sauber segmentiert.
Leitprinzip: Migration wird nicht durch Features gewonnen, sondern durch Stabilität
Der Nutzen von SR ist real, aber nur dann produktiv, wenn die Umstellung in klaren, messbaren Schritten erfolgt und die Übergangsphase explizit abgesichert wird.
Vorarbeit: Zielbild, Scope und Entscheidung SR-MPLS vs. SRv6
Bevor Sie Phasen planen, muss das Zielbild klar sein. In vielen Backbones ist SR-MPLS der natürliche erste Schritt, weil es direkt in bestehende MPLS-Forwarding-Modelle passt und Services (L3VPN/L2VPN) weiterlaufen. SRv6 bietet zusätzliche Flexibilität, bringt aber mehr Header-Overhead und erfordert sehr saubere MTU-Strategien sowie häufig stärkere Hardwareanforderungen. Ein pragmatisches Zielbild definiert außerdem, ob SR zunächst nur als Underlay (IGP-SR) genutzt wird oder ob SR-TE/Policies und Controller-Funktionen sofort dazugehören.
- SR-MPLS als Ziel: Gut für schrittweise Migration aus LDP/RSVP-TE, oft geringeres Risiko in bestehenden MPLS-Services.
- SRv6 als Ziel: Interessant für IPv6-first Netze und bestimmte Service-Modelle, aber MTU/Overhead und Plattform-Interop sind kritischer.
- Scope festlegen: Nur Core/Metro zuerst, Services später; oder bestimmte Regionen/PoPs als Canary.
- Interop-Ziel: Definieren, welche Vendor-/Release-Kombinationen unterstützt sind (Version-Matrix).
Designregel: Erst Underlay stabil, dann TE, dann Services
Eine saubere Reihenfolge reduziert Blast Radius: Wenn das Underlay stabil und beobachtbar ist, lassen sich TE- und Service-Migrationen kontrolliert darüber legen.
Phasenplan: MPLS zu SR Migration in kontrollierten Schritten
Ein belastbarer Phasenplan trennt technische Umstellung, betriebliche Absicherung und Decommissioning. Wichtig ist, dass jede Phase einen stabilen Endzustand hat und einen getesteten Rollback – nicht nur „Konfig zurück“, sondern auch „Traffic zurücksteuern“.
Phase 0: Datenbasis und Baselines
- Topologie- und SRLG-Transparenz: Linkklassen, Failure Domains, Maintenance Domains als Grundlage für TI-LFA und Rollouts.
- Baselines: Konvergenzzeiten, FRR-Verhalten, p95/p99 Latenz, Queue-Drops, CPU/Memory, BGP/IGP-Churn.
- MTU-Plan: End-to-End MTU inkl. MPLS-Labels und potenzieller SR-Overheads, PMTUD/MSS-Strategie.
- Telemetry-Basis: Metriken für SR (SID/Policy Status), CoPP Counter, IGP Health, ECMP- und LAG-Imbalance.
Phase 1: IGP vorbereiten und SR-Fähigkeit aktivieren
Hier wird SR im IGP aktiviert, ohne sofort den Datenpfad radikal zu verändern. Ziel ist, dass Nodes SIDs sauber announcen, SRGB konsistent ist und die Control Plane stabil bleibt.
- IGP-Standardisierung: Timerprofile, Authentisierung, Summarization-Grenzen, stabile Flooding-Scopes.
- SRGB planen: Einheitlicher SRGB-Bereich, dokumentiert; keine zufälligen Defaults pro Vendor.
- SID-Strategie: Node-SIDs (und ggf. Anycast-SIDs) eindeutig; klare Regeln für Zuweisung (z. B. aus Loopback/Pools).
- Rollout als Canary: SR-Enablement zuerst in einer begrenzten Domäne/Region, um Interop und Telemetry zu verifizieren.
Phase 2: LDP-zu-SR Koexistenz (Dual Control Plane, kontrollierte Forwarding-Pfade)
In vielen Netzen läuft SR zunächst parallel zu LDP. Ziel ist nicht, zwei Welten „dauerhaft“ zu betreiben, sondern die Übergangszeit abzusichern. Wichtig ist, zu definieren, welche Label-Verteilung für welche FECs gilt und wie Fallbacks aussehen.
- Koexistenzregeln: Welche Präfixe/FECs sollen über SR laufen, welche über LDP (zunächst häufig weiterhin LDP für breite Stabilität).
- Penultimate Hop Popping (PHP) und UHP: Verhalten konsistent halten, um unerwartete MPLS-Stack-Effekte zu vermeiden.
- Interop-Kanten identifizieren: Mischknoten (SR-fähig) vs. Legacyknoten (nur LDP) und klare Transitpfade.
- Guardrails: Control-Plane Protection und Max-Limits, damit zusätzlicher IGP/SR-State nicht zur CPU-Falle wird.
Phase 3: Resilienz umstellen – FRR/TI-LFA nachweisbar machen
SR-Migrationen werden oft wegen TI-LFA und konsistenter FRR-Strategien angestoßen. Entscheidend ist Coverage: Welche Links und Nodes sind geschützt? Wo fehlen Backup-Pfade? Ohne Coverage-Nachweis wird FRR zur Hoffnung.
- Coverage-Analyse: Link- und Node-Protection pro Topologiesegment; Lücken als Engineering-Backlog.
- BFD-Profile: Konsistent und stabil (nicht aggressiv), abgestimmt auf Plattform und Linkqualität.
- Failure Scenario Tests: Link down, Node down, DCI-Partition (wo relevant) – Expected vs. Observed dokumentieren.
- Operationalisierung: Alarmierung für FRR-Events, ungewöhnlichen Churn, und Degradation (Loss/RTT) statt nur „Down“.
Phase 4: Traffic Engineering auf SR-Basis (SR-TE/Policies) kontrolliert einführen
Wenn der Underlay stabil ist, können SR Policies für TE eingeführt werden. Hier entstehen häufig die größten Betriebsrisiken: unerwartete Pfade, Engpassverschiebungen, QoS-Regression. Daher sollte TE progressiv ausgerollt werden, mit klaren SLO-Gates.
- Policy-Model: Welche Traffic-Klassen werden gesteuert (z. B. DCI, Latenz-kritisch, Bulk)?
- Controller vs. Distributed: Zentraler Controller bietet Konsistenz, erhöht aber Abhängigkeiten; distributed Policies reduzieren Abhängigkeit, erhöhen aber Konfigaufwand.
- Engpassmanagement: QoS und Shaping an definierten Engpässen, bevor Pfade aktiv umgelenkt werden.
- Canary-Policies: Zuerst wenige Flows/Services steuern, danach in Wellen erweitern.
Phase 5: Services stabil halten und schrittweise „SR-native“ machen
Viele MPLS-Services (L3VPN/L2VPN) können während der Underlay-Migration weiterlaufen. Trotzdem sollten Sie prüfen, ob Servicekanten (PEs) und Service-Policies (QoS, Route Targets) unverändert korrekt funktionieren, insbesondere bei geänderten Pfaden und Failoververhalten.
- VRF-Isolation: Keine unerwünschten Route Leaks, konsistente RT/RD-Modelle.
- Service SLOs: Latenz/Loss/Konvergenz pro Serviceklasse messen, nicht nur im Core.
- Stateful Service Chains: Symmetrieanforderungen prüfen (Firewalls, CGNAT, DPI) – Mesh/SR kann Pfade verändern.
- Interconnect-Policies: Kein Leak durch neue TE-Pfade; Export-Whitelists und Max-Prefix bleiben Pflicht.
Phase 6: Decommissioning – LDP/RSVP-TE zurückbauen, aber erst nach stabiler Nachweisführung
Der Rückbau ist oft riskanter als die Einführung, weil „Alt“ als Fallback verschwindet. Deshalb ist Decommissioning eine eigene Phase mit Gates: Coverage, SLOs, Incident-Rate und Drift müssen stabil sein.
- LDP reduzieren: Schrittweise aus Domänen entfernen, beginnend mit vollständig SR-fähigen Segmenten.
- RSVP-TE ablösen: TE-Policies auf SR-TE umstellen, Tunnelinventar bereinigen, Monitoring umstellen.
- Cleanup: Alte Timerprofile, alte Policy-Sonderfälle, Dokumentation/SoT finalisieren.
- Rollback-Plan: Für den Rückbau explizit: Was ist der „sichere Zustand“, wenn LDP/RSVP-TE nicht mehr vorhanden ist?
Interop-Strategien: Multi-Vendor und Mischstände sicher beherrschen
In Telco-Netzen ist Interoperabilität der zentrale Erfolgsfaktor. SR-Features sind standardisiert, aber Details und Defaults unterscheiden sich. Eine Interop-Strategie reduziert diese Varianz durch Blueprints, explizite Parameter und eine unterstützte Version-Matrix.
- SRGB-Konsistenz: Ein einheitlicher SRGB-Plan, explizit konfiguriert auf allen Plattformen.
- SID-Zuweisung: Node-SIDs und Anycast-SIDs aus klaren Pools; keine vendor-spezifischen Auto-IDs ohne Kontrolle.
- Feature-Disziplin: Nur getestete Optionen aktivieren (z. B. bestimmte SR-TE-Policy-Mechaniken, bestimmte BGP-Optionen).
- Version-Matrix: Unterstützte Kombinationen aus Vendor/OS-Versionen definieren und durch Change-Gates erzwingen.
- Koexistenzregeln: Für Übergangszustände klar festlegen, wie SR- und LDP-Labels in gemischten Pfaden behandelt werden.
Designregel: „Lowest common denominator“ im Transport, Innovation in klaren Domänen
Halten Sie den Core/Transport möglichst standardnah und konservativ, und nutzen Sie fortgeschrittene SR-TE-Funktionen in abgegrenzten Domänen, wenn deren Stabilität nachweislich ist.
Risikofelder: Wo MPLS zu SR Migrationen typischerweise scheitern
- MTU/Label-Stack: Zusätzliche Labels oder Overhead führen zu selektiven Blackholes, besonders bei DCI/Overlays.
- FRR Coverage-Lücken: TI-LFA wird erwartet, aber Topologie liefert nicht überall Backup-Pfade.
- TE erzeugt Hotspots: Pfadsteuerung verschiebt Engpässe; ohne QoS/Headroom brechen SLOs.
- Control-Plane Overload: Mehr State und Updates, Telemetry-Fehlkonfigurationen, fehlende CoPP-Profile.
- Interop-Defaults: Unterschiedliche Defaults bei PHP/UHP, ECMP, BFD, SR-TE-Policy-Handling.
- Operational Drift: Parallelbetrieb dauert zu lange, Ausnahmen werden dauerhaft, Dokumentation/SoT driftet.
Anti-Pattern: „Wir aktivieren SR überall und schauen dann“
SR sollte in kontrollierten Bereichen eingeführt werden, mit Canary-Scopes, klaren Tests und objektiven Stop/Go-Gates.
Tests und Nachweise: Lab-Reproduktion und Intent Validation als Pflicht
Eine SR-Migration ist ideal für Lab-Reproduktion, weil viele Risiken in Control Plane und Policy-Wirkung liegen. Ergänzend sorgt Intent Validation dafür, dass Guardrails vor jedem Change geprüft werden. Beide Instrumente sind besonders wertvoll in Multi-Vendor-Umgebungen.
- Lab: Teil-Topologie (Core/Metro) nachbauen, SRGB/SIDs, FRR/TI-LFA, SR-TE-Policies und Failure Scenarios testen.
- Intent Checks: Export-Whitelists, Max-Prefix, MTU-Minimum, QoS-Failover-Profil, RR-Redundanz, CoPP aktiv.
- Failure Workshops: Link/Node/Region-Ausfälle durchspielen, Expected vs. Observed dokumentieren.
- Canary in Produktion: Nach Lab/Intent: kleine Domänen, echte Last, observability-gesteuerte Freigabe.
Erfolgsmetriken: Wie Sie Fortschritt und Stabilität objektiv messen
Eine Migration ist erfolgreich, wenn sie messbar stabiler oder effizienter wird, nicht nur „neue Technik nutzt“. Definieren Sie Metriken in drei Gruppen: Resilienz, Performance/Capacity und Operability. Besonders wichtig sind Vorher/Nachher-Vergleiche und N-1-Tests.
- Resilienz: Konvergenzzeit bei Link/Node-Ausfall, FRR-Activation-Rate, TI-LFA Coverage, Blast Radius pro Failure Domain.
- Performance: p95/p99 RTT, Loss, Queue-Drops an Engpässen, ECMP/LAG-Imbalance, DCI-Headroom im Failover.
- Operability: Change-Failure-Rate, MTTR, Anzahl manueller Hotfixes, Drift-Events zwischen SoT und Netz.
Ein einfacher Go/No-Go-Frame für jede Phase
Go= (GuardrailsOK) ∧ (CoverageOK) ∧ (SLOsWithinBudget)
Wenn Guardrails greifen, FRR-Coverage nachweisbar ist und SLOs im Budget bleiben, ist die nächste Welle vertretbar.
Praktische Leitlinien: MPLS zu SR Migration sicher umsetzen
- Zielbild präzisieren: SR-MPLS vs. SRv6, Underlay zuerst, TE/Services später; Scope und Version-Matrix definieren.
- SRGB/SID-Strategie standardisieren: Explizite SRGB-Bereiche, eindeutige Node-/Anycast-SIDs, dokumentiert und auditierbar.
- Koexistenz bewusst planen: LDP+SR Übergangszustand mit klaren Regeln und zeitlicher Begrenzung, kein Dauerbetrieb.
- Resilienz nachweisen: TI-LFA/FRR Coverage messen, Failure Scenarios testen, BFD stabil konfigurieren.
- TE progressiv einführen: Canary-Policies, Engpass-QoS, Steering reversibel; SLO-Gates pro Welle.
- MTU-End-to-End absichern: Overhead berücksichtigen, PMTUD/MSS-Strategien, Tests über Failoverpfade.
- Control Plane schützen: CoPP/Profile, Update-Rate Monitoring, Telemetry-Limits, Max-Prefix auf Interconnects.
- Lab + Intent Validation verpflichtend: Pre-Change-Checks für Guardrails und Policy-Wirkung, Evidence-by-Design archivieren.
- Decommissioning als eigene Phase: LDP/RSVP-TE erst entfernen, wenn Stabilität, Coverage und Operability nachweislich sind.
- Dokumentation/SoT konsistent halten: Multi-Layer-Doku aktualisieren, Drift-Detection betreiben, Ausnahmeprozesse mit Ablaufdatum.