Failure Scenario Workshops: Link-, Node- und Region-Ausfälle durchspielen

Failure Scenario Workshops sind eine der wirkungsvollsten Methoden, um Netzdesigns und Betriebsprozesse in Telco-Topologien wirklich belastbar zu machen. Denn viele Provider-Netze sind auf dem Papier redundant – aber erst beim gezielten Durchspielen von Link-, Node- und Region-Ausfällen zeigt sich, ob Redundanz auch in der Busy Hour funktioniert, ob Failoverpfade MTU/QoS-konform sind, ob Policies korrekt greifen und ob Observability die richtigen Signale liefert. In der Praxis sind die teuersten Incidents selten „alles ist down“. Häufiger sind partielle Degradations: ein Ringsegment ist unterbrochen, ein Edge-Router ist weg, ein IXP-Port congested nach Failover, ein Route Reflector flappt, oder eine Region verliert einen DCI-Pfad und hairpint plötzlich über Transit. Genau diese Mischformen lassen sich mit Failure Scenario Workshops strukturiert sichtbar machen – ohne echten Schaden, aber mit echtem Lerneffekt. Ein professioneller Workshop ist dabei kein Brainstorming, sondern eine systematische Übung: klare Scopes (Serviceklassen, Regionen, PoPs), definierte Failure Domains, messbare Erfolgskriterien (SLO/SLI), konkrete Szenarien, erwartetes vs. beobachtetes Verhalten, und eine Ergebnisliste, die in Design- und Betriebsänderungen übersetzt wird. Dieser Artikel zeigt, wie Sie Failure Scenario Workshops so aufsetzen und moderieren, dass Link-, Node- und Region-Ausfälle realistisch durchgespielt werden – inklusive Vorbereitung, Methodik, Messpunkten, Runbooks, Guardrails und Nachbereitung, damit Resilienz nicht nur behauptet, sondern nachweisbar wird.

Warum Failure Scenario Workshops in Telco-Netzen unverzichtbar sind

In großen Netzen ist „Resilienz“ kein einzelnes Feature, sondern ein Zusammenspiel aus Topologie, Kapazität, Routing, Policy, Services und Betrieb. Wenn eine Komponente ausfällt, übernimmt eine andere – aber nur, wenn Ersatzpfade ausreichend dimensioniert sind, wenn Konvergenzmechanismen stabil sind, wenn Service Chains nicht brechen und wenn Monitoring den Impact früh erkennt. Failure Scenario Workshops sind das strukturierte Gegenmittel zu „wir glauben, es ist redundant“.

• Vermeiden von Überraschungen: Ersatzpfade, MTU, QoS und Policy-Inkonsistenzen werden sichtbar, bevor Kunden betroffen sind.
• Validierung von N-1: Headroom in Peakzeiten und Queue-Drops im Störfall werden messbar.
• Reife im Betrieb: Runbooks, Alarmierung und Ownership werden getestet, nicht nur dokumentiert.
• Design-Feedback: Schwache Failure Domains, SRLG-Risiken und unklare Domain-Grenzen werden konkret.

Leitprinzip: Resilienz ist eine messbare Eigenschaft

Ein Workshop ist erfolgreich, wenn er messbare Aussagen liefert: Welche SLOs halten wir im Link- oder Node-Ausfall? Welche Domains sind riskant? Welche Guardrails fehlen? Das ist Evidence-by-Design.

Scope definieren: Welche Services, welche Regionen, welche Failure Domains?

Ohne klaren Scope werden Workshops zu allgemeinen Diskussionen. Telco-Topologien sind zu groß, um „alles“ gleichzeitig zu testen. Deshalb beginnt ein guter Workshop mit einer Topologie- und Serviceauswahl: welche Produktklassen (Retail Internet, Enterprise VPN, Mobile Backhaul), welche Regionen/PoPs, welche kritischen Pfade (DCI, IXP/PNI/Transit, Hub-Uplinks) und welche Service Edges (BNG, CGNAT, Firewalls).

• Service-Scope: Welche Dienste müssen im Failover stabil bleiben? Welche dürfen degradiert werden?
• Topologie-Scope: Welche Domain ist „Workshop-Target“ (PoP, Metro-Cluster, Regionpaar, Edge-Standort)?
• Failure Domains: Link, Node, Linecard, Fabric, PoP, Region, SRLG (gemeinsame Trasse/Facility).
• Erfolgskriterien: SLO/SLI (Availability, p95/p99 Latenz, Loss, Session-Stability) plus Root-Cause KPIs (Queue-Drops).

