North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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@example.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
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
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.
Just my $.02, your mileage may vary, batteries not included, etc....