CloudEngine 6800&5800 V100R003C00 Troubleshooting Guide 01

CloudEngine 6800&5800 Series Switches

V100R003C00

Troubleshooting

Issue 01

Date 2013-12-31

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 writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://enterprise.huawei.com

Issue 01 (2013-12-31) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://enterprise.huawei.com

About This Document

Intended AudienceThis document describes common troubleshooting procedure and methods.

This document is intended for:

l Data configuration engineersl Commissioning engineersl Network monitoring engineersl System maintenance engineers

Symbol ConventionsThe symbols that may be found in this document are defined as follows.

Symbol Description

Indicates an imminently hazardous situationwhich, if not avoided, will result in death orserious injury.

Indicates a potentially hazardous situationwhich, if not avoided, could result in death orserious injury.

Indicates a potentially hazardous situationwhich, if not avoided, may result in minor ormoderate injury.

Indicates a potentially hazardous situationwhich, if not avoided, could result inequipment damage, data loss, performancedeterioration, or unanticipated results.NOTICE is used to address practices notrelated to personal injury.

CloudEngine 6800&5800 Series SwitchesTroubleshooting About This Document


ii

Symbol Description

NOTE Calls attention to important information, bestpractices and tips.NOTE is used to address information notrelated to personal injury, equipment damage,and environment deterioration.

Command ConventionsThe command conventions that may be found in this document are defined as follows.

Convention Description

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

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

{ x | y | ... } Optional items are grouped in braces and separated byvertical bars. One item is selected.

[ x | y | ... ] Optional items are grouped in brackets and separated byvertical bars. One item is selected or no item is selected.

{ x | y | ... }* Optional items are grouped in braces and separated byvertical bars. A minimum of one item or a maximum of allitems can be selected.

[ x | y | ... ]* Optional items are grouped in brackets and separated byvertical bars. Several items or no item can be selected.

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

# A line starting with the # sign is comments.

Change HistoryUpdates between document issues are cumulative. Therefore, the latest document issue containsall updates made in previous issues.

Changes in Issue 01 (2013-12-31)

Initial commercial release.

CloudEngine 6800&5800 Series SwitchesTroubleshooting About This Document


iii

Contents

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

1 Instructions for Maintenance Engineers...................................................................................11.1 Precautions......................................................................................................................................................................21.2 Backing Up Data............................................................................................................................................................21.3 Troubleshooting Process.................................................................................................................................................21.4 Ask for Help...................................................................................................................................................................31.4.1 Huawei Enterprise Website.........................................................................................................................................31.4.2 Hotline.........................................................................................................................................................................3

2 Forgetting Passwords....................................................................................................................42.1 Recovering the Console Port Password..........................................................................................................................52.2 Recovering the Telnet Login Password..........................................................................................................................7

3 Information Collection.................................................................................................................93.1 Overview......................................................................................................................................................................103.2 Collecting Diagnostic Information...............................................................................................................................103.3 Health Status Information.............................................................................................................................................10

4 System Maintenance Methods..................................................................................................124.1 Restoring the Default Settings Using the Configuration File.......................................................................................134.2 Restarting the Device....................................................................................................................................................134.3 Upgrading the Device...................................................................................................................................................144.4 Transferring Files Using FTP/TFTP.............................................................................................................................14

5 Startup Failures............................................................................................................................185.1 Terminal Does Not Display Anything Or Displays Garbled Characters......................................................................19

6 Hardware.......................................................................................................................................206.1 Power Module Troubleshooting...................................................................................................................................216.1.1 The SYS and Power Module Indicators Are Off.......................................................................................................216.2 Fan Module Troubleshooting.......................................................................................................................................216.2.1 The Indicator of a Fan Module Is Steady Red or Blinking.......................................................................................216.2.2 Fan Noise Is Loud......................................................................................................................................................226.2.3 An Alarm Is Generated When the Fan Status Is Abnormal.......................................................................................226.2.4 Fan Blades Were Damaged.......................................................................................................................................23

CloudEngine 6800&5800 Series SwitchesTroubleshooting Contents


iv

6.3 Optical Module Troubleshooting..................................................................................................................................246.3.1 Optical Modules on the Local and Remote Devices Cannot Communicate.............................................................246.4 Interface Troubleshooting.............................................................................................................................................266.4.1 A 40GE Interface Fails to Be Split into 10GE Interfaces or 10GE Interfaces Fail to Be Merged into A 40GE Interface............................................................................................................................................................................................266.4.2 An Electrical Interface Cannot Go Up.......................................................................................................................276.4.3 10GE Optical Interfaces Cannot Go Up....................................................................................................................286.4.4 40GE Optical Interfaces Cannot Go Up....................................................................................................................306.4.5 Packet Loss Occurs on An Interface..........................................................................................................................31

7 Patch and Upgrade Faults..........................................................................................................337.1 Patch Faults...................................................................................................................................................................347.1.1 Failed to Install a Patch.............................................................................................................................................34

8 Service Faults................................................................................................................................358.1 Ethernet Switching.......................................................................................................................................................368.1.1 VLAN Troubleshooting.............................................................................................................................................368.1.1.1 Users in a VLAN Cannot Communicate with Each Other.....................................................................................368.1.1.1.1 Common Causes..................................................................................................................................................368.1.1.1.2 Troubleshooting Flowchart..................................................................................................................................368.1.1.1.3 Troubleshooting Procedure..................................................................................................................................388.1.1.1.4 Relevant Alarms and Logs..................................................................................................................................408.1.2 MSTP Troubleshooting.............................................................................................................................................408.1.2.1 MSTP Topology Change Leads to Service Interruption........................................................................................408.1.2.1.1 Common Causes..................................................................................................................................................408.1.2.1.2 Troubleshooting Flowchart..................................................................................................................................408.1.2.1.3 Troubleshooting Procedure..................................................................................................................................428.1.2.1.4 Relevant Alarms and Logs..................................................................................................................................468.2 IP Forwarding and Routing..........................................................................................................................................468.2.1 RIP Troubleshooting .................................................................................................................................................468.2.1.1 Device Does not Receive Partial Routes or All the Routes....................................................................................478.2.1.1.1 Common Causes..................................................................................................................................................478.2.1.1.2 Troubleshooting Flowchart..................................................................................................................................478.2.1.1.3 Troubleshooting Procedure..................................................................................................................................498.2.1.1.4 Relevant Alarms and Logs..................................................................................................................................518.2.1.2 Device Does not Send Partial or All the Routes.....................................................................................................518.2.1.2.1 Common Causes..................................................................................................................................................518.2.1.2.2 Troubleshooting Flowchart..................................................................................................................................528.2.1.2.3 Troubleshooting Procedure..................................................................................................................................548.2.1.2.4 Relevant Alarms and Logs..................................................................................................................................568.2.1.3 Trouble Cases.........................................................................................................................................................568.2.1.3.1 A RIP Error Occurs due to Discontinuous Subnets.............................................................................................568.2.2 OSPF Troubleshooting..............................................................................................................................................58



v

8.2.2.1 OSPF Neighbor Relationship Is Down...................................................................................................................588.2.2.1.1 Common Causes..................................................................................................................................................588.2.2.1.2 Troubleshooting Flowchart..................................................................................................................................588.2.2.1.3 Troubleshooting Procedure..................................................................................................................................598.2.2.1.4 Relevant Alarms and Logs..................................................................................................................................638.2.2.2 OSPF Neighbor Relationship Cannot Enter the Full State.....................................................................................638.2.2.2.1 Common Causes..................................................................................................................................................648.2.2.2.2 Troubleshooting Flowchart..................................................................................................................................648.2.2.2.3 Troubleshooting Procedure..................................................................................................................................658.2.2.2.4 Relevant Alarms and Logs..................................................................................................................................668.2.3 BGP Troubleshooting................................................................................................................................................668.2.3.1 BGP Peer Relationship Fails to Be Established.....................................................................................................668.2.3.1.1 Common Causes..................................................................................................................................................668.2.3.1.2 Troubleshooting Flowchart..................................................................................................................................678.2.3.1.3 Troubleshooting Procedure..................................................................................................................................688.2.3.1.4 Relevant Alarms and Logs..................................................................................................................................728.2.3.2 BGP Public Network Traffic Is Interrupted...........................................................................................................728.2.3.2.1 Common Causes..................................................................................................................................................728.2.3.2.2 Troubleshooting Flowchart..................................................................................................................................728.2.3.2.3 Troubleshooting Procedure..................................................................................................................................738.2.3.2.4 Relevant Alarms and Logs..................................................................................................................................768.2.3.3 BGP Private Network Traffic Is Interrupted..........................................................................................................768.2.3.3.1 Common Causes..................................................................................................................................................768.2.3.3.2 Troubleshooting Flowchart..................................................................................................................................768.2.3.3.3 Troubleshooting Procedure..................................................................................................................................788.2.3.3.4 Relevant Alarms and Logs..................................................................................................................................828.2.3.4 Troubleshooting of the Fault that Prevents a Local BGP Peer (Route Sender) from Receiving ORFs from a RemotePeer (Route Receiver).........................................................................................................................................................828.2.3.4.1 Common Causes..................................................................................................................................................828.2.3.4.2 Troubleshooting Flowchart..................................................................................................................................838.2.3.4.3 Troubleshooting Procedure..................................................................................................................................848.2.3.4.4 Relevant Alarms and Logs..................................................................................................................................878.3 IP Multicast...................................................................................................................................................................878.3.1 Multicast Traffic Cannot Be Transmitted..................................................................................................................878.3.1.1 Common Causes.....................................................................................................................................................878.3.1.2 Troubleshooting Flowchart.....................................................................................................................................878.3.1.3 Troubleshooting Procedure.....................................................................................................................................888.3.1.4 Relevant Alarms and Logs.....................................................................................................................................898.3.2 The PIM Neighbor Relationship Remains Down......................................................................................................908.3.2.1 Common Causes.....................................................................................................................................................908.3.2.2 Troubleshooting Flowchart.....................................................................................................................................908.3.2.3 Troubleshooting Procedure.....................................................................................................................................91



vi

8.3.2.4 Relevant Alarms and Logs.....................................................................................................................................938.3.3 MSDP Peers Cannot Generate Correct (S, G) Entries...............................................................................................938.3.3.1 Common Causes.....................................................................................................................................................938.3.3.2 Troubleshooting Flowchart.....................................................................................................................................938.3.3.3 Troubleshooting Procedure.....................................................................................................................................958.3.3.4 Relevant Alarms and Logs.....................................................................................................................................978.4 QoS...............................................................................................................................................................................978.4.1 Priority Mapping Troubleshooting............................................................................................................................978.4.1.1 Packets Enter Incorrect Queues..............................................................................................................................978.4.1.1.1 Common Causes..................................................................................................................................................988.4.1.1.2 Troubleshooting Flowchart..................................................................................................................................988.4.1.1.3 Troubleshooting Procedure................................................................................................................................1008.4.1.1.4 Relevant Alarms and Logs................................................................................................................................1018.4.1.2 Priority Mapping Results Are Incorrect...............................................................................................................1018.4.1.2.1 Common Causes................................................................................................................................................1018.4.1.2.2 Troubleshooting Flowchart................................................................................................................................1028.4.1.2.3 Troubleshooting Procedure................................................................................................................................1038.4.1.2.4 Relevant Alarms and Logs................................................................................................................................1048.4.2 Traffic Policing Troubleshooting............................................................................................................................1048.4.2.1 Interface-based Traffic Policing Results Are Incorrect........................................................................................1048.4.2.1.1 Common Causes................................................................................................................................................1048.4.2.1.2 Troubleshooting Flowchart................................................................................................................................1048.4.2.1.3 Troubleshooting Procedure................................................................................................................................1058.4.2.1.4 Relevant Alarms and Logs................................................................................................................................1068.4.3 Traffic Shaping Troubleshooting.............................................................................................................................1068.4.3.1 Traffic Shaping Results of Queues Are Incorrect.................................................................................................1068.4.3.1.1 Common Causes................................................................................................................................................1068.4.3.1.2 Troubleshooting Flowchart................................................................................................................................1078.4.3.1.3 Troubleshooting Procedure................................................................................................................................1098.4.3.1.4 Relevant Alarms and Logs................................................................................................................................1118.4.4 Congestion Avoidance Troubleshooting.................................................................................................................1118.4.4.1 Congestion Avoidance Fails to Take Effect.........................................................................................................1118.4.4.1.1 Common Causes................................................................................................................................................1118.4.4.1.2 Troubleshooting Flowchart................................................................................................................................1118.4.4.1.3 Troubleshooting Procedure................................................................................................................................1138.4.4.1.4 Relevant Alarms and Logs................................................................................................................................1148.4.5 Congestion Management Troubleshooting..............................................................................................................1158.4.5.1 Congestion Management Fails to Take Effect.....................................................................................................1158.4.5.1.1 Common Causes................................................................................................................................................1158.4.5.1.2 Troubleshooting Flowchart................................................................................................................................1158.4.5.1.3 Troubleshooting Procedure................................................................................................................................117



vii

8.4.5.1.4 Relevant Alarms and Logs................................................................................................................................1188.5 Device Management...................................................................................................................................................1188.5.1 Stacking Troubleshooting........................................................................................................................................1198.5.1.1 A Stack Failed to Be Set Up.................................................................................................................................1198.5.1.1.1 Common Causes................................................................................................................................................1198.5.1.1.2 Troubleshooting Flowchart................................................................................................................................1198.5.1.1.3 Troubleshooting Procedure................................................................................................................................1208.5.1.1.4 Relevant Alarms and Logs................................................................................................................................1218.5.1.2 Active/Standby Switchover Cannot Be Performed in a Stack.............................................................................1228.5.1.2.1 Common Causes................................................................................................................................................1228.5.1.2.2 Troubleshooting Flowchart................................................................................................................................1228.5.1.2.3 Troubleshooting Procedure................................................................................................................................1228.5.1.2.4 Relevant Alarms and Logs................................................................................................................................1238.6 DCN and Server Management....................................................................................................................................1238.6.1 TRILL Troubleshooting..........................................................................................................................................1238.6.1.1 TRILL Neighbor Relationship Fails to Be Established........................................................................................1238.6.1.1.1 Common Causes................................................................................................................................................1238.6.1.1.2 Troubleshooting Flowchart................................................................................................................................1238.6.1.1.3 Troubleshooting Procedure................................................................................................................................1248.6.1.1.4 Relevant Alarms and Logs................................................................................................................................1278.6.1.2 TRILL Traffic Failed to Be Forwarded................................................................................................................1278.6.1.2.1 Common Causes................................................................................................................................................1278.6.1.2.2 Troubleshooting Flowchart................................................................................................................................1288.6.1.2.3 Troubleshooting Procedure................................................................................................................................1298.6.1.2.4 Relevant Alarms and Logs................................................................................................................................1318.6.1.3 TRILL In-band NMS Fails to Manage RBs.........................................................................................................1318.6.1.3.1 Common Causes................................................................................................................................................1318.6.1.3.2 Troubleshooting Flowchart................................................................................................................................1328.6.1.3.3 Troubleshooting Procedure................................................................................................................................1328.6.1.3.4 Relevant Alarms and Logs................................................................................................................................1338.6.1.4 TRILL Fails to Be Enabled on an Interface..........................................................................................................1338.6.1.4.1 Common Causes................................................................................................................................................1348.6.1.4.2 Troubleshooting Flowchart................................................................................................................................1348.6.1.4.3 Troubleshooting Procedure................................................................................................................................1348.6.1.4.4 Relevant Alarms and Logs................................................................................................................................135

