這是筆者最近親歷的一起網絡故障，故障比較典型，排錯思路比較可取。我把這個過程寫下來和大家分享，希望能夠幫助到你。

1、癥狀描述

客戶來電報告中心主網絡則基本正常，而一個子網突然變慢。這是本地鐵通網絡服務公司，該公司為普通用戶提供Web服務和Internet接入服務。前幾天其服務的一個片區的用戶反映網絡速度很慢，發Email也需要等待超過60秒以上的時間才能聯通。這個片區被劃分為一個子網，從主機房的網管系統上觀察發現除了該片區(子網)路由器流量很高以外(測試為97%)，中心網絡的路由器與其它子網的交互流量均為40%以下。此外，沒有其它特別現象。

2、診斷過程

鐵通的維護人員自行進行了網絡排錯可惜沒有找到故障所在，由于不能斷開網絡停止用戶服務來進行檢查，于是求助于我們，本人被派出診。應該說，從癥狀上看這個故障比較簡單，只要查出子網的路由流量來源就可以很快確定故障方向，進一步則立即可以查出流量源。

從網絡拓撲圖上看，故障子網與中心網絡為E1鏈路。故障子網下面有一個營業廳，一般只與中心網絡交互一些業務數據應該不會有太大的流量。此外，該子網下的Web服務器數量為45臺，中心的網管系統報告97%的流量肯定是過高的。

筆者考慮只有一種情況可以比較多地占用E1通道的有效流量，那就是故障子網下的網站與中心網絡的網站或服務器之間有多媒體文檔的傳輸或者下載業務才會造成這種情況。不過詢問管理人員得知中心網絡并不提供諸如多媒體視頻的播放和下載服務，那只能借助工具進行檢測了。

由于故障網絡規模比較小，中心網絡的網管系統只支持到路由器一級的管理，交換機和服務器等采用的是廉價的桌面交換機，所以無法支持網絡管理。將網絡測試儀接入交換機進行測試，啟動便攜網管功能，可以看到路由器的流量和網管系統觀測的到的流量是相同的，均為97%左右。

查看中心網絡處與此相連的路由器流量，也是997%左右，這說明路由器通道鏈路性能基本正常。不過這樣高的通道流量必然導致路由器擁塞和丟包，所以從流量的角度看又是不正常的。現在需要了解的是，如此高的路由流量是從哪里（電腦自動關機）來的，以及數據包到達路由器以后的去向等。這樣就可以很快定位導致如此之高的通道流量的數據源和擁塞源。

將網絡流量分析儀接入網絡的路由器通道進行監測和分析，結果顯示95%流量流向了業務數據服務器，且多數為HTTP和Email方面應用。其中，Internet訪問流量占88%，本地流量占7%。查看流量分析儀指示的流量來源分布圖，沒有發現集中的流量應用，IP地址分布比較均衡，最高的流量只占0.5%。這些數據表明，用戶的應用比例均衡，故障原因應該在應用過程中而不是某個集中的用戶“轟擊”比如黑客等。也就是說，應該是應用的過程和通道出了問題。其原因是這些流量按通道設計不應該到達營業廳網絡的業務服務器，而是應該直接從中心網絡的Internet主路由器進入互聯網。那么，這些流量是如何被引導到營業廳服務器方向上來的呢?

下面我們進行進一步的分析，大家知道IP數據包在傳輸過程中會在路由器中作地址解析(ARP)，或是在本地DNS中進行域名分析。如果這些分析路徑出問題，則IP數據包的傳輸和交換就會出問題。根據流量分析儀的指示，筆者任意選擇了10個IP地址做路由追蹤測試，用網絡測試儀追蹤的結果是，他們都要經過一個DNS服務器。而模仿營業廳網絡成員分別對已知的本地和外地用戶做ICMP監測和路由追蹤測試，結果發現ICMP監測中重定向數據包占82%，目標不可達數據包數量占13%。這表明，只有約2%的用戶能一次性出入正常路由到達目標站點，其余95%的IP數據包都要經過路由競爭或重新發送才能有部分機會到達目的地。

由此，可以重點檢查主路由器的路由表和DNS的轉換表。由于多數Internet訪問流量被引導到了營業廳業務服務器，所以可以重點檢查DNS服務器。用網絡測試儀對DNS服務器做查詢，觀察查詢結果，發現DNS轉換表有相當大的比例指向了營業廳子網中的業務服務器。筆者懷疑是DNS服務器出了問題

于是通知中心網絡的網管人員將DNS服務器重新啟動并快速設置一次，稍后網絡管理人員報告網絡業務恢復正常。用網絡測試儀的Internet工具包查詢DNS服務器，可以看到指向營業廳業務服務器的數據已經全部消失，這表明網絡已經完全恢復了正常工作。但好景不長，約3分鐘后，故障重新出現，仍有97%的通道流量被指向了子網。

由于DNS服務器只設置了一臺，沒有備份或備用服務器，于是不得不立即來到中心網絡機房，對DNS服務器及其周圍設備進行檢查。測試服務器網卡和與路由器的電纜正常。為了不中斷服務，筆者讓網管人員在另一臺備用服務器上臨時安裝設置了DNS服務器。經過短暫的業務中斷后，更換上的新DNS服務器開始投入適用。只見子網路由器的流量立刻降低到了1.5%。經過30分鐘的穩定工作后，所有用戶均恢復到正常工作狀態，故障消除。