案例1：用戶在業務高峰期無法訪問3g portal

分析過程：

流量負載與突發流量、包尺寸均無異常。

TCP連接中大量是通過TCP RST結束連接；根據三次握手分析服務器端到捕獲端、客戶端到捕獲端的RTT，web portal端時延小，排除服務器導致連接失敗；查看RST的時延，判斷為出口路由器的故障。結論：路由器bug。

案例2：無法發送大附件郵件

分析過程：

抓包發現重傳很多，90s后，郵件服務器認定連接異常，發送重置數據包；

分別在防火墻和路由器后端進行抓包，界定為路由器問題；

原因：網絡中存在GRE通道，用于SMTP。GRE需要24字節的額外負載，原來1500byte的負荷變成了1524，而路由器的缺省MTU為1500，且本網絡中SMTP不準分片，因此丟棄。

解決方案：1、取消GRE通道配置；2、修改GRE通道的MTU，使其保證能通過1518byte的數據包；3、SMTP服務器設置為準許郵件數據包分片。

案例3：ping大包丟包

分析過程：網絡拓撲為光纖相連，中間設備只有光電轉換器。分析時在光電轉換器與路由器之間串聯一個交換機，利用交換機的端口鏡像功能。

原因：大包超過MTU，分片，中途丟包，導致數據包重組超時。

案例4：LIMS系統導致ERP系統緩慢

分析過程：在服務器與接入交換機之間串入hub，接入分析工具抓包，發現有幾次連接過程，且最后一次的響應時間太慢。TCP急迫位被置為1，導致ERP系統打破了處理調度順序，ERP資源不足時演變為故障。

解決方案：修改LIMS端的應用層控制。

案例5：無法訪問總部的網站，網頁打不開，但ping ok，且除了該網段地址外，其他網段都訪問OK。

分析過程：ping ok，因此連通性無問題，可能是中間設備未轉發請求的數據包導致包丟失從而連接失敗。用防火墻內置的抓包功能看到防火墻的端口轉發數據OK，但回應的端口由80變成了135，確定故障應是防火墻前段的設備。

結論：加速器的加速功能開啟時訪問異常，加速功能關閉時訪問OK。

案例6：不定時出現網絡延遲故障。

分析過程：抓包分析流量并不大，但某時有突發流量，且均為UDP協議，大小均為固定的112字節，經查源主機感染蠕蟲病毒。

案例7：VOIP通信受干擾，有爆音和背噪

分析過程：抓包顯示呼叫的建立和拆除信令完整。有聲音，因此RTP包沒有被丟棄（RTP封裝在UDP包中）。抓包觀察ping延遲的差異，平均抖動基本平穩，不會影響通話質量。VOIP屬于實時應用，要求數據盡力快速傳輸，未采取重傳和防偽造機制。但抓包發現有IPID值相同且按規律出現的數據包。

結論：運營商插入了用于干擾的RTP包，產生爆音和背噪，影響通話質量。由于RTP包具有明顯的特征，可以在網絡邊界設備上識別和過濾；也可以在PBX上使用NDIS驅動過濾。

案例8：網絡通訊阻塞，訪問網絡速度緩慢，ping網關偶有中斷

分析過程 ：登陸交換機查看CPU和內存利用率，均正常。在核心上做鏡像抓包，短時間內有大量TCP connection refused包，定位發現有感染病毒的主機。后再抓包，設置網關IP為過濾條件，發現兩個不同MAC。但核心交換機到網關再無其他設備，因此排查為有計算機錯誤設置為了網關的IP。

案例9：網絡丟包分析

造成丟包的主要原因：硬件故障（網卡、端口故障）、軟件故障（錯誤的靜態路由、主機默認網關配置錯誤）、網絡擁塞（帶寬過小或存在異常流量時，如ARP攻擊/P2P等）、MTU配置不當（以太網：1500字節、IEEE 802.3/802.2 1492字節）。

排查方法：分段捕獲。推薦利用率不高于15%，網絡利用率高于30%時，就會產生1%的丟包。?

案例10：瘦客戶端故障

故障：瘦客戶端無法開機，bootp無法通過DHCP獲得有效IP，從而下載操作系統失敗，瘦客戶端停留在引導的黑屏界面；已在線用戶緩慢。排查過程：網絡利用率很低；網管轉發的DHCP請求數據包服務器基本不回應；網絡設備接口無錯幀、丟幀以及誤碼等報錯信息，且設備CPU、內存等資源占用情況正常；抓包發現：某臺機器A短時間內向大量地址發數據包，頻率高，且均為ICMP請求包和目的端口為80的TCP的syn包，syn包序列號全一致。分析：A機器產生類似病毒掃描行為，大量數據包導致服務器網段工作異常，服務器不響應dhcp請求，導致用戶無法獲得IP地址并完成后續啟動。將A機離線后故障消失，網絡利用率恢復。故障定位：A機上有某管理程序異常。深層次分析：抓包分析A機發送不存在地址(1.0.0.20)的syn包后，會出現來自外部的ack應答包，但理論上不應該，即網絡上存在一個源代替1.0.0.20發回應信息。經分析為CP安全網關工作在80端口的代理模式，代理了1.0.0.20的ack應答。將安全網關下線后，檢查防火墻內存狀態表，發現FW會根據訪問控制規則，容許1.0.0.20的地址通過火墻，建立狀態為established的會話狀態表。安全網關代理應答導致消耗大量資源，從而出現故障；安全網關下線后，對FW形成大量會話連接建立請求，形成類似synflood攻擊模糊死，火墻的會話超時時間為1小時，性能約容納200萬狀態記錄，不到一小時FW即會資源耗盡導致網絡故障。?

案例11：防火墻阻擋ospf組播協議包

故障現象：核心交換機與路由器之間架設一臺硬件防火墻后，內網終端無法聯通內網系統。防火墻為透明模式，沒有任何過濾策略。撤掉防火墻后故障消失。排查過程：查看核心上show access-list，訪問列表無內容，表明核心未執行數據包過濾操作；show ip route，未發現到內網的路由。

結果：核心和路由器上開啟了OSPF，但ospf協議尋找動態鄰居時，需要以組播方式向網絡發hello包，但硬件防火墻默認狀態不容許組播數據包通過，會阻礙核心從路由器學到動態路由。配置合適的訪問規則后，訪問OK。?

?

轉載于:https://www.cnblogs.com/evangel/archive/2011/05/04/2037043.html

總結

以上是生活随笔為你收集整理的网络分析案例集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。