MTR ist ein ICMP (ping) Tool, das es ermöglicht Netzwerkprobleme zu diagnostizieren und einzugrenzen. Durch ein kontinuierliches traceroute/tracert werden die Router (Hops), die das IP-Packet bis zum abgefragten Rechner passiert, angezeigt.

Ping wird oft eingesetzt um die Netzwerkverbindung zwischen zwei Hosts zu testen. Bei einem Pingtest sendet der Quellhost einen ICMP echo request zum Zielhost. Der Zielhost antwortet wiederum mit einem ICMP echo reply. MTR legt die Hops zwischen Quell- und Zielhost offen, indem es die TTL (Time to Live) des IP-Pakets schrittweise um eins erhöht. Die TTL verhindert, dass IP-Pakete endlos im Internet herumgeroutet werden. Jeder Router, den ein IP-Paket passiert, verringert daher die TTL um eins. Wenn ein Router die TTL auf 0 setzt, schickt der Router eine Meldung an den Quellhost.

Inhaltsverzeichnis dieser Seite

Installation

Linux

Debian / Ubuntu

apt update && apt upgrade
apt install mtr-tiny

CentOS / RHEL / Fedora

yum update
yum install mtr

Windows

Für Windows gibt es einen Port von MTR namens "WinMTR". Diese Anwendung kann von der Upstream-WinMTR heruntergeladen werden.

MacOS

Auf MacOS kann MTR entweder mit Homebrew oder MacPorts genutzt werden.

brew install mtr

Um MTR mit MacPorts zu installieren, führen Sie folgendes aus:

port install mtr

MTR auf Unix-basierten Systemen

Generieren Sie MTR-Berichte mit folgender Syntax:

mtr -rw [destination_host]

Um beispielsweise die Route zum Destinationhost example.com zu testen.

mtr -rw example.com

MTR auf Windows-Systemen

MTR unter Windows verwendet eine grafische Benutzeroberfläche. Öffne WinMTR, gib den Zielhost in das Feld ein, wenn du dazu aufgefordert wirst, und wähle die Option "starten", um zu beginnen.

Ihr Server: Bidirektionale MTR-Berichte

Ein MTR-Bericht für deinen Server kann von deinem lokalen Computer aus generiert werden. Ersetze die ip durch die IP-Adresse deines Server:

mtr -rw ip

Baue eine SSH-Verbindung zu deinem Server auf. Ersetze die ip durch die IP-Adresse deines Computers (ggf. Ihr Firmen- oder Heimnetzwerk).

Wenn du deine öffentliche IP-Adresse nicht kennst, verwende WhatIsMyIP.com .

Das -r Options-Flag generiert den Bericht (kurz für --report).
Das -w Options-Flag verwendet die Langversion des Hostnamens, so dass unsere Techniker und du den vollständigen Hostnamen jedes Hops (kurz für --report-wide) sehen können.
Das -c Optionsflag legt fest, wie viele Pakete im Bericht gesendet und aufgezeichnet werden. Wenn sie nicht verwendet wird, ist die Standardeinstellung 10.

MTR Reports

Die folgenden MTR-Report Beispiele wurden für den Zielhost www.internetx.com und der --report-wide Option generiert.

$ mtr --report-wide www.internetx.org
HOST: example                                                 Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. kabel                                                     0.0%    10    1.6   2.0   1.6   2.7   0.3
  2. ip53a9b757.static.kabel-deutschland.de [83.169.183.87]    0.0%    10   13.5  13.5  10.8  17.5   1.9
  3. ip5886cb91.static.kabel-deutschland.de [88.134.203.144]   0.0%    10   13.5  15.5  12.7  19.3   2.7
  4. 145.254.3.100                                             0.0%    10   12.0  15.8  12.0  19.5   2.8
  5. 145.254.2.185                                             0.0%    10   13.6  14.4  11.8  18.5   1.8
  6. bb01.muc02.net.internetx.com                              0.0%    10   13.5  16.3  11.8  21.9   3.7
  7. b01-vl2.muc01.net.internetx.com                           0.0%    10   20.0  18.6  13.1  27.6   5.6
  8. c02-vl902.muc01.net.internetx.com                         0.0%    10   16.7  15.4  12.8  19.2   2.1
  9. 247-56-236-85.customer-net.de                             0.0%    10   11.6  14.9  11.6  22.0   3.4

