Troubleshooting - MPLS

HUAWEI NetEngine40E/80E Universal Service
Router
V600R006C00
Troubleshooting - MPLS
Issue 03
Date 2013-08-20
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 03 (2013-08-20) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - MPLS About This Document
About This Document
Purpose
NOTE
l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line
Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On
the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions
of LPUs and SFUs to exchange and forward packets.
This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/
40E in terms of common faults and causes, troubleshooting cases, and FAQs.
This document describes the procedure and method for troubleshooting for the HUAWEI
NetEngine80E/40E.
CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential ii

Product Name Version
HUAWEI NetEngine80E/40E V600R006C00

Router
Intended Audience
This document is intended for:
l System maintenance engineers

l Commissioning engineers
l Network monitoring engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER indicates a hazard with a high level or medium

level of risk which, if not avoided, could result in death or
DANGER
serious injury.
WARNING indicates a hazard with a low level of risk which,

if not avoided, could result in minor or moderate injury.
WARNING
CAUTION indicates a potentially hazardous situation that,

CAUTION if not avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP TIP indicates a tip that may help you solve a problem or save
time.
NOTE NOTE provides additional information to emphasize or

supplement important points of the main text.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential iii

Convention Description
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 03 (2013-08-20)

The third commercial release.

The second commercial release.

Initial commercial release.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential iv

Troubleshooting - MPLS Contents
Contents
About This Document.....................................................................................................................ii

1 MPLS LDP Troubleshooting.......................................................................................................1
1.1 LDP Session Flapping....................................................................................................................................................2
1.1.1 Common Causes..........................................................................................................................................................2
1.1.2 Troubleshooting Flowchart..........................................................................................................................................2
1.1.3 Troubleshooting Procedure..........................................................................................................................................3
1.1.4 Relevant Alarms and Logs..........................................................................................................................................4
1.2 LDP Session Goes Down...............................................................................................................................................4
1.2.1 Common Causes..........................................................................................................................................................4
1.3 LDP LSP Flapping..........................................................................................................................................................7
1.3.1 Common Causes..........................................................................................................................................................7
1.4 LDP LSP Goes Down.....................................................................................................................................................9
1.4.1 Common Causes..........................................................................................................................................................9
1.4.3 Troubleshooting Procedure........................................................................................................................................10
1.4.4 Relevant Alarms and Logs........................................................................................................................................12
1.5 Troubleshooting a Failure in Establishing an Inter-area LSP.......................................................................................12
1.5.1 Common Causes........................................................................................................................................................12
1.5.2 Troubleshooting Flowchart........................................................................................................................................12
1.6 Related Troubleshooting Cases....................................................................................................................................15
1.6.1 Cannot Establish a Static LSP...................................................................................................................................15
1.6.2 Cannot Establish an Inter-area LSP...........................................................................................................................17
1.6.3 Uneven Load Balancing Caused by Incorrect LDP Transport Addresses.................................................................18
Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

1.6.4 MPLS LDP Peer Relationship Cannot Be Established Because ATM Interfaces Are Not Enabled with the Broadcast
Function..............................................................................................................................................................................21
1.6.5 No LDP Session Can Be Established Between PEs Because the Route to the LSR ID of an LDP Instance Is
Unreachable........................................................................................................................................................................22
1.6.6 MPLS LDP Peer Relationship Cannot Be Established.............................................................................................24
1.6.7 LDP Flaps..................................................................................................................................................................26
1.6.8 Route of the GRE Tunnel Flaps................................................................................................................................28
1.6.9 Load Imbalance Caused by Configuring LDP Transport Addresses.........................................................................30
2 MPLS TE Troubleshooting........................................................................................................33
2.1 TE Tunnel Is Down......................................................................................................................................................34
2.1.1 Common Causes........................................................................................................................................................34
2.2 TE Tunnel Suddenly Goes Down.................................................................................................................................37
2.2.1 Common Causes........................................................................................................................................................37
2.3 Loop Occurs on a TE Tunnel.......................................................................................................................................39
2.3.1 Common Causes........................................................................................................................................................40
2.4 Bidirectional TE Tunnel Goes Down...........................................................................................................................41
2.4.1 Common Causes........................................................................................................................................................41
2.5 Related Troubleshooting Cases....................................................................................................................................44
2.5.1 A Loop Occurs Because of the Undeleted IP Address of an Interface That Has Been Shut Down on an RSVP-TE
Tunnel.................................................................................................................................................................................44
2.5.2 Tunnel Goes Down Suddenly and Then Up..............................................................................................................46
2.5.3 Fast Check and Rectify the Problem of Route Loops...............................................................................................47
2.5.4 Tunnel Flaps Every Several Minutes After IGP Shortcut Is Enabled.......................................................................48
2.5.5 TE Tunnel of the Inter-OSPF Area Fails to Be Set Up.............................................................................................50
2.5.6 Tunnel Goes Down After Switchover.......................................................................................................................52
2.5.7 Tunnel Creation Fails Because of Authentication Failure.........................................................................................53
2.5.8 Calculation of the Tunnel Path Fails.........................................................................................................................55
2.5.9 Path with the Smallest Metric Is Not Selected..........................................................................................................57
2.5.10 Establishment of the Hot-Standby LSP Fails..........................................................................................................58
2.5.11 FRR Binding Fails...................................................................................................................................................59
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi

2.5.12 Primary Tunnel Turns Down When Configuration of the Bypass Tunnel Is Modified..........................................61
2.5.13 After the Primary Tunnel Fails, Traffic Does Not Switch to an HSB Tunnel.........................................................62
2.5.14 VPN Traffic Loss Is Caused by a Change in the Next-hop Route..........................................................................64
2.5.15 Volume of Service Traffic on Interfaces of a Device Is Unstable...........................................................................65
3 MPLS Forwarding Troubleshooting........................................................................................70

3.1 Host Cannot Receive or Send Packets Through an LSP..............................................................................................71
3.1.1 Common Causes........................................................................................................................................................71
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vii

Troubleshooting - MPLS 1 MPLS LDP Troubleshooting
1 MPLS LDP Troubleshooting
About This Chapter
1.1 LDP Session Flapping
1.2 LDP Session Goes Down
1.3 LDP LSP Flapping
1.4 LDP LSP Goes Down
1.5 Troubleshooting a Failure in Establishing an Inter-area LSP
1.6 Related Troubleshooting Cases
Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1 LDP Session Flapping
1.1.1 Common Causes

This fault is commonly caused by one of the following:
l The configuration of the LDP GR timer, the LDP MTU, LDP authentication, the LDP
Keepalive timer, or the LDP transport address is set, changed, or deleted.
l An interface flaps.
l Routes flap.
1.1.2 Troubleshooting Flowchart

After an LDP session is configured, the LDP session flaps.
The troubleshooting roadmap is as follows:

l Check that LDP GR, a Keepalive timer, LDP authentication, MTU signaling, or a transport
address is configured.
l Check that the interface does not alternate between Down and Up.
l Check that the routes do not alternate between unreachable and reachable.
Figure 1-1 shows the troubleshooting flowchart.
Figure 1-1 Troubleshooting flowchart for LDP session flapping
LDP session
flaps
Yes Yes
LDP session Wait 10 seconds Is fault rectified?
is recreated?
No
No
Yes See the section Yes

Interface flaps? "Interface Is fault rectified?
Troubleshooting"
No
No
See the section Yes

Yes
Routes flap? "IGP Route Is fault rectified?
Troubleshooting"
No
No
Seek technical
End
support

1.1.3 Troubleshooting Procedure
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that LDP GR, a Keepalive timer, LDP authentication, an LDP MTU, or a transport address
is configured.
1. Run the display this command in the LDP view to view the configuration of LDP GR, an
LDP MTU, or LDP authentication.
l If the following information is displayed, LDP GR is configured.
mpls ldp
graceful-restart
l If the command output displays the following information, the LDP MTU value is set.
mpls ldp
mtu-signalling
l If the command output displays the following information, LDP authentication is

configured.
mpls ldp
md5-password plain 2.2.2.2 abc
or
mpls ldp
authentication key-chain peer 2.2.2.2 name kc1
2. Run the display this command in the interface view to view an LDP Keepalive timer or
an LDP transport address.
l If the command output displays the following information, the LDP Keepalive timer is
set. The timer value (30 seconds in the following example) depends on the real-world
situation.
mpls ldp
mpls ldp timer keepalive-hold 30
l If the command output displays the following information, the LDP transport address
is set. The transport address and interface type and number can be set as needed.
mpls ldp
mpls ldp transport-address interface
l If any of the configurations you checked in sub-steps 1 and 2, wait 10 seconds and check
whether the LDP session flaps.
l If no configuration has been performed, go to Step 2.
Step 2 Check that the interface does not alternate between Down and Up.
Run the display ip interface brief command and 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 always alternates between Down and Up, the interface flaps.
l If the interface alternates between Down and Up, see the section "Interface Flapping".
l If the interface does not flap, go to Step 3.
Step 3 Check that the routes do not alternate between unreachable and reachable.

Run the display fib command quickly to check routing information. If routes are reachable,
routing information is displayed. If no route is reachable, no routing information is displayed.
If sometimes routing information is displayed, but sometimes not, the routes alternate between
unreachable and reachable.
l If routes alternate between unreachable and reachable or no route exists, see The Ping
Operation Fails.
l If the routes do not flap, go to Step 4.
Step 4 Collect the following information, and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, logs, and alarms
----End
1.1.4 Relevant Alarms and Logs
Relevant Alarms
LDP_1.3.6.1.2.1.10.166.4.0.4 mplsLdpSessionDown
LDP_1.3.6.1.2.1.10.166.4.0.3 mplsLdpSessionUp
Relevant Logs
None.
1.2 LDP Session Goes Down
1.2.1 Common Causes

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

l The undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
l No route exists.
l An LDP Keepalive timer expires.
l An LDP Hello-hold timer expires.

After an LDP session is configured, the LDP session goes Down.

l Check that the interface on which the LDP session is established is shut down.
l Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer is run.
l Check that the routes exist.
l Check that an LDP Hello-hold timer expires.

l Check that an LDP Keepalive-hold timer expires.
Figure 1-2 Troubleshooting flowchart for the fault that an LDP session goes Down
LDP session
goes Down
Run the undo

Yes Yes
Interface is shutdown
Is fault rectified?
shut down? command on the
interface
No
No
An MPLS Yes Restore the Yes

command in undo deleted Is fault rectified?
form is run? configuration
No
No
Yes
Routes are No Troubleshoot the
Is fault rectified?
reachable? routes problem
No
Yes
Yes See the section Yes

Hello-hold timer "CPU Uage is Is fault rectified?
expires? High"
No
No
See the section Yes

Keepalive-hold Yes
"Link Forwarding Is fault rectified?
timer expires?
Fails"
No No
Seek technical
End
support

Context
NOTE
Procedure
Step 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 following information is displayed,
the interface has been shut down.
shutdown
l If the interface has been shut down, run the undo shutdown command to restart the
interface.
l If the interface is Up, go to Step 2.
Step 2 Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
Run the display current-configuration command.
l If the command output does not include the following information, MPLS is disabled.
mpls
l If the command output does not include the following information, MPLS LDP is disabled.
mpls ldp
l If the command output does not include the following information, the remote LDP session
is deleted.
mpls ldp remote peer
l If an MPLS-associated configuration is deleted, re-perform the configuration.

l If no MPLS-associated configuration is performed, go to Step 3.
Step 3 Check that the routes to the peer are reachable.

Run the display ip routing-table command to view the Destination/Mask field and a route to
the peer. If no route to the peer is displayed, a TCP connection cannot be established. If the route
to the peer is displayed, run the ping host command. If the ping succeeds, the route is reachable.
If the ping fails, the route is unreachable.
l If no route to the peer is displayed, see OSPF Troubleshooting or IS-IS Troubleshooting
to troubleshoot the problem.
l If the route to the peer is displayed but is unreachable, see The Ping Operation Fails.
l If the route to the peer is displayed and is reachable, go to Step 4.
Step 4 Check that an LDP Hello-hold timer expires.

Run the display mpls ldp interface command. Check whether both ends of the LDP session
can send Hello messages. It is recommended that the display mpls ldp interface command be
run at 3second intervals. If the statistics do not change several times, the transmission of Hello
messages is not functioning correctly and the Hello-hold timer expires.
l If the Hello-hold timer expires, see The CPU Usage Is High.
l If the Hello-hold timer does not expire, go to Step 5.

Step 5 Check that an LDP Keepalive-hold timer expires.

Run the display mpls ldp session command to check whether Keepalive messages can be sent
on both ends of the LDP session at 5-second intervals. If the statistics do not change several
times, the transmission of Keepalive messages is not functioning correctly and the Keepalive-
hold timer expires.
l If the Keepalive-hold timer expires, see The Ping Operation Fails.
l If the Keepalive-hold timer does not expire, go to Step 6.
----End
Relevant Alarms
Relevant Logs
LDP/4/SSNHOLDTMREXP
1.3 LDP LSP Flapping
1.3.1 Common Causes

