mk16.de/blog/traceroute-und-tracepath.md

---

layout: page title: traceroute und tracepath permalink: /blog/traceroute-und-tracepath/ keywords: traceroute,tracepath,ping,asymmetrische routing,asymetric routing erkennen,mapping eines network,mtu ermitteln,networking,routing description: Wie funktionieren traceroute und tracepath? Wo sind die Unterschiede? Welche Hindernisse gibt es? Kann man ein Tracing auch manuell durchführen? lang: de feed: true

date: 2023-05-08 00:12:00 +0100

Was ist das?

traceroute und tracepath sind Kommandozeilenwerkzeuge, welche es ermöglichen nachzuvollziehen, welche Wege Pakete zum Ziel nehmen. Wenn man ein Paket versendet, nimmt dieses eine ganz bestimmte Route auf dem Weg zum Ziel. In Heimnetzwerken sendet man die Anfragen im Normalfall zu seinem Router, welcher als Gateway zum Internet fungiert. Dieser leitet das Paket dann an einen Internet Service Provider (ISP), welcher das Paket in das nächste Netzwerk weiterleitet, sodass dieses dem Ziel immer näherkommt. Aus unterschiedlichen Gründen kann es hilfreich sein, diesen Weg zu kennen.

In diesem Beispiel wird eine DNS-Anfrage an einen DNS-Server gesendet. Diese wird im Computer des Anwenders generiert und als Nächstes an den Heimrouter (zum Beispiel OpenWrt) gesendet, dieser leitet die Anfrage wiederum an den ISP weiter. Der ISP schaut nun nach, welche Route zum Ziel führt und sendet das Paket entsprechend weiter. Irgendwann kommt es dann am Router vom DNS-Server an. Dieser leitet die Anfrage wiederum an den DNS-Server. Der DNS-Server antwortet und das Paket nimmt den gleichen Weg zurück.

Was kann schiefgehen?

Auf dem Weg kann einiges schiefgehen:

1. Das Paket geht verloren: DNS verwendet standardmäßig das verbindungslose UDP-Protokoll. Es kann also passieren, dass das Paket verloren geht, ohne dass jemand etwas mitbekommt. Im Fall von DNS wird die Anfrage einige Male über UDP wiederholt. Schlägt das jedoch auch fehl, wird die Anfrage über das TCP-Protokoll gestellt.
2. Das Paket ist zu groß: Es ist unwahrscheinlich, dass dies im Fall von DNS passiert, jedoch kann dies mit anderen Protokollen passieren. Jedes Interface hat eine Maximum Transmission Unit (MTU). Diese beschreibt, wie groß das IP-Paket maximal sein darf. Wenn das Paket großer als die MTU ist, passiert "etwas". Dieses "etwas" unterscheidet sich bei IPv4 und IPv6. Bei IPv6 wird das Paket verworfen und (wenn richtig konfiguriert) eine ICMP Fehlermeldung an den Absender zurückgegeben, dass das Paket zu groß ist. Dieses muss es dann im Regelfall in mehrere kleinere aufgeteilt werden. Die aufgeteilten Pakete werden dann beim Empfänger wieder zusammengesetzt. Bei IPv4 geschieht das gleiche, wenn das "Don't fragment" Flag (ein Parameter im IP-Header) gesetzt ist. Ist es nicht gesetzt, so können auch die Router, welche sonst die ICMP Fehlermeldung zurückgeben würden, das Paket aufteilen und die geteilten Pakete weitersenden.
3. Wenn eine Anfrage mit UDP oder TCP gesendet, wird ein Port gesetzt. Sollte auf dem Server der Port jedoch von keinem Programm benutzt sein, wird (wenn richtig konfiguriert) eine ICMP Fehlermeldung zurückgegeben, dass auf dem Port kein Programm läuft. Es kann jedoch auch vorkommen, dass die Firewall des Servers die Anfrage blockiert und keine ICMP Fehlermeldung zurückgesendet wird.
4. Das Paket ist zu lange unterwegs: Des Weiteren kann es vorkommen, dass das Paket zu lange unterwegs ist. Normalerweise ist dies ein Anzeichen dafür, dass irgendwo im Netzwerk ein Fehler vorliegt. Jedes IP-Paket (also auch UDP-Datagramme und TCP-Pakete) bekommen einen Time to Live (TTL)-Wert. Nach jedem Hop (beispielsweise jedem Router), welches das Paket durchquert, wird der TTL-Wert um eins verringert. Erreicht der Wert null, wird eine ICMP Fehlermeldung zurückgegeben. Diesen Wert gibt es unter anderem, um zu verhindern, dass Schleifen entstehen und Pakete Ewigkeiten im Umlauf sind. Der maximale TTL-Wert ist 255. Häufig, jedoch nicht immer, wird ein TTL-Wert von 64 verwendet.
5. Die ICMP Fehlermeldung wird blockiert: Es kann sowohl am Server als auch an den Routern Firewalls geben, welche die ICMP Fehlermeldung blockieren. Dies kann ein Ärgernis für den Absender darstellen, da er nicht weiß, was mit seinem Paket passiert ist.

