North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: chip
  • Date: Tue Sep 06 10:54:30 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=g62VtfEHb/1PnkH8M4ItTxjyJVYA+x2gm/dFae1AgGZ/mmdCoDMOtsgxVUyDI8OZDGz5qEq6o+U9DgExOUB9H4ioZqcZf7auJZBJDdehW6Gn2f6Nkyhy0V9WkijZ7wxRxB82XGy5znN01tW7veKdFo+H9rJ0bi+wzvMyMflxI1w=



On 9/6/05, Joe Maimon <[email protected]> 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....