February 15, 2026

Incident „Teilweise Site Down“: OSI-Checkliste für Multi-Site-Netzwerke

Ein Incident „Teilweise Site Down“ gehört zu den frustrierendsten Störungsbildern in Multi-Site-Netzwerken: Ein Standort wirkt „halb erreichbar“, einige Anwendungen funktionieren, andere brechen weg, und die Symptome sind je nach Client, Region oder Zugangspfad unterschiedlich. Genau deshalb ist eine strukturierte OSI-Checkliste für Multi-Site-Netzwerke so wertvoll. Sie hilft dem Ops- oder NOC-Team, die Störung schnell zu klassifizieren, Beweise pro OSI-Schicht zu sammeln und die Ursachen einzugrenzen, ohne sich in Einzelbeobachtungen zu verlieren. Das Hauptkeyword „Incident „Teilweise Site Down“: OSI-Checkliste für Multi-Site-Netzwerke“ beschreibt dabei nicht nur ein Dokument, sondern einen Arbeitsmodus: erst Lagebild, dann Schicht-für-Schicht-Validierung, anschließend zielgerichtete Mitigation. Gerade in Standortverbünden mit WAN/SD-WAN, mehreren ISPs, redundanten Firewalls, zentralen Services (DNS, IdM, Proxy) und verteilten Applikationen ist „teilweise down“ häufig ein Zusammenspiel aus Routing, Policy, MTU, Session-State oder L7-Dependencies. Wer diese Muster kennt und sauber trennt, reduziert MTTR deutlich – und vermeidet die typische Eskalationsspirale („Netzwerk ist schuld“ vs. „App ist schuld“) durch belastbare Daten.

Table of Contents

Was „Teilweise Site Down“ wirklich bedeutet

„Teilweise Site Down“ ist kein einzelner Fehler, sondern eine Kategorie: Der Standort verliert nicht komplett die Konnektivität, sondern nur bestimmte Pfade, Protokolle oder Dienste. Häufige Ausprägungen sind: Nutzer im Standort kommen ins Internet, aber nicht ins Rechenzentrum; VPN steht, aber einzelne Applikationen timeouten; VoIP ist schlecht, Datenverkehr wirkt normal; nur bestimmte VLANs sind betroffen; oder nur externe Clients sehen Fehler, interne nicht. Genau das macht die Diagnose schwierig: Ein einzelner Ping ist als Indikator zu schwach. In Multi-Site-Umgebungen müssen Sie den Incident als Kombination aus Scope (wer ist betroffen?), Path (über welche Strecke?) und Layer (auf welcher OSI-Schicht?) verstehen.

Scope: ein Standort, mehrere Standorte, nur einzelne Segmente (z. B. Voice, Guest, OT), nur Remote-User
Path: WAN-MPLS, Internet-VPN, SD-WAN-Overlay, Direktverbindung, Cloud-Interconnect
Layer: von physischer Störung bis zu DNS/Auth/HTTP-Fehlern

Erste 10 Minuten: Lagebild bauen, bevor Sie tief debuggen

Bevor Sie in Details gehen, brauchen Sie ein reproduzierbares Lagebild. Im Multi-Site-Kontext entscheidet das darüber, ob Sie sofort auf einen Pfad schwenken (z. B. ISP A) oder ob Sie eine Service-Kategorie isolieren (z. B. DNS oder Auth). Diese „Pre-OSI“-Schritte sparen Zeit, weil sie die OSI-Checkliste richtig fokussieren.

Betroffene Standorte identifizieren: Ist es exakt ein Site oder alle Sites mit einem gemeinsamen Carrier/Hub?
Betroffene Dienste clustern: Intranet, SaaS, VoIP, VDI, Fileshares, Auth, DNS, spezifische Apps
Betroffene Netzsegmente erfassen: Nur ein VLAN/VRF oder siteweit? Nur WLAN oder auch LAN?
Zeitfenster und Change-Korrelation: Gab es Deploys, ISP-Events, Wartungsfenster, Policy-Änderungen?
Referenztests definieren: Mindestens zwei Testpunkte (im Standort + extern/zentral) für denselben Dienst

OSI-Checkliste: Vorgehen pro Schicht für Multi-Site-Netzwerke

Die folgende OSI-Checkliste ist für „teilweise down“ optimiert: Sie zielt auf die häufigsten Ursachen in Standortverbünden und stellt sicher, dass Sie pro Schicht nicht nur „prüfen“, sondern Belege sammeln. Das ist entscheidend, weil Multi-Site-Incidents oft mehrere Teams betreffen (Netzwerk, Security, Plattform, App) und Sie ohne saubere Evidenz Zeit in Zuständigkeitsdebatten verlieren.

Layer 1: Physik & Träger – unterschätzter Auslöser für „halb kaputt“

Auch wenn „Teilweise Site Down“ oft wie ein L3/L7-Thema wirkt, startet es nicht selten auf Layer 1: degradierte Optik, fehlerhafte Patchung, instabile Hand-offs oder ein einzelnes Mitglied in einem Port-Channel. Das Ergebnis ist nicht zwingend „komplett down“, sondern Paketfehler, Mikroflaps oder reduzierte Kapazität, die sich erst unter Last als Applikationsfehler zeigt.

Link-Status und Flaps: Prüfen Sie alle WAN-/Uplink-Ports (auch LAG-Member) auf Link-Flap-Historie.
Speed/Duplex/Autoneg: Verifizieren Sie, ob beide Seiten identisch verhandeln; Mismatches sind selten, aber fatal.
Optik-Telemetrie (DOM/DDM): Rx/Tx-Power, Temperatur, Bias-Current gegen Baseline vergleichen.
Layer-1-Fehlerzähler: CRC/FCS/Symbol/PCS-Errors; Anstieg während Incident ist ein harter Hinweis.
Provider-Hand-off: Wenn möglich: Demark/NTU/ONT-Status, LOS/LOF-Alarme, Rx-Level.

Praxis-Tipp: Wenn nur bestimmte Anwendungen betroffen sind, prüfen Sie dennoch L1/L2-Counter. Viele „nur manche Sessions brechen“ Ursachen lassen sich als Paketfehler oder Mikroflaps nachweisen, die in L7 als Timeout erscheinen.

Layer 2: Switching, Trunks und Loops – Teil-Ausfälle durch Segment-Fehler

In Multi-Site-Standorten zeigt sich Layer-2-Instabilität häufig segmentiert: Ein VLAN ist „weg“, ein Trunk transportiert nicht mehr alle VLANs, STP reagiert auf eine Loop-Situation, oder MAC-Tabellen flappen durch Fehlverkabelung oder falsch konfigurierte Redundanz. Das wirkt für Betroffene wie „Site down“, ist aber faktisch ein L2-Segmentproblem.

VLAN/Trunk-Validierung: Allowed VLANs und Native VLAN auf beiden Seiten vergleichen (Drift ist ein Klassiker).
STP-Events: Topology Change-Spikes, Root-Bridge-Wechsel, Ports in Blocking/Forwarding-Übergängen.
Broadcast/Unknown-Unicast: Erhöhte Raten deuten auf Loop, Fehlkonfiguration oder Fehlgeräte hin.
MAC-Flapping: Dieselbe MAC auf wechselnden Ports ist ein starker Indikator für L2-Fehlerbilder.
LACP/Port-Channel: Member-States, LACP-Partner-ID, „suspended“ oder „individual“ Zustände prüfen.

Wenn Sie STP einsetzen, ist ein sauberes Verständnis der Protokolle wichtig. Eine kompakte Referenz finden Sie in IEEE-802.1D/STP-Grundlagen (Standardkontext) und ergänzend in herstellerneutralen Übersichten, z. B. über Spanning Tree Protocol.

Layer 3: Routing, VRFs und Pfade – der Kern vieler Multi-Site-Teilausfälle

Layer 3 ist die häufigste Ursache für „Teilweise Site Down“ in Standortnetzen, weil hier Pfadentscheidungen, Policies und Overlays zusammenlaufen. Besonders tückisch: Control Plane kann stabil wirken (Neighbors up), während die Data Plane partiell bricht (Blackholes, asymmetrische Pfade, ECMP-Divergenz). Deshalb muss Ihre Checkliste beides getrennt prüfen.

