有一些網(wǎng)絡故障是由不起眼的細節(jié)因素引起的，這些細節(jié)因素平時出現(xiàn)的次數(shù)比較少，我們在排除故障的時候很容易忽略它們，這樣一來故障排除起來就可能多走彎路，最終會影響故障的排除效率。　　

無論局域網(wǎng)運行規(guī)模多大，持續(xù)運行的時間長了，各式各樣的網(wǎng)絡故障就會出現(xiàn)了。面對網(wǎng)絡故障，正常情況下我們只要仔細觀察具體的故障現(xiàn)象，就能初步找到故障產(chǎn)生的原因，并能對癥下藥、采取措施解決故障了。不過，也有一些網(wǎng)絡故障是由不起眼的細節(jié)因素引起的，這些細節(jié)因素平時出現(xiàn)的次數(shù)比較少，我們在排除故障的時候很容易忽略它們，這樣一來故障排除起來就可能多走彎路，最終會影響故障的排除效率。這不，筆者曾經(jīng)遭遇到的一則網(wǎng)絡故障，竟然是由于某個HUB設備發(fā)生硬件損壞引起的，鑒于該細節(jié)因素出現(xiàn)的機率較小，現(xiàn)在筆者就將該故障的詳細排查過程還原出來，與各位朋友共享交流。

網(wǎng)速突然變慢

筆者管理的某行政大樓局域網(wǎng)網(wǎng)絡規(guī)模比較大，整個局域網(wǎng)大約由20臺二層交換機和一臺核心交換機組成，所有二層交換機都是通過1000兆多模光纖與核心交換機保持連接，每一臺客戶端系統(tǒng)采用100M網(wǎng)絡線纜與各個樓層的二層交換機相互連接，核心交換機通過1000兆多模光纖直接連接硬件防火墻，并租用本地電信部門提供的千兆寬帶線路實現(xiàn)共享上網(wǎng)目的。為了有效避免廣播風暴現(xiàn)象以及抑制網(wǎng)絡病毒的瘋狂傳播，筆者在核心交換機上進行了Vlan劃分，確保每一個樓層的客戶端系統(tǒng)都處于一個獨立的工作子網(wǎng)中。

平時，局域網(wǎng)中的所有客戶端系統(tǒng)上網(wǎng)都很正常，網(wǎng)絡訪問速度也是比較快的。可是，最近筆者接二連三地接到故障報修電話，說上網(wǎng)速度越來越慢，特別是在上班高峰期時段，網(wǎng)絡幾乎就不能使用。剛開始的時候，筆者還以為這僅僅是個別現(xiàn)象，并建議故障報修的用戶，動手去查殺一下自己客戶端系統(tǒng)中是否有網(wǎng)絡病毒;現(xiàn)在好了，電話求援的人數(shù)越來越多，這讓筆者意識到局域網(wǎng)中看來真的出現(xiàn)了大問題。

故障排查過程

由于電話求援的用戶來自不同的樓層，筆者下意識地認為局域網(wǎng)中可能存在ARP病毒，因為最近Internet網(wǎng)絡上經(jīng)常有ARP病毒瘋狂肆虐的消息，并且由ARP病毒造成的網(wǎng)絡故障表現(xiàn)出來的現(xiàn)象通常也是大面積上網(wǎng)不正常或者是上網(wǎng)速度緩慢，難道真的是ARP病毒在偷偷作祟?為了檢查單位局域網(wǎng)中是否真的有ARP病毒，筆者隨意找了一臺故障客戶端系統(tǒng)，依次單擊“開始”/“運行”命令，在彈出的系統(tǒng)運行對話框中執(zhí)行“cmd”命令，將系統(tǒng)切換到DOS命令行工作狀態(tài)，在該狀態(tài)下輸入字符串命令“arp -d *”，單擊回車鍵，將本地系統(tǒng)ARP列表中的內(nèi)容全部刪除，之后使用ping命令，重新測試核心交換機的IP地址，可是這一次仍然無法正常ping通核心交換機的地址，按理來說要是局域網(wǎng)意外感染了ARP病毒，刪除客戶端系統(tǒng)ARP列表中的內(nèi)容之后，我們應該能夠暫時ping通核心交換機的地址才對呀，難道故障客戶端系統(tǒng)中不存在ARP病毒?

