Site icon bintorosoft.com

Segment Routing (SR-MPLS) auf IOS XE: SRGB, SID, Policy-Konzept

Red Snapper

Create a visual aid showing the process of data integration from multiple sources. Include steps like data extraction, transformation, and loading (ETL).

Segment Routing mit MPLS (SR-MPLS) ist ein modernes Traffic-Engineering- und Transport-Konzept, bei dem der Ingress-Router den Pfad als Segment-Liste (Label-Stack) kodiert, statt im Netz per RSVP-TE pro Tunnel State aufzubauen. Auf IOS XE ist SR-MPLS in der Praxis vor allem drei Dinge: ein konsistenter SRGB (Segment Routing Global Block) für Label-Zuweisungen, saubere SIDs (Node/Prefix/Adjacency) im IGP und ein Policy-Konzept, das Steering und Failover deterministisch macht. Dieser Artikel erklärt die Bausteine und zeigt eine betriebsnahe Konfigurations- und Verifikationsroutine.

SR-MPLS Grundidee: Pfad als Segment-Liste

In SR-MPLS ist jedes Segment ein „Anweisungslabel“. Der Ingress pusht eine Sequenz aus Labels (Segments), die Transit-Router entlang des Pfads abarbeiten. Damit wird der Pfad „source-routed“, während der Core weniger per-Tunnel Signaling-State braucht.

Merker

SR-MPLS = IGP + SIDs + Policy (Segment-Liste)

Die wichtigsten Bausteine: SRGB, SIDs und Policies

Für das Verständnis und den Betrieb sind drei Ebenen entscheidend: SRGB definiert den Labelbereich, SIDs definieren Ziele/Anweisungen, Policies definieren, wann welche Segment-Liste genutzt wird.

SRGB verstehen: Warum Konsistenz entscheidend ist

SRGB ist der Labelpool, aus dem Router globale SIDs ableiten. In vielen Designs muss SRGB domänenweit konsistent sein, damit eine Node-SID auf jedem Router dasselbe Label bedeutet. Inkonsistenter SRGB ist eine klassische Ursache für „SR forwardet komisch“.

SRGB-Denkmodell

Label = SRGB_Base + SID_Index

Node-SID und Prefix-SID: Die „globalen“ SIDs

Node-SIDs sind das Standardwerkzeug: „bringe mich zum Router X“. Prefix-SIDs sind hilfreich für Anycast oder Services: mehrere Router announcen denselben Prefix, SR kann dennoch deterministisch steuern.

Adjacency-SID: Link-Erzwingung (mit Bedacht)

Adjacency-SIDs erzwingen einen konkreten Link und sind damit sehr mächtig. In der Praxis nutzt man sie sparsam, weil sie lokale Bedeutung haben und Policies komplexer machen. Häufiger sind Node-/Prefix-SIDs plus IGP-Metrik-Tuning ausreichend.

Konfiguration: SR-MPLS global aktivieren (IOS XE Pattern)

Die genaue Syntax kann je Release variieren, das Muster bleibt: SR-MPLS global aktivieren, SRGB setzen, dann im IGP aktivieren. Plane SRGB als Standard für die gesamte Domäne.

SR-MPLS global + SRGB (Beispielpattern)

segment-routing mpls
 global-block 16000 23999

Konfiguration: SR im IS-IS aktivieren (häufiges Backbone-Pattern)

IS-IS ist im Backbone beliebt. Du aktivierst SR im IS-IS-Prozess und weist dem Loopback eine Node-SID zu. Danach werden SIDs im IGP angekündigt.

IS-IS + Node-SID

router isis CORE
 net 49.0001.0000.0000.0001.00
 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

Konfiguration: SR im OSPF aktivieren (Alternative)

Wenn dein Underlay OSPF ist, aktivierst du SR in OSPF und setzt die Prefix-SID/Node-SID für das Loopback. Das Konzept ist identisch: IGP verteilt SID-Information.

OSPF + Prefix-SID (Pattern)

router ospf 10
 segment-routing mpls
 segment-routing global-block 16000 23999

interface loopback0

ip address 10.255.0.1 255.255.255.255

ip ospf 10 area 0

ip ospf prefix-sid index 1

Policy-Konzept: Was eine SR Policy ist

Eine SR Policy ist ein Steuerobjekt, das Traffic auf eine Segment-Liste lenkt. Du kannst Policies statisch definieren (fixe Segment-Liste) oder dynamisch (z. B. über PCE/Controller). In Enterprise-Backbones beginnt man oft mit wenigen, klaren Policies für kritische Flüsse.

Statische SR Policy (Beispielpattern)

Ein statisches Beispiel ist nützlich, um das Konzept zu verstehen: du definierst einen Endpunkt (Endpoint) und eine Segment-Liste (via). Das ist ideal für Labor und erste Backbone-Piloten.

Statische SR Policy (Pattern)

segment-routing
 traffic-eng
  policy NAME_TO_PE2
   color 100 end-point ipv4 10.255.0.2
   candidate-paths
    preference 100
     explicit segment-list SL_TO_PE2

segment-list SL_TO_PE2

index 10 mpls label 16002

Traffic Steering: Wie kommt der Traffic in die Policy?

Eine Policy hilft nur, wenn Traffic sie nutzt. In der Praxis gibt es zwei gängige Modelle: BGP-basierte Steering (z. B. Color/Policy) oder lokales Steering (PBR/ACL). Für Backbone-Designs ist BGP-basierte Steuerung oft skalierbarer.

Verifikation: SRGB, SIDs und Forwarding nachweisen

SR-MPLS Troubleshooting beginnt immer mit der Frage: Sind SIDs im IGP sichtbar und stimmt die Label-Zuweisung? Danach prüfst du, ob die Labels in der MPLS Forwarding Table auftauchen und ob Policies installed/active sind.

SR Status und SID-Datenbank

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

IGP Sichtbarkeit

show isis database detail
show ip route 10.255.0.2

MPLS Forwarding

show mpls forwarding-table | include 160
traceroute mpls ipv4 10.255.0.2

Typische Pitfalls auf IOS XE

Die häufigsten Probleme sind konsistent: SRGB nicht einheitlich, Node-SID fehlt oder kollidiert, IGP verteilt SR nicht (Feature nicht aktiv), oder Label-Stack/MTU ist zu klein. Diese Punkte solltest du vor Rollout prüfen.

Operational Best Practices: SR-MPLS sicher einführen

SR ist am stabilsten, wenn du stufenweise einführst: erst Underlay stabilisieren, dann SR als Transport (SIDs sichtbar), dann wenige Policies für kritische Flows, dann schrittweise erweitern. Jede Stufe wird mit klaren Checks verifiziert.

Quick-Runbook: SR-MPLS in 5 Minuten prüfen

Diese Kommandos liefern schnell: SR an, SIDs vorhanden, Labels forwarden, Policy aktiv.

show segment-routing mpls
show segment-routing mpls sid-database
show ip route 10.255.0.2
show mpls forwarding-table | include 160
traceroute mpls ipv4 10.255.0.2
show segment-routing traffic-eng policy

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

Sie erhalten

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.

Exit mobile version