level3.net in Chicago - high packet loss?!?

Tue Sep 6 14:52:32 UTC 2005

On 9/6/05, Joe Maimon <jmaimon at ttec.com> wrote:
> 
> 
> If the hop(s) following the one you see loss for shows no loss, then
> disregard the loss for that hop, obviously whatever it is, it does not
> affect transit, which is what you really want to know.
> 
> Is that correct?
> 
> 
This is one of the most misunderstood concepts in properly reading output 
from a traceroute (mtr, visualtraceroute, whatever). Basically you are 
seeing loss of packets destined directly *TO* that router, not THRU it. Most 
often this is caused by 1) the router having ratelimits applied to these 
packets so as not to bog down the CPU while it's trying to perfom its main 
function...forwarding packets or 2) the router is already busy and places a 
low priority on responding to those packets so as to leave CPU available for 
forwarding packets. 

You can see from the trace that hops after that don't show any loss. If that 
router was actually causing loss then you would see the loss continue thru 
the rest of the trace. Since you don't, you can assume that the router is 
experiencing one of the cases above. Of course there are always exceptions 
but 99.9% of the time this is the case. This same concept applies to latency 
as well. If you see only a single hop with a high response time and 
everything afterwards is normal, it's the same situation but it's taking the 
router a longer time to respond to you rather than it ignoring you. You can 
test this by simply pinging the end destination...do you see the same loss 
and/or high latency, if not you can disregard it. 

And while we're on the subject of reading this output, remember that traces 
only show you the forward path, not the reverse. Thanks to the wonders of 
asymmetric routing, at times it could be the return path that actually has 
the loss on it, the loss in the forward path only gives you an idea of where 
to begin troubleshooting.

--chip

-- 
Just my $.02, your mileage may vary, batteries not included, etc....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050906/75333e87/attachment.html>