癥狀

某網站IT經理顧先生是我們的老朋友了，三年前在Cisco大會上認識，彼此“情投意合”，“兄弟”幾個經常在一起交流一些網民心得。他原先在一家國有大型企業(yè)中任信息中心主任，負責網絡的規(guī)劃、設計建設和管理維護事宜。有好長一段時間沒有他的消息，免費的信箱失效，加之后來換了工作就失去了聯(lián)系。正思量怎么設法跟他重新取得聯(lián)絡，沒想到他卻不請自到，來了個“自投羅網”，昨天他因網絡問題來網絡醫(yī)院咨詢時方知其現(xiàn)在已經辭職到了現(xiàn)在的網站。顧不上仔細詢問對方的近況，他便直接進入主題：顧先生所負責的網站最近出現(xiàn)一些問題。白天時常會出現(xiàn)短暫的擁塞，上網用戶反映訪問購物頻道之網上在線商城時經常點擊無效，多次重復后仍沒有任何反應。此現(xiàn)象已經持續(xù)的兩周，網站老總責令他必須在兩天內找出原因，解決用戶無法點擊購物的問題，否則……

故障出現(xiàn)在什么時候？一般是白天，晚上基本不出現(xiàn)。何時開始出現(xiàn)故障征兆的？沒有什么征兆，突然出現(xiàn)又突然消失，很不穩(wěn)定且沒有什么規(guī)律。

那么從第一次故障現(xiàn)象出現(xiàn)到今天為止有多久了？就兩周。

兩周前你們對網絡干了什么？比如調整網絡結構、增加或刪除網絡設備、增加服務器、增刪和更改網絡用戶等？沒有。不過網站內容到是幾乎天天在變，但這應該不會有什么影響。因為我們裝有網管系統(tǒng)，可以隨時查看網絡個鏈路的流量狀態(tài)。對鏈路的流量還分別設置了門限報警，如果出現(xiàn)流量異常值班人員會馬上知道。再說，我們的內部網都是用的100Mbps的網卡，核心交換機使用千兆以太網連接。而網站出口只是8Mbps，出問題時檢查過出口流量，從來就沒有超過2Mbps，還不如不出故障時的訪問流量大。因此，說由于出口瓶頸的原因在訪問流量大造成訪問困難顯然是站不住腳的。對網上商場的服務器仔細檢查并用備用服務器試著更換過，但沒有任何作用。該用的辦法都用過了，實在查不出問題出在哪里。

有沒有做過捕包分析或延遲分析？做過，首先對有關的服務鏈路進行網管監(jiān)察，發(fā)現(xiàn)鏈路流量一般只有5%左右，捕包分析發(fā)現(xiàn)出現(xiàn)故障是有較大延遲，但Ping包正常。當時試驗在故障時在網站內任選一臺工作站從網上商城服務器拷貝一個1000M的文件，拷貝速度很快。用協(xié)議分析儀的專家診斷系統(tǒng)對捕獲的包進行分析，除了發(fā)現(xiàn)HSRP協(xié)議幀有3000個，其它未見異常。

診斷過程

三刻鐘后，我們隨顧先生來到該網站所在大廈。準備著手進行檢查。

分析故障現(xiàn)象，指示網絡主要的問題是訪問某個指定的服務器時慢。一般的原因主要有：服務器資源不足，比如接口速度低、CPU速度低、內存不夠、開通的應用窗口過多等；訪問通道出現(xiàn)瓶頸，訪問速度受限；通道上的設備出現(xiàn)處理延遲，影響通道訪問的速度等。從內部網的反應看，拷貝文件的延遲很小，速度正常。基本說明網站的內部網絡應該沒有大問題。

為了確認訪問通道上的是否有流量瓶頸或延遲超長，我們將網絡故障一點通接入路由器的出口，將網絡綜合協(xié)議分析儀OptiView接入在線商城服務器通道。從路由器出發(fā)送50Mbps(50%)高流量Ping包指向OptiView，這種方法是為了檢查該通道的通道能力。可以看到最大的通道能力是95Mbps(發(fā)送的流量相應的流量加上為95Mbps)，將流量幀改為一般的IP幀，無須服務器響應，流量仍為50%，此時安裝在服務器鏈路中的OptiView收到的流量是50Mbps，說明網絡一點通發(fā)送的50Mbps的流量已經全部“安全抵達”服務器。此時的網絡狀態(tài)非常“正常”。從OptiView測試對路由器Ping包的響應，顯示時間為12微秒(0.012ms)，結論：此時此刻網絡工作正常。

由于是不穩(wěn)定出現(xiàn)的“軟故障”，接下來我們需要在故障出現(xiàn)時進行測試，好在該故障每天白天都會出現(xiàn)，不怕它不來。

