Fiber-Cut-Incident: NOC-Runbook vom Alarm bis zum Field Dispatch

Ein Fiber-Cut-Incident ist im Provider- und Telco-Betrieb einer der klarsten, aber gleichzeitig operativ anspruchsvollsten Störfälle: Die physische Verbindung ist unterbrochen oder so stark degradiert, dass der Dienst aus Kundensicht ausfällt. Obwohl die Ursache „physisch“ ist, entstehen in der Praxis schnell komplexe Folgeeffekte: Traffic verschiebt sich auf Schutzpfade, Congestion steigt, Routing konvergiert mehrfach, Services wie DNS/AAA/Mobile/Voice geraten unter Druck, und Support meldet „Internet langsam“ statt „Trasse getrennt“. Ein NOC-Runbook für den Fiber-Cut muss deshalb zwei Dinge gleichzeitig leisten: Es muss die Fault-Location schnell in eine konkrete Fault Domain (Span/SRLG/Ring/PoP) übersetzen und parallel die Stabilisierung der Dienste steuern, bis Field Dispatch oder Carrier Repair die physische Strecke wiederherstellt. Entscheidend ist dabei ein standardisierter Ablauf vom Alarm bis zum Field Dispatch: klare Rollen, eindeutige Zeitfenster in UTC, ein Minimal-Evidence-Set, frühe Mitigation mit Guardrails und eine robuste Kommunikationsroutine. Dieses Runbook ist so formuliert, dass es direkt als Template in NOC-Prozesse, War-Room-Dokumente oder Ticketing übernommen werden kann.

Ziele und Scope des Runbooks

• Ziel 1: Kundenimpact minimieren (schnelle Stabilisierung, kontrollierter Traffic-Shift, Vermeidung von Second Outages).
• Ziel 2: Fault-Location präzisieren (welcher Span/Ring/SRLG/PoP ist betroffen) und Field Dispatch beschleunigen.
• Ziel 3: Beweiskette sicherstellen (Evidence Pack für Carrier/Vendor/Field Service, später RCA/SLA).
• Scope: Glasfasertrassen, DWDM-/Transportspans, Metro- und Backbone-Ringe, NNI/UNI-Strecken, PoP-Anbindungen.

Rollen im Fiber-Cut-Incident

Ein Fiber-Cut eskaliert schnell. Damit Diagnose und Dispatch parallel laufen, sind Rollen wichtig. In kleinen Teams können Rollen kombiniert werden, aber die Verantwortlichkeiten sollten klar benannt sein.

• Incident Commander (IC): steuert Prioritäten, entscheidet über Mitigation/Traffic-Shift, Update-Takt, Eskalationen.
• NOC Operator (Triage): sammelt Minimaldaten, bestätigt Scope, startet Erstchecks, eröffnet Master-Ticket.
• Transport/Optics Lead: bewertet L1/L0 Signale (LOS/LOF, Rx/Tx, FEC/BER/OSNR sofern verfügbar), identifiziert Span/SRLG.
• Routing/Traffic Lead: bewertet L3/L2 Folgeeffekte (Konvergenz, Hot Links, TE/Protection), setzt Guardrails.
• Field Coordinator: löst Field Dispatch aus, koordiniert Zugang, Sicherheits- und Standortdaten, ETAs.
• Comms Lead: interne/externe Kommunikation (Support, Statuspage, Key Accounts) auf Basis bestätigter Fakten.
• Scribe: pflegt SSoT (Single Source of Truth), Timeline, Actions Log, Evidence Links.

Vorbedingungen: Was im NOC vorbereitet sein muss

Ein Fiber-Cut lässt sich nur dann schnell lokalisieren und dispatchen, wenn Grunddaten vorhanden sind. Im Idealfall sind diese Informationen bereits im Inventory und in Dashboards verlinkt.

• Trassen-/Span-Mapping: A/Z-Ende, PoPs, Ring-ID, SRLG-ID, relevante Cross-Connects (ODF).
• Kontaktpfade: Field Service On-Call, Carrier NOC, Subunternehmer, Security/Access für Standorte.
• Standard-Evidence Views: Optik/Interface-Events, Protection/TE Events, Hot-Link-/Drops-Ansichten, Impact-SLIs.
• Ticket-Template: UTC-Zeitfenster, Fault Domain Felder, Dispatch-Checkliste, Evidence Pack Struktur.

