抓包工具在深圳联通移动分组网维护中的应用

爱卫生

   本文摘自《移动通信》杂志2011年第12期。

【作者】	刘志新
【作者单位】	中国联合网络通信有限公司深圳市分公司
【文献出处】	移动通信 , Mobile Communications, 编辑部邮箱 2011年 12期   期刊荣誉：ASPT来源刊  中国期刊方阵  CJFD收录刊
【中文关键词】	移动分组网; 抓包工具; IP报文; GGSN;
【摘要】	文章介绍了移动分组网维护工作中引入传统数通抓包工具软件的必要性,在简单介绍了抓包工具的常用功能后,结合深圳联通移动分组网维护中的实际案例,阐述了如何利用抓包工具的这些功能有效解决网管维护台难以定位的移动分组业务应用问题。
【更新日期】	2011-08-25

     全文如下：
1   引言
  移动分组技术（GPRS/3G PS）是移动通信与传统数据通信技术相结合的产物，因此业务使用中常见的故障无外乎由移动信令流程或由数据通信流程异常导致。目前移动分组设备厂家所提供的维护终端主要针对移动信令的接续流程，而对于信令接续完成后的数据传输及应用层出现的问题则无法进行直观分析判断。
   传统固网数通抓包工具软件在数传及应用层故障分析方面具有现网移动信令跟踪终端工具无法比拟的优势。本文将结合深圳联通移动分组网维护中的典型案例对抓包工具在分组维护中的应用做简要的介绍及探讨，旨在引导移动分组专业维护人员了解并掌握移动信令跟踪与传统抓包工具相结合的综合排障方法，及时发现并解决移动分组网设备、网络以及网元局数据存在的故障及隐患，从而提高实际移动分组网维护的效率，进而提高网络质量。

2   抓包工具在移动分组网维护中的引入
2.1 抓包工具引入背景
   移动分组网维护中常见的客户应用故障分为两大类：移动信令故障、数传及应用层故障。对于移动信令部分出现的问题，无论是会话管理（SM）还是移动性管理（MM）流程异常，利用核心网GSN或无线RNC设备的维护台通过信令跟踪可很容易得到定位。但对于那些移动信令交互正常，如终端可以正常完成附着、激活流程却仍然无法访问业务的故障，依靠移动分组设备的信令跟踪工具进行排查则会变得相当麻烦。终端在完成PDP激活后的数据传输出现问题时，只有对数传的IP报文、IP通信的交换过程甚至IP报文的L7层数据做深入解析后才能最终定位问题。而这正是传统固网数通故障排查中常用的抓包工具软件所独有的优势。
  移动分组业务在终端完成对网络的附着、PDP激活流程后，后续的业务访问流程与传统的数据通信过程基本相同，只是在SGSN与GGSN间传递的报文需要进行GTP的封装，在GTP隧道内完成传输。

2.2 抓包工具及其常用功能介绍
  抓包工具由于其可以对数据通信过程中的所有IP报文实施捕获并进行逐层拆包分析，一直是传统固网数通维护工作中最常用的故障排查工具。业内流行的抓包软件有很多：Wireshark、Sniffer Pro、Snoop以及Tcpdump等。各抓包软件除界面、应用平台稍有差别外，基本功能大同小异，本文以目前流行的Wireshark软件为例进行分析。
  抓包工具常用数通分析功能有：
（1）TCP/UDP/ICMP等报文交互过程分析
  这是抓包工具最基本的功能，此处不再详述。
（2）数据包传输时延分析
  抓包工具支持记录每一抓取报文的时间点，还支持用任一报文与前一报文的时间差来作为记录报文抓取的时间点。据此可以实现对特定时间点报文的分析和对节点转发报文时延的计算。
（3）L3～L7层IP数据报文分析
  实现对IP报文的L3层IP地址头、L4层TCP/UDP头直到L7层的内部信息的直观分析。