Die --report Option sendet 10 Pakete an den Zielhost. Ohne diese Option wird mtr kontinuierlich ausgeführt. In den meisten Fällen bietet der --report Modus ausreichend Daten in einem passenden Format.

Jede nummerierte Zeile im MTR-Bericht repräsentiert einen Hop. Hops sind die routenden Internetknoten, die IP-Pakete durchlaufen, um zu ihrem Ziel zu gelangen.

Da MTR mit ICMP ping arbeitet, ermittelt dieses Tool die round trip time (hin und zurück) zwischen Quellhost und den Hops. Die Paketumlaufzeit wird bei MTR in Milisekunden angegeben. Die Namen der Hops werden durch Reverse-DNS-Lookups ermittelt. Wenn du die rDNS-Suche auslassen möchtest, kannst du die --no-dns Option verwenden. Der vollständige Hostname ist mit -rw ,kurz für --report-wide, sichtbar.

MTR liefert Statistiken über die Stabilität dieser Verbindung in den folgenden sieben Spalten.

Die Loss% Spalte zeigt den Prozentsatz des Paketverlusts bei jedem Hop.
Die SntSpalte zählt die Anzahl der gesendeten Pakete.

Die nächsten vier Spalten Last, Avg, Best, und Wrst sind alle Messungen der Paketumlaufzeit in Millisekunden.

Last ist die Paketumlaufzeit des letzten gesendeten Pakets
Avg ist die durchschnittliche Paketumlaufzeit aller Pakete
Best und Wrst zeigt die beste (kürzeste) und schlechteste (längste) Paketumlaufzeit für ein Paket an diesen Host an.
StDev ist die Standardabweichung der Paketumlaufzeit für jeden Host. Je höher die Standardabweichung ist, desto größer ist der Unterschied zwischen den Messungen.

In den meisten Fällen sollte die durchschnittliche ( Avg) Spalte im Mittelpunkt Ihrer Aufmerksamkeit stehen.

Probleme eingrenzen

In den meisten Fällen kannst du die MTR-Ausgabe in drei Netzwerkabschnitten unterteilen.

Quellnetzwerk: Der erste Hop ist das Gateway des Quellnetzwerkes. Wenn du den MTR-Report von einem Firmennetzwerk aus generierst, können weitere interne Router sichtbar sein.
ISP Netzwerke: Der zweiten oder dritte Hop ist der eigene regionale ISP. Darauf folgt meist ein Tier 1 ISP.
Zielnetzwerk: Die letzten zwei bis drei Hops gehören zum Rechenzentrum in dem der Zielhost steht. Den redundanten Netzwerkbackbone von InternetX erkennst du an der net.internetx.com Subdomain.

Wenn du bei der lokalen Ausführung von MTR eine Unregelmäßigkeit in den ersten Hops in der Nähe des Quellhost feststellst, wende dich an deinen Netzwerkadministrator oder lokalen ISP. Umgekehrt, solltest du Unregelmäßigkeiten in der Nähe des Ziels sehen, wende dich bitte an den Technischen Support von InterNetX und sende den MTR-Bericht an support@internetx.com.

Die meisten Probleme in ISP Netzwerken, die von MTR-Berichten angezeigt werden, sind temporär und innerhalb von 24 Stunden behoben. In vielen Fällen hat die Überwachung des Internetdienstanbieters das Problem bereits gemeldet. Wenn der Dienst für einen längeren Zeitraum beeinträchtigt ist, kannst du einen Anbieter auf die Probleme hinweisen, die bei Ihnen aufgetreten sind. Wenn du einen Dienstleister kontaktierst, sende MTR-Berichte und andere relevante Daten, die du möglicherweise hast. Ohne verwertbare Daten haben Provider keine Möglichkeit, Probleme zu überprüfen oder zu beheben.

ICMP rate limiting

