网络排查命令 MTR

文章

林里克斯

1768字数

Linux

mtr 命令是一个集合 ping 和 traceroute 功能并能直观显示结果的网络诊断工具

实验平台：CentOS 7.7.1908
mtr 版本：mtr 0.85

一、介绍说明
二、安装介绍
三、使用介绍
四、MTR结果分析

一、介绍说明

1.简介
traceroute 默认使用 UDP 数据包探测，而 mtr 默认使用 ICMP 报文探测.

mtr 命令是 Linux 中有一个非常棒的网络连通性判断工具，它结合了 ping, traceroute , nslookup 的相关特性.全称: my traceroute.适配多平台(Windows、Linux、IOS、Android)后续会介绍每个平台的安装方法

参数详情：

-p      #将每次追踪的结果分别列出来
-n 或 no-dns #不对IP地址做域名解析
-s      #用来指定ping数据包的大小
-a      #设置发送数据包的IP地址。用于主机有多个IP时
-4      #使用IPv4协议
-6      #使用IPv6协议
-i      #使用这个参数来设置ICMP返回之间的要求默认是1秒
-r      #已报告模式显示(默认只会发送10个数据包，需调整数量使用 -c)
-c      #每秒发送多少包，默认为10个。英文是(–report-cycles COUNT)
-v      #显示版本号

命令内参数详情：

$ mtr
My traceroute  [v0.85]
VM_10_8_centos (::)                                                                               Fri Jul 31 23:32:31 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                  Packets               Pings
 Host                                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. localhost                                                                    0.0%    20    0.0   0.0   0.0   0.1   0.0

#? 或 h   #显示帮助
d         #切换显示模式
n         #切换启用或禁用DNS域名解析
u         #切换使用ICMP或UDP数据包进行探测
q         #退出

二、安装介绍

1.Windows
BestTrace 工具（需安装）：

https://cdn.ipip.net/17mon/besttrace.exe

GitHub（免安装）

https://github.com/oott123/WinMTR/releases

2.Linux （本文主要演示）

Debian/Ubuntu 系统
$ apt install mtr
RedHat/CentOS 系统
$ yum install mtr

3.IOS

App Store 直接安装 Best NetTools

4.Android

安装 TracePing

三、使用介绍

1.基本用法

$ mtr www.qq.com

 My traceroute  [v0.85]
VM_10_8_centos (0.0.0.0)                                                                          Fri Jul 31 23:41:59 2020
Resolver error: No error returned but no answers given. of fields   quit
                                                                                  Packets               Pings
 Host                                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 - 100.98.95.129                                                                5.7%    53    1.4   1.4   1.2   1.8   0.0
 - 100.98.115.236                                                               5.7%    53    1.2   0.8   0.6   1.8   0.0
 - 10.196.72.57                                                                 0.0%    53    0.7   0.7   0.5   1.0   0.0
 - 10.196.5.85                                                                  0.0%    53    0.9   1.2   0.7  12.5   1.6
 - 10.162.5.179                                                                 0.0%    53    7.7   2.2   1.0  16.1   3.0
 - 58.144.255.233                                                               0.0%    53    1.2   2.1   1.1  19.8   2.6
 - 113.207.25.173                                                               0.0%    53   13.7  11.8   7.7  15.3   2.2
 - 219.158.21.241                                                              54.7%    53   37.9  34.6  30.3  38.0   2.1
 - 112.97.0.194                                                                92.2%    52   40.3  39.4  38.2  40.8   1.0
 - ???
 - ???
 - ???
 - 10.162.116.129                                                              94.1%    52   31.0  29.6  28.8  31.0   1.0
 - ???
 - 10.162.112.177                                                              98.0%    50   25.5  25.5  25.5  25.5   0.0
 - ???
 - ???
 - 58.250.137.36                                                                0.0%    19   35.0  35.0  35.0  35.0   0.0
#第一列（Host）：节点IP地址和域名。如前面所示，按n键可以切换显示
#第二列（Loss%）：节点丢包率
#第三列（Snt）：每秒发送数据包数。默认值是10，可以通过参数“-c”指定
#第四列（Last）：最近一次的探测延迟值
#第五列（Avg）：探测延迟的平均值
#第六列（Best）：探测延迟的最小值
#第七列（Wrst）：探测延迟的最大值
#第八列（StDev）：标准偏差。越大说明相应节点越不稳定

