RE: Recommendation of Tools

["Braun, Mike" <MBraun () firstam com>]

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 using 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 it.  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 the 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 the path change (time/date and the differences in latency on the new path)?

Mike    

-----Original Message-----
From: Anders Lindbäck [mailto:list-only () dnz se] 
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  
traceroute and then proceeds to ICMP Ping flood each IP in the list  
generated by the traceroute, the result is usually completly useless  
on WAN topologies due to asym-routing, ICMP node protections by  
carriers and punting etc..

And using UDP will not really provide better results due to the same  
thing, and IIRC Cisco from 12.0 has a standard setting of no more  
then 1 ICMP Unreach per 500ms..

------------------------------
Anders Lindbäck
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  
> > > heard
> > >  back from the routers on path.  As a result, in almost all  
> > > cases, the real
> > >  hop-by-hop latency of actual end-to-end data packets is better  
> > > than it can
> > >  report.
> >
> > mtr has a recently added '-u' option to use UDP instead of ICMP  
> > echo requests.
>
> But that doesn't change the gist of my message: it's still relying  
> on ICMP ttl exceeded messages sent by the routers on the path to  
> check the delays etc.  As such it suffers from basically the same  
> limitations as ICMP probing.
>
> -- 
> 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, PROPRIETARY OR PRIVILEGED INFORMATION.  IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS 
MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE 
THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH.  IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY 
REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.