一个ping大包不通问题的解决过程
一、问题描述
存在问题： 深圳的采集机MQ程序无法与应用服务器进行通讯，表现为：获取小数据时正常，获取大数据时超时
场景图如下
存在问题：
- 深圳的采集机MQ程序无法与应用服务器进行通讯，表现为：获取小数据时正常，获取大数据时超时
- 进一步排查，使用公共的工具(ftp/scp)从应用服务器下载数据下载不了-----排除了MQ或者应用的问题
- 再进一步排查，从深圳采集机ping大包不通应用服务器--------
二、数据下载测试
使用SCP工具和FTP工具进行数据下载测试，主要是想排除采集机上MQ与应用服务器上应用的问题
1、在深圳采集机1上执行命令从应用服务器取数据
数据走向：应用服务器->深圳采集机1
结果：失败
2、在深圳采集机2上执行命令从应用服务器取数据
数据走向：应用服务器->深圳采集机2
结果：失败
3、在河源采集机上执行命令从应用服务器取数据
数据走向：应用服务器->河源采集机
结果：成功
4、在深圳采集机1上执行命令把数据传到应用服务器
数据走向：深圳采集机1->应用服务器
结果：成功
5、在深圳采集机1上执行命令从河源采集机取数据
数据走向：河源采集机->深圳采集机1
结果：成功
分析：
- 应用服务器->深圳采集机，数据传输不正常，出现"stalled"情况
- 应用服务器->河源采集机 数据传输正常，耗时1秒
- 深圳采集机->应用服务器 数据传输正常，耗时10秒
- 河源采集机->深圳采集机 数据传输正常，耗时4秒
从以上得出结论
- 排除采集机MQ的问题----使用scp和ftp工具都出现相同的问题
- 排除应用服务器应用的问题-----深圳采集机传输到应用服务器正常
- 排除深圳采集机服务器问题----河源采集机传数据到深圳采集机正常
通过这些测试，感觉到是中间网络的问题，但是仔细想想，又好像不对，应用服务器->深圳采集机方向就有问题，深圳采集机->应用服务器就没问题，结合出现问题的现象：获取小数据时正常，获取大数据时超时，于是接下来进行ping大包数据测试
三、ping测试
同时，我也发现一个现象，从深圳采集机1上去ping应用服务器大包，超过1468byte后就不通了，在别的十多个地市采集机测试，同样的包大小都能通，于是我尝试在深圳和河源两个地市进行ping然后在两端抓包分析，进行对比
1、在深圳采集机上发起大包ping--超过1486byte就ping不成功
发起一个2000Byte字节大小的包测试。注：此处的120.83.3.10是应用服务器的另一个IP地址
ping -s 2000 120.83.3.10 -c 1
在深圳采集机上1的抓包结果为如下：有三个帧，两个为去的，一个为返回的，有一个途中丢失了（结合下面在应用服务器收到了两个帧，可分析出一个帧从应用服务器到采集机的途中丢失了）
上图解析：
- 采集机到达应用服务器的大包拆成了2个帧，分别是1514和562
- 应用服务器按道理应该返回相同的数据量，但是只收到了一个562的帧，有一个1514的包在途中丢失了
注：因为链路层的MTU值为1500，所以包要拆分为两个帧，MTU为1500的时候对应的length为1514
在应用服务器上的抓包结果为：收到了深圳采集机过来的2个帧
仔细分析应用服务器到采集机这个包的内容：里面的一个字段为flags为：0x02(Don’t Fragment)，引起了我的注意
2、在河源采集机上发起大包ping--可以ping成功
河源采集机上的抓包结果为(这里有4个数据包，两个为去的，两个为返回的)
应用服务器这边的抓包结果为：成功收到采集机发过来的两个帧
也仔细分析应用服务器到河源采集机这两个包的内容：里面的一个字段为flags：分别是0X03和0X02
上网查找tcp/ip的协议的相关细节，原来这这个字段的值和含义如下：
用于标识数据帧分片是否发送完成，0X01代表“别着急，后面还有！”；0X00表示“好了，我是最后一个帧，所有帧都到齐了，你可以进行组装了”。除此 之外，Flags字段还有一种可能就是0X02，表示该IP数据包不允许进行拆分，这时如果IP数据包长度大于链路MTU值，就会直接丢包。还有一种情况为0X03,表示不允许拆分，后面还有分片。
1和2的分析汇总
- 当包大小超过1476byte的时候，会拆分为多个数据包发送出去
- 应用服务器能收到两个地市传过来的ICMP请求数据包
- 河源发起ping大包测试的时候收到应用服务器返回的数据包有两个
- 深圳发起ping大包测试的时候收到应用服务器返回的数据包只有一个，有一个length为1514byte的包从应用服务器返回的途中丢失了
结论分析：
- 应用服务器(solaris) 回应ping的request(即reply)的时候大包(2000byte)分成了两个数据包，数据包的flags字段不允许分段(0X02)
- 中间的网络中的一个端口的MTU值小于1500，导致包(length为1514的包)直接丢失
为了进一步验证是不是这样，从应用服务器发起对深圳采集机和河源采集机的ping情况
3、应用服务器发起对深圳采集机和河源采集机的ping大包--都能ping成功
还是2000byte的测试包
深圳采集机的抓包结果：注意此处，到深圳采集机竟然分成了三个帧？为什么
应用服务器抓包结果
河源采集机的抓包结果，注意此处，到河源采集机两个帧
应用服务器抓包结果
再进一步情况汇总：
- 从应用服务器上是可以ping通深圳采集机和河源采集机的(因为应用服务器的request包flags字段为0X01：允许分段
- 通过在深圳采集机上和河源采集机上的抓包对比，也可以发现从应用服务器至河源采集机的包划分为了3个数据帧，最大的一个数据帧length为1506，很明显小于1514，少了8Byte，而且多了一个60Byte的帧
结论分析：
- 应用服务器主动发起的包允许分段
- 应用服务器->深圳采集机的包分成了三个数据帧，1514分成了1506和8，为什么拆分了8字节的数据出来，分析是中间经过一个MPLS网络，加了8字节的载荷
- 从上一条结论延伸下：ICMP包的载荷是52（很明显60-8=52），IPv4包的载荷是24（很明显：1514-(2000-（562-52）)=24）,但是为什么一个2000字节的包切割为一个IPv4和一个ICMP的包？
回到那个scp传输数据有误的问题，进行抓包，发现各个数据包中的flags字段为0X02,也是不允许进行拆分包，所以传输有问题。
三、最终原因分析
- 服务器返回的包不允许分片是其中一个原因
- 中间经过mpls组网架构的网络，会加上两个标签(8字节)的mpls包头。通过以上针对ping大包、scp数据下载不了的分析，刚开始判断路径中有一台设备的端口的MTU值为1492，后来深圳检查了深圳侧的设备，各个端口的MTU值为1500。我估计是我们设备通往深圳的的采集机路径中经过一个mpls组网架构的网络，在这个网络的的入口侧pe会给数据包打上两个标签(每个标签4字节)，这样数据包的大小就会大过1500，端口直接把包给丢弃。
所以出现ping大包不通现象，同时也是导致采集程序无法与应用服务器通讯的原因。
四、解决方法
有三种解决方法
1、修改操作系统的限制，允许分片
2、排查应用服务器至深圳采集机服务器通过的mpls网络节点路径的进出端口，修改这些接口的MTU值为1508以上
3、修改应用服务器的网卡的MTU值为1492(因为中间多了8Byte的数据，从源端分片的时候预留这8Byte就行啦，目前采用了这种解决方法)
存在风险: 对于一个基于网络的应用来讲，如果应用穿过网络的MTU与网络上的最小MTU相等，那么应用穿过网络的效率最高，原因是有效的避免了分片和重组。MTU从1500降到1492，在数据传输的效率上会有影响，但很小。
原文：https://www.cnblogs.com/fuqu/p/9998461.html