VMware ESXi and vSphere Cluster Management

traceroute-Befehl unter Linux: Netzwerkpfade analysieren

Lernen Sie traceroute unter Linux kennen: Syntax, TTL, Hops, Probe-Methoden, Optionen, Ausgabe und praktische Fehlerdiagnose.

traceroute ist ein Kommandozeilenwerkzeug zur Ermittlung und Anzeige des Netzwerkpfads von einem lokalen Rechner zu einem Zielhost. Die Ausgabe zeigt Zwischenstationen, sogenannte Hops, sowie die gemessene Antwortzeit.

Der Befehl hilft dabei, Erreichbarkeitsprobleme, ungewöhnliche Routing-Wege, hohe Latenzen und mögliche Unterbrechungsstellen einzugrenzen. Er liefert jedoch keine Garantie dafür, dass jedes einzelne Anwendungspaket exakt denselben Weg nimmt: Routen können sich durch Lastverteilung, Routingänderungen oder asymmetrisches Routing unterscheiden.

Voraussetzungen und Installation

Sie benötigen grundlegende Kenntnisse zu IP-Adressen, Domainnamen, Routern, der Linux-Kommandozeile sowie zu ICMP, UDP und TCP. Auf vielen Distributionen ist traceroute nicht standardmäßig installiert. Installieren Sie das Paket daher bei Bedarf über die Paketverwaltung Ihrer Distribution.

Prüfen Sie anschließend die lokal verfügbare Dokumentation:

man traceroute

Bestimmte Sondierungsmethoden können besondere Rechte benötigen oder durch lokale und entfernte Sicherheitsregeln eingeschränkt sein. Welche Optionen verfügbar sind, hängt von der installierten Implementierung und Distribution ab.

Grundsyntax und erster Aufruf

Die allgemeine Syntax lautet:

traceroute [Optionen] Ziel

Als Ziel können Sie einen Domainnamen, eine IPv4-Adresse oder eine IPv6-Adresse angeben.

traceroute example.com

Der Befehl beginnt die Messung am lokalen Rechner und versucht, die Router auf dem Weg zum Ziel zu identifizieren. Ein Router ist ein Netzwerkgerät, das Pakete zwischen unterschiedlichen Netzen weiterleitet.

Wie traceroute funktioniert

TTL als Grundlage

Die zentrale Grundlage ist das Feld TTL (Time To Live) im IP-Paket. Es begrenzt die Anzahl möglicher Weiterleitungen. Jeder Router verringert die TTL typischerweise um eins. Erreicht sie null, darf das Paket nicht weitergeleitet werden.

traceroute sendet zunächst eine Sonde mit niedriger TTL, meist mit TTL 1. Der erste Router verwirft diese Sonde wegen der abgelaufenen TTL und sendet üblicherweise eine ICMP Time Exceeded-Nachricht zurück. ICMP, das Internet Control Message Protocol, dient unter anderem Kontroll- und Fehlermeldungen im IP-Netz.

Danach erhöht traceroute die TTL schrittweise auf 2, 3 und weitere Werte. So antwortet zunächst der zweite Router, dann der dritte und so weiter. Aus den Antwortadressen und den verstrichenen Zeiten entsteht die Hop-Liste.

Zielerkennung

Wann das Ziel erreicht ist, hängt von der verwendeten Probe-Methode ab. Bei klassischem UDP-traceroute werden meist hohe, wahrscheinlich ungenutzte Zielports angesprochen. Ein erreichter Zielhost antwortet dann typischerweise mit ICMP Port Unreachable. Diese Antwort bedeutet in diesem Zusammenhang, dass die Sonde das Ziel erreicht hat, dort aber kein Dienst auf dem verwendeten Port lauscht.

Pro Hop werden standardmäßig häufig mehrere Sonden gesendet. Dadurch erscheinen mehrere RTT-Werte. RTT (Round-Trip Time) ist die Zeit für Hin- und Rückweg einer Sonde, normalerweise in Millisekunden.

Linux-spezifisches Standardverhalten

