|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 04 May 2005 13:44:59 -0400 From: Joe Maimon <jmaimon@ttec.com> To: Joel Jaeggli <joelja@darkwing.uoregon.edu> Cc: Luke Parrish <lukep@centurytel.net>, Andrew Lee <leea@grnoc.iu.edu>, nanog@merit.edu In-Reply-To: <Pine.LNX.4.62.0505041019270.8865@twin.uoregon.edu> Errors-To: owner-nanog@merit.edu Joel Jaeggli wrote: > > On Wed, 4 May 2005, Luke Parrish wrote: > >> >> Andrew, traceroute is an effective tool is measuring roundtrip in ms >> format. > > > packets sent to a router are typically processed differently and with > different priority then packets forwarded through it. This makes > traceroute fairly unreliable. > Since it is probably a fair assumption that routers will never procces forwarding packets slower than ICMP replies, the following applies. The router receiving the traceroute response from its upstream would process that in its forwarding path. So if you see a 30ms hit on hop A and a 60 ms hit on hop B you can pretty much determine that hop A is 30ms away but you cant be quite sure about hop B until you see hop C's replies. To make this more interesting, its always possible that hop B or C's path to you is different than your path to hop B or C. Also, traceroute is effective at showing that the path rtt is good. Its just when you are trying to find where the latency is that things can get dicey.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |