Runbook-Template für Backbone-Outages (einsatzbereit fürs NOC)

Ein Runbook-Template für Backbone-Outages ist im NOC die schnellste Möglichkeit, aus Alarmflut und Kundenimpact eine strukturierte, reproduzierbare Incident-Bearbeitung zu machen. Backbone-Störungen wirken selten „sauber“: Ein einzelner DWDM-Span degradiert, ein IGP konvergiert zu langsam, BGP churnt, ein PE/PN-Cluster wird CPU-satt oder ein Traffic-Shift überlastet ein Interconnect – und plötzlich melden Kunden „Internet down“, während einzelne Dienste noch funktionieren. Genau deshalb braucht ein einsatzbereites NOC-Runbook nicht nur technische Prüfschritte, sondern auch klare Rollen, eine zentrale Lagequelle, feste Validierungssignale und eine evidenzbasierte Dokumentation. Dieses Template ist so aufgebaut, dass es im Ernstfall sofort kopiert und ausgefüllt werden kann: Es beginnt mit den ersten 5 Minuten (Scope und Stabilisierung), führt über OSI-/Layer-orientierte Triage, leitet zu typischen Backbone-Ursachen (Optik, MPLS/TE, IGP/BGP, Congestion, Peering/Transit) und endet mit „Done“-Kriterien, Kommunikationsbausteinen sowie einer Ordnerstruktur für ein Evidence Pack. Technische Grundlagen zum OSI-Modell finden sich etwa in ISO/IEC 7498-1 und in einer zugänglichen Einführung wie Cloudflare Learning zum OSI-Modell.

Zweck und Einsatzbereich

• Ziel: Schnellstmögliche Stabilisierung, klare Ursachenhypothese, koordinierte Mitigation, saubere Validierung und dokumentierte Timeline.
• Gilt für: IP/MPLS-Backbone, Metro/Core, Peering/Transit, Backbone-nahe Service-Edges (Anycast/DNS, CGNAT-Edges, BRAS/BNG-Backbone-Anbindung, Mobile Backhaul/Core-Transport).
• Nicht im Fokus: reine Access-Outages (FTTH/DSL/DOCSIS/RAN) – außer wenn klar backboneinduziert.

Rollen und Verantwortlichkeiten im NOC-Incident

• Incident Commander (IC): Priorisierung, Entscheidungen, Eskalationen, „Stop/Go“ für Changes, hält Lagebild stabil.
• Operations Lead (Ops): technische Triage und Mitigation-Koordination (Routing/Transport/Optik).
• Scribe: pflegt Single Source of Truth (SSoT), Timeline, Maßnahmen, Evidenzlinks.
• Communications Lead (Comms): interne/externe Updates, Statuspage, Stakeholder, Support-Alignment.
• Domain Experts: Optical/DWDM, MPLS/TE, Routing, Peering, Security/DDoS, Plattformdienste.

Single Source of Truth und Kommunikationskanäle

• SSoT-Ort: Incident-Dokument oder Ticket + dedizierter Incident-Chat/Bridge. SSoT-Link anpinnen.
• Update-Takt: intern alle 10–15 Minuten, extern (falls notwendig) alle 15–30 Minuten.
• Regel: Nur bestätigte Fakten in externe Updates. Hypothesen klar als „suspected“ markieren.
• Störungsstatus: Investigating / Mitigating / Monitoring / Resolved.

Incident-Metadaten (zum Ausfüllen)

• Incident-ID:
• Startzeit (UTC):
• Erkennungszeit (UTC):
• Severity: SEV1 / SEV2 / SEV3
• Scope: betroffene POPs/Regionen, Transportsegmente, Dienste (Internet, L3VPN, Mobile, Voice, Enterprise)
• Impact: % betroffene Sessions/Traffic, SLA-Impact, Top-Kundensegmente
• Hypothese (kurz):
• Letzte relevante Changes: Deploy/Config/Policy/Traffic-Engineering

Die ersten 5 Minuten: Stabilität und Scope