Phase 1: Alarmaufnahme und Sofortklassifikation

In den ersten 2–5 Minuten geht es um die richtige Einordnung: Handelt es sich um einen echten Fiber Cut (harte Unterbrechung) oder um Degradation (schleichend)? Und ist der Scope regional, ringbasiert oder service-spezifisch?

Sofortsignale, die stark auf Fiber Cut hindeuten

• LOS/LOF: Loss of Signal / Loss of Frame auf Transport-/Ethernet-Interfaces.
• Link Down + Flap Cluster: mehrere Links/Channels in derselben Domain fallen gleichzeitig aus.
• DWDM Span Alarm: Span Down, amplifier alarms, ROADM path loss (je nach Plattform).
• Plötzlicher Scope: viele Kunden/Access-Knoten in einer Region gleichzeitig betroffen.

Ticketing und SSoT sofort starten

• Master-Ticket: ein Incident als zentrale Referenz (SSoT-Link, War-Room-Link).
• UTC-Zeitstempel: t_start (Impact-Beginn), t_detect (Alarmzeit), t_declared (Incident declared).
• Erste Hypothese: „Verdacht Fiber Cut in Fault Domain X“, klar als suspected markiert.

Phase 2: Minimal Evidence Set – genug Daten für Fault-Location und Dispatch

Bei Fiber Cuts ist Geschwindigkeit wichtiger als Vollständigkeit. Ein Minimal Evidence Set reicht, um Dispatch auszulösen und parallel die Stabilisierung zu starten.

• Identifikatoren: betroffene Interfaces/Ports, A/Z-Ende (PoPs), Ring-ID/SRLG-ID (falls verfügbar).
• Events: Link Down Zeitpunkte, Anzahl betroffener Links/Channels, ob gleichzeitig.
• Optik: Rx/Tx dBm, ob abrupt auf „kein Signal“ fällt oder degradiert; FEC/BER/Errors (falls vorhanden).
• Pfadkontext: Schutzpfad aktiv? TE/Protection Switching ausgelöst?
• Impact-Signal: grobe ImpactRate oder Service-SLI (Timeout-Rate, Session-Failures) pro Region/Produkt.

ImpactRate als schnelle Einordnung (MathML)

$\mathrm{ImpactRate}=\frac{\mathrm{impacted\_units}}{\mathrm{total\_units}}$

Die „units“ müssen zur Produktlinie passen (z. B. aktive Sessions, VPN-Sites, Mobile Registrierungen). Für den Dispatch genügt zunächst eine grobe, konsistente Schätzung („hoch/mittel/niedrig“ plus Zahl, wenn verfügbar).

Phase 3: Fault-Location bestimmen – Span, SRLG, Ring oder PoP?

Das wichtigste Ergebnis vor Field Dispatch ist eine plausible Fault-Location. Das bedeutet: nicht „irgendwo im Netz“, sondern eine konkrete Domain, in der Field Service handeln kann.

Heuristik: „Gemeinsame Kachel“ über betroffene Links finden

• Mehrere Links zwischen denselben PoPs down: Verdacht auf gemeinsamen Span oder ODF/Cross-Connect.
• Mehrere Wellenlängen/Channels betroffen: Verdacht auf Trasse/Span, Verstärkerstandort oder ROADM-Knoten.
• Nur eine Richtung oder nur ein Interface: Verdacht auf Patch/Transceiver/Linecard (nicht primär Fiber Cut).
• Ring Protection aktiviert: Fiber Cut wahrscheinlich auf Ring-Segment; Ring-ID als Dispatch-Schlüssel nutzen.

OTDR-/Power-Messung: Wann und wie sie in den Ablauf passt

OTDR ist ideal zur Lokalisierung, aber nicht immer sofort verfügbar. Das Runbook sollte festlegen, wann OTDR zwingend ist: bei unklarer Fault-Location, bei mehrfachen Spans in Frage, oder wenn der Carrier eine Distanzangabe für Dispatch verlangt.

