suche
ESC

Netzwerk-Troubleshooting-Methodik

Bottom-up, Top-down und Divide-and-Conquer — Störungen strukturiert statt zufällig eingrenzen.

First-Level Netzwerk 25 Min +160 XP

Worum geht’s

„Geht nicht” ist kein Fehlerbild — es ist der Anfang einer Suche. Wer planlos Kabel steckt und Dienste neu startet, verliert Zeit und produziert Folgefehler. Eine Methodik gibt dir eine reproduzierbare Reihenfolge: Du grenzt das Problem Schicht für Schicht oder Hälfte für Hälfte ein, bis nur eine Ursache übrig bleibt — und dokumentierst dabei, was du ausgeschlossen hast.

Konzept

Es gibt drei bewährte Strategien, alle auf Basis des OSI-Modells:

  • Bottom-up — von L1 nach oben: Kabel/Link → IP/Subnetz → Gateway/Route → Port/Firewall → DNS/Anwendung. Stark, wenn ein physisches Problem wahrscheinlich ist (neuer Arbeitsplatz, „nichts geht mehr”).
  • Top-down — von L7 nach unten: Anwendung/Browser → DNS → Port → Routing → Link. Stark, wenn eine einzelne Anwendung klemmt, während der Rest läuft.
  • Divide-and-Conquer — Einstieg in der Mitte (L3/L4) und je nach Ergebnis nach oben oder unten. ping aufs Gateway klappt? → Problem liegt oberhalb (DNS/App). Klappt nicht? → Problem liegt unterhalb (Link/Switch/VLAN). Das halbiert den Suchraum pro Test und ist meist am schnellsten.

Goldene Regeln: eine Variable pro Test ändern, Ergebnisse notieren (was schließt der Test aus?), und vom Bekannten zum Unbekannten arbeiten. Werkzeuge je Ebene: Link-LED & ip a (L1/L3), ping Gateway (L3), ping Ziel-IP (L3 Pfad), mtr/Traceroute (Routing), nslookup/dns-lookup (L7-Namensauflösung), Telnet/Port-Check (L4).

Beispiel-Fall

Gegeben: Ein Nutzer meldet „Website firma-portal.de lädt nicht”. Divide-and-Conquer:

  1. Mitte — ping aufs Default-Gateway: antwortet → L1/L2 und lokale IP sind ok. Damit ist die untere Hälfte ausgeschlossen.
  2. ping auf eine bekannte öffentliche IP (z. B. 1.1.1.1): antwortet → Routing nach draußen funktioniert. Suchraum weiter eingegrenzt: Problem liegt oben.
  3. nslookup firma-portal.de: liefert keine Adresse → Namensauflösung defekt. Das ist die Ursache; IP-Konnektivität war nie das Problem.
  4. Gegenprobe: Aufruf per IP statt Name lädt die Seite → bestätigt: reines DNS-Problem.

Vier gezielte Tests statt zehn Zufallsversuche — und jeder Schritt hat etwas ausgeschlossen.

Selbsttest

Szenario

Praxis-Challenge

⚑ Praxis-Challenge

Wähle eine reale (oder erfundene) Störung und schreibe ein „Lauf-Protokoll”: Liste 4–6 Tests in Divide-and-Conquer-Reihenfolge, und notiere zu jedem, was ein positives bzw. negatives Ergebnis ausschließt. Markiere am Ende, an welchem Test du die Ursache festnageln konntest — und ob Bottom-up oder Top-down schneller gewesen wäre.

Modul im Speedrun testen →