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

1、    抓包工具在深圳联通移动分组网维护中的应用    刘志新摘 要 文章介绍了移动分组网维护工作中引入传统数通抓包工具软件的原因及必要性；并且在简单介绍了抓包工具的常用功能后，结合深圳联通移动分组网维护中的实际案例，讲解了如何利用抓包工具的这些功能有效解决网管维护台难以定位的移动分组业务应用问题。关键词 移动分组网 抓包工具 维护1 引言移动分组技术（gprs/3g ps）是移动通信与传统数据通信技术相结合的产物，因此业务使用中常见的故障无外乎由移动信令流程或由数据通信流程异常导致。目前移动分组设备厂家所提供的维护终端主要针对移动信令的接续流程，而对于

2、信令接续完成后的数据传输及应用层出现的问题定位则无法进行直观分析判断。然而传统固网数通抓包工具软件在数传及应用层故障分析方面具有现网移动信令跟踪终端工具无法比拟的优势。本文结合深圳联通移动分组网维护中的典型案例对抓包工具在分组维护中的应用做简要的介绍及探讨。旨在引导移动分组专业维护人员了解并掌握移动信令跟踪与传统抓包工具相结合的综合排障方法，从而提高实际移动分组网维护的效率，及时发现并解决移动分组网设备、网络以及网元局数据存在的故障及隐患，进而提高我们的网络质量。2 抓包工具在移动分组网维护中的引入2.1 抓包工具引入背景移动分组网维护中常见的客户应用故障为分两大类：移动信令故障、数传及应用层

3、故障。对于移动信令部分出现的问题，无论是会话管理（sm）还是移动性管理（mm）流程异常，利用核心网gsn或无线rnc设备的维护台通过信令跟踪可很容易得到定位。但对于那些移动信令交互正常，如终端可以正常完成附着、激活流程却仍然无法访问业务的故障，依靠移动分组设备的信令跟踪工具进行排查则会变得相当麻烦。终端在完成pdp激活后的数据传输出现问题时，只有对数传的ip报文、ip通信的交换过程甚至ip报文的l7层数据做深入解析后才能最终定位问题的根由。而这正是传统固网数通故障排查中常用的抓包工具软件所独有的优势。移动分组业务在终端完成对网络的附着、pdp激活流程后，后续的业务访问流程与传统的数据通信过程基

4、本相同。只是在sgsn与ggsn间传递的报文需要进行gtp的封装，在gtp隧道内完成传输。2.2 抓包工具介绍及其常用功能抓包工具常用数通分析功能有：（1）tcp /udp/icmp等报文交互过程分析。这是抓包工具最基本的功能，不详述。（2）数据包传输时延分析。抓包工具支持记录每一抓取报文的时间点，还支持用任一报文与前一报文的时间差来作为记录报文抓取的时间点。据此我们可以实现对特定时间点报文的分析或者实现对节点转发报文时延的计算。（3）l3-l7层ip数据报文分析。实现对ip报文的l3层ip地址头、l4层tcp/udp头直到l7层的内部信息进行直观分析。（4）数传丢包分析。根据某节点进出两侧的

5、抓包对比，通过比对ip报文中经节点转发后保持不变的identification字段；或则利用tcp通信的seq及ack序列号分析节点或链路丢包情况。依据此功能我们可分析判断转发报文的设备（路由器、交换机、sgsn、ggsn）是否发生了故障或出现了报文转发瓶颈。2.3 移动分组网中抓包文件获取方法移动分组网中抓包文件的常用获取方法有如下几种：（1）转换工具：利用厂家提供的转换工具对移动分组设备（gsn）的维护台跟踪得到的信令文件实施转换，得到抓包文件。目前移动分组网设备厂家基本都提供了类似的工具软件用于实现对维护台跟踪文件的转换。其中华为公司提供的转包工具还支持对某台设备上跟踪到的信令文件区分i

6、n方向（gn接口ggsn）以及out方向（ggsn->gi接口）的抓包数据分别提取转换，此功能极大的方便了对于gsn设备丢包问题的分析。（2）端口镜像：如分组设备厂家未提供此类工具，则必须自行在分组设备接入的数通设备上采用端口镜像的方式进行抓包获取。端口镜像就是将被监控端口上的数据复制到指定的监控端口，对数据进行分析和监视。在使用抓包终端抓包时，需要将安装有抓包软件的主机的抓包网卡连接到监控端口，来捕获流经被监控端口的数据包。交换机端口镜像的配置方法会随不同厂商、不同型号的交换机而有所区别，具体方法请查阅具体设备的指导手册。2.4 抓包工具应用条件在实际故障排查中并非任何故障定位都需要开

