Troubleshooting - MPLS (V600R003C00 - 02)

HUAWEI NetEngine80E/40E Router
V600R003C00
Troubleshooting - MPLS
Issue
02
Date
2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. 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 the 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:
[email protected]
Issue 02 (2011-09-10)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

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.
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
HUAWEI NetEngine80E/40E
Router
V600R003C00
Intended Audience
This document is intended for:
l
System maintenance engineers
Commissioning engineers
Network monitoring engineers
Issue 02 (2011-09-10)

ii

About This Document
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
TIP
Indicates a tip that may help you solve a problem or save

time.
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.
Issue 02 (2011-09-10)
Convention
Description
Boldface
The keywords of a command line are in boldface.
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.

iii

About This Document
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 02 (2011-09-10)

The second commercial release. There is no update compared with the previous issue.
Changes in Issue 01 (2011-05-30)

Initial field trial release.
Issue 02 (2011-09-10)

iv

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......................................................................................................................13
1.6 Related Troubleshooting Cases........................................................................................................................15
1.6.1 Fail to Establish the Static LSP...............................................................................................................15
1.6.2 Fail to Establish an Inter-area LSP..........................................................................................................17
1.6.3 MPLS LDP Peer Relationship Cannot Be Established Because ATM Interfaces Are Not Enabled with
the Broadcast Function.....................................................................................................................................18
Issue 02 (2011-09-10)


Contents
1.6.4 No LDP Session Can Be Established Between PEs Because the Route to the LSR ID of an LDP Instance
Is Unreachable..................................................................................................................................................19
1.6.5 MPLS LDP Peer Relationship Cannot Be Established...........................................................................21
1.6.6 LDP Flaps................................................................................................................................................23
1.6.7 Route of the GRE Tunnel Flaps..............................................................................................................25
1.6.8 Load Imbalance Caused by Configuring LDP Transport Addresses.......................................................27
2 MPLS TE Troubleshooting........................................................................................................30
2.1 TE Tunnel Is Down..........................................................................................................................................31
2.1.1 Common Causes......................................................................................................................................31
2.2 TE Tunnel Suddenly Goes Down.....................................................................................................................34
2.2.1 Common Causes......................................................................................................................................34
2.3 Loop Occurs on a TE Tunnel...........................................................................................................................36
2.3.1 Common Causes......................................................................................................................................36
2.4 Bidirectional TE Tunnel Goes Down...............................................................................................................38
2.4.1 Common Causes......................................................................................................................................38
2.5 Related Troubleshooting Cases........................................................................................................................40
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..............................................................................................................................................40
2.5.2 Tunnel Goes Down Suddendly and Then Up..........................................................................................42
2.5.3 Fast Check and Rectify the Problem of Route Loops.............................................................................43
2.5.4 Tunnel Flaps Every Several Minutes After IGP Shortcut Is Enabled.....................................................45
2.5.5 TE Tunnel of the Inter-OSPF Area Fails to Be Set Up...........................................................................47
2.5.6 Tunnel Goes Down After Switchover.....................................................................................................49
2.5.7 Tunnel Creation Fails Because of Authentication Failure.......................................................................50
2.5.8 Calculation of the Tunnel Path Fails.......................................................................................................52
2.5.9 Path with the Smallest Metric Is Not Selected........................................................................................53
2.5.10 Establishment of the Hot-Standby LSP Fails........................................................................................55
2.5.11 FRR Binding Fails.................................................................................................................................56
2.5.12 Primary Tunnel Turns Down When Configuration of the Bypass Tunnel Is Modified........................58
2.5.13 After the Primary Tunnel Fails, Traffic Does Not Switch to a HSB Tunnel.........................................59
2.5.14 VPN Traffic Loss Is Caused by a Change in the Next-hop Route........................................................60
Issue 02 (2011-09-10)

vi

Contents
2.5.15 Volume of Service Traffic on Interfaces of a Device Is Unstable.........................................................61
3 MPLS Forwarding Troubleshooting........................................................................................66

3.1 Host Cannot Receive or Send Packets Through an LSP..................................................................................67
3.1.1 Common Causes......................................................................................................................................67
Issue 02 (2011-09-10)

vii

1 MPLS LDP Troubleshooting
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 02 (2011-09-10)


1.1 LDP Session Flapping

1.1.1 Common Causes
This fault is commonly caused by one of the following:
l
The configuration of LDP GR timer, LDP MTU, LDP authentication, LDP Keepalive
timer , or LDP transport address is set, changed, or deleted.
Interface flaps.
Routes flaps.
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.
Check that the interface does not alternate between Down and Up.
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
LDP session
is recreated?
Yes
Yes
Wait 10 seconds
Is fault rectified?
No
No
Interface flaps?
Yes
See the section

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

"IGP Route
Troubleshooting"
Yes
Is fault rectified?
No
No
Seek technical
support
Issue 02 (2011-09-10)

End

1.1.3 Troubleshooting Procedure

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, LDP MTU, or a transport address
is changed.
1.
Run the display this command in the LDP view to check that the configuration of LDP
GR, an LDP MTU, or LDP authentication is changed.
l If the following information is displayed, it indicates that LDP GR is configured.
mpls ldp
graceful-restart
l If the command output displays the following information, it indicates that the LDP
MTU value is set.
mpls ldp
mtu-signalling
l If the command output displays the following information, it indicates that 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 check that an LDP Keepalive timer
or an LDP transport address has been configured.
Keepalive timer is set. The timer value (for example, 30 seconds) depend on the actual
situation.
mpls ldp
mpls ldp timer keepalive-hold 30
transport address is set. The transport address and the type and number of the interface
can be set as required.
mpls ldp
mpls ldp transport-address interface
If one of the preceding configurations has been performed, wait for 10 seconds and then
check whether the LDP session flaps.
If no configuration is 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, it indicates that the interface is Up; if one field
displays Down, it indicates that the interface is Down. If the interface always alternates between
Down and Up, it indicates that the interface flaps.
l
If the interface alternates between Down and Up, see the section "Interface Flapping."
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 route information. If routes exist, route
information will be displayed. If routes do not exist, no route information will be displayed. If
Issue 02 (2011-09-10)


the situation where route information is displayed and the situation where no route information
is displayed alternate, it indicates that the routes alternate between unreachable and reachable.
l
If routes alternate between unreachable and reachable or no route exists, see the section
The Ping Operation Fails.
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.
The undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
No route exists.
An LDP Keepalive timer expires.
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.
Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer is run.
Check that the routes exist.
Check that an LDP Hello-hold timer expires.
Check that an LDP Keepalive-hold timer expires.

Issue 02 (2011-09-10)


Figure 1-2 Troubleshooting flowchart for the fault that an LDP session goes Down
LDP session
goes Down
Interface is
shut down?
Yes
Run the undo

shutdown
command on the
interface
Is fault rectified?
Restore the
deleted
configuration
Is fault rectified?
No
An MPLS
command in undo
form is run?
Yes
Yes
No
Yes
No
No
Routes are
reachable?
No
Troubleshoot the
routes problem
Yes
Is fault rectified?
No
Yes
Yes
Hello-hold timer
expires?
See the section

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

