Segment Routing Design: SR-MPLS vs. SRv6 als Architekturentscheidung

Segment Routing Design ist heute in vielen Enterprise- und Provider-Netzen ein strategisches Architekturthema, weil es Traffic Engineering, Pfadsteuerung, Service-Steering und Netzwerkautomatisierung auf eine modernere Basis stellen kann als klassische MPLS-TE-Ansätze. Gleichzeitig ist die Technologieauswahl nicht trivial: SR-MPLS und SRv6 sind keine zwei Varianten desselben „Features“, sondern zwei Data-Plane-Ansätze mit unterschiedlichen Voraussetzungen, Overheads, Betriebsmodellen und Migrationspfaden. Wer Segment Routing nur als „schnelleres MPLS“ oder als „IPv6-Upgrade“ betrachtet, läuft Gefahr, Komplexität falsch zu verorten: Instabilitäten im Underlay, unklare Failure Domains, fehlende Observability oder zu ambitionierte Policy-Modelle führen dann zu schwer erklärbaren Störungen. Professionelles Segment Routing Design beginnt daher mit einer sauberen Einordnung: Welche Probleme sollen gelöst werden (z. B. deterministische Pfade, SLA/SLO-Einhaltung, Multi-Domain-Backbone, Service-Chaining), welche Umgebung ist gegeben (MPLS-Reife, IPv6-Reife, Plattformunterstützung), und welches Betriebsmodell kann die Organisation realistisch tragen? Dieser Artikel ordnet SR-MPLS vs. SRv6 als Architekturentscheidung ein, zeigt typische Design Patterns und liefert Kriterien, um eine belastbare, auditierbare Entscheidung zu treffen.

Segment Routing in einem Satz: Pfade als „Segment-Kette“ statt komplexem per-Flow Signaling

Segment Routing beschreibt die Idee, Pfadsteuerung und Traffic Engineering über eine Abfolge von Segmenten umzusetzen. Ein Segment ist dabei eine Anweisung, die ein Paket durch das Netz führt, zum Beispiel „gehe zu Node X“ oder „nimm diese spezielle Kante“. Die Segment Routing Architektur ist grundlegend in RFC 8402 beschrieben. In der Praxis wird Segment Routing meist in Backbones und WANs eingesetzt, wo deterministische Pfade, schnelle Konvergenz und konsistente Steuerung über Domänen hinweg wichtig sind.

• Control Plane: Segmente werden über IGP-Erweiterungen oder BGP verteilt bzw. durch Controller gesteuert.
• Data Plane: Die Segment-Information wird im Paket getragen – bei SR-MPLS als MPLS-Label-Stack, bei SRv6 als IPv6-basierte Segment Identifiers (SIDs).
• Designziel: Weniger verteilten State im Netz, klarere Pfadsteuerung, bessere Automatisierbarkeit und konsistente Policies.

SR-MPLS vs. SRv6: Der wichtigste Unterschied ist die Data Plane

Die Architekturentscheidungen zwischen SR-MPLS und SRv6 drehen sich häufig um ein Missverständnis: Es geht nicht nur um „welches SR“, sondern um die Data Plane und damit um Overhead, Plattformfähigkeit, Troubleshooting und Migrationslogik.

• SR-MPLS: Segment Routing über MPLS-Labels. Data Plane basiert auf MPLS-Label-Stacks; besonders passend, wenn MPLS bereits etabliert ist. Die SR-MPLS Data Plane ist in RFC 8660 beschrieben.
• SRv6: Segment Routing über IPv6. Data Plane nutzt IPv6 SIDs und ermöglicht zusätzlich „Network Programming“ (Servicefunktionen über SID-Logik). Grundlagen dazu finden sich in RFC 8986.

Beide Ansätze können ähnliche Ziele adressieren (TE, Steering, deterministische Pfade). Die Entscheidung hängt jedoch stark davon ab, ob Sie MPLS als stabile Grundlage nutzen oder ob Sie strategisch eine IP-native (IPv6) Data Plane aufbauen wollen.

Wann SR-MPLS als Architekturentscheidung meist überzeugt

SR-MPLS ist häufig die pragmatische Wahl, wenn ein Netz bereits MPLS- und TE-Erfahrung besitzt oder wenn die Organisation eine MPLS-basierte Betriebs- und Toolchain etabliert hat. In solchen Umgebungen ist SR-MPLS oft eine evolutionäre Weiterentwicklung: Der Einstieg kann schrittweise erfolgen, und viele Betriebsprozesse bleiben vertraut.

• Bestehender MPLS-Backbone: Wenn MPLS als Transport und Serviceschicht bereits vorhanden ist, kann SR-MPLS Modernisierung ohne „Big Bang“ ermöglichen.
• Plattform- und ASIC-Reife: MPLS-Forwarding ist in vielen Netzplattformen seit Jahren hardwarebeschleunigt, gut beobachtbar und robust.
• Operative Kontinuität: Viele Teams können Labels, LSP-Denken, MPLS-OAM und bekannte Telemetriepfade weiter nutzen.
• TE-Use-Cases: Pfadsteuerung, SLA-gerechtes Routing, Schutzpfade, ggf. Integration mit Controller-Strategien.

Wichtig ist dabei die Einordnung: SR-MPLS ersetzt nicht automatisch Designarbeit. Es ist ein Werkzeug für Pfadsteuerung – Failure Domains, Kapazitätsreserven, Konvergenz-Guardrails und Observability bleiben zwingende Designinputs.

Wann SRv6 als Architekturentscheidung sinnvoll wird

SRv6 ist besonders interessant für Organisationen, die IPv6 strategisch ausbauen oder langfristig MPLS reduzieren möchten, ohne auf Segment-Routing-Fähigkeiten zu verzichten. SRv6 kann zudem über das reine TE hinausgehen, weil SIDs als Träger für „Network Programming“ genutzt werden können. Das macht SRv6 mächtig, erhöht aber auch Anforderungen an Standards, SID-Planung und Betriebsdisziplin.

• IPv6-first oder IPv6-native Backbones: Wenn IPv6 im Underlay und im Betrieb bereits stabil ist, wird SRv6 realistischer.
• Vereinheitlichung der Data Plane: Wenn ein einheitliches IP-Forwarding-Modell bevorzugt wird, statt MPLS + IP parallel zu betreiben.
• Service-Steering-Use-Cases: Wo SRv6-Funktionen als Architekturmechanismus eingesetzt werden sollen (bewusst, nicht als „Feature-Sammlung“).
• Langfristige Roadmaps: SRv6 passt häufig in mehrjährige Transformationsprogramme, nicht in kurzfristige „Quick Wins“.

SRv6 erfordert in der Regel ein sauber geplantes IPv6-Adress- und MTU-Design, robuste Observability für SRv6-Header und eine Plattformstrategie, die Feature-Reife und Performance-Eigenschaften berücksichtigt.

Architekturziele: Welche Probleme Segment Routing typischerweise lösen soll

Eine belastbare SR-MPLS-vs.-SRv6-Entscheidung beginnt mit klaren Zielen. Wenn das Ziel unscharf ist („wir wollen modern werden“), wird die Technologieauswahl schnell zum Glaubenskrieg. In professionellen Beratungs- und Architekturprojekten haben sich folgende Zielkategorien bewährt:

• Traffic Engineering: Deterministische Pfade, bessere Ausnutzung, Umgehung von Engpässen, priorisierte Pfade für kritische Services.
• Fast Reroute und Schutzpfade: Planbares Failover-Verhalten und geringere Serviceunterbrechungen bei Ausfällen.
• Multi-Domain-Steuerung: Einheitliche Policy- und Pfadlogik über Regionen oder Domänengrenzen hinweg (mit geeigneter Control-Plane/Controller-Strategie).
• Service-Steering: Gezieltes Durchleiten über Security- oder Servicefunktionen (z. B. Inspection, regionale Egress-Kontrolle), ohne unkontrolliertes Hairpinning.
• Automatisierung: Standardisierte Policy-Patterns, wiederholbare Rollouts, geringere Abhängigkeit von manuellen TE-Konfigurationen.