9 Common Fault Diagnostic Commands.................................................................................1369.1 display Commands.....................................................................................................................................................1379.1.1 Overview.................................................................................................................................................................1379.1.2 Regular Expression in display Commands..............................................................................................................1379.1.3 Common display Commands...................................................................................................................................1419.2 reset Commands.........................................................................................................................................................143



viii

9.2.1 Overview.................................................................................................................................................................1439.2.2 reset Commands Clearing Packet Statistics.............................................................................................................1439.2.3 Using reset Commands............................................................................................................................................1449.3 Ping and Tracert..........................................................................................................................................................1449.4 Traps...........................................................................................................................................................................1489.5 Logs............................................................................................................................................................................1499.6 Packet Header Capturing Function.............................................................................................................................149

10 Appendix: Indicators.............................................................................................................. 15410.1 Fan Module Indicator...............................................................................................................................................15510.2 Power Indicators.......................................................................................................................................................156



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

CloudEngine 6800&5800 Series SwitchesTroubleshooting 1 Instructions for Maintenance Engineers


1

1.1 PrecautionsIf 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 thefaulty module by using the pre-defined troubleshooting methods immediately, and thenrestore services.

l Strictly conform to operation rules and industrial safety standards, ensuring human anddevice 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 asrestarting device and clearing database. Before performing the key operations, confirm theoperation feasibility, back up data, and prepare the emergency and security measures. Onlyqualified personnel can perform key operations.

NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation modeto ensure that the configurations take effect. Unless otherwise specified, this manual defaults to theimmediate validation mode.

l In immediate validation mode, configurations take effect after commands are input and the Enter keyis pressed.

l In two-phase validation mode, after commands are configured, the commit command needs to be runto commit the configurations.

Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correctthe fault, you will have a record of your actions to provide Huawei technical support personnel.

1.2 Backing Up DataSome faults cause resource or money loss for customers. Therefore, maintenance engineersshould focus on preventing faults and quickly restoring faults. Data backup helps you quicklylocate and recover faults. After a network is set up and operates normally, you should back upimportant 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 ProcessSystematic 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 groupedinto multiple cause sets, which make troubleshooting easier.

1.4 Ask for Help

1.4.1 Huawei Enterprise WebsiteAt 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 HotlineIf 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 advisedto keep passwords secure and change them regularly.

2.1 Recovering the Console Port Password

2.2 Recovering the Telnet Login Password

CloudEngine 6800&5800 Series SwitchesTroubleshooting 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 PasswordIf you can log in to the device using Telnet and your user right is level 3 or higher, log in to thedevice 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 usersNOTE: User-Intf: The absolute number and the relative number of user interface Authen: Whether the authentication passes Author: Command line authorization flag -------------------------------------------------------------------------------- User-Intf Delay Type Network Address Authen Author Username -------------------------------------------------------------------------------- 34 VTY 0 00:06:53 TEL 10.135.18.67 pass yes Unspecified

* 35 VTY 1 00:00:00 TEL 10.135.18.91 pass yes Unspecified

36 VTY 2 00:08:11 TEL 10.135.18.54 pass yes Unspecified

Run the display user-interface command to view the user right of all users. VTY1 has acorresponding user right 15; therefore, you have the right to change the console portpassword.<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 topassword authentication.<HUAWEI> system-view[~HUAWEI] user-interface console 0[~HUAWEI-ui-console0] authentication-mode password[*HUAWEI-ui-console0] set authentication password



5

Please configure the login password (8-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> saveWarning: The current configuration will be written to the device. Continue? [Y/N]:yNow saving the current configuration to the slot 1 Info: Save the configuration successfully.

Modifying the Console Port Password Through the BIOS MenuThe BIOS allows you to clear the console port password so that the device does not check thepassword when you log in through the console port. Then the device restarts, enters the commandline interface, and prompts you to change the console port password.

NOTICEl 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 devicerestarts.

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 BIOSpassword ([email protected] by default) to display the BIOS main menu.

2. Clear console login password. BIOS Menu (Version: 240)

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-8): 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 throughthe 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> system-view[~HUAWEI] user-interface console 0[~HUAWEI-ui-console0] authentication-mode password[*HUAWEI-ui-console0] set authentication password



6

Please configure the login password (8-16)Enter Password:Confirm Password:[*HUAWEI-ui-console0] user privilege level 15[*HUAWEI-ui-console0] commit[~HUAWEI-ui-console0] return

4. Save the configuration.<HUAWEI> saveWarning: The current configuration will be written to the device. Continue? [Y/N]:yNow saving the current configuration to the slot 1 Info: Save the configuration successfully.

2.2 Recovering the Telnet Login PasswordYou can use Telnet to remotely maintain and manage a device. If you forget the Telnet loginpassword, 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-interfacecommand to view the authentication mode of the VTY user. You can change the password without changingthe authentication mode or configure a new authentication mode.

AAA Authentication<HUAWEI> system-view[~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> saveWarning: The current configuration will be written to the device. Continue? [Y/N]:yNow saving the current configuration to the slot 1 Info: Save the configuration successfully.

After the configuration is complete, you can use the user name huawei and passwordHuawei@123 to log in to the device.

Password Authentication<HUAWEI> system-view[~HUAWEI] user-interface vty 0 4[~HUAWEI-ui-vty0-4] authentication-mode password[*HUAWEI-ui-vty0-4] set authentication passwordPlease configure the login password (8-16)Enter Password: //Enter Huawei@123Confirm Password: //Confirm the password



7

Huawei@123[*HUAWEI-ui-vty0-4] user privilege level 15[*HUAWEI-ui-vty0-4] commit[~HUAWEI-ui-vty0-4] return<HUAWEI> saveWarning: The current configuration will be written to the device.Are you sure to continue? [Y/N]:yNow saving the current configuration to the slot 1 Info: Save the configuration successfully.

After the configuration is complete, you can use the password Huawei@123 to log in to thedevice.



8

3 Information Collection

About This Chapter

This chapter describes the information collection method. You must collect detailed faultinformation before locating faults by yourself or contacting agents or Huawei technical supportpersonnel 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

CloudEngine 6800&5800 Series SwitchesTroubleshooting 3 Information Collection


9

3.1 OverviewAfter a device fault occurs, collect fault information immediately. This helps you locate the faultaccurately.

If you cannot locate the fault by yourself, provide the following information to agents or Huaweitechnical 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 ofobtaining these information, see 3.2 Collecting Diagnostic Information and 9.1.3Common display Commands.

l Logs generated when the fault occurs. For the method of obtaining the log information, seeCollecting Log Information.

3.2 Collecting Diagnostic InformationThe display diagnostic-information [ [ module-name ] &<1-8> [ slot slot-id ] | file-name ] command displays the device diagnostic information on screen or outputsthe information to a txt file. The device diagnostic information includes startup configuration,current configurations, interface information, time, and system version. The following is anexample:

<HUAWEI> display diagnostic-information dia-info.txtNow 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:/. Usingthe dir command in the user view can confirm file generation.

After a device becomes faulty, provide the device diagnostic information to agents or Huaweitechnical support personnel immediately for fast fault location. For the method of transmittingthe diagnostic information from the device to your computer, see 4.4 Transferring Files UsingFTP/TFTP.

NOTE

l Executing this command requires a long time. You can press Ctrl+C to pause diagnosis informationdisplay on screen.

l When a large amount of diagnostic information is displayed, the CPU usage may be high in a shortperiod.

3.3 Health Status InformationThe device provides the display health command. You can run the command to checkthe health status information, including the temperature, power supply, fan, CPU usage, memoryusage, and storage medium usage of the device. The following is an example:



10

<HUAWEI> display health



11

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

CloudEngine 6800&5800 Series SwitchesTroubleshooting 4 System Maintenance Methods


12

4.1 Restoring the Default Settings Using the ConfigurationFile

When the device is powered on, it reads the configuration file from the default directory forinitialization. Therefore, the configuration in the file is called the initial configuration. If noconfiguration file is stored in the default directory, the device uses the default parameters forinitialization. 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 defaultconfiguration file to the device.

2. Run the startup saved-configuration command to specify the default configuration filefor 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 upusing the current configuration.

4.2 Restarting the DeviceSome network faults will be rectified after you restart the device. This section describes how torestart a device.

You can restart the device using any of the methods in the following table.

Table 4-1 Device restart methods

Method Description

Powering recycle the device Power off and on the device.Cold restart requires manual operation;therefore, this method is applicable to onsitemaintenance personnel.Save the configurations in real time becausethe device will restart directly without savingthe current configuration.

Executing commands Run the reboot command in the user view.Hot restart requires maintenance personnelexecute commands on site or remotely;therefore, this method is applicable to onsiteand remote maintenance personnel.During a restart, the system asks whether tosave the configuration, which effectivelyprevents configuration loss.



13

4.3 Upgrading the DeviceThe upgrade of a device is closely related to the released software versions. The correspondingupgrade guide is released with each new version and you can upgrade the device according tothe guide. To obtain the upgrade guides, visit http://support.huawei.com/enterprise, anddownload the upgrade guide based on the product name and version.

4.4 Transferring Files Using FTP/TFTPDuring system maintenance such as software upgrade and configuration file backup, files mustbe 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/24192.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> system-view[~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 Reply from 192.168.0.2: bytes=56 Sequence=2 ttl=128 time=3 ms Reply from 192.168.0.2: bytes=56 Sequence=3 ttl=128 time=18 ms Reply from 192.168.0.2: bytes=56 Sequence=4 ttl=128 time=3 ms Reply from 192.168.0.2: bytes=56 Sequence=5 ttl=128 time=3 ms

--- 192.168.0.2 ping statistics --- 5 packet(s) transmitted



14

http://support.huawei.com/enterprise/

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 directlyconnected, 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 theFTP server and device.

3. Log in to the FTP server using FTP.<HUAWEI> ftp 192.168.0.2Trying 192.168.0.2 ...Press CTRL + K to abortConnected to 192.168.0.2.220 FTP Server ready.User(192.168.0.2:(none)):ftpuser331 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 downloadfiles from the FTP server to the device.[ftp] put vrpcfg.zip200 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] binary200 Type set to I.[ftp] get devicesoft.cc200 Port command okay.150 Opening BINARY mode data connection for /devicesoft.cc.\ 6482944 bytes transferred 226 Transfer complete.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/24192.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 commandto download files from the TFTP server to the device.



15

<HUAWEI> tftp 192.168.0.2 get vrpcfg.zip vrpcfg1.zipInfo: 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.zipInfo: 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/24192.168.0.1/24

MEth0/0/0

1. Connect the PC and the device and configure IP addresses for them. For details, see PCFunctioning 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> system-view[~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 commandto download files to the FTP server or run the put command to upload files from the FTPserver 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.1Connected to 192.168.0.1.220 FTP service ready.User (192.168.0.1:(none)): huawei331 Password required for huawei.Password:230 User logged in.ftp> get vrpcfg.zip200 Port command okay.150 Opening ASCII mode data connection for vrpcfg.zip.226 Transfer complete.ftp: 5203 bytes received in 0.01Seconds 346.00Kbytes/sec.ftp> lcdLocal directory now C:\Documents and Settings\Administrator.ftp> put vrpcfg.zip200 Port command okay.150 Opening ASCII mode data connection for vrpcfg.zip.



16

226 Transfer complete.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 eachoperating system.



17

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

CloudEngine 6800&5800 Series SwitchesTroubleshooting 5 Startup Failures


18

5.1 Terminal Does Not Display Anything Or DisplaysGarbled Characters

Fault DescriptionAfter a terminal connecting to a router starts, it cannot display anything or displays garbledcharacters.

Possible Causel 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 Roadmapl Check the power module indicators to determine whether the power module is faulty.l Ensure that the serial interface is correctly configured.l Install the cable firmly or replace the cable.

Troubleshooting Procedure1. Check the power module indicators (for the indicator description, see 10.2 Power

Indicators). If the indicators are in normal state, the power module is not faulty. If theindicators are in abnormal state, the power module is faulty. For troubleshooting methodsof the power module, see 6.1 Power Module Troubleshooting.

2. Check whether the COM port on your PC is correctly connected. Ensure that the physicalattributes of the COM port are the same as those of the serial port. The default parametervalues are as follows:l Baud rate: 9600l Data bit: 8l Stop bit: 1l Parity check: Nonel Flow control: None

3. Check whether the cable type is correct. The Console cable delivered with the product isrecommended. Check whether the cable is securely connected. Replace the current cablewith a new one to check whether the cable is faulty if necessary. If the fault is rectified, theconsole cable is faulty.

CloudEngine 6800&5800 Series SwitchesTroubleshooting 5 Startup Failures


19

6 Hardware

About This Chapter

6.1 Power Module Troubleshooting

6.2 Fan Module Troubleshooting

6.3 Optical Module Troubleshooting

6.4 Interface Troubleshooting

CloudEngine 6800&5800 Series SwitchesTroubleshooting 6 Hardware


20

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 poweredon.

Possible Causesl The power modules are turned off.

l Power cables are not securely connected to the sockets.

l The power modules are faulty.

Troubleshooting Procedure1. 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 powermodules 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 or Blinking

Fault Description

The indicator of a fan module is steady red or blinking.

Possible Causesl 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.

Troubleshooting Procedure1. 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.



21

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 canwork normally, the original fan module has failed.

6.2.2 Fan Noise Is Loud

Fault DescriptionThe device is running properly and no fan alarm is generated; however, the fan noise is loud.

Common Causesl The fan rotation speed is high.

Troubleshooting Procedure1. 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 percentpercent command to reduce the fan rotation speed. The following is an example:<HUAWEI> system-view[~HUAWEI] diagnose[~HUAWEI-diagnose] set fan-speed slot 1 percent 50

NOTICEReducing the fan speed may cause the overtemperature of the device. Therefore, use thiscommand with caution.

3. If the fan noise is still loud after the fan rotation speed is reduced, run the upgrade fancommand to upgrade the fan version. The following is an example:<HUAWEI> system-view[~HUAWEI] diagnose[~HUAWEI-diagnose] upgrade fan all

NOTE

The fan cannot be used during an upgrade.

4. If the fault persists, use a new fan module.

6.2.3 An Alarm Is Generated When the Fan Status Is Abnormal

Fault DescriptionThe display device command output shows that the fan status is abnormal.

<HUAWEI> display deviceDevice status: ----------------------------------------------------------------------------- Slot Sub Type Online Power Register Alarm Primary



22

----------------------------------------------------------------------------- 1 - CE5850-48T4S2Q-EI Present On Registered Normal Master FAN2 - Present On Registered Abnormal NA PWR2 - Present On Registered Normal NA -----------------------------------------------------------------------------

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-10-29 19:18:06 The fan partially failed.(FanID=FAN 2, Reason=The fan module was in the abnor mal state.)--------------------------------------------------------------------------------

Common Causesl The fan is not installed properly.l Fan blades are blocked or have heavy dust.

Troubleshooting Procedure1. Check whether the fan is properly installed and whether fan blades are blocked by an

obstacle or have heavy dust. If so, see The Indicator of a Fan Module Is Steady Red orBlinking to handle the problem.

2. Run the upgrade fan command to upgrade the fan version. The following is an example:<HUAWEI> system-view[~HUAWEI] diagnose[~HUAWEI-diagnose] upgrade fan all

NOTE

The fan cannot be used during an upgrade.

3. If the fault persists, use a new fan module.

6.2.4 Fan Blades Were Damaged

Fault DescriptionThe 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 Causesl Fan blades are damaged.

Troubleshooting Procedure1. Use a new fan module.



23

6.3 Optical Module Troubleshooting

6.3.1 Optical Modules on the Local and Remote Devices CannotCommunicate

Fault DescriptionAn optical interface of a CE switch is connected to a remote device through an optical fiber. Thetwo optical interfaces are Down and cannot communicate with each other.

Possible Causesl 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.

Troubleshooting Procedure1. 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-certifiedoptical module cannot ensure service reliability and stability. If a non-Huawei-certifiedoptical module is used, replace it with a Huawei certified optical module.

NOTE

Check whether the label of the optical module has a Huawei logo:

l If there is a Huawei logo on the label, the optical module has passed Huawei certification.

l If not, send the model of the optical module to Huawei technical support personnel.

2. Check whether the optical module matches the optical fiber. If not, replace the optical fiberor 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) :30(62.5um/125um OM1) 80(50um/125um OM2) 300(50um/125um OM3) Nominal Bitrate (MBit/sec) :10300



24

Digital Diagnostic Monitoring :YES Vendor Name :JDSU Vendor Part Number :PLRXPLSCS4322N Ordering Name :------------------------------------------------------------------- Manufacture information: Manu. Serial Number :CB46UF108 Manufacturing Date :2011-11-09 Vendor Name :JDSU------------------------------------------------------------------- Alarm information:-------------------------------------------------------------------

If a LOS alarm is displayed, the local optical interface does not receive signals from theremote interface. Run the display this command in the interface view to checkwhether the two interfaces have been manually shut down. If an interface is shut down, runthe undo shutdown command on the interface.

4. Run the display interface transceiver verbose command to displaydiagnostic information about the optical module on the interface. Check whether thediagnostic 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) :30(62.5um/125um OM1) 80(50um/125um OM2) 300(50um/125um OM3) Nominal Bitrate (MBit/sec) :10300 Digital Diagnostic Monitoring :YES Vendor Name :JDSU Vendor Part Number :PLRXPLSCS4322N Ordering Name :------------------------------------------------------------------- Manufacture information: Manu. Serial Number :CB46UF108 Manufacturing Date :2011-11-09 Vendor Name :JDSU------------------------------------------------------------------- Alarm information:------------------------------------------------------------------- Diagnostic information: Temperature (°C) :31.53 Voltage (V) :3.29 Bias Current (mA) :6.53 Bias High Threshold (mA) :10.00 Bias Low Threshold (mA) :2.60 Current RX Power (dBM) :-2.37 Default RX Power High Threshold (dBM) :1.50 Default RX Power Low Threshold (dBM) :-14.00 Current TX Power (dBM) :-2.27 Default TX Power High Threshold (dBM) :-1.00 Default TX Power Low Threshold (dBM) :-8.00-------------------------------------------------------------------