Asymmetrisches Routing

Es kann vorkommen, dass Pakete nicht den gleichen Hin- und Rückweg nehmen. So kann ein Paket auf dem Hinweg zum Beispiel Acht und auf dem Rückweg nur Fünf Hops passieren oder andersherum. Es können auch gleich viele Hops auf dem Hinweg wie auf dem Rückweg sein, welche aber nicht dieselben wie auf dem Hinweg sein müssen (gleiche Anzahl Hops, anderer Weg). Passiert so etwas, spricht man von "asymmetrischem Routing", sonst von "symmetrischen" Routing. Asymmetrisches Routing muss nicht zwingend schlecht sein - kann aber bei Fehlkonfigurationen zu Problem führen.

Wie funktioniert Traceroute?

Traceroute und Tracepath wiederum ermitteln die Hops (also Computer, welche IP-Routing machen), welche zwischen dem Absender und dem Empfänger liegen. Die Funktionsweise von traceroute und tracepath ist wiederum in den Manual Pages erklärt und eigentlich recht simpel:

Traceroute sendet "Proben" zum Ziel aus. Diese Proben haben ein TTL von eins, dann von zwei und so weiter. Wenn die TTL abläuft, wird eine ICMP Fehlermeldung zurückgegeben. Da diese Fehlermeldung auch einen Absender hat, weiß man nun den Router, welcher die Fehlermeldung gesendet hat und damit kennt man nun einen der Router, der auf dem Weg zum Ziel liegt. In der nächsten Probe erhöht man das TTL um Eins und sendet das Paket wieder. Es sollte ein anderer Router mit einer ICMP Fehlermeldung antworten. Dies wird so lange fortgesetzt, bis man das Ziel erreicht hat. Traceroute versucht einen vermutlich nicht vergebenen UDP-Port zu erreichen. Wenn das Paket dann beim Server ankommt, antwortet dieser mit einer ICMP Fehlermeldung, dass auf dem Port kein Programm läuft. Dadurch weiß man, dass man das Ziel erreicht hat.

traceroute verfolgt die Route, die Pakete von einem IP-Netzwerk auf ihrem Weg zu einem Weg zu einem bestimmten Host. Es nutzt das TTL-Feld (Time to Live) des IP-Protokolls Feld des IP-Protokolls und versucht, eine ICMP TIME_EXCEEDED-Antwort von jedem Gateway entlang des Pfades zum Host zu erhalten.

Dieses Programm versucht, den Weg eines IP-Pakets zu einem zu einem Internet-Host zu verfolgen, indem es Testpakete mit einer kleinen ttl (time to live) aussendet und dann auf eine ICMP-Antwort "time exceeded" von einem Gateway wartet. Wir beginnen unsere Probes mit einer ttl von eins und erhöhen sie um eins, bis wir eine ein ICMP "port unreachable" (oder TCP reset) erhalten, was bedeutet, dass wir den "Host" erreicht haben oder auf ein Maximum stoßen (das standardmäßig bei 30 Hops liegt).

Sollte der Host nach 30 Hops nicht erreicht wurden sein, wird der Versuch abgebrochen und nur die bisherigen Hops ausgegeben.

Die ICMP Fehlermeldung, welche von den Hops auf dem Weg kommen, beinhalten standardmäßig keine Angabe darüber, wo diese auf dem Weg liegen - also ob diese der erste, der zweite, der dritte, ... Hop sind. Deswegen greift Traceroute zu einem kleinen Trick. Die Pakete, welche Traceroute, standardmäßig sendet, sind UDP-Paket. Bei dem TTL von eins wird der Port 33434, bei einem TTL von zwei der Port 33435, bei einem TTL von drei der Port 33436 verwendet. Da das Originalpaket mit der ICMP Fehlermeldung zurückkommt, kann traceroute daraus wiederum den Port ermitteln und so weiß traceroute, bei welchem TTL (und daher wo auf dem Weg) der Hop liegt.

Traceroute lässt sich auch mit einem ICMP und einem TCP-Modus benutzen. Sodass, statt UDP-Pakete ICMP- oder TCP-Paket verwendet werden.

Traceroute sendet zu jedem Hop drei Paketproben. Dies kann bei Bedarf mit -q angepasst werden.

Wie ist die Ausgabe von traceroute zu deuten?

$ traceroute -6 git.dn42
traceroute to git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7), 30 hops max, 80 byte packets
 1  de.hujk.dn42 (fd94:dba8:42b0:e::1)  4.102 ms  4.070 ms  4.052 ms
 2  de-fra1.burble.dn42 (fd42:4242:2601:31::1)  5.643 ms  5.621 ms  5.583 ms
 3  ca-bhs2.burble.dn42 (fd42:4242:2601:2d::1)  105.657 ms  105.936 ms  105.928 ms
 4  git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)  105.900 ms  105.887 ms  105.852 ms

Als Erstes wird der traceroute Befehl eingegeben. Man kann dort verschiedene Parameter benutzen. Zum Beispiel -6 für IPv6 oder -4 für IPv4. Des Weiteren kann mit man -m oder --max-hops= die Anzahl der maximalen Hops festlegen (standardmäßig 30).

Mit --mtu kann man die maximale MTU ermitteln lassen. Dies impliziert automatisch, dass die Pakete nicht fragmentiert werden dürfen (manuell mit dem Flag -F einstellbar) und dass maximal eine Probe auf einmal gesendet werden darf (einstellbar mit -N).

In der ersten Zeile wird dann der reverse DNS (rDNS) Name sowie die dazugehörige IP-Adresse angezeigt. Des Weiteren wird die maximale Anzahl an Hops sowie die Größe der Pakete ausgegeben. Danach kommt eine Auflistung. Als Erstes steht die Position des Hops. Dann der rDNS Name und die IP-Adresse. Des Weiteren die Zeit, welche die Erste, die zweite und die dritte Probe gebraucht hat.

MTU ermitteln

$ traceroute -6 --mtu git.dn42
traceroute to git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7), 30 hops max, 65000 byte packets
 1  de.hujk.dn42 (fd94:dba8:42b0:e::1)  4.126 ms F=1420  4.162 ms  4.112 ms
 2  de-fra1.burble.dn42 (fd42:4242:2601:31::1)  5.114 ms F=1280  5.279 ms  5.382 ms
 3  ca-bhs2.burble.dn42 (fd42:4242:2601:2d::1)  103.731 ms  104.233 ms  104.718 ms
 4  git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)  104.492 ms  104.539 ms  103.605 ms

Hier wird zusätzlich zur vorherigen Ausgabe noch ein F= angefügt. Danach steht die MTU. In diesem Fall kann man sehen, dass der Absender zum ersten Host ein MTU von 1420 hat. Zum zweiten Host gibt es allerdings ein MTU von nur 1280. Es ist also wahrscheinlich, dass die Verbindung zwischen de.hujk.dn42 und de-fra1.burble.dn42 nur ein MTU von 1280 hat.

Ein Hop antwortet nicht

