OSI-basiertes „No-Connectivity“-Runbook: Von L1 bis L7

Ein OSI-basiertes „No-Connectivity“-Runbook ist eines der wirkungsvollsten Werkzeuge, um Verbindungsabbrüche im Netzwerk schnell, nachvollziehbar und reproduzierbar zu diagnostizieren. „No Connectivity“ wirkt in Tickets oft eindeutig („nichts geht mehr“), ist technisch aber ein Sammelbegriff für sehr unterschiedliche Ursachen: ein ausgefallener Uplink, ein VLAN-Fehler, eine fehlende Route, eine Firewall-Regel, ein DNS-Ausfall oder ein TLS-/HTTP-Problem, das wie „keine Verbindung“ erscheint. Genau hier spielt das OSI-Modell seine Stärke aus: Es zwingt zu einer strukturierten Vorgehensweise von Layer 1 bis Layer 7, ohne sich in Tools oder Herstellerdetails zu verlieren. Das Ziel dieses Runbooks ist nicht, jedes Problem sofort endgültig zu lösen, sondern in kurzer Zeit eine belastbare Eingrenzung zu erreichen: Welche Schicht ist betroffen, wie groß ist der Scope, welche Messpunkte belegen die Hypothese, welche Sofortmaßnahme ist sinnvoll, und an wen wird mit klaren Fakten eskaliert? Wenn Sie dieses OSI-basierte Runbook konsequent verwenden, reduzieren Sie Fehlannahmen, beschleunigen die Incident-Triage und verbessern gleichzeitig die Qualität Ihrer Dokumentation und Kommunikation im Team.

Runbook-Prinzipien: Was „No Connectivity“ wirklich bedeutet

„No Connectivity“ ist kein einzelnes Symptom, sondern das Ergebnis eines fehlgeschlagenen Kommunikationsversuchs. In der Praxis kann bereits eine nicht auflösbare Adresse („Name nicht gefunden“) als „keine Verbindung“ wahrgenommen werden, obwohl Layer 1–4 in Ordnung sind. Umgekehrt kann ein Layer-1-Problem alle höheren Schichten vollständig lahmlegen. Dieses Runbook folgt daher drei Prinzipien:

• Von unten nach oben, aber pragmatisch: Beginnen Sie bei Layer 1–3 mit schnellen Ausschlusskriterien, ohne starr zu bleiben.
• Messdaten vor Vermutung: Jede Entscheidung sollte durch mindestens einen konkreten Test oder Monitoring-Indikator gestützt sein.
• Scope zuerst: „Wer ist betroffen?“ entscheidet Priorität, Eskalation und den wahrscheinlichsten Fehlerbereich.

Eine solide Grunddefinition des OSI-Modells finden Sie über den Einstieg zum OSI-Modell. Für verlässliche Protokoll-Referenzen sind RFCs die robusteste Quelle, z. B. RFC 1122 (Internet Host Requirements).

Vorbereitung: Minimales Set an Checks und Informationen

Ein Runbook ist nur so gut wie seine Umsetzbarkeit unter Zeitdruck. Legen Sie daher ein minimales Set fest, das fast immer verfügbar ist: ein Monitoring-Dashboard, Zugriff auf Edge-/Core-Status (oder zumindest Telemetrie), ein Tool für aktive Tests (Ping/Traceroute/Port-Check) und Ticket-/ChatOps-Kontext.

• Ticket-Basisdaten: Zeitpunkt, betroffener Service, Standort/Region, Anzahl Betroffener, letzte Changes/Deployments.
• Aktive Tests: Namensauflösung (DNS), Reachability (ICMP oder Alternativen), Port-Erreichbarkeit (TCP/UDP), Pfad (Traceroute/MTR).
• Telemetrie: Interface-Status, Fehlerzähler, Routing-Adjacencies, Firewall-Drops, Load-Balancer-Health.

Schritt 0: Scope, Impact und Reproduzierbarkeit

Bevor Sie Layer prüfen, klären Sie in unter einer Minute den Scope. Das verhindert, dass Sie ein lokales Problem wie einen globalen Incident behandeln oder umgekehrt.

• Scope: Betrifft es einen User, ein Subnetz, ein VLAN, einen Standort, eine Region oder alle?
• Impact: Ist es ein kompletter Ausfall oder nur ein bestimmter Dienst/Port?
• Zeit: Seit wann? Korrelieren Startzeit und ein Change (Maintenance, Release, Provider-Event)?
• Reproduzierbarkeit: Lässt sich der Fehler aus zwei unterschiedlichen Quellen nachstellen (z. B. Client + Monitoring-Probe)?

Layer 1: Physikalisch – Link, Medium, Fehlerzähler

