traceroute: sometimes routers don't respond and user sees timeouts

I'm an admin of small network and I'm investigating a problem my users complain about. The root of their complaints is traceroute: sometimes routers along the path simply don't respond to traceroute probes and users see timeouts (those *s in place of RTT).

The network consists of a few Linux routers connected by Ethernet/wireless. Linux routers 99% idle, link utilization 20 mbit/s, 2000 packets/s. Wireless is rock solid. PING to all routers along the path is 10 ms, with some variation of course. Flood PING to any of those hosts runs for minutes without any packet loss (and I mean 0 packets lost). Downloading some huge files over the network: 10.2 MB/s average.

The example correct traceroute looks like this:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.919 ms  3.866 ms  4.117 ms
 2  10.41.13.1  4.149 ms  6.714 ms  6.707 ms
 3  10.41.1.11  8.475 ms  8.468 ms  8.705 ms
 4  10.0.0.2  8.697 ms  9.428 ms  9.707 ms

The problematic traceroutes look like this:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.190 ms  3.140 ms  3.128 ms
 2  10.41.13.1  3.119 ms  3.113 ms *
 3  10.41.1.11  3.697 ms *  3.683 ms
 4  10.0.0.2  4.531 ms  4.524 ms  5.171 ms
# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.471 ms  3.405 ms  3.388 ms
 2  10.41.13.1  3.372 ms  3.359 ms  3.350 ms
 3  10.41.1.11  5.039 ms * *
 4  10.0.0.2  5.105 ms  5.484 ms  5.473 ms

I investigated a bit with tcpdump and found out that traceroute works like this:

1. At first sends a bunch of ICMP requests with TTL of 1, 2, 3, 4, 5, 6. Each TTL is sent 3 times. That is 18 packets :)
2. It waits some time for all replies (Time Exceeded).
3. When all replies return, show results.
4. ..or wait for timeout and show results with missing replies marked with asterisks.

And the cause of timeouts is - the routers get all 3 respective requests but sometimes don't respond, they don't send ICMP Time Exceeded.

I suspect there are some settings that set this behavior on router. Namely icmp_ratelimit, icmp_ratemask, icmp_msgs_per_sec and icmp_msgs_burst. All somehow described at kernel.org docs. And here is the point I failed. I didn't come with any values of those variables to make the traceroute work all the times.

I tried setting this on all routers:

• icmp_ratelimit set to 0 (don't limit anything)
• icmp_msgs_per_sec set to 10000 (should be high enough)
• icmp_msgs_burst set to 5000 (high enouth)

It didn't help me, I see the same behavior, random timeouts. I didn't mess with icmp_ratemask, because I don't fully understand how to exclude Time Exceeded's from limiting.

So finally, questions:

1. If you are familiar with this type of traceroute problems, how did you solve it?
2. If you are familiar with kernel settings mentioned above, what are "good enough" values?
3. What is the correct way to modify icmp_ratemask to not limit Time Exceeded messages to make traceroute work without glitches?
4. And extra - are there any security breaches when changing these (or any related) settings? I don't want to be DoS'ed nor to be a source of DDoS attack to anyone.

As part of control plane policies on hops ICMP probes mostly are ignored. I would suggest a dedicated on prem smokeping instance if you want to have more thorough, in terms of metrics and trends, historical data.