• Scope klären: Welche POPs/Regionen? Welche Dienste? Welche Richtung (East-West/Core vs. North-South/Peering)?
• Kernindikatoren öffnen: Backbone-KPIs (Interface Utilization, Drops, Optical Health, IGP/BGP Events, MPLS LSP State).
• „Blast Radius“ festlegen: Ist das Problem lokal (ein Ring/PoP) oder global (mehrere POPs/Peering)?
• SSoT anlegen: Incident-Doc mit Zeitfenster, Links, bestätigte Symptome.
• Freeze-Regel: Keine zusätzlichen Änderungen außerhalb der Mitigation ohne IC-Freigabe.

Datenerhebung: Evidence-Checkliste für Backbone-Outages

• Layer 1 (Optik/Physik): LOS/LOF, Rx/Tx Power, BER/FEC, Temperatur/PSU, Link-Flaps, Timing/Sync (falls relevant).
• Layer 2 (Transport): LACP/Bundle Health, MTU, MPLS LSP/TE, Pseudowires, Queue Drops (Device), Qdisc Drops (falls hostnah).
• Layer 3 (Routing): IGP Adjacencies, SPF/Convergence, BGP Sessions, Route Churn, Prefix-Limits, Policy/Filter Events.
• Layer 4 (Transportverhalten): Retransmissions/Timeouts (wo messbar), SYN-Retries, NAT/Session Table Pressure (falls CGNAT/Edges betroffen).
• Layer 7 (Service-Impact): DNS-Timeouts, Auth/AAA-Failure Rate, VoIP/IMS-Registrierungen, Mobile Attach/Session Setup Zeiten.
• Traffic-Shift: ungewöhnliche Lastverteilung, Hot Links, ECMP Imbalance, Peering Saturation.

Analyse-Methode: Layer-orientierte Triage im Backbone

Backbone-Outages sind häufig Root-Cause-lastig in unteren Schichten, mit Symptomen in höheren Schichten. Arbeiten Sie von „niedrigster plausibler Schicht“ nach oben und dokumentieren Sie pro Layer: Signal, Beweis, Ausschluss/Bestätigung, nächste Aktion.

Layer 1 Triage: Optik, Power, Timing

• Signal: Häufung von LOS/LOF oder BER/FEC-Anstieg entlang eines Spans/Rings.
• Checks: Rx Power Abweichungen, Fehlerzähler-Trends, Flap-Korrelation, Redundanzpfade aktiv?
• Mitigation: Protection Switching/Failover, Reroute auf alternativen Span, Kapazität umverteilen.
• Validierung: Fehlerzähler sinken, Flaps stoppen, Drops normalisieren, Routing stabilisiert sich.

Layer 2 Triage: MPLS/TE, LACP, MTU, Congestion

• Signal: LSP down, TE-Reoptimierungen, Bundle-Member-Down, Queue Drops, MTU-bedingte Drops.
• Checks: LACP-Status, Member-Utilization, LSP-Protection-Events, MTU-End-to-End (besonders bei L2VPN/EVPN/PW).
• Mitigation: TE-Reroute, Bandbreitenlimits/QoS anpassen, Traffic-Shifts kontrollieren, MTU-Fix rückrollen.
• Validierung: Queue Drops und Congestion Events fallen, LSP stabil, Latenzperzentile sinken.

Layer 3 Triage: IGP/BGP, Policy, Anycast

• Signal: IGP adjacency flaps, SPF-Stürme, BGP churn, Prefix-Limit/Policy-Fehler, Reachability selektiv.
• Checks: Konvergenzzeit, Route Withdraw/Announce Peaks, betroffene Präfixe, Next-Hop-Erreichbarkeit, RPKI/Filter-Änderungen (je nach Betrieb).
• Mitigation: problematische Policy rückgängig, Dampening/Rate-Limits kontrolliert, Traffic Engineering stabilisieren, fehlerhafte Announcements zurückziehen.
• Validierung: Churn sinkt, Reachability stabil, Path-Selection konsistent, Incident-Impact sinkt.

