Cause why the service type cannot be set for a TN52TOG board when the board is added to the OSN 8800 V100R005C00


The TOG boards on the OSN 8800 V100R005C00 support only the GFP-T service type. Therefore, the service type does not need to be set.

Other related questions:
Cause why the STG board is mandatory for the OSN 8800 but optional for the OSN 6800
The OSN 8800 of version V100R002 or later is a synchronous system, requiring that all service boards and cross-connect boards are synchronized (with the same frequencies and aligned frame headers). Therefore, a unique reference clock signal and a unique frame header are required. To meet this requirement, each service board outputs services according to the clock signal and frame header of a clock board. Therefore, the STG board is mandatory for the OSN 8800 of version V100R002 or later. If no STG board is configured, centralized service scheduling cannot be achieved. The OSN 6800 is an asynchronous system and does not require a unique reference clock or unique frame header. Therefore, no STG board needs to be configured for the OSN 6800.

OSN 8800 boards that support FC1200 services
LOA, LSX, TDX, and TQX boards on the OSN 8800 support FC1200 services.

Method used to handle the failure to delete an FIU board from the OSN 8800
Delete logical fiber connections before deleting the board.

Cause why "STND" is displayed in the NE Explorer for the OSN 8800 TN54TOA board
It is a reserved design, because there are boards in compatible mode (COMP) and boards in standard mode (STND).

Failure to clear the TEMP_OVER alarm from the SCC board on OSN 8800
1. Run the :cfg-get-scc-temperature:bid command to query the actual temperature of the board. The query result is 22.3?C, which is within the normal range. 2. Run the alm-del-curdata:num command to delete the alarm from the NE. The alarm is generated again. 3. Perform a cold reset on the active and standby SCC boards. The alarm persists. 4. Suspect that the SCC board hardware is faulty and replace the SCC board in slot 18. After the board replacement, the alarm persists and the alarm generation time is the initial alarm generation time. 5. Remove both the active and standby SCC boards and then re-insert them respectively. The fault symptom persists. 6. Run the :alm-get-bdalm-new command to query the boards one by one and then determine that the SCC board in slot 118 reports the TEMP_OVER alarm.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top