經典故事:網絡醫院的故事（三）

2019-11-04 20:31:32

字體：大中小

來源：轉載

供稿：網友

　　[故事之五]
　　
　　雛菊鏈效應導致網絡速度變慢
　　
　　[癥狀]
　　
　　下午某市工商局信息中心來電，其下轄的某縣工商局今晨與市局的聯網出現問題，速度與往常相比速度慢了許多。其中與該縣工商大廈七樓的計算機基本上不能進行數據交換。而與其它樓層的計算機通信雖然速度較慢但還基本上能維持正常的數據交流。由于該市在規劃計算機網絡廣域聯網方案時沒有考慮將來自身維護的問題，只是簡單地在工程合同中將維護工作交給工程承包商負責，自己沒有配備專門的工具和培訓專門的人員來維護網絡。該工程承包商當時負責此項工程的人員早已離開這家公司，故對今日的故障只能表示愛莫能助。經人介紹找到了網絡醫院。
　　
　　[診斷過程]
　　
　　我們當晚即乘火車抵達該市并連夜開始查找故障。該市網絡規模挺大，下轄7縣6區87個工商所，市縣局之間用64K的DDN鏈路連接，工商所與縣區局之間用電話線連接。從市局向故障的縣局用F683網測試儀作通道測試，速度4K時就上不去了，響應時間804ms，ICMP Ping顯示縣局路由器連接成功率在1/7左右。將縣局網下掛的所有網絡設備斷電并拔下所有與路由器相連的聯線插頭，只留下路由器和一臺集線器、一臺筆記本電腦與之相連，再作通道測試速度為54k，響應時間46ms，ICMP Ping成功率100％。由此證實故障不在DDN鏈路，而在縣局網絡本身。
　　
　　驅車前往縣局工商大樓，恢復大樓網絡設備的供電，插上全部線纜插頭，然后將Fluke公司的F683網絡測試儀接入網絡進行網段掃描，30秒后顯示雙路由器ip地址錯誤，伴隨少量FCS類型幀錯誤。顯然，故障與地址設重的這臺路由器有直接關系，但網管人員不知道這另一臺路由器來自何方，查機器文檔備案資料也無此路由器的資料。經再三詢問網絡治理人員，才想起原來有一個廢棄的備份路由器，半年前就早已經不工作了。雖未從早期不用機架上拆下來，但一直未讓其上電工作(電纜聯線也未摘下)。我們檢查該路由器時卻發現它正在上電工作?。?，系何人所為暫且不查，立即將電源插頭拔下另路由器斷電，一分鐘后市局來電網絡速度恢復正常。此時F683網絡測試儀雖然顯示雙重地址消失，但仍然有少量FCS類型幀錯誤，這說明網絡還存在問題，而且主要是布線及鏈路設備的問題。聯系七樓數據交換比其它樓層困難的故障現象，用F683向各樓層的計算機定點發送流量，結果發現與一樓、二樓和市局的定點數據發送FCS幀錯誤明顯增高，其它樓層正常。基本可以斷定是由于雛菊鏈效應造成的典型故障。據網絡治理人員介紹，本網絡平時就感覺七樓與市局和一樓、二樓的網絡連接速度有時變慢，偶然會有中斷現象。查工程圖紙，上面只標有一到五樓的布線及網絡設備的分布圖。六樓七樓的設備由于是半年前該局自己增加的，所以沒有標示。無賴我們只得沿集線器布線方向查找網絡連接結構。簡單的計數就可以知道，七樓的設備與一樓、二樓的設備(路由器在二樓)集線器總數為5個，這很輕易引起數據包的延遲碰撞(在10Base-T網絡中則表現為FCS類型錯誤幀)。
　　
　　[診斷評點]
　　
　　雛菊鏈效應是指局域網(10M網)內任何兩個站點之間的集線器數量超過4個后引起的數據傳輸時間超長而引發的網絡錯誤現象。本案中七樓、六樓為后來增加的網絡，網絡治理人員沒有規劃網絡就想當然地將集線器按級連方式連接起來，結果出現雛菊鏈效應。假如不是有人昨天將備份路由器偶然接入網絡造成廣域網故障，雛菊鏈效應還將作為一隱患長期潛伏下來。
　　
　　一般來講，路由地址競爭將引發嚴重的路由瓶頸問題，另外路由與服務器、交換器等地址競爭也同樣會引起嚴重的帶寬平衡問題。路由與工作站地址競爭情況會好一點。
　　
　　該市工商局的網絡維護和治理可以說基本上處于空白狀態，這也是國內許多網絡維護治理的典型現狀。假如說前幾年主要精力放在了網絡的建設上，那么現在該是將網絡的健康維護工作提到議事日程上來的時候了。否則隨著網絡規模、速度和復雜性的增加將會后患無窮。
　　
　　[診斷建議]
　　
　　改變六樓、七樓的集線器連接方式，或者重新做正規布線；指定專人妥善治理備份路由器；培訓網絡維護和治理人員，配備適當的維護工具，對網絡的工作狀態做一些必要的定期測試和登記。另外，網絡的文檔備案工作非常重要，一定要仔細做好這項日常工作，硬件備案時一定要將機器的Mac地址一一對應備案。
　　
　　[故事之六]
　　
　　服務器網卡物理功能的失效,導致網絡癱瘓,僅在小數據量時能夠維持網絡活性
　　
　　[癥狀]
　　
　　某銀行向醫院求助，其西城區整個網絡癱瘓，與電腦中心的聯絡基本中斷，只偶然有部分交易能達成，但速度很慢，不知何故。由于電腦中心的網管系統也陷于癱瘓狀態，無法觀察任何網上設備的情況。
　　
　　[診斷過程]
　　
　　系統故障是凌晨4:30左右出現的(約4小時前)，值班員當時發現網管系統有報警信號，20秒鐘后網管機就基本上處于死機狀態了，想進一步了解故障，遂將系統重新啟動過三次，每次網管機都在20秒鐘左右失效，而主服務器和網管機脫機自檢均正常。
　　
　　詢問各營業所網絡內部工作情況，回答正常，只是交易動作無法實現?？梢曰緮喽ü收暇驮谥行牡挠嬎銠C系統中。中心除了配置有HP公司的網管軟件OpenView外，沒有再配備其它任何網絡維護工具。所以一旦網管系統不能正常工作，運行維護人員也就無從下手。東城區和西城區的網絡主服務器分別在兩個不同的網段中，之間用交換器連接起來。全城結算主機與東城區主服務器在同一網段。用F683網絡測試儀接入東城區正常工作的網段觀察，發現Cisco5500交換機的Plot3Port4(第3插槽的第4端口)有異常流量，而該端口連接的正是西城區主服務器和網管系統所在的網段。為更仔細地觀察此網段的工作情況，將F683網絡測試儀和協議診斷器PI接入該網段，測得網絡持續流量為97％，其中錯誤幀占98％。錯誤類型為短幀40％，幀常50～60字節不等，長幀58％，幀長3000～5200字節不等，并報告了出錯機器的Mac地址。依此地址查找對應的機器，遺憾的是該電腦中心沒有Mac地址備份表(只有IP地址和符號名對應表)。試著用ICMP的Ping查找網管機和服務器，顯示Mac地址對應的是服務器的IP地址。重裝服務器網卡驅動程序，無效，用F683測試服務器端口，協議顯示Unknown，更換服務器網卡，重裝驅動程序并設置響應參數，重啟系統即恢復正常。
　　
　　[診斷評點]
　　
　　服務器網卡已經損壞，發出的數據幀錯誤率為98％，只有不足1％的數據正常。所以網絡偶然還有交易可以達成。我們知道，超長幀有封閉網絡的作用，主要是引起網絡速度變慢或網絡癱瘓，而短幀達到一定流量則會對網絡設備的工作協議造成一定程度的破壞，引起設備死機(實際測試中發現工作站對此更敏感些)。網管機上網時在收到高錯誤流量幀后約20秒鐘即被破壞死機，無法觀測參數。許多設備在自檢時只檢查部分參數(有些參數尤其是某些物理參數無法僅靠自檢來測試)，此案例中網管機和主服務器自檢表現正常，而實際上主服務器的網卡物理功能已經失效，但在自檢時與操作系統的通信協議能正常工作，靠1％左右的正常幀可以維持極低的網絡活性。其它網站會在高流量錯誤幀的"轟炸"中陸續喪生。
　　
　　[診斷建議]
　　
　　交換機用來隔離網段和網絡故障有較好的作用，主服務器、網管機等重要網絡設備應以獨享交換機端口為佳，不宜再用共享式集線器連接上其它設備，這樣可以迅速孤立出故障設備，減少因網絡停運造成的損失。假如恰好碰到交換器故障，那么根據網絡拓撲結構圖就可以迅速定位交換機的問題，提高維護工作的時效性。另外，Mac地址是文檔備案的最重要內容之一，除了用于排除網絡設備故障有極大方便外，對于迅速查找我們稱之為"惡意用戶"的非合法上網成員也有很大幫助。

上一篇：網卡故障導致網絡風暴，同一網段內的計算機間無法通訊

下一篇：經典故事:網絡醫院的故事（四）