案例1：用戶在業(yè)務(wù)高峰期無法訪問3g portal

分析過程：

流量負(fù)載與突發(fā)流量、包尺寸均無異常。

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

案例2：無法發(fā)送大附件郵件

分析過程：

抓包發(fā)現(xiàn)重傳很多，90s后，郵件服務(wù)器認(rèn)定連接異常，發(fā)送重置數(shù)據(jù)包；

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

原因：網(wǎng)絡(luò)中存在GRE通道，用于SMTP。GRE需要24字節(jié)的額外負(fù)載，原來1500byte的負(fù)荷變成了1524，而路由器的缺省MTU為1500，且本網(wǎng)絡(luò)中SMTP不準(zhǔn)分片，因此丟棄。

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

案例3：ping大包丟包

分析過程：網(wǎng)絡(luò)拓?fù)錇楣饫w相連，中間設(shè)備只有光電轉(zhuǎn)換器。分析時在光電轉(zhuǎn)換器與路由器之間串聯(lián)一個交換機(jī)，利用交換機(jī)的端口鏡像功能。

原因：大包超過MTU，分片，中途丟包，導(dǎo)致數(shù)據(jù)包重組超時。

案例4：LIMS系統(tǒng)導(dǎo)致ERP系統(tǒng)緩慢

分析過程：在服務(wù)器與接入交換機(jī)之間串入hub，接入分析工具抓包，發(fā)現(xiàn)有幾次連接過程，且最后一次的響應(yīng)時間太慢。TCP急迫位被置為1，導(dǎo)致ERP系統(tǒng)打破了處理調(diào)度順序，ERP資源不足時演變?yōu)楣收稀?/p>

解決方案：修改LIMS端的應(yīng)用層控制。

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

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

結(jié)論：加速器的加速功能開啟時訪問異常，加速功能關(guān)閉時訪問OK。

案例6：不定時出現(xiàn)網(wǎng)絡(luò)延遲故障。

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

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

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

結(jié)論：運(yùn)營商插入了用于干擾的RTP包，產(chǎn)生爆音和背噪，影響通話質(zhì)量。由于RTP包具有明顯的特征，可以在網(wǎng)絡(luò)邊界設(shè)備上識別和過濾；也可以在PBX上使用NDIS驅(qū)動過濾。

案例8：網(wǎng)絡(luò)通訊阻塞，訪問網(wǎng)絡(luò)速度緩慢，ping網(wǎng)關(guān)偶有中斷

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

案例9：網(wǎng)絡(luò)丟包分析

造成丟包的主要原因：硬件故障（網(wǎng)卡、端口故障）、軟件故障（錯誤的靜態(tài)路由、主機(jī)默認(rèn)網(wǎng)關(guān)配置錯誤）、網(wǎng)絡(luò)擁塞（帶寬過小或存在異常流量時，如ARP攻擊/P2P等）、MTU配置不當(dāng)（以太網(wǎng)：1500字節(jié)、IEEE 802.3/802.2 1492字節(jié)）。

排查方法：分段捕獲。推薦利用率不高于15%，網(wǎng)絡(luò)利用率高于30%時，就會產(chǎn)生1%的丟包。?

案例10：瘦客戶端故障

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

案例11：防火墻阻擋ospf組播協(xié)議包

故障現(xiàn)象：核心交換機(jī)與路由器之間架設(shè)一臺硬件防火墻后，內(nèi)網(wǎng)終端無法聯(lián)通內(nèi)網(wǎng)系統(tǒng)。防火墻為透明模式，沒有任何過濾策略。撤掉防火墻后故障消失。排查過程：查看核心上show access-list，訪問列表無內(nèi)容，表明核心未執(zhí)行數(shù)據(jù)包過濾操作；show ip route，未發(fā)現(xiàn)到內(nèi)網(wǎng)的路由。

結(jié)果：核心和路由器上開啟了OSPF，但ospf協(xié)議尋找動態(tài)鄰居時，需要以組播方式向網(wǎng)絡(luò)發(fā)hello包，但硬件防火墻默認(rèn)狀態(tài)不容許組播數(shù)據(jù)包通過，會阻礙核心從路由器學(xué)到動態(tài)路由。配置合適的訪問規(guī)則后，訪問OK。?

?

轉(zhuǎn)載于:https://www.cnblogs.com/evangel/archive/2011/05/04/2037043.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。