traceroute doesn't print entire route sometimes

Question

Monitoring my network I realized some time ago that traceroute used to print routes more complete than it is doing right now... and, right now, sometimes traceroute omits some devices.

For example, this is a more complete traceroute, including my gateway:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

 1  * * *

 2  192.168.1.1 (192.168.1.1)  1.607 ms  1.604 ms  1.627 ms

 3  xxx.xx.136.5 (xxx.xx.136.5)  3.286 ms  5.729 ms  7.416 ms

Now, the exactly the same command omits my gateway:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

1  xxx.xx.136.5 (xxx.xx.136.5)  24.004 ms  28.267 ms  42.343 ms

These commands were given on the same machine.

How can I set to always have the entire route?

Answer 1

Any form of traceroute works by incrementing the TTL of an IP packet by one. The first packet has a TTL of one and the 1 router decrements the timer and send out an error massage via ICMP (Time to live exceeded). Standard *NIX traceroute uses UDP, Windows tracert ICMP, there are also versions that use TCP.

There are different cases why you don't see a hop:

• People think that ICMP is evil an block it. This will lead to many problems (e.g. PMTU discovery).
• People only think of windows and block UDP. Try running traceroute -I should to the trick.
• you may also want to try using tcptraceroute
• If a router is busy routing packets it's my not have the resources to send out ICMP packets.

Answer 2

I prefer to use tcptraceroute for a better detail of hop-to-hop routing.

tcptraceroute essentially bypasses most protective firewall ignoring ICMP packets that is used by traceroute. Use port 80 or 53.

Answer 3

If your gateway has a logging option, enable it. You may find an entry explaining the observed behavior. A router may interpret repeated ICMP as DOS.

... although, intuitively, one might expect the source to be on the outside network.

Answer 4

I have discovered what really goes with traceroute (and mtr, tpctraceroute, etc) on my intranet. It's my own router hiding known hops. My router (a TP-Link WAP like, with Linux 2.6.15) uses to hide the hops to known routes. So, v.g., giving traceroute on google, will outputs just one hop, google itself, because my router knows very well the route (I stay all day long using google). But, just connecting a PC straight on the access point, then giving traceroute toward google, it outputs back the entire route from here to google.

So, now I know what is going on, but not why it does that in this way.

As a workaround, I use the tracerout provided by the embedded linux running on the (problematic) router: that is, the router that, through my PC, hides hops, in its own embedded system provides an interface that executes tracerout properly...

Whatever, thanks for the reply!

Answer 5

Implementing a new host and noticed that trace route would only show the address of the local gateway, the address on the Hosts LAN, but all other hops where being displayed as *'s.

When I ran TCPDUMP on the same host whilst doing the trace route I could see that the ICMP TTL exceeded messages where being generated by the nodes in the path but TRACEROUTE just did not display the IP addresses...just more *'s.

The host had two network interfaces, Interface A which which had a default route configured on it and Interface B that had a static route to the Destination. It was Interface B that I was running the trace route on that was only displaying *'s.

To try and break down the problem I added another static route to the second hop, the next router in the path, so that I could work on a much shorter path. When I first started the test the second hop was only displayed as *'s but as soon as I added a static route to the network trace route displayed its IP address.

I did a trace route to the final destination again and noted all the IP addresses that generated ICMP TTL exceeded messages so that I could make sure that Interface B's routing had all of these networks statically configured. When I did this I could now see all the IP's listed in the trace routes result.

So, it looks like if the Interface receiving the ICMP TTL exceeded messages does not have routing back to that address then its not displayed in the Trace route results. I am sure someone in the community can explain why it behaves like this but a host with multiple interfaces running trace route on an interface the does not have the default route configured is pretty much a waste of time.