故障處理巧用debug

泗水縣廣播電視臺 張紅 山東廣電網絡有限公司濟寧分公司 何鈺

故障的現象總是千變萬化，令網絡運維人員防不勝防。在日常的網絡運維過程中除了要保障網絡的安全穩定，還要具有隨機應變的能力。

近日筆者單位DHCP 出現故障，通過查看設備配置和MAC 地址學習，均沒有發現問題，最后通過debug 查看DHCP 的過程，將故障定位在接入層OLT 設備上，最終完成了網絡故障的解決。

故障描述及排查

近日接到運維人員報修，某點播用戶獲取IP 地址出現故障。得知故障現象后，我們立即開始排查，排查思路是按照故障的區域進行劃分的。比如只有個別用戶故障，排查故障的重點要靠近接入層；如果一部分用戶出現故障，那就要把排查重點放在匯聚層設備；如果是大面積故障，那就要排查核心層設備諸如BRAS 或核心路由器。

此次故障的報修范圍很小，是個別用戶，那么按照上述思路首先排查接入層，無外乎物理鏈路、設備狀態、ONU 的配置等。將物理層排查后，再按照順藤摸瓜自下而上排查，那就是匯聚層。接入層ONU 上聯是OLT，在OLT 上主要查看的是PON 口和上聯口的配置。然后使用MAC 地址學習的命令“show mac-address l2-switch”，查看到故障設備的MAC 地址可以從PON 口上學習到，而且OLT 的上聯口也可以學習到故障設備所在VLAN 的MAC地址。這樣既然該VLAN 在PON 口和上聯口都可以學習到MAC 地址，說明網絡通訊是正常的。那么為什么點播用戶獲取不到IP 地址呢？

這時故障的排查陷入了僵局，不知道該如何繼續排查下去。重新梳理下故障的現象進行嘗試。

所謂的嘗試還是按照網絡結構，先從接入層開始，嘗試更換點播終端設備、ONU 設備，然后再進一步往上排查。所有的嘗試都無效后，接下來就需要排查OLT 上游設備BRAS 了。

這時讀者或許會說，不是就個別用戶有故障嗎？怎么還排查起核心設備了呢？這里需要說明的是DHCP 的地址池就在BRAS 上，也就說點播終端設備的IP 地址是BRAS 給分配的。那么我們可以在BRAS 上查看下點播終端和BRAS 交互DHCP 報文的過程。

接下來就可根據報文交互的過程看下故障到底出在什么地方。那么如何在BRAS上查看點播終端設備和BRAS交互DHCP 報文的過程呢？

這里需要使用到debug命令。Debug 即調試命令，在日常網絡維護中使用該命令可以有效的幫助我們診斷和定位和排除在使用網絡設備的各種問題。

在使用該命令前，需要開啟路由器對終端界面的日志記錄功能。具體配置命令即：

完成日志記錄功能的開啟后，接下來通過點播終端設備的MAC 地址對其DHCP報文進行調試排查，具體的配置命令即：

通過在BRAS 上執行上述debug 命令，可以得到以下報文即：

通過使用debug 命令得到的DHCP 通訊的報文，我們可以清晰地看到DHCP 通訊的前兩步。也就是說DHCP通訊的過程從第2 步就中斷了，即DHCP 服務器已經提供給客戶端IP 地址、子網掩碼、網關、DNS 和租約等其他內容，但是DHCP 客戶端沒有發起DHCP REQUEST 廣播消息來響應服務器端。這就說明BRAS 作為服務器端已經將地址和租約信息提供給客戶端，但是客戶端沒有回應，這樣就可以將問題定位在BRAS以下。

那么接下來就排查BRAS以下的問題，BRAS 以下有OLT 和ONU 設備，這就需要在OLT 上進行現場抓包，通過使用抓包工具發現OLT 上故障點播設備所在PON 口有大量廣播包，當然也可以使用show 命令查看。對廣播包的處理，可以找到發送廣播包的源，還可以使用廣播包抑制功能來解決。既然找到故障原因，通過對廣播包源MAC 地址的排查，很容易找到非法的廣播包發送源設備，將其關閉或者處理后故障恢復。

故障解決

上面我們從知悉故障，首先按照網絡層次進行排查，然后再使用debug 命令查看DHCP 通訊的過程，將故障點進一步鎖定在OLT 上，在OLT上揪出了罪魁禍首——非法廣播包，最后將故障得到了解決。

正是網絡中存在大量廣播包，導致正常DHCP 通訊中斷或不正常，才會出現文章開頭的那一幕，點播終端設備獲取不到IP 地址。通過該故障的排查，一個貌似很平常的故障，使用了許多處理手段才得以解決，所以說，每一次故障的處理都是一次經驗的積累，一次和設備增加熟知度的親密接觸。