LDP/1/mplsLdpSessionDown_active

Message

LDP/1/mplsLdpSessionDown_active: The LDP session status is Down. (PeerLsrId=[PeerLsrId], VrfName=[VrfName], SessionType=[SessionType], IfName=[IfName], SubReason=[SubReason], Reason=[Reason])

Description

An LDP session went to Down or remained in the Down state.

Parameters

Parameter Name Parameter Meaning

PeerLsrId

Peer LSR ID.

VrfName

VRF for an LDP session.

SessionType

LDP session type: - Local - Remote - Local and remote

IfName

Name of the physical interface.

SubReason

Detailed cause for an alarm When an LDP session goes Down because an incorrect packet or a Notify message is received, the specific error packet type or Notify message type is displayed. For example: - Incorrect LDP ID carried in the packet(1) - Incorrect version number carried in the packet(2) - Incorrect PDU length(3) - Incorrect message length(5) - Incorrect TLV carried in the packet(7) - The received Notify message indicates that the Hello packet times out(9) - The received Notify message indicating a shutdown instruction(10) - The received Notify message indicates the keepalive message times out(20) - IGP delete the RLFA IID(1056968430) When an LDP session goes Down because an incorrect socket is received, the detail error reason or an error code is displayed. For example: - Tcp connection reset by peer(54) - Tcp connection time out(60) This field is 0 if the LDP session goes Down due to other causes.

Reason

Alarm cause.

Possible Causes

  • Cause 1: The LDP Hello hold timer expired.
  • Cause 2: The LDP Keepalive timer expired.
  • Cause 3: The reset ldp command was configured.
  • Cause 7: GR was configured for a session.
  • Cause 9: The Keepalive timer of a session is changed.
  • Cause 11: The role of a session is changed.
  • Cause 13: The transport address of a session is changed.
  • Cause 14: The LSR ID of a session is changed.
  • Cause 15: A notification was received from a peer to request the reestablishment of an LDP session on the local end.
  • Cause 22: An LDP session cannot be set up.
  • Cause 23: An error message was received from a peer.
  • Cause 24: A socket error was received.
  • Cause 26: Capability was configured for a session.
  • Cause 27: The configure of MPLS LDP is deleted.
  • Cause 28: The configure of MPLS LDP Remote is deleted.
  • Cause 30: The session protection timer expired.
  • Cause 31: IGP delete the RLFA IID.
  • Cause 32: Excessive messages were received.