一般情况下 mtr 前几跳都是本地 ISP，后几跳属于服务商如（腾讯云、阿里云），中间跳数则是中间节点，如果发现前几跳异常，需要联系本地 ISP 服务提供上，相反如果后几跳出现问题，则需要联系服务提供商，中间几跳出现问题，则需要联系运营商进行处理

四、MTR结果分析

当我们分析 MTR 报告时候，最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外，MTR 在它的七列数据中提供了很多有价值的数据统计报告。 Loss% 列展示了数据包在每一跳的丢失率。 Snt 列记录的多少个数据包被送出。使用 –r 参数默认会送出 10 个数据包。如果使用 –report-cycles=[number-of-packets] 选项，MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间，使用的是毫秒（ ms ）单位表示。 Last 表示最后一个数据包所用的时间，Avg 表示平均时间， Best 和 Wrst 表示最小和最大时间。在大多数情况下，平均时间 Avg 列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高，说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点，或者测量数据受到某些问题的干扰。

例如，如果标准偏差很大，说明数据包的延迟是不确定的。一些数据包延迟很小（例如：25ms），另一些数据包延迟很大（例如：350ms）。当 10 个数据包全部发出后，得到的平均延迟可能是正常的，但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高，使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下，您可以把 MTR 的输出分成三大块。根据配置，第二或第三跳一般都是 本地 ISP，倒数第二或第三跳一般为目的主机的 ISP。中间的节点是数据包经过的路由器。

当分析 MTR 的输出时，需要注意两点： loss 和 latency。

网络丢包

如果在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输还是确定有丢包的现象？此时需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的

$ mtr -r www.baidu.com

Start: Fri Jul 31 23:59:17 2020
HOST: VM_10_8_centos              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 100.98.95.130              0.0%    10    1.4   1.4   1.4   1.6   0.0
  2.|-- 100.98.119.238            20.0%    10    0.7   0.8   0.6   1.4   0.0
  3.|-- 10.196.72.37               0.0%    10    0.6   0.8   0.5   1.5   0.0
  4.|-- 10.196.5.69                0.0%    10    0.8   1.0   0.8   2.6   0.3
  5.|-- 10.162.5.180               0.0%    10    1.2   1.3   1.2   2.1   0.0
  6.|-- 219.153.118.121            0.0%    10    1.4   1.3   1.3   1.4   0.0
  7.|-- 222.176.80.73              0.0%    10    2.4   2.7   1.8   7.2   1.5
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- 113.96.5.126               0.0%    10   28.9  28.9  28.8  29.1   0.0
 10.|-- 113.96.4.209               0.0%    10   31.2  32.3  31.1  35.0   1.2
 11.|-- 98.96.135.219.broad.fs.gd 20.0%    10   33.3  53.6  32.5 197.4  58.1
 12.|-- 14.29.121.206              0.0%    10   49.6  35.9  34.3  49.6   4.8
 13.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- 14.215.177.39              0.0%    10   26.3  26.3  26.3  26.4   0.0

在此例中，第 2 跳发生了丢包现象，但是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包，那就可能是第二跳有问题了。请记住，ICMP 包的速率限制和丢失可能会同时发生。

Loss%（丢包率）的判断

任一节点的 Loss%（丢包率） 如果不为零，则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有两种。

运营商基于安全或性能需求，人为限制了节点的 ICMP 发送速率，导致丢包。

节点确实存在异常，导致丢包。

可以结合异常节点及其后续节点的丢包情况，来判定丢包原因。

如果随后节点均没有丢包，则通常说明异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。如前文链路测试结果示例图中的第2跳所示。

如果随后节点也出现丢包，则通常说明异常节点确实存在网络异常，导致丢包。如前文链路测试结果示例图中的第5跳所示。

另外，需要说明的是，前述两种情况可能同时发生。即相应节点既存在策略限速，又存在网络异常。对于这种情况，如果异常节点及其后续节点连续出现丢包，而且各节点的丢包率不同，则通常以最后几跳的丢包率为准。如前文链路测试结果示例图所示，在第 5、6、7跳均出现了丢包。所以，最终丢包情况，以第7跳的40%作为参考。

关于延迟延迟跳变

如果在某一跳之后延迟明显陡增，则通常判断该节点存在网络异常。如前文链路测试结果示例图所示，从第5跳之后的后续节点延迟明显陡增，则推断是第5跳节点出现了网络异常。不过，高延迟并不一定完全意味着相应节点存在异常。如第5跳之后，虽然后续节点延迟明显陡增，但测试数据最终仍然正常到达了目的主机。所以，延迟大也有可能是在数据回包链路中引发的。所以，最好结合反向链路测试一并分析。

Over ~