Runbook „ISP down“ vs. „LAN down“: Was ist der Unterschied?

Ein praxistaugliches Runbook „ISP down“ vs. „LAN down“: Was ist der Unterschied? gehört zu den wichtigsten Grundlagen im operativen IT-Betrieb, weil beide Störungsmuster für Endnutzer oft gleich aussehen, technisch aber völlig unterschiedliche Ursachen, Zuständigkeiten und Lösungswege haben. Genau diese Verwechslung führt in vielen Teams zu langen Ausfallzeiten: Ein echtes Provider-Problem wird intern zu lange analysiert, während ein lokales LAN-Problem vorschnell an den Internetanbieter eskaliert wird. Das kostet Zeit, erhöht den Eskalationsdruck und verschlechtert die Kommunikationsqualität gegenüber Fachbereichen und Management. Ein gutes Runbook trennt deshalb klar zwischen WAN-/Provider-Störung und interner Netzwerkstörung, definiert eindeutige Prüfschritte, legt Messpunkte fest und schafft klare Übergaben zwischen Service Desk, NOC, Netzwerkteam und externem ISP-Support. Für Einsteiger liefert es Orientierung, für fortgeschrittene Teams standardisiert es Entscheidungen, und für Profis schafft es belastbare Daten für RCA und kontinuierliche Verbesserung. Der folgende Leitfaden zeigt strukturiert, wie ein solches Runbook aufgebaut ist, welche Signale wirklich unterscheiden helfen, wie man Fehlklassifizierungen vermeidet und wie Kommunikation, Validierung und Eskalation sauber ineinandergreifen.

Warum die Unterscheidung „ISP down“ vs. „LAN down“ so kritisch ist

Aus Nutzersicht heißt es oft nur: „Internet geht nicht“. Aus Betriebssicht ist das zu ungenau. Ob der Fehler im lokalen Netz oder außerhalb liegt, entscheidet über Werkzeuge, Verantwortlichkeit und Wiederherstellungszeit.

• Falsche Eskalation: Interne Fehler werden an den Provider gegeben oder umgekehrt.
• Längere MTTR: Diagnose startet am falschen Ende.
• Kommunikationschaos: Unterschiedliche Teams geben widersprüchliche Statusmeldungen.
• Unklare Verantwortung: Niemand steuert aktiv bis zur Wiederherstellung.

Ein Runbook mit klaren Entscheidungspunkten reduziert genau diese Reibungsverluste.

Begriffe sauber definieren

Bevor Prozesse starten, sollten die Begriffe einheitlich festgelegt sein:

• ISP down: Störung auf der Provider-Strecke oder im vorgelagerten WAN/Internet-Pfad außerhalb des lokalen Netzes.
• LAN down: Störung innerhalb des lokalen Netzes (Access, Distribution, Core, lokale Services wie DHCP/DNS/AAA).
• Teilbetroffenheit: Nur bestimmte VLANs, Standorte, Subnetze oder Nutzergruppen betroffen.
• Totalbetroffenheit: Standort oder Service vollständig ohne Nutzbarkeit.

Diese Definitionen sind die Basis für konsistente Ticketkategorien und Eskalationspfade.

Symptomatik: Was bei beiden Fällen ähnlich aussieht

Typische Meldungen, die sowohl bei ISP- als auch bei LAN-Problemen auftreten können:

• Webseiten laden nicht
• Cloud-Dienste sind nicht erreichbar
• VPN-Verbindungen brechen ab
• VoIP-/Videokonferenzqualität ist schlecht
• „Kein Internet“-Hinweise auf Clients

Deshalb darf die Diagnose nie auf Endnutzerbeschreibung allein basieren.

Kernunterschiede im Fehlerbild

Mit wenigen, gezielten Prüfungen lassen sich die Muster oft schnell trennen:

• LAN down typisch: lokale Gateways nicht erreichbar, ARP-Probleme, DHCP-Fehler, VLAN-/Trunk-Themen, interne Dienste ebenfalls gestört.
• ISP down typisch: internes LAN stabil, lokales Gateway erreichbar, aber externes Routing/Upstream nicht funktionsfähig.

Die Frage lautet daher immer: „Ist interne Konnektivität stabil, während nur externe Pfade ausfallen?“

Runbook-Design: Entscheidungsbaum statt Checklisten-Wildwuchs

Ein gutes Runbook besteht aus klaren Gates mit Ja/Nein-Logik. So wird es unter Zeitdruck nutzbar:

