MTR vs. Traceroute: Wann nutzt man welches Tool?

MTR vs. Traceroute: Wann nutzt man welches Tool? – diese Frage taucht in der Praxis immer dann auf, wenn ein Netzwerkpfad „irgendwo dazwischen“ Probleme macht: Latenzspitzen, Paketverlust, Timeouts oder sporadische Verbindungsabbrüche. In vielen Teams ist Traceroute das Standardwerkzeug, weil es schnell einen Pfad zeigt. Gleichzeitig liefert MTR (My Traceroute) oft deutlich bessere Hinweise, wenn das Problem nicht konstant ist, sondern intermittierend auftritt oder wenn man neben dem Pfad auch statistische Aussagen über Latenz und Loss braucht. Beide Tools basieren auf ähnlichen Grundprinzipien (TTL/Hop Limit und ICMP-Antworten), unterscheiden sich aber im Arbeitsmodus, in der Aussagekraft und in den häufigsten Fehlinterpretationen. Dieser Artikel erklärt verständlich und praxisnah, wie Traceroute und MTR funktionieren, welche Messarten sie unterstützen (ICMP, UDP, TCP), wo ihre Grenzen liegen (Rate Limiting, ICMP-Depriorisierung, asymmetrische Routen, ECMP) und wie Sie die Ausgaben richtig lesen. Ziel ist, dass Sie im Incident oder bei Performance-Analysen schnell entscheiden können, ob Traceroute reicht oder ob MTR die bessere Wahl ist – und wie Sie beide sinnvoll kombinieren.

Grundidee: Was beide Tools gemeinsam haben

Sowohl Traceroute als auch MTR machen Netzwerkpfade sichtbar, indem sie Pakete mit einer begrenzten „Lebensdauer“ senden. Bei IPv4 ist das das TTL-Feld (Time To Live), bei IPv6 das Hop Limit. Jeder Router, der ein Paket weiterleitet, reduziert TTL/Hop Limit um 1. Erreicht der Wert 0, verwirft der Router das Paket und sendet typischerweise eine ICMP-Antwort zurück („Time Exceeded“). Indem ein Tool Pakete mit TTL=1, TTL=2, TTL=3 usw. sendet, kann es die einzelnen Hops auf dem Weg zum Ziel sichtbar machen.

Wichtig: Diese Methode zeigt in erster Linie den Rückkanal der ICMP-Antworten. Sie ist daher empfindlich gegenüber Policies (ICMP geblockt), Priorisierung (ICMP wird gedrosselt), und asymmetrischen Pfaden (Hinweg und Rückweg unterscheiden sich).

Traceroute im Überblick: Stärken und typische Einsatzfälle

Traceroute ist in vielen Umgebungen das „erste Werkzeug“, weil es sehr schnell einen Pfad liefert. Es zeigt, über welche Router/Netzkomponenten ein Paket zum Ziel gelangt – oder bis zu welchem Hop es kommt, wenn es nicht ankommt. Das ist besonders nützlich für:

• Erste Orientierung: „Wo endet der Pfad?“ oder „Welche Zwischenstationen existieren?“
• Routing-/Reachability-Fragen: Falsches Routing, unerwartete Provider-Hops, falsche Next-Hops.
• Firewall-/Policy-Verdacht: Wenn Traceroute ab einem Hop komplett „* * *“ zeigt, kann das auf Filterung hindeuten.
• DNS- und Zielvalidierung: Stimmt das Ziel (IP/Host) und sieht der Pfad plausibel aus?

Ein wichtiger Punkt: Klassisches Traceroute liefert in der Regel nur eine kleine Anzahl Probes pro Hop (häufig 3). Das reicht für eine Momentaufnahme, ist aber schwach bei intermittierenden Problemen. Wenn Paketverlust nur sporadisch auftritt oder wenn Latenzspitzen selten sind, können drei Probes pro Hop den Effekt schlicht verpassen.

Referenzen: Je nach System variiert die Implementierung; hilfreich sind die Manpages für Details zu Optionen und Modi: traceroute(8) Manpage und OpenBSD traceroute Manpage.

MTR im Überblick: Warum es bei Diagnosen häufig überlegen ist

