Re: [nsp] Odd traceroutes

From: Danny McPherson (danny@qwest.net)
Date: Thu Oct 21 1999 - 23:05:59 EDT


[Since this is the Cisco list :-)] Cisco IOS by default rate-limits "ICMP Port
Unreachable", as well as Source Quench (no others, I believe), message
generation to two per second. That's why the "middle probe" usually appears
to be discarded on the *destination* device.

Note that as suggested by your traceroute output, "ICMP Time Exceeded"
messages, which the client triggers from intermediate hops, aren't throttled
(per their generation isn't as "hands-on"), that's why the intermediate hops
don't exhibit this behavior.

And, as you've observed, other OSs do this as well. You can usually tune the
kernel to modify their behavior ("sysctl" on Linux (and BSD?), "ndd" on
solaris, other?). The reasoning for the throttling is obvious, I believe,
especially on routers.
 
-danny

>
> This might have to go on a Sun-specific list, but has anyone noticed the
> following behavior: A traceroute goes fine through even many hops, but
> on last hop, if its a sun server, the -middle- interval shows up as a
> star, on otherwise pristine connections.
>
> Like:
>
> (from UUNET)
>
> traceroute to allison.clark.net (207.97.14.170), 30 hops max, 40 byte packets
> 1 passepartout.web.us.uu.net (208.240.88.1) 249.671 ms 4.546 ms
> 0.587 ms
> 2 Serial1-1-1.GW2.DCA1.ALTER.NET (137.39.128.205) 3.342 ms 1.765 ms
> 2.373 ms
> 3 105.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.42) 3.454 ms 1.865 ms
> 1.483 ms
> 4 295.ATM1-0.TR1.DCA1.ALTER.NET (146.188.161.142) 1.691 ms 1.604 ms
> 1.720 ms
> 5 101.ATM6-0.TR1.EWR1.ALTER.NET (146.188.136.186) 7.428 ms 7.212 ms
> 7.128 ms
> 6 197.ATM7-0.XR1.NYC1.ALTER.NET (146.188.178.213) 6.281 ms 6.900 ms
> 6.834 ms
> 7 195.ATM11-0-0.BR1.NYC1.ALTER.NET (146.188.177.153) 6.723 ms 7.078
> ms 6.819 ms
> 8 uunet.nyc1.verio.net (129.250.9.61) 7.423 ms 7.773 ms 7.620 ms
> 9 nyc1.phl02.verio.net (129.250.3.125) 9.886 ms 9.035 ms 9.415 ms
> 10 phl02.phl00.verio.net (129.250.3.153) 8.898 ms 8.947 ms 8.066 ms
> 11 phl00.iad3.verio.net (129.250.3.105) 8.251 ms 8.219 ms 7.780 ms
> 12 iad3.dca0.verio.net (129.250.2.62) 7.917 ms 8.052 ms 10.563 ms
> 13 vma1.dca.verio.net (129.250.30.170) 137.615 ms 10.677 ms 347.567 ms
> 14 fa0-0-0.mae-east6.vma.verio.net (207.22.81.1) 8.990 ms 20.398 ms
> 113.581 ms
> 15 allison.clark.net (207.97.14.170) 11.210 ms * 11.294 ms
>
> --
>
> Nitrous, different target
>
> Tracing the route to sprawl.clark.net (198.17.243.6)
>
> 1 iad1-core4-pos1-0.atlas.digex.net (165.117.52.186) 0 msec 0 msec 0 msec
> 2 dca1-core10-pos4-2.atlas.digex.net (165.117.53.33) 0 msec 4 msec 0 msec
> 3 verio.dca1.atlas.digex.net (165.117.52.242) 0 msec 4 msec 4 msec
> 4 iad3.dca0.verio.net (129.250.2.62) [AS 2914] 4 msec 4 msec 4 msec
> 5 vma1.dca.verio.net (129.250.30.170) [AS 2914] 4 msec 0 msec 56 msec
> 6 fe2-0-0.mae-east.vma.verio.net (207.22.81.16) [AS 2914] 28 msec 4
> msec 16 msec
> 7 168.143.0.27 [AS 2914] 4 msec * 4 msec
>
>
> ---
>
> Every sun machine (2.5.1, 2.6, 2.7, latest patches) I have tried over a
> wan does this, over the lan, they are fine. Non-sun machines don't do this
> (bsd, etc) that I have seen. I have tried multiple types of traceroutes
> through different networks and different providers.
>
> Any clues or am I just imagining things?
>
> Deepak Jain
> AiNET
>



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:06 EDT