Control Plane: Nachbarn, Routen, Konvergenz

Neighbor-Status: OSPF/BGP/IS-IS Nachbarn stabil? Flaps, Timer-Resets, ungewöhnliche State-Wechsel?
Route-Table-Check: Fehlen Prefixe? Zeigen Next-Hops auf unerwartete Interfaces/Tunnel?
Policy-Änderungen: Route-Maps, Prefix-Lists, Communities, VRF Route Targets; Drift nach Changes prüfen.
Convergence-Zeit: Lange Konvergenz kann „teilweise“ verursachen, wenn Sessions/Pfade währenddessen kippen.

Data Plane: Traceroute, Blackhole-Muster, MTU/PMTUD

Traceroute aus mehreren Perspektiven: Site → DC/Cloud, DC → Site, extern → Site. Unterschiede sind Gold wert.
Blackhole-Indikatoren: Traceroute stoppt wiederholt am selben Hop; oder erreicht Ziel, aber nur sporadisch.
Asymmetrie prüfen: Rückweg über andere Firewall/ISP kann Sessions zerstören (besonders stateful Devices).
MTU/Fragmentierung: Path-MTU-Discovery-Probleme zeigen sich als „Ping geht, App nicht“ – vor allem bei VPN/Overlay.

Für den praktischen Umgang mit Traceroute und Path-Diagnose ist die Dokumentation der jeweiligen Tools hilfreich, z. B. traceroute unter Linux.

Layer 4: TCP/UDP – wenn nur bestimmte Sessions oder Ports betroffen sind

„Teilweise down“ bedeutet häufig: Der Standort kann grundsätzlich reachen, aber bestimmte Verbindungen scheitern. Das ist ein klares Layer-4-Signal. Typische Muster sind TCP-Handshake-Probleme, Retransmissions, Timeouts auf bestimmten Ports oder UDP-Loss bei Echtzeitdiensten. In Multi-Site-Architekturen kommen hinzu: Firewall-State, NAT-Tabellen, Port-Exhaustion oder unterschiedliche QoS-Queues pro Verkehrsklasse.

Connection Refused vs. Timeout: Refused spricht eher für erreichbaren Host ohne Listener/Policy, Timeout eher für Pfad/Filter/State.
Handshake-Rate: SYN ohne SYN-ACK? SYN-ACK ohne ACK? Das trennt Netzwerkpfad von Host/Policy.
Retransmission-Spike: Deutet auf Paketverlust, Overload oder fehlerhafte Links hin; korrelieren Sie mit L1/L2 Countern.
UDP-Loss/Jitter: Besonders relevant für VoIP/Video/OT; prüfen Sie QoS und Queue-Drops.
Firewall/Conntrack/NAT: Auslastung, Drops, Table-Full-Ereignisse, Session-Aging und Port-Pools.

Wenn Sie TCP-Mechanik sauber interpretieren wollen, ist eine Referenz wie RFC 9293 (TCP) hilfreich, insbesondere für Handshake- und Retransmission-Logik.

Layer 5: Session-Zustand – der Klassiker bei „geht manchmal“

Layer 5 wird in der Praxis selten explizit gemessen, aber häufig als Incident-Symptom wahrgenommen: „VDI trennt“, „VPN droppt“, „Login läuft aus“, „nur nach einigen Minuten bricht es“. In Multi-Site-Netzen sind Session-Probleme oft die Folge von Asymmetrie, Load-Balancer-Persistenz, Idle-Timeouts oder State-Replikation (HA-Firewalls, Cluster).

Idle-Timeout vs. Keepalive: Prüfen Sie, ob Timeouts zu typischen Grenzen passen (z. B. 300s, 900s, 3600s).
Sticky Sessions: Wenn ein LB persistiert, kann ein einzelnes Backend „teilweise down“ wirken.
HA-State: Failover ohne State-Sync verursacht Session-Abbrüche, obwohl L3 weiter funktioniert.
VPN-Tunnel-Resets: DPD/Keepalive, Rekey-Intervalle, MTU-Settings und Crypto-Offload beachten.