MTR kombiniert die Pfadermittlung von Traceroute mit einem kontinuierlichen Messmodus ähnlich wie Ping – allerdings pro Hop. Das bedeutet: MTR sendet wiederholt Probes und aktualisiert laufend Statistikwerte wie Paketverlust und Latenz (Min/Avg/Max, teils auch Jitter/Standardabweichung abhängig von Version/Optionen). Dadurch wird MTR besonders wertvoll, wenn das Problem nicht statisch ist.

• Intermittierender Paketverlust: MTR kann über Zeit statistisch sichtbar machen, ob Loss tatsächlich existiert.
• Latenzspitzen: MTR zeigt Max/Avg, wodurch seltene Peaks erkennbar werden.
• Vergleich über Zeitfenster: Sie können MTR laufen lassen, während ein Incident aktiv ist, und Veränderungen beobachten.
• Schnelle Hypothesen: „Ab Hop X steigen Latenz und Loss“ ist mit MTR oft klarer als mit Traceroute.

Auch hier gilt: MTR ist kein perfektes Orakel. ICMP-Depriorisierung und Rate Limits können Loss in der Anzeige erzeugen, obwohl der tatsächliche Datenverkehr nicht betroffen ist. Der Vorteil ist, dass MTR Sie schneller auf „auffällige Stellen“ hinweist – die Sie anschließend mit weiteren Tools verifizieren.

Referenz: MTR Projektseite und mtr(8) Manpage.

Messmodi: ICMP vs. UDP vs. TCP – und warum das die Ergebnisse stark beeinflusst

Viele Fehlinterpretationen entstehen dadurch, dass Traceroute und MTR nicht zwingend den gleichen „Typ“ von Probe verwenden. Je nach Implementierung und Option können Probes als UDP, ICMP Echo oder TCP SYN gesendet werden. Das ist entscheidend, weil Firewalls und Netzkomponenten Protokolle unterschiedlich behandeln.

ICMP (Ping-ähnlich)

• Vorteil: Häufig einfach und schnell, gut für generelle Reachability.
• Nachteil: ICMP wird in vielen Netzen gedrosselt oder niedriger priorisiert, wodurch Loss/Latenz verfälscht sein kann.

UDP (klassisches traceroute-Verhalten in vielen Implementierungen)

• Vorteil: Historisch weit verbreitet; Router antworten mit „Time Exceeded“, Ziel häufig mit „Port Unreachable“.
• Nachteil: UDP kann in Cloud-/Enterprise-Umgebungen stärker gefiltert werden als ICMP.

TCP (z. B. zu Port 443)

• Vorteil: Realitätsnäher, wenn Ihre Anwendung TCP/443 nutzt; Firewalls lassen TCP/443 oft eher passieren als ICMP/UDP.
• Nachteil: Nicht jeder Hop antwortet gleich; manche Geräte behandeln TCP-Probes anders, und NAT/Stateful Devices können die Sichtbarkeit beeinflussen.

Praxisempfehlung: Wenn Sie ein Webservice-Problem debuggen, ist ein TCP-basierter Traceroute/MTR (z. B. zu Port 443) oft aussagekräftiger als ICMP. Für reine Infrastrukturtests kann ICMP ausreichen, solange Sie die typischen Verzerrungen kennen.

Ausgaben richtig lesen: Was Loss pro Hop wirklich bedeutet

Der häufigste Denkfehler lautet: „Wenn ein Hop Paketverlust zeigt, ist dieser Router schuld.“ Das stimmt nicht automatisch. Viele Router beantworten TTL-expired ICMP nur rate-limitiert oder mit niedriger Priorität. Dadurch kann ein Hop in MTR/Traceroute Loss anzeigen, während die nachfolgenden Hops (und das Ziel) keine Probleme zeigen. In so einem Fall ist der Loss meist ein Messartefakt, nicht ein Datenpfadverlust.

Ein pragmatisches Interpretationsschema:

• Loss nur auf einem Zwischenhop, danach wieder 0% bis zum Ziel: häufig ICMP Rate Limiting, meist kein echter Datenverlust.
• Loss ab einem Hop und der Loss setzt sich bis zum Ziel fort: deutlich wahrscheinlicher echter Paketverlust auf oder hinter diesem Punkt.
• Latenzsprung ab einem Hop und bleibt bis zum Ziel erhöht: möglicher Engpass oder längere Route ab diesem Hop.

