IT-Dienstleistungen

traceroute Interpretation (mit FreeBSD Besonderheiten)

Auf dieser Seite:

Das traceroute Kommando (Windows traceroute implementation: tracert) kann mehr Informationen preisgeben als man erwartet. Hinweis zu Firewalls: Die FreeBSD Implementierung von traceroute nutzt standardmäßig UDP anstatt ICMP. Der UDP Standardport ist 33434, der erhöht wird nach dem Schema default port + 1 to port + (max_ttl - first_ttl + 1) * number of probes at the destination host.

 

Empfohlene Lektüre / Quellen

 

traceroute in der Praxis

  • Durch das Senden nur eines anstatt der standardmäßigen 3 Pakete reduziert man die Komplexität des Outputs: traceroute -q 1
  • ICMP Pakete unterliegen häufig einem Rate Limiting. Programme wie etwa mtr erreichen oft die Schwelle für eine solche Limitierung.
  • Die Quelle der ICMP Antwort stellt konventionsgemäß das Ingress Interface dar (auch wenn RFC 1812 besagt, dass hier das Egress Interface genutzt werden soll, was allerdings dazu führen würde, dass traceroute nicht erwartungsgemäß funktioniert).
  • Liegen Anzeichen vor, dass ein Hop an einem /30 Netzwerk anliegt, so liefert eine whois Abfrage oft weitere wissenswerte Details.
  • Kenntnis über den erwarteten Pfad, den ein gegebener Netzwerkverkehr nehmen sollte, hilft bei der Diagnose.
  • Multipath und Load Balancing Konfigurationen beeinflussen die von traceroute berichteten Ergebnisse.
    • Mehrere Hostnamen bei einem Hop, jeweils mit einem oder mehreren Zeitstempeln, deuten auf einen Load Balancer hin.
    • Asymmetrische Netzwerkpfade beginnen häufig an den Grenzen eines Netzwerks. Die gezielte Konfiguration der Quelladresse ist hier möglicherweise hilfreich. Beide Seiten eines /30 Netzwerks zu testen hilft, Probleme mit asymmetrischen Netzwerkpfaden zu identifizieren. Die Interaktion von Quelladdresse und /30 Netzwerk auf der einen Seite und einem genutzten Routing Protokoll ist oft relevant. Die meisten Router nutzen oft als Quelladresse das Egress Interface.
    • Equal-cost multi-path (ECMP) führt häufig zum Erscheinen mehrerer Pfade für einen Hop. Es empfiehlt sich Time To Live (TTL) Werte zu vergleichen. ECMP sorgt immer dann für schwer einzuordnende Ergebnisse, wenn mehrere Pfade von unterschiedlicher Länge involviert sind.
  • traceroute von beiden Endpunkten aus auszuführen liefert die zuverlässigsten Ergebnisse; nutzen Sie dabei echte Quell- und Zieladressen; abgeschnittener traceroute Output ist oft untauglich; die Nutzung einer IP Adresse eines auf dem Weg liegenden Hops, der aus einer anderen Kommandoausführung stammt, führt zu falschen Schlussfolgerungen.
  • traceroute liefert nur Informationen zum Hinweg, der Rückweg ist hingegen unsichtbar.
  • Speichern Sie traceroute Referenzoutput für spätere Vergleiche.
 

