How to do when the OptiX OSN CXL board is frequently reset and the configuration backup fails After the upgrade

When the OptiX OSN 1500 CXL board is upgraded form the V1R3B025SP03 version to the V1R3B030SP04 version, it uses the slot for the backup SCC board at a node with a single SCC board. After the upgrade, reset the backup CXL board housed in slot 83. It is detected that the backup board resets every six minutes. The data backup fails, but the version is queried to be correct. In addition, the number and size of software files are correct.

errlog information indicates lan_sys.cpp error.
: ResetLog:: total reset times = 3  :   No.001:  2006-07-27 04:56:18   BOARD=082
TYPE=0xf0000010    SOFTTYPE=001: 
No.002:  2006-07-27 08:31:05   BOARD=082    TYPE=0xf0000004    SOFTTYPE=001   
:   No.003:  2007-02-23 17:52:04   BOARD=083    TYPE=0xf0000004    SOFTTYPE=001                                                     
: FatalLog:: total = 18          
:   001# 2007-02-26 16:37:45 fatal task errorcode=0xf0000010,   Line 02913 in lan_sys.cpp    
:   002# 2007-02-26 16:37:45 fatal task errorcode=0xf0000010,   Line 01362 in reset:MainLoop   
:   003# 2007-02-26 16:44:21 fatal task errorcode=0xf0000010,   Line 02913 in lan_sys.cpp

It is queried that the IP address of the SCC is consistent with the OptiX ASON node ID. Thus, the backup check fails. This problem can be avoided temporarily by revising the IP address.

OSN 1500B


1. The format of the Node ID is the same as that of the IP address. However, the node ID cannot be the same as the NE IP address, and the node ID should network wide unique.
Node ID should be independent of NE ID and NE IP address. Before the node ID is distributed, preliminary integrated planning is required. The node ID should be set according to the planning results and it cannot be randomly revised.

2. If the node ID is set, the board resets after the batch backup. For the SCC, if the node ID is inconsistent, the SCC manages it and then writes it to the system parameter section. The backup board frequently resets because the original node ID and IP address for the SCC conflict. When the SCC data is backed up to the newly added backup board, the fault occurs during the check. Thus, the reset is triggered.

3. The problem is not caused by the R3 version. The earlier versions of the OptiX OSN V1R3 version (not including itself) support the default value of for the node ID. According to the planning, the OptiX OSN V1R3 and later versions revise the node ID as 0 by default. Before any manual configuration is performed, the node ID and IP address for a board of the V1R3 version do not conflict.

It is assumed that the IP address and node ID for the single SCC board with the original configuration conflict because the board is upgraded from earlier versions to the R3 version. For the board of earlier versions, the default node ID is not all “0”s. If this configuration retains after the board is upgraded to the R3 version, the conflict occurs. However, the board has no check mechanism, and thus it is running normally and the problem does not occur. When the backup SCC board is newly added, the data of the active and standby SCC boards are synchronized, and thus the active/standby check is abnormal.