Traceroute und MTR interpretieren wie ein Netzbetreiber

Die Interpretation von Traceroute ist unverzichtbar, um den Pfad eines Pakets sichtbar zu machen. Störungen ziehen sich jedoch unnötig in die Länge, wenn Hop-Verluste falsch gelesen, ICMP-Filterung (Internet Control Message Protocol) für eine echte Beeinträchtigung gehalten oder Pfad-Asymmetrien ignoriert werden.

Dieser Artikel zeigt, wie Sie Traces ausführen, lesen und Ihre Ergebnisse anhand einheitlicher Artefakte überprüfen. Glossare und Erklärbeiträge helfen dabei, die Grundlagen zu festigen, und Online-Tools ergänzen die Vorbereitung Ihrer Tests.

Schritt für Schritt: Traceroute und MTR richtig interpretieren

Um Traceroutes zu interpretieren, bestätigen Sie zunächst das Symptom, erstellen einen Baseline-Trace, führen Traces mit mehreren Probe-Typen aus, interpretieren Hop-Verluste, nutzen Latenz-Deltas, berücksichtigen Asymmetrien, korrelieren mit benachbarten Signalen, bilden eine Hypothese, testen nach einer Änderung erneut und bündeln anschließend die Nachweise.

📌Voraussetzungen:

• Die Möglichkeit, ICMP-, UDP– und TCP-Traces aus Benutzer-Subnetzen, von Kernstandorten und von einem Cloud-Messpunkt aus auszuführen
• Zugriff auf My Traceroute (MTR) oder pathping auf den Arbeitsplätzen der Analyst:innen
• Ein einfaches Nachweis-Template, in dem Befehlszeilen, Zeitstempel und Ausgaben gespeichert werden
• Kenntnis der IP-Adressen und Ports der Zieldienste, einschließlich CDN- oder Anycast-Endpunkten

Schritt 1: Symptom und Umfang bestätigen

Dieser Schritt spart Stunden an Rätselraten, weil das Problem klar definiert wird.

📌 Anwendungsfall: Ein:e Benutzer:in in einer Niederlassung meldet, dass eine Web-App in einen Timeout läuft, während andere Standorte das Problem nicht beobachten. Bevor Pakete verfolgt werden, muss geklärt werden, ob der Fehler lokal, regional oder dienstspezifisch auftritt.

Dokumentieren Sie das Symptom: Was ist ausgefallen, wann begann es und wer ist betroffen? Erfassen Sie die nötigen Details wie den Namen der Anwendung oder des Dienstes, die Ziel-IP-Adresse oder URL, den Standort der Benutzer:innen und die Zugriffsmethode.

Prüfen Sie anschließend, ob der Ausfall oder die Langsamkeit isoliert oder flächendeckend auftritt. Vergleichen Sie die Ergebnisse verschiedener Benutzer:innen, Standorte oder ISPs, um festzustellen, ob das Problem über eine Netzwerkgrenze hinausreicht.

Schaffen Sie zum Schluss eine Ausgangsbasis für die Untersuchung, indem Sie das Ereignis mit einem Zeitstempel versehen und die „bekannt guten“ Ziele definieren. Dieser Kontext sorgt dafür, dass spätere Traceroutes, Latenzmessungen und Eskalationen beim Anbieter richtig eingeordnet werden.

Schritt 2: Einen sauberen Baseline-Trace erstellen

Dieser Schritt liefert einen Referenzpunkt, um normale Eigenheiten des Internets von echten Netzwerkfehlern zu unterscheiden.

📌 Anwendungsfall: Ein:e Analyst:in untersucht langsame Verbindungen zu einem Cloud-gehosteten Kundenbeziehungsmanagement. Um zu prüfen, ob die Verlangsamung neu ist oder schon länger besteht, werden frische Traces vom betroffenen Standort mit den Baseline-Ergebnissen verglichen.

Ein Baseline-Trace ist Ihre Kontrollprobe. Von einem nicht betroffenen Standort oder Endpunkt aus:

• Führen Sie einen Standard-Traceroute und einen MTR zum selben Ziel aus, idealerweise im normalen Betrieb.
• Halten Sie Befehlszeile, Zeitstempel und Ausgaben in Ihrem Nachweis-Template fest.
• Notieren Sie stabile Latenzen und Hop-Muster. Sie bilden das erwartete Netzwerkverhalten ab, solange der Dienst gesund ist.
• Wiederholen Sie die Baselines regelmäßig oder nach größeren Änderungen beim Anbieter, damit die Referenzdaten aktuell bleiben.

Schritt 3: Traces mit mehreren Probe-Typen auf dem betroffenen Pfad ausführen

