ATN 910&910I&910B&950B V200R003C10 Troubleshooting 02 (CLI)

ATN 910&910I&910B&950B Multi-Service Access
Equipment
V200R003C10
Troubleshooting
Issue 02
Date 2014-04-30
HUAWEI TECHNOLOGIES CO., LTD.

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

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

Copyright Huawei Technologies Co., Ltd.
Equipment
Troubleshooting About This Document
About This Document
Purpose
This document describes the troubleshooting flow and typical methods for troubleshooting of
theATN.
The usage precautions are as follows:
l A device can store keys in plaintext, reversible algorithm encryption, or irreversible
algorithm encryption mode. The plaintext mode has the low security level, and the
irreversible algorithm encryption mode has the highest security level. Use different storage
modes for different scenarios. Exercise caution when using an insecure storage mode. The
system automatically selects the irreversible algorithm encryption mode to store local user
keys. Generally, the reversible algorithm encryption mode is used to store protocol keys to
meet interworking requirements.
l If the plaintext mode is used, a password is stored in plaintext in the configuration file. This
results in high security risks. The plaintext mode applies only to scenarios with special
requirements, such as compatibility and interworking requirements.
l Using a password or a key without a change leaves the password prone to being stolen or
cracked, which is more likely in a longer duration. Changing the password on a regular
basis may avoid such incidences, and therefore is recommended.
Related Version
The following table lists the product version related to this document.
Product Name Version
l ATN 910 V200R003C10

l ATN 910I
l ATN 910B
l ATN 950B
Intended Audience
This document is intended for:
Issue 02 (2014-04-30) Huawei Proprietary and Confidential ii

Equipment
l System maintenance engineer

l Network monitoring engineer
l On-site maintenance engineer
Symbol Conventions
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
Command Conventions
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

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

vertical bars. One item is selected or no item is selected.
Issue 02 (2014-04-30) Huawei Proprietary and Confidential iii

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

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

vertical bars. Several items or no item can be selected.
GUI Conventions
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2014-04-30)

This document has the following updates:
Known bugs are fixed.
Changes in Issue 01 (2014-01-31)

This document is the first release of the V200R003C10 version.
Issue 02 (2014-04-30) Huawei Proprietary and Confidential iv

Equipment
Troubleshooting Contents
Contents
About This Document.....................................................................................................................ii

1 Hardware.........................................................................................................................................1
1.1 Troubleshooting Boards.................................................................................................................................................2
1.1.1 Methods of Troubleshooting a Failure to Register a Standby System Control Board................................................2
1.1.2 Methods of Troubleshooting a Failure to Register a Subcard.....................................................................................4
1.1.3 Methods of Identifying a Failure to Query Ports on a Registered Subcard.................................................................5
2 System..............................................................................................................................................7
2.1 Telnet Troubleshooting...................................................................................................................................................8
2.1.1 The User Fails to Log in to the Server Through Telnet...............................................................................................8
2.2 FTP Troubleshooting....................................................................................................................................................11
2.2.1 The User Fails to Log in to the Server Through FTP................................................................................................11
2.2.2 The FTP Transmission Fails......................................................................................................................................16
2.2.3 The FTP Transmission Rate Is Low..........................................................................................................................18
2.3 SNMP Troubleshooting................................................................................................................................................21
2.3.1 An SNMP Connection Cannot Be Established..........................................................................................................21
2.3.2 The NMS Fails to Receive Trap Messages from the Host........................................................................................25
2.4 SSH Troubleshooting...................................................................................................................................................28
2.4.1 The User Fails to Log in to the SSH Server Through SSH.......................................................................................28
2.4.2 Trouble Cases............................................................................................................................................................34
2.5 RMON Troubleshooting...............................................................................................................................................36
2.5.1 NM Station Cannot Receive RMON Alarms............................................................................................................36
2.6 RMON2 Troubleshooting.............................................................................................................................................40
2.6.1 NM Station Fail to Query the Trafic Sent by a Hosy to the Device..........................................................................40
2.7 NQA Troubleshooting..................................................................................................................................................42
2.7.1 A UDP Jitter Test Instance Fails to Be Started.........................................................................................................42
2.7.2 A Drop Record Exists in the UDP Jitter Test Result.................................................................................................44
2.7.3 A Busy Record Exists in the UDP Jitter Test Result.................................................................................................46
2.7.4 A Timeout Record Exists in the UDP Jitter Test Result...........................................................................................48
2.7.5 The UDP Jitter Test Result Is "Failed", "No Result" or "Packet Loss".....................................................................50
2.7.6 General Flow Test Result Description and Troubleshooting Roadmap....................................................................53
2.8 NTP Troubleshooting...................................................................................................................................................57
2.8.1 The Clock is not Synchronized..................................................................................................................................57
Issue 02 (2014-04-30) Huawei Proprietary and Confidential v

Equipment
3 Physical Connection and Interfaces.........................................................................................59

3.1 Eth-Trunk Interface Troubleshooting...........................................................................................................................60
3.1.1 Eth-Trunk Interface Cannot Forward Traffic............................................................................................................60
3.2 GE Interface Troubleshooting......................................................................................................................................64
3.2.1 Interconnected Interfaces Alternate Between Up/Down States.................................................................................64
3.2.2 Severe Packet Loss Occurs After the FE Optical Module Is Mistakenly Inserted into a GE Optical Interface........65
4 IP Forwarding and Routing.......................................................................................................67

4.1 ARP Troubleshooting...................................................................................................................................................68
4.1.1 The ARP Entries on the Local Device Cannot Be Learnt By the Peer......................................................................68
4.2 IP Forwarding...............................................................................................................................................................71
4.2.1 The Ping Operation Fails...........................................................................................................................................71
4.2.2 The Tracert Operation Fails.......................................................................................................................................77
4.3 OSPF Troubleshooting.................................................................................................................................................79
4.3.1 The OSPF Neighbor Relationship Is Down..............................................................................................................79
4.3.2 The OSPF Neighbor Relationship Cannot Reach the Full State...............................................................................84
4.3.3 Related Troubleshooting Cases.................................................................................................................................88
4.4 IS-IS Troubleshooting..................................................................................................................................................89
4.4.1 The IS-IS Neighbor Relationship Cannot Be Established.........................................................................................89
4.4.2 A Device Fails to Learn Specified IS-IS Routes from Its Neighbor.........................................................................94
4.4.3 The IS-IS Neighbor Relationship Flaps.....................................................................................................................98
4.4.4 IS-IS Routes Flap.....................................................................................................................................................100
4.5 BGP Troubleshooting.................................................................................................................................................103
4.5.1 The BGP Peer Relationship Fails to Be Established...............................................................................................103
4.5.2 BGP Public Network Traffic Is Interrupted............................................................................................................108
4.5.3 BGP Private Network Traffic Is Interrupted...........................................................................................................112
4.5.4 Troubleshooting of the Fault that a Local BGP Peer (Route Sender) Cannot Receive ORFs from a Remote Peer
(Route Receiver)...............................................................................................................................................................119
4.6 RIP Troubleshooting...................................................................................................................................................123
4.6.1 Device Does not Receive Partial or All the Routes.................................................................................................123
4.6.2 Device Does not Send Some or All Routes.............................................................................................................126
5 Layer 2 Network.........................................................................................................................131
5.1 Ethernet OAM Troubleshooting.................................................................................................................................132
5.1.1 Ethernet OAM 802.1ag Trace Fails.........................................................................................................................132
5.2 MSTP Troubleshooting..............................................................................................................................................134
5.2.1 MSTP Topology Change Leads to Service Interruption.........................................................................................134
5.3 RRPP Troubleshooting...............................................................................................................................................140
5.3.1 RRPP Loop Occurs Temporarily.............................................................................................................................140
5.4 ERPS (G.8032) Troubleshooting................................................................................................................................142
5.4.1 ERPS Ring Negotiation Troubleshooting................................................................................................................142
6 Multicast......................................................................................................................................148
Issue 02 (2014-04-30) Huawei Proprietary and Confidential vi

Equipment
6.1 Layer 2 Multicast Troubleshooting............................................................................................................................149

6.1.1 Layer 2 Multicast Traffic Cannot Be Transmitted..................................................................................................149
6.2 L3 Multicast................................................................................................................................................................152
6.2.1 Multicast Traffic Cannot Be Transmitted................................................................................................................152
6.2.2 The PIM Neighbor Relationship Remains Down....................................................................................................154
6.2.3 The RPT on a PIM-SM Network Fails to Forward Data.........................................................................................157
6.2.4 The SPT on a PIM-SM Network Fails to Forward Data.........................................................................................162
6.2.5 MSDP Peers Cannot Generate Correct (S, G) Entries.............................................................................................167
6.2.6 The Multicast Device Cannot Generate IGMP Entries...........................................................................................171
6.2.7 Trouble Cases..........................................................................................................................................................175
7 QoS...............................................................................................................................................180
7.1 Troubleshooting of Queue Scheduling Based on Traffic Classification....................................................................181
7.1.1 Typical Networking.................................................................................................................................................181
7.1.2 Troubleshooting Flow..............................................................................................................................................181
7.1.3 Troubleshooting Procedures....................................................................................................................................182
7.2 Troubleshooting HQoS...............................................................................................................................................183
7.2.1 Typical Networking.................................................................................................................................................183
7.2.2 Troubleshooting Flowchart......................................................................................................................................184
7.2.3 Troubleshooting Procedure......................................................................................................................................185
8 MPLS............................................................................................................................................187
8.1 MPLS LDP Troubleshooting......................................................................................................................................188
8.1.1 LDP Session Flapping.............................................................................................................................................188
8.1.2 LDP Session Goes Down........................................................................................................................................190
8.1.3 LDP LSP Flapping...................................................................................................................................................193
8.1.4 LDP LSP Goes Down..............................................................................................................................................195
8.1.5 Troubleshooting a Failure in Establishing an Inter-area LSP..................................................................................198
8.1.6 Related Troubleshooting Cases...............................................................................................................................201
8.2 MPLS TE Troubleshooting........................................................................................................................................208
8.2.1 TE Tunnel Is Down.................................................................................................................................................208
8.2.2 TE Tunnel Suddenly Goes Down............................................................................................................................211
8.2.3 Loop Occurs on a TE Tunnel..................................................................................................................................213
8.3 MPLS Forwarding Troubleshooting...........................................................................................................................236
8.3.1 Host Cannot Receive or Send Packets Through an LSP.........................................................................................236
9 VPN..............................................................................................................................................239
9.1 L3VPN Troubleshooting............................................................................................................................................240
9.1.1 L3VPN Traffic Is Interrupted..................................................................................................................................240
9.2 VPLS Troubleshooting...............................................................................................................................................251
9.2.1 VSI of Martini VPLS Cannot Go Up......................................................................................................................251
Issue 02 (2014-04-30) Huawei Proprietary and Confidential vii

Equipment
9.2.2 VSI Goes Up Only on One End...............................................................................................................................257

9.3 VLL Troubleshooting.................................................................................................................................................266
9.3.1 The VC of Martini VLL Cannot Be Up..................................................................................................................266
9.4 PWE3 Troubleshooting..............................................................................................................................................277
9.4.1 The PW Cannot Be Up............................................................................................................................................277
10 Security......................................................................................................................................293
10.1 URPF Troubleshooting.............................................................................................................................................294
10.1.1 URPF Check Fails.................................................................................................................................................294
10.1.2 Related Troubleshooting Cases.............................................................................................................................295
11 Reliability..................................................................................................................................298
11.1 BFD Troubleshooting...............................................................................................................................................299
11.1.1 BFD Session Cannot Go Up..................................................................................................................................299
11.1.2 A BFD Session for a Specific PW Cannot Go Up................................................................................................304
11.1.3 Interface Forwarding Is Interrupted After a BFD Session Detects a Fault and Goes Down.................................309
11.1.4 Dynamic BFD Session Fails to Be Created...........................................................................................................311
11.1.5 Related Troubleshooting Cases.............................................................................................................................313
11.2 Y.1731 Troubleshooting...........................................................................................................................................315
11.2.1 Troubleshooting of the Fault that No Single-ended Frame Loss Statistics Are Collected Though Single-ended Frame
Loss Measurement Is Configure for a VLL Network.......................................................................................................315
11.2.2 Troubleshooting of the Fault that No Dual-ended Frame Loss Statistics Are Collected Though Dual-ended Frame
Loss Measurement Is Configure for a VLL Network.......................................................................................................319
11.2.3 Troubleshooting of the Fault that One-way Delay Is Not Collected Though One-way Frame Delay Measurement
Is Configured for a VLL Network....................................................................................................................................321
11.2.4 Troubleshooting of the Fault that Two-way Delay Is Not Collected Though Two-way Frame Delay Measurement
Is Configured for a VLL Network....................................................................................................................................325
11.3 MPLS-TP OAM Troubleshooting............................................................................................................................328
11.3.1 ME Cannot Go Up.................................................................................................................................................328
11.4 Error Code Detection Troubleshooting....................................................................................................................331
11.4.1 Error Detection Switchover Fails..........................................................................................................................331
12 User Management....................................................................................................................335
12.1 HWTACACS Troubleshooting ...............................................................................................................................336
12.1.1 Trouble Cases........................................................................................................................................................336
12.2 DCN Troubleshooting..............................................................................................................................................337
12.2.1 A DCN Link Fails to Be Established.....................................................................................................................337
Issue 02 (2014-04-30) Huawei Proprietary and Confidential viii

Equipment
Troubleshooting 1 Hardware
1 Hardware
About This Chapter
1.1 Troubleshooting Boards
Issue 02 (2014-04-30) Huawei Proprietary and Confidential 1

Equipment
1.1 Troubleshooting Boards
1.1.1 Methods of Troubleshooting a Failure to Register a Standby

System Control Board
Common Causes
Such a fault may result from the following causes:
l The standby system control board is starting up.

l The standby system control board loads an NE software package different from that loaded
by the active system control board.
l The standby system control board loads an NE software package of an incorrect version.
l The standby system control board is not properly connected.
Troubleshooting Flowchart
Figure 1-1 shows the flowchart for troubleshooting a failure to register the standby system
control board.
Figure 1-1 Flowchart for troubleshooting a failure to register the standby system control board
The standby system control board
cannot be registered.
Yes
Yes
Is the board starting up? Wait until the startup time elapses Problem resolved?
No No
Do the active and standby system No Yes

Ensure that they load the same NE
control boards load the same NE Problem resolved?
software package.
software package?
No
Yes
Yes
Is the standby system control No
Reconnect the board properly. Problem resolved?
board properly connected?
No
Yes
Collect information and ask for

technical support. End
Troubleshooting Procedure

Equipment
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 the standby system control board is starting up.
A board takes a period of time from power-on to registration and this period is refereed to as
startup time.
For system control boards, startup time is within three minutes. If the device is reset after an
upgrade, the startup time is within five minutes.
If the startup time has not elapsed, wait until the board successfully starts up. If the startup time
has elapsed, proceed with Step 2.
Step 2 Check whether the standby system control board loads the same NE software package as that
loaded by the active system control board.
In the user view, run command display alarm all and check for an alarm indicating inconsistency
between the software packages loaded by the active and standby system control boards. The
following provides the relevant alarm description.
The software package for startup on the slave MPU mismatched that on the master MPU or the
package on the master MPU was incomplete.
If there is such an alarm, perform Step 4 and contact Huawei technical support engineers, who
will upgrade the NE software on the standby system control board to the same version running
on the active system control board.
If there is no such an alarm and the failure persists, proceed with .
Step 3 Check whether the standby system control board is properly connected.
If the standby system control board is not newly inserted, proceed with Step 4.
If the standby system control board is newly inserted, connect the console port (ETH/OAM port)
on the standby system control board and check for Unkown device type in the console port start
information. If Unkown device type is found, the standby system control board is poorly
connected. In this case, reconnect the system control board. If Unkown device type is not found,
proceed with Step 4.
Step 4 If the fault persists, collect the following information and contact Huawei technical support
personnel.
l Results of the preceding troubleshooting procedures
l Configuration file, log information, alarm information, and one-click diagnosis information
(run command display diagnostic-information in the user view)
----End
Relevant Alarms and Logs

Equipment
Relevant Alarms
None.
Relevant Logs
None.
1.1.2 Methods of Troubleshooting a Failure to Register a Subcard
Common Causes
This fault may result from the following causes:

l The subcard fails to be powered on.
l The subcard is not securely inserted.
NOTE
The following shows how to troubleshoot a failure of a hot pluggable subcard.
Figure 1-2 shows the flowchart for troubleshooting a failure to register a subcard.
Figure 1-2 Flowchart for troubleshooting a failure to register a subcard

A subcard cannot be
registered.
Has the subcard been powered No Yes

Reconnect the subcard. Problem resolved?
on?
No No
No Reconnect the subcard and Yes

Is the subcard properly
ensure that it is properly Problem resolved?
connected?
connected.
No
Yes
Collect information and

ask for technical End
support.
NOTE

Equipment
Procedure
Step 1 Check whether the subcard has been powered on.
Check whether the STAT indicator on the subcard is on. If the indicator is off, it indicates that
the subcard is not powered on. In this case, you need to check whether the subcard is securely
inserted. Insert the subcard completely into the slot, and then tighten screws to fix the subcard.
If the subcard is powered on but cannot be registered, go to Step 2.
Step 2 Check whether the subcard is properly connected. If the subcard is properly connected, proceed
with Step 3.
Step 3 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure.
(run command display diagnostic-information in user view)
----End
Relevant Alarms
None.
Relevant Logs
None.
1.1.3 Methods of Identifying a Failure to Query Ports on a

Registered Subcard
Common Causes
Such a fault may result from the following common causes:
l The subcard has an incorrect electronic label.

l Other causes.
NOTE
Figure 1-3 shows the flowchart for troubleshooting a failure to query ports on a registered
subcard.

Equipment
Figure 1-3 Flowchart for troubleshooting a failure to query ports on a registered subcard
An attempt to querying ports
on a registered subcard fails.
No Yes
Is the subcards electronic label Ask for technical support and Has the problem been
correct? update the electronic label resolved?
Yes No
Collect information and

ask for technical End of troubleshooting
support
Context
NOTE
NOTE
Procedure
Step 1 Verify the subcard's electronic label.
In the user view, run command display elabel cardID, where cardID indicates the sub-slot.
Check for an ATN field in Description in [Board Properties]. If there is no ATN field, the
subcard's electronic label is incorrect. In this case, perform Step 2.
personnel.
(run command display diagnostic-information in the user view)
----End
Relevant Alarms
None.
Relevant Logs
None.

Equipment
Troubleshooting 2 System
2 System
About This Chapter
2.1 Telnet Troubleshooting
2.2 FTP Troubleshooting
2.3 SNMP Troubleshooting
2.4 SSH Troubleshooting
2.5 RMON Troubleshooting
2.6 RMON2 Troubleshooting
2.7 NQA Troubleshooting
2.8 NTP Troubleshooting

Equipment
2.1 Telnet Troubleshooting

2.1.1 The User Fails to Log in to the Server Through Telnet
Common Causes
This fault is commonly caused by one of the following:
l The route is unreachable, and the user cannot set up a TCP connection with the server.
l The number of users logging in to the server reaches the upper threshold.
l An ACL is configured in the VTY user interface view.
l The access protocol specified in the VTY user interface view is incorrect. For example,
when the access protocol is configured to SSH through the protocol inbound ssh
command, the user cannot log in to the server through Telnet.
Figure 2-1 shows the troubleshooting flowchart.

Equipment
Figure 2-1 Troubleshooting flowchart for the fault that the client fails to log in to the server
through Telnet
The user fails to log
in to the server through
Telnet
Check the ping

If the client No operation fails Yes
can successfully ping the and rectify the Is the fault
server? fault rectified?
No
Yes
If All the Increase the Yes

Yes
current VTY channels maximum Is the fault
are used? number of users rectified?
allowed to log in
No
No
Has an ACL Permit the IP Yes

Yes Is the fault
rule been configured with address of the
user in the ACL rectified?
IP specified?
No
No
If the user access No Configure the Yes

user access Is the fault
protocol configured to rectified?
all or telnet? protocol to all or
telnet
No
Yes
No Correctly
Yes
If The authentication configure the Is the fault
mode configured? authentication rectified?
mode
No
Yes
Seek technical
support End

Equipment
Context
NOTE
Procedure
Step 1 Check whether the Telnet client can ping through the server.
Run the ping command to check the network connectivity. If the ping fails, the Telnet connection
cannot be established between the user and server.
If the ping fails, see The Ping Operation Fails to locate the problem so that the Telnet client
can ping through the server.
Step 2 Check whether the number of users logging in to the server reaches the upper threshold.
Log in to the server through a console interface and then run the display users command to
check whether all the current VTY channels are in use. By default, a maximum of 5 users can
log in to the server through VTY channels. Run the display user-interface maximum-vty
command to view the allowed maximum number of login users.
<HUAWEI> display user-interface maximum-vty
Maximum of VTY user:5
<HUAWEI> display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
+ 0 CON 0 00:00:00 pass no
Username : Unspecified
34 VTY 0 00:13:39 TEL 10.138.78.107 pass no

If the number of users logging in to the server reaches the upper threshold, you can run the user-
interface maximum-vty vty-number command to increase the maximum number of users
allowed to log in to the server through VTY channels to 15.
<HUAWEI> system-view
[HUAWEI] user-interface maximum-vty 15
Step 3 Check that an ACL is configured in the VTY user interface view.
[HUAWEI] user-interface vty 0 4
[HUAWEI-ui-vty0-4] display this
user-interface vty 0 4
acl 2000 inbound
authentication-mode password
user privilege level 3
idle-timeout 0 0
If an ACL is configured but the IP address of the client to be permitted is not specified in the
ACL, the user cannot log in to the server through Telnet. To enable a user with a specific IP
address to log in to the server through Telnet, permit the IP address of the user in the ACL.
Step 4 Check that the access protocol configured in the VTY user interface view is correct.
authentication-mode password

Equipment

idle-timeout 0 0
protocol inbound ssh
Run the protocol inbound { all | ssh | telnet } command to configure the user access protocol.
By default, the user access protocol is Telnet.
l If the user access protocol is SSH, the user cannot log in to the server through Telnet.
l If the user access protocol is "all", the user can log in to the server through Telnet or SSH.
Step 5 Check that the user can log in to the server through the VTY channel ranges from 16 to 20.
The VTY channels 16 to 20 are reserved for network management users. Whether VTY user
interfaces 0 to 14 are all used, VTY user interfaces 16 to 20 are open to NMS users (whose user
type is net-manager) only, not common login users.
Run the display users command to check the user login information of every VTY user interface.
Step 6 Check that the authentication mode is configured in the user interface view.
l If you run the authentication-mode password command to configure the authentication
mode for the user logging in to the server through the VTY channel to password, run the
set authentication password command to set the authentication password.
l If you run the authentication-mode aaa command to configure the authentication mode to
aaa, you should run the local-user password command to add a local user.
personnel:
l Configuration files, log files, and alarm files of the devices
----End
Relevant Alarms
None.
Relevant Logs
None.
2.2 FTP Troubleshooting

2.2.1 The User Fails to Log in to the Server Through FTP
Common Causes

Equipment
l The route between the client and the server is unreachable.

l The FTP server is disabled.
l The port to be monitored by the FTP is not the default port and the port is not specified
through with the client logs in to the server through FTP.
l The authentication information and working directory of the FTP user are not configured.
l The number of users logging in to the server through FTP reaches the upper threshold.
l An ACL rule is configured on the FTP server to limit client's access.
The client fails to log in to the FTP server.

Equipment
Figure 2-2 Troubleshooting flowchart for the fault that the client fails to log in to the FTP server
The user fails to log
in to the server through
FTP.
Whether No Check the

physical link and Is the fault Yes
the client can successfully
ping the server? rectify the fault. rectified?
No
Yes
Whether FTP No Enable FTP Yes

Is the fault
services are enabled? services. rectified?
No
Yes
Configure the
If the port to No port to which Yes
Is the fault
which FTP listens is the FTP listens to rectified?
default value? the default value.
Yes No
Check the
authentication
Whether information and Yes
No Is the fault
the FTP user is correctly authorization rectified?
configured? directory of the
FTP user.
No
Yes
Is the
Yes Disconnect Yes
number of FTP users Is the fault
certain FTP
reaches the upper rectified?
users.
threshold?
No No
Has an ACL Yes Yes

Correctly Is the fault
rule been configured on
configure an ACL. rectified?
the FTP server?
No No
Seek technical End

support.

Equipment
Context
NOTE
Procedure
Step 1 Check that the client and the server can successfully ping each other.
Run the ping command to check whether the client can successfully ping the FTP server.
<HUAWEI> ping 10.164.39.218
PING 10.164.39.218: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 10.164.39.218 ping statistics ---

5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
l If the ping fails, the FTP connection cannot be established between the client and the server.
To locate this problem, see The Ping Operation Fails so that the FTP client can ping
through the FTP server.
l If the ping succeeds, go to Step 2.
Step 2 Check that the FTP server is enabled.
Run the display ftp-server command in any view to check the status of the FTP server.
l If the FTP server is disabled, the command output is as follows:
<HUAWEI> display ftp-server
Info: The FTP server is already disabled.
Run the ftp server enable command in the system view to enable the FTP server.
[HUAWEI] ftp server enable
Info: Succeeded in starting the FTP server.
l If the FTP server is enabled, the command output is as follows.

FTP server is running
Max user number 5
User count 0
Timeout value(in minute) 30
Listening port 21
Acl number 0
FTP server's source address 0.0.0.0
Go to Step 3.
Step 3 Check that the port listened by the FTP server is the default port.
1. Run the display tcp status command in any view to check the listening status of the current
TCP port and the default port 21.
<HUAWEI> display tcp status
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State

Equipment
2a67f47c 6 /1 0.0.0.0:21 0.0.0.0:0 23553

Listening
2b72e6b8 115/4 0.0.0.0:22 0.0.0.0:0 23553
Listening
3265e270 115/1 0.0.0.0:23 0.0.0.0:0 23553
Listening
2a6886ec 115/23 10.137.129.27:23 10.138.77.43:4053 0
Establish
ed
2a680aac 115/14 10.137.129.27:23 10.138.80.193:1525 0
Establish
ed
2a68799c 115/20 10.137.129.27:23 10.138.80.202:3589 0
Establish
ed
2. Run the display ftp-server command in any view to check the port listened by the FTP
server.
FTP server is running
Max user number 5
User count 0
Timeout value(in minute) 30
Listening port 21
Acl number 0
FTP server's source address 0.0.0.0
l If the port listened by the FTP server is not port 21, run the ftp server port command to set
the port to be listened by the FTP server to port 21.
[HUAWEI] undo ftp server
[HUAWEI] ftp server port 21
l If the port listened by the FTP server is port 21, go to Step 4.
Step 4 Check that the authentication information and the authorization directory for the FTP user are
configured.
l The name, password, and working directory are mandatory configuration items for an FTP
user. A common cause of the fault that the user fails to log in to the server through FTP is
because the working directory is not specified.
1. Run the aaa command to enter the AAA view.

2. Run the local-user user-name password password command to configure the name
and password for a local user.
3. Run the local-user user-name ftp-directory directory command to configure the
authorization directory for the FTP user.
l The access type is an optional item. By default, the system supports all access types. If one
access type or several access types are configured, the user can log in to the server only
through the configured access types.
Run the local-user user-name service-type ftp command to configure the access type to
FTP.
l If the authentication information and authorization directory are configured for the FTP
user, go to Step 5.
Step 5 Check that the number of users logging in to the FTP server reaches the upper threshold.
Run the display ftp-users command to check whether the number of users logging in to the FTP
server reaches 5.

Equipment
l If the number of users logging in to the FTP server is greater than or equal to 5, run the
quit command in the FTP client view to tear down the connection between a user and the
FTP server.
l If the number of users logging in to the FTP server is smaller than 5, go to step 6.
Step 6 Check that no ACL rule is configured on the FTP server.

Run the display ftp-server command to check whether no ACL rule is configured on the FTP
server.
l If an ACL rule is configured, the system allows only the client with the IP address permitted
by the ACL rule to log in to the FTP server.
l If no ACL rule is configured, go to step 7.
Step 7 Contact Huawei technical support personnel.

----End
Relevant Alarms
None.
Relevant Logs
FTPS/5/LOGIN_OK:The user succeeded in login. (UserName="[string]", IpAddress=[string],
VpnInstanceName="[string]")
FTPS/5/REQUEST:The user had a request. (UserName="[string]", IpAddress=[string],

VpnInstanceName="[string]", Request=[string])
2.2.2 The FTP Transmission Fails
Common Causes
l The source path or the destination path of an FTP connection contains characters that the
device does not support,such as the character of blank space.
l The number of files in the root directory of the FTP server reaches the upper threshold.
l The available space of the root directory of the FTP server is insufficient.

Equipment
Figure 2-3 Troubleshooting flowchart for the FTP transmission failure

FTP transmission
fails.
Does the FTP source Yes

or destination Adjust the FTP source or
directory contain destination directory.
unsupported
characters?
No
Yes
Does the number of files in the
Delete unneeded files.
root directory reach the upper
limit?
No
Yes
Is the remaining space of the
root directory insufficient?
Delete unneeded files.
No
Collect the debugging

End
information.
Contact Huawei technical

support personnel.
Context
NOTE

Equipment
Procedure
Step 1 Check that the source path or the destination path of an FTP connection contains characters that
the device does not support,such as the character of blank space..
l If contains, change the path.
l If does not contains, go to Step 2.
Step 2 Check that the number of files in the root directory of the FTP server reaches the upper threshold.
At present, a maximum of 50 files can be saved in the root directory of the FTP server. When
the number of files in the root directory of the FTP server is greater than 40 and unnecessary
files are not cleared in time, new files cannot be saved.
Run the dir command on the FTP server to view the number of files in the root directory of the
FTP server.
l If the number of files in the root directory of the FTP server is greater than or equal to 50,
run the delete command in the user view to delete unnecessary files to release the storage
space.
l If the number of files in the root directory of the FTP server is smaller than 50, go to Step
3.
Step 3 Check that the available space of the root directory of the FTP server is sufficient.
Run the dir command on the FTP server to view the available space of the root directory on the
FTP server.
l If there is no sufficient space, run the delete /unreserved command in the user view to
delete unnecessary files.
l If there is sufficient space, go to Step 4.
----End
Relevant Alarms
None.
Relevant Logs
FTPS/3/TRS_FAIL:The user failed to transfer data. (UserName="[string]", IpAddress=[string],
VpnInstanceName="[string]")
2.2.3 The FTP Transmission Rate Is Low
Common Causes

Equipment
l The storage media is the Flash memory.

l Packets are retransmitted because the network is unstable.
Figure 2-4 Troubleshooting flowchart for the slow FTP transmission speed
FTP transmission
speed is slow.
Does the Yes

storage device
have a flash?
No
Are there Yes

retransmitted
packets?
No
Collect the debugging

End
information.
Contact Huawei
technical support
personnel.
Context
NOTE

Equipment
Procedure
Step 1 The Check that the storage media is the Flash memory.
The reading rate of the Flash memory is fast but the writing rate of the Flash memory is slow.
Table 2-1 shows the FTP transmission data obtained in the laboratory. The data show that
compared with other storage media, the writing rate of the Flash memory is the lowest.
Table 2-1 List of the FTP transmission rate
Item get put
Flash - Flash 0.55 kbit/s 0.51 kbit/s
Flash - hda 0.51 kbit/s 16.05 kbit/s
Flash - CFcard 1.63 kbit/s 58.66 kbit/s
hda - Flash 32.19 kbit/s 1.51 kbit/s
hda - hda 32.91 kbit/s 25.70 kbit/s
hda - CFcard 21.33 kbit/s 54.69 kbit/s
CFcard - Flash 51.23 kbit/s 0.55 kbit/s
CFcard - hda 40.19 kbit/s 14.23 kbit/s
CFcard - CFcard 33.21 kbit/s 59.14 kbit/s
Step 2 Check that packets are retransmitted.
Get packets and analyze the packet contents through tools to check whether TCP packets are
retransmitted on client PC. Packet retransmission is usually cause by the network instability.
Figure 2-5 shows packets got through tools. As shown in the diagram, a log of TCP
retransmission are received.
Figure 2-5 Diagram of packets got through tools

----End

Equipment
Relevant Alarms
None.
Relevant Logs
None.
2.3 SNMP Troubleshooting
2.3.1 An SNMP Connection Cannot Be Established
Common Causes
l Packets cannot be exchanged between the host and the NMS.
l Configurations are incorrect.

Equipment
Figure 2-6 Troubleshooting flowchart for the fault that an SNMP connection cannot be
established
An SNMP connection
fails to be established
Can No Do No Refer to the

the host and the NMS reachable routes exist troubleshooting
successfully ping each between the host and roadmap of the IP
other? the NMS? module
Yes Yes
Enable SNMP dubugging on
the host to check whether the
host can receive SNMP
messages
Does the host

No
receive SNMP
messages?
Yes
Does log messages indicating

SNMP communication failure
exists? Rectify the fault
according to the manua.
No Contact Huawei technical

Is the fault rectified?
support personnel
Yes
End
Context
NOTE
Save the results of each troubleshooting step. If your troubleshooting fails to correct the fault, you will
have a record of your actions to provide Huawei technical support personnel.

Equipment
Procedure
Step 1 Run the ping command to check whether the host and the NMS can successfully ping each other.
l If the ping succeeds, it indicates that the host and the NMS are reachable. Go to Step 2.
l If the ping fails, see The Ping Operation Fails to locate the problem so that the host and the
NMS can ping through each other.
Step 2 Run the display logbuffer command to check whether login failure logs exist on the host.
l If no login failure log exists on the host, go to Step 3.

l If login failure logs exist on the host, analyze the logs.
Table 2-2 Log description and solution
Logs Description Solution
Failed to login The SNMP 1. Run the display snmp-agent sys-info version
through version used command to check whether the host supports the
SNMP, by the NMS to SNMP version used by the NMS to send login
because the send login requests.
version was requests is not l If the host supports the SNMP version, go to Step
incorrect. (Ip= supported on c.
[STRING], the host.
Times= l If the host does not support the SNMP version,
[ULONG]) go to Step b.
2. Run the snmp-agent sys-info version command to
configure the SNMP version supported by the host.
l If the fault is rectified, go to Step d.
l If the fault persists, go to Step c.
3. Contact Huawei technical support personnel.
4. End.
Failed to login Packet bytes 1. Run the snmp-agent packet max-size command to
through received by increase the maximum packet bytes of the host.
SNMP, the host l If the fault persists, go to Step b.
because the exceed the
packet was too threshold. l If the fault is rectified, go to Step c.
large. (Ip= 2. Contact Huawei technical support personnel.
[STRING], 3. End.
Times=
[ULONG])

Equipment
Failed to login The message Contact Huawei technical support personnel.

through list is filled up.
SNMP,becaus
e messages
was failed to
be added to
the message
list. (Ip=
[STRING],
Times=
[ULONG])
Failed to login An unknown Contact Huawei technical support personnel.

through error occurs
SNMP, during packet
because of the decoding.
decoded PDU
error. (Ip=
[STRING],
Times=
[ULONG])
Failed to login The 1. Run the display snmp-agent community

through community command to can view the community string
SNMP, string is configured on the host.
because the incorrect. l If the community string used by the NMS to send
community a login request is the same as that configured on
was incorrect. the host, go to Step c.
(Ip=
[STRING], l If the community string used by the NMS to send
Times= a login request is different from that configured
[ULONG]) on the host, go to Step b.
2. Run the snmp-agent community command to
configure a read-write community string, which
must be identical with that configured on the host.
4. End.

Equipment
Failed to login The IP address 1. Run the display acl command to view the ACL
through from which configuration on the host.
SNMP, the NMS l If the IP address from which the NMS sends
because of the sends a login login requests is denied by the ACL, go to Step
ACL filter request is b.
function. (Ip= denied by the
[STRING], ACL. l If the IP address from which the NMS sends
Times= login requests is permitted by the ACL, go to
[ULONG]) Step c.
2. Run the rule command to enable the ACL to permit
the IP address from which the NMS sends login
requests.
4. End.
Failed to login The Contact Huawei technical support personnel.

through "contextname
SNMP, " in the login
because of the request is
contextname incorrect.
was incorrect.
(Ip=
[STRING],
Times=
[ULONG])
----End
Relevant Alarms
None.
Relevant Logs
None.
2.3.2 The NMS Fails to Receive Trap Messages from the Host
Common Causes

Equipment
l The trap message is lost.

l The SNMP configuration on the host is incorrect. As a result, the host is unable to send
trap messages.
l No trap message is generated on the host-side service module, or the trap message is
generated on the host-side service module, but the format of the trap messages is incorrect.
As a result, the trap message cannot be sent.
Figure 2-7 Troubleshooting flowchart used when the NMS fails to receive trap messages from
the host
The NMS fails to
receive trap messages
from the host
Whether the No
host is correctly Reconfigure the host
configured?
Yes
Observe the system log and

rectified the fault according
to the manual
Yes
Is the fault rectified? End
No
Seek technical support
Context
NOTE
Procedure
Step 1 Check whether the SNMP configurations on the host are correct.
l If the SNMP configurations are correct, go to Step 2.

Equipment
l If the SNMP configurations are incorrect, change the configuration according to the
following configuration cases.
Table 2-3 Typical SNMP configurations
Configuration Case Command
Configure a destination host running <HUAWEI> system-view

[HUAWEI] snmp-agent target-host trap
SNMPv2c, with the destination port address udp-domain 192.168.1.1 params
being the default 162, the username securityname huawei v2c
being huawei, and the IP address being
192.168.1.1.
NOTE
huawei must be an existing username.

SNMPv2c, with the destination port address udp-domain 192.168.1.1 udp-port
being 163, the username being huawei, 163 vpn-instance VPN-TEST params
and the IP address being 192.168.1.1. securityname huawei v2c
Trap messages are sent through a VPN
network named VPN-Test.
NOTE
Configure a destination host running # Configure a MIB view.

SNMPv3, with the username being <HUAWEI> system-view
[HUAWEI] snmp-agent mib-view included
huawei. The user belongs to the user Huawei_view iso
group named huawei_group and has
# Configure a user group.
Huawei_view as the notify rights [HUAWEI] snmp-agent group v3 huawei_group
(notify-view). read-view Huawei_view write-view
NOTE Huawei_view notify-view Huawei_view
With Huawei_view, the user can access all # Configure a user.
nodes from the iso subtree. [HUAWEI] snmp-agent usm-user v3 huawei
huawei_group

SNMPv3, with the username being address udp-domain 192.168.1.1 params
huawei and the IP address being securityname huawei v3
192.168.1.1.
NOTE

SNMPv3, with the destination port address udp-domain 192.168.1.1 udp-port
being 163, the username being huawei, 163 vpn-instance VPN-TEST params
and the IP address being 192.168.1.1. securityname huawei v3
Trap messages are sent through a VPN
network named VPN-Test.
NOTE

Equipment
Step 2 Run the display snmp-agent trap all command to check whether the trap function is enabled
on all feature modules.
l If the trap function is not enabled on all feature modules, go to Step 3.

l If the trap function is enabled on all feature modules, go to Step 4.
Step 3 Run the snmp-agent trap enable feature-name trap-name command to enable the host to send
trap messages and configure parameters for trap messages.
l If the NMS can receive trap messages sent from the host, go to Step 7.
l If the NMS fails to receive trap messages sent from the host, go to Step 4.
Step 4 Check whether the log message indicating that a specific trap is generated exists on the host.
l If the log message indicating that a specific trap is generated does not exist on the host, it
indicates that the trap is not generated. In this case, go to Step 6.
l If the log message indicating that a specific trap is generated exists on the host, it indicates
that the trap has been generated but the NMS fails to receive the trap message. In this case,
go to Step 5.
NOTE
The log message indicating that a specific trap is generated is as follows: #Jun 10 2010 09:55:03 Quideway
IFNET/2/IF_PVCDOWN:OID 1.3.6.1.6.3.1.1.5.3 Int erface 109 turned into DOWN state.
Step 5 Configure trap messages to be sent in Inform mode.

NOTE
Trap messages are transmitted through UDP. UDP transmission is unreliable, which may cause trap messages
to be lost on the link. Inform mechanism ensures that trap messages are sent in a reliable manner. For
configuration details, refer to "SNMP Configuration" in the Configuration Guide - System Management.
l If the NMS can receive trap messages sent from the host, go to Step 7.
l If the NMS fails to receive trap messages sent from the host, go to Step 6.
----End
Relevant Alarms
None.
Relevant Logs
None.
2.4 SSH Troubleshooting

2.4.1 The User Fails to Log in to the SSH Server Through SSH

Equipment
Common Causes
l The route is unreachable between the SSH client and SSH server and the user cannot set
up a TCP connection with the server.
l SSH services are not enabled.
l SSH is not configured in the user interface VTY view.
l The RSA public key is not configured on the SSH server and the client.
l The user service type, authentication type, user authentication service type are not
configured.
l The number of users logging in to the server reaches the upper threshold.
l An ACL is configured in the user interface VTY view.
l SSH versions of the server and the client are inconsistent.
l The initial authentication function is not enabled on the SSH client.

Equipment
Figure 2-8 Flowchart for troubleshooting the failure to log in to the SSH server by means of
SSH
Fail to log in to the SSH
server by means of SSH
Is there Yes
a route between the No Check that there is a route
between the SSH client and the Is fault
SSH client and the SSH rectified?
server? SSH server
Yes No
Is the SSH No Modify the configuration and start Yes

Is fault
service started? the SSH service rectified?
No
Yes
Are
the protocols No Modify the configuration to ensure Yes
that are allowed to access that SSH is allowed to access the Is fault
the VTY interface correctly VTY interface rectified?
configured?
No
Yes
Is an No Yes
Configure a key pair on the SSH Is fault
RSA public key configured rectified?
on the SSH server? server
Yes No
Are the Create a new SSH user and

user service type, No configure the authentication mode
and service type. Add a local user Is fault Yes
authentication type, and rectified?
authentication service type that has the same name with the
SSH user and configure the access
configured? type for the local user
Yes No
Does the number Modify the configuration to

of users connected to the No Yes
increase the number of users that Is fault
SSH server reach the are allowed to log in through VTY rectified?
upper limit? channels
Yes No
Modify the configuration to ensure

Is an ACL No that the SSH client's IP address is Is fault Yes
bound to the VTY interface allowed in the ACL bound to the rectified?
on the SSH server? VTY interface
No
Yes
Are the Modify the configuration to set the

SSH versions on the No Is fault Yes
SSH client and SSH server SSH versions on the SSH client rectified?
consistent? and SSH server to be the same
Yes No
Is first-time No Modify the configuration to enable Is fault

authentication enabled on first-time authentication on the SSH rectified?
the SSH client? client
Yes No
Collect debugging information Seek technical support End

Equipment
Context
NOTE
Procedure
Step 1 Check whether the SSH client and SSH server can communicate with each other.
On the SSH client and SSH server, run the ping command to check the network connectivity.
If the ping fails, the SSH connection cannot be established between the user and the server.
Check whether packet loss occurs on the network and whether the user access is stable.
Step 2 Check whether the SSH service on the SSH server is started.
Log in to the SSH server by means of Telnet and run the display ssh server status command
to view the configuration of the SSH server. The STelnet service and SFTP service are used as
examples.
<HUAWEI> display ssh server status
SSH version :1.99
SSH connection timeout :60 seconds
SSH server key generating interval :0 hours
SSH Authentication retries :3 times
SFTP server :Disable
Stelnet server :Disable
The command output shows that the SFTP and STelnet server are not enabled. The user can log
in to the server through SSH only after SSH services are enabled in the system. Run the following
command enable the SSH server.
[HUAWEI] sftp server enable
[HUAWEI] stelnet server enable
Step 3 On the SSH server, check that the access protocol configured in the VTY user interface view is
correct.
authentication-mode aaa
idle-timeout 0 0
protocol inbound ssh
Run the protocol inbound {all | ssh | telnet } command to configure the user access protocol.
By default, the user access protocol is Telnet. If the user access protocol is set to Telnet, the user
cannot log in to the server through SSH; if the user access protocol is set to SSH or "all", the
user can log in to the server through SSH.
Step 4 Check whether an RSA public key is configured on the SSH server.
When serving as an SSH server, a device must be configured with a local key pair.

Equipment
On the SSH server, run the display rsa local-key-pair public command to check whether the
key pair is configured on the current server. if the key pair is not configured, run the rsa local-
key-pair create command to create it.
[HUAWEI] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 2048]: 2048
Generating keys...
...........................++++++++
.++++++++
...............+++++++++
......+++++++++
Step 5 (Optional) Check that the user service type, authentication type, and authentication service type
(for password authentication only) have been configured.
The user service type, authentication type, and authentication service type must be correctly
configured on the SSH server. Run the display ssh user-information command to view the
configuration of the SSH user. If the configuration is not displayed, run the ssh user, ssh user
authentication-type, and ssh user service-type commands in the system view to create an SSH
user, configure SSH user authentication, and SSH user service type respectively.
Run the display local-user username user-name command to view detailed information about
the user that has the same name with the SSH user. If the configuration is not displayed, run the
local-user password and local-user service-type commands in the AAA view to add a local
user that has the same name with the SSH user, and configure the access type of the local user
respectively.
NOTE
In the case of the SFTP service, run the ssh user sftp-directory command in the system view to configure
an SFTP service authorization directory for the SSH user.
l Create an SSH user.
[HUAWEI] ssh user abc
[HUAWEI] ssh user abc authentication-type all
[HUAWEI] ssh user abc service-type all
[HUAWEI] ssh user abc sftp-directory cfcard:/ssh
Configure the same SSH user in the AAA view and configure the authentication server type.
[HUAWEI] aaa
[HUAWEI-aaa] local-user abc password irreversible-cipher abc-pass
[HUAWEI] local-user abc service-type ssh
l Configure password authentication as the default authentication mode for the SSH user.
[HUAWEI] ssh authentication-type default password
Configure the same SSH user in the AAA view and configure the authentication server type.
[HUAWEI] aaa
[HUAWEI-aaa] local-user abc password irreversible-cipher abc-pass
[HUAWEI] local-user abc service-type ssh
Step 6 Check whether the number of SSH login users has reached the maximum.
In the case of STelnet and Telnet services, both STelnet users and Telnet users log in to the
server through VTY channels. The number of available VTY channels ranges from 5 to 15.
When the number of users attempt to log in to the server through VTY channels is greater than
15, the new connection cannot be established between the user and the server.

Equipment
Log in to the SSH server through a console interface and then run the display users command
to check whether all the current VTY channels have been used. By default, a maximum of 5
users can log in to the server through VTY channels.
<HUAWEI> display user-interface maximum-vty
Maximum of VTY user:5
<HUAWEI> display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
34 VTY 0 03:31:35 TEL 10.1.1.1 pass no
35 VTY 1 03:51:58 TEL 10.1.1.2 pass no
36 VTY 2 00:10:14 TEL 10.1.1.3 pass no
37 VTY 3 02:31:58 TEL 10.1.1.4 pass no
+ 39 VTY 4 00:00:00 TEL 10.1.1.5 pass no
If the number of users logging in to the server reaches the upper threshold, you can run the user-
interface maximum-vty vty-number command to increase the maximum number of users
allowed to log in to the server through VTY channels to 15.
[HUAWEI] user-interface maximum-vty 15
Step 7 Check that an ACL is configured in the VTY user interface view on the SSH server.
Run the user-interface command on the SSH server to enter the SSH user interface view. Then,
run the display this command to check whether an ACL is configured in the VTY user interface
view. If an ACL is configured, record the ACL number.
Run the display acl command on the SSH server to check whether the IP address of the SSH
client is denied in an ACL. If an ACL is configured but the IP address of the client to be denied
is not specified in the ACL, the user will fail to log in to the server by means of Telnet or FTP.
To enable a user with a specific IP address to log in to the server through Telnet, permit the IP
address of the user in the ACL.
Step 8 Check the SSH versions on the SSH client and SSH server.
On the SSH server, run the display ssh server status command to check the SSH version.
<HUAWEI> display ssh server status
SSH version :1.99
SSH connection timeout :60 seconds
SSH server key generating interval :0 hours
SSH Authentication retries :3 times
SFTP server :Disable
Stelnet server :Disable
l If the client logging in to the server adopts SSHv1, the version compatible capability needs
to be enabled on the server.
[HUAWEI] ssh server compatible-ssh1x enable
l If the client logging in to the server adopts SSHv2, the version compatible capability does
not need to be enabled on the server.
[HUAWEI] undo ssh server compatible-ssh1x enable
Step 9 Check whether first-time authentication is enabled on the SSH client.

Equipment
Run the display this command in the system view on the SSH client to check whether first-time
authentication is enabled.
After the first-time authentication is enabled, the validity of the RSA public key of the SSH
server does not need to be checked when an STelnet or SFTP user logs in to the SSH server for
the first time. This is because the RSA public key of the SSH server is not kept on the STelnet
or SFTP client.
If the first-time authentication is not enabled, an STelnet or SFTP user fails to log in to the SSH
server. This is because checking the validity of the RSA public fails.
[HUAWEI] ssh client first-time enable

----End
Relevant Alarms
None
Relevant Logs
SSH/4/SSH_FAIL:Failed to log in through SSH. (Ip=[STRING], UserName=[STRING],
Times=[ULONG]).
SSH/4/STELNET_SERVER:The STELNET server is not started. Use the command' stelnet
server enable' to start it.
2.4.2 Trouble Cases
The Administrator Cannot Log in to the ATN Through SSH Due to Inconsistent
Key Lengths
Fault Symptom
In the networking shown in Figure 2-9, the administrator needs to log in to the ATN through
SSH. After the configuration, the administrator fails to log in.
Figure 2-9 The administrator failing to log in to the ATN through SSH
SSH Client SSH Server

Equipment
Fault Analysis
1. Check information about user login, and you can find the following information:
$ ssh -l client001 10.1.1.1
ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits
key_verify failed for server_host_key
The preceding information shows that the key generated on the server is less than 768 bits.
Therefore, the SSH connection cannot be set up.
Procedure
Step 1 Run the system-view view to enter the system view.
Step 2 Run the rsa local-key-pair create command to change the length of the key to 1024, in bits.
After entering the rsa local-key-pair create command, the system prompts you to enter the
number of bits of the host key. If the RSA key exists, the system prompts you to confirm whether
to change the original key. The procedure is as follows:
[HUAWEI]rsa local-key-pair create
The key name will be: HUAWEI_Host
% RSA keys defined for HUAWEI_Host already exist.
Confirm to replace them? [Y/N]:y
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]:1024
Generating keys...
.................++++++++++++
...++++++++++++
.................................++++++++
.............++++++++
After the preceding operations, the administrator can log in to the ATN through SSH. The fault
is cleared.
----End
Summary
The lengths of keys configured on the SSH server should be consistent with the requirements
of SSH clients.
Login to the SSH Server Fails Because a Local RSA Key Pair Is Not Configured
Fault Symptom
The ATN functions as an SSH server. The ATN and a client are configured with SSH to allow
the client to log in to the SSH server.

Equipment
Figure 2-10 Networking Diagram of SSH Server Fails
GE0/2/0
10.1.1.1/32
GE1/0/1
10.1.1.2/32
SSH Client SSH Server
After the configurations, the client cannot log in to the SSH server.
Fault Analysis
1. Run the display current-configuration configuration command on the ATN to check
configurations.
#
protocol inbound ssh authentication-mode aaa
#
aaa local-user abc password cipher $1a$1V%k5k!LRL$,cPI9'[Qc6b0vrQ7T<`;/
4.wOMtWY0=pLY#Ma.vE$ ssh user huawei
authentication-type password
The preceding information shows that the ATN is configured with SSH that requires
password authentication but no local RSA key pair is generated.
If the user interface adopts the SSH protocol, the rsa local-key-pair create command must
be used to create a local RSA key pair after SSH is enabled.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the rsa local-key-pair create command to generate a local RSA key pair.
After the operations, the client can log in to the SSH server. The fault is therefore rectified.
----End
Summary
Creating a local RSA key pair is a prerequisite to SSH login. That is, the rsa local-key-pair
create command must be used to create a local RSA key pair before the other SSH-related
configurations.
2.5 RMON Troubleshooting
2.5.1 NM Station Cannot Receive RMON Alarms

Equipment
Common Causes
l There is no reachable route between the router and the NM station.
l The SNMP alarm function is not configured correctly.
l Rmon StatsTable is not configured.
l The statistics of RMON is not enabled.
l The RMON eventTable is not enabled.
l The RMON alarmTable is not enabled.
l The alarm variables are not configured correctly.
When the traffic that flows in and out of the LAN exceeds the configured threshold, the NM
station fails to receive alarms. Figure 2-11 shows the troubleshooting flowchart.

Equipment
Figure 2-11 Troubleshooting flowchart for the failure of the NMS to receive RMON alarms
NM station
cannot
receive RMON
alarms.
Is
route to NM station No Configure routes Is fault Yes
to the NM station
reachable? rectified?
correctly
No
Yes
Is the SNMP No Configure the Is fault Yes

alarm function enabled SNMP alarm rectified?
correctly? function correctly
No
Yes
Is the
No Is fault Yes
RMON statistic function Enable the RMON
enabled? statistic function. rectified?
No
Yes
Is the
RMON event entry No Create the RMON Is fault Yes
created? event entry. rectified?
No
Yes
Is theRMON No Create the RMON Is fault Yes

alarm entry alarm entry. rectified?
created?
No
Yes
Is the alarm Configure the Is fault Yes

No
Variables enabled alarm variables rectified?
correctly? correctly
No
Seek technical
End
support.

Equipment
Context
NOTE
Procedure
Step 1 Check whether there are reachable routes between the ATN and the NM station.
Ping the NM station interface from the ATN.
l If the ping succeeds, it indicates that the routes between the ATN and the NM station are
reachable, go to Step 2.
l If the ping fails, check the routes between the ATN and the NM station. For details of routing
troubleshooting, see the section The Ping Operation Fails.
Step 2 Check that the SNMP alarm function is configured correctly.
Check whether the NM station can receive other alarms. If not, do as follows:
l Run the display snmp-agent trap feature-name all command to check whether the alarm
function of the ATN is enabled
l Run the display snmp-agent target-host command to check whether the NM address
through which the ATN sends alarms is correct
Step 3 Check that the statistics of RMON is enabled.
Run the display this command on the specified interface to check whether the statistics of
RMON is enabled. If the statistics of RMON is disabled, run the rmon-statistics enable
command.
Step 4 Check that rmonStatsTable is configured.
Run the display rmon statistics [ ethernet interface-number | gigabitethernet interface-
number | xgigabitethernet interface-number ] command on the ATN to check whether
rmonStatsTable is configured. If rmonStatsTable is null, run the rmon statistics entry-
number [ owner owner-name ] command to create entries of the table.
Step 5 Check that the RMON eventTable is enabled.
Run the display rmon event [ entry-number ] command on the ATN interface to check whether
the RMON eventTable is enabled. If the eventTable is null, run the rmon event command to
create entries of the table.
Step 6 Check that the RMON alarmTable is enabled.
Run the display rmon alarm [ entry-number ] command on the ATN interface to check whether
the RMON alarmTable is enabled. If the alarmTable is null, run the rmon alarm command to
create entries of the table.
Step 7 Check that the alarm variables are configured correctly.
Run the display rmon alarm [ entry-number ] command on the ATN interface to view the value
of the configured alarm variables. On the NM station, check that the values of alarm variables

Equipment
of the interface are consistent with those values configured on the ATN interface. If the values
are inconsistent, modify the values of the alarm variables to be consistent.
Step 8 After the preceding operations are complete, if the NM station cannot receive the alarm values
of the RMON module on the ATN, contact the Huawei technical personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
2.6 RMON2 Troubleshooting

2.6.1 NM Station Fail to Query the Trafic Sent by a Hosy to the
Device
Common Causes
l There is no reachable route between the router and the NM station.
l ProtocolDirTable of RMON2 is not configured correctly.
l hlhostcontrolTable of RMON2 is not configured correctly.

Equipment
Figure 2-12 Troubleshooting flowchart for the failure of the NMS to query the traffic sent from
a host to the device
NM station fails to
query the traffic sent
by a host to the
router
Are there Yes

No Configure correct
reachable routes End
routes to the NM Is fault rectified?
between NM station
station
and routers?
No
Yes
No Yes
Is protocolDirTable Configure
Is fault rectified? End
configured correctly? protocolDirTable
No
Yes
Is
hlhostControlTable No Yes
Configure
configured correctly? Is fault rectified? End
hlhostControlTable
No
Yes
Seek technica supportl
Context
NOTE
Procedure
Step 1 Check whether there are reachable routes between the ATN and the NM station.
Ping the NM station interface from the ATN.

l If the ping succeeds, it indicates that the routes between the ATN and the NM station are
reachable.

Equipment
l If the ping fails, check the routes between the ATN and the NM station. For details of routing
troubleshooting, see the section The Ping Operation Fails.
Step 2 Check that protocolDirTable of RMON2 is configured correctly.
Run the display rmon2 protocoldirtable command to check whether the value of
protocolDirHostConfig in protocolDirTable is supportedOn. If not, run the rmon2
protocoldirtable protocoldirid command to set the value to supportOn. Check whether the
value of protocolDirStatus in the protocolDirTable is active. If not, set the value of
protocolDirStatus to active.
Step 3 Check that hlhostcontrolTable of RMON2 is configured correctly.
Run the display rmon2 hlhostcontroltable [ index ctrl-index ] command to check whether the
value of hlHostControlStatus in the nlhostControlTable is active. If not, run the rmon2
hlhostcontroltable command to set the value of hlHostControlStatus to active.
Step 4 If information about nlhostTable cannot be obtained after the preceding operations are complete,
contact the Huawei technical personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
2.7 NQA Troubleshooting
2.7.1 A UDP Jitter Test Instance Fails to Be Started
Common Causes
l The mandatory parameter of the test instance is incorrect.

Equipment
Figure 2-13 Troubleshooting flowchart used when a UDP Jitter test instance fails to be started
A UDP jitter test
unstance fails to be
started
No Ensure that the test Yes

Whether the test Is the fault
type is Jitter? type is Jitter rectified?
Yes No
Whether the No Ensure that the Yes

Is the fault
destination address is destination address is
rectified?
configured? configured
No
Yes

destination port is destination port is Is the fault
configured? configured rectified?
Yes No
Seek technical support End
Context
NOTE
All the following commands, except the display commands, are used in the NQA test instance view. The
display commands can be used in any views.
Procedure
Step 1 Run the display nqa-agent admin-name test-name [ verbose ] command on the NQA client or
the display this command in the NQA test instance view to check whether the test type is Jitter.
l If the test type is Jitter, go to Step 2.
l If the test type is not Jitter, run the test-type jitter command to configure the test type to
UDP Jitter.
If the fault is rectified, the operation ends.
If the fault persists, go to Step 2.

Equipment
the display this command in the NQA test instance view to check whether the destination IP
address is configured.
l If the destination IP address is configured, go to Step 3.
l If the destination IP address is not configured, run the destination-address ipv4 ip-
address command in the NQA test instance view to configure the destination IP address.
the display this command in the NQA test instance view to check whether the destination port
is configured.
l If the destination port is configured, go to Step 4.
l If the destination port is configured, run the destination-port port-number command in the
NQA test instance view to configure the destination port.
personnel:
----End
Relevant Alarms
None.
Relevant Logs
None.
2.7.2 A Drop Record Exists in the UDP Jitter Test Result
Common Causes
If the UDP jitter test result has drop records, the value of the "Drop operation number" field in
the display nqa results command output is not 0.

l The destination IP address does not exist or the route to the network segment to which the
destination IP address belongs does not exist in the routing table.
l The source IP address is incorrect.

Equipment
Figure 2-14 Troubleshooting flowchart used when a drop record exists in the UDP jitter test
A drop record exists in

the UDP jitter test result
Ensure that the

Whether the No destination address Yes
Is the fault
destination address exists and is rectified?
reachable? reachable
Yes No

source address exists Is the fault
source address is rectified?
configured? and is reachable
Yes No
Context
NOTE
Procedure
Step 1 Run the display ip routing-table command on the NQA client to check whether the route along
the test path exists.
l If the route exists, run the ping command to check whether devices can successfully ping
each other.
If devices can successfully ping each other, go to Step 2.
If devices cannot successfully ping each other, see The Ping Operation Fails.
l If the route does not exist, run the corresponding command to reconfigure the route.
the display this command in the NQA test instance view to check whether the source IP address
is configured.
l If the source IP address is configured, run the display ip interface brief on the NQA client
to check whether the interface configured with the source IP address exists.
If the interface exists, run the display ip routing-table command on the NQA server to
check whether the route to the source IP address exists.

Equipment
If the route exists, run the ping command to check whether the source IP address is
reachable.
If the source IP address is reachable, go to Step 3.
If the source IP address is unreachable, see The Ping Operation Fails.
If the route does not exist, run the corresponding command to reconfigure the route.
If the interface configured with the source IP address does not exist, run the corresponding
command to reconfigure IP addresses and recheck the configuration about NQA.
l If the source IP address is not configured, go to Step 3.
personnel:
----End
Relevant Alarms
None.
Relevant Logs
None.
2.7.3 A Busy Record Exists in the UDP Jitter Test Result
Common Causes
If the UDP jitter test result has busy records, the value of the "System busy operation number"
field in the display nqa results command output is not 0.

l The VPN route instance that is configured in the UDP Jitter test instance is unreachable.

Equipment
Figure 2-15 Troubleshooting flowchart used when a busy record exists in the UDP jitter test
A busy record exists in

the UDP jitter test result
Yes Ensure that devices

Yes
Is the VPN instance in a VPN can Is the fault
configured? communicate with rectified?
each other
No
No
Context
NOTE
Procedure
the display this command in the NQA test instance view to check whether the VPN instance is
configured.
l If the VPN instance is configured, go to Step 2.
l If the VPN instance is not configured, go to Step 3.
Step 2 Run the ping -vpn-instance vpn-instance-name command on the NQA client to check whether
the destination address is reachable.
l If the destination address is reachable, go to Step 3.
l If the destination address is unreachable, see the section The Ping Operation Fails.
personnel:
----End

Equipment
Relevant Alarms
None.
Relevant Logs
None.
2.7.4 A Timeout Record Exists in the UDP Jitter Test Result
Common Causes
If the UDP jitter test result has timeout records, the value of the "operation timeout number"
field in the display nqa results command output is not 0.

l The destination address does not exist, but the route to the network segment of the
destination address exists in the routing table.
l The value of the parameter "nqa-jitter tag-version" is 2, and the receiver is not configured
with a UDP server.
Figure 2-16 Troubleshooting flowchart used when a timeout record exists in the UDP jitter test
A timeout record exists

in the UDP jitter test
result
Ensure that the

Whether the No destination address Yes
Is the fault
destination address exists and is rectified?
reachable? reachable
Yes No
Yes Ensure that the NQA

Yes
Is the NQA jitter tag- server is configured Is the fault
version 2? and is in the Active rectified?
state
No
No

Equipment
Context
NOTE
Unless otherwise stated, all the following commands, except display commands that can be run in all views,
need to be run in the NQA test instance view.
Procedure
Step 1 Run the ping command on the NQA client to check whether the route to the destination address
is reachable.
l If the route to the destination address is reachable, go to Step 2.
l If the route to the destination address is unreachable, see the section The Ping Operation
Fails.
Step 2 Run the display this command in the system view on the NQA client to check whether the value
of the parameter "nqa-jitter tag-version" is 2. When the value of this parameter is set to 1 (the
default value), this parameter is not displayed in the configuration file. This parameter is
displayed in the configuration file when its value is set to 2.
l If the value of the parameter "nqa-jitter tag-version" is 2, go to Step 3.
l If the value of the parameter "nqa-jitter tag-version" is not 2, go to Step 4.
Step 3 Run the display nqa-server command on the NQA server to check whether the nqa-server
udpecho ip-address port-number command has been configured on the NQA server.
l If the nqa-server udpecho ip-address port-number command has been configured on the
NQA server and is in the Active state, go to Step 4.
l If the nqa-server udpecho ip-address port-number command is not configured on the NQA
server, run the command to configure the NQA server. Note that the IP address of the NQA
server must be identical with the destination IP address configured through the destination-
address ipv4 ip-address command on the NQA client. Also, the port number configured on
the NQA server must be identical with that configured through the destination-port port-
number command on the NQA client.
personnel:
----End
Relevant Alarms
None.

Equipment
Relevant Logs
None.
2.7.5 The UDP Jitter Test Result Is "Failed", "No Result" or "Packet
Loss"
Common Causes
The UDP jitter test result displayed in the display nqa results command output can be "failed",
"no result", or "packet loss". In the command output,
l If the "Completion" field is displayed as "failed", the test fails.
l If the "Completion" field is displayed as "no result", the test has no result.
l If the "lost packet ratio" field is not 0%, packet loss occurs.

l A drop record exists in the UDP jitter test result.
l A busy record exists in the UDP jitter test result.
l A timeout record exists in the UDP jitter test result.
l The TTL expires.
l The parameter frequency is incorrect.
l The parameter fail-percent is incorrect.

Equipment
Figure 2-17 Troubleshooting flowchart used when the UDP Jitter test result is "failed", "no
result", or "packet loss"
The UDP jitter test
result Is "failed", "no
result" or "packet
loss"
Whether No Yes
Ensure that the existing Is the fault
the existing fault has
fault has been rectified rectified?
been rectified?
Yes No
Ensure that the TTL of

Yes the packet sent from the Yes
Whether the Is the fault
client is large enough for
TTL is configured? rectified?
the packet to reach the
destination
No No
Ensure that the value of

Whether the Yes the frequency is larger Yes
Is the fault
parameter frequency than the value of
rectified?
is configured? (interval*probe-
count*jitter-packetnum)
No No
Whether Yes
Yes Check whether the
the parameter Is the fault
parameter fail-percent is
fail-percent is rectified?
set to a reasonable value
configured?
No No
Seek technical
End
support
Context
NOTE
All the following commands, except the display commands, are used in the NQA test instance view. The
display commands can be used in any views.

Equipment
Procedure
the display this command in the NQA test instance view to check whether the TTL is configured.
l If the TTL is configured, you can run the ttl number command in the NQA test instance
view to set the value of the TTL to 255. If the fault persists after the TTL is set to 255, go to
Step 2.
l If the TTL is not configured, you can run the ttl number command in the NQA test instance
view to set the value of the TTL to 255. If the fault persists after the TTL is set to 255, go to
Step 2.
Step 2 Run the display nqa-agent admin-name test-name [ verbose ] command on the NQA agent or
the display this command in the NQA test instance view to check whether the parameter
frequency is configured.
l If the parameter frequency is configured, compare the value of the frequency and that of
the (interval x probe-count x jitter-packetnum). To ensure that the UDP Jitter test instance
can be complete normally, the value of the frequency must be greater than that of the (interval
x probe-count x jitter-packetnum). If the value of the frequency is less than that of the
(interval x probe-count x jitter-packetnum), run the frequency interval command in the NQA
test instance view to increase the value of the frequency.
l If the frequency is not configured or the fault persists after a proper frequency value is set,
go to Step 3.
Step 3 Run the display nqa-agent admin-name test-name [ verbose ] command on the NQA agent or
the display this command in the NQA test instance view to check whether the parameter fail-
percent is configured.
l If the fail-percent is configured, run the undo fail-percent command in the NQA test
instance view to delete the fail-percent. If the fault persists after the fail-percent is deleted,
go to Step 4.
l If the fail-percent is not configured, go to Step 4.
personnel:
----End
Relevant Alarms
None.
Relevant Logs
None.

Equipment
2.7.6 General Flow Test Result Description and Troubleshooting

Roadmap
Common Causes
l For configuration failures, possible causes are as follows:
An interface, a service VLAN, or a user VLAN does not exist.
Resources are insufficient as the number of general flow test instances exceeds the upper
limit.
Although resources are sufficient, the number of test instances on the initiator or
reflector reaches the upper limit.
The size (in bytes) of test packets is incorrect.
The same test instance already exists.
The configured bandwidth (in kbit/s) exceeds the interface bandwidth, or the total
bandwidth exceeds the interface board bandwidth.
l For test instance failures, possible causes are as follows:
The lower bandwidth threshold is set too large, or the upper bandwidth threshold is set
too small.
The path between the initiator and reflector is unreachable.
A test instance times out.
Member interfaces leave a trunk interface.
Network jitters cause the device to fail to find the rate that satisfies requirements for
packet loss ratio and precision.
NOTE
l Run the display nqa results command to view general test results. For a delay or packet loss test, the
completion field displays finished. For a throughput test, the completion field displays succeed if a
rate that satisfies requirements for the packet loss ratio and precision is found or displays failed if such
a rate is not found.
l Run the display nqa results verbose command to view detailed general test results. If the
completion field displays failed, check the Detailed result information for the cause.

Equipment

Equipment
Figure 2-18 Flowchart for troubleshooting a general flow test failure
A general flow test fails.
Yes
Does its configuration fail? Rectify the incorrect configuration.
No
Yes Verify the connectivity between the

Is the patch unreachable?
initiator and reflector.
No
Does a member Yes

interface leave a Verify the trunk configuration.
trunk interface?
No
Yes
Is the upper threshold Increase the upper threshold for
set too small? bandwidth if needed.
No
Yes
Is the lower threshold Reduce the lower threshold for bandwidth if
set too large? needed.
No
Yes
Does a network jitter Change the prevision or initiate more
occur? attempts.
No

Copyright Huawei Technologies
YesCo.,Increase
Ltd. the duration value or reduce the
Does the test time out? bandwidth range that includes the
throughput value.
Equipment
Context
NOTE
Procedure
l Run the display nqa results [ verbose ] command in the NQA test instance view to view
the Detailed result information field on the initiator.
1. If the Detailed result information field indicates a configuration failure, run the
display this command in the NQA test instance view to view the configuration on the
initiator. If a configuration is incorrect, correct the configuration.
2. If a message "The path is unreachable" is displayed, check the connectivity of the path
between the initiator and reflector. Connectivity information includes routes and static
ARP settings.
3. If a message "Trunk member remove" is displayed, verify the trunk configuration on
the initiator or reflector.
4. If a message "The specified high rate is too small" is displayed, perform either of the
following operations:
Ignore this problem if the configured upper bandwidth threshold meets test
requirements.
To use a higher bandwidth, run the rate rate-high command to increase the upper
bandwidth threshold on the initiator.
5. If a message "The specified low rate is too large" is displayed, check the throughput
value, run the rate rate-low to command to reduce the lower bandwidth threshold,
and conduct another test.
6. If a message "Fail to find a rate within the specified range to meet loss ratio and
precision requirements (Jitter may occur)" is displayed, run the precision precision-
value command to increase the precision value or conduct multiple tests.
7. If a message "Timeout" is displayed, check the duration, precision, and rate settings.
Run the duration duration command to increase the duration or run the rate rate-
low rate-high command to reduce the bandwidth range as needed before conducting
tests.
8. If the fault persists, collect the following information and contact Huawei technical
support personnel.
Results of the troubleshooting procedure.
Configuration files, log files, and alarm files of the devices
----End
Relevant Alarms
None

Equipment
Relevant Logs
None
2.8 NTP Troubleshooting
2.8.1 The Clock is not Synchronized
Common Causes
l The link flaps.

l The link is faulty.
Context
NOTE
Procedure
Step 1 Check the NTP status.
[HUAWEI] display ntp-service status
clock status: unsynchronized
clock stratum: 16
reference clock ID: none
nominal frequency: 100.0000 Hz
actual frequency: 99.9995 Hz
clock precision: 2^18
clock offset: 0.0000 ms
root delay: 0.00 ms
root dispersion: 0.00 ms
peer dispersion: 0.00 ms
reference time: 14:25:55.477 UTC Jun 9 2010(CFBA22F3.7A4B76F6)
The "clock status" field is displayed as "unsynchronized", indicating that the local system clock
is not synchronized with any NTP server or a reference clock.
Step 2 Check the status of the NTP connection.

[HUAWEI] display ntp-service sessions
The value of the "reference" is 0.0.0.0, specifying that the local system clock is not synchronized
with any NTP server.
Step 3 Run the ping command on the NTP client to check the status of the link to the NTP server.
[HUAWEI] ping 20.1.14.1
Request time out
Request time out
Request time out

Equipment
Request time out

Request time out
--- 20.1.14.1 ping statistics ---
100.00% packet loss
l The displayed information "100.00% packetloss" indicates that the link is faulty. To locate
the fault, refer to The Ping Operation Fails.
l If the packet loss percentage is not 100.00%, the link flaps. To locate the fault, refer to The
Ping Operation Fails.
l If the packet loss percentage is 0.00%, the link is normal. Then proceed to step 4.
personnel:
----End
Relevant Alarms
None.
Relevant Logs
The following log information indicates that the clock source with which the local device
synchronizes is lost.
NTP/4/SOURCE_LOST
The following log information indicates that the local clock has synchronized with a clock
source.
NTP/4/LEAP_CHANGE
NTP/4/STRATUM_CHANGE
NTP/4/PEER_SELE

Equipment
Troubleshooting 3 Physical Connection and Interfaces
3 Physical Connection and Interfaces
About This Chapter
3.1 Eth-Trunk Interface Troubleshooting
3.2 GE Interface Troubleshooting

Equipment
3.1 Eth-Trunk Interface Troubleshooting
3.1.1 Eth-Trunk Interface Cannot Forward Traffic
Common Causes
After an Eth-Trunk interface is configured, it cannot forward traffic.

l Eth-Trunk member interfaces are faulty.
l Configurations of Eth-Trunk member interfaces on the two ends are inconsistent.
l The number of Up Eth-Trunk member interfaces is smaller than the lower threshold.
l Negotiation between member interfaces of the Eth-Trunk interface in static LACP mode
fails.
On the network shown in Figure 3-1, the Eth-Trunk interface cannot forward traffic.
Figure 3-1 Networking diagram of Eth-Trunk interfaces
ATNA CX-B
Eth-Trunk1 Eth-Trunk1
The troubleshooting roadmap is as follows:

l Check that Eth-Trunk member interfaces work properly.
l Check information about Eth-Trunk member interfaces on both ends.
l Check that the number of Up member interfaces is greater than the configured lower
threshold.
l Check that LACP negotiation succeeds if the Eth-Trunk interface is in static LACP mode.

Equipment
Figure 3-2 Troubleshooting flowchart for the fault that the Eth-Trunk interface cannot forward
traffic
Eth-Trunk interface
cannot forward traffic
Check physical links

Eth-Trunk member Yes connecting member Yes
interfaces work interfaces and rectify Is fault rectified?
properly? the link fault
No No
Member interfaces Yes Modify the Yes

on both ends are Is fault rectified?
configuration
consistent?
No
No
Number of Up
Yes Change the lower Is fault rectified? Yes
member interfaces is
threshold
below the lower
threshold?
No
No
Negotiation between Locate the cause of

Yes the negotiation Yes
Eth-Trunk interfaces Is fault rectified?
working in static LACP failure and modify
mode fails? the configuration
No
No
Collect information
NOTE
Procedure
Step 1 Check that Eth-Trunk member interfaces work properly.
Run the display eth-trunk 1 command in any view to check the status of the Eth-Trunk interface.

Equipment
[HUAWEI] display eth-trunk 1

Eth-Trunk1's state information is:
WorkingMode: NORMAL Hash arithmetic: According to flow
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 8
Operate status: down Number Of Up Port In Trunk: 0
--------------------------------------------------------------------------------
PortName Status Weight
GigabitEthernet0/2/0 Down 1
l If a member interface is Down, you need to troubleshoot the physical interface. For detailed
troubleshooting procedures, see "Physical Interconnection Troubleshooting".
l If all member interfaces are Up, go to Step 2.
Step 2 Check information about Eth-Trunk member interfaces on both ends.

l Check information about member interfaces of the Eth-Trunk interface on ATNA.
[ATNA] display eth-trunk 1
Operate status: up Number Of Up Port In Trunk: 3
-------------------------------------------------------------------------------
-
GigabitEthernet0/2/0 Up 1
l Check information about member interfaces of the Eth-Trunk interface on CX-B.

[CX-B] display eth-trunk 1
-------------------------------------------------------------------------------
-
l If the number of member interfaces of the Eth-Trunk interface on ATNA is different from
that on CX-B, add the required physical interfaces to the Eth-Trunk interface.
l If the number of member interfaces of the Eth-Trunk interface on ATNA is the same as
that on CX-B, go to Step 3.
Step 3 Check whether the Eth-Trunk interface is configured with a lower threshold of Up member
interfaces.
Run the display eth-trunk 1 command on ATNA and CX-B to view the configuration of the
Eth-Trunk interface.
--------------------------------------------------------------------------------

Equipment
The preceding command output shows that the lower threshold of Up member interfaces of the
Eth-Trunk interface has been set to 4. However, the number of Up member interfaces of the Eth-
Trunk interface is actually 3, which causes the Eth-Trunk interface to go Down.
l If the Eth-Trunk interface is configured with a lower threshold of Up member interfaces

and the configured lower threshold is greater than the actual number of Up member
interfaces, set the lower threshold to a proper value.
l If the Eth-Trunk interface is not configured with a lower threshold of Up member interfaces,
go to Step 4.
Step 4 Check whether Eth-Trunk interfaces work in static LACP mode.
Run the display eth-trunk 1 command on ATNA and CX-B to view the configuration of the
Eth-Trunk interface.
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 32768 System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 8
--------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState Weight
GigabitEthernet0/2/0 Unselect 1GE 32768 264 305 11100010 1
Partner:
--------------------------------------------------------------------------------
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
GigabitEthernet0/2/0 0 0000-0000-0000 0 0 0 11100011
l If the Eth-Trunk interface is configured to work in static LACP mode and no physical
interface is selected, it indicates that LACP negotiation is unsuccessful. Possible causes for
unsuccessful LACP negotiation are as follows:
Member interfaces fail, causing timeout of LACP protocol packets.
In this case, you need to troubleshoot member interfaces.
The Eth-Trunk interface on one end is configured to work in static LACP mode, whereas
the Eth-Trunk interface on the other end is not.
Correct the configurations of the two ends of the Eth-Trunk link to make them
consistent.
After the configurations are corrected and LACP negotiation succeeds, the output of the
display eth-trunk 1 command is as follows:
[CX-B] display eth-trunk 1
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 32768 System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 16
------------------------------------------------------------------------------
--
ActorPortName Status PortType PortPri PortNo PortKey PortState
Weight

Equipment
GigabitEthernet1/0/8 Selected 1GE 32768 264 305 11111100 1

Partner:
------------------------------------------------------------------------------
--
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
GigabitEthernet1/0/8 32768 0018-823c-c473 32768 2056 305 11111100
If LACP negotiation fails after the configurations are corrected, go to Step 5.

l If the Eth-Trunk interface is not configured to work in static LACP mode, go to Step 5.
l Results of the preceding troubleshooting procedure
----End

None.
3.2 GE Interface Troubleshooting
3.2.1 Interconnected Interfaces Alternate Between Up/Down States
Fault Symptom
When the ATN and a router are directly connected through GE interfaces by optical fibers, the
GE interfaces frequently alternate between Up and Down states. The following log messages
are displayed:
%Nov 12 11:00:10 2007 HUAWEI PHY/2/PHY:Slot=;GigabitEthernet0/2/0: change status to
down
%Nov 12 11:00:11 2007 HUAWEI PHY/2/PHY:Slot=;GigabitEthernet0/2/0: change status to
up
Fault Analysis
1. Run the display interface [ interface-type interface-number ] command in any view on the
two interconnected interfaces, and you can find that both interfaces receive CRC error
packets. The possible causes are as follows:
a. Data transmission is interfered and error codes occur.
b. The optical power is unstable.
c. The transmit interface on the peer device fails.
d. An error occurs during packet resolution on the local device.
2. Through the preceding log messages, you can find that the two interfaces do not turn Up
or Down at the same time.

Equipment
If auto-negotiation is configured, the interconnected interfaces automatically send

negotiation frames afer receiving optical signals. If both interfaces receive negotiation
frames, they both go Up. In this troubleshooting case, the two interfaces do not turn Up or
Down at the same time, which indicates that one interface receives negotiation frames
whereas the other does not receive any. Therefore, it can be inferred that a fault occurs
during packet transmission over the link.
Through the preceding analysis, it can be determined that a fault occurs on the transmission
link. In this case, the following describes how to locate the fault on the transmission link:
3. Through on-site measurement, it is found that both the receive optical power of the two
interfaces is -20 dBm, which meets the optical modules' requirement. Therefore, the
possibility of a module or optical fiber fault is ruled out.
4. Check the optical fibers and optical modules for other anomalies. You can find that the
fiber end is contaminated.
It can be identified that error codes occur on the receive interface due to contamination of the
fiber end.
Procedure
Step 1 After the fiber end is cleaned, the interface goes Up.
The fault is thus rectified.
----End
Summary
In the case of long-distance transmission, ensure that the optical fiber is bent at less than 90
degrees, free from damage or contamination, and properly connected.
3.2.2 Severe Packet Loss Occurs After the FE Optical Module Is

Mistakenly Inserted into a GE Optical Interface
Fault Symptom
Users connected to GE 0/2/0 on the EG2 of the ATN device report that the Internet is slow and
severe packet loss occurs.
Fault Analysis
1. Check logs on the ATN device. No exception is displayed.
2. Run the display interface gigabitethernet 0/2/0 command to check the interface status. It
is found that the interface and protocol are both Up and no CRC error occurs.
The maximum bandwidth of the interface is 1 Gbit/s whereas the maximum bandwidth of
the optical module is 155 Mbit/s. It can be inferred that the optical module mismatches the
interface, which causes severe packet loss.

Equipment
Procedure
Step 1 Replace the FE optical module with a GE optical module and insert the GE optical module into
the interface. Then, users can access the Internet normally and the fault is rectified.
----End
Summary
The mismatch between the optical module and the interface causes severe packet loss. The
appearances of the FE optical module and the GE optical interface module are the same. Thus,
check the parameters of the optical module carefully before inserting the optical module into
the interface.

Equipment
Troubleshooting 4 IP Forwarding and Routing
4 IP Forwarding and Routing
About This Chapter
4.1 ARP Troubleshooting
4.2 IP Forwarding
4.3 OSPF Troubleshooting
4.4 IS-IS Troubleshooting
4.5 BGP Troubleshooting
4.6 RIP Troubleshooting

Equipment
4.1 ARP Troubleshooting
4.1.1 The ARP Entries on the Local Device Cannot Be Learnt By the
Peer
Common Causes
l The interface connecting the local device to the peer is not physically Up.
l The IP addresses of the interfaces connecting the local device and the peer are on different
network segments.
l The local device is under ARP attacks.
l The link transmission is unstable or the optical power is insufficient.
l The device software is faulty.
The ATN is connected to a peer device but cannot learn the ARP entries on the peer device.
Figure 4-1 shows the detailed troubleshooting procedure.

Equipment
Figure 4-1 Troubleshooting flowchart for the fault that the ARP entries on the peer device cannot
be learnt
Failing to learn the ARP entries

on the peer device
Is the No Ensure that the Yes

interface is Is the fault
interface physically Up? rectified?
physically Up
No
Yes
Is there Ensure that there is

any error packet on the No Is the fault Yes
no error packet on
interface? rectified?
the interface
Yes No
Ensure that the IP

Are the IP addresses of the
addresses of the interface No interface and the peer Is the fault Yes
and the peer device on the device are on the rectified?
same network same network
segment? segment
Yes No
Does the
number of sent broadcast Yes Ensure that the peer Is the fault Yes
packets and received device and the link
rectified?
unicast packets are normal
increase?
No
No
Context
NOTE
Procedure
Step 1 Run the display interface interface-type interface-number command in the user view to view
the physical status of the interface connecting the local device to the peer.

Equipment
NOTE
You can run the display interface interface-type interface-number command to view information about
the interface connecting the local device to the peer.
l If the interface is Down, refer to relevant troubleshooting cases to make the interface go Up.
l If the interface is Up, go to Step 2.
Step 2 View the Internet Address field. Check that the IP addresses of the interfaces connecting the
two devices are on the same network segment.
l If the two IP addresses are on different network segments, re-configure either one of the IP
addresses so that the two IP addresses are on the same network segment.
l If the two IP addresses are on the same network segment, go to Step 3.
Step 3 Run the display arp all command in the user view to check whether the number of ARP entries
on the exceeds the upper limit. If so, refer to the relevant troubleshooting cases to verify if the
device is attacked by invalid ARP packets.
If the number of ARP entries does not exceed the upper limit but the fault persists, go to Step
4.
Step 4 View status information of the interface connecting the local device to the peer. Check whether
the count displayed in the CRC field increases. If so, it indicates that there are a large number
of error packets on the interface connecting the local device to the peer. In this case, check the
link quality to verify if the link transmission is unstable or the optical power is insufficient.
If the count displayed in the CRC field does not increase but the fault persists, go to Step 5.
the count in the Broadcast sub-field of the Output field increases.
Before viewing the following information, ping the IP address of the peer device from the local
device to trigger the local device to send ARP request packets.
l If the number of broadcast packets remains unchanged, it indicates that no ARP request
packet is sent. Therefore, it can be concluded that the local device is faulty. In this case, go
to Step 7.
l If the number of broadcast packets increases, check whether the peer device or the link is
functioning properly.
If the peer device or the link is not functioning properly, locate the fault and rectify it.
If the peer device and the link function are functioning properly, go to Step 6.
the count in the Unicast sub-field of the input field increases.
l If the number of unicast packets remains unchanged, it indicates that the device has not
received any ARP response packets. The ARP response packets sent by the local device may
have been discarded on the peer device because their format is not RFC-compliant.
l If the number of unicast packets increases, it indicates that the local device has received ARP
response packets. It can be concluded that some software modules on the local device are
not functioning properly. In this case, go to Step 7.
l Results of the preceding operation procedure

Equipment
----End
Relevant Alarm and Log Messages
Alarm Messages
None.
Log Messages
None.
4.2 IP Forwarding
4.2.1 The Ping Operation Fails
Common Causes
If the source end does not receive any response to its Request packet from the destination end
within a specified period, the ping operation fails.
l The link transmission delay is too long. Therefore, if the source end does not receive any
Response packet from the destination end within the waiting time, the ping operation fails.
l There are improper configurations. For example, packet fragmentation is not enabled when
a large Ping packet is sent but the outbound interface of the packet has a smaller MTU.
l Routing entries or ARP entries (for Ethernet links) are incorrect.
l The hardware is faulty.

Equipment
Figure 4-2 Troubleshooting flowchart for a ping failure

The destination
address fails to be
pinged successfully
Yes Increase the value Yes

Is the link transmission Is fault
of -t in the ping
delay too long? rectified?
command
No
No
Is the Yes Yes

Correctly perform the Is fault
ping operation
ping operation rectified?
correct?
No No
Locate the direction and

device where the fault occurs
Is a CPU Yes
No Configure an attack
attack defense policy Is fault
defense policy on
is configured on the rectified?
the device
device?
No
Yes
Are FIB and No Ensure that FIB and Yes

Is fault
ARP entries on the ARP entries are
rectified?
device? correct
Yes No
Do error Yes Yes

Clear faults on the link Is fault
packets exist on
and optical module rectified?
interfaces?
No
No
Does the
Yes Ensure that the Yes
network layer of the Is fault
network layer works
device work rectified?
properly
properly?
No
No

Equipment
NOTE
Procedure
Step 1 Check whether or not the ping failure is caused by the too long link transmission delay.
Run the ping -t time-value -v destination-address command to check whether or not the ping
failure is caused by the too long link transmission delay.
NOTE
In this command, the parameter -t is used to set the timeout period for waiting for a Response packet from
the destination end. By default, the timeout period is 2000 ms. The parameter -v is used to display
unexpected Response packets; by default, such packets are not displayed.
The ping operation succeeds if a Response packet is received within a specified period, and the
ping operation fails if no Response packet is received within the specified period. Therefore,
you can specify proper values for -t and -v to check whether or not the ping failure is caused by
a long link transmission delay. If ping packet loss occurs because the configured link
transmission delay is shorter than the actual delay, the following information is displayed:
<HUAWEI> ping -v -t 1 10.1.1.1
Request time out
Error: Sequence number = 1 is less than the correct = 2!
If the preceding information is displayed, it indicates that the ping failure occurs because the
configured link transmission delay is shorter than the actual delay. To solve this problem,
increase the value of -t.
If the ping operation can succeed only after -t is increased to a very long value, there is a
possibility that a fault occurs on the device or link. Check the device and link status and clear
the fault.
NOTE
To ping a private network address from a PE, you need to run the ping -vpn-instance vpn-name destination-
address command. The parameter -vpn-instance vpn-name specifies the VPN instance to which the pinged
destination address belongs.
Step 2 Check that there are no incorrect operations.

1. Check whether or not the ping -f command is run. If this command is run, it indicates that
packet fragmentation is not supported. In this case, check whether the MTU of the outbound
interface along the path is smaller than the size of the Ping packet. If the MTU is smaller
than the size of the Ping packet, packet loss will occur, in which case, you need to change
the size of the Ping packet to a value smaller than the MTU. Otherwise, go to Sub-step b.
You can run the following command to view the MTU of an interface:
<HUAWEI> display interface gigabitethernet 0/2/0
GigabitEthernet0/2/0 current state : UP
Line protocol current state : UP
Last line protocol up time: 2008-08-30 10:56:22

Equipment
Description:HUAWEI, GigabitEthernet0/2/0 Interface

Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
2. Check whether or not the ping -i command is run, that is, whether or not an outbound
interface is specified. If a broadcast interface such as an Ethernet interface is specified as
an outbound interface, the destination address to be pinged must be the address of the
directly connected interface. If this condition is not met, you need to specify the directly
connected interface as the outbound interface. If the fault persists, go to Step 3.
NOTE
If -f is specified in a ping command, it indicates that Ping packets do not support packet fragmentation. If
-i interface-name is specified in a ping command, it indicates that interface-name is specified as the
outbound interface of Ping packets and the destination address is used as the next-hop address.
Step 3 Locate the direction in which the fault occurs.
A ping operation involves three roles: the sending device (source end) of Ping packets,
intermediate device, and receiving device (destination end) of the Ping packets. If the ping
operation fails, the fault may occur in the sending or receiving direction of any of the three
devices and therefore you need to locate the direction and node where the fault occurs.
Figure 4-3 Application scenario of a ping operation
Ping packet
Source Intermediate device
Check whether or not the fault occurs in the direction from the source end to the destination end
or in the reverse direction. Stop the ping operation on the source end and destination end, and
run the display icmp statistics command to check ICMP packet transmission. The following
information is displayed:
<HUAWEI> display icmp statistics
Input: bad formats 0 bad checksum 0
echo 36 destination unreachable 9
source quench 0 redirects 43
echo reply 18 parameter problem 0
timestamp 0 information request 0
mask requests 0 mask replies 0
time exceeded 6
Mping request 0 Mping reply 0
Output:echo 20 destination unreachable 71438
timestamp 0 information reply 0
time exceeded 0
NOTE
Run the display icmp statistics command on the source end to view statistics about ICMP packets.
Run the display icmp statistics command on the destination end to view statistics about ICMP packets.

Equipment
l If the number of ICMP packets does not increase, it indicates that the board or the device
does not receive other ICMP packets such as ICMP packets sent from the NMS. Do as follows
to locate the fault.
Perform a ping operation, and run the display icmp statistics command again to view
statistics about ICMP packets.
According to the numbers of sent and received ICMP packets, you can locate the direction
in which the fault occurs:
If the following conditions are all met, it indicates that the source end sends Request
packets but does not receive any Response packet, and the destination end does not receive
the Request packets.
On the source end, the value of the Output:echo field increases normally but the value
of the Input:echo field does not increase.
On the destination end, the numbers of sent and received packets remain unchanged.
In this case, you can determine that the fault occurs in the direction from the source end
to the destination end.
If the following conditions are all met, it indicates that the source end sends Request
packets but does not receive any Response packet, and the destination end receives the
Request packets and sends Response packets.
On the source end, the value of the Output:echo field increases normally but the value
of the Input:echo field does not increase.
On the destination end, the numbers of sent and received packets increase normally.
In this case, you can determine that the fault occurs in the direction from the destination
end to the source end.
After determining the direction in which the fault occurs, go to Step 4.
Step 4 Locate the node where the fault occurs.
Locate the node according to the direction in which the fault occurs.
l If the fault occurs in the direction from the source end to the destination end, do as follows
to locate the node where the fault occurs, starting with the source end.
l If the fault occurs in the direction from the destination end to the source end, do as follows
to locate the node where the fault occurs, starting with the destination end.
Run the tracert dest-ip-address command to find the location where packet loss occurs.
<HUAWEI> tracert 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
1 30.1.1.1 5 ms 4 ms 3 ms
2 89.0.0.2 10 ms 11 ms 8 ms
3 * * *
...
The preceding command output shows that the next hop of the route to 89.0.0.2 (namely, the
node displayed as "3 * * *") becomes faulty. After locating the node where the fault occurs, go
to Step 5.
NOTE
For the tracert to a VPN, run the tracert -vpn-instance vpn-name destination-address command for fault
location. -vpn-instance vpn-name specifies the VPN instance to which the tracerted destination address
belongs.

Equipment
Step 5 Check whether or not a local attack defense policy is configured on the node where the fault
occurs.
If some devices have been attacked by ICMP packets, the rate at which ICMP packets are sent
to the CPU is decreased and excess ICMP packets are dropped to protect against attacks. As a
result, the ping operation fails.
Run the display current-configuration | include cpu-defend command to check whether there
are configurations of a CPU attack defense policy in the configuration file of the device.
l If a CPU attack defense policy is configured, run the display cpu-defend policy policy-
number and display cpu-defend car commands to check the following:
Check whether or not the blacklist that contains the source or destination IP address of
ping packets is configured.
Check whether or not the CAR is configured. If the CAR is configured, check whether
or not Ping packets fail to be processed because the CAR is set to a too small value.
If the blacklist is configured or the CAR is set too small, a ping failure or packet loss occurs.
If the ping operation is still required, delete the blacklist or the CAR and then run a ping
command again. If the ping operation still fails, go to Step 6.
l If no CPU attack defense policy is configured, go to Step 6.
Step 6 Check that FIB entries and ARP entries on the node where the fault occurs are correct.
Run the display fib destination-address command on the node where the fault occurs on check
whether or not there is a route to the destination address. If there is no such route, see 4.3 OSPF
Troubleshooting or 4.4 IS-IS Troubleshooting.
If there is a route to the destination address and Ping packets are transmitted over an Ethernet
link, run the display arp all command to check whether or not the required ARP entry exists.
If the required ARP entry does not exist, go to Step 9. If the fault persists, go to Step 7.
NOTE
For the ping to a VPN, run the display fib vpn-instance vpn-name destination-address command to check
FIB entries. vpn-instance vpn-name specifies the VPN instance to which the pinged destination address
belongs.
Step 7 Check that there are no error packets on interfaces on the node where the fault occurs.
Run the display interface interface-type interface-number command to check packet statistics
on the specified interface.
Check whether or not the value of the CRC field on an Ethernet interface increases after this
display command is run again.
l If the number of error packets or alarms on the specified interface increases, it indicates that
the link or optical module becomes faulty. Clear faults on the link or optical module.
----End

Equipment
Relevant Alarms
None.
Relevant Logs
None.
4.2.2 The Tracert Operation Fails
Common Causes
l Routing entries or ARP entries are incorrect.

l Tracert packets are modified. As a result, these packets are dropped because they fail
validity check at the network layer.
l For security's sake, the peer device does not reply with an error message. An intermediate
device replies with a TTL Timeout message, and the destination device replies with a Port
Unreachable message.
l A network problem, for example, a link fault, causes packet loss.

Equipment
Figure 4-4 Troubleshooting flowchart for a tracert failure
The user cannot tracert

the destination address
No Rectify the Yes

Are FIB and ARP Is fault
entries correct? routing fault rectified?
Yes No
Does the local Yes Contact Huawei

end receive ICMP error technical support
packets? personnel
No
Does the No Yes

Rectify the forwarding Is fault
destination end receive
fault rectified?
Tracert packets?
Yes No
Does the Yes

Rectify the forwarding Yes
destination end reply Is fault
with ICMP error fault rectified?
packets?
No No
Context
NOTE
Procedure
Step 1 Check that FIB entries and ARP entries are correct.
Run the display fib command on each device to check whether there is a route to the destination
address.
l If there is no route to the destination address, see the OSPF Troubleshooting or IS-IS
Troubleshooting.
l If there is a route to the destination address and Tracert packets are transmitted over an
Ethernet link, run the display arp all command to check whether the required ARP entry

Equipment
exists. If the required ARP entry does not exist, go to Step 3. If the fault persists, go to Step
2.
Step 2 Check that the device sending Tracert packets (the source end) does not receive ICMP error
packets.
Run the display icmp statistics command on the source end to check whether or not it receives
ICMP error packets.
<HUAWEI> display icmp statistics
Input: bad formats 0 bad checksum 0
echo 13 destination unreachable 18
timestamp 0 information request 0
time exceeded 12
Output:echo 704 destination unreachable 93326
timestamp 0 information reply 0
time exceeded 0
During the tracert operation, run the display icmp statistics command several times to check
the tracert result. If the increased value of the total number of Destination Unreachable packets
and Time Exceeded packets in the Input field equals the number of sent Tracert packets, it
indicates that the source end receives ICMP error packets but the ICMP error packets are
discarded by the source end. Otherwise, go to Step 3.
----End

None.
4.3 OSPF Troubleshooting
4.3.1 The OSPF Neighbor Relationship Is Down
Common Causes
l The BFD is faulty.

l The other device is faulty.
l CPU usage on the MPU or LPU of the faulty device is too high.

Equipment

l The interface is not Up.
l The IP addresses of the two devices on both ends of the link are on different network
segments.
l The router IDs of the two devices conflict.
l The area types of the two devices are inconsistent.
l The parameter settings of the two devices are inconsistent.
After OSPF is configured on the network, it is found that the OSPF neighbor relationship is
Down. Figure 4-5 shows the troubleshooting flowchart.
Figure 4-5 Troubleshooting flowchart for the fault that the OSPF neighbor relationship is Down
The OSPF neighbor
relationship is Down
Check the logs to find the

reason why neighbor is
Down
Check the
Yes configurations of the Is fault Yes
Neighbor Down
Due to Inactivity devices at both rectified?
ends of the link
No No
Yes Yes
Neighbor Down Check the interface Is fault
Due to Kill Neighbor and BFD rectified?
No
No
Neighbor Down Yes Check the remote Is fault Yes

Due to 1-Wayhello device rectified?
Received
No
No
Neighbor Down Yes Yes

Check the remote Is fault
Due to SequenceNum
device rectified?
Mismatch
No No
Seek technical
support
End

Equipment
Context
NOTE
Saving the results of each troubleshooting step is recommended. If you are unable to correct the fault, you
will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check logs to find the cause of the fault.
Run the display logbuffer command, and you can find the following log information:
NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=
[USHORT], NeighborRouterId=[IPADDR], NeighborAreaId=[ULONG], NeighborInterface=
[STRING],NeighborDownImmediate reason=[STRING], NeighborDownPrimeReason=[STRING],
NeighborChangeTime=[STRING])
Check the NeighborDownImmediate reason field which records the cause of the fault. The
possible causes of the fault are as follows:
l Neighbor Down Due to Inactivity
If a device does not receive a Hello packet from its neighbor within the timeout period, the
OSPF neighbor relationship goes Down. In this case, go to Step 2.
l Neighbor Down Due to Kill Neighbor
If the interface is Down, BFD is Down, or the reset ospf process command is run, the OSPF
neighbor relationship goes Down. In this case, check the NeighborDownPrimeReason field
to determine the specific cause of the fault.
If the value of the NeighborDownPrimeReason field is Physical Interface State Change,
it indicates that the interface status has changed. In this case, run the display interface
[ interface-type [ interface-number ] ] command to check the interface status, and then
troubleshoot the interface fault(Refer to Troubleshooting - Layer 2 Network).
If the value of the NeighborDownPrimeReason field is BFD Session Down, it indicates
that the BFD session status is Down. In this case, troubleshoot the BFD fault (See the
section BFD Session Cannot Go Up ).
If the value of the NeighborDownPrimeReason field is OSPF Process Reset, it indicates
that the reset ospf process command has been run. The OSPF process is restarting. Wait
until OSPF re-establishes the OSPF neighbor relationship.
l Neighbor Down Due to 1-Wayhello Received or Neighbor Down Due to SequenceNum
Mismatch
When the OSPF status on the remote device goes Down first, the remote device sends a 1-
Way Hello packet to the local device, causing OSPF on the local device to go Down. In this
case, troubleshoot the fault that caused OSPF on the remote device to go Down.
l In other cases, go to Step 9.
Step 2 Check that the link between the two devices is normal.
Check whether the link between the two devices is normal, and whether the transmission devices
are normal. For the details, see the section Physical Connection and Interfaces. If the link is
normal, go to Step 3.
Step 3 Check that the CPU usage is within the normal range.
Run the display cpu-usage command to check whether the CPU usage of the faulty device is
higher than 60%. If the CPU usage is too high, OSPF fails to normally send and receive protocol

Equipment
packets, causing the neighbor relationship to flap. In this case, go to Step 9. If the CPU usage
is within the normal range, go to Step 4.
Step 4 Check that the interface status is Up.
Run the display interface [ interface-type [ interface-number ] ] command to check the physical
status of the interface. If the physical status of the interface is Down, troubleshoot the interface
fault (See the section ).
If the physical status of the interface is Up, run the display ospf interface command to check
whether the OSPF status of the interface is Down. The normal status is DR, BDR, DR Other, or
P2P.
<HUAWEI> display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1 0.0.0.0
l If the OSPF status of the interface is Down, run the display ospf cumulative command to
check whether the number of interfaces with OSPF enabled in the OSPF process exceeds
the upper threshold. If so, reduce the number of interfaces with OSPF enabled. For the
details about upper threshold of the interfaces, see the FAF/License file of the product.
<HUAWEI> display ospf cumulative
Cumulations
IO Statistics
Type Input Output
Hello 0 86
DB Description 0 0
Link-State Req 0 0
Link-State Update 0 0
Link-State Ack 0 0
SendPacket Peak-Control: (Disabled)
ASE: (Disabled)
LSAs originated by this router
Router: 1
Network: 0
Sum-Net: 0
Sum-Asbr: 0
External: 0
NSSA: 0
Opq-Link: 0
Opq-Area: 0
Opq-As: 0
LSAs Originated: 1 LSAs Received: 0
Routing Table:
Intra Area: 1 Inter Area: 0 ASE: 0
Up Interface Cumulate: 1
l If the OSPF status of the interface is not Down, go to Step 5.
Step 5 If the interface is connected to a broadcast network or an NBMA network, ensure that the IP
addresses of the two devices are on the same network segment.
l If the IP addresses of the two devices are on different network segments, modify the IP
addresses of the devices to ensure that the IP addresses are on the same network segment.
l If the IP addresses of the two devices are on the same network segment, go to Step 6.
Step 6 Check that the MTUs of the interfaces on both ends are consistent.

Equipment
If the ospf mtu-enable command is run on interfaces on both ends, the MTUs of the two
interfaces must be consistent. If the MTUs are inconsistent, the OSPF neighbor relationship
cannot be established.
l If the MTUs of the two interfaces are inconsistent, run the mtu mtu command in the interface
view to change the MTUs of the two interfaces to be consistent.
l If the MTUs of the two interfaces are consistent, go to Step 7.
Step 7 Check whether there is an interface with a priority that is not 0.
On broadcast and NBMA network segments, there must be at least one interface with a priority
that is not 0 to ensure that the DR can be correctly elected. Otherwise, the OSPF neighbor
relationship can only reach the two-way state.
Run the display ospf interface command to view the interface priority.
Interfaces
1.1.1.1 Broadcast DR 1 1 1.1.1.1 0.0.0.0
Step 8 Ensure that the OSPF configurations on the two devices are correct.
1. Check whether the OSPF router IDs of the two devices are the same.
<HUAWEI> display ospf brief
OSPF Protocol Information
If the IDs are the same, run the ospf router-idrouter-id command to modify the OSPF
router IDs of the two devices. The router ID of each device should be unique within an AS.
If the router IDs are not the same, proceed with this step.
2. Check whether the OSPF area configurations on the two devices are consistent.
Interfaces
10.1.1.1 Broadcast BDR 1 1 10.1.1.2 10.1.1.1
If the OSPF area configurations on the two devices are inconsistent, modify the OSPF Area.
If they are consistent, proceed with this step.
3. Check whether other OSPF configurations on the two devices are consistent.
Run the display ospf error command every 10s for 5 m.
<HUAWEI> display ospf error
OSPF error statistics
General packet errors:
0 : IP: received my own packet 0 : Bad packet
0 : Bad version 0 : Bad checksum
0 : Bad area id 0 : Drop on unnumbered interface
0 : Bad virtual link 0 : Bad authentication type
0 : Bad authentication key 0 : Packet too small
0 : Packet size > ip length 0 : Transmit error
0 : Interface down 0 : Unknown neighbor
HELLO packet errors:
0 : Netmask mismatch 0 : Hello timer mismatch
0 : Dead timer mismatch 0 : Extern option mismatch
0 : Router id confusion 0 : Virtual neighbor unknown
0 : NBMA neighbor unknown 0 : Invalid Source Address

Equipment
l Check the Bad authentication type field. If the value of this field keeps increasing, the
OSPF authentication types of the two devices that establish the neighbor relationship
are inconsistent. In this case, run the area-authentication-mode command to configure
the same authentication type for the two devices.
l Check the Hello timer mismatch field. If the value of this field keeps increasing, the
value of the Hello timers on the two devices that establish the neighbor relationship are
inconsistent. In this case, check the interface configurations of the two devices and run
the ospf timer hello command to set the same value for the Hello timers.
l Check the Dead timer mismatch field. If the value of this field keeps increasing, the
values of the dead timers on the two devices that establish the neighbor relationship are
inconsistent. In this case, check the interface configurations of the two devices and run
the ospf timer dead command to set the same value for the dead timers.
l Check the Extern option mismatch field. If the value of this field keeps increasing,
the area types of the two devices that establish the neighbor relationship are inconsistent
(the area type of one device is common area, and the area type of the other device is
stub area or NSSA). In this case, configure the same area type for the two devices (in
the OSPF area view, the stub command indicates the area type is stub and the stub
command indicates the area type is nssa).
Step 9 Step 9 Contact Huawei technical support personnel and provide them with the following
information.
----End
Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
Relevant Logs
OSPF/4/NBR_DOWN_REASON
4.3.2 The OSPF Neighbor Relationship Cannot Reach the Full State
Common Causes
l The link is faulty and the OSPF packets are dropped.

l The configuration of the dr-priority on the interfaces is incorrect.
l The OSPF MTUs of the local device and its neighbor are different.

Equipment
Figure 4-6 Troubleshoot flowchart for the fault that the OSPF neighbor relationship cannot
reach the Full state
The OSPF
relationship cannot
enter the Full state.
Check the status of the

OSPF neighbor relationship.
See "OSPF
Can the status of the No Neighbor Yes
Is fault
neighbor relationship be Relationship Is
rectified?
displayed? Down" to rectify the
fault.
Yes No
Is the neighbor Yes Yes

Check the interface Is fault
relationship always in status. rectified?
the Down state?
No
No
Is the neighbor Yes Check the remote Is fault Yes

relationship always in device and the link. rectified?
the Init state?
No
No

Check the interface Is fault
relationship always in
configured. rectified?
the 2-Way state?
No

Perform the ping Is fault
relationship always in
operation. rectified?
the Exstart state?
No
No

relationship always in Perform the ping Is fault
the Exchange operation. rectified?
state?
No
No
Seek technical
support
End

Equipment
Context
NOTE
Procedure
Step 1 Troubleshoot the fault based on the status of the OSPF neighbor relationship.
l The status of the OSPF neighbor relationship cannot be displayed.
If the status of the OSPF neighbor relationship cannot be displayed, see The OSPF Neighbor
Relationship Is Down to rectify the fault.
l The neighbor relationship is always in the Down state.
Run the display interface [ interface-type [ interface-number ] ] command to check the
physical status of the interface. If the physical status of the interface is Down, troubleshoot
the interface fault.
If the physical status of the interface is Up, run the display ospf interface command to check
whether the OSPF status of the interface is Up (such as DR, BDR, DR Other, or P2P).
Interfaces
192.168.1.1 Broadcast DR 1 1 192.168.1.1 0.0.0.0
If the OSPF status of the interface is Up, go to Step 2.

If the OSPF status of the interface is Down, run the display ospf cumulative command
to check whether the number of interfaces with OSPF enabled in the OSPF process
exceeds the upper threshold. If so, reduce the number of interfaces with OSPF enabled.
<HUAWEI> display ospf cumulative
Cumulations
IO Statistics
Type Input Output
Hello 0 86
DB Description 0 0
Link-State Req 0 0
Link-State Update 0 0
Link-State Ack 0 0
SendPacket Peak-Control: (Disabled)
ASE: (Disabled)
LSAs originated by this router
Router: 1
Network: 0
Sum-Net: 0
Sum-Asbr: 0
External: 0
NSSA: 0
Opq-Link: 0
Opq-Area: 0
Opq-As: 0
LSAs Originated: 1 LSAs Received: 0
Routing Table:
Intra Area: 1 Inter Area: 0 ASE: 0
Up Interface Cumulate: 1

Equipment
l The neighbor relationship is always in the Init state.

If the status of the neighbor relationship is always displayed as Init, the remote device cannot
receive Hello packets from the local device. In this case, check whether the link or the remote
device is faulty.
l The neighbor relationship is always in the 2-way state.
If the status of the neighbor relationship is always displayed as 2-way, run the display ospf
interface command to check whether the DR priorities of the interfaces with OSPF enabled
are 0.
Interfaces

1.1.1.1 Broadcast DROther 1 0 1.1.1.2 . 0.0.0.0
If the DR priorities of the interfaces with OSPF enabled are 0 and the state is
DROther, both the local device and its neighbor are not the DR or BDR and they do not
need to exchange LSAs. In this case, no action is required.
If the DR priorities of the interfaces enabled with OSPF are not 0, go to Step 2.
l The neighbor relationship is always in the Exstart state.
If the status of the neighbor relationship is always displayed as Exstart, it indicates that the
devices are exchanging DD packets but fail to synchronize LSDBs, which occurs in the
following cases:
Packets that are too long cannot be normally sent and received.
Run the ping -s 1500 neighbor-address command to check the sending and receiving of
packets that are too long. If the two devices fail to ping each other, solve the link problem
first.
The OSPF MTUs of the two devices are different.
If the ospf mtu-enable command is run on the OSPF interfaces, check whether the OSPF
MTUs on the two interfaces are the same. If they are not the same, change the MTUs of
the interfaces to ensure that the MTUs of the interfaces are the same.
l The neighbor relationship is always in the Exchange state.
If the status of the neighbor relationship is always displayed as Exchange, the two devices
are exchanging DD packets. In this case, follow the troubleshooting procedure provided for
when the neighbor relationship is in the Init state. If the fault persists, go to Step 2.
l The neighbor relationship is always in the Loading state.
NOTICE
Restarting OSPF causes the re-establishment of all neighbor relationships in the OSPF
process and the temporary interruption of services.
If the neighbor relationship is always in the Loading state, run the reset ospf process-id
process command to restart the OSPF process.

Equipment
Step 2 Step 2 Collect the following information and contact Huawei technical support personnel.
----End
Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket
OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange
Relevant Logs
None.
4.3.3 Related Troubleshooting Cases
The OSPF Neighbor Relationship Cannot Be Established Between Two Devices

Because the Link Between the Devices Is Faulty
Fault Symptom
In the networking shown in Figure 4-7, the OSPF neighbor relationship cannot be established
between ATN A and its neighbor, and the neighbor is in the Exchange state.
Figure 4-7 Network diagram of the networking where the neighbor relationship cannot be
established between two devices
10.1.1.0
ATN A ATN B
Fault Analysis
The possible causes are as follows:
l The OSPF configurations are improper.

l Parameters of the two devices are incorrectly set.
l The OSPF packets are lost.

Equipment
Check the configuration of ATN A and find that ATN A is correctly configured.
Check the OSPF parameters on the corresponding interfaces and find that the OSPF parameters
on the interfaces are set correctly.
Run the related debugging command on ATN B and find that MTU negotiation fails.
The MTUs on the two devices are 4470. The debugging ospf packet dd command, however,
shows that the MTU contained in the packet received by ATN B is 0, which indicates that the
MTU is not set on the peer device. It is concluded that the link is not working normally.
Run the following command on ATN A to ping the peer device. Packet loss occurs.
<ATNA> ping 10.1.1.0
Request time out
Reply from 10.1.1.0: bytes=56 Sequence=2 ttl=255 time=5 ms
Request time out
--- 10.1.1.0 ping statistics ---
40.00% packet loss
Ensure that the link between intermediate transmission devices is normal. Collect traffic statistics
from ATN A. It is found that packet loss does not occur on ATN A. Therefore, packet loss may
be occurring on the board of the peer device or on the link.
Collect traffic statistics on the peer device. It is found that packet loss occurs on the board on
ATN B because the board is faulty
Procedure
Step 1 Replace the faulty board on ATN B.
----End
Summary
Sometimes, OSPF packets are not received. In this case, check connectivity at the link layer first.
Enable OSPF debugging with the commands such as the debugging ospf packet and debugging
ospf event commands to locate the fault, or run the display ospf error command to view the
various OSPF error statistics. If the OSPF configuration is correct, run the debugging ip
packet command to check whether packets are successfully forwarded at the IP layer.
4.4 IS-IS Troubleshooting
4.4.1 The IS-IS Neighbor Relationship Cannot Be Established
Common Causes

Equipment
l IS-IS cannot normally send or receive Hello packets due to a device fault or a link fault.
l The devices at both ends of the link are configured with the same system ID.
l The MTUs configured on the interfaces at both ends of the link are different or the MTU
of an interface is smaller than the length of a Hello packet to be sent.
l The IP addresses of the two interfaces at both ends of the link are on different network
segments.
l The authentication configurations on the IS-IS interfaces at both ends of the link are
inconsistent.
l The IS-IS levels of the interfaces at both ends of the link are inconsistent.
l The area addresses of the devices at both ends of the link are inconsistent when the devices
establish the IS-IS Level-1 neighbor relationship.
Figure 4-8 Flowchart for troubleshooting the fault that the IS-IS neighbor relationship cannot
be established
The IS-IS neighbor
relationship cannot
be normally
established.
Is the No Check the MTU and Yes

IS-IS status of the Is fault
link status of the
interface Up? rectified?
interface.
Yes No
Are Hello packets No Check where the Is fault Yes

normally sent and packets are lost. rectified?
received?
Yes No
Is local
No Yes
IS-IS parameters are Modify the IS-IS Is fault
matched with the parameters. rectified?
neighbor's?
No
Yes
Seek technical
support.
End

Equipment
NOTE
Procedure
Step 1 Check the status of IS-IS interfaces.
Run the display isis interface command to check the state of interfaces enabled with IS-IS (the
value of the IPv4.State item).
l If the state is Mtu:Up/Lnk:Dn/IP:Dn, go to Step 2.

l If the state is Mtu:Dn/Lnk:Up/IP:Up, run the display current-configuration interface
interface-type [ interface-number ] command to check the MTUs on the interfaces. Run
the display current-configuration configuration isis command to check the lengths of
LSPs in an IS-IS process.
NOTE
If the lengths of LSPs cannot be viewed by using the display current-configuration

configuration isis command, the default LSP lengths are used. The default LSP lengths can be viewed
by using the display default-parameter isis command. The value of the LSP-Originate-Length
field is the maximum length of a originated LSP, and the value of the LSP-Receive-Length field is
the maximum length of a received LSP.
On a P2P interface, the LSP length should not be greater than the MTU on the P2P interface.
On a broadcast interface, the value obtained by the MTU on the interface subtracted by the
LSP length should be equal to or greater than 3. If the condition is not met, run the lsp-
length command in the IS-IS view to change the LSP length, or run the mtu command in
the interface view to change the MTU.
If the fault is still not rectified, go to Step 4.
l If the state is Down, run the display current-configuration configuration isis command
to check the configuration of the IS-IS process. Check whether the NET is configured in
the IS-IS process. If not, configure the network-entity command in the IS-IS process.
l If the state is Up, go to Step 4.
Run the display ip interface [ interface-type [ interface-number ] ] command to check the status
of specified interfaces.
l If the interface link status (Line protocol current state field in the output information ) is
not Up, troubleshoot the interface fault. See the section "Physical Connection and
Interfaces" or "L2 Network".
l If the interface status is Up, go to Step 3.
Step 3 Check that the IP addresses of the two interfaces at both ends of the link are on the same network
segment.
l If the IP addresses of the two interfaces are on different network segments, change the IP
addresses of the two interfaces to ensure that the two IP addresses are on the same network
segment. If the fault is still not rectified, go to Step 4.

Equipment
l If the IP addresses of the two interfaces are on the same network segment, go to Step 4.
Step 4 Check that IS-IS can normally receive and send Hello packets.
Run the display isis statistics packet [ interface interface-type interface-number ] command
to check whether IS-IS can normally receive and send Hello packets.
NOTE
The default interval at which IS-IS sends Hello packets is 10s. Therefore, run this command every 10s to
check whether the packet statistics increase (L1 IIH or L2 IIH).
On a broadcast interface, Hello packets have IS-IS levels, and therefore you can view the statistics about
Hello packets based on the levels of established neighbor relationships. On a P2P interface, Hello packets
have no IS-IS levels and are recorded as L2 IIH packets.
l If the number of received Hello packets does not increase for a certain period, check whether
the IS-IS packets are lost.
For Broadcast interface, run the debugging ethernet packet isis interface-type
interface-number command. The following information indicates the interface can
normally receive and send IS-IS Hello packets.
Jun 30 2023 20:05:30.260.1 HUAWEI ETH/7/eth_rcv:Receive an Eth Packet,
interface : Ethernet0/2/0, eth format: 3, length: 60, protoctype: 8000 isis,
src_eth_addr: 00e0-fc37-08c1, dst_eth_addr: 0180-c200-0015, SysUptime :
(0,33206263)
Jun 30 2023 20:05:30.260.1 HUAWEI ETH/7/eth_send:Send an Eth Packet,
interface : Ethernet0/2/0, eth format: 3, length: 112, protoctype: 8000
isis, src_eth_addr: 00e0-fc26-f9d9, dst_eth_addr : 0180-c200-0015
For P2P interface, run the debugging ppp osi-npdu packet interface-type interface-
number command. The following information indicates the interface can normally
receive and send IS-IS Hello packets.
Jun 30 2023 20:04:08.880.1 HUAWEI PPP7/debug2:
PPP Packet:
Mp-group0/2/1 Output OSI-NPDU(0023) Pkt, Len 1004
Jun 30 2023 20:04:08.880.1 HUAWEI PPP7/debug2:
PPP Packet:
Mp-group0/2/1 Input OSI-NPDU(0023) Pkt, Len 1501
NOTE
If the DIS field shown in the output of the display isis interface interface-type interface-
numbercommand is "--", it indicates the interface type is P2P. Otherwise, the interface type is
Broadcast.
If the device can not normally receive and send Hello packets, go to Step 9.
l If the device can normally receive Hello packets, go to Step 5.
If the interfaces at both ends of the link are trunk interfaces, check whether the numbers
of the member interfaces in the Up state in the trunk interfaces are the same. If numbers
of the member interfaces in the Up state in the trunk interfaces are different, add the
required physical interfaces to the Trunk interface correctly. Otherwise, go to Step 2
If the interfaces at both ends of the link are not trunk interfaces, go to Step 2.
Step 5 Check that the devices at both ends of the link are configured with different system IDs.
Run the display current-configuration configuration isis command to check whether the
system IDs of the two devices are the same.
l If the system IDs of the two devices are the same, set different system IDs for the two
devices.
l If the system IDs of the two devices are different, go to Step 6.

Equipment
Step 6 Check that the IS-IS levels of the two devices at both ends of the link match.
Run the display current-configuration configuration isis | include is-level command to check
the levels of the IS-IS processes on the two devices. Then, run the display current-
configuration interface interface-type interface-number | include isis circuit-level command
to check whether the IS-IS levels of the interfaces at both ends of the link match. The IS-IS
neighbor relationship can be established only when the IS-IS levels of the two interfaces match.
NOTE
If the IS-IS levels of the two interfaces cannot be viewed by using the display current-configuration
interface interface-type interface-number | include isis circuit-level command, the two interfaces use the
default IS-IS level. The default IS-IS level can be viewed by using the display default-parameter isis
command. The value of the Circuit-Level field is the default IS-IS level.
The matching rules of interface levels are as follows:
l If the level of the local interface is Level-1, the level of the remote interface must be Level-1 or
Level-1-2.
l If the level of the local interface is Level-2, the level of the remote interface must be Level-2 or
Level-1-2.
l If the level of the local interface is Level-1-2, the level of the remote interface can be Level-1,
Level-2, or Level-1-2.
l If the IS-IS levels of the two devices do not match, run the is-level command in the IS-IS
view to set matching IS-IS levels for the two devices, or run the isis circuit-level command
in the interface view to change the levels of related interfaces.
l If the IS-IS levels of the two devices match, go to Step 7.
Step 7 Check that the area addresses of the two devices at both ends of the link are the same.
When the area addresses of the two devices are different, the alarm ISIS_1.3.6.1.3.37.2.0.12
isisAreaMismatch is generated.
NOTE
If two devices at both ends of a link establish a Level-1 neighbor relationship, ensure that the two devices
are in the same area.
An IS-IS process can be configured with a maximum of three area addresses. As long as one of the area
addresses of the local IS-IS process is the same as one of the area addresses of the remote IS-IS process,
the Level-1 neighbor relationship can be established.
When the IS-IS Level-2 neighbor relationship is established between two devices, you do not need to
determine whether the area addresses of the two devices match.
l If the area addresses of the two devices are different, run the network-entity command in
the IS-IS view to set the same area address for the two devices.
l If the area addresses of the two devices at both ends of the link are the same, go to Step
8.
Step 8 Check that the authentication configurations of the two devices at both ends of the link are the
same.
If the authentication types of the two devices are different, the alarm ISIS_1.3.6.1.3.37.2.0.9
isisAuthenticationTypeFailure or the alarm ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure
is generated.
Run the display current-configuration interface interface-type interface-number | include isis

authentication-mode command to check whether the IS-IS authentication configurations of the
two interfaces at both ends of the link are the same.

Equipment
l If the authentication types on the two interfaces are different, run the isis authentication-
mode command in the view of each of the two interfaces to set the same authentication
type for the two interfaces.
l If the authentication passwords on the two interfaces are different, run the isis
authentication-mode command in the view of each of the two interfaces to set the same
authentication password for the two interfaces.
l If the authentication configurations of the two devices are the same, go to Step 9.
----End
Relevant Alarms
ISIS_1.3.6.1.3.37.2.0.12 isisAreaMismatch
ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure
ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure
Relevant Logs
None.
4.4.2 A Device Fails to Learn Specified IS-IS Routes from Its

Neighbor
Common Causes
l Another routing protocol whose priority is higher than that of IS-IS advertises the same
routes as those advertised by IS-IS.
l The preferences of the imported external routes are low, and therefore the imported external
routes are not preferred.
l The IS-IS cost styles of the two devices are inconsistent.
l The IS-IS neighbor relationship is not normally established between the two devices.
l The two devices are configured with the same system ID.
l The authentication configurations of the two devices are inconsistent.
l LSP loss occurs due to a device fault or a link fault.

Equipment
After IS-IS is configured on the network, it is found that the device cannot learn specified IS-IS
routes from its neighbor.

l Check whether another protocol also learns specified routes.
l Check whether IS-IS calculates routes.
l Check whether IS-IS LSDBs are synchronized.
l Check whether the IS-IS configuration is correct.
Figure 4-9 Troubleshooting flowchart when device cannot learn IS-IS routes
A device fails to
learn specified
routes from its
neighbor.
Do specified Check whether

No another routing Is fault Yes
routes exist in the IS-IS
routing table? protocol advertise rectified?
the same routes.
No
Yes
Seek
technical
support.
Check the IS-IS

No configuration of the Yes
Are the specified Is fault
device that
routes advertised? rectified?
advertises the
routes.
No
Yes
No Yes
Are IS-IS LSDBs Check the IS-IS Is fault
synchronized? configuration. rectified?
Yes
No
Ensure that cost
No styles of the Yes
Are IS-IS cost styles Is fault
interfaces on both
consistent? rectified?
ends of the link are
consistent.
No
Yes
Troubleshoot the
Is the IS-IS fault of the IS-IS
No Is fault Yes
neighbor relationship neighbor
normally established? rectified?
relationship fails to
be established.
No
Yes
Seek technical
support. End

Equipment
Context
NOTE
Procedure
Step 1 Check that the IS-IS routing table of the device that fails to learn specified routes is correct.
Run the display isis route command to view the IS-IS routing table.
l If the specified routes exist in the IS-IS routing table, run the display ip routing-table ip-
address [ mask | mask-length ] verbose command to check whether routes advertised by a
routing protocol whose priority is higher than that of IS-IS exist in the routing table.
NOTE
If the value of the State field of a route is Active Adv, it indicates that the route is an active route.
If there are multiple routes that have the same prefix but are advertised by different routing protocols,
the route advertised by the routing protocol with the highest priority is preferred as the active route.
If there are such routes in the routing table, adjust the configuration based on the network
planning.
If there is no such routes in the routing table, go to Step 6.
l If there is no specified route in the IS-IS routing table, go to Step 2.
Step 2 Check that the specified IS-IS routes are advertised.
On the device that advertises specified routes, run the display isis lsdb local verbose command
to check whether LSPs generated by the device carry the specified routes.
l If the LSPs do not carry the specified routes, check whether the configurations of the device
are correct, for example, whether IS-IS is enabled on associated interfaces.
NOTE
If the specified routes are imported external routes, run the display ip routing-table protocol
protocol verbose command to check whether the external routes are active routes.
l If the LSPs carry the specified routes, go to Step 3.
Step 3 Check that IS-IS LSDBs are synchronized.
On the device that fails to learn specified IS-IS routes, run the display isis lsdb command to
check whether the device learns LSPs from the device that advertises specified routes.
NOTE
LSPID identifies an LSP, and Seq Num is the sequence number of an LSP. The greater the sequence
number, the newer the LSP.
l If the LSDB of the device that fails to learn specified IS-IS routes does not have specified
LSPs, do as follows as required:

Equipment
If the alarm ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure or the alarm

ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure is generated, it indicates that the
authentication types or authentication passwords of the device that fails to learn
specified routes and the device that advertises the specified routes are inconsistent. In
this case, set the same authentication type and authentication password for the two
devices.
If the alarm ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure or
ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure is not generated, check whether
devices or intermediate links are faulty.
l If the LSDB of the device that fails to learn specified IS-IS routes contains specified LSPs,
but the Seq Num fields of the LSPs are different with the fields of the display isis lsdb
local verbose command, and the values of the Seq Num fields keep increasing, it indicates
that there is another device configured with the same system ID as the device that advertises
specified routes on the network. In this case, the alarm ISIS_1.3.6.1.3.37.2.0.8
isisSequenceNumberSkip is generated, and you need to check the IS-IS configurations on
the devices on the network.
l If the LSDB of the device that fails to learn specified IS-IS routes contains specified LSPs,
but the Seq Num fields of the LSPs are inconsistent and the values of the Seq Num fields
keep unchanged, it indicates that the LSPs may be discarded during transmission. In this
case, you need to check whether devices or intermediate links are faulty.
l If the LSDB of the device that fails to learn specified IS-IS routes contains specified LSPs
and the Seq Num fields of the LSPs are consistent, go to Step 4.
Step 4 Check whether the IS-IS cost styles of the two devices are consistent.
Run the display current-configuration configuration isis command on the device that
advertises specified routes and the device that fails to learn specified IS-IS routes respectively
to check whether the IS-IS cost styles (the cost-style command) of the two devices are consistent.
NOTE
Two devices can learn routes from each other only when the IS-IS cost styles of the two devices match.
The IS-IS cost styles are classified as follows:
l narrow: indicates that the packets with the cost style being narrow can be received and sent.
l narrow-compatible: indicates that the packets with the cost style being narrow or wide can be received
but only the packets with the cost style being narrow can be sent.
l compatible: indicates that the packets with the cost style being narrow or wide can be received and
sent.
l wide-compatible: indicates that the packets with the cost style being narrow or wide can be received
but only the packets with the cost style being wide can be sent.
l wide: indicates that the packets with the cost style being wide can be received and sent.
If the cost style of one device is narrow and the cost style of the other device is wide or wide-compatible,
or the cost style of one device is narrow-compatible and the cost style of the other device is wide, the two
devices cannot interwork.
l If the IS-IS cost styles on the two devices are inconsistent, run the cost-style command to
set the same IS-IS cost style for the two devices.
l If the IS-IS cost styles on the two devices are consistent, go to Step 5.
Step 5 Check that the IS-IS neighbor relationship is normally established.

Run the display isis peer command on every device on the path to check whether the IS-IS
neighbor relationships are normally established.

Equipment
l If the State field is not Up, troubleshoot the fault The IS-IS Neighbor Relationship
Cannot Be Established.
l If the State field is Up, go to Step 6.
----End
Relevant Alarms
ISIS_1.3.6.1.3.37.2.0.8 isisSequenceNumberSkip
ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure
ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure
Relevant Logs
None.
4.4.3 The IS-IS Neighbor Relationship Flaps
Common Causes
l Packet loss occurs because the link is unstable or devices work abnormally.
l The member interfaces of the trunk interface are incorrectly connected.
After IS-IS is configured on the network, it is found that the IS-IS neighbor relationship flaps.

Equipment
Figure 4-10 Troubleshooting flowchart when IS-IS neighbors flap
The IS-IS
neighbor
relationship flaps
Check log information

to identify the change
type of the IS-IS
neighbor relationship
Neighbor
Check the local Yes
relationship is Is fault
device and the
Down because the rectified?
intermediate link
Hold timer expires
No
Status of neighbor
Check the local Yes
relationship Is fault
device and the
changes between rectified?
intermediate link
Up and Init
No
Status of neighbor Check that member

relationship is interfaces of the Is fault Yes
MULTIPLE_P2P_ trunk interface are rectified?
ADJ correctly connected
No
Seek technical
In other case
support End
Context
NOTE
Procedure
Step 1 Check the change type of the IS-IS neighbor relationship.
When the IS-IS neighbor relationship changes, the alarm ISIS_1.3.6.1.3.37.2.0.17

isisAdjacencyChange and the log ISIS/4/ADJ_CHANGE_LEVEL are generated.
NOTE
The log ISIS/4/ADJ_CHANGE_LEVEL is recorded only when the log-peer-change command is run in
the IS-IS process.

Equipment
l If the log-peer-change command is run in the IS-IS process, you can view the value of the
ChangeType field in the log information.
If the value of the ChangeType field is HOLDTIMER_EXPIRED, it indicates that the
local device cannot normally receive Hello packets from its neighbor. In this case, you
need to check whether packet loss occurs because the local device or the intermediate
link is faulty.
If the value of the ChangeType field changes between 3_WAY_INIT and 3_WAY_UP
(for P2P interfaces) or is NEW_L1_ADJ or NEW_L2_ADJ (for broadcast interfaces),
it indicates that the status of the neighbor relationship changes between Up and Init.
This is because the remote device cannot normally receive Hello packets from the local
device. In this case, check whether packet loss occurs because the intermediate link or
the remote device is faulty.
In other cases, go to Step 2.
l If the log-peer-change command is not run, run the display isis peer command
consecutively, and then view the values of the State and HoldTime fields to identifies the
change type of the IS-IS neighbor relationship.
When the neighbor relationship flaps, if the value of the State field keeps unchanged,
the value of the HoldTime field keeps decreasing, and the neighbor relationship is
deleted after the value of the HoldTime field decreases to 0, it indicates that the local
device cannot normally receive Hello packets from the remote device. In this case, you
need to check whether packet loss occurs because the intermediate link or the local
device is faulty.
When the neighbor relationship flaps, if the value of the State field changes between
Up and Init, it indicates that the remote device cannot normally receive Hello packets
from the local device. In this case, you need to check whether packet loss occurs because
the intermediate link or the remote device is faulty.
In other cases, go to Step 2.
----End
Relevant Alarms
ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange
Relevant Logs
ISIS/4/ADJ_CHANGE_LEVEL
4.4.4 IS-IS Routes Flap
Common Causes

Equipment
l The IS-IS neighbor relationship flaps.

l The MPLS LSP flaps.
l The two devices import the same external routes to IS-IS, and the preferences of the
imported external routes are lower than those of IS-IS routes.
l The two devices are configured with the same system ID.
After IS-IS is configured on the network, it is found that IS-IS routes flap.
Figure 4-11 Troubleshooting flowchart when IS-IS routes flap
IS-IS routes flap
Check the routing table

and identify the
changed attributes of
routes
The outbound Ensure that the IS-IS Yes

Is fault
interface or cost of neighbor relationship
rectified?
the route changes does not flap
No
Ensure that the Yes

The tunnel ID of the Is fault
MPLS LSP does not
route changes rectified?
flap
No
Ensure that external
A specified route
routes do not flap Yes
appears Is fault
and that the IS-IS
intermittently in rectified?
configuration is
the routing table
correct
No
Seek technical
Other cases
support End

Equipment
Context
NOTE
Procedure
Step 1 Check the details about route flapping.
Run the display ip routing-table ip-address verbose command to check the details about route
flapping, such as, the routing protocol from which active routes are learned and the changed
attributes of routes during route flapping.
l If the Cost or Interface field of a route changes, check whether the IS-IS neighbor
relationship established between devices on the path flaps. If so, see The IS-IS Neighbor
Relationship Flaps to rectify the fault.
l If a route appears intermittently in the routing table (the value of the Age field changes),
run the display isis lsdb verbose command to identify the LSP that carries the route. Then,
run the display isislsdb lsp-id verbose command to check the updates of the LSP.
If the LSP always carries the specified route, check whether the IS-IS neighbor
relationship established between devices on the path flaps. If so, see The IS-IS
Neighbor Relationship Flaps to rectify the fault.
If the value of the Seq Num field of the LSP constantly increases, check whether the
two devices are configured with the same system ID.
If the value of the Seq Num field of the LSP constantly increases and the route appears
intermittently before and after the LSP is updated, perform Step 2 on the device that
generates the LSP.
NOTE
In the output of the display isis lsdblsp-id verbose command, the IP-Internal field or the +IP-
Internal field indicates the IP address of the device that generates the LSP.
l If the value of the Protocol field of the route changes, go to Step 2.
Step 2 Check the external routes imported by IS-IS.

If specified routes are external routes imported by IS-IS, run the display ip routing-table ip-
address verbose command on the device where IS-IS imports the external routes to view details
about route flapping.
l The active routes in the routing table are IS-IS routes rather than external routes to be
imported by IS-IS, it indicates that other IS-IS devices advertise the same routes. In this
case, you need to modify the priorities of routing protocols based on network planning, or
configure a route filtering policy in the IS-IS view to control the routes to be added to the
IP routing table.
l In other cases, go to Step 3.
----End

Equipment
Relevant Alarms
None.
Relevant Logs
None.
4.5 BGP Troubleshooting
4.5.1 The BGP Peer Relationship Fails to Be Established
Common Causes
The BGP peer relationship fails to be established if the BGP peer relationship cannot enter the
Established state.
l BGP packets fail to be forwarded.

l An ACL is configured to filter packets with the destination port TCP port 179.
l The peer router ID conflicts with the local router ID.
l The peer AS number is incorrect.
l Loopback interfaces are used to establish the BGP peer relationship, but the peer connect-
interface command is not configured.
l Loopback interfaces are used to establish the EBGP peer relationship, but the peer ebgp-
max-hop command is not configured.
l The number of routes sent by the peer exceeds the upper limit that is specified by the peer
route-limit command.
l The peer ignore command is configured on the peer.
l The address families of devices on both ends are inconsistent.
The BGP peer relationship fails to be established after the BGP protocol is configured.

Equipment
Figure 4-12 Troubleshooting flowchart for the failure to establish the BGP peer relationship
The BGP peer relationship fails to

be established
Check the routes

Can the ping operation No used to establish Yes
Is fault rectified?
succeed? the BGP peer
relationship
No
Yes
Is there an
ACL configured whose Yes Delete the Yes
Is fault rectified?
destination port is The configuration
TCP port 179?
No No
Yes
Does the peer Yes Change the two
router ID conflict with the loca router IDs to Is fault rectified?
l router ID? different values
No No
Change the AS Yes

Whether the Yes number of the
displayed peer AS number is Is fault rectified?
remote peer to be
configured correctly?
correct
No No
Does BGP Yes

configurations affect the Yes Modify the BGP
Is fault rectified?
establishment of the BGP peer configurations
relationship?
No No

Equipment
Context
NOTE
Procedure
Step 1 Run the ping command to check whether BGP peers can successfully ping each other.
l If BGP peers can successfully ping each other, there are available routes between BGP
peers and link transmission is normal. In this case, go to Step 2.
NOTE
Run the ping -a source-ip-address -s packetsize host command to detect the connectivity of devices
on both ends. Because the source address is specified in this command, it is possible to check whether
the two devices have available routes to each other. Check whether large Ping packets can be normally
transmitted over the link by specifying the size of the Ping packet.
l If the ping operation fails, check whether the two devices have routes to each other in
routing table of each device.
If there are no routes to the peer, check the associated routing protocol configurations.
For details, see the section The Ping Operation Fails.
If there are routes to the peer, contact Huawei technical support personnel.
Step 2 Check that no ACL is configured to filter the packets with the destination port TCP port 179.
Run the display acl all command on the two devices to check whether an ACL is configured to
filter the packets with the destination port TCP port 179.
<HUAWEI> display acl all
Total nonempty ACL number is 1
Advanced ACL 3001, 2 rules

Acl's step is 5
rule 5 deny tcp source-port eq bgp
rule 10 deny tcp destination-port eq bgp
l If an ACL is configured to filter the packets with the destination port TCP port 179, run
the undo rule rule-id destination-port command and the undo rule rule-id source-port
command in the Advanced ACL view to delete the configuration.
l If no ACL is configured to filter the packets with the destination port TCP port 179, go to
Step 3.
Step 3 Check that the peer router ID does not conflict with the local router ID.
View information about BGP peers to check whether the peer and local router IDs conflict. For
example, if the IPv4 unicast peer relationship fails to be established, run the display bgp peer
command to check whether the peer router ID conflicts with the local router ID. In the following
example command output, the local router ID is 223.5.0.109.
<HUAWEI> display bgp peer
BGP local router ID : 223.5.0.109
Local AS number : 41976
Total number of peers : 12 Peers in established state : 4
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
8.9.0.8 4 100 1601 1443 0 23:21:56 Established

Equipment
10000
9.10.0.10 4 200 1565 1799 0 23:15:30 Established 9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, run the display bgp vpnv4 all peer command.
l If the peer router ID conflicts with the local router ID, run the router id command in the
BGP view to change the two router IDs to different values. Generally, a loopback interface
address is used as the local router ID.
l If the peer router ID does not conflict with the local router ID, go to Step 4.
Step 4 Check that the peer AS number is configured correctly.
Run the display bgp peer command on each device to check whether the displayed peer AS
number is the same as the remote AS number.
<HUAWEI> display bgp peer
Total number of peers : 12 Peers in established state : 4
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
8.9.0.8 4 100 1601 1443 0 23:21:56 Established
10000
9.10.0.10 4 200 1565 1799 0 23:15:30 Established 9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, you can run the display bgp vpnv4 all peer command.
l If the peer AS number is incorrectly configured, change it to be the same as the remote AS
number.
l If the peer AS number is configured correctly, go to Step 5.
Step 5 Check whether BGP configurations affect the establishment of the BGP peer relationship.
Run the display current-configuration configuration bgp command to check BGP

configurations.
Item Description
peer connect-interface interface-type If two devices use loopback interfaces to establish

interface-number the BGP peer relationship, run the peer connect-
interface command to specify the associated
loopback interface as the source interface that
sends BGP packets.

Equipment
Item Description
peer ebgp-max-hop hop-count When two directly connected devices use loopback
interfaces to establish the EBGP peer relationship
or two indirectly connected devices establish the
EBGP peer relationship, run the peer ebgp-max-
hop command and specify the maximum number
of hops between the two devices.
l When two directly connected devices use
loopback interfaces to establish the EBGP peer
relationship, the hop count can be any number
greater than 1.
l When two indirectly connected devices
establish the EBGP peer relationship, specify
the number of hops based on the actual
situation.
peer route-limit limit If the peer route-limit limit command is

configured, check whether the number of routes
sent by the peer exceeds the upper limit that is
specified by limit. If the number of hops exceeds
the upper limit, reduce the number of routes to be
sent by the peer, and run the reset bgp ip-address
command to reset the BGP peer relationship and
trigger the re-establishment of the BGP peer
relationship.
peer ignore If the peer ignore command is configured on the

peer, the peer is not required to establish the BGP
peer relationship with the local device temporarily.
To establish the BGP peer relationship between the
peer and the local device, run the undo peer
ignore command on the peer.
Address family capability Check whether the address family capabilities of

devices on both ends match. For example, in order
to establish a BGP VPNv4 peer relationship, the
peer enable command must be configured in the
BGP-VPNv4 address families of both devices. If
the peer enable command is configured on only
one device, the BGP peer relationship on the other
device is displayed as No neg.
Step 6 Contact Huawei technical support personnel and provide them with the following information.
----End

Equipment
Relevant Alarms
BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition
Relevant Logs
BGP/3/STATE_CHG_UPDOWN
4.5.2 BGP Public Network Traffic Is Interrupted
Common Causes
This troubleshooting case describes how to clear the fault that traffic to be transmitted through
BGP public network routes is interrupted when the BGP peer relationship is normal.
l Routes are inactive because the next hops are unreachable.

l Routes fail to be advertised or received because routing policies are incorrectly configured.
l The received routes are dropped because there is an upper limit on the number of routes on
the device.
BGP public network traffic is interrupted after the BGP protocol is configured.

Equipment
Figure 4-13 Troubleshooting flowchart for interruption of BGP public network traffic
The BGP public network

traffic is interrupted
Is the next hop of the No Ensure that the next Yes

Is faulty rectified?
route reachable? hop is reachable
Yes No
No Yes
Is the routing policy Correctly configure the
Is faulty rectified?
configured correctly? routing policy
No
Yes
Does the Yes Yes

Reduce the number of
number of routes exceed Is faulty rectified?
routes
the upper limit?
No No
Context
NOTE
Procedure
Step 1 Verify that the next hops for the routes are reachable.
Run the display bgp routing-table network { mask | mask-length } command on the device that
sends routes (that is, the local device) to check whether the target route is active and whether it
has been sent to the peer. network specifies the prefix of the target route.
Assume that the target route is a route to 13.0.0.0/8. The following command output shows that
this route is valid and has been selected and sent to the peer at 3.3.3.3; the original next hop and
iterated next hop of this route are 1.1.1.1 and 172.1.1.1 respectively.

Equipment
<HUAWEI> display bgp routing-table 13.0.0.0 8

Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 13.0.0.0/8:
From: 1.1.1.1 (121.1.1.1)
Route Duration: 4d21h29m39s
Relay IP Nexthop: 172.1.1.1
Relay IP Out-Interface: 0/2/0
Original nexthop: 1.1.1.1
Qos information : 0x0
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best,
select, active, pre 255
Aggregator: AS 100, Aggregator ID 121.1.1.1
Advertised to such 1 peers:
3.3.3.3
l If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If there is no route to the original next hop, the BGP route is not advertised
because the next hop of the BGP route is unreachable. Then, find out why there is no route
to the original next hop (this fault is generally associated with IGP or static routes).
l If the target route is active and has been selected but there is no information indicating that
this route has been sent to the peer, go to Step 2 to check the outbound policy applied to
the local device.
Run the display bgp routing-table network { mask | mask-length } command on the peer to
check whether it has received the target route.
l If the peer has received the target route, perform Step 1 again to check whether the next
hop of the route is reachable and whether this route has been selected.
l If the peer has not received the target route, go to Step 2 to check the inbound policy applied
to the peer.
Step 2 Check that routing policies are configured correctly.
Run the display current-configuration configuration bgp command on the local device and
the peer to check whether inbound and outbound policies are configured.
<HUAWEI> display current-configuration configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 100
#
ipv4-family unicast
undo synchronization
filter-policy ip-prefix aaa import
filter-policy ip-prefix aaa export
peer 1.1.1.1 enable
peer 1.1.1.1 filter-policy acl-name acl-name import
peer 1.1.1.1 filter-policy acl-name acl-name export
peer 1.1.1.1 as-path-filter 1 import
peer 1.1.1.1 as-path-filter 1 export
peer 1.1.1.1 ip-prefix prefix-name import
peer 1.1.1.1 ip-prefix prefix-name export
peer 1.1.1.1 route-policy policy-name import
peer 1.1.1.1 route-policy policy-name export
return
l If inbound and outbound policies are configured on the two devices, check whether the
target route is filtered by these policies. For detailed configurations of a routing policy, see
the Configuration Guide - IP Routing.

Equipment
l If inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check that the number of routes is lower than the upper limit.
Run the display current-configuration configuration bgp | include peer destination-

address command or the display current-configuration configuration bgp | include peer
group-name command on the peer to check whether an upper limit on the number of routes to
be received is configured on the peer.
For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded
after the peer receives five routes from the local device at 1.1.1.1.
<HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations of the upper limit in the
command output.
peer 1.1.1.1 group IBGP
peer 1.1.1.1 enable
In this case, run the display current-configuration configuration bgp | include peer group-
name command to check the configuration of this peer group.
<HUAWEI> display current-configuration configuration bgp | include peer IBGP
peer IBGP route-limit 5 alert-only
peer IBGP enable
If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, the target route
is dropped because the upper limit is exceeded. In this case, increase the upper limit.
NOTE
Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peer
relationship. Therefore, reducing the number of sent routes by configuring route summarization on the
local device is recommended.
l Configuration files, log files, and alarm files of the devices.
----End
Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Relevant Logs
BGP/3/ROUTPRIX_EXCEED

Equipment
4.5.3 BGP Private Network Traffic Is Interrupted
Common Causes
This troubleshooting case describes how to clear the fault that BGP private network routes is
interrupted when the BGP peer relationship is normal.

l Private network routes fail to be advertised because the number of labels exceeds the upper
limit.
l Routes are inactive because they fail to be iterated to a tunnel.
l Routes fail to be added to the VPN routing table because the configured import route-target
(RT) and export RT do not match.
the device.
BGP private network traffic is interrupted after the BGP protocol is configured.

Equipment
Figure 4-14 Troubleshooting flowchart for interruption of BGP private network traffic
The BGP private network


Is fault rectified?
VPN route reachable? hop is reachable
No
Yes
No Yes
Is the routing policy is Correctly configure the
Is fault rectified?
Yes No
Reduce the number of Yes

Does the Yes routes or configure the
Number of labels exceed the Is fault rectified?
device to assign a label
upper limit?
to each instance
No
No
No Ensure that the tunnel Yes

Is the tunnel iterated
exists Is fault rectified?
successfully?
No
Yes
No Yes
Does the export RT
Ensure that they match Is fault rectified?
match the import RT?
No
Yes
Does the number Yes Reduce the number of Yes

of routes exceed the upper routes or increase the Is fault rectified?
limit? upper limit of routes
No
No

Equipment
Context
NOTE
Procedure
Step 1 Check that next hops of routes are reachable.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address

[ mask | mask-length ] command on the PE that sends routes (that is, the local PE) to check
whether the target route exists. ipv4-address specifies the prefix of the target route.
l If the target route does not exist, check whether the route of a CE is advertised to the local
PE.
l If the target route exists, check whether it is active. The following is an example:
this route is active and selected. The original next hop and iterated next hop of this route are
3.3.3.3 and 20.1.1.2 respectively.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1

From: 20.1.1.1 (1.1.1.1)
Route Duration: 00h00m03s
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, active, pre 255
Not advertised to any peer yet
because the next hop of the BGP route is unreachable. In this case, find out why there is
no route to the original next hop (this fault is generally associated with IGP or static routes).
l If the target route is active and selected but there is no information indicating that this route
is sent to the remote PE, go to Step 2 to check the outbound policy applied to the local PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the
remote PE to check whether it has received the target route.
l If the remote PE has received the target route, perform Step 1 again to check whether the
next hop of the route is reachable and whether this route is selected.
l If the remote PE has not received the target route, go to Step 2 to check the inbound policy
of the remote PE.
Run the display current-configuration configuration bgp command on the local PE and
remote PE to check whether inbound and outbound policies are configured.

Equipment
NOTE
Only focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address family in this
troubleshooting case because private network traffic is interrupted.
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpna
#
return
target route fails to be transmitted because it is filtered by these policies. For detailed
configurations of a routing policy, see the Configuration Guide - IP Routing.
Step 3 Check that routes can be iterated to a tunnel.
Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on
the remote PE to check whether the target route can be iterated to a tunnel.
Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface field
and Relay token field in the command output are not empty, it indicates that this route can be
iterated to a tunnel.
<HUAWEI> dis bgp vpnv4 all routing-table 50.1.1.2
Total routes of Route Distinguisher(1:2): 1

Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: 0/2/0
Relay token: 0x1002

Equipment

Ext-Community:RT <1 : 1>
best, select, pre 255
Total routes of vpn-instance vpna: 1

From: 1.1.1.1 (1.1.1.1)
Relay token: 0x1002
l If the target route fails to be iterated to a tunnel, run the display ip vpn-instance
verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field is
not displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy is
configured for the VPN instance. If the VPN instance selects an MPLS-TE tunnel, a tunnel
policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel
policy of the VPN instance. You can view details of the tunnel policy by running the display
this command in the corresponding tunnel policy view.
[HUAWEI-tunnel-policy-p1] display this
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to configure the mpls te reserved-for-binding
command in the tunnel interface view.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or
TE Tunnel Is Down to locate the fault and ensure that the tunnel goes Up.
l If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether routes fail to be added to the VPN routing table because the configured import
RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the local PE
and remote PE to check whether routes fail to be added to the VPN routing table of the remote
PE after being sent to the remote PE because the export RT of the local VPN instance does not
match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.
<HUAWEI> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
route-distinguisher 1:1
apply-label per-instance
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
ip vpn-instance vpnb

Equipment

#
return
l If the export RT of the local VPN instance does not match the import RT of the remote VPN
instance, configure matching VPN-targets in the VPN instance.
l If the export RT of the local VPN instance matches the import RT of the remote VPN instance,
go to Step 5.
Step 5 Check that the number of labels is below the upper limit.
Check whether MPLS is enabled on the local PE. Run the display bgp vpnv4 all routing-
table ipv4-address [ mask | mask-length ] command to check whether the target route is assigned
a VPN label.
If there is no Label information field in the command output, the number of labels may have
reached the upper limit. As a result, the target route is not assigned a label and is not advertised
to the peer.
<HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1


Imported route.
Label information (Received/Applied): NULL/12

From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: NULL0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
255
1.1.1.1

Imported route.
From: 0.0.0.0 (0.0.0.0)
60
l If the number of labels has reached the upper limit, run the apply-label per-instance
command in the VPN instance view to configure the device to assign one label to each
instance to reduce label usage. Route summarization can also be configured to reduce the
number of routes.
l If the number of labels is below the upper limit, go to Step 6.
Step 6 Check that the number of routes is below the upper limit.
If the peer is added to a peer group, run the display current-configuration configuration bgp
| include peer destination-address command or the display current-configuration

Equipment
configuration bgp | include peer group-name command on the remote PE to check whether
the upper limit on the number of routes to be received is configured on the remote PE.
after the remote PE receives five routes from the local PE at 1.1.1.1.
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations about the upper limit in the
command output.
peer 1.1.1.1 enable
name command to check configuration of this peer group.
peer IBGP enable
is dropped because the number of routes received has exceeded the upper limit. In this case,
increase the upper limit.
NOTE
----End
Relevant Alarms
Relevant Logs

Equipment
4.5.4 Troubleshooting of the Fault that a Local BGP Peer (Route

Sender) Cannot Receive ORFs from a Remote Peer (Route Receiver)
This section describes the troubleshooting roadmap for the fault that a local BGP peer (route
sender) cannot receive ORFs from a remote peer (route receiver), and provides troubleshooting
cases.
Common Causes
l The IPv4 BGP peer relationship cannot be established.

l Negotiating the BGP ORF capability fails.
l No import IP-prefix policy is configured on the remote peer (route receiver)
l No prefix list corresponding to the import IP-prefix policy is configured on the remote peer
(route receiver).
After the BGP ORF function is enabled, a local BGP peer (route sender) cannot receive ORFs
from a remote peer (route receiver). Run the display bgp peer ipv4-address orf ip-prefix
command. The command output does not contain any IP-prefix information.

l Check that a BGP peer relationship is set up successfully.
l Check that the BGP ORF capability is negotiated successfully.
l Check that an import IP-prefix policy is configured on the remote peer (route receiver).
l Check that a prefix list corresponding to the import IP-prefix policy is configured on the
remote peer (route receiver).

Equipment
Figure 4-15 Troubleshooting flowchart for the fault that a local BGP peer (route sender) cannot
receive ORFs from a remote peer (route receiver)
A local BGP peer
(route sender) fails to receive
ORFs from a remote peer
(route receiver)
See detailed
troubleshooting
No procedures in Yes
Is a BGP peer relationship Is fault
"Troubleshooting of
set up? rectified?
the Fault that a BGP
Peer Relationship
Cannot Be Set Up"
Yes No
Is the BGP ORF Enable the BGP

function enabled on ORF function on
BGP peers and Do the peer No Is fault Yes
succeed in negotiating BGP peers and
rectified?
the BGP ORF reestablish the BGP
capability? peer relationship
Yes No
Is an import IP-prefix Configure the import

Policy configured on No IP-prefix policy on Is fault Yes
the remote peer the remote peer rectified?
(route receiver)? (route receiver)
Yes No
Is the prefix list Configure the prefix

corresponding to the import No list corresponding to Yes
Is fault
IP-prefix policy is configured the import IP-prefix
on the remote peer rectified?
policy on the remote
(route receiver)? peer
Yes No

Equipment
Context
NOTE
Procedure
Step 1 Check that a BGP peer relationship is set up.
Run the display bgp peer command to check whether the BGP peer relationship is in the
Established state.
l If the BGP peer relationship is not in the Established state, see detailed troubleshooting
procedures in 4.5.1 The BGP Peer Relationship Fails to Be Established.
l If the BGP peer relationship is in the Established state, go to Step 2.
Step 2 Check that the BGP ORF function is enabled on BGP peers, and the peers succeed in negotiating
the BGP ORF capability.
Run the display current-configuration configuration bgp command on BGP peers to check
whether peer ipv4-address capability-advertise orf ip-prefix is configured in the IPv4 unicast
address family view.
#
bgp 100
#
ipv4-family unicast
peer 7.1.1.1 ip-prefix in import
peer 7.1.1.1 capability-advertise orf ip-prefix both
#
NOTE
BGP ORF has three modes: send, receive, and both. In send mode, a device can send ORFs; in receive
mode, a device can receive ORFs; in both mode, a device can either send or receive ORFs. To enable a
device to receive ORF IP-prefix information, configure the both or receive mode on the device and the
both or send mode on its peer.
l If one peer is not configured with the BGP ORF function, enter the BGP IPv4 unicast
address family view and run the peer ipv4-address capability-advertise orf ip-prefix
command to enable BGP ORF. If both or receive is specified when you configure the local
peer, both or send must be specified when you configure the remote peer.
[HUAWEI] bgp 100
[HUAWEI-bgp] ipv4-family unicast
[HUAWEI-bgp-af-ipv4] peer 7.1.1.1 capability-advertise orf ip-prefix both
If BGP ORF is enabled on both BGP peers, wait for the re-establishment of a BGP peer
relationship, and run the display bgp peer ipv4-address verbose command to check
whether the BGP ORF capability is successfully negotiated. The command output shows
the ORF capabilities on both the local and remote peers.
<HUAWEI> display bgp peer 7.1.1.1 verbose | include Address-Prefix

Equipment
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible,

both
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
NOTE
In the preceding command output, the first part shows the ORF capability announced by the remote
peer and the subsequent part shows the ORF capability configured on the local peer. The ORF
capability supported by non-huawei devices may be different from that defined in the RFC standard.
Therefore, to enable Huawei devices to communicate with non-Huawei devices, new commands for
compatibility are added. Ensure that both BGP peers are configured with the same compatibility
mode (either non-standard-compatible or RFC-compatible).
l If both BGP peers are configured with the BGP ORF function and succeed in negotiating
the BGP ORF capability, go to Step 3.
Step 3 Check that an import IP-prefix policy is configured on the remote peer (route receiver).
Run the display current-configuration configuration bgp command on the remote peer to
check whether peer ipv4-address ip-prefix ip-prefix-name import is configured in the IPv4
unicast address family.
#
bgp 100
#
ipv4-family unicast
peer 7.1.1.1 ip-prefix in import
peer 7.1.1.1 capability-advertise orf ip-prefix both
#
l If no import IP-prefix policy is configured on the remote peer, enter the BGP IPv4 unicast
address family view, and run the peer ipv4-address ip-prefix ip-prefix-name import
command to configure an import IP-prefix policy. For example, configure an IP-prefix
named in on the remote peer.
[HUAWEI] bgp 100
[HUAWEI-bgp] ipv4-family unicast
[HUAWEI-bgp-af-ipv4] peer 7.1.1.1 ip-prefix in import
l If an import IP-prefix policy is configured on the remote peer but the local peer still cannot
receive ORF IP-prefix information from the remote peer, go to Step 4.
Step 4 Check that the prefix list corresponding to the import IP-prefix policy is configured on the remote
peer (route receiver).
Run the display ip ip-prefix ip-prefix-name command on the remote peer to check whether the
prefix list corresponding to the import IP-prefix policy is configured.
<HUAWEI> display ip ip-prefix in
Info: The specified filter list does not exist.
The preceding output shows that the prefix list in has not been successfully configured.
Enter the system view, and run the ip ip-prefix ip-prefix-name index index-number permit
ipv4-address mask-length command to configure a prefix list.
[HUAWEI] ip ip-prefix in index 10 permit 10.1.1.0 24
After completing the preceding configuration, run the display ip ip-prefix ip-prefix-name
command on the remote peer to check whether the prefix list corresponding to the import IP-
prefix policy is configured.

Equipment
<HUAWEI> display ip ip-prefix in

Prefix-list in
Permitted 0
Denied 0
index: 10 permit 10.1.1.0/24
The preceding output shows that the prefix list in has been successfully configured. After
completing the preceding steps, if the local peer still cannot receive ORFs from the remote peer,
go to Step 5.
l Configuration files, log files, and alarm files of the device
----End
Relevant Alarms
BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition
BGP_1.3.6.1.2.1.15.7.1 bgpEstablished
Relevant Logs
BGP/3/STATE_CHG_UPDOWN
4.6 RIP Troubleshooting
4.6.1 Device Does not Receive Partial or All the Routes
Common Causes
l The incoming interface is not enabled with RIP.

l The incoming interface is not in Up state.
l The version number sent by the peer does not match with that received on the local interface.
l The interface is disabled to receive the RIP packet.
l The policy used to filter the received RIP routes is configured.
l The metric of the received routes is larger than 16.
l Other protocols have learned the same routes in the routing table.
l The number of the received routes exceeds the upper limit.
l The MTU value of the incoming interface is less than 532.
l The authentication of sending and receiving interface is not matching.

Equipment
If a ATN receives partial or none routes or the display ip routing-table command dose not
display routes learned by RIP, refer to the following troubleshooting flowchart, as shown in
Figure 4-16.
Figure 4-16 RIP route receiving troubleshooting flowchart

Device does not
receive partial or all
the routes
Ingress is No Is fault Yes

Enable the ingress
enabled? rectified?
Yes No
No Ensure the normal Is fault Yes
Ingress is normal? state on the
rectified?
ingress
Yes No
Ensure the same
Version No version number on Yes
Is fault
numbers are
sending and rectified?
the same?
receiving interface
No
Yes
undo rip input Yes Cancel the undo Is fault Yes

rip input
is configured? rectified?
command
No
No
Filtering policy Yes Ensure the policy Is fault Yes

does not filter out
is configured? rectified?
received packets
No No
rip metricin Yes Reduce the value Is fault Yes

is configured? of rip metricin rectified?
No No
Metric Yes
is larger than
16?
No
There Yes
are other better
routes?
No
Seek technical
End
support

Equipment
Context
NOTE
Procedure
Step 1 Check that the incoming interface is enabled with RIP.
The network command is used to specify the interface network segment. Only the interface
enabled with RIP can receive and send the RIP routing information.
Run the display current-configuration configuration rip command to check information

about the network segment where RIP is enabled. Check whether the outgoing interface is
enabled.
The network address enabled by the network command must be that of the natural network
segment.
Step 2 Check that the incoming interface works normally.
Run the display interface command to check the operating status of the incoming interface:
l If the current physical status of the interface is Down or Administratively Down, RIP cannot
receive any route from the interface.
l If the current protocol status of the interface is Down, the cost of routes learnt by RIP from
the interface changes to 16, and then is deleted.
Therefore, ensure the normal status of the interface.
Step 3 Check that the version number sent by the peer matches with that received on the Local Interface.
By default, the interface sends only RIP-1 packets, but can receive both RIP-1 and RIP-2 packets.
If the version number of the incoming interface and that of the RIP packet are different, RIP
routing information may not be received correctly.
Step 4 Check whether the undo rip input command is configured on the incoming interface.
The rip input command enables a specified interface to receive RIP packets.
The undo rip input command disables a specified interface from receiving RIP packets.
If the undo rip input command is configured on the incoming interface, all the RIP packets
from the interface cannot be processed. Therefore, the routing information cannot be received.
Step 5 Check whether a policy used to filter received RIP routes is configured.
The filter-policy import command is used to filter the received RIP routes. If an ACL is used,
run the display current-configuration configuration acl-basic command to view whether the
RIP routes learned from the neighbor are filtered. If the IP-Prefix list is used to filter routes, the
display ip ip-prefix command is used to check the configured policy.
If a routing policy is set to filter routes, it must be configured correctly.

Equipment
Step 6 Check whether the incoming interface is configured with the rip metricin command and if the
metric is larger than 16.
The rip metricin command is used to set the metric that is added to a route when the interface
receives a RIP packet.
If the metric exceeds 16, the route is regarded as unreachable and is not added to the routing
table.
Step 7 Check whether the metric of the received routes is larger than 16.
If the metric of a received route exceeds 16, the route is regarded as unreachable and is not added
to the routing table.
Step 8 Check whether the authentication on the sending and receiving interface is matching.
Run the display rip process-id statistics interface interface-type interface-number command
to check whether packet authentication has failed on the interface.
If the packet authentication was failed on the interface, it must be configured correctly.
Step 9 Check whether other protocols have learned the same routes in the routing table.
Run the display rip process-id route command to check whether routes have been received
from the neighbor.
The possible cause is that the RIP route is received correctly and the local device learns the same
route from other protocols such as OSPF and IS-IS.
The weights of OSPF or IS-IS are generally greater than that of RIP. Routes learned through
OSPF or IS-IS are preferred by routing management.
Run the display ip routing-table protocol rip verbose command to view routes in the Inactive
state.
Step 10 If the fault persists, contact Huawei technical support personnel and provide them with the
following information.
----End
Relevant Alarms
None.
Relevant Logs
None.
4.6.2 Device Does not Send Some or All Routes

Equipment
Common Causes
l The outgoing interface is not enabled with RIP.

l The outgoing interface is not in the Up state.
l The silent-interface command is configured on the outgoing interface so that the interface
is suppressed from sending RIP packets.
l The undo rip output command is configured on the outgoing interface so that the interface
is disabled to send the RIP packet.
l The RIP split-horizon is disabled on the outgoing interface.
l The policy for filtering imported RIP routes is configured in RIP.
l The physical status of the interface is Down or Administratively Down, or the current
status of the protocol on the outgoing interface is Down. The IP address of the interface
cannot be added to the advertised routing table for RIP.
l Although the outgoing interface does not support the multicast or broadcast mode, packets
must be sent to a multicast or broadcast address.
l The MTU value of the outgoing interface is less than 52.
If a ATN sends partial or none routes, refer to the following troubleshooting flowchart, as shown
in Figure 4-17.

Equipment
Figure 4-17 RIP route sending troubleshooting flowchart

Device does not
send partial or all
the routes
Egress is No Is fault Yes

Enable the egress
enabled? rectified?
Yes No
Egress is No Ensure the normal Is fault Yes

normal? state on the egress rectified?
Yes No
Yes
silent-interface Yes Cancel the silent- Is fault
is configured? interface command rectified?
No No
Yes
undo rip output Yes Cancel the undo rip Is fault
is configured? output command rectified?
No
No
Split horizon Yes

is configured?
No
Ensure the policy
Filtering policy Yes does not filter out Is fault Yes
is configured? routes imported by rectified?
RIP No
No
If packets are sent to
Local No local interface, ensure Yes
Is fault
interface is
the normal state on rectified?
normal?
local interface
Yes No
Interface is enabled
Any other Yes multicast and peer Is fault Yes
problems? command is rectified?
configured correctly
No No
Seek technical
support End

Equipment
Context
NOTE
Procedure
Step 1 Check whether the outgoing interface is enabled with RIP.
The network command is used to specify an interface network segment. Only an interface
enabled with RIP can receive and send RIP routes.
Run the display current-configuration configuration rip command to check information

about a network segment where RIP is enabled. Check whether the outgoing interface is enabled.
The network address enabled by using the network command must be that of the natural network
segment.
Step 2 Check whether the outgoing interface works normally.
Run the display interface command to check the operating status of the outgoing interface.
If the physical status of the interface is Down or Administratively Down, or the status of the
current protocol is Down, RIP cannot work properly on the interface.
Ensure that the interface is normal.
Step 3 Check whether the silent-interface command is configured on the outgoing interface.
The silent-interface command is used to suppress the interface from sending the RIP packet.
The display current-configuration configuration rip command is used to check whether the
interface is suppressed from sending RIP packets.
If the silent-interface command is configured, disable suppression on the interface.
Step 4 Check whether the undo rip output command is configured on the outgoing interface.
Run the display current-configuration command on the outgoing interface to view whether
the rip output command is configured.
The rip output command enables the interface to send RIP packets.
The undo rip output command disables the interface from sending RIP packets.
If the undo rip output command is configured on the outgoing interface, the RIP packet cannot
be sent on the interface.
Step 5 Check whether the rip split-horizon command is configured on the outgoing interface.
Run the display current-configuration command on the outgoing interface to view whether
the rip split-horizon command is configured. If the command is configured, split-horizon is
enabled on the outgoing interface.
By default, split-horizon is enabled on all outgoing interfaces, and the output of the command
does not contain configuration items about split-horizon.

Equipment
For the outgoing interface (such as X.25, FR) on the NonBroadcast Multiple Access (NBMA)
network, if the display does not contain a configuration item about split-horizon, it indicates
split-horizon is not enabled on the outgoing interface.
Split-horizon means that the route learned from an interface is not advertised on the interface.
Split-horizon is used to prevent a loop between adjacent neighbors from forming.
Step 6 Check whether the policy filtering the imported RIP route is configured in RIP.
Run the filter-policy export command to configure the filtering policy on the global interface.
Only routes that pass the filtering policy can be added to the advertised routing table of RIP.
These routes are advertised through the updated packet.
Step 7 Check the status of the interface when the route is sent to the local interface address.
Run the display interface command to check the operating status of the interface.
If the physical status of the interface is Down or Administratively Down, or the current status
of the protocol on the outgoing interface is Down, the IP address of the interface cannot be added
to the advertised routing table of RIP. Therefore, the routing information is not sent to the
neighbor.
Step 8 Check whether there are other problems.
If the outgoing interface does not support multicast or broadcast mode and a packet needs to be
sent to a multicast or broadcast address, this fault will occur.
This potential source of the fault can be removed by configuring the peer command in the RIP
mode to make ATNs send packets with unicast addresses.
Step 9 If the fault persists, contact Huawei technical support personnel and provide them with the
following information.
----End
Relevant Alarms
None.
Relevant Logs
None.

Equipment
Troubleshooting 5 Layer 2 Network
5 Layer 2 Network
About This Chapter
5.1 Ethernet OAM Troubleshooting
5.2 MSTP Troubleshooting

This chapter describes common causes of MPLS faults, and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
5.3 RRPP Troubleshooting
5.4 ERPS (G.8032) Troubleshooting

Equipment
5.1 Ethernet OAM Troubleshooting
5.1.1 Ethernet OAM 802.1ag Trace Fails
Common Causes
On the network shown in Figure 5-1, ATN fails to perform the 802.1ag MAC trace operation
to trace CX-C.
[ATN-md-one-ma-one] trace mac-8021ag mep mep-id 1 remote-mep mep-id 2
Tracing the route to 0018-823c-c449 over a maximum of 64 hops:
Request timed out.
Figure 5-1 Troubleshooting flowchart for the fault that Ethernet OAM 802.1ag trace fails
ATN CX-B CX-C

l A MEP configured on CX-C (the traced node) is at a level different from that on ATN (the
trace-initiating node).
l A MEP on an intermediate node has the same level as or higher level than that on ATN.
l An intermediate node has no MAC address entry of CX-C.

Equipment
Figure 5-2 Troubleshooting flowchart for the fault that Ethernet OAM 802.1ag trace fails
802.1ag trace fails
Configure a MEP on
The same level No Yes
Router C at the same
MEP is configured on Is fault rectified?
level as the MEP on
CX-C?
CX-C
No
Yes
Configure a MEP on
A higher-level Yes Yes
Router B at the same
MEP is configured on Is fault rectified?
level as the MEP on
CX-B? CX-B
No
No
Perform 802.1ag MAC

CX-B has a ping on ATN A to ping Yes
No
MAC address entry of CX-C and allow CX-B Is fault rectified?
CX-C? to learn the MAC
address
No
Yes
Collect information
Seek techincal support End
Procedure
Step 1 Run the display this command to check that the MEP configured on CX-C has the same level
as the MEP configured on ATN.
l If so, go to Step 2.
l If not, run the cfm md command to set the MEP level on CX-C the same as that on ATN.
If ATN successfully performs the MAC trace operation to trace CX-C, go to Step 5.
If ATN fails to perform the MAC trace operation to trace CX-C, go to Step 2.
Step 2 Run the display cfm mep command to check that the level of the MEP on an intermediate node
is the same as or higher than that on ATN.

Equipment
NOTE
After 802.1ag packets in a lower-level MD enter a higher-level MD, the 802.1ag packets will be discarded;
802.1ag packets in a higher-level MD can successfully travel through a lower-level MD. 802.1ag packets in an
MD of a specified level cannot travel through the MD with the same level.
l If the level of the MEP on an intermediate node is lower than that on ATN, go to Step 3.
l If the level of the MEP on an intermediate node is the same as or higher than that on ATN,
run the cfm md command to set the level of the MEP on the intermediate node to be lower
than that on ATN.
Step 3 Run the display mac-address dynamic command on each intermediate node to check that the
MAC address entry of CX-C exists.
l If so, go to Step 4.
l If not, run the ping mac-8021ag command to allow the intermediate node to learn the MAC
address of CX-C.
Step 4 If the fault persists, contact Huawei technical support personnel.
Step 5 End.
----End
Relevant Alarms
None
Relevant Logs
None
5.2 MSTP Troubleshooting

This chapter describes common causes of MPLS faults, and provides the corresponding
5.2.1 MSTP Topology Change Leads to Service Interruption
Common Causes
When the topology on an MSTP network changes, services are interrupted.

Equipment
l MSTP is incorrectly configured.

l Physical links flap, triggering a large number of TC messages.
l An MSTP-aware device receives MSTP TC messages from clients or transparently-
transmitted MSTP TC messages.
Changing MSTP topology leads to service interruption on the network shown in Figure 5-3.
Figure 5-3 Networking diagram of MSTP

S1 S2
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
GE1/0/2 GE1/0/2
GE1/0/1 GE1/0/1
S3 S4
CIST(MSTI0):
Root Switch: S1
Blocked port
MSTI1:
Root Switch: S1
Blocked port
MSTI2:
Root Switch: S2
Blocked port

Equipment
l Check that the MSTP status is correct.

l Check whether the device has received TC messages.
l Check that no physical interface on the device alternates between Up and Down.
l Check that the MSTP convergence mode is Normal.
Figure 5-4 Troubleshooting flowchart for service interruption due to changes in MSTP topology
Services are
interrupted or the
device is
disconnected
MSTP status is No Check and modify the Yes

Is fault rectified?
correct? MSTP configuration
No
Yes
Yes
MSTP recalculation Seek technical
is performed? support
No
Physical
interface on the device Yes Shut down the Yes
Is fault rectified?
alternates between Up flapping interface
and Down?
No
No
MSTP No Set the MSTP Yes

convergence mode is convergence mode to Is fault rectified?
Normal? Normal
Yes No
Collect information
Context
NOTE

Equipment
Procedure
Step 1 Check the status of interfaces on MSTP devices.
Check the role of each MSTP-enabled port in each instance.
On the network shown in Figure 5-3, there is only one MSTP ring, which means that each
instance can have only one blocked interface.Run the display stp brief command on each device
to check whether the status of each port is normal.
Run the display stp brief command in any view to check the MSTP status on S1.As shown in
Figure 5-3, in instances 0 and 1, S1 functions as a root bridge and all ports on S1 are designated
ports.In instance 2, one port on S1 is a designated port and the other port is a root port.Both ports
are in the Forwarding state.
[S1] display stp brief
MSTID Port Role STP State Protection
0 Ethernet0/2/1 DESI FORWARDING NONE
2 Ethernet0/2/1 ROOT FORWARDING NONE
Run the display stp brief command in any view to check the MSTP status on S2. As shown in
Figure 5-3, in instances 2, S2 functions as a root bridge and all ports on S2 are designated ports.In
other instances, one ports on S2 is a designated port and the other port is a root port. Both of
them are in the Forwarding state.

Figure 5-3, in instance 2, one port on S3 is an Alternate port and the other port is a root port.
The Alternate port is blocked and in the Discarding state.In other instances, one port on S3 is a
designated port and the other port is a root port. Both of them are in the Forwarding state.
2 Ethernet0/2/2 ALTE DISCARDING NONE
Figure 5-3, in instance 0 and 1, one port on S4 is an Alternate port and the other port is a root
port. The Alternate port is blocked and in the Discarding state.In instance 2, one port on S4 is a
designated port and the other port is a root port. Both of them are in the Forwarding state.

Equipment

1 Ethernet0/2/1 ALTE FORWARDING NONE
l On the network shown in Figure 5-3, each instance has only one port in the Discarding
state and the other port is in the Forwarding state.If several ports are in the Discarding state,
an MSTP calculation error occurs. To solve this problem, go to Step 6.
l If the MSTP status is correct, go to Step 2.
Step 2 Check that the MSTP configuration is correct.
Run the display stp region-configuration command to view mappings between VLANs and
instances.
[S1] display stp region-configuration
Oper Configuration:
Format selector :0
Region name :huawei
Revision level :0
Instance Vlans Mapped

0 21 to 4094
1 1 to 10
2 11 to 20
l Check whether mappings between VLANs and instances are correct.If the mapping
between a VLAN and an instance is incorrect, run the instance command to map the VLAN
to a specified spanning tree instance. Run the active region-configuration command to
active the mapping between the VLAN and instance configured by using the instance
command.
Run the display current-configuration command to view the MSTP configuration in the
configuration file of the device.
l Check interface configurations to confirm that MSTP-enabled interfaces have been
configured with the command.
l Check whether MSTP is disabled on the interfaces connecting to user terminals or the
interfaces are configured as edge interfaces.
l Check whether a port is added to a VLAN correctly.For VLAN configurations, see the
chapter "VLAN Configuration" in the Configuration Guide - LAN Access and MAN
Access .
l If the MSTP configuration is correct, go to Step 3.
Step 3 Check that no MSTP recalculation is performed.
Run the display stp command in any view to check whether the device has received TC
messages.
[S1] display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge :32768.0819-a6cf-d0fe
Config Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
Active Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 19
CIST Root/ERPC :0 .286e-d4cb-a8bf / 0
CIST RegRoot/IRPC :0 .286e-d4cb-a8bf / 199
CIST RootPortId :0.3
BPDU-Protection :Disabled
TC or TCN received :0
TC count per hello :0
STP Converge Mode :Normal
Time since last TC :0 days 1h:25m:59s

Equipment
l If values of the TC or TCN received, TC count per hello, TC received, and TC count per
hello fields in the command output increase, the device has received TC messages and the
network topology has changed. In this case, you need to view log messages MSTP/6/
SET_PORT_DISCARDING and MSTP/6/SET_PORT_FORWARDING to check
whether the role of an MSTP-enabled port changes.
If the port role does not change, go to Step 4.
If the port role changes, go to Step 6.
l If the values in the TC or TCN received, TC count per hello, TC received, and TC count
per hello fields in the command output are 0s, it indicates that the device does not receive
any TC message. In this case, contact Huawei technical support personnel.
Step 4 Check that no interface on the device alternates between Up and Down.
l If an MSTP-enabled interface alternates between Up and Down, it indicates that the
interface flaps. If a physical interface frequently alternates between Up and Down, the
MSTP status of the device on the network will become unsteady. As a result, a large number
of TC messages are generated; ARP entries and MAC entries are frequently deleted;
services are interrupted. Run the shutdown command on the flapping interface. If services
are not restored after the flapping interface is shut down, go to Step 5.
l If no interface flaps, go to Step 5.
Step 5 Check that the MSTP convergence mode is Normal.
Run the display stp command in any view to check the MSTP convergence mode of the device.
[S1] display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge :32768.0819-a6cf-d0fe
Config Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
Active Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 19
CIST Root/ERPC :0 .286e-d4cb-a8bf / 0
CIST RegRoot/IRPC :0 .286e-d4cb-a8bf / 199
CIST RootPortId :0.3
BPDU-Protection :Disabled
TC or TCN received :0
TC count per hello :0
STP Converge Mode :Normal
Time since last TC :0 days 1h:25m:59s
l If the convergence mode is Normal, go to Step 6.

l If the convergence mode is Fast, run the stp converge normal command to change the
convergence mode to Normal. If services are not restored after the convergence mode is
changed, go to Step 6.
----End
Relevant Alarms
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding

Equipment
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
Relevant Logs
MSTP/6/RECEIVE_MSTITC
5.3 RRPP Troubleshooting
5.3.1 RRPP Loop Occurs Temporarily
Common Causes
After RRPP is configured on a device, a loop occurs temporarily.

l The configuration is incorrect.
l Values of the Failtime timers configured for nodes along the RRPP ring are different.
l Check that every node on the RRPP ring is configured correctly.
l Check that the Failtime timer of every node on the RRPP ring is set to the same value.

Equipment
Figure 5-5 Troubleshooting flowchart for the fault that an RRPP loop occurs temporarily
RRPP loop occurs

temporarily
Every node No Yes

Modify the
on The RRPP ring is Is fault rectified?
configurations
correctly configured?
No
Yes
Failtime timer
No Yes
of every node on the Correct the
Is fault rectified?
RRPP ring is set to the configurations
same value?
No
Yes
Collect information
NOTE
Procedure
Step 1 Check that every node on the RRPP ring is correctly configured.
Run the display this command in the RRPP view of each node on the RRPP ring to view RRPP
configurations.
[RouterA-rrpp-domain-region1] display this
#
rrpp domain 1
control-vlan 100
ring 1 node-mode master primary-port Ethernet0/2/0 secondary-port
GigabitEthernet0/2/1 level 0
ring 1 enable #
return
Check whether all nodes on the RRPP ring belong to the same domain, whether the nodes are
configured with the same control VLAN ID and instance number, and whether the RRPP ring
has only one master node.

Equipment
l If all configurations are correct, go to Step 2.

l If any of the preceding configurations is incorrect, RRPP configurations may be incorrect.
For correct configurations, see the chapter "RRPP Configuration" in the Configuration Guide
- LAN Access and MAN Access.
Step 2 Check that the Failtime timer of every node on the RRPP ring is set to the same value.
Run the display rrpp verbose domain domain-id command in any view to check detailed RRPP
configurations.
[RouterA-rrpp-domain-region1] display rrpp verbose domain 1
Domain Index : 1
Hello Timer : 1 sec(default is 1 sec) Fail Timer : 6 sec(default is 6 sec)
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Ring State : Complete
Is Enabled : Enable Is Active : Yes
l If the Failtime timers of the nodes on the RRPP ring are set to different values, correct the
configurations according to the chapter "RRPP Configuration" in the Configuration Guide
- LAN Access and MAN Access.
l If the Failtime timer of every node on the RRPP ring is set to the same value, go to Step
3.
----End
Relevant Alarms
RRPP_1.3.6.1.4.1.2011.5.25.113.4.2 hwRrppRingFail
Relevant Logs
RRPP/3/FAIL
RRPP/5/PBLK
RRPP/5/RESTORE
5.4 ERPS (G.8032) Troubleshooting
5.4.1 ERPS Ring Negotiation Troubleshooting
Common Causes
ERPS negotiation fails after ERPS is configured.

Equipment

l Basic ERPS configurations are incorrect.
l The WTR timer is running.
The networking shown in Figure 5-6 is used to describe how to troubleshoot an ERPS
negotiation failure.
Figure 5-6 Networking of an ERPS ring
Network
NPE1 NPE2
LSW1 LSW4
ERPS
LSW2 RPL
LSW3
RPL Owner
CE
Blocked Port

l Check that whether basic configurations are correct.
l Check that whether the WTR timer is running.
l Check that whether the packet statistics on the port are correct.

Equipment
Figure 5-7 Troubleshooting flowchart for an ERPS negotiation failure
ERPS ring
negotiation fails
No Configure control VLANs Is fault Yes

Basic configurations and protection instances rectified
are correct? correctly ?
No
Yes
Yes Wait until the WTR Is fault Yes

WTR Timer is
Timer expires rectified?
running?
No
No
Solve the problem of Yes

Packet count is No Is fault
physical layer
a non-zero rectified?
interconnection
value?
No
Yes
Collect debugging
information
Context
NOTE
Procedure
Step 1 Check that whether basic configurations of the ERPS are correct.
Each ERPS ring must be configured with a control VLAN. After a port is added to an ERPS
ring configured with a control VLAN, the port is added to the control VLAN automatically.
Different ERPS rings cannot be configured with the same control VLAN ID.

Equipment
Create a protected instance, and then map a VLAN to a specified protected instance, ports can
be added to the ERPS ring finally. Additionally, each node must have two ports added to the
same ERPS ring.
Run the display erps verbose command on each device to check whether basic configurations
of the ERPS are correct.
<LSW1> display erps verbose
Ring ID : 1
Description : Ring 1
Control Vlan : 10
Protected Instance : 1
WTR Timer Setting (min) : 6 Running (s) : 0
Guard Timer Setting (csec) : 100 Running (csec) : 0
Holdoff Timer Setting (deciseconds) : 0 Running (deciseconds) : 0
Ring State : Idle
RAPS_MEL : 7
Time since last topology change : 0 days 0h:33m:4s
------------------------------------------------------------------------
Port Port Role Port Status Signal Status
------------------------------------------------------------------------
GE0/2/1 Common Forwarding Non-failed
GE0/2/2 RPL Owner Discarding Non-failed
Ring ID : 2
Control Vlan : 20
Ring State : Idle
RAPS_MEL : 7
------------------------------------------------------------------------
------------------------------------------------------------------------
l If configurations of control VLANs and protected instances of devices that are added to
the same ERPS ring are inconsistent, or ports are incorrectly added to the ERPS ring, ensure
that the configurations are correct. For details, see the section "ERPS (G. 8032)
Configuration" in the "ATN Configuration Guide - LAN and MAN Access".
l If configurations of control VLANs and protected instances of devices that are added to
the same ERPS ring are consistent and ports are correctly added to the ERPS ring, perform
Step 2.
Step 2 Check whether the WTR timer is running.
To prevent the RPL owner port alternates between Up and Down, the node where the RPL owner
port resides starts a WTR timer after receiving an RAPS PDU indicating link or node recovery.
If the node receives an RAPS PDU indicating that another port fails before the timer expires,
the device stops the WTR timer. If the node does not receive any RAPS PDUs indicating that
another port fails before the timer expires, the device blocks the RPL owner port after the timer
expires and sends an RAPS PDU indicating that the RPL owner port is blocked. After receiving
this RAPS PDU, the other nodes set their ports on the ring to the Forwarding status.
If the WTR timer is running, an ERPS ring negotiation may fail.
Run the display erps verbose command on each device to check whether the WTR timer of the
ERPS is running.

Equipment
<LSW1> display erps verbose

Ring ID : 1
Control Vlan : 10
Ring State : Idle
RAPS_MEL : 7
------------------------------------------------------------------------
------------------------------------------------------------------------
GE0/2/2 RPL Owner Discarding Non-failed
Ring ID : 2
Control Vlan : 20
Ring State : Idle
RAPS_MEL : 7
------------------------------------------------------------------------
------------------------------------------------------------------------
l If the "Running (s)" field value that indicates the WTR timer is not 0, check whether the
ERPS ring negotiation succeeds after the WTR timer expires.
l If the "Running (s)" field value that indicates the WTR timer is running is 0, perform Step
3.
Step 3 Check that the number of ERPS ring packets is not 0.
Run the display erps statistics command on each device to check whether devices receive and
send ERPS packets properly.
--------------------------------------------------------------------------------
Ring Port RX/TX SF NR NRRB FS MS EVENT
--------------------------------------------------------------------------------
1 Eth-Trunk1 RX 0 0 552 0 0 0
1 Eth-Trunk1 TX 0 68 0 326 0 6
1 GE0/2/1 RX 0 6 552 0 0 0
1 GE0/2/1 TX 4 63 0 326 0 6
10 GE0/2/2 RX 0 1 0 0 0 0
10 GE0/2/2 TX 4 74 0 0 0 0
l If the number of ERPS packets is 0, a link fault may occur. For details about how to
troubleshoot the link fault, see "Physical Interconnection Troubleshooting."
l If packet statistics are correct, perform Step 4.
Step 4 Collect the following information and contact Huawei technical support personnel:
----End

Equipment
Relevant Alarms
None.
Relevant Logs
ERPS/5/PORTFWDSTATUS
ERPS/5/PORTSIGNALSTATUS
ERPS/5/TOPOCHANGE
ERPS/5/PORTADDRINGFAILED

Equipment
Troubleshooting 6 Multicast
6 Multicast
About This Chapter
This chapter describes common causes of multicast faults and provides the corresponding
6.1 Layer 2 Multicast Troubleshooting
6.2 L3 Multicast

Equipment
6.1 Layer 2 Multicast Troubleshooting

6.1.1 Layer 2 Multicast Traffic Cannot Be Transmitted
Common Causes
This fault is commonly caused by one of the following causes:
l A fault occurs on the uplink or downlink.

l The VLAN status is incorrect.
l The number of Layer 2 multicast entries on the device reaches the upper limit.
l Traffic interruption caused by a hardware failure, such as board failure, or improper
connection of optic fiber or network cable.
After Layer 2 multicast is configured, multicast traffic cannot be transmitted.

l Check that the link functions properly.
l Check that configurations are correct.
l Check that the number of Layer 2 multicast entries on the device is within the upper limit.

Equipment
Figure 6-1 Troubleshooting flowchart for the fault that Layer 2 multicast traffic cannot be
transmitted
Multicast
traffic cannot
be transmitted

Interface Yes
Status is
normal?
No
No
Check and rectify Number of

the fault on the Layer 2 multicast
uplink or downlink entries on the device
reaches the upper Yes
limit?
IGMP Yes
No
Is fault Snooping is
rectified? enabled in the
VLAN ?
No
Yes End
Function of
discarding unknown No
multicast traffic is
enabled?
Yes
Correct the Seek technical

configuration support
End
Context
NOTE
Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Equipment
Procedure
Step 1 Check that the uplink and downlink interfaces are Up.
Run the display this interface command on the interface enabled with the multicast function
to check whether the interface is Down.
l If the interface is shut down, run the undo shutdown command on the interface.
l If the interface is restarted but it is still in the Down state, check whether the physical link
is faulty.
l If the interface is in the Up state but the fault persists, go to Step 2.
Step 2 Check that IGMP snooping is enabled in the VLAN.
Run the display igmp-snooping configuration command. If igmp-snooping enable is

displayed, IGMP snooping is enabled.
NOTE
In this command, you can specify the parameter vlan vlan-id to check IGMP snooping configurations in
the specified VLAN.
l If IGMP snooping is disabled, check whether the function of discarding unknown multicast
traffic is enabled in the VLAN view.
NOTE
The unknown-multicast discard command is configured in the VLAN view to discard unknown
multicast traffic.
If either of the preceding commands is used to enable the function of discarding
unknown multicast traffic:
Run the undo unknown-multicast discard command in the VLAN view to disable the
function of discarding unknown multicast traffic.
If neither of the preceding commands is used to enable the function of discarding
unknown multicast traffic but the fault persists:
Contact Huawei technical support personnel.
l If IGMP snooping is enabled but the fault persists, go to Step 3.
Step 3 Check that the number of Layer 2 multicast entries on the device is below the upper limit.
Run the display igmp-snooping port-info command on the device to check the number of Layer
2 multicast entries.
l If the number of Layer 2 multicast entries has exceeded the upper limit, no more multicast
entries can be generated.
NOTE
The specification of Layer 2 multicast entries varies with the software version. For detailed
information, see descriptions of specifications of each version.
l If the number of Layer 2 multicast entries is below the upper limit but the fault persists, go
to Step 4.

Equipment
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2 L3 Multicast
6.2.1 Multicast Traffic Cannot Be Transmitted
Common Causes
l Route configurations are incorrect.

l The VLAN status is incorrect.
l Multicast configurations fail to be delivered.
l No Layer 2 multicast entry is generated.
l No upper-layer forwarding entry is generated.
After Layer 3 multicast is enabled, multicast traffic cannot be transmitted.

l Check that the route to the multicast source is reachable.
l Check that the configuration for enabling multicast has been delivered to interface boards.
l Check that PIM information table has been generated.
l Check that forwarding entries have been generated.

Equipment
Figure 6-2 Troubleshooting flowchart for the fault that multicast traffic cannot be transmitted
Multicast traffic
Cannot be
transmitted
Route to the No Configure a static route Yes

Is fault
multicast source is to the multicast source or
rectified?
reachable? enable a routing protocol
No
Yes
Configurations No
Seek technical
Have been delivered to End
support
interface boards?
Yes
PIM information No
table has been
generated?
Yes
Check whether forwarding

entries have been generated
and record the phenomena
Context
NOTE
Procedure
Step 1 Check that the route to the multicast source is reachable.
Run the display ip routing-table ip-address command on the device to check whether the
routing table contains a route to the multicast source.
NOTE
ip-address specifies the address of the multicast source.

l If no route to the multicast source is found, check route configurations.
l If the route to the multicast source is reachable but the fault persists, go to Step 2.
Step 2 Check that the configuration for enabling multicast has been delivered to interface boards.

Equipment
Run the display multicast forwarding-table statistics commands on the device to check
whether the configuration for enabling multicast has been delivered to interface boards.
l If no information about the maximum number of multicast entries and outbound interfaces
is displayed, no multicast configuration is delivered to the interface board. In this case,
contact Huawei technical support personnel.
l If multicast configurations have been delivered to interface boards but the fault persists, go
to Step 4.
Step 3 Check that PIM information table has been generated.
Run the display pim routing-table and display multicast routing-table commands on the
device to check whether PIM information table has been generated.
l If no upper-layer protocol entry is displayed, contact Huawei technical support personnel.

l If upper-layer protocol entries are displayed but the fault persists, go to Step 5.
Step 4 Check that forwarding entries have been generated.
Run the display multicast forwarding-table commands on the device to check whether
forwarding entries have been generated.
l If forwarding entries have been generated but the fault persists, record the displayed
information and contact Huawei technical support personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2.2 The PIM Neighbor Relationship Remains Down
Common Causes
l The interface is physically Down or the link-layer protocol status of the interface is Down.
l PIM is not enabled on the interface.
l PIM configurations on the interface are incorrect.

Equipment
After PIM network configuration is complete, the PIM neighbor relationship remains Down.
Figure 6-3 Troubleshooting flowchart: the PIM neighbor relationship remains Down
The PIM neighbor
relationship remains
Down
Is PIM enabled No Yes

Enable PIM on the interface Is fault rectified?
on the interface?
Yes No
No No Refer to the
Is the PIM status Is the interface
troubleshooting of
Up on the interface? physically Up?
interface Down
Yes Yes
No Yes
Is fault rectified?
Yes No Refer to the

Is the link status Up
troubleshooting of
on the interface?
interface Down
No Yes
Is fault rectified?
Are the PIM No Change the PIM Yes

configurations on the configurations on the Is fault rectified?
interface correct? interface
Yes No

Equipment
Context
NOTE
Procedure
Step 1 Check that PIM is enabled on the interface.
Run the display current-configuration interface interface-type interface-number command to

check whether PIM is enabled on the interface.
l If PIM is not enabled, enable PIM on the interface.

If "Error: Please enable multicast in the system view first." is prompted when you enable
PIM, first run the multicast routing-enable command in the system view to enable the
multicast function. Then, go on to enable PIM-SM or PIM-DM on the interface.
l If PIM has been enabled on the interface, go to Step 2.
Step 2 Check that the PIM status of the interface is Up.
Run the display pim interface interface-type interface-number command to check whether the
PIM status of the interface is Up.
l If the PIM status is Down, run the display interface interface-type interface-number
command to check whether the physical status and link status of the interface are both Up.
1. If the physical status is not Up, make the physical status go Up.
2. If the link status is not Up, make the link status go Up.
l If the PIM status of the interface is Up, go to Step 3.
Step 3 Check that PIM configurations on the interface are correct.
This fault may be caused by the following PIM configurations:

l The IP addresses of directly-connected interfaces are on different network segments.
l PIM silent is configured on the interface.
l A PIM neighbor filtering policy is configured on the interface and the address of the PIM
neighbor is filtered out by the policy.
l If the interface is configured to deny Hello messages without Generation IDs, the interface
discards all the Hello messages received from PIM neighbors without any Generation IDs.
As a result, the PIM neighbor relationship cannot go Up. This case applies to the scenario in
which Huawei devices are intercommunicating with non-Huawei devices.

check whether any of the preceding PIM configurations exist on the interface.
l If any of the preceding PIM configurations exist, correct it.

l If the fault persists after the preceding operations are complete, go to Step 4.

Equipment

----End
Relevant Alarms
None.
Relevant Logs
PIM/4/NBR_DOWN
6.2.3 The RPT on a PIM-SM Network Fails to Forward Data
Common Causes
l The unicast route from the multicast device to the RP is unavailable.

l The RP addresses on multicast devices are inconsistent.
l The downstream interface on the multicast device does not receive any (*, G) Join
messages.
l PIM-SM is not enabled on interfaces.
l The RPF route to RP is incorrect, for example, the unicast route contains a loop.
l Configurations are incorrect, for example, the configurations of the TTL, MTU, or multicast
boundary are improper.
After a PIM-SM network is configured, the RPT cannot forward data.

Equipment
Figure 6-4 Troubleshooting flowchart: the RPT on a PIM-SM network fails to forward data
The RPT on a PIM-SM network
fails to forward data Check next hop along
Re-check RPF path from the
receiver's DR to RP No
the DR
Ensure Yes Seek
Do correct (*, G) Yes
That the current router technical
entries exist?
is an RP? support
No
Has the
downstream interface No Is fault Yes
Rectify the interface fault
received Join rectified?
messages?
Yes No
Is PIM-SM No Enable PIM-SM on Is fault Yes

enabled on interfaces? interfaces rectified?
Yes No
Are RP No Yes
Rectify the faults on the Is fault
configurations
static RP or BSR RP rectified?
correct?
Yes No
Is the RPF route No Rectify the fault of unicast Is fault Yes

to the RP available? routes rectified?
Yes No
No Is the
interface that forwards
multicast data the
receiver's DR?
Yes
Is the Change the outbound

outbound interface of the Yes interface of the RPF route Is fault Yes
RPF route to the RP a TE to the RP, ensuring that it is rectified?
tunnel interface? not a TE tunnel interface
No No
Is a multicast Yes Yes

Remove the configurations Is fault
boundary configured on the
of the multicast boundary rectified?
interface?
No No
Remove the configurations
Yes of the source-policy or Is fault Yes
Is a source-policy
configured? change the configurations rectified?
of the ACL
No
No
Do correct (*, G) Yes

entries exist?
No
End

Equipment
Procedure
Step 1 Check that the PIM routing table contains the correct (*, G) entries.
Run the display pim routing-table group-address command on the device to check whether
the PIM routing table contains the correct (*, G) entries. Focus on checking whether the
downstream interface list contains downstream interfaces to forward data to all (*, G) group
members.
l If the (*, G) entries exist and are all correct in the PIM routing table, run the display
multicast forwarding-table group-address command every 15 seconds to check whether
the forwarding table contains (S, G) entries associated with the (*, G) entries and whether
the value of the Matched field in the command output continues to increase.
If the forwarding table contains associated (S, G) entries and the value of the
Matched field continues to increase, the upstream device can normally forward
multicast data to the current device but the current device fails to forward the data
downstream, for example, a too small TTL value or a forwarding fault.
If the forwarding table does not contain the associated (S, G) entries or the value of the
Matched field remains unchanged, do as follows:
If the current device is not an RP, the current device has not received any multicast
data. This fault may be caused by the upstream device. Then check whether the PIM
routing table on the upstream device contains correct (S, G) entries.
If the current device is already an RP, it indicates the RPT has been set up but the
RP fails to receive the multicast data from the multicast source. This fault may be
caused by a failure in source's DR registration. In such a case, contact Huawei
technical support personnel.
l If the PIM routing table does not contain correct (*, G) entries, go to Step 2.
Step 2 Check that the downstream interface has received Join messages.
Run the display pim control-message counters interface interface-type interface-number
message-type join-prune command to check whether the number of received Join/Prune
messages on the downstream interface continues to increase.
l If the number of received Join/Prune messages on the downstream interface does not
increase, run the display pim control-message counters interface interface-type
interface-number message-type join-prune command on the downstream device to check
whether the downstream device has sent Join/Prune messages upstream.
If the command output shows that the number of sent Join/Prune messages continues
to increase, the downstream device has sent Join/Prune messages. This fault may be
caused by a failure in PIM neighbor communication. In such a case, contact Huawei
If the command output shows that the number of sent Join/Prune messages does not
increase, the downstream device experiences a fault. Then locate the fault.
l If the number of received Join/Prune messages on the downstream interface continues to
increase, go to Step 3.
Step 3 Check that PIM-SM is enabled on interfaces.
The following interfaces are easy to be ignored in enabling PIM-SM:

Equipment
l RPF neighboring interface to the RP

l RPF interface to the RP
l Interface directly connected to shared network segment of user hosts, that is, downstream
interface of the receiver's DR
Run the display pim interface verbose command to check PIM configurations on the interface.
Focus on checking whether PIM-SM is enabled on the preceding interfaces.
l If the command output does not contain information about an interface on the device or the
PIM mode of an interface is dense, run the pim sm command on the interface.
If the system displays "Error: Please enable multicast in the system view first." when you
configure PIM-SM on the interface, run the multicast routing-enable command in the
system view to enable the multicast function first and enable PIM-SM on the interface.
l If PIM-SM has been enabled on all the interfaces on the device, go to Step 4.
Step 4 Check that the RP information is correct.
Run the display pim rp-info command on the device to check whether the device has learned
information about the RP serving a specific group and whether the RP information of the same
group on all other devices is consistent.
l If no RP information is displayed or RP information on the devices are inconsistent, do as

follows:
If the static RP is used on the network, run the static-rp command on all the devices to
make information about the RP serving a specific group consistent.
If the dynamic RP is used, contact Huawei technical support personnel.
l If RP information of a specific group is consistent on all the devices, go to Step 5.
Step 5 Check that an RPF route to the RP is available.
Run the display multicast rpf-info source-address command on the device to check whether
there is an RPF route to the RP.
l If the command output does not contain an RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
l If the command output shows an RPF route to the RP, do as follows:
If the command output shows that the RPF route is a static multicast route or an MBGP
route, run the display current-configuration command to check whether the static
multicast route or the MBGP route is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
l If the command output shows an RPF route to the RP and the route is properly configured,
go to Step 6.
Step 6 Check that the interface that forwards multicast data is a receiver's DR.
Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.

Equipment
l If the DR information in the command output is not marked local, troubleshoot the involved
DR following the preceding steps.
l If the DR information in the command output is marked with local, go to Step 7.
Step 7 Check whether the outbound interface of the RPF route to the RP is a TE tunnel interface.
the outbound interface of the RPF route to the RP is a TE tunnel interface.
The multicast routing is reverse to unicast routing. The TE tunnel is unidirectional and hence it
does not support multicast.
l If the command output shows that the outbound interface of the RPF route is a TE tunnel
interface, enable the local MT feature or change the configurations of the static multicast
route to ensure that the outbound interface of the RPF interface is not a TE tunnel interface.
l If the command output shows that the outbound interface of the RPF route is not a TE tunnel
interface, go to Step 8.
Step 8 Check whether a multicast boundary is configured on the interface.
Run the display current-configuration interface interface-type interface-number command

on the device to check whether a multicast boundary is configured on the interface.
l If the configuration of the interface contains multicast boundary, a multicast boundary is

configured on the interface. Then run the undo multicast boundary { group-address
{ mask | mask-length } | all command to delete the configuration of the multicast boundary
or re-plan the network to ensure that no multicast boundary is configured on the RPF
interface or the RPF neighboring interface.
l If no multicast boundary is configured on the interface, go to Step 9.
Step 9 Check whether a source policy is configured.
Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.
l If the configuration contains source-policy acl-number, it indicates a source-based

filtering rule is configured. If the received multicast data is blocked by the ACL rule, the
multicast data is discarded. Then run the undo source-policy command to delete the
configuration of the ACL rule or reconfigure an ACL rule to ensure that the multicast data
can be normally forwarded.
l If no source policy is configured, go to Step 10.
Step 10 Check whether the PIM routing table contains the correct (*, G) entries.
Run the display pim routing-table group-address command on the device to check whether
the PIM routing table contains the correct (*, G) entries. For details, see Step 1.
If the fault persists after the preceding troubleshooting procedures are complete, contact Huawei
----End

Equipment
Relevant Alarms
None.
Relevant Logs
None.
6.2.4 The SPT on a PIM-SM Network Fails to Forward Data
Common Causes
l The downstream interface on the multicast device does not receive any (S, G) Join
messages.
l PIM-SM is not enabled on the interface.
l The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
l Configurations are incorrect. For example, the configurations of the TTL, MTU, switchover
threshold, or multicast boundary are improper.
After the PIM-SM network is configured, the SPT fails to forward data.

Equipment
Figure 6-5 Troubleshooting flowchart: the SPT on a PIM-SM network fails to forward data
The RPT on a PIM-SM
network fails to forward data Check the next hop along the
RPF path from the receiver's
Re-check DR to the multicast source
the DR No
Yes Ensure Yes
Do correct (*, G) entries Seek technical
that the current router is
exist? support
an RP
No
Has the
downstream interface Is fault Yes
received Join messages? Rectify the interface fault
rectified?
No
No
Yes
No Is fault Yes
Is PIM-SM enabled Enable PIM-SM on interfaces
on interfaces? rectified?
Yes No
Is the RPF
No Rectify the fault of unicast Yes
route to the multicast Is fault rectified?
source available? routes
Yes No
Is the interface
No that forwards multicast
data the receiver's DR?
Yes
Is the
outbound interface Yes Change the outbound interface
of the RPF route to the RP of the RPF route to the Yes
Is fault rectified?
a TE tunnel interface? multicast source, ensuring that
it is not a TE tunnel interface
No
No
Is a multicast boundary Yes Remove the configurations of Is fault Yes

configured on the the multicast boudnary rectified?
interface?
No No
Yes Remove the configurations of the Yes

Is a source-policy Is fault
source-policy or change the
configured? rectified?
configurations of the ACL
No No
Yes
Do correct (*, G) entries
exist?
No End

Equipment
Procedure
Step 1 Check that the PIM routing table contains the correct (S, G) entries.
Run the display pim routing-table command on the device to check whether the PIM routing
table contains the correct (S, G) entries.
l If the PIM routing table contains the correct (S, G) entries, do as follows:
Check whether the entry has an SPT flag.
If the multicast group is in the ASM group address range, the SPT switchover is
triggered by the RP, and the upstream interface of the RP is a register interface, the
RP has received the Register message from the source's DR but the SPT fails to be
established. Then contact Huawei technical support personnel.
If the multicast group is in the ASM group address range, the SPT switchover is
triggered by the receiver's DR, and the upstream interface is an RPF interface to the
RP but not the SPT interface to the multicast source, the SPT fails to be established.
Then run the display current-configuration configuration pim command on the
receiver's DR to view the current configurations in the PIM view. If the command
output shows spt-switch-threshold traffic-rate or spt-switch-threshold infinity,
run the undo spt-switch-threshold command to delete the configurations of the
traffic rate or run the spt-switch-threshold traffic-rate command to reconfigure a
proper traffic rate.
Check whether the downstream interface list contains downstream interfaces to forward
data to all group members.
If the (S, G) entries exist and are all correct in the PIM routing table, run the display
multicast forwarding-table command to view the (S, G) entries in the forwarding
table and check whether the value of the Forwarded field in the command output
continues to increase. The value of the Matched field is not updated in time.
Therefore, wait for several minutes after running the display multicast forwarding-
table command.
If the value of the Matched field continues to increase, the upstream device can
normally forward multicast data to the current device but the current device fails
to forward the data downstream. Then contact Huawei technical support
personnel.
If the value of the Matched field remains unchanged, do as follows:
If the current device is not a source's DR, the current device has not received
any multicast data. This fault may be caused by the upstream device. Then
check whether the PIM routing table on the upstream device contains correct
(S, G) entries.
If the PIM routing table on the upstream device does not contain the correct
(S, G) entries, troubleshoot the upstream device following the preceding
steps.
If the PIM routing table on the upstream device contains correct (S, G)
entries, but the value of the Matched field still remains unchanged,
contact Huawei technical personnel.

Equipment
If the current device is already a source's DR, SPT has been set up but the
source's DR fails to forward the multicast data along the SPT. Then contact
Huawei technical support personnel.
l If the PIM routing table does not contain the correct (S, G) entries, go to Step 2.
Step 2 Check that the downstream interface has received Join messages.
NOTE
If the current device is a receiver's DR, skip this step.
If the downstream interface does not receive any (S, G) Join messages, the possible causes may
be as follows:
l A fault occurs on the downstream interface.
l PIM-SM is not enabled on the downstream interface.
Run the display pim control-message counters interface interface-type interface-number

message-type join-prune command to check whether the number of received Join/Prune
messages on the downstream interface continues to increase.
l If the number of received Join/Prune messages on the downstream interface does not
increase, run the display pim control-message counters interface interface-type
interface-number message-type join-prune command on the downstream device to check
whether it has sent Join/Prune messages upstream.
If the command output shows that the number of sent Join/Prune messages continues
to increase, the downstream device has sent Join/Prune messages. This fault may be
caused by a failure in PIM neighbor communication. In this a case, contact Huawei
If the command output shows that the number of sent Join/Prune messages does not
increase, the downstream device experiences a fault. Then locate the fault.
l If the number of received Join/Prune messages on the downstream interface continues to
increase, go to Step 3.
Step 3 Check that PIM-SM is enabled on interfaces.
The following interfaces are easily overlooked when PIM-SM is enabled:

l RPF neighboring interface to the multicast source
l RPF interface to the multicast source
NOTE
In PIM-SM network deployment, enabling the multicast function on all the devices on the network and
enabling PIM-SM on all the interfaces are recommended.
Run the display pim interface verbose command to check PIM configurations on the interface.
Focus on checking whether PIM-SM is enabled on the preceding interfaces.
l If the command output does not contain information about an interface on the device or the
PIM mode of an interface is dense, run the pim sm command on the interface.
If the system displays "Error: Please enable multicast in the system view first." when you
configure PIM-SM on the interface, run the multicast routing-enable command in the
system view to enable the multicast function first and run the pim sm command in the
interface view to enable PIM-SM on the interface.
l If PIM-SM has been enabled on all the interfaces on the device, go to Step 4.

Equipment
Step 4 Check that an RPF route to the multicast source is available.
an RPF route to the multicast source exists.
l If the command output does not contain an RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
l If the command output shows an RPF route to the multicast source, do as follows:
If the command output shows that the RPF route is a static multicast route or an MBGP
route, run the display current-configuration command to check whether the static
multicast route or the MBGP route is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
l If the command output shows an RPF route to the RP and the route is properly configured,
go to Step 5.
Step 5 Check that the interface that forwards multicast data is a receiver's DR.
Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.
l If the DR information in the command output is not marked local, troubleshoot the involved
DR following the preceding steps.
l If the DR information in the command output is marked local, go to Step 6.
Step 6 Check whether the outbound interface of the RPF route is a TE tunnel interface.
the outbound interface of the RPF route to the multicast source is a TE tunnel interface.
The multicast routing is based on the RPF check but the TE tunnel is unidirectional. Therefore,
TE tunnels are not applicable to the multicast scenario.
l If the command output shows that the outbound interface of the RPF route is a TE tunnel
interface, enable the local MT feature or change the configurations of the static multicast
route to ensure that the outbound interface of the RPF interface is not a TE tunnel interface.
l If the command output shows that the outbound interface of the RPF route is not a TE tunnel
interface, go to Step 7.
Step 7 Check whether a multicast boundary is configured on the interface.
Run the display current-configuration interface interface-type interface-number command

on the device to check whether a multicast boundary is configured on the interface.
l If the configuration of the interface contains multicast boundary, a multicast boundary is

configured on the interface. Then run the undo multicast boundary { group-address
{ mask | mask-length } | all command to delete the configuration of the multicast boundary
or re-plan the network to ensure that no multicast boundary is configured on the RPF
interface or the RPF neighboring interface.
l If no multicast boundary is configured on the interface, go to Step 8.
Step 8 Check whether a source policy is configured.

Equipment
Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.
l If the configuration contains source-policy acl-number, a source filtering rule is
configured. If the received multicast data is blocked by the ACL rule, the multicast data is
discarded. Then run the undo source-policy command to delete the configuration of the
ACL rule or reconfigure an ACL rule to ensure that the multicast data can be normally
forwarded.
l If no source policy is configured, go to Step 9.
Step 9 Check whether the PIM routing table contains the correct (S, G) entries.
Run the display pim routing-table command on the device to check whether the PIM routing
table contains the (S, G) entries. For details, see Step 1.
If the fault persists after the preceding troubleshooting procedures are complete, contact Huawei
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2.5 MSDP Peers Cannot Generate Correct (S, G) Entries
Common Causes
l The MSDP peer to initiate SA messages is not configured on the RP.
l The logical RP is not configured on the devices to be deployed with anycast RP or
configurations of the logical RP are incorrect.
l MSDP peer relationships are not set up between every two members in a mesh group.
l The used intra-domain multicast protocol is not PIM-SM.
l The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
l Configurations are incorrect. For example, the configurations of the SA policy, import
policy, TTL, switchover threshold, or multicast boundary are improper.
l The SA message fails to pass RPF check.
After configurations are complete on a multicast network, MSDP peers cannot generate correct
(S, G) entries.

Equipment
Figure 6-6 Troubleshooting flowchart: MSDP peers cannot generate correct (S, G) entries
MSDP peers cannot generate
correct (S, G) entries
Ensure that interfaces

No are correctly configured Yes
Are MSDP Is fault
peers in the Up state? and peers are reachable rectified?
through unicast routes
Yes No
No Is fault Yes
Is SA cache enabled? Enable SA cache
rectified?
Yes No
Have any SA Yes Ensure that MSDP peers

Is fault Yes
messages reached can receive SA
rectified?
MSDP peers? messages
No No
Are export Yes Remove or change the

Is fault Yes
policies configured on MSDP configurations of the rectified?
peers? export policies
No No
Yes
Remove or change the Is fault
Are import policies Yes
configurations of the rectified?
configured on MSDP
import policies
peers?
No No
Does current
No MSDP peer receive multicast
data from the multicast
source?
Yes
Yes Change the

Is the current MSDP Is fault Yes
configurations of the RP
peer an RP? rectified?
or MSDP
No No
Are import-source Yes Remove or change the

policies configured on Is fault Yes
configurations of the
the current MSDP rectified?
import-source policies
peer? No
No

Equipment
Context
NOTE
Procedure
Step 1 Check that the status of MSDP peers is Up.
Run the display msdp brief command on the devices setting up an MSDP peer relationship to
check whether the status of MSDP peers is Up.
l If the command output shows that the status of MSDP peers is Down, check whether the
MSDP peer interfaces are correctly configured and whether the MSDP peers can ping each
other successfully. If the ping fails, perform troubleshooting based on 4.2.1 The Ping
Operation Fails.
l If the MSDP peers are both in the Up state, go to Step 2.
Step 2 Check that SA cache is enabled.
Run the display current-configuration configuration msdp command on MSDP peers to view
the current configurations in the MSDP view.
l If the command output shows undo cache-sa-enable, SA cache is disabled in the MSDP
view. In this case, run the cache-sa-enable command in the MSDP view to enable SA
cache.
l If SA cache has been enabled, go to Step 3.
Step 3 Check that SA messages have reached MSDP peers.
Run the display msdp sa-count command on MSDP peers to check the contents of the SA
cache.
l If there is no command output, contact Huawei technical support personnel.

l If the value of the Number of source or Number of group field in the command output
is non-zero, SA messages have reached the peers. Then go to Step 4.
Step 4 Check whether export policies are configured on the MSDP peers.
Run the display current-configuration configuration msdp command in the MSDP view on
the MSDP peers to view the current configurations.
l If export policies are configured on the MSDP peers, do as follows:

If the command output shows the configurations of the peer peer-address sa-policy
export command without any parameters, the MSDP peers are disabled from
forwarding messages received from the multicast source. Then run the undo peer peer-
address sa-policy export command to delete the configurations of export policies.
export acl advanced-acl-number command with an ACL specified, MSDP peers can
forward only the (S, G) entries permitted by the ACL. Then check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the

Equipment
ACL. You can run the undo peer peer-address sa-policy export command to delete
the configurations of the ACL or change the configurations of the ACL rules.
l If no export policies are configured on MSDP peers, go to Step 5.
Step 5 Check whether import policies are configured on MSDP peers.
the MSDP peers to view the current configurations.
l If import policies are configured on MSDP peers, do as follows:

import command without any parameters, the MSDP peers are disabled from receiving
messages from the multicast source. Run the undo peer peer-address sa-policy
import command to delete the export policy configurations.
import acl advanced-acl-number command with an ACL specified, MSDP peers can
receive only the (S, G) entries permitted by the ACL. Check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the
ACL. Run the undo peer peer-address sa-policy import command to delete the
configurations of the ACL or change the configurations of the ACL rule.
l If no import policies are configured on the MSDP peers, go to Step 6.
Step 6 Check whether the current MSDP peer receives multicast data from the multicast source.
l If the current MSDP peer does not receive multicast data from the multicast source,
troubleshoot the upstream device following the preceding steps.
l If the current MSDP peer receives multicast data from the multicast source, go to Step 7.
Step 7 Check whether the current MSDP peer is an RP.
Run the display pim routing-table command on the MSDP peer closest to the multicast source
to view the routing table.
l If the (S, G) entry does not have a 2MSDP flag, the MSDP peer is not an RP. Change the
configurations of the RP or MSDP peer on the PIM-SM network to ensure that the MSDP
peer is an RP.
l If the MSDP peer is an RP, go to Step 8.
Step 8 Check whether import-source policies are configured on the current MSDP peer.
The import-source [ acl acl-number ] command is used to enable an MSDP peer to filter the
(S, G) entries to be advertised based on source addresses when creating SA messages. The MSDP
peer can control the transmission of multicast source information. By default, SA messages can
be used to advertise information about all known multicast sources.
the MSDP peer closest to the multicast source to view the current configurations.
l If import-source policies are configured on the MSDP peer, do as follows:

If the command output shows the configurations of the import-source command
without any parameters, the MSDP peer is disabled from advertising multicast source
information. Then run the undo import-source command to delete the import-source
policy configurations.

Equipment
If the command output shows the import-source acl acl-number command with an
ACL specified, the MSDP peer advertises only (S, G) information matching the ACL.
Then check whether ACL-related commands are run on the MSDP peer and whether
(S, G) entries are permitted by the ACL. Then run the undo import-source command
to delete the configurations of the ACL or change the configurations of the ACL rule.
l If no import policies are configured on the MSDP peers, go to Step 9.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2.6 The Multicast Device Cannot Generate IGMP Entries
Common Causes
l Multicast is not enabled on the device.

l IGMP is not enabled on the interface or the configured IGMP version is incorrect.
l The interface receives an EXCLUDE message in which the group address is within the
SSM group address range.
l A multicast boundary or a group policy is configured on the interface.
l A limit on the maximum number of IGMP group memberships is configured on the
interface.
After configurations are complete on a multicast network, the multicast device cannot generate
IGMP entries.

Equipment
Figure 6-7 Troubleshooting flowchart: the multicast device cannot generate IGMP entries
Multicast device cannot

generate IGMP entries
Is fault Yes
No
Is multicast enabled? Enable IGMP rectified?
No
Yes
Is fault Yes
No Rectify the
Is Interface in Up state? interface fault rectified?
No
Yes
Is IGMP No Enable IGMP enabled Is fault Yes
enabled on interface? on interface rectified?
No
Yes
Multicast Yes Ensure that the group Yes
Is fault
Group in SSM group address address is in the SSM
rectified?
range? group address range
No
No
Ensure that the group
Is range of groups Yes
is in the range of the Is fault Yes
that hosts can join limited on groups that the rectified?
interface? interface serves No
No
Maximum Increase maximum

Number of IGMP group Yes Yes
number of IGMP group Is fault
memberships limited on memberships on the rectified?
interface? interface or remove limit No
No
Increase maximum
Maximum Yes Is fault Yes
number of IGMP group
of group memberships limitedYes rectified?
memberships in
in current instance?
interface or remove limit
No
No
Increase maximum of
Maximum Yes Yes
global IGMP group Is fault
Of IGMP group
memberships on rectified?
memberships is limited
interface or remove
globally?
limit No
No
Are The
Yes Yes
Number of Entries And Re-plan network Is fault
That of interfaces below the deployment rectified?
upper limit?
No
No

Equipment
Context
NOTE
Procedure
Step 1 Check that multicast is enabled on the device.
Run the display current-configuration command on the device that is directly connected to
hosts to check the current configurations of the device.
l If the command output does not contain multicast routing-enable, run the multicast
routing-enable command in the system view to enable multicast on the device first and
then complete other IGMP configurations. For details, see the ATN Configuration Guide
- IP Multicast.
l If multicast has been enabled on the device, go to Step 2.
Run the display interface interface-type interface-number command on the device to check the
configuration of the interface directly connected to the network segment of the hosts.
l If the command output shows interface-type interface-number current state: DOWN,

the interface is physically Down. Check the networking and ensure that the interface is
properly connected.
l If the command output shows Line protocol current state : DOWN, the protocol status
of the interface is Down. Perform the following operations:
Check whether the interface is in the shutdown state.
Run the display current-configuration interface interface-type interface-number
command to check the current configurations of the interface. If the command output
shows shutdown, run the undo shutdown command in the interface view.
Check whether an IP address is configured for the interface.
Run the display current-configuration interface interface-type interface-number
command to check the IP address of the interface. If an IP address is not configured for
the interface or the configured IP address is on a different network segment from the
hosts, run the ip address ip-address { mask | mask-length } command to reconfigure
an IP address for the interface and ensure that the IP address is on the same network
segment with those of the hosts.
l If the interface status is Up, go to Step 3.
Step 3 Check that IGMP is enabled on the interface.

check the current configurations of the interface that is directly connected to the hosts.
l If the command output does not contain igmp enable, neither IGMP is enabled on the
interface. Run the igmp enable command in the interface view to enable IGMP.

Equipment
l If IGMP has been enabled on the interface, go to Step 4.

Step 4 Check whether the multicast group G of the EXCLUDE message is in the SSM group address
range.
Run the display current-configuration configuration pim command on the device that is
directly connected to hosts to check the current configurations in the PIM view. If the command
output shows ssm-policy basic-acl-number, the SSM group address range is defined on the
device. Then, run the display acl acl-number command to check the ACL configurations.
l If the command output shows that the multicast group G is in the address range permitted
by the ACL, G belongs to the SSM group address range. Ensure that IGMPv3 is running
between the host and the interface on the device.
If the version of IGMP running on the host cannot be upgraded, enable SSM mapping on
the device interface and create static SSM mapping rules for G.
l If the command output shows that the multicast group G is in the address range denied by
the ACL, G belongs to the ASM group address range. Adjust the group address range
specified in the ACL so that G is in the address range permitted by the ACL.
l If the multicast group G is not in the SSM address range and the configured IGMP version
is correct, go to Step 5.
Step 5 Check whether the range of groups that the hosts can join is limited on the interface.
Run the display igmp interface interface-type interface-number command (in the IPv4
scenario) to check the current configurations of the interface that is directly connected to the
hosts.
l If the group-policy field in the command output is not none, the range of groups the hosts
can join is limited on the interface. IGMP then filters Report or Join messages of the hosts
according to the ACL. Check the range of the groups permitted by the ACL. If the multicast
group G is not in this range, modify the ACL or delete the ACL configuration to ensure
that IGMP can serve members of G.
l If the range of groups that the hosts can join is not limited on the interface, go to Step 6.
Step 6 Check whether the maximum number of IGMP group memberships is limited on the interface.
Run the display igmp interface interface-type interface-number command (in the IPv4
scenario) to check the current configurations of the interface that is directly connected to the
hosts.
l If the IGMP limit field in the command output does not display -, the maximum number
of IGMP group memberships is limited on the interface. Run the igmp limit number
command (in the IPv4 scenario) to increase the IGMP limit, or run the undo igmp limit
command (in the IPv4 scenario) to delete the configured IGMP limit.
l If the IGMP limit field in the command output is -, go to Step 7.
Step 7 Check whether the maximum number of IGMP group memberships is limited in the current
instance.
Run the display current-configuration configuration igmp command (in the IPv4 scenario)
to check the configurations of the IGMP limit limit in the current instance.
l If the command output shows the configurations of the IGMP limit for the instance, the
maximum number of IGMP group memberships is limited in this instance. Then, run the
limit number command in the IGMP view of the instance (in the IPv4 scenario) to increase

Equipment
the IGMP limitt, or run the undo limit command in the IGMP view of the instance (in the
IPv4 scenario) to delete the configured IGMP limit.
l If the command output does not contain the configurations of the IGMP limit for the
instance, go to Step 8.
Step 8 Check whether the maximum number of IGMP group memberships is limited globally.
Run the display current-configuration | include igmp global limit command (in the IPv4
scenario) to check the global configurations of the IGMP limit.
l If there is command output, the maximum number of IGMP group memberships is limited
globally. Then, run the igmp global limit number command in the system view (in the
IPv4 scenario) to increase the IGMP limit, or run the undo igmp global limit command in
the system view (in the IPv4 scenario) to delete the set IGMP limit.
l If there is no command output, go to Step 9.
Step 9 Check that the number of entries and number of interfaces are below the upper limit defined in
the product license.
l If the number of entries and number of interfaces exceed the upper limit defined in the
product license, re-plan network deployment.
l If the fault persists after the preceding troubleshooting procedures are complete, go to Step
10.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2.7 Trouble Cases
Receivers Attached to a Multicast Interface Experience Video Lagging
Fault Symptom
On the network shown in Figure 6-8, multicast services are deployed. ATN A and ATN C have
Receivers attached to them. Receiver attached to ATN A experiences video lagging.

Equipment
Figure 6-8 Networking diagram of on-demand multicast programs on an interface
Ethernet
PIM SM
RouterB ATN C
Source
GE0/2/0
ATN A
GE0/2/1 Receiver
Receiver
Fault Analysis
1. Check whether the multicast source works properly.
Receiver attached to ATN C can properly receive multicast data. Therefore, it can be
concluded that the multicast source is normal.
2. Check whether Receiver attached to ATN A has sent a Report message.
On ATN A, run the display igmp routing-table command to check whether information
about IGMP Report messages is displayed. Information about GE0/2/1 on ATN A is
displayed:
Total 1 IGMP Group reported
The command output indicates that ATN A has received a Report message.
3. Check whether multicast forwarding entries are correctly generated, that is, whether
ATN A has a downstream interface to which Receiver attaches.
Run the display multicast forwarding-table command on ATN A to check whether
forwarding entries contain downstream interfaces. The multicast forwarding entry list
contains the following information:
1: GE0/2/1
It indicates that ATN A has a downstream interface to which Receiver attaches.
4. Check the number of multicast packets sent and received by ATN A.
l Run the display this interface command in the view of GE0/2/0 on ATN A to check
the number of received multicast packets. The following information is displayed:
Input:
Unicast: 21839, Multicast: 4139477
l Run the display this interface command in the view of GE0/2/1 on ATN A to check
the number of sent multicast packets. The following information is displayed:

Equipment
Output:
Unicast: 3, Multicast: 366591
The preceding information shows that GE0/2/0 has received 4,139,477 multicast packets
but GE0/2/1 has sent out only 366,591 multicast packets. This indicates that about 90% of
the packets are lost.
Run the display this command in the view of GE0/2/1 on ATN A to check configurations
of GE0/2/1. The following information is displayed:
igmp static-group 224.0.1.0
The preceding information shows that Receiver attached to ATN A has joined a multicast
group whose address is in the reserved multicast group address range. (An interface board
reserves the multicast group addresses 224.0.0.0 through 224.0.1.255 for protocol packets.)
Therefore, after receiving multicast packets, interface board considers them as protocol
packets rather than data packets and directly delivers the packets to the main control board
instead of forwarding them to Receiver.
Because the rate at which the interface board delivers protocol packets is limited, the main
control board receives only some packets. The main control board reserves multicast group
addresses 224.0.0.0 through 224.0.0.255 for protocol packets. After receiving multicast
packets, the main control board does not consider the packets as protocol packets and
forwards the packets to the interface board based on the MFIB. Therefore, some traffic fails
to be sent out from GE 1/0/5, in which case Receiver experiences video lagging.
Procedure
l Change the address of the multicast group that Receiver joins. Addresses 224.0.0.0 through
224.0.0.255 are reserved multicast group addresses that cannot be used for multicast data
packet forwarding.
After the preceding operations, multicast data packets can properly reach Receiver. The
fault is rectified.
----End
Summary
Addresses 224.0.0.0 through 224.0.0.255 are reserved multicast group addresses that cannot be
used for multicast data packet forwarding. Therefore, avoid using the addresses within this range
as the group address of multicast data packets.
PIM Inter-Domain MSDP Failed
Fault Symptom
As shown in Figure 6-9, each PIM-SM domain has two RPs and MSDP is run between RPs.
Anycast RP is used in each PIM domain and RPs are statically designated. In addition, MSDP
is deployed between PIM-SM2 and PIM-SM1, and between PIM-SM3 and PIM-SM1. PIM-
SM3 cannot obtain (S, G) information about the multicast source in PIM-SM2.

Equipment
Figure 6-9 Networking diagram of PIM inter-domain MSDP
S1
PIM-SM1 Level-1
PIM-SM2 PIM-SM3
Level-2
Level-2
S1 S1
Fault Analysis
PIM-SM3 cannot receive (S, G) information about the multicast source. The possible cause may
be that (S, G) messages are discarded. Then, check the networking.
1. MSDP performs the RPF check after receiving SA messages to avoid loops.
2. PIM-SM2 originates SA messages and sends messages to PIM-SM1; PIM-SM1 then
forwards the messages to PIM-SM3. After receiving the SA messages, the MSDP peer in
PIM-SM3 finds that the source IP of the messages is not the next hop of the route to the
source's RP. The RPF check fails and the peer discards the messages.
3. PIM-SM1 originates SA messages and sends messages to PIM-SM3. Because the source's
RP address and the source IP of SA messages are the same, the RPF check succeeds and
PIM-SM3 can receive (S, G) messages from PIM-SM1.
Procedure
Step 1 There are three solutions to this problem.
l Fully connect all MSDP peers.
Advantage: After full connections are set up, RPF check succeeds and loops are avoided.
In addition, peers can rapidly respond to network changes.
Disadvantages: The number of MSDP peer connections are added. With the increase in
network nodes, configuration workloads are heavy.
This solution is recommended.
l Configure a static RPF peer relationship between the RP in PIM-SM3 and the RP in PIM-
SM1 to ensure that PIM-SM3 can properly receive SA messages.

Equipment
Advantage: The configuration is simple. You only need to run the static-rpf-peer peer-
address [ rp-policy ip-prefix-name ] command to configure a static RPF peer relationship
between the RP in PIM-SM3 and the RP in PIM-SM1.
Disadvantage: Static configuration cannot rapidly respond to network changes.
l Establish an MBGP connection between MSDP peers in PIM-SM1 and PIM-SM3 to
advertise remote RP routes to PIM-SM3 through MBGP. This solution ensures correct RPF
check.
This solution is not recommended. Because there are services running on the network, MBGP
connections will cause the flapping of unicast BGP neighbor relationships.
----End
Summary
Full-connected MSDP peers ensure correct RPF check and avoid SA message flooding, thereby,
ensuring correctness of multicast entries.
In addition, to ensure RP reliability and node backup, there is no need to divide one AS into
multiple multicast domain. You only need to configure anycast RP on the nodes that need to set
up fully connected MSDP connections.

Equipment
Troubleshooting 7 QoS
7 QoS
About This Chapter
7.1 Troubleshooting of Queue Scheduling Based on Traffic Classification

This section describes the notes about configuring queue scheduling based on traffic
classification, and provides the queue scheduling based on traffic classification troubleshooting
flowchart and the troubleshooting procedure.
7.2 Troubleshooting HQoS

This section describes the notes about configuring HQoS, and provides the HQoS
troubleshooting flowchart and troubleshooting procedure.

Equipment
7.1 Troubleshooting of Queue Scheduling Based on Traffic

Classification
This section describes the notes about configuring queue scheduling based on traffic
classification, and provides the queue scheduling based on traffic classification troubleshooting
flowchart and the troubleshooting procedure.
7.1.1 Typical Networking

Figure 7-1 shows a typical networking of queue scheduling based on traffic classification.
Figure 7-1 Networking of queue scheduling based on traffic classification
GE0/2/0 GE8/0/0 GE1/0/1

GE0/2/1 GE8/0/1 GE8/0/1
ATNA CX-B CX-C
The solution in the above figure includes:
1. Send the traffic of ef level with 700 M, the traffic of af1 level with 100 M, the traffic of
af2 level with 200 M, and the traffic of be level with 300 M from ATN A. The bandwidth
of GE 1/0/1 of CX-B is 1000 M. Congestion is caused.
2. According to queue scheduling, all the traffic of ef level can be transmitted from GE 1/0/1,
and the traffic of af1, af2, be levels can be separately transmitted with 50 M, 100 M, 150
M.
7.1.2 Troubleshooting Flow

For the network shown in Figure 7-1, the traffic at each level sent from ATN A is not forwarded
correctly after reaching CX-B based on the expected queue scheduling.
Perform the troubleshooting flow shown in Figure 7-2.

Equipment
Figure 7-2 Troubleshooting flow of queue scheduling based on traffic classification
A fault occurs
Check
No Isolate the
the network
network fault
connectivity
Yes
Check
whether simple No Configure simple traffic
traffic classification is classification on the
configured on the
inbound inbound interface
interface
Yes
Check
whether queue No Configure queue
scheduling is
configured scheduling correctly
correctly
Yes
Seek Huawei No Is the fault

technical support removed?
Yes
End
7.1.3 Troubleshooting Procedures
Procedure
Step 1 Check the network connectivity
Display the state of each interface through the display ip interface brief command.
l Up indicates available.
l Down indicates unavailable.
When the interface is Down, check weather connection of the line is normal and weather the
interface is shutdown.
Step 2 Check that simple traffic classification is configured on the inbound interface

Equipment
Display whether simple traffic classification is enabled through the display this command in
the inbound interface view of GE 8/0/1 on CX-B. That is, whether the trust upstream command
is configured.
Step 3 Check the mapping of the domain
Check the mapping of the domain in global configuration mode through the display diffserv
domain command. That is, whether the mapping meet the requirement.
Step 4 Check queue scheduling configured
Display whether the correct queue scheduling is configured to forward the traffic at each level
through the display this command in the outbound interface view of GE 1/0/1 on CX-B. That
is, whether the commands such as port-queue ef, port-queue af1, port-queue af2, port-queue
be are configured.
Confirm that the shaping for the traffic at each level is set correctly.
----End
7.2 Troubleshooting HQoS

This section describes the notes about configuring HQoS, and provides the HQoS
troubleshooting flowchart and troubleshooting procedure.
7.2.1 Typical Networking

Typical networking of HQoS is shown in Figure 7-3 and Figure 7-4.HQoS troubleshooting in
this chapter is described based on these two networking figures.
HQoS on the User-Side Primary Interface of the PE
Figure 7-3 Networking for HQoS configuration on the primary interface

PE1 PE2
GE0/2/4 IP
172.1.2.2/24 backbone
network
GE0/2/0
172.1.1.1/24
NodeB RNC
In general, HQoS is configured on the access-layer ATN to guarantee bandwidth and limit traffic
of users.
In this networking, the configuration roadmap of HQoS is as follows:

Equipment
l Configure the WRED parameters for each CoS.

l Queue scheduling algorithm and parameters for each flow queue.
l Configure mapping of the CoS for flow queues.
l Configure SQ on the interface.
HQoS on the User-Side Sub-interface of the PE
Figure 7-4 Networking for HQoS configuration on the sub-interface
PE1 GE0/2/4.1 IP PE2

172.1.2.2/24 backbone
network
GE0/2/0.1
172.1.1.1/24
NodeB RNC
In this networking, the NodeB and RNC connect to the sub-interface of the PE by means of
VLL, VPLS or L3VPN.HQoS is configured on the access side of the PE to guarantee the
bandwidth and limit traffic of users.
The configuration roadmap is similar to that on the primary interface.
7.2.2 Troubleshooting Flowchart

In the network shown in Figure 7-4 in previous section "7.2.1 Typical Networking", the traffic
limit for the SQ is incorrect on one ATN. The troubleshooting flowchart is shown in Figure
7-5.

Equipment
Figure 7-5 HQoS troubleshooting flowchart

SQ traffic
is incorrect
HQoS is configured on the Upstream Upstream HQoS will not apply to

inbound (upstream) or outbound ATN, change upstream HQoS to
(downstream) interface of ATN? downstream HQoS
Downstream
Larger Smaller
Volume of traffic
is smaller or larger
Yes Yes
Multicast, unicast
Eth-Trunk interface? Load balancing Yes Disable the
packets exist on the ATN? is configured? load balancing
No No
No
Yes Yes
NNI-side is connected Excessive
to the MPLS core network? protocol packets
No No
In this case,
HQoS does not
take effect on the
NNI-side interface
No No
Fault Seek Fault
removed? technical support removed?
Yes Yes
End
7.2.3 Troubleshooting Procedure
Procedure
Step 1 Check whether HQoS is configured on the inbound (upstream) or outbound (downstream)
interface.
If upstream HQoS is configured, HQoS does not take effect on the ATN. You need to change
upstream HQoS to downstream HQoS.
Step 2 Compare the actual traffic that passes through the ATN with the configuration.
If they are inconsistent, do as follows:

Equipment
1. If the volume of traffic is smaller than the configuration, check that the interface where
HQoS is configured is an Eth-Trunk interface.
2. If the interface is an Eth-Trunk interface, check whether packet-based load balancing is
configured on that Eth-Trunk interface.
[PE1] interface eth-trunk 5
[PE1-Eth-Trunk5] display this
#
interface Eth-Trunk5
load-balance src-dst-ip
#
3. If packet-based load balancing is configured on the Eth-Trunk interface, disable the load
balancing. Then the problem can be solved.
Step 3 Check whether there are too many protocol packets.

l SQ limits rate of all traffic including protocol packets. In this case, if too many protocol
packets go into the ATN, the bandwidth allocated for protocol packets is wasted. Therefore,
actual traffic is too small.
l If too few protocol packets go into the ATN, perform Step 6.
Step 4 Check whether there are multicast or unknown unicast packets.

l If there are multicast or unknown unicast packets on the outbound interface, the volume of
traffic that passes the ATN will be too large.
l If there are no multicast or unknown unicast packets, perform Step 5.
Step 5 Check whether the NNI-side interface is connected to the MPLS network.
l If the NNI-side interface is connected to the MPLS network, the actual volume of traffic will
be too large because HQoS does not take effect on the NNI-side interface in this case.
l If not, perform step 6.
Step 6 Contact Huawei Technical Support Engineers.
----End

Equipment
Troubleshooting 8 MPLS
8 MPLS
About This Chapter
8.1 MPLS LDP Troubleshooting
8.2 MPLS TE Troubleshooting
8.3 MPLS Forwarding Troubleshooting

Equipment
8.1 MPLS LDP Troubleshooting

8.1.1 LDP Session Flapping
Common Causes
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.
After an LDP session is configured, the LDP session flaps.

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

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

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

Equipment
Context
NOTE
Procedure
Step 1 Check that LDP GR, a Keepalive timer, LDP authentication, an LDP MTU, or a transport address
is configured.
1. Run the display this command in the LDP view to view the configuration of LDP GR, an
LDP MTU, or LDP authentication.
l If the following information is displayed, LDP GR is configured.
mpls ldp
graceful-restart
l If the command output displays the following information, the LDP MTU value is set.
mpls ldp
mtu-signalling
l If the command output displays the following information, LDP authentication is

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

Equipment
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 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.
8.1.2 LDP Session Goes Down
Common Causes
l The interface on which the LDP session is established is shut down.

l The undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
l No route exists.
l An LDP Keepalive timer expires.
l An LDP Hello-hold timer expires.
After an LDP session is configured, the LDP session goes Down.

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

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

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

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

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

Keepalive-hold Yes
"Link Forwarding Is fault rectified?
timer expires?
Fails"
No No
Seek technical
End
support
Context
NOTE
Procedure
Step 1 Check that the interface on which the LDP session is established is shut down.
Run the display this command in the interface view. If the following information is displayed,
the interface has been shut down.
shutdown
l If the interface has been shut down, run the undo shutdown command to restart the
interface.

Equipment
l If the interface is Up, go to Step 2.
Step 2 Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
Run the display current-configuration command.
l If the command output does not include the following information, MPLS is disabled.
mpls
l If the command output does not include the following information, MPLS LDP is disabled.
mpls ldp
l If the command output does not include the following information, the remote LDP session
is deleted.
mpls ldp remote peer
l If an MPLS-associated configuration is deleted, re-perform the configuration.

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

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

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

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

Equipment
Relevant Alarms
Relevant Logs
LDP/4/SSNHOLDTMREXP
8.1.3 LDP LSP Flapping
Common Causes
l The route between LSP peers is flapping.

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

l Check that the routes do not alternate between unreachable and reachable.
l Check that the LDP session flaps.
Figure 8-3 Troubleshooting flowchart for LDP LSP flapping
LDP LSPs
flap
See the section Yes

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

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

Equipment
This section describes the troubleshooting procedure of LDP LSP flapping.
Context
NOTE
Procedure
Step 1 Check that the routes alternate between unreachable and reachable.
Run the display ip routing-table command to check information about the routes to the
destination of the LSP. Run this command at 1-second interval. If routes exist, routing
information is displayed. If no routes exist, no routing information is displayed. If sometimes
routing information is displayed but sometimes not after the command is run several times, the
routes alternate between unreachable and reachable.
l If routes alternate between unreachable and reachable or no route is displayed, see The
Ping Operation Fails and rectify the fault in IGP routes.
l If the routes are always reachable, go to Step 2.
Step 2 Check that the LDP session flaps.
Run the display mpls ldp session command to check the Status field. Running this command
every second is recommended. If Operational and Initialized are displayed alternatively, the
LDP session flaps.
l If the LDP session flaps, see LDP Session Flapping.
l If the LDP session does not flap, go to Step 3.
----End
Relevant Alarms
LSPM_1.3.6.1.2.1.10.166.2.0.2 mplsXCDown
LSPM_1.3.6.1.2.1.10.166.2.0.1 mplsXCUp
Relevant Logs
None.

Equipment
8.1.4 LDP LSP Goes Down
Common Causes
l Routes become unreachable.

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

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

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

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

Yes
setting up an policy for setting Is fault rectified?
LSP exists? up an LSP
No
No
Seek technical
End
support
Context
NOTE
Procedure
Step 1 Check that routes exist.
Run the display ip routing-table ip-address mask-length verbose command to check
information about the route to the destination of the LSP.
ip-address mask-length specifies the destination address of the LSP.

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

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

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

Equipment
l If no policy is configured, go to Step 5.
----End
Relevant Alarms
LSPM_1.3.6.1.2.1.10.166.2.0.2 mplsXCDown
LSPM_1.3.6.1.2.1.10.166.2.0.1 mplsXCUp
Relevant Logs
None.
8.1.5 Troubleshooting a Failure in Establishing an Inter-area LSP
Common Causes
l Routing problems occur.

l The inter-area LDP extension is not configured.
l An LDP session fails to be established.
l The route associated with the LDP session does not match the route in the routing table.
After the inter-area LDP extension has been enabled, an inter-area LSP fails to be set up.

l Check that routes are reachable.
l Check that the inter-area LDP extension is enabled.
l Check that an LDP session is set up.
l Check that the route associated with the LDP session matches the route in the routing table.

Equipment
Figure 8-5 Flowchart for troubleshooting the failure in establishing an inter-area LSP
An inter-area
LSP cannot
be
established
No See "IGP Yes

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

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

Equipment
Run the display ip routing-table ip-address mask-length verbose command to check

information about routes to the destination address of the inter-area LSP.
ip-address mask-length specifies the destination address of the inter-area LSP.
If routes are reachable, and the State field displays Active Adv, routes associated with the LSP
are reachable and are in the active state. If the Label field displays a value, not NULL, public
network BGP routes carry labels.
NOTE
Either the longest match rule or the exact match rule can be used to search for a reachable route.
l If no route is reachable, the reachable routes are in the inactive state, or BGP routes do not
carry labels, follow the procedure in Ping Failures
l If the routes are reachable in the active state and BGP routes carry labels, go to Step 2.
Step 2 Check that the inter-area LDP extension has been enabled.
Run the display mpls ldp command. If the Longest-match field displays On, the inter-area
LDP extension has been enabled; if Off is displayed, the inter-area LDP extension has not been
enabled.
l If the inter-area LDP extension is disabled, run the longest-match command to enable the
inter-area LDP extension.
l If the inter-area LDP extension has been enabled, go to Step 3.
Step 3 Check that an LDP session is set up.
Run the display mpls ldp session command. If the Status field displays Operational, the LDP
session has been set up and is Up; if Operational is not displayed or no session information is
displayed, the LDP session has not been set up.
l If the LDP session has not been established, follow the procedure in LDP Session Goes
Down.
l If the LDP session has been set up, go to Step 4.
Step 4 Check that the route associated with the LDP session matches the route in the routing table.
Run the display ip routing-table command, and check the NextHop and Interface fields.
Run the display mpls ldp session verbose command, and check the Addresses received from
peer field.
Run the display mpls ldp peer command, and check the DiscoverySource field.
If the value in the NextHop field is displayed as part of information in the Addresses received
from peer field, and the value in the Interface is the same as that in the DiscoverySource field,
the route associated with the LDP session matches the route in the routing table.
l If the LDP session does not match routes, follow the procedure in LDP LSP Goes
Down.
l If the LDP session matches routes, go to Step 5.
----End

Equipment
Relevant Alarms
None
Relevant Logs
None
Fail to Establish the LDP Session
Fault Symptom
As shown in Figure 8-6, The LDP function is enabled on the directly connected interfaces
between ATN and CX.
Figure 8-6 Networking diagram of establishing a LDP session

Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32
GE0/2/0 GE7/3/0
10.1.1.1/30 10.1.1.2/30
ATN CX
ATN cannot set up the LDP session with the peer.
Fault Analysis
Establishment of the LDP session is divided into two phases:
l Setting up the TCP connection

l Initiating the session and negotiating the session parameters
A fault in either of the two phases will cause a failure in establishing the LDP session.
The LSR ID is the default address used in setting up the TCP connection. Therefore, the route
of the LSR ID must be advertised to the peer.
After the LDP session is established, the local device and its peer cannot communicate on the
network layer due to the network congestion or fault. If no LDP PDU packet is received until
the session hold timer expires, the LDP session goes down.
Procedure
Step 1 Use the display ip routing-table command to check whether the node obtains the route of the
peer LSR ID.

Equipment
Step 2 Run the display this command on the interfaces that connect LSRs on both ends of the session
to check whether the label advertisement modes of the interfaces are the same.
----End
Summary
To create an LDP session successfully, you must ensure the following aspects:
l The route associated with the local LSR ID is correctly advertised to the peer.
l The interfaces that connect LSRs on both ends of the session are configured with the same
label advertisement mode.
Fail to Establish the Static LSP
Fault Symptom
Figure 8-7 Networking diagram of establishing a static LSP

Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32
GE0/2/0 GE7/3/0
10.1.1.1/30 10.1.1.2/30
ATN CX
A Point-to-Point Protocol (PPP) link connects ATN with CX. When a static LSP is configured,
the LSP status on the ingress goes Down.
Fault Analysis
Establishing a static LSP according to a routing protocol. When you configure a static LSP on
the ingress LSR, the local routing table must contain a routing entry exactly matching the
destination IP address. The routing entry includes the destination IP address and the next hop
IP address.
1. Use the display mpls static-lsp verbose command, and you can view that the Forwarding
Equivalence Class (FEC) is 2.2.2.9/32 and the IP address of the next hop is 10.1.1.1.
<ATN> 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, and you can view that the destination IP
address is 2.2.2.9/32 and the IP address of the next hop is 10.1.1.2.
<ATN> display ip routing-table

Equipment
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
The static LSP cannot be established because the next hop of the LSP does not match that
of the corresponding routing entry.
3. Use the display current-configuration | include static-lsp command, and you can view
the configuration of the static LSP.
<ATN> display current-configuration | include static-lsp
To match the routing entry, configure the static LSP by designating next hops.
Summary
When you configure a static LSP on an ingress LSR, ensure that a routing entry exactly matching
the specific destination IP address must exist in the local routing table. The routing entry includes
the destination IP address and the next hop IP address.
l If the routing entry is learnt from a dynamic routing protocol, the next hop must be
designated when you configure the static LSP. Moreover, the designated next hop must be
in accordance with the next hop in the corresponding routing entry.
Fail to Establish an Inter-area LSP
Fault Symptom
On the network shown in Figure 8-8, LSR B, LSR C, and LSR D are in Area 10, and LSR A is
in Area 20. LSR D aggregates routes associated with LSR B and LSR C and advertises the
summary route to Area 20. The inter-area LDP extension is enabled on LSR A.
Figure 8-8 Networking diagram for failing to establish an inter-area LSP
Loopback0
1.3.0.1/32
0/1
Loopback0 Loopback0 S1/ /24 0 LSRB
O
1.2.0.1/32 P .1.1.
1 /0/ 4
1.1.0.1/32
O S1 .2/2
GE0/2/0 20 P 1.1
. IS-IS
10.1.1.1/24 PO 20
20 S1 Area10
GE2/0/0 .1. /0/
2.1 2
LSRA 10.1.1.2/24 LSRD /24 Loopback0
1.3.0.2/32
IS-IS P
Area20 20 OS1
.1. /0/
2.2 0
/24
LSRC

Equipment
No inter-area LSP is established.
Fault Analysis
1. Run the display ip routing-table command on Router A to view route information. No
information about a summary route to the inter-area LSP destination address is displayed.

------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 10 Routes : 10

1.2.0.1/32 ISIS-L1 15 10 D 10.1.1.2 GE0/2/0
1.3.0.0/24 ISIS-L1 15 20 D 10.1.1.2 GE0/2/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 GE0/2/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 GE0/2/0
20.1.1.0/24 ISIS-L1 15 20 D 10.1.1.2 GE0/2/0
20.1.2.0/24 ISIS-L1 15 20 D 10.1.1.2 GE0/2/0
2. Run the display mpls ldp command on LSR A. The Longest-match field displays Off,
indicating that the inter-area LDP extension is not enabled. This causes the failure in
establishing an inter-area LDP.
Run the following commands on LSR A to rectify the fault:
Procedure
Step 1 Run the system-view to enter the system view.
Step 2 Run the mpls ldp 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.
No LDP Session Can Be Established Between PEs
Fault Symptom
MPLS is deployed on the network shown in Figure 8-9. With this configuration, no LDP session
can be established between PE1 and PE2.

Equipment
Figure 8-9 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
100.100.100.100 210.210.210.210
Fault Analysis
1. Run the display current-configuration and display ip interface commands on PE1 and
PE2 to view the configuration of the LSR ID and the related IP address. The address of
Loopback1 is used as the LSR ID for establishing an LDP session between PE1 and PE2.
2. Run the display ip routing-table command on PE1. No route to the peer is displayed.
3. Check OSPF configurations on PE2:
ospf
1
import-route
static
area
0.0.0.10
network 211.93.100.4
0.0.0.3
network 3.3.3.3
0.0.0.0
network 210.210.210.211
0.0.0.0
nssa
The preceding information shows that the OSPF route to Loopback1 is incorrect, and as a
result, the TCP connection between the two Loopback1 interfaces on PE1 and PE2 is not
reachable.
Procedure
Step 2 Run the ospf [ process-id ] [ router-id router-id ] command to enter the OSPF view.
Step 3 Run the area area-id command to enter the OSPF area view.
Step 4 Run the network 210.210.210.210 0.0.0.0 command to configure a correct route. After the
preceding configurations, an LDP session is established between PE1 and PE2. The fault is
rectified.
----End

Equipment
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.
MPLS LDP Peer Relationship Cannot Be Established
Fault Symptom
On the network shown in Figure 8-10, MPLS is configured on a ATN and a CX, but MPLS
LDP peer relationship cannot be established between the two devices.
Figure 8-10 Networking diagram of the case where the MPLS LDP peer relationship cannot be
established
GE0/2/0 GE1/0/0
ATN CX
Fault Analysis
1. Run the command on the ATN. The command output shows that the ATN has not received
any Hello packet from the CX.
2. Run the display this command on GigabitEthernet 0/2/0 to check its configuration. The
command output shows that traffic-policy CX inbound is configured on the interface.
Analysis on this traffic policy shows that the last rule is configured to reject multicast
packets from 224.0.0.2.
rule 10 permit ip destination 224.0.0.5 0

rule 20 permit ip destination 224.0.0.6 0
rule 30 deny ip destination 224.0.0.0 31.255.255.255
According to the mechanism for establishing LDP peer relationships, the LDP session is
triggered by multicast packets sent by 224.0.0.2. Therefore, it can be concluded that the
MPLS LDP peer relationship fails to be established because the last rule in the traffic policy
rejects multicast packets from 224.0.0.2.
Procedure
Step 2 Run the acl number acl-number command to enter the ACL view.
Step 3 Run the rule 25 permit ip destination 224.0.0.2 0 command to allow multicast packets from
224.0.0.2 to pass. After the configuration, the MPLS LDP peer is established. The fault is
rectified.
----End

Equipment
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.
VPN Traffic Loss Is Caused by a Change in the Next-hop Route
Fault Symptom
On the network shown in Figure 8-11, 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 8-11 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
GE0/2/0 GE1/0/0
LSRA 10.1.1.1/24 10.1.1.2/24 LSRB
Primary
GE0/2/1 GE2/0/0
10.1.2.1/24 Backup 10.1.3.2/24
GE1/0/0 GE2/0/0
10.1.2.2/24 10.1.3.1/24
LSRC
Loopback0
3.3.3.3/32
Fault Analysis
1. Run the display ip routing-table 2.2.2.2 32 command. The route to LSRB is displayed.
For example:
<LSRA> display ip routing-table 2.2.2.2 32
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
2.2.2.2/32 OSPF 10 2 D 10.1.2.2

GigabitEthernet0/2/1
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.

Equipment
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.
8.2 MPLS TE Troubleshooting

8.2.1 TE Tunnel Is Down
Common Causes
l The mpls te commit command is not configured to commit the TE tunnel configuration.
l CSPF fails to calculate a path.
l RSVP is not enabled on a device along the TE tunnel.
l Devices fail to exchange RSVP Path or Resv messages along the TE tunnel.
After a TE tunnel is configured, the TE tunnel goes Down.

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

Equipment
Figure 8-12 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 No See the section "IGP
to the tunnel
to calculate a Route
destination does
path? Troubleshooting"
not exist
Yes
No See the section "CSPF

Fails"
Yes Yes
RSVP is not
Enable RSVP Is fault rectified?
configured?
No
No
Yes Yes
Packet Cannot See the section "IP
Is fault rectified?
be exchanged? Forwarding Fails"
No
No
Seek technical
End
support
Context
NOTE
Procedure
Step 1 Check that the mpls te commit command has been configured to commit the TE tunnel
configuration.

Equipment
Run the display current-configuration command on the ingress that is configured with the TE
tunnel.
l If the mpls te commit command is not displayed in the command output, run the mpls te
commit command.
l If the mpls te commit command is displayed in the command output but the fault persists,
go to Step 2.
Step 2 Check that CSPF has successfully calculated paths.

Run the display mpls te cspf destination ip-address [ affinity properties [ mask mask-value ]
| bandwidth ct0 ct0-bandwidth | explicit-path path-name | hop-limit hop-limit-number |
metric-type { igp | te } | priority setup-priority | srlg-strict exclude-path-name | tie-
breaking { random | most-fill | least-fill } ]* command on the ingress of the TE tunnel. If
information is displayed, CSPF has successfully calculated paths; if no information is displayed,
CSPF failed to calculate a path.
l If CSPF failed to calculate a path, check whether routes to the destination of the TE tunnel
exist.
If no route is reachable, see The Ping Operation Fails to rectify the fault.
If reachable routes exist and the routes satisfy the requirements for establishing a TE
tunnel, run the display explicit-path command or identify interfaces that an LSP passes
through based on the network topology to check the interfaces along the tunnel. Then,
run the display this command in the interface view of each interface of the tunnel to
check whether the interface is enabled with MPLS, MPLS TE, and RSVP-TE.
If MPLS, MPLS TE, or RSVP-TE is not enabled, run the mpls, mpls te or mpls
rsvp-te commands in the view of the interface.
If any interface along the tunnel is not in Up state, restart the interface. That is, run
the shutdown and then undo shutdown commands in the interface view.
l If CSPF has successfully calculated paths but the fault persists, go to Step 3.
Step 3 Check that RSVP is enabled on every device along the TE tunnel.
The display mpls te cspf destination ip-address explicit-path path-name command output in
Step 2 contains a series of IP addresses. These IP addresses indicate the hops along the TE tunnel.
On the interface mapped to each IP address, run the display current-configuration interface
interface-name command to check if RSVP is enabled.
l If an interface is not enabled with RSVP, enable RSVP on the interface.
l If all interfaces are enabled with RSVP but the fault persists, go to Step 4.
Step 4 Check that devices along the TE tunnel have been successful in exchanging RSVP Path and
Resv messages.
Run the display mpls te tunnel-interface command on the ingress of the TE tunnel to check
fields Ingress LSR ID, LSP ID, and Session ID in the command output. In Step 3, LSRA,
LSRB, and LSRC are identified to be the nodes along the TE tunnel.
Perform the following steps to check whether the RSVP Path and Resv messages are correctly
transmitted:
l Check whether RSVP Path messages are correctly sent and received on every node along the
LSP in the sending direction (LSRA -> LSRB -> LSRC).
Run the display mpls rsvp-te psb-content command on every node along which the RSVP
Resv messages travel.

Equipment
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.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.2.2 TE Tunnel Suddenly Goes Down
Common Causes
l The configuration associated with the TE tunnel is deleted manually.

l A physical interface on the TE tunnel goes Down.
l Transmission of an RSVP message times out.
The TE tunnel goes suddenly Down after being configured.

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

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

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

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

Equipment
l If the preceding command is run, go to Step 2.
Step 2 Check whether any physical interface along the TE tunnel is Down.
1. Record the time when the log IFNET/4/LINKNO_STATE indicating that the TE tunnel
goes Down was generated. Record the time as T1.
2. Run the display mpls te cspf destination ip-address explicit-path path-name command
on the ingress of the tunnel. The command output contains a series of IP addresses. These
IP addresses identify the nodes along the TE tunnel. Record these nodes along the TE tunnel.
3. Run the display interface interface-type interface-number command on each node of the
TE tunnel. Record the time displayed in the Last line protocol up time field as T2.
l If T1 is greater than T2, the TE tunnel went Down because the physical interface on the
TE tunnel is faulty. See the section "Physical Interface Is Faulty."
l If T1 is smaller than T2, go to Step 3.
----End
Relevant Alarms
None.
Relevant Logs
IFNET/4/LINKNO_STATE
RSVP/6/PSB_CLEAN_TIMEOUT
RSVP/6/RSB_CLEAN_TIMEOUT
8.2.3 Loop Occurs on a TE Tunnel
Common Causes
l A loop occurs on the link along which an RSVP Path message travels.
l A loop occurs on the link along which an RSVP Resv message travels.
After a TE tunnel is configured, a loop occurs.

l Check that no loop occurs on the link, along which an RSVP Path message travels.

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

when transmitting the identical If fault rectified?
Path message? addresses
No
No
Yes Yes
Loop occurs Delete one of two
when transmitting the identical If fault rectified?
Rev message? addresses
No
No
Context
NOTE
Procedure
Step 1 Check that no loop occurs on the link along which RSVP Path messages travel.
If the log RSVP/3/LOOP_PATH is generated, a loop occurs on the link along which RSVP Path
messages travel.
Run the display mpls te cspf destination ip-address explicit-path path-name command. The
command output contains a series of IP addresses. These IP addresses and LSR IDs identify the
nodes along the TE tunnel.
On the node where the log RSVP/3/LOOP_PATH is generated, run the tracert ip-address
command. In this command, the ip-address is the IP address of each hop on the TE tunnel. If
the following information is displayed, ip-address is the same as an existing one and IP address
collision occurs.
Error: The destination address cannot be a local address.

Equipment
l In the case of IP address collision, delete or change the IP address of the node.
l If no IP address collision occurs but the fault persists, go to Step 2.
Step 2 Check that no loop occurs on the link along which RSVP Resv messages travel.
If the log RSVP/3/LOOP_RESV is generated, a loop occurs on the link along which RSVP Resv
messages travel.
The troubleshooting operations are the same as that in Step 1.
l In the case of IP address collision, delete or change the IP address.

l If no IP address collision occurs but the fault persists, go to Step 3.
----End
Relevant Alarms
None.
Relevant Logs
RSVP/3/LOOP_PATH
RSVP/3/LOOP_RESV
A Loop Occurs Because of the Undeleted IP Address of an Interface That Has Been
Shut Down on an RSVP-TE Tunnel
Fault Symptom
On the network shown in Figure 8-15, 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.

Equipment
Figure 8-15 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
GE0/2/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
shutdown
Fault Analysis
1. Run the display mpls te tunnel command on LSRA. A single tunnel is successfully set
up.
<LSRA> display mpls te tunnel
LSP-Id Destination In/Out-If
10.1.1.2:8:29 10.1.1.1 GE0/2/0/-
2. Run the terminal monitor command to enable the display of debugging information and
the terminal debugging command to enable debugging on LSRD. Debugging information
RSVP/3/LOOP_PATH or RSVP/3/LOOP_RESV shows that a loop is generated on LSRD.
3. Run the display current-configuration interface tunnel0/0/1 command on LSRA to
check tunnel configurations. The mpls te record-route command has been configured for
the tunnel (from LSRA to LSRD) that fails to be established.
4. Run the undo mpls te record-route command and the mpls te commit command on
LSRA. The tunnel from LSRA to LSRD is set up successfully.
If you enable MPLS TE FRR, the route record function will be automatically enabled. The
problem will recur. The cause has not been located yet.
5. Run the tracert -a 10.1.1.1 10.1.1.2 command on LSRD. No loop occurs.
6. Run the display current-configuration command on LSRD to check configurations. An
interface on LSRD is shut down, and its IP address that is not deleted is the same as that
of POS 2/0/0 on LSRB, causing the failure in establishing the tunnel from LSRA to LSRD.
interface GigabitEthernet1/0/1
shutdown
ip address 192.168.30.1 255.255.255.252
#
To establish the tunnel from LSRA to LSRD, LSRA sends an RSVP Path message to LSRD.
The RSVP Path message passes through each device along the path from LSRA to LSRD.
As the route record function is enabled using the mpls te record-route command, the IP
address of each hop along the path is added to the RSVP Path message. After receiving the
RSVP Path message, LSRD detects that 192.168.30.1 added to the message is the same as
the IP address of its interface. Although LSRD's interface with the IP address of
192.168.30.1 has been shut down, its address is not deleted, resulting in two identical

Equipment
addresses. LSRD considers that a loop occurs and therefore sends the alarm and rejects the
request for resources.
Run the following commands on LSRD to clear the fault:
Procedure
Step 2 Run the interface gigabitethernet1/0/1 command to enter the view of GE 1/0/1.
Step 3 Run the undo ip address 192.168.30.1 255.255.255.252 command to delete the IP address of
GE 1/0/1.
After completing the preceding operations, run the display mpls te tunnel command on LSRA.
The tunnel from LSRA to LSRD has been successfully set up. The fault is cleared.
<LSRA> display mpls te tunnel
LSP-Id Destination In/Out-If
10.1.1.2:8:29 10.1.1.1 GE0/2/0/-
10.1.1.1:1:64 10.1.1.2 -/GE2/0/0
----End
Summary
Deleting configurations that are no longer used on interfaces is recommended to prevent
unpredictable errors.
Tunnel Goes Down Suddendly and Then Up
Fault Symptom
As shown in Figure 8-16, an RSVP-TE tunnel is set up from LSR A (ingress) to LSR C (egress).
After the RSVP-TE tunnel is Up, it suddenly goes Down and then Up again.
Figure 8-16 Networking diagram of MPLS TE

GE0/2/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
1. Run the display current-configuration interface tunnel tunnel-number command on
LSR A to check the configuration of the RSVP-TE tunnel and its explicit path.
Alternatively, run the display mpls te tunnel path tunnel-number command to check the
path of the RSVP-TE tunnel.
2. View the logs on LSR A (ingress), or run the display logbuffer command to check the
point time T when the RSVP-TE tunnel goes Down.
3. Check whether the physical link of the RSVP-TE tunnel is faulty at the time T by using
the following methods.

Equipment
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 GigabitEthernet0/2/0 has entered the DOWN state.
Check whether the time when the physical outgoing interface along the RSVP-TE tunnel
goes Down is the same as the time when the tunnel interface goes Down. If so, it means
that the physical outgoing interface is faulty, which causes the RSVP-TE tunnel to go
Down.
l Run the display interface interface-number command on each device along the RSVP-
TE tunnel. The command output shows the status of the interface along the physical
link.
<LSRA> display interface gigabitethernet 0/2/0
GigabitEthernet0/2/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2008-12-23 14:54:44
Description: GigabitEthernet0/2/0 Interface
The Maximum Transmit Unit is 1500
According to the command output, the time displayed in the Last line protocol up
time field is later than the point time T when the RSVP-TE tunnel goes Down. This
means that the physical interface has been faulty before the point time T, which causes
the RSVP-TE tunnel to go Down.
Procedure
Step 1 The RSVP-TE tunnel restores to be Up, and no action is required.
----End
Summary
On the current network, the tunnel usually goes Down because a certain physical interface is
Down. You can view the log or run the display interface interface-type interface-number
command to check the status of each physical interface to find out the physical interface that
goes Down.
Fast Check and Rectify the Problem of Route Loops
Fault Symptom
As shown in Figure 8-17, an RSVP-TE tunnel is set up from LSR A (ingress) to LSR C (egress).
After the configuration, the interface status of the RSVP-TE tunnel cannot go Up.

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

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

Equipment
Fault Analysis
LSR A to check the tunnel configuration. Then, run the display current-configuration
command hop by hop to check the MPLS, MPLS TE, and RSVP-TE configurations. The
command output shows that the configurations are correct.
2. Run the display mpls te cspf destination ip-address explicit-path path-name command
on on LSR A. If information is displayed, it can be concluded that CSPF has been successful
in calculating paths; if no information is displayed, it can be concluded that CSPF failed to
calculate a path.
3. Check the logs on LSR A, LSR B, and LSR C. The following information is displayed on
LSR C.
Dec 23 2008 17:43:35 LSRC %%01RSVP/3/LOOP_PATH(1): There is a loop in path
message. (TunnelId=100, EgressAddress=3.3.3.3)
According to the log, the Path message detects a loop is detected on LSR C in the Patch
message.
Procedure
Step 1 Run the display current-configuration interface tunnel tunnel-number command on LSR A
to check the tunnel configuration. The command output shows information about the configured
explicit path and routes, which identifies the path of the RSVP-TE tunnel. Assume that
information about the path of the RSVP-TE tunnel is displayed as follows:
Hop1:10.1.1.1
Hop2:10.1.1.2
Hop3:2.2.2.2
Hop4:10.2.1.1
Hop5:10.2.1.2
Hop6:3.3.3.3
Step 2 The loop is detected on LSR C. This means that an IP address on LSR C is the same as the IP
address of the RSVP-TE tunnel (except Hop 5 and Hop 6 of LSR C itself). That is, the IP address
of LSR C is the same as one of the IP addresses of Hop 1 to Hop 4. Use each IP address from
Hop 1 to Hop 4 to run the tracert ip-address command on LSR C to find the conflicted IP
address. The command output is as follows:
<LSRC> tracert 10.1.1.2
Tracertoute: Destination can not be a local address
According to the command output, the IP address 10.1.1.2 on LSR C is duplicated.
Step 3 Run the display ip interface brief command on LSR C to search for 10.1.1.2 and then delete
it.
After the preceding operations, run the display interface tunnel tunnel-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.

Equipment
Tunnel Flaps Every Several Minutes After IGP Shortcut Is Enabled
Fault Symptom
As shown in Figure 8-18, an RSVP-TE tunnel is set up from LSR A (ingress) to LSR C (egress)
and IGP shortcut is enabled on LSR A. After the RSVP-TE tunnel goes Up, it flaps every several
minutes.

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE0/2/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
command output shows that the configurations are correct. In addition, IGP shortcut is
enabled on the tunnel interface and the explicit path is not configured.
#
interface Tunnel0/2/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 GE 0/2/0. After the RSVP-TE tunnel goes Up, the route
to the destination address of the RSVP-TE tunnel passes along the path of the RSVP-TE
tunnel itself, because the IGP route calculation counts in the tunnel.
<LSRA> display ip routing-table 3.3.3.3
------------------------------------------------------------------------------
----
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop

Equipment
Interface
3.3.3.3/32 OSPF 10 3 D 1.1.1.1
Tunnel0/2/0
3. Before the RSVP-TE tunnel goes Up, because CSPF is not enabled, and the explicit path
is not configured, RSVP sends the Path message through the physical interface according
to the routing table. After the RSVP-TE tunnel goes Up, the route to the destination address
of the RSVP-TE tunnel passes the path of the RSVP-TE tunnel itself, because the IGP route
calculation counts in the tunnel. Then, RSVP fails to search routes and the Path message
cannot be updated. As a result, the RSVP-TE tunnel is deleted because the Path message
times out.
4. After the RSVP-TE tunnel is torn down, the physical interface is used as the outgoing
interface of the route, and the Path message can be sent normally. Then, the RSVP-TE
tunnel goes Up again. Then, the IGP route calculation counts in the tunnel. As a result, the
Path message fails to be sent and the RSVP-TE tunnel is torn down after the Path message
times out. In this manner, tunnel flapping occurs.
Procedure
Step 1 Choose one of the following procedures:
l Enable CSPF on LSR A.
1. Run the system-view command to enter the system view.
2. Run the mpls command to enter the MPLS view.
3. Run the mpls te cspf command to enable CSPF.
l Alternatively, create an explicit path.
2. Run the explicit-path path-name command to configure an explicit path.
3. Run the next hop ip-address command to assign an IP address for the next hop along
the explicit path.
4. Run the quit command to return to the system view.
5. Run the interface tunnel interface-number command to enter the tunnel interface view.
6. Run the mpls te path explicit-path path-name command to configure an explicit path
for the tunnel.
7. Run the mpls te commit command to commit the configuration.
After the preceding operations, wait for 5 minutes or 6 minutes after the tunnel goes Up. Tunnel
flapping does not occur and thus the fault is rectified.
----End
Summary
If IGP shortcut is enabled on a tunnel, the CSPF must be enabled or an explicit path must be set
up. Otherwise, tunnel flapping occurs.

Equipment
TE Tunnel of the Inter-OSPF Area Fails to Be Set Up
Fault Symptom
As shown in Figure 8-19, LSR A and LSR B are in Area0, and LSR C and LSR D are in Area1.
An RSVP-TE tunnel is set up along the path LSR A -> LSRB -> LSR C -> LSR D. After the
configuration, the RSVP-TE tunnel fails to be set up.
Figure 8-19 Networking diagram of MPLS TE tunnel over inter-area

Loopback0 Loopback0 Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
GE0/2/0 GE2/0/0 GE2/0/0

10.1.2.1/30 10.2.3.1/30 10.1.4.1/30
GE1/0/0 GE1/0/0 GE1/0/0
LSRA 10.1.2.2/30 LSRB 10.2.3.2/32 LSRC 10.3.4.2/30 LSRD
Fault Analysis
command output shows that the configurations are correct.
LSR A to check the tunnel configuration. The command output shows that an explicit path
is set up on the tunnel interface.
<LSRA> display current-configuration interface tunnel 0/2/0
#
Interface Tunnel0/2/0
ip address unnumbered interface Loopback0
tunnel-protocol mpls te
destination 4.4.4.4
mpls te tunnel-id 100
mpls te record-route label
mpls te path explicit-path path1
mpls te commit
#
return
3. Run the display explicit-path path-name command. The command output shows
information about the explicit path.
<LSRA> display explicit-path path1
Path Name : path1 Path Status : Enabled
1 10.1.2.2 Strict Include
4. Run the display mpls te cspf tedb command on LSR A to check the CSPF TEDB. The
command output shows information about the CSPF TEDBs of only LSR A and LSR B.
<LSRA> display mpls te cspf tedb all
Maximum Node Supported: 128 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

Equipment
5. Run the display mpls te cspf destination dest-ip-address explicit-path path-name

command on LSR A to check the result of CSPF calculation. The command output shows
that the calculated path is not complete, which may be resulted from the incomplete explicit
path.
<LSRA> display mpls te cspf destination 4.4.4.4 explicit-path path1
Path for the given constraints is:
10.1.2.1
10.1.2.2
The computation to egress is not finished.
The total metrics for the given path is : 1
Procedure
Step 2 Run the interface tunnel tunnel-number command to enter the tunnel interface view.
Step 3 Run the undo mpls te path command to delete the explicit path of the tunnel.
Step 4 Run the mpls te commit command to commit the configuration.
Step 5 Run the quit command to return to the system view.
Step 6 Run the explicit-path explicit-path command to enter the explicit path view.
Step 7 Run the next hop 10.2.3.2 command to specify 10.2.3.2 as the IP address of the next hop along
the explicit path.
Step 8 Run the next hop 10.3.4.2 command to specify 10.3.4.2 as the IP address of the next hop along
the explicit path.
Step 10 Run the interface tunnel tunnel-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 LSR
A. The command output shows that the tunnel interface goes Up and thus the fault is rectified.
----End
Summary
On the network with inter-area tunnels, IGP routes can be advertised only in one area, and inter-
area CSPF calculation cannot be performed automatically. Therefore, a complete explicit path
should be specified manually, and it must contain the edge nodes between areas.
Tunnel Goes Down After Switchover
Fault Symptom
As shown in Figure 8-20, multiple RSVP-TE tunnels are set up from LSR A (ingress) to LSR
C (egress). After master/slave switchover on LSR A, all RSVP-TE tunnels that pass through
LSR A go Down.

Equipment

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE0/2/0 GE2/0/0
GE1/0/0 GE1/0/0
LSRA LSRB LSRC
Fault Analysis
command hop by hop to check the configurations of MPLS, MPLS TE, RSVP-TE, and
RSVP-TE Hello mechanism. The command output shows that the configurations are
correct.
2. Run the display mpls rsvp-te graceful-restart peer command on LSR A and then LSR
B to view the Neighbor Capability field to check whether RSVP GR on the neighbor is
supported. The field is Can Support GR, indicating that the neighbor supports RSVP GR.
3. Run the display mpls rsvp-te graceful-restart command on LSR A and LSR B to check
whether RSVP GR is supported. Take the display on LSR A as an example.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 1.1.1.1
Graceful-Restart Capability: None
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0
Received RecoveryPath message count: 0
Send Recovertpath message count: 0
According to the command output, RSVP GR is not enabled on LSR A or LSR B.
Procedure
Step 1 Do as follows on LSR A and LSR B:
2. Run the mpls command to enter the MPLS view.
3. Run the mpls rsvp-te hello full-gr command to enable RSVP GR.
After the preceding operations, run the display mpls rsvp-te graceful-restart command on
LSR A and LSR B to check whether RSVP GR is supported. Take the display on LSR A as an
example.
<LSRA> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 1.1.1.1
Graceful-Restart Capability: GR-Self GR-Support
Restart Time: 90000 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr path message count: 0

Equipment
Received RecoveryPath message count: 0

Send Recovertpath message count: 0
According to the command output, LSR A supports GR. Perform switchover to check the status
of the tunnel. The tunnel remains to be Up and thus the fault is rectified.
----End
Summary
When the tunnel goes Down after switchover, you should check whether the configurations on
devices are correct, whether the RSVP-TE Hello mechanism is configured in both the system
and interface views, and whether RSVP GR is configured correctly.
Tunnel Creation Fails Because of Authentication Failure
Fault Symptom
Based on the network shown in Figure 8-21, configure MPLS VPN.
Figure 8-21 Networking diagram of MPLS VPN, No.2
GE0/2/0 GE1/0/0
200.1.1.1/24 200.1.1.2/24 POS2/0/0 POS1/0/0
ATN CX-B CX-C
The tunnel from ATN to CX-C is Down.
Fault Analysis
1. Use the display current-configuration interface tunnel interface-type interface-
number command on ATN to check the tunnel configurations are correct.
2. Use the display mpls te cspf tedb all command on ATN and find that CSPF TEDB is
correct.
3. Use the display mpls rsvp-te statistics global command on ATN and CX-B.
Statistics on ATN 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

Equipment
RecReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0
Statistics on CX-B are as follows:

Total Statistics Information:
PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 0 RecPacketCounter: 2
SendPathCounter: 0 RecPathCounter: 0
SendResvCounter: 0 RecResvCounter: 0
SendResvConfCounter: 0 RecResvConfCounter: 0
SendHelloCounter: 0 RecHelloCounter: 0
SendAckCounter: 0 RecAckCounter: 0
SendPathErrCounter: 0 RecPathErrCounter: 0
SendResvErrCounter: 0 RecResvErrCounter: 0
SendPathTearCounter: 0 RecPathTearCounter: 0
SendResvTearCounter: 0 RecResvTearCounter: 0
SendSrefreshCounter: 0 RecSrefreshCounter: 0
SendAckMsgCounter: 0 RecAckMsgCounter: 0
SendErrMsgCounter: 0 RecErrMsgCounter:
RecReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0
Based on the preceding display, you can view that "RecPacketCounter" is not zero on CX-
B and the number of all types of messages is zero. This indicates that a defect occurs when
packets are pre-processed. The possible cause is that invalid packets are received or RSVP
authentication fails.
4. Use the display current-configuration interface command on ATN and CX-B.
The display on CX-B is as follows:
ip address 200.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 10000
mpls rsvp-te
mpls rsvp-te authentication plain 12345678
The display on ATN is as follows:

ip address 200.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 10000
mpls rsvp-te
From the configuration display, you can view that RSVP is configured on the interface of
Route B but not of ATN . The authentication of the packets sent by ATN to CX-B fails
and the tunnel cannot be set up.
Procedure
Step 1 Run the interface interface-type interface-number command to enter the interface view of
GE0/2/0.
Step 2 Run the mpls rsvp-te authentication { cipher | plain } auth-key command to configure the
RSVP authentication. The keys on both ends should be the same.
After the preceding operation, run the display mpls te tunnel-interface command on ATN ,
and you can view that the tunnel interface goes Up, which indicates that the fault is removed.
----End

Equipment
Summary
Check statistics of the received and sent packets carefully to locate the fault.
Calculation of the Tunnel Path Fails
Fault Symptom
Based on the network shown in Figure 8-22, configure MPLS TE. An MPLS TE tunnel named
Tunnel0/2/0 is established from LSR A to LSR D. After the configuration, the mpls te
commit is run on Tunnel0/2/0 of LSR A, but the MPLS TE tunnel cannot be established.

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
LSRA GE0/2/0 GE1/0/0 GE3/0/0 LSRD

GE1/0/0 GE3/0/0 GE1/0/0
LSRB LSRC
GE0/2/1 GE2/0/0
GE1/0/0 GE2/0/0
LSRE
Loopback1
5.5.5.9/32
Fault Analysis
1. Using the debugging mpls te cspf all command on LSRA, you can find the faulty CSPF
calculation.
01:6821: The current computation is loose
*0.10305390 LSRA CSPF/8/ERROR:
01:7000: Destination node is unreachable
01:7002: Error configuration or all the nodes can not fulfil the path request
01:6640: The first segment computation is failure
*0.10305390 LSRA CSPF/8/COMPUTE:
01:7264: The CSPF path computation is failed
2. Using the display mpls te cspf tedb node command on LSRA, you can view the TEDB
on each node. Check whether various attributes of IP addresses of interfaces such as the
color and the maximum reservable bandwidth of TE Class can meet the requirements.
You can find that the path calculation fails because of unavailable link bandwidth. The
destination address is unreachable.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the interface view of the
interface on which the bandwidth cannot meet the requirement.

Equipment
Step 3 Run thempls te bandwidth max-reservable-bandwidth command to change the maximum

reservable bandwidth on an MPLS TE tunnel or change the constraints of the tunnel bandwidth
on LSRA. Thus, the bandwidth of all nodes can 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 LSR 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.
Path with the Smallest Metric Is Not Selected
Fault Symptom
Based on Figure 8-23, configure MPLS TE. By default, the metric of all the interfaces on the
devices are 10. The optimal path is LSR A -> LSR B -> LSR C -> LSR D.
Run the mpls te record-route command and then run the display mpls te tunnel path command
on the tunnel interface. The bandwidth of the optimal path is sufficient, but the tunnel is
established over another path LSR A ->LSR B -> LSR E ->LSR C ->LSR D, which is not an
optimal path.
Figure 8-23 Typical networking of MPLS TE

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE3/0/0 GE1/0/0 GE3/0/0 GE1/0/0
GE0/2/0
GE1/0/0 GE2/0/0 GE2/0/0
LSRA LSRB GE2/0/0 LSRC LSRD
GE2/0/0
GE1/0/0
LSRE GE3/0/0
Loopback1
5.5.5.9/32
Fault Analysis
1. Run the display mpls te cspf tedb command on LSRA, and you can find that the database
on LSRB --> LSRE --> LSRC is correct.
2. Create a new tunnel and view the CSPF calculation result. The shortest path is calculated
and the fault does not appear.

Equipment
3. Continue to check the log files. The metric of GE3/0/0 on LSRB is changed to 100 before
the tunnel is created. During the new tunnel configuration, the metric then recovers to the
default.
At first, the path LSRA --> LSRB --> LSRE --> LSRC --> LSRD 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 LSRA, 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 mpls te commit command to commit the current tunnel configuration.
Step 5 Run the return command to return to the user view.
Step 6 Run the mpls te reoptimization command to trigger the optimization immediately.
On LSRA, run the display mpls te tunnel path command to view the tunnel path and find the
path with the smallest metric is selected. The fault is rectified.
----End
Summary
Removing this fault depends on the TE feature. TE is driven by configuration, not by topology.
You can configure re-optimization to avoid this fault.
Establishment of the Hot-Standby LSP Fails
Fault Symptom
Based on the networking shown in Figure 8-24 configure the MPLS TE.

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
LSRA GE0/2/0 GE1/0/0 GE3/0/0 LSRD

GE1/0/0 GE3/0/0 GE1/0/0
LSRB LSRC
GE0/2/1 GE2/0/0
GE1/0/0 GE2/0/0
LSRE
Loopback1
5.5.5.9/32
Use the display mpls te tunnel-interface tunnel 0/2/0 command. The display is as follows:

Equipment
================================================================
Tunnel0/2/0
================================================================
Tunnel State Desc : UP
Active LSP : Primary LSP
Session ID : 34
Ingress LSR ID : 1.1.1.9 Egress LSR ID: 4.4.4.9
Admin State : UP Oper State : UP
Primary LSP State : UP
Main LSP State : READY LSP ID : 20
Hot-Standby LSP State : DOWN
Main LSP State : SETTING UP
The command output indicates that the establishment of the primary tunnel succeeds, but the
establishment of the backup LSP fails.
Fault Analysis
1. Using the display mpls te tunnel path command on LSRA to view the primary LSP of
the tunnel and find the path LSRA -> LSRB -> LSRC is used.
2. Using the display mpls te cspf destination command on LSRA, you can view CSPF
calculation fails and the path to the destination address is unavailable.
3. Using the display mpls te cspf tedb node command to check the CSPF database. Note
that the bandwidth of GE2/0/0 on LSRE is not adequate to set up the bypass LSP.
Procedure
Step 1 On LSRE, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view of
GE2/0/0 on which the bandwidth is too low.
Step 3 Run the mpls te bandwidth max-reservable-bandwidth and

mpls_te_bandwidth_interface_view command to modify the maximum reservable bandwidth
and BC bandwidth of the link.
Run the display mpls te tunnel-interface tunnel command on LSRA to change the bandwidth,
and you can find that the standby LSP is set up. Thus, the fault is rectified.
----End
Summary
The key point of the example lies in the mechanism in CR-LSP backup. The bandwidth of the
backup LSP cannot be configured through the command line but are inherited from the primary
LSP.
FRR Binding Fails
Fault Symptom
Based on Figure 8-25, configure MPLS TE.

Equipment

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE3/0/0 GE1/0/0 GE3/0/0 GE1/0/0
GE0/2/0
GE1/0/0 GE2/0/0 GE2/0/0
LSRA LSRB GE2/0/0 LSRC LSRD
GE2/0/0
GE1/0/0
LSRE GE3/0/0
Loopback1
5.5.5.9/32
The primary tunnel path is LSRA --> LSRB --> LSRC --> LSRD. Then create a Bypass tunnel
between LSRB and LSRD, specifying LSRE as the loose node.
After the configuration, FRR binding fails.
Fault Analysis
1. Use debugging mpls te management fast-reroute, terminal debugging, and terminal
monitor commands on LSRA or LSRB to enable the FRR debugging and view the binding
states of the main tunnel and the Bypass tunnel. The following display prompts:
Error: Optimal Bypass tunnel not found for Tunnel
2. Use the display mpls te tunnel path command to check the adopted paths in the tunnel,
and find that the primary tunnel uses the path LSRA --> LSRB --> LSRC --> LSRD and
the backup tunnel uses the path LSRB --> LSRE --> LSRC --> LSRD. You can view there
are some coincident nodes between the PLR and the MP on the primary tunnel and the
backup tunnels, leading to FRR binding fails.
Procedure
Step 1 On LSRB, run the system-view command to enter the system view.
Step 2 Run the interface tunnel interface-number command to enter the interface view of the bypass
tunnel.
Step 3 Run the undo mpls te path command to delete the explicit path on the tunnel interface.
Step 6 Run the explicit-path path-name command to enter the explicit path view of the bypass tunnel.
Step 7 Run the add hop ip-address before 5.5.5.9 command to add the IP address of Ethernet 1/0/0 of
LSRE before 5.5.5.9.
Step 8 Run the add hop ip-address before 4.4.4.9 command to add the IP address of Ethernet 2/0/0 of
LSRD before 4.4.4.9.

Equipment
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 tunnel-number ] command to view the LSP
on LSRA and find the FRR binding succeeds. The fault is removed.
----End
Summary
In FRR configuration, to ensure the successful binding, you need to specify the strict explicit
paths of the primary and bypass tunnels. Otherwise, the binding fails when the coincident nodes
exist between the PLR and the MP.
Primary Tunnel Turns Down When Configuration of the Bypass Tunnel Is

Modified
Fault Symptom
As shown in Figure 8-26, a primary tunnel Tunnel 0/2/0 is set up on the path LSRA --> LSRB
--> LSRC, and a bypass tunnel is set up on the path LSRB --> LSRD --> LSRC.
Figure 8-26 Networking diagram in which the configuration of the bypass tunnel is modified
LSRA LSRB LSRC
Primary LSP
Bypass LSP
LSRD
After the configuration, shutdown the outgoing interface from LSRB to LSRC to make the
bypass tunnel turn to in use. After modifying the configuration of the bypass tunnel and
committing the new configuration, the primary tunnel turns Down.
Fault Analysis
During the modification of the bypass tunnel, a phase called make-before-break exists. That is,
a new CR-LSP is set up firstly and then the previous CR-LSP is removed.
After the old CR-LSP is removed, the binding relationship between the primary tunnel and the
bypass tunnel is also removed. The primary tunnel, therefore, turns Down because the newly-
established bypass tunnel cannot set up the binding relationship with the primary tunnel.

Equipment
Procedure
Step 1 On LSRB, 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 LSRC.
Step 3 Run the undo shutdown command to restore the primary tunnel and bind the primary tunnel to
the bypass tunnel again.
Run the display mpls te tunnel [ name tunnel-name ] command on LSRA, and you can view
that the establishment of the primary and bypass tunnels succeeds. Thus, the fault is removed.
----End
Summary
It is not recommended to modify the configuration of bypass tunnels when the bypass tunnel is
in use.
Volume of Service Traffic on Interfaces of a Device Is Unstable

The volume of service traffic on some interfaces of a device reduces suddenly, and the volume
of service traffic on an interface of the device increase suddenly.
Fault Symptom
On the network shown in Figure 8-27, normal service traffic reaches LSR B from LSR C and
LSR D, and then is forwarded by LSR B to LSR 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 GE 1/0/0 and GE 2/0/0 of LSR A, and then reaches LSR 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 GE 1/0/0 connecting LSR B to LSR A
suddenly exceeds 1 Gbit/s, whereas the volume of traffic on POS 5/0/0 connecting LSR B to
LSR E reduces by more than 1 Gbit/s. Services, however, are not affected.
Figure 8-27 Diagram of the networking where the volume of service traffic on interfaces of a
device is unstable
LSRC LSRD
POS1/0/0 POS2/0/0
LSRB
GE1/0/0 POS5/0/0
GE2/0/0
LSRA LSRE

Equipment
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 LSR 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. Thus,
packet forwarding may fail on LSR B.
3. Run the display ip routing-table 1.1.1.1 command on LSR B to identify the interfaces that
send the packets out.
Route Flags: R - relay, D - download to
fib
------------------------------------------------------------------------------
Routing Table :
Public
Summary Count :
1
Destination/Mask Proto Pre Cost Flags NextHop

Interface
1.1.1.0/25 BGP 255 0 RD 4.4.4.1

Pos1/0/0
BGP 255 0 RD 4.4.4.1 Pos2/0/0
The command output shows that the packets are sent from POS 1/0/0 and POS 2/0/0.
4. Run the display fib 2.2.2.2 command on LSR 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

Equipment
Out Label: 1097

Next Hop: 3.3.3.3
5. Run the display mpls lsp in-label 1097 command on LSR B to check the MPLS forwarding
table of LSR B based on outbound labels.
----------------------------------------------------------------------
LSP Information: LDP

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

Name
3.3.4.3/32 1097/3 -/
GE1/0/0
3.3.4.3/32 1097/3 -/GE2/0/0
The command output shows that MPLS load balancing is performed among two paths for
the packets. The outbound interface of one path is GE 1/0/0, and the outbound interface of
the other path is GE 2/0/0. Because flow-by-flow load balancing is adopted, packets are
sent through GE 1/0/0 based on the hash algorithm. In addition, packets are forwarded
through MPLS rather than IP on LSR B.
6. Check the configuration of LSR C. You can find that the route recursive-lookup tunnel
command is run on LSR 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 LSR A to check the
routes iterated to LSP tunnels.
----------------------------------------------------------------------
LSP Information: LDP

LSP
----------------------------------------------------------------------
No :
1
VrfIndex :
Fec :
3.3.4.3/32
Nexthop :
3.3.3.3
In-Label :
NULL
Out-Label :
3
In-Interface :
----------
Out-Interface :
Pos1/0/0
LspIndex :
44181
Token :
0xc0b3de
FrrToken :
0x0
LsrType :
Ingress
Outgoing token :
0x0
Label Operation :
PUSH
Mpls-Mtu :

Equipment
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 LSR 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 LSR C, related routes are successfully iterated to the LSP and packets are
forwarded through MPLS. On LSR B, packets are sent out through GE 1/0/0 and GE 2/0/0,
because the routes to LSR E are built up late. Thus, 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.
8.3 MPLS Forwarding Troubleshooting

8.3.1 Host Cannot Receive or Send Packets Through an LSP
Common Causes
l Routing information is incorrect.

l The LSP does not exist.
l The LSP status is incorrect in the situation where BFD status is Down.
l The system status is incorrect.
After an MPLS network is configured, a host cannot transmit packets along an LSP.

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

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

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

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

LSP status is
"BFD Session Goes Is fault rectified?
normal?
Down"
Yes No
Seek technical
End
support
Context
NOTE
Procedure
Step 1 Check that routes are correct.
Run the display fib verbose command to check whether routing information on the ping initiator
and the ping destination node.
l If the LspFwdFlag field is not 1 and the LspToken field is 0, IGP routes are incorrect. For
instructions on how to clear the fault, see the section "IGP Route Troubleshooting."
l If the LspFwdFlag field is 1 and the LspToken field is not 0, IGP routes are correct. Then,
go to Step 2.
Step 2 Check that the LSP exists.

Run the display tunnel-info command on the ping initiator and the ping destination node.

Equipment
l If the LSP does not exist, clear the fault by referring to LDP LSP Goes Down.
l If the LSP exists and the fault persists, go to Step 3.
Step 3 Check that the LSP status is normal.

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

Equipment
Troubleshooting 9 VPN
9 VPN
About This Chapter
9.1 L3VPN Troubleshooting

This chapter describes common causes of L3VPN faults and provides the corresponding
9.2 VPLS Troubleshooting

This chapter describes common causes of VPLS faults and provides the corresponding
9.3 VLL Troubleshooting

This chapter describes common causes of VLL faults and provides the corresponding
9.4 PWE3 Troubleshooting

This chapter describes common causes of PWE3 faults and provides the corresponding

Equipment
9.1 L3VPN Troubleshooting

This chapter describes common causes of L3VPN faults and provides the corresponding
9.1.1 L3VPN Traffic Is Interrupted
Common Causes
This troubleshooting case describes how to clear the fault that BGP private network routes is
interrupted when the BGP peer relationship is normal.

l Private network routes fail to be advertised because the number of labels exceeds the upper
limit.
l Routes are inactive because they fail to be iterated to a tunnel.
l Routes fail to be added to the VPN routing table because the configured import route-target
(RT) and export RT do not match.
the device.
BGP private network traffic is interrupted after the BGP protocol is configured.

Equipment
Figure 9-1 Troubleshooting flowchart for interruption of BGP private network traffic
The BGP private network


Is fault rectified?
VPN route reachable? hop is reachable
No
Yes
No Yes
Is the routing policy is Correctly configure the
Is fault rectified?
Yes No
Reduce the number of Yes

Does the Yes routes or configure the
Number of labels exceed the Is fault rectified?
device to assign a label
upper limit?
to each instance
No
No
No Ensure that the tunnel Yes

Is the tunnel iterated
exists Is fault rectified?
successfully?
No
Yes
No Yes
Does the export RT
Ensure that they match Is fault rectified?
match the import RT?
No
Yes
Does the number Yes Reduce the number of Yes

of routes exceed the upper routes or increase the Is fault rectified?
limit? upper limit of routes
No
No

Equipment
Context
NOTE
Procedure
Step 1 Check that next hops of routes are reachable.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address

[ mask | mask-length ] command on the PE that sends routes (that is, the local PE) to check
whether the target route exists. ipv4-address specifies the prefix of the target route.
l If the target route does not exist, check whether the route of a CE is advertised to the local
PE.
l If the target route exists, check whether it is active. The following is an example:
this route is active and selected. The original next hop and iterated next hop of this route are
3.3.3.3 and 20.1.1.2 respectively.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1

From: 20.1.1.1 (1.1.1.1)
because the next hop of the BGP route is unreachable. In this case, find out why there is
no route to the original next hop (this fault is generally associated with IGP or static routes).
l If the target route is active and selected but there is no information indicating that this route
is sent to the remote PE, go to Step 2 to check the outbound policy applied to the local PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the
remote PE to check whether it has received the target route.
l If the remote PE has received the target route, perform Step 1 again to check whether the
next hop of the route is reachable and whether this route is selected.
l If the remote PE has not received the target route, go to Step 2 to check the inbound policy
of the remote PE.
Run the display current-configuration configuration bgp command on the local PE and
remote PE to check whether inbound and outbound policies are configured.

Equipment
NOTE
Only focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address family in this
troubleshooting case because private network traffic is interrupted.
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpna
#
return
target route fails to be transmitted because it is filtered by these policies. For detailed
configurations of a routing policy, see the Configuration Guide - IP Routing.
Step 3 Check that routes can be iterated to a tunnel.
Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on
the remote PE to check whether the target route can be iterated to a tunnel.
Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface field
and Relay token field in the command output are not empty, it indicates that this route can be
iterated to a tunnel.
<HUAWEI> dis bgp vpnv4 all routing-table 50.1.1.2

From: 1.1.1.1 (1.1.1.1)
Relay token: 0x1002

Equipment

best, select, pre 255

From: 1.1.1.1 (1.1.1.1)
Relay token: 0x1002
l If the target route fails to be iterated to a tunnel, run the display ip vpn-instance
verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field is
not displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy is
configured for the VPN instance. If the VPN instance selects an MPLS-TE tunnel, a tunnel
policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel
policy of the VPN instance. You can view details of the tunnel policy by running the display
this command in the corresponding tunnel policy view.
#
tunnel-policy p1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to configure the mpls te reserved-for-binding
command in the tunnel interface view.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or
TE Tunnel Is Down to locate the fault and ensure that the tunnel goes Up.
l If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether routes fail to be added to the VPN routing table because the configured import
RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the local PE
and remote PE to check whether routes fail to be added to the VPN routing table of the remote
PE after being sent to the remote PE because the export RT of the local VPN instance does not
match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.
<HUAWEI> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
apply-label per-instance
ip vpn-instance vpnb

Equipment

#
return
l If the export RT of the local VPN instance does not match the import RT of the remote VPN
instance, configure matching VPN-targets in the VPN instance.
l If the export RT of the local VPN instance matches the import RT of the remote VPN instance,
go to Step 5.
Step 5 Check that the number of labels is below the upper limit.
Check whether MPLS is enabled on the local PE. Run the display bgp vpnv4 all routing-
table ipv4-address [ mask | mask-length ] command to check whether the target route is assigned
a VPN label.
If there is no Label information field in the command output, the number of labels may have
reached the upper limit. As a result, the target route is not assigned a label and is not advertised
to the peer.
<HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1


Imported route.
Label information (Received/Applied): NULL/12

From: 0.0.0.0 (0.0.0.0)
255
1.1.1.1

Imported route.
From: 0.0.0.0 (0.0.0.0)
60
l If the number of labels has reached the upper limit, run the apply-label per-instance
command in the VPN instance view to configure the device to assign one label to each
instance to reduce label usage. Route summarization can also be configured to reduce the
number of routes.
l If the number of labels is below the upper limit, go to Step 6.
Step 6 Check that the number of routes is below the upper limit.
If the peer is added to a peer group, run the display current-configuration configuration bgp
| include peer destination-address command or the display current-configuration

Equipment
configuration bgp | include peer group-name command on the remote PE to check whether
the upper limit on the number of routes to be received is configured on the remote PE.
after the remote PE receives five routes from the local PE at 1.1.1.1.
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations about the upper limit in the
command output.
peer 1.1.1.1 enable
name command to check configuration of this peer group.
peer IBGP enable
is dropped because the number of routes received has exceeded the upper limit. In this case,
increase the upper limit.
NOTE
----End
Relevant Alarms
Relevant Logs

Equipment
VPN Routes Cannot Be Exchanged Between PEs

On a BGP/MPLS VPN network, the mask of a loopback address is incorrectly configured,
leading to the failure of VPN route exchange.
Fault Symptom
On the BGP/MPLS VPN network shown in Figure 9-2, VPN routes fail to be exchanged between
PE1 and PE2, and both PEs cannot ping each other successfully.
On PE1 and PE2, loopback interfaces are created, respectively assigned the IP addresses
1.1.1.1/24 and 1.1.1.2/24, and bound to the VPN instance named test.
Figure 9-2 Networking diagram of BGP/MPLS VPN
PE1 P1 PE2
Fault Analysis
1. Run the display ip routing-table command on PE1 and PE2 to check whether both PEs
have routes destined for each other's loopback interfaces. You can find that both PEs have
such routes.
2. Run the display mpls ldp peer command on P1, and you can find that P1 establishes the
LDP peer relationships, with PeerID being 1.1.1.1 and 1.1.1.2. Run the display mpls lsp
command on P1, and you can find that P1 establishes LSPs with FECs being 1.1.1.1 and
1.1.1.2.
3. Run the display bgp peer command on P1 to check BGP peer relationships. You can find
that P1 establishes IBGP peer relationships with 1.1.1.1 and 1.1.1.2, as indicated by
Established in the command output.
4. Run the display bgp vpnv4 all peer command on P1 to check VPNv4 peer relationships.
You can find that P1 establishes VPNv4 peer relationships with 1.1.1.1 and 1.1.1.2,
indicating that VPN routes can be properly advertised.
5. After the preceding steps, run the display ip routing-table command on PE1 and PE2, and
you can find only one route destined for each other's loopback interfaces, that is, 1.1.1.0/24
Direct with a 24-bit mask instead of a 32-bit mask.
This indicates that both loopback interfaces are on the same network segment, which is
obviously incorrect. In fact, both PEs have received the VPN routes (BGP routes) destined
for each other's loopback interfaces. The received VPN routes, however, are on the same
network segment as that of the route 1.1.1.0/24 Direct. In this case, both PEs consider that
the received VPN routes are the same as 1.1.1.0/24 Direct, and therefore import only
1.1.1.0/24 Direct to their VPN routing tables because the direct route has a higher

Equipment
preference than the BGP route. As a result, both VPN routing tables do not contain the BGP
routes, and the PEs cannot ping each other successfully.
Procedure
Step 1 On PE1 and PE2, run the system-view command to enter the system view.
Step 2 Run the interface loopback loopback-number command to enter the loopback interface view.
Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the
loopback interface.
NOTE
Change the mask length of the loopback address to 32 bits.
Step 4 Run the return command to return to the user view and then run the save command to save the
modification.
After the preceding configurations, the PEs can ping each other successfully. The fault is cleared.
----End
Summary
If two routes of different protocols are destined for the same network segment, the device only
adds the one with a higher preference to the routing table.
The RR Fails to Reflect VPN Routes
Fault Symptom
On the network shown in Figure 9-3, an Route Reflector (RR) is configured to optimize BGP/
MPLS VPN services. Node B and RNC are in the same VPN. After the configuration is complete,
it is found that the RR can learn a VPNv4 route advertised by PE1 but PE2 fails to learn this
route.
Figure 9-3 Networking diagram of the RR failing to reflect VPN routes
Route Reflector
PE1 PE2
(Client1) (Client2)
Node B RNC

Equipment
Fault Analysis
1. Run the display current-configuration configuration bgp command on the RR and PEs.
It is found that route reflection relationships are correctly set up between the RR and two
PEs.
2. Run the display bgp vpnv4 all peer command on the RR. It is found that the IBGP peer
relationships between the RR and the PEs are in the Established state.
3. Run the display ip extcommunity-filter command on the RR to view information about
the extended community attribute filter.
Extended Community filter Number 1
deny rt : 100:1
permit rt : 200:1
The output of the display ip extcommunity-filter command indicates that the routes with
the RT being 100:1 are filtered out.
4. Run the display ip vpn-instance verbose command on PE1 to view detailed information
about all VPN instances.
Total VPN-Instances configured : 1
VPN-Instance Name and ID : a, 1

Create date : 2010/06/23 20:18:40 UTC+08:00 DST
Up time : 0 days, 00 hours, 02 minutes and 27 seconds
Route Distinguisher : 1:1
Export VPN Targets : 100:1
Import VPN Targets : 111:1
Label Policy : label per route
Import Route Policy : p1
Export Route Policy : p2
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
The VPN QoS configuration information : based on VPN
CIR: 10000000 PIR: 10000000 QoS-profile name: profile1
Tunnel Policy : tnlpolicy1
Description : This is a VPN for company1.
Maximum Routes Limit : 100
Log Interval : 5
Interfaces : GigabitEthernet0/2/0
The output of the display ip vpn-instance verbose command indicates that the packets
with the Export VPN Targets field being 100:1 are filtered out on the RR. As a result, the
RR does not reflect routes to PE2.
Procedure
Step 1 Run the system-view command on the RR to enter the system view.
Step 2 Run the ip extcommunity-filter 1 permit rt 100:1 command on the RR to make the Export RT
on PE1 and the RT of the extended community filter on the RR the same.
Step 3 Run the bgp as-number command on the RR to enter the BGP view.
Step 4 Run the ipv4-family vpnv4 command on the RR to enter the BGP-VPNv4 address family view.
Step 5 Run the undo rr-filter command on the RR to delete the original reflection policy of the RR.
Step 6 Run the rr-filter 1 command on the RR to specify a new reflection policy for the RR.

Equipment
After the preceding operations, PE2 can learn the VPNv4 routes advertised by PE1. The fault is
rectified.
----End
Summary
When configuring an RR, ensure that the Import VPN target and Export VPN target match the
RTs on PE1 and PE2.
To minimize the impact of incorrect configurations, you can run the undo policy vpn-target
command to permit all VPNv4 routes.
PEs Fail to Exchange Private Network Routes Because the Mask Set for the
Loopback Interface Is Not a 32-bit Mask
Fault Symptom
On the network shown in Figure 9-4, BGP/MPLS IP VPN services and OSPF are configured
on the two PEs and the P. A loopback interface is created on each PE and bound to a VPN
instance named vpn1. The IP address of the loopback interface on PE1 is 1.1.1.1; the IP address
of the loopback interface on PE2 is 1.1.1.2.
When the configuration is complete, the two PEs cannot exchange private network routes, and
the ping between them fails.
Figure 9-4 Networking diagram for the failure in exchanging private network routes between
PEs
Loopback1 Loopback1
GE0/2/0 GE1/0/1
PE1 PE2
GE1/0/2 GE1/0/1
P
Fault Analysis
1. Run the display ospf peer command on each PE, and you can view that the neighbor status
is Full. Run the display ip routing-table command on each PE, and you can view that each
PE has learned the route to Loopback1 on the peer PE.
2. Run the display mpls ldp session command on the P. You can view that the LDP peer
relationships between the P and PEs are established.
3. Run the display mpls lsp command on both PEs to check label allocation. You can find
that the PEs have LSPs to each other.
4. Run the display this command in the BGP-VPNv4 address family view on each PE. You
can find that the peer ipv4-address enable command has been configured. Run the display
bgp vpnv4 all peer command on each PE. You can find that the BGP peer relationships
are established between the PEs and between the PE and CE.

Equipment
5. Run the display ip routing-table vpn-instance vpn1 command on each PE to check the
VPN routing table. A route, 1.1.1.0/24 direct, with Loopback1 being the outbound interface,
is found in the routing table. The mask of the route is a 24-bit value rather than a 32-bit
value.
1.1.1.0/24 Direct 0 0 D 1.1.1.1 LoopBack1
6. Run the display ip interface brief command on each PE. You can find that a 24-bit mask
(not a 32-bit mask) is configured for the IP address of Loopback1.
Interface IP Address/Mask Physical Protocol
LoopBack1 1.1.1.1/24 up up(s)
In this manner, the IP addresses of loopback interfaces on the two PEs belong to the same
network segment (1.1.1.0/24). In fact, the PEs have learned private network routes from
each other. On each PE, the PE learned private network route and local Loopback1,
however, belong to the same network segment. Then, there are two routes to Loopback1
on the peer PE: One is a direct route; the other is a BGP route. In this case, the PE places
the direct route in its routing table, and there are no private network routes in the VPN
routing table. As a result, Loopback1 on the peer PE fails to be pinged.
Procedure
Step 2 Run the interface loopback1 command to enter the view of Loopback1 bound to the VPN
instance.
Step 3 Run the ip address ip-address { mask | mask-length } command to configure an IP address with
a 32-bit mask on each PE.
When the configuration is complete, the PEs can successfully ping Loopback1 on each other,
and the fault is rectified.
----End
Summary
When configuring BGP/MPLS IP VPN services, ensure that the IP addresses of the interfaces
bound to the same VPN instance but residing on different PEs belong to different network
segments.
9.2 VPLS Troubleshooting

This chapter describes common causes of VPLS faults and provides the corresponding
9.2.1 VSI of Martini VPLS Cannot Go Up

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the VSI of Martini VPLS cannot go Up.

Equipment
Common Causes
l Encapsulation types of both ends are different.

l MTUs of both ends are different.
l VSI IDs of both ends are different.
l LDP sessions are not in the Up state.
l The tunnel policy for selecting a TE tunnel as the public network tunnel is incorrectly
configured.
l The local or remote end of the tunnel does not go Up.
l The local or remote AC interface does not go Up.
After Martini VPLS is configured, the VSI cannot go Up.

Equipment
Figure 9-5 Troubleshooting flowchart for the fault that the VSI of Martini VPLS cannot go Up
The Martini VSI

is Down
Are
encapsulation types No Yes
of both ends the
same?
Yes No
Are MTUs No Yes

of both ends the Is fault rectified? End
same?
Yes No
Are the No Yes

VSI IDs of both ends Is fault rectified? End
the same?
Yes No
Is the LDP session No Yes

Up?
Yes No
No Yes
Tunnel is
Selected?
Yes No
Are AC No Yes
interfaces of both ends Is fault rectified? End
Up?
Yes No
Seek technical
support

Equipment
Context
NOTE
Procedure
Step 1 Check that the encapsulation types of both ends are the same.
<HUAWEI> display vsi name tt
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
tt static ldp unqualify vlan 1500 up
l If the encapsulation types of both ends are different, run the encapsulation { ethernet |
vlan } command in the VSI view to change the encapsulation type of either end, ensuring
that the encapsulation types of both ends are the same.
l If the encapsulation types of both ends are the same, go to Step 2.
NOTE
The same encapsulation type on both ends is one of the prerequisites for the VSI to go Up.
Step 2 Check that MTUs of both ends are the same.

<HUAWEI> display vsi name tt
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
tt static ldp unqualify vlan 1500 up
l If the MTUs of both ends are different, run the mtu mtu-value command in the VSI view to
change the MTU of either end, ensuring that the MTUs of both ends are the same.
l If the MTUs of both ends are the same, go to Step 3.
NOTE
The same MTU on both ends is one of the prerequisites for the VSI to go Up.
Step 3 Check that the VSI IDs or negotiation-VC-IDs of both ends are the same.
<HUAWEI> display vsi name tt verbose
***VSI Name : tt
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 3
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : 255
Domain Name :
Tunnel Policy Name : p1
Ignore AcState : disable
Create Time : 2 days, 2 hours, 47 minutes, 40 seconds

Equipment
VSI State : up
VSI ID : 101
*Peer Router ID : 2.2.2.2
VC Label : 187393
Peer Type : dynamic
Session : up
Tunnel ID : 0xc0060401
Broadcast Tunnel ID : 0xc0060401
CKey : 6
NKey : 5
StpEnable : 0
PwIndex : 0
Interface Name : GigabitEthernet0/2/1

State : up
Last Up Time : 2011/02/05 06:36:57
Total Up Time : 2 days, 2 hours, 40 minutes, 19 seconds
l If the VSI IDs or negotiation-VC-IDs are different for both ends, run the pwsignal ldp
command in the VSI-LDP view to modify the VSI ID of either end, or run the peer peer-
address negotiation-VC-ID vc-id command in the VSI-LDP view to modify the negotiation-
VC-ID of either end, ensuring that the VSI IDs or negotiation-VC-IDs of both ends are the
same.
l If the VSI IDs or negotiation-VC-IDs of both ends are the same, go to Step 4.
NOTE
The same VSI ID or negotiation-VC-ID on both ends is one of the prerequisites for the VSI to go Up.
Step 4 Check that the LDP session between both ends is Up.
Run the display vsi name vsi-name verbose command to check whether the Session field is
displayed as Up.
***VSI Name : tt
VSI Index : 3
PW Signaling : ldp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
VSI State : up
VSI ID : 101
VC Label : 187393
Peer Type : dynamic
Session : up
CKey : 6
NKey : 5
StpEnable : 0

Equipment
PwIndex : 0

State : up
Last Up Time : 2011/02/05 06:36:57
l If the LDP session between both ends is not Up, see LDP Session Goes Down to locate
the fault and enable the LDP session to go Up.
If the Layer 2 interface is not displayed in the display command output, run the l2 binding
vsi vsi vsi-name [ access-port ] command in the interface view to bind the interface to
the VSI.
l If the LDP session is Up and the interface is bound to the VSI, go to Step 5.
NOTE
The Up status of the LDP session is one of the prerequisites for both ends to perform the L2VPN negotiation.
Step 5 Check whether the VSI has selected a tunnel.
Run the display vsi name vsi-name verbose command to check the following:
l Check whether the Tunnel ID field is displayed as 0x0. If so, it indicates that the VSI does
not select a tunnel.
l Check the Tunnel Policy Name field. If this field is not displayed, it indicates that the VSI
selects an LDP LSP or no tunnel policy is configured for the VSI. If the VSI selects an MPLS-
TE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field
indicates the tunnel policy of the VSI. You can view details of the tunnel policy by running
the display this command in the corresponding tunnel policy view.
#
tunnel-policy p1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is configured

in the tunnel policy view, you also need to configure the mpls te reserved-for-binding command in the
tunnel interface view.
If the tunnel between both ends is not Up, refer to the session "LSP Goes Down" or "TE Tunnel
Goes Down" to locate the fault and ensure that the tunnel goes Up. If the tunnel between both
ends is Up and the TE interfaces are correctly configured, go to Step 6.
NOTE
The Up status of the tunnel is one of the prerequisites for the VSI to go Up.
Step 6 Check that the AC interfaces of both ends are in the Up state.
Run the display vsi name vsi-name verbose command on both ends to check whether the
interfaces corresponding to the Interface Name field are in the Up state.
l If not, refer to the section "Physical Interconnection & Interface Type" to locate the fault and
ensure that the AC interfaces go Up.
l If the AC interfaces on both ends are Up, go to Step 7.
NOTE
The Up status of AC interfaces on both ends is one of the prerequisites for the VSI to go Up.

Equipment
----End
Relevant Alarms
None.
Relevant Logs
None.
9.2.2 VSI Goes Up Only on One End

procedure for the fault that the VSI goes Up only on one end.
Common Causes
This fault is commonly caused by the following:
l The local end is specified as a UPE by the remote end.

l Multiple AC interfaces in the Up state are bound to the VSI on the local end but no tunnel
is selected.
After VPLS is configured, the VSI goes Up only on one end.

Equipment
Figure 9-6 Troubleshooting flowchart for the fault that the VSI goes Up only on one end
The VSI is Up only on the

local end
Is the local
end bound to two or more Yes
AC interfaces in the Up End
state?
No
Does Yes
the remote end specify
the local end as End
the UPE?
No
Context
NOTE
Procedure
Step 1 Check that multiple AC interfaces on the local end are bound to the VSI.
***VSI Name : tt
VSI Index : 3
PW Signaling : ldp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :

Equipment
VSI State : up
VSI ID : 101
VC Label : 187393
Peer Type : dynamic
Session : up
CKey : 6
NKey : 5
StpEnable : 0
PwIndex : 0

State : up
Last Up Time : 2011/02/05 06:36:57
State : up
Last Up Time : 2011/02/07 12:33:13
If two or more AC interfaces are bound to the VSI, this is a normal situation that the VSI status
is Up.
Step 2 Check that the remote end specifies the local end as the UPE.
[HUAWEI-vsi-tt-ldp] display this
#
vsi-id 101
peer 1.1.1.1 upe
#
l If the remote end specifies the local end as the UPE, it is normal to find that the VSI goes
Up only on one end. This situation is normal, and no action is required.
l If the remote end does not specify the local end as the UPE, but the fault persists, go to Step
3.
----End
Relevant Alarms
None.
Relevant Logs
None.

Equipment
VPLS Services Fail

In a Martini VPLS, VPLS packets are inconsistently encapsulated on the local device and the
remote device. As a result, VPLS services fail.
Fault Symptom
As shown in Figure 9-7, ATN connect with another vendor's device and functions as PE1, only
VPLS services fail.
Figure 9-7 Networking diagram of Martini VPLS

Outbound Inbound
MAN
CE2
PE1 PE2
Node B
(Huawei Device) (Another Vendor's device)
RNC
Martini VPLS
Fault Analysis
NOTE
Because only VPLS services fail, you can exclude the possibility of a link failure or the failure of another
device.
1. Run the display current-configuration command on PE1 to check whether the

configurations are correct and consistent with those of PE2. You can find that
configurations of PE1 are correct and consistent with those of PE2.
2. Run the display vpls connection command on PE1 to check the VCState field. You can
find that VCState is Up, indicating that a Layer 2 tunnel is established.
3. When Node B pings RNC, run the display traffic-statistics vsi vsi-name [ peer peer-
address [ negotiation-vc-id vc-id ] ] command on PE1 to check whether the packet sending
and receiving process is normal. You can find that packets can be correctly sent and
received.
4. When Node B pings RNC, you can capture VPLS packets in the inbound and outbound
directions of PE1 on another device of the MAN.
A captured VPLS packet in the inbound direction of PE1 is shown as follows:
0018 821D 2010 0014 1CD2 FC06 8847 22C0
01FE 0019 E019 0D9E 0019 21D5 5FD6 0806
0001 0800 0604 0002 0019 21D5 5FD6 0303
0301 0019 E019 0D9E 0303 0302 0000 0000
As indicated by the 0806 field, the captured VPLS packet sent from PE2 carries no VLAN
tag and is just a common ARP packet. PE1 and PE2, however, are configured with the
encapsulation mode of VLAN, causing PE1 to add a VLAN tag to the VPLS packet. After
adding a VLAN tag to the VPLS packet, PE1 forwards the packet in the outbound direction.

Equipment
A captured VPLS packet in the outbound direction of PE1 is shown as follows:

0019 E019 0D9E 0019 21D5 5FD6 8100 019b
0800 0604 0002 0019 21D5 5FD6 0303 0301
0019 E019 0D9E 0303 0302 0000 0000 0000
You can find that PE1 replaces the 0806 field (ARP packet identifier) with the 8100 field
(VLAN packet identifier). As a result, VPLS services fail. If the VLAN encapsulation mode
of PE2 (another vendor's device) is modified to send VLAN tags, or PE1 and PE2 are
configured with the encapsulation mode of Ethernet, the fault can be rectified.
Procedure
l Solution 1: Modify the VLAN encapsulation mode of another vendor's device to send
VLAN tags.
l Solution 2: Change the encapsulation mode on PE1 and PE2 to Ethernet. The Huawei device
(PE1) can be configured as follows:
2. Run the vsi vsi-name command to enter the VSI view.
3. Run the encapsulation ethernet command to set the VSI encapsulation mode as
Ethernet.
After the preceding configurations, Node B and RNC can ping each other successfully,
and VPLS services become normal.
----End
Summary
Why can the Layer 2 tunnel be Up when PE1 has incorrectly parsed packets?
To answer this question, check the configurations of PE2. You can find that the VPLS sending
and receiving on PE2 is in the hybrid mode. That is, PE2 can process any types of packets; when
receiving a VPLS packet carrying a VLAN tag, PE2 removes the VLAN tag and then forwards
the VPLS packet. This is the cause for the problem.
As defined by RFC 4448, if a packet transmitted on a PW is encapsulated to the tagged mode,
the packet must carry a VLAN tag. The Huawei device (PE1) complies with the RFC standard;
however, the other vendor's device (PE2) does not comply with the RFC standard.
VSIs Cannot Be Up in LDP Signaling Mode
Fault Symptom
Figure 9-8 Networking diagram of VPLS

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE0/2/0 POS2/0/0
168.1.1.1/24 169.1.1.1/24
PE1 PE2
GE1/0/0 POS1/0/0
168.1.1.2/24 P 169.1.1.2/24
Node B RNC

Equipment
VPLS in LDP signaling mode is configured on both PE1 and PE2. After the configuration, the
VSI on both PEs cannot be Up.
Then PE1 initiates CE-Ping to detect the IP address of RNC, but the detection fails. Locating
the fault, you find that the VSI cannot go Up.
Fault Analysis
1. Check the VSI status on PE1 and PE2.
Run the display vsi verbose command.
The display on PE1 is as follows.
VSI Name : v1
VSI Index : 0
PW Signaling : ldp
MTU : 1500
VSI State : down
VSI ID : 1
VC Label : 17409
Session : up
Tunnel ID : 0x6002002,
State : up
The display on PE2 is as follows.

VSI Name : v1
VSI Index : 0
PW Signaling : ldp
MTU : 1500
VSI State : down
VSI ID : 1
*peer Router ID : 2.2.2.9
VC Label : 17408
Session : up
Tunnel ID : 0x6002001,
State : up
ACs on both ends are Up. The tunnel on both ends of a PW is in existence, and the tunnel
ID is not 0x0.
2. According to the displayed PW information, you can find that the designated remote LDP
peer of the PE2 is not correct. It should be 1.1.1.9 rather than 2.2.2.9. Then modify the peer.
Procedure
Step 1 Run the display vsi verbose command on PEs.
Step 2 Check the status of VSI and AC. Find that the VSI is Down, but AC is Up.
Step 3 Check the status of the PW. Find that the PW cannot be set up.
Step 4 Check whether the tunnel is available. Find that the tunnel is ready.

Equipment
Step 5 Find that the designated remote LDP peer of the PE2 is not correct according to the displayed
PW information. The incorrectness makes the PW establishment failed. It should be designated
as 1.1.1.9 rather than 2.2.2.9. Modify the peer.
Step 6 Reconfigure the remote LDP peer of the PE2, which means to designate it as 1.1.1.9. Then the
PW is established successfully.
----End
Summary
If the signaling protocol is LDP and the VSI cannot be Up, the errors related to the peer are as
follows:
l The peer is specified incorrectly.

l The address of the peer is not the peer LSR-ID. The LDP remote session then cannot be
established.
l The LSR-ID of the peer is re-defined. Then the LDP remote session cannot be set up.
If a VSI is Up, there must be at least two ACs are Up, or at least one AC is Up and one PW is
Up.
To locate the fault, you can check the status of the AC and PW first.
l It is simple to let an AC go Up. You must bind the AC with a physical interface, and the
line protocol state of the interface must be Up.
l There are many conditions for a PW to go Up, such as the correct configurations of MTU,
encapsulation type, VSI ID, and remote peer. The key is that the local and the remote ends
can receive labels from each other.
You can run the display vsi remote { ldp } command to find which device is faulty according
to the label receiving.
Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are
Up
Fault Symptom
After configuring VPLS, check the VSI status on PEs. You find that both VSIs are Up, but the
packets cannot be forwarded successfully between two PEs.
Fault Analysis
1. Check whether the PW is available.
Run the display vsi verbose command to check whether the PW is available.
If the PW is not available, check whether the delivering status of the PW is "up", as shown
below:
l If the status is not "up", it shows that the forwarding information is not delivered to the
interface board, which leads to the failure of the forwarding.
l If the status is "up" but the forwarding still fails, check the operating status of the
interface board.

Equipment
2. Check the MAC limit.

If the PW is available, but packets cannot be forwarded between PEs, run the display
current-configuration | begin vsi vsi-name command to check the MAC limit. If the
number of MAC address entries exceeds the MAC limit, re-configure the MAC limit.
3. If the fault persists, contact the Huawei technical personnel.
Procedure
Step 1 Run the display vsi command to check whether the status of the PW is up.
Step 2 Run the display vpls connection command to check whether the PW is available.
Step 3 If the status is "up", check whether the operating status of the interface board is normal.
----End
Summary
The fault occurs when one of the following conditions is met:
l The PW information is not delivered to the forwarding chip.

l The number of MAC address entries exceeds the MAC limit.
VPLS Configurations on PEs Do Not Take Effect
Fault Symptom
On the network shown in Figure 9-9, VPLS services are deployed on PE1 and PE2. PE2 is a
non-Huawei device. After the configuration, CEs fail to ping each other and the PW connection
is Down.
The display mpls l2vc command output is as follows:

***VSI Name : v2
Isolate Spoken : enable
VSI Index : 1
PW Signaling : ldp
MTU : 1500
Diffserv Mode : pipe
Service Class : af1
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : down
VSI ID : 20
primary or secondary : primary
ignore-standby-state : no
VC Label : 17
Peer Type : dynamic

Equipment
Session : up
Tunnel ID :
Broadcast Tunnel ID : 0x0
Broad BackupTunnel ID : 0x0
CKey : 3
NKey : 1
Stp Enable : 0
PwIndex : 0

State : up
Access Port : false
Last Up Time : 2011/12/22 18:25:37
**PW Information:
*Peer Ip Address : 1.1.1.1

PW State : down
Local VC Label : 17
Remote VC Label : 16
PW Type : label
Tunnel ID :
Broadcast Tunnel ID : 0x0
Broad BackupTunnel ID : 0x0
Ckey : 0x3
Nkey : 0x1
Main PW Token : 0x0
Slave PW Token : 0x0
Tnl Type : Other
OutInterface :
Backup OutInterface :
Stp Enable : 0
PW Last Up Time : 2011/12/22 09:53:17
PW Total Up Time : 1 days, 7 hours, 15 minutes, 24 seconds
Figure 9-9 Networking diagram of the case where VPLS configurations do not take effect
PE1 PE2 RNC
MAN
Node B
Fault Analysis
1. Run the display current-configuration command on PE1 to view VSI-related
configurations.
2. Run the display vpls connection command on PE1 to view information about VPLS
connections. The result shows that there is one VPLS connection, the VSI label is correctly
allocated, and the VSI status is Up.
1 total connections,
connections: 1 up, 0 down, 1 ldp
VSI Name: v1 Signaling: ldp
VsiID EncapType PeerAddr InLabel OutLabel VCState
1 vlan 1.1.1.1 17408 17409 up

Equipment
3. Run the display mpls l2vc command on PE1 to view the encapsulation mode of packets.
***VSI Name : v2
Isolate Spoken : enable
VSI Index : 1
PW Signaling : ldp
MTU : 1500
Diffserv Mode : pipe
Service Class : af1
Color : --
DomainId : 255
Domain Name :
Ignore AcState : enable
P2P VSI : disable
VSI State : up
The result shows that PE1 adds VLAN tags to ARP packets before forwarding them to PE2
but PE2 cannot process APR packets with VLAN tags. Instead, PE2 encapsulates packets
with Ethernet headers. VPLS configurations, therefore, do not take effect.
Procedure
Step 1 Run the system-view command to enter the system view on the PE1.
Step 2 Run the vsi vsi-name command to enter the VSI view.
Step 3 Run the encapsulation ethernet command to configure the encapsulation mode as Ethernet.
After the preceding operations, VPLS configurations take effect and CEs can ping each other
successfully. The fault is rectified.
----End
Summary
PE2 can receive and process VPLS packets with or without VLAN tags. After receiving a VLAN-
tagged packet, PE2 strips off the tag and forwards it to PE1. PE1, however, cannot parse the
packet.
As defined in RFC 4448, if packets are tagged, they must carry VLAN tags when being
transmitted over PWs. In this troubleshooting case, the ATN complies with the RFC whereas
the non-Huawei device does not comply with the RFC.
9.3 VLL Troubleshooting

This chapter describes common causes of VLL faults and provides the corresponding
9.3.1 The VC of Martini VLL Cannot Be Up

Equipment
Common Causes
l The encapsulation types of both ends of the VC are different.

l The MTUs of both ends of the VC are different.
l The VC IDs of both ends of the VC are different.
l The control word configurations of both ends of the VC are different.
l The rtp-headers of both ends of the VC are different.
l The LDP session is not Up.
l The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public
network tunnel.
l The tunnel on the local or remote end is not Up.
l The AC interface on the local or remote end is not Up.
The VC cannot be Up after Martini VLL is configured.

Equipment
Figure 9-10 Troubleshooting flowchart for the VC of Martini VLL failing to be Up
VC of
Martini VLL
cannot be
Up
Encapsulation No Yes
types of both ends Fault rectified? End
the same?
Yes No
MTUs of both No Yes

Fault rectified? End
ends the same?
Yes No
VC IDs of both No Yes

ends the same
No
Yes
No Yes
LDP session is Fault rectified? End
Up?
No
Yes
No Yes
Tunnel is
Selected?
No
Yes
No Yes
AC interfaces
are Up?
Yes No
Seek technical
support

Equipment
Context
NOTE
Procedure
Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU.
Run the display mpls l2vc vc-id command to check VC information.
<HUAWEI> display mpls l2vc 243
Total LDP VC : 1 0 up 1 down
*client interface : GigabitEthernet0/2/0 is up

Administrator PW : no
session state : down
AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
VC type : IP-interworking
destination : 3.0.0.3
local VC label : 16 remote VC label : 0
control word : disable
forwarding entry : not exist
local group ID : 0
manual fault : not set
active state : inactive
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
local VC MTU : 1500 remote VC MTU : 0
tunnel policy name : gq
PW template name : --
load balance type : flow
Access-port : false
create time : 9 days, 0 hours, 37 minutes, 58 seconds
up time : 0 days, 0 hours, 0 minutes, 0 seconds
last change time : 9 days, 0 hours, 37 minutes, 58 seconds
VC last up time : 0000/00/00 00:00:00
VC total up time : 0 days, 0 hours, 0 minutes, 0 seconds
CKey : 2
NKey : 1
AdminPw interface : --
AdminPw link state : --
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the two ends are configured with different encapsulation types or MTUs, change the
encapsulation type or MTU of one end to be the same as that of the other end.

Equipment
If the two ends are configured with the same encapsulation type and MTU but the fault persists,
go to Step 2.
NOTE
A VC can be Up only when the two ends of the VC are configured with the same encapsulation type and
MTU.
Step 2 Check that the VC IDs of both ends of the VC are the same.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same
as that of the other end.
If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3.
NOTE
A VC can be Up only when the VC IDs of both ends of the VC are the same.

Equipment
Step 3 Check that the CWs configuration of both ends of the VC are the same.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the CWs configuration of both ends of the VC are different, change the VC ID of one end to
be the same as that of the other end.
If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step
4.
NOTE
A VC can be Up only when the CWs of both ends of the VC are the same.
Step 4 Check that the LDP session between the two ends is Up.

AC status : up

Equipment
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the
LDP session Up.
If the LDP session is Up but the fault persists, go to Step 5.
NOTE
A VC can be set up only when the LDP session is Up.
Step 5 Check whether the PW has selected a tunnel.
Run the display mpls l2vc vc-id command.
l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is
displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW.
l Check the tunnel policy name field in the command output.
If tunnel policy name is displayed as "--", it indicates that an LDP LSP is used as the
tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for
a PW only after a tunnel policy is configured.
If tunnel policy name is not displayed as "--", it indicates that a tunnel policy is adopted.
In this case, you can run the display this command in the tunnel policy view to view the
tunnel policy configuration.

Equipment

#
tunnel-policy p1
#
NOTE

in the tunnel policy view, you also need to run the mpls te reserved-for-binding command on the tunnel
interface.
If the tunnel is Down, see "An LSP Is Down" or "A TE Tunnel Is Down" to locate the fault and
then turn the tunnel Up. If the tunnel is Up and the TE interfaces are correctly configured, go to
Step 6.
NOTE
A VC can be Up only when the tunnel that bears the VC is Up.
Step 6 Check that the AC interfaces on the two ends are Up.
Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC
status field is displayed as Up.
l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to
locate the fault and turn the AC interfaces Up.
l If the AC interfaces on the two ends are Up, go to Step 7.
NOTE
A VC can be Up only when the AC interfaces on both ends of the VC are Up.
----End
Relevant Alarms
None.
Relevant Logs
None.

Equipment
Both the Session and the AC Are Up, But the VC Cannot Be Up
Fault Symptom
Figure 9-11 Networking diagram

PE1 GE2/0/0 PE2
100.1.1.2/24
GE0/2/0
10.1.1.2/24 GE0/2/1 GE1/0/0
100.1.1.1/24 10.1.1.1/24
GE1/0/0
10.1.1.1/24 GE1/0/0
10.1.1.2/24
Node B RNC
As shown in Figure 9-11, the VC cannot go Up after Martini VLL is configured, and all
parameters about the remote end are 0s, namely, invalid values. Check the session and the AC,
and find both of them are Up.
Fault Analysis
Use the display mpls l2vc vc-id command on the PE to check whether the MTU values at both
ends are consistent. For example:
# Check the MTU value of the GE interface on PE1.

[PE1-GigabitEthernet0/2/0] display mpls l2vc 100
total LDP VC : 1 0 up 1 down
*client interface : GigabitEthernet0/2/0

session state : up
AC status : up
VC state : down
VC ID : 100
VC type : ethernet
local group ID : 0
active state : active
link state : down
tunnel policy name : --
traffic behavior name: --
PW template name : pwt1
VC last up time : 2009/04/07 16:19:26
# View the MTU value of the GE interface on PE2.


Equipment

session state : up
AC status : up
VC state : down
VC ID : 100
VC type : ethernet
local group ID : 0
link state : down
PW template name : pwt1
VC last up time : 2009/04/07 16:19:26
The display shows that the MTU value of the local end is not consistent with that of the remote
end, which leads to the parameter negotiation failure.
Modify the MTU value on either PE to make the MTU values consistent at both ends.
For example, change the MTU value of the interface on PE2 to make it consistent with that on
PE1.
[PE2-GigabitEthernet1/0/0] mtu 80
[PE2-GigabitEthernet1/0/0] shutdown
[PE2-GigabitEthernet1/0/0] undo shutdown
After the modification, the VC goes Up.


session state : up
AC status : up
VC state : up
VC ID : 100
VC type : ethernet
forwarding entry : exist
local group ID : 0
link state : up
VC last up time : 2009/04/07 16:19:26

Equipment
Procedure
Step 1 Check whether the correct peer addresses are configured on PEs at both ends.
Step 2 Check whether the VC IDs at both ends are the same.
Step 3 Check whether the encapsulation types at both ends are the same.
Step 4 Check whether the control word is enabled or disabled at both ends. Both ends must enable or
disable the control word simultaneously.
Step 5 Check whether the MTU values are consistent at both ends.
Step 6 If inconsistency occurs, modify the MTU value on either end to ensure consistency.
Step 7 Use the shutdown command and then the undo shutdown command on the modified interface.
----End
Summary
PWE3 extends Martini interface parameters. Some of them must be supported, and others need
not be supported. Some of them must be matched while others need not match during the
negotiation.
The following lists the Martini interface parameters.
Code Length Description
0x01 4 Interface MTU in octets
0x02 4 Maximum Number of concatenated ATM cells
0x03 up to 82 Optional Interface Description string
0x04 4 CEM [8] Payload Bytes
0x05 4 CEM options
The following shows the PWE3 interface parameters.
0x01 4 Interface MTU in octets
0x02 4 Maximum Number of concatenated ATM cells
0x03 Up to 82 Optional Interface Description string
0x04 4 CEP/TDM Payload Bytes
0x05 4 CEP options
0x06 4 Requested VLAN ID
0x07 6 CEP/TDM bit-rate

Equipment
0x08 4 Frame-Relay DLCI Length
0x09 4 Fragmentation indicator
0x0A 4 FCS retention indicator
0x0B 4/8/12 TDM options
0x0C 4 VCCV parameter
Items from 0x06 to 0x0C are extended in PWE3.
When configuring interface parameters, note the following:
l The same MTU must be specified for the Ethernet interface; otherwise, the PW cannot be
Up.
l In ATM cell (0x0003 ATM transparent cell transport, 0x0009 ATM n-to-one VCC cell
transport and 0x000A ATM n-to-one VPC cell transport) mode, the maximum ATM cell
number must be sent to the peer in order to inform the peer how many cells it can handle
at a time. When the remote end encapsulates packets, this number should not be exceeded.
Inconsistency of the cell number at both ends does not affect the status of a PW.
l Fragmentation and ATM cell have the same handling mode. The configuration of
fragmentation and ATM cell handling mode is optional and may not be consistent at both
ends. The local end only informs the remote end whether it can perform reassembly. The
remote end decides whether to fragment packets according to the packet size and its
fragmentation capability. The fragmentation capability does not affect the status of a PW,
and it is not necessary to be the same at both ends.
l VCCV processing is similar to ATM cell and fragmentation capability. The VCCV
configuration is optional. The local end uses VCCV to inform the remote end of its VCCV
capability. When performing VCCV, the peer chooses a path (CC) and a method (CV)
according to the configuration at both ends. VCCV does not affect the status of a PW, and
is not required consistent at both ends.
l The Request VLAN ID is used to inform the peer of its capability. During the forwarding,
the remote end is required to insert a VLAN ID on its Layer 2 frame header. Other means
can also be used. This configuration is optional. If the Request VLAN ID is carried, the
VLAN IDs can be different at both ends.
9.4 PWE3 Troubleshooting

This chapter describes common causes of PWE3 faults and provides the corresponding
9.4.1 The PW Cannot Be Up

procedure for the fault that the PW of PWE3 cannot be Up.

Equipment
Common Causes
l The encapsulation types of both ends of the VC are different.

l The MTUs of both ends of the VC are different.
l The VC IDs of both ends of the VC are different.
l The control word configurations of both ends of the VC are different.
l The rtp-headers of both ends of the VC are different.
l The LDP session is not Up.
l The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public
network tunnel.
l The tunnel on the local or remote end is not Up.
l The AC interface on the local or remote end is not Up.
The VC cannot be Up after Martini VLL is configured.

Equipment
Figure 9-12 Troubleshooting flowchart for the VC of Martini VLL failing to be Up
VC of
Martini VLL
cannot be
Up
Encapsulation No Yes
types of both ends Fault rectified? End
the same?
Yes No
MTUs of both No Yes

ends the same?
Yes No
VC IDs of both No Yes

ends the same
No
Yes
No Yes
LDP session is Fault rectified? End
Up?
No
Yes
No Yes
Tunnel is
Selected?
No
Yes
No Yes
AC interfaces
are Up?
Yes No
Seek technical
support

Equipment
Context
NOTE
Procedure
Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU.
Run the display mpls l2vc vc-id command to check VC information.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the two ends are configured with different encapsulation types or MTUs, change the
encapsulation type or MTU of one end to be the same as that of the other end.

Equipment
If the two ends are configured with the same encapsulation type and MTU but the fault persists,
go to Step 2.
NOTE
A VC can be Up only when the two ends of the VC are configured with the same encapsulation type and
MTU.
Step 2 Check that the VC IDs of both ends of the VC are the same.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same
as that of the other end.
If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3.
NOTE
A VC can be Up only when the VC IDs of both ends of the VC are the same.

Equipment
Step 3 Check that the CWs configuration of both ends of the VC are the same.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the CWs configuration of both ends of the VC are different, change the VC ID of one end to
be the same as that of the other end.
If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step
4.
NOTE
A VC can be Up only when the CWs of both ends of the VC are the same.
Step 4 Check that the LDP session between the two ends is Up.

AC status : up

Equipment
VC state : down
Label state : 0
Token state : 0
VC ID : 243
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the
LDP session Up.
If the LDP session is Up but the fault persists, go to Step 5.
NOTE
A VC can be set up only when the LDP session is Up.
Step 5 Check whether the PW has selected a tunnel.
Run the display mpls l2vc vc-id command.
l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is
displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW.
l Check the tunnel policy name field in the command output.
If tunnel policy name is displayed as "--", it indicates that an LDP LSP is used as the
tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for
a PW only after a tunnel policy is configured.
If tunnel policy name is not displayed as "--", it indicates that a tunnel policy is adopted.
In this case, you can run the display this command in the tunnel policy view to view the
tunnel policy configuration.

Equipment

#
tunnel-policy p1
#
NOTE

in the tunnel policy view, you also need to run the mpls te reserved-for-binding command on the tunnel
interface.
If the tunnel is Down, see "An LSP Is Down" or "A TE Tunnel Is Down" to locate the fault and
then turn the tunnel Up. If the tunnel is Up and the TE interfaces are correctly configured, go to
Step 6.
NOTE
A VC can be Up only when the tunnel that bears the VC is Up.
Step 6 Check that the AC interfaces on the two ends are Up.
Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC
status field is displayed as Up.
l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to
locate the fault and turn the AC interfaces Up.
l If the AC interfaces on the two ends are Up, go to Step 7.
NOTE
A VC can be Up only when the AC interfaces on both ends of the VC are Up.
----End
Relevant Alarms
None.
Relevant Logs
None.
PW Attributes Cannot Be Changed by Using the reset pw Command
Fault Symptom
After a PW is configured on a PE, change PW attributes.

Equipment
Use the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command. You find that PW attributes are unchanged.
# Check the configuration of the PW template on PE.

[PE] display pw-template pwt1
PW Template Name : pwt1
PeerIP : 1.1.1.1
Tnl Policy Name : --
CtrlWord : Disable
MTU : 1500
Max Atm Cells : 28
ATM Pack Overtime: 1000
Seq-Number : Disable
Transmit ATM Cells : 28
TDM Encapsulation Number: 8
Jitter-Buffer : 4
Idle-Code : ff
Rtp-Header : Disable
VCCV Capability : alert ttl lsp-ping bfd
Total PW : 0, Static PW : 0, LDP PW : 0
# Configure a PW by applying the PW template.

[PE-GigabitEthernet0/2/0] mpls l2vc pw-t pwt1 2.2.2.2 100
# View the PW configuration.

[PE-GigabitEthernet0/2/0] display mpls l2vc 100

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 100
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1

Equipment
Service Class : --
Color : --
DomainId : --
Domain Name : --
# Specify a new peer address for the PW in the PW template.

[PE] pw-template pwt1
[PE-pw-template-pwt1] peer-address 3.3.3.3
Info: The attribute of this PW template has been modified, please use PW restart
command to update PW's attribute
According to the prompt, do as follows.

[PE-pw-template-pwt1] return
# Reset the PW.

<PE> reset pw 100 ethernet
# View the output, and find that the peer IP address of the PW is unchanged.
<PE> display mpls l2vc 100

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 100
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --

Equipment
Color : --
DomainId : --
Domain Name : --
# Reset the PW template.

<PE> reset pw pw-template pwt1
# View the output, and find that the peer IP address of the PW still does not change.

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 100
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
Fault Analysis
Some PW attributes can be configured by using the PW template or by using the CLI command.
However, the latter method has the higher priority.
If PW attributes are specified in the CLI, then those specified in the PW template are invalid.
The PW attributes do not change if the reset pw pw-template pw-template-name command or
the reset pw pw-id pw-type commands are run.

Equipment
In this case, you can use the PW template to set PW attributes, rather than using the CLI
command. Do as follows:
# Specify the peer IP address in the PW template.
[PE] pw-template pwt1
[PE-pw-template-pwt1] peer-address 3.3.3.3
[PE-pw-template-pwt1] quit
# Apply the template to the PW.

[PE] interface GigabitEthernet0/2/0
[PE-GigabitEthernet0/2/0] mpls l2vc pw-t pwt1 100
# View the output, and find that the IP address of the PW peer is unchanged.
[PE-GigabitEthernet0/2/0] display mpls l2vc 100

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 100
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
[PE-GigabitEthernet0/2/0] return
<PE> reset pw 100 GigabitEthernet0/2/0
# View the output, and find that the IP address of the PW peer changes.

Equipment

AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 100
local group ID : 0
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : down
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
Procedure
Step 1 Create a PW template, and set PW attributes (especially those needing changes) on it.
Step 2 Apply the PW template to the PW.
Step 3 Run the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command in the user view to modify PW attributes.
----End
Summary
The reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command can only change the attributes that are set by the PW template.

Equipment
VPN Services Between Two PEs Are Unavailable
Fault Symptom
PWE3 internetworking is configured in a test, as shown in Figure 9-13.
Figure 9-13 PWE3 internetworking

MPLS Backbone

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE0/2/1 POS2/0/0
100.1.1.1/24 100.2.1.2/24
GE1/0/0 POS2/0/0
100.1.1.2/24 100.2.1.1/24
PE1 GE0/2/2 P POS1/0/0 PE2
PW
GE1/0/0.1 POS1/0/0
10.1.1.1/24 10.1.1.2/24
Node B RNC
After the configuration, Node B can receive data from RNC, but RNC cannot receive data from
Node B.
Fault Analysis
1. Run the ping vc command to check whether the VC between the two PEs can normally
forward data. You can find that the VC between the two PEs can forward packets normally.
<PE1> ping vc ip-interworking 100 control-word remote 100
Reply: bytes=100 Sequence=1 time = 11 ms
--- FEC: FEC 128 PSEUDOWIRE (NEW). Type = ethernet, ID = 100 ping statistics---
0.00% packet loss
round-trip min/avg/max = 4/5/11 ms
2. Run the tracert command. You can find that RNC can normally receive packets from Node
B and all packets sent by RNC can reach PE1. This indicates that the fault occurs on the
link between PE1 and Node B.
3. Run the display this command on GE 0/2/2 of PE1 to view the configuration of the AC
interface. You can find that the local-ce ip and local-ce mac commands are not used.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the AC interface view of
PE1.

Equipment
Step 3 Run the local-ce ip ip-address command to configure the IP address of the local CE interface,
or run the local-ce mac mac-address command to configure the MAC address of the local CE
interface.
Step 4 Run the return command to return to the user view.
Step 5 Run the save command to save the modification of the configuration.
After the preceding configurations, the fault is thus rectified.
----End
Summary
When configuring PWE3 internetworking, you need to run the local-ce ip command or the local-
ce mac command to configure the MAC address or IP address for the CE interface if the AC
interface of the related PE is an Ethernet interface.
Failed to Establish OSPF Neighborhood Between CEs
Fault Symptom
As shown in Figure 9-14, CE1 is dual-homed to PE1 and PE2; CE2 is dual-homed to PE3 and
PE4.
l CE1 and CE2 are connected to PEs through Frame Relay (FR).
l PWs are set up between PE1 and PE3, and between PE2 and PE4, using MPLS LSPs as
the tunnel.
l When the path CE2 - PE3 - P1 - PE1 - CE1 fails, L2VPN traffic can be fast switched to the
backup path CE2 - PE4 - PE2 - CE1.
l When the path CE2 - PE3 - P1 - PE1 - CE1 recovers, L2VPN traffic can be switched back
to this path.
Virtual Leased Line Fast Reroute (VLL FRR) symmetric networking is deployed on PEs; 128
sub-interfaces with different IP addresses are created on CEs. Open Shortest Path First (OSPF)
is run on CE1 and CE2 to advertise the IP addresses of the sub-interfaces to each other. The
problem is that the status of most neighborhood cannot be Full on CEs and CEs cannot
communicate.
Figure 9-14 Symmetric VLL FRR networking

PE1 P1 PE3
POS1/0/0 GE2/0/0 GE2/0/0 POS1/0/0
GE1/0/0 GE2/0/0
GE0/2/0 GE0/2/0
CE1 CE2
GE0/2/1 PE2 P2 PE4 GE0/2/1

GE2/0/0 GE2/0/0
POS1/0/0 GE1/0/0 POS1/0/0
GE2/0/0

Equipment
Fault Analysis
The MTU of Ethernet interfaces on CEs is set to 4470. The type of the links connecting PEs and
Ps are Ethernet and hence the maximum MTU is 1500. Therefore, when a large number OSPF
neighbors are configured on CEs, the size of an OSPF packet is larger than 1500. VLL does not
support packet fragmentation. Therefore, the large packets from CEs are discarded when they
are forwarded through the VLL between PEs and Ps. In this way, OSPF neighborhood cannot
be set up between CEs.
Procedure
Step 2 Run the interface interface-type interface-number.subinterface-number command to enter the

AC sub-interface view.
Step 3 Run the mtu mtu command to configure the MTU of the sub-interface.
Step 4 Run the shutdown command to close the current sub-interface.
Step 5 Run the undo shutdown command to start the current sub-interface.
After the preceding configurations, OSPF neighborhood can be established between CEs and
the fault is rectified.
----End
Summary
L2VPN does not support packet fragmentation. So, large packets sent from the CE to the PE
cannot be forwarded to the PSN side. When configuring VLL, you are recommended to set the
MTU value of the interface connecting the CE to the PE to 1500 by using the mtu command.
As a result, larger packets sent by the CE to the PE are fragmented first. The fragmented packets
can be correctly forwarded in the public network.

Equipment
Troubleshooting 10 Security
10 Security
About This Chapter
10.1 URPF Troubleshooting

Equipment
10.1 URPF Troubleshooting
10.1.1 URPF Check Fails

This section includes common causes, a troubleshooting flowchart, troubleshooting procedure,
and relevant alarms and logs for the fault that occurs when the URPF-enabled device does not
discard packets as expected.
Common Causes

l There are source addresses of the packets that should be discarded in the routing entries.
l There are default routes in the routing table.
l The matching rules configured on the device are incorrect.
A URPF-enabled device receives certain packets that it should discard, but statistics show that
no packets are discarded by the device. In this case, follow the troubleshooting flowchart shown
in Figure 10-1 to isolate the problem.
l Check whether there are default routes and routes with the source addresses of the packets
that should be discarded in the routing table.
l Check whether the matching rules are correct.
Figure 10-1 Troubleshooting flowchart for URPF
Device configured with URPF loose

check does not discard packets.
No
Route with the Yes Yes

source address of the packet Delete the route
that should be discarded in the Fault rectified?
entry.
routing table?
No
No
Incorrect matching rules Yes Yes

Configure correct
configured? Fault rectified?
rules.
No
No
Seek technical End

support

Equipment
Context
NOTE
Save the results of each troubleshooting step. If 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 there are no default routes and routes with the source addresses of the packets that
should be discarded in the routing table.
Run the display ip routing-table command in the user view to check the Destination/Mask field
in the routing table.
l If the routing table contains routes with the source addresses of packets that should be
discarded, configure certain rules and import the rules into the filter to deny the packets sent
along these routes. For detailed configuration, see "Routing Policy Configuration" in the
Configuration Guide - IP Routing.
l If the routing table does not contain such routes, go to Step 2.
----End
Relevant Alarms
None
Relevant Logs
None
Ping Fails After URPF Is Configured
Fault Symptom
On the network shown in Figure 10-2, ATN-C is dual-homed to two ATNs in load balancing
mode. The cost of the link between ATN-A and ATN-B is 500; the cost of the link between

Equipment
ATN-C and ATN-A is 800; the cost of the link between ATN-C and ATN-B is 800. Strict URPF
is configured on ATN-A and ATN-B to protect them from DoS attacks from ATN-C. After the
configurations, ATN-B can ping GE 0/2/1 on ATN-C successfully but cannot ping GE 0/2/0 of
ATN-C.
Figure 10-2 Ping failure after URPF is configured

GE0/2/2
ATN-A
800
GE0/2/0
500
GE0/2/1
ATN-C
800
GE0/2/3 ATN-B
Fault Analysis
1. Run the display ip routing-table command on ATN-B to check routing entries. The
command output shows that routing information is correct.
2. Run the undo ip urpf command on ATN-A and ATN-B to disable URPF.
The ping failure occurs after URPF is enabled. Therefore, it is suspected that URPF discards
Ping packets. Therefore, you can disable URPF and then check whether the ping operation
succeeds.
3. Analyze the path along which a ping request packet travels.
When ATN-B pings GE 0/2/1, two paths are available, that is, ATN-B -> ATN-C with the
cost being 800 and ATN-B -> ATN-A -> ATN-C with the cost being 2100. The first path
is preferentially used. For the ping response packet, two paths are available, that is, ATN-
C -> ATN-B with the cost being 800 and ATN-C -> ATN-A -> ATN-B with the cost being
1300. The first path is preferentially used.
When ATN-B pings GE 0/2/0, two paths are available, that is, ATN-B -> ATN-C with the
cost being 1600 and ATN-B -> ATN-A -> ATN-C with the cost being 1300. The second
path is preferentially used. For the ping response packet, two paths are available, that is,
ATN-C -> ATN-B with the cost being 800 and ATN-C -> ATN-A -> ATN-B with the cost
being 1300. The first path is preferentially used.
The URPF check are available in two forms: URPF loose check and URPF strict check.
l In the URPF loose check, a packet can pass the URPF check as long as the forwarding
table has a routing entry whose destination address is the source address of the packet.
The URPF loose check does not require that the inbound interface of the packet be the
same as the outbound interface in the routing entry.
l In the URPF strict check, a packet can pass the URPF check only if the forwarding table
has a routing entry whose destination address is the source address of the packet and
whose outbound interface is the same as the inbound interface of the packet.
It can therefore be concluded that this problem is caused by the URPF strict check. In this
troubleshooting case, when ATN-B pings GE 0/2/0, the paths of ping request packets and
ping response packets are different. As a result, ping response packets cannot pass the URPF
strict check, and therefore the ping fails.

Equipment
Procedure
Step 1 Run the system-view command on ATN-A and ATN-B to enter the system view.
Step 2 Run the interface interface-type interface-number command on ATN-A and ATN-B to enter
the view of GE 0/2/2 on ATN-A and the view of GE 0/2/3 on ATN-B.
Step 3 Run the ip urpf loose command on ATN-A and ATN-B to enable the URPF loose check
function.
After the preceding operations, ATN-B can ping both GE 0/2/0 and GE 0/2/1 on ATN-C. The
fault is thus rectified.
----End
Summary
On the network where a device has two uplink paths, it is not recommended to configure the
URPF strict check function on the device.

Equipment
Troubleshooting 11 Reliability
11 Reliability
About This Chapter
11.1 BFD Troubleshooting
11.2 Y.1731 Troubleshooting

This chapter describes common causes of a Y.1731 fault, and provides the corresponding
troubleshooting flowchart, troubleshooting procedure, alarms, and logs.
11.3 MPLS-TP OAM Troubleshooting

This chapter describes common causes of MPLS-TP OAM faults, and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, logs, and
commands.
11.4 Error Code Detection Troubleshooting

Equipment
11.1 BFD Troubleshooting
11.1.1 BFD Session Cannot Go Up
Common Causes
l The discriminators of the two devices are inconsistent.
l The link detected by the BFD session fails. As a result, BFD packets cannot be exchanged
between the two ends of the BFD session.
l The BFD session status flaps.

Equipment

Equipment
Figure 11-1 Troubleshooting flowchart for the fault that a BFD session cannot go Up
A BFD session
can not go Up
Configuration No Commit the Yes

of the BFD session is Is fault rectified?
comfiguration
commited?
No
Yes
set consistent
Check whether the No Yes
discriiminators for
discriminators of the two Is fault rectified?
the two devices.
devices are consistent?
No
Yes
BFD packets No
Collect debugging Seek technial
can be received and sent
information support
correctly?
Yes
Yes
Statistics about
error packets exist?
No
Two ends of the Yes Does the down

No
BFD session can ping counts of BFD session
each other? increase?
No Yes
Adjust the BFD

Check the link detection time
No
No Yes
Is fault rectified? Is fault rectified?
Collect debugging
Yes information
Seek technial support
End

Equipment
Context
NOTE
Procedure
Step 1 Run the display bfd configuration all command to check that the configurations of the BFD
session are committed.
l If the commit field is True, it indicates that the configurations of the BFD session have been
committed. Then, go to Step 2.
l If the commit field is False, it indicates that the configurations of the BFD session have not
been committed. In this case, run the commit command to make the configurations take
effect. After doing so, run the display bfd session all command to check the State field.
If Up is displayed, it indicates that the BFD session is successfully established.
If Up is not displayed, go to Step 2.
Step 2 Run the display bfd session all Verbose command to check whether the discriminators of the
two devices are consistent.
l If not, run the discriminator { local discr-value | remote discr-value } command to set
consistent discriminators for the two devices. Then, go to Step 3.
l If yes, go to Step 4.
Step 3 Run the display bfd session all command to check the State field.
l If Up is displayed, it indicates that the BFD session is successfully established.
l If Up is not displayed, go to Step 4.
Step 4 Run the display bfd statistics session all command several times to check statistics about the
BFD packets of the BFD session.
l If the value of the Received Packets field does not increase, go to Step 5.
NOTE
For single-hop BFD, if two devices that have created a BFD session learn ARP entries with different
VLAN IDs, there is a possibility that the Received Packets count will not increase and the BFD session
will go Down.
l If the value of the Send Packets field does not increase, go to Step 6.
l If the values of Received Packets and Send Packets fields increase, go to Step 9.
l If none of the values of the Received Packets, Send Packets, Received Bad Packets, and
Send Bad Packets fields increase, go to Step 7.
l If the value of the Down Count field increases, it indicates that the BFD session flaps. Then,
go to Step 7.
Step 5 Run the display bfd statistics session all command several times to check the Received Bad
Packets field.

Equipment
l If the value of this field increases, it indicates that the BFD packets have been received and
discarded. Then, go to Step 9.
l If the value of this field does not increase, it indicates that the BFD packets have not been
received. Then, go to Step 7.
Step 6 Run the display bfd statistics session all command several times to check the Send Bad
Packets field.
l If the value of this field increases, it indicates that the BFD packets sent by the BFD session
have been discarded. Then, go to Step 9.
l If the value of this field does not increase, it indicates that the BFD packets failed to be sent.
Then, go to Step 7.
Step 7 Run the display bfd statistics session all command several times. If the BFD session still does
not go Up, run the ping command on one end to ping the other end of the BFD session.
l If the ping fails, it indicates that the link fails. See the section The Ping Operation Fails to
rectify the fault on the link.
l If the ping is successful, it indicates that the link is reachable. Then, go to Step 8.
Step 8 Run the display bfd session all Verbose command to view the min-tx-interval and min-rx-
interval fields to check that the BFD detection period is longer than the delay on the link.
l If the BFD detection period is shorter than the delay on the link, run the detect-multiplier,
min-rx-interval, and min-tx-interval commands to adjust the values to make the BFD
detection timer longer than the delay on the link.
l If the BFD detection time is longer than the delay time on the link, go to Step 9.
personnel.
----End
Relevant Alarms
BFD/3/BFD_DOWN_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.1 Session changes to DOWN.
(Index=16389, ConfigurationName=2/1/0, PeerIp=224.0.0.108, BindIfIndex=134217985,
BindIfName=GigabitEthernet2/1/0, Diagnosis=1, BindVrfIndex=0, BindVpnName="",
SessionType=1, DefaultIp=2, BindType=1, StaticLspName="", PwSecondary=0,
NextHop=224.0.0.108, VcId=0, VsiName="", VsiPeerAddress=0.0.0.0, DiscrAuto=2)
BFD/3/BFD_UP_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.2 Session changes to UP.
Relevant Logs
%%01BFD/4/STACHG_TODWN(l):Slot=1;BFD session changed to Down. (SlotNumber=1,
Discriminator=18, Diagnostic=DetectDown, Applications=IFNET, ProcessPST=True,
BindInterfaceName=GigabitEthernet1/1/11, InterfacePhysicalState=Up,
InterfaceProtocolState=Down)

Equipment
%%01BFD/4/STACHG_TOUP(l):-Slot=2; Slot BFD session changed to Up. (SlotNumber=2,

Discriminator=9469, FormerStatus=Init)
11.1.2 A BFD Session for a Specific PW Cannot Go Up
Common Causes
l The PW to which BFD is bound cannot go Up.
l BFD is configured incorrectly, causing BFD packets unable to be exchanged.

Equipment
Figure 11-2 Troubleshooting flowchart for the fault that a BFD session for a specific PW cannot
go Up
BFD for PW can not go Up
Check whether No Detect the cause

the PW is Up? of a faulty PW
Yes
Check whether the No Yes

Commit the Is the fault
BFD session configuration is
configuration rectified?
committed?
No
Yes
Check whether
Yes BFD session packets are
properly transmitted and
received?
No
Does the down

Check whether Yes counts of BFD Yes Change the
there are errored BFD
session detection time
session packets?
increase?
No No
Is the fault Yes
Check whether rectified?
Yes all links of the BFD session
can be pinged No
successfully?
Collect debugging
information
No
Check the links Contact Huawei

technical support
personnel
Yes
Is the fault rectified?
No
No
Collect debugging information
Contact Huawei technical

support personnel End

Equipment
Context
NOTE
Procedure
Step 1 Check that the PW to which BFD is bound is Up by running one of the following commands
based on the PW type:
l To check information about a VSI PW, run the display vsi verbose command to check the
Vsi State field in the command output.
If the Vsi State field is displayed as Up, go to Step 2.
If the Vsi State field is displayed as Down, see 9.2 VPLS Troubleshooting.
l To check information about a VLL, run the display mpls l2vc command to check the local
vc state and remote vc state fields.
If both the local vc state and remote vc state fields are displayed as Up, go to Step 2.
If one of the local vc state and remote vc state fields is displayed as Down, see 9.3 VLL
Troubleshooting.
l To view information about a PWE3 tunnel, run the display mpls l2vc command to check
the session state, AC status, and VC state fields.
If the session state, AC status, and VC state fields are all displayed as Up, go to Step
2.
If one of the session state, AC status, and VC state fields is displayed as Down, see 9.4
PWE3 Troubleshooting.
Step 2 Run the display bfd session all Verbose command to check that the local discriminator of one
end is the same as the remote discriminator of the other end.
l If the local discriminator of one end is the same as the remote discriminator of the other end,
go to Step 3.
l If they are inconsistent, delete the existing bfd session, and then run the bfd bind peer-ip
command to create a new bfd session. At last run the discriminator command to configure
the local and remote discriminators. Ensure that the local discriminator on the local end is
the same as the remote discriminator on the remote end and the remote discriminator on the
local end is the same as the local discriminator on the remote end,and then run the display
bfd session all command to check whether the BFD session is Up.
If the State field is Up, the BFD session has been created.
If the State field is not Up, go to Step 3.
Step 3 Run the display bfd session all Verbose command to check whether the two ends of a BFD
session are configured with the same PW TTL value.
l If the two ends are configured with the same PW TTL value, go to Step 4.
l If the two ends are configured with different PW TTL values, run the bfd cfg-name bind
pw interface interface-type interface-number remote-peer remote-peer-address pw-ttl

Equipment
{ auto-calculate | ttl-number } command to configure the same PW TTL value for the two
ends, and then run the display bfd session all command to check whether the BFD session
is Up.
If the State field is displayed as Up, the BFD session has been created.
NOTE
l Before configuring the PW TTL value, delete the BFD session. After configuring the PW TTL
value, run the commit command to commit the BFD configuration.
l When a BFD session for a specific PW is configured, if you specify the TTL value, ensure that the
TTL value is the number of S-PE nodes plus 1. You can also configure the auto-calculate parameter
in this command to automatically calculate the TTL value. Note that remote-peer remote-peer-
address specifies the address of the remote U-PE.
Step 4 Run the display bfd session all Verbose command to check whether the BFD session
configuration has been committed.
l If the commit field is displayed, the BFD session configuration has been committed. In this
case, go to Step 5.
l If the commit field is not displayed, the BFD session has not been committed. In this case,
run the commit command in the BFD session view, and then run the display bfd session
all command to check whether the BFD session is Up.
Step 5 Run the display interface [ interface-type] [ interface-number ] command to check whether the
interface tracked by the BFD session is Up.
NOTE
You can run the display bfd session all Verbose command to obtain the interface tracked by the BFD
session.
l If the interface tracked by the BFD session is Up, go to Step 6.

l If the interface tracked by the BFD session is Down, see "Physical Connection and Interface
Fault Diagnosis" to correctly configure the interface, and then run the display bfd session
all command to check whether the BFD session is Up.
Step 6 Run the display bfd statistics session all command repeatedly to check statistics about the BFD
packets.
l If the value of the Received Packets field does not increase, go to Step 7.
l If the value of the Send Packets field does not increase, go to Step 8.
l If the values of both the Received Packets and Send Packets fields increase properly, go to
Step 11.
l If none of the Received Packets, Send Packets, Received Bad Packets, and Send Bad
Packets fields increases, go to Step 11.
l If the value of the Down Count field increases, the BFD session flaps. In this case, go to
Step 9.

Equipment
Step 7 Run the display bfd statistics session all command repeatedly to check that the value of the
Received Bad Packets field increases properly.
l If the value of the Received Bad Packets field increases, the local end receives but discards
the BFD packets sent from the remote end. In this case, go to Step 11.
l If the value of the Received Bad Packets field does not increase, the local end does not
receive BFD packets. In this case, go to Step 9.
Step 8 Run the display bfd statistics session all command repeatedly to check that the value of the
Send Bad Packets field increases properly.
l If the value of the Send Bad Packets field increases, the BFD packets are sent but discarded.
In this case, go to Step 11.
l If the value of the Send Bad Packets field does not increase, the local end does not send
BFD packets to the remote end. In this case, go to Step 9.
Step 9 Run the ping command to ping the remote end of the BFD session.
NOTE
Use different ping command to detect link connectivity based on the L2VPN type:
l In a VLL network, run the ping vc command.
l In a PWE3 network, run the ping vc command.
l In a VPLS network, run the ping vpls command.
l If the ping operation fails, see 4.2.1 The Ping Operation Fails to rectify the fault.
l If the ping operation succeeds, go to Step 10.
Step 10 Run the display bfd session all Verbose command to check the values of the min-tx-interval
and min-rx-interval fields and determine whether the detection time value is larger than the
delay value.
l If the detection time value is smaller than the delay value, run one of the detect-
multiplier, min-rx-interval, and min-tx-interval commands to set the detection time value
of the BFD session to be larger than the delay value.
l If the detection time value of the BFD session is larger than the delay value, go to Step 11.
l Results of the preceding operation procedure.
----End
Relevant Alarms
BFD/3/BFD_DOWN_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.1 Session changes to DOWN.
BFD/3/BFD_UP_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.2 Session changes to UP.

Equipment

Relevant Logs
%%01BFD/6/STACHG_TODWN(l):Slot=1;BFD session changed to Down. (SlotNumber=1,
Discriminator=18, Diagnostic=DetectDown, Applications=IFNET, ProcessPST=True,
BindInterfaceName=GigabitEthernet1/1/11, InterfacePhysicalState=Up,
InterfaceProtocolState=Down)
%%01BFD/6/STACHG_TOUP(l):-Slot=2; Slot BFD session changed to Up. (SlotNumber=2,
Discriminator=9469, FormerStatus=Init)
11.1.3 Interface Forwarding Is Interrupted After a BFD Session

Detects a Fault and Goes Down
Common Causes
This fault is commonly caused by the following:
l The BFD session status is associated with the interface status.

Equipment
Figure 11-3 Troubleshooting flowchart for the fault that the interface forwarding is interrupted
after a BFD session detects a fault and goes Down
Interface forwarding
is interrupted after a
BFD session detects
a fault and goes
Down
Check the interface status
Interface is Up No Rectify the fault in the

but the BFD session End
forwarding module
status is Down?
Yes
No BFD session Yes

BFD session is Up? status is associated End
with interface
status?
Yes No
Context
NOTE
Procedure
Step 1 Run the display interface interface-type interface-number command to check the status of the
interface to which the BFD session is bound.

Equipment
l If the Line protocol current state field displays UP(BFD status down), it indicates that the
interface status is set to BFD status down after the BFD session detects a link fault. Then,
go to Step 2.
l If the Line protocol current state field displays UP but the interface cannot forward packets,
it indicates that the forwarding module is faulty. See the section The Ping Operation
Fails to rectify the forwarding fault.
Step 2 Run the display bfd session all command to check the status of the BFD session.
l If the BFD session is Down, go to Step 3.

l If the BFD session is Up, go to Step 4.
Step 3 Run the display bfd session all Verbose command to check that the process-interface-status
command is configured to Disable.
l If the process-interface-status command is configured, it indicates that the interface is set

to UP(BFD status down) because the BFD session detects a fault and goes Down.
l If the process-interface-status command is not configured, go to Step 4.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
11.1.4 Dynamic BFD Session Fails to Be Created
Common Causes
l BFD is not enabled for the protocol.
l The route to the peer of the BFD session does not exist in the routing table.
l The interface is prohibited from creating a BFD session.

Equipment
Figure 11-4 Troubleshooting flowchart for the fault that a dynamic BFD session fails to be
created
Dynamic BFD session

fails to be created
Check the configuration of the

BFD session
BFD is enabled No Enable BFD for Dynamic BFD session Yes

for the protocol? the protocol sucess to be created?
Yes No
Enable the
Routes exist in the No interface to
routing table? create a BFD
session
Yes
Interface is Yes Rectify the fault

prohibited from creating a
on the link
BFD session?
No

End
Context
NOTE

Equipment
Procedure
Step 1 Run the display bfd session all Verbose command to check that BFD is enabled for a specified
protocol.
l If BFD is not enabled for the specified protocol, enable BFD. Then, go to Step 2.
l If BFD is enabled, go to Step 3.
Step 2 Run the display bfd session all command to view the state field.
l If the state field in the command output displays Up, it indicates that the BFD section to be
created.
l If the state field in the command output displays not Up, go to step 3.
Step 3 Run the display ip routing-table command to check whether the route of the link detected by
the BFD session exists.
l If the route exists, go to step 4.

l If the route does not exist, it indicates that the BFD session associated with the protocol fails
to be created. see the section The Ping Operation Fails.
Step 4 Run the display interface interface-type interface-number command to check that a command
is configured to disable an interface to dynamically create a BFD session.
l If there is, Run the undo ospf bfd blockcommand to enable the interface to dynamically
create a BFD session. Then, run the display bfd session all command to check whether the
BFD session is Up. If not, go to step 5.
l If there is not, go to step 5.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
Traffic Loss Occurs in a Network Enabled with BFD-based IP FRR

On a network enabled with BFD-based IP FRR, traffic is discarded because no single-hop BFD
session is configured.

Equipment
Fault Symptom
On the network shown in Figure 11-5, the link between ATN and CX-B is an active link; the
link between ATN and CX-C is a standby link. A BFD session is configured on ATN and CX-
B to detect the direct link between ATN and CX-B; the other BFD session is configured on
ATN and CX-C to detect the direct link between ATN and CX-C. If the active link between
ATN and CX-B fails, traffic switches to the standby link. User traffic is lost during the 15-second
switchover.
Figure 11-5 Networking diagram of traffic loss on a network enabled with BFD-based IP FRR
CX-B CX-D
GE1/0/0
10.1.1.1 /24
GE0/2/0
10.1.1.2 /24
ATN
GE0/2/1
20.1.1.2 /24
GE1/0/0
20.1.1.1/24
CX-C CX-E
Fault Analysis
1. Run the display bfd session all verbose command on CX-B and CX-C to check the
State field and the Process PST field. The State field is Up, the BFD session type is
(Multi Hop), and the Process PST field is Disable. The command output indicates that
the configurations on CX-B and CX-C are incorrect. In the case of correct configurations,
the State field should be Up and the BFD session type should be (One Hop); the Process
PST field should be Enabled.
2. Run the display bfd session all verbose command on ATN to check the State field and
the Process PST field. The State field is Up, the BFD session type is (Multi Hop), and
the Process PST field is Disable. The command output indicates that the configurations
on ATN are incorrect. In the case of correct configurations, the State field should be Up
and the BFD session type should be (One Hop); the Process PST field should be
Enabled.
Procedure
l Configure a single-hop BFD session on ATN to detect the direct link between ATN and
CX-B.
2. Run the undo bfd cfg-name command to delete the BFD session between ATN and
CX-B.

Equipment
3. Run the bfd cfg-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between ATN and CX-B.
4. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
5. Run the discriminator local discr-value command to set the local discriminator.
6. Run the discriminator remote discr-value command to set the remote discriminator.
7. Run the commit command to make the BFD session configurations take effect.
l Configure a single-hop BFD session on ATN to detect the direct link between ATN and
CX-C.
2. Run the undo bfd cfg-name command to delete the BFD session between ATN and
CX-C.
3. Run the bfd cfg-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between ATN and CX-C.
4. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
5. Run the discriminator local discr-value command to set the local discriminator.
6. Run the discriminator remote discr-value command to set the remote discriminator.
7. Run the commit command to make the BFD session configuration take effect.
----End
Summary
During the configuration of BFD-based IP FRR, the process-pst command must be run to bind
a BFD session with the interface status in the port status table (PST). The process-pst command
is only applicable to a single-hop BFD session that has been bound to an interface. The parameter
interface interface-type interface-number must be specified before a single-BFD session is
configured.
11.2 Y.1731 Troubleshooting

This chapter describes common causes of a Y.1731 fault, and provides the corresponding
troubleshooting flowchart, troubleshooting procedure, alarms, and logs.
11.2.1 Troubleshooting of the Fault that No Single-ended Frame

Loss Statistics Are Collected Though Single-ended Frame Loss
Measurement Is Configure for a VLL Network
Common Causes
This fault is commonly caused in one of the following situations:

Equipment
l The service link is faulty.

l The action of displaying single-ended frame loss is not performed on the local MEP.
l LMM reception is not enabled on the remote MEP.
l The direction in which the MEP faces does not match the usage scenario.
l The remote MEP is not Up.
l The remote MEP ID is specified for single-ended frame loss measurement but the local
MEP has not learned MAC address from the remote MEP.
In VLL networking, no single-ended frame loss statistics are collected though single-ended
frame loss measurement is configured.

Equipment
Figure 11-6 Troubleshooting flowchart for the fault that no single-ended frame loss statistics
are collected though single-ended frame loss measurement is configured for a VLL network
No single-ended frame loss
statistics are collected
though single-ended frame
loss measurement is
configured for a VLL
Does the service No Check and reconfigure Is fault Yes

link work properly? the service link rectified?
Yes
No
Is the action of
displaying single-ended No Display single-ended
Is fault
frame loss is performed on frame loss on the local
rectified?
MEP Yes
the local MEP?
Yes No
Check whether the
Is LMM No Receive command Yes
Is fault
reception enabled on the (LMM reception) is
rectified?
remote MEP? configured on the
remote MEP
Yes No
Is the MEP No Correctly configure Is fault Yes

direction correct? the MEP direction rectified?
No
Yes
Is a RMEP ID specified for Yes

single-ended frame loss
measurement?
Has the
Yes
local MEP learned
the MAC address of
the RMEP?
No
Check CFM configurations and
ensure that the CC is in the Up
state so that the local MEP can
learn MAC address of the RMEP
No Yes
Is fault rectified?
Collect debugging Seek technical

information support
End

Equipment
Context
NOTE
Procedure
Step 1 Check that the service link works properly.
Run the display mpls l2vc command to view the session state, AC status, and VC state fields.
l If the three fields in the command output all display Up, go to Step 2.
l If any of the three fields in the command output does not display Up, check VLL
configurations. For the correct VLL configuration, see "VLL Configuration in the VRP
Configuration Guide - VPN.
NOTE
In Y.1731, trunk interfaces cannot be used as public network-side PW interfaces.
Step 2 Check that the action of displaying single-ended frame loss is performed on the local MEP.
The single-ended frame loss is collected by the local MEP that sends LMM frames. If the action
of displaying single-ended frame loss is performed on the local MEP, go to Step 3.
Step 3 Check that the loss-measure single-ended receive mep command is configured on the remote
MEP.
Run the display this command in the MD view of the remote MEP to view configuration
information.
l If the command output shows that the loss-measure single-ended receive mep command
has been configured in the MD view, go to Step 4.
l If the command output shows that the loss-measure single-ended receive mep command
has not been configured in the MD view, run the loss-measure single-ended receive mep
command to enable LMM reception.
Step 4 Check whether the direction in which the MEP faces is correct.
Run the display cfm mep command on MEPs at both link ends to view the Direction field.
Step 5 Check the parameter specified for single-ended frame loss measurement.
If remote-mep mep-id mep-id is specified, run the display cfm remote-mep md md-name
ma ma-name mep-id mep-id command to view the value of the MAC field and check whether
the local MEP has learned the MAC address of the remote MEP.
l If the MAC field is displayed as -, check CFM configurations and ensure that the CC is Up
so that the local MEP can learn the MAC address of the remote MEP.
l If the MAC field is not displayed as -, go to Step 6.
l Results of the preceding troubleshooting procedures.

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

None.
11.2.2 Troubleshooting of the Fault that No Dual-ended Frame Loss

Statistics Are Collected Though Dual-ended Frame Loss
Measurement Is Configure for a VLL Network
procedure for the fault that no dual-ended frame loss statistics are collected though dual-ended
frame loss measurement is configured for a VLL network.
Common Causes
l The remote MEP is not Up.
In VLL networking, no dual-ended frame loss statistics are collected though dual-ended frame
loss measurement is configured.

Equipment
Figure 11-7 Troubleshooting flowchart for the fault that no dual-ended frame loss statistics are
collected though dual-ended frame loss measurement is configured for a VLL network
No dual-ended frame loss

statistics are collected
though dual-ended frame
loss measurement is
configured for a VLL
No Check and
Does the service Is fault Yes
reconfigure the
link work properly? rectified?
service link
Yes No
Is the MEP No Correctly configure the Is fault Yes

direction correct? MEP direction rectified?
No
Yes
Check CFM
No
Is the remote MEP configurations to Is fault Yes
in the Up state? ensure that the remote rectified?
MEP is in the Up state
No
Yes
Context
NOTE

Equipment
Procedure
Step 2 Check the direction in which the MEP faces.
Step 3 Check that the remote MEP is Up.
Run the display cfm remote-mep md md-name ma ma-name mep-id mep-id command on the
local MEP to view the CFM Status field.
l If the CFM Status field in the command output displays Up, go to Step 4.
l If the CFM Status field in the command output does not display Up, check the CFM
configurations.
----End

None.
11.2.3 Troubleshooting of the Fault that One-way Delay Is Not

Collected Though One-way Frame Delay Measurement Is
Configured for a VLL Network
Common Causes
l The action of displaying one-way frame delay is not performed on the local MEP.
l 1DM reception is not enabled on the remote MEP.
l The remote MEP ID is specified for one-way frame delay measurement but the local MEP
has not learned MAC address from the remote MEP.

Equipment
In VLL networking, the one-way delay is not collected though one-way frame delay
measurement is configured.

Equipment
Figure 11-8 Troubleshooting flowchart for the fault that the one-way delay is not collected
though one-way frame delay measurement is configured for a VLL network
No one-way delay is
collected though one-way
frame delay measurement
is configured for a VLL
Check and
Does the service No Is fault Yes
reconfigure the
service link
Yes No
Is the action of
No Display one-way Yes
displaying one-way frame Is fault
frame delay on the
delay is performed on the rectified?
remote MEP
remote MEP?
No
Yes
Check whether the
Is 1DM No Receive command
Is fault Yes
reception enabled on the (DMM reception) is
rectified?
remote MEP? configured on the
remote MEP No
Yes
Yes No
Is a RMEP Yes
ID specified for one-way
frame delay measurement?
Has the local

No MEP learned the MAC
address of the
RMEP?
Yes
Check CFM configurations
and ensure that the CC is in
the Up state so that the local
MEP can learn MAC address
of the RMEP
No
Yes
Is fault rectified?

information support
End

Equipment
Context
NOTE
Procedure
Step 2 Check that the action of displaying one-way frame delay is performed on the remote MEP.
The one-way frame delay is collected by the local MEP that sends DMM frames. If the action
of displaying one-way frame delay is performed on the remote MEP, go to Step 3.
Step 3 Check whether the delay-measure one-way receive mep command (DMM reception) is
configured on the remote MEP.
information.
l If the delay-measure one-way receive mep command is configured in the MD view, go to
Step 4.
l If the delay-measure one-way receive mep command is not configured in the MD view, run
the delay-measure one-way receive mep command to enable DMM reception.
Step 5 Check the parameter specified for one-way frame delay measurement.
----End

Equipment

None.
11.2.4 Troubleshooting of the Fault that Two-way Delay Is Not

Collected Though Two-way Frame Delay Measurement Is
Configured for a VLL Network
Common Causes
l The action of displaying two-way frame delay is not performed on the local MEP.
l DMM reception is not enabled on the remote MEP.
l The remote MEP ID is specified for two-way frame delay measurement but the local MEP
has not learned MAC address from the remote MEP.
In VLL networking, the two-way delay is not collected though two-way frame delay
measurement is configured.

Equipment
Figure 11-9 Troubleshooting flowchart for the fault that the two-way delay is not collected
though two-way frame delay measurement is configured for a VLL network
No two-way delay is
collected though two-way
frame delay measurement
is configured for a VLL
No Check and
Does the service Is fault Yes
reconfigure the
service link
Yes No
Is displaying No Two-way delay

Is fault Yes
two-way delay performed on collected by the local
rectified?
the local MEP? MEP is dispalyed
No
Yes
Check whether the
No Receive command
Is DMM reception Is fault Yes
(DMM reception) is
enabled on the remote rectified?
configured on the
MEP?
remote MEP
Yes No

Yes No
Is a RMEP
Yes
ID specified for two-way
delay measurement?
Has the
Yes local MEP learned the
MAC address of the
RMEP?
No
Check CFM configurations
and ensure that the CC is in
the Up state so that the local
MEP can learn MAC address
of the RMEP
No Yes
Is fault rectified?

information support
End

Equipment
Context
NOTE
Procedure
Step 2 Check that the action of displaying two-way frame delay is performed on the local MEP.
The two-way frame delay is collected by the local MEP that sends DMM frames. If the action
of displaying two-way frame delay is performed on the local MEP, go to Step 3.
Step 3 Check that the delay-measure two-way receive mep command is configured on the remote
MEP.
information.
l If the command output shows that the delay-measure two-way receive mep command has
been configured in the MD view, go to Step 4.
l If the command output shows that the delay-measure two-way receive mep command has
not been configured in the MD view, run the delay-measure two-way receive mep command
to enable DMM reception.
Step 5 Check the parameter specified for two-way frame delay measurement.
----End

Equipment

None.
11.3 MPLS-TP OAM Troubleshooting

This chapter describes common causes of MPLS-TP OAM faults, and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, logs, and
commands.
11.3.1 ME Cannot Go Up
procedure for the fault that an ME cannot go Up.
Common Causes
l The ME configuration is incorrect.
l The MEG configuration is incorrect.
l The intervals between sending CCMs on both ends are inconsistent.
l The CCM sending function is disabled.
l The CCM receiving function is disabled.

Equipment
Figure 11-10 Troubleshooting flowchart for a failure that an ME cannot go Up
ME cannot be Up
No Yes
Check whether the Change the ME Is the fault
ME configuration is configuration rectified?
correct
No
Yes
No Yes
Check whether the Change the MEG Is the fault
MEG configuration configuration rectified?
is correct
No
Yes
Check
whether the periods No Yes
Change them to the Is the fault
for sending CCMs same value rectified?
are the same
No
Yes
No Yes
Check whether Is the fault
CCM sending is Enable CCM sending
rectified?
enabled
No
Yes
No Yes
Check whether Enable CCM receiving Is the fault
CCM receiving is rectified?
enabled
No
Yes
Ask for technical support End
Context
NOTE
Procedure
Step 1 Verify the fiber connection.

Equipment
l If the fiber is disconnected, see "Physical Interconnection Troubleshooting" for details

about how to troubleshoot the fiber connection fault.
l If the fiber is connected securely, go to Step 2.
Step 2 Run the display mpls-tp oam meg command on the ingress and egress to verify that the ingress
has ME and MEG information consistent with that on the egress.
l If inconsistency occurs, change the configuration on one end to ensure that the ingress has
ME and MEG information consistent with that on the egress. If the fault persists, go to
Step 3.
l If the ingress has ME and MEG information consistent with that on the egress, go to Step
3.
Step 3 Run the display mpls-tp oam meg command on the ingress and egress to view the CC
configuration. If there is any inconsistency, select one command in the following situations:
l If the intervals at which CCMs are sent are different, disable sending and receiving CCMs,
then run the cc interval command to set the same interval for the two ends.
l If the ingress or egress is disabled from sending CCMs, run the cc send enable command
to enable it to send CCMs.
l If the ingress or egress is disabled from receiving CCMs, run the cc receive enable
command to enable it to receive CCMs.
l If the fault persists, go to Step 4.
----End
Relevant Alarms
MPLS-TPOAM/5/OID [OID] loss of continuity alarm start. (MegId=[MegId],MeType=
[MeType],MeDirection=[MeDirection],IfName=[IfName],PeerIP=[PeerIP],VcId=
[VcId],VcType=[VcType],RemoteIp=[RemoteIp],Ttl=[Ttl],MepId=[MepId],RemoteMepId=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] loss of continuity alarm end. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected MEG alarm start. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected MEG alarm end. (MegId=[MegId],MeType=
[RemoteMepId],LspName=[octet],VsiName="")
MPLS-TPOAM/5/OID [OID] unexpected MEP alarm start. (MegId=[MegId],MeType=
MPLS-TPOAM/5/OID [OID] unexpected MEP alarm end. (MegId=[MegId],MeType=

Equipment
MPLS-TPOAM/5/OID [OID] unexpected period alarm start. (MegId=[MegId],MeType=

MPLS-TPOAM/5/OID [OID] unexpected period alarm end. (MegId=[MegId],MeType=
MPLS-TPOAM/5/OID [OID] RDI alarm end. (MegId=[MegId],MeType=[MeType],MeDirection=
[MeDirection],IfName=[IfName],PeerIP=[PeerIP],VcId=[VcId],VcType=
[VcType],RemoteIp=[RemoteIp],Ttl=[Ttl],MepId=[MepId],RemoteMepId=
MPLS-TPOAM/5/OID [OID] RDI alarm start. (MegId=[MegId],MeType=[MeType],MeDirection=
[MeDirection],IfName=[IfName],PeerIP=[PeerIP],VcId=[VcId],VcType=
[VcType],RemoteIp=[RemoteIp],Ttl=[Ttl],MepId=[MepId],RemoteMepId=
Relevant Logs
None
11.4 Error Code Detection Troubleshooting
11.4.1 Error Detection Switchover Fails
Common Causes
l BFD is not globally enabled.

l The TE tunnel configuration is incorrect.
l The L2VPN service configuration is incorrect.
l Error code detection is not configured on the interface.
l The protection path fails to be established.
After the error code detection switchover is configured, protection switchover is not performed
on the device where an error code occurs on an interface.
l Check whether BFD is globally enabled.

l Check whether error code detection is configured for the tunnel.
l Check whether error code detection is configured for the L2VPN service.
l Check whether error code detection is configured on the interface.
l Check whether the protection path for the tunnel or L2VPN service has been created.
l Check whether an error code occurs.

Equipment
Figure 11-11 Failure in the code detection switchover
Error code detection

switchover fails
No Enable BFD
Is BFD globally enabled?
globally
Yes
No Configure error code

Is error code detection
detection for the
enabled for the tunnel?
tunnel
Yes
Is the tunnel associated No Associate the tunnel

with an LSP? with an LSP
Yes
Is error code detection No Configure error code

configured for L2VPN? detection for L2VPN
Yes
No Configure error code

Is error code detection
detection on the
configured on the interface?
interface
Yes
Locate the fault
Is HSB or VPN protection No according to HSB or
path established? PW redundancy
troubleshooting
Yes
Is fault rectified?
No
No
End

Equipment
Context
NOTE
Procedure
Step 1 Check that the device configuration is correct. For example, check whether BFD is globally
enabled, whether error code detection is enabled on the interface, tunnel, and PW, whether
tunnel-based error code detection is associated with an LSP, and whether PW redundancy is
configured for the error code detection function of the L2VPN service.
Step 2 Check whether the protection path is established.

l If tunnel-based error code detection is configured, run the display mpls te tunnel-
interface tunnel interface-number command to check the Primary LSP State and Hot-
Standby LSP State fields. If the two fields display Up, the primary and backup LSPs have
been established. Otherwise, the protection path is not established.
l If L2VPN-based error code detection is configured, run the display mpls l2vc command to
check whether the VC state of the primary and backup PWs is Up. If so, the primary and
backup PWs have been established.
Step 3 Check whether an error code occurs.
Run the display bfd bit-error-detection session all command to check the Fault Type field
and determine the error code type.
<HUAWEI>display bfd bit-error-detection session all
--------------------------------------------------------------------------------
BFD Bit Error Information:
--------------------------------------------------------------------------------
Session MIndex : 256
Session Type : PE
FSM Board Id : 0
Fault Type : -
Min Tx Interval (ms) : 1000
Max Tx Interval (ms) : 30000
Actual Tx Interval (ms) : 30000
Detect Multi : 3
Source IP Address : 28.28.28.28
Destination IP Address : 127.0.0.1
Destination Port : 3784
TOS-EXP : 7
PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0
l Configuration file, logs, and alarms of the device
----End

Equipment
Relevant Alarms
PIA/2/CRCPERALARM: OID: [oid] The CRC-PER(Packet Error Ratio) is rising. (IfIndex=
[INTEGER],IfName=[STRING],CurrentValue=[STRING],AlarmThreshold=
[STRING],ResumeThreshold=[STRING])
PIA/2/CRCPERALARMRESUME: OID: [oid] The CRC-PER(Packet Error Ratio) resume.

(IfIndex=[INTEGER],IfName=[STRING],CurrentValue=[STRING],AlarmThreshold=
[STRING],ResumeThreshold=[STRING])
Relevant Logs
None

Equipment
Troubleshooting 12 User Management
12 User Management
About This Chapter
12.1 HWTACACS Troubleshooting
12.2 DCN Troubleshooting

Equipment
12.1 HWTACACS Troubleshooting

12.1.1 Trouble Cases
User with the Correct User Name and Password Fails to Pass HWTACACS
Authentication
During network configuration adjustment, the new routing protocol does not advertise loopback
addresses. As a result, a user who uses a loopback address as the source IP address cannot
communicate with the TACACS server.
Fault Symptom
On the core network shown in Figure 12-1, Routing protocol, AAA, QoS, and SNMP are
configured on ATN A, ATN B, ATN C, and ATN D. The four devices belong to the same AS
and are configured with IBGP and IS-IS. IS-IS advertises the IP addresses of loopback interfaces
and interconnected interfaces. The devices are re-configured based on a new private AS number,
IBGP is replaced by EBGP and IS-IS is replaced by OSPF.
Figure 12-1 Networking diagram of HWTACACS authentication on a core network
Loopback0 Loopback0
RouterA
RouterB
TACACS
server
RouterD
RouterC
Loopback0 Loopback0
After the configurations, an HWTACACS user with the correct user name and password can no
longer pass the HWTACACS authentication.
Fault Analysis
1. Check whether the user name and password of the user are the same as those recorded on
the TACACS server. The user name and password are correct.
2. Run the ping command on ATN A to check whether ATN A can ping the TACACS server.
The ping succeeds.

Equipment
3. Run the display current-configuration command on ATN A to check whether the

HWTACACS configuration is correct. The following command is found in the
HWTACACS server template:
hwtacacs-server source-ip 192.168.1.227
In this command, 192.168.1.227 is the loopback address of ATN A.

As the deleted IS-IS configuration includes loopback addresses and HWTACACS uses the
loopback address of ATN A as the source IP address, it is possible that HWTACACS
authentication fails because ATN A cannot receive authentication response packets with
the destination address being 192.168.1.227 from the TACACS server.
4. Run the ping -a 192.168.1.227 10.1.1.245 command on ATN A (10.1.1.245 is the IP
address of the TACACS server) to check whether the loopback address can ping the
TACACS server address. The ping fails.
5. Run the display ip routing-table command on ATN A to check whether routing protocols
have advertised this loopback address. The command output shows that the IP address of
Loopback0 is not advertised.
Therefore, it can be concluded that the loopback address is deleted when the IS-IS
configuration is deleted during network configuration adjustment. Because OSPF does not
advertise this loopback address, ATN A cannot receive authentication response packets
from the TACACS server, and as a result, HWTACACS authentication fails.
Procedure
Step 2 Run the ospf process-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 address wildcard-mask command to advertise the loopback address.
After the preceding configurations, the user can successfully log in. The fault is cleared.
----End
Summary
Before changing protocols on network devices, you need to record the original configurations.
After the configuration of new protocols , ensure that the new configurations meet all the service
requirements before the change and whether the new configurations affect other configurations.
12.2 DCN Troubleshooting
12.2.1 A DCN Link Fails to Be Established

procedure to use when a DCN link fails to be established.
Common Causes

Equipment
l DCN is not enabled in the PAF file.

l Obtaining an NEID fails.
l An NEID conflict occurs.
l An NEIP conflict occurs.
l DCN is not enabled globally.
l The interface on which DCN negotiation is performed is Down.
l DCN is not enabled on the interface on which DCN negotiation is performed.
When a GNE is connected correctly, it fails to use Stelnet to connect to an NE after being powered
on.
l Check whether the GNE can ping the NE device successfully.

l Check whether the DCN route of the DCN virtual interface is reachable.
l Check whether the DCN OSPF neighbor relationship is established on the DCN virtual
interface.
l Check whether the protocol status of the DCN virtual interface is Up.
l Check whether a DCN virtual interface has been created.
l Check whether DCN is enabled on the physical interface.
l Check whether the physical interface is in Up state.

Equipment
Figure 12-2 Failure to establish a DCN link

A GNE fails to use
Stelnet to connect to
an NE
Can the GNE Yes

ping the NE
successfully?
No
Is the DCN Yes

route on the DCN
virtual interface
reachable?
No
Is the DCN OSPF Yes

neighbor relationship
established on the DCN
virtual interface?
No
Is the
Yes
protocol status of
the DCN virtual
interface Up?
No
Is the DCN Yes

Virtual interface
created on the
physical
interface?
Yes No
Is the fault
rectified after Huawei techical
DCN is support
enabled?
No
Yes
Is the physical
interface Up? No
Ensure that the

No connection status and Whether the
interface status are problem is fixed
correct
Yes
End

Equipment
Context
NOTE
Procedure
Step 1 Check whether the GNE can ping the NE successfully.
l If the ping succeeds, there is a reachable route between the GNE and NE. Go to Step 2.
l If the ping fails, go to Step 2.
Step 2 Check whether the route of the DCN virtual interface is reachable.
Run the display ip routing-table vpn-instance command on the GNE to check whether the
local routing table contains the route destined for the remote NE.
l If the GNE has the route to the NE, DCN OSPF configuration is correct. Go to Step 8.
l If the GNE has not route to the NE, go to Step 3.
Step 3 Check whether the DCN OSPF neighbor relationship is established on the DCN virtual interface.
Run the display ospf peer command on the GNE to check whether the DCN OSPF neighbor
relationship has been established.
l If the DCN OSPF neighbor relationship has been established and is in Full state, DCN
negotiation is correct. Go to Step 8.
l If the DCN OSPF neighbor relationship is not established or not in Full state, go to Step 4.
Step 4 Check whether the protocol status of the DCN virtual interface is Up.
Run the display ip interface brief command on the GNE to check whether the protocol status
of the DCN virtual interface is Up.
<HUAWEI> display ip interface brief
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(d): Dampening Suppressed
The number of interface that is UP in Physical is 23
The number of interface that is DOWN in Physical is 6
The number of interface that is UP in Protocol is 9
The number of interface that is DOWN in Protocol is 20

DCN-Serial0/2/2:0 128.1.0.1/16 up up
Ethernet0/0/0 10.137.221.167/23 up up
Ethernet0/0/0.1 unassigned up down
Ethernet0/3/0 unassigned up down
l If the protocol status of the DCN virtual interface is Up, DCN PPP negotiation is correct. Go
to Step 8.
l If the protocol status of the DCN virtual interface is not Up or no DCN virtual interface is
configured, go to Step 5.
Step 5 Check whether a DCN virtual interface is created.
Run the display dcn interface command on the GNE to check whether the protocol status of
the DCN virtual interface has been created.

Equipment
l If a DCN virtual interface has been created, DCN PPPoE negotiation is correct. Go to Step
8.
l If no DCN virtual interface is created, go to Step 6.
Step 6 Check whether DCN is enabled on the physical interface.
Run the display this command on the GNE to check whether DCN is enabled.
[HUAWEI-Ethernet0/2/2] display this
#
interface Ethernet0/2/2
undo shutdown
dcn
#
return
l If DCN is not enabled on the physical interface, enable DCN on the physical interface to
rectify the fault. If the fault persists, go to Step 4.
l If DCN has been enabled on the physical interface, go to Step 7.
Step 7 Check whether the physical interface is in Up state.
Run the display ip interface brief command on the GNE to check whether the physical interface
is Up.
<HUAWEI> display ip interface brief
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(d): Dampening Suppressed
The number of interface that is UP in Physical is 23
The number of interface that is DOWN in Physical is 6
The number of interface that is UP in Protocol is 9
The number of interface that is DOWN in Protocol is 20

DCN-Serial0/2/2:0 128.1.0.1/16 up up
Ethernet0/0/0 10.137.221.167/23 up up
Ethernet0/0/0.1 unassigned up down
l If the physical interface is not in Up state, remove and insert the cable to check whether the
interface is shut down.
l If the physical interface is in Up state but the fault persists, go to Step 8
l Configuration file, logs, and alarms of the device
----End
Relevant Alarms
None

Equipment
Relevant Logs
None


ATN 910&910I&910B&950B V200R003C10 Troubleshooting 02 (CLI)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ATN 910&910I&910B&950B V200R003C10 Troubleshooting 02 (CLI)

Transféré par

Droits d'auteur :

Formats disponibles

ATN 910&910I&910B&950B Multi-Service Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2014-04-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

l ATN 910 V200R003C10

Issue 02 (2014-04-30) Huawei Proprietary and Confidential ii

l System maintenance engineer

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

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

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

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

Issue 02 (2014-04-30) Huawei Proprietary and Confidential iii

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

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

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Changes in Issue 02 (2014-04-30)

Known bugs are fixed.

Changes in Issue 01 (2014-01-31)

Issue 02 (2014-04-30) Huawei Proprietary and Confidential iv

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

Issue 02 (2014-04-30) Huawei Proprietary and Confidential v

3 Physical Connection and Interfaces.........................................................................................59

4 IP Forwarding and Routing.......................................................................................................67

Issue 02 (2014-04-30) Huawei Proprietary and Confidential vi

6.1 Layer 2 Multicast Troubleshooting............................................................................................................................149

Issue 02 (2014-04-30) Huawei Proprietary and Confidential vii

9.2.2 VSI Goes Up Only on One End...............................................................................................................................257

Issue 02 (2014-04-30) Huawei Proprietary and Confidential viii

About This Chapter

1.1 Troubleshooting Boards

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 1

1.1 Troubleshooting Boards

1.1.1 Methods of Troubleshooting a Failure to Register a Standby

Such a fault may result from the following causes:

l The standby system control board is starting up.

Do the active and standby system No Yes

Collect information and ask for

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 2

If there is no such an alarm and the failure persists, proceed with .

Relevant Alarms and Logs

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 3

1.1.2 Methods of Troubleshooting a Failure to Register a Subcard

This fault may result from the following causes:

Figure 1-2 Flowchart for troubleshooting a failure to register a subcard

Has the subcard been powered No Yes

No Reconnect the subcard and Yes

Collect information and

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 4

If the subcard is powered on but cannot be registered, go to Step 2.

Relevant Alarms and Logs

1.1.3 Methods of Identifying a Failure to Query Ports on a

Such a fault may result from the following common causes:

l The subcard has an incorrect electronic label.