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 TE Troubleshooting

MPLS TE Troubleshooting

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

A TE Tunnel Goes Down

This section describes how to troubleshoot a TE tunnel that goes Down.

Common Causes

This section describes common causes for a TE tunnel that goes Down.

Common causes are as follows:

  • The commit command is not configured to commit the TE tunnel configuration.

  • CSPF fails to calculate a path.

  • RSVP is not enabled on a device along the TE tunnel.

  • Devices fail to exchange RSVP Path or Resv messages along the TE tunnel.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for the fault that causes a TE tunnel to go Down.

After a TE tunnel is configured, the TE tunnel is Down.

The troubleshooting roadmap is as follows:
  • Check whether the commit command is configured to commit the TE tunnel configuration.

  • Check whether CSPF successfully calculates a path.

  • Check whether RSVP is enabled on every device along the TE tunnel.

  • Check whether devices along the TE tunnel successfully exchange messages.

Figure 4-84 shows the troubleshooting flowchart.

Figure 4-84 Troubleshooting the fault that causes a TE tunnel to go Down

Troubleshooting Procedure

This section describes the procedure for troubleshooting a TE tunnel 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 no tunnel settings are missing.

    Run the display current-configuration command on a node on which a tunnel is configured. Check whether the commands in the configuration file match the command instances in the following example.

    interface Tunnel1
     tunnel-protocol mpls te
     destination 4.4.4.9
     mpls te tunnel-id 1
    

    • If one of the command instances in the following example does not appear in the configuration file, a tunnel setting is missing. Run the related command and then the commit command to make the setting take effect.

    • If they match, no tunnel settings are missing. Go to Step 2.

  2. Check that CSPF has been successful in calculating paths.

    Run the display mpls te cspf destination ip-address [ explicit-path path-name ] command on the ingress of the TE tunnel. If information is displayed, CSPF has been successful in calculating paths. If no information is displayed, CSPF fails to calculate a path.

    • If CSPF fails to calculate a path, check whether routes to the destination of the TE tunnel exist.
      • If such routes do not exist, rectify the fault by following the procedure in the section The Ping Operation Fails.

      • If such routes exist and meet the constraints, run the display explicit-path command or observe the network topology to check the interfaces that the LSP passes. Then, run the display this command on each of the interfaces to check whether the interface has MPLS, MPLS TE, and RSVP-TE enabled.
        • If they are not enabled, run the mpls, mpls te, and mpls rsvp-te commands to enable them.
        • If any interface is not Up, restart the interface by running the shutdown and undo shutdown commands in sequence, or by running the restart command.
    • If CSPF has been successful in calculating paths but the fault persists, go to Step 3.

  3. Check that devices along the TE tunnel have been successful in exchanging RSVP Path and Resv messages.

    Run the display mpls te tunnel-interface command on the ingress of the TE tunnel to view fields Ingress LSR ID, Primary LSP ID, and Session ID in the command output. In Step 3, LSRA, LSRB, and LSRC are identified along the TE tunnel.

    Perform the following steps to check whether RSVP Path and RSVP Resv messages are correctly transmitted:
    • Check that RSVP Path messages are correctly sent and received on every node along the LSP on the path LSRA -> LSRB -> LSRC.

      Run the display mpls rsvp-te psb-content command on every node RSVP Resv messages travel.

      • If the command output is not empty on any node, RSVP Path messages are correctly sent and received between these nodes, and go to Step 4.

      • If the command output is empty on a node, the node fails to receive RSVP Path messages from the upstream node, rectify the fault by following the procedure in the section The Ping Operation Fails.

    • Check that RSVP Resv messages are correctly transmitted on the path LSRC -> LSRB -> LSRA.

      Run the display mpls rsvp-te rsb-content command on every node RSVP Resv messages travel.

      • If the command output is not empty on any node, RSVP Resv messages are correctly transmitted.

      • If the command output is empty on a node, the node fails to receive RSVP Resv messages from the upstream node, go to Step 4.

  4. contact technical support personnel.

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

Relevant Alarms and Logs

This section describes relevant alarms and logs for a TE tunnel that goes Down.

Relevant Alarms

None

Relevant Logs

None

A TE Tunnel Suddenly Goes Down

This section describes how to troubleshoot a TE tunnel that suddenly goes Down.

Common Causes

This section describes common causes for a TE tunnel that suddenly goes Down.

Common causes are as follows:

  • The configuration associated with the TE tunnel is deleted manually.

  • A physical interface on the TE tunnel goes Down.

  • RSVP message transmission times out.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for a TE tunnel that suddenly goes Down.

The troubleshooting roadmap is as follows:
  • Check that a command has been running to delete TE tunnel configurations, such as MPLS or RSVP-TE configuration.

  • Check that a physical interface on the TE tunnel goes Down.

  • Check that the transmission time of an RSVP message has expired.

Figure 4-85 shows the troubleshooting flowchart.

Figure 4-85 Flowchart for troubleshooting a TE tunnel that suddenly goes Down

Troubleshooting Procedure

