一个ping大包不通问题的解决过程

Posted 千里之外

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一个ping大包不通问题的解决过程相关的知识,希望对你有一定的参考价值。

1、问题描述

存在问题: 深圳的采集机MQ程序无法与应用服务器进行通讯,表现为:获取小数据时正常,获取大数据时超时

场景图如下

image

2、数据下载测试

使用SCP工具和FTP工具进行数据下载测试,主要是想排除采集机上MQ与应用服务器上应用的问题

2.1、在深圳采集机1上执行命令从应用服务器取数据

数据走向:应用服务器->深圳采集机1

结果:失败

image

2.2、在深圳采集机2上执行命令从应用服务器取数据

数据走向:应用服务器->深圳采集机2

结果:失败

image

2.3、在河源采集机上执行命令从应用服务器取数据

数据走向:应用服务器->河源采集机

结果:成功

image

2.4、在深圳采集机1上执行命令把数据传到应用服务器

数据走向:深圳采集机1->应用服务器

结果:成功

image

2.5、在深圳采集机1上执行命令从河源采集机取数据

数据走向:河源采集机->深圳采集机1

结果:成功

image

分析:

  • 应用服务器->深圳采集机,数据传输不正常,出现"stalled"情况
  • 应用服务器->河源采集机 数据传输正常,耗时1秒
  • 深圳采集机->应用服务器 数据传输正常,耗时10秒
  • 河源采集机->深圳采集机 数据传输正常,耗时4秒

从以上得出结论

  • 排除采集机MQ的问题----使用scp和ftp工具都出现相同的问题
  • 排除应用服务器应用的问题-----深圳采集机传输到应用服务器正常
  • 排除深圳采集机服务器问题----河源采集机传数据到深圳采集机正常

通过这些测试,感觉到是中间网络的问题,但是仔细想想,又好像不对,应用服务器->深圳采集机方向就有问题,深圳采集机->应用服务器就没问题,结合出现问题的现象:获取小数据时正常,获取大数据时超时,于是接下来进行ping大包数据测试

3、ping测试

同时,我也发现一个现象,从深圳采集机1上去ping应用服务器大包,超过1468byte后就不通了,在别的十多个地市采集机测试,同样的包大小都能通,于是我尝试在深圳和河源两个地市进行ping然后在两端抓包分析,进行对比

3.1、在深圳采集机上对应用服务器发起大包ping--超过1486byte就ping不成功

发起一个2000Byte字节大小的包测试。注:此处的120.83.3.10是应用服务器的另一个IP地址

ping -s 2000 120.83.3.10 -c 1

在深圳采集机上1的抓包结果为如下:有三个帧,两个为去的,一个为返回的,有一个途中丢失了(结合下面在应用服务器收到了两个帧,可分析出一个帧从应用服务器到采集机的途中丢失了)

image

上图解析:

  • 采集机到达应用服务器的大包拆成了2个帧,分别是1514和562
  • 应用服务器按道理应该返回相同的数据量,但是只收到了一个562的帧,有一个1514的包在途中丢失了

注:因为链路层的MTU值为1500,所以包要拆分为两个帧,MTU为1500的时候对应的length为1514

image

在应用服务器上的抓包结果为:收到了深圳采集机过来的2个帧

image

仔细分析应用服务器到采集机这个包的内容:里面的一个字段为flags为:0x02(Don’t Fragment),引起了我的注意

clip_image002[18]

3.2、在河源采集机上对应用服务器发起大包ping--可以ping成功

河源采集机上的抓包结果为(这里有4个数据包,两个为去的,两个为返回的)

image

应用服务器这边的抓包结果为:成功收到采集机发过来的两个帧

image

也仔细分析应用服务器到河源采集机这两个包的内容:里面的一个字段为flags:分别是0X03和0X02

image

image

上网查找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.3、应用服务器发起对深圳采集机和河源采集机的ping大包--都能ping成功

还是2000byte的测试包

深圳采集机的抓包结果:注意此处,到深圳采集机竟然分成了三个帧?为什么

image

应用服务器抓包结果

image

河源采集机的抓包结果,注意此处,到河源采集机两个帧

image

应用服务器抓包结果

image

再进一步情况汇总:

  • 从应用服务器上是可以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,也是不允许进行拆分包,所以传输有问题。

image

4、最终原因分析

  • 服务器返回的包不允许分片是其中一个原因
  • 中间经过mpls组网架构的网络,会加上两个标签(8字节)的mpls包头。通过以上针对ping大包、scp数据下载不了的分析,刚开始判断路径中有一台设备的端口的MTU值为1492,后来深圳检查了深圳侧的设备,各个端口的MTU值为1500。我估计是我们设备通往深圳的的采集机路径中经过一个mpls组网架构的网络,在这个网络的的入口侧pe会给数据包打上两个标签(每个标签4字节),这样数据包的大小就会大过1500,端口直接把包给丢弃。

所以出现ping大包不通现象,同时也是导致采集程序无法与应用服务器通讯的原因。

5、解决办法

有三种解决方法

1、修改操作系统的限制,允许分片

2、排查应用服务器至深圳采集机服务器通过的mpls网络节点路径的进出端口,修改这些接口的MTU值为1508以上

3、修改应用服务器的网卡的MTU值为1492(因为中间多了8Byte的数据,从源端分片的时候预留这8Byte就行啦,目前采用了这种解决方法)

存在风险: 对于一个基于网络的应用来讲,如果应用穿过网络的MTU与网络上的最小MTU相等,那么应用穿过网络的效率最高,原因是有效的避免了分片和重组。MTU从1500降到1492,在数据传输的效率上会有影响,但很小。

以上是关于一个ping大包不通问题的解决过程的主要内容,如果未能解决你的问题,请参考以下文章

为啥ping 不通外网IP?

解决克隆虚拟机网络ping不通

解决Win10系统ping不通无法远程的问题

ping小包是多少的包

怎么解决网络ping不通问题

ping IP通 ping 主机名不通 如何解决?