The display interface transceiver verbose command displays the currenttransmit and receive power values of the optical module, as well as the default maximumand minimum power values.

l If RxPower Low is displayed, the receive signal strength is too low. The possible reasonis that the remote interface is Down or packets sent from the remote interface are droppedduring transmission. Check whether the distance between the two devices exceeds the



25

maximum transmission distance of the optical module. If the distance is within thetransmission distance of the optical module, check whether the optical module on theremote 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 possiblereason is that the distance between the two devices is short but a long-distance opticalmodule is used. In this case, install an optical attenuator on the optical module to reducethe transmit power.

l If TxPower Low is displayed, the transmit signal strength on the local optical moduleis too low. This may cause a low receive power on the remote optical module. As aresult, 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 moduleis too high. This may cause a high receive power on the remote optical module. If thehigh 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 andreceive power alarms after the two interfaces have optical modules installed and connectedusing an optical fiber. Ensure that the transmit and receive power values of the two opticalmodules are in the normal range. Otherwise, traffic forwarding on the optical interfacesmay 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 interfacesare still Down, collect detailed information and logs about the optical modules, and thenreplace the optical modules or optical fiber. If the interfaces can turn Up, the original opticalmodules or optical fiber has been damaged. If the interfaces are still Down, contact HuaweiTechnical Assistance Center.

6.4 Interface Troubleshooting

6.4.1 A 40GE Interface Fails to Be Split into 10GE Interfaces or 10GEInterfaces 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 intoa 40GE interface.

Common Causesl Corresponding commands are not correctly configured.

l The card is not restarted.

Troubleshooting Procedurel A 40GE interface fails to be split into 10GE interfaces.

1. Run the display current-configuration command to check whetherconfiguration information about port split is available. If not, run the portsplit interface interface-type interface-number1 [ to



26

interface-type interface-number2 ] command in the system view to splitthe 40GE interface into 10GE interfaces.

2. Run the display port split command to check the current interface status. Ifthe command output displays the following information, restart the card.<HUAWEI> display port splitNote: *Enable : Enabled after board reset *Disable : Disabled after board reset (Offline): Offline ports ----------------------------------------------------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 whetherconfiguration information about port split is available. If not, run the undoport split interface interface-type interface-number1 [ tointerface-type interface-number2 ] command in the system view tomerge 10GE interfaces into the 40GE interface.

2. Run the display port split command to check the current interface status. Ifthe command output displays the following information, restart the card.<HUAWEI> display port splitNote: *Enable : Enabled after board reset *Disable : Disabled after board reset (Offline): Offline ports ----------------------------------------------------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/610GE1/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 0025-9e95-7c10 Port Mode: COMMON COPPER, Port Split:



27

- 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 Causesl The power cable is faulty.l Negotiation between the local and remote interfaces fails.l The duplex modes of the local and remote interfaces are different.

Troubleshooting Procedure1. 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 thanOK, 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 localinterface view to configure the same rate as that of the remote interface.

3. Check the duplex mode configuration of the local and remote interfaces.The CloudEngine 6800&5800 Series interfaces can only work in full duplex mode. If theremote interface works in half duplex mode, the interface cannot be Up. Change the workingmode of the remote interface to full-duplex or replace the interface with the one thatsupports the full duplex mode.

6.4.3 10GE Optical Interfaces Cannot Go Up

Fault DescriptionA 10GE optical interface cannot go up physically. The interface status is as follows:

<HUAWEI> display interface 10ge4/0/210GE4/0/2 current state : DOWN (ifindex: 9) Line protocol current state : DOWN Description: Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216 Internet protocol processing : disabled



28

IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0025-9e01-0204 Port Mode: COMMON FIBER, Port Split: - Speed : 10000, Loopback: NONE Duplex: FULL, Negotiation: DISABLE Mdi : - Last physical up time : - Last physical down time : 2013-04-10 03:12:43 Current system time: 2013-04-13 10:42:27 ......

Common Causesl 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.

Troubleshooting Procedure1. 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 moduleis within the allowed range, that is, the power of the optical module must meet thefollowing requirements: Default RX Power Low Threshold < Current RX Power<Default RX Power High Threshold and Default TX Power Low Threshold < CurrentTX Power < Default TX Power High Threshold.

------------------------------------------------------------------- Diagnostic information: Temperature (°C) :



29

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) :-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 samenegotiation 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/240GE3/0/2 current state : DOWN (ifindex: 9) Line protocol current state : DOWN Description: Switch Port, PVID : 1, The Maximum Frame Length is 9216 Internet protocol processing : disabled IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0025-9e01-0204 Port Mode: COMMON FIBER, Port Split: - Speed : 40000, Loopback: NONE Duplex: FULL, Negotiation: DISABLE Mdi : - Last physical up time : - Last physical down time : 2013-04-10 03:12:43 Current system time: 2013-04-13 10:42:27 ......



30

Common Causesl 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 The optical module fails.

Troubleshooting Procedure1. 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 transmissionmode (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 attenuatorto 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 theoptical 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 moduleis within the allowed range, that is, the power of the optical module must meet thefollowing 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 Causesl 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.

Troubleshooting Procedure

Run the display interface [ interface-type [ interface-number ] ] commandto check packet statistics on the interface where packet loss occurs and determine the type ofthe lost packets.



31

l If crc error packets are lost and the percentage of the number of crc error packets againstthe total number of packets is small, check whether the cable connector is loose or thephysical line is damaged. If so, tighten the connector or replace the transmission mediumsuch as the optical fiber, copper cable, optical module, or network cable. Run therestart command in the interface view to restart the interface.

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 lengthof the packets sent by the remote device is correct. If the length of the packets sent bythe 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 islarger than or equal to 64 bytes), run the restart command to restart the localinterface.

l If giants packets are lost, check whether the length of the packets received by the localinterface. Run the display interface[ interface-type [ interface-number ] ] command to check the value of The Maximum Frame Length which indicatesthe maximum length of packets allowed by the interface. Then compare the length of thereceived packets and the value of The Maximum Frame Length.

– If the length of the received packets is larger than the The Maximum Frame Lengthbut smaller than the maximum frame length allowed by the interface, run thejumboframe enable value command to increase the length of packets allowedby 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 allowedby the interface (the packet length is larger than the maximum length configured usingthe jumboframe enable value command), run the mtu mtu command on theremote device to reduce the MTU of the remote interface to a value smaller than orequal to the value of The Maximum Frame Length.

l If discard packets are lost, check whether traffic shaping for an interface queue isconfigured on the outbound interface and whether the rate of the outbound interface issmaller than the traffic bandwidth.

For example, if packets received by 10GE1/0/1 are forwarded through 10GE1/0/2, andtraffic shaping for a specified interface queue is configured on 10GE1/0/2 or the rate of10GE1/0/2 is smaller than the traffic bandwidth, some packets cannot be forwarded. As aresult, 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, increase theinterface rate or available bandwidth using the following methods:

– When the current or negotiated interface rate does not reach the maximum, run thespeed { 10 | 100 | 1000 } or speed { 100 | 1000 | 10000 } command toconfigure a higher rate.

– Replace the interface with the one with a higher rate, for example, replace a GEinterface with a 10GE interface.

– Use link aggregation to bind multiple physical interfaces to a logical interface toincrease the bandwidth.



32

7 Patch and Upgrade Faults

About This Chapter

This section describes how to troubleshoot patch installation faults and upgrade faults.

7.1 Patch Faults

CloudEngine 6800&5800 Series SwitchesTroubleshooting 7 Patch and Upgrade Faults


33

7.1 Patch Faults

7.1.1 Failed to Install a Patch

Fault DescriptionA patch cannot be installed.<HUAWEI> patch load patch.PAT allError: Files cannot be obtained from the patch file.

Possible Causesl 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.

Troubleshooting Procedure1. 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 beinstalled to the device.

3. If the device has a patch to be installed but the version of the patch does not match thesystem software version, install a patch of which the version matches the system softwareversion.

CloudEngine 6800&5800 Series SwitchesTroubleshooting 7 Patch and Upgrade Faults


34

8 Service Faults

About This Chapter

8.1 Ethernet Switching

8.2 IP Forwarding and Routing

8.3 IP MulticastThis chapter describes common causes of IP multicast faults and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4 QoS

8.5 Device Management

8.6 DCN and Server ManagementThis chapter describes common causes of DCN and server management faults and provides thecorresponding troubleshooting flowcharts, troubleshooting procedures.

CloudEngine 6800&5800 Series SwitchesTroubleshooting 8 Service Faults


35

8.1 Ethernet Switching

8.1.1 VLAN TroubleshootingThis chapter describes common causes of VLAN faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.1.1.1 Users in a VLAN Cannot Communicate with Each OtherThis section describes common causes of the communication failure between users in a port-based VLAN, and provides the corresponding troubleshooting flowcharts, troubleshootingprocedures, 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.



36

Figure 8-1 Troubleshooting flowchart for communication failure between users in a port-basedVLAN

Users in a VLAN cannot

communicate

Are user interfaces in the VLAN Up?

Are terminalIP addresses

correct?

Are thelearned MAC

address entries correct?

Bring the interfaces to Up state

End

Yes

No

Yes

Yes

No

No

Seek technical support

NoYes

Modify terminal IP addresses

No

No

Yes

Is VLAN configuration

correct?

Modify VLAN configuration

Yes

Is the fault rectified?



No

Is port isolation configured? Disable port isolation

No

NoNo

YesAre static ARPentries on terminals

correct?

Modify static ARP entries

YesIs the fault rectified?



Yes

Yes

No

No

Yes



37

8.1.1.1.3 Troubleshooting Procedure

ContextNOTE





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 inany view to check the status of the interfaces.

l If the interface is in Down state, rectify the fault according to InterfaceTroubleshooting.

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 MACaddresses, interfaces, and VLANs in the learned MAC address entries are correct. If the learnedMAC address entries are incorrect, run the undo mac-address mac-address vlanvlan-id command on the interface to delete the current entries so that the device can learnMAC 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 theVLAN has beencreated

Run the display vlan vlan-id command in any view to checkwhether the VLAN has been created. If not, run the vlan commandto create the VLAN.



38

Check Item Method

Whether theinterfaces areadded to theVLAN

Run the display vlan vlan-id command in any view to checkwhether the VLAN contains the interfaces. If not, add the interfacesto the VLAN.NOTE

If the interfaces are located on different devices, add the interfaces connectingthe devices to the VLAN.

l Add an access interface to the VLAN by using either of thefollowing methods:NOTE

The default type of a device interface is access. To change the interfacetype to access, run the port link-type access command in theinterface view.

1. Run the port default vlan command in the interfaceview.

2. Run the port command in the VLAN view.

l Add a trunk interface to the VLAN.NOTE

The default type of a device interface is access. To change the interfacetype to trunk, run the port link-type trunk command in theinterface view.

Run the port trunk allow-pass vlan command in theinterface view.

l Add a hybrid interface to the VLAN by using either of thefollowing methods:NOTE

The default type of a device interface is access. To change the interfacetype to hybrid, run the port link-type hybrid command in theinterface view.

1. Run the port hybrid tagged vlan command to adda port to VLANs in untagged mode in the interface view.

2. Run the port hybrid untagged vlan command toadd a port to VLANs in tagged mode in the interface view.

Whetherconnectionsbetween interfacesand user terminalsare correct

Check the connections between interfaces and user terminalsaccording to the network plan. If any user terminal is connected toan 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.



39

Run the interface interface-type interface-number command in the systemview to enter the interface view, and then run the display this command to check whetherport isolation is configured on the interface.

l If port isolation is configured, run the undo port-isolate enable command on theinterface 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 theuser 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 TroubleshootingThis chapter describes common causes of MPLS faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.1.2.1 MSTP Topology Change Leads to Service Interruption


When the topology on an MSTP network changes, services are interrupted.

This fault is commonly caused by one of the following:

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.



40

Figure 8-2 Networking diagram of MSTP

Switch1

10GE1/0/1 10GE1/0/110GE1/0/2

10GE1/0/210GE1/0/1

Switch2

Switch3 Switch4

10GE1/0/110GE1/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.




41

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?

MSTP convergence mode is

Normal?

Collect information

Check and modify the MSTP configuration

