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

ME60 Troubleshooting Guide V1.0 (VRPv8)

This document provides the maintenance guide of the device, including daily maintenance, emergence maintenance, and typical troubleshooting.
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).
MPLS LDP Troubleshooting

MPLS LDP Troubleshooting

This chapter describes common causes of MPLS LDP faults and provides troubleshooting flowcharts and procedures, alarms, and logs to help identify and rectify these faults.

An LDP Session Flaps

This section describes how to troubleshoot LDP session flapping.

Common Causes

This section describes the common causes of LDP session flapping.

Common causes are as follows:

  • The LDP GR timer value is set, changed, or deleted.

  • The LDP Keepalive timer value is set, changed, or deleted.

  • A transport address is added, changed, or deleted.

  • Interfaces are flapping.

  • Routes are flapping.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for LDP session flapping.

The troubleshooting roadmap is as follows:
  • Check that LDP GR, a Keepalive timer, or a transport address is configured.

  • Check that the interface is alternating between Down and Up.

  • Check that the routes are alternating between unreachable and reachable.

Figure 4-77 shows the troubleshooting flowchart.

Figure 4-77 Flowchart for troubleshooting LDP session flapping

Troubleshooting Procedure

This section describes the procedure for troubleshooting LDP session flapping.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that LDP GR, a Keepalive timer, or a transport address is changed.
    1. Run the display this command in the LDP view to check whether the LDP GR configuration is changed.

      If the following information is displayed, LDP GR is configured.
      mpls ldp
      graceful-restart
      

    2. Run the display this command in the interface view to check whether an LDP Keepalive timer or an LDP transport address is configured.

      • If the command output displays the following information, the LDP Keepalive timer is set. The timer value (for example, 30 seconds) depends on the actual situation.
        mpls ldp
        mpls ldp timer keepalive-hold 30
        
      • If the command output displays the following information, the LDP transport address is set. The transport address and the type and number of the interface can be set as needed.
        mpls ldp
        mpls ldp transport-address interface 
        

    • If one of these configurations has been performed, wait 10 seconds and then check whether the LDP session is flapping.

    • If no configuration is performed, go to Step 2.

  2. Check that the interface is alternating between Down and Up.

    Run the display ip interface brief command to view the Physical and Protocol fields in the command output. If both fields display Up, the interface is Up. If one field displays Down, the interface is Down. If the interface regularly alternates between Down and Up, the interface is flapping.

    • If the interface alternates between Down and Up, see the section "Interface Flapping" for help.

    • If the interface remains Up or Down, go to Step 3.

  3. Check that the routes are alternating between unreachable and reachable.

    Run the display ip routing-table command quickly to check route information. If routes exist, route information is displayed. If routes do not exist, no route information is displayed. If route information alternates between being displayed and not being displayed, the routes are alternating between unreachable and reachable.

    • If routes are alternating between unreachable and reachable or no route exists, see The Ping Operation Fails for help.

    • If the routes are always reachable, go to Step 4.

  4. contact technical support personnel:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

This section describes relevant alarms and logs for LDP session flapping.

An LDP Session Goes Down

This section describes how to troubleshoot an LDP session that goes Down.

Common Causes

This section describes the common causes of an LDP session that goes Down.

Common causes are as follows:

  • The interface on which the LDP session is established is shut down.

  • The undo mpls, undo mpls ldp, or undo mpls ldp remote peer command has been run.

  • No route exists.

  • An LDP Keepalive timer has expired.

  • An LDP Hello-hold timer has expired.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for an LDP session that goes Down.

The troubleshooting roadmap is as follows:
  • Check that the interface on which the LDP session is established is shut down.

  • Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer command has been run.

  • Check that the routes exist.

  • Check that an LDP Hello-hold timer has expired.

  • Check that an LDP Keepalive-hold timer has expired.

Figure 4-78 shows the troubleshooting flowchart.

Figure 4-78 Flowchart for troubleshooting an LDP session that goes Down

Troubleshooting Procedure

This section describes the procedure for troubleshooting an LDP session that goes Down.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that the interface on which the LDP session is established is shut down.

    Run the display this command in the interface view. If the command output shows the following command, the interface is shut down.

    shutdown

    • If the interface is shut down, run the undo shutdown command to restart the interface.

    • If the interface is Up, go to Step 2.

  2. Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote-peer command has been run.

    Run the display current-configuration command.

    • If the mpls command is not displayed, MPLS is disabled. Run this command to enable MPLS.

    • If the mpls ldp command is not displayed, MPLS LDP is disabled. Run this command to enable MPLS LDP.

    • If the mpls ldp remote-peer command is not displayed, the remote LDP session is deleted. Run this command to configure a remote LDP peer.

    • If an MPLS-associated configuration is deleted, perform the configuration again.

    • If no MPLS-associated configuration is performed, go to Step 3.

  3. Check that the routes exist.

    Run the display ip routing-table command to view the Destination/Mask field and then check whether the route to the peer exists. Lack of routes to the peer causes TCP connection failures.

    • If no route exists, see the section The Ping Operation Fails for help.

    • If the route to the peer is reachable, go to Step 4.

  4. Check that an LDP Hello-hold timer has expired.

    Run the display mpls ldp interface command every 3 seconds and check whether both ends of the LDP session can send Hello messages. If the statistics do not change, the transmission of Hello messages becomes abnormal, and the Hello-hold timer expires.

    • If the Hello-hold timer has expired, see the section "High CPU Usage" for help.

    • If the Hello-hold timer has not expired, go to Step 5.

  5. Check that an LDP Keepalive-hold timer has expired.

    Run the display mpls ldp session command to check whether Keepalive messages can be sent on both ends of the LDP session every 5 seconds. If the statistics do not change, the transmission of Keepalive messages becomes abnormal, and the Keepalive-hold timer expires.

    • If the Keepalive-hold timer has expired, see the section The Ping Operation Fails for help.

    • If the Keepalive-hold timer has not expired, go to Step 6.

  6. Please collect the following information and contact technical support personnel.

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

This section describes relevant alarms and logs for an LDP session that goes Down.

An LDP LSP Flaps

This section describes how to troubleshoot LDP LSP flapping.

Common Causes

This section describes the common causes of LDP LSP flapping.

Common causes are as follows:

  • The route between LSP peers is flapping.

  • The LDP session is flapping.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for LDP LSP flapping.

The troubleshooting roadmap is as follows:
  • Check that the routes are alternating between unreachable and reachable.

  • Check that the LDP session is flapping.

Figure 4-79 shows the troubleshooting flowchart.

Figure 4-79 Flowchart for troubleshooting LDP LSP flapping

Troubleshooting Procedure

This section describes the procedure of troubleshooting LDP LSP flapping.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that the routes are alternating between unreachable and reachable.

    Run the display ip routing-table command to check information about the routes to the destination of the LSP. Huawei recommends that you run this command every second. If routes exist, route information is displayed. If no routes exist, no route information is displayed. If route information is intermittently displayed after the command has run several times, the routes are alternating between unreachable and reachable.

    • If routes are alternating between unreachable and reachable or no route exists, see the section "The Ping Operation Fails" for more information on rectifying the IGP route fault.

    • If the routes are always reachable, go to Step 2.

  2. Check that the LDP session is flapping.

    Run the display mpls ldp session command to check the Status field. Huawei recommends that you run this command every second. If the status switches between Operational and another state, the LDP session is flapping.

    • If the LDP session is flapping, see the section "LDP Session Flapping" for help.

    • If the LDP session is not flapping, go to Step 3.

  3. contact technical support personnel:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

This section describes relevant alarms and logs for LDP LSP flapping.

An LDP LSP Goes Down

This section describes how to troubleshoot an LDP LSP that goes Down.

Common Causes

This section describes the common causes of an LDP LSP that goes Dow.

Common causes are as follows:

  • The routes become unreachable.

  • The LDP session goes Down.

  • Resources are insufficient. Specifically, the number of labels has reached the upper limit, or memory is insufficient.

  • The policy for establishing an LSP is configured.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for an LDP LSP that goes Down.

The troubleshooting roadmap is as follows:
  • Check that the routes exist.

  • Check that the LDP session is established.

  • Check that the resources are insufficient. Specifically, check whether the number of labels has reached the upper limit, or memory is insufficient.

  • Check that a policy for establishing LSPs is configured.

Figure 4-80 shows the troubleshooting flowchart.

Figure 4-80 Flowchart for troubleshooting an LDP LSP that goes Down

Troubleshooting Procedure

This section describes the procedure of troubleshooting an LDP LSP that goes Down.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that routes exist.

    Run the display ip routing-table ip-address mask-length verbose command to check information about the route to the LSP destination.

    ip-address mask-length specifies the LSP destination address.

    If route information is displayed and the value of the State field is Active Adv in the command output, such a route exists and is active. If the route is a public network BGP route, check the Label field in the command output. If non-NULL is displayed, the route information carries a label.

    • If routes do not exist, the routes are inactive. Or, if the BGP routes do not carry labels, see the section The Ping Operation Fails for help.

    • If routes exist and are active, and if the routes are BGP routes that carry labels, go to Step 2.

  2. Check that the LDP session is established.

    Run the display mpls ldp session command to check the Status field. If Operational is displayed, the LDP session is established and goes Up. If another state, not Operational, is displayed, the LDP session is in the Initialized state.

    • If the LDP session is established abnormally, see the section LDP Session Goes Down for help.

    • If the LDP session is not flapping, go to Step 3.

  3. Check that the resources are sufficient. The problem occurs if labels are used up, or memory is insufficient.

    Perform the following steps:

    1. Check that the system memory is sufficient.

      Run the display memory-usage command to check whether the system memory is sufficient. If it is insufficient, delete unwanted LSPs.

    2. Check that the number of LSPs exceeds the upper limit.

      Run the display mpls ldp lsp statistics command to check whether the number of LSPs exceeds the upper limit. If the number exceeds the upper limit, delete unwanted LSPs.

    If the resources are sufficient, go to Step 4.

  4. Check that a policy for establishing LSPs is configured.

    • Run the display this command in the MPLS view. If the command output shows the following command, an IP-prefix-based policy for triggering the establishment of LSPs is configured. Check whether some LSPs are not included in the IP-prefix-based policy. The policy name (abc) can be set as needed.
      lsp-trigger ip-prefix abc
    • Run the display this command in the MPLS LDP view. If the command output shows the following command, an IP-prefix-based policy for triggering the establishment of LSPs is configured. Check whether some LSPs are not included in the IP-prefix-based policy. The policy name (abc) can be set as needed.
      propagate mapping for ip-prefix abc
    • Run the display ip ip-prefix command in the system view. If the command output shows the following information, only routes to 1.1.1.1/32 and 2.2.2.2/32 are allowed to trigger the establishment of LSPs. The IP addresses (1.1.1.1/32 and 2.2.2.2/32) can be configured as needed.
             index: 10               permit  1.1.1.1/32
             index: 20               permit  2.2.2.2/32 

    • If one of these policies is configured, add routing information about the desired LSP to the policy.

    • If no policy is configured, go to Step 5.

  5. contact technical support personnel:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

This section describes relevant alarms and logs for an LDP LSP that goes Down.

Trouble Cases

This section describes fault symptoms, fault isolation, and troubleshooting procedure for common MPLS LDP-related fault cases.

An LDP Session Fails to Be Established

This section describes how to troubleshoot a failure to establish an LDP session.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Fault Symptom

As shown in Figure 4-81, the LDP function is enabled on directly connected interfaces between Router A and Router B.

Figure 4-81 Establishing an LDP session
NOTE:

In this example, the interface1 is GE1/0/0.



Router A cannot establish an LDP session with its peer.

Fault Analysis

LDP session establishment undergoes two phases:

  • Two devices establish a TCP connection.

  • One device initiates a session and negotiates session parameters with the other device.

A fault in either of the two phases causes a failure to establish an LDP session.

An LSR ID, a default address, is used to establish a TCP connection. Therefore, the LSR ID route must be advertised to the peer.

