Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

After experiencing an extremely sluggish internet, 'connection refused','unable to negotiate link' and such across sites (fb, stackoverflow, yahoo, google amongst them) I took the liberty of hitting tracert at random.

The trace output is below

C:\Documents and Settings\G0D>tracert in.yahoo.com

Tracing route to any-fp-in.wa1.b.yahoo.com [98.139.183.24]
over a maximum of 30 hops:

  1    12 ms     *       11 ms  1.64.95.59.in-addr.arpa [59.95.64.1]
  2    35 ms    34 ms    34 ms  218.248.255.58
  3   142 ms   140 ms   140 ms  115.114.57.249.static-Mumbai.vsnl.net.in [115.114.57.249]
  4   481 ms   478 ms   475 ms  ix-0-100.tcore1.MLV-Mumbai.as6453.net [180.87.38.5]
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8   551 ms   555 ms   543 ms  if-8-2.tcore2.SV8-Highbridge.as6453.net [80.231.91.26]
  9     *        *      514 ms  if-2-2.tcore1.SV8-Highbridge.as6453.net [80.231.139.2]
 10   547 ms   552 ms   554 ms  if-6-2.tcore1.NJY-Newark.as6453.net [80.231.138.18]
 11     *      549 ms   721 ms  if-2-2.tcore2.NJY-Newark.as6453.net [66.198.70.2]
 12   528 ms   543 ms   547 ms  if-3-2.tcore2.AEQ-Ashburn.as6453.net [216.6.87.9]
 13   341 ms   341 ms   342 ms  54.27.58.209.in-addr.arpa [209.58.27.54]
 14   356 ms   351 ms   351 ms  ae-6.pat2.dcp.yahoo.com [216.115.102.178]
 15   354 ms   381 ms     *     ae-7.pat2.che.yahoo.com [216.115.100.137]
 16   362 ms   362 ms   362 ms  ae-2.pat2.bfz.yahoo.com [216.115.100.74]
 17   384 ms   365 ms   385 ms  ge-1-0-0.pat1.bfz.yahoo.com [216.115.97.211]
 18   426 ms     *      366 ms  ae-4.msr2.bf1.yahoo.com [216.115.100.73]
 19   364 ms   370 ms   383 ms  xe-7-0-0.clr2-a-gdc.bf1.yahoo.com [98.139.128.19]
 20   368 ms   388 ms   394 ms  et-17-1.fab3-1-gdc.bf1.yahoo.com [98.139.128.41]
 21   477 ms   450 ms     *     ir2.fp.vip.bf1.yahoo.com [98.139.183.24]
 22   435 ms   416 ms   480 ms  ir2.fp.vip.bf1.yahoo.com [98.139.183.24]

Trace complete.

There appear to be bottlenecks Hop 3 onwards.

What is particularly surprising to me is the apparent recursion happening at Hop 13.

What could be the reason for this recursion?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Very Brief Overview of How Traceroute Works:
Traceroute sends a lot of packets to the destination. Each packet (or possibly groups of packets) starts with a TTL of 1 (How many hops until the packet dies). When a router receives a packet with a TTL, it stops forwarding it and possibly sends a Internet Control Message Protocol (ICMP) Time-Exceeded message.

For the next packet (or group of packets) the TTL 2 two. The first router forwards the packet and decrements the TTL to 1. Therefore, the next router is the one that will possibly send the Time-Exceeded message.

Important things to note with this mechanism is that routers can decide never to send the Time-Exceeded messages, or rate limit them so you only get partial hits. It is also important to know that the return path of packets is not shown in a traceroute and may be different. Lastly, routes can change so the traceroute might be different from moment to moment.

Another Brief Overview, How the Internet Routes:
Internet routers use a protocol called BGP to build its routing tables. BGP has a macro view of the Internet, which is basically connections of whole networks. So in this example, you see that you go from "as6453.net" to "[209.58.27.54]" and then to yahoo. As far as BGP is concerned it takes that macro view and doesn't worry about the hops within those networks.

There is a lot more to this, but that is the basic idea.

Recursion:
Not really sure what you mean here, but if you mean the way the IP number is reversed in 54.27.58.209.in-addr.arpa [209.58.27.54], this just the "default" for reverse DNS entries when there isn't a name like ae-6.pat2.dcp.yahoo.com. You can use whois to find the owner in this case:

kbrandt@alpine:~$ whois 209.58.27.54
...
NetRange:       209.58.0.0 - 209.58.127.255
CIDR:           209.58.0.0/17
OriginAS:       AS6453
...
OrgName:        Tata Communications
OrgId:          TATAC
Address:        1555 Carrie-Derick
City:           Montreal
StateProv:      QC
...
share|improve this answer
    
Also, going of the specific latency from hops 2-4, I would guess the upstream provider to your ISP isn't that great. That might just be the nature of the Internet in India, or you might be able to get a better ISP. Best bet is to forward this to your ISP and see if you can get someone who knows what they are talking about to explain that latency. –  Kyle Brandt May 2 '12 at 13:03

Hop 13 is on a different network from hop 12. So most likely the returning packet from hop 13 took a different, and presumably better, path back to you, resulting in a lower time for that hop and subsequent hops.

I should also point out that the *'s on hops 5, 6, and 7 probably don't mean anything. They're likely just devices that weren't able to return locally-sourced packets to you. The *'s in later lines may or may not mean anything. It could just mean the routers were too busy to bother returning a packet to you, but it's more likely that those reflect real packet loss.

share|improve this answer
3  
...or that ICMP packets are filtered on those routers...so they just drop the packets automatically. Usually the packets which come from outside of their network. I've seen this quite a lot. –  Silviu May 2 '12 at 12:14
    
Wouldn't that path then be identified as the quickest/best and retained so subsequent packets along that route would use that same path then? That is to say, I'd experience recursion on a few packets instead of all of them? –  Everyone May 2 '12 at 12:21
2  
No, that is fundamentally not how the Internet works. Each network sets its own policy based on who it pays money to and packets leaving that network use that network's routing policy. Each network typically routes each packet based solely on its destination IP address and where it entered the network. The network does not learn from packets. –  David Schwartz May 2 '12 at 12:22
    
Routes need not be the same in both directions, and it took several seconds to do the trace route, network conditions may have changed during the test. There's really nothing interesting about the report other than the high latency from hop 3 outward. –  Chris S May 2 '12 at 12:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.