Problem Description
Version upgrade of OSN2500 of a bureau, unified to version 5.36.18.50P01. The upgrade process is normal with analog packet loading. After the upgrade is completed, the master control reports NESF_LOST with alarm parameters 0x01, 0x00, 0x0d, 0x01,0xff; the master control hardware model is SSQ3CXL.
Alert message
NESF_LOST
Processing
1, the first parameter of NESF_LOST is fixed, the third parameter is the registered channel number of the lost software, which should be compared with the actual channel number of the files on the single board queried by the command :sftm-get-fpatrol-info:bid in order to know which file has been lost.
2, you can also use the command to query the software of the normal equipment after the upgrade, and compare it with the software of the network element that reported the alarm to see if there is any software that was not loaded, or the size of the software displayed after loading is not consistent with that of the normal network element. Reload the missing or inconsistent files.
: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/fpga".
:sftm-show-dir:82(83),"/ofs2/hwx"; :sftm-show-dir:82(83),"/ofs2/hwx".
3, through comparison found that the normal network elements and reported alarm network elements are indeed inconsistent, reported NESF_LOS network elements /ofs1/hwx, /ofs2/hwx directory more than a few old files but less q31500.hwx, see Annex 1-2;
4, consult the R & D, the root of the problem because the Q3cxl software defined patrol and the old version is different, and the new upgrade of the extended bios did not take effect led to, can be solved by the following method:
Take 83 as the backup master and 82 as the main master as an example
Step 1:
Connect to the upgraded master control through Navigator, and rename the extended BIOS of the main and backup master control boards with the following command:
: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";
via
:sftm-show-dir:83,"/ofs1/hwx".
:sftm-show-dir:83,"/ofs2/hwx";
:sftm-show-dir:82,"/ofs1/hwx"; :sftm-show-dir:82,"/ofs1/hwx";
:sftm-show-dir:82,"/ofs2/hwx"; :sftm-show-dir:82,"/ofs2/hwx";
Delete the old extbios.hwx after checking to make sure that all q3ebios.hwx already exists
:sftm-delete-file:82,"/ofs1/hwx/extbios.hwx"; query to confirm that q3ebios. hwx already exists, then delete the old 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"
Step 2:
Reset the backup master first with the commands :cfg-reset-board:83,soft and :cfg-reset-board:82,soft, and then reset the master when the backup master is up.
Root cause
1、Since the upgrade process is normal, it may be a false alarm;
2、There is indeed a file missed loading;
3、Other reasons.
Recommendations and Summary
The root cause of this issue is due to the fact that the Q3cxl software defined patrol is different from the old version and the newly upgraded extended bios did not take effect. The network elements of Q3CXL that do not report NESF_LOS also need to be handled, see the attachment for the handling method.
END


Chinese
English





