John, 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. regards, mb -- Mark Boolootian booloo@cats.ucsc.edu