Asymmetric Routing

Curtis Villamizar curtis at ans.net
Wed Oct 18 16:06:29 UTC 1995


In message <199510181108.HAA05648 at dcb01a.cwi.net>, joliveto at cwi.net writes:
> Analysis of some of our routes shows the potential for asymmetric 
> routing...that is...the transmit path will be different than the return path 
> for packets.

Assymetric routes seem to be a fact of life these days.

> Questions:
> 
> How noticeable is this likely to be for customer traffic/applications?

The only application that gets upset over an assymetric route (that I
know of) is xntpd.  You can throw off time synchronization by the
difference in the delay of the two paths.

> Are there failure conditions waiting to haunt us?

There is a related condition that can give horrible TCP performance
for any TCP applications.  If you do load splitting across two links
and do the every other packet style load splitting, TCP gets tons of
out of order packets and performance can be seriously affected.  This
is the case where a dual homed site decides to load split by taking
equal costs default routes rather than full routing and splitting
traffic by destination.  An assymetric route that doesn't do load
splitting won't be affected.  Sometimes you can't help it if a
provider in the path does load splitting this way (other than complain
to them or get another provider).

> For this type of route, how does one go about troubleshooting route failures?

When using traceroute think about what is happening before declaring
that you've found a black hole.  At some point in a traceroute there
is a jump in the hop count of the return path.  This makes doing
traceroutes tricky (at best).  Use a traceroute that support -g.

> Any bad experiences out their with such routes in place?
> 
> Am I being paranoid?

Just smart in asking first.

> Thanks;
> 
> - jeff -

Curtis



More information about the NANOG mailing list