So sehen Sie, was der Datenverkehr der Benutzer:innen tatsächlich erlebt, und nicht nur, was auf ICMP antwortet.

📌 Anwendungsfall: Eine Software-as-a-Service-Plattform scheint aus einer Region nicht erreichbar zu sein. Der ICMP-Traceroute bricht mitten auf dem Pfad ab, doch Benutzer:innen erreichen die Seite zeitweise weiterhin. Zusätzliche UDP- und TCP-Traces zeigen, dass lediglich ICMP gefiltert wird.

Wer nur mit ICMP testet, übersieht womöglich bestimmte Routing-Verhalten. Für ein vollständigeres Bild:

• Führen Sie ICMP-, UDP- und TCP-Traceroutes vom betroffenen Standort zum selben Ziel aus.
• Notieren Sie Befehle, Parameter und Zeitstempel, damit sich Ihre Ergebnisse zum Vergleich reproduzieren lassen.
• Speichern Sie die Rohausgaben in Ihrem Nachweis-Log, um sie später mit erneuten Tests oder Antworten des Anbieters abzugleichen.

Die Kombination verschiedener Probe-Typen reduziert blinde Flecken, zeigt, ob Paketverlust eine echte Beeinträchtigung oder nur Filterung auf der Control Plane widerspiegelt, und stellt sicher, dass Ihre Analyse zu dem passt, was die Benutzer:innen vom Dienst wahrnehmen.

Schritt 4: Hop-Verluste interpretieren, ohne zu überreagieren

Dieser Schritt hilft Ihnen, bewusst begrenzte ICMP-Antworten von echten Problemen zu unterscheiden, und verhindert so Fehlalarmierungen und unnötige Eskalationen.

📌 Anwendungsfall: Ein:e Analyst:in bemerkt bei Hop 7 einen Verlust von 40 %, während das Ziel weiterhin sauber antwortet. Statt einen Ausfall zu melden, erkennt die Person darin ein ICMP-Rate-Limiting auf einem Zwischenrouter.

Traceroute kann Paketverlust an Zwischen-Hops anzeigen, doch nicht jeder Verlust bedeutet, dass Daten nicht durchkommen. Für die richtige Deutung:

• Prüfen Sie, ob sich der Verlust über den Hop hinaus fortsetzt. Antworten spätere Hops normal, ist der „Verlust“ rein kosmetisch. Beginnt der Verlust an einem Hop und bleibt über alle folgenden Hops bestehen, deutet das auf ein echtes Problem hin.
• Gleichen Sie die Werte mit MTR- oder Ping-Ergebnissen ab.
• Eskalieren Sie nicht wegen eines Verlusts an einem einzelnen Hop.
• Dokumentieren Sie Ihre Ergebnisse frühzeitig.

Schritt 5: Latenz-Deltas statt einzelner Ausreißer nutzen

So lesen Sie Latenzwerte korrekt.

📌 Anwendungsfall: Bei einer Störungsanalyse sieht ein:e Analyst:in bei Hop 6 einen plötzlichen Anstieg um 200 ms, während Hop 7 und das Ziel normale Latenzen zeigen. Statt eine Überlastung zu melden, wird dies als kurzzeitige Verzögerung auf der Control Plane eingeordnet.

Beim Interpretieren von Traceroute- oder MTR-Ergebnissen verraten die Muster eine Überlastung, nicht einzelne Werte. Um Latenzen richtig zu lesen:

• Vergleichen Sie Durchschnittswerte von Hop zu Hop statt isolierter Spitzen.
  • Ein dauerhafter Anstieg, der an einem Hop beginnt und auf allen folgenden Hops erhöht bleibt, weist meist auf eine echte Überlastung hin.
  • Ein einzelner hoher Wert, der sich nicht über diesen Hop hinaus fortsetzt, ist typischerweise Messrauschen.
• Bestätigen Sie die Werte mit MTR oder mehreren Durchläufen.
• Notieren Sie neben dem Wert auch das Delta.
• Dokumentieren Sie, an welcher Stelle der Sprung auftritt.

Schritt 6: Asymmetrie und Anycast berücksichtigen

Dieser Schritt verhindert, dass Sie dem falschen Netzwerksegment hinterherjagen, weil Sie Netzwerkpfade richtig einordnen.

📌 Anwendungsfall: Ein:e Benutzer:in in Europa meldet eine langsame Verbindung zu einem US-Webdienst. Der Hin-Traceroute sieht sauber aus, doch der Rückweg nimmt eine überlastete Transatlantikstrecke. Traces aus mehreren Regionen zeigen, dass nur bestimmte Anycast-Edges betroffen sind.