Für Protokollreferenzen und Standards ist die Übersicht der IETF Standards hilfreich, insbesondere wenn Policy- oder Konvergenzfragen präzise begründet werden müssen.

Layer 4 Triage: Retransmits, Timeouts, Session-Pressure

• Signal: Retransmissions steigen, Timeouts häufen sich, SYN-Retries nehmen zu, Sessions resetten.
• Checks: Korrelation zu Drops/Queueing, RTT-Peaks, NAT/Session Tables (falls Edge relevant), asymmetrische Pfade.
• Mitigation: Congestion reduzieren (Reroute/QoS), Session-Table entlasten (Traffic Dämpfung), gezielte Rate-Limits gegen Retry-Stürme.
• Validierung: Retransmits/Timeouts fallen, End-to-End-Erfolg steigt.

Konkrete Diagnosepfade für typische Backbone-Outage-Muster

Muster A: Regionale Störung in einem Ring/PoP

• Priorität: Layer 1–2 zuerst (Optik/Power, LSP/Bundle, Congestion).
• Beweisführung: Link-/Optik-Degradation korreliert zeitlich mit Kundenimpact.
• Mitigation-Fokus: Protection Switching, TE-Reroute, Kapazitätshilfe aus Nachbar-POPs.

Muster B: Selektiver Reachability-Ausfall (bestimmte Präfixe/Destinationen)

• Priorität: Layer 3 (BGP/Policy/Peering) zuerst.
• Beweisführung: Präfixlisten, Withdraws, Policy-Changes, Anycast-Announcements prüfen.
• Mitigation-Fokus: Filter/RPKI/Policy rollback, Peering-Pfad wechseln, kontrolliertes Announcement-Tuning.

Muster C: Breite Latenzspitzen ohne komplette Ausfälle

• Priorität: Congestion/Queueing (Layer 2) und Transportindikatoren (Layer 4).
• Beweisführung: Queue Drops, Utilization Peaks, ECMP Imbalance, Retransmits, P99-Latenz.
• Mitigation-Fokus: Traffic Engineering, QoS, Capacity Shift, Dämpfung von Retries.

Muster D: „Alles wirkt flappy“ (Instabilität, wechselnder Impact)

• Priorität: Control-Plane Stabilität (Layer 3) plus darunterliegende Linkqualität (Layer 1–2) parallel.
• Beweisführung: Routing-Prozess-CPU, CoPP/Policing, IGP/BGP Event-Raten, Link-Flap-Korrelation.
• Mitigation-Fokus: Flapping-Quelle isolieren, Policy/Rate-Limits stabilisieren, fehlerhafte Komponenten aus dem Pfad nehmen.

Mess- und Validierungsformeln (für konsistente Reports)

Um Fortschritt objektiv zu messen, sind einfache Quoten hilfreich. Nutzen Sie konsistente Definitionen in SSoT und Updates.

Drop Rate

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

Restoration-Ziel: „Impact Rate“

$\mathrm{ImpactRate}=\frac{\mathrm{impacted\_sessions\_or\_requests}}{\mathrm{total\_sessions\_or\_requests}}$

Wählen Sie als Zähler je nach Dienst (Internet, VPN, Mobile, Voice) eine passende, stabil messbare Größe (Sessions, Registrierungen, Requests, Throughput-Defizit).

Mitigation-Katalog: sichere Standardmaßnahmen im Backbone

Die folgenden Maßnahmen sind als Katalog zu verstehen. Jede Maßnahme wird nur mit IC-Freigabe, klarer Hypothese und Validierungsmetriken durchgeführt.

