Segment Routing (SR-MPLS) auf Cisco: Konfiguration und Migration

Segment Routing (SR-MPLS) auf Cisco ist für viele Netzbetreiber der nächste logische Schritt nach klassischem MPLS mit LDP und RSVP-TE: weniger zustandsbehaftete Signalisierung im Core, klarere Steuerung über IGP-Erweiterungen, bessere Automatisierbarkeit und eine Migration, die sich schrittweise und risikoarm gestalten lässt. SR-MPLS verschiebt den Fokus weg von „per Tunnel stateful signalisieren“ hin zu „Pfadintention als Segmentliste ausdrücken“: Das Underlay (OSPF oder IS-IS) verteilt die notwendigen Segment-Informationen (SIDs), und Traffic kann per Segmentliste deterministisch über bestimmte Knoten (Node-SIDs) oder Links (Adjacency-SIDs) gesteuert werden. In der Praxis ist Segment Routing damit nicht nur ein Traffic-Engineering-Feature, sondern auch ein Betriebsmodell: Sie standardisieren SIDs, bauen ein konsistentes Label- und IGP-Design, koppeln Fast Failover über TI-LFA/BFD und schaffen die Grundlage für zentrale Controller (PCE) oder automatisierte Policies. Gleichzeitig gilt: Die beste SR-MPLS-Einführung scheitert nicht an der CLI, sondern an Underlay-Disziplin, MTU/Label-Stack-Planung, kontrollierter Migration von LDP/RSVP-TE, sauberem Monitoring und klaren Rollback-Strategien. Dieser Artikel zeigt Konfiguration und Migration aus Expertensicht: welche Bausteine SR-MPLS ausmachen, wie Sie ein tragfähiges SID-Design definieren, welche Schritte sich in Cisco-Umgebungen bewähren und welche Fallstricke Sie vermeiden sollten, damit Segment Routing nicht „neue Komplexität“ wird, sondern ein stabiler Ersatz für klassische MPLS-Mechanismen.

SR-MPLS im Überblick: Was sich gegenüber LDP/RSVP-TE ändert

In klassischem MPLS verteilt LDP Labels entlang der IGP-Pfade; RSVP-TE signalisiert explizite LSPs und reserviert (optional) Bandbreite. SR-MPLS nutzt ebenfalls MPLS-Labels, aber die „Bedeutung“ der Labels kommt aus dem IGP (SR Extensions): Ein Label steht für ein Segment, z. B. „zu diesem Node routen“ (Node-SID) oder „diese konkrete Linkkante nehmen“ (Adjacency-SID). Dadurch sinkt der Bedarf an separater Label-Signalisierung im Core (LDP) oder an RSVP-State (RSVP-TE), insbesondere in Standard-Traffic-Engineering-Szenarien.

• Control Plane: SR-Informationen werden über OSPF/IS-IS verteilt; separate LDP-Sessions können entfallen.
• Data Plane: MPLS-Labels bleiben, aber ihre Semantik ist „SR Segment“ statt „LDP Binding“.
• Traffic Engineering: Pfade können über Segmentlisten gesteuert werden; optional mit Controller/PCE für Berechnung und Policy.
• Fast Reroute: TI-LFA (Topology Independent LFA) bietet sehr schnelles, lokales Failover ohne RSVP-FRR-Mechanik.

Für die formale Grundlage von Segment Routing sind die IETF-Dokumente ein guter Einstieg, z. B. RFC 8402 (Segment Routing Architecture) sowie für IS-IS SR-Erweiterungen RFC 8667 und für OSPF SR-Erweiterungen RFC 8665.

Bausteine von SR-MPLS: SIDs, SRGB und Segmentlisten

Damit SR-MPLS operativ „einfach“ wird, müssen Sie die SR-Grundbausteine sauber trennen. In Cisco-Designs sind insbesondere drei Konzepte wichtig: Segment IDs (SIDs), der Segment Routing Global Block (SRGB) und die Segmentliste.

