The below is a part of traceroute to my hosted server:
9 ae-2-2.ebr2.dallas1.level3.net (184.108.40.206) 19.433 ms 19.599 ms 19.275 ms
10 ae-72-72.csw2.dallas1.level3.net (220.127.116.11) 19.496 ms
ae-82-82.csw3.dallas1.level3.net (18.104.22.168) 19.630 ms
ae-62-62.csw1.dallas1.level3.net (22.214.171.124) 19.518 ms
11 ae-3-80.edge4.dallas3.level3.net (126.96.36.199) 19.659 ms
ae-2-70.edge4.dallas3.level3.net (188.8.131.52) 90.610 ms
ae-4-90.edge4.dallas3.level3.net (184.108.40.206) 19.658 ms
12 the-planet.edge4.dallas3.level3.net (220.127.116.11) 19.905 ms 19.519 ms 19.688 ms
13 te9-2.dsr01.dllstx3.networklayer.com (18.104.22.168) 40.037 ms 24.063 ms
te2-4.dsr02.dllstx3.networklayer.com (22.214.171.124) 28.605 ms
14 * * *
15 * * *
16 zyzzyva.site5.com (126.96.36.199) 20.414 ms 20.603 ms 20.467 ms
What's the meaning of lines 14 and 15? Information hidden?
Traceroute sends packets to the destination with the field "time to live" (TTL) equal to the number of hops.
Every router decreases the value of TTL of an incoming packet and if it sees an incoming packet with TTL = 0 then drops it, otherwise it decreases the value and sends it further. At the same time it sends diagnosing information to the source about router's identity.
If router does not respond within a timeout then traceroute prints an asterisk. Lines 14 and 15 show that routers which drop packets with original TTLs 14 and 15 did not respond within timeout.
If the problem is just a timeout issue, you can set the -w parameter to the number of seconds you want to wait; e.g., traceroute -w 10 google.com will wait 10 seconds instead of the default of 5 seconds.
Note: Some traceroute clients use milliseconds instead of seconds for the -w parameter.
Arp may have timed out. I set up a test network with packetracer and got a asterisk for a destination host. I then pinged it, got a response then tracerouted again and it worked. I then noticed that the machines that were asterisking back did not have arp entries in the local router