difference between reverse, forwarding and return path on traceroute

Question

As described on the title, I can't make difference between reverse, forwarding and return path, especially between reverse and return path. Also, how the RTT is affected by the reverse, forwarding and return path?

Thanks in advance.

Answer 1

You are "A", you are performing a Traceroute to "B"

First hop is A > R1. The response travels R1 > A. In this case, the RTT time is how long it took for the packet to get from A, to R1, and back. In a way, you could divide the RTT in half, and you would have the time from A to R1, and from R1 to A.

Second Hop is A > R1 > R2. The response travels R2 > R1 > A. This is the same as above. The forward path is identical to the reverse path.

Third Hop is A > R1 > R2 > R3. And for reasons outside of your control, the response travels R3 > R5 > R1 > A. You receive a RTT time that encompasses BOTH of these paths. The problem is that since there is a different reverse path than there is a forward path the RTT time doesn't directly indicate a problem in the path.

For example, if you get a RTT time of 90. It might be tempting to divide that in half and say the path A > R1 > R2 > R3 took 45ms and the R3 > R5 > R1 > A path took 45ms. But there is no way of knowing that.

Its possible that the forward path took 20ms (which is relatively "healthy"), but the response path took 70ms (which is relatively less healthy, but not quite unhealthy).

Moreover, there is also no way of determining what the return path is -- traceroute only provides the forward path.

To summarize:

• Forward Path - path from you to the destination
• Return Path - path from the destination back to you (sometimes this is the exact inverse of the forward path, sometimes it is not)

Return Path vs Reverse Path are the same thing, as far as I know. But maybe someone else will have an answer that says otherwise.

Answer 2

I don't have much to nit-pick about @Eddie answer, it's a great answer. My only augment - it's possible in some cases to get a view of the return path.

This uses the "Return Path" option in the ICMP ECHO_REQUEST. It's not required to be supported by any nodes, and many admins disable the support (it can be used for network mapping by l33t hax0rs 😲). But Cisco routers don't disable it by default, we don't disable it (long story), and in lab scenarios (GNS3, etc) it can be an interesting academic exercise.

Here's an example from my network.

[user@server ~]$ ping -R Router3
PING Router3 (IP) 56(124) bytes of data.
64 bytes from IP: icmp_seq=1 ttl=253 time=4.87 ms
NOP
RR:     server
        Router1
        Router2
        Router3
        Router3
        Router2
        Router4
        server

^C
--- Router3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.878/4.878/4.878/0.000 ms
[user@server ~]$

But, like I said, it's not guaranteed to work:

[user@server ~]$ ping -R 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=10.5 ms

^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.542/10.542/10.542/0.000 ms
[user@server ~]$