技术分享

在Mac OS X中安装mtr诊断路由

下载地址

http://rudix.org/packages/mtr.html(在园子里下载)

下载后运行

mtr-0.85-0.pkg进行安装

$ cd /usr/local/sbin ,就会看mtr文件。

运行mtr出现提示

-bash: mtr: command not found

解决方法:

$ alias mtr=/usr/local/sbin/mtr

继续运行mtr出现提示

mtr: unable to get raw sockets.

解决方法:

$ sudo chown root mtr
$ sudo chmod u+s mtr

运行mtr进行诊断

$ Mtr luymm.com

理解

当我们研究 MTR 报告时候,最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外,MTR 在它的七列数据中提供了很多有价值的数据统计报告。 Loss% 列展示了数据包在每一跳的丢失率。 Snt 列记录的多少个数据包被送出。 使用 –report 参数默认会送出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,目的地是您的 Linode VPS,一般前三跳属于您的本地 ISP,后三跳属于 Linode 数据中心这边的。中间的条数是属于中间节点的。当您在本地运行 MTR,如果您在前几跳发现异常,请联系您本地的 ISP 服务提供商。相反,如果您在接近目的地的几跳发现问题,请联系您目的地的服务器提供商(例如:Linode)。如果您的问题出现在中间几跳,很不幸,两边的服务提供商的能力有限,可能不能完全为您解决问题喽。
分析 MTR 报告
核查数据包的丢失
当分析 MTR 的输出时,您需要注意两点: loss 和 latency。首先,让我们讨论一下 loss。如果您在任何一跳上看到 loss 的百分比,这就说明这一跳上可能有问题了。当然,很多服务提供商人为限制 ICMP 发送的速率,这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输 还是确定有丢包的现象?我们需要查看下一跳。如果下一跳没有丢包现象,说明上一条是人为限制的。如下示例:
root@meiriyitie.com:~# 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
在此例中,第二跳发生了丢包现象,但是接下来几条都没任何丢包现象,说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包,那就可能是第二跳有问题了。请记住,ICMP 包的速率限制和丢失可能会同时发生。如果发生包的丢失情况,我们要用最低百分比来衡量时间情况。为什么这么说呢?请看如下示例:
root@meiriyitie.com:~# 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
在这个例子中,您可以看打 第3跳和第4跳都有 60% 的丢包率,从接下来的几跳都有丢包现象,所以不像是人为限制 ICMP 速率的原因。但是最后几跳都是40%的丢包率,我们可以猜测到60%的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以,当我们看到不同的丢包率时,通常要以最后几跳为准。
还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机,但是返回过程中遇到“困难”了。所以,当问题发生后,我们通常需要收集反方向的 MTR 报告。
此外,互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率,当出现短暂的10%丢包率时候,不必担心,应用层的程序会弥补这点损失。
读懂网络延迟
除了可以通过 MTR 报告看到丢包率,我们还可以看到本地到目的主机之间的延时。因为不同的物理位置,延迟通常随着跳数的增加而增加。所以,延迟通常取决于节点之间的物理距离和线路质量。
例如,在同样的传输距离下,dial-up连接比cable modem连接有更大的延迟。如下示例中显示 MTR 报告:
root@meiriyitie.com:~# 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
在这份报告中,从第三跳到第四跳的延迟猛增,直接导致了后面的延迟也很大。这可能是因为第四跳的路由器配置不当,或者线路很拥堵的原因。
然而,高延迟并不一定意味着当前路由器有问题。这份报告虽然看到第四跳有点问题,但是数据仍然可以正常达到目的主机并且返回给主机。延迟很大的原因也有可能是在返回过程中引发的。我这份报告我们看不到返回的路径,返回的路径可能是完全不同的线路,所以我们一般要进行双向测试了。
ICMP 速率限制也可能会增加延迟,如下:
root@meiriyitie.com:~# 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跳直接的延迟很大。但是第5跳之后,延迟又恢复正常了。最后的延迟差不多为 40ms。像这种情况,是不影响实际情况的。因为可能仅仅是第5跳设备限制了 ICMP 传输速率的原因。所以我们一般要用最后一跳的实际延迟为准。
常见的 MTR 报告类型
很多网络问题十分麻烦,并且需要上级网络提供商来帮助。然而,这里有很多常见的 MTR 报告所描述的网络问题。如果您正在经历一些网络问题,并且想诊断出原因,可以参考如下示例:
目的主机网络配置不当
在下面这个例子中,数据包在目的地出现了 100% 的丢包。乍一看是数据包没有到达,其实未必,很有可能是路由器或主机配置不当。
root@meiriyitie.com:~# 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    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         100.0    10    0.0   0.0   0.0   0.0   0.0
MTR 报告数据包没有到达目的主机是因为目的主机没有发送任何应答。这可能是目的主机防火墙的原因,例如: iptables 配置丢掉 ICMP 包所致。
家庭或办公室路由器的原因
有时候家庭路由器的原因导致 MTR 报告看起来有点误导。
% mtr --no-dns --report google.com
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5
不要为 100% 的丢包率所吓到,这并不表明这里有问题。你可以看打在接下来几跳是没有任何丢包的。
运营商的路由器没有正确配置
有时候您的运营商的路由器配置原因,导致 ICMP 包永远不能到达目的地,例如:
root@meiriyitie.com:~# 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. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
当没有额外的路由信息时,将会显示问号(???),下面例子也一样:
root@meiriyitie.com:~# 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. 172.16.29.45                 0.0%    10    0.0   0.0   0.0   0.0   0.0
   6. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   7. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   8. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   9. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
  10. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