l The route between LSP peers is flapping.

l The LDP session flaps.

This section describes the troubleshooting flow of LDP LSP flapping.
After an LDP LSP is established, the LDP LSP flaps.

l Check that the routes do not alternate between unreachable and reachable.
l Check that the LDP session flaps.

Figure 1-3 Troubleshooting flowchart for LDP LSP flapping
LDP LSPs
flap
See the section Yes

Route flapping Yes
"IGP Route Is fault rectified?
occurs? Troubleshooting"
No
No
See the section Yes

LDP Yes
"LDP Session Is fault rectified?
session flaps?
Flaps"
No
No
Seek technical
support End

This section describes the troubleshooting procedure of LDP LSP flapping.
Context
NOTE
Procedure
Step 1 Check that the routes alternate between unreachable and reachable.
Run the display ip routing-table command to check information about the routes to the
destination of the LSP. Run this command at 1-second interval. If routes exist, routing
information is displayed. If no routes exist, no routing information is displayed. If sometimes
routing information is displayed but sometimes not after the command is run several times, the
routes alternate between unreachable and reachable.
l If routes alternate between unreachable and reachable or no route is displayed, see The Ping
Operation Fails and rectify the fault in IGP routes.
l If the routes are always reachable, go to Step 2.
Step 2 Check that the LDP session flaps.

Run the display mpls ldp session command to check the Status field. Running this command
every second is recommended. If Operational and Initialized are displayed alternatively, the
LDP session flaps.
l If the LDP session flaps, see LDP Session Flapping.
l If the LDP session does not flap, go to Step 3.

----End
Relevant Alarms
LSPM_1.3.6.1.2.1.10.166.2.0.2 mplsXCDown
LSPM_1.3.6.1.2.1.10.166.2.0.1 mplsXCUp
Relevant Logs
None.
1.4 LDP LSP Goes Down
1.4.1 Common Causes

l Routes become unreachable.

l The LDP session goes Down.
l Resources are insufficient. The number of resources defined in the PAF/license file, the
number of tokens, or the number of labels reaches the upper limit, or memory is insufficient.
l The policy for establishing an LSP is configured.

After an LDP LSP is established, the LDP LSP goes Down.

l Check that the routes exist.
l Check that the LDP session is successfully established.
l Check that resources are insufficient. The number of resources defined in the PAF/license
file, the number of tokens, or the number of labels reaches the upper limit, or memory is
insufficient.
l Check that a policy for establishing LSPs is configured.

Figure 1-4 Troubleshooting flowchart for the fault that an LDP LSP goes Down
LDP LSP
Down
No Yes
IGP routes See "IGP Route
Is fault rectified?
exist? Troubleshooting"
No
Yes
Session is No See the section Yes

successfully "LDP Session Is fault rectified?
set up? Goes Down"
No
Yes
Increase the
Yes upper limit or Yes
Resources
delete unwanted Is fault rectified?
are insufficient?
LSPs
No
No
Policy for Change the Yes

Yes
setting up an policy for setting Is fault rectified?
LSP exists? up an LSP
No
No
Seek technical
End
support
Context
NOTE
Procedure
Step 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 destination of the LSP.

ip-address mask-length specifies the destination address of the LSP.
If routing information is displayed and the value of the State field is Active Adv in the command
output, a route reachable and is in the active state. If the route is a BGP route of a public network,
check the Label field in the command output. If a value is displayed, not NULL, routing
information carries a label.
l If no route appears, the routes are not in the active state, or the BGP routes do not carry
labels, see The Ping Operation Fails.
l If BGP routes are reachable and in the active state, they carry labels. Go to Step 2.
Step 2 Check that the LDP session is successfully established.

Run the display mpls ldp session command to check the Status field. If Operational is
displayed, the LDP session is established and is Up. If Initialized is displayed, the session is in
Initialized state.
l If the LDP session fails to be established, see LDP Session Goes Down.
l If the LDP session is established properly, go to Step 3.
Step 3 Check that resources are insufficient. The number of resources defined in the PAF/license file,
the number of tokens, or the number of labels reaches the upper limit, or memory is insufficient.
Perform the following steps to check that resources are insufficient.
1. Check whether the number of LSPs reaches the upper limit defined in the PAF/license file.
Run the display mpls lsp statistics command to check the Total field subject to the LDP
LSP field. If the value is greater than that defined in the PAF/license file, resources are
insufficient.
2. Check that tokens to establish ingress LSPs or transit LSPs are used up.
Run the display tunnel-info statistics command to view token statistics. The Global-1
Avail Tunnel-ID Num field shows the total number of available tokens, and the Global-1
Allocated Tunnel-ID Num field shows the number of used tokens. If the values of these
two fields are the same, the tokens are used up and resources are insufficient.
l If resources are insufficient, increase the upper limit of the resources or delete unwanted
LSPs.
l If resources are sufficient, go to Step 4.
Step 4 Check that a policy for establishing LSPs is configured.

l Run the display this command in the MPLS view. If the following information is displayed,
an IP-prefix-based policy has been configured to trigger the establishment of LSPs. The
policy name (abc in the following example) depends on the real-world situation. Then, check
that some LSPs are not included in the IP-prefix-based policy.
lsp-trigger ip-prefix abc
l Run the display this command in the MPLS LDP view. If the following information is
displayed, an IP-prefix-based policy has been configured to trigger the establishment of
LSPs. The policy name (abc in the following example) depends on the real-world situation.
Then, check that some LSPs are not included in the IP-prefix-based policy.
propagate mapping for ip-prefix abc
l Run the display ip ip-prefix command in the system view. If the following information is
displayed, only routes to 1.1.1.1/32 and 2.2.2.2/32 can be used to trigger the establishment
of LSPs. The IP addresses (1.1.1.1/32 and 2.2.2.2/32 in the following example) depend on
the real-world situation.

index: 10 permit 1.1.1.1/32

index: 20 permit 2.2.2.2/32
l If one of the policies for establishing LSPs is configured, add the route to the destination
of the required LSP to the policy.
l If no policy is configured, go to Step 5.
----End
Relevant Alarms
LSPM_1.3.6.1.2.1.10.166.2.0.2 mplsXCDown
LSPM_1.3.6.1.2.1.10.166.2.0.1 mplsXCUp
Relevant Logs
None.
1.5 Troubleshooting a Failure in Establishing an Inter-area

LSP
1.5.1 Common Causes

l Routing problems occur.

l The inter-area LDP extension is not configured.
l An LDP session fails to be established.
l The route associated with the LDP session does not match the route in the routing table.

After the inter-area LDP extension has been enabled, an inter-area LSP fails to be set up.

l Check that routes are reachable.
l Check that the inter-area LDP extension is enabled.
l Check that an LDP session is set up.

l Check that the route associated with the LDP session matches the route in the routing table.
Figure 1-5 Flowchart for troubleshooting the failure in establishing an inter-area LSP
An inter-area
LSP cannot
be
established
No See "IGP Yes

Are route
Routing Is fault rectified?
reachable?
Problems"
No
Yes
Is LDP Yes
No Enable the inter-
inter-area LDP
area LDP Is fault rectified?
extension
extension
enabled?
No
Yes
Is an See "LDP Yes

LDP session is No
Session Goes Is fault rectified?
established? Down"
No
Yes
Does
the LDP route Yes
No See "LSP Goes
match the route Is fault rectified?
Down"
in the routing
table ? No
Yes
Seek
technical
support End
Context
NOTE
Perform the following procedure along an LSP from the egress to the ingress.

Procedure
Step 1 Check that routes are reachable.
Run the display ip routing-table ip-address mask-length verbose command to check

information about routes to the destination address of the inter-area LSP.
ip-address mask-length specifies the destination address of the inter-area LSP.
If routes are reachable, and the State field displays Active Adv, routes associated with the LSP
are reachable and are in the active state. If the Label field displays a value, not NULL, public
network BGP routes carry labels.
NOTE
Either the longest match rule or the exact match rule can be used to search for a reachable route.
l If no route is reachable, the reachable routes are in the inactive state, or BGP routes do not
carry labels, follow the procedure in Ping Failures
l If the routes are reachable in the active state and BGP routes carry labels, go to Step 2.
Step 2 Check that the inter-area LDP extension has been enabled.
Run the display mpls ldp command. If the Longest-match field displays On, the inter-area
LDP extension has been enabled; if Off is displayed, the inter-area LDP extension has not been
enabled.
l If the inter-area LDP extension is disabled, run the longest-match command to enable the
inter-area LDP extension.
l If the inter-area LDP extension has been enabled, go to Step 3.
Step 3 Check that an LDP session is set up.

Run the display mpls ldp session command. If the Status field displays Operational, the LDP
session has been set up and is Up; if Operational is not displayed or no session information is
displayed, the LDP session has not been set up.
l If the LDP session has not been established, follow the procedure in LDP Session Goes
Down.
l If the LDP session has been set up, go to Step 4.
Step 4 Check that the route associated with the LDP session matches the route in the routing table.
Run the display ip routing-table command, and check the NextHop and Interface fields.
Run the display mpls ldp session verbose command, and check the Addresses received from
peer field.
Run the display mpls ldp peer command, and check the DiscoverySource field.
If the value in the NextHop field is displayed as part of information in the Addresses received
from peer field, and the value in the Interface is the same as that in the DiscoverySource field,
the route associated with the LDP session matches the route in the routing table.
l If the LDP session does not match routes, follow the procedure in LDP LSP Goes
Down.
l If the LDP session matches routes, go to Step 5.
Step 5 Collect the following information and contact Huawei technical support personnel.

l Results of the preceding troubleshooting procedures

l Configuration files, log files, and alarm files of the device
----End

Relevant Alarms
None
Relevant Logs
None
1.6.1 Cannot Establish a Static LSP

Fault Symptom
Figure 1-6 Networking diagram for a static LSP establishment failure

Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32
POS1/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30
RouterA RouterB
A Point-to-Point Protocol (PPP) link connects Router A with Router B. When a static LSP is
configured, the LSP on the ingress goes Down.
Fault Analysis
Establishing a static LSP according to a routing protocol. When you configure a static LSP on
the ingress LSR, the local routing table must contain a routing entry exactly matching the
destination IP address. The routing entry includes the destination IP address and the next-hop
IP address.
1. Use the display mpls static-lsp verbose command. You can see that the forwarding
equivalence class (FEC) is 2.2.2.9/32 and the next-hop IP address is 10.1.1.1.
<RouterA> display mpls static-lsp ad verbose
No : 1
LSP-Name : ad
LSR-Type : Ingress
FEC : 2.2.2.9/32
In-Label : NULL

Out-Label : 30
In-Interface : -
Out-Interface : -
NextHop : 10.1.1.1
Static-Lsp Type: Normal
Lsp Status : Down
2. Use the display ip routing-table command. You can see that the destination IP address is
2.2.2.9/32 and the next-hop IP address is 10.1.1.2.
<RouterA> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 InLoopBack0
2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
The static LSP cannot be established because the next hop of the LSP does not match that
of the corresponding routing entry.
3. Use the display current-configuration | include static-lsp command to view the
configuration of the static LSP.
<RouterA> display current-configuration | include static-lsp
static-lsp ingress ad destination 2.2.2.9 32 outgoing-interface Pos1/0/0 out-
label 30
If a static LSP is configured by designating an outgoing interface, the IP address of the

outgoing interface is specified to be the next hop of the LSP. To match the routing entry,
configure the static LSP by designating next hops.
Procedure
Step 1 Run static-lsp ingress lsp-name destination ip-address mask-length nexthop next-hop-
address out-label out-label command in the system view to configure the static LSP by
designating next hops.
static-lsp ingress ad destination 2.2.2.9 32 nexthop 10.1.1.2 out-label 30
After the preceding configuration, the value of the Lsp Status field is Up in the display mpls
static-lsp verbose command output. The fault is rectified.
----End
Summary
When you configure a static LSP on an ingress LSR, ensure that a routing entry exactly matching
the specific destination IP address exists in the local routing table. The routing entry includes
the destination IP address and next hop IP address.
l If the routing entry is learnt from a dynamic routing protocol, the next hop must be
designated when you configure the static LSP. Moreover, the designated next hop must the
same as that in the corresponding routing entry.
l If you configure a static LSP by specifying an outgoing interface, ensure the following
conditions:

The outgoing interface type must be PPP.

