故障診斷-客戶機之間ping包掉包嚴重案例

  Q：故障診斷-客戶機之間ping包掉包嚴重案例
  A：故障地點：上海某某百貨局域網
    故障現象：嚴重通訊障礙，客戶機之間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分左右，在老樓發現故障源也已經消失。由於時間因素，進一步的定位工作沒有繼續，但是由於已經把問題縮小到老樓局部以及能夠定位了故障類型本身，對之後的維護保障工作應當有比較好的幫助。

    結論

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

故障診斷-客戶機之間ping包掉包嚴重案例.