Blast Radius bei ISP-Outages bestimmen mit Fault Domains (praxisnah)

Den Blast Radius bei ISP-Outages bestimmen ist im NOC eine der wichtigsten Aufgaben der ersten Minuten: Erst wenn klar ist, wer und wie breit betroffen ist, lassen sich Triage, Mitigation und Kommunikation sauber priorisieren. „Fault Domains“ sind dafür ein praxistaugliches Konzept: Sie beschreiben technische Ausfall-Domänen, in denen ein einzelner Fehler (oder eine gemeinsame Ursache) mehrere Kunden, POPs, Dienste oder Netzelemente gleichzeitig beeinträchtigen kann. In Provider- und Telco-Netzen sind das nicht nur geografische Bereiche, sondern auch Transport-Ringe, DWDM-Spans, Aggregationsknoten, Peering-Fabrics, Routing-Domänen, Strom- und Timing-Domänen oder sogar Konfigurationsdomänen (gleiche Policy, gleiche Software-Version, gleicher Vendor-Stack). Wer Fault Domains im Betrieb konsequent modelliert und im Outage nutzt, kann den Blast Radius in Minuten quantifizieren: Welche Access-Regionen hängen an welchen Aggregationspunkten? Welche Präfixe werden über welche POPs angekündigt? Welche Kunden sind an einem bestimmten Ring oder BNG/CGNAT-Cluster terminiert? Und welche Abhängigkeiten (DNS, AAA, Mobile Core, IMS) teilen sich dieselbe Domain? Dieser Artikel zeigt praxisnah, wie Sie Fault Domains definieren, Daten konsolidieren und daraus eine belastbare Blast-Radius-Schätzung ableiten – inklusive Checklisten, Kennzahlen und typischen Fehlerquellen.

Begriffe klarziehen: Blast Radius und Fault Domain

Blast Radius ist die Menge an betroffenen Nutzern, Diensten und Netzbereichen, die durch einen Vorfall beeinträchtigt werden. Er ist keine rein technische Größe, sondern eine Kombination aus technischer Ausbreitung und Kundenimpact. Fault Domains sind die „Kachelstruktur“, mit der Sie diese Ausbreitung beschreiben: Jede Domain gruppiert Komponenten, die eine gemeinsame Fehlerursache teilen können oder deren Ausfall sich gemeinsam manifestiert.

• Blast Radius: „Wie groß ist der Schaden?“ – z. B. % Sessions betroffen, # POPs, # Regionen, # Kundensegmente.
• Fault Domain: „Wo kann ein einzelner Fehler gleichzeitig zuschlagen?“ – z. B. Ring, PoP, Peering-Fabric, IGP-Area, AAA-Cluster.

Wichtig ist die Trennung: Fault Domains sind ein Modell; der Blast Radius ist die aktuelle Realität. Im Outage vergleichen Sie beides: Passt der beobachtete Impact zu einer bestimmten Fault Domain? Wenn ja, ist das eine starke Root-Cause-Spur.

Warum Fault Domains im ISP-Outage besser funktionieren als „Regionen“

Viele Organisationen versuchen Blast Radius über Geografie abzuleiten („Region Süd“). Das ist oft zu grob oder schlicht falsch, weil Netztopologien sich nicht strikt an Regionen halten. Access-Regionen können an entfernten Aggregations-POPs terminiert sein, internationale Transitpfade beeinflussen lokale Nutzer, und ein Peering-Problem wirkt nur für bestimmte Ziele. Fault Domains sind deshalb präziser, weil sie die wirklichen gemeinsamen Abhängigkeiten abbilden:

• Topologie statt Karte: Welche Kunden hängen technisch an welchem Aggregationsknoten?
• Pfadabhängigkeit: Welche Destinationen gehen über welches Peering/Transit?
• Geteilte Ressourcen: Strom, Timing/Sync, Software-Versionen, Policy-Templates.

Die wichtigsten Fault Domain-Typen im ISP/Telco-Betrieb

Damit Blast-Radius-Bestimmung schnell wird, sollten Fault Domains in Kategorien organisiert sein. In der Praxis haben sich folgende Typen bewährt.

