[144670] in North American Network Operators' Group
Re: Traceroute losses through NYC1.gblx.net?
daemon@ATHENA.MIT.EDU (Jared Mauch)
Fri Sep 16 14:52:08 2011
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
Date: Fri, 16 Sep 2011 14:50:28 -0400
To: Steve Bohrer <skbohrer@simons-rock.edu>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 16, 2011, at 2:42 PM, Steve Bohrer wrote:
> My general question is "what meaning do I give to lossy traceroutes, =
even when pings show no problem."
>=20
> Can I expect that backbone routers should never give me timeouts on a =
traceroute through them, so, lots of asterisks from these systems =
indicate a packet loss problem that needs to be fixed?
>=20
> Or, are these traceroute asterisks essentially meaningless, and should =
be expected on any busy link?
Basically, you should expect timeouts in the middle of the path from any =
large network from time-to-time.
It could be for any number of reasons, ddos, control-plane "busyness", =
etc..
There was even a provider that once limited the ability for people to =
see inside their network.
The true tests are always end-to-end tests. I recommend having a host =
at each end that you can run pings or iperf from. This will aide you =
greatly in diagnosing the trouble. Traceroute (or, more specifically =
TTL expiry handling by a multipurpose device) is often lower on the =
priority list than things to keep the element "alive and operational".
Your outputs showed good results on each end of the path, meaning that =
the device was perhaps rate-limiting the TTL expiry traffic or had =
something else going on.
- Jared=
