odd traceroute...

I've noticed a long delay whenever i type in a url in to my browser... I decided to do a traceroute to see what was wrong.. This is what I found.... % traceroute google.com traceroute: Warning: google.com has multiple addresses; using

64.233.187.99 traceroute to google.com (64.233.187.99), 64 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 3.819 ms 2.097 ms 1.938 ms 2 * * * 3 rd1no-ge3-0-0-1.cg.shawcable.net (64.59.142.115) 22.471 ms 10.471 ms 8.648 ms 4 rc1no-ge6-0-0.cg.shawcable.net (66.163.77.5) 26.183 ms 15.414 ms 10.912 ms 5 rc1so-pos15-0.cg.shawcable.net (66.163.77.9) 12.143 ms 23.177 ms 17.998 ms 6 rc1wh-pos12-0.vc.shawcable.net (66.163.76.10) 24.113 ms 30.108 ms 25.873 ms 7 rc1wt-pos1-0-0.wa.shawcable.net (66.163.76.2) 26.423 ms 25.656 ms 29.004 ms 8 six.sea01.google.com (198.32.180.17) 26.730 ms 31.314 ms 37.598 ms 9 72.14.233.117 (72.14.233.117) 68.557 ms 67.478 ms 67.403 ms 10 72.14.236.26 (72.14.236.26) 84.189 ms 103.591 ms 85.113 ms 11 72.14.236.175 (72.14.236.175) 83.759 ms 85.358 ms 84.454 ms 12 216.239.49.222 (216.239.49.222) 86.832 ms 87.021 ms 87.286 ms 13 64.233.187.99 (64.233.187.99) 83.578 ms 84.233 ms 83.444 ms

Notice the 2nd hop.. RIght between my wireless NAT/Router and my ISP. It takes a good ten seconds to get to the third hop. Does the ISP need to be provided with DNS information or does that all get automatically resolved by DHCP? Or am I barking up the completely wrong tree? If so what else should I be looking at?

Reply to
KraftDiner
Loading thread data ...

Going one step further... I went to the wireless router/nat (linksys WRT54G) and ran a traceroute on it... again pretty much the same results.. traceroute to google.com (64.233.167.99), 30 hops max, 40 byte packets

1 * * * Request timed out. 2 rd1no-ge3-0-0-1.cg.shawcable.net (64.59.142.115) 8.682 ms 6.915 ms 8.153 ms 3 rc1no-ge6-0-0.cg.shawcable.net (66.163.77.5) 8.412 ms 8.130 ms 7.629 ms 4 rc1so-pos15-0.cg.shawcable.net (66.163.77.9) 7.730 ms 7.831 ms * 5 rc1wh-pos12-0.vc.shawcable.net (66.163.76.10) 22.081 ms 39.183 ms 20.218 ms 6 rc1wt-pos1-0-0.wa.shawcable.net (66.163.76.2) 24.817 ms 24.370 ms 24.379 ms 7 six.sea01.google.com (198.32.180.17) 23.689 ms 30.040 ms 24.448 ms 8 72.14.233.117 (72.14.233.117) 67.734 ms 67.655 ms 65.974 ms 9 66.249.95.247 (66.249.95.247) 65.164 ms 66.249.95.245 (66.249.95.245) 65.386 ms 65.116 ms 10 72.14.232.53 (72.14.232.53) 67.137 ms 66.249.94.135 (66.249.94.135) 67.143 ms 67.969 ms 11 72.14.232.70 (72.14.232.70) 79.638 ms 73.242 ms 64.233.175.26 (64.233.175.26) 73.481 ms 12 64.233.167.99 (64.233.167.99) 68.193 ms 68.298 ms 71.696 ms Trace complete
Reply to
KraftDiner

"KraftDiner" wrote in news:1158128283.054383.115590 @d34g2000cwd.googlegroups.com:

I typically see a hop like that when ging through a router. I don't know about anyone, but I use 3 different NAT routers at 3 different, nad they all do that on either the first or second hop.

DanS

Reply to
DanS

Well, no. It takes about 10 milliseconds to get to the third hop (three responses, shortest 8.6ms, longest 22.4ms).

Whatever device is at hop two is simply not responding to the ICMP message that traceroute uses; not every box does.

If you're seeing long delays when doing your traceroute, use the "-n" option, so you won't waste all that time looking up the name of each node.

Reply to
Bert Hyman

Probably not the best solution. First, the original LBL traceroute is using UDP - your web browser uses TCP, and some routers treat the two protocols differently (UDP is generally lower in priority). The b0rked windoze "TRACERT" and a few "improved" UNIX traceroute implementations use ICMP echo (ping) which is even more useless. Second, a more suitable tool would be a packet sniffer. Are you seeing retransmits?

man traceroute - the LBL man page is quite extensive. Look at the -q and

-w options

-q nqueries Set the number of probes per ``ttl'' to nqueries (default is three probes).

-w Set the time (in seconds) to wait for a response to a probe (default 5 sec.).

and the examples in the man page.

The second hop is ignoring/blocking/dropping UDP and/or isn't providing an ICMP Type 11 error for some reason - often, a misguided attempt at some form of security. Your traceroute has to wait for each attempt to time out before heading for hop 3. Normal. This has absolutely nothing to do with delays in loading a web page - notice that hops after this host are not showing significant delays because hop 2 isn't talkative.

Nothing to do with it - but you _could_ use the -n option to tell traceroute not to look up the hostnames. You probably won't see a difference in the reported delays.

Not enough information. I'd be looking at tcpdump (or what ever packet sniffer you have on that box and are comfortable with) to see what the packets are doing. There are quite a number of possibilities. As for trying to locate delays enroute, I don't know if tcptraceroute or hping2 is available for OSX (applications that can run a traceroute using TCP instead of UDP), but I suspect your problem lies elsewhere. Certainly the two traces you provide show no network problems.

Old guy

Reply to
Moe Trin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.