精確定位“軟故障”源頭

引言：在網絡管理工作中，經常遇上一些莫名其妙的“軟故障”，這些故障并非由于硬件所引起， 而是由于病毒、木馬、用戶誤操作所導致，這類故障通常需要結合多類數據分析來定位其源頭進行解決。本文介紹了一個由于用戶誤操作所導致的網絡故障以及解決辦法，希望給各位同行解決此類問題帶來啟發。

突發性的網絡故障往往令網絡管理人員措手不及，需要在最短的時間內解決故障，恢復業務運轉，這也是網絡管理人員的價值所在。以往的網絡故障很多都是由于硬件故障引起的，因此找到故障設備進行更換即可，我們稱之為“硬故障”。這種故障解決相對簡單，通過對各類網絡設備的狀態監控即可進行故障定位。

隨著硬件工藝水平的提高及容災技術的發展，發生“硬故障”的概率越來越低。但是由于病毒、木馬、ARP攻擊、用戶誤操作等一系列原因導致的網絡故障比例大幅增加，我們稱之為“軟故障”。解決軟故障比解決硬故障更加困難，如果沒有豐富的網絡維護經驗，僅憑網絡設備狀態監控系統，是很難定位軟故障源頭的。如果定位不了故障源頭，一方面難以解決故障，另一方面也無法向上級領導提供準確的故障報告及相關建議，難以徹底杜絕此類網絡故障的發生。所以，解決軟故障的能力很大程度上反映了網絡管理人員的水平。

筆者所在單位不久前發生過一起網絡故障，這次故障牽涉范圍很廣，對業務的影響也比較大。但是，筆者最終在較短時間內找到了故障源頭，及時解決了問題。同時，也提交了詳細的故障報。下面將對該起網絡故障進行詳細介紹。

背景及故障現象

筆者所在單位是在CBD大樓辦公，各個業務及職能部門分布在不同的樓層，中心機房設置在5樓，每個樓層會有一個網絡設備間用于放置接入交換機及相關配線架，然后通過綜合布線工程將各個樓層辦公室的辦公電腦接入網絡。每層網絡設備間的接入交換機與匯聚交換機通過光纖互聯，匯聚交換機與核心交換機也通過光纖互聯，這是一個典型的“核心-匯聚-接入”的三層網絡架構。局域網內服務器IP通過靜態方式分配，用戶電腦的IP則是由一臺Windows Server 2003 DHCP服務器自動分配。每個樓層都是一個獨立的網段，通過VLAN技術進行劃分，交換機品牌全部為思科。

某工作日上午8:10左右，還沒有到上班時間，筆者接到用戶反映：6樓業務部門兩臺電腦無法上網。由于其他樓層的用戶上網均無異常，當時筆者以為是病毒或者電腦自身問題所導致，就聯系了維護電腦終端的同事前去處理。10分鐘后，同事打來電話，說故障現象很奇怪，那兩臺故障電腦都進行了重啟，一臺恢復正常，另一臺還是不能上網，而且后續開機的電腦，也是一部分正常，另一部分不能上網。由于馬上就要到8:30上班時間，如果拖延時間太長，恐怕會影響業務，引起用戶不滿。

筆者立即親自趕赴現場，在排除了硬件、病毒及網絡后臺相關的問題之后，發現故障主機通過DHCP獲得的IP都是192.168.1.0/24網段的地址，但是單位DHCP服務器統一分配的IP均是172.19.0.0/16網段的地址，而且分配的網關、DNS等其他參數也都不正確。如果為故障主機靜態指定一個正常IP，則該主機的網絡通信恢復正常。但是故障主機數量太多，不可能挨個手動指定IP。而且，故障源頭沒有找到，后續肯定還會出現問題，所以必須盡快找到故障源頭并加以解決。

故障分析

故障現象初步分析，用戶無法上網的原因就是DHCP分配地址錯誤，但是之前已經排查過單位的DHCP服務器，證明其運行正常。考慮到故障僅僅發生在6樓業務部門這一個網段，這只能有一個解釋，就是該網段內出現了另外一臺DHCP服務器。用戶主機在發出DHCP廣播請求時，兩臺DHCP服務器均會收到請求包并給出響應，然后將相應的DHCP配置下發給對應的主機，這時就會發生沖突，哪個響應包先到達主機，主機就會“采納”哪臺DHCP服務器下發的配置，就會出現上述同一網段IP地址不一致的現象。