Shut down the flapping interface

Set the MSTP convergence mode to

Normal

Services are interrupted or the

device is disconnected

No

No


Yes

No

End

Is fault rectified?

Is fault rectified?

Is fault rectified?

Yes

No

Yes

Yes

Yes

No

No

No


No

Yes


ContextNOTE







42

Procedure

Step 1 Check the status of interfaces on MSTP devices.

Check the role of each MSTP-enabled port in each instance.

On the network shown in Figure 8-2, there is only one MSTP ring, which means that eachinstance can have only one blocked interface. Run the display stp brief command oneach 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 portson Switch1 are designated ports. In instance 2, one port on Switch1 is a designated port, and theother 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 0 10GE1/0/2 DESI forwarding none 2 disable 1 10GE1/0/1 DESI forwarding none 2 disable 1 10GE1/0/2 DESI forwarding none 2 disable 2 10GE1/0/1 ROOT forwarding none 2 disable 2 10GE1/0/2 DESI forwarding none 2 disable

Run the display stp brief command in any view to check the MSTP status on Switch2.As shown in Figure 8-2, in instances 2, Switch2 functions as a root bridge, and all ports onSwitch2 are designated ports. In other instances, one port on Switch2 is a designated port, andthe other port is a root port. Both of them are in the Forwarding state.

[Switch2] display stp brief MSTID Port Role STP State Protection Cost Edged 0 10GE1/0/1 ROOT forwarding none 2 disable 0 10GE1/0/2 DESI forwarding none 2 disable 1 10GE1/0/1 ROOT forwarding none 2 disable 1 10GE1/0/2 DESI forwarding none 2 disable 2 10GE1/0/1 DESI forwarding none 2 disable 2 10GE1/0/2 DESI forwarding none 2 disable

Run the display stp brief command in any view to check the MSTP status on Switch3.As shown in Figure 8-2, in instance 2, one port on Switch3 is an Alternate port and the otherport 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 theForwarding state.

[Switch3] display stp brief MSTID Port Role STP State Protection Cost Edged 0 10GE1/0/1 DEST forwarding none 2 disable



43

0 10GE1/0/2 ROOT forwarding none 2 disable 1 10GE1/0/1 DEST forwarding none 2 disable 1 10GE1/0/2 ROOT forwarding none 2 disable 2 10GE1/0/1 ALTE discarding none 2 disable 2 10GE1/0/2 ROOT forwarding none 2 disable

Run the display stp brief command in any view to check the MSTP status on Switch4.As shown in Figure 8-2, in instance 0, one port on Switch4 is an Alternate port, and the otherport is a root port. The Alternate port is blocked and in the Discarding state. In instance 2, oneport on Switch4 is a designated port, and the other port is a root port. Both of them are in theForwarding state.

[Switch4] display stp brief MSTID Port Role STP State Protection Cost Edged 0 10GE1/0/1 ALTE discarding none 2 disable 0 10GE1/0/2 ROOT forwarding none 2 disable 1 10GE1/0/1 ALTE discarding none 2 disable 1 10GE1/0/2 ROOT forwarding none 2 disable 2 10GE1/0/1 DESI forwarding none 2 disable 2 10GE1/0/2 ROOT forwarding none 2 disable

l On the network shown in Figure 8-2, each instance has only one port in the Discardingstate and the other port is in the Forwarding state. If several ports are in the Discardingstate, 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 betweenVLANs and instances.[Switch1] display stp region-configurationOper 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 isincorrect, run the instance command to map the VLAN to a specified spanning treeinstance.

Run the display current-configuration command to view the MSTP configurationin 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.



44

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 TCmessages.

[Switch1]display stp-------[CIST Global Info][Mode MSTP]-------Config Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20CIST Bridge :32768.00e0-fc0e-a421Active Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20CIST 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.0BPDU-Protection :DisabledTC or TCN received :0TC count per hello :0STP Converge Mode :NormalShare region-configuration :EnabledTime since last TC :0 days 23h:9m:30sNumber of TC :1Last TC occurred :10GE1/0/1

l If the values of TC or TCN received and TC count per helloin the command outputincrease, 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 portchanged.

– 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 instructdevices in process 0 to refresh their MAC and ARP address tables. Then, devices on the network canre-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 outputare 0s, the device does not receive any TC message. Contact Huawei technical supportpersonnel.

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 portalternates between Up and Down.

l If an MSTP-enabled interface alternates between Up and Down, the interface flaps. If aphysical interface frequently alternates between Up and Down, the MSTP status of thedevice on the network becomes unsteady. As a result, a large number of TC messages aregenerated, ARP entries and MAC entries are frequently deleted, and services areinterrupted. Run the shutdown command on the flapping interface. If services are notrestored after the interface is shut down, go to Step 5.

l If no interface flaps, go to Step 5.

Step 5 Check that the MSTP convergence mode is Normal.



45

Run the display stp command in any view to check the MSTP convergence mode of thedevice.

[Switch1] display stp-------[CIST Global Info][Mode MSTP]-------CIST Bridge :32768.00e0-fc0e-a421Config Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20Active Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20CIST 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.0BPDU-Protection :DisabledTC or TCN received :0TC count per hello :0STP Converge Mode :NormalShare region-configuration :EnabledTime since last TC :0 days 23h:9m:30sNumber of TC :1Last TC occurred :10GE1/0/1Topo Change Flag :0

l If the convergence mode is Normal, go to Step 6.

l If the convergence mode is Fast, run the stp converge normal command to changethe convergence mode to Normal. If services are not restored after the convergence modeis changed, go to Step 6.



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

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 TroubleshootingThis chapter describes common causes of RIP faults and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.



46

8.2.1.1 Device Does not Receive Partial Routes or All the RoutesThis 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 isdisabled 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.




47

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

NoNo

Yes Yes

No

A device fails to receive some or all routes.

Is RIP enabled on the

ingress?

Does the ingress work

properly?


Do the versions of the

sending and receiving interfaces match?

Is a filtering policy configured?

Has the undorip input command

run?

Is the RIP metric equal to or

greater than 16?

Do other better routes exist?

Seek technical supports.


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.





End

NoNo

YesIs load balancing

configured?Increase the

number of equal-cost paths.


NoNo

YesHas the verify-source command run?

Delete the verify-source command.


Yes

Yes

Yes



48


NOTE





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 interfaceenabled 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 networksegment.

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 currentprotocol is Down, RIP cannot work normally on the interface. Therefore, the UP state of theinterface must be ensured.

Step 3 Check whether the version number sent by the peer matches the version number received on thelocal interface.

If the version numbers of the inbound interface and that of the RIP packet are different, the RIProuting 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 RIPpackets. If the undo rip input command is configured on the inbound interface, none ofthe RIP packets coming from the interface can be processed. Therefore, the routing informationcannot 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 routinginformation.



49

l If the ACL is adopted, use the display current-configurationconfiguration acl-basic command to verify whether the RIP routing informationlearned from the neighbor is filtered out.

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 routingpolicy.

Step 6 Check whether the inbound interface is configured with the rip metricin command andthe metric is equal to 15.The rip metricin command sets the metric added to the route when the interface receivesthe RIP packet.

If the metric exceeds 16, the route is seen as unreachable. Therefore, the route is not added intothe 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 balancedpaths configured for RIP.

If the maximum value is reached, then the incoming routes to the same destination are not addedto 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-sourcecommand.

Step 9 Check whether other protocols learning the same route exist.Run the display rip route command to check whether routes received from the neighborexist.

l One possible case is that the RIP route is received correctly and the local device learns thesame 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 thoseroutes over RIP routes. You can change the preference of RIP to a larger value using thepreference command.

l Using the display ip routing-table protocol rip verbose command, youcan 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 theauthentication 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



50

l Configuration files, log files, and alarm files of the devices

----End


Relevant AlarmsNone

Relevant LogsNone

8.2.1.2 Device Does not Send Partial or All the RoutesThis 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 allthe 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 cannotbe added to the advertised routing table of RIP.

l The outgoing interface does not support the multicast or broadcast mode and a packet needsto 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.



51




52

Figure 8-5 RIP route sending troubleshooting flowchart

No

No

No

No

No

No

Yes

Yes

Yes

Yes

No

No

Yes

Yes

Yes

Yes

NoNo

Yes Yes

Yes

No

Yes

A device fails to send some or all of routes.

Is RIP enabled on the egress?


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 YesDisable route summarization.

NoNo

Yes YesReduce the metric of the interface.

NoNo

Yes YesEnsure that the route exists in the database.

YesYesReduce the routing

update interval.

Yes

YesNo

Does the outbound interface work

properly?

Is the metric equal to or greater

than 16?

Has the Silent-interface

command been run?

Is theundo rip outputcommand 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.













53


NOTE





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 interfaceenabled 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 networksegment 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 outboundinterface.

If the physical state of the interface is down or Administratively Down or the state of the currentprotocol 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 commandto 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 toverify 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 packetcannot be sent on the interface.



54

Step 5 Check whether the summary has been configured.The rip summary-address command disables Classful summarization to perform routingbetween subnets. When Classful summarization is off, subnets are advertised. This feature isused 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, youcan 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 metricvalue 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 thisfault, 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 RIPdatabase. 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 globalinterface.

Only the route whose attributes match those specified in the filter policy are added to theadvertised 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 thephysical state of the interface is down or Administratively Down or the current state of theprotocol on the outbound interface is down, the IP address of the interface cannot be added tothe 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 toolow.Run the display rip command to check the value of the rip timers. If the update timer valueis configured to a very high value, the updates are sent after a long period giving the impressionthat the router is not functioning properly. If the age timer and garbage timer are configured tooless, then the route is removed from the databasel 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 needsto 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. Thisaction 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 theinformation about the maximum packet length where RIP is enabled.



55

Packets are transmitted if at least one RTE can be sent out. Packets are not transmitted out if themaximum packet length is less than 32. Reconfigure the maximum packet length on the interfaceto 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 incommon RIP-related fault cases.

8.2.1.3.1 A RIP Error Occurs due to Discontinuous Subnets

NOTE





Fault Symptom

As shown in Figure 8-6, Switches A, B, and C run RIP. RIP is run in the network segments172.16.1.0/24 and 192.168.1.0/24 of Switch A, network segments 192.168.1.0/24 and192.168.2.0/24 of Switch B, and network segments 172.16.2.0/24 and 192.168.2.0/24 of SwitchC.



56

Figure 8-6 Networking where a RIP route error occurs due to discontinuous subnets

SwitchA

SwitchB

SwitchC

10GE1/0/1VLANIF100

192.168.1.2/24

10GE1/0/1VLANIF100192.168.1.1/24

10GE1/0/2VLANIF200

192.168.2.2/24

10GE1/0/2VLANIF200

192.168.2.1/24

10GE1/0/2VLANIF400

172.16.1.1/24

10GE1/0/1VLANIF300

172.16.2.1/24

Run the display ip routing-table command on Switch B to check whether the routinginformation is correct.

If the routing information of Switch B is correct, Switch B has a route to each of the networksegments 172.16.1.0 and 172.16.2.0.

The command output, however, shows that Switch B has only one route to the network segment172.16.0.0.

Fault AnalysisThe network configured with discontinuous subnets runs RIP-1, which does not support VLSMand 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 classfullroute 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 Band Switch C are similar to that of Switch A, and are not provided here.

----End

SummaryRIPv1 does not support discontinuous subnets. When discontinuous subnets are deployed on anetwork, configure RIPv2 on the network.

When a network runs RIPv2, class-based route summarization is enabled by default. To ensurethe correctness of the routing information, disable class-based route summarization.



57

8.2.2 OSPF TroubleshootingThis chapter describes common OSPF faults and provides troubleshooting.

8.2.2.1 OSPF Neighbor Relationship Is DownThis section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure 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. Figure8-7 shows the troubleshooting flowchart for the fault that the OSPF neighbor relationship isDown.



58

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




End

No

No

No

Yes

Yes Yes

No

Yes

Yes

No

Check the interface and BFD Is the fault rectified?

No

Yes

Check the remote device


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







59

Procedure

Step 1 Check the logs to find the cause of the fault.

Run the display logbuffer size buffersize command to access the following loginformation.

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 faultare as follows:

l Inactivity (NbrEvent=7)

An InactivityTimer event of the neighbor state machine occurs. If a device does not receiveany Hello packets from its neighbor within the down time, the OSPF neighbor relationshipbecomes 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-layerprotocol 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 sentfrom the remote end to the local end when the OSPF status on the remote end changes toDown. 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 displayinterface [ interface-type [ interface-number ] ] command to check theinterface 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 interfaceview to check whether the link between the two devices is normal and the transmission devicesare 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 of the faulty device is toohigh. If it is, OSPF fails to receive and send protocol packets, causing the neighbor relationshipto flap. In this case, troubleshoot the fault of the high CPU usage and disable unnecessaryfunctions. If the CPU usage is within the normal range, go to Step 4.



60

Step 4 Check whether the interface status is Up.

Run the display interface [ interface-type [ interface-number ] ] commandto check the physical status of the interface. If the physical status is Down, troubleshoot theinterface fault.

If the physical status of the interface is Up, run the display ospf interface commandto 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 cumulativecommand to check whether the number of interfaces enabled with OSPF in the OSPFprocess exceeds the upper limit. If so, reduce the number of interfaces enabled with OSPF.<Huawei> display ospf cumulative OSPF Process 1 with Router ID 1.1.1.1 Cumulations IO Statistics Type Input Output Hello 0 86 DB Description 0 0 Link-State Req 0 0Link-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.



61

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 ] commandto check the IP addresses of the interfaces on the two devices.

l If the IP addresses of the two devices are on different network segments, run the ipaddress command to change these IP addresses to ensure that they are on the samenetwork 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 thetwo interfaces must be consistent. Otherwise, the OSPF neighbor relationship cannot beestablished.

l If the MTUs of the two interfaces are inconsistent, run the mtu mtu command in the interfaceview 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 mustexist to ensure that the DR can be elected correctly. Otherwise, the OSPF neighbor relationshipcan only reach the two-way state.

Run the display ospf interface command to view the interface priority.



Area: 0.0.0.0 (MPLS TE not enabled) Interface IP Address Type State Cost Pri 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 Process 1 with Router ID 1.1.1.1 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.



Area: 0.0.0.0 (MPLS TE not enabled) Interface IP Address Type State Cost Pri 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 Process 1 with Router ID 1.1.1.1 OSPF error statistics



62

General packet errors: 0 : IP: received my own packet 0 : Bad packet 0 : Bad version 0 : Bad checksum 0 : Bad area id 0 : Drop on unnumbered interface 0 : Bad virtual link 0 : Bad authentication type 0 : Bad authentication key 0 : Packet too small 0 : Packet size > ip length 0 : Transmit error 0 : Interface down 0 : Unknown neighborHELLO 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, theOSPF authentication types of the two devices that establish the neighbor relationshipare 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, thevalue of the Hello timers on the two devices that establish the neighbor relationship aredifferent. In this case, check the interface configurations of the two devices and set thesame value for the Hello timers.

l Check the Dead timer mismatch field. If the value of this field keeps increasing, thevalue of the dead timers on the two devices that establish the neighbor relationship aredifferent. In this case, check the interface configurations of the two devices and set thesame 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 deviceis 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

This section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure for the fault that prevents the OSFP neighbor relationship from entering the Full state.



