Professional Documents
Culture Documents
Router
V600R006C00
Troubleshooting - MPLS
Issue 03
Date 2013-08-20
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Purpose
NOTE
l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line
Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On
the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions
of LPUs and SFUs to exchange and forward packets.
This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/
40E in terms of common faults and causes, troubleshooting cases, and FAQs.
This document describes the procedure and method for troubleshooting for the HUAWEI
NetEngine80E/40E.
CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Intended Audience
This document is intended for:
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Convention Description
&<1-n> The parameter before the & sign can be repeated 1 to n times.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Contents
1.6.4 MPLS LDP Peer Relationship Cannot Be Established Because ATM Interfaces Are Not Enabled with the Broadcast
Function..............................................................................................................................................................................21
1.6.5 No LDP Session Can Be Established Between PEs Because the Route to the LSR ID of an LDP Instance Is
Unreachable........................................................................................................................................................................22
1.6.6 MPLS LDP Peer Relationship Cannot Be Established.............................................................................................24
1.6.7 LDP Flaps..................................................................................................................................................................26
1.6.8 Route of the GRE Tunnel Flaps................................................................................................................................28
1.6.9 Load Imbalance Caused by Configuring LDP Transport Addresses.........................................................................30
2 MPLS TE Troubleshooting........................................................................................................33
2.1 TE Tunnel Is Down......................................................................................................................................................34
2.1.1 Common Causes........................................................................................................................................................34
2.1.2 Troubleshooting Flowchart........................................................................................................................................34
2.1.3 Troubleshooting Procedure........................................................................................................................................35
2.1.4 Relevant Alarms and Logs........................................................................................................................................37
2.2 TE Tunnel Suddenly Goes Down.................................................................................................................................37
2.2.1 Common Causes........................................................................................................................................................37
2.2.2 Troubleshooting Flowchart........................................................................................................................................37
2.2.3 Troubleshooting Procedure........................................................................................................................................38
2.2.4 Relevant Alarms and Logs........................................................................................................................................39
2.3 Loop Occurs on a TE Tunnel.......................................................................................................................................39
2.3.1 Common Causes........................................................................................................................................................40
2.3.2 Troubleshooting Flowchart........................................................................................................................................40
2.3.3 Troubleshooting Procedure........................................................................................................................................40
2.3.4 Relevant Alarms and Logs........................................................................................................................................41
2.4 Bidirectional TE Tunnel Goes Down...........................................................................................................................41
2.4.1 Common Causes........................................................................................................................................................41
2.4.2 Troubleshooting Flowchart........................................................................................................................................42
2.4.3 Troubleshooting Procedure........................................................................................................................................42
2.4.4 Relevant Alarms and Logs........................................................................................................................................43
2.5 Related Troubleshooting Cases....................................................................................................................................44
2.5.1 A Loop Occurs Because of the Undeleted IP Address of an Interface That Has Been Shut Down on an RSVP-TE
Tunnel.................................................................................................................................................................................44
2.5.2 Tunnel Goes Down Suddenly and Then Up..............................................................................................................46
2.5.3 Fast Check and Rectify the Problem of Route Loops...............................................................................................47
2.5.4 Tunnel Flaps Every Several Minutes After IGP Shortcut Is Enabled.......................................................................48
2.5.5 TE Tunnel of the Inter-OSPF Area Fails to Be Set Up.............................................................................................50
2.5.6 Tunnel Goes Down After Switchover.......................................................................................................................52
2.5.7 Tunnel Creation Fails Because of Authentication Failure.........................................................................................53
2.5.8 Calculation of the Tunnel Path Fails.........................................................................................................................55
2.5.9 Path with the Smallest Metric Is Not Selected..........................................................................................................57
2.5.10 Establishment of the Hot-Standby LSP Fails..........................................................................................................58
2.5.11 FRR Binding Fails...................................................................................................................................................59
2.5.12 Primary Tunnel Turns Down When Configuration of the Bypass Tunnel Is Modified..........................................61
2.5.13 After the Primary Tunnel Fails, Traffic Does Not Switch to an HSB Tunnel.........................................................62
2.5.14 VPN Traffic Loss Is Caused by a Change in the Next-hop Route..........................................................................64
2.5.15 Volume of Service Traffic on Interfaces of a Device Is Unstable...........................................................................65
l The configuration of the LDP GR timer, the LDP MTU, LDP authentication, the LDP
Keepalive timer, or the LDP transport address is set, changed, or deleted.
l An interface flaps.
l Routes flap.
LDP session
flaps
Yes Yes
LDP session Wait 10 seconds Is fault rectified?
is recreated?
No
No
Seek technical
End
support
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that LDP GR, a Keepalive timer, LDP authentication, an LDP MTU, or a transport address
is configured.
1. Run the display this command in the LDP view to view the configuration of LDP GR, an
LDP MTU, or LDP authentication.
l If the following information is displayed, LDP GR is configured.
mpls ldp
graceful-restart
l If the command output displays the following information, the LDP MTU value is set.
mpls ldp
mtu-signalling
2. Run the display this command in the interface view to view an LDP Keepalive timer or
an LDP transport address.
l If the command output displays the following information, the LDP Keepalive timer is
set. The timer value (30 seconds in the following example) depends on the real-world
situation.
mpls ldp
mpls ldp timer keepalive-hold 30
l If the command output displays the following information, the LDP transport address
is set. The transport address and interface type and number can be set as needed.
mpls ldp
mpls ldp transport-address interface
l If any of the configurations you checked in sub-steps 1 and 2, wait 10 seconds and check
whether the LDP session flaps.
l If no configuration has been performed, go to Step 2.
Step 2 Check that the interface does not alternate between Down and Up.
Run the display ip interface brief command and view the Physical and Protocol fields in the
command output. If both fields display Up, the interface is Up; if one field displays Down, the
interface is Down. If the interface always alternates between Down and Up, the interface flaps.
l If the interface alternates between Down and Up, see the section "Interface Flapping".
l If the interface does not flap, go to Step 3.
Step 3 Check that the routes do not alternate between unreachable and reachable.
Run the display fib command quickly to check routing information. If routes are reachable,
routing information is displayed. If no route is reachable, no routing information is displayed.
If sometimes routing information is displayed, but sometimes not, the routes alternate between
unreachable and reachable.
l If routes alternate between unreachable and reachable or no route exists, see The Ping
Operation Fails.
l If the routes do not flap, go to Step 4.
Step 4 Collect the following information, and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, logs, and alarms
----End
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.
Figure 1-2 Troubleshooting flowchart for the fault that an LDP session goes Down
LDP session
goes Down
Yes
Routes are No Troubleshoot the
Is fault rectified?
reachable? routes problem
No
Yes
No No
Seek technical
End
support
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that the interface on which the LDP session is established is shut down.
Run the display this command in the interface view. If the following information is displayed,
the interface has been shut down.
shutdown
l If the interface has been shut down, run the undo shutdown command to restart the
interface.
l If the interface is Up, go to Step 2.
Step 2 Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
Run the display current-configuration command.
l If the command output does not include the following information, MPLS is disabled.
mpls
l If the command output does not include the following information, MPLS LDP is disabled.
mpls ldp
l If the command output does not include the following information, the remote LDP session
is deleted.
mpls ldp remote peer
Step 6 Collect the following information, and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, logs, and alarms
----End
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
LDP/4/SSNHOLDTMREXP
LDP LSPs
flap
Seek technical
support End
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that the routes alternate between unreachable and reachable.
Run the display ip routing-table command to check information about the routes to the
destination of the LSP. Run this command at 1-second interval. If routes exist, routing
information is displayed. If no routes exist, no routing information is displayed. If sometimes
routing information is displayed but sometimes not after the command is run several times, the
routes alternate between unreachable and reachable.
l If routes alternate between unreachable and reachable or no route is displayed, see The Ping
Operation Fails and rectify the fault in IGP routes.
l If the routes are always reachable, go to Step 2.
Step 3 Collect the following information, and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, logs, and alarms
----End
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
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.
Figure 1-4 Troubleshooting flowchart for the fault that an LDP LSP goes Down
LDP LSP
Down
No Yes
IGP routes See "IGP Route
Is fault rectified?
exist? Troubleshooting"
No
Yes
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that routes exist.
If routing information is displayed and the value of the State field is Active Adv in the command
output, a route reachable and is in the active state. If the route is a BGP route of a public network,
check the Label field in the command output. If a value is displayed, not NULL, routing
information carries a label.
l If no route appears, the routes are not in the active state, or the BGP routes do not carry
labels, see The Ping Operation Fails.
l If BGP routes are reachable and in the active state, they carry labels. Go to Step 2.
Step 3 Check that resources are insufficient. The number of resources defined in the PAF/license file,
the number of tokens, or the number of labels reaches the upper limit, or memory is insufficient.
Perform the following steps to check that resources are insufficient.
1. Check whether the number of LSPs reaches the upper limit defined in the PAF/license file.
Run the display mpls lsp statistics command to check the Total field subject to the LDP
LSP field. If the value is greater than that defined in the PAF/license file, resources are
insufficient.
2. Check that tokens to establish ingress LSPs or transit LSPs are used up.
Run the display tunnel-info statistics command to view token statistics. The Global-1
Avail Tunnel-ID Num field shows the total number of available tokens, and the Global-1
Allocated Tunnel-ID Num field shows the number of used tokens. If the values of these
two fields are the same, the tokens are used up and resources are insufficient.
l If resources are insufficient, increase the upper limit of the resources or delete unwanted
LSPs.
l If resources are sufficient, go to Step 4.
l Run the display this command in the MPLS LDP view. If the following information is
displayed, an IP-prefix-based policy has been configured to trigger the establishment of
LSPs. The policy name (abc in the following example) depends on the real-world situation.
Then, check that some LSPs are not included in the IP-prefix-based policy.
propagate mapping for ip-prefix abc
l Run the display ip ip-prefix command in the system view. If the following information is
displayed, only routes to 1.1.1.1/32 and 2.2.2.2/32 can be used to trigger the establishment
of LSPs. The IP addresses (1.1.1.1/32 and 2.2.2.2/32 in the following example) depend on
the real-world situation.
l If one of the policies for establishing LSPs is configured, add the route to the destination
of the required LSP to the policy.
l If no policy is configured, go to Step 5.
Step 5 Collect the following information, and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, logs, and alarms
----End
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
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.
l Check that the route associated with the LDP session matches the route in the routing table.
Figure 1-5 Flowchart for troubleshooting the failure in establishing an inter-area LSP
An inter-area
LSP cannot
be
established
Is LDP Yes
No Enable the inter-
inter-area LDP
area LDP Is fault rectified?
extension
extension
enabled?
No
Yes
No
Yes
Does
the LDP route Yes
No See "LSP Goes
match the route Is fault rectified?
Down"
in the routing
table ? No
Yes
Seek
technical
support End
Context
NOTE
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.
Perform the following procedure along an LSP from the egress to the ingress.
Procedure
Step 1 Check that routes are reachable.
If routes are reachable, and the State field displays Active Adv, routes associated with the LSP
are reachable and are in the active state. If the Label field displays a value, not NULL, public
network BGP routes carry labels.
NOTE
Either the longest match rule or the exact match rule can be used to search for a reachable route.
l If no route is reachable, the reachable routes are in the inactive state, or BGP routes do not
carry labels, follow the procedure in Ping Failures
l If the routes are reachable in the active state and BGP routes carry labels, go to Step 2.
Step 2 Check that the inter-area LDP extension has been enabled.
Run the display mpls ldp command. If the Longest-match field displays On, the inter-area
LDP extension has been enabled; if Off is displayed, the inter-area LDP extension has not been
enabled.
l If the inter-area LDP extension is disabled, run the longest-match command to enable the
inter-area LDP extension.
l If the inter-area LDP extension has been enabled, go to Step 3.
Step 4 Check that the route associated with the LDP session matches the route in the routing table.
Run the display ip routing-table command, and check the NextHop and Interface fields.
Run the display mpls ldp session verbose command, and check the Addresses received from
peer field.
Run the display mpls ldp peer command, and check the DiscoverySource field.
If the value in the NextHop field is displayed as part of information in the Addresses received
from peer field, and the value in the Interface is the same as that in the DiscoverySource field,
the route associated with the LDP session matches the route in the routing table.
l If the LDP session does not match routes, follow the procedure in LDP LSP Goes
Down.
l If the LDP session matches routes, go to Step 5.
Step 5 Collect the following information and contact Huawei technical support personnel.
----End
Relevant Logs
None
RouterA RouterB
A Point-to-Point Protocol (PPP) link connects Router A with Router B. When a static LSP is
configured, the LSP on the ingress goes Down.
Fault Analysis
Establishing a static LSP according to a routing protocol. When you configure a static LSP on
the ingress LSR, the local routing table must contain a routing entry exactly matching the
destination IP address. The routing entry includes the destination IP address and the next-hop
IP address.
1. Use the display mpls static-lsp verbose command. You can see that the forwarding
equivalence class (FEC) is 2.2.2.9/32 and the next-hop IP address is 10.1.1.1.
<RouterA> display mpls static-lsp ad verbose
No : 1
LSP-Name : ad
LSR-Type : Ingress
FEC : 2.2.2.9/32
In-Label : NULL
Out-Label : 30
In-Interface : -
Out-Interface : -
NextHop : 10.1.1.1
Static-Lsp Type: Normal
Lsp Status : Down
2. Use the display ip routing-table command. You can see that the destination IP address is
2.2.2.9/32 and the next-hop IP address is 10.1.1.2.
<RouterA> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 InLoopBack0
2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.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 to view the
configuration of the static LSP.
<RouterA> display current-configuration | include static-lsp
static-lsp ingress ad destination 2.2.2.9 32 outgoing-interface Pos1/0/0 out-
label 30
Procedure
Step 1 Run static-lsp ingress lsp-name destination ip-address mask-length nexthop next-hop-
address out-label out-label command in the system view to configure the static LSP by
designating next hops.
static-lsp ingress ad destination 2.2.2.9 32 nexthop 10.1.1.2 out-label 30
After the preceding configuration, the value of the Lsp Status field is Up in the display mpls
static-lsp verbose command output. The fault is rectified.
----End
Summary
When you configure a static LSP on an ingress LSR, ensure that a routing entry exactly matching
the specific destination IP address exists in the local routing table. The routing entry includes
the destination IP address and next hop IP address.
l If the routing entry is learnt from a dynamic routing protocol, the next hop must be
designated when you configure the static LSP. Moreover, the designated next hop must the
same as that in the corresponding routing entry.
l If you configure a static LSP by specifying an outgoing interface, ensure the following
conditions:
Fault Symptom
On the network shown in Figure 1-7, LSRB, LSRC, and LSRD are in Area 10, and LSRA is in
Area 20. LSRD aggregates routes associated with LSRB and LSRC and advertises a summary
route to Area 20. The inter-area LDP extension is enabled on LSRA.
Loopback0
1.3.0.1/32
0/1
Loopback0 Loopback0 S1/ /24 0 LSRB
O 1 /0/ 24
1.1.0.1/32 1.2.0.1/32 P .1.1. 1
S 2/
POS1/0/0 20 PO 1.1.
. IS-IS
10.1.1.1/24 PO 20
20 S1 Area10
POS1/0/0 .1. /0/
2.1 2
LSRA 10.1.1.2/24 LSRD /24 Loopback0
1.3.0.2/32
IS-IS PO
Area20 20 S1
.1. /0/
2.2 0
/24
LSRC
Fault Analysis
1. Run the display ip routing-table command on LSRA to view routing information. No
information about a summary route to the inter-area LSP destination address is displayed.
2. Run the display mpls ldp command on LSRA. The Longest-match field displays Off,
indicating that the inter-area LDP extension is not enabled. This causes the failure in
establishing an inter-area LSP.
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.
Fault Symptom
On the network shown in Figure 1-8, Router B is deployed between Routers A and C. Two POS
links between Routers B and C are used to implement load balancing.
Traffic is unevenly distributed over the links from Router C to Router B, whereas traffic is evenly
distributed over the links from Router B to Router C.
Figure 1-8 Networking where incorrect LDP transport addresses cause uneven load balancing
POS2/0/0
Fault Analysis
The possible causes of this fault are as follows:
l The traffic model is incorrect.
l Load balancing is not implemented between routes over the POS links.
l Load balancing is not implemented between LSPs over the POS links.
Procedure
Step 1 As traffic is unevenly distributed over the links from Router C to Router B and Router C has
already been deployed on the network, the traffic model is not changed when Router B is
deployed. Therefore, an incorrect traffic model can be ruled out as the source of the fault.
Step 2 Run the display ip routing-table command to check whether load balancing is implemented
between the routes over the POS links.
<RouterC> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 18409 Routes : 21796
NOTE
The preceding command output contains only routing information for some of the main network segments. To
determine whether load balancing is implemented between routes, check the entire routing table.
The preceding command output shows that the routes over the POS links are implementing load
balancing, but traffic is not evenly distributed over the links. Therefore, traffic is not being
balanced using IP.
Step 3 Run the display mpls lsp outgoing-interface interface-type interface-number command to
check whether load balancing is implemented between the LSPs over the links.
Check information about the LSPs established by POS 1/0/0 and POS 2/0/0.
<RouterC> display mpls lsp outgoing-interface Pos 1/0/0
no command output
<RouterC> display mpls lsp outgoing-interface Pos 2/0/0
-----------------------------------------------------------------------------
LSP Information: LDP LSP
-----------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
112.100.5.16/30 NULL/3 -/Pos2/0/0
112.100.5.16/30 1041/3 -/Pos2/0/0
112.100.7.1/32 1043/3 -/Pos2/0/0
112.100.7.1/32 NULL/3 -/Pos2/0/0
The preceding command output shows that only POS 2/0/0 is used to establish LSPs and POS
1/0/0 is not used to establish LSPs. This is consistent with the fact that POS 1/0/0 has no traffic.
Step 4 Find out why POS 1/0/0 does not establish LSPs.
Check information about established LDP sessions. The command output shows that Router C
has established an LDP session only using POS 2/0/0.
<RouterC> display mpls ldp peer
LDP Peer Information in Public network
----------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
----------------------------------------------------------------------------
......
112.100.7.1:0 112.100.5.5 Pos2/0/0 ====POS 1/0/0 does not establish
any LDP session.
......
----------------------------------------------------------------------------
The preceding command output shows that the mpls ldp transport-address interface command
has been run on POS 1/0/0 and POS 2/0/0 to set the addresses of POS 1/0/0 and POS 2/0/0 as
transport addresses. When the mpls ldp transport-address interface command is run and LDP
sessions are to be established over multiple links between LSRs, LDP-enabled interfaces of each
device must use the same transport address. If multiple transport addresses are configured on a
device, only one transport address can be used to establish an LDP session. To establish LDP
sessions over multiple links and implement load balancing among the links, delete the mpls ldp
transport-address interface command configuration.
Step 6 Run the undo mpls ldp transport-address command to delete configurations on POS 1/0/0 and
POS 2/0/0. Then check information about traffic load balancing between the interfaces. The
command output shows that traffic in the two directions is evenly balanced between the links.
The fault is rectified.
----End
Summary
If LDP sessions are to be established over multiple links between two LSRs, LDP-enabled
interfaces of each LSR must use the default transport address or the same transport address. If
multiple transport addresses are configured on an LSR, only one transport address can be used
to establish an LDP session.
Fault Symptom
MPLS LDP is deployed on the network shown in Figure 1-9. An MPLS LSP is established
between LSR A and LSR C by using MPLS LDP. After the configurations, MPLS LDP peer
relationship cannot be established between LSR A and LSR C.
Figure 1-9 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
Fault Analysis
NOTE
This troubleshooting case takes the configurations of LSR A as an example. Troubleshooting the fault on
LSR B and LSR C is similar and is omitted.
1. Run the display current-configuration interface atm 1/0/0 command on LSR A to view
the configurations on the ATM interface.
interface Atm1/0/0
undo shutdown
pvc 2/33
pvc 2/34
pvc 2/35
mpls
mpls ldp
MPLS LDP broadcasts packets. ATM interfaces, however, do not forward broadcast
packets by default. As a result, the MPLS LDP peer relationship cannot be established
between LSR A and LSR C.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface atm interface-number command to enter the ATM interface view.
Step 3 Run the pvc { pvc-name [ vpi/vci ] | vpi/vci } command to enter the ATM-PVC view.
Step 4 Run the map ip inarp broadcast command to enable broadcast on the ATM interface.
After the preceding operations, run the display mpls ldp peer command to check that the MPLS
LDP peer relationship has been established between LSR A and LSR C. The fault is therefore
rectified.
----End
Summary
MPLS LDP broadcasts packets. ATM interfaces, however, do not forward broadcast packets by
default. As a result, the MPLS LDP peer relationship cannot be established between LSR A and
LSR C. When configuring MPLS LDP on an interface, ensure that the interface is able to
broadcast protocol packets.
Fault Symptom
MPLS is deployed on the network shown in Figure 1-10. With this configuration, no LDP
session can be established between PE1 and PE2.
Figure 1-10 Networking diagram of the case where no LDP session can be established between
PEs
Loopback 0 Loopback 0
1.1.1.1 3.3.3.3
PE1 PE2
Loopback 1 Loopback 1
100.100.100.100 210.210.210.210
Fault Analysis
1. Run the debugging mpls ldp session command on PE1 and PE2. The command output
shows that PE1 and PE2 can exchange Hello packets but the LDP status alternates between
the Non-existent state and the Initialized state. The following diagnostic information shows
that the address of Loopback1 is used as the LSR ID for establishing an LDP session
between PE1 and PE2.
Diagnostic information on PE1:
*0.1513340 PE1 LDP/8/Session:
Gigabitethernet1/0/0
Link Hello message received on interface:
Gigabitethernet1/0/0
*0.1513340 PE1 LDP/8/Session:
Created session with LSR:
210.210.210.210
*0.1513340 PE1 LDP/8/Session:
Gigabitethernet1/0/0
Link Hello message sent on interface:
Gigabitethernet1/0/0
*
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 1 Run the system-view command to enter the system view.
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.
Fault Symptom
On the network shown in Figure 1-11, MPLS is configured on a router and an MA5200G, but
MPLS LDP peer relationship cannot be established between the two devices.
Figure 1-11 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
GE1/0/0 GE1/0/0
Router MA5200G
Fault Analysis
1. Run the debugging mpls ldp all command on the router. The command output shows that
the router has not received any Hello packet from the MA5200G.
2. Run the display this command on GigabitEthernet 1/0/0 to check its configuration. The
command output shows that traffic-policy ma5200g inbound is configured on the
interface. Analysis on this traffic policy shows that the last rule is configured to reject
multicast packets from 224.0.0.2.
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 1 Run the system-view command to enter the system view.
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.
Fault Symptom
G E 1 /0 /0
LSR A
G E 2 /0 /0
LSR C
On the network shown in Figure 1-12, the LDP sessions on two upstream interfaces (GE 1/0/0
and GE 2/0/0) of the device alternate between Up and Down. When the telnet command is run
on the device, the device responds slowly.
Fault Analysis
1. Run the display logbuffer command to check the logs generated by the device. You can
find that LDP frequently flaps because the device cannot normally receive Keepalive
messages.
#Aug 17 12:46:40 2009 SX LDP/4/SessionDown: Session(1.1.1.1:0. public
Instance)'s state change to Down
Aug 17 2009 12:46:40 SX %%01LDP/4/SSNHOLDTMREXP(l): Sessions were deleted
because the session hold timer expired and the notification of the expiry was
sent to the peer 1.1.1.1.
The Keepalive messages of LDP are carried by TCP packets with the port number being
646.
2. Run the display health command to check the CPU usage of the device. You can find that
the CPU usage of the LPU in slot 1 and the LPU in slot 2 is high.
Slot CPU Usage Memory Usage(Used/Total)
----------------------------------------------------
10 MPU(Master) 27% 19% 378MB/1901MB
1 LPU 25% 50% 203MB/405MB
2 LPU 24% 50% 203MB/405MB
3 LPU 5% 48% 196MB/405MB
4 LPU 19% 49% 202MB/405MB
5 LPU 12% 50% 203MB/405MB
3. Run the display cpu-usage slot 1 command to check the CPU usage of the device. You
can find that the TSD task and SOCK task consume a lot of CPU resources, indicating that
a large number of packets are sent to the CPU for processing.
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage : 24% Max: 68%
CPU Usage Stat. Time : 2009-08-17 14:04:02
CPU Usage Stat. Tick : 0x15286(CPU Tick High) 0x13a9ba5e(CPU Tick Low)
Actual Stat. Cycle : 0x0(CPU Tick High) 0x77c5c6f7(CPU Tick Low)
TaskName CPU Runtime(CPU Tick High/CPU Tick Low)
BUFM 0% 0/ 20058e
VIDL 0% 0/5bcbca6e
TICK 0% 0/ 63102e
VT 0% 0/ 16d51
IPCR 0% 0/ 29fa9
VPR 0% 0/ 5ea0b28
VPS 2% 0/ 3212994
ECM 0% 0/ 474be
BEAT 0% 0/ a021c
RTMR 0% 0/ 313356
IPCQ 0% 0/ 59ad08
VP 0% 0/ 2ca
RPCQ 0% 0/ 3a660
VMON 0% 0/ 7438
STND 0% 0/ 955f3
INFO 0% 0/ 2ed9
APS 0% 0/ 8180c
FIB6 0% 0/ 124a2e
FHM 0% 0/ 969e2
BFD 0% 0/ 1117d0
OAM 0% 0/ 127ab0
SNPG 0% 0/ 1127b
ADPT 0% 0/ 450505
QAT 0% 0/ 744d
ATMA 0% 0/ de6e
LLDP 0% 0/ d6ed
SECL 0% 0/ 2318
FLD 0% 0/ 1975d
EOAM 0% 0/ a75c38
TRAF 0% 0/ fdc45
FIB 0% 0/ 19b69
SOCK 25% 0/ 615ece3
IFNT 0% 0/ 5ccbf
L2TP 0% 0/ 290e
TUNN 0% 0/ 1d36
DIAG 0% 0/ 3b8564
SRM 0% 0/ 173ee1
NPS 0% 0/ e1bb5
TSC 0% 0/ 1f9d15
TSD 5% 0/ 6b2e2f8
MAG 0% 0/ 84935e
ALT 1% 0/ 1cc6f28
TSTA 0% 0/ 10800c
ARPV 0% 0/ 3ff11
MACF 0% 0/ 2b6dd1
HQOS 0% 0/ 1efbb5
NE50 0% 0/ 12d6d
STAT 0% 0/ 5e1c3
SQOS 0% 0/ 19b02d
QOSA 0% 0/ 156699
DEFD 0% 0/ 4265
VRRP 0% 0/ 1f78
OS 7% 0/ 0
4. Capture packets on the mirrored interface. You can find that the packets are received
through GE 1/0/0 and GE 2/0/0 and the destination address of the packets is 10.1.1.255.
The destination address is a broadcast address, and is on the same network segment with
the IP address of Eth-Trunk 5. For details about the mirroring configuration, see chapter
"Mirroring Configuration" in the Configuration Guide - Security.
The preceding analysis shows that the attack packets are from GE 1/0/0 and GE 2/0/0, the
destination address of the packets is a broadcast address, and the attack packets are from
the network segment where Eth-Trunk 5 resides.
Procedure
Step 1 Run the system-view command to enter the system view.
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.
Fault Symptom
NOTE
On the network shown in Figure 1-13, PE1 and PE2 connect to the public network by using
default routes. A GRE tunnel is set up between PE1 and PE2. A tunnel interface is configured
at each end of the tunnel, and its IP address is a private network address. The source interface
(at the local end) and destination interface (at the peer end) of the tunnel are configured on each
tunnel interface, using public network addresses. OSPF is enabled on the GRE tunnel interfaces
and direct routes are imported into OSPF.
When the configuration is complete, the route of the GRE tunnel becomes unreachable
occasionally.
Figure 1-13 Networking diagram of the flapping of the route of the GRE tunnel
Public network
PE 1 10.1.1.1 20.1.1.1 PE 2
GRE Tunnel
30.1.1.1 Tunnel1/0/1 Tunnel1/0/1 40.1.1.1
10.2.1.1 10.2.1.1
CE 1 CE 2
Fault Analysis
1. Rooting loops may exist on the network, which will cause the problem.
2. Log in to PE1 (or PE2), and then run the display ospf routing command to check the OSPF
routing table. You can find that there is an external route to the public network address of
an interface on PE2 (or PE1). Obviously, this route is imported into OSPF as a direct route
on the peer end and then learned by the local end.
3. The router considers that the direct route (that is, the GRE tunnel) can reach the public
network address of the peer end and prefers the direct route to the default route. The GRE
tunnel, however, uses the route on the public network, and this route is the default route.
Because the default route is not chosen by the router in route iteration, the GRE tunnel is
unavailable.
4. After a period of time, the OSPF neighbor relationship between the PEs goes Down, and
the public network routes learned through OSPF are lost. Then, the router can access the
public network interface of the peer PE through the default route again, and the GRE tunnel
becomes available. Then, the OSPF neighbor relationship can be set up between the PEs
again. The process repeats and causes the GRE tunnel to switch between the states of
unavailable and available.
Therefore, PE1 and PE2 need to advertise static private network routes to each other or
cancel the import of direct routes into OSPF so that OSPF will advertise only the private
network segment route of the interface.
Procedure
Step 1 Run the system-view command to enter the system view on the PE.
Step 2 Run the ip route-static ip-address { mask | mask-length } tunnel interface-number command
to advertise the static private network route to the peer PE.
NOTE
If the dynamic routing protocol needs to be used, you can configure OSPF to advertise only the private network
segment routes of interfaces: First, run the undo import-route direct command in the OSPF area view to delete
the imported direct routes. Then, run the network address wildcard-mask command to configure OSPF to
advertise only CE-side routes.
----End
Summary
When a GRE tunnel is configured, usually static private network segment routes are adopted
because they are reliable. If the customer requires a dynamic routing protocol such as OSPF,
avoid configuring import of direct routes into the routing protocol. Otherwise, route iteration
may ensue, which will cause some unexpected faults.
Typical Networking
On the network shown in Figure 1-14, Router B is added between Router A and Router C, load
balancing is performed over two POS links between Router B and Router C.
Figure 1-14 Networking diagram for load imbalance caused by configuring LDP transport
addresses
Pos 1/0/0
Pos 2/0/0
Router A Router B Router C
After the configuration is complete, the load between C and B is totally imbalanced while that
between B and C is balanced. Statistics about traffic on C are as follows:
<HUAWEI> display interface brief
Interface PHY Protocol InUti OutUti inErrors outErrors
Pos1/0/0 up up 41% 1% 0 0
Pos2/0/0 up up 40% 83% 0 0
Fault Analysis
1. Check that LSPs implement load balancing on Router C.
The following command output shows that an LSP is established on POS 2/0/0, and no
LSP is established on POS 1/0/0. This result complies with the fact that there is no traffic
on POS 1/0/0.
<HUAWEI> display mpls lsp outgoing-interface Pos 1/0/0
<HUAWEI> display mpls lsp outgoing-interface Pos 2/0/0
-----------------------------------------------------------------------------
LSP Information: LDP LSP
-----------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
112.100.5.16/30 NULL/3 -/Pos2/0/0
112.100.5.16/30 1041/3 -/Pos2/0/0
112.100.7.1/32 1043/3 -/Pos2/0/0
112.100.7.1/32 NULL/3 -/Pos2/0/0
NOTE
After the display mpls lsp outgoing-interface Pos 1/0/0 command is run, no information is displayed
by the system. This means there is no LSP created on POS 1/0/0.
2. Check the causes why no LSP is created on POS 1/0/0 of Router C.
Check whether an LDP session is created first. The following command output shows that
Router C only creates an LDP peer session on POS 2/0/0. This means the configuration is
incorrect.
<HUAWEI> display mpls ldp peer
mpls ldp
mpls ldp transport-address interface
#
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
mpls
mpls ldp
mpls ldp transport-address interface
#
......
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 inErrors outErrors
Pos1/0/0 up up 44% 50% 0 0
Pos2/0/0 up up 44% 50% 0 0
----End
Summary
Traffic imbalance occurs in one of the following situations:
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.
2 MPLS TE Troubleshooting
l The mpls te commit command is not configured to commit the TE tunnel configuration.
l CSPF fails to calculate a path.
l RSVP is not enabled on a device along the TE tunnel.
l Devices fail to exchange RSVP Path or Resv messages along the TE tunnel.
Figure 2-1 Troubleshooting flowchart for the fault that a TE tunnel is Down
TE tunnel goes
Down
The
Yes Yes
Commit Run the mpls te
Is fault rectified?
command is not commit command
run?
No
No
Route
CSPF fails Yes to the tunnel No See the section "IGP
to calculate a destination does Route
path? not exist? Troubleshooting"
Yes
No Trouble shooting
CSPF Fails
Yes Yes
RSVP is not
Enable RSVP Is fault rectified?
configured?
No
No
Yes Yes
Packet Cannot See the section "IP
Is fault rectified?
be exchanged? Forwarding Fails"
No
No
Seek technical
End
support
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 the mpls te commit command has been configured to commit the TE tunnel
configuration.
Run the display current-configuration command on the ingress that is configured with the TE
tunnel.
l If the mpls te commit command is not displayed in the command output, run the mpls te
commit command.
l If the mpls te commit command is displayed in the command output but the fault persists,
go to Step 2.
Step 3 Check that RSVP is enabled on every device along the TE tunnel.
The display mpls te cspf destination ip-address explicit-path path-name command output in
Step 2 contains a series of IP addresses. These IP addresses indicate the hops along the TE tunnel.
On the interface mapped to each IP address, run the display current-configuration interface
interface-name command to check if RSVP is enabled.
l If an interface is not enabled with RSVP, enable RSVP on the interface.
l If all interfaces are enabled with RSVP but the fault persists, go to Step 4.
Step 4 Check that devices along the TE tunnel have been successful in exchanging RSVP Path and
Resv messages.
Run the display mpls te tunnel-interface command on the ingress of the TE tunnel to check
fields Ingress LSR ID, LSP ID, and Session ID in the command output. In Step 3, LSRA,
LSRB, and LSRC are identified to be the nodes along the TE tunnel.
Perform the following steps to check whether the RSVP Path and Resv messages are correctly
transmitted:
l Check whether RSVP Path messages are correctly sent and received on every node along the
LSP in the sending direction (LSRA -> LSRB -> LSRC).
Run the display mpls rsvp-te psb-content command on every node along which the RSVP
Resv messages travel.
If the command output is not empty on any node, RSVP Path messages are correctly sent
and received between these nodes.
If the command output is empty on a node, the node fails to receive RSVP Path messages
from the upstream node.
l Check whether RSVP Resv messages are correctly transmitted in the sending direction
(LSRC -> LSRB -> LSRA).
Run the display mpls rsvp-te rsb-content command on every node along which the RSVP
Resv messages travel.
If the command output is not empty on any node, RSVP Resv messages are correctly
transmitted.
If the command output is empty on a node, the node fails to receive RSVP Resv messages
from the upstream node.
l If messages fail to be properly exchanged, see the section "IP Forwarding Fails" and rectify
the fault.
l If messages are properly exchanged but the fault persists, go to Step 5.
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 devices
----End
Relevant Logs
None.
Figure 2-2 Troubleshooting flowchart for the fault that a TE tunnel goes suddenly Down
TE tunnel
goes Down
suddenly
Seek technical
End
support
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check whether a command has been run to delete the configuration associated with the TE
tunnel.
Run the display current-configuration command on the ingress of the TE tunnel to check
whether the following command is run:
l interface tunnel interface-number
Step 2 Check whether any physical interface along the TE tunnel is Down.
1. Record the time when the log IFNET/4/LINKNO_STATE indicating that the TE tunnel
goes Down was generated. Record the time as T1.
2. Run the display mpls te cspf destination ip-address explicit-path path-name command
on the ingress of the tunnel. The command output contains a series of IP addresses. These
IP addresses identify the nodes along the TE tunnel. Record these nodes along the TE tunnel.
3. Run the display interface interface-type interface-number command on each node of the
TE tunnel. Record the time displayed in the Last line protocol up time field as T2.
l If T1 is greater than T2, the TE tunnel went Down because the physical interface on the
TE tunnel is faulty. See the section "Physical Interface Is Faulty."
l If T1 is smaller than T2, go to Step 3.
Collect logs generated 10 minutes before T1 (see Step 2) on every node along the TE tunnel to
check whether either of the following logs is displayed:
l RSVP/6/PSB_CLEAN_TIMEOUT
l RSVP/6/RSB_CLEAN_TIMEOUT
l If either of the preceding logs is displayed, see the section "IP Forwarding Fails" and rectify
the fault.
l If neither of the preceding logs is displayed, go to Step 4.
Step 4 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 devices
----End
Relevant Alarms
None.
Relevant Logs
IFNET/4/LINKNO_STATE
RSVP/6/PSB_CLEAN_TIMEOUT
RSVP/6/RSB_CLEAN_TIMEOUT
l A loop occurs on the link along which an RSVP Path message travels.
l A loop occurs on the link along which an RSVP Resv message travels.
Figure 2-3 Troubleshooting flowchart for the fault that a loop occurs on a TE tunnel
Loop occurs when
transmitting the TE
tunnel
Yes Yes
Loop occurs Delete one of two
when transmitting the identical If fault rectified?
Resv message? addresses
No
No
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that no loop occurs on the link along which RSVP Path messages travel.
If the log RSVP/3/LOOP_PATH is generated, a loop occurs on the link along which RSVP Path
messages travel.
Run the display mpls te cspf destination ip-address explicit-path path-name command. The
command output contains a series of IP addresses. These IP addresses and LSR IDs identify the
nodes along the TE tunnel.
On the node where the log RSVP/3/LOOP_PATH is generated, run the tracert ip-address
command. In this command, the ip-address is the IP address of each hop on the TE tunnel. If
the following information is displayed, ip-address is the same as an existing one and IP address
collision occurs.
Error: The destination address cannot be a local address.
l In the case of IP address collision, delete or change the IP address of the node.
l If no IP address collision occurs but the fault persists, go to Step 2.
Step 2 Check that no loop occurs on the link along which RSVP Resv messages travel.
If the log RSVP/3/LOOP_RESV is generated, a loop occurs on the link along which RSVP Resv
messages travel.
Step 3 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 devices
----End
Relevant Alarms
None.
Relevant Logs
RSVP/3/LOOP_PATH
RSVP/3/LOOP_RESV
l MPLS TE is not enabled on the outbound interface of the bidirectional static CR-LSP that
is bound to the bidirectional TE tunnel.
l The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is Down.
l The outbound interface of the bidirectional CR-LSP that is bound to the bidirectional TE
tunnel is allocated insufficient bandwidth.
Figure 2-4 Troubleshooting flowchart for a problem that a bidirectional TE tunnel goes Down
Bidirectional TE
Tunnel goes Down
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Run the display current-configuration command on the nodes where the tunnel is set up to
check that the bidirectional TE tunnel is correctly configured.
l Ingress:
If the tunnel is not enabled with the bidirectional LSP attribute, run the mpls te
bidirectional command in the tunnel view to enable the bidirectional LSP attribute.
This tunnel is an ingress tunnel and is bound to a bidirectional static LSP.
If the name of the bidirectional static CR-LSP on the ingress is different from the name
of the tunnel, run the bidirectional static-cr-lsp ingress tunnel-name command to
change the name of the bidirectional static CR-LSP.
l Egress:
If the reverse tunnel attribute is not enabled for the tunnel, run the mpls te passive-
tunnel command to enable the reverse tunnel attribute. The reverse tunnel itself does
not trigger the generation of a CR-LSP but can be bound to a reverse LSP for upper
layer applications.
If the tunnel is not bound to a bidirectional static LSP, run the mpls te binding command
to bind the tunnel to a bidirectional static LSP on the egress.
Step 2 Check the status of the outbound interface of the bidirectional static CR-LSP that is bound to
the bidirectional TE tunnel.
Run the display ip interface brief command on the tunnel node to view the status of the
outbound interface.
l If the outbound interface is Down, see "Physical Interconnection Troubleshooting."
l If the outbound interface is Up, go to Step 3.
Step 3 Check that the sufficient bandwidth is allocated to the outbound interface of the bidirectional
static CR-LSP that is bound to the bidirectional TE tunnel.
l If the remaining bandwidth of the outbound interface of the bidirectional static CR-LSP is
less than the configured value, reconfigure the remaining bandwidth.
l If the remaining bandwidth of the outbound interface of the bidirectional static CR-LSP is
greater than the configured value, go to Step 4.
Step 4 Collect the following information and contact Huawei technical support personnel:
l Results of the preceding troubleshooting procedure
l Configuration, log, and alarm files
----End
Fault Symptom
On the network shown in Figure 2-5, RSVP-TE is enabled, and bidirectional RSVP-TE tunnels
are established between LSRA and LSRD using loopback addresses as tunnel destination
addresses. The tunnel from LSRD to LSRA is successfully set up, but the tunnel from LSRA to
LSRD fails to be set up.
Figure 2-5 Networking diagram for a loop caused by the undeleted IP address of an interface
that has been shut down on an RSVP-TE Tunnel
POS2/0/0
192.168.30.1/30
LSRB LSRC
POS1/0/1
192.168.30.2/30
GE1/0/0 GE2/0/0
LSRA LSRD
GE1/0/1
192.168.30.1/30 LSRE
Loopback1 Loopback1
10.1.1.1/32 10.1.1.2/32
Fault Analysis
1. Run the display mpls te tunnel command on LSRA. A single tunnel is successfully set
up.
<LSRA> display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.1.1.2 10.1.1.1 8 --/3 I Tunnel0/0/1
2. Run the terminal monitor command to enable the display of debugging information and
the terminal debugging command to enable debugging on LSRD. Debugging information
RSVP/3/LOOP_PATH or RSVP/3/LOOP_RESV shows that a loop is generated on LSRD.
To establish the tunnel from LSRA to LSRD, LSRA sends an RSVP Path message to LSRD.
The RSVP Path message passes through each device along the path from LSRA to LSRD.
As the route record function is enabled using the mpls te record-route command, the IP
address of each hop along the path is added to the RSVP Path message. After receiving the
RSVP Path message, LSRD detects that 192.168.30.1 added to the message is the same as
the IP address of its interface. Although LSRD's interface with the IP address of
192.168.30.1 has been shut down, its address is not deleted, resulting in two identical
addresses. LSRD considers that a loop occurs and therefore sends the alarm and rejects the
request for resources.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface gigabitethernet1/0/1 command to enter the view of GE 1/0/1.
Step 3 Run the undo ip address 192.168.30.1 255.255.255.252 command to delete the IP address of
GE 1/0/1.
After completing the preceding operations, run the display mpls te tunnel command on LSRA.
The tunnel from LSRA to LSRD has been successfully set up. The fault is cleared.
<LSRA> display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.1.1.2 10.1.1.1 8 --/3 I Tunnel0/0/1
10.1.1.1 10.1.1.2 1 --/3 I Tunnel0/0/1
----End
Summary
Deleting configurations that are no longer used on interfaces is recommended to prevent
unpredictable errors.
Fault Symptom
As shown in Figure 2-6, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress).
After the RSVP-TE tunnel is Up, it suddenly goes Down and then Up again.
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the configuration of the RSVP-TE tunnel and its explicit path. Alternatively,
run the display mpls te tunnel path interface-number command to check the path of the
RSVP-TE tunnel.
2. View the logs on LSRA (ingress), or run the display logbuffer command to check the point
time T when the RSVP-TE tunnel goes Down.
3. Check whether the physical link of the RSVP-TE tunnel is faulty at the time T using the
following methods.
l View the logs on each device along the RSVP-TE tunnel to check whether the following
information is displayed:
Dec 23 2008 14:54:37 LSRA %%01IFNET/4/LINKNO_STATE(l): The line protocol on
the interface GigabitEthernet1/0/0 has entered the DOWN state.
Check whether the time when the physical outgoing interface along the RSVP-TE tunnel
goes Down is the same as the time when the tunnel interface goes Down. If so, the
physical outgoing interface is faulty, which causes the RSVP-TE tunnel to go Down.
l Run the display interface interface-type interface-number command on each device
along the RSVP-TE tunnel. The command output shows the status of the interface along
the physical link.
According to the command output, the time displayed in the Last line protocol up
time field is later than the point time T when the RSVP-TE tunnel goes Down. This
means that the physical interface has been faulty before the point time T, which causes
the RSVP-TE tunnel to go Down.
Procedure
Step 1 The RSVP-TE tunnel goes Up again, and no action is required.
----End
Summary
On the live network, the tunnel usually goes Down because a physical interface is Down. View
the log or run the display interface interface-type interface-number command to check the status
of each physical interface to find out the physical interface that goes Down.
Fault Symptom
As shown in Figure 2-7, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress).
After the configuration is complete, the interface of the RSVP-TE tunnel cannot go Up.
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the tunnel configuration. Then, run the display current-configuration
command hop by hop to check the MPLS, MPLS TE, and RSVP-TE configurations. The
command output shows that the configurations are correct.
2. Run the display mpls te cspf destination ip-address explicit-path path-name command
on LSRA. If information is displayed, CSPF has been successful in calculating paths; if no
information is displayed, CSPF failed to calculate a path.
3. Check the logs on LSRA, LSRB, and LSRC. The following information is displayed on
LSRC.
Dec 23 2008 17:43:35 LSRC %%01RSVP/3/LOOP_PATH(1): There is a loop in path
message. (TunnelId=100, EgressAddress=3.3.3.3)
Procedure
Step 1 Run the display current-configuration interface tunnel interface-number command on LSRA
to check the tunnel configuration. The command output shows information about the configured
explicit path and routes, which identifies the path of the RSVP-TE tunnel. In the following
example, information about the path of the RSVP-TE tunnel is displayed.
Hop1:10.1.1.1
Hop2:10.1.1.2
Hop3:2.2.2.2
Hop4:10.2.1.1
Hop5:10.2.1.2
Hop6:3.3.3.3
Step 2 The loop is detected on LSRC. This means that an IP address on LSRC is the same as the IP
address of the RSVP-TE tunnel (except Hop 5 and Hop 6 of LSRC itself). The IP address of
LSRC is the same as one of the IP addresses of Hop 1 to Hop 4. Use each IP address from Hop
1 to Hop 4 to run the tracert ip-address command on LSRC to find the conflicted IP address.
The command output is as follows:
<LSRC> tracert 10.1.1.2
Tracertoute: Destination can not be a local address
Step 3 Run the display ip interface brief command on LSRC to search for 10.1.1.2 and then delete it.
After the preceding operations, run the display interface tunnel interface-number command.
If the tunnel interface is Up, the fault is rectified.
----End
Summary
When a loop causes the tunnel setup failure, you can view logs to identify the device on which
the loop occurs. Then, run the tracert ip-address command on the device, and you can quickly
find the conflicted IP address.
Fault Symptom
As shown in Figure 2-8, an RSVP-TE tunnel is set up from LSRA (ingress) to LSRC (egress)
and IGP shortcut is enabled on LSRA. After the RSVP-TE tunnel goes Up, it flaps every several
minutes.
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the 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. IGP shortcut is enabled on the
tunnel interface and the explicit path is not configured.
#
interface Tunnel1/0/0
ip address unnumbered interface Loopback0
tunnel-protocol mpls te
destination 3.3.3.3
mpls te tunnel-id 100
mpls te record-route label
mpls te bandwidth bc0 100000
mpls te igp shortcut ospf
mpls te igp metric absolute 10
mpls te commit
#
According to the command output, CSPF is not enabled in the MPLS view.
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
2. Before the RSVP-TE tunnel goes Up, the route to the destination address of the RSVP-TE
tunnel passes the physical interface GE1/0/0. After the RSVP-TE tunnel goes Up, the route
to the destination address of the RSVP-TE tunnel passes along the path of the RSVP-TE
tunnel itself, because IGP route calculation counts in the tunnel.
<LSRA> display ip routing-table 3.3.3.3
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
----
Routing Table : Public
Summary Count : 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. Tunnel flapping occurs.
Procedure
Step 1 Choose one of the following procedures:
l Enable CSPF on LSRA.
1. Run the system-view command to enter the system view.
2. Run the mpls command to enter the MPLS view.
After the preceding operations, wait 5 minutes or 6 minutes after the tunnel goes Up. Tunnel
flapping does not occur and the fault is rectified.
----End
Summary
If IGP shortcut is enabled on a tunnel, the CSPF must be enabled or an explicit path must be set
up. Otherwise, tunnel flapping occurs.
Fault Symptom
As shown in Figure 2-9, LSRA and LSRB are in Area0, and LSRC and LSRD are in Area1. An
RSVP-TE tunnel is set up along the path LSRA -> LSRB -> LSRC -> LSRD. After the
configuration is complete, the RSVP-TE tunnel fails to be set up.
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the tunnel configuration. Then, run the display current-configuration
command hop by hop to check the MPLS, MPLS TE, and RSVP-TE configurations. The
command output shows that the configurations are correct.
3. Run the display explicit-path path-name command. The command output shows
information about the explicit path.
<LSRA> display explicit-path path1
Path Name : path1 Path Status : Enabled
1 10.1.2.2 Strict Include
4. Run the display mpls te cspf tedb command on LSRA to check the CSPF TEDB. The
command output shows information about the CSPF TEDBs of only LSRA and LSRB.
<LSRA> display mpls te cspf tedb all
Maximum Node Supported: 128 Maximum Link Support: 256
Current Total Node Number: 2 Current Total Link Number: 2
ID Router-ID IGP Process-ID Area Link-
Count
1 1.1.1.1 OSPF 1 0
1
2 2.2.2.2 OSPF 1 0
1
Procedure
Step 1 Run the system-view command to enter the system view.
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 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 10 Run the interface tunnel interface-number command to enter the tunnel interface view.
Step 11 Run the mpls te path explicit-path path-name command to configure the explicit path of the
tunnel.
After the preceding configurations, run the display mpls te tunnel-interface command on
LSRA. The command output shows that the tunnel interface goes Up and the fault is rectified.
----End
Summary
On the network with inter-area tunnels, IGP routes can be advertised only in a single area, and
inter-area CSPF calculation cannot be performed automatically. Therefore, a complete explicit
path must be specified manually.
Fault Symptom
As shown in Figure 2-10, multiple RSVP-TE tunnels are set up from LSRA (ingress) to LSRC
(egress). After a master/slave switchover is performed on LSRA, all RSVP-TE tunnels that pass
through LSRA go Down.
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the tunnel configuration. Then, run the display current-configuration
command hop by hop to check the configurations of MPLS, MPLS TE, RSVP-TE, and
RSVP-TE Hello mechanism. The command output shows that the configurations are
correct.
2. Run the display mpls rsvp-te graceful-restart peer command on LSRA and LSRB to
view the Neighbor Capability field to check whether RSVP GR on the neighbor is
supported. The field is Can Support GR, indicating that the neighbor supports RSVP GR.
3. Run the display mpls rsvp-te graceful-restart command on LSRA and LSRB to check
whether RSVP GR is supported. In the following example, the display on LSRA is used.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 1.1.1.1
Graceful-Restart Capability: None
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0
Received RecoveryPath message count: 0
Send Recovertpath message count: 0
Procedure
Step 1 Perform the following steps on LSRA and LSRB:
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 rsvp-te hello full-gr command to enable RSVP GR.
After the preceding operations, run the display mpls rsvp-te graceful-restart command on
LSRA and LSRB to check whether RSVP GR is supported. In the following example, the display
on LSRA is used.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSRID: 1.1.1.1
Graceful-Restart Capability: GR-Self GR-Support
Restart Time: 90000 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0
Received RecoveryPath message count: 0
Send Recovertpath message count: 0
According to the command output, LSRA supports GR. Perform switchover to check the status
of the tunnel. The tunnel remains to be Up and the fault is rectified.
----End
Summary
If a tunnel goes Down after a switchover is performed, verify that the configurations on devices
are correct, that the RSVP-TE Hello mechanism is configured in both the system and interface
views, and that RSVP GR is configured correctly.
POS1/0/0 POS1/0/0
200.1.1.1/24 200.1.1.2/24 POS2/0/0 POS1/0/0
Fault Analysis
1. Use the display current-configuration interface tunnel interface-type interface-
number command on Router A. The tunnel configurations are correct.
2. Use the display mpls te cspf tedb all command on Router A. The CSPF TEDB information
is correct.
3. Use the display mpls rsvp-te statistics global command on Router A and Router B.
Statistics on Router A are as follows:
Total Statistics Information:
PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 2 RecPacketCounter: 0
SendPathCounter: 1 RecPathCounter: 0
SendResvCounter: 0 RecResvCounter: 0
SendResvConfCounter: 0 RecResvConfCounter: 0
SendHelloCounter: 0 RecHelloCounter: 0
SendAckCounter: 0 RecAckCounter: 0
SendPathErrCounter: 0 RecPathErrCounter: 0
SendResvErrCounter: 0 RecResvErrCounter: 0
SendPathTearCounter: 1 RecPathTearCounter: 0
SendResvTearCounter: 0 RecResvTearCounter: 0
SendSrefreshCounter: 0 RecSrefreshCounter: 0
SendAckMsgCounter: 0 RecAckMsgCounter: 0
SendErrMsgCounter: 0 RecErrMsgCounter: 0
RecReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0
The preceding command output shows that "RecPacketCounter" is not zero on Router B
and the number of all types of messages is zero. A defect occurs when packets are pre-
processed. A possible cause is that invalid packets are received or RSVP authentication
fails.
4. Use the display current-configuration interface command on Router A and Router B.
The display on Router B is as follows:
interface POS1/0/0
ip address 200.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 10000
mpls rsvp-te
mpls rsvp-te authentication plain 12345678
The preceding command output shows that RSVP is configured on the interface of Router
B but not of Router A. The authentication of the packets sent by Router A to Router B fails
and the tunnel cannot be set up.
Procedure
Step 1 On Router A, run the display mpls te tunnel-interface command to check the current tunnel
status.
Step 2 Run the interface interface-type interface-number command to enter the interface view of POS
1/0/0.
Step 3 Run the mpls rsvp-te authentication { cipher | plain } auth-key command to configure RSVP
authentication. The keys on both ends must be the same.
After completing the preceding operation, run the display mpls te tunnel-interface command
on Router A. The tunnel interface goes Up, and the fault is removed.
----End
Summary
Check statistics about the sent and received packets carefully to rectify the fault.
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.
GE1/0/0 GE2/0/0
RouterE
Loopback1
5.5.5.9/32
After the configurations, the CR-LSP setup between Router A and Router D fails.
Fault Analysis
1. Using the debugging mpls te cspf all command on Router A, you can find the faulty CSPF
calculation.
01:6821: The current computation is loose
*0.10305390 RouterA CSPF/8/ERROR:
01:7000: Destination node is unreachable
*0.10305390 RouterA CSPF/8/ERROR:
01:7002: Error configuration or all the nodes can not fulfil the path request
*0.10305390 RouterA CSPF/8/ERROR:
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 1 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 the
interface on which the bandwidth cannot meet the requirement.
Step 4 Run the interface tunnel interface-number command to enter the tunnel interface view.
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.
GE2/0/0
GE1/0/0
RouterE GE3/0/0
Loopback1
5.5.5.9/32
Fault Analysis
1. Run the display mpls te cspf tedb command on Router A. The database on Router B -->
Router E --> Router C is correct.
2. Create a new tunnel and view the CSPF calculation result. The shortest path is calculated
and the fault does not appear.
3. Continue to check the log files. The metric of GE 3/0/0 on Router B is changed to 100
before the tunnel is created. During the new tunnel configuration, the metric recovers to
the default value.
At first, the path Router A --> Router B --> Router E --> Router C --> Router D is selected
in CSPF calculation. After the link metric restores, the path is not recalculated and the
tunnel does not select the path with the smallest metric.
Procedure
Step 1 On Router A, run the system-view command to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the tunnel interface view.
Step 3 Run the mpls te reoptimization command to enable the periodical optimization.
Step 4 Run the return command to return to the user view.
Step 5 Run the mpls te reoptimization command to trigger the optimization immediately.
On Router A, run the display mpls te tunnel path command to view the tunnel path. The path
with the smallest metric is selected. The fault is rectified.
----End
Summary
Removing this fault depends on the TE feature that is driven by configuration, not by topology.
You can configure re-optimization to prevent this fault.
GE1/0/0 GE2/0/0
RouterE
Loopback1
5.5.5.9/32
After the configuration is complete, the tunnel from Router B to Router C is created but the hot-
standby LSP fails to be set up.
Use the display mpls te tunnel-interface tunnel 1/0/0 command. The display is as follows:
Primary CR-LSP UP and HotBackup CR-LSP setting Up
The command output shows that the establishment of the primary tunnel succeeds, but the
establishment of the backup LSP fails.
Fault Analysis
1. Using the display mpls te tunnel path command on Router A to view the primary LSP of
the tunnel. The path Router A -> Router B -> Router C is used.
2. Use the debugging mpls te management states command on Router A to view the tunnel
status.
State Change :Tunnel %s enters HBKP_WAITFORCSPF state from HBKP_USEDIDLE state
The preceding display shows that the hot-standby requires CSPF calculation but fails.
3. Using the debugging mpls te cspf tedb errors command on Router A. CSPF calculation
fails and the path to the destination address is unavailable.
Destination node is unreachable
01:7050:Error configuration or all the nodes can not fulfil the path request.
4. Using the display mpls te cspf tedb node command to check the CSPF database. Note
that the bandwidth of GE 2/0/0 on Router E is not adequate to set up the bypass LSP.
Procedure
Step 1 On Router E, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view of GE
2/0/0 on which the bandwidth is too low.
Step 3 Run the mpls te bandwidth max-reservable-bandwidth command to modify the maximum
reservable bandwidth of the link.
Run the display mpls te tunnel-interface tunnel 1/0/0 command on Router A to change the
bandwidth. After this, the standby LSP is set up. The fault is rectified.
----End
Summary
The key point of the example lies in the CR-LSP backup mechanism. The bandwidth of the
backup LSP cannot be configured through a command line but are inherited from the primary
LSP.
Fault Symptom
Configure MLS TE based on the network shown in Figure 2-15.
GE2/0/0
GE1/0/0
RouterE GE3/0/0
Loopback1
5.5.5.9/32
The primary tunnel path is Router A --> Router B --> Router E --> Router C --> Router D. Then
create a Bypass tunnel between Router B and Router D, specifying Router E as the loose node.
Fault Analysis
1. Use the debugging mpls te management fast-reroute command on Router A or Router
B to enable FRR debugging and view the binding states of the main tunnel and the bypass
tunnel. The following display prompts:
Error: Optimal Bypass tunnel not found for Tunnel
2. Use the display mpls te tunnel path command to check the used paths in the tunnel. The
primary tunnel uses the path Router A --> Router B --> Router C --> Router D and the
backup tunnel uses the path Router B --> Router E --> Router C --> Router D. There are
some coincident nodes between the PLR and the MP on the primary and backup tunnels,
leading to FRR binding fails.
Procedure
Step 1 On Router B, run the system-view command to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the interface view of the bypass
tunnel.
Step 3 Run the undo mpls te path command to delete the explicit path on the tunnel interface.
Step 6 Run the explicit-path path-name command to enter the explicit path view of the bypass tunnel.
Step 7 Run the add hop ip-address before 5.5.5.9 command to add the IP address of GE 1/0/0 of Router
E before 5.5.5.9.
Step 8 Run the add hop ip-address before 4.4.4.9 command to add the IP address of GE 2/0/0 of Router
D before 4.4.4.9.
Step 10 Run the interface tunnel interface-number command to enter the interface view of the bypass
tunnel.
Step 11 Run the mpls te path explicit-path path-name command to re-designate an explicit path.
Use the display mpls te tunnel-interface [ tunnel interface-number ] command to view the
LSP on Router A. The FRR binding succeeds. The fault is removed.
----End
Summary
In FRR configuration, to ensure the successful binding, specify the strict explicit paths of the
primary and bypass tunnels. If loose explicit paths are used, the binding fails when the coincident
nodes exist between the PLR and the MP.
Fault Symptom
As shown in Figure 2-16, a primary tunnel Tunnel 1/0/00/0/1 is set up along the path Router A
--> Router B --> Router C, and a bypass tunnel is set up on the path Router B --> Router D
--> Router C.
Figure 2-16 Networking diagram in which the configuration of the bypass tunnel is modified
Primary LSP
Bypass LSP
RouterD
After the configuration is complete, shut down the outgoing interface from Router B to Router
C to make the bypass tunnel turn to in-use. After the configuration of the bypass tunnel is
modified and the new configuration is committed, the primary tunnel goes Down.
Fault Analysis
During modification of the bypass tunnel, a phase called make-before-break exists. A new CR-
LSP is set up before the previous CR-LSP is removed.
After the previous CR-LSP is removed, the binding relationship between the primary and bypass
tunnels is also removed. The primary tunnel, therefore, goes Down because the newly established
bypass tunnel cannot set up the binding relationship with the primary tunnel.
Procedure
Step 1 On Router B, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to the view of the interface
connected to Router C.
Step 3 Run the undo shutdown command to restore the primary tunnel and bind the primary tunnel to
the bypass tunnel again.
----End
Summary
Do not modify the configuration of bypass tunnels when the bypass tunnel is in use.
2.5.13 After the Primary Tunnel Fails, Traffic Does Not Switch to
an HSB Tunnel
Fault Symptom
On the network shown in Figure 2-17, an RSVP-TE tunnel is set up from LSRA to LSRC along
the path 10.1.1.1 -> 10.1.1.2 -> 10.2.1.1 -> 10.2.1.2, and an HSB tunnel is set up from 10.4.1.1
to 10.4.1.2. After the outbound GE 2/0/0 on LSRB fails, traffic does not switch to the HSB tunnel
from 10.4.1.1 to 10.4.1.2.
Figure 2-17 Networking diagram for the problem that after the primary tunnel fails, traffic does
not switch to an HSB tunnel
Loopback0 Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
Fault Analysis
1. Run the display current-configuration interface tunnel interface-number command on
LSRA to check the explicit path LSRA -> LSRB -> LSRC.
2. Run the display explicit-path [ path-name ] [ tunnel-interface | verbose ] command on
LSRA to check the explicit path information and the tunnel using the explicit path. The
explicit path includes LSRA and LSRB, but not LSRC, for the primary tunnel.
3. Run the display mpls te tunnel path tunnel-name command on LSRA to check information
about the MPLS TE tunnel. The tunnel is along the path 10.1.1.1 -> 10.1.1.2 -> 10.3.1.1 -
> 10.3.1.2.
A loose explicit path is specified for the tunnel, which contains LSRA and LSRB, but not LSRC.
The tunnel over this explicit path can be set up over the path 10.1.1.1 -> 10.1.1.2 -> 10.3.1.1 -
> 10.3.1.2. This means if GE 2/0/0 on LSRB fails, traffic travels through the HSB tunnel is not
affected.
Procedure
Step 1 Run the system-view command on LSRA to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the view of the MPLS TE tunnel
interface.
Step 3 Run the undo mpls te path command to delete the loose explicit path LSRA -> LSRB -> LSRC.
Step 4 Run the quit command to exit from the tunnel interface view.
Step 5 Run the explicit-path path-name command to enter the view of the loose explicit path LSRA -
> LSRB -> LSRC.
Step 6 Run the next hop 10.2.1.1 command to specify the next-hop IP address of the explicit path to
10.2.1.1. This allows the primary tunnel to use a strict explicit path.
Step 7 Run the quit command to exit from the explicit path view.
Step 8 Run the interface tunnel interface-number command to enter the view of the MPLS TE tunnel
interface.
Step 9 Run the mpls te path explicit-path path-name command to specify the strict explicit path
10.1.1.1 -> 10.1.1.2 -> 10.2.1.1 -> 10.2.1.2 for the primary tunnel.
Step 10 Run the mpls te commit command to make the configurations take effect. The fault is rectified.
----End
Summary
Using a strict explicit path is recommended for the primary tunnel which is supposed to forward
traffic over a pre-configured explicit path.
Fault Symptom
On the network shown in Figure 2-18, an MPLS LDP LSP is established between LSRA and
LSRB. The next-hop route from LSRA to LSRB changes, which causes the VPN route unable
to be iterated to the LDP LSP. As a result, VPN services are interrupted from LSRA to LSRB.
Figure 2-18 Networking diagram for the problem that VPN traffic loss is caused by a change
in the next-hop route
Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
LSRA 10.1.1.1/24 10.1.1.2/24 LSRB
Primary
GE2/0/0 GE2/0/0
10.1.2.1/24 Backup 10.1.3.2/24
GE1/0/0 GE2/0/0
10.1.2.2/24 10.1.3.1/24
LSRC
Loopback0
3.3.3.3/32
Fault Analysis
1. Run the display ip routing-table 2.2.2.2 32 command. The route to LSRB is displayed.
For example:
<LSRA> display ip routing-table 2.2.2.2 32
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
The command output shows that the next hop to LSRB (2.2.2.2/32) has been changed. The
primary LSP fails, and the route is switched to the backup LSP.
2. Run the display mpls lsp include 2.2.2.2 32 command on LSRA. No LSP to LSRB is
established.
3. Run the display mpls lsp include 3.3.3.3 32 command on LSRA. No LSP to LSRC is
established.
4. Run the display mpls ldp session command on LSRA. No LDP session to 3.3.3.3 is
established.
5. Run the display mpls ldp interface command on LSRA. Directly connected interfaces on
LSRA and LSRC have not been enabled with MPLS LDP.
Procedure
Step 1 Run the system-view command on LSRA, LSRB, and LSRC to enter the system view.
Step 2 Run the interface interface-type interface-number command on LSRA, LSRB, and LSRC to
enter the interface view.
Step 3 Run the mpls command on LSRA, LSRB, and LSRC to enable MPLS for interfaces on the
backup LSP.
Step 4 Run the mpls ldp command on LSRA, LSRB, and LSRC to enable MPLS LDP for interfaces
on the backup LSP. The fault is rectified.
----End
Summary
Enabling MPLS LDP on the entire network ensures that an LSP is established successfully even
if the next-hop route changes, preventing VPN traffic loss.
Fault Symptom
On the network shown in Figure 2-19, normal service traffic reaches Router B from Router C
and Router D, and then is forwarded by Router B to Router E (the arrow line marked red indicates
the model of the normal service traffic). Based on network planning, traffic should be sent
through POS 5/0/0 but actually sent through POS 3/0/0 and POS 4/0/0 of Router A, and then
reaches Router E (the arrow line marked blue indicates the model of the service traffic in the
case of a fault). After the configuration, it is found that the volume of traffic on POS 3/0/0
connecting Router B to Router A suddenly exceeds 1 Gbit/s, whereas the volume of traffic on
POS 5/0/0 connecting Router B to Router E reduces by more than 1 Gbit/s. Services, however,
are not affected.
Figure 2-19 Diagram of the networking where the volume of service traffic on interfaces of a
device is unstable
RouterC RouterD
POS1/0/0 POS2/0/0
RouterB
POS3/0/0 POS5/0/0
POS4/0/0
RouterA RouterE
Fault Analysis
1. Capture packets on the mirrored interface. You can find that the source address of the
packets is 1.1.1.1, and the destination address of the packets is 2.2.2.2. For details about
the mirroring configuration, see chapter "Mirroring Configuration" in the Configuration
Guide - Security.
2. Run the display fib 2.2.2.2 command on Router B to check the route destined for 2.2.2.2.
Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface
TunnelID
2.2.0.0/17 1.1.2.2 DGU t[3530817] Pos5/0/0
0x0
The command output shows that the packets are forwarded by the POS board in slot 5 and
the value of TunnelID is 0, which indicates that the packets are forwarded through IP.
Therefore, packet forwarding may fail on Router B.
3. Run the display ip routing-table 1.1.1.1 command on Router B to identify the interfaces
that send the packets out.
Route Flags: R - relay, D - download to
fib
------------------------------------------------------------------------------
Routing Table :
Public
Summary Count :
The command output shows that the packets are sent from POS 1/0/0 and POS 2/0/0.
4. Run the display fib 2.2.2.2 command on Router C to check the route destined for 2.2.2.2.
Route Entry Count:
2
Destination/Mask Nexthop Flag TimeStamp Interface
TunnelID
2.2.0.0/17 3.3.3.3 DGU t[3361320] Pos1/0/0
0x40b3e0
2.2.0.0/17 3.3.4.4 DGU t[3361320] Pos3/0/0
0xc0b3de
The value of TunnelID shows that the packets are forwarded through MPLS.
Run the display tunnel-info 40b3e0 command to check the details.
Tunnel ID: 0x40b3e0
Tunnel Token:
13280
Type:
lsp
Destination: 3.3.4.3
Out Slot:
1
Instance ID:
0
Out Interface: Pos1/0/0
Out Label: 1097
Next Hop: 3.3.3.3
5. Run the display mpls lsp in-label 1097 command on Router B to check the MPLS
forwarding table of Router B based on outbound labels.
----------------------------------------------------------------------
The command output shows that MPLS load balancing is performed among two paths for
the packets. The outbound interface of one path is POS 3/0/0, and the outbound interface
of the other path is POS 4/0/0. Because flow-by-flow load balancing is adopted, packets
are sent through POS 3/0/0 based on the hash algorithm. In addition, packets are forwarded
through MPLS rather than IP on Router B.
6. Check the configuration of Router C. You can find that the route recursive-lookup
tunnel command is run on Router C. After the route recursive-lookup tunnel command
is run, the entire device becomes valid, unlabeled routes of the public network are iterated
to LSP tunnels, and packets are forwarded through MPLS.
7. Run the display mpls lsp include 3.3.4.3 32 verbose command on Router A to check the
routes iterated to LSP tunnels.
----------------------------------------------------------------------
No :
1
VrfIndex :
Fec :
3.3.4.3/32
Nexthop :
3.3.3.3
In-Label :
NULL
Out-Label :
3
In-Interface :
----------
Out-Interface :
Pos1/0/0
LspIndex :
44181
Token :
0xc0b3de
FrrToken :
0x0
LsrType :
Ingress
Outgoing token :
0x0
Label Operation :
PUSH
Mpls-Mtu :
4470
TimeStamp :
535709sec
The command output shows that the period during which the LSP is formed is six days,
which is the same as the period during which traffic keeps changing. Because a new LSP
is formed and the function of iterating unlabeled routes to tunnels is configured on
Router C, related routes are successfully iterated to the LSP and packets are forwarded
through MPLS, causing the volume of traffic on interfaces to be unstable.
Procedure
Step 1 The fault is caused by improper network planning, proper network planning needs to be worked
out to reduce subsequent network maintenance efforts. If the fault occurs, services may be
interrupted after related measures are taken.
----End
Summary
Because a new LSP is formed and the function of iterating unlabeled routes to tunnels is
configured on Router C, related routes are successfully iterated to the LSP and packets are
forwarded through MPLS. On Router B, packets are sent out through POS 3/0/0 and POS 4/0/0,
because the routes to Router E are built up late. Therefore, services are not interrupted.
The fault is caused by improper network planning, proper network planning needs to be worked
out to reduce subsequent network maintenance efforts.
Figure 3-1 Troubleshooting flowchart for the fault that a host cannot receive or send packets
through an LSP
Host cannot
receive or sent
packets along
an LSP
No
Yes
Yes No
Yes No
No Yes
System status See the section
Is fault rectified?
is normal? "CPU Usage Is High"
Yes No
Seek technical
End
support
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 routes are correct.
Run the display fib verbose command to check whether routing information on the ping initiator
and the ping destination node.
l If the LspFwdFlag field is not 1 and the LspToken field is 0, IGP routes are incorrect. For
instructions on how to clear the fault, see the section "IGP Route Troubleshooting."
l If the LspFwdFlag field is 1 and the LspToken field is not 0, IGP routes are correct. Then,
go to Step 2.
If a value of the Token field in the display mpls lsp verbose command output is the same as a
value of the LspToken field in the display fib verbose command output, the LSPs indicated by
the two identical tokens are the same. Check whether the label, label operation mode, and next-
hop information of the LSP in the output of these two commands are the same and check whether
the BFD status associated with the LSP is Up.
l If BFD is configured but BFD is Down, clear the fault by referring to BFD Session Cannot
Go Up.
l If the label, label operation mode, and next-hop information in the output of these two
commands are the same and BFD is Up, go to Step 4.
Step 4 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 devices
----End
Relevant Alarms
None.
Relevant Logs
None.