Die klassische Linux-Variante verwendet häufig UDP-Sonden mit hohen Zielports. Der Portbereich beginnt üblicherweise bei 33434 und wird für weitere Sonden erhöht. Hohe Ports werden gewählt, weil dort wahrscheinlich kein regulärer Dienst lauscht und die Zielantwort dadurch als Port-Fehler erkennbar werden kann.

Implementierungen unterscheiden sich jedoch. Zusätzlich zu UDP können sie ICMP- oder TCP-Sonden unterstützen. Firewall-Regeln, NAT (Network Address Translation) und Router-Konfigurationen können diese Methoden unterschiedlich behandeln.

Probe-Methoden im Vergleich

Eine Probe ist eine einzelne Messsonde, die mit einer bestimmten TTL und einem bestimmten Protokoll gesendet wird.

Methode | Typische Option | Gesendete Sonden | Typische Antwort am Ziel | Geeignete Einsatzfälle | Mögliche Filterprobleme

UDP | Standard, abhängig von der Implementierung | UDP an hohe Zielports | ICMP Port Unreachable | Klassische Linux-Routenanalyse | UDP oder ICMP-Antworten können gefiltert werden

ICMP | -I | ICMP Echo Request | ICMP Echo Reply | Wenn UDP nicht aussagekräftig ist | ICMP kann blockiert oder rate-limitiert werden

TCP | -T, häufig mit -p 443 | TCP-Sonden zu einem Zielport | Je nach Zustand TCP- oder ICMP-Antwort | Wenn nur bestimmte TCP-Dienste zugelassen sind | TCP-SYNs, Antworten oder Ports können gefiltert werden

Die Groß-/Kleinschreibung der Optionen ist wichtig: -I wählt ICMP-Echo-Probes, während -i ein ausgehendes Netzwerkinterface auswählt.

Wichtige Optionen

Option | Bedeutung | Beispiel | Hinweise

-n | Reverse-DNS-Namensauflösung unterdrücken | traceroute -n example.com | Schneller und übersichtlicher; Adressen werden numerisch angezeigt

-q | Anzahl der Sonden pro Hop festlegen | traceroute -q 1 example.com | Weniger Messwerte verkürzen die Ausgabe, reduzieren aber die Vergleichbarkeit

-I | ICMP-Echo-Probes verwenden | traceroute -I example.com | Nicht mit -i verwechseln

-i | Ausgehendes Netzwerkinterface auswählen | traceroute -i eth0 example.com | Möglich sind je nach System etwa eth0, enp0s3 oder wlan0

-m | Maximale Hop-Anzahl festlegen | traceroute -m 20 example.com | Begrenzt die Suche nach sehr langen oder fehlerhaften Pfaden

-w | Wartezeit pro Antwort anpassen | traceroute -w 3 example.com | Lange Wartezeiten machen die Messung langsamer

-f | Start-TTL beziehungsweise ersten Hop festlegen | traceroute -f 3 example.com | Überspringt die Messung niedriger TTL-Werte

-T | TCP-Probes verwenden | traceroute -T -p 443 example.com | Nur verwenden, wenn die lokale Version diese Methode unterstützt

Prüfen Sie die genaue Bedeutung und Verfügbarkeit einzelner Optionen immer mit man traceroute. Die Implementierung kann sich zwischen Distributionen unterscheiden.

Eine typische Ausgabe lesen

traceroute to example.com (203.0.113.20), 30 hops max, 60 byte packets
 1  192.168.1.1       1.234 ms  1.102 ms  1.087 ms
 2  gateway.example   8.421 ms  8.510 ms  8.477 ms
 3  *                 *         *
 4  198.51.100.10     18.2 ms  17.9 ms  18.1 ms

Ausgabeelement | Bedeutung | Interpretationshinweis

Hop-Nummer | Position der Station im Pfad | Hop 1 ist normalerweise der erste Router hinter dem lokalen Rechner

Hostname | Durch Reverse DNS ermittelter Name zur IP-Adresse | Der Name ist eine Zusatzinformation und muss nicht vorhanden oder korrekt beschreibend sein

