SRv6 auf Cisco: Grundlagen, Konfiguration und Use Cases

SRv6 auf Cisco (Segment Routing over IPv6) gilt als eines der wichtigsten Architekturthemen für moderne Provider- und große Enterprise-Backbones, weil es Traffic Engineering, Service Chaining und VPN-Funktionen direkt in die IPv6-Datenebene verlagert. Im Gegensatz zu MPLS-basiertem Segment Routing (SR-MPLS), das Labels als Segment-Identitäten nutzt, setzt SRv6 auf IPv6-Adressen als Segmente (SIDs) und trägt die Segmentliste im IPv6 Segment Routing Header (SRH). Dadurch entsteht ein sehr einheitliches Modell: Unterlay und Overlay sprechen IPv6, die „Steuerinformation“ steckt in IPv6-basierten SIDs, und viele klassische TE-/Service-Konstrukte lassen sich als Routing-Policy ausdrücken. Der große Vorteil ist nicht nur technische Eleganz, sondern vor allem Betriebsfähigkeit: weniger separate Protokollschichten, weniger zustandsbehaftete Signalisierung im Core und eine bessere Grundlage für Automatisierung und Controller-gestützte Policies. Gleichzeitig ist SRv6 kein „Schalter“, den man einfach umlegt. Wer SRv6 auf Cisco sauber einführen will, braucht ein durchdachtes Locator- und Adressdesign, klare Use Cases, passende Hardware-/Software-Unterstützung und eine Migrationsstrategie, die Risiken wie MTU-Overhead, QoS-Interpretation, Security-Policies und Observability von Anfang an berücksichtigt. Dieser Artikel erklärt SRv6-Grundlagen, typische Cisco-Konfigurationsbausteine und praxiserprobte Use Cases, damit SRv6 nicht zur neuen Komplexität wird, sondern zu einem stabilen, auditierbaren Betriebsmodell.

Was SRv6 konzeptionell ist: Segmente als IPv6-Adressen

Segment Routing beschreibt eine Pfadintention als Liste von Segmenten. Bei SRv6 sind diese Segmente IPv6-SIDs (Segment IDs). Ein SRv6-fähiger Router kann anhand der aktiven SID im Paket entscheiden, welche Aktion ausgeführt wird: Weiterleiten zum nächsten Segment, ein bestimmtes Interface nutzen, einen Service anwenden oder das Paket in eine VRF/Policy einspeisen. Diese Logik wird oft als „Network Programming“ beschrieben, weil SIDs nicht nur Ziele sind, sondern auch definierte Funktionen auslösen können.

• SID: IPv6-Adresse, die ein Segment repräsentiert (Ziel oder Aktion).
• SRH: Segment Routing Header, der die Segmentliste und den aktiven Segmentindex trägt.
• Locator: IPv6-Präfixbereich, aus dem SIDs gebildet werden; zentral für Skalierung und Ordnung.
• End-Behaviors: Standardisierte SRv6-Aktionen, die ein Router ausführt, wenn er eine SID „terminiert“.

Für die technische Grundlage sind die Standards zum IPv6 Segment Routing Header und SRv6 Network Programming hilfreich, z. B. RFC 8754 (IPv6 Segment Routing Header) und RFC 8986 (SRv6 Network Programming).

SRv6 vs. SR-MPLS: Wann welches Modell sinnvoll ist

SR-MPLS und SRv6 verfolgen denselben Steuerungsgedanken (Segmente, Policies, TE), unterscheiden sich aber in der Datenebene. SR-MPLS nutzt MPLS-Labels, SRv6 nutzt IPv6-Header/SRH. Die Wahl ist häufig keine reine Technikfrage, sondern abhängig von vorhandener Infrastruktur, Interoperabilität, Migrationstempo und Plattformunterstützung.

• SR-MPLS: Gut, wenn MPLS-Core bereits existiert und MPLS-Operationalisierung etabliert ist; Segmentlisten als Label-Stack.
• SRv6: Attraktiv, wenn IPv6 als Underlay-Standard gesetzt wird, wenn Service-Programmierung (z. B. VRF-Steering) stark genutzt wird oder wenn langfristig „IPv6-first“ im Core geplant ist.
• Mischbetrieb: In vielen realen Netzen existieren Übergangsphasen, in denen MPLS, SR-MPLS und SRv6 nebeneinander betrieben werden – aber nur mit klarer Governance und sauberer Domänentrennung.