Layer 6: TLS/Zertifikate – warum ein Standort „down“ wirkt, obwohl das Netz steht

Ein häufiger Stolperstein: TLS-Probleme werden als Netzwerkstörung gemeldet, weil die Benutzeroberfläche nur „geht nicht“ zeigt. In Multi-Site-Architekturen passiert das besonders, wenn unterschiedliche Egress-Pfade, Proxy-Policies oder TLS-Offload-Varianten existieren. Dann funktioniert derselbe Service aus Standort A, aber nicht aus Standort B.

Zertifikatsablauf/Chain: Betroffene Clients schlagen fehl, während andere (mit anderem Trust Store) noch funktionieren.
SNI-Routing: Bei gleicher IP unterschiedliche Domains; falsches SNI-Mapping führt zu „Domain A geht, Domain B nicht“.
Cipher/Protocol-Mismatch: „Geht nur bei manchen Clients“ ist ein typisches L6-Signal.
mTLS/Service Mesh Edge-Cases: Wenn Standorte unterschiedliche Sidecar-/Policy-Versionen haben, entstehen partielle Ausfälle.

Für ein solides Grundverständnis ist die IETF-Dokumentation zu TLS nützlich, z. B. RFC 8446 (TLS 1.3).

Layer 7: Applikationssymptome richtig interpretieren, um Owner-Teams zuzuweisen

Auf Layer 7 zeigt sich „Teilweise Site Down“ oft als HTTP 502/503/504, als sporadische 5xx-Spikes, als erhöhte Latenz oder als Auth-Fehler. Entscheidend ist, diese Signale nicht isoliert zu betrachten, sondern mit den OSI-Schichten darunter zu korrelieren. Ein 504 kann „Upstream langsam“ bedeuten, aber ebenso ein MTU-Problem, das Retransmissions erzeugt, bis das Gateway timeoutet.

HTTP-Statusmuster: 502/503/504 unterscheiden: Upstream down, Überlast, Timeout, Misroute.
Endpoint-Spezifik: Betrifft es nur Login, nur Upload, nur große Payloads? Das weist auf TLS/MTU/Proxy hin.
Dependency-Check: Zentrale Services (DNS, LDAP, Kerberos, DB, Queue) verursachen standortweit „teilweise down“.
RUM vs. Synthetic: Real User Monitoring zeigt echte Clientpfade; Synthetic ist kontrolliert und ideal fürs Reproduzieren.

Eine herstellerneutrale Übersicht über HTTP-Statuscodes ist als Referenz praktisch, z. B. über HTTP-Statuscodes bei MDN.

Multi-Site-Spezial: Die häufigsten Root-Cause-Klassen bei „Teilweise Site Down“

In Standortverbünden wiederholen sich bestimmte Ursachen. Wenn Sie diese Klassen kennen, können Sie Ihre OSI-Checkliste als „Hypothesenfilter“ nutzen: Welche Klasse passt am besten zu den aktuellen Beobachtungen?

Pfad-Asymmetrie: Rückweg über andere Firewall/ISP; besonders kritisch bei stateful Firewalls und NAT.
Overlay/Underlay-Mismatch: SD-WAN/Gre/IPsec steht, aber Underlay degradiert; oder MTU passt nicht.
Segment-Drift: VLAN/Trunk Allowed Lists, VRF RTs, ACLs unterscheiden sich standortweise.
Zentrale Abhängigkeit: DNS, IdM, Proxy, Zertifikatsdienste – wenn zentral gestört, sind Sites „teilweise“ betroffen.
Capacity/Queueing: Ein Standort hat Engpässe, Drops in QoS-Queues oder Shaping falsch dimensioniert.
Policy-Regressions: WAF/Firewall/Proxy blockt bestimmte Pfade oder User Agents, oft nur in einem Egress.

Beweissammlung: Welche Artefakte Sie pro Schicht sichern sollten

Eine gute OSI-Checkliste endet nicht beim „Check“, sondern liefert verwertbare Artefakte für RCA und Vendor-Tickets. Im Multi-Site-Fall ist das besonders wichtig, weil Provider- und Carrier-Tickets ohne harte Daten nur Zeit kosten.

