網絡故障診斷案例: 百貨商廈網絡癱瘓事件的診斷與恢復

故障地點：上海某某百貨局域網
故障現象：嚴重通訊障礙，客戶機之間ping包掉包嚴重，甚至POS機也不能正常通訊，用戶很難完成付款操作。
詳細描述：
整個網絡間斷性出現網絡通訊中斷，造成經常性的客戶機應用延遲和上網緩慢。在主機房中進行ping包測試時發現，主機房客戶機對主交換機的管理地址的ping包也會發生間隙性掉包。主機房客戶機對各個樓面交換機通訊的通訊中斷情況更加嚴重。

初步經驗性問題判斷為：可能性1）ARP表更新問題
2）廣播故障
3）路由表更新故障
4）病毒攻擊及其他安全狀況
需要獲取的進一步信息是，1) ARP表信息 2) 交換機負載 3) 通訊數據捕獲

進行了簡單的ARP測試，發現更新ARP正常; 由于交換機反應緩慢，操作超時，無法準確獲得當前負載數據。
選擇主交換上一網絡端口接入測試用筆記本，啟動協議分析工具。
接入端口沒有做鏡像，接入后發現每秒鐘接收到數據報文數量平均8000個，最高達到每秒14000個。按此推算，每臺交換機背板每秒可能交換336000多個封包，這可能是造成交換機處理器被嚴重占用，造成間歇性丟包的直接原因。

由于交換機端口沒有做鏡像，可以認為當前的接收到的數據主要為廣播通訊。利用協議分析工具捕獲解碼后，可以得到以下結果。

主要的協議通訊都是廣播通訊。包括ARP 廣播、SMB廣播和Name SVC廣播。

幾乎所有的封包大小都小于255字節。所以盡管封包數量很大，但是總體字節數不多，吞吐量較小，在一些只記錄流量的軟件系統中，不能準確發現這個問題的危害。




從解碼角度察看，可以看到一段時間內，主要為某一臺主機的瘋狂通訊。往往一臺主機的通訊在瞬間占據當時總體通訊的50%以上。
到此，問題原因曾經被導向到個別流量特別大的主機，懷疑其由于病毒/蠕蟲的侵害而造成大流量的產生。但是在進一步分析的過程中，我們注意到了這些在通訊中有一個特點，例如在NetBIOS 的Name SVC廣播為UDP協議，UDP為IP之上封裝的通訊，在IP包頭包含了IP Identification信息(縮寫IPID)，一般每臺主機在主動發送一個數據包時，會對IPID這個值進行遞增。例如第一個包IPID為10000，第二個發送包就可能是10001，第三是10002，依次類推，不同的主動發送的報文的IPID應當是不同的。但是在解碼中可以發現在一段時間內，IPID是在大量簡單重復。換言之，這些大量的廣播報文，通常不應當是某臺主機主動引起，而是被交換機發復轉發造成。

在此情況下，為了正式這一現象，我們作了一次試驗，讓某臺主機以每三秒一次的頻率發送請求到一個不存在的地址（為了引起ARP廣播），但是每三秒一次的廣播，在網絡中捕獲的結果是在一秒鐘內形成了7991次反復轉發，造成了大量的網絡流量。 經過這些過程，我們確認這一問題是由于交換機環路造成。

通常交換網絡中會打開Spanning Tree協議以保障不發生交換機環路的現象，如果不使用Spanning Tree Protocol (以下簡稱STP)，當兩臺交換機發生同時被兩條線纜互聯時候，會形成環路，交換機無法自我偵測這一情況，其結果是把廣播報反復轉發。

如果啟用STP，各個交換機會發送優先度很高的BPDU數據封包，進行線路檢測，當發現發送的BPDU包被不恰當的轉發回來時候，交換機可以相互協商，關閉某一條環路路徑。保障任意兩個交換機中只有一條耦合鏈路。

問題確認得到以后，我們試圖解決。

采用二分法，臨時斷開東樓和西樓的光纖鏈路。斷開后發現故障立即消除，所有超時現象不再出現，流量平復正常。 以此可以判斷，環路發生在西樓和東樓之間，或在老樓內部。
恢復光纖鏈路之后，我們前往老樓進一步查訪故障源。由于老樓交換機放置地點條件較差，經過整理和分析，到18:45分左右，在老樓發現故障源也已經消失。由于時間因素，進一步的定位工作沒有繼續，但是由于已經把問題縮小到老樓局部以及能夠定位了故障類型本身，對之后的維護保障工作應當有比較好的幫助。

結論
<< 涉及客戶信息，被省略 >>

在診斷該故障同時，還發現有一些網絡掃描的現象，網內還伴隨一些病毒和蠕蟲的征兆，因此網絡維護任重道遠，仍然需要更多的努力和投入。