1. Start
2. /
3. Server & Cloud
4. /
5. Netzwerkdiagnose mit MTR

Netzwerkdiagnose mit MTR

12 Min. Lesezeit

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

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, also die passierten Router, 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 geroutet 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.

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

port install mtr

MTR auf Unix-basierten Systemen

Generiere MTR-Berichte mit folgender Syntax …

mtr -rw [destination_host]

Beispiel: Testen der Route zum Zielhost example.com.

mtr -rw example.com

Server: Bidirektionale MTR-Berichte

Ein MTR-Bericht für einen Server kann vom lokalen Computer aus generiert werden.

mtr -rw ip

→ Eine SSH-Verbindung zu dem Server aufbauen.

→ Die IP durch die IP-Adresse des Computers (ggf. die des Firmen- oder Heimnetzwerks) ersetzen.

Wenn die öffentliche IP-Adresse nicht bekannt ist kann zur Ermittlung WhatIsMyIP.com verwendet werden.

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

MTR Reports

Beispiele:

Die folgenden MTR-Report Beispiele wurde 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-wide 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 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. Um die rDNS-Suche auzulassen, kann die —no-dns Option verwendet werden. 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 “Snt” Spalte 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 ist die “Avg”-Spalte mit der mittleren Paketlaufzeit für die Analyse sehr aussagekräftig. 

Probleme eingrenzen

In den meisten Fällen kannt die MTR-Ausgabe in drei Netzwerkabschnitte unterteilt werden:

• Quellnetzwerk: Der erste Hop ist das Gateway des Quellnetzwerkes. Wenn der MTR-Report von einem Firmennetzwerk aus generiert wird, 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. Der redundante Netzwerkbackbone von InterNetX ist an der net.internetx.com Subdomain erkennbar.

Wenn sich bei der lokalen Ausführung von MTR eine Unregelmäßigkeit in den ersten Hops in der Nähe des Quellhost zeigt, ist der Netzwerkadministrator oder lokale ISP der Ansprechpartner. Sind Unregelmäßigkeiten in der Nähe des Ziels zu sehen, ist der Technische Support von InterNetX der Ansprechpartner, an den der MTR-Bericht geschickt wird. 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 man den Anbieter auf die Probleme hinweisen, die aufgetreten sind.Wenn ein Dienstleister kontaktiert wird, ist es gut ihm den MTR-Berichte und wenn vorhanden andere relevante Daten zuzusenden. Ohne verwertbare Daten haben Provider keine Möglichkeit, Probleme zu überprüfen oder zu beheben.

ICMP Rate Limiting

Beim Analysieren der MTR-Ausgabe sind oft zwei Werte von Interesse: 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 im Problemfall MTR-Reports in beiden Richtungen zu sammeln.

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 standarmäßig, um z.B. DoS entgegenzuwirken.

Es ist nicht notwendig und sinnvoll, alle Fälle von ICMP-Paketverlust in den  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 der 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.

MTR-Berichte für häufige Netzwerkprobleme

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. Bei der Diagnose von Netzwerkprobleme können die folgenden Beispiele hilfreich sein.

Netzwerklatenz

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.

Bei der Auswertung von MTR-Berichten für potenziell problematische Verbindungen sollten frühere korrekte Reports zusätzlich zu den bekannten Verbindungsgeschwindigkeiten zwischen anderen Hosts in einem bestimmten Netzwerksegment berücksichtigt werden.

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    
 

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 (z. B. 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 Zielhost ohne signifikante Latenz erreichen.

Fortgeschrittene MTR-Techniken

Neuere Versionen von MTR können im TCP-Modus ein TCP-SYN-Paket an den Zielhost anstelle des ICMP-Paketes 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 Firewall-Regeln nicht mit ICM-Ping-Paketen erreichbar ist.  

InterNetX technischer Support

Bei Verbindungsproblemen oder Fragen zum MTR-Bericht bitte an den technischen Support wenden  support@internetx.com. Den MTR-Bericht zur Problemanalyse an die Nachricht anhängen.