The corresponding routing entries must be configured manually, and a specific outgoing
interface mode must be used in the configuration.
1.6.2 Cannot Establish an Inter-area LSP
Fault Symptom
On the network shown in Figure 1-7, LSRB, LSRC, and LSRD are in Area 10, and LSRA is in
Area 20. LSRD aggregates routes associated with LSRB and LSRC and advertises a summary
route to Area 20. The inter-area LDP extension is enabled on LSRA.
Figure 1-7 Networking diagram for an inter-area LSP establishment failure
Loopback0
1.3.0.1/32
0/1
Loopback0 Loopback0 S1/ /24 0 LSRB
O 1 /0/ 24
1.1.0.1/32 1.2.0.1/32 P .1.1. 1
S 2/
POS1/0/0 20 PO 1.1.
. IS-IS
10.1.1.1/24 PO 20
20 S1 Area10
POS1/0/0 .1. /0/
2.1 2
LSRA 10.1.1.2/24 LSRD /24 Loopback0
1.3.0.2/32
IS-IS PO
Area20 20 S1
.1. /0/
2.2 0
/24
LSRC
No inter-area LSP is established.
Fault Analysis
1. Run the display ip routing-table command on LSRA to view routing information. No
information about a summary route to the inter-area LSP destination address is displayed.

------------------------------------------------------------------------------

1.2.0.1/32 ISIS-L1 15 10 D 10.1.1.2 Pos1/0/0

1.3.0.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
20.1.1.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
20.1.2.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
2. Run the display mpls ldp command on LSRA. The Longest-match field displays Off,
indicating that the inter-area LDP extension is not enabled. This causes the failure in
establishing an inter-area LSP.
Run the following commands on LSRA to rectify the fault:
Procedure
Step 1 Run the system-view to enter the system view.
Step 2 Run the mpls command to enter the MPLS LDP view.
Step 3 Run the longest-match command to enable the inter-area LDP extension, using the longest
match rule to search routes for establishing an inter-area LSP.
----End
Summary
An inter-area LSP can be established only if the inter-area LDP extension is enabled on the LSR
with a reachable summary route.
1.6.3 Uneven Load Balancing Caused by Incorrect LDP Transport

Addresses
Fault Symptom
On the network shown in Figure 1-8, Router B is deployed between Routers A and C. Two POS
links between Routers B and C are used to implement load balancing.
Traffic is unevenly distributed over the links from Router C to Router B, whereas traffic is evenly
distributed over the links from Router B to Router C.
Information about the traffic on Router C is as follows:

<RouterC> display interface brief
PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Pos11/0/0 up up 41% 1% 0 0
Pos12/0/0 up up 40% 83% 0 0

Figure 1-8 Networking where incorrect LDP transport addresses cause uneven load balancing
RouterA RouterB RouterC

POS1/0/0
Internet1 Internet2
POS2/0/0
Fault Analysis
The possible causes of this fault are as follows:
l The traffic model is incorrect.
l Load balancing is not implemented between routes over the POS links.
l Load balancing is not implemented between LSPs over the POS links.
Procedure
Step 1 As traffic is unevenly distributed over the links from Router C to Router B and Router C has
already been deployed on the network, the traffic model is not changed when Router B is
deployed. Therefore, an incorrect traffic model can be ruled out as the source of the fault.
Step 2 Run the display ip routing-table command to check whether load balancing is implemented
between the routes over the POS links.
<RouterC> display ip routing-table
------------------------------------------------------------------------------

......
0.0.0.0/0 O_ASE 150 1 D 112.100.5.45 Pos2/0/0
O_ASE 150 1 D 112.100.5.49 Pos1/0/0
1.192.0.0/13 BGP 255 100 RD 112.100.7.2 Pos2/0/0
BGP 255 100 RD 112.100.7.2 Pos1/0/0
1.193.128.0/18 BGP 255 100 RD 112.100.7.2 Pos2/0/0
BGP 255 100 RD 112.100.7.2 Pos1/0/0
......
NOTE
The preceding command output contains only routing information for some of the main network segments. To
determine whether load balancing is implemented between routes, check the entire routing table.
The preceding command output shows that the routes over the POS links are implementing load
balancing, but traffic is not evenly distributed over the links. Therefore, traffic is not being
balanced using IP.
Step 3 Run the display mpls lsp outgoing-interface interface-type interface-number command to
check whether load balancing is implemented between the LSPs over the links.
Check information about the LSPs established by POS 1/0/0 and POS 2/0/0.
<RouterC> display mpls lsp outgoing-interface Pos 1/0/0
no command output
<RouterC> display mpls lsp outgoing-interface Pos 2/0/0

-----------------------------------------------------------------------------
LSP Information: LDP LSP
-----------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
112.100.5.16/30 NULL/3 -/Pos2/0/0
112.100.5.16/30 1041/3 -/Pos2/0/0
112.100.7.1/32 1043/3 -/Pos2/0/0
112.100.7.1/32 NULL/3 -/Pos2/0/0
The preceding command output shows that only POS 2/0/0 is used to establish LSPs and POS
1/0/0 is not used to establish LSPs. This is consistent with the fact that POS 1/0/0 has no traffic.
Step 4 Find out why POS 1/0/0 does not establish LSPs.
Check information about established LDP sessions. The command output shows that Router C
has established an LDP session only using POS 2/0/0.
<RouterC> display mpls ldp peer
LDP Peer Information in Public network
----------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
----------------------------------------------------------------------------
......
112.100.7.1:0 112.100.5.5 Pos2/0/0 ====POS 1/0/0 does not establish
any LDP session.
......
----------------------------------------------------------------------------
Step 5 Run the display current-configuration command to check interface configurations.

<RouterB> display current-configuration
......
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 112.100.5.6 255.255.255.252
isis enable 99
isis circuit-level level-2
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 112.100.5.2 255.255.255.252
isis enable 99
mpls
mpls ldp
......
The preceding command output shows that the mpls ldp transport-address interface command
has been run on POS 1/0/0 and POS 2/0/0 to set the addresses of POS 1/0/0 and POS 2/0/0 as
transport addresses. When the mpls ldp transport-address interface command is run and LDP
sessions are to be established over multiple links between LSRs, LDP-enabled interfaces of each
device must use the same transport address. If multiple transport addresses are configured on a
device, only one transport address can be used to establish an LDP session. To establish LDP
sessions over multiple links and implement load balancing among the links, delete the mpls ldp
transport-address interface command configuration.
Step 6 Run the undo mpls ldp transport-address command to delete configurations on POS 1/0/0 and
POS 2/0/0. Then check information about traffic load balancing between the interfaces. The
command output shows that traffic in the two directions is evenly balanced between the links.
The fault is rectified.

<RouterC> display interface brief

PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
Pos1/0/0 up up 44% 50% 0 0
Pos2/0/0 up up 44% 50% 0 0
----End
Summary
If LDP sessions are to be established over multiple links between two LSRs, LDP-enabled
interfaces of each LSR must use the default transport address or the same transport address. If
multiple transport addresses are configured on an LSR, only one transport address can be used
to establish an LDP session.
1.6.4 MPLS LDP Peer Relationship Cannot Be Established Because

ATM Interfaces Are Not Enabled with the Broadcast Function
Fault Symptom
MPLS LDP is deployed on the network shown in Figure 1-9. An MPLS LSP is established
between LSR A and LSR C by using MPLS LDP. After the configurations, MPLS LDP peer
relationship cannot be established between LSR A and LSR C.
Figure 1-9 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
Loopback 1 Loopback 1 Loopback 1

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
ATM1/0/0 ATM1/0/0 ATM2/0/0 ATM2/0/0

2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.2.1.2/24
LSRA LSRB LSRC
Fault Analysis
NOTE
This troubleshooting case takes the configurations of LSR A as an example. Troubleshooting the fault on
LSR B and LSR C is similar and is omitted.
1. Run the display current-configuration interface atm 1/0/0 command on LSR A to view
the configurations on the ATM interface.

interface Atm1/0/0
undo shutdown
pvc 2/33
pvc 2/34
pvc 2/35
mpls
mpls ldp
MPLS LDP broadcasts packets. ATM interfaces, however, do not forward broadcast
packets by default. As a result, the MPLS LDP peer relationship cannot be established
between LSR A and LSR C.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface atm interface-number command to enter the ATM interface view.
Step 3 Run the pvc { pvc-name [ vpi/vci ] | vpi/vci } command to enter the ATM-PVC view.
Step 4 Run the map ip inarp broadcast command to enable broadcast on the ATM interface.
After the preceding operations, run the display mpls ldp peer command to check that the MPLS
LDP peer relationship has been established between LSR A and LSR C. The fault is therefore
rectified.
----End
Summary
MPLS LDP broadcasts packets. ATM interfaces, however, do not forward broadcast packets by
default. As a result, the MPLS LDP peer relationship cannot be established between LSR A and
LSR C. When configuring MPLS LDP on an interface, ensure that the interface is able to
broadcast protocol packets.
1.6.5 No LDP Session Can Be Established Between PEs Because the

Route to the LSR ID of an LDP Instance Is Unreachable
Fault Symptom
MPLS is deployed on the network shown in Figure 1-10. With this configuration, no LDP
session can be established between PE1 and PE2.

Figure 1-10 Networking diagram of the case where no LDP session can be established between
PEs
Loopback 0 Loopback 0
1.1.1.1 3.3.3.3
PE1 PE2
Loopback 1 Loopback 1
100.100.100.100 210.210.210.210
Fault Analysis
1. Run the debugging mpls ldp session command on PE1 and PE2. The command output
shows that PE1 and PE2 can exchange Hello packets but the LDP status alternates between
the Non-existent state and the Initialized state. The following diagnostic information shows
that the address of Loopback1 is used as the LSR ID for establishing an LDP session
between PE1 and PE2.
Diagnostic information on PE1:
*0.1513340 PE1 LDP/8/Session:
Gigabitethernet1/0/0
Link Hello message received on interface:
Created session with LSR:
210.210.210.210
Link Hello message sent on interface:
*
Diagnostic information on PE2:

Link Hello message received on interface:
Created session with LSR:
100.100.100.100
Session(100.100.100.100,Active role) start to open TCP
connection.
Session(100.100.100.100)'s state changed from Non-existent to
Initialized.


2. Run the display ip routing-table command on PE1. No route to the peer is displayed.
3. Check OSPF configurations on PE2:
ospf
1
import-route
static
area
0.0.0.10
network 211.93.100.4
0.0.0.3
network 3.3.3.3
0.0.0.0
network 210.210.210.211
0.0.0.0
nssa
The preceding information shows that the OSPF route to Loopback1 is incorrect, and as a
result, the TCP connection between the two Loopback1 interfaces on PE1 and PE2 is not
reachable.
Procedure
Step 2 Run the ospf [ process-id ] [ router-id router-id ] command to enter the OSPF view.
Step 3 Run the area area-id command to enter the OSPF area view.
Step 4 Run the network 210.210.210.210 0.0.0.0 command to configure a correct route. After the
preceding configurations, an LDP session is established between PE1 and PE2. The fault is
rectified.
----End
Summary
By default, the LSR ID of an LDP instance is the MPLS LSR ID configured through the mpls
lsr-id command. An LDP instance will use the MPLS LSR ID if it is not configured with an
LDP LSR ID. If an LDP LSR ID is configured, it will be used to establish an LDP session. In
this case, the route to the LSR ID must be advertised in advance. Incorrect route advertisement
causes this problem. To resolve this problem, re-configure routes.
1.6.6 MPLS LDP Peer Relationship Cannot Be Established
Fault Symptom
On the network shown in Figure 1-11, MPLS is configured on a router and an MA5200G, but
MPLS LDP peer relationship cannot be established between the two devices.

Figure 1-11 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
GE1/0/0 GE1/0/0
Router MA5200G
Fault Analysis
1. Run the debugging mpls ldp all command on the router. The command output shows that
the router has not received any Hello packet from the MA5200G.
2. Run the display this command on GigabitEthernet 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
According to the mechanism for establishing LDP peer relationships, the LDP session is
triggered by multicast packets sent by 224.0.0.2. Therefore, it can be concluded that the
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
Step 2 Run the acl number acl-number command to enter the ACL view.
Step 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, the MPLS LDP peer is established. The fault is
rectified.
----End
Summary
When configuring a traffic policy on an interface, pay attention to the control of multicast packets
to avoid the situation where multicast protocol packets are rejected.

1.6.7 LDP Flaps
Fault Symptom
Figure 1-12 Diagram of the networking LDP flaps

LSR B
G E 1 /0 /0
LSR A
G E 2 /0 /0
LSR C
On the network shown in Figure 1-12, the LDP sessions on two upstream interfaces (GE 1/0/0
and GE 2/0/0) of the device alternate between Up and Down. When the telnet command is run
on the device, the device responds slowly.
Fault Analysis
1. Run the display logbuffer command to check the logs generated by the device. You can
find that LDP frequently flaps because the device cannot normally receive Keepalive
messages.
#Aug 17 12:46:40 2009 SX LDP/4/SessionDown: Session(1.1.1.1:0. public
Instance)'s state change to Down
Aug 17 2009 12:46:40 SX %%01LDP/4/SSNHOLDTMREXP(l): Sessions were deleted
because the session hold timer expired and the notification of the expiry was
sent to the peer 1.1.1.1.
The Keepalive messages of LDP are carried by TCP packets with the port number being
646.
2. Run the display health command to check the CPU usage of the device. You can find that
the CPU usage of the LPU in slot 1 and the LPU in slot 2 is high.
Slot CPU Usage Memory Usage(Used/Total)
----------------------------------------------------
10 MPU(Master) 27% 19% 378MB/1901MB
1 LPU 25% 50% 203MB/405MB
2 LPU 24% 50% 203MB/405MB
3 LPU 5% 48% 196MB/405MB
4 LPU 19% 49% 202MB/405MB
5 LPU 12% 50% 203MB/405MB
3. Run the display cpu-usage slot 1 command to check the CPU usage of the device. You
can find that the TSD task and SOCK task consume a lot of CPU resources, indicating that
a large number of packets are sent to the CPU for processing.
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage : 24% Max: 68%
CPU Usage Stat. Time : 2009-08-17 14:04:02