This section describes the procedure for troubleshooting a TE tunnel that suddenly 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 a command has been run to delete the configuration associated with the TE tunnel.

    Run the display this command on the ingress of the TE tunnel and check whether either of the following commands is configured:

    • shutdown
    • undo interface Tunnel tunnel-number

    • If either of these commands is configured, restore the deleted configurations.

    • If neither of these commands is configured but the fault persists, go to Step 2.

  2. Check that any physical interface along the TE tunnel goes Down.

    1. Run the display mpls te cspf destination ip-address [ explicit-path path-name ] command on the ingress of the tunnel. The command output contains a series of IP addresses, which identify the nodes along the TE tunnel.

    2. View the alarms generated on each node along the TE tunnel. Check whether an active/linkDown alarm exists and record the time T1. Run the display interface interface-type interface-number command to view the Last line protocol up time field and record the time T2.

    • If T1 is greater than T2, the TE tunnel has gone Down because the physical interface on the TE tunnel is faulty. In this case, see the section "Physical Interface Is Faulty" for more information on rectifying the fault.

    • If T1 is less than T2, go to Step 3.

  3. Check that RSVP message transmission times out.

    Check the P2PTE/2/mplsTunnelDown log on the ingress. Confirm the time (T1) when the tunnel goes Down. Run the display mpls rsvp-te last-error command on every node along the tunnel confirmed in Step 2 and check last-error information. Check whether the following information is recorded 10 minutes before T1:
    • PATH TIME OUT

    • RESV TIME OUT

    • If either of these logs is displayed, see the section "The Ping Operation Fails" for more information on rectifying the fault.

    • If neither of these logs is displayed, go to Step 4.

  4. contact technical support personnel:

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

Relevant Alarms and Logs

This section describes relevant alarms and logs for a TE tunnel that goes Down.

Relevant Alarms

None

Relevant Logs

P2PTE/2/mplsTunnelDown

A Loop Occurs on a TE Tunnel

This section describes how to troubleshoot a loop on a TE tunnel.

Common Causes

This section describes common causes for a loop on a TE tunnel.

Common causes are as follows:

  • A loop has occurred on the link along which an RSVP Path message travels.

  • A loop has occurred on the link along which an RSVP Resv message travels.

Troubleshooting Flowchart

This section describes the troubleshooting flowchart for a loop on a TE tunnel.

The troubleshooting roadmap is as follows:
  • Check that a loop has occurred on the link along which an RSVP Path message travels.

  • Check that a loop has occurred on the link along which an RSVP Resv message travels.

Figure 4-86 shows the troubleshooting flowchart.

Figure 4-86 Flowchart for troubleshooting a loop on a TE tunnel

Troubleshooting Procedure

This section describes the procedure for troubleshooting a loop on a TE tunnel.

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 a loop has occurred on the link along which the RSVP Path messages travel.

    Run the display mpls rsvp-te last-error command on the RSVP-enabled node. If path loop information is displayed, a loop occurs.

    Run the display mpls te cspf destination ip-address explicit-path path-name command. The command output contains a series of IP addresses. An IP address and LSR ID uniquely identify a node along the TE tunnel.

    Run the tracert ip-address command on the node on which the message indicating a loop for Path messages is displayed. Set ip-address to the IP address of each hop on the tunnel. If the following information is displayed, the address specified by ip-address is in conflict.
    Error: The destination address cannot be a local address.

    On the node sending the Path message containing a conflicting address, run the tracert ip-address command to trace the path to each node address. The ip-address value is the IP address of each node on the LSP.

    • If an IP address collision has occurred, delete or change the IP address of the node.

    • If no IP address collision has occurred but the fault persists, go to Step 2.

  2. Check that a loop has occurred on the link along which the RSVP Resv messages travel.

    Run the display mpls rsvp-te last-error command on the node enabled with RSVP. If RESV LOOP information is displayed, the Path messages are sent in a loop.

    The troubleshooting operations are the same as those in Step 1.

    • If an IP address collision has occurred, delete or change the IP address.

    • If no IP address collision has occurred but the fault persists, go to Step 3.

  3. contact technical support personnel:

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

Relevant Alarms and Logs

This section describes relevant alarms and logs for a loop on a TE tunnel.

Relevant Alarms

None

Relevant Logs

P2PTE/4/LSP_ERR

Trouble Cases

A Loop Occurs Because the IP Address of a Shut-Down Interface Is Not Deleted on an RSVP-TE Tunnel

This section describes how to troubleshoot a loop resulted from an undeleted IP address of an interface that has been shut down on an RSVP-TE tunnel.

NOTE:

After the commands are configured to troubleshoot the faults, check the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to immediate validation mode.

  • In immediate validation mode, the configurations take effect after the commands are entered.
  • In two-phase validation mode, after the commands are configured, the commit command needs to be run to commit the configurations.

Save the results of each troubleshooting step so that if your troubleshooting attempts fail to correct the fault, you will have a record of your actions to present to Huawei.

Fault Symptom

On the network shown in Figure 4-87, RSVP-TE is enabled, and bidirectional RSVP-TE tunnels are established between LSRA and LSRD using loopback addresses as tunnel destination addresses. The tunnel from LSRD to LSRA is established, but the tunnel from LSRA to LSRD fails to be established.

Figure 4-87 Networking of a loop resulted from an undeleted IP address of an interface that has been shut down on an RSVP-TE tunnel
NOTE:

Interfaces 1 through 2 in this example are GE 1/0/0, GE 1/0/1, respectively.



Fault Analysis
  1. Run the display mpls te tunnel command on LSRA. The command output shows that only one tunnel is established.
    <LSRA> display mpls te tunnel
    LSP-Id                    Destination            In/Out-If
    10.1.1.2:8:29               10.1.1.1             GE1/0/0/-
    
  2. Run the display mpls rsvp-te last-error command on LSRD. The PATH LOOP information is displayed, indicating a loop on LSRD.

  3. Run the display current-configuration interface tunnel 1 command on LSRA to check tunnel configurations. The mpls te record-route command is run for the tunnel (from LSRA to LSRD) that fails to be established.

  4. Run the undo mpls te record-route command on LSRA. The tunnel from LSRA to LSRD is then established.

    However, if you enable MPLS TE FRR, the route record function is automatically enabled. When this is the case, the fault recurs, which indicates that the cause has not been located.

  5. Run the tracert -a 10.1.1.1 10.1.1.2 command on LSRD. No loop occurs.

  6. Run the display current-configuration command on LSRD to check tunnel configurations. An interface on LSRD is shut down, and its IP address, which is not deleted, is the same as that of GE1/0/0 on LSRB, preventing the tunnel from LSRA to LSRD from being established.
    interface GigabitEthernet1/0/1
    shutdown
     ip address 192.168.30.1 255.255.255.252
    #
    

    To establish the tunnel from LSRA to LSRD, LSRA sends an RSVP Path message to LSRD. The RSVP Path message passes through each device along the LSRA-to-LSRD path. In addition, the route record function enabled using the mpls te record-route command adds the IP address of each hop along the path to the RSVP Path message. After receiving the RSVP Path message, LSRD detects that the address 192.168.30.1 added to the message is the same as the IP address of its interface. Although the LSRD interface with the IP address 192.168.30.1 is shut down, its address is not deleted, resulting in two identical addresses. In this case, LSRD determines that a loop has occurred and sends the alarm and rejects the request for resources.

Procedure

  1. Run the system-view command to enter the system view on LSRD.
  2. Run the interface gigabitethernet1/0/1 command to enter the view of GE 1/0/1.
  3. Run the undo ip address 192.168.30.1 255.255.255.252 command to delete the IP address of GE 1/0/1.

    After these operations are performed, run the display mpls te tunnel command on LSRA. The tunnel from LSRA to LSRD is established. The fault is rectified.
    <LSRA> display mpls te tunnel
    LSP-Id                    Destination            In/Out-If
    10.1.1.2:8:29               10.1.1.1             GE1/0/0/-
    10.1.1.1:1:64               10.1.1.2             -/GE1/0/0
    

Summary

Delete the configurations of interfaces that are no longer used in order to prevent unpredictable errors.

A Tunnel Suddenly Goes Down and Then Up

This section describes how to troubleshoot the fault that tunnel goes Down suddenly and then Up.

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-88, an RSVP-TE tunnel is established from LSRA (ingress) to LSRC (egress). After the RSVP-TE tunnel is Up, it suddenly goes Down and then Up again.

Figure 4-88 MPLS TE network
NOTE:

Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.



Fault Analysis
  1. Run the display current-configuration interface tunnel tunnel-number command on LSRA to check the configuration of the RSVP-TE tunnel and its explicit path. Alternatively, run the display mpls te tunnel path tunnel-name command to check the path of the RSVP-TE tunnel.

  2. Query alarm information on LSRA (the ingress) to check the time T when the tunnel went Down.

  3. Check whether the physical link of the RSVP-TE tunnel is faulty at the time T using the following methods.

    • View the alarms on each device along the RSVP-TE tunnel to check whether the following information is displayed:

      active/linkDown/Major/occurredTime:2010-11-25 14:24:10/-/-/alarmID:0x08520003/VS=0:The interface status changes. (ifName=GE1/0/0, AdminStatus=DOWN, OperStatus=DOWN, Reason=The interface is shut down.)

      Check whether the time when the physical outbound interface along the RSVP-TE tunnel went Down is the same as the time when the tunnel interface went Down. If the two events happened at the same time, the physical outbound interface is faulty, which caused the RSVP-TE tunnel to go Down.

    • Run the display interface interface-type interface-number command on each device along the RSVP-TE tunnel. The command output shows the status of the interface along the physical link.

      <LSRA> display interface gigabitethernet 1/0/0
      GigabitEthernet1/0/0 current state : UP (ifindex: 5)  
      Line protocol current state : UP 
      Last line protocol up time : 2013-01-21 10:48:32
      Description: 
      Route Port,The Maximum Transmit Unit is 1500
      Internet Address is 10.1.1.1/24

      In the command output, the time displayed in the Last line protocol up time field is later than the time T when the RSVP-TE tunnel went Down. This means that the physical interface was faulty before the time T, which caused the RSVP-TE tunnel to go Down.

