Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The man page for traceroute says " traceroute tracks the route packets taken from an IP network on their way to a given host." , but while doing research on the topic I was not able to find any statistical data / scientific work on how precise Traceroute actually is as whether the route displayed is the route actually taken (maybe the different packets use completely different routes) and what the error margin is, and whether it would be possible , due to different routing protocols, a Traceroute ping might display a complete different path than a subsequent TCP request or even the actual ping packets would take.

The only work I found, implicating that a Ping tracing might not be perfect is the documentation on scamper which says "ping is useful to measure end-to-end delay and loss, search for responsive IP addresses, and classify the behaviour of hosts by examining how they respond to probes." and (as far as I understood) uses MDA traceroute for path detection. Therefore implying that using PING might not have the desired result.

Therefore my question is: How reliable is path detection using Traceroute (also why)? I'd greatly appreciate links going into details about that topic, but a general explanation why or why not would also suffice.

share|improve this question
up vote 2 down vote accepted

The most important thing to remember is that routes are not static. By design, routes on the public internet are changing all the time. Sometimes routes change due to load balancing; sometimes they change because a node goes down; sometimes they change because routers decide literally at random to change the routing rules (just to shake things up).

From the perspective of an end-user who does not have System Administrator-level access to every single intermediate router and internet hub between the origin and destination of a packet, you have to treat it kind of like the Heisenberg Uncertainty Principle.

Things to consider:

  1. Based on the declared IP "destination" in your packet, intermediate routers may decide to route you differently. Therefore, if a traceroute is an attempt to sequentially map the routers between source and destination, a traceroute can be thrown way off course by having routes take different paths depending on which node you're trying to reach.

  2. Not all routers will listen for ICMP or UDP pings. They may choose to silently ignore this traffic and just drop it at the NIC (often to help combat DDoS). This can frustrate your attempt to map a route.

  3. Even if you successfully map a route, and all intermediate nodes reply to your pings and don't attempt to play with your mapping attempt, the route may change for the next packets you send using some "real" protocol (or even if you attempt a traceroute a second time).

  4. QoS may cause normally-behaving networks to route traffic differently. For instance, VoIP or streaming video may take one path, while regular web browsing may take another.

  5. The type of traffic may cause the routing to differ. For instance, even without considering QoS, you may get a different path for FTP than you get for SSH. The intermediate nodes can exercise any discretion whatsoever (anything from a totally random selection of routes, to a malicious attempt to slow down your traffic, to an honest attempt to make your connection faster by routing to the node with the least load) when determining where to route your traffic from each hop.

  6. In theory, intermediate routers could also, if they so desired, turn your traceroute attempt into an infinite cycle: node A points to node B, node B points to node C, and node C points back to node A. There is nothing stopping the routers from doing this (I'm not sure why they would choose to, but it's a possibility) for packets detected as "traceroutes" (ICMP or UDP pings). It can do this to attempt to foil your efforts, or for any other reason.

The Multipath Discovery Algorithm is useful, but it cannot overcome these theoretical limitations.

Basically, in order to determine a path, you have to send one or more packets. Those packets can be routed in any way the intermediate nodes see fit. But as soon as you send another packet, there is absolutely nothing stopping the routers from changing the path. This is sort of a networking analogy of the Heisenberg Uncertainty Principle.

Paths are ephemeral and transient. You should not rely on information received from a traceroute for anything important, except to diagnose a connectivity issue on a network where you already have deep knowledge of the topology (on a complicated corporate LAN, for instance), and can control the behavior of the participating nodes. If any of the participating nodes aren't "yours" (if you can't log into them with system administrator privileges), the results of the traceroute are effectively arbitrary.

On the other hand, if all of the participating nodes are yours, you can, as administrator, control the exact behavior of each node. For instance, you can enable ICMP, and set up static routes (routes that don't change). You can then be confident that your traceroute is accurate. But if you put a load balancer in the middle, then you will have to be aware of the load balancer's behavior and the way that it can switch routes pretty much as needed (although it generally isn't random and generally doesn't try to deceive you on purpose).

share|improve this answer
Thank you for this throughout and detailed answer which does provide a great explanation on the theoretical properties of traceroute. But concerning your conclusion I (just) ran across ["Y. Zhang, V.Paxson, and S.Shenker, “The Stationarity of Internet Path Properties: Routing, Loss and Throughput,” in ACIRI Technical Report, May 2000.] which states that most routes seem to be stable at least for a day concerning multiple traceroute runs. Though it does not address QoP and the other points made by you concerning "real" protocols. – Sim Mar 18 '14 at 14:12
That's an interesting paper (didn't read it all) and the results may be empirically correct, but please keep in mind that the paper is from the year 2000; the internet has changed a lot since then. Their results may not be valid any longer. – allquixotic Mar 18 '14 at 14:36
of cause, I just wanted to mention it here for further information. Sadly this is the most up-to-date paper I found so far – Sim Mar 18 '14 at 14:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .