物理層故障

物理層是0SI分層結構體系中最基礎的一層。它建立在通信媒體的基礎上，實現系統和通信媒體的物理接口，為數據鏈路實體之間進行透明傳輸，為建立、保持和拆除計算機和網絡之間的物理連接提供服務。物理層涉及底層通信及相關網絡設備，像中繼器、集線器、多路復用器和網卡(NIC，即網絡接口卡)等均運行在物理層上，物理介質的質量在很大程度上決定了網絡的基礎性能。故可從如下方面了解常見的物理層故障。



1.物理線路故障

◆線路物理連接錯誤導致不能正常通信，如在局域網中直通線與交叉線的錯用。

◆電纜制作標準不統一，如雙絞線的EIMA-568-A與EIA-568-B。

◆違反接線規則或布線規則，如以太網連接的543規則。

◆模塊、跳線等物理故障。

2.網絡設備端口設置問題

◆兩端連接端口物理類型不匹配，如RS232與V.35之間的轉換。

◆通信兩端相關端口設置不正確，如速率、雙工等。

◆通信端口人為關閉等。

3.集線器故障

(1)網絡傳輸信號的質量和信號傳輸的狀態有時可能與介質的性能和質量關系不大，而與設備本身的質量有關。可以經常定期地對集線器端口發出的數字基帶信號的質量進行監測，比如，定期地看一看信號的強度、抖動、極性、前后延波形等是否符合要求。事實上會發現，一個工作了三年的集線器，可能有甚至高達5%-10%的端口存在老化問題，傳輸的信號質量大打折扣。

(2)連接距離超過線纜或相關技術要求。在局域網連接范圍較遠

網技術的要求。在傳統10M以太網中最多可以通過集線器級連四級，使網絡的最大傳輸距離可以達到600m，而當網絡升級到快速以太網時，就只允許兩個100M集線器級連了，而且兩個集線器的連接距離不能超過5m，即在100M快速以太網中使用集線器時最大傳輸范圍不能超過205m，否則就不能正常通信了，這就是由于所使用的以太網技術而限制的。

(3)電纜的連接方式錯誤。集線器之間級連時，所使用的端口不同，相應的電纜連接方式也不同，例如交換機集線器通過Uplink級連時使用直通線，而不通過Upl1ink口級聯時必須使用交又線等。

(4)網站制作集線器端口故障。集線器端口由于經常拔插以及使用劣質水鏡頭，都可能導致端口故障或接觸不良，這時可換個端口試試，或者關閉設備電源重新啟動。

網絡的分層診斷技術

為了降低設計的復雜性，增強通用性和兼容性，計算機網絡互聯都設計成層次結構，例如典型的應用性架構TCP/IP協議簇，它相應地也遵循OST的七層理論模型(所有網絡架構組成的理論框架)，這種分層體系能夠使多種不同硬件系統和軟件系統能夠方便地連接到網絡。正是基于這一網絡結構特點，網絡管理員在分析和排査網絡故障時，可充分利用網絡這種分層的特點，把網絡故障層次化、簡單化，快速準確地定位并排除故障。然而在實際故障排查過程中，這種分層方法往往被忽略，導致故障排査效率降低。



OSI的層次結構把每層功能及職責范圍定義得非常清晰，為管理員分析和排查故障提供了非常好的組織方式。由于各層相對獨立，按層排査能夠有效地發現和隔離故障，因而一般使用逐層分析和排查的方法。通常有兩種逐層排查方式，一種是從低層開始排査，適用于物理網絡不夠成熟穩定的情況，如組建新的網絡、重新調整網絡線纜、增加新的網絡設備；另一種是從高層開始排查，適用于物理網絡相對成熟穩定的情況，如硬件設備沒有變動。無論哪種方式，最終都能達到目標，只是解決問題的效率有所差別，第一種方法較為普遍。

具體采用哪種方式，可根據具體情況來選擇。例如，遇到某客戶端不能訪同Web服務的情，如果管理員首先去檢查網絡的連接線纜，就顯得太悲觀了，除非明確知道網絡線路有所變動。比較好的選擇是直接從應用層著手，可以這樣來排查:首先檢查客戶端Web瀏覽器是否正確配置，可嘗試使用瀏覽器訪問另一個Web服務器:如果Web測覽器沒有問題，可在Web服務器上測試Web服務器是否正常運行:如果Web服務器沒有問題，再測試網絡的連通性。即使是Web服務器問題，

從底層開始逐層排查也能最終解決問題，只是花費的時間太多了。如果碰巧是線路問題，從高層開始逐層排查也要浪費時間。在實際應用中往往采用折中的方式，凡是涉及網絡通信的應用出了問題，直接從位于中間的網絡層開始排查，首先測試網絡連通性，如果網絡不能連通，再從物理層(測試線路)開始排查:如果網絡能夠連通，再從應用層(測試應用程序本身)開始排査。

據統計，網站建設網絡故障有35%在物理層，25%在數據鏈路層，12%在網絡層，10%在傳輸層，8%在對話層，7%在表示層，3%在應用層。由此可以看出網絡故障通常發生在網絡七層模型的下三層，即物理層、鏈路層和網絡層，對應于實際的網絡也就是我們使用的網線、連接模塊、網卡、交換機、路由器等設備故障。這些故障可能因為產品的質量或性能、磨損老化、人為誤操作、不正確的設置以及管理缺陷等原因而經常性地發生。其后果輕則影響單個站點的信息傳送，重則可能造成網絡重要設備:服務器、交換機和路由器的宕機，導致全網絡的癱瘓。

確定解決方案

當確定了最終可能導致故障的原因之后，就可以方便地制出相關問題的解決方案，包括故障的診斷計劃，在此同時，有兩個方面要特別注意:一是可以考慮用一個最可能的故障原因進行診斷，來觀察這種改變對故降的影響；二是要考慮解決方案能否破壞故障的基本現象，是否有辦法把所做的改變恢復為原狀。



在執行解決方案前，還需考慮以下幾方面問題

所確定的原因是否真是故障原因，需要相應的診斷結果或報告作支撐。

◆是否可以對設定的解決方案進行預先的測試，并制定故障的診斷計劃。

◆實現解決方案預定的結果是怎樣的?

◆所制定的解決方案對于網絡的其他部分有沒有影響?

相應地，在實施某一項方案或計劃之前，還必須做好相應的準備工作，因為實施解決方案可能導致筆試實施前更壞的情況，無論故障以及解決方案是否涉及整個網絡還是個別的用戶，都應該考慮怎么樣把事件恢復到初始狀態。所以在實施解決方案前必須完成以下相關的操作

◆保存全部的網絡設備配置文件

的各段的置文件進行備份記錄。

◆記錄網絡的基本拓撲結構，設備的物理位置以及各設備之間線路的連接關系、端口號等。

◆網站設計建立最終的基準，以便對新舊結果進行對比，同時在需要恢復時可以作為比較的依據。