Procedure

  1. The RSVP-TE tunnel is restored, and no action is required.

Summary

On a live network, a tunnel goes Down because a specific physical interface goes Down. You can view the alarms or run the display interface interface-type interface-number command to check the status of each physical interface to locate the physical interface that goes Down.

Route Loops

This section describes how to troubleshoot route loops.

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

In Figure 4-89, an RSVP-TE tunnel between LSRA (ingress) and LSRC (egress) is established. The interface status of the RSVP-TE tunnel cannot go Up.

Figure 4-89 MPLS TE network
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.



Fault Analysis
  1. Run the display current-configuration interface tunnel tunnel-number command on LSRA to view the tunnel configuration. Then, run the display current-configuration command hop by hop to check the MPLS, MPLS TE, and RSVP-TE configurations. The command output shows that the configurations are correct.

  2. Run the display mpls te cspf destination ip-address explicit-path path-name command on LSRA. If information is displayed, CSPF has calculated the paths. If no information is displayed, CSPF has failed to calculate any paths.

  3. Run the display mpls te tunnel-interface last-error command on LSRA, LSRB, and LSRC. The PATH LOOP information is displayed on LSRC, indicating that a loop is detected on LSRC using Path messages.

Procedure

  1. Run the display current-configuration interface tunnel tunnel-number command on LSRA to view the tunnel configuration. The command output shows information about the configured explicit path and routes, which identify the path of the RSVP-TE tunnel. The following example contains information about the path of the RSVP-TE tunnel.

    Hop1:10.1.1.1
    Hop2:10.1.1.2
    Hop3:2.2.2.2
    Hop4:10.2.1.1
    Hop5:10.2.1.2
    Hop6:3.3.3.3
    

  2. Run the tracert ip-address command on LSRC to trace information about routes to hops 1 to 4 and analyze the command output to locate the node with the same IP address as LSRC. There is no need to trace information about routes to hops 5 and 6 because LSRC is at hops 5 and 6.
  3. Run the display ip interface brief command on LSRC to search for 10.1.1.2 and delete it.

    Then run the display interface tunnel tunnel-number command. If the tunnel interface goes Up, the fault is rectified.

Summary

If a loop causes a tunnel setup failure, run the display mpls te tunnel-interface last-error command to view error information and identify the device on which the loop has occurred. Run the tracert ip-address command on the device to find the conflicting IP address.

Inter-OSPF Area TE Tunnels Fail to Be Set Up

This section describes how to troubleshoot a failure to establish an inter-OSPF area TE tunnel.

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-90, LSRA and LSRB are in Area0, and LSRC and LSRD are in Area1. An RSVP-TE tunnel is established along the path LSRA -> LSRB -> LSRC -> LSRD. The RSVP-TE tunnel fails to be established.

Figure 4-90 Networking of an inter-OSPF area MPLS TE tunnel
NOTE:

Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.



Fault Analysis
  1. Run the display current-configuration interface tunnel tunnel-number command on LSRA to view the tunnel configuration. Then, run the display current-configuration command hop by hop to view the MPLS, MPLS TE, and RSVP-TE configurations. The command output shows that the configurations are correct.
  2. Run the display current-configuration interface tunnel tunnel-number command on LSRA to view the tunnel configuration. The command output shows that an explicit path is established on the tunnel interface.
    <LSRA> display current-configuration interface Tunnel 10
    #
    Interface Tunnel10
     ip address unnumbered interface Loopback0
     tunnel-protocol mpls te
     destination 4.4.4.4
     mpls te tunnel-id 100
     mpls te record-route label
     mpls te path explicit-path path1
    #
    return
  3. Run the display explicit-path path-name command to view explicit path information.
    <LSRA> display explicit-path path1
    Path Name : path1                          Path Status : Enabled
     1        10.1.2.2                             Strict        Include
  4. Run the display mpls te cspf tedb command on LSRA to view CSPF TEDB. The command output shows information about the CSPF TEDBs of only LSRA and LSRB.
    <LSRA> display mpls te cspf tedb all
    Maximum Node Supported: 128                    Maximum Link Support: 256
    Current Total Node Number: 2                   Current Total Link Number: 2
    ID      Router-ID          IGP          Process-ID      Area               Link-Count
    1       1.1.1.1             OSPF         1                 0                  1
    2       2.2.2.2             OSPF         1                 0                  1
  5. Run the display mpls te cspf destination dest-ip-address explicit-path path-name command on LSRA to view CSPF calculation results. The command output shows that the calculated path is incomplete, which may be the result of an incomplete explicit path.
    <LSRA> display mpls te cspf destination 4.4.4.4 explicit-path path1
    Path for the given constraints is:
    1.1.1.1                           LSR-ID
    10.1.2.1
    10.1.2.2
    The computation to egress is not finished.
    The total metrics for the given path is :            1

Procedure

  1. Run the system-view command to enter the system view.
  2. Run the interface tunnel tunnel-number command to enter the tunnel interface view.
  3. Run the undo mpls te path command to delete the explicit path of the tunnel.
  4. Run the quit command to return to the system view.
  5. Run the explicit-path path-name command to enter the explicit path view.
  6. Run the next hop 10.2.3.2 command to set the next-hop IP address along the explicit path to 10.2.3.2.
  7. Run the next hop 10.3.4.2 command to set the next-hop IP address along the explicit path to 10.3.4.2.
  8. Run the quit command to return to the system view.
  9. Run the interface tunnel tunnel-number command to enter the tunnel interface view.
  10. Run the mpls te path explicit-path path-name command to configure the explicit path of the tunnel.
  11. Run the commit command to make the configuration take effect.

    After these configurations are complete, run the display mpls te tunnel-interface command on LSRA. The command output shows that the tunnel interface is now Up. The fault is then rectified.

Summary

On a network with inter-area tunnels, IGP routes can be advertised only in a single area, and inter-area CSPF calculation cannot be performed automatically. Therefore, a complete explicit path must be specified manually.

Tunnel Creation Fails Because of an Authentication Failure

This section describes how to troubleshoot a failure to create a tunnel as a result of an authentication fault.

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

The tunnel from Device A to Device C goes Down.

MPLS VPN is configured on the network shown in Figure 4-91.

Figure 4-91 MPLS VPN
NOTE:

Interfaces 1 and 2 in this example are GE 1/0/0 and GE 2/0/0, respectively.



Fault Analysis
  1. Run the display current-configuration interface tunnel interface-type interface-number command on Device A to view the tunnel configurations. The command output shows that the tunnel configurations are correct.

  2. Run the display mpls te cspf tedb all command on Device A to view CSPF TEDB information. The command output shows that CSFP TEDB information is correct.

  3. Run the display mpls rsvp-te statistics global command on Device A and Device B.

    Statistics on Device A are as follows:

    Total Statistics Information:
     PSB CleanupTimeOutCounter: 0           RSB CleanupTimeOutCounter: 0
     SendPacketCounter: 36                  RecPacketCounter: 35
     SendCreatePathCounter: 1               RecCreatePathCounter: 0
     SendRefreshPathCounter: 34             RecRefreshPathCounter: 0
     SendCreateResvCounter: 1               RecCreateResvCounter: 1
     SendRefreshResvCounter: 0              RecRefreshResvCounter: 34
     SendResvConfCounter: 0                 RecResvConfCounter: 0
     SendHelloCounter: 0                    RecHelloCounter: 0
     SendAckCounter: 0                      RecAckCounter: 0
     SendPathErrCounter: 0                  RecPathErrCounter: 0
     SendResvErrCounter: 0                  RecResvErrCounter: 0
     SendPathTearCounter: 1                 RecPathTearCounter: 0
     SendResvTearCounter: 0                 RecResvTearCounter: 0
     SendSrefreshCounter: 0                 RecSrefreshCounter: 0
     SendAckMsgCounter: 0                   RecAckMsgCounter: 0
     SendChallengeMsgCounter: 0             RecChallengeMsgCounter: 0
     SendResponseMsgCounter: 0              RecResponseMsgCounter: 0
     SendErrMsgCounter: 0                   RecErrMsgCounter: 0
     SendRecoveryPathMsgCounter: 0          RecRecoveryPathMsgCounter: 0
     SendGRPathMsgCounter: 0                RecGRPathMsgCounter: 0
     ResourceReqFaultCounter: 0            
     Bfd neighbor count: 0                  Bfd session count: 0

    The statistics on Device B are as follows:

    Total Statistics Information:
     PSB CleanupTimeOutCounter: 0           RSB CleanupTimeOutCounter: 0
     SendPacketCounter: 36                  RecPacketCounter: 35
     SendCreatePathCounter: 1               RecCreatePathCounter: 0 SendRefreshPathCounter: 34             RecRefreshPathCounter: 0
     SendCreateResvCounter: 1               RecCreateResvCounter: 1
     SendRefreshResvCounter: 0              RecRefreshResvCounter: 34
     SendResvConfCounter: 0                 RecResvConfCounter: 0
     SendHelloCounter: 0                    RecHelloCounter: 0
     SendAckCounter: 0                      RecAckCounter: 0
     SendPathErrCounter: 0                  RecPathErrCounter: 0
     SendResvErrCounter: 0                  RecResvErrCounter: 0
     SendPathTearCounter: 0                 RecPathTearCounter: 0 SendResvTearCounter: 0                 RecResvTearCounter: 0
     SendSrefreshCounter: 0                 RecSrefreshCounter: 0
     SendAckMsgCounter: 0                   RecAckMsgCounter: 0
     SendChallengeMsgCounter: 0             RecChallengeMsgCounter: 0
     SendResponseMsgCounter: 0              RecResponseMsgCounter: 0
     SendErrMsgCounter: 0                   RecErrMsgCounter: 0
     SendRecoveryPathMsgCounter: 0          RecRecoveryPathMsgCounter: 0
     SendGRPathMsgCounter: 0                RecGRPathMsgCounter: 0
     ResourceReqFaultCounter: 0            
     Bfd neighbor count: 0                  Bfd session count: 0

    The command output shows that RecPacketCounter is not zero on Device B, and the number of all types of messages is zero. This indicates that a fault occurs when packets are pre-processed. The possible cause is that invalid packets are received, or RSVP authentication fails.

  4. Run the display current-configuration interface command on Device A and Device B.

    The configuration on Device B is as follows:

    interface GE1/0/0
     ip address 10.1.1.2 255.255.255.0
     isis enable 1
     mpls
     mpls te
     mpls te bandwidth max-reservable-bandwidth 10000
     mpls rsvp-te
     mpls rsvp-te authentication plain Huawei-123

    The display on Device A is as follows:

    interface GE1/0/0
     ip address 10.1.1.1 255.255.255.0
     isis enable 1
     mpls
     mpls te
     mpls te bandwidth max-reservable-bandwidth 10000
     mpls rsvp-te

    The command output shows that RSVP is configured on Router B's interface, but not Device A's interface. Packets sent by Device A to Device B fail to be authenticated, and the tunnel cannot be established.

Procedure

  1. Run the interface interface-type interface-number command to enter the view of GE1/0/0.
  2. Run the mpls rsvp-te authentication { cipher | plain } auth-key command to configure RSVP authentication. The keys on both ends must be the same.

    Then run the display mpls te tunnel-interface command on Device A. The command output shows that the tunnel interface goes Up. The fault is rectified.

Summary

Check statistics about the sent and received packets to analyze the fault.

Tunnel Path Calculation Fails

This section describes how to troubleshoot a tunnel path calculation failure.

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 TE is configured on the network shown in Figure 4-92. An MPLS TE tunnel named Tunnel10 is established from Device A to Device D. After the commit command is run on Tunnel10 of Device A, the MPLS TE tunnel cannot be established.

Figure 4-92 MPLS TE network
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.



A CR-LSP between Device A and Device D fails to be established.

Fault Analysis
  1. Run the display mpls te tunnel-interface last-error tunnel-name command on Device A to enable debugging. An error message indicating a CSPF calculation failure is displayed.

        LSP Type   : Primary LSP               LSP ID     : 1.1.1.1:2:20194
        Error Code : 2                         Occur Time : 2017-09-21 07:42:28.730
        Error Info : Path Err, Error Node 13.1.1.1, Error LsrId 1.1.1.1,
                     RSVP ErrCode 24: Routing problem,
                     RSVP ErrValue 5: No route,
                     RSVP failed to set up the LSP.
                     DownReason: PATH error ERO ERROR.
    
  2. Run the display mpls te cspf tedb node command on Device A to view the TEDB on each node. Check whether various attributes of the interface IP addresses, such as the color and the maximum reservable bandwidth of TE class types can meet the requirements.

    The command output shows that path calculation has failed because of unavailable link bandwidth. The destination address is unreachable.

Procedure

  1. Run the system-view command to enter the system view.
  2. Run the interface interface-type interface-number command to enter the view of the interface on which the bandwidth cannot meet the requirements.
  3. Run the mpls te bandwidth max-reservable-bandwidth command to change the maximum reservable bandwidth on an MPLS TE tunnel or change the constraints of the tunnel bandwidth on Device A. The bandwidth of all nodes can meet the requirements.
  4. Run the interface tunnel tunnel-number interface-number command to enter the tunnel interface view.
  5. Run the mpls te bandwidth command to change tunnel bandwidth.

    Run the display mpls te tunnel-interface command on Device A to view the status of CR-LSPs and the tunnel. Both CR-LSPs and the tunnel go Up. The fault is then rectified.

Summary

If a message "CSPF fail to compute the query" is displayed, indicating that tunnel path calculation has failed, the fault mainly lies in an incorrect configuration or unavailable node resource.

The Path with the Smallest Metric Is Not Selected

This section describes how to troubleshoot a failure to select a path with the smallest metric.

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 TE is configured on the network shown in Figure 4-93. The default metric of all interfaces on each device is 10. The optimal path is Device A --> Device B --> Device C --> Device D.

Run the mpls te record-route command and then run the display mpls te tunnel path command on the tunnel interface. The bandwidth of the optimal path is sufficient, but the tunnel is established over another path Device A -->Device B --> Device E -->Device C -->Device D, which is not an optimal path.

Figure 4-93 MPLS TE network
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.



Fault Analysis
  1. Run the display mpls te cspf tedb command on Device A. The command output shows that the database on Device B --> Device E --> Device C is correct.

  2. Create a new tunnel and view the CSPF calculation result. The shortest path is calculated, and the fault does not appear.

  3. Continue to check the log files. The metric of GE 3/0/0 on Device B is changed to 100 before the tunnel is created. When the new tunnel is being configured, the metric reverts to the default.

    The path Device A --> Device B --> Device E --> Device C --> Device D is selected using CSPF calculation. After the link metric is restored, the path is not recalculated, and the tunnel does not select the path with the smallest metric.

Procedure

  1. On Device A, run the system-view command to enter the system view.
  2. Run the interface tunnel interface-number command to enter the tunnel interface view.
  3. Run the mpls te reoptimization command to enable periodic optimization.
  4. Run the return command to return to the user view.
  5. Run the mpls te reoptimization command to trigger optimization immediately.

    The path with the smallest metric is selected on Device A.

Summary

Rectifying the failure to select a path with the smallest metric depends on the TE feature. TE is driven by configuration, not by topology.

You can configure re-optimization to prevent the failure to select a path with the smallest metric.

Hot-Standby LSP Establishment Fails

This section describes how to troubleshoot a hot-standby LSP establishment failure.

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 TE is configured on the network shown in Figure 4-94.

Figure 4-94 MPLS TE network
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.



A tunnel from Device B to Device C is created, but a hot-standby LSP fails to be established.

Run the display mpls te tunnel-interface tunnel 1/0/0 command. The command output is as follows:

Primary CR-LSP  UP and HotBackup CR-LSP setting Up

The command output shows that the primary tunnel is established, but its hot-standby LSP fails to be established.

Fault Analysis
  1. Run the display mpls te tunnel path command on Device A to view the primary LSP of the tunnel. The command output shows that the path Device A -> Device B -> Device C is used.

  2. Run the display mpls te tunnel-interface last-error tunnel-name command on Device A to view last error information on the tunnel. A message indicating a hot-standby calculation failure is displayed.

        LSP Type   : Hot-Standby LSP           LSP ID     : 1.1.1.1:2:21131
        Error Code : 2                         Occur Time : 2017-09-21 08:05:16.602
        Error Info : Path Err, Error Node 24.1.1.4, Error LsrId 4.4.4.4,
                     RSVP ErrCode 24: Routing problem,
                     RSVP ErrValue 5: No route,
                     RSVP failed to set up the LSP.
                     DownReason: PATH error CSPF FAIL.
    

    The preceding command output shows that the system has failed use CSPF calculation to calculate a hot standby CR-LSP.

  3. Run the display mpls te cspf tedb node command to check the CSPF database. Note that the bandwidth of GE 2/0/0 on Device E is not adequate to establish the bypass LSP.

Procedure

  1. On Device E, run the system-view command to enter the system view.
  2. Run the interface interface-type interface-number command to enter the view of GE 2/0/0 on which the bandwidth is too low.
  3. Run the mpls te bandwidth max-reservable-bandwidth command to modify the maximum link reservable bandwidth.

    Run the display mpls te tunnel-interface tunnel 1/0/0 command on Device A to change the bandwidth. The command output shows that the hot-standby CR-LSP is established. The fault is rectified.

Summary

The key point of the example lies in the mechanism in CR-LSP backup. The bandwidth of the backup CR-LSP cannot be configured, but is inherited from the primary CR-LSP.

FRR Binding Fails

This section describes how to troubleshoot an FRR binding failure.

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 TE is configured on the network shown in Figure 4-95.

Figure 4-95 MPLS TE network
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.



The primary tunnel path is along the path Device A --> Device B --> Device E --> Device C --> Device D. A bypass tunnel is established between Device B and Device D, with Device E functioning as a loose node.

FRR binding fails.

Fault Analysis
  1. Run the display mpls rsvp-te last-error command on Device B to view last RSVP error information. If the following information is displayed, no matching bypass LSP exists.

    SubError: NO MATCHED BYPASS          Time:2010-11-24 23:08:18
    IfIndex: Unknown
    TunnelId: 1                              IngressLsrId:1.1.1.1
    LspId: 1                                  EgressLsrId: 4.4.4.4
    Description:
    
  2. Run the display mpls te tunnel path command to view paths for the tunnel. The command output shows that the primary tunnel uses the path Device A --> Device B --> Device C --> Device D, and the backup tunnel uses the path Device B --> Device E --> Device C --> Device D. The output also shows that some coincident nodes exist between the PLR and the MP on the primary and backup tunnels. These nodes cause FRR binding to fail.

Procedure

  1. On Device B, run the system-view command to enter the system view.
  2. Run the interface tunnel tunnel-number command to enter the interface view of the bypass tunnel.
  3. Run the undo mpls te path command to delete the explicit path on the tunnel interface.
  4. Run the commit command to make the configuration take effect.
  5. Run the quit command to return to the system view.
  6. Run the explicit-path path-name command to enter the explicit path view.
  7. Run the add hop ip-address before 5.5.5.9 command to add the IP address of GE 1/0/0 of Device E before 5.5.5.9.
  8. Run the add hop ip-address before 4.4.4.9 command to add the IP address of GE 2/0/0 of Device D before 4.4.4.9.
  9. Run the quit command to return to the system view.
  10. Run the interface tunnel interface-number command to enter the interface view of the bypass tunnel.
  11. Run the mpls te path explicit-path path-name command to re-designate an explicit path.
  12. Run the commit command to make the configuration take effect.

    Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to view information about the LSP on Device A. The command output shows that FRR binding is implemented. The fault is removed.

Summary

In the FRR configuration, to ensure that binding is implemented, specify the strict explicit paths of the primary and bypass tunnels. Otherwise, the binding fails when the coincident nodes exist between the PLR and MP.

After the Primary Tunnel Fails, Traffic Does Not Switch to an HSB Tunnel

