霍 澤

內(nèi)蒙古廣播電視網(wǎng)絡(luò)集團(tuán)有限公司烏拉特中分公司 內(nèi)蒙古 巴彥淖爾市 015300

1 長發(fā)光ONU故障

1.1 故障情況

新安裝用戶光功率在正常范圍，但是PON 燈閃爍，注冊失敗，OLT 中同時也沒有注冊信息。初步判斷，有長發(fā)光ONU 存在。某小區(qū)編號為：JFHT-01#主分纖箱下掛的新裝用戶張三（化名）ONU 無法正常使用，安裝隊反映，安裝后用戶ONU PON 燈一直在閃爍，光功率為（-20），鏈路經(jīng)過反復(fù)排查也沒有異常。

1.2 故障處理

1.2.1 確定覆蓋設(shè)備

從營業(yè)廳查找到JFHT-01#下掛的其他的已經(jīng)注冊并且在用的ONU，通過這個ONU 的MAC 地址鎖定OLT 設(shè)備，由于中分公司城網(wǎng)只有兩臺OLT，所以排查其他也比較方便，最終，排查到JFHT-01#下的某臺ONU 上聯(lián)PON 口是筆者所在單位 232.162的1號OLT，登錄OLT通過已知 MAC 查找對應(yīng)PON 口。如圖1所示。

圖1

以：00∶0a∶5a∶27∶fe∶79 這臺正常在線的ONU 為例，查找結(jié)果為：設(shè)備2/1/10，設(shè)備2PON板1Pon 口下存在。命令為：config 模式下：show onu mac 00∶0a∶5a∶27∶fe∶79，如圖2所示。

圖2

1.2.2 查看是否有長發(fā)光ONU 存在

例：Config 模式下輸入：

gcom-wulatezhongqi-01 （config）#interface po 3/5 gcom-wulatezhongqi-01 （config-if-pon-3/5）#show opm op laser-always-on。通過不停的刷新設(shè)備信息，會看到這個PON 口下一直有長發(fā)光ONU存在，確定有長發(fā)光ONU 存在。如圖3、圖4所示。

圖3

圖4

1.2.3 確定端口

下往現(xiàn)場，通過斷開分路器纖芯接頭，結(jié)合OLT 設(shè)備刷新查看發(fā)光命令來綜合確定端口。方法有兩種，一種是通過無法上線的ONU 來排查。將用戶端的ONU 鏈接好，ONU PON 燈處于閃爍無法注冊的狀態(tài)，通過拔插PON 口下的第一個分路器到每個單元的光纖，一旦斷開長發(fā)光的某一路，這臺無法注冊的ONU 會馬上注冊上線，從而確定單元分纖箱的位置。用同樣的方法，確定單元分纖箱所帶的ONU 接口，確定故障ONU。

另一種方法是通過OLT 不停的刷新查看長發(fā)光命令來判定。

通過拔插第一個分路器的光纖，查看到這個PON 口下，如果顯示沒有長發(fā)光信息，說明拔插正確，從而確定端口。如圖5所示。

圖5

同樣的方法，查找到單元的分纖箱光纖和到ONU 的光纖。例：斷開3//9/11 這臺ONU 后，長發(fā)光消失，其他ONU 同時可以正常注冊在線。如圖6所示。

圖6

找到這個ONU 將其更換，此PON 口下ONU 恢復(fù)正常。如圖7所示。

圖7

筆者理解的長發(fā)光并不是影響所有ONU 都無法注冊，只是影響比長發(fā)光ONU 接收光功率低的其他ONU 無法注冊。例如:長發(fā)光這臺ONU 的接收光功率為-18，那么這個PON 口下所有低于-18接收的ONU 就會注冊失敗。長發(fā)光故障排查起來有一定的困難，但是一定要按順序逐一排查。

2 PPPoE撥號691故障

2.1 故障情況

用戶端直連電腦撥號一直出現(xiàn)錯誤代碼691，或通過路由器后，路由中設(shè)置好PPPoE 撥號，但提示撥號失敗。（確定賬號密碼無誤），如圖8所示。

圖8

2.2 故障處理

首先，從OLT 中通過查看報障用戶端的MAC查到了PON 板信息和ONU 配置信息，確定沒有問題。如圖9所示。

圖9

然后在用戶端，將PPPoE 改回WEB 動態(tài)獲取方式后可使用，但會不定時的掉線。再通過相關(guān)協(xié)助，登錄BRAS 后發(fā)現(xiàn)，無法查看到故障用戶端ONU 的正常上下線認(rèn)證過程并報錯。接著在機(jī)房OLT 上聯(lián)GE 口抓包，結(jié)合用戶端現(xiàn)場撥號，抓包抓取撥號請求發(fā)送過程。發(fā)現(xiàn)異常交互報文，在與故障用戶同PON 板下，不同PON 口的4/11PON口下，有異常設(shè)備MAC 存在。將異常MAC 做黑洞隔離。