• Node-SID: Repräsentiert einen Zielknoten. Ein Paket mit Node-SID im Label-Stack wird im IGP-Sinn zum Knoten geroutet.
• Adjacency-SID: Repräsentiert eine konkrete Linkkante (lokal am Knoten). Nützlich für präzise Pfadsteuerung, aber betrieblich anspruchsvoller.
• SRGB: Ein reservierter Labelbereich, aus dem SIDs abgeleitet werden. Konsistenz im SRGB ist ein operativer Erfolgsfaktor.
• Segmentliste: Sequenz von SIDs, die eine Pfadintention beschreibt (z. B. „via Knoten X und Y“).

Warum SRGB-Konsistenz so wichtig ist

In vielen SR-MPLS-Implementierungen werden Node-SIDs als „Index“ im SRGB interpretiert. Wenn SRGBs inkonsistent sind, kann ein identischer SID-Wert auf zwei Routern unterschiedliche Labelbedeutungen haben. Das führt zu schwer zu diagnostizierenden Forwarding-Fehlern. Best Practice ist daher, SRGB domänenweit zu standardisieren und Änderungen daran als High-Risk-Change zu behandeln.

Underlay zuerst: OSPF/IS-IS als Basis für SR-MPLS

SR-MPLS lebt vom Underlay. Wenn das IGP instabil ist, sind SR-Pfade instabil. Wenn das IGP schlecht skaliert, wird SR nicht „magisch“ besser. Ein professioneller SR-Blueprint beginnt daher mit einem sauberen Underlay:

• Punkt-zu-Punkt Links: Wo möglich, p2p statt großer Broadcast-Transits, um DR/DIS-Komplexität zu reduzieren.
• Stabile Router-IDs: Loopbacks als Router-ID und als IGP-Transportanker; konsequent im IGP annonciert.
• BFD: Schnelle Failure Detection ohne aggressive IGP-Timer; BFD-Grundlage: RFC 5880.
• Hierarchie und Summaries: OSPF-Areas oder IS-IS-Level sinnvoll schneiden, damit Flooding und SPF-Last beherrschbar bleiben.

Cisco SR-MPLS Konfiguration: Praktisches Zielbild statt Befehlsliste

Die exakte CLI variiert je nach Plattform (IOS XE, IOS XR, NX-OS) und Release. Entscheidend ist deshalb das Konfigurationszielbild: Welche Features müssen in welcher Reihenfolge aktiviert werden, und welche Verifikationspunkte bestätigen, dass SR-MPLS wirklich aktiv ist.

Schritt 1: IGP stabilisieren und SR Extensions aktivieren

SR erfordert, dass das IGP SR-Informationen verteilt. Das bedeutet: SR aktivieren, SRGB definieren und sicherstellen, dass Router SR-fähige Informationen austauschen. In der Praxis ist dies der erste „Cut“: Sie können SR-Extensions verteilen, ohne sofort Traffic Engineering zu aktivieren.

Schritt 2: SIDs planen und konsistent zuweisen

Node-SIDs sollten nach einem nachvollziehbaren Schema vergeben werden, das zur Netzstruktur passt. Typische Muster:

• Standort-/Region-Codierung: Node-SIDs in Blöcken pro Region, um Troubleshooting und Dokumentation zu erleichtern.
• Funktionale Codierung: Core-Router in einem Bereich, Edge/PE in einem anderen, um Rollen schnell zu erkennen.
• Reserviert/Spare: Freie Bereiche für Wachstum und Ersatzgeräte (Lifecycle-Management).

Ein Profi-Hinweis: „Kreative“ SID-Vergabe ohne Governance führt später zu Migrationsrisiken. Behandeln Sie SIDs wie IP-Adressräume: geplant, dokumentiert, versioniert.

Schritt 3: MPLS Data Plane und Label-Handling prüfen

SR-MPLS nutzt MPLS Labels. Daher müssen MPLS-Forwarding, Label-Stack-Handling und MTU/Encapsulation konsistent sein. Besonders in Netzen, die von LDP kommen, wird das oft unterschätzt: LDP kann bereits MPLS-MTU-Annahmen geprägt haben; SR kann zusätzliche Labels im Stack erzeugen (Segmentlisten), was Overhead erhöht.

• MPLS MTU: End-to-End im Core ausreichend hoch, um Label-Stacks zu tragen.
• PHP/Explicit Null: Je nach QoS- und Visibility-Anforderungen kann Explicit Null relevant sein (z. B. für DSCP/EXP-Mappings).
• ECMP-Verhalten: Prüfen, wie Lastverteilung auf SR-Pfaden erfolgt; Hashing und Adjacency-Design können beeinflussen.

