问题描述
升级#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分钟。