（4）数传丢包分析
  通过比对某节点进出两侧的抓包的IP报文中经节点转发后保持不变的Identification字段，或者利用TCP通信的SEQ及ACK序列号分析节点或链路丢包情况，可分析判断转发报文的设备（路由器、交换机、SGSN、GGSN）是否发生了故障或出现了报文转发瓶颈。

2.3 移动分组网中抓包文件获取方法
  移动分组网中抓包文件的常用获取方法有如下几种：
（1）转换工具：利用厂家提供的转换工具对移动分组设备（GSN）的维护台跟踪得到的信令文件实施转换，得到抓包文件。目前移动分组网设备厂家基本都提供了类似的工具软件，其中华为公司提供的转包工具还支持对某台设备上跟踪到的信令文件分in方向（Gn接口→GGSN）和out方向（GGSN→Gi接口）分别提取转换，此功能极大地方便了对GSN设备丢包问题的分析。
（2）端口镜像：如分组设备厂家未提供转换工具，则必须自行在分组设备接入的数通设备上采用端口镜像的方式进行抓包获取。端口镜像就是将被监控端口上的数据复制到指定的监控端口，对数据进行分析和监视。在使用抓包终端抓包时，需要将安装有抓包软件的主机的抓包网卡连接到监控端口，来捕获流经被监控端口的数据包。交换机端口镜像的配置方法随不同厂商、不同型号的交换机而有所区别，具体方法请查阅具体设备的指导手册。

2.4 抓包工具应用条件
   在实际故障排查中，并非任何故障定位都需要开启抓包工具进行分析。启用抓包分析手段的前提是：利用信令跟踪排除了移动分组信令接续异常（无法附着、无法激活等MM及SM流程异常）导致的故障，即终端成功激活并获取到了GGSN分配的IP地址但访问业务失败，需要进一步对数传过程及IP报文做深入分析才能定位故障。当然在利用抓包工具分析过程中，仍然需要考虑具体的通信过程是否与移动分组的信令接续有相关性，两者结合全面分析才能得出正确的结果。

3  抓包工具在深圳联通移动分组网维护中的实践
3.1 L3层数传报文分析的应用
（1）终端设备APN设置错误导致无法上网
   实例1：北京一漫游至深圳区域的上网卡可以正常激活，但无法上网。核心网GSN设备维护台信令跟踪显示MM信令、SM信令均正常，但PDP激活后在GSN设备上有上行报文（GGSN：有去往Gi接口的报文；SGSN：有SGSN→GGSN的报文）无下行报文，最终用户无法上网主动去激活PDP。
  分析过程：根据信令无法判断问题的原因，问题应该出在数传上。通过抓包工具来分析用户的上述上网行为发现：客户所有的上网报文均是被发送给了IP为10.0.0.172的主机，该IP恰好是联通WAP网关的IP。北京上网卡的GPRS签约都是uninet/3gnet 2个APN，用户激活都应直接送往Gi侧的公网IP地址才对，为何此处用户报文却被送至了WAP网关的IP？结合前面的MM/SM信令信息，发现用户激活时终端送给SGSN的APN为3gwap，而SGSN发给GGSN的激活请求中的APN实际被SGSN纠错成了3gnet（符合现网SGSN配置的纠错规则）。
  至此，问题的原因得到定位：用户在上网卡激活时采用了设置代理服务器（IP为10.0.0.172）的3gwap APN，而由于该卡的签约APN仅有2个：3gnet（context id=1）及uninet（context id=2），于是启用了域名纠错机制的H公司的SGSN对终端送上来的未签约的3gwap进行了纠错，修改成HLR签约中context id较小的3gnet并激活。尽管用户采用未签约的APN成功PDP激活并获取了GGSN分配的IP地址，但由于终端中设置有代理服务器，因此所有上网请求报文都被终端送往在Gi侧实际不存在的10.0.0.172主机。

