用ping ，mtr ，traceroute 进行网络丢包分析

转自 https://blog.csdn.net/hankerzero/article/details/67062617 

一、丢包原因

　　网络丢包原因很多，但是一般都是链路问题：

• 骨干拥塞

• 链路某个交换机背板坏了

• 交换机负载不均导致

  　　此外，还有主机本身原因：

• 系统CPU负载高，数据包到网卡后CPU不能及时处理，但是缓冲区溢出，从而丢包。

• 网卡故障 
  　　丢包时一般先分析下网络层面的，主机本身的还是原因较少的

二、丢包分析方法及步骤

2.1 丢包分析工具

• ping

  ping -c 400 -i 0.01 -s 1024 -f

• mtr

  mtr -c 400 -i 0.1 -n -r

• traceroute

  traceroute -n

2.2 分析方法

　　一般对丢包IP之间做ping、mtr、traceroute测试，对于十分明显的，可以很容易分析出丢包点在哪里。但是对于故障现象不明显的我们可以做以下测试： 
1、抓包：从源IP ping 目的IP，然后在源端抓reply包，在目的端抓request包 
　　a)如果目的端抓到的request包少于400（目的端收到的请求包少于400，源端收到的reply包肯定少于400），则重点关注源端到目的端的mtr和traceroute图 
　　b)如果目的端收到的request包为400，但是源端收到的reply包少于400，则重点关注从目的端到源端的mtr和traceroute图 
　　c) 如果我在对端抓包，抓不到任何数据包，这种情况一般是数据包在中间路径就丢了。此时对比MTR分析，可以很明显的看到路径是不完整的或者是有回路。 
　　抓包小技巧：因为我们测试一般是在监控机测试，但是作为监控机，一定会收到大量的ICMP包，对抓包会造成影响。为了避免这种影响，我们可以为发送的数据包指定伊特特殊的长度，比如1016。此时的表达式为：

tcpdump -i eth1 -n -vv -p icmp and src host IPADD | grep “length 1024”

这里为什么时1024字节了？因为需要加上8字节的头部，所以是1016+8=1024

2、路由对比

　　对比两个IDC之间的丢包路由图和不丢包的路由图，查看路径是否一致（一般都会有明显区别的），然后分析在哪个网段开始丢包。

3、路由逐跳ping 
　　对于mtr或者traceroute的结果做一个逐跳ping测试，同时还需要对每一跳做一个traceroute，这是为了查看逐跳ping路由和之前的mtr路径是否一致，如果逐跳ping不丢包但是路由又不一致，这种结果是不能够作为判断的。如下：

[root@xxxx ~]# mtr -c 400 -i 0.1  -n -r <公司IP，不方便公布> 
HOST: xxxx                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. <公司IP，不方便公布>                 0.0%   400    2.7   2.3   1.7  10.8   0.8
  2. <公司IP，不方便公布>                 0.0%   400    0.7   0.6   0.4  17.1   0.9
  3. 120.221.17.85                99.0%   400    1.0   1.0   0.9   1.0   0.1
  4. 211.137.196.233              67.2%   400    1.5   5.3   1.2  44.7  10.0
  5. 120.192.97.9                 86.8%   400    6.0   5.8   5.6   7.0   0.2
  6. 221.183.12.205                0.0%   400    5.2   7.1   5.1  89.8   7.0
  7. 221.183.10.26                12.8%   400   38.2  38.7  28.3 127.0   9.2
  8. 221.183.23.170                9.8%   400   61.8  65.0  53.3 186.8  12.5
  9. 221.176.20.186               11.5%   400   51.9  53.4  40.0 123.6  11.9
 10. 183.203.27.218               10.5%   400   51.7  51.1  41.3  70.0   3.9
 11. 183.203.21.138               11.0%   399   63.1  62.2  50.9  76.7   3.2
 12. 221.180.20.170               13.0%   399   55.8 228.3  48.2 1004. 275.5
 13. ???                          100.0   399    0.0   0.0   0.0   0.0   0.0
 14. <公司IP，不方便公布>                12.0%   399   60.9  62.6  53.4  74.8   3.8

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16

　　看MTR，第7跳可能存在问题，但是我ping测时时不丢包，然后做traceroute图对比，发现路由在第3跳已经发生了变化。因此这个逐跳ping无效。有的IDC经常做这种测试“忽悠人”，这时我们可以叫机房拿出测试路由对比图。因为整个网络的传输链路很多，可能是某个链路的问题，一般很难查到，必须对比，以便配合运营商更快的解决问题。

[root@xxx ~]# traceroute -n <公司IP，不方便公布> 
traceroute to <公司IP，不方便公布>  (<公司IP，不方便公布> ), 30 hops max, 60 byte packets
 1  <公司IP，不方便公布>   11.330 ms  11.774 ms  11.859 ms
 2  <公司IP，不方便公布>   0.551 ms 120.221.17.25  11.146 ms 120.221.17.253  0.793 ms
 3  120.221.16.13  0.838 ms 223.99.224.25  0.897 ms  0.965 ms
 4  211.137.196.233  27.478 ms * *
 5  221.183.12.229  1.201 ms 221.183.12.61  0.683 ms 221.183.27.181  16.531 ms
 6  <公司IP，不方便公布>   39.187 ms  38.786 ms  45.546 ms

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

2.3

• mtr报告各列含义

Loss%       表示在每一跳的丢包率
Snt         每个中间设备收到的发送的报的数目（上图为400个包），MTR会同            时对所有中间节点发送ICMP包进行测试。
Last        最后一个数据包往返时间（ms）
Avg         数据包往返平均时间（ms）
Best        数据包往返最小时间（ms）
Wrst        数据包往返最大时间（ms）
StDev       标准偏差。如果标准偏差越高，说明数据包在这个节点上的延时越           不相同

• 1
• 2
• 3
• 4
• 5
• 6
• 7

• MTR报告分析 
  　　对于MTR报告我们主要关注丢包率和延时。如果在Loss% 列有丢包，说明这一跳可能有问题。但是，ISP会人为的限制ICMP的速率，这也会导致丢包现象。 
  如何排除限速干扰了？我们只需要观察丢包的下一跳或者后面几跳是否有丢包率为0的情况，如果有，则说明是设备本身的干扰。判定理由：如果中间路由某跳确实丢包，那么后续节点肯定收不到预定的数据包数量了。因此在图一我们可以看到，前5跳都是有丢包的，但是第6跳没有丢包，因此可以认为之前5跳的丢包率的是由于设备上的ICMP策略导致的。 
  注意：ICMP限制和丢包可能同时存在！如果在这种情况下中间节点全部是丢包的，那么我们要用最低百分比来衡量。如下图：

　　第6跳丢包57%，但是后面几跳的丢包率又下降了，第7跳相对于后续几跳，丢包率也是偏高的，因此可以认为6、7跳不仅有丢包原因，还是有ICMP限速原因导致的。 
　　对于MTR测试结果，一般首先看最后一跳，如果最后一跳有丢包，那么这个分析才是有意义的。因此判断是否丢包，丢在哪里，看最后几跳是最明显的。