Tracert richtig deuten

AuroraXF

Cadet 4th Year
Registriert
Aug. 2009
Beiträge
90
Hallo zusammen,

wie tracert ansich funktioniert ist mir klar, nur gibt es einen punkt an dem ich nicht weiß wie ich solch eine abfrage deuten soll.

Angenommen folgendes tracert beispiel:

1 20ms 20ms 20ms ipxxxx
2 23ms 23ms 23ms ipxxxx
3 120ms 120ms 120ms ipxxxx
4 24ms 24ms 24ms ipxxxx

Wie kann es sein das er am Zielpunkt 4 nur 24ms benötigt um eine Antwort zu bekommen, wenn er doch am vorherigen Punkt 120ms gebraucht hat?
Weil bei der Abfrage zu Punkt 4 muss das Paket doch auch wieder über Punkt 3 laufen und bekommt dort doch wieder eine größere verzögerung dazu oder nicht?

Kann mich da jemand erleuchten? =)

Grüße
 
Hm. . Eigentlich funktioniert ein Traceroute über das Hochzählen der TTL (TimeToLive). Der erste Ping hat TTL 1, wird also nur zum ersten Hop geleitet und danach ist vorbei. Das nächste Paket hat TTL und geht durch den ersten Hop durch (TTL - 1) und landet beim zweiten Hop und so weiter und so fort. Die Antwortzeit sollte dabei immer höher sein als beim vorherigen Hop. Ist das reproduzierbar?
 
Zuletzt bearbeitet:
Es kann sein, dass einige Stationen auf der Route die ICMP Pakete mit geringer Priorität behandeln und demnach richtigen Datenverkehr bevorzugen. Genau genommen können sie die Pakete sogar blockieren - zu sehen an '* * *' in der Zeile . Entscheidend ist daher die RTT (RoundTripTime) des letzten Hop.
Ergänzung ()

Priorität ist vielleicht etwas missverständlich. Wenn die TTL eines Pakets abgelaufen ist, schickt der Router eine entsprechende Antwort 'abgelaufen' an den Sender. Dieses Paket kann etwas verzögert gesendet werden, wenn anderer Datenverkehr ansteht. Ist die TTL > 1 dann leitet der Router es quasi ungesehen weiter. Das kann in deinem Beispiel den Unterschied von 120 ms (abgelaufen, niedrige Priorität der Antwort) und effektiv 1 ms (aktiv, hohe Priorität der Weiterleitung ) ausmachen.
 
ok Raijin das mit der priorisierung habe ich nicht bedacht und ist ein interissanter Aspekt.
Gibt es auch die möglichkeit das solch ein ICMP Paket nur dann geringer priorisiert wird wenn die Station an der es ankommt den TTL wert auf 0 bringt und somit antworten muss, jedoch gleichwertig mit anderem Datenverkehr behandelt wird wenn es nur weitergeleitet wird da der TTL wert nicht auf 0 sinkt?

Nur so könnte ich mir das bild erklären:



Bei der ersten IP handelt es sich um die HP des Betreibers selbst und die zweite IP ist der Gameserver.
Nun sieht man das jedesmal Punkt 6 deutlich länger benötigt aber danach wieder absinkt.
Der Gameserver selbst ist auch schlecht im Ping, so wird er mir auch Ingame angezeigt.

Also für mich sieht es halt so aus das Punkt 6 beim selbst antworten, nicht priorisiert aber beim weiterleiten, zu 7 und weitere, dann scheinbar normal durchlässt.
Ansonsten kann ich mir die ~20ms bei Punkt 7 nicht erklären.

Grüße
 
Genau so meinte ich das ja. Ich hab doch die beiden Fälle gegenüber gestellt.

Kommt das Paket mit TTL = 1 am Router an, zählt er die TTL runter (TTL = 0) und antwortet mit einer Timeout-Nachricht. Das kann wie beschrieben mit niedriger Priorität behandelt werden, weil der Router ja 'etwas tun muss'. zb 120 ms

Kommt das Paket mit TTL > 1 am Router an, zählt er die TTL runter (zb TTL = 2) und reicht das Paket nur weiter. zb 26-25=1 ms

Gerade bei wichtigen InternetKnoten wie zb ISP-Gateways oder dergleichen kann sowas passieren, da das Verkehrsaufkommen dort naturgemäß höher ist als bei simplen Zwischenstationen.

Höhere RTTs bei MiddleHops ist also meistens zu vernachlässigen. Interessant wird es dann, wenn man auf der Route sozusagen Treppenstufen sieht. Ungefähr so: 1,1, 20,21, 79,80,81, 200,201
Das deutet darauf hin das der jeweils erste Hop in dem Bereich die nachfolgende Route verzögert. Bei den 20ern ist das der Wechsel vom Modem zum ISP-Einwahlknoten, im 80 Bereich vielleicht der Weg vom ISP-Netz ins restlichen Internet..

In deinem Screenshot ist Hop 7 ein bischen komisch, weil die RTT schwankt. Warum? Keine Ahnung. Kann man was dagegen tun? Nein. Alles hinter deinem Default Gateway bzw dem deines ISP kannst du nicht beeinflussen. Das sind irgendwelche Router in Unis, Rechenzentren oder sonstwo.
 
Zuletzt bearbeitet:
Zurück
Oben