Migrationsdesign: Von MPLS zu Segment Routing in klaren Schritten

Migrationsdesign: Von MPLS zu Segment Routing in klaren Schritten ist für viele Provider und Telcos aktuell ein zentrales Vorhaben, weil Segment Routing (SR) die Komplexität klassischer MPLS-TE-Umgebungen reduzieren und gleichzeitig moderne Anforderungen an Traffic Engineering, Automatisierung und Observability besser unterstützen kann. Dabei ist wichtig: Eine Migration ist kein „Big Bang“. In großen Carrier-Netzen laufen L2/L3VPNs, Internet- und Peering-Services, Mobile Backhaul sowie Service-Farms (z. B. CGNAT, Firewall, UPF) oft über Jahre stabil – und genau das darf sich während der Umstellung nicht ändern. Ein professionelles Migrationsdesign definiert daher ein Zielbild (SR-MPLS oder SRv6), einen schrittweisen Pfad dorthin, klare Kompatibilitätsregeln für die Übergangszeit und messbare Akzeptanzkriterien. Dazu gehören: IGP- und iBGP-Design, Label-/SID-Plan, FRR- und TE-Strategie, Interworking mit bestehenden LDP- oder RSVP-TE-Mechanismen, ein Rollout- und Rollback-Konzept sowie Telemetrie, die Konvergenz und Servicequalität während der Migration sichtbar macht. Dieser Artikel zeigt praxisnah, wie Sie von MPLS zu Segment Routing migrieren, ohne Stabilität zu riskieren, und wie Sie typische Stolperfallen vermeiden, die aus einer „technisch machbaren“ Migration schnell ein operatives Risiko machen.

Warum überhaupt migrieren: Nutzen und typische Ziele

Segment Routing bringt im Provider-Umfeld vor allem zwei Vorteile: Erstens kann SR den Signalisierungsaufwand klassischer MPLS-TE-Lösungen reduzieren, weil Pfadsteuerung über Segmente (SIDs) erfolgt, die auf IGP-Informationen basieren. Zweitens wird Automatisierung einfacher, weil SR-Policies und Pfadentscheidungen besser mit zentralen Controllern, Telemetrie und modernen Betriebsmodellen zusammenspielen können. Das Ziel ist selten „MPLS abschaffen“, sondern „weniger Betriebsaufwand bei gleichbleibender oder besserer QoE“.

• Vereinfachung: Weniger State in der Netzsignalisierung, klarere TE- und FRR-Mechanismen.
• Skalierung: Besseres Handling großer Topologien und vieler Services durch standardisierte Pfadsteuerung.
• Konvergenz: Saubere Repair-Pfade und kontrollierbare Schutzfallprofile.
• Automation: SR-Policies lassen sich konsistenter als „Intent“ beschreiben und ausrollen.
• Observability: Bessere Transparenz über Pfade, Latenz, Drops und TE-Auswirkungen.

Begriffe und Varianten: SR-MPLS vs. SRv6

Segment Routing kann in zwei Hauptformen auftreten. SR-MPLS nutzt MPLS-Labels als SIDs (Segment Identifiers). SRv6 nutzt IPv6-Addresses als SIDs und transportiert Segmentinformationen in IPv6-Headern. In vielen Telco-Migrationsprojekten ist SR-MPLS der erste Schritt, weil bestehende MPLS-Forwarding- und Service-Mechanismen (L3VPN, EVPN, ggf. L2VPN) oft leichter weiterverwendet werden können. SRv6 kann je nach Netzstrategie später folgen, etwa wenn ein stärker IPv6-zentriertes Design oder bestimmte Serviceketten/Programmierungsvorteile gewünscht sind.

• SR-MPLS: SIDs als Labels; oft der pragmatischste Einstieg aus MPLS-IP-Backbones.
• SRv6: SIDs als IPv6; stärker „IP-native“, aber erfordert konsequente IPv6-Fähigkeit und Header-Overhead-Betrachtung.
• Migrationsrealität: Viele Netze fahren längere Zeit Hybridbetrieb (SR + klassische MPLS-Mechanismen).

Startpunkt: Bestandsaufnahme und Zielbild definieren

