故障排除

為了能在現場測試網絡的連通性，在網絡中心，我們把連接那棟大樓接入交換機的多模尾纖經光電轉換器用雙絞線連到一臺PC上，并將其模擬成那個問題VLAN的網關。然后，到現場找來大樓網管員，想讓他協助我們盡快把感染了未知病毒的主機查到并隔離。據大樓網管員反映，昨天網絡還算正常，不過，當時本大樓某部門正在做網絡調整，今天上班就發現網絡不行了，不知跟他們有沒有關系。我們認為調整網絡應該跟感染病毒關系不大。

在大樓主配線間，我們把該接入交換機上的網線都拔掉，接上手提電腦，能連通網絡中心的測試主機。我們確認鏈路沒問題后，每次將剩余網線數量的一半插回該交換機，經測試沒問題則如是繼續下去，否則換插另一半，逐漸縮小懷疑有問題網線的數量。我們最終找到一條會引起問題的網線，只要插上這根網線，該大樓網絡就會與模擬網關中斷連接。經大樓網管員辨認，這條網線是連接昨天在做網絡調整的那個部門的。他還說以前該部們拉了一主一備兩條網線，應該還有一條，并親自在那臺交換機上把另一條找了出來。隨意插上這兩條網線中的一條，網絡沒問題，但只要同時插上，就有問題，哪有在一臺交換機上同時插上兩條網線才會激活網絡病毒的SYN Flood攻擊的？這時我們倒是覺得這種現象更像是網絡中有環路。

我們到了那個部門發現有三臺非管理型交換機，都是串在一起的，然而其中兩臺又分別通過那兩條網線與接入交換機相連，從而導致了網絡環路（如圖2）。顯然是施工人員對網絡拓撲不清楚，當時大樓網管員有事外出，就自以為是地把線接錯了，從而造成了這起網絡事故。原因找到就好辦了，只需拔掉其中一條上聯網線（例如，圖2的虛線）即可恢復網絡連通。

498)this.style.width=498;" border=0>

圖2 接入上聯線

經過一番周折，網絡恢復了正常，但我們還一直在想，是什么干擾了我們的判斷呢？

故障分析

一起典型的網絡環路故障，用協議分析工具Sniffer抓了這么多的數據包，經過一番分析卻沒看出問題來。顯然，第一眼看到大量的SYN包讓我們產生了錯覺，想當然地就以為是SYN Flood攻擊。事后，我們就這起網絡環路故障排除過程做了檢討，重新仔細地分析抓回來的這些數據包，據此解釋一下前面提到這些數據包所具有的5個共同特征，以便今后遇到同類問題時能及時作出正確的反應。

先看前4個特征：匯聚交換機是網絡層設備，該大樓所屬VLAN的網絡層接口就設置在這臺匯聚交換機上，出于實施網絡管理策略的需要，對已注冊或沒注冊的IP地址都進行了MAC地址的綁定。TCP連接要經過3次握手才能建立起來，在這里發起連接的SYN包長度為28個字節，加上14個字節的以太幀頭部和20個字節的IP報頭，由Sniffer捕獲到的幀長度共為62個字節（不包含4字節的差錯檢測FCS域）。恰巧當時訪問該VLAN的單播幀是來自外網的TCP請求包，根據以太網橋的轉發機制，通過CRC正確性檢測后，因已做靜態ARP配置，這臺匯聚交換機會將該單播幀的源MAC地址轉換成本機的MAC地址，其目的MAC地址依據綁定參數來更換，并重新計算CRC值，更新FCS域，經過這樣重新封裝后，再轉發到那棟樓的接入交換機。