icmp performance vs. traceroute/tcptraceroute, ssh, ipsec

Lincoln Dale ltd at
Tue May 8 04:12:57 UTC 2007

> Anyways, initial reports are that as per my advice, customer calls
> vendor says "voip not working" vendor says "i changed something, wont
> tell you what, reboot everything in 30" and now things seem to work
> perfectly, strangely enough EVEN the traceroutes.
> This is obviously not best effort. Best guess would be "managed
> bandwidth" differentiated by ip ranges and that the "change" was a
> different pool assignment.

its hard to say.  could be that a peering connection was down or congested,
that cold-potato routing within said provider was suboptimal, there are any
number of rational reasons other than "managed bandwidth".

> I suspect the stellar icmp echo performance is also intentional.

as stated previously, eliciting a response out of a router through "icmp
processing" is vastly different to the standard process of forwarding a packet.

there are any number of countless reasons why icmp-ttl-exceeded response times
can be vastly-over or vastly-under the actual round-trip-time of a packet.

if you still don't believe, do a search for "Cisco Control Plane Policing" or
other vendors have similar mechanisms also.

> Compare:
> tcptraceroute -q 5 -w 1  80 -f 7
> Selected device eth0, address, port 33204 for outgoing packets
> Tracing the path to ( on TCP port
> 80 (www), 30 hops max
>   7 (  45.008 ms
> 52.978 ms  32.404 ms  50.676 ms  33.657 ms
>   8 (  49.037 ms  33.145
> ms  48.029 ms  34.355 ms  48.453 ms

using tcptraceroute in this manner is NO DIFFERENT to normal traceroute.

the routers in the intermediate hops are still essentially doing
icmp-ttl-exceeded behaviour, so the same "can't read anything into the latency"
statements i've made a few times now.

in either case, its good to hear you have your issue resolved.



More information about the NANOG mailing list