CloudEngine 6800&5800 V100R002C00 Troubleshooting Guide 01 PDF

CloudEngine 6800&5800 Series Switches
V100R002C00
Troubleshooting
Issue 01
Date 2013-08-01
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://enterprise.huawei.com
Issue 01 (2013-08-01) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Intended Audience
This document describes common troubleshooting procedure and methods.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER
Indicates a hazard with a high level or medium level of risk
which, if not avoided, could result in death or serious injury.
WARNING
Indicates a hazard with a low level of risk which, if not
avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation that, if not
avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP
Provides a tip that may help you solve a problem or save time.
NOTE
Provides additional information to emphasize or supplement
important points in the main text.

Command Conventions
The command conventions that may be found in this document are defined as follows.
Troubleshooting About This Document
ii
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. You can select one or several items, or select
no item.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.

Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 01 (2013-08-01)
Initial commercial release.
Troubleshooting About This Document
iii
Contents
About This Document.....................................................................................................................ii
1 Instructions for Maintenance Engineers...................................................................................1
1.1 Precautions......................................................................................................................................................................2
1.2 Backing Up Data............................................................................................................................................................2
1.3 Troubleshooting Process.................................................................................................................................................2
1.4 Ask for Help...................................................................................................................................................................3
1.4.1 Huawei Enterprise Website.........................................................................................................................................3
1.4.2 Hotline.........................................................................................................................................................................3
2 Forgetting Passwords....................................................................................................................4
2.1 Recovering the Console Port Password..........................................................................................................................5
2.2 Recovering the Telnet Login Password..........................................................................................................................7
3 Information Collection.................................................................................................................8
3.1 Overview........................................................................................................................................................................9
3.2 Collecting Diagnostic Information.................................................................................................................................9
3.3 Health Status Information...............................................................................................................................................9
4 System Maintenance Methods..................................................................................................10
4.1 Restoring the Default Settings Using the Configuration File.......................................................................................11
4.2 Restarting the Device....................................................................................................................................................11
4.3 Upgrading the Device...................................................................................................................................................12
4.4 Transferring Files Using FTP/TFTP.............................................................................................................................12
5 Startup Failures............................................................................................................................16
5.1 Terminal Does Not Display Anything Or Displays Garbled Characters......................................................................17
6 Hardware.......................................................................................................................................18
6.1 Power Module Troubleshooting...................................................................................................................................19
6.1.1 The SYS and Power Module Indicators Are Off.......................................................................................................19
6.2 Fan Module Troubleshooting.......................................................................................................................................19
6.2.1 The Indicator of a Fan Module Is Steady Red...........................................................................................................19
6.2.2 Fan Noise Is Loud......................................................................................................................................................20
6.2.3 An Alarm Is Generated When the Fan Status Is Abnormal.......................................................................................20
6.2.4 Fan Blades Were Damaged.......................................................................................................................................21
Troubleshooting Contents
iv
6.3 Optical Module Troubleshooting..................................................................................................................................21
6.3.1 Optical Modules on the Local and Remote Devices Cannot Communicate.............................................................21
6.4 Interface Troubleshooting.............................................................................................................................................24
6.4.1 A 40GE Interface Fails to Be Split into 10GE Interfaces or 10GE Interfaces Fail to Be Merged into A 40GE Interface
............................................................................................................................................................................................24
6.4.2 An Electrical Interface Cannot Go Up.......................................................................................................................25
6.4.3 10GE Optical Interfaces Cannot Go Up....................................................................................................................26
6.4.4 40GE Optical Interfaces Cannot Go Up....................................................................................................................28
6.4.5 Packet Loss Occurs on An Interface..........................................................................................................................29
7 Patch and Upgrade Faults..........................................................................................................31
7.1 Patch Faults...................................................................................................................................................................32
7.1.1 Failed to Install a Patch.............................................................................................................................................32
8 Service Faults................................................................................................................................33
8.1 LAN..............................................................................................................................................................................34
8.1.1 VLAN Troubleshooting.............................................................................................................................................34
8.1.1.1 Users in a VLAN Cannot Communicate with Each Other.....................................................................................34
8.1.1.1.1 Common Causes..................................................................................................................................................34
8.1.1.1.2 Troubleshooting Flowchart..................................................................................................................................34
8.1.1.1.3 Troubleshooting Procedure..................................................................................................................................36
8.1.1.1.4 Relevant Alarms and Logs..................................................................................................................................38
8.1.2 MSTP Troubleshooting.............................................................................................................................................38
8.1.2.1 MSTP Topology Change Leads to Service Interruption........................................................................................38
8.1.2.1.1 Common Causes..................................................................................................................................................38
8.2 IP Forwarding and Routing..........................................................................................................................................44
8.2.1 RIP Troubleshooting .................................................................................................................................................44
8.2.1.1 Device Does not Receive Partial Routes or All the Routes....................................................................................44
8.2.1.1.1 Common Causes..................................................................................................................................................44
8.2.1.2 Device Does not Send Partial or All the Routes.....................................................................................................48
8.2.1.2.1 Common Causes..................................................................................................................................................48
8.2.1.3 Trouble Cases.........................................................................................................................................................53
8.2.1.3.1 A RIP Error Occurs due to Discontinuous Subnets.............................................................................................53
8.2.2 OSPF Troubleshooting..............................................................................................................................................55
v
8.2.2.1 OSPF Neighbor Relationship Is Down...................................................................................................................55
8.2.2.1.1 Common Causes..................................................................................................................................................55
8.2.2.2 OSPF Neighbor Relationship Cannot Enter the Full State.....................................................................................60
8.2.2.2.1 Common Causes..................................................................................................................................................60
8.2.3 BGP Troubleshooting................................................................................................................................................63
8.2.3.1 BGP Peer Relationship Fails to Be Established.....................................................................................................63
8.2.3.1.1 Common Causes..................................................................................................................................................63
8.2.3.2 BGP Public Network Traffic Is Interrupted...........................................................................................................69
8.2.3.2.1 Common Causes..................................................................................................................................................69
8.2.3.3 BGP Private Network Traffic Is Interrupted..........................................................................................................73
8.2.3.3.1 Common Causes..................................................................................................................................................73
8.2.3.4 Troubleshooting of the Fault that Prevents a Local BGP Peer (Route Sender) from Receiving ORFs from a Remote
Peer (Route Receiver).........................................................................................................................................................79
8.2.3.4.1 Common Causes..................................................................................................................................................79
8.3 IP Multicast...................................................................................................................................................................84
8.3.1 Multicast Traffic Cannot Be Transmitted..................................................................................................................84
8.3.1.1 Common Causes.....................................................................................................................................................84
8.3.1.2 Troubleshooting Flowchart.....................................................................................................................................84
8.3.1.3 Troubleshooting Procedure.....................................................................................................................................85
8.3.1.4 Relevant Alarms and Logs.....................................................................................................................................86
8.3.2 The PIM Neighbor Relationship Remains Down......................................................................................................86
8.3.2.1 Common Causes.....................................................................................................................................................86
vi
8.3.3 MSDP Peers Cannot Generate Correct (S, G) Entries...............................................................................................89
8.3.3.1 Common Causes.....................................................................................................................................................89
8.4 QoS...............................................................................................................................................................................93
8.4.1 Priority Mapping Troubleshooting............................................................................................................................93
8.4.1.1 Packets Enter Incorrect Queues..............................................................................................................................93
8.4.1.1.1 Common Causes..................................................................................................................................................94
8.4.1.2 Priority Mapping Results Are Incorrect.................................................................................................................97
8.4.1.2.1 Common Causes..................................................................................................................................................97
8.4.1.2.4 Relevant Alarms and Logs................................................................................................................................100
8.4.2 Traffic Policing Troubleshooting............................................................................................................................100
8.4.2.1 Interface-based Traffic Policing Results Are Incorrect........................................................................................100
8.4.2.1.1 Common Causes................................................................................................................................................100
8.4.2.1.2 Troubleshooting Flowchart................................................................................................................................100
8.4.2.1.3 Troubleshooting Procedure................................................................................................................................101
8.4.3 Traffic Shaping Troubleshooting.............................................................................................................................102
8.4.3.1 Traffic Shaping Results of Queues Are Incorrect.................................................................................................102
8.4.3.1.1 Common Causes................................................................................................................................................102
8.4.4 Congestion Avoidance Troubleshooting.................................................................................................................107
8.4.4.1 Congestion Avoidance Fails to Take Effect.........................................................................................................107
8.4.4.1.1 Common Causes................................................................................................................................................107
8.4.5 Congestion Management Troubleshooting..............................................................................................................110
8.4.5.1 Congestion Management Fails to Take Effect.....................................................................................................111
8.4.5.1.1 Common Causes................................................................................................................................................111
vii
8.5 Device Management...................................................................................................................................................113
8.5.1 Stacking Troubleshooting........................................................................................................................................114
8.5.1.1 A Stack Failed to Be Set Up.................................................................................................................................114
8.5.1.1.1 Common Causes................................................................................................................................................114
8.5.1.2 Active/Standby Switchover Cannot Be Performed in a Stack.............................................................................116
8.5.1.2.1 Common Causes................................................................................................................................................117
8.6 TRILL.........................................................................................................................................................................118
8.6.1 TRILL Neighbor Relationship Fails to Be Established...........................................................................................118
8.6.1.1 Common Causes...................................................................................................................................................118
8.6.1.2 Troubleshooting Flowchart...................................................................................................................................118
8.6.1.3 Troubleshooting Procedure...................................................................................................................................119
8.6.1.4 Relevant Alarms and Logs...................................................................................................................................122
8.6.2 TRILL Traffic Failed to Be Forwarded...................................................................................................................122
8.6.2.1 Common Causes...................................................................................................................................................122
8.6.3 TRILL In-band NMS Fails to Manage RBs............................................................................................................125
8.6.3.1 Common Causes...................................................................................................................................................125
8.6.4 TRILL Fails to Be Enabled on an Interface.............................................................................................................127
8.6.4.1 Common Causes...................................................................................................................................................128
9 Common Fault Diagnostic Commands.................................................................................130
9.1 display Commands.....................................................................................................................................................131
9.1.1 Overview.................................................................................................................................................................131
9.1.2 Regular Expression in display Commands..............................................................................................................131
9.1.3 Common display Commands...................................................................................................................................135
9.2 reset Commands.........................................................................................................................................................137
9.2.1 Overview.................................................................................................................................................................137
viii
9.2.2 reset Commands Clearing Packet Statistics.............................................................................................................137
9.2.3 Using reset Commands............................................................................................................................................138
9.3 Ping and Tracert..........................................................................................................................................................138
9.4 Traps...........................................................................................................................................................................141
9.5 Logs............................................................................................................................................................................143
9.6 Packet Header Capturing Function.............................................................................................................................143
10 Appendix: Indicators.............................................................................................................. 147
10.1 Fan Module Indicator...............................................................................................................................................148
10.2 Power Indicators.......................................................................................................................................................149
ix
1 Instructions for Maintenance Engineers
About This Chapter
1.1 Precautions
1.2 Backing Up Data
1.3 Troubleshooting Process
1.4 Ask for Help
Troubleshooting 1 Instructions for Maintenance Engineers
1
1.1 Precautions
If you are a maintenance engineer, read the following precautions before doing your work:
l Confirm whether the fault is an emergency fault. If it is an emergency fault, recover the
faulty module by using the pre-defined troubleshooting methods immediately, and then
restore services.
l Strictly conform to operation rules and industrial safety standards, ensuring human and
device safety.
l Wear the ESD wrist strap when touching device components.
l Record original information about the problems occurring during troubleshooting.
l Record all the operations you have performed, especially the key operations such as
restarting device and clearing database. Before performing the key operations, confirm the
operation feasibility, back up data, and prepare the emergency and security measures. Only
qualified personnel can perform key operations.
NOTE
After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.
1.2 Backing Up Data
Some faults cause resource or money loss for customers. Therefore, maintenance engineers
should focus on preventing faults and quickly restoring faults. Data backup helps you quickly
locate and recover faults. After a network is set up and operates normally, you should back up
important data as soon as possible.
Important data includes:
l Complete network topology, including device models, versions, and networking diagram
l Configuration files and license files
l System software and patch files
l (Optional) Logs
l (Optional) Feature library
1.3 Troubleshooting Process
Systematic troubleshooting is to find fault causes step by step, and finally recover the fault.
2
Generally, troubleshooting steps include observing fault symptom, collecting information,
analyzing problem, and finding the root cause. The possible causes of all faults can be grouped
into multiple cause sets, which make troubleshooting easier.
1.4 Ask for Help
1.4.1 Huawei Enterprise Website
At http://support.huawei.com/enterprise, you can:
l Search troubleshooting cases to find a way to fix your problem.
l Post your question on BBS and wait for answers from online technical experts.
1.4.2 Hotline
If you cannot recover the fault, you can:
l Contact the agent.
NOTE
Provide device and fault information to technical support personnel.
3
2 Forgetting Passwords
About This Chapter
This section describes how to recover the console port and Telnet passwords. You are advised
to keep passwords secure and change them regularly.
2.1 Recovering the Console Port Password
2.2 Recovering the Telnet Login Password
Troubleshooting 2 Forgetting Passwords
4
2.1 Recovering the Console Port Password
Three methods are provided to recover the console port password.
l Method 1: Log in to the device using Telnet and change the console port password.
l Method 2: Change the console port password through the BIOS menu.
NOTE
Method 1 is recommended. If you forget the Telnet password, use method 2.
Logging In to the Device Using Telnet and Modifying the Console Port Password
If you can log in to the device using Telnet and your user right is level 3 or higher, log in to the
device using Telnet, change the console port password, and save the configuration.
1. Log in to the device using Telnet. Ensure that your user right is level 3 or higher.
Run the display users command to display all the users that have logged into the device.
The item with a "+" mark indicates your user account on user interface VTY1.
<HUAWEI> display users
User-Intf Delay Type Network Address AuthenStatus
AuthorcmdFlag
34 VTY 0 00:06:53 TEL 10.135.18.67 pass yes
Username : Unspecified
+ 35 VTY 1 00:00:00 TEL 10.135.18.91 pass yes
36 VTY 2 00:08:11 TEL 10.135.18.54 pass yes
Run the display user-interface command to view the user right of all users. VTY1 has a
corresponding user right 15; therefore, you have the right to change the console port
password.
<HUAWEI> display user-interface
Idx Type Tx/Rx Modem Privi ActualPrivi Auth Int
0 CON 0 9600 - 15 - P -
+ 34 VTY 0 - 15 15 P -
+ 35 VTY 1 - 15 15 P -
+ 36 VTY 2 - 15 - P -
37 VTY 3 - 15 15 P -
......
2. Change the console port password. In this example, you set the authentication mode to
password authentication.
<HUAWEI> system-view
[~HUAWEI] user-interface console 0
[~HUAWEI-ui-console0] authentication-mode password
Please configure the login password (6-16)
Enter Password:
Confirm Password:
[~HUAWEI-ui-console0] user privilege level 15
[~HUAWEI-ui-console0] commit
[~HUAWEI-ui-console0] return
3. Save the configuration to prevent configuration loss after a restart.
<HUAWEI> save
Warning: The current configuration will be written to the device.
Are you sure to continue? [Y/N]:y
5
Now saving the current configuration to the slot 1
Info: Save the configuration successfully.
Modifying the Console Port Password Through the BIOS Menu
The BIOS allows you to clear the console port password so that the device does not check the
password when you log in through the console port. Then the device restarts, enters the command
line interface, and prompts you to change the console port password.
CAUTION
l You must restart the device to display the BIOS menu, which results in service interruption.
Migrate services to a backup device and perform this operation in off-peak hours.
l Set a new password immediately after you log in to the device by clearing console login
password. Otherwise, you must repeat this operation when the login expires or the device
restarts.
l Do not power off the device during the operation.
1. Connect a PC to the device with a serial cable and restart the device. When the message
"Press CTRL+B to enter BIOS menu" is displayed, press Ctrl+B and enter the BIOS
password (Admin@huawei.com by default) to display the BIOS main menu.
2. Clear console login password.
BIOS Menu (Version: 126)
1. Continue to boot
2. Update from serial interface
3. Update from ethernet interface
4. Modify startup parameters
5. File system
6. Modify BIOS password
7. Modify console password
8. Reboot
Enter your choice(1-7): 7
Caution: A new console password must be set after the restart.
Continue now? Yes(y) or No(n): y
3. After the system starts, authentication is not required when logging in to the device through
the console port, but you need to change the console port password in time. In this example,
you set the authentication mode to password authentication.
[~HUAWEI] user-interface console 0
[~HUAWEI-ui-console0] authentication-mode password
Enter Password:
Confirm Password:
[~HUAWEI-ui-console0] user privilege level 15
[~HUAWEI-ui-console0] commit
[~HUAWEI-ui-console0] return
4. Save the configuration.
<HUAWEI> save
6
2.2 Recovering the Telnet Login Password
You can use Telnet to remotely maintain and manage a device. If you forget the Telnet login
password, log in to the device using the console port and set a new password.
Currently, the device supports two authentication modes for Telnet login.
l AAA authentication: To log in to the device, you must have a user name and a password.
l Password authentication: To log in to the device, you must have a password.
In this example, the configurations for VTY0 to VTY4 are the same.
NOTE
After you log in to the device, run the display current-configuration configuration user-interface
command to view the authentication mode of the VTY user. You can change the password without changing
the authentication mode or configure a new authentication mode.
AAA Authentication
[~HUAWEI] user-interface vty 0 4
[~HUAWEI-ui-vty0-4] authentication-mode aaa
[~HUAWEI-ui-vty0-4] quit
[~HUAWEI] aaa
[~HUAWEI-aaa] local-user huawei password irreversible-cipher huawei@123
[~HUAWEI-aaa] local-user huawei service-type telnet
[~HUAWEI-aaa] local-user huawei level 15
[~HUAWEI-aaa] commit
[~HUAWEI-aaa] return
<HUAWEI> save
After the configuration is complete, you can use the user name huawei and password
huawei@123 to log in to the device.
Password Authentication
[~HUAWEI] user-interface vty 0 4
[~HUAWEI-ui-vty0-4] authentication-mode password
Enter Password:
Confirm Password:
[~HUAWEI-ui-vty0-4] user privilege level 15
[~HUAWEI-ui-vty0-4] commit
[~HUAWEI-ui-vty0-4] return
<HUAWEI> save
After the configuration is complete, you can use the password huawei@123 to log in to the
device.
7
3 Information Collection
About This Chapter
This chapter describes the information collection method. You must collect detailed fault
information before locating faults by yourself or contacting agents or Huawei technical support
personnel for fault location.
NOTE
If you need to send fault information to agents or Huawei technical support personnel for fault location,
delete security information such as network configurations before sending the fault information.
3.1 Overview
3.2 Collecting Diagnostic Information
3.3 Health Status Information
Troubleshooting 3 Information Collection
8
3.1 Overview
After a device fault occurs, collect fault information immediately. This helps you locate the fault
accurately.
If you cannot locate the fault by yourself, provide the following information to agents or Huawei
technical support personnel:
l Fault occurrence time, network topology, operations triggering the fault, fault symptom,
measures that you have taken and results, and affected services
l Name, version, current configurations, interfaces of the faulty device. For the method of
obtaining these information, see 3.2 Collecting Diagnostic Information and 9.1.3
Common display Commands.
l Logs generated when the fault occurs. For the method of obtaining the log information, see
Collecting Log Information.
3.2 Collecting Diagnostic Information
The display diagnostic-information [ [ module-name ] &<1-8> [ slot slot-id ] | file-name ]
command displays the device diagnostic information on screen or outputs the information to a
txt file. The device diagnostic information includes startup configuration, current configurations,
interface information, time, and system version. The following is an example:
<HUAWEI> display diagnostic-information dia-info.txt
Now saving the diagnostic information to the device.............................
................................................................................
..............
Info: The diagnostic information was saved to the device successfully.
The default storage path is the root directory of the system default storage device: flash:/. Using
the dir command in the user view can confirm file generation.
After a device becomes faulty, provide the device diagnostic information to agents or Huawei
technical support personnel immediately for fast fault location. For the method of transmitting
the diagnostic information from the device to your computer, see 4.4 Transferring Files Using
FTP/TFTP.
NOTE
l Executing this command requires a long time. You can press Ctrl+C to pause diagnosis information
display on screen.
l When a large amount of diagnostic information is displayed, the CPU usage may be high in a short
period.
3.3 Health Status Information
The device provides the display health command. You can run the command to check the health
status information, including the temperature, power supply, fan, CPU usage, memory usage,
and storage medium usage of the device. The following is an example:
<HUAWEI> display health
Troubleshooting 3 Information Collection
9
4 System Maintenance Methods
About This Chapter
This section describes how to restore default settings, restart a device, and transfer files.
4.1 Restoring the Default Settings Using the Configuration File
4.2 Restarting the Device
4.3 Upgrading the Device
4.4 Transferring Files Using FTP/TFTP
Troubleshooting 4 System Maintenance Methods
10
4.1 Restoring the Default Settings Using the Configuration
File
When the device is powered on, it reads the configuration file from the default directory for
initialization. Therefore, the configuration in the file is called the initial configuration. If no
configuration file is stored in the default directory, the device uses the default parameters for
initialization. You must restart the device to make the recovered default settings take effect.
1. Restore the configuration file using the FTP/TFTP server.
For detailed operations, see Using FTP/TFTP to Transfer Files. Download the default
configuration file to the device.
2. Run the startup saved-configuration command to specify the default configuration file
for the next startup and restore the default settings.
<HUAWEI> startup saved-configuration config.zip
<HUAWEI> reboot fast
NOTE
When restoring the default settings, do not save the configuration. Otherwise, the device starts up
using the current configuration.
4.2 Restarting the Device
Some network faults will be rectified after you restart the device. This section describes how to
restart a device.
You can restart the device using any of the methods in the following table.
Table 4-1 Device restart methods
Method Description
Turn off and then turn on the power switch to
restart the device.
Cold restart is performed manually. In cold
restart, a device can be restarted only by
pressing the power button, which has
limitations and is applicable to onsite
maintenance.
Save the configurations in real time because
the device will restart directly without saving
the current configuration.
Run the reboot command in the user view to
restart the device.
Hot restart uses commands, which is adopted
by maintenance personnel who remotely
manages the device.
In restart, the system asks whether to save the
configuration, which effectively prevents
configuration loss.

