Traceroute #8 shows an increase in latency at hop 3 but no latency after that. This is another common example of traceroute being misleading. Notice there’s no latency to the intended destination of 10.10.10.6. Ping #1 confirms this as well.
Ping #1
C:\Users\candres>ping 10.10.10.6
Pinging 10.10.10.6 with 32 bytes of data:
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=3ms TTL=124
Ping statistics for 10.10.10.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms
Traceroute #8
C:\Users\candres>tracert 10.10.10.6
Tracing route to 10.10.10.6 over a maximum of 30 hops
1 1 ms 1 ms 1 ms SVL_FA0-0 [10.10.10.1]
2 1 ms 1 ms 1 ms SEA_Fa0-1 [192.168.1.2]
3 68 ms 319 ms 159 ms MIN_Fa0-0 [192.168.1.22]
4 4 ms 3 ms 3 ms OMH_Se0-1 [192.168.1.9]
5 6 ms 4 ms 4 ms 10.10.10.6
Trace complete.
There’s a clear discrepancy. Ping#1 between 10.10.10.2 and 10.10.10.6 shows no latency at all, traceroute #9 shows no latency between 10.10.10.6 and 10.10.10.2, yet traceroute #8 shows latency at hop 3. Why is this? To answer this we need to know the specific details of how traceroute operates which are shown below.
Traceroute #9 confirms no latency in the reverse path:
Traceroute #9
C:\>tracert 10.10.10.2
Tracing route to 10.10.10.2 over a maximum of 30 hops
1 3 ms 1 ms 1 ms OMH_Et0-0 [10.10.10.5]
2 3 ms 2 ms 2 ms TUL_Se0-1-0-0 [192.168.1.13]
3 5 ms 5 ms 5 ms PHX_Et1-1 [192.168.1.38]
4 5 ms 4 ms 4 ms SVL_Se0-0 [192.168.1.6]
5 4 ms 4 ms 4 ms 10.10.10.2
Trace complete
In this example we go over Traceroute #8
Looking at the diagram below, you can see why Traceroute #8 looks the way it does.
Out of all the probes and TTL exceeded messages the only packet to traverse the congested link, depicted with the bolded red arrow between MIN and DVR, is the TTL exceeded message generated by MIN. The rest of the packets traverse one or more links in the top (SVL > SEA > MIN > OMH) or bottom (OMH > TUL > PHX > SVL) paths.
For traceroute its possible for every packet, whether the probes or the TTL exceeded message, to take a path unique of the other traceroute packets. In the forward path for example probes may take different paths to reach the destination; this can happen if multipath is enabled for example. In the reverse path TTL exceeded messages can take different paths than the probes in asymmetric routing environments (the internet for example).
In this example the latency increase at hop 3 would not be a concern as it relates to performance between 10.10.10.2 and 10.10.10.6. This is because traffic between these two hosts never traverses the congested link (MIN > DVR). The forward path follows the top of the diagram (SVL > SEA > MIN > OMH) and the reverse path follows the bottom of the diagram (OMH > TUL > PHX > SVL).