主页 / unix / 问题 / 783243
Accepted
MMAX
Asked: 2024-09-09 22:36:09 +0800 CST

traceroute (UDP) 丢失数据包

  • 772

在同一子网中的两个节点之间运行时，我遇到了以下问题traceroute。这样做是为了测试这两个节点之间的网络连接是否可靠。一家知名数据库供应商的支持团队建议我们使用这种方法。

运行该命令时： traceroute -s 10.1.3.205 -r 10.1.3.210 随机有数据包未收到，并且没有报告 RTT：

traceroute to 10.1.3.210 (10.1.3.210), 30 hops max, 60 byte packets
 1  10.1.3.210 (10.1.3.210)  0.152 ms  0.064 ms *

相反，运行带有 ICMP: 选项的 traceroutetraceroute -I -s 10.1.3.205 -r 10.1.3.210是可靠的，并且不会发生丢失数据包的情况。

在我们的环境中，多个 Linux 系统上都发现了同样的问题，这些系统具有不同的补丁级别、不同的 traceroute 版本，无论系统是虚拟机还是物理系统。

为了简化和更容易读取 tcpdump，我尝试使用以下命令：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done

输出如下：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.203 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.071 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.075 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  *
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.142 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.054 ms

每 7 个数据包都没有响应，这种情况是可以重现的。现在，支持团队最终确定我们的网络设置中存在此数据包丢失问题。

运行相同的循环，延迟 1 秒，所有 10 个数据包均被发送和接收：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; sleep 1; done

我有点怀疑这种测试网络可靠性的方式是否正确，因为通常使用 traceroute 来监控路由连接上的网络路径。

我尝试使用 SAP 进行了几个小时的网络连接测试niping，没有发现丢失的连接。

那么我是否遗漏了什么明显的内容？使用traceroute这种方式是否是测试网络可靠性的可行方法？

tcpdump

2 个回答

  1. 正如 Steffen所说，traceroutetraceroute 并不是适合这项工作的工具，因为它的错误检测和报告根本无法胜任这项工作。因此，请代我们向 DB 供应商团队问好，并告诉他们其他管理员说，虽然 traceroute 是检测从源到目标是否存在路由的好工具，但它对于诊断单个子网中的 UDP 可靠性问题没有帮助。

    这是因为网络负载很小，所以造成的网络负载是其两倍traceroute。如果你想弄清楚你的网络是否在数据库负载很高的情况下丢失 UDP 数据包，它甚至不会尝试加载网络。

    诊断丢包可能是您希望与运行网络的人员一起做的事情，但对于第一次负载测试，您可以使用iperf，就像在客户端计算机上一样：

    RATE_BITS_PER_SEC=10m
SERVER=10.1.3.210
CLIENT=10.1.3.205
iperf -c ${SERVER} -B ${CLIENT} -i 1 -u -b ${RATE_BYTES_PER_SEC}

    服务器也是如此：

    iperf -s -i 1 -w 4M -u

    如果 10 Mb/s 有效，那么您可以增加变量RATE_BITS_PER_SEC，直到您的服务器开始打印数字，表明您丢失了数据包。这必须在某个时候发生，即当您超过线速时，问题是您有多接近这个速度。

    • 5
  2. Best Answer

    基于 UDP 的跟踪路由需要 ICMP TTL 超出消息来查明路由器是否丢弃了具有特定 TTL 的数据包。发送 ICMP TTL 超出消息通常存在速率限制，有时这些消息根本不会发送，或者中间系统会阻止 ICMP/限制速率。

    因此，traceroute 不是用于测试网络丢包可靠性的有用工具。该工具从未用于此目的。使用适当的知识，traceroute 可能用于查找网络中可能影响可靠性的奇怪事物，但它不是通用的可靠性测试工具。

    • 4

相关问题