February 14, 2026

Troubleshooting-Checkliste nach den 7 OSI-Schichten

Eine Troubleshooting-Checkliste nach den 7 OSI-Schichten ist eines der effektivsten Werkzeuge, um Netzwerkprobleme strukturiert, schnell und nachvollziehbar zu lösen. Statt wahllos Einstellungen zu ändern oder Geräte neu zu starten, arbeiten Sie mit einer klaren Reihenfolge: von der physikalischen Basis (Kabel, Signal, Link) über Switching und Adressierung bis hin zu DNS, HTTPS und Anwendungsdiensten. Genau diese Struktur reduziert Fehlinterpretationen, weil Symptome auf höheren Ebenen (z. B. „Webseite lädt nicht“) oft durch Ursachen auf niedrigeren Ebenen ausgelöst werden (z. B. falsches VLAN oder fehlendes Default Gateway). Die OSI-Methode hilft außerdem bei der Dokumentation: Sie können Ergebnisse pro Schicht festhalten, Hypothesen sauber testen und die Root Cause später leichter erklären. Diese Checkliste ist bewusst praxisorientiert aufgebaut und eignet sich für Einsteiger ebenso wie für Fortgeschrittene und Profis: Sie enthält typische Fehlerbilder, konkrete Prüfpunkte, sinnvolle Abzweigungen („Wenn X, dann Y“) sowie Hinweise, welche Belege Sie sammeln sollten, um Diagnosen belastbar zu machen.

Table of Contents

So nutzt du die Checkliste richtig

Die OSI-Checkliste funktioniert am besten, wenn Sie vor dem ersten Test drei Dinge klären: (1) Was genau ist kaputt? (nur Internet, nur interne Ziele, nur ein Dienst?) (2) Wer ist betroffen? (ein Gerät, eine Abteilung, ein VLAN, ein Standort?) (3) Seit wann? (nach Änderung, nach Update, zeitabhängig, unter Last?). Danach gehen Sie schichtweise vor. Wichtig: Sie müssen nicht immer alle sieben Schichten vollständig prüfen. Sobald eine Schicht eindeutig fehlerhaft ist, wird dort vertieft, bis eine plausible Root Cause gefunden und bestätigt ist.

Arbeite von unten nach oben: Erst Signal/Link, dann Switching/VLAN, dann IP/Routing, dann Ports/Firewall, dann Dienste.
Teste immer gegen einen klaren Messpunkt: Gateway, DNS-Server, interner Dienst, externer Dienst.
Trenne Symptom und Ursache: „DNS geht nicht“ ist häufig ein Symptom, nicht die Ursache.
Sammle Belege: Messwerte, Logauszüge, Zeitstempel, Konfigurationsänderungen.

Vorab: Drei schnelle Orientierungstests (ohne in Details abzutauchen)

Diese drei Tests helfen, den Suchraum sofort zu verkleinern, bevor Sie in die schichtweise Detailprüfung gehen.

Test A: Erreichbarkeit des Default Gateways (lokales Routing): Wenn das Gateway nicht erreichbar ist, liegt der Fokus fast immer auf Schicht 1–3.
Test B: DNS-Auflösung (Name → IP): Wenn IP-Ziele erreichbar sind, aber Namen nicht, liegt der Fokus oft auf Schicht 7 oder Policies auf Schicht 3/4.
Test C: HTTPS-Verbindung zu einem stabilen Ziel (z. B. ein bekannter Dienst): Wenn DNS ok ist, aber HTTPS nicht, liegt der Fokus häufig auf Schicht 4–7 (Firewall, Proxy, TLS).

Für Hintergrundwissen zu IP und DNS sind diese Referenzen hilfreich: IPv4-Spezifikation (RFC 791) und DNS-Spezifikation (RFC 1035).

Schicht 1: Physical Layer – Signal, Kabel, Funk, Strom

Schicht 1 ist die Grundlage: Ohne stabile physische Übertragung ist alles darüber unzuverlässig. Fehler hier wirken oft „sporadisch“ und werden fälschlich für Software- oder DNS-Probleme gehalten.

