I am pinging an IP hop1 and hop 2 show an adderss hop 3 and hop 4 are blank hop 5 destination shows the address and all information . What is hop 3 and hop 4 telling me. Thanks Phil

Hi, Phil.

There are a couple of possiblities here.

First, it could be that those two routers are configured to not respond. See here for details:

http://www.nessoft.com/kb/2

Another possibility comes from the documentation of the Unix traceroute command. Here's an excerpt:

[ ... some text snipped ... ] the above may be the result of a bug in the 4.[23]BSD network code (and its derivatives): 4.x (x <= 3) sends an unreachable message using whatever ttl remains in the original datagram. Since, for gateways, the remaining ttl is zero, the ICMP "time exceeded" is guaranteed to not make it back to us. The behavior of this bug is slightly more interesting when it appears on the destination system:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms !

Notice that there are 12 "gateways" (13 is the final destination) and exactly the last half of them are "missing". What's really happening is that rip (a Sun-3 running Sun OS3.5) is using the ttl from our arriving datagram as the ttl in its ICMP reply. So, the reply will time out on the return path (with no notice sent to anyone since ICMP's aren't sent for ICMP's) until we probe with a ttl that's at least twice the path length. I.e., rip is really only 7 hops away.

In your case, the destination may only be 3 hops away, but the destination is exhibiting this behavior.

In any case, the blank hops do not indicate a problem in routing data. If the final destination is looking good, then there is no problem with the route. If the final destination is having a problem, then you can look back at the hops that *are* reporting for the first one that's showing similar problems, and work with that to solve the problem.

- Pete