• OTDR sofort: wenn A/Z-Ende unklar oder mehrere potenzielle Trassen beteiligt sind.
• OTDR nach Stabilisierung: wenn zunächst Mitigation nötig ist und die Region stabilisiert werden muss.
• Power Meter: wenn DOM-Werte unzuverlässig sind oder für Carrier-Eskalation ein unabhängiger Messwert benötigt wird.

Phase 4: Sofort-Mitigation – Stabilisieren, bevor Folgeprobleme eskalieren

Ein Fiber Cut löst häufig Traffic-Shifts aus. Diese können sekundäre Störungen erzeugen: Congestion auf Schutzpfaden, erhöhte Latenz, Paketverlust, Routing-Churn. Das Runbook muss daher eine kontrollierte Mitigation vorsehen.

Mitigation-Optionen (staged)

• Protection nutzen: Ring-Protection/TE-Failover aktiv, aber Schutzpfad-Headroom prüfen.
• Traffic Engineering: kontrollierte Shifts, um Hot Links zu entlasten (nicht „alles auf einmal“).
• QoS Guardrails: kritische Klassen schützen (Control-Plane, Voice, Mobile Signaling).
• Rate-Limits: falls Session-Rebuild droht (z. B. Mobile/BNG/AAA), kontrollierte Dämpfung erwägen.

DropRate als Guardrail (MathML)

$\mathrm{DropRate}=\frac{\mathrm{dropped\_packets}}{\mathrm{total\_packets}}$

• Regel: Wenn DropRate auf Schutzpfaden deutlich über Baseline steigt und > X Minuten anhält, muss Mitigation angepasst oder weiterer Traffic geshiftet werden.
• Ziel: Second Outage vermeiden, bei dem nach dem ersten Recovery Congestion und Timeouts explodieren.

Phase 5: Kommunikation – konsistent, knapp, ohne Spekulation

Fiber Cuts erzeugen hohen Kommunikationsdruck. Eine robuste Routine verhindert widersprüchliche Aussagen und sorgt dafür, dass Support und Management das gleiche Lagebild haben.

Update-Takt und Inhalte

• Intern (NOC/War-Room): alle 10–15 Minuten: Scope, bestätigte Fakten, Maßnahmen, Validierung, nächste Schritte.
• Extern (Support/Statuspage): alle 15–30 Minuten oder nach Bedarf: betroffene Regionen/Dienste, aktueller Status, Workarounds, nächstes Update.

Für Kommunikationsmuster und „confirmed facts“-Disziplin sind praxisnahe Leitfäden hilfreich, z. B. Atlassian Incident Communication und Prozessressourcen wie PagerDuty Incident Response.

Phase 6: Field Dispatch – vom Verdacht zur konkreten Beauftragung

Field Dispatch ist der Wendepunkt: Jetzt wird aus der NOC-Diagnose eine physische Entstörung. Damit Dispatch schnell läuft, braucht es ein standardisiertes Dispatch-Paket, das ohne Rückfragen nutzbar ist.

Dispatch-Pflichtdaten

• Fault-Location: Span/Ring/SRLG/PoP, A/Z-Ende, vermuteter Abschnitt (so genau wie möglich).
• Zeitfenster (UTC): Startzeit, Peak, aktueller Stand; letzte stabile Messung (falls vorhanden).
• Symptome: LOS/LOF, Rx-Power drop, mehrere Wellenlängen down, Link-Flaps.
• Messdaten: DOM Rx/Tx dBm, OTDR-Distanz (wenn vorhanden), eventuelle Power-Meter-Werte.
• Impact: betroffene Regionen/Services, grobe ImpactRate oder „hoch/mittel/niedrig“.
• Access/Logistik: Standortzugang, Sicherheitsauflagen, Schlüssel/Contact, geplante ETA, Ansprechpartner vor Ort.

Carrier vs. eigenes Field Team: Entscheidungskriterien

• Carrier-Strecke: Carrier-Ticket sofort eröffnen; Evidence Pack beilegen; SLA/ETA abfragen.
• Eigene Trasse: Field Dispatch direkt; OTDR zur Lokalisierung nutzen; Trassenplan heranziehen.
• Unklare Ownership: parallel: Carrier informieren und internes Field Team standby, bis Ownership bestätigt ist.

Phase 7: Evidence Pack – Beweise für Carrier/Vendor und späteres RCA

