案例分析：DNS故障引發(fā)子網(wǎng)流量異常
這是筆者最近親歷的一起網(wǎng)絡(luò)故障，故障比較典型，排錯思路比較可取。我把這個過程寫下來和大家分享，希望能夠幫助到你。
1、癥狀描述
客戶來電報告中心主網(wǎng)絡(luò)則基本正常，而一個子網(wǎng)突然變慢。這是本地鐵通網(wǎng)絡(luò)服務公司，該公司為普通用戶提供Web服務和Internet接入服務。前幾天其服務的一個片區(qū)的用戶反映網(wǎng)絡(luò)速度很慢，發(fā)Email也需要等待超過60秒以上的時間才能聯(lián)通。這個片區(qū)被劃分為一個子網(wǎng)，從主機房的網(wǎng)管系統(tǒng)上觀察發(fā)現(xiàn)除了該片區(qū)(子網(wǎng))路由器流量很高以外(測試為97%)，中心網(wǎng)絡(luò)的路由器與其它子網(wǎng)的交互流量均為40%以下。此外，沒有其它特別現(xiàn)象。
2、診斷過程
鐵通的維護人員自行進行了網(wǎng)絡(luò)排錯可惜沒有找到故障所在，由于不能斷開網(wǎng)絡(luò)停止用戶服務來進行檢查，于是求助于我們，本人被派出診。應該說，從癥狀上看這個故障比較簡單，只要查出子網(wǎng)的路由流量來源就可以很快確定故障方向，進一步則立即可以查出流量源。
從網(wǎng)絡(luò)拓撲圖上看，故障子網(wǎng)與中心網(wǎng)絡(luò)為E1鏈路。故障子網(wǎng)下面有一個營業(yè)廳，一般只與中心網(wǎng)絡(luò)交互一些業(yè)務數(shù)據(jù)應該不會有太大的流量。此外，該子網(wǎng)下的Web服務器數(shù)量為45臺，中心的網(wǎng)管系統(tǒng)報告97%的流量肯定是過高的。
筆者考慮只有一種情況可以比較多地占用E1通道的有效流量，那就是故障子網(wǎng)下的網(wǎng)站與中心網(wǎng)絡(luò)的網(wǎng)站或服務器之間有多媒體文檔的傳輸或者下載業(yè)務才會造成這種情況。不過詢問管理人員得知中心網(wǎng)絡(luò)并不提供諸如多媒體視頻的播放和下載服務，那只能借助工具進行檢測了。
由于故障網(wǎng)絡(luò)規(guī)模比較小，中心網(wǎng)絡(luò)的網(wǎng)管系統(tǒng)只支持到路由器一級的管理，交換機和服務器等采用的是廉價的桌面交換機，所以無法支持網(wǎng)絡(luò)管理。將網(wǎng)絡(luò)測試儀接入交換機進行測試，啟動便攜網(wǎng)管功能，可以看到路由器的流量和網(wǎng)管系統(tǒng)觀測的到的流量是相同的，均為97%左右。
查看中心網(wǎng)絡(luò)處與此相連的路由器流量，也是997%左右，這說明路由器通道鏈路性能基本正常。不過這樣高的通道流量必然導致路由器擁塞和丟包，所以從流量的角度看又是不正常的。現(xiàn)在需要了解的是，如此高的路由流量是從哪里來的，以及數(shù)據(jù)包到達路由器以后的去向等。這樣就可以很快定位導致如此之高的通道流量的數(shù)據(jù)源和擁塞源。
將網(wǎng)絡(luò)流量分析儀接入網(wǎng)絡(luò)的路由器通道進行監(jiān)測和分析，結(jié)果顯示95%流量流向了業(yè)務數(shù)據(jù)服務器，且多數(shù)為HTTP和Email方面應用。其中，Internet訪問流量占88%，本地流量占7%。查看流量分析儀指示的流量來源分布圖，沒有發(fā)現(xiàn)集中的流量應用，IP地址分布比較均衡，***的流量只占0.5%。這些數(shù)據(jù)表明，用戶的應用比例均衡，故障原因應該在應用過程中而不是某個集中的用戶“轟擊”比如黑客等。也就是說，應該是應用的過程和通道出了問題。其原因是這些流量按通道設(shè)計不應該到達營業(yè)廳網(wǎng)絡(luò)的業(yè)務服務器，而是應該直接從中心網(wǎng)絡(luò)的Internet主路由器進入互聯(lián)網(wǎng)。那么，這些流量是如何被引導到營業(yè)廳服務器方向上來的呢?
下面我們進行進一步的分析，大家知道IP數(shù)據(jù)包在傳輸過程中會在路由器中作地址解析(ARP)，或是在本地DNS中進行域名分析。如果這些分析路徑出問題，則IP數(shù)據(jù)包的傳輸和交換就會出問題。根據(jù)流量分析儀的指示，筆者任意選擇了10個IP地址做路由追蹤測試，用網(wǎng)絡(luò)測試儀追蹤的結(jié)果是，他們都要經(jīng)過一個DNS服務器。而模仿營業(yè)廳網(wǎng)絡(luò)成員分別對已知的本地和外地用戶做ICMP監(jiān)測和路由追蹤測試，結(jié)果發(fā)現(xiàn)ICMP監(jiān)測中重定向數(shù)據(jù)包占82%，目標不可達數(shù)據(jù)包數(shù)量占13%。這表明，只有約2%的用戶能一次性出入正常路由到達目標站點，其余95%的IP數(shù)據(jù)包都要經(jīng)過路由競爭或重新發(fā)送才能有部分機會到達目的地。
由此，可以重點檢查主路由器的路由表和DNS的轉(zhuǎn)換表。由于多數(shù)Internet訪問流量被引導到了營業(yè)廳業(yè)務服務器，所以可以重點檢查DNS服務器。用網(wǎng)絡(luò)測試儀對DNS服務器做查詢，觀察查詢結(jié)果，發(fā)現(xiàn)DNS轉(zhuǎn)換表有相當大的比例指向了營業(yè)廳子網(wǎng)中的業(yè)務服務器。筆者懷疑是DNS服務器出了問題!
于是通知中心網(wǎng)絡(luò)的網(wǎng)管人員將DNS服務器重新啟動并快速設(shè)置一次，稍后網(wǎng)絡(luò)管理人員報告網(wǎng)絡(luò)業(yè)務恢復正常。用網(wǎng)絡(luò)測試儀的Internet工具包查詢DNS服務器，可以看到指向營業(yè)廳業(yè)務服務器的數(shù)據(jù)已經(jīng)全部消失，這表明網(wǎng)絡(luò)已經(jīng)完全恢復了正常工作。但好景不長，約3分鐘后，故障重新出現(xiàn)，仍有97%的通道流量被指向了子網(wǎng)。
由于DNS服務器只設(shè)置了一臺，沒有備份或備用服務器，于是不得不立即來到中心網(wǎng)絡(luò)機房，對DNS服務器及其周圍設(shè)備進行檢查。測試服務器網(wǎng)卡和與路由器的電纜正常。為了不中斷服務，筆者讓網(wǎng)管人員在另一臺備用服務器上臨時安裝設(shè)置了DNS服務器。經(jīng)過短暫的業(yè)務中斷后，更換上的新DNS服務器開始投入適用。只見子網(wǎng)路由器的流量立刻降低到了1.5%。經(jīng)過30分鐘的穩(wěn)定工作后，所有用戶均恢復到正常工作狀態(tài)，故障消除。#p#
3、故障原因
大家知道，DNS服務器用于將用戶域名轉(zhuǎn)換為IP地址，一般來說不會出現(xiàn)什么問題。但由于某些原因，造成了類似本例的中轉(zhuǎn)換地址統(tǒng)統(tǒng)指向了營業(yè)廳子網(wǎng)的業(yè)務服務器。業(yè)務服務器不具備路由處理功能，對發(fā)送來的IP數(shù)據(jù)包要么拒收并置之不理，要么返回目標不可達或需要重定向的報告數(shù)據(jù)包。這就是我們在ICMP監(jiān)測時經(jīng)常觀察到的現(xiàn)象。
本地鐵通的用戶數(shù)量并不多，而且與上級網(wǎng)絡(luò)的鏈路帶寬為155M的ATM鏈路，大有富余，所以上Internet的用戶其上網(wǎng)速度主要受子網(wǎng)帶寬的影響。因為許多的用戶要經(jīng)過擁擠的無效E1鏈路，造成路由重定向和嚴重的時延。大量的IP數(shù)據(jù)包擁向只有2M帶寬的子網(wǎng)路由器，流量達到了97%，造成子網(wǎng)工作速度突然變慢，路由器出現(xiàn)嚴重擁塞等現(xiàn)象。
4、兩點建議
(1).DNS服務器要定期“體檢”
基為了防止DNS服務不穩(wěn)定造成業(yè)務中斷或出錯，不少網(wǎng)管人員在設(shè)置DNS服務器時都安裝了備用DNS服務器，亦即安裝不只一臺DNS服務器。但這樣做也會帶來一個潛在的危險，即主DNS服務器出問題，備用自動服務器投入運行，這樣會犧牲一定的網(wǎng)絡(luò)帶寬，使得系統(tǒng)總體性能有所下降。危險在于，性能的下降常常是在不知不覺中來到的。所以，為了保證網(wǎng)絡(luò)經(jīng)常處于良好的工作狀態(tài)，網(wǎng)絡(luò)管理人員需要定期檢查DNS服務器的轉(zhuǎn)換表。
本故障中的DNS指向錯誤導致用戶的IP數(shù)據(jù)包對準了子網(wǎng)服務器，但如果對準的不是服務器而是中心網(wǎng)絡(luò)本地網(wǎng)段中的某臺機器，則故障強度會減弱，用戶不會感到非常明顯的速度變慢。這樣可能不會感到明顯的“身體不適”從而使得網(wǎng)絡(luò)長期帶病運行。就象人一樣，定期的體檢對及時發(fā)現(xiàn)疾病及其隱患是非常必要的。而如何及時發(fā)現(xiàn)路由優(yōu)化方面的問題，也是網(wǎng)絡(luò)定期項目測試中的內(nèi)容之一，對大型網(wǎng)絡(luò)則更有必要，必須堅持定期維護和測試。
(2).網(wǎng)絡(luò)狀況的實時監(jiān)控
許多網(wǎng)絡(luò)設(shè)備如路由器、交換機、只能集線器等都支持SNMP網(wǎng)管功能，但為了全面監(jiān)測網(wǎng)絡(luò)通道功能，還需要網(wǎng)絡(luò)設(shè)備支持全面的RMON和RMON2。用這樣的設(shè)備組建起來的網(wǎng)絡(luò)其管理和故障診斷功能是很不錯的。但現(xiàn)實的問題是，這樣的網(wǎng)絡(luò)設(shè)備價格是普通網(wǎng)絡(luò)設(shè)備的6～10倍左右，用戶難以接受。因此，為了隨時監(jiān)測網(wǎng)絡(luò)的服務應用流量及其比例、來源，工作記錄以及必要時進行解包分析，建議用戶在重要的服務器通道或路由通道上安裝監(jiān)測接口。以便必要時可以隨時將流量分析儀、網(wǎng)絡(luò)測試儀接入通道進行監(jiān)測和分析。這樣，本故障的查找時間可以縮短到20分鐘左右。當然，如果資金允許，也可以將流量分析儀長期接入通道對多個重要的網(wǎng)絡(luò)設(shè)備進行全速率透明流量監(jiān)測，這樣可以把故障定位時間縮短到1分鐘以內(nèi)。
這次“出診”總的來說還算順利，其實每次出診就是一次學習和提高的機會。也許上述案例只是個案，你可能不會遇到，但排錯思路還是值得大家借鑒的。另外，***的兩點建議我希望能夠引起大家的重視。
【編輯推薦】
