No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Log Reference

CloudEngine 8800, 7800, 6800, and 5800 V200R005C00

This document provides the explanations, causes, and recommended actions of logs on the product.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
LDP/1/mplsLdpSessionDown_active

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

The LDP session went Down or was unable to go Up.

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 an LDP peer interface

SubReason

Detailed cause for an alarm

Reason

Alarm cause

Possible Causes

Cause 0: The LDP session went Up.

Cause 1: The LDP Hello hold timer expired.

Cause 2: The LDP Keepalive timer expired.

Cause 3: The reset ldp command was configured.

Cause 4: MPLS LDP is disabled.

Cause 6: The remote MPLS LDP peer is disabled.

Cause 7: GR was configured for a session.

Cause 9: The Keepalive timer 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 25: The LDP session was deleted.

Procedure

  • Cause 0: The LDP session went Up.
    1. This alarm information is informational only, and no action is required.
  • Cause 1: The LDP Hello hold timer expired.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, the LDP session is Up. This means an intermittent interruption occurs, and some services are interrupted. In this case, go to Step 8.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Run the display mpls ldp interface command to check whether Hello messages are exchanged properly between nodes on both ends of the LDP session.

      As a Hello message is sent every 5 seconds, run this command every 3 seconds for several times. The Hello-Send/Rcv field in the command output represents statistics about sent and received Hello messages. If statistics are unchanged or changed at an interval longer than 5 seconds, Hello messages are not properly sent or received.

      • If Hello messages are not properly sent or received, check the location where this exception occurs before proceeding to the next step:
        • If the exception occurs only on the peer, go to Step 3.
        • If the exception occurs on both ends of the LDP session, go to Step 3.
        • If the exception occurs only on the local node, go to Step 5.
      • If Hello message are exchanged properly between the two ends of the LDP session but alarm persists, go to Step 4.

    3. CPU or memory usage is high. Follow the procedure for solving the high CPU or memory usage problem, and check whether this problem is solved.

      • If CPU or memory usage becomes normal, go to Step 7.
      • If the alarm persists, go to Step 8.

    4. Check whether the LDP peer configuration is correct

      • If the configuration is correct, go to Step 7.
      • If the configuration is incorrect, correct the configuration. If the alarm persists, go to Step 8.

    5. Network congestion occurs. To locate the fault, run the ping -a source-ip-address -c count host 100 command to check whether the forwarding is proper.

      • If the forwarding is proper, go to Step 7.
      • If the forwarding is not proper, go to Step 6.

    6. Follow the procedure for solving the forwarding problem, and check whether the problem is solved.

      • If the alarm is cleared, go to Step 7.
      • If the alarm persists, go to Step 8.

    7. Check whether the LDP session is Up.

      • If the LDP session is in the Operational state, the problem is solved and the alarm is cleared.
      • If the LDP session is not in the Operational state, go to Step 8.

    8. Collect the alarm information, log information, and configuration information on both ends of the LDP session, and then contact technical support personnel.
  • Cause 2: The LDP Keepalive timer expired.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, the LDP session is Up. This means an intermittent interruption occurs, and some services are interrupted. In this case, go to Step 7.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Run the display mpls ldp interface command to check whether Hello messages are exchanged properly between nodes on both ends of the LDP session.

      As a Hello message is sent every 5 seconds, run this command every 3 seconds for several times. The Hello-Send/Rcv field in the command output represents statistics about sent and received Hello messages. If statistics are unchanged or changed at an interval longer than 5 seconds, Hello messages are not properly sent or received.

      • If Hello messages are not properly sent or received, check the location where this exception occurs before proceeding to the next step:
        • If the exception occurs only on the peer, go to Step 3.
        • If the exception occurs on both ends of the LDP session, go to Step 3.
        • If the exception occurs only on the local node, go to Step 4.
      • If Hello message are exchanged properly between the two ends of the LDP session but alarm persists, go to Step 7.

    3. CPU or memory usage is high. Follow the procedure for solving the high CPU or memory usage problem, and check whether this problem is solved.

      • If CPU or memory usage becomes normal, go to Step 6.
      • If the problem persists, go to Step 7.

    4. Network congestion occurs. To locate the fault, run the ping -a source-ip-address -c count host 100 command to check whether the forwarding is proper.

      • If the forwarding is proper, go to Step 6.
      • If the forwarding is not proper, go to Step 7.

    5. Follow the procedure for solving the forwarding problem, and check whether the alarm is cleared.

      • If the alarm is cleared, go to Step 6.
      • If the alarm persists, go to Step 7.

    6. Check whether the LDP session is Up.

      • If the LDP session is in the Operational state, the problem is solved and the alarm is cleared.
      • If the LDP session is not in the Operational state, go to Step 7.

    7. Collect the alarm information, log information, and configuration information on both ends of the LDP session, and then contact technical support personnel.
  • Cause 3: The reset ldp command was configured.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state,the session goes Up again.This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Collect the alarm information, log information, and configuration information, and then contact technical support personnel.
  • Cause 4: MPLS LDP is disabled.
    1. Run the display current-configuration command. Check whether MPLS LDP is disabled globally or on an interface.

      • If MPLS LDP is disabled globally or on an interface, enable MPLS LDP globally or on an interface, and go to Step 2.
      • If MPLS LDP is not enabled, go to Step 3.

    2. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, the LDP session is Up. This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    3. Collect the alarm, log, and configuration information, and contact technical support personnel.
  • Cause 6: The remote MPLS LDP peer is disabled. The remote MPLS LDP peer is disabled.
    1. Run the display current-configuration command to check whether the MPLS LDP peer is deleted.

      • If the remote MPLS LDP peer is deleted, reconfigure the remote MPLS LDP peer, and go to Step 2.
      • If the remote MPLS LDP peer is not deleted, go to Step 3.

    2. Run the display mpls ldp session peer-id command. Check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, the LDP session is Up. This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    3. Collect the alarm, log, and configuration information, and contact technical support personnel.
  • Cause 7: GR was configured for a session.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state,the session goes Up again.This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Collect the alarm information, log 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 peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state,the session goes Up again.This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Collect the alarm information, log information, and configuration information, and then contact technical support personnel.
  • Cause 13: The transport address of a session is changed.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, go to Step 2.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 3.

    2. The LDP session is already Up. This means an intermittent interruption occurs, and some services are interrupted. For further analysis based on log information, go to Step 3.
    3. Run the display mpls ldp peer peer-id command to check whether a reachable route to the LDP transport address exists on the peer with the value of peer-id the same as the value of the PeerLsrId field in the alarm message. View the value of the TransportAddress field in the command output to obtain the transport address. Run the display ip routing-table ip-address command with the value of ip-address the same as the value of the TransportAddress field, to check whether a route to the transport address exists.

      • If the route to the transport address is reachable but the LDP session is not in the Operational state, go to Step 5.
      • If the route to the transport address does not exist, go to Step 4.

    4. The transport address is incorrect. In this case, reconfigure the transport address, and go to Step 1.
    5. Run the display tcp status command on both ends of the LDP session to check whether the TCP connection is correct. If the TCP connection is correct, the active role's TCP connection is in the Established state, and the passive role's TCP connection is also in the Established state.

      • If the TCP connection statues are correct, go to Step 6.
      • If the TCP connection statues are incorrect, go to Step 7.

    6. Check whether the LDP session is Up.

      • If the LDP session is in the Operational state, the problem is solved and the alarm is cleared.
      • If the LDP session is not in the Operational state, go to Step 7.

    7. Collect the alarm information, log 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 peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state,the session goes Up again.This is an intermittent interruption caused by an incorrect configuration. The alarm is cleared.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Collect the alarm information, log 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 peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, go to Step 2.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 3.

    2. The LDP session is already Up. This means an intermittent interruption occurs, and some services are interrupted. For further analysis based on log information, go to Step 3.
    3. Collect the alarm information, log 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 peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, the LDP session is Up. This means an intermittent interruption occurs, and some services are interrupted. In this case, go to Step 8.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 2.

    2. Run the display mpls ldp interface command to check whether Hello messages are exchanged properly between nodes on both ends of the LDP session.

      As a Hello message is sent every 5 seconds, run this command every 3 seconds for several times. The Hello Send/Rcv field in the command output represents statistics about sent and received Hello messages. If statistics are unchanged or changed at an interval longer than 5 seconds, Hello messages are not properly sent or received.

      • If Hello messages are not properly sent or received, check the location where this exception occurs before proceeding to the next step:
        • If the exception occurs only on the peer, go to Step 3.
        • If the exception occurs on both ends of the LDP session, go to Step 3.
        • If the exception occurs only on the local node, go to Step 5.
      • If Hello message are exchanged properly between the two ends of the LDP session but alarm persists, go to Step 4.

    3. CPU or memory usage is high. Follow the procedure for solving the high CPU or memory usage problem, and check whether the problem is solved.

      • If CPU or memory usage becomes normal, go to Step 7.
      • If the problem persists, go to Step 8.

    4. The peer configuration has been changed. In this case, check whether the LDP peer configuration is correct.

      • If the configuration is correct, go to Step 7.
      • If the configuration is incorrect, correct the configuration. If the problem persists, go to Step 8.

    5. Network congestion occurs. To locate the fault, run the ping -a source-ip-address -c count host 100 command to check whether the forwarding is proper.

      • If the forwarding is proper, go to Step 7.
      • If the forwarding is not proper, go to Step 8.

    6. Follow the procedure for solving the problem of a forwarding failure, and check whether the problem is solved.

      • If the problem is solved, go to Step 7.
      • If the problem persists, go to Step 8.

    7. Check whether the LDP session is Up.

      • If the LDP session is in the Operational state, the problem is solved and the alarm is cleared.
      • If the LDP session is not in the Operational state, go to Step 8.

    8. Collect the alarm information, log information, and configuration information on both ends of the LDP session, and then contact technical support personnel.
  • Cause 23: An error message was received from a peer.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, go to Step 2.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 3.

    2. The LDP session is already Up. This means an intermittent interruption occurs, and some services are interrupted. For further analysis based on log information, go to Step 3.
    3. Collect the alarm information, log information, and configuration information, and then contact technical support personnel.
  • Cause 24: A socket error was received.
    1. Run the display mpls ldp session peer-id command to check whether the LDP session is proper. Ensure that the value of peer-id is the same as that of the PeerLsrId field in the alarm message.

      • If the LDP session status is in the Operational state, go to Step 2.
      • If no information is displayed or the LDP session is not in the Operational state, go to Step 3.

    2. The LDP session is already Up. This means an intermittent interruption occurs, and some services are interrupted. For further analysis based on log information, go to Step 3.
    3. Collect the alarm information, log information, and configuration information, and then contact technical support personnel.
  • Cause 25: The LDP session was deleted.
    1. Check whether an LDP-associated undo command is run.
    2. Collect the alarm information, log information, and configuration information, and then contact technical support personnel.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100039602

Views: 121822

Downloads: 90

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next