I am currently in college for a bachelor's degree in Network Engineering, and one of my Professors explained in class that a traceroute that shows, for example, 15 hops is actually abstracting the path, and in reality many more nodes are involved. Is this true?

This contradicts everything I can find on traceroute. To my knowledge, traceroute works by sending ICMP (or UDP) packets to a specific destination with a TTL from 0 --> n until the destination is reached. The probe packets that are sent out time out at each location along the way in succession, producing an ICMP "time exceeded" reply, and finally a "port unreachable" message when reaching the destination.

I understand the imperfections of traceroute - for example, traceroute traffic may be blocked by certain gateways, or the TTL of the reply packet may be set to the probe's remaining TTL, causing it to never return to the sender.

However, after a lot of researching, I can't find anything referencing traceroute being inaccurate in the case of a traceroute that always returns the same path. Likewise, nothing referencing there being any "extra" hops not reported by traceroute (other than * * * hops that timed out with no reply).

I'm open to discussion, and I'm genuinely interested to know the answer to this.


3 Answers 3


A traceroute will show you how many layer 3 hops you are getting through from A to B.

However you could be going through hundreds of switches in between. You could also be going through 10 ISP routers running a layer 2 VPN which appears as a single hop. An MPLS network could hide its internals, or show its internals to you. You could have transparent firewalls in the path as well.

Either way your Professor is correct in saying that you cannot guarantee that every single device in the path will count as a hop to you. Because of the above points I mentioned, you could be going through 50 devices but it could look like three to you.

It doesn't happen all the time though. If you see 15 hops it very well could be 15 hops.

This is a basic example of an MPLS set up in regards to TTL: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/no-propagate-ttl-edit-protocols-mpls.html

  • Thank you! The situations you pointed out definitely give more insight as to what traceroute could be missing.
    – WilHall
    Commented Nov 16, 2013 at 18:03
  • 1
    No worries. Even things like a GRE tunnel can hide the underlaying hops as the GRE header itself has its own TTL
    – mellowd
    Commented Nov 16, 2013 at 18:08

Any device, that does not decrement IP TTL field value is not going to show up in the traceroute path. For example, Cisco ASA Firewall can be configured to decrement the IP TTL field for packets traversing the firewall (set connection decrement-ttl). By default, the TTL is not being decremented, thus hiding (well, somewhat) the firewall.


Traceroute will not show you devices that do not decrement the TTL fields of an IP datagram.

It also will not show devices which decrement the TTL field, and consume the packet if TTL reaches zero, but neglect to inform the sender of this event via an ICMP datagram. This is not entirely invisible though; you can infer the existence of this missing hop in the traceroute because when the next higher TTL value is used, the next device in the chain does respond, and we know that something between that and the previous device is decrementing TTL, but not announcing itself. The traditional traceroute utilty prints asterisks when it doesn't receive a response; it would print a row of asterisks for this type of host.

There is also the remote possibility that some router in between selectively supresses these ICMP messages depending on their source address, making some parts of the path look invisible even though they generated the response.

  • It's not that remote a possibility, all it would take is one network that used private IPs for their inter-router links and another that dropped all packets with private source IPs. Commented Oct 7, 2017 at 3:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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