Ein Migrationsdesign beginnt mit einer nüchternen Bestandsaufnahme. Sie müssen wissen, welche Dienste über das Netz laufen, welche Control-Plane-Mechanismen aktiv sind (IGP, iBGP, LDP, RSVP-TE), wie FRR umgesetzt ist, wo Engpässe und Failure Domains liegen und welche Plattformen welche SR-Funktionen unterstützen. Gleichzeitig definieren Sie das Zielbild: Wollen Sie „nur“ SR als Underlay und behalten die Service-Layer (z. B. L3VPN) weitgehend gleich? Oder möchten Sie Traffic Engineering und Pfadsteuerung neu aufstellen?

• Service-Inventar: L3VPN/L2VPN/EVPN, Internet Edge, Mobile Backhaul, Multicast, Wholesale, Service-Farms.
• Control Plane Status: IGP-Design, RR-Topologie, LDP/RSVP-TE-Verwendung, TE-Domänen.
• Hardware/Software: SR-Fähigkeiten, Label-/SID-Kapazität, Telemetrie, Linecard-Constraints.
• SLO/SLA: Konvergenz- und QoE-Ziele, Wartungsfenster, Schutzfallprofile (N-1).

Grundregel der Migration: Stabiler Underlay zuerst, TE/Policies danach

Der häufigste Erfolgspfad ist: zuerst SR im Underlay einführen (SIDs, SR-fähiges IGP, grundlegende Forwardingfähigkeit), dann schrittweise Traffic Engineering (SR-Policies, ggf. Controller) aktivieren und erst danach alte TE-Mechanismen zurückbauen. So minimieren Sie das Risiko, dass gleichzeitig mehrere grundlegende Verhaltensweisen wechseln. Außerdem bleibt Troubleshooting einfacher: Wenn Underlay stabil ist, können Sie TE-Änderungen isoliert testen.

• Phase 1: SR-Underlay aktivieren, ohne das Traffic-Engineering-Verhalten sofort zu ändern.
• Phase 2: SR-TE/Policies kontrolliert einführen (Canary, Regionen, Serviceklassen).
• Phase 3: Legacy-Mechanismen (z. B. LDP oder RSVP-TE) schrittweise reduzieren und entfernen.

IGP-Design für SR: IS-IS/OSPF, SIDs und Metrikdisziplin

Segment Routing basiert stark auf dem IGP. Deshalb muss das IGP-Design sauber sein: klare Area/Level-Struktur, konsistente Metriken und stabile Flooding-Charakteristik. Für SR-MPLS werden meist Node-SIDs (pro Router) vergeben, optional auch Adjacency-SIDs (pro Link), wenn sehr präzise Pfadvorgaben nötig sind. Ein gutes Migrationsdesign erstellt einen SID-Plan, der Wachstum, Aggregation und Betrieb berücksichtigt: eindeutig, dokumentiert und automatisierbar.

• Node-SIDs: Basis für SR; sauberer Plan pro Region/PoP erleichtert Betrieb und Fehlersuche.
• Adjacency-SIDs: Für spezielle Pfade; sparsam einsetzen, weil Betrieb komplexer wird.
• Metrikmodell: Konsistent halten, sonst entstehen unerwartete ECMP-/Pfadänderungen während der Migration.
• FRR-Coverage: Schutzmechanismen auf IGP-Basis (z. B. LFA/Remote-LFA) früh planen und messen.

Interworking in der Übergangszeit: LDP, RSVP-TE und SR parallel betreiben

In vielen Netzen existiert MPLS bereits über LDP (für Labels) und eventuell RSVP-TE (für TE-Tunnel). Eine Migration zu SR bedeutet nicht, dass Sie beides sofort abschalten. Häufig wird SR parallel eingeführt, während LDP/RSVP-TE weiterlaufen. Entscheidend ist dabei ein klares Interworking-Konzept: Welche Services nutzen welche Transportmechanik? Wie verhindern Sie doppelte Schutzmechanik oder unerwartete Pfadwahl? Wie stellen Sie sicher, dass Label-/SID-Ressourcen nicht kollidieren?

• Parallelbetrieb: SR und LDP/RSVP-TE können koexistieren, wenn Scope und Regeln klar sind.
• Schutzebenen koordinieren: FRR/Protection nicht unkoordiniert auf mehreren Ebenen aktivieren, um Flapping zu vermeiden.
• Ressourcenplanung: Label-/SID-Space und Hardwarekapazitäten (LFIB) prüfen, bevor Sie breit ausrollen.
• Operational Clarity: NOC muss erkennen können, ob ein Pfad „legacy“ oder „SR“ ist.

SR-TE einführen: Policies, Pfadsteuerung und Controller-Optionen

Der eigentliche Mehrwert entsteht oft mit SR-TE: Sie können Pfade gezielter steuern, Engpässe umgehen, Latenzprofile optimieren oder Premium-Services mit definierten Pfaden versehen. Wichtig ist, SR-TE nicht gleichzeitig überall zu aktivieren. Ein gutes Migrationsdesign startet mit klaren Use Cases: etwa „Hotspot-Umgehung in Busy Hour“, „Low-Latency-Pfad für bestimmte Serviceklassen“ oder „Schutzfallkapazität besser verteilen“. Danach definieren Sie, ob SR-TE lokal (Policy auf Routern) oder zentral (Controller) gesteuert wird.

• Use-Case-getrieben: SR-TE nur dort zuerst, wo Nutzen messbar ist (QoE, Kapazität, Kosten).
• Policy-Standard: Templates und Namensregeln verhindern Policy-Sprawl.
• Controlled Rollout: Canary-PoPs, dann Regionen, dann Flächenausbau.
• Messpflicht: Vorher/Nachher über QoE-Probes, Queue-Drops und Pfadtelemetrie validieren.

Services sicher migrieren: L3VPN/L2VPN/EVPN und Service Edge

Viele Carrier-Services setzen auf MPLS-Transport. Bei SR-MPLS bleibt der Transport MPLS-basiert, nur die Art, wie Labels/Pfade entstehen, ändert sich. Das erlaubt häufig eine schrittweise Migration, bei der Service-Edges (PEs) zunächst im bestehenden Modell laufen, während der Core/Transport bereits SR-fähig ist. Später können PEs auf SR-Transport umgestellt werden. Wichtig ist, dass Sie Service-Impact messen: Nicht nur „VPN ist erreichbar“, sondern auch Session-Stabilität, Jitter/Loss und Schutzfallverhalten.

• Core zuerst: SR im Core/Transport stabilisieren, bevor Sie Service-Edges breit umstellen.
• PE-Migration in Wellen: Nach Regionen/PoP-Klassen, mit klaren Rollback-Schritten.
• Stateful Dienste beachten: NAT/Firewall/UPF/BNG können empfindlich auf Pfadwechsel reagieren; Symmetrie sichern.
• Abnahme: Service-Abnahmetests inklusive Schutzfall (N-1) und QoE, nicht nur Ping.

Konvergenz und Resilienz: FRR, LFA/Remote-LFA und Failure Scenarios

Eine Migration ist nur dann erfolgreich, wenn Ausfälle weiterhin kaum spürbar sind. Deshalb müssen Sie Konvergenz und Resilienz als eigene Arbeitspakete behandeln. SR-Netze nutzen häufig IGP-basierte FRR-Mechanismen. Das Migrationsdesign sollte definieren, welche Failure Scenarios wichtig sind (Link, Node, PoP), welche Umschaltzeiten erwartet werden und wie Sie diese messen. Außerdem müssen Schutzfallpfade kapazitiv passen, sonst wird schnelle Umschaltung zwar erreicht, aber QoE bricht durch Congestion ein.

• Scenario-Katalog: Link-/Node-/PoP-Ausfall, Interconnect-Ausfall, Maintenance Mode, Degradation.
• FRR-Coverage: Nachweis, dass kritische Links und Knoten geschützt sind (Coverage, nicht nur Konfiguration).
• Schutzfallqualität: p95/p99 Latenz, Jitter, Loss und Queue-Drops im Failoverfall prüfen.
• Koordination: Optik-/Ethernet-Schutz und IP-FRR abstimmen, um Flapping zu vermeiden.