Ein Fiber-Cut wird häufig später für SLA-Nachweise, Gutschriften und RCA benötigt. Ein kleines Evidence Pack spart Stunden Arbeit und beschleunigt externe Eskalationen.

• 00_meta: Incident-ID, Rollen, Zeitfenster UTC, betroffene Fault Domains, Kontakte.
• 10_events: Link Down/Up Timeline, Protection/TE Events, Routing-Konvergenz (kurz).
• 20_optics: Rx/Tx dBm, LOS/LOF, FEC/BER/Errors (falls vorhanden), Vorher/Nachher nach Repair.
• 30_impact: ImpactRate/SLIs, betroffene Produktlinien/Regionen, Peak-Fenster.
• 40_actions: Mitigation-Schritte, Outcomes, Validierung, Rollback/Guardrails.

Phase 8: Recovery und Validierung – wann ist „wiederhergestellt“ wirklich stabil?

Nach dem physischen Fix ist der Incident nicht automatisch beendet. Häufig folgen Recovery-Wellen: Sessions bauen sich neu auf, DNS-Caches laufen aus, Traffic kehrt zurück, und Schutzpfade werden zurückgebaut. Ein Runbook muss daher klare Validierung und ein Stabilitätsfenster definieren.

Validierungskriterien (Minimum)

• L1: Rx/Tx dBm im erwarteten Band, keine neuen LOS/LOF Events, keine auffälligen Error-Trends.
• L2: Queue Drops normalisieren, Utilization/ECMP-Balance erwartungskonform.
• L3: Konvergenz abgeschlossen, keine Adjacency-Flaps/Churn-Spikes.
• Service Lens: Timeout-Rate/P99/Session-Success in betroffener Region stabil.

Stabilitätsfenster als Gate (MathML)

$\mathrm{Stable}\Leftarrow \mathrm{DropRate}\approx \mathrm{Baseline}\wedge \mathrm{RoutingChurn}\approx \mathrm{Baseline}\wedge \mathrm{ServiceSLI}\ge \mathrm{Target}$

• Empfehlung: mindestens 30 Minuten Stabilität vor Cleanup (TE/QoS temporäre Regeln zurückbauen).
• Bei SEV1: 60–120 Minuten Monitoring kann sinnvoll sein, insbesondere bei großen Traffic-Shifts.

Phase 9: Cleanup und Sign-off – Second Outage vermeiden

Viele Teams machen den Fehler, nach dem Fix sofort „alles zurückzudrehen“. Gerade nach Fiber Cuts ist das riskant: Traffic kehrt zurück, aber Schutzpfade oder Policies sind noch in Übergangszuständen. Cleanup sollte deshalb staged erfolgen.

• Cleanup staged: pro Fault Domain ein Schritt, dann Mini-Post-Check (Drops, Churn, Reachability).
• Rollback bereit: pro Cleanup-Schritt definieren, wie man zurückgeht.
• Sign-off: nur wenn Stabilitätsfenster erfüllt und Evidence Pack abgeschlossen ist.

Typische Fehler beim Fiber-Cut-Handling und Gegenmaßnahmen

• Zu spätes Dispatch: Warten auf „perfekte Daten“ → Minimal Evidence Set reicht für frühe Beauftragung.
• Folgealarme dominieren: Routing-/Service-Symptome werden als eigene Ursache behandelt → confirmed L1 als Master-Incident führen.
• Schutzpfad überlastet: Congestion erzeugt Second Outage → Headroom prüfen, staged Traffic-Shift, DropRate-Guardrails.
• Unklare Zeitbasis: lokale Zeiten statt UTC → konsequent UTC in Timeline und Eskalation.
• Kein Evidence Pack: Carrier/Vendor fragt nach → Evidence Pack Template verpflichtend machen.

Outbound-Ressourcen

• ITU-T G.652 (Single-mode optical fibre and cable)
• IEEE 802.3 (Ethernet Standards und optische PHY-Kontexte)
• PagerDuty Incident Response (Rollen und Abläufe)
• Atlassian: Incident Communication (Update-Disziplin)
• Cisco: Transceiver- und Optik-Guides (DOM, Betrieb, Troubleshooting)

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.