$ traceroute vpnhub1.hack
traceroute to vpnhub1.hack (172.31.2.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Sollte ein Hop nicht antworten, wird dies mit * * * gezeigt. Das * bedeutet, dass auf diese Probe keine Antwort kam. Dies kann zum Beispiel aufgrund einer zu restriktiven Firewall der Fall sein. Ein rDNS Name bzw. eine IP-Adresse wird dann auch nicht angezeigt, da der Hop und seine IP-Adresse nicht bekannt sind.

Um dieses Problem zu umgehen, kann man den ICMP Modus probieren. In diesem Modus werden statt UDP-Datagramme ICMP-Nachrichten versendet. Einige Firewalls blockieren lediglich UDP Pakete, jedoch keine ICMP Pakete.

$ traceroute -6 bbs.dn42
traceroute to bbs.dn42 (fd42:1919:810::3), 30 hops max, 80 byte packets
 1  de.hujk.dn42 (fd94:dba8:42b0:e::1)  4.143 ms  4.137 ms  4.108 ms
 2  * usw.hujk.dn42 (fd94:dba8:42b0:18::1)  157.087 ms  157.062 ms
 3  lax2.6.nico.dn42 (fd42:1919:810::3)  158.998 ms  158.981 ms  158.954 ms

Des Weiteren kann es auch vorkommen, dass nur ein Hop eine Firewall hat und die anderen nicht. Darüber hinaus kann es auch sein, dass ein Hop nur zeitweise bzw. teilweise nicht auf eine Probe antwortet.

Workaround

$ sudo traceroute -I vpnhub1.hack
traceroute to vpnhub1.hack (172.31.2.1), 30 hops max, 60 byte packets
 1  vpnhub1.hack (172.31.2.1)  3.526 ms  3.682 ms  3.674 ms

Der ICMP Modus erfordert jedoch erhöhte Rechte, da rohe ICMP-Nachrichten gesendet werden. Daher kann man dies mit sudo ausführen. Eine andere Möglichkeit besteht darin, dass man traceroute das cap_net_raw-Privileg gibt:

sudo setcap cap_net_raw+ep $(realpath $(which traceroute))

Dazu gibt es auch alternative Möglichkeiten.

Fehlermeldungen

traceroute kann des Weiteren, einige auf den ersten Blick "kryptische", Hinweise anzeigen.

$ traceroute -6 fd94:dba8:42b0:e::90
traceroute to fd94:dba8:42b0:e::90 (fd94:dba8:42b0:e::90), 30 hops max, 80 byte packets
 1  de.hujk.dn42 (fd94:dba8:42b0:e::1)  4.502 ms !N  4.450 ms !N  4.461 ms !N

In diesem Fall wird versucht ein Host zu erreichen, welcher nicht erreichbar ist. An dem Hop, wo dies festgestellt wird, wird dann ein !N angezeigt. !N entspricht der Fehlermeldung Destination unreachable: No route und bedeutet, dass das Zielnetzwerk bzw. die Zieladresse nicht erreichbar ist. Beispielsweise könnte sie temporär vom Hauptnetzwerk getrennt sein oder existiert einfach nicht.

Nach der Round Trip Time können einige zusätzliche Anmerkungen ausgegeben werden: !H, !N, oder !P (Host, Netzwerk oder Protokoll unerreichbar), !S (Quellroute fehlgeschlagen), !F (Fragmentierung erforderlich), !X (Kommunikation administrativ verboten), !V (Host-Präferenzverletzung), !C (Prioritätsabschaltung in Kraft), oder ! (ICMP Unerreichbarkeitscode ). Wenn fast alle Proben eine Art von Unerreichbarkeit ergeben, gibt Traceroute auf und wird beendet.

Wie funktioniert Tracepath?

Tracepath funktioniert fast so wie traceroute. In Gegenzug zu traceroute, verwendet es aber nicht immer den Port 33434+, sondern einen Zufälligen. Des Weiteren ermittelt tracepath ohne zusätzlichen Parameter immer das MTU und setzt daher bei IPv4 auch immer das "Don't fragment" Flag im IP-Header. Ein weiterer Unterschied besteht darin, dass es statt drei nur eine Probe aussendet.

Wie ist die Ausgabe von tracepath zu deuten?

$ tracepath -p 33434 herzstein.bandura.dn42
 1?: [LOCALHOST]                        0.008ms pmtu 1420
 1:  p2prouter.bandura.dn42                                0.504ms 
 1:  p2prouter.bandura.dn42                                0.611ms 
 2:  laplace.bandura.dn42                                 19.435ms 
 3:  herzstein.bandura.dn42                              203.043ms reached
     Resume: pmtu 1420 hops 3 back 3

Wie immer erfolgt als Erstes der Aufruf von tracepath. Mit der Option -p kann man den Startport festlegen. In diesem Fall wurde er auf 33434 wie bei traceroute gesetzt. Die Angabe ist optional. Da mein Netzwerk, welches ich in diesem Beispiel verwende, jedoch nur auf UDP Traceroutes antwortet, musste ich den Port manuell festlegen. Als Erstes wird wie bei traceroute die Position auf dem Weg ausgegeben. Wird ein ? nach der Zahl ausgegeben, bedeutet dies, dass die Position geraten ist. Der erste Punkt ist in diesem Fall der eigene Computer, also localhost. Dieser hat zum nächsten Hop ein MTU von 1420. pmtu steht dabei für path mtu. Des Weiteren wird wie bei Traceroute die Round Tripe Time (RTT) angezeigt - also wie lange unser Paket hin und zurück gebraucht hat. Wenn das Ziel erreicht ist, wird reached angezeigt. Zum Schluss wird noch einmal zusammengefasst: Ein Paket zum Ziel darf maximal 1420 Bytes groß sein und braucht drei Hops hin und drei zurück.

MTU und asymetrisches Routing

$ tracepath -p 33434 git.dn42
 1?: [LOCALHOST]                        0.008ms pmtu 1420
 1:  de.hujk.dn42                                          4.221ms 
 1:  de.hujk.dn42                                          4.137ms 
 2:  de.hujk.dn42                                          4.136ms pmtu 1280
 2:  tier1.de-fra1.burble.dn42                             5.133ms 
 3:  tier1.ca-bhs2.burble.dn42                           105.222ms asymm  4 
 4:  git.dn42                                            105.094ms reached
     Resume: pmtu 1280 hops 4 back 5

In dieser Ausgabe sieht man, dass sich das MTU auf dem Weg von 1420 zu 1280 verändert hat. Dies konnten wir auch schon bei traceroute feststellen. Bei tracepath kann man auch klar erkennen, dass sich das MTU zwischen dem 1 und 2 Hops verändert hat - also zwischen de.hujk.dn42 und de-fra1.burble.dn42. Der zweite Hop taucht hier zweimal in der Ausgabe aus, da die Probe mit der richtigen MTU, also einem kleineren Paket, erneut versendet werden musste. Beim ersten Durchgang wurde das Paket also beim de.hujk.dn42 angehalten, welche damit als zweiten Hop auftrat. Das angepasste Paket konnte jedoch weiter und wurde bei (aufgrund der ausgelaufenen TTL) tier1.de-fra1.burble.dn42 aufgehalten. Des Weiteren zeigt uns tracepath, dass es hier um asymmetrisches Routing handelt. Beim dritten Hop gibt es die Anmerkung asymm 4. Dies bedeutet, dass das Paket für den Rückweg vermutlich vier Hops brauchte. Diese Angabe ist jedoch nicht zuverlässig (siehe unten). Zum Schluss wird wieder die Zusammenfassung ausgegeben. Das Paket hat zum Ziel vier und zurück fünf Hops durchquert.

Dabei sollte man anmerken, dass tracepath die Anzahl der Hops auf dem Rückweg zum Teil errät. Berechnet wird diese, in dem die vermutlich verwendete maximale TTL um die TTL, welche das Rückpaket hat, wenn es ankommt, verringert. Da es jedoch keinen Standard dafür gibt, muss tracepath die maximale TTL beim Absenden erraten, weshalb diese Angabe unzuverlässig ist.

Ausgabe von IP-Adressen

Möchte man statt dem rDNS Namen lieber die IP-Adressen der Hops ausgegeben haben, so kann man das Flag -n benutzen. Wenn Sie sowohl die IP-Adresse als auch den rDNS-Namen ausgeben möchten, kann man das Flag -b verwenden.

$ tracepath -p 33434 -n git.dn42
 1?: [LOCALHOST]                        0.008ms pmtu 1420
 1:  fd94:dba8:42b0:e::1                                   4.234ms 
 1:  fd94:dba8:42b0:e::1                                   4.263ms 
 2:  fd94:dba8:42b0:e::1                                   4.175ms pmtu 1280
 2:  fd42:4242:2601:31::1                                  5.338ms 
 3:  fd42:4242:2601:2d::1                                104.775ms asymm  4 
 4:  fd42:180:3de0:100:fc5f:3a14:838e:a7a7               104.840ms reached
     Resume: pmtu 1280 hops 4 back 5 

Fehlermeldungen

$ tracepath -p 33434 fd94:dba8:42b0:e::120
 1?: [LOCALHOST]                        0.026ms pmtu 1420
 1:  de.hujk.dn42                                          4.484ms !N
 1:  de.hujk.dn42                                          4.156ms !N
     Resume: pmtu 1420 

tracepath benutzt die gleichen Abkürzungen für Fehlermeldungen wie traceroute. Sollte eine Fehlermeldung zurückkommen, wird die entsprechende Abkürzung nach der RTT angezeigt.

Manuelle Traceroute mithilfe von Ping

Das, was traceroute und tracepath automatisiert machen, kann man auch mithilfe von Ping erreichen. Dabei helfen die Ping-Paramater -t, um die TTL zu setzen, -s um die Größe des Payload (und dadurch des Paketes) zu bestimmten sowie -Mdo, um eine automatische Fragmentierung zu verhindern und bei IPv4 um das "Don't fragment" Flag zu setzen sowie -c um die Anzahl der Pings zu festzulegen.

Wenn wir auch die MTU ermitteln wollen, ist es wichtig, dass die Payload auf den maximalen Wert festzulegen und die automatische Fragmentierung mit -Mdo zu deaktivieren. Die maximale Payload berechnet man, indem man die MTU des ausgehenden Interfaces (hier 1420, einsehbar mit ip link) mit dem IP-Header (20 Bytes bei IPv4 und 40 Bytes bei IPv6) sowie den ICMP-Header (hier: 4 Bytes ICMP-Header + 4 Bytes Echo-Request Header) verringert: 1420 bytes (MTU) - 40 bytes (IPv6) - 8 bytes (ICMP) = 1372 bytes Entsprechend setzt man das Payload mit -s.

Diese manuelle Methode würde einer traceroute im ICMP-Modus mit MTU Ermittlung entsprechen.

Anfrage mit maximalen Payload und einer TTL von Eins:

$ ping -t1 -s 1372 -c1 -Mdo -6 git.dn42
PING git.dn42(git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)) 1372 data bytes
From de.hujk.dn42 (fd94:dba8:42b0:e::1) icmp_seq=1 Time exceeded: Hop limit