Adress- und SID-Planung: Struktur statt Wildwuchs

Wie bei IP-Adressierung gilt auch für SIDs: Ohne Hierarchie wird Betrieb teuer. Ein SID-Plan sollte Regionen, PoP-Klassen und Rollen widerspiegeln. Zusätzlich braucht es Regeln, wie neue SIDs vergeben werden, wie Kollisionen verhindert werden und wie Dokumentation/Source-of-Truth aussieht. Das ist ein Kernpunkt für E-E-A-T im Betrieb: reproduzierbar, auditierbar, standardisiert.

• Hierarchie: Region/PoP/Role abbilden, damit Fehlersuche und Automatisierung einfacher werden.
• Source of Truth: SID-Zuweisung versioniert, reviewbar und automatisiert ausrollbar.
• Reservierung: Platz für Wachstum und neue PoPs einplanen.
• Dokumentation: Diagramme und Datenmodelle verknüpfen (Device-ID ↔ Node-SID).

Observability und Telemetrie: Migration ohne Blindflug

Während der Migration ist Sichtbarkeit entscheidend, weil Pfade sich schrittweise ändern. Sie benötigen daher Telemetrie auf drei Ebenen: Control Plane (IGP/BGP Events, SR-Policy Status, RR-Events), Data Plane (Auslastung, Queue-Drops, Errors) und QoE (Probes, p95/p99). Besonders wertvoll ist eine Pfadtransparenz: Sie sollten nachvollziehen können, welche Segmente ein Traffic tatsächlich nutzt und ob Policies wie geplant wirken.

• Control Plane: Route-Churn, Session-Flaps, SR-Policy Up/Down, IGP-Flooding-Indikatoren.
• Data Plane: Queue-Drops pro Klasse, Microburst-Indikatoren, Linkauslastung im Schutzfall.
• QoE-Probes: RTT/Jitter/Loss zwischen PoPs und zu Service-Edges, vor/nach Migration vergleichen.
• Change-Korrelation: Rollouts/Wartungen markieren, um Regressionen schnell zuzuordnen.

Rollout-Plan: In klaren Wellen migrieren

Ein gutes Migrationsdesign definiert Rollout-Wellen, die technisch und organisatorisch sinnvoll sind. Üblich sind Wellen nach PoP-Klassen: erst Lab/Pilot, dann ein kleiner Canary-PoP, dann eine Region, dann weitere Regionen. Jede Welle hat Abnahmekriterien und einen Rollback-Plan. Wichtig ist außerdem ein Maintenance-Design: Statt „hart abschalten“ werden Knoten drainiert und de-prefered, damit Pfadwechsel kontrolliert stattfinden.

• Pilot: Lab + wenige PoPs mit repräsentativen Services und realem Trafficprofil.
• Canary: Begrenzter Scope, enges Monitoring, klare Abbruchkriterien.
• Regionen: Rollout nach Region/PoP-Klasse; keine parallelen Changes in derselben Failure Domain.
• Standard-Runbooks: Schrittfolgen, Checks, Rollback – damit Ausführung reproduzierbar bleibt.

Rollback-Design: Rückbau muss genauso geplant sein wie Aufbau

Migrationen scheitern oft nicht an der Technik, sondern an fehlenden Rückfallebenen. Ein Rollback-Design beschreibt, wie Sie bei Problemen kontrolliert zurückkehren, ohne neue Instabilität zu erzeugen. Das betrifft sowohl Routing/Policies als auch Services. Wichtig ist, dass Rollback nicht ad hoc passiert, sondern als getesteter Ablauf existiert: Welche Parameter werden zurückgesetzt? Welche Sessions müssen neu aufgebaut werden? Welche SLOs müssen wieder erreicht sein, bevor Sie erneut starten?

• Rollback pro Welle: Für jede Rolloutstufe definierter Rückbaupfad.
• Konfig-Templates: Policy-as-Code und Versionierung ermöglichen schnellen, sauberen Rücksprung.
• Health-Kriterien: QoE/Queue-Drops/Control-Plane-Stabilität als harte Entscheidungspunkte.
• Kommunikation: NOC/SOC/Field und Stakeholder kennen den Rollback-Prozess und Trigger.