如果主機獲得的不是單位DHCP服務器下發的配置，那么肯定無法上網。由于單位最近并無訪客接入內網，所以能夠排除惡意攻擊的可能，最有可能就是用戶無意的誤操作所導致的。只有找出這臺沖突的DHCP服務器，才能徹底解決問題。

看著故障主機DHCP分配的192.168.1.0/24網段的IP，筆者突然想起前期給各部門部署過一些TPLink無線路由器，這些無線路由器內部分配的IP就是192.168.1.0/24這個網段，但是當初部署時，從樓層交換機出來的主線接入的都是無線路由器的WAN口，這兩個網段應該邏輯上已完全隔離，即使無線路由器上啟用DHCP服務，也不會影響到172.19.0.0/16網段的主機。除非有人將WAN口的主線接到LAN口上，并且沒有關閉無線路由器自帶的DHCP服務，這種情況下，無線路由器也會為局域網內其他主機提供DHCP服務，造成主機DHCP配置混亂，無法正常上網。

故障解決

通過分析得出故障的原因后，下一步就必須找到“惹事”的無線路由器。由于6樓業務部門部署無線路由器范圍大，且數量較多，每個設備的物理位置也不能確定，挨個排查不現實，只能通過后臺數據來進行分析， 最終定位目標無線路由器。筆者所采用的步驟如下。

1.分析單位DHCP服務器IP分配數據，定位該無線路由器所接入的交換機端口。如果主線接入了無線路由器的LAN口，并且接入該無線路由器的終端是從單位DHCP服務器獲取的IP，那么主線對應的交換機端口很可能對應多臺無線終端，只要找到端口和終端數是“一對多”的關系，那么該交換機端口接入的很可能就是目標無線路由器。由于單位的DHCP服務器上都記錄了當前的終端接入信息，可以通過主機名稱來區別是否為手機終端（如圖 1）。

從圖1可以看出，主機名中含有“android”字符的記錄應該為android手機終端，這種命名方式是android系統所特有的。下面再通過交換機上的ARP表和MAC地址轉發表來確定這幾個手機終端是否都接入同一個交換機端口。由于DHCP服務器上已經記錄了手機終端的MAC地址，所以可以通過“show macaddress address XXXX.XXXX.XXXX” 和“show cdp neighbor”命令最終獲取手機終端的接入端口，結果如下圖2和圖3所示。

從上圖2和圖3可知，這兩個手機終端均接入了同一臺交換機的Gi0/25口，可以確定從該交換機Gi0/25口接入的是目標無線路由器。

圖1 手機終端DHCP記錄

圖2 接入端口示意圖1

圖3 接入端口示意圖2

2.定位該無線路由器的物理位置。通過步驟（1）找到目標無線路由器所接入的端口后，我們就可以著手進行處理。為了盡快恢復局域網的正常并找到目標無線路由器的物理位置，筆者在交換機對應端口上使用了“shutdown”命令，將該端口關閉，然后通知故障用戶重新啟動電腦，果不其然，所有主機立即恢復正常。

過了幾分鐘后，客服人員打來電話，說6樓某業務科室反映手機連接無線路由器無法上網，經過現場檢查，該科室內無線路由器主線果然是接在LAN口上，經核實，系昨天一位同事將筆記本帶來公司，但是該筆記本無線網卡是壞的，只能通過有線網絡上網，于是順手將無線路由器上的WAN口主線拔下來臨時接在筆記本上使用，用完后就隨意插到了LAN口上，由于無線路由器的DHCP功能并沒有關閉，結果就導致了今天的網絡故障。

至此，此次網絡故障的源頭已經找到。筆者將主線接回WAN口，并將交換機端口重新開啟，經過測試，網絡恢復正常。

故障總結

這次網絡故障屬于典型的由于用戶誤操作而引發的“軟故障”。由于故障源頭在較短時間內找到，沒有嚴重影響業務，在提交了故障說明后，領導并沒有追責。但是從這次故障可以看出，一個合格的網絡管理人員必須能在較短時間內以清晰的思路去追溯故障源頭，特別是能夠充分利用網絡后臺相關數據進行深度關聯分析，進而解決問題。

隨著虛擬化、云計算、無線網絡等先進技術在企業內的推廣使用，傳統網絡架構已經發生了深度變革，這種變化將會引發更多“不可思議”的網絡問題，網絡管理人員必須要有充足的準備去迎接挑戰。