Schritt 4: SR Policies und Traffic Steering einführen

Der Mehrwert von SR entsteht häufig erst, wenn Sie Traffic gezielt steuern: über SR Policies, Segmentlisten oder Controller-basierte Berechnung. Die Einführungsreihenfolge sollte dabei konservativ sein: erst wenige, klar messbare Use Cases (z. B. „kritischer Verkehr via Core-Knoten X“), dann ausbauen.

TI-LFA: Fast Reroute ohne RSVP-TE State

Ein Kernargument für SR-MPLS ist TI-LFA (Topology Independent Loop-Free Alternate): lokales, sehr schnelles Failover, das nicht auf RSVP-TE-FRR angewiesen ist. Der praktische Vorteil: Sie erhalten schnelle Reaktion auf Link-/Node-Failures, ohne pro Tunnel RSVP-State zu halten. In der Praxis ist TI-LFA jedoch nicht „automatisch perfekt“: Es benötigt ein Underlay, das entsprechende Alternativpfade bietet, und klare IGP- und SR-Konfiguration.

• Link- und Node-Protection: TI-LFA kann beide Schutzarten abdecken, wenn Topologie und Konfiguration es erlauben.
• BFD als Trigger: BFD liefert schnelle Failure Detection, TI-LFA liefert schnelle lokale Umleitung.
• Designabhängig: Ohne ausreichende Topologieredundanz gibt es keine „magischen“ Alternativen.

Migration: Von LDP/RSVP-TE zu SR-MPLS ohne Big Bang

Eine sichere Migration ist selten ein „Ausschalten von LDP, Einschalten von SR“. Stattdessen hat sich ein stufenweises Vorgehen bewährt, bei dem Sie zunächst SR-Fähigkeit im Underlay etablieren und dann Traffic schrittweise umstellen.

Phase 1: SR im Underlay aktivieren, ohne LDP abzuschalten

• Ziel: SR-IGP-Extensions laufen stabil, Node-SIDs sind im Netz sichtbar, SRGB ist konsistent.
• Vorteil: Keine unmittelbare Datenpfadänderung, geringes Risiko.
• Verifikation: SR-fähige Nachbarschaften, SID-Advertisements, stabile IGP-Konvergenz.

Phase 2: Kontrollierte Coexistence und Traffic-Steering im Pilot

In vielen Netzen läuft LDP parallel, während SR für ausgewählte Pfade genutzt wird. Wichtig ist, dass Sie klar definieren, welche Mechanik „gewinnt“ bzw. welche FECs und Pfade bereits SR nutzen. Hier entstehen sonst „verdeckte“ Abhängigkeiten.

• Pilot: Eine Region, ein Service oder ein definierter Traffic-Korridor.
• Messung: Latenz, Loss, Convergence, Link-Auslastung, Pfadkonsistenz.
• Rollback: Klare Möglichkeit, Traffic wieder über das alte Verhalten zu führen.

Phase 3: LDP schrittweise zurückbauen

Wenn SR-Pfade produktiv sind, wird LDP oft schrittweise entfernt. Der entscheidende Punkt ist, dass Sie Abhängigkeiten prüfen: Einige Features oder Plattformen nutzen LDP noch für bestimmte Label-Distribution-Szenarien, oder es existieren Altlasten (z. B. bestimmte VPN- oder Interop-Designs). Ein professioneller Abbau ist daher iterativ.

• Abhängigkeiten identifizieren: Welche Services erwarten LDP-Labels (z. B. bestimmte L2VPN/L3VPN-Interaktionen je Plattform)?
• Stückweise decommission: Nicht „im ganzen Core gleichzeitig“ – sondern nach Regionen/Pods.
• Post-Checks: Label-Continuity, End-to-End Forwarding, TE-Policies, FRR-Verhalten.

Phase 4: RSVP-TE konsolidieren oder ersetzen

Wenn RSVP-TE im Einsatz ist, hängt die Migration davon ab, wofür RSVP genutzt wird: nur für Traffic Engineering, für Bandbreitenreservierung oder für FRR. In vielen Fällen können SR Policies und TI-LFA den Bedarf stark reduzieren. Wenn Sie jedoch harte Reservierungen oder etablierte TE-Workflows haben, kann RSVP noch länger parallel existieren oder durch Controller-basierte SR-TE-Modelle ersetzt werden.