CPU Usage Stat. Tick : 0x15286(CPU Tick High) 0x13a9ba5e(CPU Tick Low)
Actual Stat. Cycle : 0x0(CPU Tick High) 0x77c5c6f7(CPU Tick Low)
TaskName CPU Runtime(CPU Tick High/CPU Tick Low)
BUFM 0% 0/ 20058e
VIDL 0% 0/5bcbca6e
TICK 0% 0/ 63102e
VT 0% 0/ 16d51
IPCR 0% 0/ 29fa9
VPR 0% 0/ 5ea0b28
VPS 2% 0/ 3212994
ECM 0% 0/ 474be
BEAT 0% 0/ a021c
RTMR 0% 0/ 313356
IPCQ 0% 0/ 59ad08
VP 0% 0/ 2ca
RPCQ 0% 0/ 3a660
VMON 0% 0/ 7438
STND 0% 0/ 955f3
INFO 0% 0/ 2ed9
APS 0% 0/ 8180c
FIB6 0% 0/ 124a2e
FHM 0% 0/ 969e2
BFD 0% 0/ 1117d0
OAM 0% 0/ 127ab0
SNPG 0% 0/ 1127b
ADPT 0% 0/ 450505
QAT 0% 0/ 744d
ATMA 0% 0/ de6e
LLDP 0% 0/ d6ed
SECL 0% 0/ 2318
FLD 0% 0/ 1975d
EOAM 0% 0/ a75c38
TRAF 0% 0/ fdc45
FIB 0% 0/ 19b69
SOCK 25% 0/ 615ece3
IFNT 0% 0/ 5ccbf
L2TP 0% 0/ 290e
TUNN 0% 0/ 1d36
DIAG 0% 0/ 3b8564
SRM 0% 0/ 173ee1
NPS 0% 0/ e1bb5
TSC 0% 0/ 1f9d15
TSD 5% 0/ 6b2e2f8
MAG 0% 0/ 84935e
ALT 1% 0/ 1cc6f28
TSTA 0% 0/ 10800c
ARPV 0% 0/ 3ff11
MACF 0% 0/ 2b6dd1
HQOS 0% 0/ 1efbb5
NE50 0% 0/ 12d6d
STAT 0% 0/ 5e1c3
SQOS 0% 0/ 19b02d
QOSA 0% 0/ 156699
DEFD 0% 0/ 4265
VRRP 0% 0/ 1f78
OS 7% 0/ 0
4. Capture packets on the mirrored interface. You can find that the packets are received
through GE 1/0/0 and GE 2/0/0 and the destination address of the packets is 10.1.1.255.
The destination address is a broadcast address, and is on the same network segment with
the IP address of Eth-Trunk 5. For details about the mirroring configuration, see chapter
"Mirroring Configuration" in the Configuration Guide - Security.
The preceding analysis shows that the attack packets are from GE 1/0/0 and GE 2/0/0, the
destination address of the packets is a broadcast address, and the attack packets are from
the network segment where Eth-Trunk 5 resides.

Procedure
Step 2 Run the acl number 3333 command to create ACL 3333 and configure associated ACL rules.
rule 5 permit tcp source-port eq 646
rule 15 permit tcp destination-port eq 646
rule 20 permit tcp source-port eq telnet
rule 25 permit tcp destination-port eq telnet
rule 30 permit tcp source-port eq bgp
rule 35 permit tcp destination-port eq bgp
rule 40 permit tcp source-port eq tacacs
rule 45 permit tcp destination-port eq tacacs
rule 50 permit tcp destination-port eq ftp
rule 55 permit tcp destination-port eq ftp-data
Step 3 Run the quit command to exit from the ACL view.
Step 4 Run the acl number 3334 command to create ACL 3334 and permit TCP packets.
rule 5 permit tcp
Step 5 Run the quit command to exit from the ACL view.
Step 6 Run the cpu-defend policy 5 command to create an attack defense policy and enable the
application-layer association function. Add packets matching ACL 3333 to the whitelist and
packets matching ACL 3334 to the blacklist.
whitelist acl 3333
blacklist acl 3334
application-apperceive disable
Step 7 Run the quit command to exit from the attack defense policy view.
Step 8 Run the slot 1 command to enter the slot view.
Step 9 Run the cpu-defend-policy 5 command to apply the attack defense policy on the LPU in slot 1.
Step 10 Run the slot 2 command to enter the slot view.
Step 11 Run the cpu-defend-policy 5 command to apply the attack defense policy on the LPU in slot 2.
----End
Summary
LDP flaps due to the attack by using TCP packets. After receiving attack packets, the device
sends the packets to the CPU for processing. When the packets are being sent to the CPU, normal
LDP packets and Telnet packets are discarded, causing LDP to flap. To resolve this problem,
configure a corresponding attack defense policy.
1.6.8 Route of the GRE Tunnel Flaps
Fault Symptom
NOTE
GRE cannot be configured on the X1 and X2 models of the NE80E/40E.
On the network shown in Figure 1-13, PE1 and PE2 connect to the public network by using
default routes. A GRE tunnel is set up between PE1 and PE2. A tunnel interface is configured

at each end of the tunnel, and its IP address is a private network address. The source interface
(at the local end) and destination interface (at the peer end) of the tunnel are configured on each
tunnel interface, using public network addresses. OSPF is enabled on the GRE tunnel interfaces
and direct routes are imported into OSPF.
When the configuration is complete, the route of the GRE tunnel becomes unreachable
occasionally.
Figure 1-13 Networking diagram of the flapping of the route of the GRE tunnel
Public network
PE 1 10.1.1.1 20.1.1.1 PE 2
GRE Tunnel
30.1.1.1 Tunnel1/0/1 Tunnel1/0/1 40.1.1.1
10.2.1.1 10.2.1.1
CE 1 CE 2
Fault Analysis
1. Rooting loops may exist on the network, which will cause the problem.
2. Log in to PE1 (or PE2), and then run the display ospf routing command to check the OSPF
routing table. You can find that there is an external route to the public network address of
an interface on PE2 (or PE1). Obviously, this route is imported into OSPF as a direct route
on the peer end and then learned by the local end.
3. The router considers that the direct route (that is, the GRE tunnel) can reach the public
network address of the peer end and prefers the direct route to the default route. The GRE
tunnel, however, uses the route on the public network, and this route is the default route.
Because the default route is not chosen by the router in route iteration, the GRE tunnel is
unavailable.
4. After a period of time, the OSPF neighbor relationship between the PEs goes Down, and
the public network routes learned through OSPF are lost. Then, the router can access the
public network interface of the peer PE through the default route again, and the GRE tunnel
becomes available. Then, the OSPF neighbor relationship can be set up between the PEs
again. The process repeats and causes the GRE tunnel to switch between the states of
unavailable and available.

Therefore, PE1 and PE2 need to advertise static private network routes to each other or
cancel the import of direct routes into OSPF so that OSPF will advertise only the private
network segment route of the interface.
Procedure
Step 1 Run the system-view command to enter the system view on the PE.
Step 2 Run the ip route-static ip-address { mask | mask-length } tunnel interface-number command
to advertise the static private network route to the peer PE.
NOTE
If the dynamic routing protocol needs to be used, you can configure OSPF to advertise only the private network
segment routes of interfaces: First, run the undo import-route direct command in the OSPF area view to delete
the imported direct routes. Then, run the network address wildcard-mask command to configure OSPF to
advertise only CE-side routes.
----End
Summary
When a GRE tunnel is configured, usually static private network segment routes are adopted
because they are reliable. If the customer requires a dynamic routing protocol such as OSPF,
avoid configuring import of direct routes into the routing protocol. Otherwise, route iteration
may ensue, which will cause some unexpected faults.
1.6.9 Load Imbalance Caused by Configuring LDP Transport

Addresses
Typical Networking
On the network shown in Figure 1-14, Router B is added between Router A and Router C, load
balancing is performed over two POS links between Router B and Router C.
Figure 1-14 Networking diagram for load imbalance caused by configuring LDP transport
addresses
Pos 1/0/0
Pos 2/0/0
Router A Router B Router C
After the configuration is complete, the load between C and B is totally imbalanced while that
between B and C is balanced. Statistics about traffic on C are as follows:
<HUAWEI> display interface brief
Pos1/0/0 up up 41% 1% 0 0
Pos2/0/0 up up 40% 83% 0 0

Fault Analysis
1. Check that LSPs implement load balancing on Router C.
The following command output shows that an LSP is established on POS 2/0/0, and no
LSP is established on POS 1/0/0. This result complies with the fact that there is no traffic
on POS 1/0/0.
<HUAWEI> display mpls lsp outgoing-interface Pos 1/0/0
<HUAWEI> display mpls lsp outgoing-interface Pos 2/0/0
-----------------------------------------------------------------------------
LSP Information: LDP LSP
-----------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
112.100.5.16/30 NULL/3 -/Pos2/0/0
112.100.5.16/30 1041/3 -/Pos2/0/0
112.100.7.1/32 1043/3 -/Pos2/0/0
112.100.7.1/32 NULL/3 -/Pos2/0/0
NOTE
After the display mpls lsp outgoing-interface Pos 1/0/0 command is run, no information is displayed
by the system. This means there is no LSP created on POS 1/0/0.
2. Check the causes why no LSP is created on POS 1/0/0 of Router C.
Check whether an LDP session is created first. The following command output shows that
Router C only creates an LDP peer session on POS 2/0/0. This means the configuration is
incorrect.
<HUAWEI> display mpls ldp peer
LDP Peer Information in Public network

----------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
----------------------------------------------------------------------------
112.100.7.10:0 112.100.7.10 GigabitEthernet3/0/0
112.100.7.1:0 112.100.5.5 Pos2/0/0
----------------------------------------------------------------------------
TOTAL: 10 Peer(s) Found.
3. Check the interface configuration on Router C. The transport-address command is run to

configure LDP transport addresses on both POS 1/0/0 and POS 2/0/0.
If multiple links connect two LSRs, the two LSRs must use the same transport address to
set up an LDP session between these links. This means that a single LDP session can be
established for links between two LSRs. To establish an LDP session for each link between
the two LSRs, the transport address configurations need to be deleted on both LSRs.
<HUAWEI> display current-configuration
......
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 112.100.5.6 255.255.255.252
isis enable 99
isis cost 100
ospf cost 100
mpls

mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 112.100.5.2 255.255.255.252
isis enable 99
isis cost 100
ospf cost 100
mpls
mpls ldp
#
......
Procedure
Step 1 Run the system-view command on Router C to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the undo mpls ldp transport-address command to delete the LDP transport address.
Step 4 Delete configurations on POS 1/0/0 and POS 2/0/0. After doing this, check the load balancing
status. Traffic is load-balanced bidirectionally between Router B and Router C. The fault is
rectified.
<HUAWEI> display interface brief
Pos1/0/0 up up 44% 50% 0 0
Pos2/0/0 up up 44% 50% 0 0
----End
Summary
Traffic imbalance occurs in one of the following situations:
l A specific traffic model is used.

l Routes do not carry out load balancing.
l LSPs do not carry out load balancing.
Traffic sent from Router C to Router B is not load-balanced, and Router C already exists before
Router B is added. This means the traffic model is correct and does not cause traffic imbalance.
NOTE
The Router uses the hash algorithm to load-balance packets among links based on the source address,
destination address, source port number, destination port number, and protocol type. If a special traffic
model is used, traffic imbalance occurs.

Troubleshooting - MPLS 2 MPLS TE Troubleshooting
2 MPLS TE Troubleshooting
About This Chapter
2.1 TE Tunnel Is Down
2.2 TE Tunnel Suddenly Goes Down
2.3 Loop Occurs on a TE Tunnel
2.4 Bidirectional TE Tunnel Goes Down

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that a bidirectional TE tunnel goes Down.

2.1 TE Tunnel Is Down
2.1.1 Common Causes

l The mpls te commit command is not configured to commit the TE tunnel configuration.
l CSPF fails to calculate a path.
l RSVP is not enabled on a device along the TE tunnel.
l Devices fail to exchange RSVP Path or Resv messages along the TE tunnel.

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

