Weblog

Mythos traceroute

01.04.2025 3 Min. Lesezeit

Warum traceroute kein verlässliches Werkzeug ist.

Ein kritischer Blick auf ein oft überschätztes Diagnose-Tool.

Einleitung

traceroute (bzw. tracert unter Windows) ist eines der bekanntesten Werkzeuge zur Netzwerkdiagnose. Es zeigt den Pfad, den Pakete durch ein IP-Netzwerk nehmen, indem es die TTL (Time To Live) systematisch erhöht und ICMP-Antworten auswertet. Doch trotz seiner Popularität ist traceroute kein verlässliches Werkzeug, wenn es um präzise Aussagen über Routing, Latenz oder Erreichbarkeit geht.

Wie traceroute funktioniert

traceroute nutzt das TTL-Feld im IP-Header, das bei jedem Hop dekrementiert wird. Wenn TTL = 0 erreicht ist, sendet der Router ein ICMP “Time Exceeded”-Paket zurück. Durch schrittweises Erhöhen der TTL (1, 2, 3, …) kann man so die Route zum Ziel rekonstruieren.

Je nach Implementierung (ICMP, UDP oder TCP-basierte Varianten) unterscheidet sich das Verhalten leicht:

Linux traceroute nutzt standardmäßig UDP mit hohen Zielports. Windows tracert verwendet ICMP Echo Requests. Moderne Tools wie mtr, paris-traceroute oder tracepath versuchen, einige Schwächen zu kompensieren.

Warum traceroute unzuverlässig ist

Asymmetrisches Routing

Das größte Missverständnis: traceroute zeigt nur den Hinweg der Pakete. In modernen Netzwerken (insbesondere mit ECMP, MPLS oder Policy-Based Routing) ist der Rückweg möglicherweise komplett anders. Die ICMP-Antworten nehmen also nicht zwangsläufig denselben Pfad zurück.

Beispiel: Ein Paket geht über Router A → B → C → Ziel, aber die ICMP-Antwort kommt über C → D → E → Quelle zurück. traceroute zeigt nur A → B → C.

ICMP-Rate-Limiting und Filtering

Viele Router oder Firewalls priorisieren ICMP sehr niedrig oder blockieren es ganz. Das führt zu:

Zeitüberschreitungen (Timeouts) bei bestimmten Hops Falschen Latenzangaben, weil ICMP depriorisiert wird Fehlenden Hops, obwohl der Pfad korrekt funktioniert.

Ob es ein faires Verhalten ist ICMP zu blockieren steht auf einem anderen Blatt.

Load Balancing und ECMP

Bei Equal-Cost Multi-Path (ECMP) Routing kann ein Router mehrere gleichwertige Pfade nutzen. traceroute erzeugt jedoch pro TTL-Wert nur ein Paket - das heißt, es zeigt nur einen zufälligen Pfad.

Tools wie paris-traceroute versuchen, durch konstante Flow-Hash-Werte konsistente Pfade zu zeigen - mit gemischtem Erfolg.

NAT, MPLS und Tunnel

NAT-Gateways können ICMP-Antworten verfälschen oder blockieren. MPLS-Netze verstecken interne Hops, es sei denn, sie sind so konfiguriert, dass sie ICMP “Time Exceeded” senden.

IP/IP oder auch GRE/IPSec-Tunnel können Hops komplett verschleiern.

Unterschiedliche Implementierungen

Nicht alle Systeme verhalten sich gleich:

Windows tracert ≠ Linux traceroute

mtr zeigt aggregierte Statistiken, aber keine exakten Pfade tracepath nutzt UDP mit cleverer TTL-Logik, ist aber nicht weit verbreitet.

Was traceroute trotzdem gut kann

Trotz aller Schwächen hat traceroute seine Daseinsberechtigung:

  • Erste Hinweise auf Routing-Probleme
  • Erkennung von Blackholes oder Firewalls
  • Vergleich von Pfaden zu verschiedenen Zielen
  • Visualisierung von Netzwerkpfaden (z. B. mit mtr oder traceroute -A)

traceroute ist ein Klassiker - aber kein Präzisionswerkzeug. Wer es nutzt, sollte seine technischen Grenzen kennen und die Ergebnisse kritisch hinterfragen. In modernen Netzwerken mit Load Balancing, Firewalls und Tunneln ist traceroute allerdings oft mehr Illusion als Information.

traceroute zeigt dir, was du sehen darfst - nicht, was wirklich passiert.

Bonus: Typische Fehlinterpretationen

„Hop 5 antwortet nicht - da ist das Problem!“
Nicht unbedingt.
Vielleicht ist ICMP blockiert.

„Die Latenz bei Hop 3 ist hoch!“
Höchstwahrscheinlich irrelevant.
Router priorisieren Weiterleitung, nicht ICMP-Antworten.

„Der Pfad ist stabil.“
Vielleicht.
Oder du siehst nur einen von vielen möglichen Pfaden.


Info
Auch wenn das Datum es vermuten läßt, bei diesem Artikel handelt es sich um keinen Aprilscherz.
Themen Technikzeug
Schlagworte ICMP MPLS NAT traceroute Tunnel
π