Underlay bleibt der König: Segment Routing braucht stabile Grundlagen

In SR-Projekten wird der Wert des Underlays häufig unterschätzt. Segment Routing kann Pfade steuern, aber es kann keine Instabilität im Underlay „wegzaubern“. Wenn IGP-Konvergenz, BFD-Design, ECMP-Headroom oder Failure Domains nicht sauber sind, wird SR nur die Geschwindigkeit erhöhen, mit der Fehler sichtbar werden.

• Konvergenzziele definieren: Pro Domäne und Serviceklasse; Failover muss messbar und testbar sein.
• ECMP ohne Hotspots: Load Sharing muss Elephant Flows und Failover-Last berücksichtigen, sonst wird TE zur Symptombekämpfung.
• Failure Domains schneiden: Regionen, Hubs, Pods und Shared Services müssen so entworfen sein, dass Blast Radius begrenzt bleibt.
• Time Sync und Telemetrie: Ohne konsistente Zeitbasis und aussagekräftige Telemetrie ist Troubleshooting bei SR deutlich schwerer.

Operatives Betriebsmodell: Der eigentliche Kostenfaktor in der Entscheidung

Die Data Plane ist nur ein Teil. In der Praxis entscheidet das Betriebsmodell über Erfolg oder Scheitern. Segment Routing bringt neue Artefakte: Segment-Plan, Policy-Katalog, Observability-Standards, Testszenarien, Change-Gates. Ohne Governance entsteht schnell „Policy-Sprawl“: immer mehr Sonderpfade, immer mehr Ausnahmen, sinkende Transparenz.

SR-MPLS: Operative Stärken und typische Belastungen

• Stärken: MPLS-Forwarding ist vielerorts etabliert; Label-Stacks sind gut interpretierbar, OAM- und Tooling-Landschaften sind oft vorhanden.
• Belastungen: Parallelbetrieb von IP und MPLS bleibt bestehen; Segment-Policies müssen standardisiert werden, sonst entsteht eine schwer wartbare TE-Landschaft.

SRv6: Operative Stärken und typische Belastungen

• Stärken: IP-native Data Plane; langfristig kann die Betriebslogik vereinheitlicht werden, wenn IPv6 insgesamt konsequent umgesetzt wird.
• Belastungen: Overhead und MTU-Fragen sind kritischer; SID-Planung und Debugging brauchen klare Standards; Plattformreife kann heterogen sein.

Overhead, MTU und Performance: Die Praxisunterschiede, die oft zu spät betrachtet werden

Eine robuste Architekturentscheidung berücksichtigt Paketoverhead und MTU schon im Design, nicht erst im Rollout. SR-MPLS arbeitet mit Label-Stacks, SRv6 mit IPv6 Extension-Headern und SIDs. In beiden Fällen steigt der Overhead mit der Länge der Segment-Kette. Das ist grundsätzlich beherrschbar, aber nur, wenn Underlay-MTU, Path-MTU-Tests und QoS-Handling sauber geplant sind.

• SR-MPLS: Overhead hängt von der Anzahl Labels ab; MPLS-Stacks sind in vielen Plattformen effizient verarbeitet, aber MTU muss dennoch passen.
• SRv6: Overhead kann höher sein, je nach SID-List-Länge; MTU-Design und Fragmentierungsvermeidung sind besonders wichtig.
• QoS und Marking: Markierungen müssen durch Encapsulation korrekt transportiert und in Queues umgesetzt werden.
• Messbarkeit: Latenz/Jitter/Loss müssen end-to-end gemessen werden, nicht nur auf Geräteniveau.

Control Plane und Policy-Modelle: Standards statt Sonderpfade

