Traceroute ungenau? Wann MTR sinnvoll ist – und warum

Traceroute ungenau – diese Wahrnehmung ist im Netzwerkbetrieb sehr verbreitet. Ein Traceroute zeigt zwar schnell den Pfad zu einem Ziel, liefert aber oft Ergebnisse, die auf den ersten Blick widersprüchlich wirken: einzelne Hops mit hoher Latenz, scheinbar hoher Paketverlust in der Mitte der Strecke oder „Sterne“ (keine Antwort) an mehreren Stellen, obwohl die Anwendung am Ende trotzdem erreichbar ist. Genau hier ist MTR (My Traceroute) häufig die bessere Wahl: MTR kombiniert Traceroute und Ping in einer laufenden Messung und macht aus einer Momentaufnahme eine Zeitreihe. Damit können Sie nicht nur sehen, wo ein Problem auftreten könnte, sondern auch, wie stabil es ist und ob es sich um ein echtes Pfadproblem oder um ein Messartefakt handelt. Dieser Praxisleitfaden erklärt, warum Traceroute im Alltag oft „ungenau“ wirkt, wann MTR sinnvoll ist, welche Interpretationsfehler typischerweise passieren und wie Sie mit Monitoring- und Troubleshooting-Daten zu belastbaren Aussagen kommen – ohne Rätselraten, ohne voreilige Schuldzuweisungen und ohne falsche Eskalationen.

Wie Traceroute technisch arbeitet und warum das zu Missverständnissen führt

Traceroute basiert auf dem TTL-Prinzip (Time To Live) in IP-Paketen. Das Tool sendet Pakete mit TTL=1, dann TTL=2, dann TTL=3 usw. Jeder Router, der ein Paket wegen abgelaufener TTL verwirft, kann eine Antwort (meist ICMP „Time Exceeded“) zurücksenden. So entsteht eine Liste der Hops bis zum Ziel. Diese Logik ist einfach und nützlich – aber sie hat Grenzen, die in modernen Netzen regelmäßig sichtbar werden.

• Traceroute misst Kontrollpfade, nicht zwingend Datenpfade: Antworten stammen oft aus der Control Plane eines Routers, nicht aus dem Forwarding Path.
• Traceroute ist eine Momentaufnahme: Ein einzelner Lauf bildet keine Schwankungen, Lastspitzen oder intermittierende Probleme ab.
• Traceroute hängt vom Protokoll ab: ICMP-, UDP- und TCP-Traceroute können unterschiedliche Ergebnisse zeigen, weil Firewalls und Router sie unterschiedlich behandeln.

Warum Traceroute „ungenau“ wirkt: Die häufigsten Ursachen

Wenn Traceroute-Ergebnisse „komisch“ aussehen, steckt dahinter oft kein kaputtes Internet, sondern ein Messartefakt. Die folgenden Ursachen sind in Unternehmensnetzen und im Provider-Umfeld besonders häufig.

ICMP-Depriorisierung und Rate-Limits

Viele Router beantworten ICMP-Requests nur mit niedriger Priorität oder begrenzen die Anzahl der Antworten pro Sekunde (Rate-Limit). Das führt dazu, dass einzelne Hops eine hohe Latenz oder sogar scheinbaren Paketverlust zeigen, obwohl der Transitverkehr zum nächsten Hop und zum Ziel korrekt weiterläuft. Das ist einer der Hauptgründe, warum Traceroute „Paketverlust in der Mitte“ anzeigen kann, während Anwendungen stabil funktionieren.

• Hohe RTT an einem Hop, aber alle folgenden Hops und das Ziel haben normale RTT.
• „Loss“ auf einem Hop, aber kein Loss am Ziel.
• Viele „* * *“ trotz erreichbarem Ziel.

Load Balancing (ECMP) und wechselnde Pfade

In modernen Netzen ist Equal-Cost Multi-Path (ECMP) oder anderes Load Balancing üblich. Traceroute sendet mehrere Probes pro TTL. Je nach Hashing (Quell-/Ziel-IP, Ports, Protokoll) können diese Probes unterschiedliche Pfade nehmen. Das erzeugt scheinbar „springende“ Hops oder wechselnde Router-Namen in der Ausgabe – ohne dass ein Fehler vorliegt.

• Ein Hop zeigt mal Router A, mal Router B.
• Die Hop-Reihenfolge wirkt unlogisch, weil verschiedene Probes unterschiedliche Pfadsegmente abbilden.
• Ein einzelner Lauf zeigt eine Route, der nächste Lauf eine andere.