• Gate 1: Ist das lokale Gateway aus Client-/Segment-Sicht erreichbar?
• Gate 2: Sind interne kritische Services (DNS, DHCP, AD/AAA, Intranet) erreichbar?
• Gate 3: Ist der Edge-Router/Uplink physisch und logisch stabil?
• Gate 4: Funktioniert externe Erreichbarkeit via definierter Testziele?
• Gate 5: Liegt eine providerseitige Störung oder internes Routing/Policy-Problem vor?

Jedes Gate braucht klare Evidenz und einen festen Owner.

Phase 1: Sofort-Triage in den ersten 5 Minuten

• Scope erfassen: einzelner Nutzer, VLAN, Standort, mehrere Standorte
• Alarm- und Monitoringlage prüfen (Linkstatus, Loss, Latenz, BGP/OSPF-Events)
• Clientsicht validieren (IP erhalten? Gateway erreichbar?)
• Interne Referenzdienste testen (z. B. internes DNS und Intranet)

Nach diesen Schritten ist meist eine erste Hypothese möglich: eher LAN oder eher ISP.

Phase 2: Runbook „LAN down“ im Detail

Wenn lokale Anzeichen dominieren, folgt die LAN-Pfadprüfung von innen nach außen.

L1/L2-Basis prüfen

• Portstatus, Flaps, Fehlerzähler (CRC/FCS), Duplex/Speed
• VLAN-Zuordnung, Trunk Allowed-VLANs, Native VLAN Konsistenz
• LACP/STP-Status auf Access- und Distribution-Ebene

L3/L4-Lokalprüfung

• SVI/Default-Gateway-Status
• ARP/ND-Tabellen, lokale Routen, VRF-Zuordnung
• Interne Reachability auf definierte Testziele

Abhängige Infrastrukturservices

• DHCP-Leases und Scope-Auslastung
• Lokale DNS-Resolver und Forwarding
• AAA/Directory-Dienste für Authentifizierung

Wenn diese Ebenen rot sind, ist ISP-Eskalation verfrüht.

Phase 3: Runbook „ISP down“ im Detail

Wenn das LAN stabil ist, beginnt die strukturierte Provider-/WAN-Diagnose.

Edge- und Uplink-Evidenz

• WAN-Interface-Status, Fehlerzähler, Optikwerte
• PPP/BGP-Session-Status (falls genutzt)
• Default-Route-Präsenz und Next-Hop-Erreichbarkeit

Externe Testmethodik

• Tests gegen mehrere externe Ziele und unterschiedliche ASNs
• DNS und IP-basierte Tests getrennt durchführen
• Traceroute/MTR nur mit Kontext interpretieren

Provider-Eskalation vorbereiten

• Startzeit, Scope, betroffene Standorte/Präfixe
• Messwerte (Loss, RTT, Session-Events)
• Konfigurations-/Change-Historie der letzten Stunden

Diese Mindestdaten beschleunigen die Bearbeitung im ISP-NOC erheblich.

Entscheidungsmatrix: LAN oder ISP?

Eine einfache Matrix erhöht die Konsistenz im Schichtbetrieb:

• Gateway nicht erreichbar + interne Dienste gestört → hohe Wahrscheinlichkeit LAN down
• Gateway erreichbar + interne Dienste stabil + externe Ziele gestört → hohe Wahrscheinlichkeit ISP down
• Nur bestimmte VLANs/Subnetze betroffen → meist LAN/L3-intern
• Mehrere Standorte mit gleichem Upstream betroffen → häufig ISP/WAN

Bei Mischsignalen wird ein Dual-Track gestartet: intern weiterprüfen und parallel Provider informieren.

Mathematisches Scoring zur Hypothesenbewertung

Für größere Teams kann ein gewichteter Hypothesenscore helfen:

$\mathrm{ISP\_Probability}=0.35\times \mathrm{InternalHealth}+0.30\times \mathrm{ExternalFailureEvidence}+0.20\times \mathrm{MultiSiteCorrelation}+0.15\times \mathrm{ProviderSignal}$

Werte zwischen 0 und 1 normieren. Analog kann ein LAN-Score berechnet werden. Die Scores ersetzen keine Diagnose, verbessern aber die Entscheidungsdisziplin.

Kommunikation im Incident: unterschiedliche Botschaften für LAN und ISP

Die Kommunikationsstrategie unterscheidet sich je nach Störungstyp:

• Bei LAN down: Fokus auf lokale Maßnahmen, interne ETAs, ggf. Standort-spezifische Workarounds.
• Bei ISP down: Hinweis auf externen Carrier Case, Ticket-ID, abgestimmte Update-Frequenz.

