traceroute

[chin hyeon jung]

when using client/server program, sometimes the responding time is very slow.
So I used traceroute and found following
1 10.0.91.2 (10.0.91.2) 0.693 ms 0.492 ms 0.465 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * 10.10.0.138 (10.10.0.138) 41.400 ms
Could you tell me the meaning of "*" and is there is any solution of this problem?

[avsrini]

Hi,

the "*" means the host on the route of the packet did'nt replied within the timeout period. Seems there are some routers inbetween the client / server. Are you using any VLAN?. Also provide the IP address of the client and server and the route entry.

Your network seems loaded or you are having some route configuration issue.

Srini.

[malay boy]

I guest * mean not reachable or timeout.
Anybody ,am i correct ?.

regards
AAR

[Balaji N]

hi
see some info below snipped from the traceroute manpage on my linux box.

If there is no response within a 5 sec. timeout interval (changed with the
-w flag), a "*" is printed for that probe.


A more interesting example is:

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

Note that the gateways 12, 14, 15, 16 & 17 hops away either don't send
ICMP "time exceeded" messages or send them with a ttl too small to
reach us. 14 - 17 are running the MIT C Gateway code that doesn't send
"time exceeded"s. God only knows what's going on with 12.

The silent gateway 12 in 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 data-
gram. 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 destina-
tion 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. A reply that
returns with a ttl of 1 is a clue this problem exists. Traceroute
prints a "!" after the time if the ttl is <= 1. Since vendors ship a
lot of obsolete (DEC's Ultrix, Sun 3.x) or non-standard (HPUX) soft-
ware, expect to see this problem frequently and/or take care picking
the target host of your probes.



hth
-balaji

[Ron Kinner]

Traceroute works by sending out a series of packets with a gradually increasing TTL (time to live). Each device along the route will subtract one from the TTL. If an incoming packet has a 0 TTL then the packet is considered expired and will not be forwarded any further. Normally the router will send back an ICMP unreachable message which means that the packet has expired. The result is your traceroute list of hosts along the route.

However, besides the poor programming in some older machines mentioned in an earlier posts, nowadays you also see a lot of machines which do not generate ICMP unreachable networks for security reasons. They figure the less information they give to a possible hacker the better.

Also these packets are not resent if they get dropped. So you may have a bad serial connection, a noisy circuit, or a bottleneck where packets get dropped from the queue before being sent. Could also be some sort of routing loop involved.

There may also be an issue with your firewall setup. Often they have very narrow filters which only allow ICMP messages from certain networks.

From the information given it is hard to say exactly why you are getting the *'s tho I would suspect lost packets since traceroute send out three packets with the same TTL each time and you are not getting a response until the third instance of step 7. I would need to know more about the details of your network to really say for sure. Is the host you are tracing in the same building, only reachable over the internet, in a different remote location or what? How many routers are really in between the two hosts?

If you are lucky the routers in between may respond to:
ping -o 10.10.0.138
and give you more information.

If you do a regular ping do you see a lot of replies getting lost?

Ron