"Link Forwarding
Fails"
Yes
Is fault rectified?
No
No
Seek technical
support
End

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 command output shows the following
command, it indicates that the interface has been shut down.
shutdown
If the interface has been shut down, run the undo shutdown command to restart the
interface.
If the interface is Up, go to Step 2.
Issue 02 (2011-09-10)


Step 2 Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer is run.
Run the display current-configuration command.
l If the command output does not display the following information, it indicates that MPLS is
disabled.
mpls
l If the command output does not display the following information, it indicates that MPLS
LDP is disabled.
mpls ldp
l If the command output does not display the following information, it indicates that the remote
LDP session is deleted.
mpls ldp remote peer
If an MPLS-associated configuration is deleted, re-perform the configuration.
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 then check
whether the route to the peer exists. If the route to the peer does not exist, a TCP connection
cannot be established. If the route to the peer exists, run the ping host command. If the ping
succeeds, the route is reachable. If the ping fails, the route is unreachable.
l
If the route to the peer does not exist, see OSPF Troubleshooting or IS-IS
Troubleshooting to troubleshoot the problem.
If the route to the peer exists but is not reachable, see The Ping Operation Fails.
If the route to the peer exists and is reachable, go to Step 4.
Step 4 Check that an LDP Hello-hold timer expires.

Run the display mpls ldp interface command to check whether both ends of the LDP session
can send Hello messages. It is recommended that the display mpls ldp interface command be
run every 3 seconds. If the statistics do not change for several times, it indicates that the
transmission of Hello messages becomes abnormal and the Hello-hold timer expires.
l
If the Hello-hold timer expires, see the section The CPU Usage Is High.
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 every 5 seconds. If the statistics do not change for several times,
it indicates that the transmission of Keepalive messages becomes abnormal and the Keepalivehold timer expires.
l
If the Keepalive-hold timer expires, see the section The Ping Operation Fails.
If the Keepalive-hold timer does not expire, go to Step 6.
----End
Issue 02 (2011-09-10)



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.
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.
Check that the LDP session flaps.

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

"IGP Route
Troubleshooting"
Yes
Is fault rectified?
No
No
LDP
session flaps?
Yes
See the section

"LDP Session
Flaps"
Yes
Is fault rectified?
No
No
Seek technical
support
Issue 02 (2011-09-10)

End


This section describes the troubleshooting procedure of LDP LSP flapping.
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. It is recommended that this command be run every second. If routes
exist, route information will be displayed. If no routes exist, no route information will be
displayed. If sometimes route information is displayed and sometimes no route information is
displayed after the command run several times, it indicates that the routes alternate between
unreachable and reachable.
l
If routes alternate between unreachable and reachable or no route exists, see the section
The Ping Operation Fails to rectify the fault of IGP routes.
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. It is recommended that
this command be run every second. If Operational and Initialized are displayed alternatively,
it indicates that the LDP session flaps.
l
If the LDP session flaps, see the section LDP Session Flapping.
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.
Issue 02 (2011-09-10)


1.4 LDP LSP Goes Down

1.4.1 Common Causes
l
Routes become unreachable.
The LDP session goes Down.
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.
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.
Check that the LDP session is successfully established.
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.
Check that a policy for establishing LSPs is configured.
Check whether a static LSP is established.
Issue 02 (2011-09-10)


Figure 1-4 Troubleshooting flowchart for the fault that an LDP LSP goes Down
LDP LSP
Down
IGP routes
exist?
No
See "IGP Route

Troubleshooting"
Yes
Is fault rectified?
No
Yes
Session is
successfully
set up?
No
See the section

"LDP Session
Goes Down"
Is fault rectified?
Yes
No
Yes
Resources
are insufficient?
Yes
Increase the
upper limit or
delete unwanted
LSPs
Is fault rectified?
Change the
policy for setting
up an LSP
Is fault rectified?
Yes
No
No
Policy for
setting up an
LSP exists?
Yes
Yes
No
No
Seek technical
support
End

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 route information is displayed and the State field is Active Adv in the command output, it
indicates that such a route exists and is in the active state. In addition, if the route is a BGP route
of a public network, check the Label field in the command output. If non-NULL is displayed,
it indicates that route information carries a label.
Issue 02 (2011-09-10)

10

If routes do not exist, the routes are not in the active state, or the BGP routes do not carry
labels, see the section The Ping Operation Fails.
If routes exist and in the active state, and additionally if the routes are BGP routes, 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, it indicates that the LDP session is established and is Up. If Initialized is displayed,
it indicates that the LDP session is in Initialized state.
l
If the LDP session is established abnormally, see the section LDP Session Goes Down.
If the LDP session is established normally, 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 larger than that defined in the PAF/license file, it indicates that
resources are insufficient.
2.
Check that tokens are used out for establishing ingress LSPs or transit LSPs.
Run the display tunnel-info statistics command to statistics. The Global-1 Avail TunnelID 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, it indicates that the tokens are used out and resources are insufficient.
If resources are insufficient, adjust the upper limit of the resources or delete unwanted LSPs.
If resource 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 command output shows the
following command, it indicates that an IP-prefix-based policy for triggering the
establishment of LSPs has been configured. The policy name (for exmaple, abc) depends on
the actual situation. Then, check that certain 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 command output shows the
following command, it indicates that an IP-prefix-based policy for triggering the
establishment of LSPs has been configured. The policy name (for exmaple, abc) depends on
the actual situation. Then, check that certain 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 command output shows
the following information, it indicates that only routes to 1.1.1.1/32 and 2.2.2.2/32 are
allowed to trigger the establishment of LSPs. The IP addresses (for example, 1.1.1.1/32 and
2.2.2.2/32) depends on the actual situation.
index: 10
index: 20
permit
permit
1.1.1.1/32
2.2.2.2/32
If one of the preceding policies are configured, add information about the route to the
destination of the required LSP to the policy.
If no policy is configured, go to Step 5.
Issue 02 (2011-09-10)

11

Step 5 Check whether a static LSP is established.

Run the display mpls lsp include ip-address mask-length verbose command to check that a
static LSP with the same destination address exists.
NOTE
ip-address mask-length specifies the destination address of the LSP failed to be established.
If STATIC LSP is displayed in the LSP Information field, it indicates that a static LSP exists.
NOTE
The dynamic and static LSPs with the same destination cannot coexist and the static LSP prevails.
Therefore, the dynamic LSP failed to be established.
If the static LSP exists, delete it.
If no static LSP exists, go to Step 6.
----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.
The inter-area LDP extension is not configured.
An LDP session fails to be established.
The route associated with the LDP session does not match the route in the routing table.
Issue 02 (2011-09-10)

12


After the inter-area LDP extension has been enabled, an inter-area LSP fails to be set up.
l
Check that routes are reachable.
Check that the inter-area LDP extension is enabled.
Check that an LDP session is set up.
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
Are route
reachable?
No
See "IGP
Routing
Problems"
Yes
Is fault rectified?
No
Yes
Is LDP
inter-area
extension
enabled?
No
Enable the interarea LDP