Segment Routing entfaltet Nutzen, wenn Policies wiederverwendbar sind. Das bedeutet: klare Klassen, klare Regeln, klare Grenzen. Ein gutes Design verhindert, dass jede Applikation einen eigenen „Spezialpfad“ bekommt. Stattdessen werden wenige TE-Profile definiert, die sich an Serviceklassen orientieren.

• Policy-Tiers: z. B. „Low Latency“, „High Throughput“, „Best Effort“, „Protected“ (mit Schutzpfaden).
• Traffic-Klassifizierung: DSCP/QoS-Klassen als Input; Policies wirken konsistent über WAN und Backbone.
• Guardrails: Maximale Anzahl aktiver Policies, Namenskonventionen, Approval-Gates, Deprecation-Regeln.
• Nachweise: Jede Policy ist messbar (Telemetrie, Pfad-Trace, SLA/SLO-Checks) und hat Owner/Review-Intervall.

Service-Steering und Security: Mehr Möglichkeiten, aber auch mehr Verantwortung

Sowohl SR-MPLS als auch SRv6 können genutzt werden, um Traffic gezielt über bestimmte Knoten zu führen. Das ist hilfreich, wenn Security-Inspection, regionale Egress-Kontrolle oder Servicefunktionen benötigt werden. Gleichzeitig ist Service-Steering ein klassischer Bereich, in dem der Blast Radius durch Fehlkonfiguration schnell groß wird. Daher sollten Policy- und Security-Gates hier besonders strikt sein.

• Enforcement Points regionalisieren: Zentralisierung kann zu Single Points of Failure und Kapazitätsengpässen führen.
• Statefulness beachten: NAT, Firewalls, Proxies benötigen symmetrische Pfade oder bewusstes Session-Handling, sonst entstehen sporadische Abbrüche.
• Kommunikationsmatrix: Erlaubte Flows und Servicepfade müssen begründet, versioniert und regelmäßig reviewed werden.
• Logging und Forensik: SR-Policies dürfen Observability nicht verschleiern; Pfade müssen nachvollziehbar bleiben.

Migrationsstrategien: Evolution statt Big Bang

Die beste Technologieentscheidung scheitert, wenn die Migration nicht realistisch ist. In der Praxis ist SR-MPLS oft leichter evolutionär einzuführen, wenn MPLS bereits vorhanden ist. SRv6 kann ebenfalls schrittweise eingeführt werden, setzt aber meist eine konsequente IPv6-Strategie voraus.

SR-MPLS: Typischer evolutionärer Pfad

• Phase 1: Underlay stabilisieren, SR-capable Nodes identifizieren, Segment-Plan definieren.
• Phase 2: SR-MPLS aktivieren, zunächst ohne komplexe TE-Policies, Observability und OAM etablieren.
• Phase 3: Policies schrittweise ausrollen (Pilot → Wellen), Failover- und Degradation-Tests durchführen.
• Phase 4: Standardisierung und Governance festigen (Policy-Katalog, Deprecation, KPI/SLO-Reporting).

SRv6: Typischer evolutionärer Pfad

• Phase 1: IPv6-Underlay und Betriebsmodell stabil, MTU-Baseline und Telemetrie sauber.
• Phase 2: SRv6 in begrenzter Domäne pilotieren, SID-Plan und Observability-Standards testen.
• Phase 3: SRv6 Policies ausrollen, Service-Steering nur dort, wo Nutzen klar und messbar ist.
• Phase 4: Koexistenz- und Übergangsarchitekturen bereinigen, Standards konsolidieren.

Entscheidungskriterien als Architektur-Checkliste