After the LDP session is established, the local device and its peer cannot communicate on the network layer due to network congestion or the fault. If no LDP PDU packet is received before the session hold timer has expired, the LDP session goes down.

Procedure

  1. Run the display ip routing-table command to check whether the node obtains the route destined for the peer LSR ID. If the node does not obtain the route, configure one.
  2. Run the display this command on the interfaces that connect LSRs on both ends of the session to check whether the label advertisement modes of the interfaces are the same. If the two interfaces use different mode, change the label advertisement mode on one end the same as that on the other end.
Summary

An LDP session can be created if the following conditions are met:

  • The route associated with a local LSR ID is correctly advertised to the peer.

  • The interfaces that connect the LSRs on both ends of the session use the same label advertisement mode.

An LDP Session Cannot Be Established Between PEs

This section describes how to troubleshoot a failure to establish an LDP session between PEs.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Fault Symptom

MPLS is deployed on the network shown in Figure 4-82. With this configuration, an LDP session cannot be established between PE1 and PE2.

Figure 4-82 Networking in which an LDP session cannot be established between PEs

Fault Analysis
  1. Run the display ip routing-table command on PE1. No route to the peer is displayed.

  2. Run the display this command and check OSPF configurations on PE2.

    ospf 1                                                                          
     import-route static                                                            
     area 0.0.0.10                                                                  
      network 1.2.1.1 0.0.0.3                                                  
      network 3.3.3.3 0.0.0.0                                                       
      network 1.1.1.2 0.0.0.0                                               
      nssa
    

    The preceding command output shows that the OSPF route to Loopback1 is incorrect. As a result, the TCP connection between the two Loopback1 interfaces on PE1 and PE2 is unreachable.

Procedure

  1. Run the system-view command to enter the system view.
  2. Run the ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] * command to enter the OSPF view.
  3. Run the area area-id command to enter the OSPF area view.
  4. Run the network 1.1.1.1 0.0.0.0 command to configure a correct route. After these configurations are performed, an LDP session is established between PE1 and PE2. The fault is rectified.
Summary

The default LSR ID of an LDP instance is an MPLS LSR ID configured using the mpls lsr-id command. An LDP instance uses the MPLS LSR ID if no LDP LSR ID is set. If an LDP LSR ID is set, it is used to establish an LDP session. In this case, the route to the LSR ID must be advertised. An incorrect route advertisement causes this problem. To resolve this problem, re-configure routes.

An MPLS LDP Peer Relationship Cannot Be Established

This section describes how to troubleshoot a failure to establish an MPLS LDP peer relationship.

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Fault Symptom

On the network shown in Figure 4-83, MPLS is configured on a router and an MA5200G, but an MPLS LDP peer relationship cannot be established between the two devices.

Figure 4-83 Networking in which an MPLS LDP peer relationship cannot be established
NOTE:

Interfaces 1 in this example is GE 1/0/0.



Fault Analysis
  1. Run the display this command on GE 1/0/0 to check its configuration. The command output shows that traffic-policy ma5200g inbound is configured on the interface. Analysis on this traffic policy shows that the last rule is configured to reject multicast packets from 224.0.0.2.

     rule 10 permit ip destination 224.0.0.5 0
     rule 20 permit ip destination 224.0.0.6 0
     rule 30 deny ip destination 224.0.0.0 31.255.255.255
    

    Based on the LDP peer relationship establishment mechanism, an LDP session is triggered by multicast packets sent by 224.0.0.2. Therefore, an MPLS LDP peer relationship fails to be established because the last rule in the traffic policy rejects multicast packets from 224.0.0.2.

Procedure

  1. Run the system-view command to enter the system view.
  2. Run the acl number acl-number command to enter the ACL view.
  3. Run the rule 25 permit ip destination 224.0.0.2 0 command to allow multicast packets from 224.0.0.2 to pass. After the configuration is complete, an MPLS LDP peer relationship is established. The fault is rectified.
Summary

When configuring a traffic policy on an interface, check the control of multicast packets to prevent multicast protocol packets from being rejected.

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 12295

Downloads: 247

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