Warum „Loss zum Hop“ und „Loss durch den Hop“ nicht dasselbe ist

MTR misst pro Hop, wie viele Probes an diesen Hop eine Antwort geliefert haben. Das ist nicht identisch mit „wie viele Datenpakete verliert der Hop beim Weiterleiten“. Ein Router kann Ihre TTL-Probes ignorieren und dennoch Ihren echten Datenverkehr korrekt forwarden.

Einfaches Loss-Rechenbeispiel

$\mathrm{Loss\%}=\frac{\mathrm{sent}–\mathrm{received}}{\mathrm{sent}}\times 100$

Beispiel: 100 Probes gesendet, 95 Antworten erleichtert → 5% Loss. Wenn aber das Ziel selbst 100/100 antwortet, ist der „Loss“ auf Zwischenhops sehr wahrscheinlich nur Antwort-Depriorisierung.

Wann Traceroute die bessere Wahl ist

Traceroute ist oft ausreichend, wenn Sie eine schnelle, einmalige Pfadaufnahme brauchen. Typische Situationen:

• „Wo geht es lang?“ Sie möchten in Sekunden wissen, ob der Traffic über erwartete Netzsegmente/Provider läuft.
• Akute Reachability-Frage: Ein Ziel ist nicht erreichbar, und Sie wollen die letzte sichtbare Station finden.
• Change-Validation: Nach Routing- oder Firewall-Änderungen prüfen Sie, ob der Pfad plausibel ist.
• Minimalinvasiv: Sie möchten keine längeren Tests laufen lassen, sondern nur eine Momentaufnahme.

In Cloud-Umgebungen kann Traceroute außerdem helfen, grobe Pfadunterschiede zwischen Regionen/Zonen zu erkennen, bevor Sie tiefer in Observability (Flow Logs, Metriken) einsteigen.

Wann MTR die bessere Wahl ist

MTR lohnt sich besonders, wenn Zeit und Statistik wichtig sind. Typische Situationen:

• Intermittierende Störungen: Sporadische Timeouts, kurze Aussetzer, „flaky“ Verbindungen.
• Latenzspikes: Nutzer berichten über gelegentliche „Langsamkeit“, aber Averages sind unauffällig.
• Vergleich mehrerer Pfade: Sie testen von verschiedenen Quellen (Nodes/Regions) und brauchen vergleichbare Werte.
• Provider-/WAN-Probleme: Loss/Latency über Zeit ist hier entscheidend, nicht der Moment.

Ein praktischer Ansatz ist: Traceroute für den groben Pfad, MTR für die statistische Absicherung. Wenn Sie bereits vermuten, dass ein Problem „nur manchmal“ auftritt, sparen Sie Zeit, wenn Sie direkt zu MTR greifen.

Cloud- und Unternehmensnetze: Typische Fallstricke bei beiden Tools

In modernen Netzen gibt es mehrere Gründe, warum Traceroute/MTR nicht so „sauber“ aussehen wie in Lehrbuchbeispielen.

• ICMP Rate Limiting: Router priorisieren Forwarding gegenüber ICMP-Antworten.
• Firewalls/Policies: ICMP oder UDP wird geblockt; TCP/443 funktioniert dagegen.
• Asymmetrische Pfade: Hinweg und Rückweg unterscheiden sich; die ICMP-Antwort kommt über einen anderen Pfad zurück.
• ECMP/Load Balancing: Mehrere gleichwertige Pfade; Probes können unterschiedliche Hops zeigen.
• NAT und Proxies: Der sichtbare Pfad ist nicht identisch mit dem logischen Servicepfad.

Gerade ECMP kann dazu führen, dass Traceroute scheinbar „springt“ oder unterschiedliche Router pro Hop zeigt. Das ist nicht zwingend ein Fehler, sondern häufig normales Routingverhalten.

Praktische Auswahl: Entscheidungsregeln in der On-Call-Situation

Wenn Sie in einem Incident schnell handeln müssen, helfen einfache Regeln:

• Wenn das Problem konstant ist (immer kaputt): Traceroute zuerst, um die letzte Station zu sehen.
• Wenn das Problem sporadisch ist: MTR laufen lassen, um Loss/Latency über Zeit sichtbar zu machen.
• Wenn ICMP/UDP vermutlich gefiltert wird: TCP-basierte Varianten wählen (z. B. Port 443).
• Wenn nur ein Zwischenhop Loss zeigt: Nicht vorschnell „Schuldigen“ benennen; prüfen, ob sich Loss bis zum Ziel fortsetzt.

Wie Sie beide Tools sinnvoll kombinieren

Ein bewährtes Vorgehen ist ein zweistufiger Ablauf:

• Stufe 1 (Pfadaufnahme): Traceroute (oder ein kurzer MTR-Lauf) zur Pfadübersicht.
• Stufe 2 (Statistik): MTR über ein geeignetes Zeitfenster, um Stabilität, Loss und Latenzverteilung zu bewerten.

Wenn Sie parallel Observability-Signale haben (APM, Proxy-Metriken, Flow Logs), nutzen Sie diese, um den betroffenen Pfadbereich einzugrenzen. PCAP ist meist erst dann nötig, wenn trotz MTR/Traceroute unklar bleibt, ob z. B. RSTs von einem Load Balancer kommen oder ob MTU/Fragmentierung im Spiel ist.

Interpretation von Latenz: Min/Avg/Max sind nicht gleich wichtig

MTR zeigt typischerweise pro Hop Min/Avg/Max (und oft auch Standardabweichung). Für Performance-Diagnosen ist Max häufig der erste Hinweis auf Spikes, während Avg eher den „Normalzustand“ beschreibt. Min kann zeigen, ob der Pfad grundsätzlich schnell sein könnte, und ob Peaks eher durch Queueing/Bufferbloat entstehen.

• Min stabil, Max hoch: häufig sporadisches Queueing oder Burst-Last.
• Avg dauerhaft hoch ab Hop X: möglicher Pfadwechsel oder Engpass ab diesem Segment.
• Stark schwankende Werte auf Zwischenhops, Ziel stabil: oft ICMP-Depriorisierung, nicht zwingend Datenpfadproblem.

Tooling-Alternativen und Ergänzungen

In einigen Situationen sind andere Tools geeigneter oder ergänzen MTR/Traceroute sinnvoll:

• ping: Einfacher End-to-End-Test erklärt aber nicht den Pfad.
• tcping / hping: Für TCP-basierte Reachability-Tests und spezifische Ports.
• pathping (Windows): Ähnlich zu MTR/Traceroute-Kombination, aber OS-spezifisch.
• Flow Logs: Metadaten über Accept/Reject und Bytes/Packets ohne Protokolldetails.

Gerade in Cloud-Umgebungen sind Flow Logs oft der nächste Schritt, wenn MTR/Traceroute aufgrund von Policies wenig zeigt. Sie liefern zwar keine Paketinhalte, aber sie helfen zu klären, ob Verbindungen überhaupt erlaubt sind und ob es Rejects gibt.

Best Practices: So vermeiden Sie die häufigsten Fehlalarme

• Immer das Ziel als Referenz betrachten: Zwischenhops sind weniger verlässlich als die End-to-End-Sicht.
• Gleichen Messmodus wählen: Vergleichen Sie nicht ICMP-Traceroute mit TCP-MTR und wundern sich über explains.
• Ausreichend lange messen: Bei Intermittency sind 10–30 Sekunden oft zu kurz; je nach Problem eher 2–5 Minuten.
• Mehrere Quellen testen: Wenn nur eine Node betroffen ist, sieht der Pfad von einer anderen Node anders aus.
• ECMP berücksichtigen: Unterschiedliche Hops können normal sein, nicht zwingend ein Defekt.

Outbound-Quellen für vertiefende Informationen

• MTR Projektseite (My Traceroute): Hintergrund und Downloads
• mtr(8) Manpage: Optionen, Ausgabeformate und Messmodi
• traceroute(8) Manpage: Protokolle, Parameter und typische Defaults
• OpenBSD traceroute Manpage: Alternative Implementierungsdetails
• Wireshark Dokumentation: Wenn Pfadtools nicht reichen und Protokolldetails nötig sind
• ICMPv6 (RFC 4443): Grundlagen zu Time Exceeded und Diagnosen in IPv6

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.