63



l The link is faulty.

l The configurations of the OSPF neighbors are improper.


Figure 8-8 shows the troubleshooting flowchart for the fault that prevents the OSPF neighborrelationship from reaching the Full state.

Figure 8-8 Troubleshooting flowchart for the fault that prevents the OSPF neighbor relationshipfrom reaching the Full state

Perform the ping operation.




End

No

No

No

Yes

Yes Yes

No

Yes

Yes

No

Check the interface status. Is the fault rectified?

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

YesCheck the remote device and the link.

No

Yes


No

YesCheck 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?



64


NOTE





Procedure

Step 1 Troubleshoot the fault based on the status of the OSPF neighbor relationship.

l The status of the OSPF neighbor relationship cannot be displayed.

If the status of the OSPF neighbor relationship cannot be displayed, see The OSPF NeighborRelationship 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 cannotreceive Hello packets from the local device. In this case, check whether the link or the remotedevice 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 displayospf interface command to check whether the DR priorities of the interfaces enabledwith OSPF are 0.<Huawei> display ospf interface


Area: 0.0.0.0 (MPLS TE not enabled) Interface IP Address Type State Cost Pri 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 neighborrelationship 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 areexchanging 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 andreceiving of long packets. If the two devices fail to ping each other, solve the link problemfirst.

– The OSPF MTUs of the two devices are different.



65

If the ospf mtu-enable command is run on the OSPF interfaces, check whether theOSPF MTUs on the two interfaces are the same. If not, change the MTUs to ensure theyare the same.

If the fault persists, go to Step 2.l The neighbor relationship is always in the Exchange state.

If the status of the neighbor relationship is always displayed as Exchange, the two devicesare exchanging DD packets. In this case, perform troubleshooting as has been described whenthe 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.

NOTICERestarting OSPF causes the re-establishment of all the neighbor relationships in the OSPFprocess 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.

If the fault persists, go to Step 2.

Step 2 Collect the following information and contact Huawei.l Results of this troubleshooting procedurel Configuration files, log files, and alarm files of the devices

----End


Relevant AlarmsOSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

Relevant LogsNone

8.2.3 BGP TroubleshootingThis chapter describes common BGP faults and provides troubleshooting procedures.

8.2.3.1 BGP Peer Relationship Fails to Be EstablishedThis section describes the troubleshooting flow and provides a step-by-step troubleshootingprocedure 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:



66

l BGP packets fail to be forwarded.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 peerebgp-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 peerrelationship.



67

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



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


NoNo

YesYes

Is the displayed peer AS Number the same as the

remote number?

Change the AS number of the remote peer.


No

YesYes

Does BGP configurations affect the

establishment of the BGP peer relationship?

Modify the BGPconfigurations


NoNo

YesYes

No




68

NOTE





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 linktransmission 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 packetsize destination-ipv6-address command to detect theconnectivity 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 sizeof a Ping packet, you can check whether large Ping packets can be normally transmitted over thelink.

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 port179.

Run the display acl all command on the two devices to check whether an ACL isconfigured to filter the packets whose destination port is TCP port 179.

<Huawei> display acl allAdvanced ACL 3001, 2 rulesACL's step is 5ACL'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, runthe 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, ifthe IPv4 unicast peer relationship fails to be established, run the display bgp peercommand to check whether the peer router ID conflicts with the local router ID. The followingcommand 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



69

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 inthe BGP view to change the two router IDs to different values. Generally, a loopbackinterface 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 peerAS number is the same as the remote AS number.

<Huawei> display bgp peer BGP local router ID : 223.5.0.109 Local AS number : 41976 Total number of peers : 12 Peers in established state : 4

Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 8.9.0.8 4 100 1601 1443 0 23:21:56 Established 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 ASnumber.

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 tocheck the BGP configurations.

Item Description

peer connect-interface{ interface-type interface-number | ipv4-source-address }

If two devices use loopback interfaces to establishthe BGP peer relationship, run the peerconnect-interface command to specify thesource interface through which the BGP packetsare sent, and the source address with which theBGP connection is established.



70

Item Description

peer ebgp-max-hop hop-count When two directly connected devices use loopbackinterfaces to establish the EBGP peer relationshipor two indirectly connected devices establish theEBGP peer relationship, run the peer ebgp-max-hop command and specify the maximumnumber of hops between the two devices.l When two directly connected devices use

loopback interfaces to establish the EBGP peerrelationship, the hop count can be any numbergreater than 1.

l When two indirectly connected devicesestablish the EBGP peer relationship, specifythe number of hops according to the actualsituation.

NOTEThe peer ebgp-max-hop command must beconfigured on the devices on both ends.

peer valid-ttl-hops hops If the peer valid-ttl-hops hopscommand is configured, check whether the valueof hops is correct. The valid TTL range of thedetected packet is [255 - hops + 1, 255]. hopsspecifies the number of hops between the deviceson both ends. The hop count between the twodirectly connected devices is 1.NOTE

The peer valid-ttl-hops command must beconfigured on the devices on both ends.

peer route-limit limit If the peer route-limit limit command isconfigured, check whether the number of routessent by the peer exceeds the upper limit specifiedby limit. If the upper limit is exceeded, reducethe number of routes to be sent by the peer, and runthe reset bgp ip-address command to resetthe BGP peer relationship to trigger the re-establishment of the BGP peer relationship.

peer ignore If the peer ignore command is configured onthe peer, the peer is not required to establish atemporary BGP peer relationship with the localdevice. To establish the BGP peer relationshipbetween the peer and the local device, run theundo peer ignore command on the peer.



71

Item Description

Address family capability Check whether the address family capabilities ofthe devices on both ends match. For example, inorder to establish the BGP VPNv4 peerrelationship, the peer enable command mustbe configured in the BGP-VPNv4 address familiesof both devices. If the peer enable commandis configured on one device only, the BGP peerrelationship on the other device is displayed as Noneg.

Step 6 Collect the following information and contact Huawei.l Results of this troubleshooting procedurel Configuration files, log files, and alarm files of the devices

----End


Relevant AlarmsBGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Relevant LogsNone

8.2.3.2 BGP Public Network Traffic Is InterruptedThis section describes the troubleshooting flow and provides a step-by-step troubleshootingprocedure 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 networktraffic.



72

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

NoNo

YesYesIs the next hop of the route reachable?

Is the routing policy configured

correctly?

Does the number of routes exceed the upper

limit?




NOTE





Procedure

Step 1 Check whether the next hops of routes are reachable.



73

Run the display bgp routing-table network { mask | mask-length } commandon the local device that sends routes to check whether the target route is active and has been sentto 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 showsthat this route is valid and has been selected and sent to the peer at 3.3.3.3. The original nexthop 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

BGP local router ID : 23.1.1.2 Local AS number : 100 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 theIP routing table. If no route to the original next hop exists, the BGP route is not advertisedbecause its next hop is unreachable. Determine why there is no route to the original nexthop. 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 thatthis route is sent to the peer, perform Step 2 to check the outbound policy applied to thelocal 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-lengthcommand 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 thelocal 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 filter-policy ip-prefix aaa import filter-policy ip-prefix aaa export peer 1.1.1.1 enable peer 1.1.1.1 filter-policy acl-name acl-name import peer 1.1.1.1 filter-policy acl-name acl-name export



74

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 checkwhether 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 peerdestination-address command or the display current-configuration configurationbgp | include peer group-name command on the peer to check whether an upper limit on thenumber 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 recordedafter 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 as-number 100 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 thecommand output.

<Huawei> display current-configuration configuration bgp | include peer 1.1.1.1 peer 1.1.1.1 as-number 100 peer 1.1.1.1 group IBGP peer 1.1.1.1 enable peer 1.1.1.1 group IBGP

In this case, run the display current-configuration configuration bgp | includepeer 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 whentraffic is interrupted, the target route is dropped because the upper limit is exceeded. When thisoccurs, increase the upper limit.

NOTE

Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peerrelationship. Therefore, reduce the number of sent routes by configuring route summarization on the localdevice.

Step 4 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



75


Relevant AlarmsBGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed

Relevant LogsNone

8.2.3.3 BGP Private Network Traffic Is InterruptedThis section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure 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 privatenetwork traffic for the fault that interrupts BGP private network traffic.



76

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

YesNo

Correctly configure the routing policy

NoYes

No Yes

Yes

Ensure that they match

No

Yes

No Yes


Reduce the number of routes or increase the upper limit of routes

Reduce the number of 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?






No




77


NOTE





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 routesto 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 localPE.

l If the target route exists, check whether it is active. The following is an example in whichthe 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 nexthop 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

BGP local router ID : 20.1.1.2 Local AS number : 100 Paths: 1 available, 1 best, 1 select BGP routing table entry information of 1.1.1.1/32: From: 20.1.1.1 (1.1.1.1) Route Duration: 00h00m03s Relay IP Nexthop: 20.1.1.2 Relay IP Out-Interface: Vlanif50 Original nexthop: 3.3.3.3 Qos information : 0x0 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 theIP routing table. If no route to the original next hop exists, the BGP route is not advertisedbecause its next hop is unreachable. Determine why there is no route to the original nexthop.

l If the target route is valid and the best one available but there is no information indicatingthat this route is sent to the remote PE, perform Step 2 to check the outbound policy appliedto 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 targetroute.



78

– If the remote PE has received the target route, perform Step 1 again to check whetherthe 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 inboundpolicy of the remote PE.

Step 2 Check whether the routing policies are configured correctly.

Run the display current-configuration configuration bgp command on thelocal 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 thistroubleshooting case because the private network traffic is interrupted.

<Huawei> display current-configuration configuration bgp#bgp 100 peer 1.1.1.1 as-number 200 # ipv4-family unicast peer 1.1.1.1 enable # ipv4-family vpnv4 policy vpn-target peer 1.1.1.1 enable peer 1.1.1.1 filter-policy acl-name acl-name import peer 1.1.1.1 filter-policy acl-name acl-name export peer 1.1.1.1 as-path-filter 1 import peer 1.1.1.1 as-path-filter 1 export peer 1.1.1.1 ip-prefix prefix-name import peer 1.1.1.1 ip-prefix prefix-name export peer 1.1.1.1 route-policy policy-name import peer 1.1.1.1 route-policy policy-name export # ipv4-family vpn-instance vpna peer 10.1.1.1 as-number 300 peer 10.1.1.1 filter-policy acl-name acl-name import peer 10.1.1.1 filter-policy acl-name acl-name export peer 10.1.1.1 as-path-filter 1 import peer 10.1.1.1 as-path-filter 1 export peer 10.1.1.1 ip-prefix prefix-name import peer 10.1.1.1 ip-prefix prefix-name export peer 10.1.1.1 route-policy policy-name import peer 10.1.1.1 route-policy policy-name export#return

l If the inbound and outbound policies are configured on the two devices, check whether thetarget route fails to be transmitted because it is filtered by these policies. For detailedconfigurations 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 atunnel.

In the following example, the target route is a route to 50.1.1.2/32. If the Relay Tunnel Namefield 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.2BGP local router ID : 2.2.2.2



79

Local AS number : 100 Total routes of Route Distinguisher(1:2): 1 BGP routing table entry information of 50.1.1.2/32: Label information (Received/Applied): 13316/NULL From: 1.1.1.1 (1.1.1.1) Route Duration: 00h00m08s Relay IP Nexthop: 20.1.1.1 Relay IP Out-Interface: Vlanif50 Relay Tunnel Name: ldp Original nexthop: 1.1.1.1 Qos information : 0x0 Ext-Community:RT <1 : 1> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Not advertised to any peer yet Total routes of vpn-instance vpna: 1 BGP routing table entry information of 50.1.1.2/32: Label information (Received/Applied): 13316/NULL From: 1.1.1.1 (1.1.1.1) Route Duration: 00h00m07s Relay Tunnel Name: ldp Original nexthop: 1.1.1.1 Qos information : 0x0 Ext-Community:RT <1 : 1> 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 fails to be iterated to a tunnel, check whether an associated tunnel existsor 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 importRT and export RT do not match.

Run the display current-configuration configuration vpn-instance command onthe local PE and remote PE to check whether the routes fail to be added to the VPN routing tableof the remote PE after being sent to the remote PE because the export RT of the local VPNinstance does not match the import RT of the remote VPN instance.

export-extcommunity indicates an export RT, and import-extcommunity indicatesan 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-extcommunityip 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 VPNinstance, 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.



80

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 vpnv4all routing-table ipv4-address [ mask | mask-length ] command to checkwhether the target route is assigned a VPN label.

If no Label information field in the command output exists, the labels may be insufficient. As aresult, 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

BGP local router ID : 10.1.1.2 Local AS number : 100 Total routes of Route Distinguisher(1:1): 1 BGP routing table entry information of 100.1.1.0/24: Imported route. Label information (Received/Applied): NULL/13312 From: 0.0.0.0 (0.0.0.0) Route Duration: 00h21m24s Direct Out-interface: NULL0 Original nexthop: 0.0.0.0 Qos information : 0x0 Ext-Community:RT <1 : 1> 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 BGP routing table entry information of 100.1.1.0/24: Imported route. From: 0.0.0.0 (0.0.0.0) Route Duration: 00h21m24s Direct Out-interface: NULL0 Original nexthop: 0.0.0.0 Qos information : 0x0 AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre 60 Not advertised to any peer yet

l If the labels are insufficient, run the apply-label per-instance command in theVPN 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 peerdestination-address command or the display current-configuration configurationbgp | include peer group-name command on the remote PE to check whether the upper limiton 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 recordedafter the remote PE receives five routes from the local PE at 1.1.1.1.

<Huawei> display current-configuration configuration bgp | include peer 1.1.1.1 peer 1.1.1.1 as-number 100 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 thecommand output.



81

<Huawei> display current-configuration configuration bgp | include peer 1.1.1.1 peer 1.1.1.1 as-number 100 peer 1.1.1.1 group IBGP peer 1.1.1.1 enable peer 1.1.1.1 group IBGP

In this case, run the display current-configuration configuration bgp | includepeer 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 whentraffic is interrupted, the target route is dropped because the number of routes received hasexceeded 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 peerrelationship. Therefore, reduce the number of sent routes by configuring route summarization on the localdevice.




----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 providestroubleshooting cases.



l The IPv4 BGP peer relationship cannot be established.



82

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 receivingORFs from a remote peer (route receiver). Run the display bgp peer ipv4-addressorf ip-prefix command. The command output does not contain any IP-prefix information.

The troubleshooting roadmap is as follows: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).




83

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



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?


YesConfigure 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




84

NOTE





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 theEstablished state.

l If the BGP peer relationship is not in the Established state, see detailed troubleshootingprocedures 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 innegotiating the BGP ORF capability.

Run the display current-configuration configuration bgp command on theBGP peers to check whether peer ipv4-address capability-advertise orf ip-prefix is configured in the IPv4 unicast address family view.

<Huawei> display current-configuration configuration bgp#bgp 100peer 7.1.1.1 as-number 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 receivemode, a device can receive ORFs; in both mode, a device can either send or receive ORFs. To enable adevice to receive ORF IP-prefix information, configure both or receive mode on the device and both orsend mode on its peer.

l If one peer is not configured with the BGP ORF function, enter the BGP IPv4 unicastaddress family view and run the peer ipv4-address capability-advertiseorf ip-prefix command to enable BGP ORF. If both or receive is specified when youconfigure the local peer, both or send must be specified when you configure the remotepeer.<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 peerrelationship, and run the display bgp peer ipv4-address verbose command



