suche
ESC

Routing — Gateway, Hops & RTT

Default-Gateway, Hop-für-Hop-Weiterleitung und MTR/RTT-Ausgaben sicher interpretieren.

First-Level Netzwerk 25 Min +150 XP

Worum geht’s

„Internet langsam” oder „Server nicht erreichbar” — bevor du das Problem dem Provider in die Schuhe schiebst, willst du wissen: Wo auf dem Weg klemmt es? Routing entscheidet, über welche Stationen (Hops) ein Paket zum Ziel läuft. Ein MTR- oder Traceroute-Bericht zeigt dir jeden Hop mit Laufzeit (RTT) und Paketverlust — daran liest du ab, ob das eigene Netz, das Gateway oder eine ferne Strecke das Problem ist.

Konzept

Ein Host kennt nur sein eigenes Subnetz. Alles, was nicht lokal ist, schickt er an sein Default-Gateway (die Route 0.0.0.0/0). Das Gateway leitet das Paket an den nächsten Router weiter — und so Hop für Hop, bis das Ziel erreicht ist. Jeder Router verringert die TTL (Time To Live, hier ein Hop-Zähler) um 1; erreicht sie 0, wird das Paket verworfen und ein ICMP-„Time Exceeded” zurückgeschickt. Genau das nutzt Traceroute: es schickt Pakete mit steigender TTL und sammelt, welcher Router jeweils antwortet.

RTT (Round-Trip Time) ist die Hin- und Rückzeit zu einem Hop in Millisekunden. Beim Lesen eines MTR-Berichts gilt:

  • RTT steigt mit der Distanz — ein langsamer Anstieg über die Hops ist normal.
  • Ein plötzlicher großer Sprung, der ab da bestehen bleibt, deutet auf einen Engpass an.
  • Einzelne hohe RTTs, die danach wieder sinken, sind oft nur Hops, die ICMP niedrig priorisieren — kein echtes Problem.
  • Paketverlust (Loss), der bis zum Ziel durchgereicht wird, ist relevant; Loss nur an einem Zwischen-Hop (ohne Folge) ist meist harmlos.

Beispiel-Fall

Gegeben: Zugriff auf example.com fühlt sich träge an. Dein MTR liefert (gekürzt):

Hop Host RTT
1 fritz.box 0,9 ms
2 dslb-gw 8,4 ms
3 core1.fra 12,7 ms
4 ae-2.r01 14,1 ms
5 example.com 16,0 ms
  1. Hop 1 ist dein Default-Gateway (Router daheim) — unter 1 ms, lokal alles gut.
  2. Hop 1 → 2 springt auf ~8 ms: der Übergang ins Provider-Netz (DSL-Strecke). Normal.
  3. Hop 2 → 5 steigt nur sanft (12 → 16 ms): gleichmäßiger Anstieg, kein Engpass.
  4. Kein Loss, kein Sprung — das Routing ist gesund. Die gefühlte Trägheit liegt nicht am Pfad; nächster Verdacht: DNS, Server-Antwortzeit oder Anwendung (L7).

Lehre: Ein sauberer, gleichmäßiger RTT-Verlauf entlastet das Netz als Ursache.

Anwenden

▶ Am Tool ausprobieren

Ein bleibender RTT-Sprung plus durchgereichter Loss ab demselben Hop grenzt die Störung auf genau diese Strecke ein.

  1. Starte einen MTR auf ein Ziel (z. B. eine öffentliche Domain).
  2. Identifiziere Hop 1 — das ist dein Default-Gateway.
  3. Lies den RTT-Verlauf: steigt er gleichmäßig oder gibt es einen bleibenden Sprung?
  4. Prüfe die Loss-Spalte: tritt Verlust erst am Ziel auf oder nur an einem Zwischen-Hop?
Tool öffnen: /mtr ↗

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Lasse einen MTR auf zwei verschiedene Ziele laufen (z. B. eine nahe und eine weit entfernte Domain). Vergleiche die RTT-Verläufe: Wo ist dein erster gemeinsamer Hop (dein Gateway)? Ab welchem Hop unterscheiden sich die Pfade? Schreibe in einem Satz auf, welcher Hop der wahrscheinliche Engpass wäre, falls Loss auftritt — und begründe es mit der „durchgereicht vs. einmalig”-Regel.

Tool öffnen: /mtr ↗

Modul im Speedrun testen →