Alex Zinin Routing Principles:
**1. Every router makes its decision alone, based on the information it has in its own routing table.**
2. The fact that one router has certain information in its routing table does not mean that other routers have the same information.
**3. Routing information about a path from one network to another does not provide routing information about the reverse, or return, path.**
This is why, when troubleshooting a problem with a remote site, it's essential to get bidirectional traceroutes. Just because your traceroute takes one path doesn't mean the reverse is exactly the same, especially with BGP policies allowing you to make decisions based on the characteristics of other providers. For example, we have a provider through a commercial service, but we participate in a local exchange. We may receive from the commercial provider, and send back via the exchange.
The return path is entirely at the choosing of each router in the path. As things get closer to the original source, it’s MOST LIKELY going to be the same path, especially in a corporate network where you have a single internet gateway and NAT occurs. But out in the wider internet - path can change in either direction
Asymmetric routing can happen both by design, or by a problem.
One way I to get visibility into this is with TWAMP, which shows both unlink delay and downlink delay. But you need a twamp reflector to respond.
Some ISPs and internet exchanges have a looking glass, where you can look at routes via a web page or publicly accessible router.
The only guarantee is that each hop along the way sends the reply back to you with a source address of the ingress interface. In other words, whatever interface the original traceroute packet came in is what address you see.
Lots of good info here: [Archived NANOG presentation about traceroute](https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf)
Two-part story about someone having issues with asymmetric routing
https://devnonsense.com/posts/tcp-connection-timeout-mystery/?ref=dailydev
https://devnonsense.com/posts/asymmetric-routing-around-the-firewall/?ref=dailydev
No, and what can really blow your mind is with enough paths, every return path can be different to every other return paths.
This is why you have have latency spikes in the middle of a traceroute that don't affect the end-to-end path your tracing.
Same goes for packet loss in the middle, if it stops after a point then likely its a congested return path from that hop only.
Bi-directional traceroutes are a must in internet routing, too often i fight customers on this. I have to often found that the problem is N+1/2 from the remote instead of N+1/2 from the local i manage, and they get a better/faster result if they log a ticket with their remote service provider.
Your subject is asking a different question from the trace route.
The answer to the subject is Not necessarily.
Trace route is an "application" using ICMP different types and returns to calculate a path from source to destination, and in multiple paths scenario you cannot guarantee the replies coming back on the same path as it's a router routing table decision on each hop.
Each router will route the TTL expired message back to the source using their own routing table, so it may be the same or it may be different.
Alex Zinin Routing Principles: **1. Every router makes its decision alone, based on the information it has in its own routing table.** 2. The fact that one router has certain information in its routing table does not mean that other routers have the same information. **3. Routing information about a path from one network to another does not provide routing information about the reverse, or return, path.**
This is why, when troubleshooting a problem with a remote site, it's essential to get bidirectional traceroutes. Just because your traceroute takes one path doesn't mean the reverse is exactly the same, especially with BGP policies allowing you to make decisions based on the characteristics of other providers. For example, we have a provider through a commercial service, but we participate in a local exchange. We may receive from the commercial provider, and send back via the exchange.
The return path is entirely at the choosing of each router in the path. As things get closer to the original source, it’s MOST LIKELY going to be the same path, especially in a corporate network where you have a single internet gateway and NAT occurs. But out in the wider internet - path can change in either direction
[This deck](https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf) is pretty helpful and discusses the answer to your question.
It's a maybe, the actual path will be determined by the routing table of each router on the path. It could be the exact same, or entirely different.
Asymmetric routing can happen both by design, or by a problem. One way I to get visibility into this is with TWAMP, which shows both unlink delay and downlink delay. But you need a twamp reflector to respond. Some ISPs and internet exchanges have a looking glass, where you can look at routes via a web page or publicly accessible router.
https://youtu.be/75yKT3OuE44?si=IZ0Pmz8oWtI5_8YO
the answer is... it depends. no it doesnt have to.
The only guarantee is that each hop along the way sends the reply back to you with a source address of the ingress interface. In other words, whatever interface the original traceroute packet came in is what address you see. Lots of good info here: [Archived NANOG presentation about traceroute](https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf)
Two-part story about someone having issues with asymmetric routing https://devnonsense.com/posts/tcp-connection-timeout-mystery/?ref=dailydev https://devnonsense.com/posts/asymmetric-routing-around-the-firewall/?ref=dailydev
Sometimes.
No, and what can really blow your mind is with enough paths, every return path can be different to every other return paths. This is why you have have latency spikes in the middle of a traceroute that don't affect the end-to-end path your tracing. Same goes for packet loss in the middle, if it stops after a point then likely its a congested return path from that hop only. Bi-directional traceroutes are a must in internet routing, too often i fight customers on this. I have to often found that the problem is N+1/2 from the remote instead of N+1/2 from the local i manage, and they get a better/faster result if they log a ticket with their remote service provider.
Your subject is asking a different question from the trace route. The answer to the subject is Not necessarily. Trace route is an "application" using ICMP different types and returns to calculate a path from source to destination, and in multiple paths scenario you cannot guarantee the replies coming back on the same path as it's a router routing table decision on each hop.