Governance: Standardisierung, Blueprints und Change-Sicherheit

SR-Migration ist ein mehrmonatiges bis mehrjähriges Programm. Ohne Governance entsteht Drift: Regionen konfigurieren unterschiedlich, Policies wachsen unkontrolliert, und die Übergangsphase verlängert sich. Daher sollte das Migrationsdesign Blueprints definieren: Core-Blueprint (IGP/SIDs/FRR), Metro-Blueprint (Aggregation/Protection), Edge-Blueprint (Interconnect/Policies), sowie Standards für Telemetrie und Dokumentation. Design Reviews und Abnahmechecklisten stellen sicher, dass jede Welle konsistent ausgerollt wird.

• Blueprints: Wiederholbare Muster statt Einzelfallkonfiguration pro PoP.
• Design Reviews: Prüfen von Failure Domains, Schutzfallkapazität, SRLGs und Konvergenz.
• Deviation-Prozess: Abweichungen nur mit Begründung und Ablaufdatum, damit Migration nicht „stecken bleibt“.
• Postmortem-Loop: Jedes Problem verbessert den Blueprint, statt Workarounds zu zementieren.

Typische Stolperfallen bei der Migration von MPLS zu Segment Routing

Die häufigsten Probleme entstehen, wenn zu viel gleichzeitig verändert wird oder wenn man SR als rein technisches Feature betrachtet. Besonders gefährlich sind unklare Interworking-Regeln, fehlende Kapazitätsplanung im Schutzfall, fehlende Pfadtransparenz und fehlende Hysterese, die zu Instabilität führt. Ebenso kritisch: stateful Services werden nicht berücksichtigt, und Pfadwechsel lösen Mass-Reconnects aus.

• Big-Bang-Ansatz: Underlay, TE und Services gleichzeitig – erhöht Risiko und erschwert Root Cause Analysis.
• Unklare Parallelphase: Niemand weiß, ob Pfade über LDP/RSVP-TE oder SR laufen; NOC verliert Übersicht.
• Schutzfall ignoriert: N-1 führt zu Congestion; QoE verschlechtert sich trotz „moderner“ Technik.
• Zu viele Adjacency-SIDs: Betrieb wird komplex; besser sparsam und zielgerichtet einsetzen.
• Fehlende Telemetrie: Ohne SR-Policy- und Pfadobservability wird Debugging langsam und riskant.
• Statefulness übersehen: NAT/Firewall/UPF/BNG reagieren empfindlich auf asymmetrische Pfade.

Operative Checkliste: Migration von MPLS zu Segment Routing in klaren Schritten

• Sind Zielbild und Scope definiert (SR-MPLS oder SRv6, Underlay-only vs. SR-TE), inklusive messbarer SLOs (Konvergenz, QoE, Schutzfallprofile)?
• Gibt es eine Bestandsaufnahme (Services, LDP/RSVP-TE, IGP/RR, Hardwarekapazitäten, Label/SID-Ressourcen) und einen klaren Interworking-Plan für die Übergangszeit?
• Ist ein SID-Plan vorhanden (hierarchisch, dokumentiert, Source of Truth), inklusive Regeln für Wachstum und Rollout-Automatisierung?
• Wird SR zuerst als stabiler Underlay eingeführt, bevor SR-TE/Policies und Service-Edge-Änderungen breit ausgerollt werden?
• Sind Resilienz und Konvergenz geplant und verifiziert (FRR-Coverage, Link/Node/PoP-Szenarien, Schutzfallkapazität, QoE-Probes, Queue-Drops)?
• Ist der Rollout in Wellen geplant (Pilot, Canary, Regionen) mit Abnahmekriterien, Change-Guardrails, Maintenance Mode und getesteten Rollback-Schritten?
• Ist Observability vollständig (Control-Plane-Events, SR-Policy-Status, Pfadtransparenz, QoE/p95/p99, Flow- und Drop-Sicht) und mit Changes korrelierbar?
• Ist Governance etabliert (Blueprints, Design Reviews, Deviation-Prozess, Postmortem-Loop), damit die Migration konsistent bleibt und nicht in Sonderfällen stecken bleibt?

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.