Site icon bintorosoft.com

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

Red Snapper

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.

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.

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:

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:

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.

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.

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

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.

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.

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:

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?

Typische Fallstricke bei SR-MPLS Migrationen

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

Outbound-Referenzen

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:

Lieferumfang:

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.

 

Exit mobile version