Link-Status prüfen: Leuchtet die Link-LED? Gibt es Port-Flaps (ständig up/down)?
Kabeltest: anderes Patchkabel, andere Dose, anderer Switchport, Sichtprüfung auf Knicke/Brüche.
WLAN-Signal: Signalstärke, Abstand zum Access Point, Hindernisse, Interferenzen (2,4/5/6 GHz).
Strom/PoE: Access Point oder VoIP-Telefon rebootet? Netzteil/PoE-Budget ok?
Transceiver/Fiber: SFP kompatibel, Faser sauber, richtige Wellenlänge/Typ.

Typische Symptome: hohe Paketverluste, stark schwankende Latenz, Verbindungsabbrüche, „nur manchmal geht’s“.

Schicht 2: Data-Link-Layer – Switching, VLAN, MAC, STP

Wenn die physische Verbindung steht, geht es um Frames, MAC-Adressen und Segmentierung. VLAN-Fehler und Loop-Schutzmechanismen sind häufige Root Causes, weil sie „Connectivity“ gezielt verhindern können, ohne dass der Link down ist.

VLAN-Zugehörigkeit: Endgerät im richtigen VLAN (Access-Port) oder korrekt getaggt (Trunk)?
Trunk-Allowed-VLANs: Ist das VLAN auf allen relevanten Uplinks erlaubt?
Native VLAN Konsistenz: Ungetaggte Frames dürfen nicht „versehentlich“ in falsche VLANs laufen.
MAC-Learning: Lernt der Switch die MAC am erwarteten Port? Kein MAC-Flapping?
STP/Loop-Schutz: Port blockiert STP einen Link? Gibt es Broadcast-Stürme?
Port-Security/NAC: Port in Quarantäne/Violation, weil zu viele MACs oder falsche Auth?

Hilfreicher Einstieg zu VLAN-Tagging: IEEE 802.1Q im Überblick. Zu ARP als Bindeglied zwischen Schicht 2 und 3: ARP (RFC 826).

Schicht 3: Network Layer – IP-Adresse, Subnetz, Gateway, Routing, MTU

Schicht 3 entscheidet, ob Geräte ihre eigenen Netze verlassen können und ob Antworten wieder zurückfinden. Sehr viele „kein Internet“-Fälle sind letztlich Schicht-3-Probleme (falsches Gateway, DHCP-Fehler, Routing, IP-Konflikte).

IP-Konfiguration plausibel? IP-Adresse im richtigen Subnetz, Subnetzmaske korrekt, kein APIPA/169.254.x.x ohne Absicht.
Default Gateway vorhanden? Ohne Gateway kein Weg nach außen (außer rein lokal).
Gateway erreichbar? Wenn nein: VLAN, ARP, SVI/Router-Interface, lokale Policies prüfen.
Routing korrekt? Gibt es eine Route zum Zielnetz und eine Rückroute? Keine asymmetrischen Pfade?
IP-Konflikte: Ungewöhnliche Instabilität, „falsches Gerät antwortet“, wechselnde Erreichbarkeit.
MTU/PMTUD: Kleine Pakete gehen, große hängen? ICMP „Packet Too Big“/„Fragmentation needed“ wird möglicherweise gefiltert.

IP-Referenzen: IPv4 (RFC 791) und IPv6 (RFC 8200). Path MTU Discovery: PMTUD für IPv4 (RFC 1191).

Mini-Formel: Warum Overhead die Nutzlast reduziert

$Nutzdaten = MTU - IP-Header - Transport-Header - Tunnel-Overhead$

Wenn z. B. ein VPN aktiv ist, steigt der Overhead. Dadurch können Pakete, die ohne VPN funktionieren, im Tunnel zu groß werden und verworfen werden. Das wirkt dann wie „Zufallsfehler“ bei bestimmten Webseiten oder Downloads.

