Einführung
MTR (ursprünglich Matt’s TraceRoute, jetzt nur My TraceRoute) ist ein praktisches, leichtgewichtiges Tool im Arsenal eines UNIX/Linux-Administrators, das dabei helfen kann, allgemeine Netzwerkprobleme wie Latenz, Paketverlust und Routing-Fehler zu identifizieren und zu diagnostizieren. Es ist ein leistungsstarkes 2-in-1-Tool, das die Ergebnisse einer Traceroute und eines Pings mit einem Befehl kombiniert und anzeigt. Sehen wir uns die Grundlagen der Verwendung von MTR und die Interpretation der bereitgestellten Daten an.
Voraussetzungen
- Sie benötigen einen Linux-Server, und wenn Sie noch keinen Server haben, können Sie unsere VPS-Hosting-Seite besuchen und in weniger als 30 Sekunden einen neuen Server einrichten
MTR installieren
MTR-Pakete sind für die meisten heute gängigen Linux- (oder UNIX-basierten) Betriebssysteme verfügbar.
MTR unter Ubuntu/Debian installieren:
sudo apt-get install mtr-tiny
Der mtr-tiny Paket ist die reine Befehlszeilenversion von mtr Paket. Der mtr Paket enthält Unterstützung für die grafische Benutzeroberfläche X-11.
MTR auf CentOS/Fedora installieren:
yum install mtr
MTR unter Arch Linux installieren:
pacman -S mtr
MTR unter FreeBSD installieren:
pkg install mtr
.
Wie MTR funktioniert
Um die Ausgabe zu verstehen, die MTR generiert, ist es möglicherweise hilfreich zu wissen, wie es funktioniert. Wenn Sie bereits wissen, wie die traceroute Befehl funktioniert, dann wird Ihnen diese Erklärung bekannt vorkommen.
MTR generiert ein ICMP-Echo-Request-Paket, das für die Ziel-IP/den Hostnamen Ihres mtr bestimmt ist Befehl. Das erste Paket hat einen Time-to-Live (TTL)-Wert von 1. Wenn dieses Paket auf dem Weg zu seinem endgültigen Ziel am Router ankommt, der sein Gateway ist, verringert der empfangende Router die TTL um 1 und macht sie zu 0 Wenn eine TTL 0 erreicht, verwirft der Router das Paket und sendet dem ursprünglichen Absender ein ICMP Time Exceeded-Paket. Dieses Rückpaket enthält die IP-Adresse des Absenders, und MTR zeigt diese IP (oder den Hostnamen, falls er ihn auflösen kann) als ersten Hop an. Dann sendet es ein separates ICMP Echo Request-Paket mit einer TTL von 2, und wenn es das ICMP Time Exceeded-Paket vom TTL-Ablauf empfängt, listet es dieses Gerät als zweiten Hop auf und so weiter, bis das Ziel ein ICMP Echo Reply-Paket zurücksendet .
.
MTR-Berichte lesen
Zusätzlich zum Auflisten jedes Netzwerksprungs zwischen dem Absender und dem Ziel verfolgt MTR auch Statistiken bezüglich der Umlaufzeit für Pakete vom Ursprungshost zu jedem Sprung auf dem Weg. Diese Umlaufzeit wird oft als Latenzzeit bezeichnet .
Um eine bessere Vorstellung davon zu bekommen, was MTR uns sagt, werfen wir einen Blick auf ein Beispiel, das die Route zum öffentlichen DNS von Google verfolgt.
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
MTR-Berichte zeigen standardmäßig die folgenden Spalten an:
– Verlust % =Prozentsatz der Pakete, für die keine ICMP-Antwort empfangen wurde.
– Snt =Die Anzahl der an jeden Hop gesendeten Pakete.
– Letzte =Die Umlaufzeit des letzten Traceroute-Tests in Millisekunden.
– Durchschn. =Die durchschnittliche Umlaufzeit aller Traceroute-Sonden in Millisekunden.
– Am besten =Die kürzeste Umlaufzeit aller Traceroute-Sonden in Millisekunden.
– Wrst =Die längste Umlaufzeit aller Traceroute-Probes in Millisekunden.
– StDev =Die Ergebnisse der Standardabweichungsprüfung für jeden Hop.
.
Einen Live-Bericht von MTR erhalten
Wenn Sie MTR nur mit einer Ziel-IP (oder einem Hostnamen) ausführen, erhalten Sie einen Live-Bericht, der fortgesetzt wird, bis Sie Ihre Sitzung beenden oder den Unterbrechungsbefehl ausführen (Ctrl+C ).
sudo mtr 8.8.8.8
Einige Betriebssysteme erfordern sudo bevor Sie mtr ausführen Befehl; andere nicht.
.
Wenn Sie MTR pausieren möchten, drücken Sie p . MTR behält alle während der Pause gesammelten Zählungen bei, sodass Sie einen Screenshot machen oder die Daten in Ihre Zwischenablage kopieren können. Unpause MTR mit der Leertaste.
.
Generieren eines MTR-Berichts mit fester Anzahl
Mit -r können Sie nach einer bestimmten Anzahl von Trace-Probes auch einen MTR-Bericht generieren Option (Langform ist --report ). Die Standardanzahl der Zählungen ist 10, aber wenn Sie MTR für eine andere Anzahl von Zählungen ausführen möchten, verwenden Sie den -c (--report-cycles ) Option ebenfalls. Wenn Sie beispielsweise einen Bericht über 200 Zählungen erstellen möchten:
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
Jeder MTR wird mit -r ausgeführt Die Option erzeugt keine Ausgabe (im Gegensatz zum obigen Live-Bericht), bis die vollständige Anzahl von Zählungen abgeschlossen ist. MTR sendet standardmäßig einmal pro Sekunde eine Reihe von Trace-Sonden, sodass ein Bericht in etwas mehr als einer Anzahl von Sekunden abgeschlossen sein sollte, die Ihrer Zählnummer entspricht (200 Sekunden im obigen Beispiel).
.
Weitere nützliche Optionen
Es gibt mehrere andere Optionen, die Sie bei der Verwendung von MTR nützlich finden könnten. Diejenigen, die keine Argumente erfordern (wie -r ) können in derselben Optionszeichenfolge verkettet werden (z. B. -rn ). Eine Option, die ein Argument erfordert, kann nur dann in eine dieser Ketten aufgenommen werden, wenn sie die letzte Option ist und ihr Argument folgt (z. B. -rnc 200 ).
-n:(Langform--no-dns) Deaktivieren Sie DNS-Hostnamen-Lookups. Dasnkann auch während eines Live-Berichts verwendet werden, um zwischen dem Deaktivieren und Aktivieren von DNS-Lookups umzuschalten.-u:Senden Sie UDP-Datagramme anstelle von ICMP-Echo-Request-Paketen. Dasukann auch während eines Live-Berichts zwischen UDP und ICMP umschalten.-w:(Langform--report-wide) Ersetzt-rerzeugt aber einen Bericht, der längere Hostnamen nicht abschneidet.-i*:(Langform--interval) Geben Sie das Intervall in Sekunden zwischen Testproben an. Das Standardintervall ist 1 Sekunde.-4:Test auf IPv4 beschränken.-6:Test auf IPv6 beschränken.
.
Analyse von MTR-Daten auf Latenz
Die Ausgabe von MTR-Daten kann Ihnen helfen, Probleme zu identifizieren, die Sie oder einer der Internetanbieter möglicherweise mit dem Routing haben. Es kann auch hilfreich sein, eine Baseline für die erwartete Latenz zwischen Endpunkten festzulegen.
Lassen Sie uns hier noch einmal wiederholen, dass die von MTR generierten Zeiten die Round-Trip-Zeiten für ein ICMP-Paket sind, um den Hop zu erreichen, bei dem seine TTL abläuft, für das Gerät, das diesen Ablauf verarbeitet, um ein Paket mit ICMP-Zeitüberschreitung zu generieren, und für dieses Paket, zu dem es zurückkehrt das Ursprungsgerät. Bei vielen Routern hat die Durchführung der ICMP-Antwort für verworfene Pakete eine niedrige Priorität – und auf einigen Geräten ist sie vollständig deaktiviert.
Aus einem dieser Gründe werden Sie wahrscheinlich Fälle sehen, in denen ein Zwischensprung gelegentliche Spitzen in der Spalte „Letzte“ oder „Schlechteste“ Zeit zeigt. Solange sich der Latenzsprung nicht auch auf jeden nachfolgenden Hop ausbreitet, sehen Sie die Verzögerung des Antwortmechanismus auf diesem einen Gerät im Gegensatz zur tatsächlichen Durchsatzlatenz. Nehmen Sie zum Beispiel die folgende MTR-Ausgabe:
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
Sehen Sie, wie der erste Sprung und der elfte Sprung jeweils eine schlechtere Zeit haben, die viel höher ist als ihre Durchschnittswerte? Viele sehen sich einen Indikator wie diesen an und gehen davon aus, dass er einen Beweis für die Durchsatzlatenz darstellt. Aber beachten Sie, dass der zweite und zwölfte Sprung nicht auch eine ähnlich schlechte Zeit zeigen? Wenn die Spalte mit der schlechtesten Zeit für jeden nachfolgenden Hop die gleiche oder eine längere Zeit anzeigt, könnten wir dieses Ergebnis von einem Vorfall nehmen, der auf potenzielle Latenzprobleme hinweist. Beachten Sie im Gegensatz dazu die Spalte für die durchschnittliche Zeit, insbesondere zwischen den Sprüngen 6 und 7. Der Durchschnitt springt von 8,3 Millisekunden auf 21,7 Millisekunden, und jeder nachfolgende Sprung hat eine höhere Zahl. Diese Spalte zeigt ein Beispiel für echte Latenz, in diesem Fall zwischen Routern in Washington, D.C., und Atlanta, GA (dieses Ergebnis ist nach den Standards von 2015 ziemlich normal).
Möglicherweise sehen Sie auch sporadisch zwischengeschaltete Sprünge oder sogar Pakete, die ständig insgesamt fallen gelassen werden. Auch hier gilt:Solange diese Drops auf dem einen Gerät isoliert und nicht über alle nachfolgenden Hops hinweg konsistent sind, ist dies sehr wahrscheinlich ein Symptom dafür, dass die ICMP Time Exceeded-Antwortnachrichten für wichtigeren Transitverkehr depriorisiert werden (Sie können ein Beispiel für diesen Drop sehen in Sprung 7 oben). In einigen Fällen konfigurieren Netzwerkadministratoren Router so, dass sie überhaupt nicht mit ICMP Time Exceeded-Antworten antworten. Sie sehen möglicherweise, dass diese Hops 100 % des Datenverkehrs verlieren, während Hops darüber hinaus noch reagieren (im ersten Beispiel in diesem Artikel können Sie ein Beispiel für dieses Verhalten in Hop 13 sehen, das 100 % Verlust zeigt und die Host-IP nicht anzeigt oder Hostname).
.
Was kommt als Nächstes?
Dieser Artikel ist nur eine Einführung, wie Sie das MTR-Tool verwenden können, um Ihre Netzwerkkonnektivität mit verschiedenen Endpunkten im Internet zu untersuchen. Obwohl es noch viel mehr zu lernen gibt, sollten Ihnen die hier präsentierten Informationen einen guten Einstieg in die Diagnose von Netzwerkproblemen geben, die Sie möglicherweise haben. Vielen Dank fürs Lesen. Bitte schauen Sie erneut bei uns vorbei, um weitere Updates und fortgeschrittenere VPS-Hosting-Tutorials und Artikel wie „Was ist:Netzwerkgrundlagen – Switches, Router und Firewalls“ zu erhalten.
Erfahren Sie mehr über unsere VPS-Hosting-Services und Virtual Private Server.
.
.