Gi口问题导致终端用户无法上网

爱卫生

现象描述：
    S省U公司省内配置两套GGSN设备，PS域设备网络优化期间地市不断出现用户投诉IPHONE手机上网有网页打不开的问题，针对IPHONE上网问题进行了具体的测试，并从Iu口、Gn、Gi等接口进行联合分析。

告警信息：
    无。

原因分析：
    U公司的IPHONE定制手机默认采用xxNET方式浏览，无法更改APN为xxWAP，并且U公司定制IPHONE采用xxNET方式浏览和xxWAP方式浏览不同之处在于：xxNET方式是不经过WebGW网关的，而且DNS域名查询是由手机直接向DNS服务器发起的。因而xxNET方式浏览流程包含附着、PDP激活、DNS查询和文本显示等4个子流程。
    现场进行主动测试模拟现网用户上网行为，设置APN为xxNET，只进行WEB浏览成功率测试。测试网页分别为流量较小的百度，以及流量较大的新浪。每次测试以打开所有文本文档视为成功，然后关闭网页，再打开飞行模式然后再调成普通模式（即让手机去附着后再重新附着网络），然后再打开浏览器浏览网页（即手机重新激活一次）。
IPHONE WEB浏览成功率测试结果
测试次数 失败次数 成功率
75 5 93.33%
从测试情况来看，上网失败比例较高，占6.67%。
失败记录详细信息
序号 失败详细时间 访问网页 失败场景
1 17:37:37 百度 网页打不开
2 17:45:28 新浪 网页打不开
3 17:46:28 百度 网页打不开
4 17:49:47 新浪 网页打不开
5 17:57:14 新浪 网页打不开
   从以上5次失败的场景来看，5次中其中有4次是完整的附着、激活、业务浏览流程，均为手机PDP激活后访问网页无响应的情况，所以这里分析只针对此次失败流程进行分析，其他几次分析方法相同。
   另有1次（表中失败序列3）是在浏览失败之后，没有进行PDP激活，直接继续访问其他网页造成的失败（也就是现网用户发现不能上网，然后继续访问其他网址的行为），该次失败依然使用上次失败的IP地址，因此从流程上看，和上次访问失败是相同的场景，可参考“访问网页无响应”分析方法。

处理过程：
  SGSN侧信令跟踪分析：
（1） 信令跟踪发现MS->SGSN附着请求“PMM_ATTACH_REQ”及MS->SGSN附着响应“PMM_ATTACH_CMP”均显示正常，附着流程正常。
（2）信令跟踪发现GGSN->SGSN激活响应“GMT_CREAT_PDP_CONTEXT_RSP”相关信令显示正常，激活流程正常。
（3） 信令跟踪发现RNC->SGSN的RAB指配响应 “RAB_ASSIGNMENT_RSPONSE”相关信令显示正常，RAB指配流程正常。
（4）信令跟踪发现核心网侧已经到了用户面数传流程，信令面没有问题，但用户面数传只有上行RNC->SGSN及GGSN->SGSN用户面只有“GTP V1 Uplink T-PDU”，而无下行，将用户面的跟踪转换成CAP格式，看到的这里的数据传输也是只有上行。
（5） SGSN侧CAP格式文件看，用户一直在给202.102.128.68和202.102.152.3这个两个DNS服务器发起URL分别为“m.baidu.com”和“smtp.chinaunicom.cn”的DNS请求，这两个服务器均无响应。
测试地点的无线信号：
指标 Ec/Io RSCP
数值 -2dB -64dBm
测试环境角度，本次测试无线信号覆盖较好，消息上也没有看到无线有信号不好丢包的情况。手机终端的信令流程来看，手机进行了正常的附着、激活、以及业务流程，没有异常信令消息流程。
GGSN侧信令跟踪分析：
（1） 激活流程发生在GGSN 上，GGSN进行了正常激活“Creat PDP Conetext Responese”，但用户面数据同样只有上行SGSN->GGSN的“Uplink Data from GN”和GGSN->NET的“Uplink Data out from GI”，没有下行，且将这段消息转换成CAP格式，看到有SGSN的CAP文件同样问题；这里看到GGSN也同样是将此次的DNS请求外发给DNS服务器，没有异常的情况，需要继续向上分析。
（2） 将GN/GI接口的CAP抓包按该次手机得到的IP地址进行过滤（其中带GTP封装的为GN接口数据，不带GTP封装的为GI接口数据），分析表明GGSN已经将这些上行DNS请求报文送往防火墙方向，但是没有下行数据，进一步证实了问题定位核心网以下没有问题。

