Osheep

时光不回头,当下最重要。

如何用 MTR 诊断网络问题?(下)

原文发表于:如何用 MTR 诊断网络问题?—下篇

如何用 MTR 诊断网络问题?(上)我们了解了什么是 MTR,以及如何生成一份报告等知识。这里,我们深入分析一下 MTR 报告的含义,以及常见的 MTR 结果分析。

分析 MTR 报告

验证数据包丢失

在分析 MTR 输出时,您正在寻找两件事情:丢包和延迟。首先让我们来谈谈丢包。如果您在任何特定跳点看到一定百分比的丢失,这可能表明该特定路由器存在问题。然而,一些服务提供商通常的做法是限制 MTR 使用的ICMP流量。这实际上没有损失可以给出丢包的错觉。要确定您看到的损失是真实的还是由于速率限制,请查看随后的一跳,如果该跳丢包率是0.0%,那么您可以确定您看到 ICMP 速率限制,而不是实际丢包。参见下面的例子:

root@localhost:~# mtr –report www.google.com

HOST: example              Loss%  Snt  Last  Avg  Best  Wrst StDev

1. 63.247.74.43                  0.0%    10    0.3  0.6  0.3  1.2  0.3

2. 63.247.64.157                50.0%    10    0.4  1.0  0.4  6.1  1.8

3. 209.51.130.213                0.0%    10    0.8  2.7  0.8  19.0  5.7

4. aix.pr1.atl.google.com        0.0%    10    6.7  6.8  6.7  6.9  0.1

5. 72.14.233.56                  0.0%    10    7.2  8.3  7.1  16.4  2.9

6. 209.85.254.247                0.0%    10  39.1  39.4  39.1  39.7  0.2

7. 64.233.174.46                0.0%    10  39.6  40.4  39.4  46.9  2.3

8. gw-in-f147.1e100.net          0.0%    10  39.6  40.5  39.5  46.7  2.2

在这种情况下,第一跳和第二跳之间报告的丢包可能是由于第二跳速率限制。虽然剩下的八跳的流量都触及第二跳,但是没有丢包。如果丢失持续多于一个跳,则可能存在一些丢包或路由问题。请记住,速率限制和丢失可能同时发生。在这种情况下,将序列中的最低损失百分比作为实际损失。例如,考虑以下输出:

root@localhost:~# mtr –report www.google.com

HOST: localhost                  Loss%  Snt  Last  Avg  Best  Wrst StDev

1. 63.247.74.43                  0.0%    10    0.3  0.6  0.3  1.2  0.3

2. 63.247.64.157                  0.0%    10    0.4  1.0  0.4  6.1  1.8

3. 209.51.130.213                60.0%    10    0.8  2.7  0.8  19.0  5.7

4. aix.pr1.atl.google.com        60.0%    10    6.7  6.8  6.7  6.9  0.1

5. 72.14.233.56                  50.0%  10    7.2  8.3  7.1  16.4  2.9

6. 209.85.254.247                40.0%  10  39.1  39.4  39.1  39.7  0.2

7. 64.233.174.46                40.0%  10  39.6  40.4  39.4  46.9  2.3

8. gw-in-f147.1e100.net          40.0%  10  39.6  40.5  39.5  46.7  2.2

在这种情况下,您会看到跳数2和3之间以及跳数3和4之间的损失为60%。您可以假设第三跳和第四跳可能会丢失一定数量的流量,因为后续的主机报告零损失。然而,一些损失是由于速率限制,因为几个最终的跳数只有40%的损失。报告不同数量的损失时,请始终信任来自后期的报告。

一些损失也可以通过返回路线中的问题来解释。数据包将无错误地到达目的地,但很难做出回程。这在报告中很明显,但可能难以从 MTR 的输出中推断出来。因此,当您遇到问题时,通常最好双向收集 MTR 报告。

另外,抵制调查或报告您的连接中所有丢包发生的诱惑。互联网协议被设计为对一些网络退化具有弹性,并且数据跨 Internet 的路由可以响应于负载,简短的维护事件和其他路由问题而波动。如果您的 MTR 报告显示10%附近的少量损失,则没有任何理由引起真正的关注,因为应用层将补偿可能短暂的丢包。