Designregel: Ein Workshop braucht eine klare „Definition of Done“

Beispielsweise: „Wir können für Region West nachweisen, dass Retail Internet im Link- und Node-Ausfall p95 Latenz < X ms und Loss < Y% bleibt und dass Failover innerhalb Z Sekunden stabil konvergiert.“

Workshop-Setup: Rollen, Moderation und Artefakte

Failure Scenario Workshops funktionieren am besten interdisziplinär. Routing- und Transportteams sehen andere Risiken als Security-, Service-Edge- oder Observability-Teams. Gleichzeitig braucht es klare Moderation, sonst verliert man sich in Details. Der Workshop sollte außerdem konkrete Artefakte erzeugen: eine Szenarioliste, erwartetes Verhalten, Messplan, Runbooks und einen Maßnahmen-Backlog.

• Teilnehmerrollen: Backbone/Core, Metro, Edge/Interconnect, Service Edge (BNG/CGNAT), Security, Observability, NOC.
• Moderator: Hält Scope, Zeit und Ergebnisorientierung; trennt Hypothesen von Fakten.
• Artefakte: Topologie-Skizze, Failure-Domain-Karte, KPI-Dashboard-Liste, Runbook-Checklisten.
• Entscheider: Jemand, der Prioritäten setzen kann, damit Findings nicht im Nirwana enden.

Anti-Pattern: Workshop ohne Maßnahmen-Owner

Wenn Findings nicht in Tickets/Backlog mit Ownership und Fristen überführt werden, bleibt der Workshop ein theoretischer Erfolg ohne betriebliche Wirkung.

Szenarienkatalog: Link-, Node- und Region-Ausfälle strukturiert aufbauen

Ein guter Szenarienkatalog steigt in Komplexität. Zuerst einfache Link-Ausfälle, dann Node-Ausfälle, dann kombinierte und regionale Szenarien. Dabei ist wichtig, nicht nur „hard down“ zu testen, sondern auch „soft failures“: Congestion, erhöhte Errors, partielle Blackholes, asymmetrische Pfade. Diese Fälle sind in der Realität häufig und schwerer zu erkennen.

• Link-Ausfall: Uplink down, LAG-Member down, Ringsegment cut, IXP-Port down.
• Node-Ausfall: Edge-Router down, Metro-Hub down, BNG/CGNAT-Knoten down, RR-Knoten down.
• Region-Ausfall: PoP-Cluster offline, DCI-Regionpaar down, Region isoliert (no DCI, nur Transit).
• Soft Failures: Congestion, MTU-Blackhole, Optical Degradation, BGP Route Leak/Prefix Explosion.

Designregel: Jedes Szenario braucht einen erwarteten Pfad

Bevor man testet, muss klar sein, welcher Pfad im Failover genutzt werden soll. Sonst ist die Bewertung „richtig/falsch“ unmöglich. Erwartete Pfade sind Teil des Designs, nicht nur der Beobachtung.

Link-Ausfälle durchspielen: Ringe, ECMP, LAG und Interconnect-Ports

Link-Ausfälle sind die häufigsten realen Events. In Telco-Netzen treten sie in vielen Formen auf: Faserschaden, LAG-Member-Defekt, IXP-Port-Problem, DCI-Link-Degradation. Workshops sollten daher Link-Szenarien in verschiedenen Linkklassen testen: Access-Uplinks, Metro-Uplinks, DCI, IXP/PNI/Transit. Ziel ist, zu prüfen, ob Konvergenz schnell genug ist und ob Ersatzpfade kapazitiv und policyseitig passen.

• Ring Cut: Prüfen, ob Traffic gleichmäßig um den Ring verteilt wird oder ob ein Segment überlastet.
• LAG-Member Down: Prüfen, ob Hashing Hotspots erzeugt und ob Member-Telemetry dies sichtbar macht.
• IXP-Port Down: Prüfen, ob Transit-Fallback greift und ob Transit-Ports N-1 tragen.
• DCI-Link Down: Prüfen, ob Cross-Region-SLOs degradieren und ob das Verhalten erwartet ist.

Messpunkte für Link-Szenarien

• Data Plane: Probe Success, p95/p99 RTT, Loss/Jitter entlang betroffener Pfadklassen.
• Engpasssignale: Queue-Drops pro Klasse, Portauslastung, Microburst-Indikatoren.
• Routing: FRR-Aktivierungen, IGP/BGP Events, Konvergenzzeiten.

