問題描述

升級#478網元OSN3500設備，該網元為環網上站點，速率為10G（2塊SSN1SL64），為支持N3EGS4單板，版本由5.21.17.12升級至5.21.17.31,主控板為N1GSCC，采用TOOLKIT模擬包加載方式進行，在激活最后一塊單板SSN1SL64后，網元脫管，業務無影響。

告警信息

#478網元兩端站點及業務對端站點均無異常告警。

處理過程

通過分析結果進行處理：

1、通過：cm-get-chanerror:bid;查詢對接兩側網元光板DCC字節收發情況，所有參數均無變化，通過cm-get-chaninfo:bid查詢，僅有發送，而無接收字節，暫時排除ECC誤碼問題；

2、由于網元已經脫管，因此只能到現場進行查詢，通過命令行能夠正常登錄網元，對主控進行主備倒換測試，故障仍舊;

3、查詢ECC相關信息，設置均正常，通過

:cm-get-chanmode;

                                CHAN-ALLOMODE                                 

                                   CHAN-MODE                                    

                                     2      

:cm-get-chanallocinfo;

                              CHAN-ALLOC-INFO                                 

                     CHAN-MODE  CHAN-WIDTH  CHAN-NUM                         

                        1          3          40                               

                        2          3           10                               

                        2          9           10                               

                        3          3           22                               

                        3          9           6 

得知（以前結果也可以在T2000網管上查詢）：設備當前DCC工作模式為2，3字節模式，支持10路ECC；由于5.0平臺設備ECC端口分配非固定，單板硬復位后，ECC資源釋放，由于設備上有多光口單板SLT1（當前版本支持8路ECC），釋放后的資源被分配給了SLT1單板，于是將兩塊SLT1板拔出去，通過立即恢復正常；

3、通過T2000V2R7C03網管上載該網元數據，直觀地對網元進行難操作，將SLT1板插回，正常開工后，將兩塊SL64單板ECC禁止后再打開，網元又無法與其它網元進行通信了，逐一關閉SLT1板各端口ECC，當剩下9個端口未關閉時，通信恢復正常了，但僅有8-SL64收發正常，再關閉一個SLT1端口ECC，11-SL64板收發也正常了，證明了前面數據采集分析結果，其實在激活11-SL64時，問題已經開始發生，11-SL64板激活后，ECC資源已經重新分配給了SLT1板，走至8-SL64激活后，問題發生了。

根因

分析整改升級過程：

1、升級前檢查，網元無異常告警，ECC通信正常，可達網元數量為94個；

2、開始軟件加載；

3、激活單板軟件，順序是：備用主控-->主用主控-->備用UXCSB-->主用UXCSB-->11-SL64

-->1~4 SSN2PQ1-->8-SL64,設備中兩塊SLT1板已經配套5.21.17.31，因此TOOLKIT未對該類單板進行加載；

4、激活過程超過30分鐘，在激活8-SL64時，網元脫管；

分析可能原因：

1、激活過程應該沒有問題，即使在激活8-SL64單板前，復位了所以PQ1板，與脫管應該是沒有關系的；

2、初步懷疑主用主控板DCC處理問題，但在脫管前主控復位運行已經超過至少30分鐘，突然出再問題可能性不大，如果是硬件故障，至少可以切換到備用主控，備用主控同時故障機率更小；

3、對于出現ECC誤碼可能性相對比較大，

4、由于設備中安裝有兩塊SLT1多光口板，對于ECC資源需求較多，會不會有ECC資源不足的情況呢

建議與總結

1、這個案例看上去比較簡單，但有時候也是容易犯的錯誤，該問題的發生僅僅緣于對ECC資源分配不夠重視，以為升級前設備運行正常，業務正常就可以開始升級了，案例中正好是SLT1板不用升級，更不需要硬復位，而僅僅需要復位的光板為SL64，正好暴露出這個問題，如果SLT1需要升級，硬復位，安裝我們平時升級的習慣，一般是先激活高速率的線路板，后低速率，也許還沒有發現和關注ECC資源分配問題；

2、目前我們的NG-SDH設備默認采用ECC通信，因此了ECC資源建議大家平時開局維護時多關注，象SLT1這樣基本上不會參與組網的單板，開局擴容時，就把它的ECC資源禁止；

3、在進行升級任務時，建議多采集相關的數據，如：ECC通信是否正常，單板主備狀態是否正常，是否有屏蔽什么異常告警之類的數據，這樣才能夠做到升級基本萬無一失，也為自己節省了時間，本案例中去站點現場來回路程花費了10個小時，而處理好問題僅用了不到10分鐘。