對網路整體結構的掌握,是處理網路故障的前提，下面是YJBYS收集的網路故障的案例分析，希望對你有幫助!
案例二：
[網路故障]
某大型化工股份有限公司資訊中心報告網路故障，新近進行網路的更新升級和擴容，由10M網全部提升為100M乙太網，核心交換機為千兆乙太網。完工後系統試機時發現，大部分的網路成員感覺速度慢，有時資料出錯，但子網段內拷貝資料速度基本不受影響。Ping測試檢查所有工作站和伺服器均正常。
遵照網路醫院上週的建議他們對網路佈線系統進行嚴格認證測試，佈線施工質量優良，全部電纜光纜鏈路按超五類標準測試引數均合格，沒有發現任何問題。由於資訊中心除了電纜和光纜的認證測試儀外，沒有其它測試維護工具，無法對網路進行評測。雖然仔細進行了網路系統及平臺的重新安裝，仍無濟於事。
由於總公司希望全面提高ERP系統的覆蓋範圍，新增的網路裝置比較多，網上成員也增加了二倍多，工作站從原來的220臺猛增至680臺，辦公區和生產區之間、生產區和生產區之間均用光纜和路由器連線起來，因此洪主任抱怨現在網路的管理成了問題，查詢故障不象從前那樣容易了，一來網路規模比以前大多了，故障數量和種類增多，二來網路結構變得比以前複雜多了，故障的定位分析和隔離變得比較困難。
該網路各子網段基本上採用核心交換機和工作組交換機作網路骨架，用桌面交換機和集線器混用的方式構成基層使用者接入平臺，核心交換機之間為千兆乙太網連線，使用者全部為100M到桌面。為了便於維護和管理，同時也從安全形度考慮，設計方案中將大多數資料伺服器均安裝在了網管中心。
[診斷過程]
網路為新擴容的網路，從拓撲圖上看不出網路結構設計有何不合理之處。由於在各子網段內拷貝資料時速度基本不受影響，所以分析資料多在跨網段時受阻。將網路測試儀接入辦公區網路的網管中心，開啟網段內的全部4個路由器的埠觀察，網段間的流量為27%～42%之間，由於網路沒有多媒體應用啟用，因此如此高的流量記錄是不正常的。我們需要觀察這些流量的走向，於是在辦公區將網路測試儀串入路由器與交換機之間(100M埠)監測，啟動IP矩陣監測和乙太網MAC矩陣監測功能，觀察資料流向。結果如下，大部分的資料流向均指向辦公區的WINS伺服器，而WINS響應流量極少。檢視拓撲圖，該WINS伺服器直接與一臺工作組交換機相連，開啟工作組交換機的埠記錄檢查，流量記錄為13%，伴隨少許碰撞指示記錄。
為了不影響使用者的使用，下班後我們從測試儀所在埠向WINS伺服器所在交換機埠P32的鄰近埠P31傳送高額流量，選值為90Mbps流量衝擊，並在此鄰近埠P31觀察接收到的流量記錄，記錄顯示為89.7Mbps，這說明埠P31的通道測試是合格的。然後對準WINS伺服器所在埠P32傳送90Mpbs的高額流量，觀察P32埠流量衝擊記錄，結果顯示為13.5%，並出現大量延遲幀，表明該埠通道測試不合格。將流量傳送方向指向與該埠連線的上游埠P17，觀察P17流量顯示為90Mbps。
問題很清楚，被丟棄和延遲的流量就在P32口。對WINS本身作WINS查詢，10次測試響應只有2次，響應地址正確，響應率20%。重新測試WINS鏈路電纜，合格。測試WINS伺服器網絡卡，合格;測試交換機的埠P32，低效。在此臨時將WINS伺服器埠P32改接到埠P33，重新啟動系統，5分鐘後進行上述測試，全部合格。為了驗證P32口低效，用網路測試儀接入該埠並向P17傳送90M流量，收到流量為12%。由於這臺工作組交換機為新品，尚在保用期之內，因此建議立即更換之。
[診斷評點]
網路中的大多數資料伺服器由於設定在辦公區的網管中心，所以公司整個系統的工作依賴集中式系統中的這些專用資料伺服器，鏈路連線和資料交換時需要WINS伺服器提供服務。與WINS伺服器連線的鏈路中，交換機一側的埠P32發射能力低效，使得傳送的訊號幅度不符合要求，由於鏈路長度不長，所以並不是對所有的資料包WINS伺服器都無響應。
有些資料被作為部分錯誤和碰撞資料由埠記錄之，大部分從交換機各埠送往P32埠的的資料因鏈路介面問題被延遲和丟棄，造成記錄資料中有用流量正常，而網路使用者速度普遍偏慢的假象。交換機、網絡卡、集線器和路由器等網路裝置的埠一般從工作2～3年開始出現低效現象，5年比例為3%～18%(這取決於不同的廠商產品質量，也取決於同一廠商的不同系列產品的產品質量)。由於系統中有大量的埠，所以在網路維護週期建議中要求每半年對埠效能進行定期測試。每一～二年對佈線系統進行一次輪測，尤其對重要的網路裝置如伺服器、交換機、路由器等應該堅持定期測試，這樣做對提高網路的可靠性有莫大的幫助。
[診斷建議]
建議“病人”所有網路裝置進行一次普查，將全部埠都進行備案測試，並列入定期維護的內容之一。
案例二：【多協議使用，設定不良，伺服器超流量工作】
[網路故障]
今天的故事發生在某機電進出口公司來電告知他們的網路昨天剛剛進行了升級，從10M乙太網桌面應用全部升級為100M乙太網交換到桌面，結果出現區域網內網路訪問速度反而比升級前慢的現象。有的訪問很長時間沒有結果，有的則出錯。他手裡有幾款偵測網路流量的軟體，啟動執行後也沒有發現任何問題。對伺服器的Ping測試平均小於1ms，應該不會慢，但不知何故會如此表現。
[診斷過程]
這個故障看起來比較簡單，實際診斷卻頗費周折。該網路由4個路由器經幀中繼線路與國內總部和國際分部連結，佔據4層樓面，由2臺千兆核心交換機和二級5臺工作組交換機(每層一臺)以及20臺桌面交換機(每層4臺)組成，100M交換到桌面，結構比較典型。從故障現象看，網路聯通性尚可，但速度受影響。
一般來說，速度慢的原因有很多，比如網上裝置速度跟不上要求，網路裝置出現阻塞或瓶頸效應，電纜光纜系統問題使得網路資料出錯或產生高額碰撞，網路協議設定錯誤造成無效的重複訪問，應用軟體或協議設定錯誤訪問受阻等等。由於剛更新了網路，原來的電纜系統又沒有經過認證測試，根據以往的經驗，電纜系統存在問題的.可能性最大，所以我們決定先檢查電纜系統。鑑於所有網路成員都有速度問題，我們先抽取部分電纜尤其是主要伺服器的網路電纜進行現場認證測試。
系統電纜採用的是超五類線，用電纜認證測試儀測試20條電纜鏈路，結果出伏出乎意料地全部合格!改用網路測試儀對抽測的電纜人工模擬傳送流量，結果當傳送至75%流量時，碰撞率仍不超過5%，表明網路佈線系統雖然在工程完工後沒有進行認證測試，但電纜品質和施工品質還是不錯的，實屬少見。
轉而進行網路健康指標評測，除了伺服器流量嚴重超標以外，其它如錯誤、碰撞、廣播等都合格。檢測流量分佈，基本上都集中在伺服器鏈路上，平均流量達91%。令任意兩臺工作站之間進行拷貝檔案操作，速度很快。說明問題很可能就出在伺服器與工作站的協議流程障礙上。啟動F683網路測試的ICMP Ping、ScanHost、ICMP Monitor等功能測試，檢查其IP協議的工作質量，結果顯示正常。這說明，網路連線通道效能是可以的，問題出在協議的5層以上。
啟動網路測試儀的協議分佈偵測功能Protocol Mix，結構發現其Apple Talk和BanyanVines協議流量分別為47%和39%，合計流量為86%。進一步顯示執行該協議的是兩臺主伺服器。
詢問網路部主任網路設計執行的是什麼協議，答曰全部是基於視窗環境的單一的IP協議。為何會出現Apple Talk和Banyan Vines?答曰根本未知。
由於這兩種協議有沒有參與該公司的業務流程尚且不明，故暫時不能貿然將其刪除。必須儘快核實現在的業務軟體是否依賴這兩種協議。網路部主任告知他是一年前接手網路部主任一職的，對業務流程軟體並不熟悉，但知道現在執行各軟體的供應商。我們請他立即與該軟體開發商聯絡，15分鐘後對方發來傳真明確說明該公司的軟體只在Windows平臺上執行，不支援Apple Talk和Banyan Vines等應用平臺。為慎重起見，我們請各業務部門的代表集中辨認並統計現在各自所用的操作平臺和軟體，結果都不包括Apple Talk和Banyan Vines。至此，我們決定對該協議平臺進行解除安裝。一邊操作一邊請林先生查閱以前網路檔案，結果發現了這兩種平臺的安裝軟盤和應用軟體安裝軟盤。
完成協議清理作業後，重新啟動網路，網路訪問立即恢復正常。
[診斷評點]
非工作協議是指在網規劃和絡設計中未被選用的協議和應用，但他們存在於各種網路平臺之中。作為網路上的“遊魂”之一，他們會耗用少量網路頻寬。常用的被捆綁於視窗平臺的協議如IPX、IP、NetBEUI基本上沒有衝突。所以許多使用者雖然沒有同時使用這幾種協議但也會時常同時捆綁這些協議。NetBIOS設定有多種平臺協議的輸入輸出介面，有助於眾多協議的互動工作和各種協議平臺及其應用的並存。但從網路效能優化的角度看，各種協議平臺和應用版本是由不同廠商開發的，相容性始終是一個動態適應的過程。沒有一種始終能緊密跟蹤各種協議平臺和應用協議變化、相容和協調的有效方法。從這個意義上講，多協議工作的衝突是不可避免的。
翻閱六年前網路檔案我們發現，該網路多年以前一直使用的是Apple Talk和Banyan Vines平臺協議，當時是請ALP國際公司提供的應用軟體並負責安裝工程。直到三年前才全部安裝啟用視窗平臺和基於IP協議的新的應用軟體，但APL公司的人員沒有將老平臺解除安裝，而是簡單地停止啟動執行。後繼的網管人員在交接時因不熟悉這些協議及其用途，沒有進行清理。最近的這次的網路升級工程安裝除錯時根據原先的網管記錄和伺服器平臺的提示重新安裝並啟動運行了這些軟體。詢問負責軟體安裝的網管人員是否瞭解這些軟體的用途，答曰因為在老平臺的視窗中一直看見這些軟體，其間也曾詢問過一直任職的財務經理，證實有用，所以才重新安裝之。實則該平臺的設定與新的應用軟體之間有嚴重衝突，並同時干擾現行應用軟體的有效工作。兩臺伺服器之間一直在互相詢問並重新發送無法處理的無效資料包，除了干擾其它協議外，直接的結果就是佔用大量的網路頻寬，破壞資料的傳輸和處理，致使網路速度變慢並時常出錯。
另外，網路部手裡的診斷軟體都是基於視窗環境的應用軟體，無法觀察其它應用的流量。
[診斷建議]
協議的無縫互聯和互操作是軟體開發工程中的難點。實際的應用軟體品質並不如開發商所標榜的那樣樂觀。為了使網路的工作效率達到最佳，網管人員需要經常監測網路協議數量及其工作狀態。對於無用的協議要即時清理之。重要網路在協議監測對新出現的協議還要監測其操作過程，查詢其來源。因為許多網路在遭到黑客攻擊時常會伴隨某些新協議的活動。
