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

分析過(guò)程：

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

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

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

分析過(guò)程：

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

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

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

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

案例3：ping大包丟包

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

案例10：瘦客戶端故障

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

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

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

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

?

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

總結(jié)

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

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