l Check that the mpls te commit command is configured to commit the TE tunnel
configuration.
l Check that CSPF successfully calculates a path.
l Check that RSVP is enabled on every device along the TE tunnel.
l Check that devices along the TE tunnel successfully exchange messages.

Figure 2-1 Troubleshooting flowchart for the fault that a TE tunnel is Down
TE tunnel goes
Down
The
Yes Yes
Commit Run the mpls te
Is fault rectified?
command is not commit command
run?
No
No
Route
CSPF fails Yes to the tunnel No See the section "IGP
to calculate a destination does Route
path? not exist? Troubleshooting"
Yes
No Trouble shooting
CSPF Fails
Yes Yes
RSVP is not
Enable RSVP Is fault rectified?
configured?
No
No
Yes Yes
Packet Cannot See the section "IP
Is fault rectified?
be exchanged? Forwarding Fails"
No
No
Seek technical
End
support

Context
NOTE

Procedure
Step 1 Check that the mpls te commit command has been configured to commit the TE tunnel
configuration.
Run the display current-configuration command on the ingress that is configured with the TE
tunnel.
l If the mpls te commit command is not displayed in the command output, run the mpls te
commit command.
l If the mpls te commit command is displayed in the command output but the fault persists,
go to Step 2.
Step 2 Check that CSPF has successfully calculated 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 successfully calculated paths; if
no information is displayed, CSPF failed to calculate a path.
l If CSPF failed to calculate a path, check whether routes to the destination of the TE tunnel
exist.
If no route is reachable, see The Ping Operation Fails to rectify the fault.
If reachable routes exist and the routes satisfy the requirements for establishing a TE
tunnel, run the display explicit-path command or identify interfaces that an LSP passes
through based on the network topology to check the interfaces along the tunnel. Then,
run the display this command in the interface view of each interface of the tunnel to
check whether the interface is enabled with MPLS, MPLS TE, and RSVP-TE.
If MPLS, MPLS TE, or RSVP-TE is not enabled, run the mpls, mpls te or mpls
rsvp-te commands in the view of the interface.
If any interface along the tunnel is not in Up state, restart the interface. That is, run
the shutdown and then undo shutdown commands in the interface view, or run the
restart command in the interface view.
l If CSPF has successfully calculated paths but the fault persists, go to Step 3.
Step 3 Check that RSVP is enabled on every device along the TE tunnel.
The display mpls te cspf destination ip-address explicit-path path-name command output in
Step 2 contains a series of IP addresses. These IP addresses indicate the hops along the TE tunnel.
On the interface mapped to each IP address, run the display current-configuration interface
interface-name command to check if RSVP is enabled.
l If an interface is not enabled with RSVP, enable RSVP on the interface.
l If all interfaces are enabled with RSVP but the fault persists, go to Step 4.
Step 4 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 check
fields Ingress LSR ID, LSP ID, and Session ID in the command output. In Step 3, LSRA,
LSRB, and LSRC are identified to be the nodes along the TE tunnel.
Perform the following steps to check whether the RSVP Path and Resv messages are correctly
transmitted:
l Check whether RSVP Path messages are correctly sent and received on every node along the
LSP in the sending direction (LSRA -> LSRB -> LSRC).

Run the display mpls rsvp-te psb-content command on every node along which the 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.
If the command output is empty on a node, the node fails to receive RSVP Path messages
from the upstream node.
l Check whether RSVP Resv messages are correctly transmitted in the sending direction
(LSRC -> LSRB -> LSRA).
Run the display mpls rsvp-te rsb-content command on every node along which the 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.
l If messages fail to be properly exchanged, see the section "IP Forwarding Fails" and rectify
the fault.
l If messages are properly exchanged but the fault persists, go to Step 5.
l Configuration files, log files, and alarm files of the devices
----End

Relevant Alarms
None.
Relevant Logs
None.
2.2 TE Tunnel Suddenly Goes Down
2.2.1 Common Causes

l The configuration associated with the TE tunnel is deleted manually.
l A physical interface on the TE tunnel goes Down.
l Transmission of an RSVP message times out.

The TE tunnel goes suddenly Down after being configured.


l Check whether a command is run to delete TE tunnel configuration such as MPLS or RSVP-
TE.
l Check whether a physical interface on the TE tunnel is Down.
l Check whether the transmission of RSVP message expires.
Figure 2-2 Troubleshooting flowchart for the fault that a TE tunnel goes suddenly Down
TE tunnel
goes Down
suddenly
Tunnel Yes Yes

Restore the
configuration is Is fault rectified?
configuration
deleted
No
No
Physical Yes See the section Yes

tunnel interface "Physical Is fault rectified?
is Down Interface Fails"
No
No
RSVP Yes See the section Yes

message times "IP Forwarding Is fault rectified?
out Fails"
No
No
Seek technical
End
support
Context
NOTE
Procedure
Step 1 Check whether a command has been run to delete the configuration associated with the TE
tunnel.
Run the display current-configuration command on the ingress of the TE tunnel to check
whether the following command is run:
l interface tunnel interface-number

l If the preceding command is not run, run the command.

l If the preceding command is run, go to Step 2.
Step 2 Check whether any physical interface along the TE tunnel is Down.
1. Record the time when the log IFNET/4/LINKNO_STATE indicating that the TE tunnel
goes Down was generated. Record the time as T1.
2. 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. These
IP addresses identify the nodes along the TE tunnel. Record these nodes along the TE tunnel.
3. Run the display interface interface-type interface-number command on each node of the
TE tunnel. Record the time displayed in the Last line protocol up time field as T2.
l If T1 is greater than T2, the TE tunnel went Down because the physical interface on the
TE tunnel is faulty. See the section "Physical Interface Is Faulty."
l If T1 is smaller than T2, go to Step 3.
Step 3 Check whether the transmission of RSVP message times out.
Collect logs generated 10 minutes before T1 (see Step 2) on every node along the TE tunnel to
check whether either of the following logs is displayed:
l RSVP/6/PSB_CLEAN_TIMEOUT
l RSVP/6/RSB_CLEAN_TIMEOUT
l If either of the preceding logs is displayed, see the section "IP Forwarding Fails" and rectify
the fault.
l If neither of the preceding logs is displayed, go to Step 4.
----End
Relevant Alarms
None.
Relevant Logs
IFNET/4/LINKNO_STATE
RSVP/6/PSB_CLEAN_TIMEOUT
RSVP/6/RSB_CLEAN_TIMEOUT
2.3 Loop Occurs on a TE Tunnel

2.3.1 Common Causes

l A loop occurs on the link along which an RSVP Path message travels.
l A loop occurs on the link along which an RSVP Resv message travels.

After a TE tunnel is configured, a loop occurs.

l Check that no loop occurs on the link, along which an RSVP Path message travels.
l Check that no loop occurs on the link, along which an RSVP Resv message travels.
Figure 2-3 Troubleshooting flowchart for the fault that a loop occurs on a TE tunnel
Loop occurs when
transmitting the TE
tunnel
Loop occurs Yes Delete one of two Yes

when transmitting the identical If fault rectified?
Path message? addresses
No
No
Yes Yes
Loop occurs Delete one of two
when transmitting the identical If fault rectified?
Resv message? addresses
No
No
Seek technical support End
Context
NOTE
Procedure
Step 1 Check that no loop occurs on the link along which RSVP Path messages travel.
If the log RSVP/3/LOOP_PATH is generated, a loop occurs on the link along which RSVP Path
messages travel.

Run the display mpls te cspf destination ip-address explicit-path path-name command. The
command output contains a series of IP addresses. These IP addresses and LSR IDs identify the
nodes along the TE tunnel.
On the node where the log RSVP/3/LOOP_PATH is generated, run the tracert ip-address
command. In this command, the ip-address is the IP address of each hop on the TE tunnel. If
the following information is displayed, ip-address is the same as an existing one and IP address
collision occurs.
Error: The destination address cannot be a local address.
l In the case of IP address collision, delete or change the IP address of the node.
l If no IP address collision occurs but the fault persists, go to Step 2.
Step 2 Check that no loop occurs on the link along which RSVP Resv messages travel.
If the log RSVP/3/LOOP_RESV is generated, a loop occurs on the link along which RSVP Resv
messages travel.
The troubleshooting operations are the same as that in Step 1.
l In the case of IP address collision, delete or change the IP address.

l If no IP address collision occurs but the fault persists, go to Step 3.
----End
Relevant Alarms
None.
Relevant Logs
RSVP/3/LOOP_PATH
RSVP/3/LOOP_RESV
2.4 Bidirectional TE Tunnel Goes Down

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that a bidirectional TE tunnel goes Down.
2.4.1 Common Causes

l The bidirectional TE tunnel configuration does not match the bidirectional static CR-LSP
configuration.

l MPLS TE is not enabled on the outbound interface of the bidirectional static CR-LSP that
is bound to the bidirectional TE tunnel.
l The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is Down.
l The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is allocated insufficient bandwidth.

Figure 2-4 Troubleshooting flowchart for a problem that a bidirectional TE tunnel goes Down
Bidirectional TE
Tunnel goes Down
No Check that the Yes

Is the bidirectional Is the fault
TE tunnel correctly bidirectional TE tunnel is
correctly configured rectified
configured
No
Yes
Is outbound No See "Physical Yes

interface of the Interconnection Is the fault
bidirectional static Troubleshooting." rectified
CR-LSP Up
No
Yes
Check that the Configure the remaining

No bandwidth of outbound Yes
remaining bandwidth Is the fault
meets the interface to meet the rectified
requirements requirements
No
Yes
Ask for technical

support End
Context
NOTE

Procedure
Step 1 Run the display current-configuration command on the nodes where the tunnel is set up to
check that the bidirectional TE tunnel is correctly configured.
l Ingress:
If the tunnel is not enabled with the bidirectional LSP attribute, run the mpls te
bidirectional command in the tunnel view to enable the bidirectional LSP attribute.
This tunnel is an ingress tunnel and is bound to a bidirectional static LSP.
If the name of the bidirectional static CR-LSP on the ingress is different from the name
of the tunnel, run the bidirectional static-cr-lsp ingress tunnel-name command to
change the name of the bidirectional static CR-LSP.
l Egress:
If the reverse tunnel attribute is not enabled for the tunnel, run the mpls te passive-
tunnel command to enable the reverse tunnel attribute. The reverse tunnel itself does
not trigger the generation of a CR-LSP but can be bound to a reverse LSP for upper
layer applications.
If the tunnel is not bound to a bidirectional static LSP, run the mpls te binding command
to bind the tunnel to a bidirectional static LSP on the egress.
If the fault persists, go to Step 2.
Step 2 Check the status of the outbound interface of the bidirectional static CR-LSP that is bound to
the bidirectional TE tunnel.
Run the display ip interface brief command on the tunnel node to view the status of the
outbound interface.
l If the outbound interface is Down, see "Physical Interconnection Troubleshooting."
l If the outbound interface is Up, go to Step 3.
Step 3 Check that the sufficient bandwidth is allocated to the outbound interface of the bidirectional
static CR-LSP that is bound to the bidirectional TE tunnel.
Run the display mpls te link-administration bandwidth-allocation command on the tunnel

node to view the bandwidth allocation information on all MPLS TE interfaces.
l If the remaining bandwidth of the outbound interface of the bidirectional static CR-LSP is
less than the configured value, reconfigure the remaining bandwidth.
l If the remaining bandwidth of the outbound interface of the bidirectional static CR-LSP is
greater than the configured value, go to Step 4.
Step 4 Collect the following information and contact Huawei technical support personnel:
l Configuration, log, and alarm files
----End

None.

2.5.1 A Loop Occurs Because of the Undeleted IP Address of an

Interface That Has Been Shut Down on an RSVP-TE Tunnel
Fault Symptom
On the network shown in Figure 2-5, 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 successfully set up, but the tunnel from LSRA to
LSRD fails to be set up.
Figure 2-5 Networking diagram for a loop caused by the undeleted IP address of an interface
that has been shut down on an RSVP-TE Tunnel
POS2/0/0
192.168.30.1/30
LSRB LSRC
POS1/0/1
192.168.30.2/30
GE1/0/0 GE2/0/0
LSRA LSRD
GE1/0/1
192.168.30.1/30 LSRE
Loopback1 Loopback1
10.1.1.1/32 10.1.1.2/32
Interface that is shut down
Fault Analysis
1. Run the display mpls te tunnel command on LSRA. A single tunnel is successfully set
up.
<LSRA> display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.1.1.2 10.1.1.1 8 --/3 I Tunnel0/0/1
2. Run the terminal monitor command to enable the display of debugging information and
the terminal debugging command to enable debugging on LSRD. Debugging information
RSVP/3/LOOP_PATH or RSVP/3/LOOP_RESV shows that a loop is generated on LSRD.

3. Run the display current-configuration interface tunnel0/0/1 command on LSRA to