Beim Analysieren der MTR-Ausgabe suchst du oft nach zwei Dingen: Paketverlust und Latenz.

Es ist jedoch bei einigen Dienstanbietern üblich, Antworten auf die ICMP Pakete, die von MTR generiert werden, nicht zu priorisieren oder ICMP Pakete zu verwerfen. Somit können für ICMP Pakete Paketverluste und Latenzen gemessen werden, die für IP-Pakete, die http- oder SSH-Daten kapseln, nicht real existieren. ICMP rate limiting führt häufig zu Latenzen, die nur für einzelne Hops messbar sind:

$ mtr --rw www.icann.org
HOST: example                            Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. fw1.muc01.net.internetx.com          0.0%    10    0.3   0.4   0.2   1.2   0.3
  2. c02-vl13.muc01.net.internetx.com     0.0%    10   25.2  40.9  25.2 136.1  34.9
  3. 2001:4178:1::11d                     0.0%    10   10.0  13.8   0.7  20.5   5.9
  4. ipv6.decix-munich.core1.muc1.he.net  0.0%    10    1.0   1.1   1.0   1.5   0.2
  5. 100ge14-2.core1.fra2.he.net          0.0%    10    6.9   9.4   6.7  28.5   6.8
  6. e0-53.core1.ams2.he.net              0.0%    10   13.8  14.4  13.8  15.9   0.9
  7. 100ge8-1.core1.lon3.he.net           0.0%    10   19.7  19.1  16.9  24.2   2.8
  8. 100ge14-1.core1.lon2.he.net          0.0%    10   17.0  18.0  17.0  25.3   2.6
  9. 100ge13-2.core1.nyc4.he.net          0.0%    10   85.3  85.5  85.2  86.0   9.6
 10. 100ge16-1.core1.ash1.he.net          0.0%    10   90.4  97.9  90.3 112.0   9.6
 11. 100ge2-1.core1.lax1.he.net           0.0%    10  144.8 144.9 144.7 145.1   0.1
 12. equinix-lax.icann.org                0.0%    10  144.3 144.3 144.1 144.5   0.1
 13. www.icann.org                        0.0%    10  144.2 144.4 144.1 144.7   0.2

Latenzen und ICMP Paketverlust wird häufig gleichzeitig angezeigt:

$ mtr --rw www.icann.org
HOST: example                            Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. fw1.muc01.net.internetx.com          0.0%    10    0.3   0.4   0.2   0.9   0.2
  2. c02-vl13.muc01.net.internetx.com     0.0%    10   25.2  25.5  25.1  27.2   0.6
  3. 2001:4178:1::11d                     0.0%    10    0.5   0.6   0.4   0.9   0.2
  4. ipv6.decix-munich.core1.muc1.he.net  0.0%    10    0.9   1.2   0.9   1.7   0.2
  5. 100ge14-2.core1.fra2.he.net          0.0%    10    6.6   6.7   6.5   6.9   0.1
  6. e0-53.core1.ams2.he.net             70.0%    10   16.4  15.2  14.2  16.4   1.1
  7. 100ge8-1.core1.lon3.he.net          20.0%    10   17.1  17.1  16.8  17.5   0.2
  8. 100ge14-1.core1.lon2.he.net         30.0%    10   16.9  17.2  16.9  17.4   0.1
  9. 100ge13-2.core1.nyc4.he.net          0.0%    10   85.2  85.4  85.2  85.7   0.2
 10. 100ge16-1.core1.ash1.he.net          0.0%    10   91.1  97.1  90.4 104.9   5.2
 11. 100ge2-1.core1.lax1.he.net           0.0%    10  144.6 144.7 144.5 145.1   0.2
 12. equinix-lax.icann.org                0.0%    10  144.1 146.4 144.0 166.7   7.1
 13. www.icann.org                        0.0%    10  144.2 144.4 144.2 144.7   0.2

ICMP Paketverluste können darauf zurückgeführt werden, dass Router ICMP rate limiting implementieren und nicht auf alle ICMP Pakete antworten. Asymetrisches Routen können auch für gemessene Paketverluste verantwortlich sein. Hier erreichen ICMP Pakete ihr Ziel ohne Fehler, haben es aber schwer, der return Route zu folgen. Aus diesem Grund ist es am besten, MTR-Reports in beiden Richtungen zu sammeln, wenn ein Problem auftritt.

MTR sendet ein ICMP Paket pro Sekunde, kann aber auch langsamer oder schneller ausgeführt werden:

sudo mtr -rw -i 0.2 [destination_host]

Wenn es bei einer schnelleren Ausführung von ICMP ping zu Packetverlusten kommt, deutet das nicht auf eine Überlastung des Netzwerkes hin. Routende Netzwerkkomponenten implementieren ICMP rate limiting per Default, um z.B. DoS entgegenzuwirken.

Es ist nicht notwendig und sinnvoll, alle Fälle von ICMP Paketverlust in deinen Verbindungen zu untersuchen oder zu melden. Die Internetprotokolle sind so ausgelegt, dass sie gegen eine Verschlechterung des Netzwerkes resistent sind, und die Routen, die Daten über das Internet zurücklegen, können als Reaktion auf Last, kurze Wartungsereignisse und andere Routing-Probleme schwanken. Wenn Ihr MTR-Bericht geringe Mengen von Verlusten in der Nähe von 10% anzeigt, gibt es keinen Grund zu echten Bedenken, da bei nicht-ICMP Datenströmen die Transport- und Anwendungsschicht den vorübergehenden Verlust kompensiert.

Übliche MTR-Berichte

Einige Netzwerkprobleme sind neu und erfordern eine Eskalation für die Betreiber der Upstream-Netzwerke. Es gibt jedoch eine Auswahl allgemeiner MTR-Berichte, in denen häufige Netzwerkprobleme beschrieben werden. Wenn du ein Netzwerkproblem hast und dein Problem diagnostizieren möchten, beachten Sie die folgenden Beispiele.

Netzwerk Latenz

MTR kann dazu dienen die Ursache für Latenzen zwischen den Quellhost und dem Zielhost zu lokalisieren. Aufgrund physikalischer Einschränkungen steigt die Latenz immer mit der Anzahl der Hops in einer Route. Die Steigerungen sollten konsistent und linear sein. Leider ist die Latenz oft relativ und hängt stark von der Qualität der Verbindungen beider Hosts und ihrer physischen Entfernung ab.

Berücksichtige bei der Auswertung von MTR-Berichten für potenziell problematische Verbindungen frühere korrekte Reports zusätzlich zu den bekannten Verbindungsgeschwindigkeiten zwischen anderen Hosts in einem bestimmten Netzwerksegment.

Der folgende MTR-Bericht zeigt, dass Hop 2. eine Latenz verursacht:

$ mtr --rw www.internetx.com
HOST: example                                                       Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. 192.168.176.1                                                   0.0%    10    0.5   0.8   0.3   1.2   0.3
  2. dslb-084-057-017-003.084.057.pools.vodafone-ip.de (84.57.17.3)  0.0%    10   17.7  17.7  17.5  17.8   0.1
  3. 188.111.216.234                                                 0.0%    10   17.3  17.4  17.2  17.6   0.2
  4. 92.79.215.18                                                    0.0%    10   17.8  17.8  17.7  18.1   0.5
  5. 145.254.2.185                                                   0.0%    10   18.2  18.2  18.1  18.3   2.3
  6. bb01.muc02.net.internetx.com                                    0.0%    10   18.1  18.0  17.6  18.3   0.4
  7. b02-vl2.muc01.net.internetx.com                                 0.0%    10   18.2  18.1  18.1  18.2   2.1
  8. c02-vl904.muc01.net.internetx.com                               0.0%    10   18.4  20.9  18.5  23.6   2.2
  9. 246-56-236-85.rev.customer-net.de                               0.0%    10   21.2  21.4  19.0  24.2   2.0

Die Latenz springt signifikant zwischen den Hop 1 und 2 und bleibt hoch. In den nachfolgenden Hops steigt die Latenz praktisch linear. Somit kann die DSL Internetanbindung als Verursacher der insgesamt hohen Latenz zwischen den Quellhost und den Zielhost eingegrenzt werden.

