這些常見的網絡故障，你都知道如何解決嗎

很多弱電圈的朋友經常提到網絡故障，其中在交換機組網時常見的故障比較多，為了便于大家排除這些故障，在此介紹一些常見的典型故障案例及處理思路。

故障 1：交換機剛加電時網絡無法通信

故障現象

交換機剛剛開啟的時候無法連接配接至其他網絡，需要等待一段時間才可以。另外，需要使用一段時間之後，通路其他計算機的速度才快，如果有一段時間不使用網絡，再通路的時候速度又會慢下來。

故障分析

由于這台交換機是一台可網管交換機，為了避免網絡中存在拓撲環，進而導緻網絡癱瘓，可網管交換機在預設情況下都啟用生成樹協定。這樣即使網絡中存在環路，也會隻保留一條路徑，而自動切斷其他鍊路。是以，當交換機在加電啟動的時候，各端口需要依次進入監聽、學習和轉發狀态，這個過程大約需要3~5分鐘時間。

如果需要迅速啟動交換機，可以在直接連接配接到計算機的端口上啟動“PortFast”，使得該端口立即并且永久轉換至轉發狀态，這樣裝置可以立即連接配接到網絡，避免端口由監聽和學習狀态向轉發狀态過渡而必須的等待時間。

故障解決

如果需要在交換機加電之後迅速實作資料轉發，可以禁用擴充樹協定，或者将端口設定為PortFast模式。不過需要注意的是，這兩種方法雖然省略了端口檢測過程，但是一旦網絡裝置之間産生拓撲環，将導緻網絡通信癱瘓。

故障 2：5口交換機隻能使用4口

辦公室中有4台計算機，但是隻有一個資訊插座，于是配置了一台5口（其中一口為UpLink端口）交換機。原以為4台計算機剛好與4個接口連接配接，1個UpLink端口用于連接配接到區域網路，但是接入到網絡之後，與UpLink端口相鄰的1号口無法正常使用。

UpLink 端口不能被看作是一個單獨的端口，這是因為它與相鄰端口其實就是一個端口，隻是适用的連接配接對象不同而已。借助UpLink端口，集線裝置可以使用直通線連接配接至另外一個集線裝置的普通端口，這樣就不必使用交叉線。

交換機和集線器的晶片通常為×4，是以集線裝置端口大多為4口、8口、16口、24口等，如果制作成5口，就會浪費3個子產品，進而增加成本。

将4口交換機更換為8口交換機，即可解決故障。

故障 3：“COL”訓示燈長亮或不斷閃爍，無法實作通信

區域網路中計算機通過集線器通路伺服器，但是某日發現所有用戶端計算機無法與伺服器進行連接配接，客戶機之間Ping也時斷時續。檢查集線器發現“COL”訓示燈長亮或不斷閃爍。

“COL”訓示燈用于訓示網絡中的碰撞和沖突情況。“COL”燈不停閃爍，表明沖突發生；“COL”燈長亮則表示有大量沖突發生。導緻沖突大量發生的原因可能是集線器故障，也可能是網卡故障。一般情況下，網卡出現故障的可能性比較小，是以将重點放在對集線器的排除方面。

更換集線器，網絡恢複正常。

故障 4：更新至千兆網絡之後，伺服器連接配接時斷時續

原先伺服器采用10/100Mbit/s網卡，運作一切正常。但是安裝了一款1000Mbit/s網卡，用其連接配接至中心交換機的1000Base-T端口之後，伺服器與網絡的連接配接時斷時續，連接配接極不穩定，無法提供正常的網絡服務。使用網線測試儀測試網絡，發現雙絞線鍊路的連通性沒有問題。

在100Mbit/s時連接配接正常，隻是在更新到1000Mbit/s時才發生故障，看來導緻這種故障的原因可能是超五類布線問題。雖然從理論上說超五類系統支援1000Mbit/s的傳輸速率，但是如果雙絞線、配線架、網線和其他網絡裝置的品質不是很好，或者端接工藝有問題，就仍然無法實作1000Mbit/s帶寬。

由于1000Base-T需要使用雙絞線全部的4對線，每對線的有效傳輸速率為250Mbit/s，并完成全雙工傳輸，是以1000Base-T對雙絞線的信号衰弱減、回波、傳回耗損、串音和抗電磁幹擾等電氣性能有了更高的要求。如果雙絞線或者其他配件的性能不好，就會線上對間産生嚴重串擾，進而導緻通信失敗。

考慮到五類布線系統的性能有可能無法滿足千兆網絡系統，是以更換為六類布線産品之後故障解決。

故障 5：盡管Link燈不停閃動，但網速卻奇慢

伺服器上網速度很慢，開始時打開網頁非常緩慢，後來甚至連網頁都無法打開，Ping網站也無法解析位址。 起初以為是DNS設定或者伺服器故障，但是這些都正常運作。嘗試Ping其他計算機，發現丢包率很高。而此時交換機的Link訓示燈不停閃爍，資料的交換非常頻繁，說明計算機在不停地發送和接受資料包。關閉交換機之後再重新打開，故障現象得到緩解，但是一段時間之後又出現這種故障。

從故障現象來看，這是網絡内的廣播風暴。廣播風暴的産生會有很多種原因，比如蠕蟲病毒、交換機端口故障、網卡故障、鍊路備援而沒有啟用生成樹協定、網線順序錯誤或者受到幹擾等。在網絡故障發生的時候檢視交換機訓示燈是一個很便捷的判斷方法，可以直覺檢視網絡連通性和網絡流量。