check tunnel configurations. The mpls te record-route command has been configured for
the tunnel (from LSRA to LSRD) that fails to be established.
4. Run the undo mpls te record-route command and the mpls te commit command on
LSRA. The tunnel from LSRA to LSRD is set up successfully.
If you enable MPLS TE FRR, the route record function will be automatically enabled. The
problem will recur. The cause has not been located yet.
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 configurations. An
interface on LSRD is shut down, and its IP address that is not deleted is the same as that
of POS 2/0/0 on LSRB, causing the failure in establishing the tunnel from LSRA to LSRD.
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 path from LSRA to LSRD.
As the route record function is enabled using the mpls te record-route command, the IP
address of each hop along the path is added to the RSVP Path message. After receiving the
RSVP Path message, LSRD detects that 192.168.30.1 added to the message is the same as
the IP address of its interface. Although LSRD's interface with the IP address of
192.168.30.1 has been shut down, its address is not deleted, resulting in two identical
addresses. LSRD considers that a loop occurs and therefore sends the alarm and rejects the
request for resources.
Run the following commands on LSRD to clear the fault:
Procedure
Step 2 Run the interface gigabitethernet1/0/1 command to enter the view of GE 1/0/1.
Step 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 completing the preceding operations, run the display mpls te tunnel command on LSRA.
The tunnel from LSRA to LSRD has been successfully set up. The fault is cleared.
<LSRA> display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.1.1.2 10.1.1.1 8 --/3 I Tunnel0/0/1
10.1.1.1 10.1.1.2 1 --/3 I Tunnel0/0/1
----End
Summary
Deleting configurations that are no longer used on interfaces is recommended to prevent
unpredictable errors.

2.5.2 Tunnel Goes Down Suddenly and Then Up
Fault Symptom
As shown in Figure 2-6, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress).
After the RSVP-TE tunnel is Up, it suddenly goes Down and then Up again.
Figure 2-6 Networking diagram of MPLS TE

GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
1. Run the display current-configuration interface tunnel interface-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 interface-number command to check the path of the
RSVP-TE tunnel.
2. View the logs on LSRA (ingress), or run the display logbuffer command to check the point
time T when the RSVP-TE tunnel goes Down.
3. Check whether the physical link of the RSVP-TE tunnel is faulty at the time T using the
following methods.
l View the logs on each device along the RSVP-TE tunnel to check whether the following
information is displayed:
Dec 23 2008 14:54:37 LSRA %%01IFNET/4/LINKNO_STATE(l): The line protocol on
the interface GigabitEthernet1/0/0 has entered the DOWN state.
Check whether the time when the physical outgoing interface along the RSVP-TE tunnel
goes Down is the same as the time when the tunnel interface goes Down. If so, the
physical outgoing interface is faulty, which causes the RSVP-TE tunnel to go Down.
l 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.
According to the command output, the time displayed in the Last line protocol up
time field is later than the point time T when the RSVP-TE tunnel goes Down. This
means that the physical interface has been faulty before the point time T, which causes
the RSVP-TE tunnel to go Down.
Procedure
Step 1 The RSVP-TE tunnel goes Up again, and no action is required.
----End

Summary
On the live network, the tunnel usually goes Down because a physical interface is Down. View
the log or run the display interface interface-type interface-number command to check the status
of each physical interface to find out the physical interface that goes Down.
2.5.3 Fast Check and Rectify the Problem of Route Loops
Fault Symptom
As shown in Figure 2-7, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress).
After the configuration is complete, the interface of the RSVP-TE tunnel cannot go Up.
Figure 2-7 Networking diagram for MPLS TE

Loopback0 Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE2/0/0 GE1/0/0

10.1.1.1/30 10.2.1.1/30 10.2.1.2/30
GE1/0/0
GE3/0/0 GE2/0/0
LSRA 10.1.1.2/30 LSRB 10.3.1.1/30 10.3.1.2/30 LSRC
Fault Analysis
LSRA to check 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 been successful in calculating paths; if no
information is displayed, CSPF failed to calculate a path.
3. Check the logs on LSRA, LSRB, and LSRC. The following information is displayed on
LSRC.
Dec 23 2008 17:43:35 LSRC %%01RSVP/3/LOOP_PATH(1): There is a loop in path
message. (TunnelId=100, EgressAddress=3.3.3.3)
According to the log, the Path message detects a loop.
Procedure
Step 1 Run the display current-configuration interface tunnel interface-number command on LSRA
to check the tunnel configuration. The command output shows information about the configured
explicit path and routes, which identifies the path of the RSVP-TE tunnel. In the following
example, information about the path of the RSVP-TE tunnel is displayed.
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
Step 2 The loop is detected on LSRC. This means that an IP address on LSRC is the same as the IP
address of the RSVP-TE tunnel (except Hop 5 and Hop 6 of LSRC itself). The IP address of
LSRC is the same as one of the IP addresses of Hop 1 to Hop 4. Use each IP address from Hop
1 to Hop 4 to run the tracert ip-address command on LSRC to find the conflicted IP address.
The command output is as follows:
<LSRC> tracert 10.1.1.2
Tracertoute: Destination can not be a local address
According to the command output, the IP address 10.1.1.2 on LSRC is duplicated.
Step 3 Run the display ip interface brief command on LSRC to search for 10.1.1.2 and then delete it.
After the preceding operations, run the display interface tunnel interface-number command.
If the tunnel interface is Up, the fault is rectified.
----End
Summary
When a loop causes the tunnel setup failure, you can view logs to identify the device on which
the loop occurs. Then, run the tracert ip-address command on the device, and you can quickly
find the conflicted IP address.
2.5.4 Tunnel Flaps Every Several Minutes After IGP Shortcut Is

Enabled
Fault Symptom
As shown in Figure 2-8, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress)
and IGP shortcut is enabled on LSRA. After the RSVP-TE tunnel goes Up, it flaps every several
minutes.

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis

command output shows that the configurations are correct. IGP shortcut is enabled on the
tunnel interface and the explicit path is not configured.
#
interface Tunnel1/0/0
ip address unnumbered interface Loopback0
tunnel-protocol mpls te
destination 3.3.3.3
mpls te tunnel-id 100
mpls te record-route label
mpls te bandwidth bc0 100000
mpls te igp shortcut ospf
mpls te igp metric absolute 10
mpls te commit
#
According to the command output, CSPF is not enabled in the MPLS view.
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
2. Before the RSVP-TE tunnel goes Up, the route to the destination address of the RSVP-TE
tunnel passes the physical interface GE1/0/0. After the RSVP-TE tunnel goes Up, the route
to the destination address of the RSVP-TE tunnel passes along the path of the RSVP-TE
tunnel itself, because IGP route calculation counts in the tunnel.
<LSRA> display ip routing-table 3.3.3.3
------------------------------------------------------------------------------
----
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop

Interface
3.3.3.3/32 OSPF 10 3 D 1.1.1.1
Tunnel1/0/0
3. Before the RSVP-TE tunnel goes Up, because CSPF is not enabled and the explicit path is
not configured, RSVP sends the Path message through the physical interface according to
the routing table. After the RSVP-TE tunnel goes Up, the route to the destination address
of the RSVP-TE tunnel passes the path of the RSVP-TE tunnel itself, because the IGP route
calculation counts in the tunnel. Then, RSVP fails to search routes and the Path message
cannot be updated. As a result, the RSVP-TE tunnel is deleted because the Path message
times out.
4. After the RSVP-TE tunnel is torn down, the physical interface is used as the outgoing
interface of the route, and the Path message can be sent normally. Then, the RSVP-TE
tunnel goes Up again. Then, the IGP route calculation counts in the tunnel. As a result, the
Path message fails to be sent and the RSVP-TE tunnel is torn down after the Path message
times out. Tunnel flapping occurs.
Procedure
Step 1 Choose one of the following procedures:
l Enable CSPF on LSRA.
1. Run the system-view command to enter the system view.
2. Run the mpls command to enter the MPLS view.

3. Run the mpls te cspf command to enable CSPF.

l Alternatively, create an explicit path.
2. Run the explicit-path path-name command to configure an explicit path.
3. Run the next hop ip-address command to assign an IP address for the next hop along
the explicit path.
4. Run the quit command to return to the system view.
5. Run the interface tunnel interface-number command to enter the tunnel interface view.
6. Run the mpls te path explicit-path path-name command to configure an explicit path
for the tunnel.
7. Run the mpls te commit command to commit the configuration.
After the preceding operations, wait 5 minutes or 6 minutes after the tunnel goes Up. Tunnel
flapping does not occur and the fault is rectified.
----End
Summary
If IGP shortcut is enabled on a tunnel, the CSPF must be enabled or an explicit path must be set
up. Otherwise, tunnel flapping occurs.
2.5.5 TE Tunnel of the Inter-OSPF Area Fails to Be Set Up
Fault Symptom
As shown in Figure 2-9, LSRA and LSRB are in Area0, and LSRC and LSRD are in Area1. An
RSVP-TE tunnel is set up along the path LSRA -> LSRB -> LSRC -> LSRD. After the
configuration is complete, the RSVP-TE tunnel fails to be set up.
Figure 2-9 Networking diagram for MPLS TE tunnel over inter-area

Loopback0 Loopback0 Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
GE1/0/0 GE2/0/0 GE2/0/0

10.1.2.1/30 10.2.3.1/30 10.1.4.1/30
GE1/0/0 GE1/0/0 GE1/0/0
LSRA 10.1.2.2/30 LSRB 10.2.3.2/32 LSRC 10.3.4.2/30 LSRD
Fault Analysis
command output shows that the configurations are correct.


LSRA to check the tunnel configuration. The command output shows that an explicit path
is set up on the tunnel interface.
<LSRA> display current-configuration interface tunnel 1/0/0
#
Interface Tunnel1/0/0
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
mpls te commit
#
return
3. Run the display explicit-path path-name command. The command output shows
information about the explicit path.
<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 check the 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 check the result of CSPF calculation. The command output shows
that the calculated path is not complete, which may be resulted from the incomplete explicit
path.
<LSRA> display mpls te cspf destination 4.4.4.4 explicit-path path1
Path for the given constraints is:
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
Step 2 Run the interface tunnel interface-number command to enter the tunnel interface view.
Step 3 Run the undo mpls te path command to delete the explicit path of the tunnel.
Step 4 Run the mpls te commit command to commit the configuration.
Step 5 Run the quit command to return to the system view.
Step 6 Run the explicit-path explicit-path command to enter the explicit path view.
Step 7 Run the next hop 10.2.3.2 command to specify 10.2.3.2 as the IP address of the next hop along
the explicit path.

Step 8 Run the next hop 10.3.4.2 command to specify 10.3.4.2 as the IP address of the next hop along
the explicit path.
Step 11 Run the mpls te path explicit-path path-name command to configure the explicit path of the
tunnel.
After the preceding configurations, run the display mpls te tunnel-interface command on
LSRA. The command output shows that the tunnel interface goes Up and the fault is rectified.
----End
Summary
On the 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.
2.5.6 Tunnel Goes Down After Switchover
Fault Symptom
As shown in Figure 2-10, multiple RSVP-TE tunnels are set up from LSRA (ingress) to LSRC
(egress). After a master/slave switchover is performed on LSRA, all RSVP-TE tunnels that pass
through LSRA go Down.

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
command hop by hop to check the configurations of MPLS, MPLS TE, RSVP-TE, and
RSVP-TE Hello mechanism. The command output shows that the configurations are
correct.

2. Run the display mpls rsvp-te graceful-restart peer command on LSRA and LSRB to
view the Neighbor Capability field to check whether RSVP GR on the neighbor is
supported. The field is Can Support GR, indicating that the neighbor supports RSVP GR.
3. Run the display mpls rsvp-te graceful-restart command on LSRA and LSRB to check
whether RSVP GR is supported. In the following example, the display on LSRA is used.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 1.1.1.1
Graceful-Restart Capability: None
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0
Received RecoveryPath message count: 0
Send Recovertpath message count: 0
According to the command output, RSVP GR is not enabled on LSRA or LSRB.
Procedure
Step 1 Perform the following steps on LSRA and LSRB:
2. Run the mpls command to enter the MPLS view.
3. Run the mpls rsvp-te hello full-gr command to enable RSVP GR.
After the preceding operations, run the display mpls rsvp-te graceful-restart command on
LSRA and LSRB to check whether RSVP GR is supported. In the following example, the display
on LSRA is used.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSRID: 1.1.1.1
Graceful-Restart Capability: GR-Self GR-Support
Restart Time: 90000 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0
Received RecoveryPath message count: 0
Send Recovertpath message count: 0
According to the command output, LSRA supports GR. Perform switchover to check the status
of the tunnel. The tunnel remains to be Up and the fault is rectified.
----End
Summary
If a tunnel goes Down after a switchover is performed, verify that the configurations on devices
are correct, that the RSVP-TE Hello mechanism is configured in both the system and interface
views, and that RSVP GR is configured correctly.
2.5.7 Tunnel Creation Fails Because of Authentication Failure

Fault Symptom
The tunnel from Router A to Router C goes Down.