Latenzen in der gemessenen Paketumlaufzeit könnte bei ICMP ping auch durch ein Problem mit dem Rückweg verursacht werden. Der Rückweg wird im MTR-Report nicht angezeigt, und Pakete können völlig unterschiedliche Routen zu und von einem bestimmten Ziel nehmen. Deshalb sollten, wenn möglich, bidirektionale MTR-Reports erstellt werden, um Latenzprobleme einzugrenzen.

Firewall verhindert ICMP Antworten

Im nächsten Beispiel scheint es, dass die ICMP Pakete den Zielhost nicht erreichen, was jedoch nicht der Fall ist.

$ mtr --rw load-balance.customer-net.de
HOST: example                       Loss%   Snt   Last   Avg Best Wrst StDev
  1. 192.168.2.1                     0.0%    10    0.5   0.6   0.5   0.7   0.3
  2. load-balance.customer-net.de 100.0%    10    0.0   0.0   0.0   0.0   0.0

Der MTR-Bericht zeigt einen 100% Verlust an, da Hop 2. keine ICMP-Antwort sendet. Dies kann auf Netzwerk- oder Firewall-Regeln (zB iptables) zurückzuführen sein, die ICMP-Antworten blockieren.

Wohnrouter

Wohngateways verursachen manchmal irreführende Berichte:

$ mtr --rw www.internetx.com
HOST: example                                                         Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. 192.168.176.1                                                     0.0%    10    0.5   0.8   0.3   1.2   0.3
  2. dslb-084-057-016-001.084.057.pools.vodafone-ip.de (84.57.17.3)  100.0%    10   17.7  17.7  17.5  17.8   0.1
  3. 188.111.216.234                                                   0.0%    10   17.3  17.4  17.2  17.6   0.2
  4. 92.79.215.18                                                      0.0%    10   17.8  17.8  17.7  18.1   0.5
  5. 145.254.2.185                                                     0.0%    10   18.2  18.2  18.1  18.3   2.3
  6. bb01.muc02.net.internetx.com                                      0.0%    10   18.1  18.0  17.6  18.3   0.4
  7. b02-vl2.muc01.net.internetx.com                                   0.0%    10   18.2  18.1  18.1  18.2   2.1
  8. c02-vl904.muc01.net.internetx.com                                 0.0%    10   18.4  20.9  18.5  23.6   2.2
  9. 246-56-236-85.rev.customer-net.de                                 0.0%    10   21.2  21.4  19.0  24.2   2.0

Für Hop 2. wird 100% Paketverlust gemeldet, obwohl die Paketumlaufzeit für die ICMP Pakete auch dokumentiert wird.

Routing Schleifen im Netzwerk

Manchmal sind Router falsch konfiguriert und IP Pakete erreichen möglicherweise niemals ihr Ziel, zum Beispiel wenn ein Router Pakete in einer Schleife weiterleitet.

$ mtr --rw www.meinserver.com
HOST: example                                                 Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. kabel                                                     0.0%    10    2.5   2.1   1.7   2.5   0.3
  2. ip53a9b757.static.kabel-deutschland.de [83.169.183.87]    0.0%    10   11.9  13.2  10.7  18.5   2.2
  3. ip5886cb91.static.kabel-deutschland.de [88.134.203.144]   0.0%    10   13.8  14.3  11.8  21.5   3.2
  4. 145.254.3.100                                             0.0%    10   17.8  14.3  11.8  18.7   2.3
  5. 145.254.2.185                                             0.0%    10   12.2  13.2  11.8  15.0   1.1
  6. bb01.muc02.net.internetx.com                              0.0%    10   13.8  19.6  13.2  32.5   7.0
  7. b02-te1-4.muc01.net.internetx.com                         0.0%    10   14.6  15.7  13.0  22.4   3.0
  8. c02-te9-1.muc01.net.internetx.com                         0.0%    10   19.2  14.9  12.8  19.2   2.2
  9. gw-fw.customer-net.de                                     0.0%    10   11.6  14.9  11.6  22.0   3.4
 10. c01-te9-1.muc01.net.internetx.com                         0.0%    10    0.0   0.0   0.0   0.0   0.0
 11. gw-fw.customer-net.de                                     0.0%    10    0.0   0.0   0.0   0.0   0.0
 12. c01-te9-1.muc01.net.internetx.com                         0.0%    10    0.0   0.0   0.0   0.0   0.0
 13. ???                                                       0.0%    10    0.0   0.0   0.0   0.0   0.0
 14. ???                                                       0.0%    10    0.0   0.0   0.0   0.0   0.0
 15. ???                                                       0.0%    10    0.0   0.0   0.0   0.0   0.0

