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

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.

• Symptom: Traffic nimmt „falsche“ Wege, endet an unerwarteten Egresses, oder bestimmte Regionen werden isoliert.
• Symptom: nur SR-Policy-Traffic betroffen; normaler IGP-Traffic wirkt ok.
• Diagnoseanker: Konsistenzcheck der advertised SIDs pro Node; Vergleich mit Source-of-Truth.
• Mitigation: SID-Plan korrigieren, Rollout stufenweise; bei akuter Störung betroffene Policies deaktivieren oder auf IGP-shortest-path zurückfallen.

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.

• Symptom: SR Policies bleiben down oder wechseln unerwartet; Pfade sind zwischen Knoten inkonsistent.
• Symptom: nur bestimmte PoPs/Linecards betroffen – häufig nach Upgrades.
• Diagnoseanker: SR Capability/Flags pro Router, IGP-Datenbank-Sicht konsistent?
• Mitigation: Feature-Parität herstellen, SR nur in validierten Domänen aktiv; Upgrade-Standardisierung.

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.

• Symptom: plötzlich andere Latenzprofile, Congestion auf unerwarteten Links, aber keine harten Alarme.
• Symptom: Traffic driftet nach einem Change oder nach einem Link-Event.
• Diagnoseanker: Welcher Candidate Path ist aktiv? Warum (Preference, Validity, Constraints)?
• Mitigation: Policy-Guardrails (nur erlaubte Fallbacks), Change-Validation mit Probes, klar definierte „Stop“-Kriterien.

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.

• Symptom: nur einige Kunden betroffen, oder nur bestimmte Flows (Hash-bedingt).
• Symptom: Queue Drops steigen auf einem Segment nach Policy-Änderung.
• Diagnoseanker: per-next-hop/per-LAG-member Telemetrie, Multi-Flow-Probes, Traffic-Shift-Korrelation.
• Mitigation: Headroom-Regeln, schrittweises Steering, per-segment Monitoring als Pflicht.

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).

• Symptom: sehr kurze, aber harte Loss-Spikes bei Link-Fails; danach Stabilisierung.
• Symptom: manche Links failen „clean“, andere verursachen große Impact-Fenster (Coverage-Lücken).
• Diagnoseanker: FRR-Coverage-Metriken, Repair Path Aktivierungs-Events, Zeit bis No-Impact.
• Mitigation: Coverage messen und als KPI behandeln; Topologie/Metriken so designen, dass FRR möglich ist.

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)

$\mathrm{Payload}\_\max =\mathrm{MTU}\_\mathrm{link}-\mathrm{Labels}\times 4-\mathrm{L3}\_\mathrm{header}$

• Symptom: kleine Pakete ok, große brechen; TLS/HTTP2/QUIC auffällig.
• Diagnoseanker: small vs. large Probes, ICMP/PMTUD-Verhalten, Drops ohne Errors.
• Mitigation: MTU-Standard erhöhen, Stack-Längen kontrollieren, Policy-Design so wählen, dass Stack nicht unnötig wächst.

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.

• Symptom: lange MTTR, weil „Policy-Ebene“ nicht sichtbar ist.
• Diagnoseanker: Policy-Status, Candidate Path, SID-Stack, Counters pro Policy/Segment.
• Mitigation: SR-Policy-Telemetrie als Pflicht; standardisierte Dashboards und Ticket-Felder (Policy-ID, Active Path).

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.

• Symptom: Probleme nur an Vendor-Grenzen oder nach Rolling Upgrades.
• Diagnoseanker: Feature-Matrix pro Plattform, konsistente Defaults, Interop-Tests als Teil von Change-Validation.
• Mitigation: standardisierte Profile, schrittweise Rollouts, klare „Supported Feature Set“-Definition.

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.

• Symptom: nach „Fix“ steigt Loss/Latenz wieder, weil Traffic zurückschwappt.
• Diagnoseanker: Traffic-Shift-Timeline, Queue Drops, Policy-Change-Events.
• Mitigation: Graceful Re-Enable, stufenweises Zurücknehmen von Policies, Headroom-Planung.

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

• Welche Services? nur SR-Policy Traffic oder auch normaler IGP-Transport?
• Welche Regionen/PoPs? isoliert oder global?
• Welche Richtung? einseitig oder bidirektional?
• Welche Größe/Protokolle? MTU-Indizien (small ok, large fail)?

Schritt: Underlay sanity check

• IGP stabil? Adjazenzen, SPF-Churn, Loopback-Reachability.
• Data Plane Health: Queue Drops, LAG-member Errors, Congestion auf Kernlinks.

Schritt: SR-Policy Nachweis

• Policy aktiv? welcher Candidate Path ist gewählt?
• SID-Stack plausibel? entspricht er dem erwarteten Intent (Node/Adj SIDs)?
• Fallback passiert? und wenn ja, warum?

Schritt: Pfadvalidierung und Segment-Telemetrie

• OAM-Ansatz: Pfadvalidierung entlang des tatsächlichen SR-Pfads (inkl. Segmentliste), soweit Tooling das unterstützt.
• Segment-Hotspots: welche Links/Nodes zeigen Drops oder ungewöhnliche Latenzspitzen?

Schritt: Mitigation wählen

• Policy degraden: gezielt auf sicheren Fallback (IGP-shortest-path), wenn Policy-Ebene verdächtig ist.
• Traffic drosseln/umlenken: wenn Congestion/Partial Failure, Headroom schaffen oder Steering anpassen.
• MTU fixen: wenn Stack-Länge/PMTUD-Indizien, MTU standardisieren und ICMP/PMTUD sicherstellen.

Evidence Pack: Pflichtdaten für SR-MPLS RCAs

• Policy-Daten: Policy-ID, aktive Candidate Path, SID-Stack, Change-Historie im Zeitfenster.
• IGP/SR Daten: advertised SIDs pro Node, SR-Capability pro Router, Inkonsistenz-Indizien.
• Data Plane: Queue Drops, per-link/per-member Errors, Traffic Shift Metriken.
• Probes: End-to-End SLIs, small vs. large Tests (MTU), multi-flow Probes (ECMP).

Outbound-Ressourcen

• RFC 8402 (Segment Routing Architecture)
• RFC 8660 (Segment Routing with MPLS Data Plane, SR-MPLS)
• RFC 3031 (MPLS Architecture)
• RFC 5880 (BFD: schnelle Failure Detection)
• RFC 5286 (Loop-Free Alternates, FRR-Grundlagen)
• RFC 2991 (Multipath Issues, ECMP-Kontext)
• RFC 8201 (PMTUD IPv6, relevant bei MTU/Stack-Blackholes)

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.