[109637] in North American Network Operators' Group
Re: Recommendation of Tools
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=)
Wed Dec 3 13:01:52 2008
In-Reply-To: <alpine.LRH.2.00.0812031258350.7485@netcore.fi>
From: =?ISO-8859-1?Q?Anders_Lindb=E4ck?= <list-only@dnz.se>
Date: Wed, 3 Dec 2008 19:01:37 +0100
To: Pekka Savola <pekkas@netcore.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Mtr is even less usefull then that, in its default mode it does a =20
traceroute and then proceeds to ICMP Ping flood each IP in the list =20
generated by the traceroute, the result is usually completly useless =20
on WAN topologies due to asym-routing, ICMP node protections by =20
carriers and punting etc..
And using UDP will not really provide better results due to the same =20
thing, and IIRC Cisco from 12.0 has a standard setting of no more =20
then 1 ICMP Unreach per 500ms..
------------------------------
Anders Lindb=E4ck
anders.lindback@dnz.se
On 3 dec 2008, at 12.00, Pekka Savola wrote:
> On Tue, 2 Dec 2008, Antonio Querubin wrote:
>> On Wed, 3 Dec 2008, Pekka Savola wrote:
>>> FWIW, Mtr measures latency/delay and loss based on ICMP messages =20=
>>> heard
>>> back from the routers on path. As a result, in almost all =20
>>> cases, the real
>>> hop-by-hop latency of actual end-to-end data packets is better =20
>>> than it can
>>> report.
>>
>> mtr has a recently added '-u' option to use UDP instead of ICMP =20
>> echo requests.
>
> But that doesn't change the gist of my message: it's still relying =20
> on ICMP ttl exceeded messages sent by the routers on the path to =20
> check the delays etc. As such it suffers from basically the same =20
> limitations as ICMP probing.
>
> --=20
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