Node-Ausfälle durchspielen: Edge-Router, Hubs, Service-Edges und RR

Node-Ausfälle sind seltener, aber teurer. Ein Edge-Router-Ausfall kann eine ganze Region beeinflussen, ein Metro-Hub-Ausfall kann viele Access-Ringe abklemmen, und ein Service-Edge-Ausfall kann Session-Churn erzeugen. Workshops sollten Node-Failures deshalb immer mit Failure Domain Denken kombinieren: Was passiert, wenn ein gesamter Knoten verschwindet? Welche Teile sind redundant? Welche nicht?

• Edge-Router Down: Prüfen, ob Peering/Transit-Pfade sauber auf den zweiten Edge kippen und ob Policies konsistent bleiben.
• Metro-Hub Down: Prüfen, ob Access-Standorte alternative Hubs haben oder ob eine große Insel entsteht.
• BNG/CGNAT Node Down: Prüfen, ob Sessions migrieren oder neu aufgebaut werden; CPS/State Peaks und Logging-Backpressure beobachten.
• RR Node Down: Prüfen, ob iBGP stabil bleibt, ob Prefixe konsistent bleiben, ob Control Plane Churn entsteht.

Designregel: Stateful Nodes brauchen eigene Kriterien

Bei BNG/CGNAT/Firewalls ist „Traffic fließt“ nicht genug. Sie müssen Session-Stabilität, Reconnect-Wellen, CPS-Limits, Drop-Reasons und Symmetrie prüfen.

Region-Ausfälle durchspielen: Isolation, DCI-Loss und Multi-Region Failover

Region-Ausfälle sind die Königsdisziplin. Sie betreffen nicht nur Links oder Router, sondern ganze Failure Domains: Facility-Ausfall, regionale Strom-/Transportstörung, DCI-Isolation oder ein großflächiges Routing-Problem. Region-Scenarios sollten daher die Frage beantworten: Welche Services müssen regional weiterlaufen, welche dürfen auf andere Regionen failovern, und wie wird dabei Latenz, Kapazität und Policy kontrolliert?

• Region isoliert (kein DCI): Prüfen, ob Internet-Exit regional funktioniert und ob Enterprise VPNs definierte Fallbacks haben.
• Region failover zu Region B: Prüfen, ob DCI und Interconnect-Headroom reichen und ob SLOs noch eingehalten werden.
• Interconnect-Ausfall in Region: Prüfen, ob Transit/andere Region übernehmen kann, ohne Hairpinning-Kollaps.
• Control-Plane Partition: Prüfen, ob RR/Controller-Ausfälle zu Split-Brain oder Route Inconsistency führen.

Ein praktisches Latenzbudget im Region-Failover

$\mathrm{Latency\_budget\_failover}=\mathrm{Latency\_normal}+\mathrm{\Delta \_path}+\mathrm{\Delta \_queue}$

Im Region-Failover steigt Latenz durch längere Pfade (Δ_path) und durch zusätzliche Queueing-Effekte (Δ_queue) an Engpässen. Workshops sollten beide Anteile messbar machen.

Vorbereitung: Checklisten, Dashboards und „Expected Behavior“ dokumentieren

Ein Workshop wird erst effizient, wenn Vorbereitung stimmt. Dazu gehören: aktuelle Topologie-Dokumente, ein Servicepfadmodell, definierte KPIs, funktionierende Probes, und eine klare Liste erwarteter Pfade und Policies. Der häufigste Zeitfresser in Workshops ist „wir wissen gerade nicht, wie es eigentlich sein sollte“.

• Topologie-Map: Rollen, Linkklassen, Redundanzpaare, SRLG-Gruppen, Interconnect-Standorte.
• Expected Paths: Normalpfad und Failoverpfad pro Szenario, inklusive Policy-Mechanik.
• Dashboards: SLO/SLI (Availability/Latenz/Loss), Queue/Port, Routing Health, Service KPIs.
• Kommunikation: Wer führt Tests aus? Wer beobachtet? Wer entscheidet über Stop/Rollback?

Designregel: Ohne Telemetry ist ein Workshop Spekulation

Wenn Queue-Drops, Path-KPIs oder Routing-Events nicht sichtbar sind, wird jede Diskussion zu Meinungen. Stellen Sie Observability vor dem Workshop sicher.

Durchführung: Tabletop, Simulation und kontrollierte Live-Tests