• IPv6-Reifegrad: Ist IPv6 im Backbone/Underlay stabil, betrieblich beherrscht und durchgängig observability-fähig?
• MPLS-Reifegrad: Gibt es etablierte MPLS-Prozesse, Tooling, OAM und Skillsets, die SR-MPLS begünstigen?
• Plattformunterstützung: Ist die Feature-Reife für SR-MPLS/SRv6 inklusive Telemetrie, Counters und Debugging ausreichend?
• MTU und Overhead: Sind MTU-Reserven und Testszenarien für die geplanten Segment-Listen vorhanden?
• Use Cases klar: TE, Schutzpfade, Multi-Domain, Service-Steering – sind sie priorisiert und messbar definiert?
• Governance: Gibt es Standards für Segment-/SID-Pläne, Naming, Policy-Katalog, Ausnahmeprozess und Deprecation?
• Observability: Können Pfade, Policy-Wirkung, Konvergenz und Servicequalität end-to-end nachgewiesen werden?
• Wartbarkeit: Gibt es Staged Rollouts, getestete Rollbacks, Drift-Kontrolle und klare Change-Gates?

Tests und Nachweise: Segment Routing muss unter Stress funktionieren

Eine Architekturentscheidung gilt als belastbar, wenn sie verifiziert wurde. Bei Segment Routing sollten Tests nicht nur „funktional“ sein, sondern gezielt degradierte Zustände und Failure Events abdecken. Wichtig ist die Messung des Service-Impacts, nicht nur der Control-Plane-Reaktion.

• Link-/Node-Ausfall: Konvergenzzeit, Pfadwechsel, Drops/Jitter/Loss messen, inklusive Recovery in Normalzustand.
• Flap-Szenarien: Wiederholte kurze Störungen; prüfen, ob Guardrails (Throttle, Hold-down, Stabilitätsmechanismen) wirken.
• Policy-Rollout: Staged Deployments, Canary-Policies, Validierung über synthetische Probes und Telemetrie.
• MTU- und Encapsulation-Tests: Path-MTU, Fragmentierung, stille Drops, QoS-Markierung durch Encapsulation.
• Service-Steering: Symmetrie, Session-Stabilität und Logging-Vollständigkeit für stateful Services prüfen.

Dokumentation: SR-MPLS vs. SRv6 als nachvollziehbare Entscheidung festhalten

Segment Routing ist eine langfristige Architekturentscheidung mit Trade-offs. Damit die Entscheidung auch Jahre später erklärbar bleibt (Audit, Personalwechsel, Incident Reviews), sollte sie strukturiert dokumentiert werden: Kontext, Optionen, Entscheidung, Konsequenzen und Validierung. Ein praxistauglicher Einstieg in das ADR-Prinzip findet sich unter Architecture Decision Records. Für Segment Routing speziell ist es hilfreich, die zugrunde liegenden Standards (z. B. SR-Architektur, SR-MPLS Data Plane, SRv6 Network Programming) explizit zu referenzieren, etwa über RFC Editor, damit die technische Basis dauerhaft prüfbar bleibt.

Praktische Gate-Checkliste für Architektur- und Security-Reviews

• Underlay stabil und ausreichend dimensioniert: ECMP-Headroom im Failover, definierte Konvergenzziele, BFD/IGP-Guardrails.
• Segment-/SID-Plan vorhanden: konsistent, versioniert, mit Namenskonventionen und klarer Variabilität.
• Policy-Katalog standardisiert: wenige TE-Profile statt Sonderpfade; Owner und Review-Intervalle sind definiert.
• Observability implementiert: Pfadtransparenz, Policy-Wirkung, Telemetrie/Counters, Logs und Zeitbasis sind belastbar.
• MTU/Overhead geprüft: Encapsulation-Tests durchgeführt, stille Drops ausgeschlossen, QoS end-to-end konsistent.
• Service-Steering abgesichert: Symmetrie für stateful Pfade, Logging-Vollständigkeit, klare Enforcement-Strategie.
• Migration in Wellen: Pilot → Rollout, Exit-Kriterien, getestete Rollbacks, Dokumentation aktualisiert.
• Nachweis durch Tests: Failure-, Flap-, Degradation- und Maintenance-Tests mit dokumentierten Ergebnissen.

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.