Can you explain why paths to same host diverge?


Thanks very much for providing the cogent explanation.

You ask:

I feel obligated to ask -- is there some reason you didn't
direct your query to Sprint, before asking NANOG? It really seems like
this is the kind of question they should be able to answer for you,
and diagnose the problem to some extent. I can't see a good reason to ask
here without asking the providers in question, first.

There were really two reasons I asked this question here. First, it
seemed like an interesting operational issue that I hadn't ever seen
beaten to death on NANOG. Everyone is used to asymmetry between forward
and reverse paths, but I don't think I'd ever seen a case of asymmetry
in the forward path (at least, not while the network was stable). Second,
I don't necessarily expect my provider to tell me why things route the way
they do; I only expect them to fix things when they're broken. NANOG
seems the appropriate place to ask the "why" questions. For what it's
worth, I am pursuing this with our provider.

It is worth noting, I suppose, that optioned packets (i.e. traceroute -g
or ping -R) are not CEF-switched, and therefore cannot be used to
instrument the behavior of this hash. As a result, your best bet is
limited ttl probes to various hops.

Presumably this is why the reverse traceroutes I ran didn't seem to
shed any light.

Thanks again for the end2end-interest pointer and the fine explanation.


Actually, this is alot more common than you'd think. Because of the lead
time in getting OC-Nc circuits installed (where N is whatever greater
than your carrier/transmissions folks are used to delivering) and
the difficulty in getting them, alots of folks put in multiple parallel
DS3s and such to tide them over.

To use such links effectively, many folks are turning to source/dest
hashing load balancing in DCEF.