SR-MPLS und QoS: DSCP, EXP und Sichtbarkeit planen

In MPLS-Netzen ist QoS nicht nur ein „Edge-Thema“, sondern hängt auch von Label-Handling ab. SR-MPLS verändert die Label-Semantik, nicht automatisch die QoS-Prinzipien. Trotzdem sollten Sie bei der Migration prüfen:

• Markierungsstrategie: Wird QoS über DSCP im IP-Header, über EXP/TC im Label oder über beides umgesetzt?
• PHP vs. Explicit Null: Wenn Sie bestimmte Markierungen am Egress benötigen, kann Explicit Null wichtig sein.
• End-to-End Konsistenz: QoS-Policies an Engpässen (WAN/Interconnects) müssen SR-Label-Stacks korrekt behandeln.

Monitoring und Verifikation: SR ist nur so gut wie Ihre Observability

Der größte operative Unterschied zwischen „SR läuft“ und „SR ist produktiv beherrscht“ ist Sichtbarkeit. Sie sollten jederzeit beantworten können: Welche SIDs sind aktiv? Welche Segmentlisten werden genutzt? Welche Pfade sind tatsächlich im Forwarding? Wie oft greift TI-LFA? Gibt es unerwartete Label-Stacks oder MTU-Drops?

• IGP-SR Sicht: SID-Advertisements, SRGB-Konsistenz, Nachbarschaftsstabilität.
• Forwarding-Sicht: Label-Stack im Datenpfad, ECMP-Verhalten, Penultimate Hop Popping/Explicit Null.
• Fast Reroute: TI-LFA-Events, lokale Reparaturpfade, BFD-Flaps vs. echte Ausfälle.
• Kapazität: CPU/Memory in Control Plane, insbesondere bei großen Netzen oder vielen Policies.

Typische Fallstricke bei SR-MPLS Migrationen

• SRGB inkonsistent: Führt zu unvorhersehbarer Label-Semantik; einer der kritischsten Fehler.
• SID-Sprawl: Zu viele Adjacency-SIDs ohne Governance; Troubleshooting wird unnötig schwer.
• MTU unterschätzt: Segmentlisten erhöhen Label-Stack; Drops wirken wie „random“.
• Underlay instabil: SR macht IGP-Probleme sichtbarer; zuerst Underlay stabilisieren.
• Coexistence ungeplant: LDP und SR parallel ohne klare Steuerlogik erzeugen schwer erklärbare Pfade.
• FRR nicht getestet: TI-LFA funktioniert designabhängig; Failover muss real getestet werden (Link/Node Failure).

Best Practices als Blueprint: SR-MPLS sauber einführen

• Underlay-Disziplin: OSPF/IS-IS stabil, BFD gezielt, klare Topologie-Redundanz.
• SRGB standardisieren: Ein SRGB für die Domäne, dokumentiert und change-kontrolliert.
• SID-Design dokumentieren: Node-SIDs nach Schema, Adjacency-SIDs sparsam und nur für definierte TE-Use Cases.
• Stufenmigration: SR Extensions zuerst, Pilot-Traffic-Steering, dann LDP/RSVP schrittweise reduzieren.
• MTU-Planung: Label-Stack-Overhead einkalkulieren, End-to-End testen, besonders bei Interconnects.
• Observability: Monitoring für SIDs, Policies, TI-LFA, Drops und Flaps als Pflichtbestandteil.

Outbound-Referenzen

• RFC 8402 (Segment Routing Architecture) für die Architektur- und Grundbegriffe von Segment Routing.
• RFC 8667 (IS-IS Extensions for Segment Routing) für SR-Verteilung via IS-IS.
• RFC 8665 (OSPF Extensions for Segment Routing) für SR-Verteilung via OSPF.
• RFC 3031 (MPLS Architecture) als Hintergrund für MPLS-Label-Forwarding, auf dem SR-MPLS aufbaut.
• RFC 5880 (BFD) als Referenz für schnelle Failure Detection, häufig in SR-Underlays genutzt.
• Cisco IOS XE Configuration Guides für Cisco-spezifische SR-MPLS Konfiguration, Verifikation und Plattformhinweise.

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.