Configure MPLS VPN based on the network shown in Figure 2-11.
Figure 2-11 Networking diagram for MPLS VPN
POS1/0/0 POS1/0/0
200.1.1.1/24 200.1.1.2/24 POS2/0/0 POS1/0/0
Fault Analysis
1. Use the display current-configuration interface tunnel interface-type interface-
number command on Router A. The tunnel configurations are correct.
2. Use the display mpls te cspf tedb all command on Router A. The CSPF TEDB information
is correct.
3. Use the display mpls rsvp-te statistics global command on Router A and Router B.
Statistics on Router A are as follows:
Total Statistics Information:
PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 2 RecPacketCounter: 0
SendPathCounter: 1 RecPathCounter: 0
SendResvCounter: 0 RecResvCounter: 0
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
SendErrMsgCounter: 0 RecErrMsgCounter: 0
RecReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0
Statistics on Router B are as follows:

Total Statistics Information:
PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 0 RecPacketCounter: 2
SendPathCounter: 0 RecPathCounter: 0
SendResvCounter: 0 RecResvCounter: 0
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
SendErrMsgCounter: 0 RecErrMsgCounter:
RecReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0

The preceding command output shows that "RecPacketCounter" is not zero on Router B
and the number of all types of messages is zero. A defect occurs when packets are pre-
processed. A possible cause is that invalid packets are received or RSVP authentication
fails.
4. Use the display current-configuration interface command on Router A and Router B.
The display on Router B is as follows:
interface POS1/0/0
ip address 200.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 12345678
The display on Router A is as follows:

interface POS1/0/0
ip address 200.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 10000
mpls rsvp-te
The preceding command output shows that RSVP is configured on the interface of Router
B but not of Router A. The authentication of the packets sent by Router A to Router B fails
and the tunnel cannot be set up.
Procedure
Step 1 On Router A, run the display mpls te tunnel-interface command to check the current tunnel
status.
Step 2 Run the interface interface-type interface-number command to enter the interface view of POS
1/0/0.
Step 3 Run the mpls rsvp-te authentication { cipher | plain } auth-key command to configure RSVP
authentication. The keys on both ends must be the same.
After completing the preceding operation, run the display mpls te tunnel-interface command
on Router A. The tunnel interface goes Up, and the fault is removed.
----End
Summary
Check statistics about the sent and received packets carefully to rectify the fault.
2.5.8 Calculation of the Tunnel Path Fails
Fault Symptom
Based on the network shown in Figure 2-12, configure MPLS TE. An MPLS TE tunnel named
Tunnel1/0/0 is established from Router A to Router D. After the configuration, the mpls te
commit is run on Tunnel1/0/0 of Router A, but the MPLS TE tunnel cannot be established.

Figure 2-12 Networking diagram of MPLS TE

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0 GE3/0/0

GE1/0/0 GE3/0/0 GE1/0/0
RouterA RouterB RouterC RouterD
GE2/0/0 GE2/0/0
GE1/0/0 GE2/0/0
RouterE
Loopback1
5.5.5.9/32
After the configurations, the CR-LSP setup between Router A and Router D fails.
Fault Analysis
1. Using the debugging mpls te cspf all command on Router A, you can find the faulty CSPF
calculation.
01:6821: The current computation is loose
*0.10305390 RouterA CSPF/8/ERROR:
01:7000: Destination node is unreachable
01:7002: Error configuration or all the nodes can not fulfil the path request
01:6640: The first segment computation is failure
*0.10305390 RouterA CSPF/8/COMPUTE:
01:7264: The CSPF path computation is failed
2. Using the display mpls te cspf tedb node command on Router A, you can view the TEDB
on each node. Check whether various attributes of IP addresses of interfaces such as the
color and the maximum reservable bandwidth of TE Class can meet the requirements.
You can find that the path calculation fails because of unavailable link bandwidth. The
destination address is unreachable.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the interface view of the
interface on which the bandwidth cannot meet the requirement.
Step 3 Run thempls 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 Router A. Therefore, the bandwidth of all nodes can meet the requirement.
Step 5 Run the mpls te bandwidth command to change the bandwidth of the tunnel.

Run the display mpls te tunnel-interface command on Router A to view the status of CR-LSPs
and the tunnel. Both CR-LSPs and the tunnel go Up. The fault is then rectified.
----End
Summary
When tunnel path calculation fails, that is, when "Destination node is unreachable" is displayed,
the fault mainly lies in the wrong configuration or the unavailable node resource.
2.5.9 Path with the Smallest Metric Is Not Selected

Fault Symptom
Configure MPLS TE based on the network shown in Figure 2-13, configure MPLS TE. The
default metric of all the interfaces on the devices is 10. The optimal path is Router A ->
Router B -> Router C -> Router 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 Router A ->Router B -> Router E ->Router C ->Router D, which
is not an optimal path.
Figure 2-13 Typical networking for MPLS TE

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE3/0/0 GE1/0/0 GE3/0/0 GE1/0/0
GE1/0/0
GE1/0/0 GE2/0/0 GE2/0/0
RouterA RouterB GE2/0/0 RouterC RouterD
GE2/0/0
GE1/0/0
RouterE GE3/0/0
Loopback1
5.5.5.9/32
Fault Analysis
1. Run the display mpls te cspf tedb command on Router A. The database on Router B -->
Router E --> Router 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 Router B is changed to 100
before the tunnel is created. During the new tunnel configuration, the metric recovers to
the default value.

At first, the path Router A --> Router B --> Router E --> Router C --> Router D is selected
in CSPF calculation. After the link metric restores, the path is not recalculated and the
tunnel does not select the path with the smallest metric.
Procedure
Step 1 On Router A, run the system-view command to enter the system view.
Step 3 Run the mpls te reoptimization command to enable the periodical optimization.
Step 4 Run the return command to return to the user view.
Step 5 Run the mpls te reoptimization command to trigger the optimization immediately.
On Router A, run the display mpls te tunnel path command to view the tunnel path. The path
with the smallest metric is selected. The fault is rectified.
----End
Summary
Removing this fault depends on the TE feature that is driven by configuration, not by topology.
You can configure re-optimization to prevent this fault.
2.5.10 Establishment of the Hot-Standby LSP Fails

Fault Symptom
Configure MPLS TE based on the network shown in Figure 2-14.

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0 GE3/0/0

GE1/0/0 GE3/0/0 GE1/0/0
RouterA RouterB RouterC RouterD
GE2/0/0 GE2/0/0
GE1/0/0 GE2/0/0
RouterE
Loopback1
5.5.5.9/32
After the configuration is complete, the tunnel from Router B to Router C is created but the hot-
standby LSP fails to be set up.

Use the display mpls te tunnel-interface tunnel 1/0/0 command. The display is as follows:
Primary CR-LSP UP and HotBackup CR-LSP setting Up
The command output shows that the establishment of the primary tunnel succeeds, but the
establishment of the backup LSP fails.
Fault Analysis
1. Using the display mpls te tunnel path command on Router A to view the primary LSP of
the tunnel. The path Router A -> Router B -> Router C is used.
2. Use the debugging mpls te management states command on Router A to view the tunnel
status.
State Change :Tunnel %s enters HBKP_WAITFORCSPF state from HBKP_USEDIDLE state
The preceding display shows that the hot-standby requires CSPF calculation but fails.
3. Using the debugging mpls te cspf tedb errors command on Router A. CSPF calculation
fails and the path to the destination address is unavailable.
Destination node is unreachable
01:7050:Error configuration or all the nodes can not fulfil the path request.
4. Using the display mpls te cspf tedb node command to check the CSPF database. Note
that the bandwidth of GE 2/0/0 on Router E is not adequate to set up the bypass LSP.
Procedure
Step 1 On Router E, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view of GE
2/0/0 on which the bandwidth is too low.
Step 3 Run the mpls te bandwidth max-reservable-bandwidth command to modify the maximum
reservable bandwidth of the link.
Run the display mpls te tunnel-interface tunnel 1/0/0 command on Router A to change the
bandwidth. After this, the standby LSP is set up. The fault is rectified.
----End
Summary
The key point of the example lies in the CR-LSP backup mechanism. The bandwidth of the
backup LSP cannot be configured through a command line but are inherited from the primary
LSP.
2.5.11 FRR Binding Fails
Fault Symptom
Configure MLS TE based on the network shown in Figure 2-15.


1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE3/0/0 GE1/0/0 GE3/0/0 GE1/0/0
GE1/0/0
GE1/0/0 GE2/0/0 GE2/0/0
RouterA RouterB GE2/0/0 RouterC RouterD
GE2/0/0
GE1/0/0
RouterE GE3/0/0
Loopback1
5.5.5.9/32
The primary tunnel path is Router A --> Router B --> Router E --> Router C --> Router D. Then
create a Bypass tunnel between Router B and Router D, specifying Router E as the loose node.
After the configuration, FRR binding fails.
Fault Analysis
1. Use the debugging mpls te management fast-reroute command on Router A or Router
B to enable FRR debugging and view the binding states of the main tunnel and the bypass
tunnel. The following display prompts:
Error: Optimal Bypass tunnel not found for Tunnel
2. Use the display mpls te tunnel path command to check the used paths in the tunnel. The
primary tunnel uses the path Router A --> Router B --> Router C --> Router D and the
backup tunnel uses the path Router B --> Router E --> Router C --> Router D. There are
some coincident nodes between the PLR and the MP on the primary and backup tunnels,
leading to FRR binding fails.
Procedure
Step 1 On Router B, run the system-view command to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the interface view of the bypass
tunnel.
Step 3 Run the undo mpls te path command to delete the explicit path on the tunnel interface.
Step 6 Run the explicit-path path-name command to enter the explicit path view of the bypass tunnel.
Step 7 Run the add hop ip-address before 5.5.5.9 command to add the IP address of GE 1/0/0 of Router
E before 5.5.5.9.

Step 8 Run the add hop ip-address before 4.4.4.9 command to add the IP address of GE 2/0/0 of Router
D before 4.4.4.9.
Step 10 Run the interface tunnel interface-number command to enter the interface view of the bypass
tunnel.
Step 11 Run the mpls te path explicit-path path-name command to re-designate an explicit path.
Use the display mpls te tunnel-interface [ tunnel interface-number ] command to view the
LSP on Router A. The FRR binding succeeds. The fault is removed.
----End
Summary
In FRR configuration, to ensure the successful binding, specify the strict explicit paths of the
primary and bypass tunnels. If loose explicit paths are used, the binding fails when the coincident
nodes exist between the PLR and the MP.
2.5.12 Primary Tunnel Turns Down When Configuration of the

Bypass Tunnel Is Modified
Fault Symptom
As shown in Figure 2-16, a primary tunnel Tunnel 1/0/00/0/1 is set up along the path Router A
--> Router B --> Router C, and a bypass tunnel is set up on the path Router B --> Router D
--> Router C.
Figure 2-16 Networking diagram in which the configuration of the bypass tunnel is modified
Primary LSP
Bypass LSP
RouterD
After the configuration is complete, shut down the outgoing interface from Router B to Router
C to make the bypass tunnel turn to in-use. After the configuration of the bypass tunnel is
modified and the new configuration is committed, the primary tunnel goes Down.

Fault Analysis
During modification of the bypass tunnel, a phase called make-before-break exists. A new CR-
LSP is set up before the previous CR-LSP is removed.
After the previous CR-LSP is removed, the binding relationship between the primary and bypass
tunnels is also removed. The primary tunnel, therefore, goes Down because the newly established
bypass tunnel cannot set up the binding relationship with the primary tunnel.
Procedure
Step 1 On Router B, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to the view of the interface
connected to Router C.
Step 3 Run the undo shutdown command to restore the primary tunnel and bind the primary tunnel to
the bypass tunnel again.
Run the display mpls te tunnel-interface [ tunnel interface-number ] command on Router A.

The establishment of the primary and bypass tunnels succeeds. The fault is removed.
----End
Summary
Do not modify the configuration of bypass tunnels when the bypass tunnel is in use.
2.5.13 After the Primary Tunnel Fails, Traffic Does Not Switch to
an HSB Tunnel
Fault Symptom
On the network shown in Figure 2-17, an RSVP-TE tunnel is set up 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 set up from 10.4.1.1
to 10.4.1.2. After the outbound GE 2/0/0 on LSRB fails, traffic does not switch to the HSB tunnel
from 10.4.1.1 to 10.4.1.2.
Figure 2-17 Networking diagram for the problem that after the primary tunnel fails, traffic does
not switch to an HSB tunnel
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE2/0/0 GE1/0/0

10.1.1.1/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRC
GE1/0/0 GE3/0/0 GE2/0/0
GE2/0/0 10.1.1.2/30 LSRB 10.3.1.1/30 10.3.1.2/30 GE3/0/0
10.4.1.1/30 10.4.1.2/30

