MTR vs. Ping vs. Traceroute: Wann nutzt man was?

MTR vs. Ping vs. Traceroute gehört zu den häufigsten Fragen im NOC und bei der Netzwerkdiagnose, weil alle drei Tools „irgendwie“ Latenz und Erreichbarkeit messen – aber jeweils mit anderen Stärken, Schwächen und typischen Fehlinterpretationen. Wer sie falsch einsetzt, kommt schnell zu falschen Ursachen: „Hop X hat 60% Loss, also ist Hop X kaputt“ oder „Ping ist gut, also ist die Anwendung okay“. In der Realität prüfen Ping, Traceroute und MTR unterschiedliche Aspekte des Pfads und reagieren empfindlich auf Firewalls, ICMP-Rate-Limits, asymmetrisches Routing, ECMP-Loadbalancing und Priorisierung im Control Plane. Richtig eingesetzt liefern sie jedoch extrem schnelle Hinweise, ob ein Problem eher in der Nähe des Clients, im Transit, am Zielsystem oder nur in der Messmethode liegt. Dieser Artikel erklärt, wann Sie Ping, Traceroute oder MTR nutzen sollten, welche Informationen jedes Tool zuverlässig liefert, wie Sie „falschen Loss“ von echtem Paketverlust unterscheiden und wie Sie aus den Ergebnissen einen belastbaren Incident-Befund ableiten – verständlich für Einsteiger, aber mit genug Tiefe für fortgeschrittene Troubleshooter.

Grundprinzip: Was die Tools wirklich messen

Alle drei Werkzeuge basieren typischerweise auf ICMP oder UDP/TCP-Probes, die gezielt Paketlaufzeiten (Round Trip Time, RTT) und Antworten entlang eines Pfads auslösen. Sie messen aber nicht „die Anwendung“, sondern den Transport bis zu einem Ziel oder zu Zwischenstationen. Daraus ergeben sich drei zentrale Grenzen:

• Sie messen den Hin- und Rückweg zusammen (RTT), nicht die Richtung einzeln.
• Sie messen eine spezielle Paketart (ICMP Echo oder TTL-exceeded), die im Netz anders behandelt werden kann als produktiver Traffic.
• Sie messen aus der Perspektive des Messpunkts: Ein anderer Standort kann ein völlig anderes Ergebnis sehen.

Damit diese Werkzeuge korrekt interpretiert werden, ist es hilfreich, das IP-TTL-Konzept zu kennen: Traceroute-Mechanismen nutzen bewusst eine geringe TTL, damit Router unterwegs mit „Time Exceeded“ antworten. Das Verhalten von IP und ICMP ist in den relevanten RFCs beschrieben, z. B. in RFC 792 (ICMP) und für Traceroute-nahe Mechanismen in RFC 1812 (Requirements for IP Version 4 Routers).

Ping: Der schnellste Realitätstest – mit klaren Grenzen

Ping ist das Werkzeug für die erste Minute im Incident: „Ist das Ziel grundsätzlich erreichbar, und wie sieht die RTT aus?“ Standardmäßig nutzt Ping ICMP Echo Request/Reply. Das macht Ping schnell, überall verfügbar und leicht zu automatisieren. Gleichzeitig ist genau das auch die größte Quelle von Missverständnissen: Ein gutes Ping-Ergebnis beweist nicht, dass HTTP, DNS oder eine Datenbankverbindung funktioniert – und ein schlechtes Ping-Ergebnis beweist nicht automatisch, dass das Netz kaputt ist.

Wann Ping die beste Wahl ist

• Erreichbarkeit prüfen: Gibt es überhaupt Antworten vom Ziel?
• Baseline erfassen: Wie hoch ist die normale RTT von diesem Messpunkt aus?
• Schnelle Trendbeobachtung: Wird die Latenz gerade schlechter, gibt es sporadische Timeouts?
• Vergleich mehrerer Ziele: Ist nur ein Host betroffen oder ein ganzes Subnetz/Region?

Welche Ping-Kennzahlen wirklich aussagekräftig sind

• Packet Loss: Anteil verlorener Antworten aus Sicht des Messpunkts.
• Min/Avg/Max RTT: grobe Lage; der Durchschnitt kann Spikes verdecken.
• Jitter (implizit): große Schwankungen zwischen Min und Max sind oft wichtiger als der Mittelwert.

Typische Ping-Fallen (und wie Sie sie vermeiden)

