案例分析：DNS故障引發子網流量異常
這是筆者最近親歷的一起網絡故障，故障比較典型，排錯思路比較可取。我把這個過程寫下來和大家分享，希望能夠幫助到你。
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分鐘的穩定工作后，所有用戶均恢復到正常工作狀態，故障消除。#p#
3、故障原因
大家知道，DNS服務器用于將用戶域名轉換為IP地址，一般來說不會出現什么問題。但由于某些原因，造成了類似本例的中轉換地址統統指向了營業廳子網的業務服務器。業務服務器不具備路由處理功能，對發送來的IP數據包要么拒收并置之不理，要么返回目標不可達或需要重定向的報告數據包。這就是我們在ICMP監測時經常觀察到的現象。
本地鐵通的用戶數量并不多，而且與上級網絡的鏈路帶寬為155M的ATM鏈路，大有富余，所以上Internet的用戶其上網速度主要受子網帶寬的影響。因為許多的用戶要經過擁擠的無效E1鏈路，造成路由重定向和嚴重的時延。大量的IP數據包擁向只有2M帶寬的子網路由器，流量達到了97%，造成子網工作速度突然變慢，路由器出現嚴重擁塞等現象。
4、兩點建議
(1).DNS服務器要定期“體檢”
基為了防止DNS服務不穩定造成業務中斷或出錯，不少網管人員在設置DNS服務器時都安裝了備用DNS服務器，亦即安裝不只一臺DNS服務器。但這樣做也會帶來一個潛在的危險，即主DNS服務器出問題，備用自動服務器投入運行，這樣會犧牲一定的網絡帶寬，使得系統總體性能有所下降。危險在于，性能的下降常常是在不知不覺中來到的。所以，為了保證網絡經常處于良好的工作狀態，網絡管理人員需要定期檢查DNS服務器的轉換表。
本故障中的DNS指向錯誤導致用戶的IP數據包對準了子網服務器，但如果對準的不是服務器而是中心網絡本地網段中的某臺機器，則故障強度會減弱，用戶不會感到非常明顯的速度變慢。這樣可能不會感到明顯的“身體不適”從而使得網絡長期帶病運行。就象人一樣，定期的體檢對及時發現疾病及其隱患是非常必要的。而如何及時發現路由優化方面的問題，也是網絡定期項目測試中的內容之一，對大型網絡則更有必要，必須堅持定期維護和測試。
(2).網絡狀況的實時監控
許多網絡設備如路由器、交換機、只能集線器等都支持SNMP網管功能，但為了全面監測網絡通道功能，還需要網絡設備支持全面的RMON和RMON2。用這樣的設備組建起來的網絡其管理和故障診斷功能是很不錯的。但現實的問題是，這樣的網絡設備價格是普通網絡設備的6～10倍左右，用戶難以接受。因此，為了隨時監測網絡的服務應用流量及其比例、來源，工作記錄以及必要時進行解包分析，建議用戶在重要的服務器通道或路由通道上安裝監測接口。以便必要時可以隨時將流量分析儀、網絡測試儀接入通道進行監測和分析。這樣，本故障的查找時間可以縮短到20分鐘左右。當然，如果資金允許，也可以將流量分析儀長期接入通道對多個重要的網絡設備進行全速率透明流量監測，這樣可以把故障定位時間縮短到1分鐘以內。
這次“出診”總的來說還算順利，其實每次出診就是一次學習和提高的機會。也許上述案例只是個案，你可能不會遇到，但排錯思路還是值得大家借鑒的。另外，***的兩點建議我希望能夠引起大家的重視。
【編輯推薦】