So vermeiden Sie Fehldiagnosen:

• Rechnen Sie mit Asymmetrie. Hin- und Rückweg unterscheiden sich durch Richtlinien, Peering-Entscheidungen oder Traffic Engineering der Anbieter.
• Testen Sie von verschiedenen Messpunkten aus.
  • Führen Sie Traceroutes von unterschiedlichen Standorten, ISPs oder Cloud-Probes zum selben Ziel aus.
  • Vergleichen Sie Hop-Folgen und Latenzen, um zu erkennen, ob das Problem durchgängig auftritt.
• Erkennen Sie Anycast-Verhalten.
  • Dienste wie DNS-Resolver können Verbindungen unter derselben IP-Adresse an verschiedenen regionalen Knoten terminieren.
  • Das Routing kann sich im Tagesverlauf durch Lastverteilung ändern, sodass identische Tests zu unterschiedlichen Zeiten über andere Pfade laufen.
• Korrelieren Sie Ergebnisse über die Zeit. Ein durchgängiger Fehler über verschiedene Messpunkte hinweg deutet auf ein echtes, stabiles Problem hin.
• Dokumentieren Sie beobachtete Abweichungen. Halten Sie Messpunkt, Routenunterschiede und Zeitstempel fest, damit andere nachvollziehen können, ob Anycast-Verhalten Ihre Ergebnisse beeinflusst hat.

Schritt 7: Mit benachbarten Signalen korrelieren

Dieser Schritt vergleicht Traceroute-Daten mit anderen Indikatoren und liefert so eine echte Validierung.

📌 Anwendungsfall: Ein:e Analyst:in sieht bei einem Traceroute zu einer Cloud-App 20 % Verlust, doch es gibt keine Beschwerden von Benutzer:innen. Ein kurzer Ping-Test zeigt keinen Paketverlust und die App antwortet normal. Der „Verlust“ entpuppt sich als ICMP-Filterung und nicht als echter Fehler.

Traceroute-Ergebnisse sollten Sie immer gegen andere Datenquellen prüfen, um zu bestätigen, ob sie tatsächlich eine Auswirkung auf Benutzer:innen abbilden oder nur das Verhalten der Probes. Dazu gehört:

• Begleitende Tests zum Traceroute ausführen:
  • Ping: bestätigt Erreichbarkeit und Verluste über die Zeit.
  • Anwendungs-Probe: testet Benutzerfunktionen wie HTTP, SSH oder API-Aufrufe.
  • MTR: macht Trends bei Latenz und Verlust sichtbar.
• Die Muster vergleichen:
  • Zeigt der Traceroute Verluste, während Ping- und App-Tests erfolgreich sind, liegt der Verdacht auf ICMP-Filterung oder Rate-Limiting der Probes nahe.
  • Treten Verlust oder Latenz in allen Tests auf, ist die Beeinträchtigung real und sollte untersucht werden.
• Symptome der Benutzer:innen gegenprüfen: Klären Sie, ob die betroffenen Benutzer:innen langsame Antwortzeiten oder Verbindungsabbrüche erleben, die zu den gemessenen Werten passen.
• Zeitliche Einordnung prüfen: Stellen Sie sicher, dass alle Tests mit Zeitstempel versehen sind und innerhalb eines kurzen Zeitfensters stattfinden.

Schritt 8: Eine klare Hypothese bilden und das Segment eingrenzen

Dieser Schritt macht aus Beobachtungen eine These.

📌 Anwendungsfall: Ein:e Analyst:in sieht ab dem dritten Hop anhaltende Latenz, also genau dort, wo der Datenverkehr das Unternehmens-LAN verlässt und in das Netz des ISP eintritt. Dokumentiert wird das als „mögliche Überlastung an der Übergabe vom Standort zum ISP“, samt unterstützender Traceroute-Daten und Zeitstempel.

Fassen Sie nach der Auswertung Ihrer Traces mit mehreren Probe-Typen und der begleitenden Signale Ihre Ergebnisse in einer Aussage darüber zusammen, wo und warum das Problem auftritt:

• Bestimmen Sie die Grenze, an der die Verschlechterung beginnt.
  • Suchen Sie den ersten Hop mit anhaltendem Verlust oder einem dauerhaften Latenzsprung.
  • Klären Sie, ob dieser Hop zum Standort-LAN, zum ISP-Edge, zu einem Transit-Anbieter oder zum Zielnetz gehört.
• Formulieren Sie die Hypothese in klarer Sprache.
• Untermauern Sie die Hypothese mit Nachweisen.
• Halten Sie sie überprüfbar.

