[109656] in North American Network Operators' Group
Re: Recommendation of Tools
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=)
Wed Dec 3 17:14:31 2008
In-Reply-To: <CCC465742E47CC4090095AE1FF1C5B59107628B5@CREDPWY01SXCH02.credit.credco.net>
From: =?ISO-8859-1?Q?Anders_Lindb=E4ck?= <list-only@dnz.se>
Date: Wed, 3 Dec 2008 23:14:23 +0100
To: "Braun, Mike" <MBraun@firstam.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Well, to be somewhat cynical about it, you don't.
Either you have an SLA with a delay component, if that is the case =20
the delay is either end-to-end if everything is in the same AS, or =20
host-to-border if the other end is in some other AS. If this is the =20
case you would already have an agreed upon measuretool (ex. SLA =20
probes) and specified measuring points.
If you dont have a specified delay clause in your SLA then it is best =20=
effort and irrelevant, in either case the hop by hop delay seen is =20
academic at best..
So as long as your delay is lower then specified by the SLA the only =20
result from trying to be "smart" and complaining about large hop to =20
hop delay is that the engineer you talk to will call you names after =20
he/she hangs up, or if it is over it is still very little/nothing you =20=
can do but wait and let the carrier engineers fix it.
------------------------------
Anders Lindb=E4ck
anders.lindback@dnz.se
On 3 dec 2008, at 20.56, Braun, Mike wrote:
> If the question is to measure hop by hop latency from source to =20
> destination, perhaps across routers you don't manage, how can this =20
> be done without using the ICMP time exceeded messages? End to end =20
> latency is easily done with Smokeping and the use of TCP (SYN, SYN =20
> ACK, ACK, RST) and them timestamp it. This gives you a very clear =20
> idea on application latency on any tcp port. Hop by hop is a =20
> different story and the only option I know of is with the reliance =20
> on the ICMP mechanism. One additional question on this; how do you =20=
> measure hop by hop when the path dynamically changes, and then =20
> record the path change (time/date and the differences in latency on =20=
> the new path)?
>
> Mike
>
> -----Original Message-----
> From: Anders Lindb=E4ck [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=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
>>>> 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.
>>
>> --=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 =20
> INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY =20
> CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF =20
> YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE =20=
> FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, =20
> USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED =20
> HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE =20=
> SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT =20=
> FROM YOUR SYSTEM.
>