• Traffic Engineering: TE-Reroute, IGP-Metric-Shift, LocalPref/Exit-Adjustment, Anycast-Announcement-Tuning.
• Capacity Shift: Last von Hot Links weg verteilen, zusätzliche Links/Ports aktivieren, Bundle-Health wiederherstellen.
• QoS/Queueing: Schutz kritischer Klassen (Control-Plane, Voice), Anpassung von Policing/Shaping (vorsichtig).
• Protection Switching: Optical/Transport Protection aktivieren, defekten Span isolieren.
• Policy Rollback: Prefix-Filter, RPKI/Validation-Policy, Route-Maps, Communities zurückrollen.
• DDoS/Abuse-Controls: Scrubbing, RTBH/Flowspec (nur mit Security/Abuse Team), Rate-Limits zur Stabilisierung.

Kommunikation: Update-Template für NOC und Stakeholder

• Status: Investigating / Mitigating / Monitoring
• Impact: Region/POPs, Dienste, geschätzter Anteil betroffen
• Bestätigte Fakten: 2–3 Bulletpoints (z. B. „Queue drops auf Link X“, „BGP churn in POP Y“)
• Maßnahmen: was wird gerade getan, mit welchem Ziel
• Nächste Validierung: welche Metrik zeigt Erfolg (z. B. Drops↓, Churn↓, Success↑)
• Nächstes Update: Zeitpunkt

Done-Kriterien: Wann gilt der Backbone als stabilisiert?

• Routing stabil: IGP/BGP Eventraten normalisiert, keine anhaltenden Flaps/Churn.
• Transport stabil: keine ungewöhnlichen Queue Drops, Utilization im erwarteten Bereich, Protection aktiv/korrekt.
• Service-Impact sinkt: ImpactRate fällt unter definierten Schwellenwert und bleibt stabil (mind. 15–30 Minuten).
• Kein versteckter Tail: Latenzperzentile (P95/P99) stabilisieren sich, Timeouts sinken.
• Kommunikation konsistent: interne/externe Statusmeldungen spiegeln denselben Faktenstand.

Evidence Pack: Ordnerstruktur für Backbone-Outages

• INC-YYYYMMDD-HHMM-SEVx-backbone/
  • 00_meta/
    • incident_summary.html
    • scope_impact.html
    • roles_contacts.html
    • timeline.html
  • 10_layer1_optical/
    • optical_power_ber_fec.html
    • link_flaps.html
    • power_temperature.html
  • 20_layer2_transport/
    • mpls_lsp_te_state.html
    • bundle_lacp_health.html
    • queue_drops_congestion.html
    • mtu_encap_checks.html
  • 30_layer3_routing/
    • igp_adjacency_spf.html
    • bgp_sessions_churn.html
    • prefix_policy_events.html
    • reachability_matrix.html
  • 40_layer4_transport_behavior/
    • retransmissions_timeouts.html
    • session_table_pressure.html
  • 50_services_impact/
    • customer_impact_metrics.html
    • dns_aaa_service_slis.html
  • 60_actions_changes/
    • mitigation_log.html
    • change_events.html
    • validation_checks.html
  • 70_comms/
    • internal_updates.html
    • external_updates.html
  • 90_post_incident/
    • preliminary_rca.html
    • followups_actions.html

Post-Incident: Welche Kennzahlen und Fragen sofort ergänzt werden sollten

• Detection Gap: Welche Metrik hätte früher alarmiert (z. B. Churn-Rate, FEC-Error-Rate, Queue Drops)?
• Diagnosis Gap: Welche Segmentierung fehlte (PoP, Ring, Linkgruppe, Präfixfamilie)?
• Mitigation Wirksamkeit: Welche Maßnahme wirkte, welche nicht, und welches Validierungssignal war eindeutig?
• Change Governance: Waren relevante Policy/Config-Änderungen sauber sichtbar und korrelierbar?
• Runbook-Update: Welche Checkliste war zu lang/zu kurz? Welche Links/Queries müssen standardisiert werden?

Weiterführende Quellen für NOC-Runbooks

• ISO/IEC 7498-1 (OSI Reference Model)
• OSI-Modell (Cloudflare Learning)
• IETF Standards (Routing, Transport, DNS)
• RFC 1035 (DNS Grundlagen)
• RFC 8914 (Extended DNS Errors)

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.