（2）内容计费匹配规则验证及故障排查
  实例2：新推的3G预付上网卡业务陆续接到客户投诉，反映访问部分网站的页面（QQ空间、bbs.55168.com等）会立即掉线（终端侧显示PDP自动去激活），每次都需要手动再次“拨号”重连网络，客户对此非常不满而要求退卡。
   分析过程：在GGSN维护台信令跟踪结果如图1所示，预付用户在业务使用过程中访问某网站时触发了rating-group=839712775的业务，GGSN于是向OCS系统申请该业务的配额，但OCS却返回了无法成功实施计费的result-code 5031，GGSN因此去激活了该PDP。查询SCP系统，客户账户中仍有70元余额，并且客户访问绝大多数网站都不会有此问题发生。经核对发现该RG值所对应的是前不久新开启的SP-N业务的RG，但客户实际访问的网站并不属于SP-N。

图1 OCS返回配额分配失败

  对客户访问bbs.55168.com页面时触发掉线的报文利用抓包工具进行分析（图2），序列号为75～77的3个包是终端在被GGSN去激活前的最后3个报文。可以看到终端在访问bbs.55168.com页面过程中主动发起对sz7.cnzz.com的TCP连接，首先通过域名解析获取到s27.cnzz.com的IP为58.248.245.14，然后再发起至该IP的TCP握手包。正是77号报文触发了RG=839712775的计费业务配额申请导致了计费失败，最终引起GGSN去活PDP连接。

图2 PDP被去活前抓包结果

   经查，域名为s27.cnzz.com的网站为一统计服务提供商的web页面，其通过向其他ICP收费提供内嵌代码的方式为其他ICP提供网站访问统计服务。而核对GGSN所配置的SP-N的内容计费规则后，发现之前SP-N的内容计费IP地址范围设置过大（1个C类IP段），误将上述网站包含了进去；另外，OCS系统维护人员也证实该SP-N的RG尚未在OCS侧做配置。
  至此，预付卡掉线原因通过抓包工具查明：预付卡终端激活后访问并打开了内嵌有s27.cnzz.com统计代码的页面，终端侧页面自动触发对该统计网站服务器的访问，而该网站的IP由于被错误配置进了SP-N的业务IP段进而触发了GGSN系统向OCS系统申请该RG的配额。但OCS尚未完成该业务的配置，因此GGSN在收到计费失败的CODE值后去活了连接。
  此外，在日常内容计费规则的配置中也常利用抓包工具对配置的计费规则实施验证及错误排查。

3.2 报文间转发时延的应用
   实例3：2009年11月陆续接到分组用户反映：20:00以后，HSDPA上网速度不稳定，该时段上网最高速度也仅100kb/s；21:00～23:00网速更是奇慢无比，连接速度只有几kb/s，终端ping公网时延约500ms～4000ms，并伴随有丢包发生。而正常情况下，在信号覆盖正常区域HSDPA的速率应为2Mb/s。

   分析过程：在业务异常时段用上网卡拨测并进行信令跟踪，信令显示终端可以正常附着并激活，且GSN设备也有正常转发的上下行数据报文。由于现网GSN设备厂家的维护台所支持的信令跟踪时间粒度仅能到秒级，因此从维护台跟踪的信令除可判断出移动分组接续信令正常外，无法分析数传慢的问题所在。
   我们知道，最简单用于定位导致访问时延过大节点的方法是逐段ping包，但因SGSN、GGSN设备均无可用于终端ping测的近用户侧的用户面IP，所以用户端所能ping测的最近IP是GGSN Gi接口IP。实际测试终端ping至Gi接口的时延已达500ms～4000ms，仅能证实故障点在Gi接口以内，包括无线侧、SGSN、Gn承载网以及GGSN设备。由于故障复现时整网不同无线覆盖区域均有客户反映该问题，因而无线的因素可直接排除；通过在GSN的GTP用户面间的ICMP包测试也很容易排除了Gn承载网的问题。
   于是将GGSN设备跟踪的信令数据进行转包，借助于抓包工具来深入分析GGSN设备上报文转发是否异常。为简化报文分析的难度，利用抓包工具的过滤器将在用户端ping Gi接口的ICMP报文过滤出（如图3）。图3中连续的包1“GTP<ICMP> Echo(ping) request”、包2“ICMP Echo(ping) request”的Identification字段相同，可知这两个报文是同一报文。包1是GGSN接收的用户端发出经SGSN做GTP封装后转发上来的GTP-U包，包2则是GGSN内部完成解包、内容计费处理后转交至Gi接口的报文。此处将抓包工具中time字段的显示方式调整为与前一捕获到的报文的时差即可看到，包2与包1存在约4.194305秒的转发时延，而这就是一个ICMP Echo request报文在GGSN内的转发时延。类似分析其余来自SGSN的GTP报文在GGSN内的转发时延，均约4秒。而自Gi经GGSN转发至Gn侧的报文则几乎都是无时延立即完成转发（时延都约0秒）。至此，导致业务异常慢的故障点已找到，正是由于GGSN设备的上行报文转发出现了故障所致。