Probleme identifizieren mit traceroute

  • Lange Verzögerungen zwischen zwei Hops stellen nicht zwingend ein Problem dar. Möglicherweise befindet sich zwischen Punkt A und Punkt B ein Ozean. Testen Sie, was traceroute meldet, wenn z.B. eine Universität auf einem anderen Kontinent das Ziel ist.
  • Asymmetrisches Routing ist ein Grund eine hohe Round Trip Time (RTT) an einem Hop zu ignorieren: Möglicherweise war der Hinweg ein anderer als der Rückweg. Traceroute zeigt die Hops auf dem Rückweg nicht an.
  • Prüfen Sie den DNS Einstellungen, wenn traceroute sehr langsam ist. Die Auflösung von DNS Namen bei jedem Hop verhindert man so: traceroute -n
  • traceroute kann DNS Probleme aufzeigen; die erste Zeile des Outputs zeigt IP und Hostnamen des Ziels.
  • Ein Sternsymbol im Output deutet auf ein verlorenes Paket hin: Das angesprochene Gerät ist nicht erreichbar, es antwortet nicht, oder die Antwort hat den Rückweg nicht überstanden. Das passiert in Zusammenhang mit asymmetrischem Routing oder mit dem Umstand, dass der Netzwerkverkehr für UDP oder ICMP an einer oder mehreren Stellen gefiltert wird.
  • ICMP innerhalb von MPLS-LSP führt zu auffälligen traceroute Ergebnissen: ICMP Antwortpakete müssen an das Ende des LSP gelangen, bevor sie an das eigentliche Ziel geschickt werden. Das hat zur Folge, dass jeder Hop innerhalb des LSP so aussieht, als hätte er dieselbe RTT wie der letzte Hop.
 

Interpretation von traceroute Informationen

Traceroute Output kann Informationen liefern zu: Physischen Orten der Geräte auf dem Weg, Interfacetypen und Kapazitäten, Routertypen und deren Rolle im Netzwerk, Grenzen der Netzwerke und Zusammenhänge, Port Nummern an den Geräten.

  • Die meisten Implementierungen versenden 3 Pakete --> 3 voneinander unabhängige Latenzmessungen pro Hop; daher dreo Sternsymbole * * * bei fehlender Rückantwort (oder einem Paketfilter auf dem Weg).
  • Traceroute Fehler:
    • !H (host unreachable), !N (network unreachable), !A, !X, !Z (traffic administratively prohibited).
    • Weitere Fehlercodes am Ende der FreeBSD traceroute man page.
 

Was die Round Trip Time beeinflussen kann

  • Nutzen Sie Zeitstempel für die Interpretation des traceroute Outputs, um Netzwerkprobleme zu diagnostizieren.
  • Latenz hat ihre Ursache nicht nur auf dem Hin- und Rückweg, sie entsteht auch durch Verarbeitungszeiten am Ziel.
    • Serialisation delay - die Dauer Daten in ein versandfertiges Paket zu verwandeln.
    • Queuing delay.
    • Propagation delay auf der Leitung.
    • Buffer bloat
    • Bei ICMP Paketen: Die Dauer zur Generierung einer ICMP Type 11 Code 0 (Time Exceeded) Antwort. HINWEIS: Ein Router kann auch so konfiguriert sein, dass er keine ICMP verschickt oder dies nur mit sehr geringer Priorität tut - dies stellt keinen Netzwerkengpass dar.
    • Backbone ISPs haben kaum Veranlassung traceroute und ping Pakete mit hoher Priorität zu behandeln, daher ist die Antwortzeit an entsprechenden Hops meist höher.
  • Utilisation: Ein 10G Interface sendet entweder mit 10G oder gar nicht. Die Beobachtung dieses Umstands über einen längeren Zeitraum ist Utilisation. Probleme treten in der Regel bei 95% Utilisation auf.
  • Die Perspektive eines Routers (Data Plane vs Control Plane): Es ist mit mehr Aufwand verbunden, eine Antwort zu generieren als Pakete nur weiterzleiten --> traceroute und ping haben geringe Priorität.
    • Ein Router arbeitet schnell, wenn die Arbeit auf einen ASIC abgewälzt werden kann.
    • Es gibt keinen ASIC für ICMP, daher muss auf die vielleicht etwas schwache CPU zurückgegriffen werden, um ICMP Antworten zu generieren.
    • Dagegen ist die Verarbeitung von BGP oder OSPF stark optimiert.
 

ICMP anstatt UDP nutzen bei der FreeBSD Implementierung von traceroute

# FreeBSD ICMPv6 traceroute6
traceroute6 -I example.com
# FreeBSD ICMPv4 traceroute
traceroute -P ICMP example.com

# Extra: Alle Router im lokalen mit vtnet0 verbundenen IPv6 Netz ansprechen
ping6 ff02::2%vtnet0

Zahlung veranlassen