SRv6-Bausteine im Detail: Locators, SIDs und Funktionen

In der Praxis steht und fällt SRv6 mit dem Locator-Design. Locators sind die „Adressräume“, aus denen SIDs generiert werden. Ein robustes Design nutzt Locators wie IP-Adressräume: geplant, dokumentiert, aggregierbar und stabil über Hardware-Lifecycles hinweg.

Locator-Design: Ordnung und Aggregation

• Aggregation: Locators sollten sich sinnvoll zusammenfassen lassen (z. B. pro Region/PoP), um Routing-Tabellen schlank zu halten.
• Rollen: Häufig werden Locator-Bereiche nach Routerrollen getrennt (Core, Edge/PE, Service-Knoten).
• Reservierung: Reservebereiche für Wachstum und Ersatzgeräte verhindern späteres „Umnummerieren“.
• Stabilität: Locators sind Control-Plane-Grundlage; Änderungen sind High-Risk und brauchen Change-Disziplin.

Typische SRv6 End-Behaviors

SRv6 definiert standardisierte End-Behaviors, die ein Router ausführt, wenn er eine SID als „lokal“ erkennt. Wichtig ist: Nicht jeder Use Case braucht exotische Behaviors. Viele Designs kommen lange mit wenigen, klaren Mustern aus.

• End: Segment wird „verbraucht“, nächstes Segment wird aktiv, Paket wird weitergeleitet.
• End.X: Erzwingt eine bestimmte nächste Hop-/Adjacency-Weiterleitung (präzise Pfadsteuerung, aber sorgfältig zu betreiben).
• End.DT*: Steuert das Paket in eine VRF/Policy-Instanz (klassischer Baustein für VPN-/Service-Steering).

Underlay-Anforderungen: IPv6, IGP und Fast Failover

SRv6 ist kein Ersatz für ein stabiles Underlay. Im Gegenteil: SRv6 nutzt IPv6-Forwarding und ist damit so robust wie Ihr IPv6-IGP. In Cisco-Designs ist der wichtigste Erfolgsfaktor: ein „langweiliges“, stabiles IGP (OSPFv3 oder IS-IS für IPv6) mit klaren Failure-Domains, konservativen Timern und schneller Fehlererkennung über BFD.

• IPv6-Underlay konsequent: Punkt-zu-Punkt Links, Loopbacks, Router-IDs und Addressing-Standards müssen konsistent sein.
• IGP-Skalierung: OSPF-Areas oder IS-IS-Level so schneiden, dass Flooding und SPF-Last beherrschbar bleiben.
• BFD: Schnelle Failure Detection ohne aggressive IGP-Timer; Grundlage: RFC 5880.
• MTU-Basis: Unterlay-MTU muss stabil und ausreichend sein, bevor SRH-Overhead hinzukommt.

Cisco-Konfiguration als Zielbild: Was Sie wirklich aktivieren müssen

Die konkrete CLI unterscheidet sich je nach Cisco-Betriebssystem (IOS XR, IOS XE, NX-OS) und Plattformfamilie. Für ein professionelles Vorgehen ist daher ein Zielbild hilfreicher als eine starre Befehlsliste. Ein SRv6-Rollout lässt sich in vier logische Blöcke zerlegen, die Sie jeweils verifizieren können.

Block 1: IPv6 und IGP stabil betreiben

• Loopbacks: Als stabile Identität, im IGP annonciert.
• Transitlinks: IPv6 adressieren, IGP aktivieren, Interface-Typen konsistent halten.
• Stabilitätschecks: Nachbarschaften stabil, keine Flaps, SPF-Events im normalen Rahmen.

Block 2: SRv6 aktivieren und Locators definieren

• SRv6 Global: SRv6-Funktionalität einschalten (plattformabhängig).
• Locators: Locator-Präfixe konfigurieren und an den Router binden.
• IGP-Advertisement: Sicherstellen, dass Locator/Relevant-Informationen im IGP verbreitet werden.

Block 3: SRv6-Behaviors für Use Cases bereitstellen

• Basis-Forwarding: Node-basierte Pfade (End) funktionieren.
• Service-Steering: VRF- oder Service-Behaviors (End.DT*) dort, wo benötigt.
• Policy-Integration: Koppeln an BGP, SR Policies oder Traffic Steering Mechanismen (je Design).