Schicht 4: Transport Layer – TCP/UDP, Ports, Firewalls, Timeouts

Auf Schicht 4 geht es darum, ob Verbindungen über definierte Ports funktionieren und ob Rückverkehr zuverlässig ankommt. Viele Probleme sind hier nicht technisch „kaputt“, sondern policy-bedingt (ACLs, Firewalls, NAT, Rate Limits).

TCP vs. UDP unterscheiden: Echtzeit (VoIP, Gaming, Video) reagiert anders als TCP-basierte Downloads.
Port-Blockaden: Funktioniert z. B. Ping (ICMP), aber HTTPS (443) nicht? Das deutet auf Filtering hin.
Timeout vs. Reset: Timeout spricht oft für „Dropped/Blocked“, Reset eher für „Port closed“ oder Dienst nicht aktiv.
Stateful Firewall/NAT: Geht der Hinweg raus, kommt die Antwort zurück? Fehlt State, brechen Sessions ab.
Congestion/Queue Drops: Problem nur unter Last? Dann QoS, Buffering, Uplink-Überlast prüfen.

Transportgrundlagen: TCP (RFC 793) und UDP (RFC 768).

Schicht 5: Session Layer – Sitzungsaufbau, Timeouts, Captive Portals, VPN

Schicht 5 wird im Alltag oft übersehen, ist aber wichtig, wenn Verbindungen „kurz gehen und dann abbrechen“ oder wenn der Zugriff erst nach einer Anmeldung möglich ist.

Captive Portal: Hotel/Guest-WLAN: verbunden, aber Internet erst nach Login. Bis dahin wirkt es wie „kein Internet“.
VPN-Sessions: Tunnel steht, aber Traffic ist instabil oder nur teilweise geroutet (Split-Tunnel/Split-DNS).
Session-Timeouts: Verbindungen sterben nach festen Zeitfenstern (z. B. NAT-Timeouts, Idle-Timeouts).
Roaming-Probleme: Bei WLAN-Roaming wechseln Clients den AP, Sessions reißen, Apps wirken „hängen geblieben“.

Praktischer Hinweis: Wenn ein Problem nach Reconnect sofort kurz besser ist, aber wiederkommt, sind Session- und Timeout-Themen wahrscheinlicher als reine IP-Adressfehler.

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

Schicht 6 ist relevant, wenn Verbindungen technisch stehen, aber sichere Kommunikation scheitert. Besonders in Unternehmensnetzen kann TLS-Inspection oder ein Proxy zu Fehlerbildern führen, die wie „Internet kaputt“ wirken.

TLS-Handshake scheitert: Zertifikatswarnungen, „Secure Connection Failed“, Abbrüche bei HTTPS.
Systemzeit falsch: Zertifikate wirken ungültig, obwohl das Netz ok ist.
Inspection/Proxy-CA fehlt: Endgeräte vertrauen der ausstellenden CA nicht, Verbindungen brechen ab.
Alte Clients/Protokolle: Inkompatible TLS-Versionen oder Cipher Suites können Handshakes verhindern.

Ein gut verständlicher Einstieg: MDN: Transport Layer Security.

Schicht 7: Application Layer – DNS, DHCP, HTTP, Proxy, Authentifizierung

Schicht 7 ist dort, wo Nutzer Probleme zuerst wahrnehmen: Webseiten laden nicht, E-Mails gehen nicht raus, Apps melden „Server nicht erreichbar“. Root Causes können hier liegen (z. B. DNS-Ausfall), aber sehr häufig sind es nur die sichtbarsten Symptome tieferer Schichten.

DNS: Namen werden nicht aufgelöst, nur IP-Zugriffe funktionieren. Resolver erreichbar? Richtige DNS-Server verteilt?
DHCP: keine IP, falsches Gateway/DNS, falsche Lease-Optionen, DHCP-Relay fehlt.
HTTP/HTTPS: Statuscodes, Redirects, Proxy-Pflicht, Content-Filter.
Proxy: Falscher Proxy-Eintrag blockiert alles, obwohl Ping und DNS ok sind.
Identity/Auth: 802.1X/NAC, SSO, Token-Probleme können Zugriff verhindern, obwohl Netzwerk ok ist.