Physische Fault Domains

• DWDM-Span / Glasfasertrasse: gemeinsame physische Strecke, gemeinsame Bauarbeiten-Risiken.
• Optical Ring: Ringdomäne mit Protection Switching und Kapazitätsgrenzen.
• PoP-Stromdomäne: gemeinsame USV/Generator/PSU-Ketten, Klimatisierung.
• Timing/Sync-Domäne: PTP/SyncE-Verteilung, besonders relevant für Mobile Backhaul/5G.

Layer-2/Transport Fault Domains

• MPLS-TE Domäne: LSP-Set, Shared Risk Link Groups (SRLG) oder gemeinsame TE-Constraints.
• Aggregation-Fabric: Carrier Ethernet/EVPN-Fabric, gemeinsame Linecards, gemeinsame Queues.
• MTU/Encapsulation Domäne: gemeinsam konfigurierte MTU, Tunnel-Overhead, einheitliche Encapsulation-Policies.

Routing und Control-Plane Fault Domains

• IGP-Area/Domain: OSPF/IS-IS Bereiche, gemeinsame SPF-Last und Konvergenzverhalten.
• BGP Route Reflector Cluster: RR-Group als gemeinsame Steuerebene.
• Anycast-Announcement Domäne: DNS/CDN/Edge-Anycast pro POP-Set.
• Control-Plane-Policing (CoPP) Policy: gemeinsame Schutzprofile können bei Last gleichzeitig limitieren.

Service- und Plattform Fault Domains

• DNS Resolver/Authoritative Cluster: gemeinsame Resolver-Infrastruktur, Anycast-Node-Set.
• AAA/Policy Cluster: RADIUS/DIAMETER, PCRF/PCF, Policy-Engines.
• CGNAT/BNG-Cluster: gemeinsame Session-States, NAT-Pools, per-Cluster Capacity.
• IMS/SBC Domäne: VoIP/IMS-Registrierung, RTP-Medienpfade, Session-Control-Knoten.

Konfigurations- und Change Fault Domains

• Template-/Automation-Domäne: ein Playbook/Rollout betrifft viele Geräte gleichzeitig.
• Software-Version / Vendor-Stack: gleicher Bug oder gleiches Verhalten in einer Flotte.
• Policy-Domäne: gemeinsame Filter/Route-Maps, RPKI-Policy, QoS-Profile.

Die Kernidee im Outage: „Welche Domain erklärt den Impact am besten?“

In den ersten Minuten brauchen Sie ein schnelles Verfahren, um beobachtete Symptome auf eine plausible Fault Domain abzubilden. Das funktioniert am besten als iterative Eingrenzung: Sie starten breit (z. B. „PoP Nord“), dann schneiden Sie entlang von Domains (Ring, RR-Cluster, Peering, Service-Cluster), bis eine Domain „maximal erklärt“ und gleichzeitig „minimal unnötig“ ist.

Minimalerklärungs-Prinzip

• Maximiert Abdeckung: Die Domain erklärt einen großen Teil der betroffenen Signale.
• Minimiert Zusatzannahmen: Sie brauchen nicht mehrere unabhängige Ursachen, um das Muster zu erklären.

Datengrundlagen: Welche Quellen Sie für Blast Radius brauchen

Blast Radius wird schnell und belastbar, wenn Sie die richtigen Datenquellen standardisieren. Wichtig ist, dass Sie nicht „alles“ brauchen, sondern wenige Schlüsselzuordnungen zwischen Kunden, Netz und Fault Domains.

Topologie- und Inventardaten

• Service-to-Network Mapping: Kunde/Service → Access Node/BNG/OLT/CGNAT → Aggregation → Core/PoP.
• SRLG-Informationen: Links, die dieselbe physische Trasse teilen (für optische/transportseitige Domains).
• PoP- und Ring-Modelle: welche Geräte und Links gehören zu welchem Ring/PoP.
• Peering/Transit Mapping: Präfix-/Zielgruppen → bevorzugte Exits/Peers.

Live-Signale aus dem Betrieb