50分鐘后，從外線來的電話報告“故障出現(xiàn)”。我們迅速用OptiView的移動網管查看該通道的流量狀態(tài)，顯示均小于10%，從OptiView上對網站的路由器做Ping檢查，時間是1200ms。立即從OptiView發(fā)送50Mbps流量給網絡一點通，報告收到的流量只有5M，看來不光45M的流量被通道給“濾除”了，而且還引入了很大延遲。檢查網站的拓撲圖，從圖上標注的狀況來看該訪問通道應該都是100Mbps的以太網鏈路，中間經過5臺交換機到達服務器。在OptiView上對路由器做路徑“TraceSwitch”檢查。結果顯示路徑已經改變！整個路徑中多出了3臺交換機，從而使得原來需要經過5臺交換機就能到達服務器的訪問包現(xiàn)在需要經過8臺交換機才能到達服務器！追蹤查看這3臺交換機，發(fā)現(xiàn)相應鏈路端口工作狀態(tài)都是100Mbps。逐級檢查延遲響應時間，發(fā)現(xiàn)1200ms的延遲就出現(xiàn)在新增加的第一臺交換機通道節(jié)點上。由于有備份交換機，為了縮短故障診斷時間，試著更換此交換機。10分鐘后，交換機更換完畢，開機試驗，故障現(xiàn)象消失。

繼續(xù)監(jiān)測至下午收工時間，故障均未再出現(xiàn)。

診斷評點

此故障是由于交換機的問題引發(fā)的。白天工作時該交換機會不穩(wěn)定地處在較大時間延遲狀態(tài)，并且會改變交換機對協(xié)議的傳輸路徑。從該故障的表現(xiàn)和OptiView監(jiān)測到部分STP/HSRP協(xié)議來分析，一般配置不良的交換機會出現(xiàn)類似情況。比如，使用STP或HSRP協(xié)議可以對端口的連接狀態(tài)進行監(jiān)測和從新依據(jù)傳輸?shù)膸挕⒃试S或限制的協(xié)議進行端口連接分配。這在高檔交換機中是正常的功能，但如果設置不佳或網絡出現(xiàn)異常未設定點流量，交換機也會依據(jù)設定點條件進行端口路徑的檢查、運算和重新連接構圖，或者對流量帶寬進行分配。

網絡的配置文檔是很重要的檢查故障的參照系，準確的文檔備案更是快速故障檢測的有力輔助手段。反之，沒有配置文檔的備案資料會給故障檢測帶來不少麻煩。維護人員往往不能斷定檢測的參數(shù)到底是正常還是異常。一份不準確的文檔備案有時甚至比沒有文檔病案更糟糕，它可能會把故障檢測工作引向"萬劫不復"的境地。那時有多少頭痛藥都是無濟于事的。維護人員神經、耐心和體力都會收到很大的挑戰(zhàn)。

診斷建議

由于時間關系，我們來不及對更換下來的交換機進行檢查。根據(jù)以往經驗，可以初步斷定此交換機很可能是配置不良而不一定是有質量問題。我們希望顧先生安排專門時間將此交換機的設置仔細檢查一番。如果能找到原來的初始配置文檔則參照檢查會方便許多。

后記

一周后，顧先生告知我們檢查結果：該交換機某些端口被人設置為流量選擇轉發(fā)狀態(tài)。處于這種設置狀態(tài)的交換機會對鏈路流量在達到一定值時進行端口路徑的重新分配，目的是均衡整個鏈路的負載。也可以對設置的協(xié)議進行端口路徑轉移，使得按設置要求的在某些協(xié)議或流量出現(xiàn)異常時轉移交換端口或重新分配端口流量。

本故障經檢查是由于最近安裝了Oracle應用軟件所至。當啟用該數(shù)據(jù)庫流量時，原來的端口只允許部分流量用來處理在線商城的用戶訪問流量，其它的帶寬要用來保證新增加的應用流量對帶寬的需要。

由于顧先生對Oracle關系數(shù)據(jù)庫不熟悉，該項應用工程是承包給一家系統(tǒng)集成商做的。系統(tǒng)集成商在安裝系統(tǒng)時為了一次驗收合格，故對交換機的配置進行了更改。這一點顧先生的一名配合系統(tǒng)集成商工作的手下是知道的，但他對網站的拓撲結構根本不了解，以為此舉對網絡沒有什么影響，并沒有將此情況告之顧先生。

由于該網站平時就沒有定期檢查和文檔備案的制度，這位老兄當然也不會把這一情況登記入檔。這使得我們的檢查效率也不會高到哪里去，端時間內要查驗出該故障撓度是會很大的。