• ICMP wird gedrosselt oder geblockt: Viele Geräte priorisieren produktiven Traffic höher als ICMP oder limitieren Echo Replies. Dann zeigt Ping „Loss“, obwohl die Anwendung stabil ist.
• Ping misst nicht den Applikationspfad: Ein Server kann ICMP beantworten, aber Port 443 ist down oder die App hängt.
• Asymmetrisches Routing: Ping kann ok wirken, während produktiver Traffic über einen anderen Rückweg Probleme hat (oder umgekehrt).

Praxisregel: Ping ist ein guter Start, aber kein Ende. Wenn der Incident „App langsam“ lautet, kombinieren Sie Ping sofort mit einem anwendungsnahen Check (z. B. TCP Connect auf Port 443 oder HTTP HEAD), um ICMP-Sonderbehandlung auszuschließen.

Traceroute: Der Pfadfinder – ideal für Scope und Routing-Hypothesen

Traceroute zeigt, über welche Hops ein Paket zum Ziel gelangt. Das ist besonders wertvoll bei Routingänderungen, blackholing, falschen Next-Hops, Anycast/Geo-Routing und Provider-Problemen. Klassisch arbeitet Traceroute mit UDP-Probes zu hohen Ports (die am Ziel „Port unreachable“ auslösen) oder alternativ mit ICMP oder TCP (z. B. TCP SYN auf 443). Entscheidend ist: Traceroute misst nicht nur Latenz, sondern liefert eine Pfadsequenz – und damit Kontext.

Wann Traceroute die beste Wahl ist

• Routing-Pfad verstehen: Wo geht der Traffic lang, welcher Provider/Peering-Punkt ist involviert?
• Pfadwechsel erkennen: Vorher/Nachher bei Changes, Flaps oder Failover.
• Blackhole-Verdacht: Wo endet die Sichtbarkeit, ab welchem Hop kommen keine Antworten mehr?
• Segmentierung: Ist das Problem „nah am Client“ oder „nah am Ziel“?

Warum Traceroute oft „komisch“ aussieht

• ICMP Time Exceeded wird rate-limited: Router antworten nicht zuverlässig auf TTL-exceeded, weil Control Plane geschützt ist. Das kann wie Loss aussehen.
• ECMP und Loadbalancing: Bei Equal-Cost Multi-Path kann jede Probe einen anderen Pfad nehmen. Dann sehen Sie scheinbar „springende“ Hops oder wechselnde Latenzen.
• Asymmetrie: Traceroute zeigt den Hinweg der Probes (und die Rückantworten), aber die reale Anwendung kann andere Wege nutzen, insbesondere bei NAT, Anycast oder Policy-Based Routing.

Die wichtigste Traceroute-Interpretationsregel

„Loss auf einem Zwischenhop ist nur dann relevant, wenn der Loss bis zum Ziel durchgeht.“ Wenn Hop 5 70% Loss anzeigt, aber der Zielhost (letzter Hop) 0% Loss hat, dann ist Hop 5 sehr wahrscheinlich nicht kaputt – er antwortet nur selektiv oder mit niedriger Priorität. Diese Regel ist der häufigste Unterschied zwischen professioneller Interpretation und Fehlalarm.

MTR: Traceroute + Ping über Zeit – das beste Tool für „es ist sporadisch“

MTR (My Traceroute) kombiniert die Pfadansicht von Traceroute mit kontinuierlichen Messungen wie bei Ping. Dadurch sehen Sie pro Hop über eine Messdauer hinweg Latenz und Loss-Statistiken. Das ist besonders nützlich, wenn Probleme nicht permanent sind: Mikro-Aussetzer, sporadische Congestion, instabile Links oder periodische Interferenzen.

Wann MTR die beste Wahl ist

• Sporadische Probleme: „Alle paar Minuten hängt es kurz“ – MTR zeigt, ob Loss/Latenzspikes korrelieren.
• Korrelation pro Hop: Steigt die Latenz ab einem bestimmten Segment? Nimmt Loss ab einem Hop zu und bleibt bis zum Ziel bestehen?
• Vergleich über Zeitfenster: Vor Mitigation und nach Mitigation denselben Test laufen lassen.
• Provider-Eskalation: Ein sauber interpretierter MTR-Output kann als Beleg dienen, wenn er konsistent ist und richtig gelesen wird.

Welche MTR-Spalten operativ zählen

• Loss%: Vorsicht bei Zwischenhops; entscheidend ist der Loss am Ziel und ob er „durchgängig“ ist.
• Last/Avg/Best/Wrst: „Wrst“ und „Last“ zeigen Spikes, „Avg“ kann sie glätten.
• StDev: Hohe Standardabweichung ist oft ein besserer Congestion-Indikator als ein moderater Average.