85

to check whether the BGP ORF capability is successfully negotiated. The command outputshows the ORF capabilities on both the local and remote peers.<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 andthe subsequent part shows the ORF capability configured on the local peer. The ORF capabilitysupported by non-Huawei devices is different from that defined in the RFC standard. Therefore, toenable Huawei devices to communicate with non-Huawei devices, new commands for compatibilityare added. Ensure that both BGP peers are configured with the same compatibility mode (eitherCisco-compatible or RFC-compatible).

l If both BGP peers are configured with the BGP ORF function and succeed in negotiatingthe 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 theremote peer to check whether peer ipv4-address ip-prefix ip-prefix-nameimport is configured in the IPv4 unicast address family view.

<Huawei> display current-configuration configuration bgp#bgp 100peer 7.1.1.1 as-number 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 unicastaddress family view, and run the peer ipv4-address ip-prefix ip-prefix-name import command to configure an import IP-prefix policy.<Huawei> system-view[~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 cannotreceive 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 theremote peer (route receiver).

Run the display ip ip-prefix ip-prefix-name command on the remote peer tocheck whether the prefix list corresponding to the import IP-prefix policy is configured.

<Huawei> display ip ip-prefix inInfo: 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> system-view[~Huawei] ip ip-prefix in index 10 permit 10.1.1.0 24



86

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 importIP-prefix policy is configured.

<Huawei> display ip ip-prefix inPrefix-list inPermitted 0Denied 0 index: 10 permit 10.1.1.0/24

This output shows that the prefix list in has been successfully configured. After completing thesesteps, if the local peer still cannot receive ORFs from the remote peer, go to Step 5.

Step 5 Collect the following information and contact Huawei.l Results of this troubleshooting procedurel Configuration files, log files, and alarm files of the device

----End


Relevant AlarmsBGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Relevant LogsBGP/6/BGP_PEER_STATE_CHG

8.3 IP MulticastThis chapter describes common causes of IP multicast faults and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.3.1 Multicast Traffic Cannot Be TransmittedThis section provides a step-by-step troubleshooting procedure for the fault that prevents IPmulticast 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



87

After Layer 3 multicast is configured, multicast traffic cannot be transmitted to users.

The troubleshooting roadmap is as follows:

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 beingtransmitted

Is the route tothe 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.

NoEnd

No

No

Yes

No

Yes

8.3.1.3 Troubleshooting Procedure

NOTE



l In two-phase validation mode, after commands are configured, the commit command needs to berun to commit the configurations.




88

Procedure

Step 1 Check whether the route to the multicast source is reachable.

Run the display ip routing-table ip-address command on the device to checkwhether 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 PIMinformation 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 4.

– If the PIM configurations are incorrect, perform the configurations again. Commonconfiguration errors include: failure to set up a PIM neighbor relationship, incorrect RPconfiguration, incorrect DR configuration, and PIM or IGMP not enabled on user-sideinterfaces.

l If upper-layer protocol entries are displayed but the fault persists, go to Step 3.

Step 3 Check whether the multicast forwarding table has been generated.

Run the display multicast ip fib command on the device to check whether themulticast forwarding table has been generated.

l If no entry is displayed, go to Step 4.

l If multicast forwarding entries are displayed but the fault persists, collect the entries andgo to Step 4.


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



89

8.3.2 The PIM Neighbor Relationship Remains DownThis section provides a step-by-step troubleshooting procedure for the fault that causes the PIMneighbor 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.l The PIM configurations on the interface are incorrect.


After the PIM network configuration is complete, the PIM neighbor relationship remains Down.




90

Figure 8-14 Troubleshooting flowchart for the fault that causes the PIM neighbor relationshipto remain Down

Enable PIM on the interface

Refer to the troubleshooting

of interface Down

Refer to the troubleshooting

of protocol 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 protocol status Up on the interface?

Is the interface physically Up?




91

NOTE





Procedure

Step 1 Check whether PIM is enabled on the interface.

Run the display current-configuration interface interface-typeinterface-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 enablePIM, run the multicast routing-enable command in the system view to enablethe 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-numbercommand to check whether the PIM status on the interface is Up.

l If the PIM status is Down, run the display interface interface-typeinterface-number command to check whether the physical status and protocol statusof the interface are both Up.

1. If the physical status (current state) is not Up, change the physical status go Up.2. If the protocol status (Line protocol current state) is not Up, change the protocol status

go Up. A probable cause is that an IP address has not been configured on the interface.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 GenerationIDs, and as a result, the PIM neighbor relationship cannot be set up. This case applies toHuawei devices that intercommunicate with non-Huawei devices.

Run the display current-configuration interface interface-typeinterface-number command to check whether any of these PIM configurations exists onthe interface.



92

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 LogPIMPRO/4/NBR_LOSS

8.3.3 MSDP Peers Cannot Generate Correct (S, G) EntriesThis section provides a step-by-step troubleshooting procedure for the fault that prevents theMSDP 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 theconfigurations 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, importpolicy, 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 generatecorrect (S, G) entries.




93

Figure 8-15 Troubleshooting flowchart for the fault that prevents the MSDP peers fromgenerating correct (S, G) entries

Are the MSDP Peer in theUp state?

The MSDP peers cannot generate correct

(S, G) entries.

Ensure that interfaces are correctly configured and peers are reachable through unicast routes.


No Yes

Seek technical support. End

Is SA cache enabled? Enable SA cache. Is the fault rectified?

Have any SAMessage reached the

MSDP peers?

Ensure that MSDP peers can receive SA

messages.


Are export policies configured on the

MSDP peers?

Remove or change the configurations of the

export policies.


Are import policies configured on the

MSDP peers?


import policies.


Is the currect MSDP peer an RP?

Change the configurations of the RP

or MSDP.


Are import-source policies configured on the

current MSDP peer?


import-source policies.


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



94


NOTE





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 peerrelationship 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 theMSDP 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 inthe 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 enableSA 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 ofthe SA cache.

l If no information is displayed, run the display msdp peer-status command tocheck 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 seewhether 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 outputis non-zero, the SA messages have reached the peers. Go to Step 4.



95

Step 4 Check whether any export policies are configured on the MSDP peers.


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-policyexport without any parameters, the MSDP peers are prevented from forwarding themessages received from the multicast source. In this case, run the undo peer peer-address sa-policy export command to delete the configurations of the exportpolicies.

– If the command output contains the configurations of the peer peer-address sa-policyexport 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) entriespermitted by the ACL. Check whether the ACL-related commands are running on theMSDP peers and the (S, G) entries are permitted by the ACL. You can run the undopeer peer-address sa-policy export command to delete the ACLconfigurations 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.


l If import policies are configured on the MSDP peers, perform the following:

– If the command output contains the configurations of the peer peer-address sa-policyimport without any parameters, the MSDP peers are prevented from receiving messagesfrom the multicast source. In this case, run the undo peer peer-address sa-policy import command to delete the configurations of the export policies.

– If the command output contains the configurations of the peer peer-address sa-policyimport acl advanced-acl-number with an ACL specified, the MSDP peers can receiveonly the (S, G) entries permitted by the ACL. Check whether the ACL-relatedcommands are running on the MSDP peers and the (S, G) entries are permitted by theACL. You can run the undo peer peer-address sa-policy importcommand 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 themulticast 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 theconfigurations of the RP or MSDP peer on the PIM-SM network to ensure that the MSDPpeer is an RP.



96

l If the MSDP peer is an RP, go to Step 8.

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 tofilter 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 viewthe 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 anyparameters, the MSDP peer is prevented from advertising multicast source information.Run the undo import-source command to delete the configurations of theseimport-source policies.

– If the command output contains the import-source acl acl-number with an ACLspecified, 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 todelete 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 AlarmsNone

Relevant LogNone

8.4 QoS

8.4.1 Priority Mapping TroubleshootingThis chapter describes common causes of priority mapping faults, and provides thecorresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4.1.1 Packets Enter Incorrect QueuesThis section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure to use when packets enter incorrect queues.



97


This fault is commonly caused by one of the following: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.





98

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 thereconfigurations affecting

packet enqueuing in the VLAN?

Yes Delete or modify settings

Is fault rectified?


Is fault rectified?

Are thereconfigurations affecting

packet enqueuing in the system?


Is fault rectified?

Seek technical support End

Yes

No

No

Yes

Yes

Yes

Yes

No

No

No

NoNo



99


ContextNOTE





Procedure

Step 1 Check that the priority mapping configured in the DiffServ domain of the inbound interface iscorrect.Run the display this command in the interface view in the inbound direction and checkthe configuration of the trust upstream command. If the trust upstream commandis not used, the system trusts the DiffServ domain default by default. Then, run the displaydiffserv domain ds-domain-name command to check whether the priority mappingconfigured in the DiffServ domain is correct.

l If not, run the ip-dscp-inbound or 8021p-inbound command to correctly configurepriority mapping.

l If so, go to step 2.

Step 2 Check whether there are configurations affecting the queues that packets enter on the inboundinterface.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 systemsends packets to queues based on the re-marked local priorities.

l If the trust upstream none command is used, priorities of incoming packets are notmapped 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 innercommand is not used on the interface, all the incoming packets enter queues based on thedefault priority of the interface.

Run the display this command in the inbound interface view to check whether there areconfigurations 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 thatpackets belong to.The following configurations affect the queues that packets enter:



100

l If the traffic-policy command that defines remark local-precedence is used, the systemsends packets to queues based on the re-marked local priorities.

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 whetherthe 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.The following configurations affect the queues that packets enter:

l If the qos local-precedence-queue-map command is used, the system sends packets toqueues 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, thesystem 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 mapsthe re-marked priorities of packets to PHBs and sends the packets to queues based on thePHBs.

Run the display current-configuration command to check whether the configurations affectingthe 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

This section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure to use when priority mapping results are incorrect.





101

l On the inbound interface, packets do not enter queues corresponding to the priority ofpackets.

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.

8.4.1.2.2 Troubleshooting FlowchartFigure 8-17 shows the troubleshooting flowchart.

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?

NoCorrectly 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?


Yes

Yes

Yes

Yes

Yes

No

No

NoNo

Are there settings affecting priority mapping in

the VLAN?

Yes Delete or modify settings Is fault rectified?

Yes

No No



102


ContextNOTE





Procedure

Step 1 Check whether packets enter correct queues on the outbound interface.Run the display qos queue statistics interface interface-typeinterface-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 EnterIncorrect 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 checkwhether the trusted priority type set by using the trust command on the inbound or outboundinterface is correct. (If the trust command is not used, the system trusts the 802.1p priority inthe outer VLAN tag by default.)l If not, run the trust command to correctly configure the priority type trusted by the

inbound/outbound interface.l If so, go to step 3.

Step 3 Check whether there are configurations affecting priority mapping on the inbound or outboundinterface.

The following configurations affect the queues that packets enter: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 checkwhether the configurations affecting priority mapping are performed on the inbound or outboundinterface.l If so, delete or modify the configuration.l If not, go to step 4.



103

Step 4 Check whether there are configurations affecting priority mapping in the VLAN that packetsbelong 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 packetsto queues based on the mapped local priorities.

Run the display this command in the view of the VLAN that packets belong to and checkwhether the configurations affecting packet enqueuing are performed in the VLAN.






----End


Relevant Alarms

None.

Relevant Logs

None.

8.4.2 Traffic Policing TroubleshootingThis chapter describes common causes of traffic policing faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4.2.1 Interface-based Traffic Policing Results Are Incorrect

This section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure 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.





104

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

parametersIs fault rectified?


Yes

Yes

Yes

Yes

No

No


ContextNOTE





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 carinbound command is used.

l If not, run the qos car inbound command to configure the QoS CAR correctly.




105

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 TroubleshootingThis chapter describes common causes of traffic shaping faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4.3.1 Traffic Shaping Results of Queues Are Incorrect

This section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure 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 fortraffic shaping in queues on the interface. As a result, the bandwidth of traffic shaping inqueues cannot be ensured.

l Packets do not enter queues configured with traffic shaping because the configuration isincorrect. 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.



106





107

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?

NoEnsure 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


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



108


ContextNOTE





ProcedureStep 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 queueshaping command is used.

l If traffic shaping parameters of queues are set incorrectly or not set, run the qos queueshaping command to set the parameters correctly.

l If traffic shaping parameters of queues are set and the CIR value for traffic shaping on aninterface 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 aninterface 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 CIRvalues for traffic shaping in queues on the interface.

Compare the CIR value for interface-based traffic shaping with the sum of CIR values of trafficshaping in queues on the interface:

l If the CIR value of traffic shaping on an interface is smaller than the sum of CIR values oftraffic shaping in queues on the interface, the bandwidth required by queues on the interfacecannot be guaranteed. The traffic shaping result may be incorrect. In this case, run the qoslr outbound and qos queue shaping commands to modify related parameters sothat the CIR value of traffic shaping on an interface is greater than the sum of CIR values oftraffic 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 fortraffic 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 valueis smaller than the specified CIR value for queue shaping, queue shaping uses the CIR valuefor interface-based traffic policing.

Run the display this command in the inbound interface view to check whether theqos car inbound command is run on the inbound interface and whether its CIR valueis smaller than the CIR value for queue shaping.



109

l If the qos car inbound command is used and the CIR value is smaller than theCIR value for queue shaping, disable interface-based traffic policing or modify theconfiguration so that the CIR value for interface-based traffic policing is greater thanthe CIR value for queue shaping.

l If the qos lr inbound command is not run or this command is run but the CIR valueof 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 theCIR 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, andVLAN view to check whether the traffic-policy command is used:

l If the traffic-policy command is run, run the display traffic policycommand to check whether a CIR value is defined in the traffic policy and whether theCIR value is smaller than the CIR value for queue shaping.

– If the CIR value is set, run the display traffic policy command to checkwhether traffic in queues matches the traffic classifier in the configured trafficpolicy. If traffic in queues matches the traffic classifier, delete the CIR value definedin the traffic policy or modify the configuration so that the CIR value in the trafficpolicy is greater than the CIR value for queue shaping. If traffic in queues does notmatch 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-typeinterface-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 PacketsEnter 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 step6.

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 usedby each queue on the interface.

l If qos pq and qos wrr or qos drr are configured in each queue, the queue uses thecombined scheduling mode.

In combined scheduling mode, if no bandwidth limit is configured for PQ queues, trafficshaping of WRR or DRR queues is affected when PQ queues contain a large number ofpackets. This is because queue shaping is configured on WRR or DRR queues. Run theqos { pq | drr | wrr }, qos queue queue-index wrr weight weight, or qosqueue queue-index drr weight weight command to reconfigure the schedulingmode and parameters of each queue, reducing packets entering PQ queues.



110

l If each queue uses the scheduling mode of qos pq or qos wrr/drr, go to step 6.

Step 6 Collect the following information and contact Huawei technical support personnel:l Results of the preceding troubleshooting procedurel Configuration file, logs, and alarms of the device

----End


Relevant AlarmsNone.

Relevant LogsNone.

8.4.4 Congestion Avoidance TroubleshootingThis chapter describes common causes of congestion avoidance faults, and provides thecorresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4.4.1 Congestion Avoidance Fails to Take EffectThis section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure to use when congestion avoidance fails to take effect.