就目前情況來看，蠕蟲病毒是造成網絡癱瘓的最主要原因。及時為伺服器更新系統更新檔，并且安裝網絡版本的病毒清除軟體，及時為伺服器更新病毒庫，在伺服器安裝防病毒用戶端程式之後，故障得以解決。

故障 6：伺服器資源共享故障

1.無法将通路權限指定給使用者

整個網絡使用的是Windows域，用戶端是Windows2000 Professional。伺服器的IP設定為192.168.0.1，DNS是127.0.0.1，路由器的内部IP位址是192.168.0.1。用戶端全部采用自動擷取IP位址方式，并且同屬于DomainUser組。在伺服器設定共享檔案的時候，雖然可以指定權限，但是無法通路。

在Windows域中，都是使用NTFS權限和共享權限來設定共享檔案夾的通路權限。不過NTFS權限是高于共享檔案夾權限的，也就是說必須先為欲設定為共享的檔案夾設定NTFS權限，然後再為其設定共享檔案夾權限。如果兩者發生沖突，那麼将以NTFS權限為準。

先為使用者指定NTFS權限，然後再指定共享檔案夾權限。例如需要給使用者A建立一個共享檔案夾TESTA，使該共享檔案夾能夠被使用者A完全控制，而被其他任何使用者通路，就要先設定TESTA的通路權限，為使用者A指定“完全控制”權限，而為Everyone設定“隻讀”權限。同樣，在設定共享檔案夾權限的時候也要這樣設定。

2.共享檔案夾無法顯示在“網路上的芳鄰”中

已經共享了某些檔案夾，但是在“網路上的芳鄰”中無法檢視，但是同一計算機的有些共享檔案又能夠看見。

既然有些共享檔案夾可以看見，說明該計算機的網絡配置和連接配接基本正常。而且這其實并非一個故障，而是屬于共享屬性的一種配置類型。在Windows系統中，共享檔案類型主要有兩種，一種是供系統調用的；另外一種是供其他使用者通路的。供系統調用的共享檔案是不在“網路上的芳鄰”中出現的，但是可以用諸如“Net View”之類的指令顯示；供其他使用者通路的共享檔案是可以在“網路上的芳鄰”中看見的。

那麼如何配置不可見的共享檔案夾呢？隻需在共享檔案夾名後面加上一個美元符号“”符号，是以用戶端使用者是無法看見的。

将共享檔案名後的“$”符号删除，不能顯示的共享檔案就可以在“網路上的芳鄰”中出現了。

故障 7：集線器和路由器無法共享上網

多台計算機采用寬帶路由器和集線器方式，利用集線器擴充端口組網共享Internet。連接配接完成後，直接連接配接至寬帶路由器LAN口的3台機器能上網，而通過集線器連接配接的計算機卻無法上網，路由器與集線器之間無論采用交叉線或平行線都不行，且集線器上與路由器LAN端口連接配接的燈不亮。另外，集線器上的計算機無法Ping通路由器，也無法Ping通其他計算機，是什麼原因？

1.集線器自身故障

故障現象是集線器上的計算機彼此之間無法Ping通，更無法Ping通路由器。該故障所影響的隻能是連接配接至集線器上的所有計算機。

2.級聯故障

例如路由器與集線器之間的級聯跳線采用了不正确的順序，或者是跳線連通性故障，或者是采用了不正确的級聯端口。故障現象是集線器上的計算機之間可以Ping通，但無法Ping通路由器。不過，直接連接配接至路由器LAN端口的計算機的Internet接入将不受影響。

3.寬帶路由器故障

如果是LAN端口故障，結果将與級聯故障類似：如果是路由故障，結果将是網絡内的計算機都無法接入Internet，無論連接配接至路由器的LAN端口，還是連接配接至路由器。

從故障現象上來看，連接配接至集線器的計算機既無法Ping通路由器，也無法Ping通其他計算機，初步斷定應該是計算機至集線器之間的連接配接故障。此時可以先更換一根網線試試，如果依然無法排除故障，則可以更換集線器解決。

故障8：IP位址沖突

最近我的計算機經常出現下面這種情況，提示“系統檢測到IP位址xxx.xxx.xxx.xxx和網絡硬體位址00 05 3B 0C 12 B7發生位址沖突。此系統的網絡操作可能會突然中斷”，然後就掉線一分鐘左右又恢複網絡連接配接。這是什麼原因，該如何解決？

這種系統提示是典型的IP位址沖突，也就是該計算機采用的IP位址與同一網絡中另一台計算機的IP位址完全相同，進而導緻通信失敗。與該計算機發生沖突的網卡的MAC位址是“00 05 3B 0C 12 B7”。通常情況下，IP位址沖突是由于網絡管理者IP位址配置設定不當，或其他使用者私自亂設定IP位址所造成的。

由于網卡的MAC位址具有唯一性，是以可以請網管借助于MAC位址查找到與你發生沖突的計算機，并修改IP位址。使用“IPCONFIG /ALL”指令，即可檢視計算機的IP位址與MAC位址。最後使用“ARP –S IP位址 網卡實體位址”的指令，将此合法IP位址與你的網卡MAC位址進行綁定即可。

原文釋出時間為：2018-10-25

本文作者：弱電工程師

本文來自雲栖社群合作夥伴“

高效運維

”，了解相關資訊可以關注“

”。