图3 GGSN设备报文转发抓包结果

   该问题提交给GGSN厂家研发分析后得出真正的原因所在：GGSN设备上内容计费规则匹配过宽。由于计费规则误配了对所有报文实施内容计费的检测，导致在业务忙时段系统对过多的上行报文进行内容计费的深度检测，使得系统业务处理卡负荷过高引起了故障的发生。而下行报文由于在GGSN内部仅是做表项匹配而不再进行深度检测，因此可以得到实时转发。
   在调整内容计费规则后，在业务忙时段再无异常出现。

3.3 L7层数据报文分析的应用
   实例4：某用户投诉使用联通定制的NOKIA 6210SI无法登陆公司的南广卫视页面，而访问其他页面及应用都无任何问题，用户终端更换了不同浏览器尝试都存在该问题。
  分析过程：用户访问其他页面及应用都正常，排除了用户无法附着、无法激活的问题。原因应该出在数传或应用层，只有依靠抓包工具进行定位。通过抓包发现用户的NOKIA 6210SI终端发出的L7层URL存在异常，无论用户使用wap还是net APN，终端所发出的http get数据所含的URL u.3gtv.net后都多了一个后缀“/favicon.ico”。而“u.3gtv.net/favicon.ico”是不存在的URL，每次访问必然失败。因此问题产生的原因是该终端自身系统存在bug。

3.4  TCP连接信息分析的应用
  实例5：某用户投诉使用联通3G上网卡无法打开英文yahoo网站上的视频，提示“页面无法显示”，但其他应用正常，客户要求对此给出合理解释否则退网。
  分析过程：首先核实确认yahoo中的视频连接及IP均未在工信部下发的涉黄等封锁范围中，而且结合客户访问yahoo视频时的页面提示信息可知，yahoo视频无法访问并非核心网侧wap网关及Gi防火墙限制所致。此问题定位唯一可用的方法就是分析访问过程中的抓包文件（图4）。

图4 无法访问yahoo视频抓图一

   图4中，报文3～7显示终端在成功通过DNS解析到video.yahoo.com的IP后，发起TCP三步握手的过程，报文8则是终端点击访问其中一个具体的视频连接的http get数据包（seq=1、ack=1、Len=565）。按照TCP/IP协议要求，TCP连接建立后的数传序列号及确认号应该如下：
（1）发送数据：A向B发送一个带有数据的数据包，该数据包中的序列号和确认号与建立连接第三步的数据包中的序列号和确认号相同；
（2）确认收到：B收到该数据包，向A发送一个确认数据包。该数据包中，序列号是上一个数据包中的确认号值，而确认号=A发送的上一个数据包中的序列号+该数据包中所带数据的大小。
   根据协议规定可知，后续服务器66.163.168.216应返回的确认报文：seq=1,ack=1+565=566。但实际后续抓包得到的服务器返回报文9～12的序列号是随机的，确认号也不符合协议规定，而且返回报文都是异常中止TCP连接RST报文。直到报文13我们才看到符合协议规定的ACK报文，但由于此前的RST报文中止了TCP连接，导致后续视频信息无法得到正常传输。
   服务器侧为何在正常TCP握手完毕后突然发起RST报文中止会话呢？对比符合协议规定的报文13与此前TCP握手中服务器返回的SYN报文的TTL，发现二者是一致的，均是53（见图5）。

