“Es geht nicht”: Netzwerk-Triage Checkliste für On-Call Engineers

„Es geht nicht“ ist die häufigste, aber auch die unbrauchbarste Fehlermeldung im On-Call. Sie sagt nichts darüber aus, ob das Problem am Client, im Access-Netz, im Core, im WAN, in der Cloud, an einer Firewall oder in der Anwendung liegt. Genau deshalb brauchen On-Call Engineers eine Netzwerk-Triage Checkliste, die in wenigen Minuten aus einem vagen Symptom eine technische Richtung macht: Was ist der Impact? Welche Fehlerdomäne ist am wahrscheinlichsten? Welche Evidence ist belastbar genug, um eine Mitigation zu starten oder gezielt zu eskalieren? Dieser Artikel liefert eine praxiserprobte Checkliste für Netzwerk-Triage, die sich in komplexen Umgebungen bewährt: Campus und Rechenzentrum, Hybrid-Cloud, SD-WAN/VPN, Zero-Trust-Perimeter und Multi-Provider-Anbindungen. Sie lernen, wie Sie systematisch messen statt zu raten, welche Fragen Sie den Meldenden stellen müssen, welche „Golden Signals“ die höchste Aussagekraft haben und wie Sie schnelle Entscheidungen treffen, ohne durch hektische Änderungen weitere Störungen zu erzeugen.

On-Call Mindset: Triage ist nicht Troubleshooting

Im Bereitschaftsdienst ist Zeit der begrenzende Faktor. Triage bedeutet: die Störung so weit einzuordnen, dass Sie entweder sicher mitigieren können oder präzise eskalieren. Vollständige Root Cause Analysis ist später dran. Trotzdem muss Triage sauber sein, sonst eskalieren Sie falsch, ändern unnötig Konfigurationen oder verlieren wertvolle Minuten.

• Ziel: Fehlerdomäne eingrenzen, wahrscheinlichste Ursache benennen, nächste Schritte entscheiden
• Nicht-Ziel: jedes Detail beweisen oder alle Layer vollständig prüfen
• Erfolgskriterium: Impact sinkt, Evidenz steigt, Teamkommunikation wird klarer

Vorbereitung: Was Sie vor dem ersten Klick klären müssen

Bevor Sie Tools öffnen, benötigen Sie ein Minimum an Kontext. Ohne diese Informationen erzeugen Sie nur Daten, aber keine Erkenntnis. On-Call heißt nicht „blind reagieren“, sondern strukturiert fragen.

Die fünf Fragen, die Sie sofort stellen sollten

• Was genau geht nicht? DNS, Login, VPN, Website, API, VoIP, interne App, nur Uploads, nur Downloads?
• Wer ist betroffen? alle Nutzer, einzelne Teams, ein Standort, ein VLAN/VRF, nur externe Nutzer?
• Seit wann? exakte Zeit (für Korrelation mit Changes, Provider-Events, Batch-Jobs)
• Was funktioniert noch? Vergleichsservice, anderes Gerät, anderer Standort, Mobilfunk statt WLAN
• Gab es Änderungen? Deployments, Firewall-Policy, Routing, SD-WAN-Profile, Zertifikate, DNS

Praxisregel: Wenn Sie nach 60 Sekunden nicht sagen können, ob es eher „Standort/Access“, „WAN/Provider“, „Security/Policy“ oder „Service/Applikation“ ist, fehlt Kontext – nicht Technik.

Die Netzwerk-Triage Checkliste: Schritt für Schritt

Die folgende Checkliste ist so aufgebaut, dass sie in den ersten 10–15 Minuten maximalen Signalgewinn liefert. Jeder Schritt hat ein klares Ergebnis: „weiter so“ oder „Richtung wechseln“. Damit vermeiden Sie Tool-Hopping und Aktionismus.

Schritt 1: Impact & Priorität festlegen

• Severity: kompletter Ausfall, Degradation, Teilfunktion gestört
• Business Impact: Kundensysteme, Produktionssysteme, interne Tools, nur einzelne Nutzer
• Blast Radius: global, regionalspezifisch, standortspezifisch, segmentbezogen
• Time Criticality: SLA/SLO relevant? Peak-Zeit? Sicherheitsvorfall möglich?

Schritt 2: Scope eingrenzen (wo tritt es auf?)

• Standortvergleich: funktioniert es aus einem anderen Standort?
• Zugangsart: WLAN vs. Kabel, VPN vs. direkt, Office vs. Homeoffice
• Devicevergleich: nur ein Gerätetyp/OS? nur ein Browser? nur eine App-Version?
• Netzsegment: nur ein VLAN/VRF/Subnetz? nur Gäste-Netz? nur Server-Netz?

Ein schneller Vergleich über einen alternativen Pfad ist eine der effektivsten Trennmessungen: Wenn es über Mobilfunk funktioniert, ist das Zielsystem vermutlich erreichbar – und die Fehlerdomäne liegt im Unternehmensnetz oder VPN.