Asymmetrisches Routing

Traceroute zeigt den Hinweg der Probes und den Rückweg der ICMP-Antworten. In vielen Netzen ist der Rückweg nicht identisch mit dem Hinweg (asymmetrisches Routing). Dadurch können RTTs und Hop-Identitäten im Traceroute in die Irre führen: Eine Antwort kann über einen anderen Pfad zurückkommen, wodurch sich Latenzen „aufblähen“, ohne dass der Hinweg problematisch ist.

Firewalls, NAT und Security Gateways

Firewalls und NAT-Gateways können Traceroute-Probes blockieren, umschreiben oder anders behandeln als normalen Datenverkehr. Außerdem werden Time-Exceeded-Antworten manchmal verworfen oder nur selektiv zugelassen. Das Ergebnis: Traceroute bricht scheinbar ab oder zeigt Lücken, obwohl die eigentliche Verbindung (z. B. HTTPS über TCP/443) funktionieren kann.

MPLS, Tunneling und „unsichtbare“ Hops

Provider setzen häufig MPLS oder Tunnels ein. Je nach Konfiguration sind interne Hops nicht sichtbar, oder es erscheinen nur Edge-Router. Traceroute wirkt dann „zu kurz“ oder zeigt Sprünge in der Latenz. Das ist nicht automatisch ein Problem, sondern eine Folge der Abstraktion im Transportnetz.

DNS-Reverse-Lookups und irreführende Namen

Traceroute zeigt häufig Hostnames über Reverse DNS (PTR Records). Diese Namen können veraltet, generisch oder schlicht falsch gepflegt sein. Dadurch entsteht schnell der Eindruck, ein Hop liege geografisch „falsch“ oder gehöre zu einem anderen Provider, obwohl es nur ein Naming-Thema ist.

Was MTR anders macht: Warum MTR bei unklaren Traceroute-Ergebnissen hilft

MTR kombiniert Traceroute und fortlaufende Messungen. Statt einmal pro TTL ein paar Probes zu senden, misst MTR dauerhaft und zeigt pro Hop Statistiken wie Loss und Latenzverteilung. Damit wird aus der Frage „Wie sieht der Pfad jetzt aus?“ die wichtigere Frage „Wie verhält sich der Pfad über Zeit?“ – genau das, was Sie bei sporadischen Problemen und scheinbar „ungenauen“ Traceroutes benötigen.

• Zeitreihe statt Momentaufnahme: MTR zeigt Stabilität, Schwankungen und intermittierende Aussetzer.
• Statistik pro Hop: Loss und RTT pro Hop über viele Probes, nicht nur 1–3 Messpunkte.
• Interpretation wird belastbarer: Sie sehen, ob ein Hop nur ICMP begrenzt oder ob Loss bis zum Ziel durchschlägt.

Wann MTR sinnvoll ist: Typische Einsatzfälle

MTR ist besonders nützlich, wenn Sie nicht nur „den Pfad“ sehen wollen, sondern das Verhalten über Zeit. Diese Szenarien sind im Betrieb typisch:

• Intermittierende Störungen: Anwendungen hängen „manchmal“, VoIP hat kurze Aussetzer, Remote-Desktop ruckelt sporadisch.
• Traceroute zeigt scheinbaren Loss in der Mitte: Sie müssen klären, ob es echter Transit-Loss ist oder ICMP-Depriorisierung.
• Jitter-/Latenzspitzen: Ping wirkt „okay“, aber Nutzer melden langsam/ruckelig; MTR macht Schwankungen sichtbar.
• Provider-Eskalationen: Sie brauchen Zeitreihen und Belege, nicht nur einen einzelnen Traceroute-Screenshot.
• Vergleich mehrerer Pfade: Standort A vs. Standort B, VPN vs. direkt, IPv4 vs. IPv6.

Die wichtigste Interpretationsregel: Loss in der Mitte ist nur relevant, wenn er „bis zum Ziel“ durchschlägt

Eine der häufigsten Fehlinterpretationen ist: „Hop 7 zeigt 30% Loss, also ist Hop 7 kaputt.“ Das ist in vielen Fällen falsch. Wenn ein Hop ICMP-Antworten rate-limited, kann er in MTR oder Traceroute Loss zeigen, während nachfolgende Hops und das Ziel keinen Loss haben. Dann ist das Problem nicht der Transit, sondern die Antwortbereitschaft dieses Routers.