11
4.3 Upgrading the Device
The upgrade of a device is closely related to the released software versions. The corresponding
upgrade guide is released with each new version and you can upgrade the device according to
the guide. To obtain the upgrade guides, visit http://support.huawei.com/enterprise, choose
Software > Product Software > Enterprise Networking > Switch > Data Center Switch,
and download the upgrade guide based on the product name and version.
4.4 Transferring Files Using FTP/TFTP
During system maintenance such as software upgrade and configuration file backup, files must
be transferred between a PC and the device. FTP/TFTP is used to transfer files.
When transferring files using FTP/TFTP, the roles of PC and device vary in different methods:
l PC functioning as an FTP server: You must install the FTP server software on your PC.
l PC functioning as a TFTP server: You must install the TFTP server software on your
PC. TFTP is easy to configure but this method has low security and transmission speed.
l Device functioning as an FTP server: You can perform configurations on the device
without installing any software. When there are a large number of devices on a network,
the first two methods are recommended.
PC Functioning as an FTP Server
Figure 4-1 Networking diagram
FTP Client
FTP Server
192.168.0.2/24 192.168.0.1/24
MEth0/0/0
1. Run the FTP server software on the FTP server and configure the FTP service. For details,
see relevant help documentation.
2. Connect the device and the FTP server. (The IP addresses are used as an example.)
a. Connect the FTP server to MEth0/0/0 of the device using a network cable.
b. Configure an IP address 192.168.0.1/24 for MEth0/0/0.
c. Configure an IP address 192.168.0.2/24 for the FTP server.
[~HUAWEI] interface meth 0/0/0
[~HUAWEI-MEth0/0/0] ip address 192.168.0.1 24
[~HUAWEI-MEth0/0/0] commit
[~HUAWEI-MEth0/0/0] ping 192.168.0.2
PING 192.168.0.2: 56 data bytes, press CTRL_C to break
Reply from 192.168.0.2: bytes=56 Sequence=1 ttl=128 time=4 ms
--- 192.168.0.2 ping statistics ---
12
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 3/6/18 ms
[~HUAWEI-MEth0/0/0] return
NOTE
l In this example, the FTP server and the device are directly connected. If they are not directly
connected, you must ensure that they have reachable routes to each other.
l After the configuration is complete, run the ping command to test the connectivity between the
FTP server and device.
3. Log in to the FTP server using FTP.
<HUAWEI> ftp 192.168.0.2
Trying 192.168.0.2 ...
Press CTRL + K to abort
Connected to 192.168.0.2.
220 FTP Server ready.
User(192.168.0.2:(none)):ftpuser
331 Password required for ftpuser.
Enter password:
230 User logged in.
[ftp]
4. Run the put command to upload files to the FTP server or run the get command to download
files from the FTP server to the device.
[ftp] put vrpcfg.zip
200 Port command okay.
150 Opening ASCII mode data connection for /vrpcfg.zip.
/ 100% [***********]
226 Transfer complete.
FTP: 1098 byte(s) sent in 0.131 second(s) 8.38Kbyte(s)/sec.
[ftp] binary
200 Type set to I.
[ftp] get devicesoft.cc
150 Opening BINARY mode data connection for /devicesoft.cc.
\ 6482944 bytes transferred
FTP: 6482944 byte(s) received in 54.500 second(s) 1117.40Kbyte(s)/sec.
[ftp]
PC Functioning as a TFTP Server
TFTP Client
TFTP Server
192.168.0.2/24 192.168.0.1/24
MEth0/0/0
1. Run the TFTP server software on the TFTP server (PC) and configure the TFTP service.
For details, see relevant help documentation.
2. Connect the TFTP server and the device and configure IP addresses for them. For details,
see PC Functioning as an FTP Server.
3. Run the tftp put command to upload files to the TFTP server or run the tftp get command
to download files from the TFTP server to the device.
13
<HUAWEI> tftp 192.168.0.2 get vrpcfg.zip vrpcfg1.zip
Info: Transfer file in binary mode.
Please wait for a while...
/ 8174 bytes transferred
Info: Downloaded the file successfully.
<HUAWEI> tftp 192.168.0.2 put vrpcfg.zip vrpcfg2.zip
Info: Transfer file in binary mode.
Please wait for a while...
/ 100% [***********]
Info: Uploaded the file successfully.
<HUAWEI>
Device Functioning as an FTP Server
FTP Server
FTP Client
192.168.0.2/24 192.168.0.1/24
MEth0/0/0
1. Connect the PC and the device and configure IP addresses for them. For details, see PC
Functioning as an FTP Server.
2. Enable FTP on the device, and create a user name, password, and FTP path.
NOTE
You must set the user level to level 3 or above to establish an FTP connection.
[~HUAWEI] ftp server enable
[~HUAWEI] aaa
[~HUAWEI-aaa] local-user huawei password irreversible-cipher huawei@123
[~HUAWEI-aaa] local-user huawei service-type ftp
[~HUAWEI-aaa] local-user huawei ftp-directory flash:
[~HUAWEI-aaa] local-user huawei level 15
[~HUAWEI-aaa] commit
[~HUAWEI-aaa] quit
[~HUAWEI] quit
3. Log in to the device by running the ftp command on the FTP server. Run the get command
to download files to the FTP server or run the put command to upload files from the FTP
server to the device.
For example, on an FTP server with the Windows operating system, choose Start > Run,
enter cmd, and click OK.
C:\Documents and Settings\Administrator> ftp 192.168.0.1
Connected to 192.168.0.1.
220 FTP service ready.
User (192.168.0.1:(none)): huawei
331 Password required for huawei.
Password:
230 User logged in.
ftp> get vrpcfg.zip
150 Opening ASCII mode data connection for vrpcfg.zip.
ftp: 5203 bytes received in 0.01Seconds 346.00Kbytes/sec.
ftp> lcd
Local directory now C:\Documents and Settings\Administrator.
ftp> put vrpcfg.zip
150 Opening ASCII mode data connection for vrpcfg.zip.
14
ftp: 5203 bytes sent in 0.01Seconds 346.87Kbytes/sec
NOTE
If you use the user name Administrator to log in to the PC, the output differs from the above.
You can run the lcd command to view the path where backup configuration files are saved.
The commands vary with the operating system. For details, see relevant help documentation of each
operating system.
15
5 Startup Failures
About This Chapter
This section describes how to troubleshoot device startup failures.
5.1 Terminal Does Not Display Anything Or Displays Garbled Characters
Troubleshooting 5 Startup Failures
16
5.1 Terminal Does Not Display Anything Or Displays
Garbled Characters
Fault Description
After a terminal connecting to a router starts, it cannot display anything or displays garbled
characters.
Possible Cause
l The power module of the router is faulty or the router is not powered on.
l The serial interface connecting to the router is incorrectly configured.
l The cable between the terminal and router is faulty or not firmly connected to the serial
interface.
Troubleshooting Roadmap
l Check the power indicator on the router's front panel to ensure that the power module is
working properly.
l Ensure that the serial interface is correctly configured.
l Install the cable firmly or replace the cable.
Troubleshooting Procedure
1. Check the power indicator on the router's front panel. If the power indicator is On, the
power module is working properly. If the power indicator is Off, rectify the fault according
to Power Module Troubleshooting.
2. Check whether the combo interface type is correct and whether the physical attributes of
the PC is consistent with those of the serial interface. The default parameters are as follows:
l Baud rate: 9600
l Data bit: 8
l Stop bit: 1
l Parity check: None
l Flow control: None
3. Ensure that the cable is firmly connected to the serial interface. You can replace it with a
new cable to verify whether the cable is faulty.
Troubleshooting 5 Startup Failures
17
6 Hardware
About This Chapter
6.1 Power Module Troubleshooting
6.2 Fan Module Troubleshooting
6.3 Optical Module Troubleshooting
6.4 Interface Troubleshooting
Troubleshooting 6 Hardware
18
6.1 Power Module Troubleshooting
6.1.1 The SYS and Power Module Indicators Are Off
Fault Description
The SYS indicator and power module indicators are all off, and the chassis cannot be powered
on.
Possible Causes
l The power modules are turned off.
l Power cables are not securely connected to the sockets.
l The power modules are faulty.
1. Ensure that the power switches on the power modules are turned on.
2. Ensure that the power cables are securely connected to the sockets.
3. Replace the power modules with normal power modules of the same model. If the chassis
is powered on, the original power modules on the chassis are faulty. Send the faulty power
modules to Huawei for repair.
4. If the chassis still fails to be powered on, contact Huawei Technical Assistance Center.
6.2 Fan Module Troubleshooting
6.2.1 The Indicator of a Fan Module Is Steady Red
Fault Description
The indicator of a fan module is steady red.
Possible Causes
l The fan module is not properly installed in the fan slot.
l Fan blades are blocked or stop rotating because of heavy dust.
l The fan module is faulty.
1. Check whether the fan module is securely installed. If not, remove and reinstall the fan
module (hot swappable).
2. Remove the fan module and check whether fan blades are blocked or covered with heavy
dust.
19
l If fan blades are blocked by an obstacle, remove the obstacle.
l If fan blades have heavy dust, use a brush to clean fan blades.
3. Install another fan module of the same model into the fan slot. If the new fan module can
work normally, the original fan module has failed.
6.2.2 Fan Noise Is Loud
Fault Description
The device is running properly and no fan alarm is generated; however, the fan noise is loud.
Common Causes
l The fan rotation speed is high.
1. Run the display device fan command to check the fan rotation speed.
2. If the fan rotation speed is high, run the set fan-speed slot slot-id percent percent command
to reduce the fan rotation speed. The following is an example:
[~HUAWEI] diagnose
[~HUAWEI-diagnose] set fan-speed slot 1 percent 50
CAUTION
Reducing the fan speed may cause the overtemperature of the device. Therefore, use this
command with caution.
3. If the fan noise is still loud after the fan rotation speed is reduced, run the upgrade fan
command to upgrade the fan version. The following is an example:
[~HUAWEI] diagnose
[~HUAWEI-diagnose] upgrade fan all
4. If the fault persists, use a new fan module.
6.2.3 An Alarm Is Generated When the Fan Status Is Abnormal
Fault Description
The display device command output shows that the fan status is abnormal.
<HUAWEI> display device
Device status:
-----------------------------------------------------------------------------
Slot Sub Type Online Power Register Alarm Primary
-----------------------------------------------------------------------------
1 - CE5850-48T4S2Q-EI Present On Registered Normal Master
FAN2 - Present On Registered Abnormal NA
PWR2 - Present On Registered Normal NA
-----------------------------------------------------------------------------
20
Common Causes
l The fan is not installed properly.
l Fan blades are blocked or have heavy dust.
1. Check whether the fan is properly installed and whether fan blades are blocked by an
obstacle or have heavy dust. If so, properly install the fan, remove the obstacle, or use a
brush to clean fan blades.
2. Run the upgrade fan command to upgrade the fan version. The following is an example:
[~HUAWEI] diagnose
[~HUAWEI-diagnose] upgrade fan all
3. If the fault persists, use a new fan module.
6.2.4 Fan Blades Were Damaged
Fault Description
The display device alarm hardware command output contains the following fan alarm.
<HUAWEI> display device alarm hardware
--------------------------------------------------------------------------------
Index Level Date Time Info
--------------------------------------------------------------------------------
1 critical 2013-04-10 03:03:36 The fan partially failed.(FanID=FAN 1,
Reason=The first fan failed.)
--------------------------------------------------------------------------------
Common Causes
l Fan blades are damaged.
1. Use a new fan module.
6.3 Optical Module Troubleshooting
6.3.1 Optical Modules on the Local and Remote Devices Cannot
Communicate
Fault Description
An optical interface of a CE switch is connected to a remote device through an optical fiber. The
two optical interfaces are Down and cannot communicate with each other.
21
Possible Causes
l The optical module installed on the optical interface is not a Huawei certified optical
module.
l The optical module type does not match the optical fiber type.
l At least one of the two optical interfaces has been manually shut down.
l The transmit power of the optical module is too low or too high.
l The receive power of the optical module is too low or too high.
1. Check whether a Huawei certified optical module is installed on the optical interface. The
CE series switches must use Huawei certified optical modules. Non-Huawei-certified
optical module cannot ensure service reliability and stability. If a non-Huawei-certified
optical module is used, replace it with a Huawei certified optical module.
2. Check whether the optical module matches the optical fiber. If not, replace the optical fiber
or optical module.
l A single-mode optical module (generally with a center wavelength of 1310 nm or 1550
nm) must work with a single-mode optical fiber (generally yellow).
l A multimode optical module (generally with a center wavelength of 850 nm) must work
with a multimode optical fiber (generally orange).
3. Run the display interface transceiver command to check whether any alarm information
has been generated for the optical module.
<HUAWEI> display interface 10ge 1/0/1 transceiver
10GE1/0/1 transceiver
information:
-------------------------------------------------------------------
Common
information:
Transceiver Type :
10GBASE_SR
Connector
Type :LC
Wavelength (nm) :
850
Transfer Distance (m) :80(50um),30(62.5um),300
(OM3)
Digital Diagnostic
Monitoring :YES
Vendor
Name :AVAGO
Vendor Part
Number :AFBR-703SDZ
Ordering
Name :
-------------------------------------------------------------------
Manufacture
information:
Manu. Serial
Number :AD1148A07G7
Manufacturing Date :
2011-12-05
Vendor
Name :AVAGO
-------------------------------------------------------------------
Alarm information:
LOS Alarm
-------------------------------------------------------------------
22
If a LOS alarm is displayed, the local optical interface does not receive signals from the
remote interface. Run the display this command in the interface view to check whether the
two interfaces have been manually shut down. If an interface is shut down, run the undo
shutdown command on the interface.
4. Run the display interface transceiver verbose command to display diagnostic information
about the optical module on the interface. Check whether the diagnostic information
displays alarms about abnormal transmit or receive power.
<HUAWEI> display interface 10ge 1/0/1 transceiver verbose
10GE1/0/1 transceiver
information:
-------------------------------------------------------------------
Common
information:
Transceiver Type :
10GBASE_SR
Connector
Type :LC
Wavelength (nm) :
850
Transfer Distance (m) :80(50um),30(62.5um),300
(OM3)
Digital Diagnostic
Monitoring :YES
Vendor
Name :AVAGO
Vendor Part
Number :AFBR-703SDZ
Ordering
Name :
-------------------------------------------------------------------
Manufacture
information:
Manu. Serial
Number :AD1148A07G7
Manufacturing Date :
2011-12-05
Vendor
Name :AVAGO
-------------------------------------------------------------------
Alarm information:
RxPower Low
-------------------------------------------------------------------
Diagnostic
information:
Temperature (C) :
34.77
Voltage (V) :
3.29
Bias Current (mA) :
7.19
Bias High Threshold (mA) :
10.50
Bias Low Threshold (mA) :
2.50
Current RX Power (dBM) :-40.00
Default RX Power High Threshold (dBM) :3.01
Default RX Power Low Threshold (dBM) :-15.02
Current TX Power (dBM) :-2.57
Default TX Power High Threshold (dBM) :3.01
Default TX Power Low Threshold (dBM) :-9.00
-------------------------------------------------------------------
23
The display interface transceiver verbose command displays the current transmit and
receive power values of the optical module, as well as the default maximum and minimum
power values.
l If RxPower Low is displayed, the receive signal strength is too low. The possible reason
is that the remote interface is Down or packets sent from the remote interface are dropped
during transmission. Check whether the distance between the two devices exceeds the
maximum transmission distance of the optical module. If the distance is within the
transmission distance of the optical module, check whether the optical module on the
remote interface or the optical fiber is damaged. If they are damaged, replace them.
l If RxPower High is displayed, the receive signal strength is too high. The possible
reason is that the distance between the two devices is short but a long-distance optical
module is used. In this case, install an optical attenuator on the optical module to reduce
the transmit power.
l If TxPower Low is displayed, the transmit signal strength on the local optical module
is too low. This may cause a low receive power on the remote optical module. As a
result, the remote interface cannot turn Up or drops packets sent from the local interface.
l If TxPower High is displayed, the transmit signal strength on the local optical module
is too high. This may cause a high receive power on the remote optical module. If the
high receives power lasts for a long time, the remote optical module will be burned.
To ensure normal communication between two optical interfaces, check for transmit and
receive power alarms after the two interfaces have optical modules installed and connected
using an optical fiber. Ensure that the transmit and receive power values of the two optical
modules are in the normal range. Otherwise, traffic forwarding on the optical interfaces
may be abnormal or the optical modules may be damaged.
5. If no transmit and receive power alarms are displayed on the two ends but the two interfaces
are still Down, collect detailed information and logs about the optical modules, and then
replace the optical modules or optical fiber. If the interfaces can turn Up, the original optical
modules or optical fiber has been damaged. If the interfaces are still Down, contact Huawei
Technical Assistance Center.
6.4 Interface Troubleshooting
6.4.1 A 40GE Interface Fails to Be Split into 10GE Interfaces or 10GE
Interfaces Fail to Be Merged into A 40GE Interface
Fault Description
A 40GE interface fails to be split into 10GE interfaces or 10GE interfaces fail to be merged into
a 40GE interface.
Common Causes
l Corresponding commands are not correctly configured.
l The card is not restarted.
24
l A 40GE interface fails to be split into 10GE interfaces.
1. Run the display current-configuration command to check whether configuration
information about port split is available. If not, run the port split interface interface-
type interface-number1 [ to interface-type interface-number2 ] command in the
system view to split the 40GE interface into 10GE interfaces.
2. Run the display port split command to check the current interface status. If the
command output displays the following information, restart the card.
<HUAWEI> display port split
Note:*Enable : Enabled after board reset
*Disable : Disabled after board reset
----------------------------------------------------
Port Status Split-port
----------------------------------------------------
40GE4/0/1 *Enable 10GE4/0/49
10GE4/0/50
10GE4/0/51
10GE4/0/52
----------------------------------------------------
l 10GE interfaces fail to be merged into a 40 GE interface.
1. Run the display current-configuration command to check whether configuration
information about port split is available. If not, run the undo port split interface
interface-type interface-number1 [ to interface-type interface-number2 ] command in
the system view to merge 10GE interfaces into the 40GE interface.
2. Run the display port split command to check the current interface status. If the
command output displays the following information, restart the card.
<HUAWEI> display port split
Note:*Enable : Enabled after board reset
*Disable : Disabled after board reset
----------------------------------------------------
Port Status Split-port
----------------------------------------------------
40GE4/0/3 *Disable 10GE4/0/57
10GE4/0/58
10GE4/0/59
10GE4/0/60
----------------------------------------------------
6.4.2 An Electrical Interface Cannot Go Up
Fault Description
An electrical interface cannot go up physically. The interface status is as follows:
<HUAWEI> display interface 10GE1/0/6
10GE1/0/6 current state : DOWN (ifindex:
10)
Line protocol current state :
DOWN

Description:

Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is
9216
Internet protocol processing :
disabled

IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
25
0025-9e95-7c10
Port Mode: COMMON COPPER, Port Split:
-
Speed : 10000,
Loopback:NONE

Duplex: FULL, Negotiation:
ENABLE
Mdi :
AUTO,

Last physical up time :
-

Last physical down time : 2013-04-09 16:27:40
Common Causes
l The power cable is faulty.
l Negotiation between the local and remote interfaces fails.
1. Check the cable status. Run the virtual-cable-test command in the interface view to check
the cable status. If the cable status is displayed as Open or Short rather than OK, replace
the cable.
2. Check configurations on the local and remote interfaces.
l If the remote interface works in auto-negotiation mode, run the restart command in the
local interface view to restart the interface.
l If the remote interface works in non-auto negotiation and has a rate configured, run the
speed { 10 | 100 | 1000 } or speed { 100 | 1000 | 10000 } command in the local interface
view to configure the same rate as that of the remote interface.
6.4.3 10GE Optical Interfaces Cannot Go Up
Fault Description
A 10GE optical interface cannot go up physically. The interface status is as follows:
<HUAWEI> display interface 10ge4/0/2
9)
DOWN

Description:

Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is
9216
disabled

0025-9e01-0204
Port Mode: COMMON FIBER, Port Split:
-
Speed : 10000, Loopback:
NONE
26
DISABLE
Mdi :
-

-

Last physical down time : 2013-04-10
03:12:43
Current system time: 2013-04-13 10:42:27
......
Common Causes
l The type, rate, and wavelength of the local and remote optical modules are different.
l An incorrect type or length of optical fiber is used.
l The optical module is incorrectly installed or the optical fiber fails.
l Negotiation between the local and remote end fails.
l The optical module fails.
1. Ensure that the type, rate (10GE or GE), and wavelength of the local and remote optical
modules are the same. The remote optical module must transmit optical signals properly.
2. Ensure that the local and remote optical modules have the same optical fiber transmission
mode (single-mode or multimode) and use optical fibers of proper length.
l If the transmission distance is long, the optical module must use an optical attenuator
to prevent excessively high optical power.
l If the transmission distance is short, use optical fibers of proper length.
3. Run the display interface [ interface-type interface-number ] transceiver verbose
command to check whether optical module information is correct.
l If alarm messages are displayed, install the optical module correctly or replace the
optical fiber. Then, run the restart command to restart the interface.
-------------------------------------------------------------------
Alarm information:
LOS Alarm
-------------------------------------------------------------------
l If no alarm message is displayed, check whether the optical power of the optical module
is within the allowed range, that is, the power of the optical module must meet the
following requirements: Default RX Power Low Threshold < Current RX Power
<Default RX Power High Threshold and Default TX Power Low Threshold < Current
TX Power < Default TX Power High Threshold.
-------------------------------------------------------------------

