Erläuterung des Traceroute-Befehls

Traceroute kann ein unschätzbares Werkzeug sein, wenn es darum geht, Verbindungsprobleme zu Hosts in anderen Netzwerken zu diagnostizieren. Um es jedoch effektiv zu nutzen, müssen Sie verstehen, wie es funktioniert und was die Ausgabe bedeutet.

Traceroute funktioniert durch Manipulation des Time-To-Live (TTL)-Werts im IP-Header (Abbildung 1). Da ich für meine Beispiele das interne Netz von Stratus verwenden musste, habe ich die hexadezimale Darstellung der IP-Adresse in den Paketverfolgungen mit einem X versehen und alle Oktette in dezimaler Notation in einen eindeutigen Buchstabencode A bis W übersetzt. Das heißt, AAA steht für eine dreistellige Zahl und J für eine einstellige Zahl.

Abbildung 1 - packet_monitor-Frame mit hervorgehobenem TTL

Jeder Router, der das Paket verarbeitet, verringert den TTL-Wert um 1, und wenn der TTL-Wert größer als 0 ist, leitet er das Paket an den nächsten Router oder das endgültige Ziel weiter. Wenn der TTL-Wert 0 ist, verwirft der Router das Paket und *kann* eine ICMP-Zeitüberschreitung an den Absender zurücksenden. Die Betonung liegt auf *kann*, denn einige Router senden keine Nachricht mit Zeitüberschreitung zurück oder nur, wenn sie nicht ausgelastet sind. Außerdem blockieren einige Firewalls die ICMP-Nachricht, so dass der Host, auf dem Traceroute ausgeführt wird, die Nachricht möglicherweise nie zu Gesicht bekommt, selbst wenn der Router die Nachricht "Zeit überschritten" sendet.

Traceroute sendet zunächst eine Nachricht mit einem TTL-Wert von 1 an das Ziel und misst, wie lange es vom Senden der Nachricht bis zum Erhalt einer Antwort dauert.

Abbildung 2 - packet_monitor traceroute frame und Antwort

Standardmäßig sendet der Befehl traceroute drei Nachrichten mit einer TTL von 1 und meldet alle drei Male sowie den Namen und/oder die IP-Adresse des Routers, der die Antwort gesendet hat. Ich verwende immer das Argument -numerisch, damit ich nicht auf die Namensauflösung warten muss (Abbildung 3). Traceroute erhöht dann den TTL-Wert um 1 und wiederholt den Vorgang. Traceroute erhöht den TTL-Wert so lange, bis es eine Antwort vom Zielort erhält oder ein bestimmter Grenzwert, standardmäßig 30, erreicht ist. Die Dokumentation zu allen Traceroute-Argumenten finden Sie im OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ).

Abbildung 3 - Traceroute-Ausgabe

Man würde erwarten, dass die Zeiten mit steigender TTL zunehmen, und das ist im Allgemeinen auch der Fall, aber nicht immer. Man vergleiche die dritten gemeldeten Zeiten von Hop 6 (79 ms) und Hop 5 (80 ms) in Abbildung 3. Hierfür gibt es mehrere Gründe. Erstens ist das Netz nicht deterministisch, manchmal dauert es einfach länger. Zweitens kann der Router an Hop N-1 stärker ausgelastet sein als der Router an Hop N und länger brauchen, um die ICMP-Nachricht zu senden. Schließlich kann der Rückweg von Router N schneller sein als der Rückweg von Router N-1. So ist es beispielsweise nicht erforderlich, dass der vierte Router seine Antwort über die Router 3, 2 und 1 an die Quelle zurücksendet. Er könnte seine Antwort direkt an Router 1 senden, was wesentlich schneller sein könnte. Das bedeutet, dass Traceroute zwar den Weg eines Pakets vom sendenden Host zum Zielhost sehr gut wiedergeben kann, dass man sich aber nicht darauf verlassen kann, dass ein Paket, das vom Zielhost zum sendenden Host gesendet wird, denselben Weg nur in umgekehrter Richtung nimmt. Dies ist als asymmetrisches Routing bekannt.

Traceroute kann ein Flag an eine Zeit anhängen, das anzeigt, dass es etwas anderes als die erwartete Zeitüberschreitung empfangen hat. Die Flaggen sind:

!H - Host nicht erreichbar
!N - Netzwerk unerreichbar
!P - Protokoll unerreichbar

Abbildung 4 zeigt beispielsweise, dass der erste Router nicht weiß, wie er das Zielnetz erreichen kann, und daher eine Meldung "Netzwerk unerreichbar" zurückgibt und Traceroute an diesem Punkt beendet.

Abbildung 4 Meldungen über ein nicht erreichbares Netz

Ein Sternchen (*) anstelle einer Zeitangabe bedeutet, dass traceroute keine Antwort erhalten hat. Wie bereits erwähnt, könnte es sein, dass der Router keine ICMP-Zeitüberschreitung sendet, dass eine Firewall die Zeitüberschreitung auf dem Rückweg blockiert oder dass eine Firewall die ausgehende Nachricht blockiert. Es könnte auch sein, dass das Netzwerk entweder die ausgehende oder die zurückkommende Nachricht einfach verworfen hat.