• Loss nur an einem Hop, danach 0%: sehr häufig ICMP-Depriorisierung, kein echter Datenverlust im Pfad.
• Loss ab einem Hop und bleibt bis zum Ziel: deutlich stärkerer Hinweis auf echten Loss (Queue Drops, Linkfehler, Überlast).
• RTT steigt ab einem Hop dauerhaft: kann Congestion/Queueing sein, muss aber mit Ziel-RTT abgeglichen werden.

MTR richtig einsetzen: Protokollwahl und Messdauer

Damit MTR aussagekräftig ist, sollten Sie es passend zur Anwendung fahren. Ein reines ICMP-MTR ist schnell und oft ausreichend, kann aber durch Policies verfälscht sein. In vielen Umgebungen ist ein TCP-basierter Test auf den relevanten Port (z. B. 443) näher an der Realität, weil Firewalls ICMP anders behandeln als TCP. Entscheidend ist außerdem die Messdauer: Bei sporadischen Problemen brauchen Sie genügend Samples, sonst sehen Sie nur Zufall.

ICMP vs. TCP vs. UDP

• ICMP: schnell, universell, aber häufig rate-limited oder depriorisiert.
• TCP (z. B. Port 443): oft näher an Web-/API-Traffic, hilfreich bei Firewall-/Proxy-Nähe.
• UDP: kann je nach Anwendung sinnvoll sein, ist aber oft stärker gefiltert.

Messdauer und Sample-Größe als Qualitätsfaktor

Eine Messung über wenige Sekunden kann zufällig gut oder zufällig schlecht ausfallen. Für belastbare Aussagen sollten Sie MTR so lange laufen lassen, bis Sie ein stabiles Bild haben oder bis ein reproduzierbares Fehlerfenster erfasst ist.

• Bei sporadischen Aussetzern: mehrere Minuten bis deutlich länger, abhängig vom Fehlerintervall.
• Bei Lastspitzen: MTR während der Stoßzeit laufen lassen, nicht in ruhigen Zeitfenstern.
• Bei Vergleichen: gleiche Dauer und gleiche Bedingungen (Netz, Ziel, Protokoll) verwenden.

Traceroute bleibt nützlich: Wann Traceroute trotz „Ungenauigkeit“ ausreicht

Traceroute ist weiterhin ein hervorragendes Werkzeug, wenn Sie schnell eine grobe Pfadübersicht brauchen oder wenn Sie vor allem wissen möchten, wo der Traffic grundsätzlich entlangläuft. In vielen Fällen reicht ein sauber interpretierter Traceroute-Lauf als Einstieg – insbesondere, wenn Sie ihn mit einem zweiten Lauf (anderes Protokoll) oder mit Baseline-Wissen abgleichen.

• Schnelle Erstdiagnose: „Geht der Traffic über den erwarteten Edge?“
• Routing-Änderungen: „Hat sich der Pfad nach einem Change verändert?“
• Segmentlokalisierung: „Bricht es intern, am Edge oder erst außerhalb ab?“

Warum MTR bei Congestion und Bufferbloat besonders hilfreich ist

Congestion ist selten ein „dauerhafter harter Ausfall“, sondern zeigt sich als schwankende Latenz, Jitter und zeitweiser Loss. Genau das bildet MTR besser ab als Traceroute. Während Traceroute Ihnen eventuell nur einen Hop mit hoher RTT zeigt, kann MTR die Dynamik sichtbar machen: RTT steigt, dann fällt sie wieder; Loss tritt in Bursts auf; ab einem bestimmten Hop wird alles „wackelig“. Diese Muster sind entscheidend, wenn Sie zwischen Packet Loss durch physische Fehler und Congestion durch Überlast unterscheiden wollen.

Queueing Delay als interpretierbares Signal

Wenn Sie eine Baseline-RTT kennen, können Sie die zusätzliche Verzögerung durch Queueing grob abschätzen. Das ist kein perfektes Modell, aber in Tickets und Eskalationen oft sehr hilfreich.

$\mathrm{QueueingDelay}=\mathrm{RTT}-\mathrm{RTT}\_\mathrm{baseline}$

