MTU值设置不合理产生下行分片过多导致内容计费业务过程中产生缺省流量

爱卫生

现象描述：
    某客户投诉在使用手机音乐随身听过程中产生“默认流量”，即非内容计费流量，造成多收取费用。

告警信息：
   无相关告警。

原因分析：
   产生内容计费流量之外的非免费流量可能的原因有：
1、用户在访问免费网页的同时访问了非免费的网页。
2、用户终端中安装的其他软件自动向网络侧发包，导致用户无感知的情况下产生默认流量，造成计费。
3、其他异常访问流程造成部分流量无法匹配内容计费规则。
4、GGSN配置或者软件存在问题，导致无法匹配内容计费数据报文。

处理过程：
1、对该用户产生的话单进行确认，音乐随身听的业务代码为1010000001，但却产生了SI(Service ID)为：5001的流量。
2、根据运营商下发的内容计费局数据规范核对GGSN内容计费配置，相关内容业务的3/4层规则和7层规则配置正确完整，没有出现漏配的情况。
3、从CG中获取了更多话单，发现很多话单中伴随内容计费流量都产生了默认流量，且默认流量只有下行没有上行。如下话单中serviceCode:5001uplink流量为0，donwlink不为0。此为疑点1。
4、联系终端客户进行收集音乐业务拨测，查看转化后的pcap文件：用户上网过程中只有一个会话，没有其他异常信令和异常流量，且URL完整、没有分片；（见附件1）。
5、又跟踪了几次用户上网过程，现象基本一致，但发现每次用户上网都会出现较多的下行分片。此为疑点2。
6、结合疑点1和疑点2，怀疑下行流量是分片造成的；
7、分析现场的调试信息，发现GGSN出现过内容计费报文分片重组失败的记录。进一步分析现网的数据报文，发现所有WAP网关下行是1500字节的报文，都被WAP网关到GGSN之间的中间数传设备进行了分片。这样就导致了在GGSN出现了大量的用户数据报文分片，在业务忙时出现这些下行分片报文无法重组，GGSN无法解析端口信息，导致内容计费失败，这些分片报文的流量因此被记录到了缺省流量。
8、内容计费的是基于五元组（源IP、目的IP、传输层协议、传输层源端口、传输层目的端口）进行流量统计。但由于用户的下行数据报文是在IP层被分片，因此五元组中的传输层源端口、传输层目的端口都只存在于第一个分片，后续分片中都不含传输层信息.GGSN必须对用户的所有分片报文重组起来后，再进行内容计费流量统计，否则无法判断分片部分的流量属于哪个TCP链接。
9、因现场存在大量分片，超过GGSN分片处理能力，导致GGSN无法重组部分分片，即无法识别分片报文所属的会话。这部分分片统计成默认流量，造成额外计费。
10、确认现场组网图和路径上设备的MTU（见附件2）。现网为了规避某厂商GGSN GRE分片处理缺陷，在wap网关侧防火墙MTU改成1460。这样WAP网关发出的1500的数据包会在wap网关侧防火墙分片后到达GRE路由器进行GRE封装，就不会形成GRE分片报文。但是这些在“内层”分片的报文到达GGSN做内容计费解析的时候，需要重组，进而触发该问题。
11、如果wap网关发送的数据包变小，“内层”包和封装之后的GRE包都不会被分片。TCP发送数据段最大长度称为MSS，该值是TCP握手时终端和服务器协商的，取终端和服务器MSS的最小值。中间防火墙设备可以更改TCP握手消息的最小值（经过防火墙的GRE封装后的TCP消息除外）。
12、由于终端上的MSS和手机特性有关，不可更改，因此可以修改wap网关侧防火墙的MSS或者WAP网关的MSS（可通过修改网卡的MTU实现，MSS=MTU-40Bytes）。
13、最后将wap网关上网卡的MTU修改为1460，使wap网关的MSS变为1420。从附件3可以看到，wap网关三次握手应答消息SYN ACK中MSS已经变为1420Bytes。
14、修改后查看话单，问题解决。

建议与总结：
    涉及到MTU问题，需要全网排查。由于GRE报文经过防火墙的时候，防火墙不建立会话，因此GRE封装后的TCP报文中的MSS经过防火墙的时候不会被更改。

注：附件请登录后查看。生成文章后，附件是看不到的。

附件2.路径MTU情况

kfclove

太中意这个论坛了。向LZ致敬！！

hendouse

    “现网为了规避某厂商GGSN GRE分片处理缺陷，在wap网关侧防火墙MTU改成1460。这样WAP网关发出的1500的数据包会在wap网关侧防火墙分片后到达GRE路由器进行GRE封装，就不会形成GRE分片报文。但是这些在“内层”分片的报文到达GGSN做内容计费解析的时候，需要重组，进而触发该问题。而如果wap网关发送的数据包变小，“内层”包和封装之后的GRE包都不会被分片。”  这是本帖发生问题的关键。
   疑问如下：
1、将wap网关上网卡的MTU修改为1460，使wap网关的MSS变为1420，那么wap网关发送的数据包还是会比较大啊，在到达GRE前不是要被分包吗？这样不是会造成GGSN重组包问题吗？

爱卫生

回复 hendouse 的帖子

  没有啊。经过修改后，Wap网关的MTU为1460，包到达Wap网关侧防火墙后，Wap网关防火墙的MTU也是1460，刚好没有超过。就不会产生分片啊。然后到达GRE路由器后，GRE路由器加上GRE头部以后，也没有超过GRE路由器出接口的MTU 1500字节，因此从GRE路由器出来的包也没有分片，然后这个包经过GGSN侧的防火墙到达GGSN，GGSN侧防火墙的MTU也没超过，这样在GGSN侧收到的就是一个个1460字节的报文了。没有包重组的问题了。

hendouse

回复 爱卫生 的帖子

“TCP发送数据段最大长度称为MSS”，这个应该是指外网发给网关 TCP包最大的长度吧？
那“使wap网关的MSS变为1420”，是不是先让网关把这些超过1420字节的TCP包先分包再接着往下发送呢？

爱卫生

hendouse 发表于 2011-6-19 16:37
回复 爱卫生 的帖子

“TCP发送数据段最大长度称为MSS”，这个应该是指外网发给网关 TCP包最大的长度吧？

1 MSS是TCP层支持的最大段大小。类似于IP层的MTU。只不过是针对TCP层来说的。
  数据的封装过程是从上往下，依照OSI 7层模型。应用层交给TCP层处理后，TCP将根据MSS的大小来决定是否在TCP层进行分段处理，这个例子里如果TCP MSS为1420字节，则如果TCP的上层超过1420字节，就除以1420进行分段。然后再将分好段的报文交给下层IP层处理。IP层还需要执行一次分片，依据就是MTU。
通常TCP的MSS为1460字节，向下交给IP层处理。IP层的MTU默认为1500字节，这样1460+20字节TCP头+20字节IP头刚好就是1500字节，这样在IP层也避免了分片。
本例中是TCP MSS 1420字节+40=1460字节，这个1460就是IP层的MTU。
TCP的MSS是在三次握手的过程中由通信双方来协商的。（点击附件#2包的TCP层的Option部分可以看到MSS为1460字节）。
如果WAP网关的MSS为1420，则上层的网页内容超过1420字节，则在WAP网关上就会按1420字节进行分段，然后再往下发送。设置成1420的好处就是，使得包交给IP层处理的时候，正好等于IP层MTU 1460字节，不会导致分片，在发给GRE路由器的时候，也不会超过GRE路由器的IP层MTU 1500字节而导致分片。

2 本例中的MSS是指的TCP层通信的双方，也就是WAP网关和手机MS。其中，10.169.219.181为MS的IP，10.0.0.172是WAP网关。前3个包就是他们的TCP三次握手，并协商MSS的过程。并且显示的都是私网地址，没有地址转换，所以肯定是在Gi口抓的。

zglaojiang

向楼组致敬，那种无私奉献的精神值得每个人学习。

hrbqby

好贴，收藏

zs622

顶，先看看在说

zs622

顶一下，先看看

hycl5410

嗯，基本确定是H生成的文档。
H研发支持的competence是很强的，很佩服那拨人。

小燕-smile

爱卫生 发表于 2011-6-19 17:03
1 MSS是TCP层支持的最大段大小。类似于IP层的MTU。只不过是针对TCP层来说的。
  数据的封装过程是从上往 ...

爱总，这个GRE隧道是从GGSN到GRE路由器吧？如果GGSN侧的防火墙MSS=1400,那么GGSN侧防火墙和GRE路由器协商的MSS=1400,是不是从GRE发给GGSN侧防火墙的时候要根据MSS=1400进行分段？如果真的分段，那GGSN接收到的MTU=1400+40+40=1480的GRE数据包？谢谢，不知道怎么理解？

小燕-smile

GGSN侧防火墙是不是MSS=1400应该改为MTU=1500才合适？

hycl5410

GGSN侧防火墙MSS=1400确实看起来比较突兀，因为整个文档都没有提及这个防火墙可以有更改UE与server之间MSS协商的能力。而且从抓包也可以看到SYNC的MSS是1460，看起来像是手机原始带上来的，没有被该防火墙改成1400.

不看这个防火墙的MSS=1400，整个文档就很通顺；看了这个MSS=1400，确实感觉还有东西没有交待清楚。

why_zero

好帖，收藏！！！