找出潛伏的DHCP服務

單位局域網的拓撲結構十分簡單，由多臺交換機組成一個簡單樹型結構（如圖 1）。

由于近期業務調整，一臺接入交換機上部分計算機需要訪問較大的遠程共享數據文件，為了解決數據訪問過程中的網絡瓶頸問題，決定將原有的百兆交換機換成千兆交換機，并直接接到核心交換機上，這樣既提高了計算機的接入速率，也減少了與其他接入交換機的競爭沖突。

故障現象

用于替換的是一臺新購的華為S5700系列三層網交換機，替換原來的設備接入到核心交換機對應VLAN中。測試各項業務，共享文件訪問速率明顯得到改善。可是，不久之后有用戶反映，接入計算機提示網絡斷開，業務中斷一兩分鐘后才恢復正常。此后，這一狀況每間隔一段時間就會重復出現，無論是維護人員還是最終用戶對此都是困惑不已。

圖1 局域網拓撲結構

圖2 交換機提示信息

故障排查

由于此次調整只涉及到這一臺交換機，那么故障引發原因肯定與這次更換行為有關。難道是新購交換機的質量有問題？該型號的交換機此次共采購了兩臺，替換另一臺交換機后發現故障現象依舊。以華為網絡產品的質量，兩臺全新交換機同時存在故障問題的可能性幾乎為零，那么硬件故障的可能性基本可以被排除掉。筆者還檢查了電源負載并用萬用表測了交換機接地電阻，基本排除了可能導致交換機重啟的外部因素 。

接下來就是對交換機的參數配置進行檢查，通過Console口登錄交換機上，確認都是默認的出廠配置。不過此時卻發現了一些問題，交換機上不斷提示如圖2所示的信息。

經過仔細閱讀發現，提示信息分為兩類，一類標記為“DATASYNC _CFGCHANGE”，提示配置發生改變，另一類標 記 為“LINK_STATE”，提示Vlanif1的狀態不斷的在“UP”和“DOWN”之間 變化。華為三層交換機出廠默認所有端口都是屬于虛擬接口Vlanif1的，由于此次更換的交換機是直接接到現有業務VLAN中，當作二層交換機來使用的，按理說Vlanif1的地址配置與否對網絡的連通性影響不大。查看端口狀態發現該端口通過DHCP獲取到了一個IP地址為“192.168.1.150”（如圖 3）。

將一臺計算機配置為通過DHCP獲取IP地址，果然也得到了同一網段的地址。由于網絡規模不大，局域網內根本沒有架設DHCP服務器，是哪里提供的DHCP服務呢？計算機在通過Ping工具測到交換機Vlanif1口的網絡狀況時，發現狀態時斷時續，十分不穩定。每次中斷時，Console口都會打印出一條標記為“LINK_STATE”的Vlanif1端口狀態變化，隨后就會記錄一條標記“DATASYNC _CFGCHANGE”的消息。

會不會是DHCP獲取的IP地址不斷跳變，導致Vlanif1的端口不斷變化呢？于是嘗試為Vlanif1口指定一個固定IP地址，果然Console口上不再提示Vlanif1端口的變化信息了。至此，已經找到了導致引發交換機不斷重啟的原因，就是這個狀態不穩定的DHCP服務。

圖3 Vlanif1端口狀態

圖4 DHCP ACK數據包

華為三層交換機默認所有端口都是屬于Vlanif1，默認配置Vlanif1采用dhcpalloc方式獲取IP地址。由于網絡中不知道哪里來的一個DHCP服務，導致交換機狀態不斷變化，當記錄積累一定數量時，就引起交換機的重啟，這就是交換機不定期重啟的真相。

徹底解決問題根源

接下來的工作就是找到這個DHCP服務，徹底清除故障根源。所有自動獲取的地址都是從IP地址為192.168.1.100的DHCP服務器中獲取的，可是通過Ping工具無法測試到這個DHCP服務的提供者，ARP列表中也找不到該IP地址的MAC條目，接下來的工作就要借助網絡協議分析工具來完成了。DHCP是采用UDP數據包進行消息廣播，基本思路是采用抓包工作捕捉來自192.168.1.100的UDP數據包，通過分析MAC地址，再到交換機上逐一查找端MAC地址表，最終捕捉到這個DHCP服務的所在位置。圖4為使用Wireshark抓到的來自192.168.1.100的DHCP ACK數據包。當DHCP客戶端向全網發送分配IP地址請求后，DHCP服務器向全網廣播對于該請求的響應。

所以，該數據報的源地址為DHCP服務器的IP地址，目的地址為廣播地址。而對于鏈路層的以太網數據幀來說，目的端MAC地址為“ff:ff:ff:ff:ff:ff”,源 端 MAC為“00:19:5b:db:3c:22”，有了這個地址就可以追蹤到DHCP服務的提供者了。不過這里我們看到了一條可以減少排查工作量的信息，在源地址中標記了“D-Link db”的描述信息。說明這臺DHCP提供者是一臺品牌為D-Link的設備。有了這一線索，就不用通過交換機的地址交換表去順藤摸瓜了。

經過排查，目標很快就被鎖定一臺D-Link路由器，它被當作交換機來擴展網絡接口數量使用。由于該路由器自帶的DHCP功能沒有關閉，導致其成為不穩定的DHCP服務提供者。接下來的工作就是關閉其DHCP服務，至此，故障的誘發原因已經被徹底排除。

經驗總結

造成網絡設備故障的原因多種多樣，可能是內部原因也可能是外部因素。所以在故障排查過程中，需要廣泛收集盡可能多的信息，綜合分析才能準確地定位故障。作為網絡管理者不僅僅要熟悉網絡知識，也要掌握常用的網絡分析工具，這樣可以極大地減少故障排查的工作量。網絡管理者應該盡可能詳細地掌握網絡中提供服務的種類和狀態，才能最快時間定位故障、排除故障。