--- git.dn42 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% Paket loss, time 0ms

Anfrage mit maximalen Payload und einer TTL von Zwei:

$ ping -t2 -s 1372 -c1 -Mdo -6 git.dn42
PING git.dn42(git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)) 1372 data bytes
From de.hujk.dn42 (fd94:dba8:42b0:e::1) icmp_seq=1 Paket too big: mtu=1280

--- git.dn42 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% Paket loss, time 0ms

Hier verändert sich die MTU, also berechnen wir die maximale Payload mit der neuen MTU neu: 1280 bytes (MTU) - 40 bytes (IPv6) - 8 bytes (ICMP) = 1232 bytes

Anfrage mit maximalen Payload und einer TTL von Zwei:

$ ping -t2 -s 1232 -c1 -Mdo -6 git.dn42
PING git.dn42(git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)) 1232 data bytes
From tier1.de-fra1.burble.dn42 (fd42:4242:2601:31::1) icmp_seq=1 Time exceeded: Hop limit

--- git.dn42 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% Paket loss, time 0ms

Anfrage mit maximalen Payload und einer TTL von Drei:

$ ping -t3 -s 1232 -c1 -Mdo -6 git.dn42
PING git.dn42(git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)) 1232 data bytes
From tier1.ca-bhs2.burble.dn42 (fd42:4242:2601:2d::1) icmp_seq=1 Time exceeded: Hop limit

