a colleague and I are pinging the same website from different locations (geographically, we are about 30 miles apart, both pinging a server about 1500 miles away). Pinging at 15 second intervals. Oddly, I will show a whole spurt of packets dropped by the target server during a particular period, indicating server difficulties, but my colleague may not show that at all. Why would this be? We want to reliably know when the server is having problems, but these differences make it difficult to be sure...

I'm assuming that you're using different ISPs, right?

It's almost certain that the problem is a router between you and the target server - and your colleague is going through a different route.

Note that if only the final hop is showing packet loss, then it's the route *back* that's causing the problem. I'd love to see the actual routes / data that you and your colleage are seeing - without that, I can just speculate. Feel free to e-mail it to pete@pingplotter.com and I'll post the pertinent data in a response.

Hi

I am seeing exactly what you describe



No matter what my destination is the last hop always has high packet loss after a few traces. Usually all the rest of the hops in between have no packet loss. You mention the route back can you explain what you mean or rather go into more detail on it. I think I am experiencing this issue.

Now my curiosity is piqued also. What are some of the destinations some of you are seeing this behavior with?

greatlakes.owo.com
www.lotsof-gifts.com
www.paypal.com
www.uo.com
www.ameritech.net
www.our-personals.com

greatlakes.owo.com and www.uo.com might give packet loss all along the route inside above net or what ever name they are hiding behind now. but even when I am getting no packetloss along the route I am getting it on those servers. In fact as I said I almost always see packet loss on the destination while pinging every 1 sec - 2 minutes. I have not any other intervals.

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!