Layer 1 ist der schnellste „Hard Stop“: Wenn der Link down ist oder Fehlerzähler explodieren, sparen Sie sich jede weitere Analyse in höheren Schichten, bis die physische Basis stabil ist.

Symptome, die stark auf Layer 1 hindeuten

• Interface down/down, häufiges Link Flapping
• CRC-/FCS-Errors, Input Errors, starke Drops auf dem Interface
• Duplex-/Speed-Mismatch (typisch: hohe Errors, instabile Performance)
• Optische Werte außerhalb Grenzbereich (Fiber: Tx/Rx Power)

Runbook-Checks auf Layer 1

• Status: Ist das betroffene Interface administrativ up und operativ up?
• Fehlerzähler: Steigen CRC/Drops kontinuierlich? Lokal oder auf beiden Link-Seiten?
• Physik: Bei Fiber: optische Pegel prüfen; bei Kupfer: Autonegotiation/Speed/Duplex konsistent?
• Transport: Gibt es Provider-Alarme (LOS/LOF) oder bekannte Wartungsfenster?

Für Ethernet-Grundlagen und Standards ist der Einstieg über IEEE Standards eine hilfreiche Referenz.

Layer 2: Data Link – VLAN, Switching, ARP, STP

Wenn Layer 1 gesund wirkt, sind Layer-2-Fehler besonders häufige Ursachen für „No Connectivity“ innerhalb eines Standorts oder einer Broadcast-Domäne. Typische Auslöser sind falsche VLAN-Zuordnungen, STP-Events, Loops, MAC-Flapping oder ARP-Anomalien.

Symptome, die auf Layer 2 passen

• Nur ein VLAN/Subnetz betroffen, andere funktionieren
• Intermittierende Erreichbarkeit, besonders lokal (z. B. Gateway im gleichen Segment)
• STP-Topology-Changes, Ports im Blocking/Err-Disable
• MAC-Flapping oder plötzlich „unbekannte“ MACs auf Uplinks
• ARP-Timeouts, Duplicate IP Verdacht, ARP-Entries fehlen

Runbook-Checks auf Layer 2

• VLAN-Pfad: Access-Port/VLAN korrekt? Trunk erlaubt VLAN? Native VLAN konsistent?
• STP: Topology-Changes? Root-Bridge wie erwartet? Port-Role/State plausibel?
• MAC/ARP: MAC-Learning stabil? ARP-Cache enthält Gateway und Ziel korrekt?
• Broadcast/Storm: Ungewöhnliche Broadcast-/Multicast-Spitzen, Storm-Control Events?

ARP als Baustein zwischen Layer 2 und 3 ist in RFC 826 (ARP) beschrieben.

Layer 3: Network – IP, Routing, Gateway, MTU

Layer 3 ist der Kern für echte „Reachability“-Probleme zwischen Netzen. Hier geht es um Routing, Default Gateways, Netzmasken, ACLs auf L3, asymmetrische Pfade und MTU-Themen. Im No-Connectivity-Runbook sind die wichtigsten Fragen: Erreicht der Client sein Gateway? Gibt es eine Route zum Ziel? Bricht der Pfad an einer bestimmten Stelle?

Symptome, die auf Layer 3 hindeuten

• Gateway nicht erreichbar (Client im gleichen VLAN, aber kein ARP/kein Ping)
• Nur bestimmte Zielnetze nicht erreichbar, andere schon
• Traceroute endet an einem bestimmten Hop oder springt unerwartet
• MTU-Probleme: kleine Pakete funktionieren, große hängen (PMTUD/Fragmentierung)

Runbook-Checks auf Layer 3

• Gateway-Test: Erreicht der Client sein Default Gateway? Wenn nein: zurück zu L2/L1.
• Pfadtest: Traceroute/MTR von zwei Perspektiven (Client-Seite und Core/Probe).
• Routing: Existiert eine Route zum Ziel? Richtiger Next-Hop? Routing-Policy/VRF korrekt?
• MTU-Indikatoren: Hinweise auf Fragmentation Needed oder Blackholing bei großen Paketen.

Die grundlegende IPv4-Spezifikation ist RFC 791, PMTUD wird u. a. in RFC 1191 behandelt.

Layer 4: Transport – TCP/UDP, Ports, Firewalls, NAT

Sehr häufig ist „No Connectivity“ in Wahrheit ein Layer-4-Problem: Der Host ist erreichbar, aber der Dienstport nicht. Oder UDP-Verkehr wird durch NAT/State-Timer, Firewall-Policies oder Load-Balancer-Healthchecks beeinträchtigt. Der Schlüssel in der Triage ist die Unterscheidung: Timeout, Reset oder „Connection refused“.

