Analysis of some of our routes shows the potential for asymmetric
routing...that is...the transmit path will be different than the return path
Asymmetry has been a reality for quite some time now; in fact
it was happening during the NSFNET backbone service days,
since the information in the PRDB was often in a shambles.
(Using the advisory mechanism and having it driven by
end site administrators makes it very easy to get ANS
to route traffic the wrong way. A quick estimate done
just prior to the last NANOG meeting showed that of the
routes which actually are accurate, fully a third of
them appeared to be localpreffed towards the wrong ENSSes.
To their credit, ANS is now listening to MEDs, as a means of
fixing that problem.
Personally, I'm quite happy to see them do closest-exit
towards AS 1239 instead; it doesn't really matter all that
much unless they get starved for capacity on their long-haul
lines or at certain touchdown points.)
How noticeable is this likely to be for customer traffic/applications?
Modern TCPs don't even notice; older TCPs seem to cope well
enough that you're liklier to have problems with small
window sizes than with asymmetrical routing.
You have to be careful about interpreting traceroute and ping
results, however, and NTP dispersion will increase as path
RTT asymmetry increases. (The fix for the former is probably
Tao or Zen, the fix for the latter is to peer only with
things very close to you; this usually means your direct
service provider('s|s') customer-access router(s)).
Any bad experiences out their with such routes in place?
SprintLink AS1239 and InternetMCI AS3561 have been
doing closest-exit routing towards each other for several
weeks; so far so good as far as huge-scale asymmetry goes.
Lots of other (multihomed) sites have had small-scale
asymmetries in abundance for more than a year. Most of
the ones I know have been more concerned about balancing
traffic across multiple connections than about side-effects
of asymmetrical routing.