OSN2500 Q3CXL主控升级后上报NESF_LOS告警处理一例
问题描述
对某局OSN2500进行版本升级,统一到5.36.18.50P01版本。采用模拟包加载方式,升级过程正常,升级完成后主控上报NESF_LOST,告警参数为0x01,0x00,0x0d,0x01,0xff;主控硬件型号为SSQ3CXL。
告警信息
NESF_LOST
处理过程
1、NESF_LOST 的第一个参数是固定不变的,第三个参数是表示丢失的软件的注册通道号,这个通道号要和命令:sftm-get-fpatrol-info:bid查询到的该单板上的文件的实际的通道号对照才能知道是哪个文件丢失了;
2、也可以使用命令查询升级后正常设备的软件情况,与上报告警的网元的软件情况进行对比,看是否有软件漏加载了,或者加载后显示的软件大小和正常网元不一致。对丢失或者不一致的文件重新加载。
:sftm-show-dir:82(83),"/ofs1/fpga";
:sftm-show-dir:82(83),"/ofs1/hwx";
:sftm-show-dir:82(83),"/ofs2/fpga";
:sftm-show-dir:82(83),"/ofs2/hwx";
3、通过比较发现正常网元和上报告警的网元确实不一致,上报NESF_LOS的网元/ofs1/hwx、/ofs2/hwx目录下多了几个老文件但少了q31500.hwx,详见附件1-2;
4、咨询研发,问题的根因为Q3cxl软件定义巡检和老版本不同,而新升级的扩展bios没有生效导致,可以通过如下方法解决:
以83为备主控,82为主主控为例
第一步:
通过Navigator连接上升级完成的主控,通过以下命令将主备主控单板的扩展BIOS改名:
:sftm-copy-file:82,"/ofs1/hwx/extbios.hwx",82,"/ofs1/hwx/q3ebios.hwx";
:sftm-copy-file:83,"/ofs1/hwx/extbios.hwx",83,"/ofs1/hwx/q3ebios.hwx";
:sftm-copy-file:82,"/ofs2/hwx/extbios.hwx",82,"/ofs2/hwx/q3ebios.hwx";
:sftm-copy-file:83,"/ofs2/hwx/extbios.hwx",83,"/ofs2/hwx/q3ebios.hwx";
通过
:sftm-show-dir:83,"/ofs1/hwx";
:sftm-show-dir:83,"/ofs2/hwx";
:sftm-show-dir:82,"/ofs1/hwx";
:sftm-show-dir:82,"/ofs2/hwx";
查询确认q3ebios.hwx都已经存在后,删除老的extbios.hwx
:sftm-delete-file:82,"/ofs1/hwx/extbios.hwx"
:sftm-delete-file:83,"/ofs1/hwx/extbios.hwx"
:sftm-delete-file:82,"/ofs2/hwx/extbios.hwx"
:sftm-delete-file:83,"/ofs2/hwx/extbios.hwx"
第二步:
通过:cfg-reset-board:83,soft 和 :cfg-reset-board:82,soft两条命令先复位备主控,等备主控起来以后再复位主主控。
根因
1、由于升级过程正常,有可能是误报;
2、确实有文件漏加载;
3、其他原因。
建议与总结
该问题的根因为Q3cxl软件定义巡检和老版本不同,而新升级的扩展bios没有生效导致。对于不上报NESF_LOS的Q3CXL的网元也需要处理,处理方法见附件。
END
- 上一篇:OSN2500 SSN1ADQ1单板绑定时隙时交叉板复位 2018-5-22
- 下一篇:OSN2500 SNCP业务倒换不成功 2018-5-22