抓包工具在深圳聯(lián)通移動(dòng)分組網(wǎng)維護(hù)中的應(yīng)用

劉志新

摘 要 文章介紹了移動(dòng)分組網(wǎng)維護(hù)工作中引入傳統(tǒng)數(shù)通抓包工具軟件的原因及必要性；并且在簡單介紹了抓包工具的常用功能后，結(jié)合深圳聯(lián)通移動(dòng)分組網(wǎng)維護(hù)中的實(shí)際案例，講解了如何利用抓包工具的這些功能有效解決網(wǎng)管維護(hù)臺難以定位的移動(dòng)分組業(yè)務(wù)應(yīng)用問題。

關(guān)鍵詞 移動(dòng)分組網(wǎng) 抓包工具 維護(hù)

1 引言

移動(dòng)分組技術(shù)（GPRS/3G PS）是移動(dòng)通信與傳統(tǒng)數(shù)據(jù)通信技術(shù)相結(jié)合的產(chǎn)物，因此業(yè)務(wù)使用中常見的故障無外乎由移動(dòng)信令流程或由數(shù)據(jù)通信流程異常導(dǎo)致。目前移動(dòng)分組設(shè)備廠家所提供的維護(hù)終端主要針對移動(dòng)信令的接續(xù)流程，而對于信令接續(xù)完成后的數(shù)據(jù)傳輸及應(yīng)用層出現(xiàn)的問題定位則無法進(jìn)行直觀分析判斷。然而傳統(tǒng)固網(wǎng)數(shù)通抓包工具軟件在數(shù)傳及應(yīng)用層故障分析方面具有現(xiàn)網(wǎng)移動(dòng)信令跟蹤終端工具無法比擬的優(yōu)勢。

本文結(jié)合深圳聯(lián)通移動(dòng)分組網(wǎng)維護(hù)中的典型案例對抓包工具在分組維護(hù)中的應(yīng)用做簡要的介紹及探討。旨在引導(dǎo)移動(dòng)分組專業(yè)維護(hù)人員了解并掌握移動(dòng)信令跟蹤與傳統(tǒng)抓包工具相結(jié)合的綜合排障方法，從而提高實(shí)際移動(dòng)分組網(wǎng)維護(hù)的效率，及時(shí)發(fā)現(xiàn)并解決移動(dòng)分組網(wǎng)設(shè)備、網(wǎng)絡(luò)以及網(wǎng)元局?jǐn)?shù)據(jù)存在的故障及隱患，進(jìn)而提高我們的網(wǎng)絡(luò)質(zhì)量。

2 抓包工具在移動(dòng)分組網(wǎng)維護(hù)中的引入

2.1 抓包工具引入背景

移動(dòng)分組網(wǎng)維護(hù)中常見的客戶應(yīng)用故障為分兩大類：移動(dòng)信令故障、數(shù)傳及應(yīng)用層故障。對于移動(dòng)信令部分出現(xiàn)的問題，無論是會話管理（SM）還是移動(dòng)性管理（MM）流程異常，利用核心網(wǎng)GSN或無線RNC設(shè)備的維護(hù)臺通過信令跟蹤可很容易得到定位。但對于那些移動(dòng)信令交互正常，如終端可以正常完成附著、激活流程卻仍然無法訪問業(yè)務(wù)的故障，依靠移動(dòng)分組設(shè)備的信令跟蹤工具進(jìn)行排查則會變得相當(dāng)麻煩。終端在完成PDP激活后的數(shù)據(jù)傳輸出現(xiàn)問題時(shí)，只有對數(shù)傳的IP報(bào)文、IP通信的交換過程甚至IP報(bào)文的L7層數(shù)據(jù)做深入解析后才能最終定位問題的根由。而這正是傳統(tǒng)固網(wǎng)數(shù)通故障排查中常用的抓包工具軟件所獨(dú)有的優(yōu)勢。

移動(dòng)分組業(yè)務(wù)在終端完成對網(wǎng)絡(luò)的附著、PDP激活流程后，后續(xù)的業(yè)務(wù)訪問流程與傳統(tǒng)的數(shù)據(jù)通信過程基本相同。只是在SGSN與GGSN間傳遞的報(bào)文需要進(jìn)行GTP的封裝，在GTP隧道內(nèi)完成傳輸。

2.2 抓包工具介紹及其常用功能

