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，這樣就可以斷定是設備間互聯端口出現了問題。……