Segment Routing (SR-MPLS/SRv6): Modernes Telco-Design erklärt

Segment Routing (SR-MPLS/SRv6) gilt als einer der wichtigsten Modernisierungsschritte im Telco-Backbone und in großen IP-Transportnetzen. Wer heute ein Provider-Netz plant oder ein bestehendes IP/MPLS-Design weiterentwickelt, stößt schnell auf die Frage, ob klassische MPLS-Mechanismen wie LDP oder RSVP-TE langfristig noch die beste Grundlage sind. Segment Routing verspricht hier eine klarere Architektur: weniger verteilten Zustand im Netz, einfachere Traffic-Steuerung, bessere Automatisierbarkeit und eine saubere Basis für moderne Services – vom Backbone über Metro bis hin zu Mobile Transport und Cloud-Anbindungen. Gleichzeitig ist SR kein „Plug-and-Play“-Upgrade, sondern eine Designentscheidung, die Adressierung, IGP, Policy-Modelle, Observability und Betriebsprozesse berührt. Dieser Artikel erklärt Segment Routing (SR-MPLS/SRv6) verständlich und praxisnah: Welche Konzepte stecken dahinter, wie unterscheiden sich SR-MPLS und SRv6, welche Topologien und Einsatzfälle sind typisch, und welche Best Practices helfen, ein modernes Telco-Design stabil, skalierbar und betriebssicher umzusetzen.

Warum Segment Routing in Telco-Netzen so relevant ist

Telco-Netze müssen gleichzeitig wachsen, stabil bleiben und neue Dienste schneller bereitstellen. Klassische IP/MPLS-Designs funktionieren weiterhin hervorragend, können aber in komplexen Umgebungen betrieblich anspruchsvoll werden: viele LSPs, aufwendige Traffic-Engineering-Konfigurationen, zusätzliche Signalisierung, mehr Fehlerquellen. Segment Routing adressiert genau diese Pain Points, indem es Pfadsteuerung und Service-Transport stärker „algorithmisch“ und weniger „stateful“ im Kernnetz gestaltet. Das Ziel ist ein Backbone, der planbar skaliert, einfacher automatisiert werden kann und bei Erweiterungen nicht jedes Mal ein neues Signalisierungs- oder Tunnelmanagement-Problem erzeugt.

• Skalierung: Weniger pro-Tunnel-Zustand im Netz, bessere Eignung für große Topologien.
• Traffic-Steuerung: Pfade und Policies werden über Segmente definiert, nicht über komplexe Signalisierungsketten.
• Automatisierung: Standardisierte, wiederholbare Policy-Modelle erleichtern Rollouts und Änderungen.
• Resilienz: Schnelle Umschaltung und robuste Pfadwahl lassen sich konsequent planen und messen.

Grundidee: Was ist Segment Routing?

Segment Routing erweitert das Routing um das Konzept „Segmente“. Ein Segment ist eine Anweisung, wie ein Paket weitergeleitet werden soll. Statt für jeden Traffic-Flow separate, signalisierte Tunnel im Netz aufzubauen, kann der Ingress-Knoten (z. B. ein Edge-Router) eine Segmentliste in den Paketkopf schreiben. Diese Segmentliste steuert den Weg durch das Netz. Das Kernnetz muss dafür keine zusätzliche per-flow Signalisierung pflegen, sondern folgt der Segmentlogik und seinem IGP-Topologiewissen.

• Source Routing Idee: Der Einstiegsknoten legt die gewünschte Route fest, das Netz setzt sie um.
• Segmentliste: Sequenz von Schritten (Segmente), die den Pfad definieren.
• IGP als Grundlage: Die Topologie und Shortest Paths kommen aus OSPF oder IS-IS.
• Policy statt Tunnel-Wildwuchs: Steuerung über konsistente Regeln, nicht über massenhaft Einzelkonstrukte.

SR-MPLS vs. SRv6: Die beiden Ausprägungen im Überblick

