用ping ，mtr ，traceroute 进行网络丢包分析 |
您所在的位置：网站首页 › 交换机丢包可能是什么原因 › 用ping ，mtr ，traceroute 进行网络丢包分析 |
用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 HOST: xxxx Loss% Snt Last Avg Best Wrst StDev 1. 0.0% 400 2.7 2.3 1.7 10.8 0.8 2. 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. 12.0% 399 60.9 62.6 53.4 74.8 3.8 12345678910111213141516 看MTR，第7跳可能存在问题，但是我ping测时时不丢包，然后做traceroute图对比，发现路由在第3跳已经发生了变化。因此这个逐跳ping无效。有的IDC经常做这种测试“忽悠人”，这时我们可以叫机房拿出测试路由对比图。因为整个网络的传输链路很多，可能是某个链路的问题，一般很难查到，必须对比，以便配合运营商更快的解决问题。 [root@xxx ~]# traceroute -n traceroute to ( ), 30 hops max, 60 byte packets 1 11.330 ms 11.774 ms 11.859 ms 2 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 39.187 ms 38.786 ms 45.546 ms 12345678 2.3 mtr报告各列含义 Loss% 表示在每一跳的丢包率 Snt 每个中间设备收到的发送的报的数目（上图为400个包），MTR会同 时对所有中间节点发送ICMP包进行测试。 Last 最后一个数据包往返时间（ms） Avg 数据包往返平均时间（ms） Best 数据包往返最小时间（ms） Wrst 数据包往返最大时间（ms） StDev 标准偏差。如果标准偏差越高，说明数据包在这个节点上的延时越 不相同 1234567 MTR报告分析 对于MTR报告我们主要关注丢包率和延时。如果在Loss% 列有丢包，说明这一跳可能有问题。但是，ISP会人为的限制ICMP的速率，这也会导致丢包现象。 如何排除限速干扰了？我们只需要观察丢包的下一跳或者后面几跳是否有丢包率为0的情况，如果有，则说明是设备本身的干扰。判定理由：如果中间路由某跳确实丢包，那么后续节点肯定收不到预定的数据包数量了。因此在图一我们可以看到，前5跳都是有丢包的，但是第6跳没有丢包，因此可以认为之前5跳的丢包率的是由于设备上的ICMP策略导致的。 注意：ICMP限制和丢包可能同时存在！如果在这种情况下中间节点全部是丢包的，那么我们要用最低百分比来衡量。如下图：
第6跳丢包57%，但是后面几跳的丢包率又下降了，第7跳相对于后续几跳，丢包率也是偏高的，因此可以认为6、7跳不仅有丢包原因，还是有ICMP限速原因导致的。 对于MTR测试结果，一般首先看最后一跳，如果最后一跳有丢包，那么这个分析才是有意义的。因此判断是否丢包，丢在哪里，看最后几跳是最明显的。 |
【本文地址】