Traceroute: Can it trace a path from A to B correctly?

Question

Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace). In Windows, you can type tracert. The main algorithm is:

send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.

send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.

Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B

Does this algorithm work correctly? Because at different time, an intermediate server can send a message to different server. For example, at first time, UDP message is sent to A1, but at a later time, it can send to another server, for example, B1. So, trace route will not work properly.

Did I misunderstand something?

Answer 1

From the man page :

traceroute tracks the route packets take from an IP network on their way to a given host

So if you are trying to find one of the possible paths your packet may take, you'll find a friend in traceroute .

Now because routing tables do not change every minute, the packets that you send will most probably take the same path as traced by traceroute.

Another important point that cannot be missed is the record route option in the IP v4 header. Once you specify that you want to use this option, every router in the path will add it's ip address to the options in the header. You can read more about it here. The catch being that the destination gets to know about the intermediate hops , not the source.

I see that you missed the role of icmp echo request and reply messages in the description of traceroute. In case this was not intentional , take a look.

Update : You can see the record route option in action by doing a ping -R

ping -R Turns on route recording for the Echo Request packets, and display the route buffer on returned packets (ignored by many routers).

Answer 2

The algorithm works properly. Indeed, routing may change due to considerations of different servers along the way, such as server load or availability. Let's say you want to send message from A to B. If the route is not changeable, what will happen if some server on the route is down? If the routing couldn't be adjusted dynamically, that would result in inability to deliver the message to the destination in this example. Here is a different example: let's say you have a server that is used for some heavy computation during the day but it's idle during the night. It's possible to allow it to pass traffic only during the night, so any routing using it will need to be changed at day.

To conclude all this we can definitely say that without dynamic routing the internet couldn't have existed in its' present form.

Addition:

Tracert sends message from A to B. It shows hops along the way. These hops constitute a valid route from A to B at the time of the execution. There is no guarantee that connection between 2 adjacent points along the way is valid after the hop has been completed. The only thing guaranteed is that for each hop there was a link between it's 2 endpoints when the message sent by tracert passed there.