Site icon bintorosoft.com

Segment Routing (SR-MPLS): Failure Modes, die Ops beherrschen müssen

Red Snapper

Segment Routing (SR-MPLS) wird oft als „weniger Protokolle, weniger Probleme“ verkauft: Kein klassisches LDP, weniger Signalisierung, klarere Pfadsteuerung. Operativ stimmt das teilweise – aber nur, wenn Operations-Teams die Failure Modes von SR-MPLS wirklich beherrschen. Denn SR verschiebt die Komplexität: weg von LDP-Nachbarschaften hin zu SID-Planung, IGP-Extensions, Policy-Logik, Label-Stacks, FRR-Mechaniken (z. B. TI-LFA) und der Frage, wie ein Router im Fehlerfall den „Intent“ eines Pfads interpretiert. Viele SR-Incidents fühlen sich zunächst „mysteriös“ an: Der Underlay-Ping ist ok, IGP ist converged, aber ein SR-Policy-Traffic fließt nicht wie geplant; nur bestimmte Services sind betroffen; MTU-Probleme tauchen plötzlich auf; oder ein einzelner Node-SID-Drift isoliert einen PoP. Genau deshalb braucht SR-MPLS im NOC klare, wiederholbare Nachweise: Welche SID-Liste ist aktiv? Welche Candidate Path wurde gewählt? Welche Repair-Mechanik griff? Und ist das Problem Control Plane, Policy-Ebene oder Data Plane? Dieser Artikel beschreibt die wichtigsten Failure Modes von Segment Routing (SR-MPLS), die Ops beherrschen müssen – inklusive typischer Symptome, schneller Diagnoseanker und praktischer Mitigation-Ansätze.

Kurzer Kontext: Was SR-MPLS operativ anders macht

In SR-MPLS wird die Forwarding-Entscheidung häufig über Segment-IDs (SIDs) beschrieben. Node-SIDs repräsentieren Knoten, Adj-SIDs repräsentieren Links/Adjazenzen (je nach Design), und SR-Policies können explizite SID-Listen vorgeben, die einen Traffic-Intent ausdrücken. Die SR-Informationen werden typischerweise über IGP-Extensions verteilt; SR-Policies können lokal oder zentral gesteuert werden. Operativ bedeutet das: Fehler entstehen nicht nur durch „Link down“, sondern durch Inkonsistenzen in SIDs, Policies oder Label-Stack-Handling. Als Referenz für SR-Architektur eignet sich RFC 8402, für SR mit MPLS Datenebene RFC 8660.

Failure Mode 1: SID-Plan-Drift (Node-SID-Kollisionen oder Inkonsistenzen)

Ein klassischer SR-Fehler ist ein inkonsistenter SID-Plan. Wenn zwei Router dieselbe Node-SID nutzen oder wenn Node-SIDs in einem PoP anders geplant sind als im Rest des Netzes, kann Traffic falsch zugestellt oder blackholed werden. Das ist operativ besonders gefährlich, weil IGP „gesund“ wirken kann: Die Topologie stimmt, aber die Segment-Identitäten sind falsch.

Failure Mode 2: SR-IGP-Extension Probleme (SR Capability nicht überall konsistent)

SR hängt stark davon ab, dass IGP-Extensions korrekt verteilt und interpretiert werden. Wenn einzelne Router SR nicht vollständig unterstützen (Softwarestand, Feature-Flags, falsche IGP-Parameter), entstehen „Halb-SR“-Zustände: ein Teil des Netzes kennt die SIDs oder SR-Attribute nicht korrekt.

Failure Mode 3: Policy-Selection Fehler (Candidate Paths, Preference, Fallback)

SR-MPLS wird im Betrieb oft über SR Policies genutzt. Diese haben häufig Candidate Paths (z. B. explicit vs. dynamic), Prioritäten und Fallback-Mechaniken. Ein häufiger Failure Mode ist nicht „Path down“, sondern „Policy wählt den falschen Candidate“ oder fällt in einen ungewollten Fallback, der zwar technisch funktioniert, aber Kapazität oder Latenz sprengt.

Failure Mode 4: ECMP und SR – unerwartete Lastverteilung

SR löst ECMP nicht auf. Auch SR-Pfade können über ECMP-Segmente laufen. Das bedeutet: Partial Failures und selektive Drops bleiben relevant. Zusätzlich kann die Kombination aus Policy-Steering und ECMP Hotspots erzeugen: Viele Flows werden gezielt auf denselben Pfad gelenkt, der vorher „zufällig“ verteilt war.

Failure Mode 5: TI-LFA/FRR greift falsch oder unvollständig

Viele SR-Backbones setzen auf schnelle Umleitung (Fast Reroute). TI-LFA ist eine verbreitete Technik, deren Details je nach Plattform variieren. Operativ ist die gefährliche Situation: FRR greift scheinbar, aber der Repair Path ist suboptimal oder erzeugt Transienten, die Kunden sehen (Loss-Spikes, Microbursts).

Failure Mode 6: Label-Stack-Overhead und MTU-Regressionen

SR-MPLS kann mehr Labels im Stack nutzen als klassische LDP-Setups, insbesondere bei expliziten Segmentlisten oder bei zusätzlichen Service-Labels. Dadurch sinkt die maximale Payload, wenn die physische MTU nicht angepasst ist. Das führt zu PMTUD-/MTU-Blackholes, die sich oft als „nur bestimmte Anwendungen“ zeigen.

Vereinfachte Payload-Abschätzung (MathML)

Payload_max = MTU_link − Labels×4 − L3_header

Failure Mode 7: OAM/Observability-Lücken – SR ist da, aber niemand sieht den aktiven Pfad

In vielen Migrationen ist das größte Ops-Problem nicht SR selbst, sondern fehlende Sichtbarkeit: Teams wissen nicht, welche SID-Liste gerade aktiv ist, welche Policy gewinnt, oder ob der Pfad sich verändert hat. Dann wird Troubleshooting wieder zu Rätselraten – genau das, was SR eigentlich verbessern soll.

Failure Mode 8: Multi-Vendor-Interop und Feature-Drift

SR-MPLS ist standardisiert, aber Details sind in Multi-Vendor-Netzen operativ entscheidend: SID-Behaviors, OAM-Implementierung, Policy-Features, FRR-Mechaniken und Telemetrie unterscheiden sich. Das kann zu „funktioniert im Lab, bricht in Produktion“ führen, wenn ein Vendor im Failurefall anders reagiert.

Failure Mode 9: Traffic Steering erzeugt Second Outage nach Recovery

SR macht Traffic Engineering einfacher – und damit ist das Risiko größer, große Traffic Shifts schnell auszulösen. Nach Repairs oder nach Policy-Rollbacks kann Traffic auf einmal zurückspringen und Congestion verursachen. Das ist der klassische Second Outage nach Mass-Recovery, nur eben mit SR-Triggern.

Ops-Runbook: SR-MPLS Incident-Triage in Minuten

Das folgende Runbook ist bewusst vendorneutral und auf Nachweise fokussiert. Es reduziert SR-Incidents auf drei Ebenen: Underlay, SR-Policy, Data Plane.

Schritt: Scope und Klassifikation

Schritt: Underlay sanity check

Schritt: SR-Policy Nachweis

Schritt: Pfadvalidierung und Segment-Telemetrie

Schritt: Mitigation wählen

Evidence Pack: Pflichtdaten für SR-MPLS RCAs

Outbound-Ressourcen

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