Schritt 3: Golden Signals gegen Baseline prüfen

Bevor Sie in tiefe Debugging-Tools gehen, prüfen Sie die Kernsignale. Idealerweise als Zeitreihe im Monitoring, nicht nur als Momentaufnahme.

• Latenz: RTT zu Gateway, zu DNS, zu Cloud-Endpoints, zu kritischen Services
• Packet Loss: Loss auf WAN-Tunneln, Drops/Discards auf Interfaces, Policer Drops
• Jitter: relevant für Voice/Video und „sporadische“ Probleme
• Errors: CRC/FCS, Link Flaps, Optical Power (bei Fiber)
• Traffic Shift: ungewöhnliche Auslastung, neue Top Talker, Microbursts

Schritt 4: Pfad verifizieren (nicht annehmen)

In modernen Netzen ist der aktive Pfad selten trivial. Policy Routing, SD-WAN, NAT, Load Balancer und ECMP verändern den Weg. Ihre Triage muss die Pfadfrage beantworten: „Welcher Weg ist für den betroffenen Traffic aktuell aktiv?“

• Routing/Policy: welcher egress, welcher Tunnel, welcher Provider?
• Symmetrie: kommt der Rückweg über denselben Pfad? kritisch bei Stateful Firewalls/NAT
• Edge-Grenzen: wo passiert NAT, wo endet ein Tunnel, wo sitzt die Firewall?
• Load Balancer/Anycast: landet der Traffic auf dem erwarteten Ziel?

Schritt 5: Layer-Checkpoints (L1–L7) für schnelle Entscheidungen

Sie müssen nicht starr von Layer 1 nach Layer 7 durchgehen, aber Sie sollten Checkpoints nutzen, um Hypothesen schnell zu falsifizieren.

• L1: Link up reicht nicht – gibt es CRC/FCS, Flaps, Optik-Anomalien?
• L2: VLAN/Trunk/Port-Channel korrekt? STP-Events? MTU-Inkonsistenz möglich?
• L3: Routing-Änderungen, BGP/OSPF-Events, ECMP-Pfadproblem, VRF-Leaks?
• L4: TCP Handshake (SYN/SYN-ACK) ok? Retransmits? RSTs? UDP Loss/Jitter?
• L7: DNS-Lookup schnell? TLS Handshake ok? HTTP Statuscodes/TTFB auffällig?

Symptomorientierte Checklisten: „Wenn es so aussieht, dann prüfen Sie das“

On-Call lebt von Mustern. Die folgenden Symptomcluster sind in der Praxis besonders häufig und helfen Ihnen, in Minuten die wahrscheinlichste Ursache zu finden.

„Nichts geht“ im Standort (kompletter Ausfall)

• Wahrscheinliche Ursachen: WAN/Last-Mile down, Edge-Firewall/Router down, Strom/Link-Event, DHCP/DNS zentral gestört
• Schnellchecks: Edge-Uplinks/Flaps, Tunnel-Status, Default Gateway erreichbar, DNS-Resolver erreichbar
• Mitigation: Failover auf Backup-Link/zweiten Tunnel, Out-of-Band Zugriff, Provider eskalieren

„Internet langsam“, interne Systeme ok

• Wahrscheinliche Ursachen: Provider/Peering-Problem, Congestion, QoS/Policer auf Internet-Egress, DNS/Proxy/SSL-Inspection
• Schnellchecks: Loss/RTT zu externen Targets, Egress-Interface Drops, Proxy/Firewall Counters
• Mitigation: alternativer ISP/Peering, SD-WAN Path Preference, Inspection temporär reduzieren (nur kontrolliert)

„Nur manche Nutzer/Flows“ betroffen

• Wahrscheinliche Ursachen: ECMP auf fehlerhaften Member, Load-Balancer-Node defekt, WLAN-Roaming/802.1X, Segment-Policy
• Schnellchecks: Korrelation betroffener Flows zu Next-Hop/Member, Health-Checks, AP/Controller Events
• Mitigation: Member drainen, Hash/ECMP prüfen, betroffene APs isolieren, Policy-Rollback (eng begrenzt)

„Login geht, aber Upload hängt“ oder „nur große Transfers“

• Wahrscheinliche Ursachen: MTU/MSS/PMTUD-Problem, Fragmentation blockiert, Tunnel-Overhead
• Schnellchecks: große vs. kleine Requests, TLS/HTTP Timing, Retransmits bei großen Payloads
• Mitigation: MSS-Clamping an Tunnel-Edges, ICMP für PMTUD gezielt erlauben

„VPN instabil“ oder „Remote bricht ab“

• Wahrscheinliche Ursachen: Tunnel Loss/Jitter, NAT/State-Timeouts, Client-WLAN, Provider-Last-Mile
• Schnellchecks: Tunnel-SLA (Loss/Latency/Jitter), Firewall Session Table, Reauth/DPD/BFD Events
• Mitigation: Pfadwechsel, Keepalive/Timeout Anpassung (kontrolliert), alternative Gateway-Region

