☰

traceroute：有时路由器不响应，用户会看到超时

tag-icon • tag-icon linux timeout rate-limiting icmp traceroute
traceroute：有时路由器不响应，用户会看到超时

我是小型网络的管理员，正在调查用户抱怨的一个问题。他们抱怨的根源是traceroute：有时路径上的路由器根本不响应traceroute探测，用户会看到超时（那些*代替 RTT 的 s）。

网络由几台通过以太网/无线连接的 Linux 路由器组成。Linux 路由器空闲率 99%，链路利用率为 20 mbit/s，2000 数据包/秒。无线非常稳定。对路径上所有路由器的 PING 时间为 10 毫秒，当然会有一些变化。对任何主机的泛洪 PING 运行数分钟，没有任何数据包丢失（我的意思是没有数据包丢失）。通过网络下载一些大文件：平均 10.2 MB/秒。

这个例子正确的 traceroute看起来像这样：

# 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

这有问题的 traceroute看起来像这样：

# 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

我进行了一些调查tcpdump，发现其traceroute工作原理如下：

  1. 首先发送一堆 ICMP 请求，TTL 为 1、2、3、4、5、6。每个 TTL 发送 3 次。一共有 18 个数据包 :)
  2. 它会等待一段时间来接收所有答复（Time Exceeded）。
  3. 当所有回复返回时，显示结果。
  4. ..或者等待超时并显示带有星号标记的缺失回复的结果。

超时的原因是 - 路由器收到所有 3 个相应的请求，但有时不响应，它们不发送 ICMP 超时。

我怀疑路由器上的某些设置导致了这种行为。即icmp_ratelimit，icmp_ratemask，icmp_msgs_per_sec和icmp_msgs_burst. 所有这些都以某种方式被描述在 kernel.org 文档中。这就是我失败的地方。我没有提供这些变量的任何值来使它traceroute始终有效。

我尝试在所有路由器上进行此项设置：

  • icmp_ratelimit设置为0（不限制任何内容）
  • icmp_msgs_per_sec设置为10000（应该足够高）
  • icmp_msgs_burst设置为5000（足够高）

它对我没有帮助，我看到了相同的行为，随机超时。我没有弄乱icmp_ratemask，因为我不完全了解如何Time Exceeded从限制中排除。

最后，问题是：

  1. 如果您熟悉此类traceroute问题，您是如何解决的？
  2. 如果您熟悉上面提到的内核设置，那么“足够好”的值是什么？
  3. 正确的修改方法是什么，icmp_ratemask以不限制Time Exceeded消息并使traceroute工作顺利进行？
  4. 另外，更改这些（或任何相关）设置时是否存在安全漏洞？我不想遭受 DoS 攻击，也不想成为任何人的 DDoS 攻击源。

答案1

作为控制平面策略的一部分，ICMP 探测大多被忽略。如果您想要获得更全面的指标和趋势、历史数据，我建议使用专用的本地 smokeping 实例。

相关内容