最近，接連有校園網用戶向網管員反映，他們的辦公用計算機有些時段上Internet和校園網速度極慢，不能正常瀏覽網頁、收發電子郵件。起初我們并未在意，以為是用戶端計算機的問題，但反映情況的老師逐漸增多，這引起了我們的關注。在故障再次發生時，我們得到了用戶的報告，并立即開始對故障進行排查。

首先，我們在網絡中心對本校的WWW服務器和Internet出口做了檢查，發現一切正常；檢查中心交換機，其資源利用率等各項指標基本正常。這就排除了網絡中心不能提供正常服務的可能。

之后，Ping用戶的計算機、用戶辦公樓（A號樓）的二級交換機、A號樓的其他計算機，發現丟包嚴重；Ping其他辦公樓的二級交換機和計算機，發現B號辦公樓和A號樓的情況相似，其余均正常。這樣，故障范圍縮小到A、B兩座樓。電話詢問A、B兩座樓的個別用戶，證實了不能正常上網的情況。

這種現象同時出現在兩座辦公樓上，線路和二級交換機同時出故障的可能性極小。查看這兩座辦公樓的網絡拓撲圖，二級交換機的所有端口處于同一個VLAN中，懷疑是病毒向網絡瘋狂發送數據包（導致廣播風暴的原因有很多，一塊故障網卡、一個故障端口都有可能引發廣播風暴）引發了網絡阻塞。必須先找到引起故障的計算機！

在網管交換機上，把一個端口的VLAN配置為VLAN X，接上裝有Sniffer軟件的計算機抓包，在不到兩分鐘的時間內得到了如附圖所示的巨量廣播包。

從附圖中可以看到，這種廣播包的數據量是驚人的。數據鏈路層的封裝是正常的廣播：數據從源MAC地址“50:78:4c:71:2f:19”發往目的地址“ff:ff:ff:ff:ff:ff”，但封裝協議是“0x9899(39065) unknown”，Sniffer軟件無法向下剝離，只能以二進制代碼來顯示數據，無法看到源計算機的IP地址。但這已經足夠了——我們有了發包計算機的MAC地址！

Telnet到用戶辦公樓的二級交換機上，用Show cam命令找到了交換機的地址關聯存儲表（CAM）中MAC地址所對應的交換機端口，再查看樓層布線圖，找到了發包計算機所處的房間號（某系對學生開放的上網機房）。

無法得到此計算機的其他信息，只能到該機房實地了解情況了。原來，該系新購進了一批聯想品牌的計算機，帶硬盤保護卡，其硬盤保護系統功能的實現不依賴于操作系統和其他軟件，且具有網絡安裝的功能。機房維護人員安裝好一臺計算機后，可以使用硬盤保護卡的網絡安裝功能，完成單個或多個計算機的安裝（一般需要2～3個小時）。因為網絡安裝的功能是在硬盤保護卡的底層開發的，無法使用Windows系統下類似組播的方法同時給多臺計算機發送數據，只能在數據鏈路層使用廣播方式，但用這種廣播方式高速傳送大量的硬盤數據，給網絡帶來了嚴重的擁堵，二級交換機和同一VLAN的用戶不堪重負（廠方的說明書中并未說明它的工作原理及所帶來的問題）。網絡出現故障的時候，機房維護人員正在給幾臺機器重新傳輸系統（其他品牌的計算機網絡安裝也有類似問題）。