Segment Routing gibt es in zwei Hauptvarianten: SR-MPLS und SRv6. Beide verfolgen das gleiche Prinzip, nutzen aber unterschiedliche Datenebenen. SR-MPLS arbeitet mit MPLS-Labels (Segment IDs als Labels), SRv6 nutzt IPv6 und trägt die Segmentliste in IPv6-Header-Erweiterungen (SIDs als IPv6-Adressen) beziehungsweise als SRv6-Konstrukte. Die Wahl hängt stark von Netzstrategie, Hardwareunterstützung, Betriebsmodell und Zukunftsplanung (insbesondere IPv6) ab.

• SR-MPLS: MPLS-Label-Stack als Segmentliste, oft evolutionärer Schritt aus bestehenden MPLS-Netzen.
• SRv6: IPv6-basierte Segmentliste, sehr flexibel für Service-Chaining und neue Funktionen, erfordert starke IPv6-Readiness.
• Gemeinsame Basis: IGP/Topology, Policies am Ingress, Observability und saubere Failure Models.

Wann SR-MPLS oft naheliegt

• Bestehendes MPLS-Backbone: Wenn MPLS bereits im Core etabliert ist und Hardware/Prozesse passen.
• Schrittweise Migration: Wenn ein evolutionärer Umstieg ohne kompletten IPv6-Overhaul gewünscht ist.
• Operative Kontinuität: Wenn MPLS-Tooling und Betriebswissen bereits stark ausgeprägt sind.

Wann SRv6 oft strategisch attraktiv ist

• IPv6 als Zielbild: Wenn IPv6 ohnehin End-to-End geplant ist und Innovationen auf IPv6 aufsetzen sollen.
• Service-Flexibilität: Wenn Service-Chaining, programmierbare SIDs und neue Service-Modelle wichtig sind.
• Langfristige Vereinheitlichung: Wenn man Transport und Service-Mechanik stärker in eine IPv6-Welt integrieren will.

Bausteine eines modernen SR-Designs

Unabhängig von SR-MPLS oder SRv6 bestehen moderne SR-Architekturen aus wiederkehrenden Bausteinen: ein stabiles IGP, konsistente Segment-IDs, klare Rollen im Netz (Core/Edge), ein Policy- und Traffic-Engineering-Modell sowie Telemetrie und Automatisierung. Der wichtigste Grundsatz bleibt dabei Telco-typisch: Der Core sollte schlank bleiben, und Komplexität gehört an definierte Kantenpunkte.

• IGP-Design: OSPF oder IS-IS als Topologiegrundlage, konsistente Metriken, klare Areas/Levels.
• Segment-Plan: Strukturierte Vergabe von SIDs (Node-SIDs, Adjacency-SIDs, ggf. weitere Typen).
• Policy-Framework: Einheitliche SR-Policies statt individueller Sonderfälle pro Standort.
• Fast Reroute: Schnelle Umleitung bei Ausfällen, ohne die Stabilität zu gefährden.
• Observability: Pfad-Transparenz, Event-Korrelation, Kapazitäts- und SLA-Messung.

Adressierung und SID-Planung: Ordnung ist Skalierung

Ein häufiger Erfolgsfaktor ist eine saubere Planung der Segment-IDs. In Telco-Netzen ist „Wachstum ohne Chaos“ nur möglich, wenn Identitäten strukturiert sind. Für SR-MPLS bedeutet das: konsistente Node-SIDs und ein klarer Plan, wie Adjacency-SIDs oder zusätzliche Segmente eingesetzt werden. Für SRv6 bedeutet es: ein IPv6-Adresskonzept für SIDs, das Regionen, Rollen und Funktionen sauber abbildet.

• Node-SIDs: Eindeutige Identität für Knoten, Grundlage für standardisierte Pfadsteuerung.
• Adjacency-SIDs: Detaillierte Steuerung über konkrete Links, sinnvoll für gezielte Pfade und Sonderfälle.
• Hierarchie: Regionen/PoPs/Rollen in der SID-Struktur erkennbar machen.
• Reserve: Freiräume für Wachstum und neue Knoten einplanen, um spätere Umbauten zu vermeiden.