Symptome, die typisch für Layer 4 sind

• Ping/ICMP funktioniert, aber TCP-Verbindungen bauen nicht auf (Timeout)
• „Connection refused“ oder TCP RST (Dienst/Port erreichbar, aber lehnt ab)
• Nur bestimmte Ports betroffen (z. B. 443 down, 22 ok)
• Probleme nach Lastspitzen (NAT-/State-Table Exhaustion)
• Asymmetrisches Routing führt zu State-Drops auf Firewalls

Runbook-Checks auf Layer 4

• Port-Erreichbarkeit: TCP SYN/SYN-ACK? Bei Timeout: Drop/Filter vermuten.
• Reset vs. Timeout: Reset deutet auf aktives Ablehnen oder Dienstproblem, Timeout eher auf Filter/Pfad.
• Firewall/ACL: Gab es Regeländerungen? WAF-Policies? Geo-Blocking?
• NAT/State: Session-Zähler, Drops, Ressourcenlimits, Timeouts prüfen.

Für TCP-Verhalten und Semantik ist RFC 9293 (TCP) eine zentrale Referenz.

Layer 5: Session – Sitzungen, Auth-Flows, Stateful Middleboxes

Layer 5 wird in vielen Umgebungen nicht als eigener „Troubleshooting-Block“ wahrgenommen, ist aber praktisch relevant: Session-Handling, Wiederaufnahme von Sitzungen, Timeouts, Proxy-States, VPN-Tunnel-States oder Authentifizierungsflüsse können „No Connectivity“ verursachen, obwohl Ports grundsätzlich offen sind.

Wann Layer 5 wahrscheinlich ist

• Verbindung klappt kurz, bricht dann reproduzierbar nach einer festen Zeit ab
• Nur angemeldete Nutzer betroffen, anonyme Requests funktionieren
• VPN/Proxy-Tunnel etabliert sich, Datenverkehr fließt jedoch nicht stabil

Runbook-Checks auf Layer 5

• Session-Timeouts: Gibt es fixe Abbruchzeiten (z. B. 30/60 Sekunden, 15 Minuten)?
• Stateful Komponenten: Proxy, VPN-Gateway, Firewall-Cluster – State-Sync ok?
• Auth-Korrelation: Tritt der Fehler nach Login/Token-Refresh auf?

Layer 6: Presentation – TLS, Zertifikate, Verschlüsselung

Viele Nutzer melden „keine Verbindung“, wenn eigentlich ein TLS-Problem vorliegt: abgelaufene Zertifikate, falsche Hostnames, fehlende Intermediate CAs oder SNI-Mismatches. Für das Runbook heißt das: Wenn TCP 443 erreichbar ist, aber der Handshake scheitert, ist Layer 6 ein Top-Kandidat.

Typische TLS-Symptome

• Zertifikat abgelaufen oder noch nicht gültig
• Hostname passt nicht (SAN/CN), SNI zeigt auf falsches Backend
• Chain-Probleme (Intermediate fehlt), Client-spezifische Fehler
• Cipher/Protocol-Mismatch nach Hardening oder Update

Runbook-Checks auf Layer 6

• Handshake: Scheitert er sofort oder nach ClientHello/ServerHello?
• Zertifikatdetails: Ablaufdatum, SAN, Ausstellerkette, OCSP/CRL-Hinweise.
• SNI: Wird der korrekte Hostname präsentiert, besonders bei Multi-Tenant-LBs?

Layer 7: Application – DNS, HTTP, APIs, Fehlercodes

Layer 7 ist häufig der Ort, an dem „No Connectivity“ sichtbar wird, obwohl die eigentliche Ursache darunter liegt. Gleichzeitig gibt es echte Layer-7-Ausfälle: DNS-Resolver down, falsche DNS-Antworten, HTTP 5xx, API-Gateway-Fehler, Rate-Limits oder fehlerhafte Deployments. Entscheidend ist, DNS als frühe Abhängigkeit nicht zu vergessen.

Typische Layer-7-Symptome

• DNS: NXDOMAIN, SERVFAIL, Timeouts bei Auflösung
• HTTP: 4xx/5xx, ungewöhnliche Redirects, lange TTFB
• API: 429 Rate Limit, 503 Upstream unavailable, Gateway-Timeouts
• Nur bestimmte Endpoints betroffen, andere funktionieren

Runbook-Checks auf Layer 7

• DNS zuerst: Löst der Name korrekt auf? Richtige Records (A/AAAA/CNAME), plausible TTL?
• HTTP-Signal: Statuscode, Antwortzeit, Header (Cache, Location, Server) prüfen.
• Backend-Korrelation: Startzeit vs. Deployment, nur bestimmte Region/PoP betroffen?
• Abhängigkeiten: IdP/SSO, Datenbank, Message Queue – zeigen diese parallel Störungen?