Empfohlenes Update-Format:

• Aktueller Zustand
• Bisherige Evidenz
• Nächster technischer Schritt
• Nächstes Update mit Zeitstempel

Eskalationspfade und Verantwortlichkeiten

• Service Desk: Ersterfassung, Scope-Klärung, Standardtests.
• NOC: Gate-Entscheidung LAN vs. ISP, Incident-Steuerung.
• Netzwerkteam: Tiefendiagnose L1–L3 intern.
• Carrier Management: Provider-Eskalation und Nachverfolgung.
• Incident Commander: Entscheidungshoheit bei Mischlagen und Business-Kommunikation.

Ohne dieses Rollenmodell entstehen Doppelarbeit und Lücken in der Verantwortung.

Typische Fehlannahmen und wie das Runbook sie verhindert

• „Ping 8.8.8.8 geht nicht, also ISP down“ – kann auch internes Routing/Firewall-Problem sein.
• „Internes WLAN läuft, also LAN ist gesund“ – einzelne Segmente können trotzdem gestört sein.
• „Provider meldet keine Großstörung, also liegt es intern“ – regionale oder peering-spezifische Probleme sind möglich.
• „Traceroute zeigt Sternchen, also dort ist der Fehler“ – ICMP-Rate-Limits können täuschen.

Das Runbook zwingt auf Evidenz pro Gate statt auf Einzelindikatoren.

Runbook-Artefakte für saubere Übergabe und RCA

• Incident-Timeline mit Messpunkten
• Testergebnisse intern vs. extern (Zeitstempel)
• Edge-/Uplink-Status, Routing-/Session-Ereignisse
• Provider-Ticketnummer und Kommunikationsprotokoll
• Durchgeführte Mitigations und Wirksamkeitsnachweise

Diese Artefakte verkürzen Folgediagnosen und verbessern Lernzyklen.

Qualitätsmetriken für das Runbook

• Time-to-Classification (bis LAN/ISP-Hypothese)
• False-Escalation-Rate zum ISP
• Reclassification-Rate (wie oft LAN/ISP später korrigiert wird)
• MTTR je Incident-Typ
• Anteil vollständiger Eskalationsdaten beim ersten Kontakt

So wird sichtbar, ob das Runbook im Alltag wirklich funktioniert.

Praxisnahe Einführung in 30 Tagen

Woche 1: Standardisieren

• Definitionen, Gates, Pflichtdaten und Rollen freigeben
• Ticketfelder für LAN/ISP-Klassifikation ergänzen

Woche 2: Technisch verankern

• Standardtests automatisieren (intern/extern, DNS/IP getrennt)
• Dashboards für Edge, Uplink, interne Kernservices bereitstellen

Woche 3: Training

• Tabletop-Szenarien „LAN down“, „ISP down“, Mischlage durchführen
• Schichtteams auf Update- und Eskalationsformat trainieren

Woche 4: Review

• Erste Incidents auswerten, Fehlklassifizierungen analysieren
• Gates und Checklisten anhand realer Evidenz nachschärfen

Outbound-Ressourcen für vertiefende Standards und Betriebspraxis

• RFC Editor mit Protokollgrundlagen zu IP, Routing, DNS und Transport
• RIPE-Ressourcen zu Internet-Routing, Peering und operativer Netzpraxis
• NANOG mit praxisnahen Betriebs- und Routing-Insights aus Provider-Umfeldern
• Google SRE Book für Incident-Management und Betriebszuverlässigkeit
• Google SRE Workbook mit konkreten Runbook- und Alarmierungsansätzen
• Incident-Management-Leitfäden für Kommunikation und Eskalationsprozesse

Sofort einsetzbare Kurz-Checkliste

• Scope in 5 Minuten klären: Nutzer, Segment, Standort, Region
• Interne Gesundheit zuerst prüfen: Gateway, DHCP, DNS, Intranet
• Externe Störung mit mehreren Zielen und Methoden verifizieren
• LAN/ISP-Entscheidung auf Gate-Evidenz stützen, nicht auf Einzeltest
• Bei ISP-Eskalation Pflichtdaten vollständig mitgeben
• Statusupdates im festen Format und Takt kommunizieren

Mit einem diszipliniert aufgebauten Runbook „ISP down“ vs. „LAN down“: Was ist der Unterschied? wird aus diffuser Störungsanalyse ein klarer, wiederholbarer Betriebsprozess, der Fehlklassifizierungen reduziert, Eskalationen beschleunigt und Ausfallzeiten im Alltag deutlich verkürzt.

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.