局域網網絡使用起來很方便，但管理起來卻不是一件容易的事情，單單用戶不同的上網需求，就能讓網絡管理員忙得不亦樂乎，更不用說頻繁出現的各種網絡故障了。這不，上網斷斷續續故障現象十分常見，引起該故障的因素也是復雜、多變，該故障解決起來自然也容易多走彎路;為了幫助各位積累這方面故障的經驗，本文現在就從實戰角度出發，來向各位還原一則由動態ARP檢測功能引發的上網斷斷續續故障的排查過程，希望下面的內容能起到拋磚引玉的作用!

組網環境

某單位大樓局域網規模適中，位于中心機房的核心交換機采用的是H3C品牌的S8500交換機，所有客戶端系統通過超5類網絡線纜連接到分布在六個樓層中的接入交換機上，接入交換機統一采用2組堆疊的H3C品牌S3050交換機，這些交換機全部位于每個樓層的弱電間中，所有接入交換機全部使用千兆多模光纖與局域網核心交換機相連。為了抑制局域網中的網絡風暴現象，網絡管理員特意按照工作部門的不同，將局域網網絡劃分成12個虛擬工作子網，各個虛擬工作子網的網關全部設置在局域網核心交換機上；此外，為了提高網絡管理效率，局域網中還專門架設了一臺DHCP服務器，局域網中的每一臺客戶端系統都采用動態獲取地址方式進行上網，平時局域網中的所有系統都能快速、穩定地上網訪問。

考慮到最近一段時間ARP病毒比較猖獗，為了保證網絡能夠始終運行，網絡管理員在各個接入交換機中分別啟用了防ARP病毒功能。為了配合單位大樓建設視頻傳輸系統的要求，將位于各個樓層中辦公室內的視頻設備劃分到同一個虛擬工作子網中，并調整了各個接入交換機的相關配置，例如統一增加了兩個虛擬工作子網。

故障現象

自從接入交換機被調整過之后，局域網網絡運行一直就不穩定，許多用戶紛紛打來電話反映情況，說他們的客戶端系統托盤區域處經常彈出網絡連接受限的提示信息，這個提示說明客戶端系統普遍存在無法從局域網DHCP服務器那里獲得正確的上網參數。即使有的客戶端系統能夠勉強上網，網絡連接也是斷斷續續，使用ping命令測試線路連通性時，發現網絡傳輸延遲現象非常的嚴重，而且數據丟包率一直很高；由于各個樓層的所有客戶端系統都存在相同的故障現象，筆者下意識以為局域網的核心交換機出現了類似緩存溢出這樣的軟錯誤，于是嘗試著重新啟動了一下核心交換機后臺系統，發現故障現象依然存在。后來，筆者順便重新啟動了一臺普通樓層接入交換機，發現對應交換機下面的客戶端系統在交換機剛剛啟動穩定的那一刻，上網速度稍微有點正常，可是沒有多長時間，相同的故障現象又出現了。

排查故障

既然重新啟動樓層接入交換機，可以暫時讓上網速度恢復正常，那問題看來與樓層接入交換機有關系。為了能夠探清究竟，筆者立即以系統管理員身份登錄進入其中一個樓層的接入交換機后臺系統，使用“dis dia”命令對交換機的各個交換端口進行掃描檢查，看看它們的數據流量狀態是否正常，結果果然發現局域網中有廣播數據包存在，并且該廣播數據包容量在不斷變大，難道是局域網網絡中存在有網絡病毒或網絡環路現象？為了排除這方面因素的干擾，筆者立即進入流量異常的交換端口視圖模式狀態，在該狀態下執行字符串命令“shutdown”，將數據流量不正常的交換端口全部關閉，可是這樣的努力沒有換來任何效果，顯然上網斷斷續續故障與網絡病毒或網絡環路沒有任何關系。

后來，筆者隨意找了一臺客戶端系統，依次單擊“開始”/“運行”命令，在彈出的系統運行對話框中，執行ping命令來測試對應客戶端系統所在虛擬工作子網的網關地址，發現數據丟包率達到了驚人的85%，同時數據傳輸延遲時間平均達到500ms左右;可是，當筆者嘗試從局域網的核心交換機上，使用ping命令測試Internet網絡中的某個站點時，發現這項測試操作一切正常，并且數據丟包率僅僅只有1%左右，顯然局域網與Internet網絡之間的連接是正常的，而問題可能出現在核心交換機與故障客戶端系統之間。

為了能找到具體的故障原因，筆者在局域網的核心交換機后臺系統，使用ping命令測試了其中一臺接入交換機的管理IP地址，測試反饋回來的結果是無法ping通，會不會是核心交換機與樓層接入交換機之間的物理連接存在問題呢?為了排除物理線纜因素，筆者特意找來了專業的光功率計，來測試連接核心交換機與樓層接入交換機的多模光纖線路連通性，結果發現光纖線路具有收發信號，看來問題還是出在樓層接入交換機上。