Procedure

  • Cause 1: The LDP Hello hold timer expired.

    Check the peer Down alarm and follow the recovery suggestion for the peer Down event to clear this alarm.

  • Cause 2: The LDP Keepalive timer expired.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 14. 3. Run the display mpls ldp peer command to check whether there is information about the peer. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. The command output must contain the TransportAddress field. Run the display ip routing-table ip-address command to check whether information about the route to the peer exists. The value of ip-address must be consistent with the value of the TransportAddress field in the display mpls ldp peer command output. - If there is no routing information, go to Step 4. - If there is routing information, go to Step 6. 4. Check whether the IGP route is correctly configured. If OSPF is used as an IGP, run the display current-configuration configuration ospf command in the OSPF view to check whether OSPF has advertised the routes destined for the addresses of loopback interfaces and corresponding interfaces. If IS-IS is used as an IGP, run the display this command in the loopback interface view and the corresponding interface view to check whether IS-IS is enabled. - If IS-IS is enabled, go to Step 6. - If IS-IS is not enabled, go to Step 5. 5. Restore the routing protocol configurations and check whether the configurations are normal. - If the configurations are normal, go to Step 3. - If the configurations are not normal, go to Step 14. 6. Run the ping -a source-ip -c destination-address command for more than 100 times to check whether packet loss occurs. - If packet loss occurs, go to Step 7. - If packet loss does not occur, go to Step 8. 7. If the link is unstable because of a link fault or heavy traffic, rectify the link fault or stabilize traffic on the link. If the alarm persists, go to Step 11. 8. Run the display mpls ldp interface command on two ends of the link to check the interface status. - If the corresponding interface exists, but the Status field is displayed as Inactive, go to Step 11. - If the corresponding interface does not exist, go to Step 9. 9. Run the display this command on the interface to check whether LDP is enabled. - If LDP is enabled, go to Step 14. - If LDP is not enabled, go to Step 10. 10. Run the mpls ldp command in the interface view and then go to Step 11. 11. Run the display this command on the interface to check whether the interface is shut down. - If the interface is shut down, go to Step 12. - If the interface is not shut down, go to Step 14. 12. Run the undo shutdown command in the interface view and then go to Step 13. 13. Check whether the session is in the Up state. - If the session is in the Up state, the procedure ends. - If the session is still Down, go to Step 14. 14. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 3: The reset ldp command was configured.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 7: GR was configured for a session.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 9: The Keepalive timer of a session is changed.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 11: The role of a session is changed.

    Check whether the label distribution modes on the two ends are the same.

  • Cause 13: The transport address of a session is changed.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Run the display mpls ldp peer command to check whether there is route on the peer to the newly configured transport address. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. The command output must contain the TransportAddress field. Run the display ip routing-table ip-address command to check whether information about the route to the peer exists. The value of ip-address must be consistent with the value of the TransportAddress field in the display mpls ldp peer command output. - If there is no routing information, go to Step 4. - If there is routing information, go to Step 5. 4. Incorrect configurations exist. Select another transport address and go to Step 1. 5. Check whether the TCP status is normal. Run the display tcp status command to check whether the actor (has a larger IP address) has an established TCP connection and whether the partner (has a smaller IP address) has two TCP connections: one in the Established state, and the other in the Listening state. - If the TCP status is normal, go to Step 6. - If the TCP status is abnormal, go to Step 7. 6. Check whether the session is in the Up state. - If the session is in the Up state, the procedure ends. - Otherwise, go to Step 7. 7. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 14: The LSR ID of a session is changed.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 15: A notification was received from a peer to request the reestablishment of an LDP session on the local end.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 3. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 22: An LDP session cannot be set up.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If no information is displayed or the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 19. 3. Run the display mpls ldp peer command to check whether there is information about the peer. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If there is information about the peer, go to Step 4. - If there is no peer information, go to Step 7. 4. Run the display mpls ldp session command repeatedly to check whether the LDP session flaps. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. If the Status field in the command output is sometimes displayed as Operational and sometimes displayed as Nonexistent, or no information is displayed, the LDP session flaps. - If the LDP session flaps, go to Step 5. - If the LDP session does not flap, go to Step 19. 5. LDP session flapping is caused by inconsistent initial negotiation. Check whether configurations are frequently modified. - If configurations are frequently modified, go to Step 6. - If configurations are not frequently modified, go to Step 19. 6. Stop modifying the configurations. Two minutes later, go to Step 18. 7. Run the display mpls ldp peer command to check the TransportAddress field in the command output. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. Run the display ip routing-table ip-address command to check whether information about the route to the peer exists. The value of ip-address must be consistent with the value of the TransportAddress field in the display mpls ldp peer command output. - If there is no routing information, go to Step 8. - If there is routing information, go to Step 10. 8. Check whether the IGP route is correctly configured. If OSPF is used as an IGP, run the display current-configuration configuration ospf command in the OSPF view to check whether OSPF has advertised the routes destined for the addresses of loopback interfaces and corresponding interfaces. If IS-IS is used as an IGP, run the display this command in the loopback interface view and the corresponding interface view to check whether IS-IS is enabled. - If IS-IS is enabled, go to Step 11. - If IS-IS is not enabled, go to Step 9. 9. Restore the routing protocol configurations and check whether the configurations are normal. - If the configurations are normal, go to Step 7. - If the configurations are abnormal, go to Step 19. 10. Check whether the TCP status is normal. Run the display mpls ldp peer command to check the Peer Transport Address field (remarked as S) and the Peer Discovery Source field. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. Then, run the display mpls ldp interface interface-type interface-number command to check the Transport Address field (remarked as D). The value of interface-type interface-number in the command must be consistent with the value of the Peer Discovery Source field in the display mpls ldp peer command output. Run the display tcp status command to check whether the Local Add:port field is displayed as D and whether the Foreign Add:port field is displayed as S. If the Local Add:port field is displayed as D and the Foreign Add:port field is displayed as S, the TCP status is normal. - If TCP status is normal, go to Step 18. - If TCP status is abnormal, go to Step 11. 11. Run the ping -a source-ip -c destination-address command for more than 100 times to check whether packet loss occurs. Ensure that the parameter source-ip is the same as the value of the Peer Transport Address field in Step 10 and the value of the parameter destination-address is the same as the value of the Transport Address field in Step 10. - If packet loss occurs, go to Step 12. - If packet loss does not occur, go to Step 13. 12. If the link is unstable because of a link fault or heavy traffic, rectify the link fault or stabilize traffic on the link, and then go to Step 18. 13. Run the display mpls ldp interface command on two ends of the link to check whether the status of the interface is normal. - If the corresponding interface exists, but the Status field is displayed as Inactive, go to Step 16. - If the corresponding interface does not exist, go to Step 14. 14. Run the display this command on the interface to check whether LDP is enabled. - If LDP is enabled, go to Step 19. - If LDP is not enabled, go to Step 15. 15. Run the mpls ldp command in the interface view and then go to Step 18. 16. Run the display this command on the interface to check whether the interface is shut down. - If the interface is shut down, go to Step 17. - If the interface is not shut down, go to Step 19. 17. Run the undo shutdown command in the interface view and then go to Step 18. 18. Check whether the session is in the Up state. - If the session is in the Up state, the procedure ends. - If the session is still Down, go to Step 19. 19. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 23: An error message was received from a peer.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 3. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 24: A socket error was received.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 3. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 26: Capability was configured for a session.

    1. Run the display mpls ldp session command to check the session status. The value of in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap due to incorrect configurations. 3. Collect alarm information and configuration information, and then contact technical support personnel.

  • Cause 27: The configure of MPLS LDP is deleted.

    Reconfigure LDP.

  • Cause 28: The configure of MPLS LDP Remote is deleted.

    Reconfigure the mpls ldp remote-peer command.

  • Cause 30: The session protection timer expired.

    Check link connectivity.

  • Cause 31: IGP delete the RLFA IID.

    Check whether the next hop of the route is changed.

  • Cause 32: Excessive messages were received.

    1. Run the display mpls ldp session peer-id command to check the session status. The value of peer-id in the command must be consistent with the value of the PeerLdpId field in the alarm information. - If the session status is Operational, go to Step 2. - If the session status is not Operational, go to Step 3. 2. If the LDP session is already re-established, the session may flap. In this case, services may have been interrupted. For further analysis based on the log information, go to Step 3. 3. Collect alarm information and configuration information, and then contact technical support personnel.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
Next topic >