Block 4: Traffic Steering und SR Policies

Der Mehrwert von SRv6 entsteht meist erst, wenn Sie Traffic gezielt steuern: bestimmte Services über definierte Knoten, bestimmte Regionen über bevorzugte Pfade, oder Service Chaining über Security-/Service-Knoten. Hier kommen SR Policies (lokal oder controller-berechnet) und Traffic-Classification-Mechanismen ins Spiel.

SRv6 Use Cases: Wo SRv6 in der Praxis punktet

SRv6 ist nicht nur „TE statt RSVP“. Der größte Mehrwert entsteht oft durch die Kombination aus Pfadsteuerung und Serviceprogrammierung.

• Traffic Engineering ohne RSVP-State: Pfade deterministisch steuern, ohne RSVP-TE-Tunnelzustände im Core zu betreiben.
• Service Chaining: Traffic gezielt durch Firewall, IDS/IPS, Proxy oder DDoS-Scrubber führen, ohne komplexe PBR-Kaskaden.
• VPN/VRF-Steering: VRF- oder Service-Instanzen direkt per SID/Behavior ansteuern (z. B. für L3VPN-ähnliche Modelle, je Plattform).
• Deterministische Failover-Mechanismen: In Verbindung mit BFD und geeigneten Underlay-Mechanismen können Umschaltungen sehr schnell und stabil erfolgen.
• Cloud- und DC-Interconnect: Wenn IPv6-first-Underlays und segmentierte Services gefordert sind, kann SRv6 ein konsistentes Steuerungsmodell liefern.

Migration: Von MPLS/LDP/RSVP zu SRv6 ohne Big Bang

Eine robuste SRv6-Migration ist stufenweise. Ziel ist, zuerst das IPv6-Underlay und die SRv6-Fähigkeit aufzubauen, dann SRv6-Services/Policies gezielt einzuführen und erst danach alte Mechanismen zurückzubauen. Der wichtigste Grund: So bleibt der Datenpfad kontrollierbar und Rollback-fähig.

Phase 1: IPv6-Underlay etablieren und stabilisieren

• Dual-Stack oder IPv6-first: Abhängig von Ausgangslage; entscheidend ist IGP-Stabilität.
• Observability: IPv6-IGP, BFD, Link-Health und MTU im Normalbetrieb verifizieren.

Phase 2: SRv6-Enablement ohne Traffic-Umschaltung

• Locators ausrollen: Locator-Design implementieren, im IGP sichtbar machen.
• Baseline testen: SRv6-Forwarding im Lab und in einem Pilot-Korridor validieren.

Phase 3: Pilot-Use-Case einführen

• Klein anfangen: Ein Service, eine Region oder ein definierter Traffic-Typ.
• Messung: Latenz, Loss, Pfadkonsistenz, Failover-Verhalten unter echten Link/Node-Failures.
• Rollback: Klare Möglichkeit, Traffic wieder über den bisherigen Pfad zu führen.

Phase 4: Skalierung und Konsolidierung

• Policy-Standardisierung: SR Policies als „Produktartefakt“ (Templates, GitOps, Review-Prozess).
• Altmechanismen reduzieren: LDP/RSVP schrittweise abbauen, wenn Abhängigkeiten sauber geklärt sind.

MTU und Overhead: SRH ist kein Detail, sondern Betriebsrealität

SRv6 bringt Header-Overhead: IPv6-Header plus SRH plus Segmentliste. Je mehr Segmente Sie in einer Policy nutzen, desto größer wird der Overhead. In Netzen, die zuvor mit MPLS-Labelstacks gearbeitet haben, kann das überraschend sein, weil SRH im Worst Case deutlich mehr Bytes kostet als wenige MPLS-Labels. Best Practice ist deshalb eine bewusste MTU-Strategie.

• Core-MTU erhöhen: Wenn möglich, Jumbo-Frames konsistent im Core, um SRH-Overhead aufzufangen.
• Segmentlisten sparsam: Nicht jede Policy braucht viele Segmente; Node-SIDs und einfache Pfadvorgaben reichen oft.
• End-to-End testen: Nicht nur „Ping“, sondern echte Applikationspfade unter Last (und mit Failover).

