在組網規模相對大一些的局域網環境中，交換機的使用數量往往比較多，這些交換機在進行相互連接時，很容易被人為地連接錯誤，從而引發網絡環路故障，要是對應交換機沒有正常啟用STP功能時，網絡環路故障就會造成通信數據包在網絡傳輸通道中反復不停地進行轉發，最終形成廣播風暴，那樣一來整個局域網都有可能發生癱瘓故障。筆者在管理、維護局域網的過程中也曾多次遭遇到這種網絡故障，其中一次故障的排除經歷令筆者記憶猶新，筆者巧妙地利用了新交換機的網絡環回監測受控功能，迅速地找到了發生網絡環路的節點，現在本文就將該故障的排除過程還原出來，供各位朋友參考交流

　　案發現場

　　筆者所管理的局域網規模比較大，大約有300臺左右的計算機分布在10層大樓上，每一臺計算機都通過100M雙絞線連接到各個樓層的二層交換機上，每一樓層的交換機又會通過寬帶光纖線纜直接與單位局域網的核心交換機相連，最后局域網通過硬件防火墻連上了Internet網絡。 為了便于高效管理和維護網絡，筆者根據每個樓層的實際情況，在每一臺二層交換機上都劃分了多個虛擬工作子網，這樣一來每個虛擬工作子網的上網狀態是相互獨立的，即使某個虛擬工作子網中不幸遭遇了網絡病毒的襲擊，也不會對整個局域網網絡的穩定運行造成影響;同時，日后遇到網絡故障時，筆者也能將故障范圍縮小到某個虛擬工作子網中進行解決，而不需要在整個局域網中進行大范圍排查。

　　平http://www.49028c.com時，局域網中的所有計算機都能正常上網。可是，最近某一天，筆者突然接到電話，說八樓某房間不能正常上網，懇請能夠到現場幫忙解決一下;筆者剛剛放下電話，準備遠程登錄進對應房間所連的二層交換機上，看看其交換端口是否處于激活、啟用狀態時，接二連三的電話不停地打到筆者的辦公室，一打聽這些故障電話都來自八樓，并且都報告說計算機突然不能正常上網。

　　謎霧重重

　　這么多來自八樓的故障電話，告訴筆者整個八樓看來都不能上網了，難道是對應樓層的交換機發生了死機或其他意想不到的故障了?以前筆者也多次遇到過某個樓層都不能上網的故障，每次只要重新啟動一下對應樓層的二層交換機，往往就能恢復整個樓層的上網狀態了。為了驗證自己的猜測，筆者立即嘗試以telnet連接來遠程登錄位于八樓的二層交換機系統，可是等了好長時間，也無法遠程登錄成功，顯然該樓層的二層交換機工作狀態不正常。筆者不放心，又以系統管理員身份登錄進入了局域網的核心交換機，利用該交換機后臺管理系統提供的“display cpu”命令，查看了核心交換機上各個插槽板卡的CPU消耗情況，結果發現2號板卡的CPU使用率已經超過了50%，而根據以往經驗筆者得知，核心交換機每塊插卡正常工作時CPU使用率不會超過50%的，正常處于20%-30%之間波動(如圖1所示);繼續檢查時，筆者發現2號板卡中的某個交換端口恰好就是連接八樓二層交換機的那個端口，使用“display interface”命令查看該端口的工作狀態時，該端口已經處于“down”狀態了，同時筆者看到該端口的輸入、輸出數據流量特別大，達到了驚人的每秒萬兆級別了，這與平http://www.49028c.com時的每秒幾百兆級別相差也太大了，看來位于八樓的二層交換機系統的確存在問題。

　　由于無法遠程登錄八樓的二層交換機系統，筆者只好趕赴該交換機的現場，通過觀察交換機控制面板上的信號燈狀態，并不能找出明顯的故障痕跡;不得已，筆者只好先嘗試著重新啟動一下該樓層交換機系統，重啟成功沒有多久，八樓中的計算機又能正常上網了，原以為這種故障現象已經被成功解決了，可是沒有多長時間，八樓的二層交換機系統工作狀態又不正常了，并且該交換機與核心交換機相連的級聯端口輸入、輸出數據流量還是特別大。后來，筆者在核心交換機后臺系統不停地執行“display interface”命令，查看八樓的二層交換機級聯端口工作狀態，發現該端口的輸出廣播包不停地增大，很明顯上述故障問題不在八樓的二層交換機系統上，很可能是連接到該交換機下面的虛擬工作子網中出現了廣播風暴現象。

　　峰回路轉

