suche
ESC
Anmelden Konto anfragen

Capstone: Standort X offline

Abschluss-Szenario — eine reale Störung über die Tool-Stationen MTR, DNS und Ping methodisch lokalisieren.

First-Level Netzwerk 35 Min +250 XP

Worum geht’s

Freitagnachmittag: die Außenstelle „Standort X” meldet „komplett offline”. Die Geschäftsführung sitzt im Nacken, der Provider behauptet, alles sei grün. Jetzt zählt nicht Raten, sondern Methode: Du verbindest alles aus Pfad B — OSI-Schichten, Subnetting, DNS, Routing, Switching — und arbeitest dich mit mtr, dns-lookup und ping-checker zur Wurzel vor. Dieses Capstone führt dich durch genau diese Entscheidungskette.

Konzept

Dein Vorgehen folgt Divide-and-Conquer über drei Tool-Stationen, jede grenzt den Suchraum ein:

  • Station 1 — Erreichbarkeit (ping-checker): Kommt überhaupt etwas an? Antwortet die öffentliche IP des Standort-Gateways auf einen TCP-/HTTP-Check?
  • Station 2 — Pfad (mtr): Wo bricht der Weg ab? Endet der Trace im eigenen Netz, beim Provider oder erst kurz vor dem Ziel? Loss und RTT verraten die Strecke.
  • Station 3 — Name (dns-lookup): Ist die IP-Konnektivität da, aber „Namen gehen nicht”, liegt die Ursache in der Auflösung — A/MX/NS und TTL prüfen.

Leitprinzipien aus B6: eine Variable pro Test, vom Bekannten zum Unbekannten, und nach jedem Test notieren, was ausgeschlossen ist. Ein bleibender RTT-Sprung mit durchgereichtem Loss zeigt die defekte Strecke; saubere RTT + fehlende Namensantwort zeigt ein DNS-Problem.

Beispiel-Fall

Gegeben: Standort X meldet Totalausfall. Du arbeitest die Stationen ab:

  1. ping-checker auf das Standort-Gateway (öffentliche IP): antwortet → die Leitung und der Router leben. „Komplett offline” ist also falsch — etwas Spezifisches klemmt.
  2. mtr auf einen externen Zielserver: Hop 1–3 sauber, ab Hop 4 nur noch * und 100 % Loss, das bis zum Ziel durchgereicht wird. → Die Strecke hinter dem Provider-Core ist unterbrochen — ein Routing-/Peering-Problem außerhalb deines Netzes.
  3. Gegenprobe dns-lookup: Namen lösen normal auf, A-Records kommen → DNS ist nicht die Ursache. Bestätigt: das Problem ist der unterbrochene Pfad aus Schritt 2.
  4. Verdikt & Eskalation: Mit MTR-Beleg (Loss ab Hop 4, eigenes Netz + Gateway grün) eskalierst du gezielt an den Provider — mit Beweis statt Vermutung. Hätte Schritt 1 bereits versagt, läge die Ursache lokal (Link/VLAN/Gateway) und du wärst gar nicht erst nach außen gegangen.

Anwenden

▶ Am Tool ausprobieren

Reihenfolge je nach Symptom anpassen: „gar nichts geht” → mit ping/mtr starten; „nur Namen gehen nicht” → direkt zur DNS-Station.

  1. Station 1: Mit ping-checker die Erreichbarkeit des Ziels prüfen (HTTP/TCP).
  2. Station 2: Mit mtr den Pfad tracen — wo beginnt Loss, ist er bleibend?
  3. Station 3: Mit dns-lookup gegenprüfen, ob die Namensauflösung sauber ist.
  4. Schreibe je Station auf, was das Ergebnis ausschließt — und formuliere ein begründetes Verdikt.
Tool öffnen: /mtr ↗

Selbsttest

Szenario

Praxis-Challenge

⚑ Praxis-Challenge

Spiele den kompletten Fall durch: Wähle ein erreichbares und ein (bewusst falsches/nicht existierendes) Ziel. Durchlaufe alle drei Stationen — ping-checker, mtr, dns-lookup — und schreibe ein eskalationsfertiges Mini-Ticket: Symptom, durchgeführte Tests mit Ergebnis, je Test die ausgeschlossene Ursache, und ein begründetes Verdikt (lokal vs. Provider vs. DNS). Das ist exakt die Artefakt-Qualität, die im First-Level erwartet wird.

Tool öffnen: /mtr ↗

Modul im Speedrun testen →