This fault is commonly caused by one of the following: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.





111

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 foran interface or a queue?

Queue


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



112


ContextNOTE





Procedure

Step 1 Check whether the WRED drop profile is configured on an interface or in a queue on theinterface.

Run the display this command in the interface view to check whether the qos wred orqos queue wred command is used.

l If not, run the qos wred command to configure a WRED drop profile on the interface orrun 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 correctlyin 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 tostep 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 packetstatistics 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 tostep 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 faultaccording 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 followingconfigurations are performed on the interface.

1. Check whether the traffic-policy command is used on the interface.



113

l If the traffic-policy command is used, run the display trafficpolicy command to view the actions in the traffic policy. Check whether car withservice-class specified or remark local-precedence is configured.

– If car is configured but service-class is not specified, run the car command withservice-class specified in the traffic behavior view.

– If remark local-precedence is configured but color is not specified, run theremark local-precedence command with color specified.

– If car or remark local-precedence is configured and relevant coloringparameters 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 coloredgreen). 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 packetsaccording to the mapping from packet priorities to colors in the DiffServ domain. If thetrust upstream command is not used on the interface, the system trusts the DiffServdomain default by default, and colors packets according to the mapping from packetpriorities to colors in the DiffServ domain default. Run the display diffservdomain ds-domain-name command to check whether the mapping from packetpriorities to colors is correct.

l If the mapping is incorrect, run the 8021p-inbound or ip-dscp-inboundcommand 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.



114

8.4.5 Congestion Management TroubleshootingThis chapter describes common causes of congestion management faults, and provides thecorresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

8.4.5.1 Congestion Management Fails to Take EffectThis section describes the troubleshooting flowchart and provides a step-by-step troubleshootingprocedure to use when congestion management fails to take effect.


This fault is commonly caused by one of the following: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, congestionmanagement fails to take effect. Follow procedures shown in the troubleshooting flowchart inFigure 8-21 or Figure 8-22.



115

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?


Yes

Yes

Yes

Yes

Yes

No

No

Do packets enter correct queues? Is fault rectified?

No See “Packets Enter

Incorrect Queues”

NoYes



116

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?


Yes

Yes

Yes

No

Do packets enter correct queues? Is fault rectified?

NoSee

“Packets Enter

Incorrect Queues”

NoYes


ContextNOTE





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 schedulingmode is correct.



117

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 coreservices 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 queuesand 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 andnon-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 averagelength differs a lot, DRR scheduling is used.

l If the queue scheduling mode is incorrect, run the qos { pq | wrr | drr } command toreconfigure 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 isgreater 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. Ensurethat 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 qosqueue statistics command to view statistics on queues. Check whether packets enterqueues corresponding to the scheduling mode in step 1.

l If packets enter incorrect queues, locate the fault according to 8.4.1.1 Packets EnterIncorrect Queues.

l If packets enter correct queues, go to step 4.

Step 4 Collect the following information and contact Huawei technical support personnel:l Results of the preceding troubleshooting procedurel Configuration file, logs, and alarms of the device

----End


Relevant AlarmsNone.

Relevant LogsNone.

8.5 Device Management



118

8.5.1 Stacking TroubleshootingThis section describes common causes of Stacking faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures.

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.



119

Figure 8-23 Troubleshooting flowchart for the failure to set up a stack

A stack cannot be set up


Are stack cables connected properly?

Connect stack cables properly

Yes

NoIs 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







120

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 switcheshave 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 memberswitches.

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 isavailable 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 memberports 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 portsare in Up state.

l If any physical member port is Down, rectify the fault according to 6.4 InterfaceTroubleshooting.

l If physical member ports are Up, go to step 5.

Step 5 Check fault event information in the stack.

Run the display stack troubleshooting command to check fault event informationin the stack. The command output shows some reasons why the stack fails to be set up.

NOTE

In V100R001, the command can only be used in the diagnosis view.

Step 6 Collect the following information and contact Huawei technical support personnel.l Results of the preceding troubleshooting procedurel Configuration file, logs, and alarms of the device

----End


Relevant AlarmsNone



121

Relevant LogsNone

8.5.1.2 Active/Standby Switchover Cannot Be Performed in a Stack


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





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 masterand 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 theSwitchover 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.

Step 2 Collect the following information and contact Huawei technical support personnel.l Results of the preceding troubleshooting procedurel Configuration file, logs, and alarms of the device

----End



122


Relevant Alarms

None

Relevant Logs

None

8.6 DCN and Server ManagementThis chapter describes common causes of DCN and server management faults and provides thecorresponding troubleshooting flowcharts, troubleshooting procedures.

8.6.1 TRILL TroubleshootingThis section describes common causes of TRILL faults, and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures.

8.6.1.1 TRILL Neighbor Relationship Fails to Be Established

This section provides a troubleshooting flowchart and a detailed procedure to troubleshoot thefailure 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 linkare different.

l The types of the TRILL interfaces at the two ends of the link are different. Neighborrelationships 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.





123

Figure 8-24 Troubleshooting flowchart for the failure in establishing a TRILL neighborrelationship

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.


No


Modify the type of either interface so that the types of the interfaces at the two ends

are the same.


Check whether designated VLANs of the TRILL

interfaces at the two ends of the link are the same.

Yes

YesMake sure that Authentication configurations at the two

ends of the link are the same.


YesModify either designated VLAN so that designated

VLANs at the two ends of the link are the same.


Check whether TRILL receives and sends Hello

packets properly.

Make sure TRILL receives and sends Hello packets

properly.

No YesIs the fault rectified?

No

No

No

Yes




124

NOTE





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 verbosecommand to check Circuit State of the interface.

– If Down (CarrierVlan:Dn / Bandwidth:UP / TrillEnable:UP / MAC:Up) isdisplayed, run the display current-configuration configurationtrill command to check whether a carrier VLAN is configured. If no carrier VLANis configured, configure one and run the display trill interfaceverbose 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) isdisplayed, go to Step 2.

– If Down (CarrierVlan:UP / Bandwidth:Up / TrillEnable:Dn / MAC:Up) isdisplayed, check whether TRILL is enabled on the interface. If TRILL is not enabledon 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) isdisplayed, 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 ] ] commandto check the interface state.

l If Line protocol current state is not Up, diagnose the fault so that it is Up. For detailsabout how to troubleshoot the link fault, see "Physical Interconnection and interfaceprotocol Troubleshooting".

l If UP is displayed, go to Step 3.

Step 3 Check whether TRILL receives and sends Hello packets properly.



125

Run the display trill statistics packet [ interface interface-typeinterface-number ] command to check whether TRILL receives and sends Hello packetsproperly.

NOTE

By default, Hello packets are sent at an interval of 10s. Run the command each 10s and check whether thepacket statistics increase.

l If the statistics about received and sent packets remain unchanged, check whether there arediscarded TRILL packets. Run the debugging trill adjacency [ interfaceinterface-type interface-number ] command to check whether the interfacereceives and sends packets properly.

– If TRILL-ADJ: Sending Lan Level-1 IIH. (IfName=XXXX, LocalSnpa=XXXX) isdisplayed, the interface sends packets properly. If TRILL-ADJ: Sending Lan Level-1IIH. (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 notdisplayed, 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 atboth 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 twoends 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-numbercommand 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 relationshipcannot be established. A TRILL neighbor relationship can be established only when the interfaces at the twoends 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 interfaceso 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-typeinterface-number | include "trill authentication-mode" command oneach end to check the authentication configurations.

l If the authentication modes at the two ends are different, run the trillauthentication-mode command in the TRILL interface view to modify the



126

authentication mode of either end so that the authentication modes at the two ends are thesame.

l If the authentication passwords at the two ends are different, run the trillauthentication-mode command in the TRILL interface view to modify theauthentication password of either end so that the authentication passwords at the two endsare the same.

l If the authentication configurations at the two ends of the link are the same, go to Step 7.

Step 7 Check whether designated VLANs of the TRILL interfaces at the two ends of the link are thesame.

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 interfacesat the two ends are both P2P, the designated VLANs at the two ends must be the same. If thetypes of interfaces at the two ends are not P2P, the designated VLAN of the DRB must beconfigured as a carrier VLAN at the other end.

l If designated VLANs at the two ends of the link are different, run the trilldesignated-vlan vlan-id command to modify either designated VLAN so thatdesignated 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 DRBis 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 VLANof the DRB as a carrier VLAN.

l If designated VLANs of the TRILL interfaces at the two ends of the link are the same butthe neighbor relationship still cannot be established, go to Step 8.

Step 8 Collect the following information and contact Huawei technical support personnel.l Results of the preceding troubleshooting procedurel Configuration files, log files, and alarm files of the devices

----End


Relevant AlarmsNone

Relevant LogsNone

8.6.1.2 TRILL Traffic Failed to Be ForwardedThis section provides a troubleshooting flowchart and a detailed procedure to troubleshoot thefailure in forwarding TRILL traffic on a data center network.




127


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.l The interface that is added to the CE VLAN is not Up.l TRILL LSDBs are asynchronous on the network.





128

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.


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


Configure a CE VLAN.No Is the fault

rectified?

Check whether TRILL LSDBs are synchronous

on the network.

Yes

YesMake sure that the interface that is added to

the CE VLAN is Up.


Yes Reset TRILL.

NoIs 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 YesIs the fault rectified?

No

No

No

Yes




129

NOTE





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 isestablished.

l If the TRILL neighbor relationship fails to be established, see 8.6.1.1 TRILL NeighborRelationship 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 | includearea-authentication-mode command on each end to check the authenticationconfigurations.

l If the authentication modes at the two ends are different, run the area-authentication-mode command in the TRILL interface view to modify theauthentication mode of either end so that the authentication modes at the two ends are thesame.

l If the authentication passwords at the two ends are different, run the area-authentication-mode command in the TRILL interface view to modify theauthentication password of either end so that the authentication passwords at the two endsare 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 thenetwork.

l If nicknames conflict on the network (S/S or S/D is displayed in State), run thenickname nicknamevalue [ priority priorityvalue ] [ root-priorityrootpriorityvalue ] command in the TRILL view on the device whose nicknamehas been suppressed to modify the nickname so that there are no nickname conflicts on thenetwork.

l If there are no nickname conflicts on the network, go to Step 4.

Step 4 Check whether the CE VLAN is configured.



130

Run the display current-configuration configuration trill | includece-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.

l If the CE VLAN has been configured, run the display vlan command to check whetherthe configured CE VLAN is established, If the configured CE VLAN is not established,runthe vlan command to establish the VLAN.If the configured CE VLAN is alreadyestablished, 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 ] commandto 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 detailsabout how to troubleshoot the link fault, see "Physical Interconnection and interfaceprotocol 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 LSDBsare synchronous on the network.

l If TRILL LSDBs are asynchronous on the network, run the reset trill allcommand to reset TRILL.

l If TRILL LSDBs are synchronous on the network, go to Step 7.


----End


Relevant AlarmsNone

Relevant LogsNone

8.6.1.3 TRILL In-band NMS Fails to Manage RBsThis section provides a troubleshooting flowchart and a detailed procedure to troubleshoot whya TRILL in-band NMS fails to manage RBs on a data center network.




131


l No administrative VLAN is configured.l The administrative VLANs configured at the two ends are different.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.


See “TRILL Traffic Fails to Be Forwarded”.

END

Yes

Yes

No

No

Yes

Yes

No

Configure an Administrative VLAN.


No


Yes

Modify the administrative VLAN so that the

administrative VLANs configured at the two ends are the same.

No YesIf the fault rectified?

No

Check whether the administrative VLANs configured at the two ends

are the same.


NOTE







132

Procedure

Step 1 Check whether an administrative VLAN is configured.

Run the display current-configuration configuration trill | includeadmin-vlan command to check whether an administrative VLAN is configured.

l If no administrative VLAN is configured, run the admin-vlan vlan-id command toconfigure it.

l If an administrative VLAN has been configured, run the display vlan command tocheck whether the configured administrative VLAN is established, If the configuredadministrative VLAN is not established,run the vlan command to establish the VLAN.Ifthe 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 theadministrative 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 trillmroute [ 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.1.2 TRILL Traffic Failed to BeForwarded.

l If there are TRILL routes to the other end, go to Step 4.




----End


Relevant Alarms

None

Relevant Logs

None

8.6.1.4 TRILL Fails to Be Enabled on an Interface

This section provides a troubleshooting flowchart and a detailed procedure to troubleshoot thefailure in enabling TRILL on an interface on a data center network.



133



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.

Contact Huawei technical support personnel. END

No

NoNo

YesMake sure that the interface types at the

two ends are both P2P or non-P2P.


Yes

Check whether the interface is added to a non-TRILL

VLAN.Delete the VLAN.

Yes YesIs the fault rectified?

No

Check Whether the interface types at the two

ends are both P2P or non-P2P.


NOTE





Procedure

Step 1 Check the interface type.



134

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 tocheck 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 AlarmsNone

Relevant LogsNone



135

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 TracertThis section describes how to use Ping and Tracert commands to check network connectivityand locate network faults. The Ping command checks network connectivity and host reachabilityand the Tracert command tracks the gateways that packets pass through from the source hostto the destination host.

9.4 Traps

9.5 Logs

9.6 Packet Header Capturing Function

CloudEngine 6800&5800 Series SwitchesTroubleshooting 9 Common Fault Diagnostic Commands


136

9.1 display CommandsUsing display commands and understanding command functions are essential skills ofmaintenance engineers.

9.1.1 Overview

The display commands provide the following information:

l Current device statusl Neighbor device informationl Overall network informationl 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 canbe added behind these displayed keywords.

l Different device models or versions support different features. The keywords actually displayed maybe 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 ExpressionsA regular expression is a mode matching tool. It consists of common characters (such as lettersfrom a to z) and special characters (called meta-characters). The regular expression is a templateaccording to which you can search for the required string.



137

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 charactersCommon characters are used to match themselves in a string, including all upper-case andlower-case letters, digits, punctuations, and special symbols. For example, a matches theletter "a" in "abc", 202 matches the digit "202" in "202.113.25.155", and @ matches thesymbol "@" in "[email protected]".

l Special charactersSpecial characters are used together with common characters to match the complex orspecial string combination. Table 9-1 describes special characters and their syntax.

Table 9-1 Description of special characters

SpecialCharacters

Function Example

\ Defines an escape character, whichis used to mark the next character(common or special) as the commoncharacter.

\* matches "*".

^ Matches the starting position of thestring.

^10 matches "10.10.10.1" instead of"20.10.10.1".

$ Matches the ending position of thestring.

1$ matches "10.10.10.1" instead of"10.10.10.2".

* Matches the preceding element zeroor more times.

10* matches "1", "10", "100","1000", and so on.(10)* matches "null", "10", "1010","101010", and so on.

+ Matches the preceding element oneor more times.

10+ matches "10", "100", "1000",and so on.(10)+ matches "10", "1010","101010", and so on.

? Matches the preceding element zeroor one time.NOTE

Huawei datacom devices do not supportregular expressions with ?. Whenregular expressions with ? are enteredon Huawei datacom devices, helpfulinformation is provided.

10? matches "1" or "10".(10)? matches "null" or "10".



138

SpecialCharacters

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 canbe null. Both the expression and thesubexpression 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 theregular expression.

[123] matches the character 2 in"255".

[^xyz] Matches any character that is not inthe regular expression.

[^123] matches any character exceptfor "1", "2", and "3".

[a-z] Matches any character within thespecified range.

[0-9] matches any character rangingfrom 0 to 9.

[^a-z] Matches any character beyond thespecified range.

[^0-9] matches all non-numericcharacters.

_ Matches a comma ",", left brace "{",right brace "}", left parenthesis "(",and right parenthesis ")".Matches the starting position of theinput string.Matches the ending position of theinput string.Matches a space.

_2008_ matches "2008", "space2008 space", "space 2008", "2008space", ",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 regularexpression. 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 regularexpression. For example, abc^ matches "abc^".



139

– The special character "$" is placed at any position except for the end of the regularexpression. For example, 12$2 matches "12$2".

– A right parenthesis ")" or right bracket "]" is not paired with a corresponding leftparenthesis "(" 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 expressionsare subexpressions within parentheses.

l Combination of common and special charactersIn actual usage, regular expressions combine multiple common and special characters tomatch certain strings.

Specifying a Filtering Mode in a CommandNOTE

When filtering conditions are set to query output information, the first line of the command output startswith 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 thenumber of sections after using a filtering mode in the command output, and | ignore-case tomatches a string of case-insensitive characters. | count, | section, and | ignore-case can worktogether 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 theregular expression.Filter the character strings to be entered until the specified case-sensitive character stringis displayed. All the character strings following this specified character string are displayedon 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 characterstring, 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 effectin configuration sequence. A maximum of 32 regular expressions can be configured to filter the commandoutput.

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 donot match the regular expression 10GE|40GE. 10GE|40GE matches 10GE or 40GE.

<HUAWEI> display interface brief | exclude 10GE|40GEPHY: Physical*down: administratively down^down: standby



140

(l): loopback(s): spoofing(b): BFD down(e): EFM down(d): Dampening Suppressed(p): port alarm down(dl): DLDP downInUti/OutUti: input utility rate/output utility rateInterface PHY Protocol InUti OutUti inErrors outErrorsEth-Trunk2 down down 0% 0% 0 0Eth-Trunk27 up up 0.01% 0.01% 0 0MEth0/0/0 up up 0.01% 0.01% 0 0NULL0 up up(s) 0% 0% 0 0Vlanif2 down down -- -- 0 0Vlanif10 down down -- -- 0 0Vlanif20 down down -- -- 0 0Vlanif200 up up -- -- 0 0

Example 2: Run the display current-configuration command to display all the linesthat match the regular expression vlan.

<HUAWEI> display current-configuration | include vlanvlan batch 2 9 to 20 77 99 200 222 4091vlan 19 mux-vlanvlan 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 numberof lines that match the regular expression vlan.

<HUAWEI> display current-configuration | include vlan | countTotal 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 softwareinformation. The information helps you locate various faults.

The following table lists the commands used to collect fault information.



141

Item Command Description

Basicinformation

display diagnostic-information

This command collects basic systeminformation. It displays outputs ofmultiple display commands, includingdisplay device and displaycurrent-configuration. Executing thiscommand requires a long time. You canpress Ctrl+C to pause diagnosisinformation display on screen.

Deviceinformation

display device This command checks the status of aboard when the board worksabnormally. If the Status field displaysAbnormal, the board is not workingproperly.

Interfaceinformation

display interface This command displays variousinformation about an interface. You canrun this command to check interfaceconnection faults and statistics aboutdiscarded packets.

Versions display version This command displays versioninformation about the system software,MPU, and LPU. The versioninformation can help you locate faults.

Patchinformation

display patch-information This command displays system patchpackage information, including patchpackage version and name. Theinformation can help you locate faults.

Electroniclabelinformation

display device elabel This command displays the electroniclabel of a board. Electronic labelsidentify device hardware.

Devicestatus

display health This command displays informationabout the temperature, power supply,fan, power, CPU usage, memory usage,and storage medium usage of thedevice.

Currentconfigurations

display current-configuration This command displays allconfiguration information on a device.You can specify a regular expression toobtain the required configurationinformation.



142

Item Command Description

Savedconfigurations

display saved-configuration

If the device has been started and is notworking properly, run the displaysaved-configuration commandto check the device startupconfiguration in the file specified byrunning the startup saved-configuration command.

Run the display saved-configuration last command tocheck the system configurations savedlast time in the configuration file loadedduring the current startup.

Time display clock This command displays the currentsystem date and time.

User logs display logbuffer This command displays user logs in thelog buffer.

Alarms display trapbuffer This command displays informationrecorded in the trap buffer.

Memoryusage

display memory This command displays the memoryusage of a device.

CPUusage

display cpu This command displays the CPU usageof a device.

9.2 reset Commandsreset 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 bgpl 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 displayedin the display interface and display ip interface command output.



143

l The display interface command provides counters to collect statistics on sent and receivedLayer 2 packets. The reset interface counters command resets these counters.

l The display ip interface command provides counters to collect statistics on sent andreceived 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 displayinterface or display ip interface command to check whether packets are correctlysent and received on interfaces and whether a CRC error occurs. Then you can locate the interfacewhere the fault occurs.

The display command output shows packet statistics generated after the device starts or thecounter is reset; therefore, the packet statistics may contain unnecessary information thatinterferes 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 packetstatistics.

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 thestatistics.

----End

9.3 Ping and TracertThis section describes how to use Ping and Tracert commands to check network connectivityand locate network faults. The Ping command checks network connectivity and host reachabilityand the Tracert command tracks the gateways that packets pass through from the source hostto the destination host.

Introduction to the Ping Command

Based on the Internet Control Message Protocol (ICMP), the Ping command is used to checknetwork connectivity and host reachability. The source sends an ICMP Echo Request messageto the destination, and determines reachability. The source determines the quality of the linkfrom which the destination is reachable based on the number of sent ICMP Echo Requestmessages and received ICMP Echo Response messages, and the round-trip time (RTT) of pingpackets.



144

Ping Command FormatNOTE

CloudEngine 6800&5800 Series Switches Command Reference provides detailed description of commandparameters and usage. Here lists only some commonly used parameters and their descriptions.

ping [ ip ] [ -a source-ip-address | -c count | -f | -s packetsize | -ttimeout ] * host

l -a: specifies the source IP address for sending Echo Request messages. If no source IPaddress 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 canincrease the number of outgoing packets to detect the network quality based on the packetloss ratio.

l -f: indicates that packets are not fragmented when they are sent. The device discards thepackets 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 EchoRequest 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 performsDNS resolution and displays the resolved IP address.

NOTE

You can use the parameters -s and -f simultaneously to test the path MTU (PMTU). For example, if theping 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 isused 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 theping 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 Reply from 100.135.18.118: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 100.135.18.118: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 100.135.18.118: bytes=56 Sequence=3 ttl=255 time=2 ms Reply from 100.135.18.118: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 100.135.18.118: bytes=56 Sequence=5 ttl=255 time=2 ms --- 100.135.18.118 ping statistics --- 5 packet(s) transmitted



145

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.

l The time is 1 ms, indicating that the device receives an Echo Response message 1 ms afterit sends an Echo Request message. This parameter can be used as a reference to determinewhether the network is congested.

The device sends five ping packets by default. You can set a larger value of -c to accuratelydetect the network status. The device determines the network status based on the number of pingpackets returned.

Fault Description Possible Cause

All packets can reachthe destination butrequire a long time.

The intermediate network is unstable.QoS is deployed on the gateway, which lowers the forwarding speed.

No packet can reachthe 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 TTLvalue is reduced to 1.Packets are delayed due to network congestion.

Some packets cannotreach the destination.

Some ping packets are discarded on the unstable network.Load balancing is configured on the intermediate network and someping 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 commandtracks the gateways that packets pass through from the source host to the destination host. Thishelps check network connectivity and locate network faults. The tracert process is as follows:

1. The source host sends a UDP packet with TTL 1.

2. The first hop sends back an error ICMP packet, indicating that the packet cannot be sentdue 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 thepath to the destination host based on the source IP addresses of ICMP TTL-expired packets(ICMP6 hop limit-expired for an IPv6 packet).



146

Tracert Command FormatNOTE

CloudEngine 6800&5800 Series Switches Command Reference provides detailed description of commandparameters 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

l -a: specifies the source address. If this parameter is not specified, the IP address of theoutbound 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 sourcehost receives no TTL-expired packet. If a maximum TTL is set, the initial TTL must besmaller than the maximum TTL.

l -m: specifies the maximum TTL. The maximum TTL is usually set to the number of hopsthrough which a Tracert packet passes. If an initial TTL is set, the maximum TTL must belarger than the initial TTL.

l -q: specifies the number of UDP packets sent each time. You can increase this value toensure 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 indicatingTTL timeout, " * " is displayed. You are advised to increase the timeout interval when thenetwork 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 performsDNS resolution and displays the resolved IP address.

The tracert function varies with the operating system of a PC. The Windows operating systemis 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, andthree response time. * * * is displayed in the second line, indicating that the ping and tracertoperations are not supported on this node.

The Ping command can only determine whether the destination is reachable, whereas theTracert command can detect potential loops on a network. If you track an address and the sameaddress is displayed multiple times, a route loop occurs.



147

9.4 TrapsWhen faults occur or the system operates abnormally, alarms and events are triggered to helpusers fast detect and locate faults quickly.l Alarm

When the system operates abnormally, alarms are triggered to inform maintenancepersonnel of the device operating status.When a fault occurs, an alarm is triggered and the alarm trap is sent. After the fault isrectified, the alarm status changes from active to cleared and the clear alarm trap is sent. Ifan alarm trap is generated, a corresponding clear alarm trap will be generated after the faultis rectified.

l EventEvents are triggered by specific occurrences, and indicate anything that takes place on amanaged 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 defineddifferently 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



148

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 thetrap buffer on the command-line terminal window.

buffersize specifies the number of traps to be displayed on the command-line terminalwindow. 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 terminalwindow.

9.5 LogsDuring device operation, the log module records operations and events on the device. Therecorded operations and events are log messages.

The generated logs can be viewed through the Console port or Telnet, or stored to the log serverthrough the syslog protocol.

The syslog protocol is transmitted through UDP port 514. Any UDP datagram on port 514 isrecorded 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 FunctionThe packet header capturing function copies packet headers from a mirrored port to an observingport 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 aPC 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, Huaweidoes not capture packets for you. You must capture packets legally and with permission. Ensure that yourcustomers' privacy is protected when collecting communication information.

Packet headers can be mirrored to a local observing port or a remote observing port. The twomethods 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 directlyconnected observing device. As shown in Figure 9-2, the incoming packets on 10GE1/0/1 aremirrored to 10GE1/0/2, and the observing device directly connected to 10GE1/0/2 analyzes thepacket headers.



149

Figure 9-2 Networking diagram of local mirroring

Mirrored portObserving portPacket flowCopied packet flow

Monitoring device

Host SwitchA10GE1/0/1 10GE1/0/2

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> system-view[~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 toinbound.[~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 PortThe monitored device and the monitoring device are connected through a Layer 2 or Layer 3network.

l Across a Layer 2 networkImplement Layer 2 communication between the monitored device and the monitoringdevice. Packets passing through a mirrored port are tagged a VLAN ID and broadcast inthe remote mirroring VLAN through the observing port. The packets then reach themonitoring device.As shown in Figure 9-3, HostA connects to SwitchA through 10GE1/0/1. Server connects10GE1/0/2 of SwitchC. SwitchA and SwitchC interconnect through a Layer 2 network.



150

Figure 9-3 Networking diagram of Layer 2 remote port mirroring

10GE1/0/210GE1/0/2

10GE1/0/110GE1/0/1

VLAN2 VLAN2

SwitchA

SwitchB

SwitchC

10GE1/0/1 10GE1/0/2

HostA Server


Perform the following steps to mirror packet headers to a remote observing port.

1. Configure interfaces to implement Layer 2 communication between devices.<HUAWEI> system-view[~HUAWEI] sysname SwitchA[*HUAWEI] commit[~SwitchA] vlan batch 2 to 3[*SwitchA] interface 10ge 1/0/1[*SwitchA-10GE1/0/1] port default vlan 3[*SwitchA-10GE1/0/1] quit[*SwitchA] interface 10ge 1/0/2[*SwitchA-10GE1/0/2] port link-type trunk[*SwitchA-10GE1/0/2] port trunk allow-pass vlan 2[*SwitchA-10GE1/0/2] quit[*SwitchA] commit<HUAWEI> system-view[~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> system-view[~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



151

[*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] interface 10ge 1/0/1[~SwitchA-10GE1/0/1] port-mirroring observe-port 1 inbound[*SwitchA-10GE1/0/1] quit[*SwitchA] commit

l Across a Layer 3 networkEnsure that a reachable route exists between the monitored device and the monitoringdevice over a Layer 3 network. Packets passing through a mirrored port are encapsulatedwith GRE packet headers. The packets then reach the monitoring device through a Layer3 IP network.As shown in Figure 9-4, HostA connects to SwitchA through 10GE1/0/1. Server connectsto 10GE1/0/2 of SwitchB. A reachable route exists between HostA and Server over a Layer3 network.

Figure 9-4 Networking diagram of Layer 3 remote port mirroring

SwitchA

Server10.2.1.1/24

Network

SwitchB

HostA10.1.1.1/24

10GE1/0/1

10GE1/0/2

10GE1/0/2


Perform the following steps.

1. Ensure that a reachable routes exists between HostA and Server. The configurationprocedure is not mentioned here.

2. Configure 10GE1/0/2 on SwitchA as a Layer 3 remote observing port and configurethe destination IP address as the IP address of Server.



152

<HUAWEI> system-view[~HUAWEI] sysname SwitchA[*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] interface 10ge 1/0/1[~SwitchA-10GE1/0/1] port-mirroring observe-port 1 inbound[*SwitchA-10GE1/0/1] quit[*SwitchA] commit



153

10 Appendix: Indicators

About This Chapter

10.1 Fan Module Indicator

10.2 Power Indicators

CloudEngine 6800&5800 Series SwitchesTroubleshooting 10 Appendix: Indicators


154

10.1 Fan Module IndicatorFigure 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.



155

Table 10-1 Description of indicator on a FAN-40EA fan module

Number inFigure 10-1

Indicator Color Description

1 Fan statusindicator(STATUS)

Off The fan module is not running.

Green l Slow blinking: The fan module is workingand communicating normally with thesystem.

l Fast blinking: The fan module is workingbut is not communicating normally withthe system.

Red l Steady on: The fan module has a hardwarefault and needs to be replaced.

l Slow blinking: An alarm has beengenerated, and you need to handle itaccordingly. Common causes of thisalarms include errors of dual in-linepackage (DIP) switches, short-circuit, fanblades blocked, and fault of the fanmodule.

10.2 Power IndicatorsFigure 10-2 shows the panel of a CE6800/5800 power module.



156

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

NumberinFigure10-2

Indicator Color Description

1 STATUS Off The AC power input is abnormal (for example, no input,overvoltage, or undervoltage) or AC power output isabnormal (for example, overvoltage, overcurrent, short-circuit, or overtemperature).

Green Steady on: The power module is working normally.



157

Date post:	20-Jul-2016
Category:	Documents
Upload:	menganofulano
View:	65 times
Download:	1 times