某大型集團公司縣公司信息內(nèi)網(wǎng)PC在訪問省公司業(yè)務(wù)和市公司業(yè)務(wù)時間歇性出現(xiàn)訪問連接非常慢的情況，以及使用內(nèi)網(wǎng)PC對省公司DNS服務(wù)器和市公司官網(wǎng)IP持續(xù)ping操作時出現(xiàn)不定時丟包現(xiàn)象，但縣公司訪問其內(nèi)部服務(wù)器并無故障現(xiàn)象。訪問連接慢嚴(yán)重影響信息內(nèi)網(wǎng)的正常業(yè)務(wù)交互，尤其是營銷部門對省公司收費系統(tǒng)服務(wù)器的請求訪問。

 

網(wǎng)絡(luò)拓?fù)鋱D，如圖1：

 

圖 1某大型企業(yè)網(wǎng)絡(luò)拓?fù)鋱D

 

將科來網(wǎng)絡(luò)回溯分析系統(tǒng)旁路接入到縣公司信息內(nèi)網(wǎng)的核心交換機上，由于故障發(fā)生的間歇性需要對縣公司到市公司的主干出口流量做長時間捕獲。并利用科來網(wǎng)絡(luò)分析系統(tǒng)不間斷的捕獲市公司核心交換機與C路由器的下行接口流量。利用對比分析法，在故障發(fā)生時段，分別對兩處捕獲到的流量做精確分析。

 

 

一、出口流量分析

 

通過科來網(wǎng)絡(luò)回溯分析系統(tǒng)對通訊流量的長時間存儲，我們對故障時段的通訊流量進行故障重現(xiàn)。我們在縣公司捕獲點，對故障時段數(shù)據(jù)進行回溯。選擇4分鐘分析窗口（流量統(tǒng)計精度為1秒），未見突發(fā)流量和通訊流量為0的情況。廣播與組播流量正常，TCP SYN比值屬于正常范圍。

 

對該時段的網(wǎng)絡(luò)應(yīng)用進行分析，流量占用***網(wǎng)絡(luò)應(yīng)用為：HTTP、未知TCP、HTTP Proxy，屬正常業(yè)務(wù)行為。網(wǎng)絡(luò)應(yīng)用中存在CIFS掃描，但該應(yīng)用的通訊數(shù)據(jù)包少，對主干鏈路的傳輸影響不大，網(wǎng)絡(luò)安全事件不是造成丟包的原因。

 

對縣公司訪問關(guān)鍵業(yè)務(wù)標(biāo)準(zhǔn)應(yīng)用監(jiān)控梳理，網(wǎng)絡(luò)鏈路傳輸質(zhì)量良好，排除鏈路擁塞造成丟包現(xiàn)象。但客戶端訪問10.176.X.X服務(wù)器的TCP會話中存在98次TCP重傳，上行重傳次數(shù)為97次。大量的TCP重傳造成會話延遲確認(rèn)，嚴(yán)重影響會話質(zhì)量。TCP重傳大部分發(fā)生在上行，說明丟包位置在縣公司到省公司之間。

 

二、TCP會話解碼

 

對應(yīng)用請求的TCP會話進行解碼以確定訪問延遲的具體原因。選取故障時段，縣公司信息內(nèi)網(wǎng)PC主機10.178.x.x訪問10.176.X.X的應(yīng)用通訊流量，客戶端10.178.x.x使用2487端口訪問10.176.x.x的TCP 80端口，網(wǎng)絡(luò)鏈路傳輸質(zhì)量良好，無鏈路擁塞。

 

持續(xù)向下分析，我們發(fā)現(xiàn)縣公司捕獲點TCP會話的77號數(shù)據(jù)包在271ms后對73號數(shù)據(jù)包Seq4245726722進行了重傳，73號數(shù)據(jù)包已達(dá)到縣公司信息內(nèi)網(wǎng)辦公核心交換機出口。而同一會話在市公司捕獲點客戶端10.178.x.x發(fā)送的數(shù)據(jù)包中Seq4245726722的數(shù)據(jù)包只捕獲了一次，該包并未出現(xiàn)在Seq4245725830與Seq4245728182之間，而是間隔200多毫秒后才出現(xiàn)了一次，說明在市公司只捕獲到了重傳的數(shù)據(jù)包，客戶端10.178.x.x***次發(fā)送的Seq4245726722數(shù)據(jù)包在縣公司到市公司之間被丟棄。

 