--- git.dn42 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% Paket loss, time 0ms

Anfrage mit maximalen Payload und einer TTL von Vier:

$ ping -t4 -s 1232 -c1 -Mdo -6 git.dn42
PING git.dn42(git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7)) 1232 data bytes
1240 bytes from git.dn42 (fd42:180:3de0:100:fc5f:3a14:838e:a7a7): icmp_seq=1 ttl=60 time=105 ms

--- git.dn42 ping statistics ---
1 packets transmitted, 1 received, 0% Paket loss, time 0ms
rtt min/avg/max/mdev = 104.894/104.894/104.894/0.000 ms

Aufgrund der erfolgreichen Antwort, kann man feststellen, dass wir hier das Ziel erreicht haben. Damit haben wir alle Hops ermittelt sowie das maximale MTU und wo sich dieses verändert.

Anmerkungen

• TTL steht für Time to live und wird nur in IPv4 verwendet. In IPv6 wird TTL durch das "Hop Limit" ersetzt, welches die gleiche Funktion erfüllt. Aus einfachheitsgründen habe ich in diesem Blogbeitrag nur von TTL gesprochen.
• Paketverlust kann nicht nur bei UDP auftreten. Er kann genauso bei ICMP oder TCP auftreten. TCP verfügt jedoch über Mechanismen, welche sicherzustellen, dass ein gesendetes Paket auch zuverlässig ankommt. Jedoch gilt UDP als (minimal) schneller, weshalb es standardmäßig für DNS Anfragen verwendet wird.
• ICMP wird nur in IPv4 verwendet. In IPv6 wird ICMPv6 verwendet. Aus Einfachheitsgründen spreche ich jedoch nur von ICMP.
• Asymmetrisches Routing kann nicht immer von Tracepath erkannt werden - beispielsweise, wenn die Anzahl der Hops auf Hin- und Rückweg gleich sind, aber trotzdem ein anderer Weg genommen wurde.
• Manuelles Durchführen von Traceroutes via Ping ist aufwendig und ineffizient, kann einem aber ein gutes Verständnis für die Funktionsweise von Traceroute und Tracepath geben.