Evidence-First: Welche Daten Sie im On-Call immer sichern sollten

Wenn Sie nur eine Sache konsequent machen: sammeln Sie Evidence, bevor Sie Änderungen durchführen. So können Sie später beweisen, was geholfen hat, und vermeiden Wiederholungsfehler. Ein gutes On-Call-Protokoll besteht aus wenigen, aber harten Datenpunkten.

• Timeline: Startzeit, Detection, erste Maßnahmen, Mitigation, Stabilisierung
• Scope: betroffene Standorte/Segmente/Services
• Golden Signals: Loss/Latenz/Jitter/Errors/Drops (mit Zeitfenster)
• Pfadnotizen: egress, Tunnel, NAT, Security-Perimeter, Load Balancer
• Change-Context: relevante Deployments/Config-Diffs in der Nähe des Startzeitpunkts

Paketanalyse: Wann sie im On-Call sinnvoll ist

PCAP ist nicht immer der erste Schritt, aber häufig der schnellste Weg zur Wahrheit, wenn Symptome widersprüchlich sind (z. B. „Ping ok, App tot“) oder wenn Sie MTU, Retransmits, TLS Handshakes oder Asymmetrie vermuten. Halten Sie Captures kurz, filtern Sie auf 5-Tuple und messen Sie möglichst nahe an Quelle und Ziel. Referenzen: Wireshark Dokumentation und tcpdump Manpage.

Schnelle Entscheidungen: Mitigation, Eskalation, oder Messung?

On-Call heißt entscheiden. Ihr Ziel ist, Impact zu reduzieren, ohne das System zu destabilisieren. Deshalb sollte Ihre Checkliste klare Kriterien enthalten, wann Sie mitigieren, wann Sie eskalieren und wann Sie weiter messen.

Wann sofort mitigieren?

• Es gibt eine bekannte, risikoarme Mitigation (z. B. Failover auf Backup-Link, fehlerhaften Member drainen).
• Evidence zeigt klar einen Hotspot (z. B. Drops auf einem Link, Flaps, Tunnel Loss).
• Die Maßnahme ist reversibel und hat einen getesteten Rollback.

Wann eskalieren?

• Provider: Loss/RTT-Spikes am WAN-Edge, BGP/Link Flaps, mehrere Standorte betroffen
• Security: Firewall Drops/Policy Hits steigen, Inspection/Signaturen zeitlich korrelieren, DDoS-Verdacht
• Plattform/Applikation: Netzwerkpfad sauber, aber HTTP 5xx, TLS Alerts, Backend-Timeouts dominieren

Wann weiter messen?

• Die Symptome sind inkonsistent oder „nur manchmal“ sichtbar.
• Die Fehlerdomäne ist unklar (z. B. WAN vs. Security vs. Service).
• Mitigation wäre riskant und nicht klar reversibel.

Runbook-Format für On-Call: Kurz, robust, technologieagnostisch

Die beste Checkliste nützt nichts, wenn sie nachts um 03:00 Uhr nicht schnell erfassbar ist. Halten Sie On-Call Runbooks bewusst kurz, mit klaren Abzweigungen und Links zu tieferen Playbooks.

• Ein Bildschirm „Triage“: 10–15 Minuten Ablauf, Golden Signals, Pfad-Check
• Modul-Links: WAN-Loss, DNS langsam, MTU/PMTUD, Firewall Drops, ECMP/Load Balancer
• Evidence Packs: vordefinierte Datensätze je Symptomcluster
• Mitigation-Liste: Low-Risk zuerst, immer mit Rollback und Verifikation

Kommunikation im Incident: Klarheit statt Spekulation

„Es geht nicht“ erzeugt Druck. Mit klaren Updates reduzieren Sie Stress und verhindern unnötige Eingriffe. Kommunizieren Sie in kurzen Zyklen: Impact, aktuelle Hypothese, nächste Maßnahme, nächster Update-Zeitpunkt. Vermeiden Sie Spekulation, nennen Sie Evidence.

• Status: „Standort A hat seit 10:14 Uhr erhöhte Paketverluste am WAN-Edge.“
• Hypothese: „Wahrscheinlich Provider/Last-Mile; alternativer Tunnel wird aktiviert.“
• Nächster Schritt: „Failover + Verifikation über synthetische Checks; Provider-Ticket eröffnet.“
• Update: „Nächstes Update in 15 Minuten oder bei Statusänderung.“

Weiterführende Referenzen für On-Call, Incident Response und Netzwerk-Analyse

• Google SRE Bücher für Incident Response, On-Call-Praktiken und Postmortems
• ITIL als Referenz für Incident- und Problem-Management
• RFC Editor für Primärquellen zu Netzwerkstandards und Protokollverhalten
• Wireshark Dokumentation für Paketanalyse und Troubleshooting-Workflows
• tcpdump Manpage für Capture-Strategien und BPF-Filter

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.