综合分析：
本次IPHONE上网问题综合分析从SGSN用户跟踪、GGSN用户跟踪、Gn口、Gi口工具抓包入手：
（1）从Gi口看到DNS请求报文已经送出，但是没有下行数据，进而排除Gi口以下设备问题（包括终端、无线、SGSN、GGSN）。
（2）测试现象中涉及两个DNS地址，综合分析同时出现丢包问题的可能很小，因此可以排除DNS服务器侧的问题。
（3）综合测试中发现，IPHONE出现5次上网失败现象均发生在GGSN出口，并且问题均出现在3GNET APN的地址池172.29网段，其他四个地址池网段测试结果均显示正常，结合GGSN路由转发的处理机制（上行不区分地址段进行路由——默认路由），也可排除GGSN自身问题。
（4） 最终定位问题在GI口防火墙或GI公网路由承载网上行或下行的路由问题，导致该172.29地址段的数据包无法正常路由到GGSN和手机终端，因此需要在防火墙的GI入口和出口两侧进行抓包分析，进而初步定界问题。
（5） 次日再次进行大量IPHONE主动测试，结果显示全部可以正常上网，且前日测试无法上网现象均无法再次复现；另外查看GGSN设备配置发现：3GNET APN的172.29.*.*地址池数据被删除，随后查看系统日志（OLG文件）发现GGSN地址池删除操作：
    综合以上分析，通过大量主动测试、IPHONE上网问题定界排除及信令跟踪定位，最终将IPHONE无法上网问题定界为GGSN以上的GI口防火墙侧IP路由配置问题。
     GI口防火墙未配置到GGSN的172.29地址段路由，导致DNS无法将172.29地址段的响应数据包通过防火墙路由到GGSN，而最终将GGSNv8地址池配置中172.29.*.*地址段删除后，用户在3GNET的APN下无法上网问题得到彻底解决。

建议与总结：
      在GGSN中配置APN对应的本地地址池过程中，GGSN与GI口防火墙侧的地址段对照关系需要严格匹配对应，谨防GGSN以上防火墙上漏配或错配IP地址段而导致用户无法上网。
另外，对于现网大量3G数据用户上网问题投诉，存在定位思路模糊不清，不能快速定位问题根源，无法快速找到解决方案等弱点，因而建立一套由无线至业软的端到端信令流程分析整体解决思路势在必行。
在3G用户上网问题定位中需要由结合无线、核心网SGSN、GGSN，甚至结合业软信令侧进行联合排查，并且按照用户数据业务流程中附着、PDP激活以至DNS查询等子流程进行分段排查，进行快速问题分析定位，快速解决3G用户上网问题。

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

hendouse

“在GGSN中配置APN对应的本地地址池过程中，GGSN与GI口防火墙侧的地址段对照关系需要严格匹配对应，谨防GGSN以上防火墙上漏配或错配IP地址段而导致用户无法上网。”   通过一次实际的事件，发现的问题解决点，不过这次问题的解决耗费了太多时间和人力的。但目前通信行业似乎没有更加有效的方法去解决，很多时候还是要通过无线侧不断测试，各接口同时挂表抓包的手段去分析与解决实际问题。    期待有更加快捷有效的方法出现。。。

xiner

回复 爱卫生 的帖子

如果在各接口都设置一个能接收测试ping的功能，此类问题就可以相对容易的定位

weishengzi

这个论坛太棒了，从没见过申请这么难的

scrapersky

恩，这个分析过程很有道理，谢谢