Traffic Engineering mit Segment Routing: Steuerung ohne Tunnel-Overhead

Telcos nutzen Traffic Engineering, um Kapazität effizient zu verteilen, Hotspots zu entlasten und Latenzpfade zu optimieren. Segment Routing ermöglicht TE über Policy-Modelle, die am Ingress wirken: Der Einstiegsknoten wählt anhand von Regeln, Telemetrie und Zielvorgaben eine Segmentliste. Damit wird die gewünschte Route durch das Netz erreicht, ohne dass jeder Transit-Knoten massenhaft signalisierte Tunnelzustände pflegen muss.

• Policy-basierte Pfadwahl: Pfade anhand von Constraints (z. B. Latenz, Auslastung, Link-Gruppen) auswählen.
• ECMP bewusst nutzen: Parallele Pfade effizient auslasten, statt nur „ein bester Pfad“.
• Hotspot-Entlastung: Traffic gezielt um Engpässe herumführen, ohne globale Umkonfiguration.
• Planbare Latenz: Kritische Dienste (z. B. Mobile Transport, Echtzeit) auf geeignete Pfade legen.

Fast Reroute und Resilienz: Ausfälle schnell und stabil abfangen

Resilienz ist in Telco-Netzen nicht verhandelbar. Segment Routing unterstützt schnelle Schutzmechanismen, die Ausfälle abfangen, ohne dass das gesamte Netz „wild“ rekonvergiert. Entscheidend ist, dass Failover-Ziele messbar definiert werden und dass das Design echte Failure Domains berücksichtigt: Link-Ausfall, Node-Ausfall, PoP-Ausfall und Trassen-/Regionereignisse sind unterschiedliche Klassen, die unterschiedliche Maßnahmen erfordern.

• Link-Ausfall: Schnelle Umleitung über alternative Pfade, möglichst ohne Kundeneffekt.
• Node-Ausfall: Schutzpfade so planen, dass zentrale Knoten nicht zu Single Points of Failure werden.
• Trassenvielfalt: Physische Diversität ist Pflicht; logische Redundanz ohne Diversität ist nur scheinbar robust.
• N-1-Headroom: Failover darf nicht zur Überlast führen; Kapazitätsreserve ist Teil des Resilienzdesigns.

Services auf SR-Basis: VPNs, Transport und Segmentierung

Segment Routing ersetzt nicht automatisch alle Servicekonzepte, sondern bildet eine moderne Transportbasis, auf der Telco-Services effizient betrieben werden können. Typische Services sind weiterhin L2/L3-VPNs, Internet-Transport, Mobile Backhaul und Cloud-Connectivity. Der Mehrwert entsteht durch bessere Pfadsteuerung, stabilere Skalierung und die Möglichkeit, Servicepfade gezielt zu optimieren.

• L3VPN: Mandantenfähigkeit über VRFs bleibt zentral; SR verbessert Transport und TE darunter.
• L2VPN: L2-Services profitieren von stabilen Transportpfaden und klaren Failover-Eigenschaften.
• Mobile Transport: Pfadkontrolle für Latenz/Timing, resiliente Metro/Core-Pfade.
• Interconnect/Peering: Traffic zu Übergaben gezielt steuern, Hotspots vermeiden, Kapazität besser nutzen.

SRv6-Sicht: Warum viele Telcos über IPv6-Fähigkeit sprechen

SRv6 bringt zusätzliche Flexibilität, weil SIDs als IPv6-Adressen nicht nur Pfade, sondern auch Funktionen ausdrücken können. Das kann in modernen Designs hilfreich sein, wenn Service-Chaining, programmierbare Weiterleitungslogik oder eine Vereinheitlichung auf IPv6 gewünscht ist. Gleichzeitig ist SRv6 anspruchsvoll, wenn IPv6 im Betrieb noch nicht end-to-end etabliert ist oder wenn Hardware-Forwarding und Plattformunterstützung nicht einheitlich sind. Ein erfolgreiches SRv6-Design braucht daher eine klare IPv6-Strategie, konsequente Tests und ein sauberes Observability-Konzept.