Schritt 9: Nach einer Änderung oder Anbieterbeteiligung erneut testen

Dieser Schritt belegt Verbesserungen und bestätigt, dass ein Problem behoben ist.

📌 Anwendungsfall: Nachdem ein ISP eine Routing-Richtlinie angepasst hat, führt ein:e Analyst:in Traceroute- und MTR-Tests von genau denselben Standorten erneut aus. Die neuen Daten zeigen: Der Paketverlust von 15 % an Hop 8 ist verschwunden und die Latenz ist um 40 ms gesunken.

So testen Sie wirksam erneut:

• Führen Sie dieselben Tests noch einmal aus.
  • Verwenden Sie dieselben Probe-Typen (ICMP, UDP, TCP), dasselbe Ziel und dieselbe Befehlssyntax.
  • Stellen Sie sicher, dass die Tests von denselben Messpunkten wie die ursprüngliche Aufzeichnung ausgehen.
• Versehen Sie Ergebnisse mit Zeitstempel und eindeutiger Bezeichnung.
• Vergleichen Sie die Kennzahlen direkt:
  • Ist der Paketverlust an einem bestimmten Hop verschwunden?
  • Haben sich Latenz oder Jitter verbessert, vor allem auf dem kritischen Pfad der Anwendung?
• Fassen Sie die Verbesserungen zusammen.
• Hängen Sie die Nachweise an den Störungsdatensatz an.
• Lassen Sie sich die Besserung von den Benutzer:innen bestätigen.

Schritt 10: Nachweise für den Abschluss bündeln

Dieser Schritt sorgt dafür, dass Nachweise gebündelt und geteilt werden.

📌 Anwendungsfall: Nachdem eine zeitweise auftretende Latenz durch einen Fix des Anbieters behoben wurde, sammelt der oder die Analyst:in alle Test-Logs, Traces von vorher und nachher, Zeitstempel sowie eine Zusammenfassung der Ergebnisse. Das Paket landet im Nachweis-Workspace des Teams und wird mit dem Störungsticket verknüpft, sodass für die Nachbetrachtung eine transparente Aufzeichnung vorliegt.

So erstellen Sie ein vollständiges Abschlusspaket:

• Stellen Sie die relevanten Artefakte zusammen:
  • Befehlszeile und Parameter der Traceroute-, MTR- und Ping-Tests.
  • Rohausgaben und Screenshots.
  • Zeitstempel für jeden Test, damit ein zeitlicher Ablauf erkennbar bleibt.
• Fassen Sie die Ergebnisse zusammen:
  • Das vermutlich fehlerhafte Segment
  • Die messbare Auswirkung
  • Die ergriffene Gegenmaßnahme und ihr Resultat
• Ergänzen Sie Validierungsdaten:
  • Vorher-Nachher-Vergleich von Verlust, Latenz und Routenstabilität.
  • Bestätigung durch Benutzer:innen oder Überwachungsdaten, die die wiederhergestellte Leistung belegen.
• Speichern und verknüpfen Sie die Nachweise sauber:
  • Legen Sie Dateien mit einheitlicher Benennung in Ihrem Nachweis-Workspace ab.
  • Hängen Sie die Artefakte an das zugehörige Störungsticket an, damit sie sichtbar bleiben.

Best Practices für die Interpretation von Traceroute und MTR

Die folgende Tabelle fasst die Best Practices zusammen, die Sie bei der Interpretation von Traceroute und MTR beachten sollten:

NinjaOne-Services für die Interpretation von Traceroute und MTR

Mit den geplanten Aufgaben von NinjaOne führen Sie Traces von repräsentativen Endpunkten aus, sammeln die Ausgaben zentral und versehen Artefakte mit Tags für Standort und Internetdienstanbieter (ISP). Außerdem können Sie Nachweise an Störungstickets anhängen, sodass Verantwortliche Verbesserungen belegen können.

Traceroutes lesen wie ein Netzbetreiber

Traceroute wird deutlich nützlicher, wenn Sie es wie ein Netzbetreiber einsetzen. Wer verschiedene Probe-Typen testet, auf durchgängige Muster achtet, modernes Routing versteht und klare Nachweise sichert, findet Probleme schneller und schließt Tickets mit mehr Sicherheit ab.

Verwandte Themen:

• Was ist Traceroute?
• 6 Best Practices für die Netzwerküberwachung
• Der komplette Leitfaden zur Überwachung von IT-Systemen
• Die 7 wichtigsten Netzwerkbefehle, die Sie kennen sollten
• Was ist Netzwerk-Troubleshooting?