Dieser Bericht zeigt, dass es bei der Anbindung an den redundanten Netzwerkbackbone routing Probleme gibt. InternetX hat einen redundanten und vollvermaschten Backbone. Wir setzen hier das dynamische Routing Protokoll OSPF ein. Kundennetze sind üblicherweise mittels Virtual Router Redundancy Protocol (VRRP) redundant an den InternetX Backbone angebunden. Housing-Kunden können ihre Netze mit statischen Routen an den Backbone anbinden. Hier kann es nach Umbauarbeiten oder bei Hardwarestörungen zu Problemen kommen, da statische Routen sich nicht automatisch anpassen.

Timeout

Wenn MTR innerhalb von 5 Sekunden keine ICMP-Antwort von einen Router erhält, wird für diesen Hop ??? angezeigt. Timeouts können aus verschiedenen Gründen auftreten. Einige Router verwerfen ICMP Packete für QoS-Zwecke (Quality of Service) oder antworten gar nicht. Alternativ, kann es ein Problem mit dem Rückweg geben.

$ mtr --report-wide www.internetx.org
HOST: example                                                 Loss%   Snt   Last   Avg  Best  Wrst  StDev
  1. kabel                                                     0.0%    10    2.3   2.0   1.6   2.4   0.3
  2. ip53a9b757.static.kabel-deutschland.de [83.169.183.87]    0.0%    10   18.0  14.3  10.8  25.7   4.5
  3. ip5886cb91.static.kabel-deutschland.de [88.134.203.144]   0.0%    10   11.6  16.7  11.6  21.4   3.3
  4. ???                                                     100.0%    10    0.0   0.0   0.0   0.0   0.0
  5. ???                                                     100.0%    10    0.0   0.0   0.0   0.0   0.0
  6. bb01.muc02.net.internetx.com                              0.0%    10   13.1  14.4  13.1  17.5   1.7
  7. b01-vl2.muc01.net.internetx.com                           0.0%    10   13.8  16.6  12.3  24.7   4.3
  8. c02-vl902.muc01.net.internetx.com                         0.0%    10   16.5  17.2  12.0  21.9   3.5
  9. 247-56-236-85.customer-net.de                             0.0%    10   13.3  15.8  12.1  23.0   4.1

Timeouts sind kein Grund zur Sorge, wenn ICMP Pakete den Ziel-Host ohne signifikante Latenz erreichen.

Fortgeschrittene MTR-Techniken

Neuere Versionen von MTR können im TCP-Modus an den Zielhost anstelle des ICMP-Paket ein TCP SYN Paket schicken.

Das TCP SYN Paket wird in einem IP-Paket gekapselt, hier wird die TTL wie gewohnt hoch gesetzt. Somit antworten die Router zwischen dem Quell- und Zielhost wie gewohnt mit ICMP, wenn die TTL auf 0 gesetzt wird. Der Zielhost antwortet, wenn der http Port 80 empfangsbereit ist, mit SYN ACK und bricht dann den Verbindungsaufbau mit FYN ACK ab.

mtr --tcp -rw [destination_host]

Die --tcp Oprions-Flag kann verwendet werden, wenn der Zielhost wegen Firewallregeln nicht mit ICMP Ping Paketen erreichbar ist.

InterNetX technischer Support

Wenn Verbindungsprobleme auftreten und du Fragen zum MTR-Bericht hast, wende dich an support@internetx.com

Kopiere die Ausgabe deines MTR-Bericht in die Nachricht, so dass unsere Techniker dir bei der Analyse helfen können.

Netzwerkdiagnose mit MTR