為了弄清楚局域網(wǎng)中究竟是否存在ARP病毒，筆者決定查看一下核心交換機的日志記錄，看看有沒有由ARP病毒引起的地址沖突內(nèi)容。考慮到遠程登錄速度太慢，筆者只好火速趕到核心交換機現(xiàn)場，仔細觀察該設備控制面板上的信號燈狀態(tài)時，并沒有看到有什么異常的地方;再用筆記本電腦通過Console控制端口，連接到核心交換機上，同時以系統(tǒng)管理員身份登錄進入該交換機的后臺管理系統(tǒng)，之后將該系統(tǒng)工作狀態(tài)切換到全局配置模式狀態(tài)，并輸入“dis logb”字符串命令，單擊回車鍵后發(fā)現(xiàn)結(jié)果信息中并沒有地址沖突記錄信息，這就意味著單位局域網(wǎng)網(wǎng)絡中并沒有ARP病毒。

在排除了ARP病毒因素后，筆者開始懷疑局域網(wǎng)網(wǎng)絡的核心交換機可能出現(xiàn)了問題。于是，筆者立即在自己的筆記本電腦中，使用ping命令測試一下核心交換機的IP地址，結(jié)果發(fā)現(xiàn)ping命令測試操作存在明顯的丟包、延時現(xiàn)象，嘗試上網(wǎng)訪問網(wǎng)頁內(nèi)容時，訪問速度的確是奇慢無比。不得已，筆者再次用筆記本電腦通過Console控制端口，連接到核心交換機上，同時以系統(tǒng)管理員身份登錄進入該交換機的后臺管理系統(tǒng)，之后將該系統(tǒng)工作狀態(tài)切換到全局配置模式狀態(tài)，在該狀態(tài)下執(zhí)行“display cpu”命令時，筆者看到系統(tǒng)CPU資源消耗率竟然達到了驚人的90%，怪不得客戶端系統(tǒng)總感覺到上網(wǎng)速度緩慢，原來是核心交換機的系統(tǒng)資源被過度消耗，造成了它無法快速響應客戶端系統(tǒng)提出的上網(wǎng)訪問請求，那么究竟是什么因素強行占用核心交換機寶貴的CPU資源呢?根據(jù)以往經(jīng)驗，對待這種系統(tǒng)資源過度消耗的現(xiàn)象，通常只要簡單地重新啟動一下交換機后臺系統(tǒng)，就能將被占用的系統(tǒng)資源釋放出來了，這次會不會呢?為了一看究竟，筆者選擇下班時間，斷開核心交換機的輸入電源，過一段時間后，再接通它的電源，以便重新啟動該設備的后臺系統(tǒng)，待啟動穩(wěn)定的那一刻，筆者用筆記本電腦測試了網(wǎng)絡訪問速度，發(fā)現(xiàn)訪問速度居然恢復正常了;可是，沒有持續(xù)多長時間，網(wǎng)絡訪問速度又變得象蝸牛那樣爬行了，再測試交換機后臺系統(tǒng)的CPU資源消耗率時，發(fā)現(xiàn)該資源占用率又達到驚人的95%了。根據(jù)這一現(xiàn)象，筆者斷定局域網(wǎng)網(wǎng)絡中可能存在網(wǎng)絡環(huán)路。

為了定位具體的網(wǎng)絡環(huán)路位置，筆者在核心交換機后臺，使用“display interface”命令，依次查看了各個樓層交換機與核心交換機之間的光纖連接端口狀態(tài)信息，結(jié)果發(fā)現(xiàn)GigabitEthernet1/1/14光纖端口的狀態(tài)明顯不正常，來自該交換端口的輸出數(shù)據(jù)流量、輸入數(shù)據(jù)流量，特別大，與正常工作狀態(tài)時的輸出、輸入數(shù)據(jù)流量相差甚遠，顯然GigabitEthernet1/1/14光纖端口下面的虛擬工作子網(wǎng)中可能存在網(wǎng)絡環(huán)路現(xiàn)象。查看組網(wǎng)檔案資料，筆者發(fā)現(xiàn)與核心交換機GigabitEthernet1/1/14光纖端口相連的是來自五樓的某個樓層交換機，將該樓層交換機與核心交換機之間的物理連接斷開后，再次在核心交換機后臺系統(tǒng)上執(zhí)行“display cpu”命令，筆者發(fā)現(xiàn)這一次系統(tǒng)資源消耗下降到了正常的20%，看來整個局域網(wǎng)上網(wǎng)速度緩慢的現(xiàn)象，就是由于五樓的某個樓層交換機引起的。

