Post-Mortem für Netzwerkvorfälle: RCA-Methodik speziell für Router-Events

Ein Post-Mortem (RCA) für Netzwerkvorfälle soll nicht „Schuldige finden“, sondern die Wahrscheinlichkeit eines Wiederholungsfalls senken. Für Router-Events ist die Methodik besonders effektiv, wenn du technische Fakten (Logs, Counter, Routing-States) mit dem Change-Kontext (Wer hat was wann geändert?) kombinierst. Das Ziel ist ein belastbarer Zeitstrahl, eine verifizierte Root Cause, klare Contributing Factors und konkrete Maßnahmen (Prevent/Detect/Mitigate) mit Ownership.

RCA-Zielbild: Fakten, Zeitstrahl, Ursachenbaum, Maßnahmen

Ein gutes Post-Mortem ist kurz, aber präzise: Was ist passiert, wie wurde es bemerkt, warum ist es passiert, warum hat es Impact erzeugt, und was ändern wir. Für Router-Vorfälle sind Messpunkte wie Neighbor-Down, Default-Route-Verlust, CPU-Spikes, ACL-Drops und IPsec-Rekeys zentral.

• Impact: welche Services/Standorte/Clients waren betroffen?
• Timeline: von „erste Anomalie“ bis „vollständig stabil“
• Root Cause: verifizierte Ursache (nicht nur Korrelation)
• Contributing Factors: warum war der Impact so groß?
• Actions: Prevent/Detect/Mitigate + Owner + Termin

Datensammlung: Welche Router-Daten du direkt nach dem Incident sichern solltest

Viele Router-Indizien verschwinden schnell (Ringbuffer, Counters, SAs). Darum gehört eine „Evidence Capture“-Phase unmittelbar nach Stabilisierung ins Vorgehen.

• Konfiguration (Running/Startup) und relevante Diffs
• Syslog-Auszug um das Zeitfenster
• Interface-Fehlerzähler (CRC/Drops) und Status
• Routing-Status (Default Route, Neighbors, BGP summary)
• VPN-Status (ISAKMP/IPsec SAs, Rekey-Fehler)
• CPU/Memory und Control-Plane Policers (CoPP)

Evidence Commands (Copy & Paste)

show clock
show version
show running-config
show startup-config
show logging | last 500
show ip interface brief
show interfaces | include CRC|drops|error|rate
show ip route | include Gateway|0.0.0.0
show ip route summary
show ip ospf neighbor
show ip bgp summary
show ip nat statistics
show ip nat translations
show crypto isakmp sa
show crypto ipsec sa
show policy-map control-plane
show processes cpu sorted
show memory statistics

Timeline bauen: Router-Zeit, NTP und „Single Source of Truth“

Ein Router-RCA steht und fällt mit korrekter Zeit. Prüfe NTP-Status und normalisiere Zeitstempel (Zeitzone, UTC). Baue dann einen Zeitstrahl mit vier Kategorien: Symptom, Signal, Aktion, Ergebnis.

• Symptom: User-Impact („Internet down“, „VPN tot“)
• Signal: Monitoring/Logs („BGP neighbor down“, „line protocol down“)
• Aktion: Operator/Automation („ACL geändert“, „reload“, „failover“)
• Ergebnis: was wurde besser/schlechter?

NTP prüfen

show ntp status
show ntp associations
show clock

Root Cause finden: 5-Whys + Ursachenbaum (Router-spezifisch)

Für Router-Vorfälle ist ein Ursachenbaum hilfreich: du trennst Auslöser (Trigger) von Mechanismus (was hat technisch versagt) und von Impact-Verstärkern (warum war der Blast Radius groß). Die 5-Whys helfen, von „Symptom“ zu „Systemfehler“ zu kommen.

Praktischer Ursachenbaum

• Trigger: Change/Provider-Event/Software-Bug/Attack
• Mechanismus: Link down, Default Route weg, ACL deny, CPU-Flood, Rekey-Fail
• Blast Radius: fehlende Redundanz, fehlendes Tracking, fehlende Segmentierung
• Detection: warum wurde es spät/früh erkannt?