Ich habe mir beim Schreiben Mühe gegeben auf inhaltliche Richtigkeit zu achten, jedoch kann es trotzdem zu Fehlern kommen. Wenn du einen Fehler entdeckt, wäre ich dir dankbar, wenn du mir eine E-Mail schreibst :-)

Nachtrag

11.05.2023: Die Fehlermeldungscodes wie !X sind bei traceroute und tracepath nicht gleich. Beispielsweise verwendet traceroute !X und tracepath !A, wenn die Nachricht administrativ gefiltert worden ist.

Ich konnte keine Dokumentation für die Codes von Tracepath finden. Daher habe ich auf GitHub ein Issue geöffnet. Die Bedeutung lässt sich aber recht gut vom Quellcode her ableiten:

| Ausgabe | Code | Bedeutung | | !A | EACCES | Communication administratively prohibited | | !N | ENETUNREACH | Destination network unreachable | | !H | EHOSTUNREACH | Destination host unreachable | | !P | EPROTO | Destination protocol unreachable |

Dies ist das, was ich aus dem Quellcode lesen konnte. Ich bin mir allerdings nicht sicher, ob die Tabelle richtig ist.

Links

• 5 Ways to Traceroute - wikiHow
• What ports does trraceroute use?
• What does !H1 mean?
• TracePath - eduPERT KB
• what does asymm mean in the results for a traceroute?
• Use icmplib without root privileges
• Why ping works without capability and setuid
• Please add cap_net_raw+ep capabilities to /bin/traceroute
• Security implications of using SETCAP CAP_NET_RAW