有时候,一个错误配置的路由器,将会在一个环路中不断发送数据包,如下:
root@meiriyitie.com:~# 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. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
通过报告可以看打第4跳的路由器没有正确配置。如果这种状况发生了,您可以连接当地的网络管理员或ISP解决问题。
ICMP 速率限制
ICMP 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失,但是下面几条都正常,我们可以判断是 ICMP 速率限制的原因。如下:
root@meiriyitie.com:~# 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                 60.0%    10   27.2  25.3  23.1  26.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
这种状况是没关系的。ICMP 速率限制是一种常见的手段,这样可以减少网络数据的负载,让更重要的流量先通过。
超时
在很多种情况下会发生超时现象。例如:很多路由器可能会直接丢弃 ICMP 包,这时就会导致超时(???)。
另外,也有可能在数据返回的路上出现了问题。
root@meiriyitie.com:~# 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. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. ???                           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
超时不一定是数据包被丢失。如上例,数据包还是安全的到达目的地并且返回。中间节点的超时可能是路由器配置丢弃 ICMP 包,或者 QoS 设置引起的原因,这个是没关系的。
根据您的 MTR 报告解决路由和网络问题
MTR 报告显示的路由问题大都是暂时性的。很多问题在24小时内都被解决了。大多数情况下,如果您发现了路由问题,ISP 提供商已经监视到并且正在解决中了。当您经历网络问题后,可以选择提醒您的 ISP 提供商。当联系您的提供商时,需要发送一下 MTR 报告和相关的数据。没有有用的数据,提供商是没有办法去解决问题的。
然而大多数情况下,路由问题是比较少见的。比较常见的是因为物理距离太长,或者上网高峰,导致网络变的很慢。尤其是跨越大西洋和太平洋的时候,网络有时候会变的很慢。这种情况下,建议您选择 VPS 的物理距离尽量接近您的目标客户。
如果您遇到网络连接问题,并且不能解读 MTR 报告,您可以打开一个支持工单提交问题,Linode 工作人员会帮您分析报告。

微信扫一扫,向我赞赏

微信扫一扫,向我赞赏

微信扫一扫,向我赞赏

支付宝扫一扫,向我赞赏

file-1569295332.jpg

回复

This is just a placeholder img.