5-Whys Beispielstruktur (Template)

• Warum war Service X down? → weil Pfad Y nicht erreichbar war
• Warum war Pfad Y nicht erreichbar? → weil Default Route entfernt wurde
• Warum wurde Default Route entfernt? → weil Template Z falsch angewendet wurde
• Warum konnte Template Z falsch angewendet werden? → fehlende Pre-Checks/Review
• Warum fehlte der Guardrail? → kein Golden Config/Compliance-Check

Router-Events richtig einordnen: Häufige RCA-Kategorien

Viele Router-Incidents wiederholen sich in Mustern. Eine klare Klassifikation hilft, Maßnahmen zielgerichtet zu formulieren.

• Connectivity: Link/Interface/Provider, Duplex, MTU
• Routing: Default Route, OSPF/BGP Neighbor, Redistribution, Policy
• Policy: ACL, NAT, ZBF, CoPP (Drops)
• VPN: IKE Phase 1/2, Rekey/DPD, NAT-T, MTU/MSS
• Platform: CPU/Memory, Software-Bug, Crash/Reload

Verifikation statt Korrelation: Wie du Beweise führst

Eine Root Cause ist nur dann belastbar, wenn du sie technisch belegen kannst. Für Router heißt das oft: Counter/Logs zeigen den Zeitpunkt, ein Diff zeigt den Change, und ein Reproduktions- oder Lab-Test bestätigt den Mechanismus.

• Diff: „Welche Konfigzeilen haben sich verändert?“
• Counter: „Wann stiegen Drops/Errors?“
• State: „Wann ging Neighbor down/up?“
• Test: „Kann ich es im Lab reproduzieren oder logisch beweisen?“

Konfig-Diff via Archive (wenn aktiviert)

show archive
show archive log config all

Actions definieren: Prevent, Detect, Mitigate

Die stärksten Post-Mortem-Ergebnisse sind konkrete Maßnahmen, die künftige Vorfälle verhindern oder schneller erkennen lassen. Formuliere Actions so, dass sie testbar sind.

• Prevent: Golden Config, Template-Fixes, Review-Gates, CoPP/Hardening
• Detect: bessere Alerts (BGP down, Default Route fehlt, CPU), Syslog/NetFlow
• Mitigate: Dual-ISP mit Tracking, HSRP Tracking, OOB/Console, Runbooks

Maßnahmen-Template (kurz)

• Action: was wird geändert?
• Owner: wer ist verantwortlich?
• Due Date: bis wann?
• Verification: wie wird Erfolg gemessen?

Router-spezifische Prevent-Maßnahmen (Top 10)

Diese Maßnahmen sind bei Router-RCAs besonders häufig „high impact“.

• Golden Config + Drift Detection (Compliance)
• OOB Management + Console-Access (Lockout-Schutz)
• IP SLA Tracking für Default Route und HSRP
• CoPP/CPPr Baseline gegen CPU-Floods
• MTU/MSS Standards in VPN/Overlays
• Change Runbook (Pre-/Post-Checks) verpflichtend
• Zentrale Logs (NTP + Syslog) und korrelierbare Zeit
• SNMP/Telemetry Alerts auf Drops/Errors/Neighbor State
• NetFlow bei Congestion für schnelle Schuldzuordnung
• Staged Rollout (Pilot → Wellen) bei Änderungen/Upgrades

Post-Mortem Output: Minimalstruktur für Router-Incidents

Diese Struktur ist bewusst schlank, aber vollständig genug für Betrieb und Audit.

• Summary (2–4 Sätze): Impact, Dauer, Root Cause
• Impact: Nutzer/Standorte/Services, SLO-Verletzung
• Timeline: Signal/Aktion/Ergebnis mit Zeitstempeln
• Root Cause + Evidence: Logs/Diff/States
• Contributing Factors: warum war Impact groß?
• What went well / What went wrong
• Action Items: Prevent/Detect/Mitigate

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.