我們對兩次捕獲TCP會話進行對比分析，如圖2：

 

 圖 2捕獲的兩次TCP會話

 

該TCP會話中存在大量的TCP重傳，通過對兩處捕包點的TCP會話對比分析，確定造成丟包位置在縣公司與市公司之間某一中間件網(wǎng)絡(luò)設(shè)備。整個TCP會話過程中客戶端和服務(wù)器響應(yīng)時間未見異常，結(jié)合前面對網(wǎng)絡(luò)鏈路傳輸質(zhì)量的分析，確定縣公司對省市公司的業(yè)務(wù)訪問出現(xiàn)間歇性延遲的原因是由于中間件網(wǎng)絡(luò)設(shè)備對數(shù)據(jù)包的丟棄造成。

 

三、故障定位

 

根據(jù)拓?fù)鋱D，縣公司路由到市公司核心交換機之間需要經(jīng)過3臺路由器進行轉(zhuǎn)發(fā)。我們對故障發(fā)生時段接入B路由器的其他區(qū)縣信息內(nèi)網(wǎng)PC訪問省市公司業(yè)務(wù)系統(tǒng)的TCP會話進行解碼分析。三次握手時間7.9ms，網(wǎng)絡(luò)傳輸質(zhì)量良好，未見鏈路擁塞。TCP會話中未見丟包重傳，客戶端和服務(wù)器響應(yīng)正常。說明故障時段，只有該縣公司信息內(nèi)網(wǎng)出現(xiàn)訪問丟包現(xiàn)象。因此，故障范圍縮小為縣公司→A路由器→B路由器之間。

 

我們對縣公司到B路由的各個路由接口進行逐一檢查，發(fā)現(xiàn)A路由器與縣公司連接的下行接口光模塊在Input方向有大量CRC校驗碼錯誤日志。

 

CRC循環(huán)冗余校驗碼錯誤有三種可能：

1、 雙方網(wǎng)卡工作模式不同；

2、 鏈路通道信號衰減嚴(yán)重；

3、 網(wǎng)卡故障。

 

我們又對縣公司至A路由上行接口進行檢查，光模塊工作模式與對端A路由器相同，排除***種可能。對縣公司與A路由器之間的光纖通道進行衰減測試，通道正常。排除第二種可能。

 

CRC校驗碼錯誤日志是在A路由器與縣公司的下行接口的Input方向上檢查到，說明縣公司的路由器的上行接口在對數(shù)據(jù)包進行CRC循環(huán)冗余校驗碼封裝時出現(xiàn)間歇性故障，導(dǎo)致A路由器下行接口在對數(shù)據(jù)包進行CRC校驗碼解碼時發(fā)現(xiàn)錯誤。對錯誤CRC校驗碼數(shù)據(jù)包丟棄。

 

四、故障處理

 

將縣公司到A路由器的光模塊進行更換，恢復(fù)通訊一段時間后，對A路由器下行接口進行檢查，CRC循環(huán)冗余校驗碼數(shù)值不再增加。對縣公司訪問省市公司業(yè)務(wù)系統(tǒng)的TCP會話進行解碼，雙方通訊交互正常。TCP會話統(tǒng)計信息中無重傳和丟包?？h公司與省市公司之間的通訊恢復(fù)正常。

 

 

1、縣公司到市公司之間的鏈路流量值不大，流量趨勢不穩(wěn)定，對縣公司至市公司之間的業(yè)務(wù)交互的TCP會話分析后，客戶端RTT值正常，服務(wù)器RTT值正常，未見鏈路擁塞情況；

 

2、通過在縣公司和市公司的對比抓包分析，發(fā)現(xiàn)業(yè)務(wù)交互的TCP會話存在嚴(yán)重丟包現(xiàn)象，經(jīng)過定位分析，發(fā)現(xiàn)縣公司邊界路由器出口光模塊存在CRC校驗和錯誤；

 

3、將縣公司邊界路由器出口光模塊更換以后，CRC校驗和錯誤提示不再增加，對業(yè)務(wù)交互流量分析，未見丟包現(xiàn)象，業(yè)務(wù)通訊恢復(fù)正常。