Asymmetric routing

[knaik99]

in general, why asymmetric routing is not useful ?

do it create slowness ?

anyhow data is reaching to destination from source .

Please share pros and cons of Asymmetric routing

[Flavio Miranda]

@knaik99 

 From the networking perspective you could have problem routing  the traffic depending on how this is configured. If you are using source routing for example, using one policy applied to one interface and part of the traffic is comming from a different source interface.

 But Who dont like asymmetric routing is applications due the out of order packet and mostly, security device like firewall or IPS because it makes difficult to track the sessions.

I dont see any pros honestly, usually it cause problems.

[timo-juhani]

The nature of asymmetric routing could be discussed from the viewpoint of the normal passenger traffic. Imagine a driver who takes one route from home to work and a different one when leaving the office. The outcome of this is that unless the routes are exactly long and congested the duration of the commute will be different. When it comes to UDP based and real-time applications this could be a major quality issue because the traffic might arrive out of order or much later than expected.

The other example is that imagine that you're crossing a decentralized security boundary such as a border crossing. After showing your passport they let you go and make a note of that so that the border guards know to expect you back at some point. The real problem comes when you decide to return via a different border crossing and the guards on that crossing don't have a clue who you are. Much like border guards stateful devices such as firewalls and NAT are not quite compatible with asymmetric routing. They must know the traffic left from within so that they can keep a port open for the return traffic.

Finally in both normal and problem conditions it's demanding to figure out whether the network is fine, whether it's broken or whether in fact it was built like this.

Always understand what causes asymmetric routing and investigate the impact on applications to determine whether it's desired or not. 9.5/10 times it has turned out to be not desired.

[Joseph W. Doherty]

As the others have already described, asymmetrical routing comes in two "flavors".

The first "flavor" is: return traffic from some destination doesn't take exactly the same path as the traffic did to reach the destination.

This is usually only a problem for "stateful" devices like firewalls and NAT, those that need to "match" traffic going in one direction with traffic going in the opposite direction.

A key point with this "flavor" perhaps only one or very few transit nodes need to "match" the in/out traffic.  I.e. other parts of the two directions of traffic might flow across completely different paths without any issue.

The second "flavor" is traffic flowing in one direction, part of some "flow", individual packets, of that flow, take different paths.  The possible problem is packets may arrive at the destination in a sequence different from what was sent.  If this happens, this may, or may not, cause the network application "grief".  Much depends on the nature of the network application, and how different the arrival times are.  (Actually, depending on the network application, excessively delayed and/or lost packets might also cause a network application "grief", i.e. out of sequence delivery isn't the only possible network transit impairment.)

Anyway, to avoid causing network applications "grief", due to out of sequence delivery, network transit devices will generally send all of the same "flow's" packets along the same path, unless there's a major change within the network topology.

A key point of the second "flavor" of asymmetrical routing, IP, by design, does not guarantee packet sequence delivery.  I.e. network applications should be able to deal with out-of-sequence packet arrivals, but again, tolerance for out-of-sequence delivery varies by network application.

Interestingly, TCP provides guaranteed packet delivery in transmission sequence.  Yet, TCP implementations generally have a "feature" (fast retransmission) that when a packet doesn't arrive in sequence, and a couple of subsequent packets do arrive, TCP assumes the missing packet was lost and it will be retransmitted, yet the missing (delayed - out of sequence) packet may just arrive late.  I.e. you've sent the same data twice, duplicate(s) will be ignored by TCP, but they waste bandwidth and further delay other subsequent packets.

So, again, network routers, often, but not always, will not direct its "flows" packets onto different paths unless there's a compelling need, and then the whole flow is shifted.  (During the shift, some packets may now arrive out-of-sequence, but sequence should stabilize.)

[Ramblin Tech]

I should also point out that any asymmetry in latency, whether from asymmetrical L3 routing or L1 transmit & receive fibers having different lengths, is an absolute accuracy killer for 2-way time synch protocols like ptp and ntp. If you are carrying ptp/ntp on your network, avoid asymmetry at all costs. 

[Joseph W. Doherty]

Of course, if asymmetrical latecy is a concern, then such latency would also be impacted by asymmetrical queuing delay too.  (Which is why PTP transit nodes process PTP "special", including, if possible, hardware support.)