What do you mean, different results? They look just the same to me <img src="/forums/images/icons/wink.gif" alt="" />! Ha! Humor is a bit hard to communicate with text, isn't it!
Anyway - it looks a *LOT* like route oscillation - and since I know that our provider (pair.com) has an occasional "phantom" router - I'm pretty sure this is what's happening.
What happens is that the route is changing lengths between 16 and 17 hops long. when this oscillation is happening between hop n (the final destination) and hop n-1, this problem is hard to diagnose programatically.
Here's the scenario:
Ping Plotter sends out it's first set of samples up to 35 hops away and discovers that the final destination is at hop 16 - and there are 15 good routers ahead of it. In a normal good day, the route should be solid at 16 hops long, and a timeout at hop 16 means that the final destination didn't respond. If we, at that point (when we see a timeout at hop 16), try and push out to hop 17, then the final destination might respond just because we asked it again (in essence, giving it two opportunities to respond). If it does respond, we could assume that it is at hop 17 and put a new router in at hop 16 that didn't respond, but this is rarely the case. In most cases, if we did this, we'd show abnormally low packet loss to the final destination (because we gave every timeout a second change to respond).
Now I trace to the destination you're tracing to at least 24X7 (sometimes more since I have multiple PCs running to that destination) - and up until about 3 months ago (when my ISP changed their primary provider), I got similar results to what you're seeing - but the router that occasionally showed up for me at hop 16 actually reported back an address - a 192.168.xxx.xxx address. Note that 192.168.xxx.xxx addresses are NOT ROUTEABLE over the internet (these are designated for private use - like inside your home or inside an ISP, etc) - so some routers might decide to drop an ICMP echo timeout with this type of address. If that's the case, then this new router might appear to some people as a timeout - when really was a new router inserted into the chain.
Ugh, this gets messy!
Now, if a router *did* respond back here (like it did for me usually), then Ping Plotter would notice that another router responded at this point, and then figure out it needs to determine where the final destination actually is. It will handle that situation a lot nicer (and 2.40 makes some great advances on this front) - because it can figure out what happened. The real problem is when the newly inserted router shows up as a timeout.
This is only a problem when the new (timing out) router shows up between hop n and hop n-1 - because if it shows up and any *other* point, Ping Plotter will figure out there's a route change and take action to reconcile things.
Now, "PING" works differently because with PING we're not trying to discover the route. We're just shooting out a packet and asking the final destination to send it back - no matter how long the route is. PING ignores route changes completely.
You can actually put Ping Plotter 2.30 and later into this mode where it pings the final destination only - and you'll likely see similar results (no packet loss).
I don't have any revelations on great ways to have the software automatically determine this either. If I wasn't so familiar with this particular route, I'd be hard pressed to come up with a solid reason behind this (or to blame Ping Plotter, to tell the truth!).
While the new 2.40 beta does some work on this front, it still won't sniff this situation.
Thanks for the great example!
- Pete
Previous Topic
Index