Troubleshooting Huawei OSN SCC: Configuration, Compatibility & Error Resolving

Troubleshooting Huawei OSN SCC: Configuration, Compatibility & Error Resolving

Overview & Thematic Scope

This FAQ provides comprehensive technical guidance for network engineers and telecom professionals on resetting and troubleshooting Huawei OSN System Control & Communication (SCC) boards. Covering both pre-sales and post-sales aspects, this article addresses common issues such as IP address recovery, database initialization, BIOS restoration, and resolving compatibility errors in OSN 1800, 6800, and 9800 series platforms. All guidance is based on official Huawei support documentation.

Troubleshooting Huawei OSN SCC: Configuration, Compatibility & Error Resolving details

Frequently Asked Questions

Q1: How do I restore the default IP address of a Huawei OSN SCC board?
Restore the default IP address by pressing the LAMP button on the SCC board in a specific sequence. Hold the LAMP button for 5-10 seconds, release and wait 5-10 seconds, press again for 5-10 seconds, release, wait 5-10 seconds, and press a third time. The default IP address resets to 129.9.191.240, after which you can connect via Navigator and change the IP as required .
Q2: How do I reset the SCC database using DIP switches on the OSN 6800?
Initiate the SCC database by setting the SW1 DIP switch to 1011, which deletes the database and places the board in BIOS status. First, ensure SW1 is set to 0000, then pull the board out and set the DIP switch to 1011. Reinsert the board and wait for the PROG indicator to blink green slowly, indicating the database deletion. Pull the board out again, set the DIP switch to 0000, and reinsert it .
Q3: What is the procedure to restore an SCC board from BIOS status on OSN 6800 or 8800?
Restore the SCC from BIOS status by copying a normal NESOFT from a working NE via FTP. Connect your computer to the NM_ETH port, set the IP to 129.9.*.*, and use FTP to clear the mfs, ofs1, and ofs2 folders. Copy the hwx and fpga folders from a known good NE into the ofs1 and ofs2 folders of the faulty board. Remove the jumper caps and let the SCC run normally; verify with hsc-get-work and hbu-get-backup-info commands .
Q4: How do I restore the default subrack mode for an OSN 1800 unreachable due to incorrect subrack ID?
Restore the default subrack mode (independent mode) by setting the SCC DIP switches to binary value 1001. Toggle the 1st and 4th switches to ON, and the 2nd and 3rd to OFF. Insert the board and wait for the STAT indicator to blink slowly. Then remove the board, set all switches to OFF (0000), and reinsert it. This resolves unreachable issues without replacing the SCC board .
Q5: How can I check if an SCC board reset was caused by a power issue?
Determine if a reset was power-related by checking the ERRLOG from the device. For OptiX OSN 902, a reset code of 0xf0000004 on the SCC board (slot 7) indicates a power reset. This can be used to prove that power supply interruptions affected the device services .
Q6: What is the CLI procedure to reset the SCC board and delete the database to resolve configuration errors?
Delete the database and reset the SCC board using CLI commands to resolve configuration issues. Use dbms-delete-all:drdb; dbms-delete-all:fdb0; and dbms-delete-all:fdb1; to delete the database. Then, use hsc-get-work to identify the main board and cfg-reset-board: Standby SCC, soft; to reset the standby board before performing a full reset .
Q7: Why does an SCC board keep resetting after a software upgrade, and how is it fixed?
Post-upgrade resets often occur due to a conflict between the Node ID and the NE IP address, causing backup checks to fail. Resolve this by ensuring the Node ID is network-wide unique and does not match the NE IP. Revise the IP address as a temporary fix, and plan Node IDs carefully during network integration to prevent conflicts .
Q8: What should I do if two SCC boards are reset simultaneously causing ASON services to become abnormal?
When two SCC boards reset simultaneously, ASON services may become abnormal. Check for cross-connection deletion failures that may have caused the SCC board abnormality. Verify the reset logs to determine the root cause, and ensure proper coordination between active and standby boards to prevent service interruptions .