In message <199510181108.HAA05648@dcb01a.cwi.net>, joliveto@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