Das Hauptkeyword „Segment Routing (SR-MPLS): Störungs-Playbook und Schlüssel-Telemetrie“ trifft einen Nerv im Provider-Betrieb: Segment Routing gilt als modern, skalierbar und gut automatisierbar, aber im Incident zählt nicht die Architekturfolie, sondern die Geschwindigkeit der Störungsisolation. SR-MPLS verschiebt viele klassische Fehlerbilder aus der RSVP-TE-Welt (Signalisierungsstate, Refresh-Probleme) hin zu Themen wie IGP-SR-Konsistenz, SID-Programmierung, Policy-Verteilung und „Policy Churn“. Gleichzeitig wird die Diagnose oft schwieriger, wenn Teams SR nur als „Labels im IGP“ betrachten und nicht als ein eigenes Betriebsmodell mit klaren Zuständigkeiten: Underlay (Layer 1–3), SR-Datenebene (Label Stack, LFIB), SR-Control-Plane (IS-IS/OSPF Extensions, SRGB/SRLB) und optional ein Controller (PCE, SDN, Automationssystem). Ein gutes SR-MPLS-Playbook stellt sicher, dass ein War Room nicht in Spekulationen abgleitet („Controller kaputt“, „IGP spinnt“), sondern entlang einer reproduzierbaren Checkliste arbeitet. Dieser Artikel liefert genau das: eine praxisnahe Störungsroutine von den ersten Symptomen bis zur Root Cause sowie die Telemetrie, die in Provider-Grade-Umgebungen proaktiv vorhanden sein muss, um MTTR messbar zu senken.
SR-MPLS in zwei Minuten: Was im Betrieb wirklich relevant ist
SR-MPLS (Segment Routing mit MPLS Data Plane) nutzt Labels als „Segmente“, um Pfade explizit zu beeinflussen. Statt per-hop Signalisierung (wie bei RSVP-TE) wird am Ingress eine Segmentliste (SID-Stack) aufgebracht, und Transit-Router forwarden anhand des obersten Labels. Operativ wichtig ist dabei:
- IGP bleibt das Fundament: SR hängt an der Stabilität von IS-IS/OSPF und der Konsistenz ihrer Datenbanken.
- SIDs müssen konsistent sein: Node-SIDs, Adjacency-SIDs, ggf. Anycast-SIDs und SR-Policies müssen überall erwartungsgemäß auflösbar sein.
- LFIB ist die Wahrheit im Datenpfad: „IGP sieht gut aus“ hilft nicht, wenn die Label-Forwarding-Entries nicht passen.
- Controller ist optional, aber operativ prägend: SR kann rein verteilt laufen oder stark controller-gesteuert (SR-TE, PCE). Das ändert Failure Modes.
Für Begrifflichkeiten und Architektur sind RFC 8402 (Segment Routing Architecture) und für SR-MPLS speziell RFC 8660 (SR-MPLS) sehr nützlich.
Operatives Modell: SR in OSI einordnen, ohne Layer-Dogma
SR-MPLS ist kein eigener OSI-Layer, aber im Betrieb wirkt es wie eine „Layer 2.5“-Domäne zwischen IP-Routing und Service-Overlays. Damit Tickets standardisiert werden können, empfiehlt sich ein pragmatisches Mapping:
- Layer 1: Optik, Link-Errors, DWDM/Transceiver, Flaps, physische Pfade.
- Layer 2: Ethernet/L2-Adjazenzen, VLAN/LACP, OAM im Access/Metro.
- Layer 3 (Underlay): IS-IS/OSPF Nachbarschaften, SPF/Convergence, ECMP, MTU/PMTUD.
- SR-MPLS Datenebene: SID-Stack, Label-Operationen (push/swap/pop), LFIB-Konsistenz, TTL/MTU-Overhead.
- SR Control / Policy: SR-Extensions im IGP, SRGB/SRLB, SR-Policies, Controller/PCE-Verteilung, Versionsdrift.
Dieses Modell verhindert den Klassiker: Teams debuggen SR-Policies, obwohl das Underlay gerade konvergiert oder ein Link massiv Fehler produziert.
Störungs-Playbook: Von Symptom zu Hypothese in 10 Schritten
Das folgende Playbook ist vendorneutral formuliert. Es ist bewusst als Sequenz aufgebaut: Jede Stufe hat ein klares „Pass/Fail“-Kriterium und reduziert die Hypothesenmenge.
Symptom und Scope festnageln
- Scope: Einzelner Service/Customer, ein PoP, mehrere PoPs, global?
- Symptomklasse: Hard-Down (keine Erreichbarkeit) vs. Degradation (Loss/Jitter/Latency)?
- Zeitraum: Seit wann? Korrelation zu Changes, Maintenance, IGP-Events?
- Betroffene Pfade: Nur SR-Policies oder auch „normaler“ IGP-Traffic?
Layer 1–2: Die schnellen Ausschlüsse
- Link-Health: Flaps, Errors, FEC/CRC, Dom/DDM-Alarme.
- Interface-Drops: Discards/Queue-Drops, Microbursts, Policer-Hits.
- Aggregation: LACP-Member stabil, Hashing nicht auf einen defekten Member gekippt?
Wenn hier Auffälligkeiten existieren, ist SR selten die Root Cause, sondern nur der sichtbare „Leidtragende“.
Layer 3 Underlay: IGP-Realität vor SR-Interpretation
- Adjazenzen: IS-IS/OSPF Nachbarn stabil? Häufige Resets?
- Konvergenz: SPF-Läufe, LSA/LSP-Churn, Overload/Partition-Anzeichen.
- ECMP: Hat sich Pfadverteilung geändert? Gibt es einen „bad ECMP leg“?
- MTU/PMTUD: Hinweise auf Fragmentation oder „Packet Too Big“?
SR ist hochsensitiv gegenüber IGP-Instabilität, weil SIDs und Pfade aus derselben Topologiesicht abgeleitet werden.
SRGB/SID-Konsistenz prüfen: Der häufigste „unsichtbare“ Fehler
Ein klassischer SR-Outage entsteht, wenn SRGB (Segment Routing Global Block) oder SID-Zuordnungen inkonsistent sind. Dann kann derselbe Node-SID-Wert auf verschiedenen Routern unterschiedliche Bedeutungen haben. Operativ sollten Sie eine klare Policy haben: SRGB einheitlich oder streng validiert pro Domäne.
- SRGB-Konsistenz: identische Range und identische Offset-Logik in der gesamten SR-Domäne.
- Node-SID-Unique/Anycast-Regeln: Sind Anycast-SIDs bewusst eingesetzt und dokumentiert?
- Adjacency-SIDs: werden sie genutzt? Stimmen sie nach Interface-Changes noch?
LFIB und Datenpfad: „Control Plane ok“ reicht nicht
Wenn ein Service fällt, obwohl IGP sauber aussieht, ist der nächste Schritt die Datenebene: Stimmen die Label-Forwarding-Entries (LFIB) und die tatsächlich genutzten Label-Operationen?
- LFIB-Entries vorhanden: gibt es Labels für die relevanten SIDs und Next Hops?
- Next-Hop-Konsistenz: zeigt die LFIB auf denselben Next Hop wie die IGP-Sicht (oder die SR-Policy erwartet)?
- Pop/Swap-Verhalten: werden Labels unerwartet gepoppt (PHP/Explicit Null) und verändert das die Diagnose?
SR-Policy-Status und Pfadentscheidungen
In SR-TE-Setups hängt der Verkehr oft an Policies (z. B. Candidate Paths, Constraints, Segmentlisten). Ein Ausfall kann durch Policy-Fehler entstehen, obwohl Underlay und SIDs grundsätzlich funktionieren.
- Policy aktiv? Ist die Policy „up“ und wird sie tatsächlich genutzt (Traffic steered)?
- Candidate Path gewechselt? Gab es Failover auf einen Backup/secondary?
- Constraint-Probleme: Bandbreite/Latency/Color/Metric-Constraints erfüllen sich nicht mehr.
- Policy-Distribution: haben alle relevanten PEs dieselbe Policy-Version?
Controller/PCE: Nur prüfen, wenn der Betrieb wirklich davon abhängt
Wenn SR-TE controller-gesteuert ist, muss ein Incident-Playbook auch Controller-Health und Verteilung abdecken – aber ohne vorschnell den Controller zu beschuldigen. Typische Fragen:
- Connectivity: Haben PEs stabile Sessions zum Controller (wo relevant)?
- Staged Rollout: Wurde kürzlich eine neue Policy-Version ausgerollt?
- Fallback-Verhalten: Was passiert bei Controller-Ausfall: bleibt die letzte Policy, fällt auf IGP zurück, oder wird Traffic blackholed?
Schlüssel-Telemetrie: Was für Provider-Grade SR-MPLS zwingend ist
Ohne Telemetrie ist SR-Betrieb im großen Maßstab eine MTTR-Falle. Entscheidend ist eine Kombination aus Underlay-Signalen, SR-spezifischen Signalen und Policy-/Controller-Signalen. Die folgenden Kategorien sind praxiserprobt.
Underlay Telemetrie (L1–L3) als Baseline
- Interface Errors & Flaps: CRC/FEC, optical power, LOS/LOF, Flap-Rate pro Stunde.
- Queue-Drops: Drops/ECN-Marks, Microburst-Indikatoren, Policer-Hits.
- IGP-Churn: Anzahl SPF-Läufe, LSP/LSA-Rate, Adjazenz-Resets, Overload-Bit-Events.
- ECMP-Health: pro-next-hop Loss/Delay (wenn messbar), Hash-Imbalance, „bad leg“ Erkennung.
SR-Datenebene: LFIB- und Label-Health
- LFIB-Snapshot-Checks: erwartete SIDs vorhanden, Next-Hop korrekt, keine „missing label“-Zustände.
- Label-Stack-Statistiken: wie viele Labels werden typischerweise gepusht? Auffällige Veränderungen (z. B. von 2 auf 5) sind ein Alarmzeichen.
- TTL/MTU-Indikatoren: Drops bei großen Paketen, ICMP „Packet Too Big“, PMTUD-Fehler.
Der MTU-Aspekt ist in SR-TE besonders relevant, weil Segmentlisten den Label-Stack verlängern können. Der zusätzliche Overhead lässt sich einfach berechnen: Pro Label 4 Byte.
Wenn eine SR-Policy von 2 auf 6 Labels wächst, steigt der Overhead von 8 auf 24 Byte. In MTU-knappen Umgebungen kann das der Unterschied zwischen „geht“ und „sporadisch kaputt“ sein.
SR-Control-Plane: Konsistenz und Drift-Detektion
- SRGB/SRLB Konsistenzalarme: Abweichungen sind High Severity, weil sie Datenpfad-Fehler verursachen können.
- SID-Inventory: Node-SIDs, Anycast-SIDs, Adjacency-SIDs – mit Versionierung und Audit-Trail.
- IGP-SR-DB Checks: stimmen die SR-Informationen (SIDs, Flags) über alle Router überein?
Policy- und Controller-Telemetrie (wenn SR-TE genutzt wird)
- Policy-Status: active/standby, selected candidate path, last change time, change reason.
- Policy-Churn: Anzahl Policy-Wechsel pro Zeitraum (Indikator für Instabilität oder aggressive Optimierung).
- Distribution-Health: Versionsdrift zwischen PEs, fehlende Updates, Rollout-Failures.
- Controller Health: session up/down, push latency, error rates, backlog.
Eine einfache Kennzahl für „Policy-Stabilität“ ist die Wechselrate pro Stunde/Tag. Je höher sie ohne echte Underlay-Failures ist, desto höher das Risiko von self-inflicted Incidents.
Diagnose-Muster: Welche Symptome typischerweise auf welche SR-Ursache deuten
In War Rooms hilft es, symptomorientierte Muster zu kennen. Die folgenden Zuordnungen sind nicht absolut, aber sie verkürzen die erste Hypothesenrunde erheblich.
- Plötzlicher Hard-Down vieler SR-Services in einer Region: IGP-Partition, SRGB-Drift nach Change, massiver Link-Failure, falsches Overload/Topology-Event.
- Nur SR-Policy-Traffic betroffen, normaler IGP-Traffic ok: Policy-Distribution fehlerhaft, Segmentliste falsch, Candidate Path auf einen schlechten Pfad gewechselt.
- Nur große Flows/TCP betroffen, Ping ok: MTU/Label-Stack-Overhead, PMTUD geblockt, Fragmentation-Probleme.
- Intermittierender Loss/Jitter nach Failover: Schutzpfad überlastet, ECMP „bad leg“, Queue-Drops nach Umschaltung.
- Unidirektionale Probleme: asymmetrisches Steering, Policy nur in eine Richtung aktiv, inkonsistente SID/Policy-Sicht an einem Edge.
Mass-Mitigation: Was Sie in großen SR-Incidents schnell und sicher tun können
Ein gutes Playbook enthält nicht nur Diagnosen, sondern auch risikoarme Mitigations, die Teams zügig ausführen können, ohne den Incident zu verschlimmern. Typische, vergleichsweise sichere Maßnahmen (abhängig vom Betriebsmodell):
- Traffic zurück auf IGP lenken (Fallback): wenn SR-Policies instabil sind und ein kontrollierter Fallback existiert.
- Policy-Optimierung pausieren: um Policy-Churn zu stoppen (z. B. Re-Optimization/Controller-Rollouts temporär einfrieren).
- Bekannten guten Candidate Path erzwingen: wenn ein Secondary/Backup stabil ist und der Primary überlastet.
- Hotspot entschärfen: Traffic-Shifting weg von überlasteten Links/Queues (temporäre TE-Constraints).
- IGP stabilisieren: Adjazenz-Flaps beheben, Overload korrekt setzen/entfernen, fehlerhafte Links isolieren.
Wichtig ist, jede Mitigation mit einem messbaren Ziel zu koppeln (Loss sinkt, Latenz normalisiert, Churn stoppt) und zeitlich zu protokollieren, damit Ursache und Wirkung im RCA später nachvollziehbar bleiben.
Standardisierung im Ticketing: SR-Playbook in Felder übersetzen
Damit SR-MPLS im Alltag skalierbar betreibbar ist, sollten Tickets und RCAs standardisierte Felder enthalten. Das reduziert Abstimmungsaufwand zwischen NOC, Backbone und Automation-Teams.
- Betroffene Domäne: Underlay / SR Data Plane / SR Control / Policy/Controller.
- Scope: PoP, Region, globale Domäne, Kundensegment.
- Symptomtyp: Hard-Down / Degradation / Intermittent / Unidirectional.
- SR-Indikatoren: SRGB-Konsistenzstatus, Policy-Version, selected candidate path, letzter Policy-Wechselzeitpunkt.
- Underlay-Indikatoren: IGP-Churn, Interface-Errors, Queue-Drops, ECMP-Bad-Leg-Hinweise.
- Mitigation: Fallback/Freeze/Constraint-Change – plus Zeit und beobachteter Effekt.
Outbound-Links für Standards und vertiefende Informationsquellen
- Segment Routing Architecture (RFC 8402) für Grundbegriffe und Architektur
- Segment Routing with MPLS Data Plane (RFC 8660) für SR-MPLS Grundlagen
- MPLS Architecture (RFC 3031) zur Einordnung von Label-Forwarding im Backbone
- MPLS Label Stack Encoding (RFC 3032) für Label-Stack, TTL und Header-Details
- MPLS-TP Linear Protection (RFC 7810) als Referenz für Schutzkonzepte und Terminologie
- Framework for MPLS Traffic Engineering (RFC 4655) für TE-Begriffe und Betriebslogik
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.
