MSS值不合理及防火墙的分片存储转发未开启导致3Gwap业务故障频繁.doc

由于MSS值不合理及防火墙的分片存储未开启导致3G PS的 3GWAP类业务失败的典型案例分析一 问题描述：在进行我司3GWAP平台的建设过程中，发现用户通过3GWAP APN进行接入后有时不能使用网页浏览等业务，有时则是正常访问。而2G的APN使用的UNIWAP是可以正常通信的。核实其无线终端可以正常通过SGSN和GGSN分配到正常的IP地址段，移动终端可以ping通平台侧的WAP网关地址，但具体发生业务访问时无法正常通信；由于该用户使用该平台进行其业务数据的收集和管理，数传失败将直接影响到其正常的业务开展，因此投诉十分强烈。二故障分析处理过程：接到该问题后，立即着手进行分析处理。由于分组WAP业务涉及到得网络环节较多，无线侧，分组核心网、承载平台、WAP网关等都有可能造成最后的使用问题，因此应将该业务涉及到得网络结构上各个层面的问题进行综合分析，才能定位，解决问题。1.WAP使用的典型网络结构：我司目前提供的3Gwap接入的模型如下： 简单说来，业务的实现过程就是手机或移动终端通过3G无线网络接入到PS核心网，在核心网上单独开通一个3GWAP APN，并分配特定的IP地址段。然后从GGSN通过GI出口到行业应用平台，同WAP的对接路由器上完成路由层面的互通，为保持一定的安全性，一般要求在GGSN和3GWAP平台对接的路由器上启用一定的隧道（大多使用GRE tunnel）。然后通过该TUNNEL.移动终端可以和用户内网的服务器进行通信。2.问题分析：2.1基本分析： 由于用户在使用中可以通过PS网络获取到对应APN的IP地址，因此初步分析造成该用户业务不能使用同无线侧以及分组域核心网关系不大，问题主要应在从GGSN GI出口到wap网关这一段。由于用户在获取地址后可以PING通3GWAP的服务器IP地址，说明路由层面的互通性是正常。那为什么会出现不能使用的问题呢？ 考虑到一般的PING测试未考虑到分组数据包的大小问题，都是默认的数据包大小，不能完全检查出该通路的问题。重新做扩展的ping测试后，发现如下问题：从移动终端向用户服务器发送小于1468字节的数据包时，将可以正常ping通。但如果想服务器发送大于1468字节的数据包时，将会不能正常ping通。C:ping10.0.0.172-t-l1469Pinging10.0.0.172with1457bytesofdata:Requesttimedout.Requesttimedout.Requesttimedout.Requesttimedout. 发送包大小为1457字节的数据包可以正常通过。C:ping10.0.0.172-t-l1467Pinging10.0.0.172with1452bytesofdata:Replyfrom10.0.0.172:bytes=1467time=1374msTTL=127Replyfrom10.0.0.172:bytes=1467time=678msTTL=127Replyfrom10.0.0.172:bytes=1467 time=623msTTL=127 发送包大小为1452字节的数据包可以正常通过。 因此，从以上情况来看，怀疑是由于当业务使用时发出的数据包如果大于了1468，发生了分片，而是否是IP分片的丢失造成了业务有时不能正常使用呢？ IP包在传输过程中，其大小是有限制的，通常为1500个字节，即我们通常所定义的MTU值。一个有效的应用层数据包被封装到IP包中进行传输，当这个数据包被封装后长度大于与1500字节，就会被封装成多个IP包进行传输，每个满包的长度（加上IP包头）为1500字节。分片包会在IP包头中被表明属性和偏移量，以便最终的接收方完成重组。所有分片必须都被正确传输，否则不能正确组包，数据就丢失了。当然，考虑到本网络结构中间还经过了GRE隧道，因此还应加入GRE隧道的4字节包头。GRE隧道的起点在GGSN上，终结在对端数通设备上。通过同相应部门的同事联系，对该了通路上的所有设备，如GGSN, GI FW, 路由器等进行了MTU值的检查，发现都是1500字节。在PING测试过程，1468的数据+8字节的ICMP+20字节的IP+4字节的GRE，恰好为1500字节，如果PING测试发生的数据大于了1468字节，则最终的数据包将大于1500. 再次考虑业务使用的情况，由于业务基于TCP方式，默认IP包头大小为20字节，TCP包头20字节。如果应用层数据为1456字节，这样的话，整个数据包大小就是1456数据+20字节TCP包头+4字节GRE头+20字节IP包头，正好为1500字节，因为各接口的MTU值正好是1500，因此不会造成分片。而当应用层数据大于1456字节时，例如IP包的有效载荷为1460字节，数据包大小应为：有效载荷为：1460字节，20字节的tcp包头，20字节的IP包头，上4字节的gre包头，一共是1504字节。而该数据包在通过MTU值为1500字节的数据时会被分为两断：一段的有效载荷为1456，包长为1456+20(ip包头)+20（tcp）+4（GRE头）1500；另二段的有效载荷为4，包长为4（数据）+20(ip包头)+20（tcp）+4（GRE头）48。这样就产生了IP分片。结合前面的PING测试情况，明确了网络中一旦应用数据的大小超过了1456字节时将产生分片，而分片可能由于某种原因发生丢失。这进一步增加了分片丢失导致业务不能正常使用的可能性。关键问题是，本次业务在使用过程中，用户向server发送的应用数据是多大呢？是大于1456字节的应用数据吗？2.2 TCP OPTION选项中的MSS值MSS: Maximum Segment Size ，最大分段大小是TCP协议里面的一个概念。MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。按照以上的说明，实际上用户端同server发生通信时实际的TCP数据段有效载荷是按照通信双方在3握手过程中协商的MSS值来确定的。结合前面的基本分析，如果MSS值大于了1456字节，加上TCP包头，IP包头，GRE包头的满包将大于1500字节，也就是可能产生分片。如果分片发生丢失，就可能造成通信失败。那到底本次通信的MSS值协商是多少呢。将GGSN跟踪的消息转换为CAP包后，使用ETHEREAL进行分析，情况如下图：第一条消息，在tcp层，移动终端上报自己的mss值，仔细核实，果然为1460字节一个典型的分片报文丢失导致丢包数传失败的例子：第二条消息，wap网关回应自己的mss值，也为1460。这样一个满包为1500，而加上gre头后会变成1504的包，中间任何一个数通设备mtu为1500（通常都是），这个包会都会被分片。但是，分片数据在一般的路由器或交换机上都可以得到转发，为什么此处分片在传输过程中发生了丢失呢？考虑到防火墙的工作机制异于路由器等，首先对其进行分析。在发生分片时，所有分片的IP头被标记为分片。对原始数据包的分片，给其IP头的标识区域分配一个唯一的标识，这将帮助目的设备确定分片应该被转发给什么协议和端口。不管是数据包始末的还是中间的分片，都使用标识区域来给分片作记号。使用分片偏移域来标记在重组过程中分片应该放在哪里以便组成一个总的（完整的）数据包。对于有状态防火墙，它的数据转发依赖于转发连接表项。对于一个分片的数据，他只对首片的信息建立转发表项。由于不能保证第一个分片总是第一个被接收到，它应当把其他的分片放在缓存中，当所有分片到达后再重组，建立转发表后转发。如果没有缓存功能，当到达的数据不是一个分片时，防火墙将丢弃该分片，导致业务失败。后同厂方人员联系，核实该防火墙上未开启分片缓存功能，也就是说如果出现分片乱序到达时，分片将发生丢失。这也解释了业务时好时坏。对于2G的UNIWAP,由于GGSN在同2G wap 网关互通时没有使用GRE隧道，正常的mss 值将不能引起分片，因此该问题不会体现。三处理过程：由于MSS的设置以及GRE的组网，导致数据分片，而防火墙不缓存分片报文（通常默认不开启），导致了分片丢失。根据这几个问题，有以下几种解决办法：1、直接改wap gw的mss值，例如改到1400左右，将最终的数据包大小低于MTU值，避免分片2、对防火墙启用分片缓存功能。在防火墙上执行命令：firewall#firewall fragment enable 后业务恢复，有时好有时坏的问题得以排除。四经验总结：1. 这种由于分片