转自 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

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

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

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测试结果，一般首先看最后一跳，如果最后一跳有丢包，那么这个分析才是有意义的。因此判断是否丢包，丢在哪里，看最后几跳是最明显的。