QoS und Telemetrie: Markierungen, Sichtbarkeit und Troubleshooting

Mit SRv6 ändert sich die Datenebene. Das kann beeinflussen, wie QoS-Klassen erkannt werden (DSCP im äußeren IPv6-Header, mögliche Kopierregeln, Policer/Queues an Engpässen). Für professionelle Betriebsfähigkeit sollten Sie QoS und Observability früh in die SRv6-Planung integrieren.

• DSCP-Strategie: Klar definieren, welche Markierung relevant ist (äußerer Header, innerer Header bei Encapsulation) und wo remarkt wird.
• Engpassstellen priorisieren: QoS wirkt an Engpässen (WAN, Interconnects, Firewalls), nicht „irgendwo im Core“.
• Verifikation: Pfadtests, Counters und Logs so aufbauen, dass SRv6-Policies nachvollziehbar sind.

Security und Governance: SRv6 ist Policy – und braucht Policy-Disziplin

SRv6 ist sehr mächtig. Genau deshalb muss es governable sein: Wer darf Policies definieren? Welche Locators/SIDs sind erlaubt? Wie werden Exporte kontrolliert? Welche Security-Devices sind Teil von Service Chains? Ohne Governance wird SRv6 zur Schattensteuerung, die im Incident kaum nachvollziehbar ist.

• Locator-/SID-Katalog: Dokumentiert, versioniert, mit Ownern und Lifecycle (Einführung, Änderung, Deprecation).
• Policy-Templates: Standardisierte SR Policies pro Use Case, statt ad hoc Segmentlisten.
• Control Plane Schutz: IPv6-IGP, BFD und ggf. Controller-Kommunikation müssen geschützt, aber nicht „wegpoliced“ werden.
• Change-Prozess: SRv6-Änderungen sind High-Impact; Pre-/Post-Checks und Rollback sind Pflicht.

Typische Fallstricke bei SRv6 auf Cisco

• Unsauberes Locator-Design: Keine Aggregation, keine Reserven, keine Semantik – später kaum reparabel ohne Migration.
• MTU unterschätzt: „Manche Flows gehen nicht“ ist ein klassisches SRH-/MTU-Symptom.
• Underlay instabil: SRv6 macht IGP-Probleme sofort sichtbar; zuerst Stabilität herstellen.
• Zu viele Adjacency-ähnliche Steuerungen: Präzise Pfade sind möglich, aber erhöhen Betriebsaufwand; bevorzugt Node-basierte Steuerung, wo möglich.
• Keine Observability: Ohne klare Sicht auf aktive Policies und Pfade wirkt SRv6 wie „Blackbox-Routing“.
• Unklare QoS-Regeln: Markierungen werden falsch interpretiert, Voice/Video leidet trotz „QoS aktiv“.

Best Practices als SRv6-Blueprint

• IPv6-first Underlay: Konsistente IPv6-Adressierung, stabile IGP-Hierarchie, BFD gezielt.
• Locator-Schema: Aggregierbar, rollenbasiert, dokumentiert, mit Reserven.
• Use-Case-getrieben: SRv6 nur dort einführen, wo es echten Mehrwert liefert (TE, Service Chaining, VRF-Steering).
• Stufenmigration: Enablement → Pilot → Skalierung → Konsolidierung, immer mit Rollback.
• MTU/QoS/Monitoring: Von Anfang an planen, nicht nach dem ersten Incident „nachrüsten“.
• Governance: SID- und Policy-Katalog, Templates, Reviews, Compliance Checks.

Outbound-Referenzen

• RFC 8402 (Segment Routing Architecture) für die Architekturgrundlagen von Segment Routing.
• RFC 8754 (IPv6 Segment Routing Header) für SRH und das Header-Format.
• RFC 8986 (SRv6 Network Programming) für End-Behaviors und SRv6-Funktionsmodelle.
• RFC 8200 (IPv6 Specification) als Basis für IPv6-Header- und Extension-Mechanismen, auf denen SRv6 aufbaut.
• Cisco DevNet als Einstieg in Cisco-spezifische Lernpfade, Labs und Automatisierungsansätze rund um Segment Routing.
• Cisco IOS XE Configuration Guides als Einstiegspunkt für Cisco-Dokumentation (plattformabhängig) zu IPv6, Routing und Segment-Routing-nahen Features.

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.