本文主要給大家詳細的介紹了對于網速變慢，局域網影響等問題，這里給出了詳細的介紹，詳細看過此文對于故障排除有所幫助。

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

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

網速突然變慢

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

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

故障排查過程

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

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

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

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

徹底解決故障

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

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

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