對于諸如斷網、風暴等災難性的網絡故障，相信大多數管理員朋友能夠比較快速地定位并進行排錯。但網絡是復雜的，在運維中經常會遇到諸如網絡速度慢，時斷時續，頻繁丟包等故障，相對來說，這些故障的排錯是比較麻煩的。筆者做技術支持多年，看到運維同仁在遇到此類故障時往往束手無策，此前屢試不爽的觀察法、隔離法、替代法不僅太費時間，而且經常讓大家走彎路，并且能否排除故障還是未知數。基于此，筆者和大家分享一些自己的經驗，即通過捕獲網絡數據包并分析的手法對網絡故障進行診斷，讓網絡排錯從數據包分析開始。
1.數據包的捕獲方式
要進行數據包分析，首先要在故障的網絡的特定節點捕獲數據包。因此，筆者先和大家談談數據包的捕獲方式。數據包的捕獲方式很多，最常見的是所謂的協議分析儀。它是針對OSI模型2-7層設計的，能夠在2-7層上進行解碼，解釋450多種網絡協議，采用剝洋蔥方式，從低層開始，一直到第七層，甚至對ORACLE數據庫、SYBASE數據庫都可以進行協議分析。協議分析儀有硬件和軟件相結合的專門產品，也有純軟件產品。數據包捕獲，當然首選是專門的硬件分析儀。不過對于一般的網絡，網絡管理員憑借自己的技術、經驗，借助專門數據包捕獲軟件實施網絡排錯已經足夠。筆者通常使用的工具主要是Sniffer，此外微軟的Microsoft Network Monitor也不錯，而科來網絡分析工具相對容易上手，其圖形化的界面也比較形象。數據包捕獲和分析，大家靈活掌握其中的一兩款工具足矣。
2.數據包捕獲的工作原理
理解數據包捕獲的工作原理，對于管理員來說是非常必要的，下面筆者就其工作原理做一簡述。我們知道，通常在同一個網段的所有網絡接口都有訪問在物理媒體上傳輸的所有數據的能力，而每個網絡接口都還應該有一個硬件地址，該硬件地址不同于網絡中存在的其他網絡接口的硬件地址，同時，每個網絡還有廣播地址(代表所有的接口地址)。在正常情況下，一個合法的網絡接口應該只響應這樣的兩種數據幀：幀的目標區域具有和本地網絡接121相匹配的硬件地址以及幀的目標區域具有“廣播地址”。
在接收到上面兩種情況的數據包時，網卡通過CPU產生一個硬件中斷。該中斷能引起操作系統注意，然后將幀中所包含的數據傳送給系統進一步處理。而Sniffer就是一種能將本地網卡狀態設成混雜(Promiscuous)模式狀態的工具軟件，當網卡處于這種“混雜”方式時，該網卡具備對遭遇到的每一個幀都產生一個硬件中斷，以便提醒操作系統處理流經該物理媒體上的每一個報文包(絕大多數的網卡具備Promiscuous方式的能力)。
3.協議分析儀的功能
了解協議分析儀的主要功能，以便管理員在特定情景中利用分析儀進行數據捕獲和分析是非常有幫助的，筆者也做一概括。(1).分析從硬件分析儀中捕捉的數據包，具有完整的七層包捕捉、過濾和解碼能力。(2).實時監測網絡利用率和誤碼率、幀大小分布、協議分布、最多發送者/接收者、對話矩陣、 VLAN流量分析、應用程序響應時間分析等。(3).智能專家故障分析、診斷功能在監測實時流量時自動發現錯誤、快速指出問題所在并給出修改建議。(4).支持本地和遠程網絡分析。(5)支持特殊的協議：Extreme EDP、ESRP以及Cisco CDP和VTP等。(6).停止并保存捕捉會話、發送一個SNMP陷阱、發送Email或尋呼通知等。(7).在日志文件中保存告警消息、啟動一個應用程序和過濾等。(8).協議分析儀上的功能延展就是加入網管功能、自動網絡信息搜集功能等。
4.數據包分析排除網絡故障案例
通過上面的介紹，大家對網絡分析儀捕獲數據的方式，以及其工作原理功能有了足夠的了解。下面筆者列舉三個案例，再現用數據包分析排除網絡故障的過程。
案例一：交換機端口鎖死
(1).故障現象
交換機的某一端13聯接了一個HUB，HUB上面有DNS及WEB服務器。在沒有任何征兆的情況下，交換機的這一端口突然出現故障，端口上的所有設備不能聯網。
(2).故障檢查
①換交換機另一個好的端口，約幾分鐘后重復上述故障。
②懷疑連接交換機的HUB有物理故障，換了一個好的以后，過一段時間后故障仍然存在，可以確定不是HUB故障引起的。
③關掉交換機電源，重新加電后，原來出故障的端口恢復正常，但過一段時間后故障再次出現。由此判斷端口故障很可能是因某種原因鎖死，并非燒壞。依此，初步判斷故障是由DNS
或WEB服務器的硬件或軟件異常引起的。
④使用Sniffer協議分析儀接入該網段，測試后發現，DNS通過HUB接入一個好的交換機端口后，很快產生了幾個廣播風暴，之后交換機的端口就鎖死。廣播風暴是造成交換機端121鎖
死的直接原因。
⑤通過解讀捕捉到的數據包內容，可以看到，廣播風暴產生的原因，是本地DNS(主)服務器，與一臺遠程DNS(從)服務器之間產生了大量通信，通信內容是遠程DNS服務器向本地DNS服務器查詢一個主機的名字解析，而本地DNS服務器沒有設置該主機所在域的DNS服務器地址，從而造成異常的通信過程。
⑥從協議分析儀還可以看出，在1秒鐘內，2臺DNS之間有1155個這樣的包來回.這種數據包產生了一個廣播風暴，造成了交換機端口鎖死。
(3).故障排除
將www.*.net(基于保密用*代替)所在域的DNS服務器的地址定義在本地DNS上，故障排除。
(4).排錯總結
在這個例子中，遠程DNS向本地DNS查詢www.*.net的地址解釋，本地DNS答復找不到以后，理論上遠程DNS不應再發出查詢請示，但由于軟件BUG的問題，造成了DNS系統異常，產生了一個廣播風暴，使交換機出現了故障。
案例二：廣域網傳輸極慢
(1).故障現象
在DDN線路上，正常情況下Ping一個遠端的IP，回包時間從三十幾毫秒到幾百毫秒。有一次回包時間達到3000～5000毫秒之間，遠程訪問速度極慢。
(2).故障檢查
按筆者的經驗，這種情況是由于DDN線路有大文件在傳輸的緣故。將Sniffer協議分析儀接入廣域口，可以看到上行帶寬被占用了50%，下行帶寬被占用了近100%。再分析捕捉到的包內容，發現大部分的包的交換是在地址192.128.96.23和192.3.54.133之間進行，協議主要是HTTP。從一臺Pc瀏覽192.3.54.133，發現是一個個人網站，上面有大量游戲程序，192.128.96.23用戶正是使用了 NetAnts在該網頁上下載大量的游戲程序，造成了線路堵塞。
(3).故障排除
在路由器上用訪問控制列表將該個人游戲網站過濾，禁止任何用戶通過路由器對該網站進行HTTP訪問，通信恢復正常。
案例三：局域網廣播風暴故障
(1).故障現象
局域網任意兩臺主機之間互相PING時，掉包非常嚴重，訪問各種服務器非常緩慢。
(2).故障檢查
①查看局域網中心交換機的CPU使用率，競高達99%(平時<10%)，說明其負載非常重。
②將Sniffer接入網絡中，發現平均的帶寬利用率達20%(平時<5%)，說明網絡的的數據流量非常大。
③什么原因造成了如此巨大的流量?通過Sniffer捕捉數據包分析，可以明顯看到有一臺主機發出大量的IPX的數據包每秒大約1000個包，這顯然是不正常的。
④該主機為何會發出IPX數據包呢?對數據包的詳細解碼發現，該主機發出的都是SMB(ServerMessageBlock)協議的數據包，數據包的源地址和目的地址都相同，且為IPX地址，數據包的內容是不斷地向網絡宣告該計算機名(HGF)。SMB協議用于實現局域網中計算機之間文檔、打印設備和其他計算機資源的共享，它可以用在TCP/IP協議之上，也可以用在IPX和NetBEUI之上。在SMB協議中，計算機為了訪問網絡資源，就需要了解網絡上存在的資源列表，這個機制稱為瀏覽，維護網絡中當前資源列表的任務由網絡上的幾個特殊計算機完成的，這些計算機被稱為Browser。SMB 協議的Browser通過廣播方式了解當前的網絡資源情況。由此判斷，該主機可能有基于IPX協議的一些應用，且被當作Browser。
⑤查找到主機，發現只是一臺用于辦公，沒有任何復雜的應用和程序。但在網絡協議處發現安裝了“IPX/SPX/NetBIOS兼容傳輸協議”，該協議的錯誤配置使得主機被當作SMB協議中的Browser，并不斷向外發出大量的廣播包，導致整個局域網的擁塞。
(3).故障排除
卸載該主機的“IPX/SPX/NetBIOS兼容傳輸協議”，經20多分鐘后(廣播包在網絡中會存在一定時間)，局域網恢復正常。
多掌握一種工具，在網絡排錯中就會多一種選擇。基于網絡分析工具，通過網絡抓包，網絡協議分析的方法進行排錯的無疑是非常有效的，而且非常高效，這是其它傳統的技術方法所無法比擬的。希望網絡運維的同仁們能夠盡快掌握這種方法，但愿本文能夠幫助到你。
