波分常見故障201208

常見故障1、 OTU10G/2可調(diào)諧單板在網(wǎng)管E3003.16R2下，無法顯示波長調(diào)諧菜單故障現(xiàn)象描述：某工程中發(fā)貨的OTU10G/2可調(diào)諧單板，在網(wǎng)管中無法顯示調(diào)諧菜單?，F(xiàn)場使用的網(wǎng)管版本是E3003.16R2；單板上報后，點擊插拔，單板能正常安裝上，但是屬性中沒有可調(diào)諧一項；強制在網(wǎng)管上應安裝單板中插入可調(diào)諧單板，單板報板不匹配告警；分析單板上報后，點擊插拔，單板能正常安裝上，但是屬性中沒有可調(diào)諧一項。經(jīng)咨詢3.16R2單板示支持OTU10G/2的可調(diào)諧功能的。排除網(wǎng)管問題強制在網(wǎng)管上應安裝板中插入可調(diào)諧單板，單板上報不匹配。說明單板的重要數(shù)據(jù)中的有和應安單板的屬性中有不匹配的情況。可以通過對比看哪些屬性不一致引起，通過這種方法通?？梢蚤_闊思路。我們將重點放在了重要數(shù)據(jù)上面。故障處理：經(jīng)過分析發(fā)現(xiàn)，E300V3.17網(wǎng)管和E300V3.16網(wǎng)管在處理OTU10G/2單板的重要數(shù)據(jù)時，在模塊的重要數(shù)據(jù)的第二個字節(jié)定義的不一致。3.16不支持2.5g的可調(diào)諧，因此在定義模塊類型的字節(jié)中就默認FF為10G可調(diào)諧光模塊。而3.17網(wǎng)管由于支持2.5G和10G的收發(fā)分離可調(diào)諧單板，因此在模塊重要數(shù)據(jù)第二個字節(jié)做了變更：01代表10G的光模塊。生產(chǎn)在調(diào)試時按照3.17網(wǎng)管的要求對單板進行了設置導致3.16網(wǎng)管下無法正常操作。對于OTU10G/2單板，可調(diào)諧的發(fā)模塊排序是2，因此查詢模塊2的重要數(shù)據(jù)，并且修改重要數(shù)據(jù)的第2個字節(jié)為01，復位單板即可解決問題。1FFF03030009C410680429000000000F7EFF7B00000000000000000000008A00SRM41在E3003.15.104下無法正常顯示故障分類：單板和網(wǎng)管前后兼容問題故障現(xiàn)象描述：珠江干線擴容新發(fā)貨SRM41單板，網(wǎng)管網(wǎng)元面板配置界面無法顯示單板名稱如圖所示:

-皓網(wǎng)涵0深圳系統(tǒng)0廣深（1，1）1OG新系統(tǒng)0審山系統(tǒng)0廣布斯主統(tǒng)?廣清系統(tǒng)0廣遠系統(tǒng)0珠三環(huán)E網(wǎng)新慕統(tǒng)^JD^Xffy^Oijk :M-皓網(wǎng)涵0深圳系統(tǒng)0廣深（1，1）1OG新系統(tǒng)0審山系統(tǒng)0廣布斯主統(tǒng)?廣清系統(tǒng)0廣遠系統(tǒng)0珠三環(huán)E網(wǎng)新慕統(tǒng)^JD^Xffy^Oijk :MF系統(tǒng)《S）設備管理i。吉警（￡）性能（￡）[0珠三環(huán)宣回娜莎統(tǒng)0球三跖混折王統(tǒng)0長長中維日0stm傳送間W廣探H+D2.5W廣沿2,5G系統(tǒng)0廣逐（E）LM0廣卅-海噸5&0珠三角。同N5G0珠三角E同10G目0叩胃偉送網(wǎng)0廣卅=珠海（IMI）0廣州?州（頑?廣州=湛江（商?廣州淄口（頑IV復用段1*護狙-小管理者』夏率=由方溷蛾J01301J車劊苗masJ沖花頑廣是）J庖Wider睇JTMir?Cr?）05j<ZS215JSltZS2163成2X33J淼W3思平山（廣海）3偉山IB〔廣湛）3佛山Its（廣球）3像山2XUI佛山我2033佛山2X2043佛山2X3$m抉音碩（廣市）tr^cMIP閃墀旋示I5/971?-0/84 -5/76?^38SSE翌目&|MunLQl355CHmnl-HUOdOKc_l90510Del#三ol色故障解決:故障原因為版本兼容性問題，對于SRM單板群路速率在3.15網(wǎng)管和3.16網(wǎng)管同一個字節(jié)（第17字節(jié)）定義不同，具體如下:網(wǎng)管版本2.5G定義10G定義E300V3.150201E300V3.16R20001同樣的單板和單板軟件，配合不同網(wǎng)管使用時必須要修改重要數(shù)據(jù)，否則不能匹配。生產(chǎn)線發(fā)貨時按照E300V3.16網(wǎng)管調(diào)試的，而現(xiàn)場使用版本是E300V3.15。因此修改單板重要數(shù)據(jù)后解決。3.NCPF單板問題故障現(xiàn)象：單板在上電正常運行數(shù)日后，發(fā)現(xiàn)網(wǎng)元無法ping通，在現(xiàn)場軟硬件復位NCPF和OSC單板均無效。到網(wǎng)元處發(fā)現(xiàn)本接入出現(xiàn)通訊時斷時續(xù)，但單板運行指示燈正常。故障處理從上述顯現(xiàn)看是單板軟件運行異常，將撥碼開關(guān)的2,8撥ON后試圖重新制作NCPF單板，強制NCPF地址為1，此時可以ping通單板，ftp和telnet都可以登錄，但是無法通過FTP上傳文件，上報“notbuildfileconnected”多次試驗均是該提示。初步斷定NCPF單板的boot程序運行異?；蛴布收?。但后來想起來可能是計算機防火墻禁用了ftp文件傳輸服務，修改計算的防火墻設置后。重新制作NCPF單板，下載AGETN程序后問題解決。4.NCPF單板導致網(wǎng)元無法建鏈問題設備類型：ZXWMM900故障現(xiàn)象：在工程中發(fā)現(xiàn)無法監(jiān)控接入網(wǎng)元的相鄰網(wǎng)元，并且該站點的OSCL單板總是出現(xiàn)時間周期不等復位（根據(jù)紅綠燈的閃爍狀態(tài)判斷的），在復位期間有激光器關(guān)斷的現(xiàn)象。telnet登陸到NCPF單板上用ipconfg-a命令查詢，發(fā)現(xiàn)無法建立本網(wǎng)元和相鄰網(wǎng)元之間的光口連接關(guān)系。故障處理從現(xiàn)象上看我們把重點放在了OSCL單板上，在正常的狀態(tài)下OSCL單板即使軟件重起也不會有關(guān)段激光器的操作，加重了OSCL單板硬件故障的懷疑。因此調(diào)來一塊OSCL單板更換，但是發(fā)現(xiàn)問題并沒有得到解決。并且把原來的OSCL單板換到其他的機架上后發(fā)現(xiàn)工作正常。至此我們只有另辟蹊徑，將網(wǎng)元上的其他單板都置為浮插狀態(tài)，就剩下NCPF單板和OSCL單板，現(xiàn)象依舊OSCL還是非周期性的復位。那么就剩下兩個可能性背板或者NCPF單板有問題，從別的機架上調(diào)來一個運行正常的NCPF單板換上，觀察發(fā)現(xiàn)OSCL單板的復位情況消失了。再次telnet到NCPF單板上用ipconfig-a來查看建鏈狀態(tài)，發(fā)現(xiàn)本站點的OSCL的光口和相鄰的網(wǎng)元的OSCL單板的光口可以正確的建立連接。至此故障消除。TMUX子架無法監(jiān)控問題故障描述TMUX子架上除了FCB單板外沒有配置其他業(yè)務單板，所有TMUX子架上的所有FCB單板都無法監(jiān)控，上報“單板不在位”。拔掉網(wǎng)管上配置的FCB后無法獲取實安板信息。故障處理以前生產(chǎn)中發(fā)現(xiàn)過在空子架只配置FCB不配置其他單板時，子架無法正常監(jiān)控問題。因此，從別的子架上借調(diào)了一塊單板放在TMUX子架上，網(wǎng)管上仍然取不到任何實安板的信息。由此斷定是NCPF和TMUX子架無法建立通訊連接，F(xiàn)CB總線和S口總線都不通。互換機架上的NCPF單板，觀察發(fā)現(xiàn)故障依舊。而另外的機架上NCPF單板工作正常。排除了NCPF單板問題。更換數(shù)據(jù)電纜，調(diào)換數(shù)據(jù)接口，問題依舊，排除了數(shù)據(jù)接觸不良和線纜問題后。那么就剩下最后的可能：TMUX子架背板故障。申請新的背板更換后問題解決。SFP模塊發(fā)貨變更問題BOQ的SFP模塊配置的類型為I16.1和S16.1兩種短距模塊，發(fā)貨時發(fā)的SPF模塊是L16.1的長距模塊由此導致兩個問題。運營商在開箱驗貨時，根據(jù)BOQ的配置一項一項的對比，發(fā)現(xiàn)SFP模塊上除了模塊生產(chǎn)商的標識外，沒有關(guān)于接口類型的說明。經(jīng)核實后是L16.1的模塊，客戶認為發(fā)貨錯誤，最后經(jīng)解釋L16.1的SFP模塊性能更好，客戶雖然最終認可。但影響了客戶形象。計劃部門改變模塊配置后，營銷、計劃、和用服之間沒有有效的溝通，衰減器的配置沒有進行相應的變更，工程人員到達現(xiàn)場后才發(fā)現(xiàn)該問題。導致需要重新申請衰減器，不僅浪費了時間，也增加的成本。解決對策：是否能過要求模塊廠商在模塊上標注接口類型，明確了接口類型就意味著明確了接口指標，可以減少不合適的功率導致器件損壞，對于開局和維護都是很有裨益的。ZXMPM800環(huán)演習無法成功問題環(huán)境描述某工程配置有通道共享保護組，發(fā)現(xiàn)在進行環(huán)演習的過程中各站點的OPCS保護出現(xiàn)異常，下發(fā)清除命令后無法清除倒換的狀態(tài)。處理過程根據(jù)描述的現(xiàn)象，我們初步斷定是APS協(xié)議運行異常，具體導致的原因不清楚。即派工程師趕赴現(xiàn)場。由于現(xiàn)場有業(yè)務，因此制定了一個初步的處理方案。工程師到現(xiàn)場后測試NCPF/OSCF/APSF的S口通訊發(fā)現(xiàn)多個OSCF單板S口跑死，然后ping每個網(wǎng)元的APSF單板確認APSF單板和OSCF單板的通訊狀態(tài)。發(fā)現(xiàn)其中有個APSF單板無法ping通，然后帶了備件到現(xiàn)場，發(fā)現(xiàn)APSF單板和OSCF單板的通訊網(wǎng)線沒有插好，插好后APSF工作正常。接下來處理APS協(xié)議運行異常問題，通過網(wǎng)管的仔細查詢，發(fā)現(xiàn)實際的業(yè)務都工作在工作通道上，并沒有任何倒換發(fā)生。這樣就可以放心的重新配置保護組，首先將保護組使能“禁止”，然后刪除保護組；在重新配置保護組，配置完后重新計算多播路由并下發(fā)。擇機測試保護組。OP單板定標導致網(wǎng)管查詢偏差10DB故障描述新申請的op單板在現(xiàn)場測試時，發(fā)現(xiàn)單板的實際輸入功率和網(wǎng)管上查詢到的功率相差10dB,現(xiàn)場對接的設備為1310nm波長。故障處理這個問題從現(xiàn)象上看，是OP單板的定標不準引起的。但是什么原因?qū)е逻@個問題產(chǎn)生的，首先OP單板在配置時可能放在客戶端，也可能配置在線路側(cè)，需要根據(jù)配置確定。如果在客戶端使用的話接入的業(yè)務可能是1310nm或者1550nm，OP單板的某些光模塊在定標時，1310nm和1550nm的光源的定標是有差異的。因此需要在申請的時候，需要注明使用的波長范圍，以免發(fā)生類似問題導致延誤。多播路由組中的網(wǎng)元丟失故障描述：計算多波路由時，發(fā)現(xiàn)多波組中的部分網(wǎng)元丟失。處理過程從反饋的現(xiàn)象看，保護組配置數(shù)據(jù)有問題或組播路由設置問題，導致節(jié)點之間的通訊沒有建立，所以沒有發(fā)生倒換。由于保護組的配置比較繁瑣，現(xiàn)場工程師脫機進行了保護組重新配置，可以正確的計算多播路由。到現(xiàn)場之后重新下發(fā)了保護組的配置，進行環(huán)演習，發(fā)現(xiàn)除下發(fā)環(huán)演習命令的網(wǎng)元外，其他的站點狀態(tài)均未發(fā)生變化。但是從OPCS的重要數(shù)據(jù)和現(xiàn)場人員對OPCS的指示燈觀察，原先實際業(yè)務在沒有重配保護組之前已經(jīng)發(fā)生倒換。分析：脫機重新配置保護組前，業(yè)務已經(jīng)處于倒換狀態(tài)。然后又做了環(huán)演習，屬于非法操作。重新配置保護組，作環(huán)演習導致新保護組只識別自己的協(xié)議狀態(tài)，無法同OPCS的實際狀態(tài)同步。為了使協(xié)議狀態(tài)和OPCS的實際狀態(tài)一致，對保護組所有網(wǎng)元使用所有跨段保護鎖定命令，之后清空命令后。再進行環(huán)演習查詢其倒換狀態(tài)發(fā)現(xiàn)只有使用命令的站點出現(xiàn)環(huán)演習命令，但其他站點狀態(tài)均為空閑態(tài)未有動作。分析：為了使協(xié)議的狀態(tài)和OPCS的實際倒換狀態(tài)一致，才對保護組所有網(wǎng)元使用所有跨段保護鎖定命令，之后在清除。接著工程師又下發(fā)了環(huán)演習命令，這是多余的操作。使用強制倒換命令，發(fā)現(xiàn)還是使用命令站點發(fā)生倒換，其他站點未動作，業(yè)務中斷了，使用清除命令后業(yè)務恢復正常分析：這是一步非常危險的操作，在實際維護中不該使用，明知道業(yè)務已經(jīng)發(fā)生了倒換，那說明在之前線路中的確是有故障，故障沒有排除這個操作會導致業(yè)務中斷是肯定無疑的。在故障仍然無法解決時，只好讓現(xiàn)場工程師在線重新配置保護組，計算多波路由。在重新配置后發(fā)現(xiàn)，保護組工作正常。IP沖突導致網(wǎng)管無法監(jiān)控故障描述：M800城域波分，環(huán)網(wǎng)結(jié)構(gòu)，采用百兆動態(tài)路由，遠程網(wǎng)管通過DCN網(wǎng)連接，OSCF光口IP地址配置10.10.*.*網(wǎng)段，NCP配置198.1.*.1。遠程網(wǎng)管調(diào)試成功后，第三天出現(xiàn)除網(wǎng)關(guān)網(wǎng)元外所有網(wǎng)元脫管。處理過程：讓局方檢查DCN靜態(tài)路由，沒有改動，排除靜態(tài)路由問題。在服務器PING除網(wǎng)關(guān)網(wǎng)元外的其他網(wǎng)元IP地址，無法PING通；讓維護人員復位網(wǎng)關(guān)網(wǎng)元及相鄰網(wǎng)元的NCPF及OSCF單板，遠程網(wǎng)管仍無法PING通其他網(wǎng)元；到現(xiàn)場直接用筆記本電腦接網(wǎng)關(guān)網(wǎng)元，啟動本地網(wǎng)管，并拔掉遠程網(wǎng)管，仍只能管理到網(wǎng)關(guān)網(wǎng)元，無法PING通其他網(wǎng)元；懷疑斷開DCN后網(wǎng)絡沒有觸發(fā)OSPF的重新計算，于是拔掉網(wǎng)關(guān)網(wǎng)元OSCF第一個光口的尾纖，有一半網(wǎng)元可以管理，插回光口一的尾纖，然后拔掉光口二的尾纖，所有網(wǎng)元均可以管理，插回光口二的尾纖，仍可以全部管理；由此判讀在DCN網(wǎng)中的確存在域沖突。詢問局方數(shù)據(jù)人員，198.1.*.*網(wǎng)段沒有沖突，10.10.*.*網(wǎng)段被其他設備占用，并且網(wǎng)管也是通過DCN網(wǎng)絡相連。由此判斷遠程網(wǎng)管脫管由于OSCF光口IP地址在DCN網(wǎng)內(nèi)與其他設備發(fā)生沖突引起。更改OSCF光口IP地址，監(jiān)控恢復正常。分析：其實在3的操作之后，可以通過telnet級連方式登陸接入網(wǎng)元的相鄰網(wǎng)元，如果相鄰的網(wǎng)元存在故障的話，肯定是無法級連登陸到接入網(wǎng)元的相鄰網(wǎng)元的。如果登錄成功，用ifa命令察看ppp鏈路是否通暢，如果顯示的結(jié)果中可正確看到相鄰網(wǎng)元的端口連接情況，說明物理通道和單板的工作都沒有問題（可以用同樣的方法檢查所有網(wǎng)元）。那么問題很可能是在DCN和設備構(gòu)成的綜合網(wǎng)絡中有內(nèi)部的路由沖突，出現(xiàn)了多個相同的IP段。在到達現(xiàn)場后，斷開設備和DCN的所有連接，只要復位一下任何一個網(wǎng)元的OSCF單板，觸發(fā)OSPF協(xié)議的重新計算。如果是由于路由沖突引起的，在重新刷新路由后，就可用現(xiàn)場接入網(wǎng)管實現(xiàn)全網(wǎng)監(jiān)控。如果以上步驟都無法