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 traceroute
s 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:
- 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 :)
- It waits some time for all replies (
Time Exceeded
).
- When all replies return, show results.
- ..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:
- If you are familiar with this type of
traceroute
problems, how did you solve it?
- If you are familiar with kernel settings mentioned above, what are "good enough" values?
- What is the correct way to modify
icmp_ratemask
to not limit Time Exceeded
messages to make traceroute
work without glitches?
- 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.