霍 澤

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

1 長(zhǎng)發(fā)光ONU故障

1.1 故障情況

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

1.2 故障處理

1.2.1 確定覆蓋設(shè)備

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

圖1

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

圖2

1.2.2 查看是否有長(zhǎng)發(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。通過(guò)不停的刷新設(shè)備信息，會(huì)看到這個(gè)PON 口下一直有長(zhǎng)發(fā)光ONU存在，確定有長(zhǎng)發(fā)光ONU 存在。如圖3、圖4所示。

圖3

圖4

1.2.3 確定端口

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

另一種方法是通過(guò)OLT 不停的刷新查看長(zhǎng)發(fā)光命令來(lái)判定。

通過(guò)拔插第一個(gè)分路器的光纖，查看到這個(gè)PON 口下，如果顯示沒(méi)有長(zhǎng)發(fā)光信息，說(shuō)明拔插正確，從而確定端口。如圖5所示。

圖5

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

圖6

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

圖7

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

2 PPPoE撥號(hào)691故障

2.1 故障情況

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

圖8

2.2 故障處理

首先，從OLT 中通過(guò)查看報(bào)障用戶(hù)端的MAC查到了PON 板信息和ONU 配置信息，確定沒(méi)有問(wèn)題。如圖9所示。

圖9

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

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

圖10

圖11

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

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

3 注冊(cè)故障

3.1 故障情況

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

3.2 故障處理

CM 上線有以下過(guò)程：offline、init（r2）、init（d）、init（io）、init（dr）、init（i）、online 這幾種，其中init（r2）表示小cm 已經(jīng)鎖定上下行，等待dhcp 過(guò)程，dhcp 過(guò)程中init（d）是表示CM已經(jīng)發(fā)出discover，但是沒(méi)有收到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ā)生時(shí)，在交換鏡像抓包，發(fā)現(xiàn)交換機(jī)已經(jīng)收到DHCP服務(wù)器回復(fù)的offer。如圖13 所示。

圖12

圖13

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

圖14

圖15

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

圖16

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

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