突发情况下数据包丢失率非常高

Question 1

我认为这是 hetzner 的错。关于类似的案件，我已经与他们争论了很长时间。

我们遇到了这些问题，并向托管公司报告了这个问题。答案总是相同的 - “请将 mtr 连接到两个方向” - 即使在故障期间他们也会这样回答。所以我们确实编写了一个守护进程，每次服务器之间出现任何数据包丢失时都会启动 mtr：

如果 [ -z $1 ] ; 那么
                echo “给出目标主机”
别的
                主机=$1
                while true ; 执行
                                损失 =`ping -c 10 $host | grep 数据包 | awk {'打印 $6'} | sed s/%//g`
                                如果 [ $loss -ge 1 ]; 那么
                                                echo `日期` >> /root/scripts/loss_measure_mtr.log
                                                mtr -s 1500 -r -c 1000 -i 0.1 $host >> /root/scripts/loss_measure_mtr.log
                                菲

                完毕


菲

然后他们根据这些信息回答道：

此时子网中发生了传入攻击。在这种情况下
同一子网内的服务器可能发生数据包丢失。

此致

迈克尔·斯特雷茨

Hetzner 在线股份公司
支持
90431 纽伦堡 / 德国
电话：+49 (911) 234 226 54
传真：+49 (911) 234 226 8 977
http://www.hetzner.de

到底发生了什么？我不知道，但看起来几乎一样：

2012 年 8 月 12 日 星期日 01:13:20 CEST
主机：应用程序损失率 Snt 最后平均值 最佳 Wrst 标准差
  1. 94.1% 1000 0.2 0.2 0.1 0.4 0.1
  2. 静态.1.24.24.46.客户端.您 0.0% 1000 3.0 1.9 0.7 19.4 1.5
  3. hos-tr4.juniper2.rz13.hetzne 9.4% 1000 0.6 1.9 0.4 133.2 8.0
  4. hos-bb2.juniper1.rz1.hetzner 5.4% 1000 38.6 7.1 3.0 112.9 11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de 10.9% 1000 4.4 5.1 3.6 23.6 1.8**
  6. 静态.88-128-24-108.客户端 15.5% 1000 3.6 3.5 3.4 4.6 0.1
主机：应用程序损失率 Snt 最后平均值 最佳 Wrst 标准差
  1. 94.5% 1000 0.2 0.2 0.1 0.6 0.1
  2. 静态.1.24.24.46.客户端.您 0.0% 1000 1.2 1.9 0.7 19.3 1.6
  3. hos-tr4.juniper2.rz13.hetzne 9.3% 1000 0.6 1.8 0.4 136.8 7.9
  4. hos-bb2.juniper1.rz1.hetzner 2.7% 1000 3.3 7.0 3.0 113.1 11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de 8.5% 1000 7.0 5.1 3.6 26.8 2.0
  6. 静态.88-128-24-108.客户端 12.8% 1000 3.6 3.5 3.3 4.5 0.1

我有几十个这样的mtr。

我认为是他们的基础设施问题。请注意节点上发生了丢失：hos-tr1.ex3k3.rz1.hetzner.de，hos-tr4.juniper2.rz13.hetzner.de等等。

如果他们不解决这个问题，我可能会迁移到 linode 或 amazon。

Answer

我认为这是 hetzner 的错。关于类似的案件，我已经与他们争论了很长时间。

我们遇到了这些问题，并向托管公司报告了这个问题。答案总是相同的 - “请将 mtr 连接到两个方向” - 即使在故障期间他们也会这样回答。所以我们确实编写了一个守护进程，每次服务器之间出现任何数据包丢失时都会启动 mtr：

如果 [ -z $1 ] ; 那么
                echo “给出目标主机”
别的
                主机=$1
                while true ; 执行
                                损失 =`ping -c 10 $host | grep 数据包 | awk {'打印 $6'} | sed s/%//g`
                                如果 [ $loss -ge 1 ]; 那么
                                                echo `日期` >> /root/scripts/loss_measure_mtr.log
                                                mtr -s 1500 -r -c 1000 -i 0.1 $host >> /root/scripts/loss_measure_mtr.log
                                菲

                完毕


菲

然后他们根据这些信息回答道：

此时子网中发生了传入攻击。在这种情况下
同一子网内的服务器可能发生数据包丢失。

此致

迈克尔·斯特雷茨

Hetzner 在线股份公司
支持
90431 纽伦堡 / 德国
电话：+49 (911) 234 226 54
传真：+49 (911) 234 226 8 977
http://www.hetzner.de

到底发生了什么？我不知道，但看起来几乎一样：