Diagnostic
information:
Temperature (C) :
34.77
Voltage (V) :
3.29
Bias Current (mA) :
7.19
Bias High Threshold (mA) :
10.50
27
Bias Low Threshold (mA) :
2.50
Current RX Power
(dBM) :-2.19
Default RX Power High Threshold (dBM) :
3.01
Default RX Power Low Threshold
(dBM) :-15.02
Current TX Power
(dBM) :-2.57
Default TX Power High Threshold (dBM) :
3.01
Default TX Power Low Threshold
(dBM) :-9.00
-------------------------------------------------------------------
4. If a GE optical module is used, ensure that the local and remote modules work in the same
negotiation mode and has the same rate.
5. If a 10GE optical module is used, replace the optical module.
6.4.4 40GE Optical Interfaces Cannot Go Up
Fault Description
A 40GE optical interface cannot go up physically. The interface status is as follows:
<HUAWEI> display interface 40ge3/0/2
9)
DOWN

Description:

Switch Port, PVID : 1, The Maximum Frame Length is
9216
disabled

0025-9e01-0204
Port Mode: COMMON FIBER, Port Split:
-
Speed : 40000, Loopback:
NONE
DISABLE
Mdi :
-

-

Last physical down time : 2013-04-10
03:12:43
Current system time: 2013-04-13 10:42:27
......
Common Causes
l The type, rate, and wavelength of the local and remote optical modules are different.
l An incorrect type or length of optical fiber is used.
28
l The optical module is incorrectly installed or the optical fiber fails.
l The optical module fails.
1. Ensure that the type, rate, and wavelength of the local and remote optical modules are the
same. The remote optical module must transmit optical signals properly.
2. Ensure that the local and remote optical modules have the same optical fiber transmission
mode (single-mode or multimode) and use optical fibers of proper length.
l If the transmission distance is long, the optical module must use an optical attenuator
to prevent excessively high optical power.
l If the transmission distance is short, use optical fibers of proper length.
3. Run the display interface [ interface-type interface-number ] transceiver verbose
command to check whether optical module information is correct.
l If alarm messages are displayed, install the optical module correctly or replace the
optical fiber. Then, run the restart command to restart the interface.
-------------------------------------------------------------------
Alarm information:
LOS Alarm
-------------------------------------------------------------------
l If no alarm message is displayed, check whether the optical power of the optical module
is within the allowed range, that is, the power of the optical module must meet the
following requirements: Default RX Power Low Threshold < Current RX Power <
Default RX Power High Threshold.
4. Replace the optical module.
6.4.5 Packet Loss Occurs on An Interface
Fault Description
Packet loss occurs when packets are transmitted on an interface.
Common Causes
l Physical connection fails because the network cable connector is loose or in bad contact.
l The length of packets sent from the remote device are too small.
l The length of packets packets sent from the remote device are too large.
Run the display interface [ interface-type [ interface-number ] ] command to check packet
statistics on the interface where packet loss occurs and determine the type of the lost packets.
l If crc error packets are lost and the percentage of the number of crc error packets against
the total number of packets is small, check whether the cable connector is loose or the
physical line is damaged. If so, tighten the connector or replace the transmission medium
such as the optical fiber, copper cable, optical module, or network cable. Run the restart
command in the interface view to restart the interface.
29
l If runts packets are lost, check the length of packets received by the local interface.
If the length of the received packets is smaller than 64 bytes, check whether the length
of the packets sent by the remote device is correct. If the length of the packets sent by
the remote device is incorrect, modify configurations on the remote device.
If the length of the packets sent by the remote device is correct (the packet length is
larger than or equal to 64 bytes), run the restart command to restart the local interface.
l If giants packets are lost, check whether the length of the packets received by the local
interface. Run the display interface[ interface-type [ interface-number ] ] command to
check the value of The Maximum Frame Length which indicates the maximum length
of packets allowed by the interface. Then compare the length of the received packets and
the value of The Maximum Frame Length.
If the length of the received packets is larger than the The Maximum Frame Length
but smaller than the maximum frame length allowed by the interface, run the
jumboframe enable value command to increase the length of packets allowed by the
interface to a value larger than or equal to the length of the received packets.
If the length of the received packets is larger than the maximum frame length allowed
by the interface (the packet length is larger than the maximum length configured using
the jumboframe enable value command), run the mtu mtu command on the remote
device to reduce the MTU of the remote interface to a value smaller than or equal to the
value of The Maximum Frame Length.
l If discard packets are lost, check whether traffic shaping for an interface queue is
configured on the outbound interface and whether the rate of the outbound interface is
smaller than the traffic bandwidth.
For example, if packets received by 10GE1/0/1 are forwarded through 10GE1/0/2, and
traffic shaping for a specified interface queue is configured on 10GE1/0/2 or the rate of
10GE1/0/2 is smaller than the traffic bandwidth, some packets cannot be forwarded. As a
result, packets are discarded and packet loss occurs on 10GE1/0/1.
If traffic shaping for a specified interface queue is configured on the outbound interface,
run the qos queue queue-index shaping cir cir-value [ kbps | mbps | gbps ] pir pir-
value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] pbs pbs-
value [ bytes | kbytes | mbytes ] ] command to modify traffic shaping parameters.
If the rate of the outbound interface is smaller than the traffic bandwidth, run the
speed { 10 | 100 | 1000 } or speed { 100 | 1000 | 10000 } command to increase the
interface rate.
30
7 Patch and Upgrade Faults
About This Chapter
This section describes how to troubleshoot patch installation faults and upgrade faults.
7.1 Patch Faults
Troubleshooting 7 Patch and Upgrade Faults
31
7.1 Patch Faults
7.1.1 Failed to Install a Patch
Fault Description
A patch cannot be installed.
<HUAWEI> patch load patch.PAT all
Error: Files cannot be obtained from the patch file.
Possible Causes
l Other patches are running on the device.
l The device has no patch to be installed.
l The version of the patch to be installed does not match the system software version.
1. If other patches are running on the device, before installing a non-incremental patch, run
the patch delete all command to delete the running patches.
2. If the device has no patch to be installed, upload the patch to the installed to the device.
For detailed operations, see Using FTP/TFTP to Transfer Files to upload the patch to be
installed to the device.
3. If the device has a patch to be installed but the version of the patch does not match the
system software version, install a patch of which the version matches the system software
version.
Troubleshooting 7 Patch and Upgrade Faults
32
8 Service Faults
About This Chapter
8.1 LAN
8.2 IP Forwarding and Routing
8.3 IP Multicast
This chapter describes common causes of IP multicast faults and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
8.4 QoS
8.5 Device Management
8.6 TRILL
This chapter describes common causes of TRILL faults and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures.
Troubleshooting 8 Service Faults
33
8.1 LAN
8.1.1 VLAN Troubleshooting
This chapter describes common causes of VLAN faults, and provides the corresponding
8.1.1.1 Users in a VLAN Cannot Communicate with Each Other
This section describes common causes of the communication failure between users in a port-
based VLAN, and provides the corresponding troubleshooting flowcharts, troubleshooting
procedures, alarms, and logs.
8.1.1.1.1 Common Causes
This fault is commonly caused by one of the following:
l The link between users is faulty.
l The interfaces connected to the users are shut down manually or the physical interfaces are
damaged.
l The switch learns incorrect MAC addresses.
l Port isolation is configured on the switch.
l Incorrect static Address Resolution Protocol (ARP) entries are configured on the user
terminals.
l Incorrect mappings between interfaces and MAC addresses are configured on the switch.
8.1.1.1.2 Troubleshooting Flowchart
Figure 8-1 shows the troubleshooting flowchart.
34
Figure 8-1 Troubleshooting flowchart for communication failure between users in a port-based
VLAN
Users in a VLAN
cannot
communicate
Are user interfaces
in the VLAN Up?
Are terminal
IP addresses
correct?
Are the
learned MAC
address entries
correct?
Bring the interfaces to
Up state
End
Yes
No
Yes
Yes
No
No
Seek technical
support
No
Yes
Modify terminal IP
addresses
No
No
Yes
Is VLAN
configuration
correct?
Modify VLAN
configuration
Yes
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
No
Is port isolation
configured?
Disable port isolation
No
No
No
Yes Are static ARP
entries on terminals
correct?
Modify static ARP
entries
Yes
Is the fault
rectified?
Is the fault
rectified?
Seek technical
support
Yes
Yes
No
No
Yes
35
8.1.1.1.3 Troubleshooting Procedure
Context
NOTE
is pressed.
Procedure
Step 1 Check that the interfaces connected to the user terminals are in Up state.
Run the display interface interface-type interface-number command in any view to check the
status of the interfaces.
l If the interface is in Down state, rectify the fault according to Interface
Troubleshooting.
l If the interface is Up, go to Step 2.
Step 2 Check whether the IP addresses of user terminals are in the same network segment. .
l If they are in different network segments, change the IP addresses of the user terminals.
l If they are in the same network segment, go to Step 3
Step 3 Check that the MAC address entries on the device are correct.
Run the display mac-address command on the device to check whether the MAC addresses,
interfaces, and VLANs in the learned MAC address entries are correct. If the learned MAC
address entries are incorrect, run the undo mac-address mac-address vlan vlan-id command
on the interface to delete the current entries so that the device can learn MAC address entries
again.
After the MAC address table is updated, check the MAC address entries again.
l If the MAC address entries are incorrect, go to Step 4.
l If the MAC address entries are correct, go to Step 5.
Step 4 Check that the VLAN is properly configured.
l Check the VLAN configuration according to the following table.
Check Item Method
Whether the
VLAN has been
created
Run the display vlan vlan-id command in any view to check whether
the VLAN has been created. If not, run the vlan command to create
the VLAN.
36
Check Item Method
Whether the
interfaces are
added to the
VLAN
Run the display vlan vlan-id command in any view to check whether
the VLAN contains the interfaces. If not, add the interfaces to the
VLAN.
NOTE
If the interfaces are located on different devices, add the interfaces connecting
the devices to the VLAN.
l Add an access interface to the VLAN by using either of the
following methods:
NOTE
The default type of a device interface is access. To change the interface
type to access, run the port link-type access command in the interface
view.
1. Run the port default vlan command in the interface view.
2. Run the port command in the VLAN view.
l Add a trunk interface to the VLAN.
NOTE
type to trunk, run the port link-type trunk command in the interface
view.
Run the port trunk allow-pass vlan command in the interface
view.
l Add a hybrid interface to the VLAN by using either of the
following methods:
NOTE
type to hybrid, run the port link-type hybrid command in the interface
view.
1. Run the port hybrid tagged vlan command to add a port to
VLANs in untagged mode in the interface view.
2. Run the port hybrid untagged vlan command to add a port
to VLANs in tagged mode in the interface view.
Whether
connections
between interfaces
and user terminals
are correct
Check the connections between interfaces and user terminals
according to the network plan. If any user terminal is connected to
an incorrect interface, connect it to the correct interface.

After the preceding operations:
If the MAC address entries are correct, go to Step 5.
If the MAC address entries are incorrect, go to Step 7.
Step 5 Check whether port isolation is configured.
37
Run the interface interface-type interface-number command in the system view to enter the
interface view, and then run the display this command to check whether port isolation is
configured on the interface.
l If port isolation is configured, run the undo port-isolate enable command on the interface
to disable port isolation.
l If port isolation is not configured, go to Step 6.
Step 6 Check whether correct static Address Resolution Protocol (ARP) entries are configured on the
user terminals.
l If the static ARP entries are incorrect, modify them.
l If the static ARP entries are correct, go to Step 7.
Step 7 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration file, log file, and alarm file of the device
----End
8.1.1.1.4 Relevant Alarms and Logs
Relevant Alarms
None.
Relevant Logs
None.
8.1.2 MSTP Troubleshooting
This chapter describes common causes of MPLS faults, and provides the corresponding
8.1.2.1 MSTP Topology Change Leads to Service Interruption
When the topology on an MSTP network changes, services are interrupted.
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 8-2.
38
Figure 8-2 Networking diagram of MSTP
Switch1
10GE1/0/1 10GE1/0/1
10GE1/0/2
10GE1/0/2
10GE1/0/1
Switch2
Switch3 Switch4
10GE1/0/1
10GE1/0/2
10GE1/0/2
Root Switch: Switch1
MSTI1:
MSTI2:
Blocked port
Blocked port
CIST(MSTI0):
Blocked port
The troubleshooting roadmap is as follows:
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.
39
Figure 8-3 Troubleshooting flowchart for service interruption due to changes in MSTP topology
MSTP status is
correct?
MSTP recalculation
is performed?
Physical
interface on the device
alternates between Up
and Down?
Collect information
Check and modify the
MSTP configuration
Shut down the
flapping interface
Services are
interrupted or the
device is
disconnected
Yes
No
Seek technical support
No
End
Is fault rectified?
Is fault rectified?
Yes
Yes
Yes
No
No
Seek technical
support
No
Yes
Context
NOTE
is pressed.
Procedure
Step 1 Check the status of interfaces on MSTP devices.
Check the role of each MSTP-enabled port in each instance.
40
On the network shown in Figure 8-2, 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 Switch1. As shown
in Figure 8-2, in instances 0 and 1, Switch1 functions as a root bridge, and all ports on Switch1
are designated ports. In instance 2, one port on Switch1 is a designated port, and the other port
is a root port. Both ports are in the Forwarding state.
[Switch1] display stp brief
MSTID Port Role STP State Protection Cost
Edged
0 10GE1/0/1 DESI FORWARDING NONE 2
DISABLE
DISABLE
DISABLE
DISABLE
2 10GE1/0/1 ROOT FORWARDING NONE 2
DISABLE
DISABLE
in Figure 8-2, in instances 2, Switch2 functions as a root bridge, and all ports on Switch2 are
designated ports. In other instances, one port on Switch2 is a designated port, and the other port
is a root port. Both of them are in the Forwarding state.
Edged
DISABLE
DISABLE
DISABLE
DISABLE
DISABLE
DISABLE
in Figure 8-2, in instance 2, one port on Switch3 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
Swicth3 is a designated port and the other port is a root port. Both of them are in the Forwarding
state.
Edged
0 10GE1/0/1 DEST FORWARDING NONE 2
DISABLE
DISABLE
1 10GE1/0/1 DEST FORWARDING NONE 2
DISABLE
DISABLE
2 10GE1/0/1 ALTE DISCARDING NONE 2
41
DISABLE
DISABLE
in Figure 8-2, in instance 0, one port on Switch4 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 Switch4
is a designated port, and the other port is a root port. Both of them are in the Forwarding state.
Edged
DISABLE
DISABLE
DISABLE
DISABLE
DISABLE
DISABLE
l On the network shown in Figure 8-2, 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 5.
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.
[Switch1] display stp region-configuration
Oper configuration
Format selector :0
Region name :306b20792201
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 a mapping is
incorrect, run the instance command to map the VLAN to a specified spanning tree
instance.
Run the display current-configuration command to view the MSTP configuration in the
configuration file of the device.
l Check whether MSTP is disabled on the interfaces that connect to user terminals or the
interfaces are configured as edge interfaces.
l Check whether interfaces are added to VLANs correctly. For VLAN configurations, see
"VLAN Configuration" in the Configuration Guide - LAN.
l If the MSTP configuration is correct, go to Step 3.
Step 3 Check that no MSTP recalculation was performed.
Run the display stp command in any view to check whether the device received TC messages.
[Switch1]display stp
-------[CIST Global Info][Mode MSTP]-------
42
Config Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Bridge :32768.00e0-fc0e-a421
Active Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC :32768.00e0-fc0e-a421 / 0 (This bridge is the root)
CIST RegRoot/IRPC :32768.00e0-fc0e-a421 / 0 (This bridge is the root)
CIST RootPortId :0.0
BPDU-Protection :Disabled
TC or TCN received :0
TC count per hello :0
STP Converge Mode :Normal
Share region-configuration :Enabled
Time since last TC :0 days 23h:9m:30s
Number of TC :1
Last TC occurred :10GE1/0/1
l If the values of TC or TCN received and TC count per helloin the command output
increase, the device has received TC messages, and the network topology has changed.
View the log messages MSTP/4/PROPORT_STATE_DISCARDING and MSTP/4/
PROPORT_STATE_FORWARDING to check whether the role of an MSTP-enabled port
changed.
If the port role did not change, go to Step 4.
If the port role changed, go to Step 5.
NOTE
If a multi-process has been created on the device, and TC notification was configured in the multi-
process, when the topology of the multi-process changes, a TC message is sent to process 0 to instruct
devices in process 0 to refresh their MAC and ARP address tables. Then, devices on the network can
re-select links to forward traffic, ensuring non-stop traffic.
l If the values of the TC or TCN received and TC count per hello in the command output
are 0s, the device does not receive any TC message. Contact Huawei technical support
personnel.
Step 4 Check that no interface on the device alternates between Up and Down.
View the log message IFNET/2/linkdown_active to check whether an MSTP-enabled port
alternates between Up and Down.
l If an MSTP-enabled interface alternates between Up and Down, the interface flaps. If a
physical interface frequently alternates between Up and Down, the MSTP status of the
device on the network becomes unsteady. As a result, a large number of TC messages are
generated, ARP entries and MAC entries are frequently deleted, and services are
interrupted. Run the shutdown command on the flapping interface. If services are not
restored after the interface is shut down, go to Step 5.
l If no interface flaps, go to Step 5.
l Configuration files, log files, and alarm files of the device
----End
Relevant Alarms
MSTP_1.3.6.1.2.1.17.0.2 topologyChange
43
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
Relevant Logs
None.
8.2 IP Forwarding and Routing
8.2.1 RIP Troubleshooting
This chapter describes common causes of RIP faults and provides the corresponding
8.2.1.1 Device Does not Receive Partial Routes or All the Routes
This section describes common causes of a device not receiving partial routes or all the routes,
and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms,
and logs.
This fault commonly results from one of the following causes:
l The incoming interface is not enabled with RIP.
l The incoming interface is not in Up state.
l The authentication type and password sent by the peer does not match that received on the
local interface.
l The version number sent by the peer does not match that received on the local interface.
NOTE
RIP version 2 broadcast receives all packets from the peer.
l The undo rip input command is configured on the interface so the interface is disabled to
receive the RIP packet.
l The policy that is used to filter the received RIP routes is configured.
l The metric of the received routes is larger than 16.
l Other protocols learning the same routes in the routing table.
l The number of received routes exceeds the upper limit.
44
Figure 8-4 RIP route receiving troubleshooting flowchart
Ensure that the
filtering policy does
not filter out the
received routes.
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes Yes
No
A device fails to receive
some or all routes.
Is RIP
enabled on the
ingress?
Does
the ingress work
properly?
Is the fault
rectified?
Do the
versions of the
sending and receiving
interfaces match?
Is a filtering policy
configured?
Has the undo
rip input command
run?
Is the
RIP metric equal to or
greater than 16?
Do other
better routes exist?
Seek technical supports.
Is the fault
rectified?
Enable RIP on the
ingress.
Ensure that the
ingress works
properly.
Configure the
same version for
the receiving and
sending interfaces.
Delete the undo
rip input
command.
Run the metric of
the interface.
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
End
No
No
Yes
Is load balancing
configured?
Increase the
number of equal-
cost paths.
Is the fault
rectified?
No No
Yes
Has the
verify-source
command run?
Delete the verify-
source command.
Is the fault
rectified?
Yes
Yes
Yes
45

NOTE
is pressed.
Procedure
Step 1 Check whether RIP is enabled on the inbound interface.
The network command is used to specify the interface network segment. Only an interface
enabled with RIP protocol can receive and send RIP routing information.
Using the display current-configuration configuration rip command, check whether the
inbound interface is contained in the display about the current enabled RIP.
The network address enabled by the network command must be that of the natural network
segment.
Step 2 Check whether the inbound interface works normally.
Run the display interface command to check the running status of the inbound interface.
If the physical state of the interface is Down or Administratively Down, or the state of the current
protocol is Down, RIP cannot work normally on the interface. Therefore, the UP state of the
interface must be ensured.
Step 3 Check whether the version number sent by the peer matches the version number received on the
local interface.
If the version numbers of the inbound interface and that of the RIP packet are different, the RIP
routing information may not be received correctly.
Step 4 Check whether the undo rip input command is configured on the inbound interface.
The rip input command enables the specified interface to receive the RIP packet.
The undo rip input command disables the specified interface from receiving the RIP packets.
If the undo rip input command is configured on the inbound interface, none of the RIP packets
coming from the interface can be processed. Therefore, the routing information cannot be
received.
Step 5 Check whether the policy that filters the received RIP route is configured in RIP.
The filter-policy import command is used to filter the received RIP routing information.
l If the ACL is adopted, use the display current-configuration configuration acl-basic
command to verify whether the RIP routing information learned from the neighbor is
filtered out.
46
Use the suffix list of the IP address to filter the route.
Use the display ip ip-prefix command to check the configured policy.
l If the routing information is filtered out by the routing policy, configure the correct routing
policy.
Step 6 Check whether the inbound interface is configured with the rip metricin command and the
metric is equal to 15.
The rip metricin command sets the metric added to the route when the interface receives the
RIP packet.
If the metric exceeds 16, the route is seen as unreachable. Therefore, the route is not added into
the routing table.
Step 7 Check whether maximum load balancing is configured .
Use the display this command in the RIP view to check the number of maximum balanced paths
configured for RIP.
If the maximum value is reached, then the incoming routes to the same destination are not added
to the database.
Step 8 Check whether the rip-verify source is configured.
The rip verify source functionality checks for the address of the source in the incoming packets.
It discards the packets from a different network. By default, this feature is enabled.
If you are receiving packets from a different network, run the undo verify-source command.
Step 9 Check whether other protocols learning the same route exist.
Run the display rip route command to check whether routes received from the neighbor exist.
l One possible case 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.
l In general, the preference of OSPF or IS-IS protocol is greater than that of the RIP protocol.
Hence, if the same route is learned through OSPF or IS-IS, RM chooses either of those
routes over RIP routes. You can change the preference of RIP to a larger value using the
preference command.
l Using the display ip routing-table protocol rip verbose command, you can view the route.
The state of the route is active.
l If the fault cannot be located, contact Huawei.
Step 10 Check for authentication keys (for RIPv2).
For RIPv2, if authentication mode is configured on the sending and receiving interface, then the
authentication keys on both the interfaces should be the same.
Step 11 If the fault persists, collect the following information and contact Huawei.
l Results of this troubleshooting procedure
l Configuration files, log files, and alarm files of the devices
----End
47
Relevant Alarms
None
Relevant Logs
None
8.2.1.2 Device Does not Send Partial or All the Routes
This section describes the common causes, troubleshooting flowchart and provides a step-by-
step troubleshooting procedure for the fault that prevents the device from sending partial or all
the routes.
l The outgoing interface is not enabled with RIP.
l The outgoing interface is not in Up state.
l The silent-interface command is configured on the outgoing interface to suppress the
interface from sending the RIP packet.
l The undo rip output command is configured on the outgoing interface to disable the
interface from sending the RIP packet.
l The policy filtering the imported RIP route 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 of RIP.
l The outgoing interface does not support the multicast or broadcast mode and a packet needs
to be sent to the multicast or broadcast address.
l The number of received routes exceeds the upper limit.
l The maximum packet length bandwidth configured is less.
48
49
Figure 8-5 RIP route sending troubleshooting flowchart
No
No
No
No
No
No
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
No
Yes
A device fails to send some
or all of routes.
Is RIP enabled
on the egress?
Is the fault
rectified?
Seek technical support.
End
No
Yes
No
Yes
Enable RIP on the
egress.
Delete the undo rip
output command.
Ensure that the filtering
policy does not filter out
the routes imported by
RIP.
Ensure that the local
interface works properly.
Increase the maximum
packet length.
Yes
Yes
Disable route
summarization.
No
No
Yes
Yes
Reduce the metric of the
interface.
No
No
Yes
Yes
Ensure that the route
exists in the database.
Yes
Yes
Reduce the routing
update interval.
Yes
Yes
No
Does the
outbound interface work
properly?
Is the
metric equal to or greater
than 16?
Has the
Silent-interface
command been run?
Is the
undo rip output
command run?
Is route
summarization
configured?
Does
the route exist in the
database.
Is a
filtering policy
configured?
Does the
local interface work
properly?
Is the
routing update interval
too long?
Is the
maximum packet length
too long?
Ensure that
the outbound interface
works properly.
Delete the silent-
interface command.
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
50