• Link-/Optik-Health: Flaps, LOS/LOF, BER/FEC, Rx Power, Queue Drops.
• Routing-Events: BGP session changes, Route churn, IGP adjacency flaps.
• Service-SLIs: DNS Timeouts, AAA Failure Rate, Session Setup Times, VoIP Quality Indikatoren.
• Kundensicht: Ticket-Cluster nach Region/Access-Typ, synthetische Probes, RUM (falls vorhanden).

Praktischer Workflow: Blast Radius in 15 Minuten bestimmen

Der folgende Ablauf ist so gestaltet, dass er im NOC als Standard-Runbook eingesetzt werden kann. Er kombiniert Fault Domains mit schnellen, belastbaren Indikatoren und setzt konsequent auf Segmentierung.

Schritt 1: Impact-Signatur erfassen

• Welche Dienste sind betroffen (Internet, L3VPN, Mobile Data, Voice)?
• Welche Regionen/POPs (grob) zeigen Spike in Tickets/SLIs?
• Ist das Problem selektiv nach Destination (bestimmte Ziele) oder global?
• Welche Zeitlinie: plötzlich (Cut) vs. langsam (Degradation)?

Schritt 2: Kandidaten-Domänen aufstellen

• Physisch: Ring/Span/PoP-Power/Timing
• Transport: MPLS-TE/LSP/SRLG/Queueing
• Routing: IGP-Area/RR-Cluster/Peering
• Service: DNS/AAA/CGNAT/IMS
• Change: Template/Version/Policy-Rollout

Schritt 3: Intersection-Check („Was haben die Betroffenen gemeinsam?“)

Der stärkste Hinweis auf eine Fault Domain ist ein gemeinsamer Nenner in den betroffenen Einheiten. Das lässt sich als Schnittmenge denken: Betroffene Kunden/Services teilen eine oder wenige Domains. Formal kann man den Abdeckungsgrad einer Domain als Verhältnis ausdrücken.

$\mathrm{Coverage}\left(D\right)=\frac{\mathrm{impacted\_entities\_in\_D}}{\mathrm{total\_impacted\_entities}}$

Eine Domain mit hoher Coverage ist ein starker Root-Cause-Kandidat. Ergänzend ist die „Spill“-Quote nützlich: Wie viele Einheiten in der Domain sind nicht betroffen? Das hilft, falsche Kandidaten zu erkennen.

$\mathrm{Spill}\left(D\right)=\frac{\mathrm{non\_impacted\_entities\_in\_D}}{\mathrm{total\_entities\_in\_D}}$

Schritt 4: Domain-Hypothese gegen „Gegenbeweise“ testen

• Wenn Ring/Span schuld: sollten optische Fehler und Link-Flaps entlang der Strecke korrelieren.
• Wenn Peering schuld: sollte Impact destination-selektiv sein (bestimmte ASNs/Präfixe), nicht „alles“.
• Wenn RR-Cluster schuld: sollte Routing-Instabilität breit in der Domäne sichtbar sein (Churn, Session Flaps).
• Wenn DNS-Cluster schuld: sollten DNS-Timeouts systematisch steigen, während IP-Reachability teils noch ok ist.
• Wenn Change-Domäne schuld: sollte die Zeitlinie eng an Rollout/Policy-Change gekoppelt sein und mit Rollback korrelieren.

Schritt 5: Blast Radius quantifizieren und kommunizieren

In der Kommunikation sollte Blast Radius nicht als vage Aussage erscheinen. Nutzen Sie 2–3 Kennzahlen, die für Ihr Geschäft verständlich sind:

• Betroffene Sessions/Customers: absolute Zahl und Anteil (z. B. 12% der aktiven Sessions in Region X).
• Betroffene POPs/Access-Knoten: z. B. 3 von 14 POPs, 1 Ring, 2 Aggregationsknoten.
• Betroffene Dienste: Internet + Mobile Data betroffen, Voice stabil (oder umgekehrt).

Eine einfache Impact-Rate ist als Standard nützlich:

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

Praxisbeispiele: Fault Domains erkennen an typischen Mustern

Beispiel 1: Glasfaserdegradation in einem Metro-Ring