图5 无法访问yahoo视频抓图二

   而“非法”报文9～12的TTL则为112、118及57等。我们知道，TTL值反映的是报文自源去往目的地中间所经过的路由器个数，通常情况下数据报文正常路由转发所经的路由器间隔是一致的，即使存在多路由的情况，跳数也不会相差太多。但报文9～12的TTL与符合协议规定的报文TTL相差过于悬殊，因此可判断这几个报文并非来自真正的视频服务器，应该是网络中间某种设备拦截所致。经过解释，客户最终认可了我们的分析。

   

3.5 利用抓包工具进行节点丢包问题的分析
   原理说明：IP头具有2个字节的Identification用于标识每个IP报文。对于IP报文，其ID在整个传输过程中是唯一的，因此通过比较出入该节点报文的ip id的一致性即可判断节点是否存在转发丢包问题。如考察GGSN是否在转发过程有丢包，可将Gn和Gi接口ip id进行比较，分析入GGSN和出GGSN的报文是否完全一致。
   实例6：2010年7月份陆续接到客户报障，反映使用3G预付上网卡进行基于UDP的SKYPE、QQ语音等即时通讯软件的语音视频通信，每次通话在持续2～4分钟后必定会发生断线问题，但网络连接未中断（PDP会话并未去激活）。该问题严重影响客户的日常应用。
   分析过程：分别对预付及后付卡进行业务测试，发现现网确实存在客户反馈的问题，但仅发生在预付卡业务上。SGSN不会因用户计费属性不同而有不同处理机制，但GGSN对于预付及后付的业务实现过程因GY接口而存在差异。据此可以排除核心网SGSN设备的因素，问题应该与GGSN设备有关。在粗略分析定位故障设备后，再利用抓包工具结合Ultra Edit及文本比较软件等辅助工具进行深入剖析。
（1）首先在拨测中故障复现时，抓取测试号码在GGSN in及out方向的所有报文。
（2）使用Wireshark的过滤规则将需要的报文过滤出来：
Exip==112.97.129.98)&&(ip==220.198.162.130)
（3）用Wireshark打开报文，随意选中某个报文，展开并选中IP层。
（4）IP层保存到文本文件中，将GGSN in及out方向的两份抓包文件分别转换为解析IP层的文本文件。选择Wireshark的File→Print。
（5）打开打印出的文件，利用Ultra Edit选中Identification关键字，并利用其文本抽取功能将所有带有Identification的行，从剪贴板拷贝至另外的文件（ex:ggsn-in/ggsn-out）。
（6）使用文本比较工具将两个抓包文件的导出文件进行比较。
   根据对比结果可以看到，客户即时通信业务中断，是由于GGSN出现了转发丢包引起的。将该问题提交厂家研发后，确认为系统异常所致。

4   结束语
   作为3G市场最具特色的产品，移动分组业务必然是客户关注的焦点之一，这也对移动分组网络维护水平、维护效率提出了更高的要求。本文结合深圳联通移动分组网维护中的实例，对抓包工具的几种常用功能在移动分组网维护工作中的用法及问题分析的思路作了介绍，希望为移动分组网的建设与维护人员提供一定的借鉴。

                                                  参考文献
[1]Richard Sharpe. Wireshark User's Guide[G]. 2010.
[2]张明和. 抓包软件Wireshark安装和应用指导书[G]. 2008.
[3]W Richard Stevens. TCP/IP详解卷1：协议[M]. 北京: 机械工业出版社,2000.  ★

gpf_gprs2012

很不错，学习学习

yonka

GGSN这一段就靠IP靠的较近了~

gprssanling

yonka 发表于 2012-8-9 14:51
GGSN这一段就靠IP靠的较近了~

IP只是传输，重点在业务、应用。

ccc123

不错啊，多谢了。

ccc123

非常感谢。。。