L1: Interface-Status, Flap-Logs, DOM/DDM-Werte, Error-Counter vor/nach Incident
L2: Trunk-Konfig (Allowed VLANs), STP-Events, MAC-Flap-Logs, LACP-States
L3: Neighbor-Logs, Routing-Table-Snapshots, Policy-Auszüge, Traceroutes aus mehreren Quellen
L4: SYN/SYN-ACK/ACK-Muster (pcap oder Counters), Retransmission/RTT-Metriken, Firewall/NAT-Stats
L6: TLS-Handshake-Errors, Zertifikats-/Chain-Details, SNI/ALPN-Beobachtungen
L7: HTTP-Statusverteilung, p95/p99-Latenz, Dependency-Logs, Fehlerkorrelation nach Standort/ISP

Mitigation-Taktiken: Impact reduzieren, bevor die endgültige Ursache feststeht

Bei „Teilweise Site Down“ lohnt sich häufig eine abgestufte Mitigation: Erst Stabilität herstellen, dann Ursachenanalyse vertiefen. OSI hilft, passende Maßnahmen zu wählen, die das Risiko nicht erhöhen.

Pfadwechsel: Traffic auf sekundären ISP/Overlay-Pfad shiften, wenn Asymmetrie oder Underlay-Degradation vermutet wird.
Segment-Isolation: Betroffene VLANs/VRFs temporär isolieren, wenn Loop/Broadcast-Storm-Anzeichen vorliegen.
MTU-Safety: Temporär MSS-Clamping oder MTU-Anpassungen (mit Change-Disziplin) testen, wenn große Payloads scheitern.
Policy-Rollback: Letzte ACL/WAF/Proxy-Änderung zurück, wenn L7/L6 selektiv betroffen ist.
Service-Fallback: DNS/Resolver-Fallback, alternative Auth-Endpoints, Cache-Bypass (wo möglich) aktivieren.

Operationalisieren: OSI-Checkliste als wiederholbarer Incident-Runbook-Flow

Damit die Checkliste nicht nur ein Dokument bleibt, sollten Sie sie als Ablauf in Ihr Incident-Management integrieren: mit klaren Rollen, definierter Datensammlung und standardisierten Tests. Gerade im NOC-Kontext ist die Wiederholbarkeit entscheidend, weil die gleichen Fehlerbilder immer wieder auftreten – nur mit anderen Symptomen.

Standard-Testmatrix: pro Site zwei Testpunkte (lokal + zentral), pro Dienst mindestens DNS→TCP→TLS→HTTP prüfen.
OSI-Tagging: Tickets/Alerts konsequent einer OSI-Schicht zuordnen, um Korrelation zu erleichtern.
Baseline-Vergleich: „Normalwerte“ für L1-Errors, L3-Neighbor-Stabilität, L4-Retransmissions, L7-5xx etablieren.
Escalation by Evidence: Erst eskalieren, wenn die Belege pro Schicht gesichert sind (spart Ping-Pong).

Outbound-Links für vertiefende Grundlagen und Referenzen

Kompakte OSI-Checkliste zum schnellen Abarbeiten im Incident

Wenn der Druck hoch ist, hilft eine kurze „Run-Card“, die Sie parallel zur detaillierten Analyse nutzen. Sie ersetzt nicht die Tiefe, aber sie verhindert, dass entscheidende Basics übersehen werden.

L1: Flaps? Errors steigen? Optikwerte außerhalb Baseline?
L2: VLAN/Trunk-Drift? STP-Events? MAC-Flapping? LACP-Member konsistent?
L3: Neighbors stabil? Routes vollständig? Traceroute symmetrisch? MTU/PMTUD verdächtig?
L4: SYN/SYN-ACK/ACK sauber? Retransmissions/RTT-Spike? NAT/Conntrack eng?
L5: Session-Drops passen zu Idle/Keepalive/Failover? Sticky-Session auffällig?
L6: TLS/Cert/SNI/Cipher nur für bestimmte Clients/Standorte betroffen?
L7: 5xx/Latency/Dependency-Muster nach Standort/ISP/Clientklasse trennbar?

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.