• Symptome: erhöhte Packet Drops/Queueing, sporadische Link-Flaps, steigende Retransmissions, regionale Ticket-Cluster.
• Fault Domain: SRLG/Optical Ring (gemeinsame Trasse).
• Blast Radius: alle Access-Aggregationen, die über diesen Ring in den Core gehen, unabhängig vom Dienst.
• Gegenbeweis: Wenn Destination-selektiv statt region-selektiv, ist Peering wahrscheinlicher.

Beispiel 2: Peering-Überlast am IX in einem PoP

• Symptome: hohe Latenz/Timeouts nur zu bestimmten ASNs, interne Dienste stabil, Traffic-Shifts auf andere Exits.
• Fault Domain: Peering-Fabric/IX-Portgruppe.
• Blast Radius: Kunden, deren Traffic bevorzugt über diesen Exit geht; oft destination-abhängig.
• Gegenbeweis: Wenn auch interne Reachability und alle Ziele betroffen sind, ist Routing/Transport wahrscheinlicher.

Beispiel 3: Route Reflector-Instabilität nach Policy-Change

• Symptome: BGP churn, wechselnde Pfade, Paketloss in Wellen, viele POPs betroffen, aber nicht zwingend alle.
• Fault Domain: RR-Cluster + Change-Domäne (gemeinsame Policy).
• Blast Radius: alle Clients/POPs, die über diesen RR-Cluster ihre Routen erhalten.
• Mitigation: Policy rollback, RR entlasten, ggf. schrittweise Re-Konvergenz.

Fehlerquellen: Warum Blast-Radius-Schätzungen oft falsch sind

• Tickets sind kein perfekter Sensor: Support-Meldungen kommen zeitverzögert und region-/kundensegment-bias.
• Aggregation maskiert Hotspots: Ein globaler Mittelwert verdeckt, dass nur ein Ring brennt.
• DNS-Caching täuscht: DNS-Probleme wirken spiky und clientabhängig; ohne synthetische Probes werden sie unterschätzt.
• Asymmetrisches Routing: Nur eine Richtung betroffen; Traceroute/MTR kann irreführend sein.
• Mehrere gleichzeitige Fault Domains: z. B. ein optischer Fehler plus ein Traffic-Shift, der einen zweiten Link überlastet.

Operationalisierung: Fault Domains als dauerhafte NOC-Fähigkeit

Fault Domains funktionieren im Outage nur dann schnell, wenn sie vorher modelliert wurden. Das ist weniger ein „großes Projekt“ als eine konsequente Standardisierung: Jede relevante Entität (Link, LSP, PoP, Cluster) bekommt Domain-Tags, und Ihre Dashboards/Tickets können danach filtern.

• Domain-Tags in Inventory: ring_id, pop_id, srlg_id, rr_cluster, peering_fabric, power_domain, timing_domain.
• Standard-Dashboards: Impact und Health immer nach Domain gruppierbar (Top-N Domains nach Drops/Churn/Timeouts).
• Evidence Pack Struktur: Ordner/Sections nach Fault-Domain-Typen, damit Postmortems schnell sind.
• GameDays: Simulationen (z. B. Ring cut, Peering down) zur Übung der Blast-Radius-Bestimmung.

Checkliste für den NOC-Einsatz

• Scope in 2 Minuten: Dienst, Region/PoP, destination-selektiv oder global.
• Kandidaten-Domänen: physisch, transport, routing, peering, service, change.
• Intersection: Welche Domain erklärt die meisten Betroffenen bei geringem Spill?
• Gegenbeweise prüfen: Gibt es Signale, die der Domain widersprechen?
• Blast Radius quantifizieren: ImpactRate + betroffene POPs/Ringe + betroffene Dienste.
• Kommunikation synchronisieren: nur bestätigte Fakten, nächstes Update timestampen.
• Mitigation validieren: „Done“-Signale je Domain (Flaps↓, Drops↓, Churn↓, Success↑).

Weiterführende Ressourcen

• ISO/IEC 7498-1 (OSI Reference Model)
• OSI-Modell erklärt (Cloudflare Learning)
• IETF Standards (Routing- und Transportreferenzen)
• 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.