Subject: Re: traceroute termination on ICMP unreachable
To: None <is@NetBSD.ORG>
From: Dennis Ferguson <firstname.lastname@example.org>
Date: 09/04/1997 21:10:00
> as a side remark in his PR 4038, Havard Eidnes claimed that (some/most)
> routers rate-limit ICMP unreachable messages, so that normally, only e.g.
> two of 3 traceroute probes would get the message back.
Cisco routers do this (that probably makes `some/most' pretty accurate).
If things haven't changed recently they rate limit the ICMP messages to
1 per second. The reason you normally get 2 out of 3 is that if you
traceroute sends a new probe as soon as it gets a response, which usually
comes back in 10's or 100's of milliseconds. This new probe will be
dropped by the router since it arrived less than a second after the previous
one. Traceroute times out (in 2 seconds?) before sending the third probe,
so the third probe arrives at the router several seconds after the
previous probe the router responded to, so (if you're lucky, and the
router isn't sending ICMP messages elsewhere as well) you'll get
an answer to that one. If you send a 4th probe in response to this
it'll be dropped, but the 5th probe sent after another timeout will
get an answer. In general, if you are really fortunate, if you send
`n' probes you'll get (n + 1) / 2 responses.
> Havard proposed to test for (nunreachables && (nunreachables >= (nprobes-1))
(nunreachables >= ((nprobes + 1) / 2)) might be better.
> So, do the networking/router experts among us have better formulae to propose?
> [Is there any RFC/Internet Draft proposing rate limiting on ICMP?]
There is no RFC. Cisco makes this stuff up (though, to be fair, sending
ICMP messages in those boxes does take CPU cycles from a CPU which
sometimes has better things to do, which is probably why they do it this way).