Cause of the ALM_DATA_RLOS alarm for the LOG board


The ALM_DATA_RLOS alarm indicates that no data is received on an Ethernet port. The board regularly checks the total number of the received bytes and compares the number this time with the number last time. The alarm is reported when the two numbers are the same, indicating that the board does not receive data.

Other related questions:
Cause for the ALM_DATA_RLOS alarm on the LOG board
The ALM_DATA_RLOS alarm indicates that the receive end of the Ethernet port has no data. The board periodically checks the total number of received bytes and compares them with the previous check results. If there is no change, the board does not receive data and therefore reports this alarm.

Cause for transient alarm reporting on TOM boards
On the OSP platform, alarm reporting has anti-jitter mechanisms. The anti-jitter time for alarm reporting is 2.5s and that for alarm clearing is 10s. If a board alarm task can be reported to the platform at least two consecutive times within 2.5s, alarms may not be transiently reported. If the alarm task reporting interval of a board is greater than 2.5s, transient alarm reporting probably occurs. The alarm task reporting interval of most boards is 1s and alarm status can be reported twice in 2.5s. If an alarm is found during the first detection but cleared during the second detection, the alarm will not be reported. In this manner, transient alarm reporting can be effectively avoided. To reduce the CPU usage, the alarm task reporting interval of TN11TOM boards is 2s but that of TN52TOM boards. As a result, the alarm status may be reported only once in the 2.5s anti-jitter period. Consequently, the alarm anti-jitter mechanism does not take effect and an alarm is reported and lasts 1s. If a higher-priority task preempts the alarm task, the alarm task reporting interval may be longer and the alarm may last for more than 1s. Therefore, TOM boards are prone to report alarms in case of transient service interruption. When bit errors are present on a line, a TOM board may falsely detect that the BDI byte is reset to 1 and therefore transiently reports alarms such as ODU1_PM_BDI. As a result, alarms such as ODU1_PM_DEG may be transiently reported upon SNCP protection switching.

Cause for the BD_STATUS alarm on multiple boards when the AUX board is faulty
The AUX board implements cascading between master and slave subracks (implementing inter-subrack communication). Therefore, if the AUX board is faulty, multiple boards will become offline. You can reset or replace the AUX board to clear the BD_STATUS alarm.

Possible causes of an ODUK_PM_OCI alarm on a board
The possible causes of an ODUK_PM_OCI alarm on a board are as follows: 1. An ODUK_PM_OCI alarm occurs on the corresponding board in the upstream. 2. A loopback occurs on the peer board. 3. No cross-connections or incorrect cross-connections are configured on the peer board.

Possible causes of a power threshold-crossing alarm on an OA board
The possible causes are as follows: 1. If the upstream board outputs optical power at a normal level but the local board receives excessively high optical power, the cause may be that no appropriate attenuator is added. 2. The peer board or the upstream board outputs excessively high optical power. 3. The board at the local station is faulty.

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