Tuesday, September 20, 2016

The FDG Board Reports the R_DATA_LOST Alarm in the Early Morning

The FDG board reports the R_DATA_LOST alarm in the early morning because the traffic volume is light.

Product

OptiX Metro 6100
OptiX Metro 6040

Fault Type

Optical Transponder Board
R_DATA_LOST

Symptom

The FDG board in the Metro 6100 keeps reporting the R_DATA_LOST alarm in the early morning. The line and the data equipment connecting to the FDG board, however, are normal.

Cause Analysis

The FDG board detects the services every five seconds. If the FDG does not receive data packets during the detection, the FDG reports the R_DATA_LOST alarm. The alarm does not mean that the services are not available. No alarm is generated in the line during day and the services are normal. The alarm is generated only in the early morning. Hence, the alarm is related to the truth that the traffic volume is light. In the early morning, no data packets are transmitted normally when the FDG detects the services. Hence, the R_DATA_LOST alarm is reported.

Procedure

  1. Make sure that the services are normal. To clear T_DATA_LOST and R_DATA_LOST alarms, check the KEEP ALIVE parameter of one router. If the parameter is enabled, the router continuously sends small packets to inform the remote equipment that the link is up. You can mask the alarm on the NMS if required.

Reference Information

The data boards, such as the LDG, also have the similar problem. Solve the problem in a similar way.
The T_DATA_LOST alarm is client-side transmitting data lost. The board regularly checks the Ethernet performance event "Good Octets Transmitted" and compares the number with the number of last time. The alarm occurs when the two numbers are the same, which indicating that the board does not transmit any data.
The R_DATA_LOST alarm is client-side receiving data lost. The board regularly checks the Ethernet performance event "Good Octets Received" and compares the number with the number of last time. The alarm occurs when the two numbers are the same, which indicating that the board does not receive any data

MORE BLOG:

During the Rerouting in the ASON Network, the Protection Switching Time May Exceed the Specification ValuePrewarning for ARP Entry Aging Failures on MxU

No comments:

Post a Comment