1. First we run :cfg-get-backup-info, and the returned value is 0, which indicates that the communication between the active and standby SCC boards is interrupted. Then we run :cfg-get-phybd, and no information is found about the boards in slots 83, 81 and 5. The local end has no BD_STATUS alarm reported by boards in slot 83 or 5 either.
2. Since the boards run normally before the problem occurs, it is suspected that something is wrong with loading of the NE software. We query the types and the amount of files that exist in the /ofs1/hwx, /ofs1/fpga, /ofs1/hwx, and /ofs1/fpga directories of the standby SCC board before reset, and no anomaly is found. Moreover, the /ofs1/hwx directory contains the ne.ini file too.
3. Since the active CXL is working normally, it can be inferred that nothing is wrong with the loading of the NE software or other files. It is suspected that some anomaly occurs to the process of synchronization between the active and standby SCC software.
4. We check the upgrade logs and find that when the file ne1500.hwx is copied synchronously from the active SCC board to the standby SCC board, the returned amount of the loaded packets is 5374 instead of the normal 9401, and a fault prompt pops up:
ERROR-CODE Destination-NEID Destination-BoardID
0x90b6 589956 83
5. It is clear now that the standby SCC board remains out of service after reset due to incomplete loading of the ne1500.hwx file.