抓包工具常用數(shù)通分析功能有：（1）TCP /UDP/ICMP等報(bào)文交互過程分析。這是抓包工具最基本的功能，不詳述。（2）數(shù)據(jù)包傳輸時(shí)延分析。抓包工具支持記錄每一抓取報(bào)文的時(shí)間點(diǎn)，還支持用任一報(bào)文與前一報(bào)文的時(shí)間差來作為記錄報(bào)文抓取的時(shí)間點(diǎn)。據(jù)此我們可以實(shí)現(xiàn)對特定時(shí)間點(diǎn)報(bào)文的分析或者實(shí)現(xiàn)對節(jié)點(diǎn)轉(zhuǎn)發(fā)報(bào)文時(shí)延的計(jì)算。（3）L3-L7層IP數(shù)據(jù)報(bào)文分析。實(shí)現(xiàn)對IP報(bào)文的L3層IP地址頭、L4層TCP/UDP頭直到L7層的內(nèi)部信息進(jìn)行直觀分析。（4）數(shù)傳丟包分析。根據(jù)某節(jié)點(diǎn)進(jìn)出兩側(cè)的抓包對比，通過比對IP報(bào)文中經(jīng)節(jié)點(diǎn)轉(zhuǎn)發(fā)后保持不變的Identification字段；或則利用TCP通信的SEQ及ACK序列號分析節(jié)點(diǎn)或鏈路丟包情況。依據(jù)此功能我們可分析判斷轉(zhuǎn)發(fā)報(bào)文的設(shè)備（路由器、交換機(jī)、SGSN、GGSN）是否發(fā)生了故障或出現(xiàn)了報(bào)文轉(zhuǎn)發(fā)瓶頸。

2.3 移動(dòng)分組網(wǎng)中抓包文件獲取方法

移動(dòng)分組網(wǎng)中抓包文件的常用獲取方法有如下幾種：（1）轉(zhuǎn)換工具：利用廠家提供的轉(zhuǎn)換工具對移動(dòng)分組設(shè)備（GSN）的維護(hù)臺跟蹤得到的信令文件實(shí)施轉(zhuǎn)換，得到抓包文件。目前移動(dòng)分組網(wǎng)設(shè)備廠家基本都提供了類似的工具軟件用于實(shí)現(xiàn)對維護(hù)臺跟蹤文件的轉(zhuǎn)換。其中華為公司提供的轉(zhuǎn)包工具還支持對某臺設(shè)備上跟蹤到的信令文件區(qū)分IN方向（Gn接口→GGSN）以及OUT方向（GGSN->GI接口）的抓包數(shù)據(jù)分別提取轉(zhuǎn)換，此功能極大的方便了對于GSN設(shè)備丟包問題的分析。（2）端口鏡像：如分組設(shè)備廠家未提供此類工具，則必須自行在分組設(shè)備接入的數(shù)通設(shè)備上采用端口鏡像的方式進(jìn)行抓包獲取。端口鏡像就是將被監(jiān)控端口上的數(shù)據(jù)復(fù)制到指定的監(jiān)控端口，對數(shù)據(jù)進(jìn)行分析和監(jiān)視。在使用抓包終端抓包時(shí)，需要將安裝有抓包軟件的主機(jī)的抓包網(wǎng)卡連接到監(jiān)控端口，來捕獲流經(jīng)被監(jiān)控端口的數(shù)據(jù)包。交換機(jī)端口鏡像的配置方法會隨不同廠商、不同型號的交換機(jī)而有所區(qū)別，具體方法請查閱具體設(shè)備的指導(dǎo)手冊。

2.4 抓包工具應(yīng)用條件

在實(shí)際故障排查中并非任何故障定位都需要開啟抓包工具進(jìn)行分析。啟用抓包分析手段的前提是：利用信令跟蹤排除了移動(dòng)分組信令接續(xù)異常（無法附著、無法激活等MM及SM流程異常）導(dǎo)致的故障后，即終端成功激活并獲取到了GGSN分配的IP地址但訪問業(yè)務(wù)失敗，需要進(jìn)一步對數(shù)傳過程及IP報(bào)文做深入分析才能定位故障時(shí)啟用。當(dāng)然在利用抓包工具分析過程中，仍然需要根據(jù)具體的通信過程是否與移動(dòng)分組的信令接續(xù)有相關(guān)性，兩者相輔相成全面分析才能得出正確的結(jié)果。

3 抓包工具在深圳聯(lián)通移動(dòng)分組網(wǎng)維護(hù)中的實(shí)踐