7、启抓包工具进行分析。启用抓包分析手段的前提是：利用信令跟踪排除了移动分组信令接续异常（无法附着、无法激活等mm及sm流程异常）导致的故障后，即终端成功激活并获取到了ggsn分配的ip地址但访问业务失败，需要进一步对数传过程及ip报文做深入分析才能定位故障时启用。当然在利用抓包工具分析过程中，仍然需要根据具体的通信过程是否与移动分组的信令接续有相关性，两者相辅相成全面分析才能得出正确的结果。3 抓包工具在深圳联通移动分组网维护中的实践3.1 l3层数传报文分析的应用3.2 报文间转发时延的应用实例3：09年11月陆续接到大量分组用户反映“晚上20：00以后，hsdpa上网速度不稳定，该时段上网最

8、高速度也仅100kb/s，且经常会降至100kbit/s。到晚上21点至23点这段时间速度则奇慢无比，连接速度只有几kb/s，终端ping公网时延约500-4000ms并伴随有丢包发生”。而正常情况下在信号覆盖正常区域hsdpa的速度应为2mbit/s。分析：在业务异常时段用上网卡拨测并进行了信令跟踪（图5），信令显示终端可以正常附着并激活，且gsn设备也有正常转发的上下行数据报文。由于现网gsn设备厂家的维护台所支持的信令跟踪时间粒度仅能到秒级别，因此从维护台跟踪的信令除可判断出移动分组接续信令正常外，无法分析数传慢的问题所在。我们知道最简单用于定位导致访问时延过大节点的方法是通过逐段pin

9、g包的方式去排查，但因sgsn、ggsn设备均无可用于终端ping测的近用户侧的用户面ip，所以用户端所能ping 测的最近ip是ggsn gi接口ip（如图6）。实际测试终端ping至gi接口的时延已达500-4000ms，仅能证实故障点在gi接口以内包括无线侧、sgsn、gn承载网以及ggsn设备的范围。由于故障复现时整网不同无线覆盖区域均有客户反映该问题，因而无线的因素可直接排除；通过自gsn的gtp用户面间的icmp包测试也很容易排除了gn承载网的问题。于是我们将ggsn设备跟踪的信令数据进行转包，借助于抓包工具来深入分析ggsn设备上报文报文转发时是否异常。为简化报文分析的难度，我们

10、利用抓包工具的过滤器将我们自用户端ping gi接口的icmp报文过滤出（如图7）。图7中连续的包1“gtp 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

11、内的转发时延。类似分析其余来自sgsn的gtp报文在ggsn内的转发时延均约4秒左右。而自gi经ggsn转发至gn 侧的报文则几乎都是无时延立即完成转发（时延都约0秒）。至此，导致业务异常慢的故障点已找到，正是ggsn设备的上行报文转发出现了故障所致。该问题提交ggsn厂家研发分析后得出真正的问题根结： ggsn 设备上内容计费规则匹配过大。由于计费规则误配了对所有报文实施内容计费的检测，导致在业务忙时段系统对过多的上行报文都需要进行内容计费的深度检测，使得系统业务处理卡负荷过高引起了故障的发生。而下行报文由于在ggsn内部仅是做表项匹配而不再进行深度检测，因此可以得到实时转发。在调整内容计费

12、规则后，在业务忙时段再无异常出现。3.3 l7层数据报文分析的应用3.4 tcp 连接信息分析的应用根据协议规定可知，后续服务器66.163.168.216应返回的确认报文 seq=1，ack=1+565=566。但实际后续抓包得到的服务器返回报文912的序列号是随机的、确认号也不符合协议规定，而且返回报文都是异常中止tcp连接rst报文。直到报文13我们才看到符合协议规定的ack报文，但由于此前的rst报文中止了tcp连接导致后续视频信息无法得到正常传输而失败。服务器侧为何在正常tcp握手完毕后突然发起rst报文中止会话呢？对比符合协议规定的报文13与此前tcp握手中服务器返回的syn报文的

13、ttl 我们会发现二者是一致的均是53（见图10）。而“非法”报文9-12的ttl则为112、118及57不等，我们知道ttl值反映的是报文自源去往目的地中间所经过的路由器个数。通常情况下数据报文正常路由转发所经的路由器间隔是一致的，即使存在多路由的情况跳数也不会相差太多。但报文9-12的ttl与符合协议规定的报文ttl相差过于悬殊，因此可判断这几个报文并非来自真正视频服务器，应该是网络中间某种设备拦截所致。通过向客户解释该问题发生的原因，客户最终认可了我们的分析。3.5 利用抓包工具进行节点丢包问题的分析4 结束语随着2009年中国3g业务牌照的发放，国内3家运营商正式逐鹿3g市场。作为3g市场最具特色产品移动分组业务必然是客户关注的焦点之一，因此这也对移动分组网络维护水平、维护效率提出更高的要求。文章结合深圳联通移动分组网维护中的实例，对抓包工具的几种常用功能在移动分组网维护工作中的用途、用法以及问题分析的思路做了介绍。希望为移动分组