[109640] in North American Network Operators' Group
RE: Recommendation of Tools
daemon@ATHENA.MIT.EDU (Braun, Mike)
Wed Dec 3 14:58:23 2008
Date: Wed, 3 Dec 2008 11:56:50 -0800
In-Reply-To: <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se>
From: "Braun, Mike" <MBraun@firstam.com>
To: =?iso-8859-1?Q?Anders_Lindb=E4ck?= <list-only@dnz.se>,
"Pekka Savola" <pekkas@netcore.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
If the question is to measure hop by hop latency from source to destination=
, perhaps across routers you don't manage, how can this be done without usi=
ng the ICMP time exceeded messages? End to end latency is easily done with=
Smokeping and the use of TCP (SYN, SYN ACK, ACK, RST) and them timestamp i=
t. This gives you a very clear idea on application latency on any tcp port=
. Hop by hop is a different story and the only option I know of is with th=
e reliance on the ICMP mechanism. One additional question on this; how do =
you measure hop by hop when the path dynamically changes, and then record t=
he path change (time/date and the differences in latency on the new path)?
Mike =20
-----Original Message-----
From: Anders Lindb=E4ck [mailto:list-only@dnz.se]=20
Sent: Wednesday, December 03, 2008 10:02 AM
To: Pekka Savola
Cc: nanog@nanog.org
Subject: Re: Recommendation of Tools
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
>
--
THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY=
FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, P=
ROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICAT=
ED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PER=
SON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FI=
LES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CON=
TACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF I=
T FROM YOUR SYSTEM.
