| 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. 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. Sean.