找出潛伏的DHCP服務(wù)

單位局域網(wǎng)的拓?fù)浣Y(jié)構(gòu)十分簡(jiǎn)單，由多臺(tái)交換機(jī)組成一個(gè)簡(jiǎn)單樹(shù)型結(jié)構(gòu)（如圖 1）。

由于近期業(yè)務(wù)調(diào)整，一臺(tái)接入交換機(jī)上部分計(jì)算機(jī)需要訪問(wèn)較大的遠(yuǎn)程共享數(shù)據(jù)文件，為了解決數(shù)據(jù)訪問(wèn)過(guò)程中的網(wǎng)絡(luò)瓶頸問(wèn)題，決定將原有的百兆交換機(jī)換成千兆交換機(jī)，并直接接到核心交換機(jī)上，這樣既提高了計(jì)算機(jī)的接入速率，也減少了與其他接入交換機(jī)的競(jìng)爭(zhēng)沖突。

故障現(xiàn)象

用于替換的是一臺(tái)新購(gòu)的華為S5700系列三層網(wǎng)交換機(jī)，替換原來(lái)的設(shè)備接入到核心交換機(jī)對(duì)應(yīng)VLAN中。測(cè)試各項(xiàng)業(yè)務(wù)，共享文件訪問(wèn)速率明顯得到改善?？墒?，不久之后有用戶反映，接入計(jì)算機(jī)提示網(wǎng)絡(luò)斷開(kāi)，業(yè)務(wù)中斷一兩分鐘后才恢復(fù)正常。此后，這一狀況每間隔一段時(shí)間就會(huì)重復(fù)出現(xiàn)，無(wú)論是維護(hù)人員還是最終用戶對(duì)此都是困惑不已。

圖1 局域網(wǎng)拓?fù)浣Y(jié)構(gòu)

圖2 交換機(jī)提示信息

故障排查

由于此次調(diào)整只涉及到這一臺(tái)交換機(jī)，那么故障引發(fā)原因肯定與這次更換行為有關(guān)。難道是新購(gòu)交換機(jī)的質(zhì)量有問(wèn)題？該型號(hào)的交換機(jī)此次共采購(gòu)了兩臺(tái)，替換另一臺(tái)交換機(jī)后發(fā)現(xiàn)故障現(xiàn)象依舊。以華為網(wǎng)絡(luò)產(chǎn)品的質(zhì)量，兩臺(tái)全新交換機(jī)同時(shí)存在故障問(wèn)題的可能性幾乎為零，那么硬件故障的可能性基本可以被排除掉。筆者還檢查了電源負(fù)載并用萬(wàn)用表測(cè)了交換機(jī)接地電阻，基本排除了可能導(dǎo)致交換機(jī)重啟的外部因素 。

接下來(lái)就是對(duì)交換機(jī)的參數(shù)配置進(jìn)行檢查，通過(guò)Console口登錄交換機(jī)上，確認(rèn)都是默認(rèn)的出廠配置。不過(guò)此時(shí)卻發(fā)現(xiàn)了一些問(wèn)題，交換機(jī)上不斷提示如圖2所示的信息。

經(jīng)過(guò)仔細(xì)閱讀發(fā)現(xiàn)，提示信息分為兩類，一類標(biāo)記為“DATASYNC _CFGCHANGE”，提示配置發(fā)生改變，另一類標(biāo) 記 為“LINK_STATE”，提示Vlanif1的狀態(tài)不斷的在“UP”和“DOWN”之間 變化。華為三層交換機(jī)出廠默認(rèn)所有端口都是屬于虛擬接口Vlanif1的，由于此次更換的交換機(jī)是直接接到現(xiàn)有業(yè)務(wù)VLAN中，當(dāng)作二層交換機(jī)來(lái)使用的，按理說(shuō)Vlanif1的地址配置與否對(duì)網(wǎng)絡(luò)的連通性影響不大。查看端口狀態(tài)發(fā)現(xiàn)該端口通過(guò)DHCP獲取到了一個(gè)IP地址為“192.168.1.150”（如圖 3）。

將一臺(tái)計(jì)算機(jī)配置為通過(guò)DHCP獲取IP地址，果然也得到了同一網(wǎng)段的地址。由于網(wǎng)絡(luò)規(guī)模不大，局域網(wǎng)內(nèi)根本沒(méi)有架設(shè)DHCP服務(wù)器，是哪里提供的DHCP服務(wù)呢？計(jì)算機(jī)在通過(guò)Ping工具測(cè)到交換機(jī)Vlanif1口的網(wǎng)絡(luò)狀況時(shí)，發(fā)現(xiàn)狀態(tài)時(shí)斷時(shí)續(xù)，十分不穩(wěn)定。每次中斷時(shí)，Console口都會(huì)打印出一條標(biāo)記為“LINK_STATE”的Vlanif1端口狀態(tài)變化，隨后就會(huì)記錄一條標(biāo)記“DATASYNC _CFGCHANGE”的消息。

會(huì)不會(huì)是DHCP獲取的IP地址不斷跳變，導(dǎo)致Vlanif1的端口不斷變化呢？于是嘗試為Vlanif1口指定一個(gè)固定IP地址，果然Console口上不再提示Vlanif1端口的變化信息了。至此，已經(jīng)找到了導(dǎo)致引發(fā)交換機(jī)不斷重啟的原因，就是這個(gè)狀態(tài)不穩(wěn)定的DHCP服務(wù)。

圖3 Vlanif1端口狀態(tài)

圖4 DHCP ACK數(shù)據(jù)包

華為三層交換機(jī)默認(rèn)所有端口都是屬于Vlanif1，默認(rèn)配置Vlanif1采用dhcpalloc方式獲取IP地址。由于網(wǎng)絡(luò)中不知道哪里來(lái)的一個(gè)DHCP服務(wù)，導(dǎo)致交換機(jī)狀態(tài)不斷變化，當(dāng)記錄積累一定數(shù)量時(shí)，就引起交換機(jī)的重啟，這就是交換機(jī)不定期重啟的真相。

徹底解決問(wèn)題根源

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

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

經(jīng)過(guò)排查，目標(biāo)很快就被鎖定一臺(tái)D-Link路由器，它被當(dāng)作交換機(jī)來(lái)擴(kuò)展網(wǎng)絡(luò)接口數(shù)量使用。由于該路由器自帶的DHCP功能沒(méi)有關(guān)閉，導(dǎo)致其成為不穩(wěn)定的DHCP服務(wù)提供者。接下來(lái)的工作就是關(guān)閉其DHCP服務(wù)，至此，故障的誘發(fā)原因已經(jīng)被徹底排除。

經(jīng)驗(yàn)總結(jié)

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