DNS-Standards: DNS Concepts (RFC 1034) und DNS Specification (RFC 1035). DHCP: DHCP (RFC 2131).

Checkliste als Ablaufplan: „Wenn–Dann“-Logik für schnelle Entscheidungen

Diese OSI-basierte Entscheidungslogik ist besonders nützlich, wenn Sie unter Zeitdruck sind oder mehrere Teams involviert sind.

Wenn der Link down ist: Schicht 1 prüfen (Kabel, Port, PoE, Funk), danach Schicht 2 (administrativ down, Negotiation).
Wenn Link up, aber keine IP: Schicht 2 (VLAN/Trunk/NAC) und Schicht 7 (DHCP/Relay) prüfen.
Wenn IP da, aber Gateway nicht erreichbar: Schicht 2 (ARP/VLAN) und Schicht 3 (SVI/Router-Interface) prüfen.
Wenn Gateway erreichbar, aber DNS nicht: Schicht 7 (DNS) und Schicht 3/4 (Policy zum Resolver) prüfen.
Wenn DNS ok, aber Web nicht: Schicht 4 (443/Proxy/Firewall) und Schicht 6 (TLS) prüfen.
Wenn alles geht, aber nur langsam/instabil: Schicht 1/2 (WLAN, Loss, Retransmissions) und Schicht 3/4 (Congestion, QoS) prüfen.

Dokumentations-Template: So machst du deine Diagnose „beweisbar“

Eine gute Root-Cause-Analyse ist nicht nur „ich glaube“, sondern „ich kann zeigen“. Für jede Schicht lohnt sich ein kurzer Befundblock:

Schicht: z. B. L2
Messpunkt: z. B. Switchport X, VLAN Y, Gateway Z
Beobachtung: z. B. MAC-Flapping, STP blockt Port, VLAN nicht erlaubt
Test: z. B. Port auf korrektes VLAN gesetzt, Trunk-Liste erweitert
Ergebnis: z. B. DHCP-Lease kommt durch, Gateway erreichbar
Zeitstempel: Wann getestet und wann behoben

So können Sie später nachvollziehbar erklären, warum eine Maßnahme die Root Cause war und nicht nur ein zufälliger Workaround.

Qualitätsindikatoren: Loss, Latenz und Jitter als schnelle Plausibilitätsprüfung

Selbst ohne tiefes Tooling können Sie mit drei Qualitätsindikatoren viel erkennen: Paketverlust, Latenz und Jitter. Ein einfaches Denkmodell hilft bei der Einordnung:

$Erlebnisqualität \approx \frac{1}{1 + Loss + Jitter + Latenz}$

Diese Formel ist kein Standard, aber als Orientierung hilfreich: Schon moderate Werte bei Loss oder Jitter können Echtzeitdienste massiv beeinträchtigen, auch wenn Bandbreite ausreichend ist.

Typische Fehlerbilder nach Schichten (Kurzliste zum Mitnehmen)

Schicht 1: schwaches WLAN, defektes Kabel, Port-Flaps, PoE-Probleme
Schicht 2: falsches VLAN, Trunk erlaubt VLAN nicht, STP blockt, Port-Security/NAC sperrt
Schicht 3: falsches Gateway, IP-Konflikt, Routing fehlt, MTU/PMTUD hängt
Schicht 4: Firewall/ACL droppt Ports, NAT-State fehlt, Überlast unter Last
Schicht 5: Captive Portal nicht abgeschlossen, VPN-Sitzungen brechen ab, Idle-Timeout
Schicht 6: TLS-Zertifikatsfehler, falsche Systemzeit, Inspection-CA fehlt
Schicht 7: DNS-Resolver gestört, DHCP-Optionen falsch, Proxy falsch konfiguriert

Outbound-Links für vertiefendes Verständnis

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.