IP-Adresse | Adresse des antwortenden Routers oder Zielhosts | Mit -n sehen Sie nur numerische Adressen

Zeitwerte in ms | RTT der einzelnen Sonden | Mehrere Werte gehören zu mehreren Sonden desselben Hops

Sternchen (*) | Innerhalb der Wartezeit kam keine verwertbare Antwort an | Beweist nicht automatisch, dass der Pfad hinter diesem Hop unterbrochen ist

Ein Hostname entsteht durch Reverse DNS, also die Zuordnung einer IP-Adresse zu einem Hostnamen. Diese Namensauflösung kann die Ausgabe verzögern. Für eine schnelle Diagnose ist daher oft folgende Variante sinnvoll:

traceroute -n 1.1.1.1

Messwerte vorsichtig interpretieren

Hohe oder schwankende Zeiten an einem einzelnen Zwischenhop sind nicht automatisch ein Beweis für ein Leistungsproblem. Router priorisieren häufig die Weiterleitung echter Datenpakete gegenüber der Erzeugung von Diagnoseantworten. Zusätzlich kann ICMP-Rate-Limiting die Antworten verlangsamen oder ausdünnen.

Wenn ein Hop hohe Werte zeigt, nachfolgende Hops aber wieder normale Werte liefern, liegt die Verzögerung wahrscheinlich nur bei der Antwort dieses Routers. Aussagekräftiger ist ein dauerhaft erhöhter RTT-Wert, der auch bei allen folgenden Hops sichtbar bleibt.

Ein Sternchen bedeutet zunächst nur, dass für diese Sonde innerhalb des Zeitlimits keine Antwort einging. Router dürfen solche Antworten filtern, unterdrücken oder begrenzen und können die Pakete trotzdem weiterleiten.

Praktische Beispiele

Standardroute zu einer Domain

traceroute example.com

Verwenden Sie diesen Aufruf, um Hop-Nummern, Routeradressen und mehrere Antwortzeiten zu sehen. Beim klassischen UDP-Verfahren erkennen Sie das Ziel häufig an der ICMP-Port-Unreachable-Antwort.

Route ohne Namensauflösung

traceroute -n 1.1.1.1

-n verhindert Reverse-DNS-Abfragen. Das beschleunigt die Messung und vermeidet, dass langsame oder fehlerhafte DNS-Auflösungen die Analyse erschweren.

Anzahl der Sonden reduzieren

traceroute -q 1 example.com

Mit -q 1 wird eine Sonde pro Hop gesendet. Die Ausgabe wird kürzer, aber einzelne Ausreißer lassen sich schlechter erkennen. Mehrere Standardwerte liefern bessere Hinweise auf Schwankungen.

ICMP-Probes verwenden

traceroute -I example.com

Das große -I verwendet ICMP-Echo-Probes, ähnlich wie ping. Diese Methode kann einen anderen Weg durch Filterregeln nehmen und daher zusätzliche Informationen liefern.

Bestimmtes Interface auswählen

traceroute -i eth0 example.com

Das kleine -i bindet die Messung an ein ausgehendes Interface. Ersetzen Sie eth0 durch den Namen der gewünschten Netzwerkkarte, beispielsweise enp0s3 oder wlan0.

TCP bei gefiltertem UDP testen

traceroute -T -p 443 example.com

TCP-Probes zu Port 443 können sinnvoll sein, wenn ein Netz UDP- oder ICMP-Diagnoseverkehr filtert, HTTPS-Verkehr aber zulässt. Das Ergebnis beschreibt dann die Behandlung dieser TCP-Methode und muss nicht mit dem UDP-Pfad identisch sein.

Fehlerdiagnose mit traceroute

Schrittweise vergleichen

