traceroute / Dauer

[fu123 10]

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 11]

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 10]

Hi,

 

oder weil da eine ausgelastete standleitung dazwischen ist?

 

 

gruss

 

 

rob

[fu123 10]

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 11]

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 10]

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 11]

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

[fu123 10]

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 10]

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