在同一子网中的两个节点之间运行时，我遇到了以下问题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这种方式是否是测试网络可靠性的可行方法？