1. Prüfen Sie zunächst ein bekannt funktionierendes Ziel und anschließend das problematische Ziel.
2. Verwenden Sie zunächst dieselbe Methode und dieselben Optionen, zum Beispiel traceroute -n.
3. Vergleichen Sie den ersten Hop, den Übergang vom lokalen Netz zum Internetzugang, die Provider-Hops und das Zielnetz.
4. Wiederholen Sie die Messung zu unterschiedlichen Zeitpunkten, um vorübergehende Last oder wechselnde Routen zu erkennen.
5. Testen Sie bei unvollständiger Ausgabe zusätzlich -I und, sofern verfügbar, -T -p 443.

Sternchen ab einem bestimmten Hop

Wenn ab einem Hop nur noch Sternchen erscheinen, kommen mehrere Ursachen infrage: Der Router beantwortet abgelaufene TTL-Sonden nicht, ICMP-Antworten werden gefiltert oder die Route beziehungsweise das Ziel ist tatsächlich nicht erreichbar.

Prüfen Sie, ob spätere Hops oder das Ziel dennoch erscheinen. Testen Sie danach eine andere Probe-Methode und vergleichen Sie mit ping, einer DNS-Prüfung und einem tatsächlichen Anwendungszugriff. Ein wiederkehrender letzter sichtbarer Hop ist ein möglicher Eingrenzungspunkt, aber kein sicherer Beweis für den Fehlerort.

Ein auffälliger Zwischenhop

Zeigt nur ein Zwischenhop hohe Zeiten, während spätere Hops normale Zeiten liefern, sind niedrige Antwortpriorität oder ICMP-Rate-Limiting wahrscheinliche Erklärungen. Beurteilen Sie nicht nur diesen einzelnen Hop, sondern den Verlauf der Werte bis zum Ziel.

Befehl nicht gefunden

Bei der Meldung, dass traceroute nicht gefunden wurde, ist das Paket wahrscheinlich nicht installiert oder der Befehlspfad nicht verfügbar. Installieren Sie das Paket über die Paketverwaltung Ihrer Distribution und prüfen Sie anschließend mit man traceroute die lokale Version.

traceroute mit anderen Werkzeugen kombinieren

• ping: Prüft die grundlegende Erreichbarkeit und misst RTT, zeigt aber keine vollständige Hop-Liste.
• DNS-Werkzeuge: Mit dig oder nslookup lassen sich Namensauflösung und DNS-Antworten unabhängig untersuchen.
• mtr: Kombiniert wiederholte Ping-Messungen mit einer laufenden Routenübersicht und ist hilfreich, um Schwankungen und möglichen Paketverlust über längere Zeit zu beobachten.
• ip route: Zeigt die lokale Routingentscheidung und hilft bei der Prüfung des ersten Ausgangswegs.

Grenzen der Aussagekraft

• Asymmetrisches Routing: Hin- und Rückweg können unterschiedliche Router verwenden. traceroute misst die Antwortstrecke zurück zum lokalen Rechner, nicht zwingend den vollständigen Rückweg des Anwendungspakets.
• Lastverteilung: Router können Pakete derselben Verbindung auf unterschiedliche Wege verteilen.
• Filterung: Firewalls können UDP, ICMP, TCP oder nur bestimmte Fehlermeldungen blockieren.
• Unterschiedliche Priorisierung: Diagnoseantworten werden oft anders behandelt als normaler Datenverkehr.
• Methodenabhängigkeit: UDP-, ICMP- und TCP-Traceroutes können unterschiedliche Ergebnisse liefern, ohne dass eines davon zwingend falsch ist.

Kurzreferenz

traceroute example.com             # Standardroute
traceroute -n example.com          # Keine Reverse-DNS-Auflösung
traceroute -q 1 example.com        # Eine Sonde je Hop
traceroute -I example.com          # ICMP-Echo-Probes
traceroute -i eth0 example.com     # Bestimmtes Interface
traceroute -m 20 example.com       # Maximal 20 Hops
traceroute -w 3 example.com        # Drei Sekunden Wartezeit
traceroute -T -p 443 example.com   # TCP zu Port 443, falls unterstützt
man traceroute                     # Lokale Optionen prüfen

Weitere Informationen zur lokalen Befehlsreferenz finden Sie unter traceroute-Befehl.