Fault Analysis
LSRA to check the explicit path LSRA -> LSRB -> LSRC.
2. Run the display explicit-path [ path-name ] [ tunnel-interface | verbose ] command on
LSRA to check the explicit path information and the tunnel using the explicit path. The
explicit path includes LSRA and LSRB, but not LSRC, for the primary tunnel.
3. Run the display mpls te tunnel path tunnel-name command on LSRA to check 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 set up 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 travels through the HSB tunnel is not
affected.
Procedure
Step 1 Run the system-view command on LSRA to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the view of the MPLS TE tunnel
interface.
Step 3 Run the undo mpls te path command to delete the loose explicit path LSRA -> LSRB -> LSRC.
Step 4 Run the quit command to exit from the tunnel interface view.
Step 5 Run the explicit-path path-name command to enter the view of the loose explicit path LSRA -
> LSRB -> LSRC.
Step 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.
Step 7 Run the quit command to exit from the explicit path view.
Step 8 Run the interface tunnel interface-number command to enter the view of the MPLS TE tunnel
interface.
Step 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.
Step 10 Run the mpls te commit command to make the configurations take effect. The fault is rectified.
----End
Summary
Using a strict explicit path is recommended for the primary tunnel which is supposed to forward
traffic over a pre-configured explicit path.

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

Route
Fault Symptom
On the network shown in Figure 2-18, an MPLS LDP LSP is established between LSRA and
LSRB. The next-hop route from LSRA to LSRB changes, which causes the VPN route unable
to be iterated to the LDP LSP. As a result, VPN services are interrupted from LSRA to LSRB.
Figure 2-18 Networking diagram for the problem that VPN traffic loss is caused by a change
in the next-hop route
Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
LSRA 10.1.1.1/24 10.1.1.2/24 LSRB
Primary
GE2/0/0 GE2/0/0
10.1.2.1/24 Backup 10.1.3.2/24
GE1/0/0 GE2/0/0
10.1.2.2/24 10.1.3.1/24
LSRC
Loopback0
3.3.3.3/32
Fault Analysis
1. Run the display ip routing-table 2.2.2.2 32 command. The route to LSRB is displayed.
For example:
<LSRA> display ip routing-table 2.2.2.2 32
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
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) has been changed. The
primary LSP fails, 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. Directly connected interfaces on
LSRA and LSRC have not been enabled with MPLS LDP.

Procedure
Step 1 Run the system-view command on LSRA, LSRB, and LSRC to enter the system view.
Step 2 Run the interface interface-type interface-number command on LSRA, LSRB, and LSRC to
enter the interface view.
Step 3 Run the mpls command on LSRA, LSRB, and LSRC to enable MPLS for interfaces on the
backup LSP.
Step 4 Run the mpls ldp command on LSRA, LSRB, and LSRC to enable MPLS LDP for interfaces
on the backup LSP. The fault is rectified.
----End
Summary
Enabling MPLS LDP on the entire network ensures that an LSP is established successfully even
if the next-hop route changes, preventing VPN traffic loss.
2.5.15 Volume of Service Traffic on Interfaces of a Device Is

Unstable
Fault Symptom
On the network shown in Figure 2-19, normal service traffic reaches Router B from Router C
and Router D, and then is forwarded by Router B to Router E (the arrow line marked red indicates
the model of the normal service traffic). Based on network planning, traffic should be sent
through POS 5/0/0 but actually sent through POS 3/0/0 and POS 4/0/0 of Router A, and then
reaches Router E (the arrow line marked blue indicates the model of the service traffic in the
case of a fault). After the configuration, it is found that the volume of traffic on POS 3/0/0
connecting Router B to Router A suddenly exceeds 1 Gbit/s, whereas the volume of traffic on
POS 5/0/0 connecting Router B to Router E reduces by more than 1 Gbit/s. Services, however,
are not affected.

Figure 2-19 Diagram of the networking where the volume of service traffic on interfaces of a
device is unstable
RouterC RouterD
POS1/0/0 POS2/0/0
RouterB
POS3/0/0 POS5/0/0
POS4/0/0
RouterA RouterE
Fault Analysis
1. Capture packets on the mirrored interface. You can find that the source address of the
packets is 1.1.1.1, and the destination address of the packets is 2.2.2.2. For details about
the mirroring configuration, see chapter "Mirroring Configuration" in the Configuration
Guide - Security.
2. Run the display fib 2.2.2.2 command on Router B to check the route destined for 2.2.2.2.
Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface
TunnelID
2.2.0.0/17 1.1.2.2 DGU t[3530817] Pos5/0/0
0x0
The command output shows that the packets are forwarded by the POS board in slot 5 and
the value of TunnelID is 0, which indicates that the packets are forwarded through IP.
Therefore, packet forwarding may fail on Router B.
3. Run the display ip routing-table 1.1.1.1 command on Router B to identify the interfaces
that send the packets out.
Route Flags: R - relay, D - download to
fib
------------------------------------------------------------------------------
Routing Table :
Public
Summary Count :

Destination/Mask Proto Pre Cost Flags NextHop

Interface
1.1.1.0/25 BGP 255 0 RD 4.4.4.1

Pos1/0/0
BGP 255 0 RD 4.4.4.1 Pos2/0/0
The command output shows that the packets are sent from POS 1/0/0 and POS 2/0/0.
4. Run the display fib 2.2.2.2 command on Router C to check the route destined for 2.2.2.2.
Route Entry Count:
2
Destination/Mask Nexthop Flag TimeStamp Interface
TunnelID
2.2.0.0/17 3.3.3.3 DGU t[3361320] Pos1/0/0
0x40b3e0
2.2.0.0/17 3.3.4.4 DGU t[3361320] Pos3/0/0
0xc0b3de
The value of TunnelID shows that the packets are forwarded through MPLS.
Run the display tunnel-info 40b3e0 command to check the details.
Tunnel ID: 0x40b3e0
Tunnel Token:
13280
Type:
lsp
Destination: 3.3.4.3
Out Slot:
1
Instance ID:
0
Out Interface: Pos1/0/0
Out Label: 1097
Next Hop: 3.3.3.3
5. Run the display mpls lsp in-label 1097 command on Router B to check the MPLS
forwarding table of Router B based on outbound labels.
----------------------------------------------------------------------
LSP Information: LDP

LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf

Name
3.3.4.3/32 1097/3 -/
Pos3/0/0
3.3.4.3/32 1097/3 -/Pos4/0/0
The command output shows that MPLS load balancing is performed among two paths for
the packets. The outbound interface of one path is POS 3/0/0, and the outbound interface
of the other path is POS 4/0/0. Because flow-by-flow load balancing is adopted, packets
are sent through POS 3/0/0 based on the hash algorithm. In addition, packets are forwarded
through MPLS rather than IP on Router B.
6. Check the configuration of Router C. You can find that the route recursive-lookup
tunnel command is run on Router C. After the route recursive-lookup tunnel command
is run, the entire device becomes valid, unlabeled routes of the public network are iterated
to LSP tunnels, and packets are forwarded through MPLS.
7. Run the display mpls lsp include 3.3.4.3 32 verbose command on Router A to check the
routes iterated to LSP tunnels.

----------------------------------------------------------------------
LSP Information: LDP

LSP
----------------------------------------------------------------------
No :
1
VrfIndex :
Fec :
3.3.4.3/32
Nexthop :
3.3.3.3
In-Label :
NULL
Out-Label :
3
In-Interface :
----------
Out-Interface :
Pos1/0/0
LspIndex :
44181
Token :
0xc0b3de
FrrToken :
0x0
LsrType :
Ingress
Outgoing token :
0x0
Label Operation :
PUSH
Mpls-Mtu :
4470
TimeStamp :
535709sec
The command output shows that the period during which the LSP is formed is six days,
which is the same as the period during which traffic keeps changing. Because a new LSP
is formed and the function of iterating unlabeled routes to tunnels is configured on
Router C, related routes are successfully iterated to the LSP and packets are forwarded
through MPLS, causing the volume of traffic on interfaces to be unstable.
Procedure
Step 1 The fault is caused by improper network planning, proper network planning needs to be worked
out to reduce subsequent network maintenance efforts. If the fault occurs, services may be
interrupted after related measures are taken.
----End
Summary
Because a new LSP is formed and the function of iterating unlabeled routes to tunnels is
configured on Router C, related routes are successfully iterated to the LSP and packets are
forwarded through MPLS. On Router B, packets are sent out through POS 3/0/0 and POS 4/0/0,
because the routes to Router E are built up late. Therefore, services are not interrupted.

The fault is caused by improper network planning, proper network planning needs to be worked
out to reduce subsequent network maintenance efforts.

Troubleshooting - MPLS 3 MPLS Forwarding Troubleshooting
3 MPLS Forwarding Troubleshooting
About This Chapter
3.1 Host Cannot Receive or Send Packets Through an LSP

3.1 Host Cannot Receive or Send Packets Through an LSP
3.1.1 Common Causes

l Routing information is incorrect.

l The LSP does not exist.
l The LSP status is incorrect in the situation where BFD status is Down.
l The system status is incorrect.

After an MPLS network is configured, a host cannot transmit packets along an LSP.

l Check that routes are correct.
l Check that the LSP exists.
l Check that the LSP status is normal.
l Check that the system status is normal.

Figure 3-1 Troubleshooting flowchart for the fault that a host cannot receive or send packets
through an LSP
Host cannot
receive or sent
packets along
an LSP
No See the section "IGP Yes

Routes are
Route Is fault rectified?
correct?
Troubleshooting"
No
Yes
No See the section Yes

LSP exists? "LDP LSP Goes Is fault rectified?
Down"
Yes No
No See the section Yes

LSP status is
"BFD Session Goes Is fault rectified?
normal?
Down"
Yes No
No Yes
System status See the section
Is fault rectified?
is normal? "CPU Usage Is High"
Yes No
Seek technical
End
support

Context
NOTE
Procedure
Step 1 Check that routes are correct.
Run the display fib verbose command to check whether routing information on the ping initiator
and the ping destination node.

l If the LspFwdFlag field is not 1 and the LspToken field is 0, IGP routes are incorrect. For
instructions on how to clear the fault, see the section "IGP Route Troubleshooting."
l If the LspFwdFlag field is 1 and the LspToken field is not 0, IGP routes are correct. Then,
go to Step 2.
Step 2 Check that the LSP exists.

Run the display tunnel-info command on the ping initiator and the ping destination node.
l If the LSP does not exist, clear the fault by referring to LDP LSP Goes Down.
l If the LSP exists and the fault persists, go to Step 3.
Step 3 Check that the LSP status is normal.

Run the display mpls lsp verbose command.
If a value of the Token field in the display mpls lsp verbose command output is the same as a
value of the LspToken field in the display fib verbose command output, the LSPs indicated by
the two identical tokens are the same. Check whether the label, label operation mode, and next-
hop information of the LSP in the output of these two commands are the same and check whether
the BFD status associated with the LSP is Up.
l If BFD is configured but BFD is Down, clear the fault by referring to BFD Session Cannot
Go Up.
l If the label, label operation mode, and next-hop information in the output of these two
commands are the same and BFD is Up, go to Step 4.
----End
Relevant Alarms
None.
Relevant Logs
None.


Troubleshooting - MPLS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting - MPLS

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine40E/80E Universal Service

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential i

About This Document

Issue 03 (2013-08-20) Huawei Proprietary and Confidential ii

Product Name Version

HUAWEI NetEngine80E/40E V600R006C00

l System maintenance engineers

DANGER indicates a hazard with a high level or medium

WARNING indicates a hazard with a low level of risk which,

CAUTION indicates a potentially hazardous situation that,

NOTE NOTE provides additional information to emphasize or

Boldface The keywords of a command line are in boldface.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 03 (2013-08-20)

Changes in Issue 02 (2013-04-15)

Changes in Issue 01 (2012-11-10)

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi

3 MPLS Forwarding Troubleshooting........................................................................................70

Issue 03 (2013-08-20) Huawei Proprietary and Confidential vii

1 MPLS LDP Troubleshooting

About This Chapter

1.1 LDP Session Flapping

1.2 LDP Session Goes Down

1.3 LDP LSP Flapping

1.4 LDP LSP Goes Down

1.5 Troubleshooting a Failure in Establishing an Inter-area LSP

1.6 Related Troubleshooting Cases

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1 LDP Session Flapping

1.1.1 Common Causes

1.1.2 Troubleshooting Flowchart

The troubleshooting roadmap is as follows:

Figure 1-1 shows the troubleshooting flowchart.

Figure 1-1 Troubleshooting flowchart for LDP session flapping

Yes See the section Yes

See the section Yes

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 2

1.1.3 Troubleshooting Procedure

l If the command output displays the following information, LDP authentication is

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 3

1.1.4 Relevant Alarms and Logs

1.2 LDP Session Goes Down

1.2.1 Common Causes

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

1.2.2 Troubleshooting Flowchart

The troubleshooting roadmap is as follows:

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 4

l Check that an LDP Keepalive-hold timer expires.

Figure 1-2 shows the troubleshooting flowchart.

Run the undo

An MPLS Yes Restore the Yes