3.1 L3層數(shù)傳報(bào)文分析的應(yīng)用

3.2 報(bào)文間轉(zhuǎn)發(fā)時(shí)延的應(yīng)用

實(shí)例3：09年11月陸續(xù)接到大量分組用戶反映“晚上20：00以后，HSDPA上網(wǎng)速度不穩(wěn)定，該時(shí)段上網(wǎng)最高速度也僅100KB/S，且經(jīng)常會降至100Kbit/s。到晚上21點(diǎn)至23點(diǎn)這段時(shí)間速度則奇慢無比，連接速度只有幾KB/S，終端ping公網(wǎng)時(shí)延約500---4000ms并伴隨有丟包發(fā)生”。而正常情況下在信號覆蓋正常區(qū)域HSDPA的速度應(yīng)為2Mbit/s。

分析：在業(yè)務(wù)異常時(shí)段用上網(wǎng)卡撥測并進(jìn)行了信令跟蹤（圖5），信令顯示終端可以正常附著并激活，且GSN設(shè)備也有正常轉(zhuǎn)發(fā)的上下行數(shù)據(jù)報(bào)文。由于現(xiàn)網(wǎng)GSN設(shè)備廠家的維護(hù)臺所支持的信令跟蹤時(shí)間粒度僅能到秒級別，因此從維護(hù)臺跟蹤的信令除可判斷出移動(dòng)分組接續(xù)信令正常外，無法分析數(shù)傳慢的問題所在。

我們知道最簡單用于定位導(dǎo)致訪問時(shí)延過大節(jié)點(diǎn)的方法是通過逐段ping包的方式去排查，但因SGSN、GGSN設(shè)備均無可用于終端ping測的近用戶側(cè)的用戶面IP，所以用戶端所能ping 測的最近IP是GGSN GI接口IP（如圖6）。實(shí)際測試終端ping至GI接口的時(shí)延已達(dá)500-4000ms，僅能證實(shí)故障點(diǎn)在GI接口以內(nèi)包括無線側(cè)、SGSN、Gn承載網(wǎng)以及GGSN設(shè)備的范圍。由于故障復(fù)現(xiàn)時(shí)整網(wǎng)不同無線覆蓋區(qū)域均有客戶反映該問題，因而無線的因素可直接排除；通過自GSN的GTP用戶面間的icmp包測試也很容易排除了Gn承載網(wǎng)的問題。

于是我們將GGSN設(shè)備跟蹤的信令數(shù)據(jù)進(jìn)行轉(zhuǎn)包，借助于抓包工具來深入分析GGSN設(shè)備上報(bào)文報(bào)文轉(zhuǎn)發(fā)時(shí)是否異常。為簡化報(bào)文分析的難度，我們利用抓包工具的過濾器將我們自用戶端ping Gi接口的ICMP報(bào)文過濾出（如圖7）。圖7中連續(xù)的包1“GTP Echo（ping） request”、包2“ICMP Echo（ping） request“的Identification字段相同可知這兩個(gè)報(bào)文是同一報(bào)文。包1是GGSN接收的用戶端發(fā)出經(jīng)SGSN 做GTP封裝后轉(zhuǎn)發(fā)上來的GTP-U包，包2則是GGSN內(nèi)部完成解包、內(nèi)容計(jì)費(fèi)處理后轉(zhuǎn)交至GI接口的報(bào)文。此處我們將抓包工具中time字段的顯示方式調(diào)整為與前一捕獲到報(bào)文的時(shí)差即可看到，包2與包1存在約4.194305秒的轉(zhuǎn)發(fā)時(shí)延，而這就是一個(gè)ICMP echo request報(bào)文在GGSN內(nèi)的轉(zhuǎn)發(fā)時(shí)延。類似分析其余來自SGSN的GTP報(bào)文在GGSN內(nèi)的轉(zhuǎn)發(fā)時(shí)延均約4秒左右。而自GI經(jīng)GGSN轉(zhuǎn)發(fā)至GN 側(cè)的報(bào)文則幾乎都是無時(shí)延立即完成轉(zhuǎn)發(fā)（時(shí)延都約0秒）。至此，導(dǎo)致業(yè)務(wù)異常慢的故障點(diǎn)已找到，正是GGSN設(shè)備的上行報(bào)文轉(zhuǎn)發(fā)出現(xiàn)了故障所致。