徹底解決故障

既然網(wǎng)絡速度變慢的原因是由五樓的某個樓層交換機引起的，那么網(wǎng)絡環(huán)路現(xiàn)象究竟出現(xiàn)在五樓的哪個位置呢?由于連接到目標交換機下面的計算機數(shù)量不是很多，只有20臺左右，于是筆者打算采用比較“笨”的辦法，那就是將五樓交換機上的所有網(wǎng)絡線纜依次拔下來，之后每拔上一根網(wǎng)絡線纜后，就觀察該樓層交換機CPU資源消耗率的狀態(tài)變化，看看究竟是哪個交換端口在偷偷“搗亂”。功夫不負有心人，在經(jīng)過一段時間的觀察后，筆者終于將故障范圍縮小到e0/8這個普通的以太網(wǎng)電口上。

通過貼在e0/8交換端口上的標簽信息，筆者發(fā)現(xiàn)連接到e0/8這個普通以太網(wǎng)電口上的是位于503房間的一個網(wǎng)絡插座，趕到503房間時，筆者發(fā)現(xiàn)目標網(wǎng)絡插座下面連接的不是普通客戶端系統(tǒng)，而是連接的一個HUB設備;原來，這個辦公室最近新增加了幾個辦公人員，為了能讓所有的員工都能同時上網(wǎng)，于是他們自行主張，找來了一個舊的HUB設備，該辦公室中的所有客戶端系統(tǒng)全部連接到HUB設備上，進行共享上網(wǎng)訪問。由于這個HUB設備不支持網(wǎng)絡管理功能，筆者只好還是逐一拔掉網(wǎng)絡連接線纜，觀察HUB設備上的信號燈狀態(tài)變化情況;讓人意想不到的是，當筆者將連接到HUB設備上的所有網(wǎng)絡線纜全部拔掉的時候，HUB設備上的信號燈居然仍然處于全部點亮狀態(tài)，這是什么回事呢?很明顯，出現(xiàn)這種現(xiàn)象很可能是HUB設備發(fā)生了短路問題，這種損壞的設備在無形之中形成了網(wǎng)絡環(huán)路現(xiàn)象。為了驗證自己的猜測，筆者立即找來一只新的HUB設備，替換掉那只舊的HUB設備;果然，在完成設備的替換操作之后，筆者發(fā)現(xiàn)所有網(wǎng)絡線纜全部插入到HUB設備上后，它的信號燈狀態(tài)全部恢復到正常狀態(tài)了。再將5樓樓層交換機連接到核心交換機上后，筆者再次使用“display interface”命令，查看了GigabitEthernet1/1/14光纖端口的狀態(tài)信息，發(fā)現(xiàn)該交換端口的輸出數(shù)據(jù)包、輸入數(shù)據(jù)包立即恢復了正常，此時筆者通過筆記本電腦進行上網(wǎng)測試時，發(fā)現(xiàn)網(wǎng)絡訪問速度也恢復到原來的正常狀態(tài)了，至此網(wǎng)絡速度變慢的故障現(xiàn)象就被徹底解決了。

小提示：一般來說，現(xiàn)在局域網(wǎng)使用的核心交換機都支持環(huán)回受控測試功能，巧妙地利用該功能，我們可以快速地查看到究竟哪個交換端口下面存在網(wǎng)絡環(huán)路現(xiàn)象。在實際管理網(wǎng)絡的過程中，我們一旦遇到了網(wǎng)絡速度突然變慢的故障現(xiàn)象時，可以先將核心交換機中那個流量異常的交換端口配置成Trunk模式，再進入該Trunk端口的視圖配置模式，將該端口的環(huán)回受控測試功能啟用起來，日后要是局域網(wǎng)中果然存在網(wǎng)絡環(huán)路現(xiàn)象的話，那么該功能會自動關閉存在網(wǎng)絡環(huán)路的交換端口，那么整個局域網(wǎng)的工作狀態(tài)就不會受到影響了。當然，即使我們沒有啟用網(wǎng)絡環(huán)回受控測試功能，網(wǎng)絡環(huán)回測試功能同樣也能通過“display loopback-detection”命令，快速定位到發(fā)生環(huán)路故障的具體端口，只是不會將該端口立即關閉，如此一來可能造成整個網(wǎng)絡發(fā)生堵塞現(xiàn)象。