服务热线
189-2347-0832

中兴S385 您当前所处位置: 首页 > 新闻资讯 > 行业技术

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

发布时间:2018-03-25

问题描述

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