不得已，筆者只好再次使用Console控制線纜直接連接到樓層接入交換機上，使用“display interface”命令查看該交換機與核心交換機的級聯端口狀態，發現級聯端口的數據流量還是特別大，同時大量的廣播數據包依然存在;為了阻止廣播數據包影響局域網的穩定運行，筆者特意在該接入交換機后臺系統，啟用了廣播風暴抑制功能，然而該功能的啟用并沒有帶來任何改變。之后，筆者隨手執行了“display cpu”字符串命令，查看了故障交換機的系統資源消耗情況，結果讓筆者很是吃驚，該交換機的系統CPU資源消耗率竟然達到了驚人的100%，而正常情況下交換機的系統CPU資源消耗率應該為25%左右，這也難怪筆者無法從局域網的核心交換機上ping通故障樓層接入交換機。將故障樓層接入交換機與局域網核心交換機之間的物理連接斷開之后，筆者再次執行了“display cpu”字符串命令，結果看到該交換機的CPU資源消耗率迅速下降到30%左右;可是重新連接之后，故障樓層接入交換機的CPU資源消耗率很快又回到了100%，這是什么原因呢？

經過仔細分析、對比，筆者認為自從在接入交換機中啟用了防ARP病毒功能后，局域網中才出現了上網不穩定的故障現象，會不會是這項功能在暗中“搗亂”呢？為了驗證自己的猜想是否正確，筆者立即將接入交換機的動態ARP檢測功能給關閉掉，之后又在對應交換機后臺系統，使用“display cpu”命令查看了系統CPU資源消耗情況，果然CPU使用率立即從原先的100%下降到30%左右，對應交換機下面的客戶端系統上網速度也恢復了正常。與此同時，另外幾臺暫時沒有關閉動態ARP檢測功能的接入交換機，其CPU使用率仍然一直居高不下，并且這些交換機下面的客戶端系統上網速度還是斷斷續續，數據丟包現象仍然十分嚴重。很顯然，局域網中的上網斷斷續續故障現象，與動態ARP檢測功能有關。

原因解密

上網搜索了動態ARP檢測功能的工作原理，筆者發現該功能會自動截取來自不信任網絡端口發送過來的ARP數據請求，同時會自動驗證對應數據包的數據綁定行為是否合法，看看它的地址綁定關系與DHCP綁定表中的是否一致，如果一致的話就對ARP數據包進行放行，要是不一致的話就對ARP數據包進行丟棄，這項功能可以有效地預防中間人攻擊，也能防止局域網用戶自行修改網卡物理地址和IP地址，避免局域網中發生地址沖突現象。經過進一步了解，筆者發現該功能往往與DHCP嗅探功能配合使用，并且該功能還存在一個明顯的缺陷，那就是對ARP數據包的動態檢測操作，需要不停消耗交換機系統的CPU資源，如果處理的ARP數據包流量特別大的話，那么交換機系統的CPU資源消耗率就會很高，嚴重時就能出現CPU資源被100%消耗的現象。

而DHCP嗅探功能在工作的時候，DHCP服務器會將分配出去的動態IP地址，以及客戶端系統的網卡物理地址之間的對應關系，自動記錄保存到一個地址綁定表中，任何客戶端系統進行網絡連接的時候，該功能會自動檢查數據包的IP地址與網卡物理地址之間的對應關系，看看這種對應關系與地址綁定表中的記錄是否一致，如果一致的話就允許目標數據包通過，否則將不允許數據包通過，這種功能可以有效地防止局域網其他不合法DHCP服務器的功能。

當一臺交換機系統同時啟用了動態ARP檢測功能和DHCP嗅探功能的時候，既能有效防范非法DHCP服務器的干擾，又能禁止上網用戶隨意改動客戶端系統的上網地址以及網卡物理地址來偷偷上網，如此一來就能實現安全、穩定相互兼顧的效果；但讓筆者感到非常納悶的是，這里的樓層交換機也是同時啟用了這兩項功能，為什么它們沒有發揮應有的作用呢，反而只有關閉了動態ARP檢測功能，才能解決上網斷斷續續故障現象呢？經過與集成商的溝通、交流，筆者終于找到了問題的答案，原來當交換機系統同時啟用了上面兩項功能，如果每一臺交換機上都劃分有相同的虛擬工作子網時，那么廣播數據包就會在接入交換機之間不停地被發送或轉發，如此一來就會大量消耗交換機系統的CPU資源，最終會引發上網斷斷續續的故障現象。

故障解決

找到故障原因之后，筆者立即重新調整了各個樓層的接入交換機配置參數，去掉連接視頻傳輸系統的VLAN，并新增加了一臺新交換機，讓所有使用視頻傳輸系統的客戶端系統單獨使用新的交換機進行上網，如此一來既能保證原來系統的上網穩定，又能方便管理新的視頻傳輸系統。

總結該故障的排除過程，筆者發現該故障的發生純屬巧合，如果不在樓層的接入交換機中同時增加相同的VLAN，或者這些樓層的接入交換機沒有同時啟用動態ARP檢測功能和DHCP嗅探功能的話，那么這種網絡掉線的故障就不會發生。而以往我們在解決網絡掉線問題的時候，經常使用的方法就是先觀察交換機設備的信號燈狀態是否正常，如果不正常的話再嘗試重新啟動一下交換機后臺系統，相信多數網絡故障就能被自動解決了。沒有想到，這次故障的解決費了這么大麻煩！