了解网络延迟

除了帮助您评估数据包丢失之外,MTR 还将帮助您评估主机与目标主机之间的连接延迟。由于物理限制,延迟总是随着路由中的跳数而增加。但是,增幅应该是一致和线性的。不幸的是,延迟通常是相对的,并且非常依赖于主机连接的质量和它们的物理距离。在评估可能存在问题的连接的地铁报告时,除了在给定区域内的其他主机之间的已知连接速度之外,还可以将早期的全功能报告视为上下文。

连接质量也可能会影响特定路由的延迟时间。可以预见的是,拨号连接将比同一目的地的电缆调制解调器连接具有更高的延迟。考虑以下地铁报告显示高延迟:

root@localhost:~# mtr –report www.google.com

HOST: localhost                  Loss%  Snt  Last  Avg  Best  Wrst StDev

1. 63.247.74.43                  0.0%    10    0.3  0.6  0.3  1.2  0.3

2. 63.247.64.157                0.0%    10    0.4  1.0  0.4  6.1  1.8

3. 209.51.130.213                0.0%    10    0.8  2.7  0.8  19.0  5.7

4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7  0.2

5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7  0.2

6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7  0.4

7. 64.233.174.46                0.0%    10  391.8 360.4 342.1 396.7  2.1

8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7  1.2

跳数在跳数3和4之间显着跳跃,并保持高电平。这可能指向网络延迟问题,因为在第四跳之后的往返时间保持较高。从这个报告来看,不可能确定原因,尽管饱和的对等会话,配置不良的路由器或拥塞的链路是比较频繁的原因。

不幸的是,高延迟并不总是意味着当前路由的问题。像上面这样的报告意味着,尽管第四跳有某种问题,但流量仍然到达目的地主机并返回到源主机。延迟可能是由于返回路线的问题引起的。您的 MTR 报告中不会显示返回路由,并且数据包可以采取与特定目的地完全不同的路由。

在上面的例子中,虽然主机3和4之间的延迟有很大的跳跃,但延迟在任何后续跳都不会异常增加。从这一点来说,假设第四个路由器有一些问题是合乎逻辑的。

ICMP 速率限制还可以产生类似延迟的现象,类似于它可以产生类似丢包的现象。请考虑以下示例:

root@localhost:~# mtr –report www.google.com

HOST: localhost                  Loss%  Snt  Last  Avg  Best  Wrst StDev

1. 63.247.74.43                  0.0%    10    0.3  0.6  0.3  1.2  0.3

2. 63.247.64.157                0.0%    10    0.4  1.0  0.4  6.1  1.8

3. 209.51.130.213                0.0%    10    0.8  2.7  0.8  19.0  5.7

4. aix.pr1.atl.google.com        0.0%    10    6.7  6.8  6.7  6.9  0.1

5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4  2.9

6. 209.85.254.247                0.0%    10  39.1  39.4  39.1  39.7  0.2

7. 64.233.174.46                0.0%    10  39.6  40.4  39.4  46.9  2.3

8. gw-in-f147.1e100.net          0.0%    10  39.6  40.5  39.5  46.7  2.2

乍看之下,跳数4和5之间的延迟引起了关注。然而,在第五跳之后,潜伏期急剧下降。这里测量的实际延迟约为40ms。在这种情况下,中期审查提请注意不影响服务的问题。在评估 MTR 报告时,考虑到最后一跳的延迟。

解决您的 MTR 报告中确定的路由和网络问题

审查报告显示的大部分路由问题是暂时的。大多数问题将在24小时内自行清理。在大多数情况下,当您能够注意到路由问题时,Internet服务提供商的监控已经报告了问题,管理员正在努力解决问题。如果您在长时间内遇到劣化服务的情况,您可以选择向提供商提醒您遇到的问题。联系服务提供商时,可以发送MTR 报告和您可能拥有的任何其他相关数据。

点赞