NOTE
is pressed.
Procedure
Step 1 Check whether RIP is enabled on the outbound interface.
The network command is used to specify the interface network segment. Only an interface
enabled with RIP protocol can receive and send RIP routes.
l Using the display current-configuration configuration rip command, check the
information about the network segment where RIP is enabled.
Check whether the outbound interface is enabled.
The network address enabled by the network command must be that of any natural network
segment except loopback, broadcast, and multicast networks.
Step 2 Check whether the outbound interface works normally.
Use the display interface command to check the running status of the outbound interface.
If the physical state of the interface is down or Administratively Down or the state of the current
protocol is Down, RIP cannot work normally on the interface.
Therefore, the interface should be in UP state.
Step 3 Check whether the silent-interface command is configured on the outbound interface.
The silent-interface command disables the interface from sending the RIP packet.
l Run the display current-configuration configuration rip command to check if the
interface is disabled from sending the RIP packet.
l Enable the interface by running the undo silent-interface command.
Step 4 Check whether the undo rip output command is configured on the outbound interface.
Run the display current-configuration command on the outbound interface to verify whether
the rip output command is configured.
The rip output command enables the interface to send the RIP packets.
The undo rip output command disables the interface from sending the RIP packets.
If the outbound interface is configured with the undo rip output command, the RIP packet
cannot be sent on the interface.
Step 5 Check whether the summary has been configured.
51
The rip summary-address command disables Classful summarization to perform routing
between subnets. When Classful summarization is off, subnets are advertised. This feature is
used to reduce the number of RIP packets on the network.
If RIPv2 is configured on the interface, it always uses Classful summarization. In this case, you
can run the undo rip summary-address command.
Step 6 Check whether the sum of the route and metric out value is greater than 16.
Run the display rip route command to check the metric value of the route. If the metric value
is greater than or equal to 16, it is considered as unreachable.
While sending RIP routes, the RIP metricout value is added to the RIP packets. To correct this
fault, decrease the metricout value for the interface through which the route is sent.
Step 7 Check whether routes exist in the RIP database.
Run the display rip database command to check whether routes exist in the RIP database. If
there is no route in the RIP database, routes fail to be sent.
Step 8 Check whether the policy that filters the imported RIP route is configured in RIP.
Using the filter-policy export command, configure the filtering policy on the global interface.
Only the route whose attributes match those specified in the filter policy are added to the
advertised routing table of RIP and advertised through the updated packet.
Step 9 Check the status of the interface when the route is sent to the local interface address.
Run the display interface command to check the running status of the interface. If the physical
state of the interface is down or Administratively Down or the current state of the protocol on
the outbound 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 10 Check whether the periodic timer value is too high and the age timer and garbage timer are too
low.
Run the display rip command to check the value of the rip timers. If the update timer value is
configured to a very high value, the updates are sent after a long period giving the impression
that the router is not functioning properly. If the age timer and garbage timer are configured too
less, then the route is removed from the database
l Configure the periodic timer value to a smaller value, such as 30 seconds to get frequent
updates.
l Configure the age timer and garbage time to larger values, such as 120, 180 seconds
respectively.
Step 11 Check whether other issues exist.
If the outbound interface does not support the multicast or broadcast mode and the packet needs
to be sent to the multicast or broadcast address, the fault occurs.
Configure the peer command in RIP mode and send the packet to the unicast address. This action
prevents the fault from occurring.
Step 12 Check whether the maximum packet length on the interface is less.
Using the display current-configuration configuration command, check the information
about the maximum packet length where RIP is enabled.
52
Packets are transmitted if at least one RTE can be sent out. Packets are not transmitted out if the
maximum packet length is less than 32. Reconfigure the maximum packet length on the interface
to at least 32.
NOTE
l Maximum packet length is 52 for a simple authentication interface.
l Maximum packet length is 72 for the MD5-keyid interface or keychain MD5 interface.
l Maximum packet length is 56 for the Huawei MD5 interface
Step 13 If the fault persists, collect the following information and contact Huawei.
----End
Relevant Alarms
None
Relevant Logs
None
8.2.1.3 Trouble Cases
This section describes fault symptoms, locating process, and troubleshooting procedure in
common RIP-related fault cases.
8.2.1.3.1 A RIP Error Occurs due to Discontinuous Subnets
NOTE
is pressed.
Fault Symptom
As shown in Figure 8-6, Switches A, B, and C run RIP. RIP is run in the network segments
172.16.1.0/24 and 192.168.1.0/24 of Switch A, network segments 192.168.1.0/24 and
192.168.2.0/24 of Switch B, and network segments 172.16.2.0/24 and 192.168.2.0/24 of Switch
C.
53
Figure 8-6 Networking where a RIP route error occurs due to discontinuous subnets
SwitchA
SwitchB
SwitchC
10GE1/0/1
VLANIF100
192.168.1.2/24
10GE1/0/1
VLANIF100
192.168.1.1/24
10GE1/0/2
VLANIF200
192.168.2.2/24
10GE1/0/2
VLANIF200
192.168.2.1/24
10GE1/0/2
VLANIF400
172.16.1.1/24
10GE1/0/1
VLANIF300
172.16.2.1/24

Run the display ip routing-table command on Switch B to check whether the routing
information is correct.
If the routing information of Switch B is correct, Switch B has a route to each of the network
segments 172.16.1.0 and 172.16.2.0.
The command output, however, shows that Switch B has only one route to the network segment
172.16.0.0.
Fault Analysis
The network configured with discontinuous subnets runs RIP-1, which does not support VLSM
and CIDR. As a result, a RIP route error occurs.
To solve the problem, configure RIP-2 on all the devices on the network and disable classfull
route summarization.
Procedure
Step 1 Run the system-view command on Switch A to enter the system view.
Step 2 Run the rip [ process-id ] command on Switch A to enter the RIP view.
Step 3 Run the version 2 command on Switch A to configure RIPv2.
Step 4 Run the undo summary command on Switch A to disable classful route summarization.
After configuring Switch A, configure Switch B and Switch C. The configurations of Switch B
and Switch C are similar to that of Switch A, and are not provided here.
----End
Summary
RIPv1 does not support discontinuous subnets. When discontinuous subnets are deployed on a
network, configure RIPv2 on the network.
When a network runs RIPv2, class-based route summarization is enabled by default. To ensure
the correctness of the routing information, disable class-based route summarization.
54
8.2.2 OSPF Troubleshooting
This chapter describes common OSPF faults and provides troubleshooting.
8.2.2.1 OSPF Neighbor Relationship Is Down
This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that causes the OSFP neighbor relationship to be Down.
l The BFD is faulty.
l The other device is faulty.
l The CPU usage on the MPU or interface board of the faulty device is too high.
l The link is faulty.
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 parameters settings of the two devices are inconsistent.
After OSPF is configured on the network, the OSPF neighbor relationship is Down. Figure
8-7 shows the troubleshooting flowchart for the fault that the OSPF neighbor relationship is
Down.
55
Figure 8-7 Troubleshooting flowchart for the fault that the OSPF neighbor relationship is Down
Is the
neighbor down
due to SequenceNum
mismatch?
Check the remote
device
Is the fault rectified?
End
No
No
No
Yes
Yes
Yes
No
Yes
Yes
No
Check the interface
and BFD
No
Yes
Check the remote
device
Seek technical
support
The OSPF neighbor
relationship is Down
Check logs or alarms to
find the value of the
NeighborDownImmediate
field
No
No
Yes
Yes
Is the neighbor down
due to inactivity?
Is the
neighbor down due
to 1-Wayhello
received?
Check the
configurations of the
devices at both ends of
the link
Is theneighbor down
due to kill neighbor?

NOTE
is pressed.
56
Procedure
Step 1 Check the logs to find the cause of the fault.
Run the display logbuffer size buffersize command to access the following log information.
If the log message is as follows, the neighbor status changes:
CE6800 %%01 ospfv2comm/6/NBR_CHANGE(l):VS=0-CID=[UINT];Neighbor changes event:
neighbor status changed. (ProcessId=[UINT], NbrIpAddr=[IPADDR], NbrEvent=[UINT],
NbrPreviousState=[UINT], NbrCurrentState=[UINT])
ICheck the NbrEvent field, which records the cause of the fault. The possible causes of the fault
are as follows:
l Inactivity (NbrEvent=7)
An InactivityTimer event of the neighbor state machine occurs. If a device does not receive
any Hello packets from its neighbor within the down time, the OSPF neighbor relationship
becomes Down. In this case, go to Step 2.
l LLDown (NbrEvent=6)
An LLDown event of the neighbor state machine occurs, indicating that the lower-layer
protocol notifies the upper layer that the neighbor is unreachable. In this case, go to Step 2.
l 1-Way Received (NbrEvent=4)
A 1-Way Received event of the neighbor state machine occurs. A 1-Way Hello packet is sent
from the remote end to the local end when the OSPF status on the remote end changes to
Down. After receiving the packet, the OSPF status on the local end also changes to Down.
In this case, check the remote end to rectify any possible fault.
l Kill Neighbor (NbrEvent=5)
This event indicates that the interface or BFD session becomes Down. Run the display
interface [ interface-type [ interface-number ] ] command to check the interface status and
rectify any possible fault.
If the log message is as follows, the reset ospf process command has been run:
CE6800 %%01 ospfv2comm/6/OSPF_RESET(l):VS=%u-CID=[UINT];OSPF process or area
reset. (CompCID=[UINT], Parameter=[UINT], ResetReason=[UINT])
To verify whether this command has been run, check the operation records or log information.
In all other cases, go to Step 9.
Step 2 Check whether the link between the two devices is normal.
Run the ping command and the display this interface command in the interface view to check
whether the link between the two devices is normal and the transmission devices are normal. If
the link is normal, go to Step 3.
Step 3 Check whether the CPU usage is within the normal range.
Run the display cpu command to check whether the CPU usage on the MPU or interface board
of the faulty device is too high. If it is, OSPF fails to receive and send protocol packets, causing
the neighbor relationship to flap. In this case, troubleshoot the fault of the high CPU usage and
disable unnecessary functions. If the CPU usage is within the normal range, go to Step 4.
Step 4 Check whether the interface status is Up.
57
Run the display interface [ interface-type [ interface-number ] ] command to check the physical
status of the interface. If the physical status 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 a normal type such as DR, BDR, DROther, 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)
Interface IP Address Type State Cost Pri
Vlanif50 192.1.1.1 Broadcast DR 1 1
l If the OSPF status of the interface is Down, run the display ospf cumulative command to
check whether the number of interfaces enabled with OSPF in the OSPF process exceeds
the upper limit. If so, reduce the number of interfaces enabled with OSPF.
<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
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
Neighbor Cumulate:
=======================================================
Neighbor cumulative data. (Process 1)
-------------------------------------------------------
Down: 0 Init: 0 Attempt: 0 2-Way: 0
Exstart: 0 Exchange: 0 Loading: 0 Full: 1
Retransmit Count:1
Neighbor cumulative data. (Total)
-------------------------------------------------------
Down: 0 Init: 0 Attempt: 0 2-Way: 0
Exstart: 0 Exchange: 0 Loading: 0 Full: 1
Retransmit Count:1
l If the OSPF status of the interface is a normal type, such as DR, BDR, DR Other, or P2P,
go to Step 5.
Step 5 Check whether the IP addresses of the two devices are on the same network segment.
Run the display interface interface-type [ interface-number ] command to check the IP
addresses of the interfaces on the two devices.
58
l If the IP addresses of the two devices are on different network segments, run the ip
address command to change these IP addresses to ensure that they 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 whether the MTUs of interfaces on both ends are consistent.
If the ospf mtu-enable command is run on the interfaces on both ends, the MTUs of the two
interfaces must be consistent. Otherwise, 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 so they are consistent.
l If the MTUs are consistent, go to Step 7.
Step 7 Check whether there is an interface whose priority is not 0.
On broadcast and NBMA network segments, at least one interface whose priority is not 0 must
exist to ensure that the DR can be elected correctly. Otherwise, the OSPF neighbor relationship
can only reach the two-way state.
Run the display ospf interface command to view the interface priority.
Interfaces
Vlanif50 192.1.1.1 Broadcast P-2-P 1 1
Step 8 Check whether the OSPF configurations on the two devices are correct.
1. Check whether the OSPF router IDs of the two devices conflict.
<Huawei> display ospf brief
OSPF Protocol Information
If so, modify the OSPF router IDs. If not, proceed with the check.
2. Check whether the OSPF area configurations on the two devices are consistent.
Interfaces
Vlanif50 192.1.1.1 Broadcast BDR 1 1
3. Check whether other OSPF configurations on the two devices are the consistent.
Run the display ospf error command every 10s for 5 minutes.
<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
59
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
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 different. In this case, set 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
different. In this case, check the interface configurations of the two devices and set the
same value for the Hello timers.
l Check the Dead timer mismatch field. If the value of this field keeps increasing, the
value of the dead timers on the two devices that establish the neighbor relationship are
different. In this case, check the interface configurations of the two devices and 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 different
(the area type of one device is the common area, and the area type of the other device
is the stub area or NSSA). In this case, set the same area type for the two devices.
If the fault persists, go to Step 9.
Step 9 Collect the following information and contact Huawei.
----End
Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
Relevant Logs
OSPF/6/NBR_CHANGE
8.2.2.2 OSPF Neighbor Relationship Cannot Enter the Full State
procedure for the fault that prevents the OSFP neighbor relationship from entering the Full state.
l The link is faulty.
l The configurations of the OSPF neighbors are improper.
60
Figure 8-8 shows the troubleshooting flowchart for the fault that prevents the OSPF neighbor
relationship from reaching the Full state.
Figure 8-8 Troubleshooting flowchart for the fault that prevents the OSPF neighbor relationship
from reaching the Full state
Perform the ping
operation.
End
No
No
No
Yes
Yes
Yes
No
Yes
Yes
No
Check the interface
status.
No
Yes
Perform the ping
operation.
Seek technical
support.
The OSPF relationship
cannot enter the Full state.
Check the status of the OSPF
neighbor relationship.
See "OSPF Neighbor
Relationship Is Down"
to rectify the fault.
No
No
Yes
Yes
No
Yes
Check the remote
device and the link.
No
Yes
No
Yes
Check the interface
configured.
No
Yes
Can the status of the
neighbor relationship be
displayed?
Is the neighbor
relationship always in
the Down state?
Is the neighbor
relationship always in
the Init state?
Is the neighbor
relationship always
in the 2-Way state?
Is the neighbor
relationship always
in the Exstart state?
Is the neighbor
relationship always
in the Exchange
state?

61
NOTE
is pressed.
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 for help on rectifying the fault.
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 enabled with OSPF
are 0.
Interfaces
Vlanif50 192.168.5.1 Broadcast DROther 1 0
If the DR priorities of the interfaces enabled with OSPF are 0, the status of the neighbor
relationship is normal.
If the DR priorities 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, the devices are
exchanging DD packets but fail to synchronize LSDBs, which occurs in the following cases:
Excessively long packets cannot be normally sent and received.
Run the ping -s 1500 neighbor-address command to check the sending and receiving of
long packets. 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 not, change the MTUs to ensure they are the
same.
62
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, perform troubleshooting as has been described 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.
CAUTION
Restarting OSPF causes the re-establishment of all the neighbor relationships in the OSPF
process and temporary service interruptions.
If the neighbor relationship is always in the Loading state, run the reset ospf process-id
process command to restart the OSPF process.
----End
Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
Relevant Logs
None
8.2.3 BGP Troubleshooting
This chapter describes common BGP faults and provides troubleshooting procedures.
8.2.3.1 BGP Peer Relationship Fails to Be Established
This section describes the troubleshooting flow and provides a step-by-step troubleshooting
procedure for the fault that prevents the BGP peer relationship from failing to be established.
This fault is commonly caused by one of the following causes:
l BGP packets fail to be forwarded.
63
l An ACL is configured to filter the packets whose destination port is 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 configurations of the peer valid-ttl-hops command are incorrect.
l The peer ignore command is configured on the peer.
l Address families of devices on both ends do not match.
The BGP peer relationship fails to be established after the BGP protocol is configured.
Figure 8-9 shows the troubleshooting flowchart for the failure to establish the BGP peer
relationship.
64
Figure 8-9 Troubleshooting flowchart for the failure to establish the BGP peer relationship
Is there an ACL
configured whose destination
port is TCP port 179?
The BGP peer relationship fails to
be established
Check the routes
used to establish
the BGP peer
relationship
Delete the
configuration
Is the fault
rectified?
Is the fault
rectified?
No
No
No
Yes
Yes
Yes
No
Yes
End
Can the ping operation
succeed?
Does the peer
router ID conflict with the loca
l router ID?
Change the two
router IDs to
different values in
the BGP view
Is the fault
rectified?
No
No
Yes
Yes
Is the displayed peer
AS Number the same as the
remote number?
Change the AS
number of the
remote peer.
Is the fault
rectified?
No
Yes
Yes
Does BGP
configurations affect the
establishment of the BGP peer
relationship?
Modify the BGP
configurations
Is the fault
rectified?
No
No
Yes
Yes
No

65
NOTE
is pressed.
Procedure
Step 1 Run the ping command to check whether the BGP peers can ping each other.
l If they can ping each other, there are available routes between the BGP peers and that link
transmission is normal. In this case, go to Step 2.
NOTE
Run the ping -a source-ip-address -s packetsize host or ping ipv6 -a source-ipv6-address -s byte-
number destination-ipv6-address command to detect the connectivity of the devices on both ends.
Because the source address is specified in this command, you can check whether the two devices
have available routes to each other. By specifying the size of a Ping packet, you can check whether
large Ping packets can be normally transmitted over the link.
l If the ping operation fails, rectify the ping operation failure.
Step 2 Check whether any ACL is configured to filter the packets whose destination port is TCP port
179.
Run the display acl all command on the two devices to check whether an ACL is configured to
filter the packets whose destination port is TCP port 179.
<Huawei> display acl all
Advanced ACL 3001, 2 rules
ACL's step is 5
ACL's match-order is config
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 whose destination port is TCP port 179, run
the undo rule rule-id command and the undo rule rule-id command to delete the ACL
configuration.
l If no such ACL is configured, go to Step 3.
Step 3 Check whether the peer router ID conflicts with the local router ID.
View information about BGP peers to check whether their 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. The following command
output shows as an example:
<Huawei> display bgp peer
BGP local router ID : 1.1.1.1
Local AS number : 65001
Total number of peers : 12 Peers in established state : 4
Peer V AS MsgRcvd MsgSent OutQ Up/Down State
PrefRcv
66
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
Check information about peers in other address families.
l Run the display bgp vpnv4 all peer command to check information about all VPNv4 peers.
l Run the display bgp ipv6 peer command to check information about IPv6 peers.
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 whether 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
Check information about peers in other address families.
l Run the display bgp vpnv4 all peer command to check information about all VPNv4 peers.
l Run the display bgp ipv6 peer command to check information about IPv6 peers.
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 the BGP
configurations.
Item Description
peer connect-interface { interface-
type interface-number | ipv4-source-
address }
If two devices use loopback interfaces to establish
the BGP peer relationship, run the peer connect-
interface command to specify the source interface
through which the BGP packets are sent, and the
source address with which the BGP connection is
established.
67
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 according to the actual
situation.
peer valid-ttl-hops hops If the peer valid-ttl-hops hops command is
configured, check whether the value of hops is
correct. The valid TTL range of the detected packet
is [255 - hops + 1, 255]. hops specifies the number
of hops between the devices on both ends. The hop
count between the two directly connected devices
is 1.
NOTE
The peer valid-ttl-hops command must be configured
on the devices on both ends.
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 specified
by limit. If the upper limit is exceeded, 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 to 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 a
temporary BGP peer relationship with the local
device. To establish the BGP peer relationship
between the peer and the local device, run the undo
peer ignore command on the peer.
68
Item Description
Address family capability Check whether the address family capabilities of
the devices on both ends match. For example, in
order to establish the 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 one device only, the BGP peer
relationship on the other device is displayed as No
neg.

----End
Relevant Alarms
BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition
Relevant Logs
None
8.2.3.2 BGP Public Network Traffic Is Interrupted
This section describes the troubleshooting flow and provides a step-by-step troubleshooting
procedure for the fault that BGP public network traffic is interrupted.
l Routes are inactive because their next hops are unreachable.
l Routes fail to be advertised or received because the routing policies are configured
incorrectly.
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.
Figure 8-10 shows the troubleshooting flowchart for the fault that interrupts BGP public network
traffic.
69
Figure 8-10 Troubleshooting flowchart for the fault that interrupts BGP public network traffic
The BGP public
network traffic is
interrupted
Correctly configure the
routing policy
Reduce the number of
routes
Is the faulty
rectified?
No
No
No
Yes
Yes
Yes
No
Yes
End
Ensure that the next
hop is reachable
No
No
Yes Yes
Is the next hop of the
route reachable?
Is the routing
policy configured
correctly?
Does the
number of routes
exceed the upper
limit?
Is the faulty
rectified?
Is the faulty
rectified?

NOTE
is pressed.
Procedure
Step 1 Check whether the next hops of routes are reachable.
70
Run the display bgp routing-table network { mask | mask-length } command on the local device
that sends routes to check whether the target route is active and has been sent to the peer.
network specifies the prefix of the target route.
In the following example, the target route is a route to 13.0.0.0/8. The 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.
<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: Vlanif50
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 no route to the original next hop exists, the BGP route is not advertised
because its next hop is unreachable. Determine why there is no route to the original next
hop. Note that 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 is sent to the peer, perform Step 2 to check the outbound policy applied to the
local device.
l Run the display bgp routing-table network { mask | mask-length } command on the peer
to check whether it has received the target route.
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.
If the peer has not received the target route, perform Step 2 to check the inbound policy
applied to the peer.
NOTE
In BGP4+ networking, the display bgp routing-table ipv6-address prefix-length command is used to
check whether the target route is received.
Step 2 Check whether the routing policies are configured correctly.
Run the display current-configuration configuration bgp command on the local device and
the peer to check whether the 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
71
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
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
return
l If the inbound and outbound policies are configured on the two devices, you need to check
whether the target route is filtered by these policies.
l If the inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check whether 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 a 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 configurations 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 alarm BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed is generated when
traffic is interrupted, the target route is dropped because the upper limit is exceeded. When this
occurs, 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, reduce the number of sent routes by configuring route summarization on the local
device.
l Results of this troubleshooting procedure.
72
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.6 hwBgpPeerRouteExceed
Relevant Logs
None
8.2.3.3 BGP Private Network Traffic Is Interrupted
procedure for the fault that interrupts BGP private network traffic.
l Routes are inactive because their next hops are unreachable.
l Routes fail to be advertised or received because the routing policies are configured
incorrectly.
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.
l The received routes are dropped because there is an upper limit on the number of routes on
the device.
BGP private network traffic is interrupted after the BGP protocol is configured.
Figure 8-11 shows the troubleshooting flowchart for the fault that interrupts BGP private
network traffic for the fault that interrupts BGP private network traffic.
73
Figure 8-11 Troubleshooting flowchart for the fault that interrupts BGP private network traffic
The BGP private network
traffic is interrupted
Ensure that the tunnel
exists
No
No
Yes
Yes
Yes
Yes
No
No
Yes
Yes
No
Correctly configure the
routing policy
No
Yes
No
Yes
Yes
Ensure that they match
No
Yes
No
Yes
routes or increase the
upper limit of routes
routes or configure the
device to assign a label
to each instance
Yes
No
No
Ensure that the next
hop is reachable
End
Is the next
Hop of the VPN route
reachable?
Is the routing
policy is configured
correctly?
Does the
Number of labels exceed
the upper limit?
Is the
tunnel Iterated
successfully?
Does the
export RT match the
import RT?
Does the
number of routes exceed
the upper limit?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
No
Is the fault
rectified?

74
NOTE
is pressed.
Procedure
Step 1 Check whether the 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 local PE that sends routes 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 in which
the target route is a route to 1.1.1.1/32:
The following command output shows that this route is valid and is the best. 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
Paths: 1 available, 1 best, 1 select
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
l If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If no route to the original next hop exists, the BGP route is not advertised
because its next hop is unreachable. Determine why there is no route to the original next
hop.
l If the target route is valid and the best one available but there is no information indicating
that this route is sent to the remote PE, perform Step 2 to check the outbound policy applied
to the local PE.
l Run the display bgp vpnv4 all routing-table ipv4-address { mask | mask-length }
command on the remote PE to check whether it has received the target route.
75
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.
If the remote PE has not received the target route, perform Step 2 to check the inbound
policy of the remote PE.
Step 2 Check whether the routing policies are configured correctly.
Run the display current-configuration configuration bgp command on the local PE and
remote PE to check whether the inbound and outbound policies are configured.
NOTE
Focus on the peers of the BGP-VPNv4 address family or BGP-VPN instance address family in this
troubleshooting case because the 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
l If the inbound and outbound policies are configured on the two devices, check whether the
target route fails to be transmitted because it is filtered by these policies. For detailed
configurations of a routing policy.
l If the inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check whether the 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.
In the following example, the target route is a route to 50.1.1.2/32. If the Relay Tunnel Name
field in the command output is not empty, this route can be iterated to a tunnel.
<Huawei> dis bgp vpnv4 all routing-table 50.1.1.2
76

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 Name: ldp
Ext-Community:RT <1 : 1>
best, select, pre 255

Total routes of vpn-instance vpna: 1
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Name: ldp
best, select, active, pre 255
l If the target route fails to be iterated to a tunnel, check whether an associated tunnel exists
or the tunnel configurations are correct.
l If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether the 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 the 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
route-distinguisher 1:2
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
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.
77
Step 5 Check whether the number of labels is lower than the upper limit.
Check whether MPLS is enabled on the local PE. Then, 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 no Label information field in the command output exists, the labels may be insufficient. 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

Total routes of Route Distinguisher(1:1): 1
Imported route.
Label information (Received/Applied): NULL/13312
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
Advertised to such 1 peers:
1.1.1.1

Total routes of vpn-instance vpna: 1
Imported route.
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
60
l If the labels are insufficient, run the apply-label per-instance command in the VPN instance
view to configure the device to assign one label to each instance to save labels. You can also
configure route summarization to reduce the number of routes.
l If the labels are sufficient, go to Step 6.
Step 6 Check whether 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 remote PE to check whether the upper limit on the number of
routes to be received is configured on the remote PE.
For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded
after the remote PE receives five routes from the local PE at 1.1.1.1.
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If a peer is added to a peer group, there may be no configurations about the upper limit in the
command output.
78
peer 1.1.1.1 enable
In this case, run the display current-configuration configuration bgp | include peer group-
name command to check the configurations 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 alarm BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed is generated when
traffic is interrupted, the target route is dropped because the number of routes received has
exceeded the upper limit. When this occurs, 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, reduce the number of sent routes by configuring route summarization on the local
device.
----End
Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed
Relevant Logs
None
8.2.3.4 Troubleshooting of the Fault that Prevents a Local BGP Peer (Route Sender)
from Receiving ORFs from a Remote Peer (Route Receiver)
This section describes the troubleshooting roadmap for the fault that prevents a local BGP peer
(route sender) from receiving ORFs from a remote peer (route receiver), and provides
troubleshooting cases.
l The IPv4 BGP peer relationship cannot be established.
79
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, prevents a local BGP peer (route sender) from receiving
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 whether a BGP peer relationship is set up successfully.
l Check whether the BGP ORF capability is negotiated successfully.
l Check whether an import IP-prefix policy is configured on the remote peer (route receiver).
l Check whether a prefix list corresponding to the import IP-prefix policy is configured on
the remote peer (route receiver).
80
Figure 8-12 Troubleshooting flowchart for the fault that prevents a local BGP peer (route sender)
from receiving ORFs from a remote peer (route receiver)
A local BGP peer (route
sender) fails to receive
ORFs from a remote peer
(route receiver)
Yes
Yes
No
No
Is the fault
rectified?
Is the fault
rectified?

No
Yes
See detailed
troubleshooting
procedures in
"Troubleshooting of
the Fault that a BGP
Peer Relationship
Cannot Be Set Up"
No
Is the fault
rectified?
Yes

No
Enable the BGP ORF
function on BGP
peers and reestablish
the BGP peer
relationship
Configure the import
IP-prefix policy on the
remote peer (route
receiver)
Yes
Is an import
IP-prefix policy configured on
the remote peer (route
receiver)?
Is a BGP peer relationship
set up?
Is the BGP
ORF function enabled
on BGP peers and do the
peers succeed in negotiating
the BGP ORF
capability?
No
Is the fault
rectified?
Yes
Configure the prefix
list corresponding to
the import IP-prefix
policy on the remote
peer
Is the prefix
list corresponding to
the import IP-prefix policy
configured on the remote
peer (route
receiver)?
Yes

No

No
Yes
End

81
NOTE
is pressed.
Procedure
Step 1 Check whether 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 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 whether 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 the 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 both or receive mode on the device and 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> system-view
[~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.
82
<Huawei> display bgp peer 7.1.1.1 verbose | include Address-Prefix
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible,
both
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
NOTE
In this 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 is 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
Cisco-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 whether 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 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
#
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.
[~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 whether 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.
This 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 this 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.
83
<Huawei> display ip ip-prefix in
Prefix-list in
Permitted 0
Denied 0
index: 10 permit 10.1.1.0/24
This output shows that the prefix list in has been successfully configured. After completing these
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
Relevant Logs
BGP/6/BGP_PEER_STATE_CHG
8.3 IP Multicast
This chapter describes common causes of IP multicast faults and provides the corresponding
8.3.1 Multicast Traffic Cannot Be Transmitted
This section provides a step-by-step troubleshooting procedure for the fault that prevents IP
multicast traffic from being transmitted.
8.3.1.1 Common Causes
l Multicast routing is not enabled and the multicast configuration fails to be delivered.
l The unicast routing configuration is incorrect.
l The necessary PIM routing entries are not generated.
l The necessary multicast forwarding entries are not generated.
8.3.1.2 Troubleshooting Flowchart
After Layer 3 multicast is configured, multicast traffic cannot be transmitted to users.
84
l Check whether the route to the multicast source is reachable.
l Check whether the PIM routing entries are created.
l Check whether the multicast forwarding entries are created.
Figure 8-13 Troubleshooting flowchart for the fault that prevents multicast traffic from being
transmitted
Is the route to
the multicast source
reachable?
Multicast traffic
cannot be
transmitted.
Has the PIM
routing table been
generated?
Configure a static
route to the multicast
source or enable a
routing protocol.
If the fault
rectified?
Check whether multicast
forwarding entries have
been generated and record
the phenomena?
Yes
Seek
technical
support.
No
End
No
No
Yes
No
Yes

8.3.1.3 Troubleshooting Procedure
NOTE
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be
run to commit the configurations.
Procedure
Step 1 Check whether the route to the multicast source is reachable.
85
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 multicast source address.
l If no route to the multicast source exists, check the route configurations.
l If the route to the multicast source is reachable but the fault persists, go to Step 2.
Step 2 Check whether the PIM information table has been generated.
Run the display pim routing-table command on the device to check whether the PIM
information table has been generated.
l If no entry is displayed, check whether related PIM configurations are correct.
If the PIM configurations are correct, go to Step 3.
If the PIM configurations are incorrect, perform the configurations again. Common
configuration errors include: failure to set up a PIM neighbor relationship, incorrect RP
configuration, incorrect DR configuration, and PIM or IGMP not enabled on user-side
interfaces.
l If upper-layer protocol entries are displayed but the fault persists, go to Step 3.
l Results of this troubleshooting procedure.
l Configuration files, log files, and alarm files of the devices.
----End
8.3.1.4 Relevant Alarms and Logs
Relevant Alarms
None
Relevant Log
None
8.3.2 The PIM Neighbor Relationship Remains Down
This section provides a step-by-step troubleshooting procedure for the fault that causes the PIM
neighbor relationship to remain Down.
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.
86
l The PIM configurations on the interface are incorrect.
After the PIM network configuration is complete, the PIM neighbor relationship remains Down.
Figure 8-14 Troubleshooting flowchart for the fault that causes the PIM neighbor relationship
to remain Down
Enable PIM on the interface
Refer to the
troubleshooting
of interface Down
Refer to the
troubleshooting
of link Down
Is fault rectified?
Change the PIM
configurations on the
interface
Is fault rectified?
Is fault rectified?
End
Is fault rectified?
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
No
No
No
No
No
No
No
The PIM neighbor
relationship remains
Down
Is PIM enabled
on the interface?
Is the PIM status
Up on the interface?
Are the PIM
configurations on the
interface correct?
Is the link status Up
on the interface?
Is the interface
physically Up?

87
NOTE
is pressed.
Procedure
Step 1 Check whether 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 it.
If "Error: Please enable multicast in the system view first." is prompted when you enable
PIM, run the multicast routing-enable command in the system view to enable the multicast
function. Then, enable PIM-SM on the interface.
l If PIM is enabled on the interface, go to Step 2.
Step 2 Check whether the PIM status on the interface is Up.
Run the display pim interface interface-type interface-number command to check whether the
PIM status on 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, change the physical status go Up.
2. If the link status is not Up, change the link status go Up.
l If the PIM status of the interface is Up, go to Step 3.
Step 3 Check whether the PIM configurations on the interface are correct.
The fault may be caused by the following PIM configurations:
l The IP addresses of directly connected interfaces are on different network segments.
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 the Hello messages without Generation IDs, the interface
discards all the Hello messages received from the PIM neighbors without any Generation
IDs, and as a result, the PIM neighbor relationship cannot be set up. This case applies to
Huawei devices that intercommunicate with non-Huawei devices.
Run the display current-configuration interface interface-type interface-number command to
check whether any of these PIM configurations exists on the interface.
88
l If they exist, correct them.
l If the fault persists after these operations are complete, go to Step 4.
----End
Relevant Alarms
None
Relevant Log
PIMPRO/4/NBR_LOSS
8.3.3 MSDP Peers Cannot Generate Correct (S, G) Entries
This section provides a step-by-step troubleshooting procedure for the fault that prevents the
MSDP peers from generating correct (S, G) entries on a multicast network.
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 the
configurations of the logical RP are incorrect.
l The MSDP peer relationships are not set up between every two members in a mesh group.
l The intra-domain multicast protocol used is not PIM-SM.
l The RPF route to the multicast source is incorrect; for example, the unicast route has a loop.
l The configurations are incorrect; for example, the configurations of the SA policy, import
policy, TTL, switchover threshold, or multicast boundary are incorrect.
l SA message fails to pass RPF check.
After the configurations are complete on a multicast network, the MSDP peers cannot generate
correct (S, G) entries.
89
Figure 8-15 Troubleshooting flowchart for the fault that prevents the MSDP peers from
generating correct (S, G) entries
Are the MSDP
Peer in the
Up state?
The MSDP peers
cannot generate correct
(S, G) entries.
Ensure that interfaces
are correctly configured
and peers are reachable
through unicast routes.
Is the fault
rectified?
No
Yes
Seek technical support. End
Is SA cache enabled? Enable SA cache.
Is the fault
rectified?
Have any SA
Message reached the
MSDP peers?
Ensure that MSDP
peers can receive SA
messages.
Is the fault
rectified?
Are export
policies configured on the
MSDP peers?
Remove or change the
export policies.
Is the fault
rectified?
Are import
MSDP peers?
import policies.
Is the fault
rectified?
Is the currect
MSDP peer an RP?
Change the
configurations of the RP
or MSDP.
Is the fault
rectified?
Are import-source
current MSDP peer?
import-source policies.
Is the fault
rectified?
Does the
current MSDP peer
receive multicast data
from the multicast
source?
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Yes
No
No
No
No
No
No
No
No
No
90

NOTE
is pressed.
Procedure
Step 1 Check whether the status of the 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 the 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 the MSDP peers can ping each other.
l If the MSDP peers are both in the Up state, go to Step 2.
Step 2 Check whether SA cache is enabled.
Run the display this command on the MSDP peers to view their current configurations in the
MSDP view.
l If the command output contains cache-sa-disable, SA cache is disabled in the MSDP view.
In this case, run the undo cache-sa-disable command in the MSDP view to enable SA
cache.
l If SA cache is enabled, go to Step 3.
Step 3 Check whether any SA messages have reached the MSDP peers.
Run the display msdp sa-count command on the MSDP peers to check the contents of the SA
cache.
l If no information is displayed, run the display msdp peer-status command to check
whether the Count of RPF check failure field value is 0.
If the field value is not 0, check whether the RPF routes are configured correctly.
If the field value is 0, check the Incoming/outgoing SA messages field value to see
whether any received SA messages exist.
If no SA message is received, check whether the mesh group is configured correctly.
If received SA messages exist, go to Step 5.
l If the value of the Number of source or Number of group field in the command output
is non-zero, the SA messages have reached the peers. Go to Step 4.
91
Step 4 Check whether any export policies are configured on the MSDP peers.
MSDP view.
l If export policies are configured on the MSDP peers, perform the following:
If the command output contains the configurations of the peer peer-address sa-policy
export without any parameters, the MSDP peers are prevented from forwarding the
messages received from the multicast source. In this case, run the undo peer peer-
address sa-policy export command to delete the configurations of the export policies.
export acl advanced-acl-number or the peer peer-address sa-policy export acl acl-
name with an ACL specified, the MSDP peers can forward only the (S, G) entries
permitted by the ACL. Check whether the ACL-related commands are running on the
MSDP peers and the (S, G) entries are permitted by the ACL. You can run the undo
peer peer-address sa-policy export command to delete the ACL configurations or
change the ACL rule configurations.
l If no export policies are configured on the MSDP peers, go to Step 5.
Step 5 Check whether any import policies are configured on the MSDP peers.
MSDP view.
l If import policies are configured on the MSDP peers, perform the following:
import without any parameters, the MSDP peers are prevented from receiving messages
from the multicast source. In this case, run the undo peer peer-address sa-policy
import command to delete the configurations of the export policies.
import acl advanced-acl-number with an ACL specified, the MSDP peers can receive
only the (S, G) entries permitted by the ACL. Check whether the ACL-related
commands are running on the MSDP peers and the (S, G) entries are permitted by the
ACL. You can run the undo peer peer-address sa-policy import command to delete
the ACL configurations or change the ACL rule configurations.
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 is without 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.
92
Step 8 Check whether any 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 information about multicast sources. By default, SA
messages can be used to advertise information about all known multicast sources.
Run the display this command on the MSDP peer closest to the multicast source to view the
current configurations in the MSDP view.
l If import-source policies are configured on the MSDP peer, do as follows:
If the command output contains the configurations of the import-source without any
parameters, the MSDP peer is prevented from advertising multicast source information.
Run the undo import-source command to delete the configurations of these import-
source policies.
If the command output contains the import-source acl acl-number with an ACL
specified, the MSDP peer advertises only (S, G) information that matches the ACL.
Check whether any ACL-related commands are running on the MSDP peer and the (S,
G) entries are permitted by the ACL. Run the undo import-source command to delete
the ACL configurations or change the ACL rule configurations.
l If no import-source policies are configured on the MSDP peer, go to Step 9.
Step 9 If the fault persists after this troubleshooting procedures, contact Huawei.
----End
Relevant Alarms
None
Relevant Log
None
8.4 QoS
8.4.1 Priority Mapping Troubleshooting
This chapter describes common causes of priority mapping faults, and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
8.4.1.1 Packets Enter Incorrect Queues
procedure to use when packets enter incorrect queues.
93
l The priority mapping configured in the DiffServ domain of the inbound interface is
incorrect.
l There are configurations affecting the queues that packets enter on the inbound interface.
l There are configurations affecting the queues that packets enter in the VLAN that packets
belong to.
l There are configurations affecting the queues that packets enter in the system.
94
Figure 8-16 Troubleshooting flowchart for packets entering incorrect queues
No
Packets enter incorrect
queues
Is priority mapping
correct?
Correctly
configure
priority
mapping
Is fault rectified?
Are there
configurations affecting packet
enqueuing on inbound
interface?
Are there
configurations affecting
packet enqueuing in the
VLAN?
Yes Delete or
modify
settings
Is fault rectified?
Yes Delete or
modify
settings
Is fault rectified?
Are there
configurations affecting
packet enqueuing in the
system?
Yes Delete or
modify
settings
Is fault rectified?
End
Yes
No
No
Yes
Yes
Yes
Yes
No
No
No
No
No

95
Context
NOTE
is pressed.
Procedure
Step 1 Check that the priority mapping configured in the DiffServ domain of the inbound interface is
correct.
Run the display this command in the interface view in the inbound direction and check the
configuration of the trust upstream command. If the trust upstream command is not used, the
system trusts the DiffServ domain default by default. Then, run the display diffserv domain
ds-domain-name command to check whether the priority mapping configured in the DiffServ
domain is correct.
l If not, run the ip-dscp-inbound or 8021p-inbound command to correctly configure priority
mapping.
l If so, go to step 2.
Step 2 Check whether there are configurations affecting the queues that packets enter on the inbound
interface.
The following configurations affect the queues that packets enter on the inbound interface:
l If the traffic-policy command that defines remark local-precedence is used, the system
sends packets to queues based on the re-marked local priorities.
l If the trust upstream none command is used, priorities of incoming packets are not mapped
and all the packets enter queues based on the default priority of the interface.
l If the port link-type dot1q-tunnel command is used but the trust 8021p inner command
is not used on the interface, all the incoming packets enter queues based on the default priority
of the interface.
Run the display this command in the inbound interface view to check whether there are
configurations affecting packet enqueuing on the inbound interface.
l If so, delete or modify the configuration.
l If not, go to step b.
Step 3 Check whether there are configurations affecting the queues that packets enter in the VLAN that
packets belong to.
The following configurations affect the queues that packets enter:
l If the traffic-policy command that defines remark local-precedence is used, the system
sends packets to queues based on the re-marked local priorities.
96
l If the traffic-policy command that defines remark 8021p is used, the system maps the re-
marked priorities of packets to PHBs and sends the packets to queues based on the PHBs.
Run the display this command in the view of the VLAN that packets belong to and check whether
the configurations affecting packet enqueuing are performed in the VLAN.
l If not, go to step 4.
Step 4 Check whether there are configurations affecting the queues that packets enter in the system.
l If the qos local-precedence-queue-map command is used, the system sends packets to
queues based on the mapping between PHBs and queues specified by this command.
l If the traffic-policy global command that defines remark local-precedence is used, the
system sends packets to queues based on the re-marked local priorities.
l If the traffic-policy global command that defines remark 8021p is used, the system maps
the re-marked priorities of packets to PHBs and sends the packets to queues based on the
PHBs.
Run the display current-configuration command to check whether the configurations affecting
the packets enqueuing are performed in the system.
Step 5 Collect the following information and contact Huawei technical support personnel:
l Configuration file, logs, and alarms of the device
----End
Relevant Alarms
None.
Relevant Logs
None.
8.4.1.2 Priority Mapping Results Are Incorrect
procedure to use when priority mapping results are incorrect.
l On the inbound interface, packets do not enter queues corresponding to the priority of
packets.
97
l The type of the priority trusted by the inbound or outbound interface is incorrect.
l The priority mapping configured in the DiffServ domain trusted by the inbound or outbound
interface is incorrect.
l There are configurations affecting priority mapping on the inbound or outbound interface.
Figure 8-17 Troubleshooting flowchart for incorrect priority mapping
No
Priority mapping results are
incorrect
Do packets enter
correct queues?
See Packets
Enter Incorrect
Queues
Is fault rectified?
Is priority
type trusted by inbound or
outbound interface
correct?
No
Correctly configure
the priority
type trusted by
inbound or
outbound interface
Is fault rectified?
Are there
settings affecting priority
mapping on inbound/outbound
interface?
Yes
Delete or modify
settings
Is fault rectified?
End
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Are there settings
affecting priority mapping in
the VLAN?
Yes
Delete or modify
settings
Is fault rectified?
Yes
No
No

98
Context
NOTE
is pressed.
Procedure
Step 1 Check whether packets enter correct queues on the outbound interface.
Run the display qos queue statistics interface interface-type interface-number command to
view queue statistics on the outbound interface.
l If packets enter incorrect queues, locate the fault according to 8.4.1.1 Packets Enter
Incorrect Queues.
l If packets enter correct queues, go to step 2.
Step 2 Check whether the priority type trusted by the inbound or outbound interface is correct.
Run the display this command in the view of the inbound or outbound interface to check whether
the trusted priority type set by using the trust command on the inbound or outbound interface
is correct. (If the trust command is not used, the system trusts the 802.1p priority in the outer
VLAN tag by default.)
l If not, run the trust command to correctly configure the priority type trusted by the inbound/
outbound interface.
Step 3 Check whether there are configurations affecting priority mapping on the inbound or outbound
interface.
l If the undo qos phb marking enable command is used, the system does not perform PHB
mapping for outgoing packets on an interface.
l If the trust upstream none command is used, the system does not perform PHB mapping
for outgoing packets on an interface.
l If the traffic-policy command that defines remark 8021p or remark dscp is used in the
inbound or outbound direction, the re-marked priority is the packet priority.
Run the display this command in the view of the inbound or outbound interface to check whether
the configurations affecting priority mapping are performed on the inbound or outbound
interface.
99
Step 4 Check whether there are configurations affecting priority mapping in the VLAN that packets
belong to.
If the traffic-policy command that defines remark 8021p or remark dscp is used, the system
maps the re-marked priorities of packets to the local priorities and sends the packets to queues
based on the mapped local priorities.
Run the display this command in the view of the VLAN that packets belong to and check whether
the configurations affecting packet enqueuing are performed in the VLAN.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.4.2 Traffic Policing Troubleshooting
This chapter describes common causes of traffic policing faults, and provides the corresponding
8.4.2.1 Interface-based Traffic Policing Results Are Incorrect
procedure to use when interface-based traffic policing results are incorrect.
l The qos car inbound command is not used on the interface.
l CAR parameters are configured incorrectly.
100
Figure 8-18 Troubleshooting flowchart for incorrect interface-based traffic policing results
No
Interface-based
traffic policing rate is
incorrect
Is interface-based
traffic policing set on
interface?
Correctly
configure
interface-
based
traffic
policing
Is fault rectified?
Are CAR parameters
correct?
No Correctly set
CAR
parameters
Is fault rectified?
End
Yes
Yes
Yes
Yes
No
No

Context
NOTE
is pressed.
Procedure
Step 1 Check whether interface-based traffic policing is configured on the interface.
Run the display this command in the interface view to check whether the qos car inbound
command is used.
l If not, run the qos car inbound command to configure the QoS CAR correctly.
101
Step 2 Check whether the CAR parameters are set correctly.
Run the display qos car command to check whether the CAR parameters are correct.
l If not, run the qos car inbound command to set the CAR parameters correctly.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.4.3 Traffic Shaping Troubleshooting
This chapter describes common causes of traffic shaping faults, and provides the corresponding
8.4.3.1 Traffic Shaping Results of Queues Are Incorrect
procedure to use when traffic shaping results of queues are incorrect.
The fault symptom may be any of the following:
l Traffic shaping does not take effect.
l The CIR value for traffic shaping in queues cannot be reached.
l Traffic shaping parameters are set incorrectly.
l The CIR value for traffic shaping on an interface is smaller than the sum of CIR values for
traffic shaping in queues on the interface. As a result, the bandwidth of traffic shaping in
queues cannot be ensured.
l Packets do not enter queues configured with traffic shaping because the configuration is
incorrect. For example, priority mapping is incorrect.
l Each queue uses the combined scheduling mode and excess packets enter Priority Queuing
(PQ) queues. As a result, other queues cannot obtain sufficient bandwidth.
102
103
Figure 8-19 Troubleshooting flowchart for incorrect traffic shaping results
No
Queue-based traffic shaping
results are incorrect
Are shaping
parameters correct?
Is fault
rectified?
Is interface-based
traffic shaping configured?
Is CIR for
interface-based traffic shaping
greater than sum of CIR values
for queues?
No
Ensure that CIR
for interface-
based traffic
shaping greater
than sum of
CIR values for
queues
Is traffic policing affecting
queue shaping configured?
Yes
Modify or
delete traffic
policing
configuration
End
Yes
Yes
Yes
No
No
No
Do packets
enter shaping queues?
Yes
See Packets
Enter
Incorrect
Queues
Yes
Do
queues use
combined scheduling
mode?
Yes
Reconfigure
scheduling
modes and
weights
No
No
No
Do PQ
queues have
excess
packets?
Yes
Is fault
rectified?
Is fault
rectified?
Is fault
rectified?
No
No
Is fault
rectified?
Yes
Yes
Yes
No
Correctly set
shaping
parameters
104

Context
NOTE
is pressed.
Procedure
Step 1 Check whether traffic shaping parameters of queues are set correctly.
Run the display this command in the interface view to check whether the qos queue shaping
command is used.
l If traffic shaping parameters of queues are set incorrectly or not set, run the qos queue
shaping command to set the parameters correctly.
l If traffic shaping parameters of queues are set and the CIR value for traffic shaping on an
interface is set by using the qos lr outbound command, go to step 2.
l If traffic shaping parameters of queues are set but the CIR value for traffic shaping on an
interface is not set, go to step 3.
Step 2 Check whether the CIR value for traffic shaping on an interface is greater than the sum of CIR
values for traffic shaping in queues on the interface.
Compare the CIR value for interface-based traffic shaping with the sum of CIR values of traffic
shaping in queues on the interface:
l If the CIR value of traffic shaping on an interface is smaller than the sum of CIR values of
traffic shaping in queues on the interface, the bandwidth required by queues on the interface
cannot be guaranteed. The traffic shaping result may be incorrect. In this case, run the qos
lr outbound and qos queue shaping commands to modify related parameters so that the
CIR value of traffic shaping on an interface is greater than the sum of CIR values of traffic
shaping in queues on the interface.
l If the CIR value for traffic shaping on an interface is greater than the sum of CIR values for
traffic shaping in queues on the interface, go to step 3.
Step 3 Check whether traffic policing affecting queue shaping is configured.
1. Check whether interface-based traffic policing is configured on the inbound interface.
If interface-based traffic policing is configured on the inbound interface and its CIR value
is smaller than the specified CIR value for queue shaping, queue shaping uses the CIR value
for interface-based traffic policing.
105
Run the display this command in the inbound interface view to check whether the qos car
inbound command is run on the inbound interface and whether its CIR value is smaller
than the CIR value for queue shaping.
l If the qos car inbound command is used and the CIR value is smaller than the CIR
value for queue shaping, disable interface-based traffic policing or modify the
configuration so that the CIR value for interface-based traffic policing is greater than
the CIR value for queue shaping.
l If the qos lr inbound command is not run or this command is run but the CIR value of
the inbound interface is greater than the CIR value for queue shaping, go to step b.
2. Check whether class-based traffic policing is configured on the device.
If class-based traffic policing is configured on the device, its CIR value is smaller than the
CIR for queue shaping, and traffic in queues matches the traffic classifier, the CIR for class-
based traffic policing is used as the actual CIR value of queue shaping.
Run the display this command in the system view, inbound interface view, and VLAN
view to check whether the traffic-policy command is used:
l If the traffic-policy command is run, run the display traffic policy command to check
whether a CIR value is defined in the traffic policy and whether the CIR value is smaller
than the CIR value for queue shaping.
If the CIR value is set, run the display traffic policy command to check whether
traffic in queues matches the traffic classifier in the configured traffic policy. If
traffic in queues matches the traffic classifier, delete the CIR value defined in the
traffic policy or modify the configuration so that the CIR value in the traffic policy
is greater than the CIR value for queue shaping. If traffic in queues does not match
the traffic classifier, go to step 4.
If no CIR value is set, go to step 4.
l If the traffic-policy command is not run, go to step 4.
Step 4 Check whether packets enter traffic shaping queues.
Run the display qos queue statistics interface interface-type interface-number command to
view the packet statistics on each queue on the interface.
l If packets do not enter traffic shaping queues, locate the fault according to 8.4.1.1 Packets
Enter Incorrect Queues.
l If packets enter traffic shaping queues and many packets enter PQ queues, go to step 5.
l If packets enter traffic shaping queues and many packets do not enter PQ queues, go to step
6.
Step 5 Check whether queues on the interface use the combined scheduling mode.
Run the display this command in the interface view to check the scheduling mode used by each
queue on the interface.
l If qos pq and qos wrr or qos drr are configured in each queue, the queue uses the combined
scheduling mode.
In combined scheduling mode, if no bandwidth limit is configured for PQ queues, traffic
shaping of WRR or DRR queues is affected when PQ queues contain a large number of
packets. This is because queue shaping is configured on WRR or DRR queues. Run the
qos { pq | drr | wrr }, qos queue queue-index wrr weight weight, or qos queue queue-
106
index drr weight weight command to reconfigure the scheduling mode and parameters of
each queue, reducing packets entering PQ queues.
l If each queue uses the scheduling mode of qos pq or qos wrr/drr, go to step 6.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.4.4 Congestion Avoidance Troubleshooting
This chapter describes common causes of congestion avoidance faults, and provides the
8.4.4.1 Congestion Avoidance Fails to Take Effect
procedure to use when congestion avoidance fails to take effect.
l The interface or queue is not configured with the Weighted Random Early Detection
(WRED) drop profile.
l Packets are not colored by using priority mapping, CAR, or remark local-precedence.
l The parameters corresponding to packet colors are not configured in the WRED drop
profile.
l Packets do not enter the queue configured with the WRED drop profile.
107
Figure 8-20 Troubleshooting flowchart for ineffective congestion avoidance
No
Congestion avoidance fails
to take effect
Is WRED drop profile
configured?
Configure WRED
drop profile on an
interface or in a
queue
Is fault rectified?
Are WRED
parameters correct?
No
Correctly set
WRED parameters
Is fault rectified?
Is WRED used for
an interface or a queue?
Queue
End
Yes
Yes
Yes
Yes
Yes
No
No
Interface
Are packets colored?
Yes
Color packets
using priority
mapping, CAR,
or the remark
local-
precedence
command
Is fault rectified?
Yes
No
No
Do packets
enter WRED
queues?
See Packets Enter
Incorrect Queues
Yes
Is fault rectified?
No
No

108
Context
NOTE
is pressed.
Procedure
Step 1 Check whether the WRED drop profile is configured on an interface or in a queue on the
interface.
Run the display this command in the interface view to check whether the qos wred or qos queue
wred command is used.
l If not, run the qos wred command to configure a WRED drop profile on the interface or run
the qos queue wred command to configure a WRED drop profile in a queue.
Step 2 Check whether parameters are set correctly in the WRED drop profile.
Run the display drop-profile command to check whether parameters are set correctly in the
WRED drop profile.
l If parameters are not set, run the color command to set parameters.
l If parameters are set and the qos queue wred command is used on the interface, go to step
3.
l If parameters are set and the qos wred command is used on the interface, go to step 4.
Step 3 Check whether packets enter the queue configured with the WRED drop profile.
Run the display qos queue statistics command to check whether there are packet statistics about
the queue configured with the WRED drop profile.
l If there are packet statistics about the queue configured with the WRED drop profile, go to
step 4.
l If there are no packet statistics about the queue configured with the WRED drop profile,
packets do not enter the queue configured with the WRED drop profile. Locate the fault
according to 8.4.1.1 Packets Enter Incorrect Queues.
Step 4 Check whether packets are colored by using priority mapping or a traffic action.
Run the display this command in the interface view to check whether the following
configurations are performed on the interface.
1. Check whether the traffic-policy command is used on the interface.
109
l If the traffic-policy command is used, run the display traffic policy command to view
the actions in the traffic policy. Check whether car with service-class specified or
remark local-precedence is configured.
If car is configured but service-class is not specified, run the car command with
service-class specified in the traffic behavior view.
If remark local-precedence is configured but color is not specified, run the remark
local-precedence command with color specified.
If car or remark local-precedence is configured and relevant coloring parameters
are configured, the system colors packets according to the configuration. Go to step
5.
If the action and relevant parameters are not configured, go to step b.
2. Check whether the dei enable command is used on the interface.
l If so, verify that the system correctly marks packets with colors based on the CFI field
(if the CFI field is 1, packets are colored yellow; if the CFI field is 0, packets are colored
green). Then, go to step 5.
l If not, go to step c.
3. Check whether the trust upstream command is used on the interface.
If the trust upstream command is used on the interface, the system colors packets
according to the mapping from packet priorities to colors in the DiffServ domain. If the
trust upstream command is not used on the interface, the system trusts the DiffServ
domain default by default, and colors packets according to the mapping from packet
priorities to colors in the DiffServ domain default. Run the display diffserv domain ds-
domain-name command to check whether the mapping from packet priorities to colors is
correct.
l If the mapping is incorrect, run the 8021p-inbound or ip-dscp-inbound command to
modify the mapping from packet priorities to colors.
l If the mapping is correct, go to step 5.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.4.5 Congestion Management Troubleshooting
This chapter describes common causes of congestion management faults, and provides the
110
8.4.5.1 Congestion Management Fails to Take Effect
procedure to use when congestion management fails to take effect.
l The queue scheduling mode is configured incorrectly.
l The weight ratio in WRR or DRR queues is larger than 62:1 (CE5800).
l Packets enter incorrect queues.
If packets in a queue are not scheduled or scheduling results are incorrect, congestion
management fails to take effect. Follow procedures shown in the troubleshooting flowchart in
Figure 8-21 or Figure 8-22.
Figure 8-21 Troubleshooting flowchart for ineffective congestion management (CE5800)
No
Congestion management
fails to take effect
Is queue scheduling
mode correct?
Correctly set
queue
scheduling
mode
Is fault rectified?
Is weight ratio in
WRR or DRR queues larger
than 62:1?
No
Change the
weight ratio to
be smaller
than 62:1
Is fault rectified?
End
Yes
Yes
Yes
Yes
Yes
No
No
Do packets enter
correct queues?
Is fault rectified?
No
See Packets
Enter
Incorrect
Queues
No
Yes

111
Figure 8-22 Troubleshooting flowchart for ineffective congestion management (CE6800)
No
Congestion management
fails to take effect
Is queue scheduling
mode correct?
Correctly set
queue
scheduling
mode
Is fault rectified?
End
Yes
Yes
Yes
No
Do packets enter
correct queues?
Is fault rectified?
No
See
Packets
Enter
Incorrect
Queues
No
Yes

Context
NOTE
is pressed.
Procedure
Step 1 Check whether the queue scheduling mode is configured correctly.
Run the display this command in the interface view to check whether the queue scheduling
mode is correct.
112
NOTE
When you configure the queue scheduling mode, pay attention to the following points:
l The combined scheduling mode of PQ+WRR or PQ+DRR is recommended. The delay-sensitive core
services are scheduled in PQ mode and other services are scheduled in WRR or DRR mode.
l If each queue is configured with PQ scheduling, delay-sensitive core services are put in high-priority queues
and non-core services are put in low-priority queues.
l If each queue is configured with WRR or DRR scheduling, key services are assigned higher weights and
non-key services are assigned lower weights.
l If the average length of different types of packets varies slightly, WRR scheduling is used; if such an average
length differs a lot, DRR scheduling is used.
l If the queue scheduling mode is incorrect, run the qos { pq | wrr | drr } command to
reconfigure the queue scheduling mode.
l If the queue scheduling mode is correct, go to step 2.
Step 2 Check whether the weight ratio in WRR or DRR queues is overlarge (CE5800).
Run the display this command in the interface view to check whether the weight ratio is greater
than 62:1 in WRR or DRR scheduling.
l If the weight ratio is greater than 62:1, run the qos queue queue-index drr weight weight or
qos queue queue-index wrr weight weight command to change the queue weights. Ensure
that the weight ratio between any two queues is smaller than 62:1.
l If the weight ratio is not greater than 62:1, go to step 3.
Step 3 Check whether packets enter correct queues.
Use the tester to send different types of packets to the device and run the display qos queue
statistics command to view statistics on queues. Check whether packets enter queues
corresponding to the scheduling mode in step 1.
l If packets enter incorrect queues, locate the fault according to 8.4.1.1 Packets Enter
Incorrect Queues.
l If packets enter correct queues, go to step 4.
----End
Relevant Alarms
None.
Relevant Logs
None.
8.5 Device Management
113
8.5.1 Stacking Troubleshooting
This section describes common causes of Stacking faults, and provides the corresponding
8.5.1.1 A Stack Failed to Be Set Up
This fault is commonly caused by the following:
l Stack cable faults occur. For example, stack cables are not properly connected or the optical
module is in bad contact.
l Different stack domains are configured for member devices.
l Physical member interfaces are not in Up state.
Rectify the fault according to Figure 8-23.
114
Figure 8-23 Troubleshooting flowchart for the failure to set up a stack
A stack cannot
be set up
Seek technical
support
End
Are stack cables
connected properly?
Connect stack
cables properly
Yes
No
Is fault rectified?
Configure the
same domain ID
Is fault rectified?
Yes
No
No
Yes
Yes
No
Rectify the
interface fault
Is fault rectified?
Yes
No Yes
No
Do
member devices
have the same
domain ID?
Are physical member
interfaces Up?
Configure stack
ports
Is fault rectified?
Yes
No Yes
No
Are stack ports
configured?
NOTE
is pressed.
115
Procedure
Step 1 Check whether stack cables are correctly connected.
l If stack cables are not correctly connected, connect them correctly.
l If stack cables are correctly connected, go to step 2.
Step 2 Check whether member switches have the same domain ID.
Run the display stack configuration command to check whether member switches have the
same domain ID.
l If member switches have different domain IDs, run the stack [ member { member-id | all } ]
domain domain-id command to configure the same domain ID for the member switches.
l If member switches have the same domain ID, go to step 3.
Step 3 Check whether a logical stack port is configured.
Run the display interface brief command to check whether a logical stack port is available and
whether physical member ports have been added to the logical stack port.
l If no logical stack port is configured, configure a logical stack port and add physical member
ports to it.
l If the logical stack port has been configured, go to step 4.
Step 4 Check whether physical member ports are in Up state.
Run the display interface brief command to check whether physical member ports are in Up
state.
l If any physical member port is Down, rectify the fault according to 6.4 Interface
Troubleshooting.
l If physical member ports are Up, go to step 5.
----End
Relevant Alarms
None
Relevant Logs
None
8.5.1.2 Active/Standby Switchover Cannot Be Performed in a Stack
116
This fault is commonly caused by the following:
l Batch backup is not completed between the master and standby devices in the stack.
None
NOTE
is pressed.
Procedure
Step 1 Check whether batch backup has been completed between the master and standby devices.
Run the display switchover state command to check the backup status of the master and standby
devices.
<HUAWEI> display switchover state
Switchover State : No slave
Switchover Policy : Board Switchover
MainBoard : 1
SlaveBoard : NULL
The system meets conditions for performing an active/standby switchover only when the
Switchover State field displays Ready.
l If batch backup is not completed, wait a period until batch backup is completed and then
perform an active/standby switchover.
l If batch backup has been completed but the active/standby switchover still cannot be
performed, go to step 2.
----End
Relevant Alarms
None
117
Relevant Logs
None
8.6 TRILL
This chapter describes common causes of TRILL faults and provides the corresponding
8.6.1 TRILL Neighbor Relationship Fails to Be Established
This section provides a troubleshooting flowchart and a detailed procedure to troubleshoot the
failure in establishing a TRILL neighbor relationship on a data center network.
l TRILL cannot receive Hello packets due to a lower layer or link failure.
l No carrier VLAN is configured or the configured carrier VLANs at the two ends of the link
are different.
l The types of the TRILL interfaces at the two ends of the link are different. Neighbor
relationships cannot be established between P2P and non-P2P interfaces.
l The authentication configurations at the two ends of the link are different.
l The designated VLANs of the TRILL interfaces at the two ends of the link are different.
118
Figure 8-24 Troubleshooting flowchart for the failure in establishing a TRILL neighbor
relationship
A TRILL neighbor relationship
fails to be established.
Check whether the TRILL
interface is Up.
Check whether
the carrier VLANs at the two ends
of the link are the same.
Check whether
the types of the TRILL interfaces at
the two ends of the link are the
same.
Contact Huawei technical
support personnel.
Modify either carrier VLAN so
that the carrier VLANs at the
two ends are the same.
END
Yes
Yes
Yes
No
No
Yes
Yes
Yes
No
No
Check whether
the authentication configurations at
the two ends of the link are the
same.
Yes
Make sure that the interface
is Up.
Is the fault
rectified?
No
Is the fault
rectified?
Modify the type of either
interface so that the types of
the interfaces at the two ends
are the same.
No
Is the fault
rectified?
Check whether
designated VLANs of the TRILL
interfaces at the two ends of the link
are the same.
Yes
Yes Make sure that Authentication
configurations at the two
ends of the link are the same.
No
Is the fault
rectified?
Yes
Modify either designated
VLAN so that designated
VLANs at the two ends of the
link are the same.
No
Is the fault
rectified?
Check whether
TRILL receives and sends Hello
packets properly.
Make sure TRILL receives
and sends Hello packets
properly.
No Yes
Is the fault
rectified?
No
No
No
Yes

119
NOTE
is pressed.
Procedure
Step 1 Check the TRILL interface state.
Run the display trill interface [ interface-type interface-number ] command to check State of
the TRILL interface.
l If Mtu:Up/Lnk:Dn is displayed, go to Step 2.
l If Mtu:Dn/Lnk:Up is displayed, go to Step 2.
l If Mtu:Up/Lnk:Up is displayed, run the display trill interface verbose command to check
Circuit State of the interface.
If Down (CarrierVlan:Dn / Bandwidth:UP / TrillEnable:UP / MAC:Up) is
displayed, run the display current-configuration configuration trill command to
check whether a carrier VLAN is configured. If no carrier VLAN is configured,
configure one and run the display trill interface verbose command to check whether
Circuit State is Up. If Circuit State is not Up, go to Step 8.
If Down (CarrierVlan:UP / Bandwidth:Dn / TrillEnable:UP / MAC:Up) is
displayed, go to Step 2.
If Down (CarrierVlan:UP / Bandwidth:Up / TrillEnable:Dn / MAC:Up) is
displayed, check whether TRILL is enabled on the interface. If TRILL is not enabled
on the interface, run the trill enable command to enable it. If TRILL is enabled, go to
Step 8.
If Down (CarrierVlan:UP / Bandwidth:Up / TrillEnable:Up / MAC:Dn) is
displayed, go to Step 2.
l If UP is displayed, go to Step 3.
Step 2 Check whether the interface is Up physically.
Run the display interface [ interface-type [ interface-number ] ] command to check the interface
state.
l If Line protocol current state is not Up, diagnose the fault so that it is Up. For details
about how to troubleshoot the link fault, see "Physical Interconnection and interface
protocol Troubleshooting".
l If UP is displayed, go to Step 3.
Step 3 Check whether TRILL receives and sends Hello packets properly.
Run the display trill statistics packet [ interface interface-type interface-number ] command
to check whether TRILL receives and sends Hello packets properly.
120
NOTE
By default, Hello packets are sent at an interval of 10s. Run the command each 10s and check whether the
packet statistics increase.
l If the statistics about received and sent packets remain unchanged, check whether there are
discarded TRILL packets. Run the debugging trill adjacency [ interface interface-type
interface-number ] command to check whether the interface receives and sends packets
properly.
If TRILL-ADJ: Sending Lan Level-1 IIH. (IfName=XXXX, LocalSnpa=XXXX) is
displayed, the interface sends packets properly. If TRILL-ADJ: Sending Lan Level-1
IIH. (IfName=XXXX, LocalSnpa=XXXX) is not displayed, go to Step 8.
If TRILL-ADJ: Received Lan Level-1 IIH. (IfName=XXXX,
RemoteSnpa=XXXX) is displayed, the interface receives packets properly. If TRILL-
ADJ: Received Lan Level-1 IIH. (IfName=XXXX, RemoteSnpa=XXXX) is not
displayed, go to Step 8..
l If the interface receives Hello packets properly, go to Step 4.
Step 4 Check whether the carrier VLANs at the two ends of the link are the same.
Run the display current-configuration configuration trill command at both ends to check
whether the carrier VLANs at the two ends are the same.
l If the carrier VLANs at the two ends are different, run the carrier-vlan carrier-vlanid
command to modify either carrier VLAN so that the carrier VLANs at the two ends are the
same.
l If the carrier VLANs at the two ends are the same, go to Step 5.
Step 5 Check whether the types of the TRILL interfaces at the two ends of the link are the same.
Run the display trill interface [ interface-type interface-number ] command at both ends to
check whether Port Type values at the two ends are the same.
NOTE
If access, hybrid, or trunk is displayed at one end and P2P is displayed at the other end, the neighbor relationship
cannot be established. A TRILL neighbor relationship can be established only when the interfaces at the two
ends are both P2P or non-P2P interfaces.
l If the types of the interfaces at the two ends are different, run the trill enable port-mode
{ access | hybrid | P2P | trunk } command to modify the type of either interface so that
the types of the interfaces at the two ends are the same.
l If the types of the interfaces at the two ends are the same, go to Step 6.
Step 6 Check whether the authentication configurations at the two ends of the link are the same.
Run the display current-configuration interface interface-type interface-number | include
"trill authentication-mode" command on each end to check the authentication configurations.
l If the authentication modes at the two ends are different, run the trill authentication-
mode command in the TRILL interface view to modify the authentication mode of either
end so that the authentication modes at the two ends are the same.
l If the authentication passwords at the two ends are different, run the trill authentication-
mode command in the TRILL interface view to modify the authentication password of
either end so that the authentication passwords at the two ends are the same.
l If the authentication configurations at the two ends of the link are the same, go to Step 7.
121
Step 7 Check whether designated VLANs of the TRILL interfaces at the two ends of the link are the
same.
Run the display trill interface [ interface-type interface-number ] command to check the
designated VLAN of the interface at each end. If the types of interfaces at the two ends are both
P2P, the designated VLANs at the two ends must be the same. If the types of interfaces at the
two ends are not P2P, the designated VLAN of the DRB must be configured as a carrier VLAN
at the other end.
l If designated VLANs at the two ends of the link are different, run the trill designated-
vlan vlan-id command to modify either designated VLAN so that designated VLANs at
the two ends of the link are the same.
l If the types of interfaces at the two ends are not P2P and the designated VLAN of the DRB
is not configured as a carrier VLAN at the other end, run the carrier-vlan carrier-vlanid
command in the TRILL view on the other end to configure the designated VLAN of the
DRB as a carrier VLAN.
l If designated VLANs of the TRILL interfaces at the two ends of the link are the same but
the neighbor relationship still cannot be established, go to Step 8.
----End
Relevant Alarms
None
Relevant Logs
None
8.6.2 TRILL Traffic Failed to Be Forwarded
failure in forwarding TRILL traffic on a data center network.
l The TRILL neighbor relationship is not established.
l The authentication configurations at the two ends of the link are different.
l Nicknames conflict on the network.
l The CE VLAN is not configured.
122
l The interface that is added to the CE VLAN is not Up.
l TRILL LSDBs are asynchronous on the network.
Figure 8-25 Troubleshooting flowchart for the failure in forwarding TRILL traffic
TRILL traffic fails to be forwarded.
Check whether
the TRILL neighbor relationship
is established.
Check whether nicknames
conflict on the network.
Check whether
the CE VLAN is configured.
support personnel.
Make sure that there are
no nickname conflicts on
the network.
END
No
Yes
Yes
Yes
No
Yes
Yes
Yes
No
No
Check whether
the interface that is added to
the CE VLAN is Up.
Yes
See TRILL Neighbor
Relationship Fails to Be
Established.
Is the fault
rectified?
No
Is the fault
rectified?
Configure a CE VLAN.
No
Is the fault
rectified?
Check whether
TRILL LSDBs are synchronous
on the network.
Yes
Yes Make sure that the
interface that is added to
the CE VLAN is Up.
No
Is the fault
rectified?
Yes
Reset TRILL.
No
Is the fault
rectified?
Check whether
the authentication
configurations at the two ends
are the same.
Make sure that The
authentication
configurations at the two
ends are the same.
No
Yes
Is the fault
rectified?
No
No
No
Yes

123
NOTE
is pressed.
Procedure
Step 1 Check whether the TRILL neighbor relationship is established.
Run the display trill peer [ interface interface-type interface-number ] [ verbose ] command
to check whether the TRILL neighbor relationship is established.
l If the TRILL neighbor relationship fails to be established, see 8.6.1 TRILL Neighbor
Relationship Fails to Be Established.
l If the TRILL neighbor relationship is established, go to Step 2.
Step 2 Check whether the authentication configurations at the two ends are the same.
Run the display current-configuration configuration trill | include area-authentication-
mode command on each end to check the authentication configurations.
l If the authentication modes at the two ends are different, run the area-authentication-
mode command in the TRILL interface view to modify the authentication mode of either
end so that the authentication modes at the two ends are the same.
l If the authentication passwords at the two ends are different, run the area-authentication-
mode command in the TRILL interface view to modify the authentication password of
either end so that the authentication passwords at the two ends are the same.
l If the authentication configurations at the two ends of the link are the same, go to Step 3.
Step 3 Check whether nicknames conflict on the network.
Run the display trill nickname command to check whether nicknames conflict on the network.
l If nicknames conflict on the network (S/S or S/D is displayed in State), run the
nickname nicknamevalue [ priority priorityvalue ] [ root-priority rootpriorityvalue ]
command in the TRILL view on the device whose nickname has been suppressed to modify
the nickname so that there are no nickname conflicts on the network.
l If there are no nickname conflicts on the network, go to Step 4.
Step 4 Check whether the CE VLAN is configured.
Run the display current-configuration configuration trill | include ce-vlan command to check
whether the CE VLAN is configured.
l If the CE VLAN is not configured, run the ce-vlan { vlan-id1 [ to vlan-id2 ] } & <1-10>
command in the TRILL view to configure it.
124
l If the CE VLAN has been configured, run the display vlan command to check whether the
configured CE VLAN is established, If the configured CE VLAN is not established,run the
vlan command to establish the VLAN.If the configured CE VLAN is already established,
go to Step 5.
Step 5 Check whether the interface that is added to the CE VLAN is Up.
Run the display interface [ interface-type interface-number ] command to check Line protocol
current state of the interface that is added to the CE VLAN.
l If Line protocol current state is not Up, diagnose the fault so that it is Up. For details
about how to troubleshoot the link fault, see "Physical Interconnection and interface
protocol Troubleshooting".
l If the Line protocol current state is Up, go to Step 6.
Step 6 Check whether TRILL LSDBs are synchronous on the network.
Run the display trill lsdb command on each device to check whether TRILL LSDBs are
synchronous on the network.
l If TRILL LSDBs are asynchronous on the network, run the reset trill all command to reset
TRILL.
l If TRILL LSDBs are synchronous on the network, go to Step 7.
----End
Relevant Alarms
None
Relevant Logs
None
8.6.3 TRILL In-band NMS Fails to Manage RBs
This section provides a troubleshooting flowchart and a detailed procedure to troubleshoot why
a TRILL in-band NMS fails to manage RBs on a data center network.
l No administrative VLAN is configured.
l The administrative VLANs configured at the two ends are different.
125
l TRILL traffic fails to be forwarded.
Figure 8-26 Troubleshooting flowchart for a TRILL in-band NMS' failure to manage RBs
A TRILL in-band NMS fails
to manage RBs.
Check whether an
administrative VLAN is
configured.
Check whether
TRILL traffic is forwarded
properly.
support personnel.
See TRILL Traffic
Fails to Be Forwarded.
END
Yes
Yes
No
No
Yes
Yes
No
Configure an
Administrative VLAN.
If the fault
rectified?
No
If the fault
rectified?
Yes
Modify the administrative
VLAN so that the
administrative VLANs
configured at the two
ends are the same.
No
Yes
If the fault
rectified?
No
Check whether
the administrative VLANs
configured at the two ends
are the same.

NOTE
is pressed.
126
Procedure
Step 1 Check whether an administrative VLAN is configured.
Run the display current-configuration configuration trill | include admin-vlan command to
check whether an administrative VLAN is configured.
l If no administrative VLAN is configured, run the admin-vlan vlan-id command to
configure it.
l If an administrative VLAN has been configured, run the display vlan command to check
whether the configured administrative VLAN is established, If the configured
administrative VLAN is not established,run the vlan command to establish the VLAN.If
the configured administrative VLAN is already established, go to Step 2.
Step 2 Check whether the administrative VLANs configured at the two ends are the same.
l If the administrative VLANs configured at the two ends are different, run the admin-
vlan vlan-id command on either end to modify the administrative VLAN so that the
administrative VLANs configured at the two ends are the same.
l If the administrative VLANs configured at the two ends are the same, go to Step 3.
Step 3 Check whether TRILL traffic is forwarded properly.
Run the display trill route [ nickname ] command or the display trill mroute [ vlan-id ]
command to check whether there are TRILL routes to the other end.
l If there are no TRILL routes to the other end, see 8.6.2 TRILL Traffic Failed to Be
Forwarded.
l If there are TRILL routes to the other end, go to Step 4.
----End
Relevant Alarms
None
Relevant Logs
None
8.6.4 TRILL Fails to Be Enabled on an Interface
failure in enabling TRILL on an interface on a data center network.
127
l The link type of the interface is access.
l The interface is added to a non-TRILL VLAN.
Figure 8-27 Troubleshooting flowchart for the failure in enabling TRILL on an interface
TRILL fails to be enabled
on an interface.
support personnel.
END
No
No
No
Yes
Make sure that the
interface types at the
two ends are both
P2P or non-P2P.
Is the fault
rectified?
Yes
Check
whether the interface is
added to a non-TRILL
VLAN.
Delete the VLAN.
Yes
Yes
Is the fault
rectified?
No
Check Whether
the interface types at the two
ends are both P2P or
non-P2P.

NOTE
is pressed.
Procedure
Step 1 Check the interface type.
128
Run the display current-configuration configuration trill | include "port link-type"
command to check the interface type.
l If no interface type is displayed, the default access is used. Run the port link-type command
to change the interface type to trunk or hybrid.
l If the interface type is trunk or hybrid, go to Step 2.
Step 2 Check whether the interface is added to a non-TRILL VLAN.
Run the display current-configuration | include interface command to check configurations
on the interface.
l If the interface is added to a non-TRILL VLAN, delete the VLAN.
l If the interface is not added to a non-TRILL VLAN, go to Step 3.
----End
Relevant Alarms
None
Relevant Logs
None
129
9 Common Fault Diagnostic Commands
About This Chapter
The common fault diagnostic commands include display, reset, ping, and tracert commands.
Additionally, alarms, logs, and packet capturing are effective methods to locate faults.
9.1 display Commands
9.2 reset Commands
9.3 Ping and Tracert
This section describes how to use Ping and Tracert commands to check network connectivity
and locate network faults. The Ping command checks network connectivity and host reachability
and the Tracert command tracks the gateways that packets pass through from the source host
to the destination host.
9.4 Traps
9.5 Logs
9.6 Packet Header Capturing Function
Troubleshooting 9 Common Fault Diagnostic Commands
130
9.1 display Commands
Using display commands and understanding command functions are essential skills of
maintenance engineers.
9.1.1 Overview
The display commands provide the following information:
l Current device status
l Neighbor device information
l Overall network information
l Network fault location
The display commands can be executed in any view.
The following is an example of display commands:
<HUAWEI> display ?
aaa AAA(Authentication,Authorization,Accounting)
acl ACL status and configuration information
alarm Failure manager module
als Set automatic laser shutdown
arp Display ARP entries
auto-defend Auto defend
bfd Specify BFD(Bidirectional Forwarding Detection)
bgp BGP information
capture-packet Display capture packet
clock Display the clock status
configuration Configuration file
control-flap Interface flap control status
cpu The state of CPU monitor
cpu-defend Configure CPU defend policy
current-configuration Current configuration
debugging Current setting of debugging switches
default-parameter Display default configuration parameter value
device Device information
---- More ----
NOTE
l After you enter display ?, the system displays all the keywords behind display. More keywords can
be added behind these displayed keywords.
l Different device models or versions support different features. The keywords actually displayed may
be different from the preceding example.
This section involves only commonly used display commands. For more display commands,
see the CloudEngine 6800&5800 Series Switches Command Reference.
9.1.2 Regular Expression in display Commands
Regular Expressions
A regular expression is a mode matching tool. It consists of common characters (such as letters
from a to z) and special characters (called meta-characters). The regular expression is a template
according to which you can search for the required string.
131
A regular expression provides the following functions:
l Searches for and obtains a sub-string that matches a rule in the string.
l Substitutes a string based on a certain matching rule.
The regular expression consists of common characters and special characters.
l Common characters
Common characters are used to match themselves in a string, including all upper-case and
lower-case letters, digits, punctuations, and special symbols. For example, a matches the
letter "a" in "abc", 202 matches the digit "202" in "202.113.25.155", and @ matches the
symbol "@" in "xxx@xxx.com".
l Special characters
Special characters are used together with common characters to match the complex or
special string combination. Table 9-1 describes special characters and their syntax.
Table 9-1 Description of special characters
Special
Characte
rs
Function Example
\ Defines an escape character, which
is used to mark the next character
(common or special) as the common
character.
\* matches "*".
^ Matches the starting position of the
string.
^10 matches "10.10.10.1" instead of
"20.10.10.1".
$ Matches the ending position of the
string.
1$ matches "10.10.10.1" instead of
"10.10.10.2".
* Matches the preceding element zero
or more times.
10* matches "1", "10", "100",
"1000", and so on.
(10)* matches "null", "10", "1010",
"101010", and so on.
+ Matches the preceding element one
or more times.
10+ matches "10", "100", "1000",
and so on.
(10)+ matches "10", "1010",
"101010", and so on.
? Matches the preceding element zero
or one time.
NOTE
Huawei datacom devices do not support
regular expressions with ?. When
regular expressions with ? are entered
on Huawei datacom devices, helpful
information is provided.
10? matches "1" or "10".
(10)? matches "null" or "10".
132
Special
Characte
rs
Function Example
. Matches any single character. 0.0 matches "0x0", "020", and so on.
.oo. matches "book", "look", "tool",
and so on.
() Defines a subexpression, which can
be null. Both the expression and the
subexpression should be matched.
100(200)+ matches "100200",
"100200200", and so on.
x|y Matches x or y. 100|200 matches "100" or "200".
1(2|3)4 matches "124" or "134",
instead of "1234", "14", "1224", and
"1334".
[xyz] Matches any single character in the
regular expression.
[123] matches the character 2 in
"255".
[^xyz] Matches any character that is not in
the regular expression.
[^123] matches any character except
for "1", "2", and "3".
[a-z] Matches any character within the
specified range.
[0-9] matches any character ranging
from 0 to 9.
[^a-z] Matches any character beyond the
specified range.
[^0-9] matches all non-numeric
characters.
_ Matches a comma ",", left brace "{",
right brace "}", left parenthesis "(",
and right parenthesis ")".
Matches the starting position of the
input string.
Matches the ending position of the
input string.
Matches a space.
_2008_ matches "2008", "space
2008 space", "space 2008", "2008
space", ",2008,", "{2008}",
"(2008)", "{2008)", and "(2008}".

NOTE
Unless otherwise specified, all the characters in the preceding table must be printable characters.
l Degeneration of special characters
Certain special characters, when placed at certain positions in a regular expression,
degenerate to common characters.
The special characters following "\" match special characters themselves.
The special characters "*", "+", and "?" are placed at the starting position of the regular
expression. For example, +45 matches "+45" and abc(*def) matches "abc*def".
The special character "^" is placed at any position except for the start of the regular
expression. For example, abc^ matches "abc^".
133
The special character "$" is placed at any position except for the end of the regular
expression. For example, 12$2 matches "12$2".
A right parenthesis ")" or right bracket "]" is not paired with a corresponding left
parenthesis "(" or bracket "[". For example, abc) matches "abc)" and 0-9] matches
"0-9]".
NOTE
Unless otherwise specified, degeneration rules also apply when the preceding regular expressions
are subexpressions within parentheses.
l Combination of common and special characters
In actual usage, regular expressions combine multiple common and special characters to
match certain strings.
Specifying a Filtering Mode in a Command
NOTE
When filtering conditions are set to query output information, the first line of the command output starts
with the entire regular expression but not the string to be filtered.
The system allows you to use | count to display the number of lines, | section to display the
number of sections after using a filtering mode in the command output, and | ignore-case to
matches a string of case-insensitive characters. | count, | section, and | ignore-case can work
together with the following filtering modes.
Three filtering modes are provided for commands that support regular expressions.
l | begin regular-expression: displays all the lines beginning with the line that matches the
regular expression.
Filter the character strings to be entered until the specified case-sensitive character string
is displayed. All the character strings following this specified character string are displayed
on the screen.
l | exclude regular-expression: displays all the lines that do not match the regular expression.
If the character strings to be entered do not contain the specified case-sensitive character
string, they are displayed on the screen. Otherwise, they are filtered.
l | include regular-expression: displays all the lines that match the regular expression.
If the character strings to be entered contain the specified case-sensitive character string,
they are displayed on the screen. Otherwise, they are filtered.
NOTE
The value of regular-expression is a string of 1 to 255 characters.
The command output can be filtered by multiple regular expressions. The regular expressions take effect
in configuration sequence. A maximum of 32 regular expressions can be configured to filter the command
output.
The following examples describe how to specify a filter mode in a command.
Example 1: Run the display interface brief command to display all the lines that do not match
the regular expression 10GE|40GE. 10GE|40GE matches 10GE or 40GE.
<HUAWEI> display interface brief | exclude 10GE|40GE
PHY: Physical
*down: administratively down
^down: standby
134
(l): loopback
(s): spoofing
(b): BFD down
(e): EFM down
(d): Dampening Suppressed
(p): port alarm down
(dl): DLDP down
InUti/OutUti: input utility rate/output utility rate
Interface PHY Protocol InUti OutUti inErrors outErrors
Eth-Trunk2 down down 0% 0% 0 0
Eth-Trunk27 up up 0.01% 0.01% 0 0
MEth0/0/0 up up 0.01% 0.01% 0 0
NULL0 up up(s) 0% 0% 0 0
Vlanif2 down down -- -- 0 0
Vlanif200 up up -- -- 0 0
Example 2: Run the display current-configuration command to display all the lines that match
the regular expression vlan.
<HUAWEI> display current-configuration | include vlan
vlan batch 2 9 to 20 77 99 200 222 4091
vlan 19
mux-vlan
vlan 222
aggregate-vlan
access-vlan 1
instance 2 vlan 2
carrier-vlan 100
ce-vlan 10
port trunk allow-pass vlan 99 200
igmp-snooping static-router-port vlan 99
port trunk allow-pass vlan 20
port default vlan 77
port trunk allow-pass vlan 20
Example 3: Run the display current-configuration command to display the number of lines
that match the regular expression vlan.
<HUAWEI> display current-configuration | include vlan | count
Total lines: 14.
NOTE
The preceding information is used for reference only.
9.1.3 Common display Commands
The device provides various display commands to display hardware, interface, and software
information. The information helps you locate various faults.
The following table lists the commands used to collect fault information.
135
Item Command Description
Basic
informatio
n
display diagnostic-information This command collects basic system
information. It displays outputs of
multiple display commands, including
display device and display current-
configuration. Executing this
command requires a long time. You can
press Ctrl+C to pause diagnosis
information display on screen.
Device
informatio
n
display device This command checks the status of a
board when the board works
abnormally. If the Status field displays
Abnormal, the board is not working
properly.
Interface
informatio
n
display interface This command displays various
information about an interface. You can
run this command to check interface
connection faults and statistics about
discarded packets.
Versions display version This command displays version
information about the system software,
MPU, and LPU. The version
information can help you locate faults.
Patch
informatio
n
display patch-information This command displays system patch
package information, including patch
package version and name. The
information can help you locate faults.
Electronic
label
informatio
n
display device elabel This command displays the electronic
label of a board. Electronic labels
identify device hardware.
Device
status
display health This command displays information
about the temperature, power supply,
fan, power, CPU usage, memory usage,
and storage medium usage of the
device.
Current
configurat
ions
display current-configuration This command displays all
configuration information on a device.
You can specify a regular expression to
obtain the required configuration
information.
136
Item Command Description
Saved
configurat
ions
display saved-configuration If the device has been started and is not
working properly, run the display
saved-configuration command to
check the device startup configuration
in the file specified by running the
startup saved-configuration
command.
Run the display saved-configuration
last command to check the system
configurations saved last time in the
configuration file loaded during the
current startup.
Time display clock This command displays the current
system date and time.
User logs display logbuffer This command displays user logs in the
log buffer.
Alarms display trapbuffer This command displays information
recorded in the trap buffer.
Memory
usage
display memory This command displays the memory
usage of a device.
CPU
usage
display cpu This command displays the CPU usage
of a device.

9.2 reset Commands
reset commands are used to clear statistics. These commands help you quickly locate faults.
9.2.1 Overview
reset commands include:
l The commands resetting connections, such as reset bgp
l The commands clearing statistics
This section involves the reset commands clearing statistics.
9.2.2 reset Commands Clearing Packet Statistics
reset interface counters and reset ip statistics are often used to clear packet statistics displayed
in the display interface and display ip interface command output.
l The display interface command provides counters to collect statistics on sent and received
Layer 2 packets. The reset interface counters command resets these counters.
137
l The display ip interface command provides counters to collect statistics on sent and
received Layer 3 packets. The reset ip statistics command resets these counters.
9.2.3 Using reset Commands
Context
When you use the ping command to test link connectivity, you also need to run the display
interface or display ip interface command to check whether packets are correctly sent and
received on interfaces and whether a CRC error occurs. Then you can locate the interface where
the fault occurs.
The display command output shows packet statistics generated after the device starts or the
counter is reset; therefore, the packet statistics may contain unnecessary information that
interferes with fault location.
To collect packet statistics accurately, perform the following operations:
Procedure
Step 1 Run the reset interface counters or reset ip statistics commands to clear existing packet
statistics.
Step 2 Run the ping command to enable iterfaces to send and receive packets.
Step 3 Run the display interface or display ip interface commands to view the statistics.
----End
9.3 Ping and Tracert
This section describes how to use Ping and Tracert commands to check network connectivity
and locate network faults. The Ping command checks network connectivity and host reachability
and the Tracert command tracks the gateways that packets pass through from the source host
to the destination host.
Introduction to the Ping Command
Based on the Internet Control Message Protocol (ICMP), the Ping command is used to check
network connectivity and host reachability. The source sends an ICMP Echo Request message
to the destination, and determines reachability. The source determines the quality of the link
from which the destination is reachable based on the number of sent ICMP Echo Request
messages and received ICMP Echo Response messages, and the round-trip time (RTT) of ping
packets.
Ping Command Format
NOTE
CloudEngine 6800&5800 Series Switches Command Reference provides detailed description of command
parameters and usage. Here lists only some commonly used parameters and their descriptions.
ping [ ip ] [ -a source-ip-address | -c count | -f | -s packetsize | -t timeout ]
*
host
138
l -a: specifies the source IP address for sending Echo Request messages. If no source IP
address is specified, the IP address of the outbound interface is used as the source IP address.
l -c: specifies the count for sending Echo Request messages. The default value is 5. You can
increase the number of outgoing packets to detect the network quality based on the packet
loss ratio.
l -f: indicates that packets are not fragmented when they are sent. The device discards the
packets if the packet size exceeds the MTU.
l -s: specifies the length of an Echo Request message without the IP header and ICMP header.
l -t: specifies the timeout interval of Echo Response messages. You can set a larger timeout
interval if the network is unstable. The default value is 2s. If the device receives no Echo
Request message, it determines that the destination is unreachable.
l host: indicates an IP address or a domain name. If it is a domain name, the device performs
DNS resolution and displays the resolved IP address.
TIP
You can use the parameters -s and -f simultaneously to test the path MTU (PMTU). For example, if the
ping operation succeeds when the parameter -s is set to 1472 but fails when the parameter is set to 1473,
the PMTU is 1500, which is the total sum of 1472, 20 (IP header), and 8 (ICMP header).
The ping function varies with the operating system of a PC. The Windows operating system is
used as an example.
ping [ -n number ] [ -t ] [ -l number ] [ -f ] [ -a ] ip-address
l -n: specifies the number of ping packets. The default value is 5.
l -t: indicates that the source sends Echo Request messages to the destination continuously
until manual operations are involved. You can press Ctrl+Break to temporarily stop the
ping command and view the statistics, and press Ctrl+C to end the ping operation.
l -l: specifies the number of bytes of data in ping packets. The value ranges from 0 to 65500.
l -f: indicates that packets are not fragmented when they are sent. The device discards the
packets if the packet size exceeds the MTU.
l -a: indicates that the device resolves an IP address into a host name.
Description of the Ping Command Output
<Huawei> ping 100.135.18.118
PING 100.135.18.118: 56 data bytes, press CTRL_C to break