該問題提交GGSN廠家研發(fā)分析后得出真正的問題根結(jié)： GGSN 設(shè)備上內(nèi)容計(jì)費(fèi)規(guī)則匹配過大。由于計(jì)費(fèi)規(guī)則誤配了對所有報(bào)文實(shí)施內(nèi)容計(jì)費(fèi)的檢測，導(dǎo)致在業(yè)務(wù)忙時(shí)段系統(tǒng)對過多的上行報(bào)文都需要進(jìn)行內(nèi)容計(jì)費(fèi)的深度檢測，使得系統(tǒng)業(yè)務(wù)處理卡負(fù)荷過高引起了故障的發(fā)生。而下行報(bào)文由于在GGSN內(nèi)部僅是做表項(xiàng)匹配而不再進(jìn)行深度檢測，因此可以得到實(shí)時(shí)轉(zhuǎn)發(fā)。在調(diào)整內(nèi)容計(jì)費(fèi)規(guī)則后，在業(yè)務(wù)忙時(shí)段再無異常出現(xiàn)。

3.3 L7層數(shù)據(jù)報(bào)文分析的應(yīng)用

3.4 TCP 連接信息分析的應(yīng)用

根據(jù)協(xié)議規(guī)定可知，后續(xù)服務(wù)器66.163.168.216應(yīng)返回的確認(rèn)報(bào)文 seq=1，ack=1+565=566。但實(shí)際后續(xù)抓包得到的服務(wù)器返回報(bào)文9—12的序列號是隨機(jī)的、確認(rèn)號也不符合協(xié)議規(guī)定，而且返回報(bào)文都是異常中止TCP連接RST報(bào)文。直到報(bào)文13我們才看到符合協(xié)議規(guī)定的ACK報(bào)文，但由于此前的RST報(bào)文中止了TCP連接導(dǎo)致后續(xù)視頻信息無法得到正常傳輸而失敗。

服務(wù)器側(cè)為何在正常TCP握手完畢后突然發(fā)起RST報(bào)文中止會話呢？對比符合協(xié)議規(guī)定的報(bào)文13與此前TCP握手中服務(wù)器返回的SYN報(bào)文的TTL 我們會發(fā)現(xiàn)二者是一致的均是53（見圖10）。

而“非法”報(bào)文9-12的TTL則為112、118及57不等，我們知道TTL值反映的是報(bào)文自源去往目的地中間所經(jīng)過的路由器個(gè)數(shù)。通常情況下數(shù)據(jù)報(bào)文正常路由轉(zhuǎn)發(fā)所經(jīng)的路由器間隔是一致的，即使存在多路由的情況跳數(shù)也不會相差太多。但報(bào)文9-12的TTL與符合協(xié)議規(guī)定的報(bào)文TTL相差過于懸殊，因此可判斷這幾個(gè)報(bào)文并非來自真正視頻服務(wù)器，應(yīng)該是網(wǎng)絡(luò)中間某種設(shè)備攔截所致。通過向客戶解釋該問題發(fā)生的原因，客戶最終認(rèn)可了我們的分析。

3.5 利用抓包工具進(jìn)行節(jié)點(diǎn)丟包問題的分析

4 結(jié)束語

隨著2009年中國3G業(yè)務(wù)牌照的發(fā)放，國內(nèi)3家運(yùn)營商正式逐鹿3G市場。作為3G市場最具特色產(chǎn)品移動(dòng)分組業(yè)務(wù)必然是客戶關(guān)注的焦點(diǎn)之一，因此這也對移動(dòng)分組網(wǎng)絡(luò)維護(hù)水平、維護(hù)效率提出更高的要求。

文章結(jié)合深圳聯(lián)通移動(dòng)分組網(wǎng)維護(hù)中的實(shí)例，對抓包工具的幾種常用功能在移動(dòng)分組網(wǎng)維護(hù)工作中的用途、用法以及問題分析的思路做了介紹。希望為移動(dòng)分組網(wǎng)的建設(shè)及維護(hù)人員提供一定的借鑒，啟發(fā)大家對于這一工具在分組網(wǎng)維護(hù)中的應(yīng)用思路。

參 考 文 獻(xiàn)

[1] Richard Sharpe 《WireShark User's Guide》 2010

[2] 張明和 《抓包軟件Wireshark安裝和應(yīng)用指導(dǎo)書》 華為技術(shù)有限公司 2008

[3] W.Richard Stevens 《TCP/IP詳解 卷1： 協(xié)議》 Addison Wesley/Pearson 2010