DNS-Grundlagen sind in RFC 1034 beschrieben, HTTP-Semantik in RFC 9110.

Entscheidungsbaum: Schnell zur richtigen Schicht

Um das Runbook im Alltag zu beschleunigen, hilft ein einfacher Entscheidungsbaum, der typische „No Connectivity“-Meldungen strukturiert. Er ersetzt keine Expertise, sorgt aber für Konsistenz.

• Link down oder Errors hoch? → Layer 1 priorisieren.
• Gateway nicht erreichbar? → Layer 2/1 priorisieren (VLAN/ARP/Loop).
• Gateway ok, aber Zielnetz nicht erreichbar? → Layer 3 (Routing/VRF/ACL/MTU).
• Zielhost erreichbar, Port nicht? → Layer 4 (Firewall/NAT/Policy/State).
• Port erreichbar, aber TLS/HTTP scheitert? → Layer 6/7 (Zertifikat/DNS/App).

Messwerte, die „No Connectivity“ objektiv machen

Für saubere Eskalationen sind zwei Zahlen besonders nützlich: Paketverlust und Erfolgsquote von Tests. Beide lassen sich in der Triage mit einfachen Berechnungen beschreiben. Wenn Sie beispielsweise eine Serie von aktiven Tests auswerten, kann die Erfolgsquote (Success Rate) die Stabilität eines Pfads quantifizieren.

$\mathrm{Erfolgsquote}=\frac{\mathrm{erfolgreiche} \mathrm{Tests}}{\mathrm{Gesamttests}}\times 100\%$

Eine niedrige Erfolgsquote bei ICMP und TCP deutet eher auf Layer 1–3 hin; eine hohe ICMP-Erfolgsquote bei gleichzeitigem TCP-Timeout ist ein starkes Layer-4-Signal. Nutzen Sie solche Messwerte, um Diskussionen zu verkürzen und den nächsten Owner schneller zu finden.

Dokumentations-Template für Tickets und Handover

Ein OSI-basiertes Runbook entfaltet seine volle Wirkung erst dann, wenn die Ergebnisse standardisiert dokumentiert werden. So verhindern Sie Doppelarbeit und ermöglichen eine saubere Übergabe an 2nd/3rd Level.

• Symptom: Wortlaut, Fehlertext, Zeitpunkt, betroffener Host/Service
• Scope: Nutzergruppen, Region, VLAN/Subnetz, betroffene Abhängigkeiten
• OSI-Layer-Hypothese: Verdächtige Schicht + kurze Begründung
• Messpunkte: Von wo nach wo getestet, womit, Ergebnis (Timeout/Reset/Statuscode)
• Mitigation: Workaround, Failover, Rollback, temporäre Regel (inkl. Risiko)
• Nächster Schritt: Konkrete Aktion + verantwortliches Team/On-Call

Häufige Stolperfallen und robuste Gegenmaßnahmen

Auch ein gutes Runbook kann scheitern, wenn typische Denkfehler auftreten. Die folgenden Gegenmaßnahmen sind bewusst einfach und im NOC-Alltag praktikabel.

• ICMP ist blockiert: Wenn Ping „down“ ist, prüfen Sie zusätzlich TCP-Port-Erreichbarkeit oder einen echten Service-Request.
• Nur eine Perspektive: Testen Sie von mindestens zwei Quellen (Client/Probe/Core), um lokale Effekte auszuschließen.
• DNS vergessen: Bei „No Connectivity“ im Browser zuerst DNS-Auflösung prüfen, bevor Sie komplexe Netzwerkpfade analysieren.
• Asymmetrisches Routing: Bei stateful Firewalls und NAT ist Asymmetrie ein häufiger Root Cause – Indikatoren aktiv suchen.
• Zu früh Layer 7: Ohne Layer 1–3 Quick Checks sind App-Hypothesen oft ineffizient und führen zu langen Wartezeiten.

Outbound-Referenzen für Runbook-Pflege und Standardisierung

Für Teams, die das Runbook als Wissensbasis pflegen, sind stabile externe Referenzen sinnvoll, um Begriffe, Protokolle und Portzuordnungen konsistent zu halten. Neben den RFCs ist die IANA-Registry für Service Names und Port Numbers besonders hilfreich, wenn Ports in Tickets unklar dokumentiert sind. Für HTTP-Fehlerbilder können Spezifikationen wie RFC 9110 und technische Grundlagenartikel zu Statuscodes als Referenz dienen, ohne dass Sie in jedem Incident neu diskutieren müssen.

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.