extension
Yes
Is fault rectified?
No
Yes
Is an
LDP session is
established?
No
See "LDP
Session Goes
Down"
Yes
Is fault rectified?
No
Yes
Does
the LDP route
match the route
in the routing
table ?
No
See "LSP Goes

Down"
Yes
Is fault rectified?
No
Yes
Seek
technical
support
Issue 02 (2011-09-10)
End

13


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 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.
If no routes are reachable, the reachable routes are in the inactive state, or BGP routes do
not carry labels, follow the procedure in Ping Failures.
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.
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.
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.
Issue 02 (2011-09-10)

14

If the LDP session does not match routes, following the procedure in LDP LSP Goes
Down.
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 Fail to Establish the Static LSP
Fault Symptom
Figure 1-6 Networking diagram of establishing a static LSP
Loopback1
1.1.1.9/32
Loopback1
2.2.2.9/32
POS1/0/0
10.1.1.1/30
RouterA
POS1/0/0
10.1.1.2/30
RouterB
A Point-to-Point Protocol (PPP) link connects Router A with Router B. When a static LSP is
configured, the LSP status 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, and you can view that the Forwarding
Equivalence Class (FEC) is 2.2.2.9/32 and the IP address of the next hop is 10.1.1.1.
<RouterA> display mpls static-lsp ad verbose
Issue 02 (2011-09-10)

15

No
:
LSP-Name
:
LSR-Type
:
FEC
:
In-Label
:
Out-Label
:
In-Interface
:
Out-Interface :
NextHop
:
Static-Lsp Type:
Lsp Status
:
2.
1
ad
Ingress
2.2.2.9/32
NULL
30
10.1.1.1
Normal
Down
Use the display ip routing-table command, and you can view that the destination IP
address is 2.2.2.9/32 and the IP address of the next hop 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.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.1.1.2/32 Direct 0
0
D 10.1.1.2
Pos1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
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, and you can 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 outlabel 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-hopaddress 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 Lsp Status field shown in the display mpls static-lsp
verbose command is Up. 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 must exist in the local routing table. The routing entry includes
the destination IP address and the next hop IP address.
l
Issue 02 (2011-09-10)
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 be
in accordance with the next hop in the corresponding routing entry.
16

If you configure a static LSP by specifying an outgoing interface, you must 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 adopted in the configuration.
1.6.2 Fail to Establish an Inter-area LSP

Fault Symptom
On the network shown in Figure 1-7, LSR B, LSR C, and LSR D are in Area 10, and LSR A is
in Area 20. LSR D aggregates routes associated with LSR B and LSR C and advertises the
summary route to Area 20. The inter-area LDP extension is enabled on LSR A.
Figure 1-7 Networking diagram for failing to establish an inter-area LSP
Loopback0
1.3.0.1/32
Loopback0
1.1.0.1/32
POS1/0/0
10.1.1.1/24
LSRA
IS-IS
Area20
0/1
Loopback0 S1/ /24
0 LSRB
1
O
/0/ 24
1
1.2.0.1/32 P .1.1.
S 2/
20
PO 1.1.
.
IS-IS
20
PO
Area10
20 S1
.1. /0/
POS1/0/0
2.1 2
10.1.1.2/24 LSRD
/24
Loopback0
1.3.0.2/32
PO
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 Router A to view route information. No

information about a summary route to the inter-area LSP destination address is displayed.
-----------------------------------------------------------------------------Routing Tables: Public
Destinations : 10
Routes : 10
Destination/Mask
Issue 02 (2011-09-10)
Proto
Pre
Cost
Flags NextHop

Interface
17

1.1.0.1/32
1.2.0.1/32
1.3.0.0/24
10.1.1.0/24
10.1.1.1/32
10.1.1.2/32
20.1.1.0/24
20.1.2.0/24
127.0.0.0/8
127.0.0.1/32
2.
Direct
ISIS-L1
ISIS-L1
Direct
Direct
Direct
ISIS-L1
ISIS-L1
Direct
Direct
0
15
15
0
0
0
15
15
0
0
0
10
20
0
0
0
20
20
0
0
D
D
D
D
D
D
D
D
D
D
127.0.0.1
10.1.1.2
10.1.1.2
10.1.1.1
127.0.0.1
10.1.1.2
10.1.1.2
10.1.1.2
127.0.0.1
127.0.0.1
InLoopBack0
Pos1/0/0
Pos1/0/0
Pos1/0/0
InLoopBack0
Pos1/0/0
Pos1/0/0
Pos1/0/0
InLoopBack0
InLoopBack0
Run the display mpls ldp command on LSR A. 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 LDP.
Run the following commands on LSR A 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 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-8. 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-8 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
Loopback 1
1.1.1.1/32
ATM1/0/0
2.1.1.1/24
LSRA
Issue 02 (2011-09-10)
Loopback 1
2.2.2.2/32
ATM1/0/0
2.1.1.2/24
ATM2/0/0
3.2.1.1/24
LSRB

Loopback 1
3.3.3.3/32
ATM2/0/0
3.2.1.2/24
LSRC
18

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 thus 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.4 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-9. With this configuration, no LDP session
can be established between PE1 and PE2.
Issue 02 (2011-09-10)

19

Figure 1-9 Networking diagram of the case where no LDP session can be established between
PEs
Loopback 0
1.1.1.1
Loopback 0
3.3.3.3
PE1
PE2
P
Loopback 1
100.100.100.100
Loopback 1
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.
Issue 02 (2011-09-10)

20


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.5 MPLS LDP Peer Relationship Cannot Be Established

Fault Symptom
On the network shown in Figure 1-10, MPLS is configured on a router and an MA5200G, but
MPLS LDP peer relationship cannot be established between the two devices.
Issue 02 (2011-09-10)

21

Figure 1-10 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
GE1/0/0
Router
GE1/0/0
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.
Issue 02 (2011-09-10)

22

1.6.6 LDP Flaps

Fault Symptom
Figure 1-11 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-11, 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:
CPU Usage
:
CPU Usage Stat. Time :
CPU Usage Stat. Tick :
Actual Stat. Cycle
:
Issue 02 (2011-09-10)
60 (Second)
24% Max: 68%
2009-08-17 14:04:02
0x15286(CPU Tick High) 0x13a9ba5e(CPU Tick Low)
0x0(CPU Tick High) 0x77c5c6f7(CPU Tick Low)

23

TaskName
BUFM
VIDL
TICK
VT
IPCR
VPR
VPS
ECM
BEAT
RTMR
IPCQ
VP
RPCQ
VMON
STND
INFO
RPR
APS
FIB6
FHM
BFD
OAM
SNPG
ADPT
QAT
ATMA
LLDP
SECL
FLD
EOAM
TRAF
FIB
SOCK
IFNT
L2TP
TUNN
DIAG
SRM
NPS
TSC
TSD
MAG
ALT
TSTA
ARPV
MACF
HQOS
NE50
STAT
SQOS
QOSA
DEFD
VRRP
OS
4.