錯誤代碼691 是指radius 驗證用戶名密碼不匹配；導(dǎo)致認(rèn)證失敗。通過鏡像抓包分析，發(fā)現(xiàn)PPPoE 交互報文是用戶端和華為brass me60-x16；但實際上，現(xiàn)場組網(wǎng)內(nèi)沒有華為brass；如圖10、圖11 所示。

圖10

圖11

發(fā)現(xiàn)bras 有異常后；通過查詢?nèi)A為BRAS MAC地址后；在OLT內(nèi)使用黑洞MAC；故障排除。

反復(fù)測試后，確定故障排除，通過營業(yè)廳BOSS 查到異常源ONU 的具體地址，到用戶家后，發(fā)現(xiàn)連接并無異常，下掛設(shè)備也正常，懷疑此ONU 隱藏的流氓MAC，更換ONU 后所有問題全部處理。

3 注冊故障

3.1 故障情況

2016年3月20日，在日常接到故障保修單后，筆者前往報障地點進(jìn)行故障的排查與修復(fù)，使用2500C 場強儀進(jìn)行CM 注冊過程中發(fā)現(xiàn)，CM選擇了上行通道，但一直處于等待DHCP 信息，無法獲取IP,無法正常連接到網(wǎng)絡(luò)時間協(xié)議（NTP）。而隨后，故障自愈。自此，每天都會隨機(jī)發(fā)生此種故障。筆者與技術(shù)人員利用NM3000 網(wǎng)管平臺和SecureCRT 進(jìn)行24 小時不間斷觀察發(fā)現(xiàn)，隨機(jī)CM 出現(xiàn)卡D 狀態(tài)，部分用戶CM 無法上線，半小時內(nèi)自動恢復(fù)。隨后筆者與OLT 廠商取得聯(lián)系，廠商派技術(shù)工程師協(xié)助配合排查故障。

3.2 故障處理

CM 上線有以下過程：offline、init（r2）、init（d）、init（io）、init（dr）、init（i）、online 這幾種，其中init（r2）表示小cm 已經(jīng)鎖定上下行，等待dhcp 過程，dhcp 過程中init（d）是表示CM已經(jīng)發(fā)出discover，但是沒有收到offer，導(dǎo)致CM卡D。如圖12 所示。

重啟了小C，重啟OLT，重啟上聯(lián)交換機(jī)，故障依然未解決。嘗試更換上聯(lián)交換機(jī)端口和OLT上聯(lián)口并更換光模塊后任然出現(xiàn)故障。再更換OLT的主控板，CM還是出現(xiàn)卡D。設(shè)備廠家工程師在故障發(fā)生時，在交換鏡像抓包，發(fā)現(xiàn)交換機(jī)已經(jīng)收到DHCP服務(wù)器回復(fù)的offer。如圖13 所示。

圖12

圖13

廠家在故障時在OLT 上聯(lián)口鏡像抓包發(fā)現(xiàn)，OLT 收到多次卡(d)cm 的 offer，廠家在 OLT 的統(tǒng)計信息中發(fā)現(xiàn)收到的DHCP 的offer 信息是DISCOVER的幾百倍，已經(jīng)相當(dāng)于行DHCP 風(fēng)暴攻擊，OLT 無法處理這么多報文，導(dǎo)致CM 卡D。如圖14、圖15 所示。

圖14

圖15

經(jīng)過分析報文發(fā)現(xiàn)給一個cpe 的offer 報文峰值就到了180pps，最低的時候已經(jīng)80pps 了，這還只是其中一個cpe，320 秒內(nèi)這個TransactionID 的offer報文文件就達(dá)16MB，已經(jīng)超過正常值很多倍。如圖16 所示。

圖16

廠家將整臺OLT 更換后，cm 大量上線時發(fā)生一部分CM 卡D，經(jīng)過十幾分鐘后正常。更換設(shè)備后，廠家技術(shù)人員將DHCP 處理能力提升后故障減少很多，但還是有大量offer 報文。

經(jīng)過以上的工作與排查后得出問題和結(jié)論：設(shè)備經(jīng)過更換后，基本上無問題。故障時的大量offer 是如何產(chǎn)生的，以及怎么產(chǎn)生的。由于現(xiàn)在故障減少，如果再次出現(xiàn)大批量卡D 時需要廠家和區(qū)公司協(xié)助共同排查，確定服務(wù)器是否有問題或是在轉(zhuǎn)發(fā)過程中出現(xiàn)其他問題。