• IPv6-End-to-End: Adressierung, Security, Monitoring und Troubleshooting müssen IPv6-nativ funktionieren.
• Forwarding-Skalierung: FIB/TCAM und Paketkopf-Overhead im Blick behalten, besonders bei langen Segmentlisten.
• Operational Readiness: Tooling, Telemetrie und Runbooks für IPv6/SRv6-Fehlerbilder vorbereiten.
• Standardisierung: SID-Design und Policy-Modelle konsistent halten, um Betriebsrisiko zu senken.

Integration in bestehende Netze: Migrationspfade ohne Big Bang

Die meisten Telco-Netze können nicht „über Nacht“ umgebaut werden. Best Practice ist eine schrittweise Migration mit klaren Etappen: zuerst IGP- und Adressierungsgrundlagen konsolidieren, dann SR in kontrollierten Bereichen aktivieren, anschließend Policies und TE-Funktionen ausrollen, und erst danach größere Service-Migrationen. Wichtig ist, dass jede Phase messbare Erfolgskriterien hat: Konvergenz, Stabilität, Routing-Events, Kapazitätsverteilung und operative Entstörbarkeit.

• Phase 1: IGP-Design, Loopbacks, Metriken und Dokumentation standardisieren.
• Phase 2: SR-Fähigkeit auf Kernknoten einführen, Segment-Plan ausrollen, Basistests durchführen.
• Phase 3: SR-Policies und TE kontrolliert aktivieren, Monitoring und Telemetrie verifizieren.
• Phase 4: Services schrittweise auf das neue Transportmodell migrieren, Failover- und Lasttests wiederholen.

QoS und SLA im SR-Design: Servicequalität bleibt ein End-to-End-Thema

Segment Routing verbessert Pfadsteuerung, ersetzt aber nicht automatisch QoS. Servicequalität entsteht weiterhin durch konsistente Markierung, klare Klassenmodelle und eine kontrollierte Behandlung an Engpässen. SR kann QoS unterstützen, indem es Traffic gezielt über Pfade führt, die ausreichend Kapazität und geeignete Latenz bieten. Dennoch bleibt die wichtigste Regel: QoS muss an der Edge beginnen und über Metro und Core konsistent umgesetzt werden.

• Klassenmodell: Wenige, klar definierte Klassen, die betrieblich beherrschbar sind.
• Markierung: Traffic möglichst früh klassifizieren und Markierungen konsistent transportieren.
• Engpasssteuerung: Shaping/Queueing an Übergaben und Aggregationspunkten, um Jitter und Drops zu minimieren.
• Messbarkeit: Queue-Drops, Latenz, Jitter und Paketverlust pro Klasse überwachen.

Observability und Troubleshooting: Pfade sichtbar machen

Ein modernes Telco-Design steht und fällt mit Sichtbarkeit. Segment Routing bringt neue Fragestellungen: Welche Policy hat diesen Traffic gesteuert? Welche Segmentliste wurde genutzt? Welcher Pfad war aktiv, und warum? Deshalb ist es wichtig, Observability als Designanforderung zu behandeln: Telemetrie, Flow-Daten, Routing-Events, Link-Events und Konvergenzzeiten müssen korrelierbar sein. Nur so lässt sich ein SR-Netz im Tagesgeschäft sicher betreiben.

• Pfad-Transparenz: Nachvollziehbarkeit, welche Policies und Segmente genutzt wurden.
• Flow-Daten: Traffic-Muster, Hotspots und Heavy Flows erkennen, Kapazitätsplanung datenbasiert machen.
• Event-Korrelation: Link-Flaps, IGP-Events, Policy-Changes und Traffic-Spitzen zeitlich zusammenführen.
• Konvergenz-Messung: Failover-Zeiten messen und als SLA-/Designparameter behandeln.

Sicherheit im SR-Kontext: Schutz der Infrastruktur und kontrollierte Policies

Segment Routing verändert nicht automatisch das Sicherheitsmodell, aber es verstärkt die Bedeutung von Standards, Control-Plane-Schutz und sauberer Policy-Governance. In Telco-Netzen sind Fehlkonfigurationen häufig riskanter als theoretische Angriffe: Ein falscher Policy-Rollout kann Traffic großflächig umleiten. Deshalb sind Reviews, Validierungen, Limits und klare Ownership-Regeln essenziell. Zusätzlich bleibt der Schutz von Managementzugängen und der Control Plane Pflicht.

• Change-Governance: Policy-Änderungen reviewen, testen, versionieren, Rollbacks vorbereiten.
• Control-Plane-Schutz: Schutzmechanismen gegen Flooding und Angriffe auf Routing/Management.
• Segment- und Policy-Standards: Konsistente Modelle reduzieren Fehlerwahrscheinlichkeit und verkürzen Entstörzeiten.
• Management-Segmentierung: Separates Managementnetz, RBAC, MFA, Audit-Logging, saubere Baselines.

Typische Stolperfallen bei Segment Routing und wie man sie vermeidet

Segment Routing kann ein Netz deutlich vereinfachen, wenn es mit klaren Leitplanken eingeführt wird. Ohne diese Leitplanken entstehen neue Komplexitätsformen: unstrukturierte SID-Vergabe, inkonsistente Metriken, Policy-Wildwuchs oder mangelnde Sichtbarkeit. Häufige Fehler sind außerdem „Redundanz ohne Diversität“ und fehlender Headroom, wodurch Failover zwar technisch funktioniert, aber operativ zu Überlast führt.

• Unsaubere SID-Planung: Ohne Struktur wird Skalierung teuer und fehleranfällig.
• IGP-Inkonsistenz: Metriken und Topologie müssen stabil sein, sonst wird TE unvorhersehbar.
• Policy-Wildwuchs: Zu viele Sonderfälle erschweren Betrieb; Standardisierung ist wichtiger als Perfektion.
• Observability-Lücken: Ohne Pfadtransparenz wird Troubleshooting langsam und riskant.
• Kein N-1-Headroom: Failover darf nicht automatisch zu Congestion und SLA-Verlust führen.

Operative Checkliste: Modernes Telco-Design mit SR-MPLS/SRv6 sauber umsetzen

Eine kompakte Checkliste hilft, Segment Routing strukturiert einzuführen und im Betrieb abzusichern. Sie eignet sich sowohl für neue Netze als auch für Migrationen aus klassischen MPLS-Designs.

• Ist das IGP-Design stabil, konsistent und auf Infrastruktur begrenzt (Loopbacks, Core-Links, klare Metriken)?
• Gibt es einen strukturierten SID-Plan (Region/PoP/Rolle), inklusive Reserven für Wachstum?
• Sind Rollen im Netz klar (Core schlank, Edge policy-/serviceorientiert) und sind Verantwortlichkeiten dokumentiert?
• Ist das Traffic-Engineering-Modell standardisiert (Policies, Constraints, Hotspot-Strategie) statt individuell pro Fall?
• Sind Failure Models definiert und ist N-1-Headroom eingeplant, damit Failover nicht zur Überlast führt?
• Ist QoS end-to-end konsistent und werden SLA-relevante Metriken (Drops/Jitter/Latenz) pro Klasse überwacht?
• Ist Observability vollständig (Pfadtransparenz, Flow-Daten, Event-Korrelation, Konvergenzmessung)?
• Gibt es sichere Change-Prozesse (Reviews, Tests, Versionierung, Rollback) für SR-Policies und Segment-Änderungen?
• Bei SRv6: Ist IPv6 end-to-end betriebsreif (Security, Tooling, Troubleshooting, Forwarding-Skalierung)?

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

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

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.