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

由于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:\ping?10.0.0.172?-t?-l?1469Pinging?10.0.0.172??with?1457?bytes?of?data:Request?timed?out.Request?timed?out.Request?timed?out.Request?timed?out. 发送包大小为1457字节的数据包可以正常通过。 C:\ping?10.0.0.172??-t?-l?1467Pinging?10.0.0.172??with?1452?bytes?of?data:Reply?from?10.0.0.172?:?bytes=1467?time=1374ms?TTL=127Reply?from?10.0.0.172?:?bytes=1467?time=678ms?TTL=127Reply?from?10.0.0.172?:?bytes=1467 time=623ms?TTL=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包