　　一般來說，引起廣播風暴現象的因素有很多，比方說虛擬工作子網中存在網絡病毒或硬件設備損壞現象，或者是某個交換端口出現了瓶頸現象，也有可能是虛擬工作子網中出現了網絡環路現象。由于八樓的二層交換機上同時劃分有幾個虛擬工作子網，每個虛擬工作子網中又包含了多臺計算機，如果單純依靠手工方法去尋找網絡硬件設備的損壞或網絡病毒，工作量將十分巨大?？紤]到虛擬工作子網中發生網絡硬件損壞的現象屬于極個別現象，這種極個別的硬件損壞一般不會造成這么大輸出、輸入數據流量，為此筆者打算先從網絡環路因素著手，來排除整個八樓不能上網的故障現象。

　　那么如何才能判斷八樓的二層交換機上是否存在網絡環路現象呢?查看對應交換機的操作說明書時，筆者偶然發現該交換機支持交換端口網絡環回測試功能，我們一旦啟用了該功能后，該功能就會自動掃描本地交換機中的各個交換端口狀態，要是掃描到某個交換端口下面存在網絡環路現象時，它就能自動把掃描結果保存到交換機系統的日志文件中，日后當我們懷疑該交換機下面存在網絡環路現象時，只要查看對應的日志文件就可以了。此外，筆者還發現如果將某個Trunk類型的交換端口配置成網絡環回受控功能時，該功能只要發現目標交換機下面存在網絡環路現象，就會自動將Trunk類型的交換端口設置成自動關閉狀態，以便及時制止網絡環路現象繼續影響、沖擊整個網絡。

　　依照上述分析，筆者在八樓的二層交換機后臺系統，使用“display loopback-detection”命令查看了該交換機與核心交換機相連的級聯端口環回測試狀態(如圖2所示)，發現該級聯端口果然啟用了網絡環回受控測試功能，難道是該功能發現了目標交換機下面存在網絡環路現象，從而自動關閉了級聯端口的工作狀態?為了驗證自己的猜測，筆者立即進入級聯端口的工作視圖模式，在該模式狀態下執行了“undo loopback-detection control enable”字符串命令，來臨時取消級聯端口的網絡環回受控測試功能，之后再次使用“display interface”命令查看了級聯端口的工作狀態，果然筆者看到該端口的工作狀態已經從原來的“down”變成了“up”，看來目標交換機下面真的存在網絡環路現象。

　　由于“display loopback-detection”命令不但可以查看到究竟有哪些端口啟用了網絡環路測試功能，而且也能查看到究竟是哪個交換端口存在網絡環路，為此筆者再次執行“display loopback-detection”字符串命令，查找到e0/12端口存在網絡環路現象。果然，當筆者在全局系統配置模式下，執行“display interface e0/12”字符串命令查看該端口的工作狀態時，發現該命令無法成功被執行，看來該端口下面的網絡環路現象已經將該端口的傳輸通道堵塞起來了。為了避免e0/12端口繼續影響整個位于八樓的二層交換機工作狀態，筆者立即執字符串命令“interface e0/12”，進入e0/12端口的視圖模式狀態，在該狀態下繼續執行“shutdown”字符串命令，將該端口的工作狀態暫時關閉;此時，筆者再次查看位于八樓的二層交換機級聯端口狀態時，發現該端口的輸入、輸出數據包大小已經變成了每秒200MB左右，并且進行上網測試時，整個八樓的計算機上網狀態都恢復正常了，至此筆者基本認定上述故障就是由于e0/12端口下面存在網絡環路引起的了。

　　經過進一步檢查，筆者了解到e0/12端口連接到813房間，到現場檢查該房間的網絡連接時，筆者看到該房間私自連接了一個交換機，恰好該房間的網絡連接由于受修理窗戶的影響，發生了變化，工作人員不小心在該交換機上制造了網絡環路現象，經過重新進行正確的物理連接，再將e0/12端口的工作狀態啟用起來，筆者看到該房間也能正常上網了，同時其他計算機的上網狀態也一切正常。

　　經驗總結

　　從上面的故障排除過程來看，巧妙將某個樓層交換機的Trunk端口配置成網絡環回受控測試功能，可以快速地定位網絡環路故障具體的發生位置;當然，即使我們沒有啟用網絡環回受控測試功能，網絡環回測試功能同樣也能通過“display loopback-detection”命令，快速定位到發生環路故障的具體端口，只是不會將該端口立即關閉，如此一來可能造成整個網絡發生堵塞現象。

　　此外，需要提醒各位注意的是，不要輕易將核心交換機的Trunk端口配置成網絡環回受控測試功能，因為如果核心交換機下面的任何一個虛擬工作子網只要發生網絡環路現象，那么局域網中所有其他虛擬工作子網的工作狀態都會受到影響