通常這種看似簡單的故障實際上很難直接判斷其產生的原因,有時可能是網絡本身的問題,或是網絡應用的問題,還有時可能與網絡或服務設備的配置有關。因此從哪里入手進行測試變成關鍵問題。為了進一步了解用戶網絡的整體情況,我們決定首先安裝一套美國福祿克公司的網絡監測管理軟件,以便能獲得更多的網絡信息。這套軟件采用分布式結構,我們在用戶的各個網段內分別安裝一個監測站,用我們的筆記本電腦作為監測控制臺與各監測站通信,獲取信息并集中顯示(見圖二)。
圖一、網絡的結構示意

圖二

從上述圖中,我們可以概括了解每個網段中都有哪些設備(服務器、交換機、路由器、RMON設備等)?這些設備是否出現了嚴重的問題(注意紅色的圓點)?每個站點的流量情況是否有異常(柱狀圖中是否出現紅色的部分)?在確定沒有太大問題后,我們開始查看網段的詳細信息并找到了用戶抱怨的服務器,見圖三。

在沒有得到直接有價值的信息后,我們使用“交換路由追蹤”功能測試一下某一個客戶端到該服務器的傳輸鏈路情況,見圖四。從圖中我門可以看出該客戶機和問題服務器2正好連接在同一個Cisco交換機的端口3和端口5上。該交換機連接客戶機的端口3開啟了歷史記錄功能,可以方便地得到流量、廣播、沖突和錯誤方面的統計信息,圖中顯示該端口沒有任何網絡層的問題。而連接服務器的端口5則沒有啟動歷史記錄功能,因此無法得到服務器方面的統計數據。
問題的根源是不是在服務器這一邊?我們立即在圖一的3位置將Optiview便攜式網絡綜合協議分析儀接入服務器所在的網段。通過網絡搜索功能很快找到這臺Cisco交換機并查看連接服務器的交換機第5端口的流量情況,見圖五。發現該端口流量并不大,不應該造成客戶端訪問慢的故障。轉而檢查端口錯誤情況也沒有發現錯誤的數據包,但是存在沖突的現象。
圖四、交換路由追蹤

圖五、第5端口的流量情況

圖六

這個異常情況引起了我們的注意,該端口只連接服務器唯一一個設備,怎么會有沖突呢?我們切換到交換機列表狀態進一步檢查該端口的信息(見圖六)發現連接速率是10M/半雙工,而該交換機是支持全雙工連接方式的,有沒有可能是服務器和交換端口雙工不匹配的原因?在征得用戶同意后,我們斷開服務器與交換機的連線,串接進去一個網絡萬用表進行測試,得到的結果證實了我們的推測(見圖七)。
服務器的網卡工作在全雙工模式,而交換機端口自適應功能失敗,使其只工作于半雙工模式,這樣就造成兩端的雙工模式不匹配,產生沖突錯誤。初步找到故障原因后,用戶臨時將服務器的網絡設定為半雙工模式后,我們同樣從服務器上拷貝一個30Mbytes的文件只需要十幾秒鐘,而且采用Optiview監視也沒有發現沖突現象。問題得到確認,解決問題的方法竟如此簡單,只需將圖七中顯示的交換機的端口工作模式手工設置成全雙工的模式即可。
圖七、雙向箭頭顯示著全/半雙工的工作狀況

背景知識:
那么不匹配的雙工模式為什么會產生沖突,進而影響整個網絡的數據傳輸呢?因為運行全雙工的設備不遵從(帶沖突檢測的載波偵聽多路訪問)過程。如果全雙工設備有數據幀要發送,它就直接發送而不關心當前是否在接收數據。此時,如果與其相連的一個半雙工設備恰巧也正在發送數據,則必定發生沖突。遵從CSMA/CD的半雙工設備會立即發送一個阻塞信號,在退避延時時間過后,它將重新發送數據并引發網絡性能的下降。
如果交換機內部開啟了SNMP或具有RMON功能,則會統計沖突數量并記錄在MIB庫中。當我們接入Optiview網絡綜合協議分析儀后,通過其讀取交換機中MIB庫的信息就可發現沖突發生的歷史記錄,正是這一統計信息引導我們找到了困擾用戶很長時間的網絡故障。
經驗與總結
在排除比較復雜網絡的故障時,我們常常要通過多種的角度來測試和分析故障的現象確定故障點,我們會采用自上(網管系統)而下(現場測試)相結合的方法,還要采用理論和經驗相結合的技術背景。
在分析和解決互聯的網絡中訪問性能的問題時,我們通常有這么幾個分析的模型和方法:
1.七層的網絡結構分析模型方法:從網絡的七層結構的定義和功能上逐一地進行分析和排查,這時傳統的而且最基礎的分析和測試方法。
這里有自下而上和自上而下的兩種思路。自下而上:從物理層的鏈路開始檢測直到應用。自上而下:從應用協議中撲捉數據包,分析數據包統計和流量統計信息以獲得有價值的資料。
2.網絡連接結構的分析方法:從網絡的連接構成來看我們可以大致分成客戶端、網絡鏈路、服務器端三個模塊。
a) 在分析和檢測中故障可能來自客戶端的各種情況,客戶端也具備網絡的七層結構,也會出現這樣那樣的故障,從硬件到軟件,從驅動到應用程序,從設置錯誤到病毒等等。所以在分析和測試客戶端的過程中要有大量的背景知識,有時PC的發燒經驗也會有所幫助。在實際的測試過程中可以在現場詢問客戶端的用戶,他們反映的問題是個性的還是共性的,這個問題會非常有助于決定對客戶端的進一步檢測的決定。
b) 來自網絡鏈路的問題通常需要網管、現場測試儀、甚至是協議分析儀來幫助確定問題的性質和原因。這個方面的問題分析要有堅實的網絡知識和實戰經驗,有時實戰經驗會決定排除故障的時間。
c) 在分析服務器端的情況時更需要有網絡應用方面的豐富知識,我曾經排除過這樣的一個故障,最終定位在服務器上的數據庫參數設置上!要了解服務器的硬件性能及配置情況、系統性能及配置情況、網絡應用及對服務器的影響情況。
3.工具型分析方法:有強大的各種測試工具和軟件,它們的自動分析和專家系統能快速的給出網絡的各種參數甚至是故障的分析結果,這對解決60%的常見網絡故障有效。
4.綜合及經驗型分析方法:靠時間、錯誤與成功的積累,在大多數的網絡測試工程師的工作中都是采用這個方法,再結合網管和測試工具迅速定位網絡的故障。
本案例的分析中,我們首先要確定問題是否是共性的、然后試探確定問題是否發生再網絡鏈路上、有幸的是這個問題的測試過程就到這里結束了,否則不知要動用多少的腦筋和設備進行更多的分析了。
通過這個典型案例不難看出,要快速有效地排查網絡故障,簡單依靠單一手段和測試設備是很難的,只有通過多種測試儀器和經驗的相互配合,采用排除法逐步縮小故障范圍才能最終查找出故障原因加以排除。