Asymmetric routing is when a packet does not return on the same path it took to the destination.
This isn’t always an issue, some times it is by design. However there are certain scenarios where it can lead to issues:
1. Asymmetric routing can cause unicast flooding of traffic in very specialized conditions (worse if it’s one way UDP traffic).
In reality there are very few scenarios where the asymmetric routing is causing very bad unicast flooding.
2. If a firewall along the path is expecting the packet to be a tcp syn or part of a TCP stream and it is not (NO STATE) then it may get dropped.
The firewall may not have seen the traffic leave, and won’t allow it back in.
I’ve personally seen this specific issue when a client had a slow link backup MPLS circuit and was using a WAN site to site VPN as primary.
In that scenario the client wanted to send some traffic across the MPLS but they did not specify the return traffic should also come back through the MPLS.
This caused the traffic to go from site 1, through mpls to site 2, then to get back it went to the default gateway firewall and tried to go across the site to site VPN.
Since the firewall did not have a state for this traffic and it was not TCP syns or the begining of a UDP stream, it dropped the trafic.
3. Another issue that may creep up is performance issues across one path of an asymmetrically routed packet. The path to the destination might be good, but the return path for the packets
might be experiencing high latency. This is especially an issue when you are troubleshooting and you send traceroutes and seeing high latency thinking it’s one path but the ICMP time exceeded messages may be coming back another path and getting slowed down or dropped. This can also cause you to think there’s an issue along a path when there is not depending on how the ICMP time exceeded packets come back to you.