Site icon BintoroSoft PDF Tools

SRv6 auf Cisco: Grundlagen, Konfiguration und Use Cases

Red Snapper

An illustration of seamless connecting processes between computers, realistic, very detailed. *e20240925x* --no human, brand logo, text, label --ar 16:9 --stylize 750 --v 6.1 Job ID: 512cb19b-749b-4e0a-9440-304e6b6b23db

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.

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.

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

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.

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.

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

Block 2: SRv6 aktivieren und Locators definieren

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

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.

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

Phase 2: SRv6-Enablement ohne Traffic-Umschaltung

Phase 3: Pilot-Use-Case einführen

Phase 4: Skalierung und Konsolidierung

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.

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.

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.

Typische Fallstricke bei SRv6 auf Cisco

Best Practices als SRv6-Blueprint

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