OLT端口更換鬧故障

故障現象

近日，某專線用戶向我們反映多處業務通訊失敗，具體表現是，在專線單位服務器不能實現對客戶端設備的管理。

故障分析

首先梳理一下網絡拓撲結構，具體網絡拓撲結構如圖1所示。

圖1 網絡拓撲結構

通過圖1我們可以看到，該專線采用ONU接入，上聯至數據機房專線OLT，各基站專線業務依托環網設備，最終也匯聚到數據機房專線OLT。整個網絡結構比較簡單，可以簡單理解成是EPON系統組網。知悉了網絡拓撲結構，接下來我們開始排查。

具體的排查步驟是自上而下，采用順藤摸瓜的方式。首先在該專線OLT上使用命令show mac-address-table l2-address vlan 17查看設備全局VLAN17的MAC地址，可以看到很多MAC地址上線，但是仔細觀察發現，這些MAC地址都是該OLT的PON口學習上來的，而上聯中心基站的端口并沒有學習到VLAN17的MAC地址。

既然VLAN17的MAC地址都是從PON口學習到的，那么上聯口是什么情況呢？使用命令show mac-addresstable l2-address port 28，查看上聯端口28學習到MAC地址的情況，結果只能看到VLAN1的MAC地址上來，這是為什么呢？同樣在環網設備連接專線OLT的端口依然學習不到VLAN17的MAC地址，問題分析到這里，進一步排查到兩側設備端口都處于UP狀態，端口VLAN數據均沒有發現問題，那么為什么MAC地址學習不到呢？

我們對兩側設備學習到的VLAN1的MAC地址進行比對，也就是說在專線OLT端口28學習到的MAC地址，應該是環網設備的MAC地址。但是我們并沒有在環網設備上發現該地址，這一發現可以斷定，OLT的28口連接的不是環網設備。發現此問題后，為了驗證端口是否正確，我們關閉了OLT的28口，但是環網設備上連接專線OLT的端口依然UP，這樣就可以斷定是設備間互聯端口出現了問題。

故障解決

得出這一結論后，我們在OLT處發現上聯端口25、27和28口均處于Up狀態，根據端口描述其中端口25上聯BRAS設備，27口連接服務器，28口連接環網設備，但是28口當前是通過網線連接，28口連接環網設備肯定是光口，而這里使用的是電口。由于該OLT上聯口是光電混用的，而連接服務器的27口連接的是光口，這樣我們將27口的尾纖恢復到28口上，然后就可以看到端口28可以正常學習到VLAN17的MAC地址，這樣故障就得到解決。進一步通過專線單位核實，服務器和客戶端設備通信恢復正常。

經驗總結

上面我們得知故障，通過使用一系列show命令查看MAC地址的學習情況，并結合網絡拓撲結構進行MAC地址的比較排查，最終找到故障原因，再將端口光纖恢復后故障解決。雖然故障的出現十分偶然，但原因后面卻深藏著制度上的漏洞。

后期我們通過調查得知是同事整理機柜線纜時，將光纖和網線插拔錯誤從而導致了該故障的發生。借鑒此故障的發生，我們對機房整理線纜制定了規范，認真做好線纜標簽，杜絕此類事件的發生。并制定了相應的網絡設備線纜優化調整制度，涉及到調整前端口和線纜信息的記錄；調整中線纜的規范走向，調整后網絡的比較驗證以及端口核對信息等，通過一系列的舉措，最大程度地保障網絡的高質量穩定運行。