Re: Recommendation of Tools

* Anders Lindbäck · * Wed Dec 03 17:14:45 2008

Well, to be somewhat cynical about it, you don't.
Either you have an SLA with a delay component, if that is the case
the delay is either end-to-end if everything is in the same AS, or
host-to-border if the other end is in some other AS. If this is the
case you would already have an agreed upon measuretool (ex. SLA
probes) and specified measuring points.
If you dont have a specified delay clause in your SLA then it is best
effort and irrelevant, in either case the hop by hop delay seen is
academic at best..
So as long as your delay is lower then specified by the SLA the only
result from trying to be "smart" and complaining about large hop to
hop delay is that the engineer you talk to will call you names after
he/she hangs up, or if it is over it is still very little/nothing you
can do but wait and let the carrier engineers fix it.
------------------------------
Anders Lindbäck
[email protected]

On 3 dec 2008, at 20.56, Braun, Mike wrote:
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:[email protected]]
Sent: Wednesday, December 03, 2008 10:02 AM
To: Pekka Savola
Cc: [email protected]
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
[email protected]

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.