- 相關推薦
網絡故障處理案例分析
對網絡整體結構的掌握,是處理網絡故障的前提，下面是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公司的人員沒有將老平臺卸載，而是簡單地停止啟動運行。后繼的網管人員在交接時因不熟悉這些協議及其用途，沒有進行清理。最近的這次的網絡升級工程安裝調試時根據原先的網管記錄和服務器平臺的提示重新安裝并啟動運行了這些軟件。詢問負責軟件安裝的網管人員是否了解這些軟件的用途，答曰因為在老平臺的窗口中一直看見這些軟件，其間也曾詢問過一直任職的財務經理，證實有用，所以才重新安裝之。實則該平臺的設置與新的應用軟件之間有嚴重沖突，并同時干擾現行應用軟件的有效工作。兩臺服務器之間一直在互相詢問并重新發送無法處理的無效數據包，除了干擾其它協議外，直接的結果就是占用大量的網絡帶寬，破壞數據的傳輸和處理，致使網絡速度變慢并時常出錯。
另外，網絡部手里的診斷軟件都是基于視窗環境的應用軟件，無法觀察其它應用的流量。
[診斷建議]
協議的無縫互聯和互操作是軟件開發工程中的難點。實際的應用軟件品質并不如開發商所標榜的那樣樂觀。為了使網絡的工作效率達到最佳，網管人員需要經常監測網絡協議數量及其工作狀態。對于無用的協議要即時清理之。重要網絡在協議監測對新出現的協議還要監測其操作過程，查找其來源。因為許多網絡在遭到黑客攻擊時常會伴隨某些新協議的活動。
【網絡故障處理案例分析】相關文章：
常見的網絡故障分析與處理01-07
網絡故障診斷案例盤點01-23
有關網絡故障的綜合分析匯總03-06
DNS服務網絡故障案例解析01-23
溝通案例分析03-09
沃爾瑪經典案例分析06-22
小米戰略案例分析03-07
經典廣告案例以及分析06-20
管理溝通案例分析02-26