Wenn dieser Wert während Stoßzeiten deutlich ansteigt und gleichzeitig Jitter und gelegentliche Drops auftreten, spricht das stark für Congestion oder Bufferbloat – selbst wenn ein einzelner Traceroute-Lauf „nur“ einen merkwürdigen Hop zeigt.

Beweiskette aufbauen: MTR ist stark, aber nicht allein ausreichend

Eine saubere Diagnose entsteht, wenn Sie MTR mit weiteren Daten kombinieren. MTR zeigt Symptome entlang des Pfads; die Ursache bestätigen Sie häufig mit Interface-Countern, QoS-Statistiken, Flow-Daten oder Logs. Das verhindert Fehlinterpretationen und stärkt Ihre Eskalationsfähigkeit.

• Interface-Drops/Queue-Drops: belegen Congestion an einem bestimmten Link.
• CRC/FCS-Errors: belegen physische Probleme (Loss ohne Congestion).
• Flow-Daten: zeigen Traffic-Spitzen oder „Elephant Flows“, die Congestion auslösen.
• Firewall-Logs: zeigen Drops/Rate-Limits für bestimmte Protokolle (ICMP vs. TCP).

Typische Missverständnisse und wie Sie sie vermeiden

Traceroute und MTR sind Diagnosewerkzeuge, keine Schuldzuweiser. Besonders bei Provider-Pfaden, MPLS und ICMP-Policies entstehen schnell falsche Schlussfolgerungen. Die folgenden Fehler passieren in der Praxis besonders häufig.

• „Loss auf Hop X = Problem bei Hop X“: Nur relevant, wenn Loss ab dort bis zum Ziel sichtbar bleibt.
• „Ein Hop ist langsam, also ist der Pfad langsam“: Wenn nachfolgende Hops normal sind, ist es oft nur ICMP-Depriorisierung.
• „Traceroute zeigt * * * = Hop down“: Häufig blockt der Hop einfach Antworten; Transit kann trotzdem funktionieren.
• „MTR zeigt 5% Loss, also ist die App langsam“: Loss muss mit Anwendungssymptomen und Zeitfenster korrelieren, sonst ist es nur ein Nebensignal.

Dokumentation für Tickets und Eskalationen: So wirken Traceroute und MTR überzeugend

Damit Traceroute/MTR in der Praxis helfen, müssen Ergebnisse nachvollziehbar dokumentiert sein. Dazu gehört Kontext: welches Ziel, welcher Zeitpunkt, welches Protokoll, aus welchem Netzwerksegment. Ohne diese Angaben sind selbst gute Daten schwer verwendbar.

• Messkontext: Quelle (Standort/VLAN/VPN), Ziel (Hostname/IP), Zeitraum, Protokoll (ICMP/TCP/UDP).
• Baseline: Normalwerte für RTT und Stabilität (wenn vorhanden).
• Fehlerfenster: Zeitpunkt(e), zu denen Nutzer die Störung beobachten.
• Interpretation: klar formuliert: „Loss nur an Hop 5, nicht am Ziel → wahrscheinlich ICMP Rate-Limit“ oder „Loss ab Hop 8 bis Ziel → echter Transit-Loss wahrscheinlich“.
• Zusatzbelege: Interface-Drops/Errors, QoS-Drops, Flow-Spitzen, Logs.

Outbound-Referenzen für belastbare Grundlagen und praktische Vertiefung

• RFC-Editor (Netzwerkstandards und Protokolldefinitionen)
• Wireshark-Dokumentation (Paketanalyse zur Validierung von Loss, Retransmits und Latenz)
• RIPE Atlas Messplattform (unabhängige Perspektiven für Pfad- und Erreichbarkeitsmessungen)

Wenn Traceroute „ungenau“ wirkt, ist das in den meisten Fällen keine Schwäche des Tools, sondern eine Folge moderner Netzrealität: ICMP-Policies, Load Balancing, asymmetrische Pfade und abstrahierte Provider-Backbones. MTR ist dann sinnvoll, weil es diese Realität besser abbildet: als Zeitreihe, mit Statistiken, und mit der Möglichkeit, Muster zu erkennen statt Momentaufnahmen zu überbewerten. Entscheidend ist die korrekte Interpretation: Loss oder hohe RTT in der Mitte sind erst dann ein echter Hinweis, wenn sie sich konsistent bis zum Ziel fortsetzen oder mit anderen Datenquellen korrelieren. Genau diese Beweisführung macht aus „Traceroute ist komisch“ eine belastbare Diagnose.

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.