2012 年 8 月 12 日 星期日 01:13:20 CEST
主机：应用程序损失率 Snt 最后平均值 最佳 Wrst 标准差
  1. 94.1% 1000 0.2 0.2 0.1 0.4 0.1
  2. 静态.1.24.24.46.客户端.您 0.0% 1000 3.0 1.9 0.7 19.4 1.5
  3. hos-tr4.juniper2.rz13.hetzne 9.4% 1000 0.6 1.9 0.4 133.2 8.0
  4. hos-bb2.juniper1.rz1.hetzner 5.4% 1000 38.6 7.1 3.0 112.9 11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de 10.9% 1000 4.4 5.1 3.6 23.6 1.8**
  6. 静态.88-128-24-108.客户端 15.5% 1000 3.6 3.5 3.4 4.6 0.1
主机：应用程序损失率 Snt 最后平均值 最佳 Wrst 标准差
  1. 94.5% 1000 0.2 0.2 0.1 0.6 0.1
  2. 静态.1.24.24.46.客户端.您 0.0% 1000 1.2 1.9 0.7 19.3 1.6
  3. hos-tr4.juniper2.rz13.hetzne 9.3% 1000 0.6 1.8 0.4 136.8 7.9
  4. hos-bb2.juniper1.rz1.hetzner 2.7% 1000 3.3 7.0 3.0 113.1 11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de 8.5% 1000 7.0 5.1 3.6 26.8 2.0
  6. 静态.88-128-24-108.客户端 12.8% 1000 3.6 3.5 3.3 4.5 0.1

我有几十个这样的mtr。

我认为是他们的基础设施问题。请注意节点上发生了丢失：hos-tr1.ex3k3.rz1.hetzner.de，hos-tr4.juniper2.rz13.hetzner.de等等。

如果他们不解决这个问题，我可能会迁移到 linode 或 amazon。

Question 2

这不是一个答案，但它太长了，无法作为评论，因此我将其作为答案发布。

我不完全同意现有答案中的评估和对这个问题的一些评论。

使用任何通过 ping 和 traceroute 使用 ICMP 的工具（如果我理解它的工作原理的话，比如 mtr）的问题在于，该工具正在测试路径中的每一跳如何响应 ICMP 流量，这意味着测试被发送到每一跳，然后测量该跳的响应。这不是对路径中每一跳的路径质量的真正测试，这意味着它没有测试通过路径的“真实”流量的传输。每一跳都可能选择为基于 ICMP 的测试提供低优先级，或者它可能完全放弃它，因此从一跳到下一跳的结果会有所不同。如果您在第 10 跳处遇到真正的问题（在您的第一个屏幕截图中），那么该问题将延续（并累积）在每个连续的跳跃中。正如您在屏幕截图中看到的那样，第 10 跳显示 39% 的数据包丢失，但第 11 跳几乎没有显示数据包丢失。如果第 10 跳真的丢弃了“真实”流量，那么问题也会在跳 11 跳处出现。事实上，跳 11 可能会显示更多的数据包丢失（跳 10 处的丢失、跳 10 和 11 之间的链路上的丢失以及跳 11 处的丢失的累计）。

您应该做的是使用从一端到另一端发送真实流量的工具（如 iperf）进行测试。

Answer

这不是一个答案，但它太长了，无法作为评论，因此我将其作为答案发布。

我不完全同意现有答案中的评估和对这个问题的一些评论。

使用任何通过 ping 和 traceroute 使用 ICMP 的工具（如果我理解它的工作原理的话，比如 mtr）的问题在于，该工具正在测试路径中的每一跳如何响应 ICMP 流量，这意味着测试被发送到每一跳，然后测量该跳的响应。这不是对路径中每一跳的路径质量的真正测试，这意味着它没有测试通过路径的“真实”流量的传输。每一跳都可能选择为基于 ICMP 的测试提供低优先级，或者它可能完全放弃它，因此从一跳到下一跳的结果会有所不同。如果您在第 10 跳处遇到真正的问题（在您的第一个屏幕截图中），那么该问题将延续（并累积）在每个连续的跳跃中。正如您在屏幕截图中看到的那样，第 10 跳显示 39% 的数据包丢失，但第 11 跳几乎没有显示数据包丢失。如果第 10 跳真的丢弃了“真实”流量，那么问题也会在跳 11 跳处出现。事实上，跳 11 可能会显示更多的数据包丢失（跳 10 处的丢失、跳 10 和 11 之间的链路上的丢失以及跳 11 处的丢失的累计）。

您应该做的是使用从一端到另一端发送真实流量的工具（如 iperf）进行测试。

突发情况下数据包丢失率非常高

答案1

答案2

相关内容