This definitely sounds like your *return* route. Due to the way traceroute is implemented, we can only find the route a packet follows to get *TO* the destination - not how they get back. This is called "asynchronous routing" - and means that the outgoing route isn't the same as the return route. This happens because each router makes decisions about where data will go based on a different set of rules - and who they are "peered" to.

So in cases where you see only the final destination with packet loss, the return route may be significantly different when coming back from the final destination than it is when coming back from the hop right before it.

The best way to troubleshoot this is to have access to traceroute from that server. This isn't feasible for most situations, but if you have a business relationship with one of them, you may be able to get them to run a traceroute from them back to you - to see where this packet loss is occuring. Some sites even have scripts installed for you to check this yourself.

This is probably related to some particular provider that all these sites have in common. There are probably a whole bunch of *other* servers that use this same "problem" peer. Your goal is to try and determine what this peer is.

To that end, here is a nice page of servers that will trace back to you. If you go through this list and find one (using Ping Plotter) that gets packet loss in the same way that you're seeing with the list above, then you can use the server-side traceroute facilities to find out what the route *back* is. This should point to the problem link.

http://www.ispworld.com/ispdirectories/find_backbone.htm

You've definitely pointed out one of the weaknesses of trace route troubleshooting - that it only shows the route in one direction. Unfortunately, there's really not any better way available today.

Keep us informed about your progress on troubleshooting this problem!