Eine einzelne oder sogar zwei Zeitüberschreitungen bei einem Hop (Abbildung 5) bedeutet wahrscheinlich, dass der Router die Nachricht nicht gesendet hat, weil er beschäftigt war, oder dass das Netz Pakete verworfen hat (oder beides). Beachten Sie den 8. Hop in Abbildung 5. Das Sternchen vor der IP-Adresse bedeutet, dass die erste Nachricht in der Gruppe einen Timeout hatte.

Abbildung 5 - Beschäftigter Router oder verworfene Pakete

Wenn alle drei Nachrichten eine Zeitüberschreitung aufweisen, aber die nachfolgenden Hops Zeiten melden (Abbildung 6), ist es wahrscheinlich, dass der Router für diesen Hop einfach keine ICMP-Zeitüberschreitungsnachrichten sendet.

Abbildung 6 - nicht reagierende(r) Router

Wenn alle Hops nach einem bestimmten Punkt eine Zeitüberschreitung aufweisen (Abbildung 7), ist es wahrscheinlich, dass eine Firewall entweder die ausgehenden oder die zurückkehrenden Nachrichten blockiert.

Abbildung 7 - Firewall-Blockierung

Es gibt noch einen weiteren Grund, warum alles nach einem bestimmten Punkt ausfällt. Nämlich dann, wenn das Ziel nicht antwortet. Nicht alle Ziele antworten, und wenn das passiert, entsteht etwas, das wie in Abbildung 8 aussieht. Der Unterschied zwischen den Abbildungen 7 und 8 besteht darin, dass in Abbildung 8 der letzte Router, der eine Antwort sendet, der Router ist, der sich in der Nähe des Ziels befindet. Woran erkennt man, dass dies der Fall ist? Manchmal ist es aufgrund der Adressierung offensichtlich, zum Beispiel ist das Ziel 192.168.1.12 und 192.168.1.1 ist der letzte Router, der antwortet. In Abbildung 9 ist es nicht ganz so offensichtlich, EEE.FFF.W.XXX könnte der letzte Router vor EEE.FFF.GGG.HHH sein, sie haben die ersten 16 Bits gemeinsam. Aber ohne das Subnetzschema des Zielnetzes zu kennen, kann man nicht sicher sein, ohne nachzufragen.

Abbildung 8 - Ziel reagiert nicht

Es ist auch möglich, Antworten von zwei oder mehr Routern für denselben Hop zu erhalten (Abbildung 9). Dies kann vorkommen, wenn die Router einen Lastausgleich vornehmen oder das Netz instabil ist und sich die Routen ändern, oder wenn, wie in Abbildung 9, der Router AAA.BBB.CC.KKK nicht der optimale Router war und nach der Weiterleitung des Pakets an AAA.BBB.II.J eine Umleitungsnachricht an die Quelle zurückgeschickt hat, um seine Routing-Tabelle zu ändern.

Abbildung 9 - zwei Antworten für denselben Hopfen

Es gibt zwei Arten von Traceroute-Befehlen, die sich durch die Art der Nachricht unterscheiden, die sie senden. Einige Traceroute-Befehle, wie der auf Microsoft Windows-Systemen, senden ICMP-Echo-Request-Nachrichten (Ping); andere, wie der unter STCP laufende, senden UDP-Nachrichten. Zu wissen, welche Art von Traceroute Sie verwenden, ist wichtig, wenn Sie Firewalls so konfigurieren müssen, dass sie Pakete durchlassen oder Protokollanalysefilter schreiben. Auch die Antwort des Ziels wird unterschiedlich ausfallen. Wenn das Ziel eine Ping-Anfrage erhält, sendet es eine Ping-Antwort zurück; wenn es eine UDP-Nachricht empfängt, hängt die Antwort von der Portnummer ab. Wenn der Port in Gebrauch ist, wird die zuhörende Anwendung das Paket höchstwahrscheinlich verwerfen, da es nicht den Anforderungen der Nachrichtenstruktur der Anwendung entspricht. Wenn der Port nicht benutzt wird, *kann* der Host eine ICMP-Zielport-Unreachable-Nachricht zurücksenden. Aus diesem Grund wählt Traceroute Ports aus, die normalerweise nicht verwendet werden.

Welche Portnummer der Zielhost zu sehen bekommt, hängt davon ab, wie viele Hops erforderlich sind, um ihn zu erreichen. Traceroute beginnt den Zielport bei 33435 (Standard) und erhöht die Portnummer für jede Nachricht (Abbildung 10). Das Ziel sieht also 3 verschiedene Ports, wobei die Wahrscheinlichkeit groß ist, dass nicht alle drei in Gebrauch sind. Der Quellport basiert auf der Prozess-ID des sendenden Prozesses. Ein bestimmter Prozess wird immer denselben Quellport verwenden.

Schließlich gibt es wahrscheinlich nicht viel, was Sie tun können, um das Problem zu beheben, es sei denn, es gibt ein Problem beim ersten Hop. Sobald STCP (oder der Netzwerkstack eines beliebigen Hosts) ein Paket an den lokalen Router sendet, liegt es nicht mehr in seiner (und Ihrer) Hand. Wenn Sie jedoch die IP-Adresse des letzten Hops kennen, der antwortet, oder des Hops, bei dem plötzlich Timeouts auftreten, haben Sie eine Vorstellung davon, wo das Problem liegt, und können sich an die richtige Gruppe von Netzwerkadministratoren wenden, um es zu beheben.