CPU
0%
0%
0%
0%
0%
0%
2%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
25%
0%
0%
0%
0%
0%
0%
0%
5%
0%
1%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
7%
Runtime(CPU Tick High/CPU Tick Low)

0/ 20058e
0/5bcbca6e
0/ 63102e
0/
16d51
0/
29fa9
0/ 5ea0b28
0/ 3212994
0/
474be
0/
a021c
0/ 313356
0/ 59ad08
0/
2ca
0/
3a660
0/
7438
0/
955f3
0/
2ed9
0/ 40aa90
0/
8180c
0/ 124a2e
0/
969e2
0/ 1117d0
0/ 127ab0
0/
1127b
0/ 450505
0/
744d
0/
de6e
0/
d6ed
0/
2318
0/
1975d
0/ a75c38
0/
fdc45
0/
19b69
0/ 615ece3
0/
5ccbf
0/
290e
0/
1d36
0/ 3b8564
0/ 173ee1
0/
e1bb5
0/ 1f9d15
0/ 6b2e2f8
0/ 84935e
0/ 1cc6f28
0/ 10800c
0/
3ff11
0/ 2b6dd1
0/ 1efbb5
0/
12d6d
0/
5e1c3
0/ 19b02d
0/ 156699
0/
4265
0/
1f78
0/
0
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.
Issue 02 (2011-09-10)

24

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.7 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-12, 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
Issue 02 (2011-09-10)

25