--- 100.135.18.118 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
In this example:
l The device sends five ping packets and receives response for all the five packets.
l The ping packets use the default size, 56 bytes.
l The TTL value is 255, indicating that the source is directly connected to the destination.
139
l The time is 1 ms, indicating that the device receives an Echo Response message 1 ms after
it sends an Echo Request message. This parameter can be used as a reference to determine
whether the network is congested.
The device sends five ping packets by default. You can set a larger value of -c to accurately
detect the network status. The device determines the network status based on the number of ping
packets returned.
Fault Description Possible Cause
All packets can reach
the destination but
require a long time.
The intermediate network is unstable.
QoS is deployed on the gateway, which lowers the forwarding speed.
No packet can reach
the destination.
Services on the network are interrupted due to device or cable faults.
The firewall on the intermediate network discards ICMP packets.
A loop occurs on the network and packets are discarded when the TTL
value is reduced to 1.
Packets are delayed due to network congestion.
Some packets cannot
reach the destination.
Some ping packets are discarded on the unstable network.
Load balancing is configured on the intermediate network and some
ping packets are discarded on one path.
Packet flooding attacks.

Introduction to the Tracert Command
The Ping command checks whether the destination host is reachable and the Tracert command
tracks the gateways that packets pass through from the source host to the destination host. This
helps check network connectivity and locate network faults. The tracert process is as follows:
1. The source host sends a UDP packet with TTL (hop limit for an IPv6 packet) 1.
2. The first hop sends back an error ICMP packet, indicating that the packet cannot be sent
due to TTL timeout.
3. The source host then sends a packet with TTL 2.
4. The second hop drops the packet and sends an ICMP TTL-expired packet.
This process proceeds until the packet reaches the destination host. The source host obtains the
path to the destination host based on the source IP addresses of ICMP TTL-expired packets
(ICMP6 hop limit-expired for an IPv6 packet).
Tracert Command Format
NOTE
CloudEngine 6800&5800 Series Switches Command Reference provides detailed description of command
parameters and usage. Here lists only some commonly used parameters and their descriptions.
tracert [ -a source-ip-address | -f first-ttl | -m max-ttl | -q nqueries | -vpn-instance vpn-instance-
name | -w timeout ]
*
host
140
l -a: specifies the source address. If this parameter is not specified, the IP address of the
outbound interface is used as the source IP address of outgoing packets.
l -f: specifies the initial TTL. If the number of hops is smaller than the initial TTL, the source
host receives no TTL-expired packet. If a maximum TTL is set, the initial TTL must be
smaller than the maximum TTL.
l -m: specifies the maximum TTL. The maximum TTL is usually set to the number of hops
through which a Tracert packet passes. If an initial TTL is set, the maximum TTL must be
larger than the initial TTL.
l -q: specifies the number of UDP packets sent each time. You can increase this value to
ensure that UDP packets can reach the destination host.
l -vpn-instance: indicates the associated VPN instance name.
l -w: sets the timeout interval of Response messages. If a gateway sends a message indicating
TTL timeout, " * " is displayed. You are advised to increase the timeout interval when the
network is unstable and the transmission speed is low.
l host: indicates an IP address or a domain name. If it is a domain name, the device performs
DNS resolution and displays the resolved IP address.
The tracert function varies with the operating system of a PC. The Windows operating system
is used as an example for illustration.
tracert [ -d ] [ -h maximum_hops ] [ -j host-list ] [ -w timeout ] ip-address
l -d: indicates that the host name is not resolved.
l -h: specifies the maximum TTL.
l -j: specifies the loose source address routing list.
l -w: sets the timeout interval of UDP packets, in milliseconds.
Description of the Tracert Command Output
<Huawei> tracert 100.135.18.118
traceroute to 100.135.18.118(100.135.18.118), max hops: 30 ,packet length:
40,press CTRL_C to break
1 192.168.200.100 10 ms 2 ms 2 ms
2 * * *
3 100.135.18.118 10 ms 1 ms 2 ms
Information displayed in a line includes the number, IP address where the packet reaches, and
three response time. * * * is displayed in the second line, indicating that the ping and tracert
operations are not supported on this node.
The Ping command can only determine whether the destination is reachable, whereas the
Tracert command can detect potential loops on a network. If you track an address and the same
address is displayed multiple times, a route loop occurs.
9.4 Traps
When faults occur or the system operates abnormally, alarms and events are triggered to help
users fast detect and locate faults quickly.
l Alarm
When the system operates abnormally, alarms are triggered to inform maintenance
personnel of the device operating status.
141
When a fault occurs, an alarm is triggered and the alarm trap is sent. After the fault is
rectified, the alarm status changes from active to cleared and the clear alarm trap is sent. If
an alarm trap is generated, a corresponding clear alarm trap will be generated after the fault
is rectified.
l Event
Events are triggered by specific occurrences, and indicate anything that takes place on a
managed object in the system. For example, an object is added, deleted, or modified.
Certain events will trigger event traps. An event trap does not have a match trap.
NOTE
By default, alarms and events are defined by the Huawei NMS. Alarms and events may be defined
differently on third-party NMSs, but can be redefined as required.
As shown in Figure 9-1, alarm and event traps are stored in the following paths:
l If an NMS is configured, the system sends the traps to the NMS by the Simple Network
Management Protocol (SNMP).
l The trap buffer size can be determined as required.
l Device operating information recorded in information files is the same as the information
displayed in the buffer area.
l The information is saved as files on the syslog server for future reference.
Figure 9-1 Input and output of the alarm and event traps

Traps can be viewed using either of the following methods:
l View traps on the NMS window.
l Run the display trapbuffer [ size buffersize ] command to view traps in the trap buffer on
the command-line terminal window.
buffersize specifies the number of traps to be displayed on the command-line terminal
window. If the number of traps in the trap buffer is smaller than the buffersize value, the
actual number of traps in the trap buffer are displayed on the command-line terminal
window.
142
9.5 Logs
During device operation, the log module records operations and events on the device. The
recorded operations and events are log messages.
The generated logs can be viewed through the Console port or Telnet, or stored to the log server
through the syslog protocol.
The syslog protocol is transmitted through UDP port 514. Any UDP datagram on port 514 is
recorded in the log.
Logs can be viewed in two ways:
l Display logs on the GUI of the NMS.
l Run the display logbuffer [ starttime starttime [ endtime endtime ] | level { severity |
level } | size size ]
*
command to view logs in the log buffer.
9.6 Packet Header Capturing Function
The packet header capturing function copies packet headers from a mirrored port to an observing
port for packet header analysis. This function helps you locate faults.
A device cannot analyze packet headers. The captured packet headers need to be analyzed by a
PC with packet capturing software installed or a tester connected to the observing port.
NOTE
The packets captured for troubleshooting may contain user communication information. Therefore, Huawei
does not capture packets for you. You must capture packets legally and with permission. Ensure that your
customers' privacy is protected when collecting communication information.
Packet headers can be mirrored to a local observing port or a remote observing port. The two
methods can capture packets in inbound, outbound, or both directions.
Mirroring Packet Headers to a Local Observing Port
Packet headers are copied from a mirrored port to an observing port and then sent to a directly
connected observing device. As shown in Figure 9-2, the incoming packets on 10GE1/0/1 are
mirrored to 10GE1/0/2, and the observing device directly connected to 10GE1/0/2 analyzes the
packet headers.
Figure 9-2 Networking diagram of local mirroring
Mirrored port
Observing port
Packet flow
Copied packet flow
Monitoring
device
Host SwitchA
10GE1/0/1 10GE1/0/2
143
Perform the following steps to mirror packet headers to a local observing port.
1. Configure 10GE1/0/2 on SwitchA as a local observing port.
[~HUAWEI] sysname SwitchA
[~HUAWEI] commit
[~SwitchA] observe-port 1 interface 10ge 1/0/2
[~SwitchA] commit
2. Configure 10GE1/0/1 on SwitchA as a mirrored port and set the mirroring direction to
inbound.
[~SwitchA] interface 10ge 1/0/1
[~SwitchA-10GE1/0/1] port-mirroring observe-port 1 inbound
[~SwitchA-10GE1/0/1] commit
Mirroring Packet Headers to a Remote Observing Port
The monitored device and the monitoring device are connected through a Layer 2 or Layer 3
network.
l Across a Layer 2 network
Implement Layer 2 communication between the monitored device and the monitoring
device. Packets passing through a mirrored port are tagged a VLAN ID and broadcast in
the remote mirroring VLAN through the observing port. The packets then reach the
monitoring device.
As shown in Figure 9-3, HostA connects to SwitchA through 10GE1/0/1. Server connects
10GE1/0/2 of SwitchC. SwitchA and SwitchC interconnect through a Layer 2 network.
Figure 9-3 Networking diagram of Layer 2 remote port mirroring
10GE1/0/2
10GE1/0/2
10GE1/0/1
10GE1/0/1
VLAN2 VLAN2
SwitchA
SwitchB
SwitchC
10GE1/0/1 10GE1/0/2
HostA Server
Mirrored port
Observing port
Packet flow
Copied packet flow
Perform the following steps to mirror packet headers to a remote observing port.
1. Configure interfaces to implement Layer 2 communication between devices.
[~HUAWEI] commit
[~SwitchA] vlan batch 2 to 3
144
[~SwitchA-10GE1/0/1] port default vlan 3
[~SwitchA-10GE1/0/1] quit
[~SwitchA-10GE1/0/2] port link-type trunk
[~SwitchA-10GE1/0/2] port trunk allow-pass vlan 2
[~SwitchA] commit
[~HUAWEI] sysname SwitchB
[~HUAWEI] commit
[~SwitchB] vlan 2
[~SwitchB-vlan2] quit
[~SwitchB] interface 10ge 1/0/1
[~SwitchB-10GE1/0/1] port link-type trunk
[~SwitchB-10GE1/0/1] port trunk allow-pass vlan 2
[~SwitchB-10GE1/0/1] quit
[~SwitchB] interface 10ge 1/0/2
[~SwitchB-10GE1/0/2] port link-type trunk
[~SwitchB-10GE1/0/2] port trunk allow-pass vlan 2
[~SwitchB-10GE1/0/2] quit
[~SwitchB] commit
[~HUAWEI] sysname SwitchC
[~HUAWEI] commit
[~SwitchC] vlan 2
[~SwitchC-vlan2] quit
[~SwitchC] interface 10ge 1/0/1
[~SwitchC-10GE1/0/1] port link-type trunk
[~SwitchC-10GE1/0/1] port trunk allow-pass vlan 2
[~SwitchC-10GE1/0/1] quit
[~SwitchC] interface 10ge 1/0/2
[~SwitchC-10GE1/0/2] port default vlan 2
[~SwitchC-10GE1/0/2] quit
[~SwitchC] commit
2. Configure 10GE1/0/2 on SwitchA as a remote observing port.
[~SwitchA] observe-port 1 interface 10ge 1/0/2 vlan 2
[~SwitchA] commit
3. Configure 10GE1/0/1 on SwitchA as a mirrored port.
[~SwitchA] commit
l Across a Layer 3 network
Ensure that a reachable route exists between the monitored device and the monitoring
device over a Layer 3 network. Packets passing through a mirrored port are encapsulated
with GRE packet headers. The packets then reach the monitoring device through a Layer
3 IP network.
As shown in Figure 9-4, HostA connects to SwitchA through 10GE1/0/1. Server connects
to 10GE1/0/2 of SwitchB. A reachable route exists between HostA and Server over a Layer
3 network.
145
Figure 9-4 Networking diagram of Layer 3 remote port mirroring
SwitchA
Server
10.2.1.1/24
Network
SwitchB
HostA
10.1.1.1/24
10GE1/0/1
10GE1/0/2
10GE1/0/2
Mirrored port
Observing port
Packet flow
Copied packet flow
Perform the following steps.
1. Ensure that a reachable routes exists between HostA and Server. The configuration
procedure is not mentioned here.
2. Configure 10GE1/0/2 on SwitchA as a Layer 3 remote observing port and configure
the destination IP address as the IP address of Server.
[~HUAWEI] commit
[~SwitchA] observe-port interface 10ge 1/0/2 destination-ip 10.2.1.1
source-ip 10.1.1.1
[~SwitchA] commit
3. Configure 10GE1/0/1 on SwitchA as a mirrored port.
[~SwitchA] commit
146
10 Appendix: Indicators
About This Chapter
10.1 Fan Module Indicator
10.2 Power Indicators
Troubleshooting 10 Appendix: Indicators
147
10.1 Fan Module Indicator
Figure 10-1 shows the panel of a FAN-40EA fan module.
Figure 10-1 Panel of a FAN-40EA fan module (front view)

1
1

Table 10-1 describes the indicator on a FAN-40EA fan module.
148
Table 10-1 Description of indicator on a FAN-40EA fan module
Number in
Figure 10-1
Indicator Color Description
1 Fan status
indicator
(STATUS)
Off The fan module is not running.
Green l Slow blinking: The fan module is working
and communicating normally with the
system.
l Fast blinking: The fan module is working
but is not communicating normally with
the system.
Red l Steady on: The fan module has a hardware
fault and needs to be replaced.
l Slow blinking: An alarm has been
generated, and you need to handle it
accordingly. Common causes of this
alarms include errors of dual in-line
package (DIP) switches, short-circuit, fan
blades blocked, and fault of the fan
module.

10.2 Power Indicators
Figure 10-2 shows the panel of a CE6800/5800 power module.
149
Figure 10-2 Panel of a CE6800/5800 power module
1
1
1

Table 10-2 describes indicators on a CE6800/5800 power module.
Table 10-2 Description of indicator on a CE6800/5800 power module
Number
in
Figure
10-2
Indicator Color Description
1 STATUS Off The AC power input is abnormal (for example, no input,
overvoltage, or undervoltage) or AC power output is
abnormal (for example, overvoltage, overcurrent, short-
circuit, or overtemperature).
Green Steady on: The power module is working normally.
150

CloudEngine 6800&5800 V100R002C00 Troubleshooting Guide 01 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CloudEngine 6800&5800 V100R002C00 Troubleshooting Guide 01 PDF

Uploaded by

Copyright:

Available Formats

CloudEngine 6800&5800 Series Switches

You might also like