单板硬复位后ECC资源重新分配后导致网元脱管

问题描述

升级#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分钟。