(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-12 Networking diagram of the flapping of the route of the GRE tunnel
Public network
10.1.1.1
PE 1
20.1.1.1
PE 2
GRE Tunnel
30.1.1.1 Tunnel1/0/1
10.2.1.1
CE 1
Tunnel1/0/1 40.1.1.1
10.2.1.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.
Issue 02 (2011-09-10)

26

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.8 Load Imbalance Caused by Configuring LDP Transport

Addresses
Typical Networking
On the network shown in Figure 1-13, 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-13 Networking diagram for load imbalance caused by configuring LDP transport
addresses
Pos 1/0/0
Router A
Pos 2/0/0
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
Interface
PHY
Protocol InUti OutUti
Pos1/0/0
up
up
41%
1%
Pos2/0/0
up
up
40%
83%
inErrors
0
0
outErrors
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.
Issue 02 (2011-09-10)

27

<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.11:0
112.100.7.11
112.100.7.12:0
112.100.7.12
112.100.7.13:0
112.100.7.13
112.100.7.14:0
112.100.7.14
112.100.7.15:0
112.100.7.15
112.100.7.17:0
112.100.7.17
112.100.7.21:0
112.100.7.21
222.171.5.7:0
222.171.116.1
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 circuit-level level-2
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 circuit-level level-2
isis cost 100
ospf cost 100
Issue 02 (2011-09-10)

28

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
Interface
PHY
Protocol InUti OutUti
Pos1/0/0
up
up
44%
50%
Pos2/0/0
up
up
44%
50%
inErrors
0
0
outErrors
0
0
----End
Summary
Traffic imbalance occurs in one of the following situations:
l
A specific traffic model is used.
Routes do not carry out load balancing.
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.
Issue 02 (2011-09-10)

29

2 MPLS TE Troubleshooting
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.
Issue 02 (2011-09-10)

30

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.
CSPF fails to calculate a path.
RSVP is not enabled on a device along the TE tunnel.
Devices fail to exchange RSVP Path or Resv messages along the TE tunnel.

After a TE tunnel is configured, the TE tunnel is Down.
l
Check that the mpls te commit command is configured to commit the TE tunnel
configuration.
Check that CSPF successfully calculates a path.
Check that RSVP is enabled on every device along the TE tunnel.
Check that devices along the TE tunnel successfully exchange messages.
Issue 02 (2011-09-10)

31

Figure 2-1 Troubleshooting flowchart for the fault that a TE tunnel is Down
TE tunnel goes
Down
The
Commit
command is not
run?
Yes
Yes
Run the mpls te

commit command
Is fault rectified?
No
No
CSPF fails
to calculate a
path?
Yes
Route
to the tunnel
destination does
not exist?
No
See the section "IGP

Route
Troubleshooting"
Yes
See the section "CSPF
Fails"
No
RSVP is not
configured?
Yes
Yes
Enable RSVP
Is fault rectified?
No
No
Packet Cannot
be exchanged?
Yes
See the section "IP

Forwarding Fails"
Yes
Is fault rectified?
No
No
Seek technical
support
End

NOTE
Issue 02 (2011-09-10)

32

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, configure the
mpls te commit command.
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 been successful in calculating paths.

Run the display mpls te cspf destination ip-address explicit-path path-name command on the
ingress of the TE tunnel. If information is displayed, it can be concluded that CSPF has been
successful in calculating paths; if no information is displayed, it can be concluded that 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 such routes do not exist, clear the fault by referring to the section The Ping Operation
Fails.
If reachable routes exist and the routes satisfy the requirements for establishing a TE
tunnel, clear the fault by referring to the section "CSPF Calculation Fails."
If CSPF has been successful in calculating 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.
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, LSR A, LSR
B, and LSR C are identified to be the nodes along the TE tunnel.
Do as follows to check whether the RSVP Path message and RSVP Resv message are correctly
transmitted:
l Check whether RSVP Path messages are correctly sent and received on every node along the
LSP in the sending direction (LSR A -> LSR B -> LSR C).
Run the display mpls rsvp-te psb-content command on every node the RSVP Resv message
travels.
If the command output is not empty on any node, it can be concluded that RSVP Path
messages are correctly sent and received between these nodes.
If the command output is empty on a node, it can be concluded that 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 (LSR
C -> LSR B -> LSR A).
Issue 02 (2011-09-10)

33

Run the display mpls rsvp-te rsb-content command on every node the RSVP Resv message
travels.
If the command output is not empty on any node, it can be concluded that RSVP Resv
messages are correctly transmitted.
If the command output is empty on a node, it can be concluded that the node fails to
receive RSVP Resv messages from the upstream node.
l
If messages fail to be properly exchanged, clear the fault by referring to the section "IP
Forwarding Fails."
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 by running a command.
A physical interface on the TE tunnel goes Down.
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 the configuration of the TE tunnel, such as the
configuration of MPLS or RSVP-TE is deleted.
Check whether a physical interface on the TE tunnel is Down.
Check whether the transmission of RSVP message expires.

Issue 02 (2011-09-10)

34

Figure 2-2 Troubleshooting flowchart for the fault that a TE tunnel goes suddenly Down
TE tunnel
goes Down
suddenly
Tunnel
configuration is
deleted
Yes
Restore the
configuration
Yes
Is fault rectified?
No
No
Physical
tunnel interface
is Down
Yes
See the section

"Physical
Interface Fails"
Yes
Is fault rectified?
No
No
RSVP
message times
out
Yes
See the section

"IP Forwarding
Fails"
Yes
Is fault rectified?
No
No
Seek technical
support
End

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 one of the following commands is configured:
l undo interface tunnel interface-number
l reset mpls te tunnel-interface tunnel-name interface-number
l reset mpls rsvp-te
l
If one of the preceding commands is configured, restore the deleted configurations.
If none of the preceding commands is configured but the fault persists, go to Step 2.
Step 2 Check whether any physical interface along the TE tunnel is Down.
1.
Issue 02 (2011-09-10)
Record the time when the log IFNET/4/LINKNO_STATE indicating that the TE tunnel
goes Down was generated. Record the time as T1.
35

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.
If T1 is larger than T2, it can be concluded that the TE tunnel went Down because the
physical interface on the TE tunnel is faulty. In this case, see the section "Physical Interface
Is Faulty."
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, clear the fault by referring to the section "IP
Forwarding Fails."
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.
A loop occurs on the link along which an RSVP Resv message travels.
Issue 02 (2011-09-10)

36


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.
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
Yes Delete one of two

Loop occurs
identical
when transmitting the
addresses
Path message?
Yes
If fault rectified?
No
No
Loop occurs
when transmitting the
Resv message?
Yes
Delete one of two

identical
addresses
Yes
If fault rectified?
No
No
Seek technical support
End

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, it can be concluded that 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, it indicates that ip-address is the same as an existing one
and IP address collision occurs.
Error: The destination address cannot be a local address.
Issue 02 (2011-09-10)

37

In the case of IP address collision, delete or change the IP address of the node.
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, it indicates that 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.
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.
MPLS TE is not enabled on the outbound interface of the bidirectional static CR-LSP that
is bound to the bidirectional TE tunnel.
The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is Down.
The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is allocated insufficient bandwidth.

Issue 02 (2011-09-10)

38

Figure 2-4 Troubleshooting flowchart for a problem that a bidirectional TE tunnel goes Down
Bidirectional TE
Tunnel goes Down
Is the
bidirectional static
CR-LSP correctly
configured
No
Check that the CR-LSP

is correctly configured
Is the fault
rectified
Yes
No
Yes
Check that the

Tunnel matches the
CR-LSP
No
Check that the tunnel

matches the
CR-LSP
Yes
Is the fault
rectified
No
Yes
Is bandwidth
allocated to the
outbound interface of
the CR-LSP?
Yes
Check that the remaining

bandwidth meets the
requirements
Is the fault
rectified
Yes
No
No
Ask for technical
support
End

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.
Egress:
If the reverse tunnel attribute is not enabled for the tunnel, run the mpls te passivetunnel command to enable the reverse tunnel attribute. The reverse tunnel itself does
Issue 02 (2011-09-10)

39

not trigger the generation of a CR-LSP but can be bound to a reverse LSP for upper
layer application.
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 bandwidth allocated to the outbound interface of the bidirectional static CR-LSP
that is bound to the bidirectional TE tunnel meets the requirements.
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
smaller than the set one, reconfigure the remaining bandwidth.
l If the remaining bandwidth of the outbound interface of the bidirectional static CR-LSP is
larger than the set one, 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 LSR A and LSR D by using loopback addresses as tunnel destination
addresses. The tunnel from LSR D to LSR A is successfully set up, but the tunnel from LSR A
to LSR D fails to be set up.
Issue 02 (2011-09-10)

40

Figure 2-5 Networking diagram of a loop occurs because of 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
LSRA
GE2/0/0
LSRD
Loopback1
10.1.1.1/32
GE1/0/1
192.168.30.1/30 LSRE
Loopback1
10.1.1.2/32
Interface that is shut down
Fault Analysis
1.
Run the display mpls te tunnel command on LSR A. Only one tunnel is successfully set
up.
<LSRA> display mpls te tunnel
LSP-Id
Destination
10.1.1.2:8:29
10.1.1.1
In/Out-If
GE1/0/0/-
2.
Run the terminal monitor command to enable the display of debugging information and
the terminal debugging command to enable debugging on LSR D. Debugging information
RSVP/3/LOOP_PATH or RSVP/3/LOOP_RESV shows that a loop is generated on LSR
D.
3.
Run the display current-configuration interface tunnel 0/0/1 command on LSR A to

check tunnel configurations. The mpls te record-route command has been configured for
the tunnel (from LSR A to LSR D) that fails to be established.
4.
Run the undo mpls te record-route command and the mpls te commit command on LSR
A. The tunnel from LSR A to LSR D is then set up successfully.
However, if you enable MPLS TE FRR, the route record function will be automatically
enabled. When this is the case, the problem will recur. This indicates that the cause has not
been located yet.
5.
Run the tracert -a 10.1.1.1 10.1.1.2 command on LSR D. No loop occurs.
6.
Run the display current-configuration command on LSR D to check configurations. An

interface on LSR D is shut down, and its IP address that is not deleted is the same as that
of POS 2/0/0 on LSR B, causing the failure of establishing the tunnel from LSR A to LSR
D.
interface GigabitEthernet1/0/1
shutdown
ip address 192.168.30.1 255.255.255.252
#
Issue 02 (2011-09-10)

41

To establish the tunnel from LSR A to LSR D, LSR A sends an RSVP Path message to
LSR D. The RSVP Path message passes through each device along the path from LSR A
to LSR D. In addition, as the route record function is enabled by using the mpls te recordroute command, the IP address of each hop along the path is added to the RSVP Path
message. After receiving the RSVP Path message, LSR D detects that 192.168.30.1 added
to the message is the same as the IP address of its interface. Although LSR D's interface
with the IP address 192.168.30.1 has been shut down, its address is not deleted, resulting
in two identical addresses. In this case, LSR D considers that a loop occurs and therefore
sends the alarm and rejects the request for resources.
Run the following commands on LSR D 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 the preceding operations, run the display mpls te tunnel command on LSR A. The tunnel
from LSR A to LSR D has been successfully set up. The fault is cleared.
<LSRA> display mpls te tunnel
LSP-Id
Destination
10.1.1.2:8:29
10.1.1.1
10.1.1.1:1:64
10.1.1.2
In/Out-If
GE1/0/0/-/GE2/0/0
----End
Summary
It is recommended that the configurations of interfaces that are no longer used be deleted in
order to prevent unpredictable errors.
2.5.2 Tunnel Goes Down Suddendly and Then Up

Fault Symptom
As shown in Figure 2-6, an RSVP-TE tunnel is set up from LSR A (ingress) to LSR C (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.
Issue 02 (2011-09-10)
Run the display current-configuration interface tunnel interface-number command on

LSR A to check the configuration of the RSVP-TE tunnel and its explicit path.
42

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 LSR A (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 by 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, it means
that 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.
<LSRA> display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2008-12-23 14:54:44
Description: GigabitEthernet1/0/0 Interface
The Maximum Transmit Unit is 1500
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 restores to be Up, and no action is required.
----End
Summary
On the current network, the tunnel usually goes Down because a certain physical interface is
Down. You can 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 LSR A (ingress) to LSR C (egress).
After the configuration, the interface status of the RSVP-TE tunnel cannot go Up.
Issue 02 (2011-09-10)

43

Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
GE2/0/0
GE1/0/0
10.2.1.1/30
10.1.1.1/30
GE1/0/0
GE3/0/0
10.1.1.2/30 LSRB
LSRA
10.3.1.1/30
Loopback0
3.3.3.3/32
GE1/0/0
10.2.1.2/30
GE2/0/0
10.3.1.2/30 LSRC
Fault Analysis
1.

LSR A 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 on LSR A. If information is displayed, it can be concluded that CSPF has been successful
in calculating paths; if no information is displayed, it can be concluded that CSPF failed to
calculate a path.
3.
Check the logs on LSR A, LSR B, and LSR C. The following information is displayed on
LSR C.
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 LSR
A 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. Assume
that information about the path of the RSVP-TE tunnel is displayed as follows:
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 LSR C. This means that an IP address on LSR C is the same as the IP
address of the RSVP-TE tunnel (except Hop 5 and Hop 6 of LSR C itself). That is, the IP address
of LSR C 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 LSR C 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 LSR C is duplicated.

Step 3 Run the display ip interface brief command on LSR C to search for 10.1.1.2 and then delete
it.
Issue 02 (2011-09-10)

44

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 LSR A (ingress) to LSR C (egress)
and IGP shortcut is enabled on LSR A. After the RSVP-TE tunnel goes Up, it flaps every several
minutes.
Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
GE1/0/0
Loopback0
3.3.3.3/32
GE2/0/0
GE1/0/0
LSRA
GE1/0/0
LSRB
LSRC
Fault Analysis
1.

command output shows that the configurations are correct. In addition, 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
Issue 02 (2011-09-10)

45

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 GE 1/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 the IGP route calculation counts in the tunnel.
<LSRA> display ip routing-table 3.3.3.3
--------------------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination/Mask
Interface
3.3.3.3/32
Tunnel1/0/0
Proto
OSPF
Pre
10
Cost
Flags
NextHop
1.1.1.1
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. In this manner, tunnel flapping occurs.
Procedure
Step 1
Choose one of the following procedures:
l Enable CSPF on LSR A.
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.
Issue 02 (2011-09-10)
1.
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.

46

After the preceding operations, wait for 5 minutes or 6 minutes after the tunnel goes Up. Tunnel
flapping does not occur and thus 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, LSR A and LSR B are in Area0, and LSR C and LSR D are in Area1.
An RSVP-TE tunnel is set up along the path LSR A -> LSRB -> LSR C -> LSR D. After the
configuration, the RSVP-TE tunnel fails to be set up.
Figure 2-9 Networking diagram of MPLS TE tunnel over inter-area
Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
Loopback0
3.3.3.3/32
Loopback0
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
10.2.3.2/32
10.1.2.2/30
10.3.4.2/30
LSRD
LSRA
LSRB
LSRC
Fault Analysis
1.

command output shows that the configurations are correct.
2.

LSR A 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.
Issue 02 (2011-09-10)
Run the display explicit-path path-name command. The command output shows
information about the explicit path.
47

<LSRA> display explicit-path path1

Path Name : path1
1
10.1.2.2
4.
Run the display mpls te cspf tedb command on LSR A to check the CSPF TEDB. The
command output shows information about the CSPF TEDBs of only LSR A and LSR B.
<LSRA> display mpls te cspf tedb all
Maximum Node Supported: 128
Current Total Node Number: 2
ID
Router-ID
IGP
Count
1
1.1.1.1
OSPF
1
2
2.2.2.2
OSPF
1
5.
Path Status : Enabled

Strict
Include
Maximum Link Support: 256

Current Total Link Number: 2
Process-ID
Area
Link1
Run the display mpls te cspf destination dest-ip-address explicit-path path-name

command on LSR A 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 LSR
A. The command output shows that the tunnel interface goes Up and thus the fault is rectified.
----End
Issue 02 (2011-09-10)

48

Summary
On the network with inter-area tunnels, IGP routes can be advertised only in one area, and interarea CSPF calculation cannot be performed automatically. Therefore, a complete explicit path
should 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 LSR A (ingress) to LSR
C (egress). After master/slave switchover on LSR A, all RSVP-TE tunnels that pass through
LSR A go Down.
Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
GE1/0/0
GE2/0/0
GE1/0/0
LSRA
Loopback0
3.3.3.3/32
GE1/0/0
LSRB
LSRC
Fault Analysis
1.

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 LSR A and then LSR
B 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 LSR A and LSR B to check
whether RSVP GR is supported. Take the display on LSR A as an example.
<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 LSR A or LSR B.
Procedure
Step 1 Do as follows on LSR A and LSR B:
Issue 02 (2011-09-10)

49

1.
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
LSR A and LSR B to check whether RSVP GR is supported. Take the display on LSR A as an
example.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 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, LSR A supports GR. Perform switchover to check the status
of the tunnel. The tunnel remains to be Up and thus the fault is rectified.
----End
Summary
When the tunnel goes Down after switchover, you should check whether the configurations on
devices are correct, whether the RSVP-TE Hello mechanism is configured in both the system
and interface views, and whether 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 is Down.
Based on the network shown in Figure 2-11, configure MPLS VPN.
Figure 2-11 Networking diagram of MPLS VPN, No.2
POS1/0/0
POS1/0/0
200.1.1.1/24 200.1.1.2/24
RouterA
POS2/0/0
RouterB
POS1/0/0
RouterC
Fault Analysis
1.
Issue 02 (2011-09-10)
Use the display current-configuration interface tunnel interface-type interfacenumber command on Router A to check the tunnel configurations are correct.
50

2.
Use the display mpls te cspf tedb all command on Router A and find that CSPF TEDB 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
SendPacketCounter: 2
SendPathCounter: 1
SendResvCounter: 0
SendResvConfCounter: 0
SendHelloCounter: 0
SendAckCounter: 0
SendPathErrCounter: 0
SendResvErrCounter: 0
SendPathTearCounter: 1
SendResvTearCounter: 0
SendSrefreshCounter: 0
SendAckMsgCounter: 0
SendErrMsgCounter: 0
RecReqFaultCounter: 0
Bfd neighbor count: 0
RSB CleanupTimeOutCounter: 0
RecPacketCounter: 0
RecPathCounter: 0
RecResvCounter: 0
RecResvConfCounter: 0
RecHelloCounter: 0
RecAckCounter: 0
RecPathErrCounter: 0
RecResvErrCounter: 0
RecPathTearCounter: 0
RecResvTearCounter: 0
RecSrefreshCounter: 0
RecAckMsgCounter: 0
RecErrMsgCounter: 0
Bfd session count: 0
Statistics on Router B are as follows:

Total Statistics Information:
PSB CleanupTimeOutCounter: 0
SendPacketCounter: 0
SendPathCounter: 0
SendResvCounter: 0
SendResvConfCounter: 0
SendHelloCounter: 0
SendAckCounter: 0
SendPathErrCounter: 0
SendResvErrCounter: 0
SendPathTearCounter: 0
SendResvTearCounter: 0
SendSrefreshCounter: 0
SendAckMsgCounter: 0
SendErrMsgCounter: 0
RecReqFaultCounter: 0
Bfd neighbor count: 0
RSB CleanupTimeOutCounter: 0
RecPacketCounter: 2
RecPathCounter: 0
RecResvCounter: 0
RecResvConfCounter: 0
RecHelloCounter: 0
RecAckCounter: 0
RecPathErrCounter: 0
RecResvErrCounter: 0
RecPathTearCounter: 0
RecResvTearCounter: 0
RecSrefreshCounter: 0
RecAckMsgCounter: 0
RecErrMsgCounter:
Bfd session count: 0
Based on the preceding display, you can view that "RecPacketCounter" is not zero on
Router B and the number of all types of messages is zero. This indicates that a defect occurs
when packets are pre-processed. The 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
Issue 02 (2011-09-10)

51

From the configuration display, you can view that RSVP is configured on the interface of
Route 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 the
RSVP authentication. The keys on both ends should be the same.
After the preceding operation, run the display mpls te tunnel-interface command on Router
A, and you can view that the tunnel interface goes Up, which indicates that the fault is removed.
----End
Summary
Check statistics of the received and sent packets carefully to locate 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.
Loopback1
1.1.1.9/32
Loopback1
2.2.2.9/32
Loopback1
3.3.3.9/32
Loopback1
4.4.4.9/32
GE1/0/0
GE1/0/0
GE3/0/0
GE1/0/0
GE1/0/0
GE3/0/0
RouterD
RouterA
RouterB
RouterC
GE2/0/0
GE2/0/0
GE1/0/0
RouterE
GE2/0/0
Loopback1
5.5.5.9/32
After the configurations, the CR-LSP setup between Router A and Router D fails.
Issue 02 (2011-09-10)

52

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. Thus, 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
Based on Figure 2-13, configure MPLS TE. By default, the metric of all the interfaces on the
devices are 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.
Issue 02 (2011-09-10)

53

Figure 2-13 Typical networking of MPLS TE
Loopback1
1.1.1.9/32
Loopback1
2.2.2.9/32
GE3/0/0 GE1/0/0
GE1/0/0
RouterA
Loopback1
3.3.3.9/32
GE1/0/0
RouterB
GE1/0/0
GE2/0/0
GE2/0/0
Loopback1
4.4.4.9/32
GE3/0/0 GE1/0/0
RouterC
GE2/0/0
RouterD
GE2/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, and you can find that 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 GE3/0/0 on Router B is changed to 100 before
the tunnel is created. During the new tunnel configuration, the metric then recovers to the
default.
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 and find
the path with the smallest metric is selected. The fault is rectified.
----End
Summary
Removing this fault depends on the TE feature. TE is driven by configuration, not by topology.
You can configure re-optimization to avoid this fault.
Issue 02 (2011-09-10)

54

2.5.10 Establishment of the Hot-Standby LSP Fails

Fault Symptom
Based on the networking shown in Figure 2-14 configure the MPLS TE.
Loopback1
1.1.1.9/32
Loopback1
2.2.2.9/32
Loopback1
3.3.3.9/32
Loopback1
4.4.4.9/32
GE1/0/0
GE1/0/0
GE3/0/0
GE1/0/0
GE1/0/0
GE3/0/0
RouterD
RouterA
RouterB
RouterC
GE2/0/0
GE2/0/0
GE1/0/0
RouterE
GE2/0/0
Loopback1
5.5.5.9/32
After the configuration, the tunnel from Router B to Router C is created but the hot-standby LSP
setup fails.
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 indicates 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 and find 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
state.
State Change :Tunnel %s enters HBKP_WAITFORCSPF state from HBKP_USEDIDLE state
The preceding display indicates that the hot-standby requires CSPF calculation but fails.
3.
Using the debugging mpls te cspf tedb errors command on Router A, you can view 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.
Issue 02 (2011-09-10)
Using the display mpls te cspf tedb node command to check the CSPF database. Note
that the bandwidth of GE2/0/0 on Router E is not adequate to set up the bypass LSP.

55

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
GE2/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, and you can find that the standby LSP is set up. Thus, the fault is rectified.
----End
Summary
The key point of the example lies in the mechanism in CR-LSP backup. The bandwidth of the
backup LSP cannot be configured through the command line but are inherited from the primary
LSP.
2.5.11 FRR Binding Fails

Fault Symptom
Based on Figure 2-15, configure MPLS TE.
Loopback1
1.1.1.9/32
Loopback1
2.2.2.9/32
GE3/0/0 GE1/0/0
GE1/0/0
RouterA
Loopback1
3.3.3.9/32
GE1/0/0
RouterB
GE1/0/0
GE2/0/0
GE2/0/0
Loopback1
4.4.4.9/32
GE3/0/0 GE1/0/0
RouterC
GE2/0/0
RouterD
GE2/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.
Issue 02 (2011-09-10)

56

Fault Analysis
1.
Use the debugging mpls te management fast-reroute command on Router A or Router

B to enable the 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 adopted paths in the tunnel,
and find that 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.
You can view there are some coincident nodes between the PLR and the MP on the primary
tunnel and the 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 Ethernet 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 Ethernet 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 and find the FRR binding succeeds. The fault is removed.
----End
Summary
In FRR configuration, to ensure the successful binding, you need to specify the strict explicit
paths of the primary and bypass tunnels. Otherwise, the binding fails when the coincident nodes
exist between the PLR and the MP.
Issue 02 (2011-09-10)

57

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/0 is set up on 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
RouterA
RouterB
RouterC
Primary LSP
Bypass LSP
RouterD
After the configuration, shutdown the outgoing interface from Router B to Router C to make
the bypass tunnel turn to in use. After modifying the configuration of the bypass tunnel and
committing the new configuration, the primary tunnel turns Down.
Fault Analysis
During the modification of the bypass tunnel, a phase called make-before-break exists. That is,
a new CR-LSP is set up firstly and then the previous CR-LSP is removed.
After the old CR-LSP is removed, the binding relationship between the primary tunnel and the
bypass tunnel is also removed. The primary tunnel, therefore, turns Down because the newlyestablished 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,
and you can view that the establishment of the primary and bypass tunnels succeeds. Thus, the
fault is removed.
----End
Issue 02 (2011-09-10)

58

Summary
It is not recommended to 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 a
HSB Tunnel
Fault Symptom
On the network shown in Figure 2-17, an RSVP-TE tunnel is set up from LSR A to LSR C
along the path 10.1.1.1 -> 10.1.1.2 -> 10.2.1.1 -> 10.2.1.2, and a HSB tunnel is set up from
10.4.1.1 to 10.4.1.2. After the outbound GE2/0/0 on LSR B fails, traffic does not switch to the
HSB 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 a HSB tunnel
Loopback0
1.1.1.1/32
LSRA
GE2/0/0
10.4.1.1/30
Loopback0
2.2.2.2/32
Loopback0
3.3.3.3/32
GE2/0/0
10.2.1.1/30
GE1/0/0
10.2.1.2/30
GE1/0/0
GE3/0/0
10.1.1.2/30 LSRB 10.3.1.1/30
GE2/0/0
10.3.1.2/30
GE1/0/0
10.1.1.1/30
LSRC
GE3/0/0
10.4.1.2/30
Fault Analysis
1.

LSR A to check the explicit path LSR A -> LSR B -> LSR C.
2.
Run the display explicit-path [ path-name ] [ tunnel-interface | verbose ] command on

LSR A to check the explicit path information and the tunnel using the explicit path. The
explicit path includes LSR A and LSR B, but not LSR C, for the primary tunnel.
3.
Run the display mpls te tunnel path tunnel-name command on LSR A 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 LSR A and LSR B, but not LSR
C. 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 LSR B fails, traffic travels through the HSB tunnel is not
affected.
Procedure
Step 1 Run the system-view command on LSR A to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the view of the MPLS TE tunnel
interface.
Issue 02 (2011-09-10)

59

Step 3 Run the undo mpls te path command to delete the loose explicit path LSR A -> LSR B -> LSR
C.
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 LSR A
-> LSR B -> LSR C.
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
A strict explicit path is recommended for the primary tunnel which is supposed to forward traffic
over a pre-set 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 LSR A and
LSR B. The next-hop route from LSR A to LSR B changes, which causes the VPN route unable
to be iterated to the LDP LSP. As a result, VPN services are interrupted from LSR A to LSR B.
Figure 2-18 Networking diagram for the problem that VPN traffic loss is caused by a change
in the next-hop route
Loopback0
1.1.1.1/32
LSRA
Loopback0
2.2.2.2/32
GE1/0/0
10.1.1.1/24
GE2/0/0
10.1.2.1/24
GE1/0/0
10.1.1.2/24
Primary
Backup
GE1/0/0
10.1.2.2/24
LSRB
GE2/0/0
10.1.3.2/24
GE2/0/0
10.1.3.1/24
LSRC
Loopback0
3.3.3.3/32
Issue 02 (2011-09-10)

60

Fault Analysis
1.
Run the display ip routing-table 2.2.2.2 32 command. The route to LSR B is displayed.
For example:
<LSRA> display ip routing-table 2.2.2.2 32
-----------------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
2.2.2.2/32
OSPF
10
10.1.2.2
The command output shows that the next hop to LSR B (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 LSR A. No LSP to LSR B is
established.
3.
Run the display mpls lsp include 3.3.3.3 32 command on LSR A. No LSP to LSR C is
established.
4.
Run the display mpls ldp session command on LSR A. No LDP session to 3.3.3.3 is
established.
5.
Run the display mpls ldp interface command on LSR A. Directly connected interfaces on
LSR A and LSR C have not been enabled with MPLS LDP.
Procedure
Step 1 Run the system-view command on LSR A, LSR B, and LSR C to enter the system view.
Step 2 Run the interface interface-type interface-number command on LSR A, LSR B, and LSR C to
enter the interface view.
Step 3 Run the mpls command on LSR A, LSR B, and LSR C to enable MPLS for interfaces on the
backup LSP.
Step 4 Run the mpls ldp command on LSR A, LSR B, and LSR C 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
Issue 02 (2011-09-10)

61

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
TunnelID
2.2.0.0/17
1.1.2.2
0x0
Flag TimeStamp
Interface
DGU
Pos5/0/0
t[3530817]
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. Thus,
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
Issue 02 (2011-09-10)

62

-----------------------------------------------------------------------------Routing Table :
Public
Summary Count :
1
Destination/Mask
Interface
Proto
Pre
Cost
Flags NextHop
1.1.1.0/25
Pos1/0/0
BGP
255
RD
4.4.4.1
BGP
255
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
TunnelID
2.2.0.0/17
3.3.3.3
0x40b3e0
2.2.0.0/17
3.3.4.4
0xc0b3de
Flag TimeStamp
Interface
DGU
t[3361320]
Pos1/0/0
DGU
t[3361320]
Pos3/0/0
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:
Tunnel Token:
13280
Type:
lsp
Destination:
Out Slot:
1
Instance ID:
0
Out Interface:
Out Label:
Next Hop:
5.
0x40b3e0
3.3.4.3
Pos1/0/0
1097
3.3.3.3
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
Name
3.3.4.3/32
Pos3/0/0
3.3.4.3/32
In/Out Label
In/Out IF
1097/3
-/
1097/3
Vrf
-/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.
Issue 02 (2011-09-10)
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.
63

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. Thus, services are not interrupted.
Issue 02 (2011-09-10)

64

The fault is caused by improper network planning, proper network planning needs to be worked
out to reduce subsequent network maintenance efforts.
Issue 02 (2011-09-10)

65

3 MPLS Forwarding Troubleshooting
MPLS Forwarding Troubleshooting
About This Chapter

3.1 Host Cannot Receive or Send Packets Through an LSP
Issue 02 (2011-09-10)

66

3.1 Host Cannot Receive or Send Packets Through an LSP

3.1.1 Common Causes
l
Routing information is incorrect.
The LSP does not exist.
The LSP status is incorrect in the situation where BFD status is Down.
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.
Check that the LSP exists.
Check that the LSP status is normal.
Check that the system status is normal.
Issue 02 (2011-09-10)

67

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
Routes are
correct?
No
See the section "IGP

Route
Troubleshooting"
Yes
Is fault rectified?
No
Yes
No
LSP exists?
See the section

"LDP LSP Goes
Down"
Is fault rectified?
Yes
No
Yes
LSP status is
normal?
No
See the section

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

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
Issue 02 (2011-09-10)
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, refer to the section "IGP Route Troubleshooting."
68

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 the section LDP LSP Goes
Down .
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. In this case, 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 the section BFD
Session Cannot Go Up.
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.
Issue 02 (2011-09-10)

69

Troubleshooting - MPLS (V600R003C00 - 02)

Uploaded by

Copyright:

Available Formats

Troubleshooting - MPLS (V600R003C00 - 02)

Uploaded by

Document Information

Original Title

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 (V600R003C00 - 02)

Uploaded by

Copyright:

Available Formats

What are some common causes for a host not being able to receive or send packets through an LSP?

What are some common causes for a host not being able to receive or send packets through an LSP?

What is the troubleshooting flowchart for a host not being able to receive or send packets through an LSP?

What is the troubleshooting flowchart for a host not being able to receive or send packets through an LSP?

HUAWEI NetEngine80E/40E Router

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

About This Document

System maintenance engineers

Network monitoring engineers

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

Indicates a hazard with a high level of risk, which if not

Indicates a tip that may help you solve a problem or save

Provides additional information to emphasize or supplement

The keywords of a command line are in boldface.

Command arguments are in italics.

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

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

The parameter before the & sign can be repeated 1 to n times.

A line starting with the # sign is comments.

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

Changes in Issue 02 (2011-09-10)

Changes in Issue 01 (2011-05-30)

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

2.5.15 Volume of Service Traffic on Interfaces of a Device Is Unstable.........................................................61

3 MPLS Forwarding Troubleshooting........................................................................................66

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

1 MPLS LDP Troubleshooting

MPLS LDP Troubleshooting

About This Chapter

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

1 MPLS LDP Troubleshooting

1.1 LDP Session Flapping

1.1.2 Troubleshooting Flowchart

Figure 1-1 shows the troubleshooting flowchart.

See the section

See the section

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router