Wenn Ping hohe Latenz oder Paketverlust zeigt, aber keinen Hinweis auf die Ursache gibt, ist MTR der logische nächste Schritt. Es kartiert jeden Router zwischen Quelle und Ziel, misst Latenz und Verlust an jedem Hop und läuft kontinuierlich — damit auch sporadische Probleme sichtbar werden.

Was MTR eigentlich macht

MTR (ursprünglich "Matt's Traceroute") kombiniert zwei klassische Tools:

Traceroute kartiert den Pfad, indem es Pakete mit steigenden TTL-Werten schickt. Jeder Router, der ein Paket mit TTL=0 verwirft, schickt eine ICMP-"Time Exceeded"-Nachricht zurück und verrät damit seine IP-Adresse und seine Position im Pfad.

Ping misst Round-Trip-Zeit und Paketverlust.

Ein normales Traceroute liefert einen einmaligen Snapshot. MTR läuft kontinuierlich und baut Statistiken auf — Durchschnittslatenz, Minimum, Maximum und Verlustzprozentsatz an jedem Hop. Damit werden sporadische Probleme sichtbar.

Wie man die Ausgabe liest

Jede Zeile ist ein Hop im Pfad. Die wichtigsten Spalten:

• Host — IP oder Hostname des Routers an diesem Hop. ??? bedeutet, der Router antwortet nicht auf TTL-Exceeded-Probes — das ist bei Transit-Routern normal und kein Fehler.
• Loss% — Prozentsatz der Probes ohne Antwort von diesem Hop.
• Avg — durchschnittliche Round-Trip-Zeit in Millisekunden.
• Wrst — schlechteste (höchste) gesehene Round-Trip-Zeit. Ausreißer hier deuten auf gelegentliche Überlastung hin.

Die wichtigste Regel: Paketverlust an einem mittleren Hop, der bei nachfolgenden Hops nicht bestehen bleibt, ist fast immer ein Router, der ICMP-Probes deprioritisiert — kein echter Verlust. Wenn Hop 5 20 % Verlust zeigt, Hop 6 und 7 aber 0 %, läuft der Traffic einwandfrei.

Echter Paketverlust zeigt sich an einem Hop und bleibt bei allen nachfolgenden Hops gleich hoch oder steigt weiter an.

Ein praktisches Beispiel

 1. 192.168.1.1           2ms   2ms   2ms   (Heimrouter)
 2. 10.200.0.1            6ms   6ms   7ms   (ISP-Edge)
 3. core1.isp.net         8ms   8ms   9ms
 4. ???                   ???              (kein ICMP — normal)
 5. peer.transit.net    210ms 215ms 240ms   (Sprung: +200ms)
 6. edge.target         215ms 218ms 245ms

Hops 1–3 sind sauber. Hop 4 antwortet nicht (normal). Hop 5 zeigt plötzlich 210ms, Hop 6 ähnlich. Das Problem liegt auf dem Link zwischen Hop 3 und Hop 5 — ein überlastetes oder schlecht gePeertes Transit-Segment fügt ~200ms Latenz hinzu.

Warum MTR von mehreren Standorten starten?

Das eigene MTR zeigt nur den Pfad vom eigenen ISP. Das MTR-Tool auf Check-Host läuft von 50+ globalen Knoten — das ist der richtige Ansatz für regionale Probleme:

• Ein Server in Frankfurt kann aus Deutschland 10ms Latenz haben, aber für Singapur-Traffic über New York routen.
• Eine CDN-Fehlkonfiguration schickt asiatische Nutzer möglicherweise in ein europäisches Rechenzentrum.
• Eine Peering-Absprache kann dazu führen, dass Pakete von bestimmten Carriern einen sehr langen Weg nehmen.

Immer MTR von der Region starten, aus der Nutzer klagen — nicht von da, wo man selbst sitzt.

MTR-Report mit dem Provider teilen

Wenn du einen Hosting-Provider oder ein Network Operations Center wegen eines Routing-Problems kontaktierst, ist ein MTR-Report aus der betroffenen Region genau das, was sie brauchen. Er zeigt, wo im Pfad das Problem liegt — das schränkt die Zuständigkeit sofort ein.

Check-Host generiert für jeden Test einen permanenten Report-Link — den einfach in das Support-Ticket einfügen statt rohen Output zu kopieren.