Die häufigste MTR-Fehlinterpretation

Ein Zwischenhop mit hohem Loss ist nicht automatisch die Fehlerstelle. Viele Router beantworten ICMP/UDP-Probes in der Control Plane nur mit sehr geringer Rate. Das Ergebnis ist „Loss“ für MTR, aber kein Loss für Transitverkehr. Deshalb gilt auch bei MTR: Nur Loss, der ab einem Hop beginnt und bis zum Ziel bestehen bleibt, ist ein starkes Indiz für echten Paketverlust im Datenpfad.

ICMP, UDP oder TCP: Welche Probe-Variante wann sinnvoll ist

Ping ist typischerweise ICMP. Traceroute und MTR können je nach Implementierung ICMP-, UDP- oder TCP-Probes nutzen. Diese Wahl ist nicht kosmetisch, sondern beeinflusst die Aussagekraft, weil Firewalls und Netzgeräte verschiedene Protokolle unterschiedlich behandeln.

ICMP-Probes

• Vorteil: Standardisiert, einfach, oft überall verfügbar.
• Nachteil: Häufig rate-limited oder geblockt, besonders an Edges oder in Cloud-Umgebungen.
• Wann sinnvoll: Interne Netze, Baselines, schnelle Erreichbarkeit.

UDP-Traceroute

• Vorteil: Klassischer Mechanismus; oft gute Hop-Sichtbarkeit in vielen Netzen.
• Nachteil: UDP kann gefiltert werden; Rückmeldung am Ziel basiert auf ICMP „Port unreachable“.
• Wann sinnvoll: Provider-/Transit-Analysen, wenn UDP nicht geblockt ist.

TCP-Traceroute (z. B. auf Port 443)

• Vorteil: Näher am realen Anwendungspfad (HTTPS), oft weniger geblockt als ICMP/UDP.
• Nachteil: Manche Geräte behandeln TCP-Probes anders; nicht jede Umgebung liefert saubere Hop-Antworten.
• Wann sinnvoll: Wenn ICMP/UDP gefiltert werden oder wenn Sie explizit den HTTPS-Pfad testen wollen.

Für ein Verständnis von ICMP und Router-Antworten sind RFC 792 (ICMP) und die Router-Anforderungen in RFC 1812 nützliche Referenzen.

Wie Sie „echten Loss“ von „ICMP-Noise“ unterscheiden

In der NOC-Praxis ist die wichtigste Kompetenz nicht das Starten der Tools, sondern das korrekte Lesen. Die folgenden Regeln helfen, falsche Schlüsse zu vermeiden.

• Regel 1: Loss ist nur dann ein starker Beweis, wenn er am Ziel sichtbar ist oder ab einem Hop beginnt und bis zum Ziel durchgängig bleibt.
• Regel 2: Einzelne Hops mit Loss, aber ein sauberes Ziel, deuten meist auf Rate-Limiting oder niedrige Priorität der Antworten hin.
• Regel 3: Latenzspikes auf Zwischenhops sind nur relevant, wenn die Latenz ab dort dauerhaft höher bleibt oder das Ziel ebenfalls spikt.
• Regel 4: Prüfen Sie immer mit mindestens zwei Messpunkten, wenn das Problem „regional“ sein könnte.
• Regel 5: Wenn ICMP verdächtig ist, testen Sie mit TCP-Probes (z. B. 443), um eine realistischere Behandlung zu erzwingen.

Messdesign: Dauer, Paketgröße und Statistik richtig wählen

Ein häufiger Fehler ist „ein kurzer Ping und fertig“. Sporadische Probleme brauchen Messdauer. Congestion zeigt sich oft als Varianz, nicht als dauerhafter Ausfall. Deshalb sollten Sie die Messparameter bewusst wählen.

Messdauer als Mindestanforderung

• Ping: Für stabile Aussagen eher 50–200 Pakete als 4 Standardprobes.
• MTR: Mindestens einige Minuten bei sporadischen Beschwerden, damit Muster sichtbar werden.
• Traceroute: Mehrfach wiederholen, wenn ECMP vermutet wird, um Pfadvarianten zu sehen.

Paketgröße und MTU-Effekte

Manche Probleme treten nur bei größeren Paketen oder Fragmentierung auf (z. B. PMTUD-Störungen). Ping kann mit größerer Payload solche Effekte sichtbar machen. Eine grobe Abschätzung der Nutzlast P bei einer gewünschten Gesamtgröße S ist:

$P=S-H$

Hier steht H für die Summe der Header (z. B. IP + ICMP, ggf. zusätzlich Ethernet/Layer-2 in der Betrachtung). Operativ ist wichtiger: Wenn kleine Pings funktionieren, große aber nicht, ist MTU/PMTUD ein plausibler Kandidat.

Perzentile statt Durchschnitt

Wenn Sie Ergebnisse dokumentieren, sind Perzentile oft aussagekräftiger als ein Mittelwert. Viele Tools zeigen das nicht direkt, aber Sie können mit längeren Messreihen Spikes sichtbar machen („Worst“ in MTR oder Max RTT in Ping). Für NOC-Kommunikation gilt: „p95/p99 steigt“ ist stärker als „Average ist etwas höher“.

Wann nutzt man was? Ein pragmatischer Entscheidungsbaum

Im Incident zählt Geschwindigkeit. Der folgende Ablauf ist in vielen NOC-Teams praxistauglich, weil er die Stärken der Tools kombiniert.

• Schritt 1: Ping – Erreichbarkeit und grobe RTT prüfen. Wenn Ping bereits Loss zeigt, notieren Sie das, aber verifizieren Sie es mit weiteren Methoden.
• Schritt 2: Traceroute – Pfad sichtbar machen, Blackhole-Verdacht prüfen, Pfadwechsel erkennen.
• Schritt 3: MTR – Wenn das Problem sporadisch ist oder wenn Sie „ab welchem Hop beginnt es?“ belastbar sehen wollen.
• Schritt 4: Probes variieren – Wenn ICMP verdächtig ist: TCP-Traceroute/MTR auf 443 oder anwendungsnahe Checks ergänzen.

Das Ergebnis sollte nicht „Hop 7 ist schuld“ sein, sondern ein sauberer Befund: „Loss beginnt ab Hop X und bleibt bis zum Ziel; Latenzspikes korrelieren mit diesem Segment; ICMP/TCP zeigen konsistentes Bild.“

Provider- und Cloud-Realität: Warum externe Messungen oft widersprüchlich sind

In Provider- und Cloud-Umgebungen sind Ping/Traceroute/MTR besonders nützlich – aber auch besonders fehleranfällig in der Interpretation, weil Control Plane geschützt wird und ICMP/TLL-Antworten bewusst gedrosselt sind. Zusätzlich kommen Anycast, globale Load Balancer und dynamische Pfadwahl hinzu. Daraus folgen drei Empfehlungen:

• Mehrere Messpunkte: intern + extern, mindestens zwei Regionen/ISPs, um Pfadabhängigkeit zu erkennen.
• Protokollnähe erhöhen: TCP-Probes auf den realen Service-Port, wenn ICMP unzuverlässig ist.
• Beweise bündeln: MTR/Traceroute nie isoliert verwenden, sondern mit Service-Metriken (Fehler/Latenz) korrelieren.

Dokumentation und Kommunikation im NOC: Ergebnisse so festhalten, dass sie eskalierbar sind

Ein häufig unterschätzter Punkt: Ein sauberer MTR- oder Traceroute-Output ist nur dann hilfreich, wenn er mit Kontext geliefert wird. Für eine Eskalation an Provider oder ein internes Netzwerkteam sollten Sie immer mitschreiben:

• Zeitfenster: Start/Ende der Messung, Zeitzone.
• Messpunkt: Hostname/Standort/Netz (intern/extern), idealerweise IP und ASN-Kontext.
• Probe-Typ: ICMP/UDP/TCP, Zielport, Paketgröße.
• Ergebniszusammenfassung: Wo beginnt Loss/Latenz, ist das Ziel betroffen, ist es reproduzierbar?

So vermeiden Sie Ping-/MTR-Screenshots ohne Kontext, die zwar „dramatisch“ aussehen, aber keine belastbare RCA oder Provider-Ticket-Bearbeitung ermöglichen.

Outbound-Quellen für vertiefendes Verständnis

Für das grundlegende Verhalten von ICMP (inklusive Echo und „Time Exceeded“) ist RFC 792 (ICMP) eine zentrale Referenz. Für Router-Verhalten und den Umgang mit TTL sowie ICMP-Antworten ist RFC 1812 (Requirements for IP Version 4 Routers) hilfreich. Für eine praxisnahe Beschreibung von MTR, Parametern und Interpretation ist die MTR-Projektseite ein guter Einstieg, insbesondere für Optionen wie TCP-/UDP-Modi und Ausgabeformate.

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.