Failure Scenario Workshops können in drei Intensitäten laufen. Tabletop-Übungen sind schnell und sicher, decken aber keine technischen Überraschungen auf. Simulationen (z. B. Traffic- oder Pfadmodellierung) geben quantitative Hinweise. Kontrollierte Live-Tests (z. B. geplanter Drain, Link-Shut, BGP-Policy-Flip) liefern die höchste Realität, erfordern aber Guardrails und Change-Governance.

• Tabletop: Szenario durchsprechen, Pfade/Policies verifizieren, Runbooks und Ownership testen.
• Simulation: Kapazitäts- und Pfadmodelle, N-1 Auswirkungen, Interconnect-Fallback analysieren.
• Live-Test: Geplante Drains, Link-Shuts, controlled failover; SLO-Gates und Rollback-Kriterien zwingend.

Best Practice: Beginnen Sie tabletop, enden Sie mit einem kleinen Live-Test

Viele Teams gewinnen am meisten, wenn sie erst das Verständnis schärfen und dann einen begrenzten Canary-Test machen. So bleibt Risiko klein und der Lernwert hoch.

Auswertung: „Expected vs. Observed“ und Maßnahmen ableiten

Der wichtigste Teil ist die Auswertung. Jeder Workshop sollte pro Szenario festhalten: Was war erwartet? Was ist passiert? Welche SLOs wurden verletzt? Welche Root-Cause-Signale traten auf? Daraus entsteht ein Maßnahmenkatalog, der sowohl technische Änderungen (Topologie, Policies, Kapazität) als auch betriebliche Änderungen (Runbooks, Alerting, Ownership) enthält.

• Drift finden: Unterschied zwischen Designabsicht und realem Verhalten identifizieren.
• Engpässe priorisieren: Queue-Drops und p99-Latenz-Spikes an Choke Points als Upgrade-Trigger nutzen.
• Guardrails ergänzen: Max-Prefix, Hysterese, Drain-Checks, Change-Gates, SLO-First Alerting.
• Runbooks verbessern: Konkrete Schritte, klare Stop/Go Kriterien, Rollback, Eskalationswege.

Evidence-by-Design: Workshop-Ergebnisse müssen auditierbar sein

Dokumentieren Sie Messwerte, Zeitstempel, Pfadwechsel, Alerts und Entscheidungen. Das verbessert spätere Workshops und schafft eine belastbare Resilienz-Historie.

Typische Erkenntnisse aus Failure Workshops

• N-1 reicht nicht in Peak: Ersatzpfad congestioniert, Queue-Drops steigen → Headroom/Upgrade/QoS anpassen.
• MTU/PMTUD bricht im Failover: Selektive Blackholes → MTU-Profile harmonisieren, PMTUD-Strategie definieren.
• Interconnect-Fallback unklar: Transit-Spike ohne Kapazität → Edge-Portklassen und Policies anpassen.
• ECMP Imbalance: Einzelne Member überlasten → Hashing/Member-Visibility/Drain-Prozess verbessern.
• Stateful Services reagieren empfindlich: Session-Churn, CPS Peaks → Service-Cluster N+1, State-Handling, Logging-Headroom.
• Alerting ist zu laut: Pager-Sturm bei Failover → SLO-first, topologische Korrelation, Change-Awareness.

Praktische Leitlinien: Failure Scenario Workshops erfolgreich durchführen

• Scope klein starten: Eine Region oder ein PoP-Cluster, eine Serviceklasse, klare Failure Domains.
• Szenarien staffeln: Link → Node → Region, plus ausgewählte Soft-Failures (Congestion, MTU, Policy).
• Expected Behavior dokumentieren: Failoverpfade, Policies, Kapazitätsannahmen vorab festlegen.
• SLIs/SLOs definieren: Availability, p95/p99 Latenz, Loss, Queue-Drops, Routing Health, Session KPIs.
• Messbarkeit sicherstellen: Probes, Queue-Telemetry, Routing-Events, Flow-/Interconnect-Mix; Labels (Region/PoP/Linkklasse).
• Live-Tests canaryen: Kleine, kontrollierte Tests mit Go/No-Go Gates und Rollback-Kriterien.
• Expected vs. Observed auswerten: Drift, Engpässe, Guardrails und Runbook-Lücken in Maßnahmen überführen.
• Ownership und Fristen: Findings in Backlog mit Verantwortlichen und Priorität; sonst verpufft der Effekt.
• Regelmäßig wiederholen: Nach größeren Topologie- oder Policy-Änderungen und mindestens pro Quartal pro kritischer Domain.