traceroute / Dauer

[fu123]

Hallo,


weiß jemand warum so ein einfacher Tracerout ganze 30 Sekunden dauert?
Es sieht einfach aus als ob das in Zeitlupe läuft.
Und dann am Ende auch noch anscheinend ein Packet verloren geht?

Fu


r2#traceroute 192.168.104.1

Type escape sequence to abort.
Tracing the route to 192.168.104.1

1 192.168.2.2 16 msec 16 msec 16 msec
2 192.168.3.2 32 msec 28 msec *
r2#

[Wordo]

Vielleicht weil er dauernd einen Reverselookup von den IP's versucht? Probier mal traceroute ip X.X.X.X numeric. Das da ein Paket verloren geht ist komisch, schau mal obs dauernd so ist

[rob_67]

Hi,

oder weil da eine ausgelastete standleitung dazwischen ist?


gruss


rob

[fu123]

Zitat von Wordo Vielleicht weil er dauernd einen Reverselookup von den IP's versucht? Probier mal traceroute ip X.X.X.X numeric. Das da ein Paket verloren geht ist komisch, schau mal obs dauernd so ist

Hi,

du meinst:
tracerout ip 192.168.104.1 numeric

als Befehl? Das Argument "numeric" kennt der Router hier nicht.
Als "traceoute ip 192.168.104.1" ändert sich nichts. Das verlorene
Packet bleibt. Ich versteh das nicht ganz.
Aber reverse lookup war ne gute Idee. Das hat mich auf
"no ip domain-lookup" gebracht. Und das tut's. Anscheinend ist das auch
für reverse lookup zuständig. Thanks.
Nur das Paket raff ich jetzt nicht.

Fu

[Wordo]

Wenn die 192.168.3.2 ne Cisco is kannst dir ja mal n "sh int" anschaun ob da Errors/CRSs/Collisions drauf sind.

[rob_67]

ich nochmal,


ist doch unklar, warum soll der cisco ne ip auflösen, wenn er die doch direkt anspechen kann, ist wohl doch eher nen bug?! scheint dann ja zusätzlich? ein nat problem zu sein, weil die ip nicht selbst antwortet und auch eine antwort fehlt?!


gruss

rob

[Wordo]

Jop, denk ich auch, aber bei Windows muss man ja auch "tracert -d" machen damit der keinen Reverselookup macht.

[fu123]

Zitat von rob_67 Hi, oder weil da eine ausgelastete standleitung dazwischen ist? rob

Ne, das ist ein serieller Link ohne Auslastung. Ich kann es jederzeit reproduzieren. Interessant wie es dazu kommen kann. Ich hab keine Ahnung.
Das muss ich mir noch mal anschauen.

Fu

[fu123]

Also, ich habe mittlerweile dazu herausgefunden, das es eher ein Feature als ein Bug ist. Und zwar liegt es an folgendem.

Link

Es gibt ein Rate Limit für ICMP unreachable's.

Nur noch mal zur Erinnerung.

Bei meinem traceroute zwischen Cicso Routern ist immer folgendes passiert.
Es ist immer die zweite Antwort auf dem letzen Router verloren gegangen.
Egal wie viele andere Router dazwischen sind.

Beispiel:

r1#traceroute 192.168.2.1

Type escape sequence to abort.
Tracing the route to 192.168.2.1

1 172.20.44.2 16 msec 16 msec 16 msec
2 172.10.144.2 16 msec * 16 msec

r1#traceroute 192.168.2.1

Type escape sequence to abort.
Tracing the route to 192.168.2.1

1 172.20.44.2 16 msec 16 msec 16 msec
2 172.10.144.2 20 msec * 16 msec


Mit einem "no ip icmp rate-limit unreachable" auf dem Router der keine Antwort sendet, ist das "Problem" behoben.

Das sollte eigentlich auf den meisten Routern so sein. Vielleicht fällt es sonst nur nicht so auf.

fu