This section describes how to troubleshoot a failure to switch traffic from a faulty primary LSP to an HSB tunnel.

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-96, an RSVP-TE tunnel is established from LSRA to LSRC along the path 10.1.1.1 -> 10.1.1.2 -> 10.2.1.1 -> 10.2.1.2, and an HSB tunnel is established, which originates from 10.4.1.1 and is destined for 10.4.1.2. After the outbound GE 2/0/0 on LSRB fails, traffic does not switch to the HSB tunnel.

Figure 4-96 Networking for a failure to switch traffic from a faulty primary tunnel to an HSB tunnel
NOTE:

Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.



Fault Analysis
  1. Run the display current-configuration interface tunnel tunnel-number command on LSRA to view information about the explicit path LSRA -> LSRB -> LSRC.

  2. Run the display explicit-path [ path-name ] [ tunnel-interface | verbose ] command on LSRA to view information about an explicit path and a tunnel established over the explicit path. The explicit path for the primary tunnel includes LSRA and LSRB, but not LSRC.

  3. Run the display mpls te tunnel path tunnel-name command on LSRA to view information about the MPLS TE tunnel. The tunnel is along the path 10.1.1.1 -> 10.1.1.2 -> 10.3.1.1 -> 10.3.1.2.

A loose explicit path is specified for the tunnel, which contains LSRA and LSRB but not LSRC. The tunnel over this explicit path can be established over the path 10.1.1.1 -> 10.1.1.2 -> 10.3.1.1 -> 10.3.1.2. This means if GE 2/0/0 on LSRB fails, traffic traveling through the HSB tunnel is not affected.

Procedure

  1. Run the system-view command on LSRA to enter the system view.
  2. Run the interface tunnel tunnel-number command to enter the view of the MPLS TE tunnel interface.
  3. Run the undo mpls te path command to delete the loose explicit path LSRA -> LSRB -> LSRC.
  4. Run the quit command to exit the tunnel interface view.
  5. Run the explicit-path path-name command to enter the view of the loose explicit path LSRA -> LSRB -> LSRC.
  6. Run the next hop 10.2.1.1 command to specify the next-hop IP address of the explicit path to 10.2.1.1. This allows the primary tunnel to use a strict explicit path.
  7. Run the quit command to exit the explicit path view.
  8. Run the interface tunnel tunnel-number command to enter the view of the MPLS TE tunnel interface.
  9. Run the mpls te path explicit-path path-name command to specify the strict explicit path 10.1.1.1 -> 10.1.1.2 -> 10.2.1.1 -> 10.2.1.2 for the primary tunnel.
  10. Run the commit command to make configurations take effect. The fault is rectified.
Summary

A strict explicit path is recommended for the primary tunnel so that traffic can be transmitted over a pre-configured explicit path.

VPN Traffic Loss Is Caused by a Change in the Next-hop Route

This section describes how to troubleshoot VPN traffic loss caused by a change in the next-hop route.

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-97, an MPLS LDP LSP is established between LSRA and LSRB. The next-hop route from LSRA to LSRB changes, which prevents the VPN route from recursing to the LDP LSP. As a result, VPN services sent by LSRA to LSRB are interrupted.

Figure 4-97 Networking for VPN traffic loss caused by a change in the next-hop route
NOTE:

Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.



Fault Analysis
  1. Run the display ip routing-table 2.2.2.2 32 command on LSRA. The route to LSRB is displayed. For example,

    <LSRA> display ip routing-table 2.2.2.2 32
    Route Flags: R - relay, D - download
    to fib, T - to vpn-instance, B - black hole route
    ------------------------------------------------------------------------------
    Routing Table : Public
    Summary Count : 1
    Destination/Mask    Proto  Pre  Cost       Flags NextHop         Interface
    
          2.2.2.2/32    OSPF   10   2            D   10.1.2.2        GigabitEthernet2/0/0

    The command output shows that the next hop to LSRB (2.2.2.2/32) is changed. The primary LSP has failed, and the route is switched to the backup LSP.

  2. Run the display mpls lsp include 2.2.2.2 32 command on LSRA. No LSP to LSRB is established.

  3. Run the display mpls lsp include 3.3.3.3 32 command on LSRA. No LSP to LSRC is established.

  4. Run the display mpls ldp session command on LSRA. No LDP session to 3.3.3.3 is established.

  5. Run the display mpls ldp interface command on LSRA. MPLS LDP is disabled on directly connected interfaces on LSRA and LSRC.

Procedure

  1. Run the system-view command on LSRA, LSRB, and LSRC to enter the system view.
  2. Run the interface interface-type interface-number command on LSRA, LSRB, and LSRC to enter the interface view.
  3. Run the mpls command on LSRA, LSRB, and LSRC to enable MPLS for the interfaces on the backup LSP.
  4. Run the mpls ldp command on LSRA, LSRB, and LSRC to enable MPLS LDP for the interfaces on the backup LSP. The fault is rectified.
Summary

Enabling MPLS LDP on an entire network ensures that an LSP is established even if the next-hop route changes to prevents VPN traffic loss.

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 14619

Downloads: 258

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