VLAN缺失惹故障

近日，我們接到某專線單位的報修，故障現象是該單位位于某十字路口的終端設備無法采集數據。

故障分析

為了更好地排除故障，我們首先了解一下網絡拓撲結構，如圖1所示。

按照故障現象和網絡拓撲結構，首先根據資料在解放站OLT上查找到該終端設備連接的ONU，使用命令show interface onu 1/4/13 uni ethernet information查看到該ONU下的終端設備連接狀態是正常的。然后再使用命令show interface onu 1/4/13 mac-address-table l2-address uni ethernet 1 dynamic查看到該ONU的端口1能學習到終端設備的MAC地址，即8ce7.48e9.b01b。

圖1 網絡拓撲結構

既然在ONU上能夠學習到終端設備的MAC地址，那么就按照至下而上順藤摸瓜的方法開始排查OLT。使用show命令依然可以在OLT上學習到終端設備的MAC地址，按照圖1的網絡拓撲結構在該專線單位ONU（中心站OLT）的上聯口也可以學習到終端設備的MAC地址。

通過這樣一個流程排查下來似乎沒有問題，既然MAC地址能夠正常學習到，但是數據采集不上來，會不會是終端設備的IP地址丟失或者是該終端設備出現故障呢？帶著這個疑問我們趕到故障現場，使用筆記本連接到ONU上，筆記本電腦的IP地址設置成終端設備的IP地址，然后Ping專線單位的服務器，結果是不通的。問題分析到這里，可以斷定該終端設備沒有問題，問題還應該出在整個傳輸通道上。

回到故障發生的原點，即ONU所屬的解放站OLT上進行故障排查，打算在OLT上設置一個地址直接Ping專線單位服務器和終端設備。在OLT上配置IP地址的具體步驟如下：

在OLT上配置完IP地址后，分別對專線單位服務器10.0.16.153和終端設備進行Ping測試，可以正常Ping通終端設備，但是不能Ping通服務器。既然能在OLT上正常學習到服務器的MAC地址，為什么Ping不通呢？使用命令查看該OLT的ARP表項即，如圖2所示。

通過ARP表項我們可以清晰地看到，在OLT上能學習到服務器的IP地址對應關系，而且對應關系也是正確的，問題分析到這里似乎找不到頭腦了。

故障解決

我們重新梳理一下思路，該終端設備可以在OLT上Ping通，這證明從OLT至終端設備這一段距離是沒有問題的，那么問題應該出在解放站OLT之上。按照這個思路繼續排查城域網解放站傳輸設備CP5566，就在我們使用命令在CP5566上查看連接OLT端口MAC地址表的時候，觀察到兩者互聯使用了鏈路聚合。問題會不會出在鏈路聚合上呢？

在這里給大家簡要介紹一下鏈路聚合的概念。鏈路聚合通過將多個物理以太網端口聚合在一起形成一個邏輯上的聚合組，并把同一聚合組內的多條物理鏈路視為一條邏輯鏈路。鏈路聚合可以實現流量在聚合組各成員端口之間的負載分擔，在有效的提高設備之間鏈路可靠性的同時，還增大了帶寬。

了解完鏈路聚合的相關知識后，我們先查看一下OLT上配置的鏈路聚合配置：

圖2 查看ARP表項

通過上面的配置我們可以看到，在OLT上創建了一個鏈路聚合組1，成員是端口3和4，其中端口3和4的配置應該是一致的，但是仔細觀察后發現，端口4的VLAN比端口3少了一個，缺少的VLAN就是VLAN230，這個會不會是引起網絡故障的原因呢？立即將端口4的配置進行了修正，具體配置即：

在端口4上增加了VLAN230后，在OLT上對專線單位的服務器進行Ping測試，結果是正常的。經過確認，專線單位對終端設備的數據采集也恢復了正常。

經驗總結

上面我們從得知故障現象后，按照自下而上順藤摸瓜的方式逐級排查網絡設備，廣泛使用了show命令，并配合學習到的MAC地址表進行分析，最終將故障根源鎖定到了鏈路聚合的配置上。經過對端口配置的修正，網絡恢復了正常，后期我們了解到，開通此專線業務時，兩臺設備間并沒有配置鏈路聚合，由于為了業務發展的需要，同事在配置鏈路聚合的時候粗心地將其中一個端口漏配置了VLAN230，所以才出現文章開頭的那一幕。

根據這個故障，我們后期查閱了資料，得知在同一個鏈路聚合組中，參與負載分擔的成員端口必須具有一致的配置，否則數據轉發存在問題。而端口4正是違背了這一規則而導致了網絡故障。通過這一故障的排查，作為網絡運維人員，在配置設備時，要時刻提醒自己認真對待每一次設備的調試，細心做好每一步配置，要堅決杜絕配置錯誤事情的發生。