Troubleshooting (V200R002C00 02) PDF

Huawei AR1200 Series Enterprise Routers
V200R002C00
Troubleshooting
Issue
02
Date
2012-03-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

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

Address:
Huawei Industrial Base

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

Copyright Huawei Technologies Co., Ltd.

Troubleshooting
About This Document
About This Document
Intended Audience
This document describes the procedure for troubleshooting various services supported by the
AR1200 in terms of common causes, flowchart, troubleshooting procedure, alarms and logs,
and case studies.
This document is intended for:
l
System maintenance engineers
Commissioning engineers
Network monitoring engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
Issue 02 (2012-03-30)
Indicates a hazard with a high level of risk, which if not

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

time.
NOTE
Provides additional information to emphasize or supplement

important points of the main text.

ii

Troubleshooting
About This Document
Command Conventions
The 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 by

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

vertical bars. One item is selected or no item is selected.
{ x | y | ... }*
Optional items are grouped in braces and separated by

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

vertical bars. Several items or no item can be selected.
&<1-n>
The parameter before the & sign can be repeated 1 to n times.
A line starting with the # sign is comments.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2012-03-30)

Based on issue 01 (2011-12-30), the document is changed as follows:
The following information is modified:
l
6.1.1 No Dial Tone Is Heard After Offhook
Troubleshooting Procedure
The following information is deleted:

l
Calling Number Is Not Displayed on the Called Party's Telephone
Busy Tone Is Heard After Offhook
Fax Service Fails
Changes in Issue 01 (2011-12-30)

Initial commercial release.
Issue 02 (2012-03-30)

iii

Troubleshooting
Contents
Contents
About This Document.....................................................................................................................ii
1 Hardware.........................................................................................................................................1
1.1 Board Registration Troubleshooting..................................................................................................................2
1.1.1 A Board Fails to Be Registered.................................................................................................................2
2 System..............................................................................................................................................5
2.1 CPU Troubleshooting.........................................................................................................................................6
2.1.1 CPU Usage Is High....................................................................................................................................6
2.2 Telnet Troubleshooting.....................................................................................................................................10
2.2.1 The User Fails to Log in to the Server Through Telnet...........................................................................10
2.3 SSH Troubleshooting.......................................................................................................................................13
2.3.1 The User Fails to Log in to the Server Through SSH.............................................................................13
2.4 Mirroring Troubleshooting...............................................................................................................................17
2.4.1 Monitoring Device Does Not Receive Any Mirrored Packet After Port Mirroring Is Configured.........17
2.4.2 Monitoring Device Does Not Receive Any Mirrored Packets After Traffic Mirroring Is Configured
..........................................................................................................................................................................20
2.4.3 Troubleshooting Cases............................................................................................................................23
2.5 PoE Troubleshooting........................................................................................................................................26
2.5.1 PSE Cannot Detect a PD.........................................................................................................................26
2.5.2 PSE Cannot Provide Power for a PD.......................................................................................................28
2.6 SNMP Troubleshooting....................................................................................................................................32
2.6.1 An SNMP Connection Cannot Be Established........................................................................................32
2.6.2 The NMS Fails to Receive Trap Messages from the Host......................................................................35
2.7 RMON Troubleshooting...................................................................................................................................37
2.7.1 NM Station Cannot Receive RMON Alarms..........................................................................................37
2.8 NQA Troubleshooting......................................................................................................................................40
2.8.1 A UDP Jitter Test Instance Fails to Be Started.......................................................................................40
2.8.2 A Drop Record Exists in the UDP Jitter Test Result...............................................................................42
2.8.3 A Busy Record Exists in the UDP Jitter Test Result...............................................................................43
2.8.4 A Timeout Record Exists in the UDP Jitter Test Result.........................................................................45
2.8.5 The UDP Jitter Test Result Is "Failed", "No Result" or "Packet Loss"...................................................47
2.9 NTP Troubleshooting.......................................................................................................................................49
2.9.1 The Clock is not Synchronized................................................................................................................49
2.10 CWMP Troubleshooting.................................................................................................................................50
Issue 02 (2012-03-30)

iv

Troubleshooting
Contents
2.10.1 Failed to Manage AR1200 Using CWMP.............................................................................................50
3 Physical Connection and Interfaces.........................................................................................54

3.1 Eth-Trunk Interface Troubleshooting...............................................................................................................55
3.1.1 Eth-Trunk Interface Cannot Forward Traffic..........................................................................................55
3.1.2 Troubleshooting Cases............................................................................................................................59
4 LAN................................................................................................................................................63
4.1 VLAN Troubleshooting....................................................................................................................................64
4.1.1 Users in a VLAN Cannot Communicate with Each Other......................................................................64
4.2 MAC Address Table Troubleshooting.............................................................................................................68
4.2.1 Correct MAC Address Entries Cannot Be Generated.............................................................................68
4.3 MSTP Troubleshooting....................................................................................................................................73
4.3.1 MSTP Topology Change Leads to Service Interruption.........................................................................73
4.4 Transparent Bridging Troubleshooting............................................................................................................79
4.4.1 Layer 2 Traffic Forwarding in a Bridge Group Fails..............................................................................79
4.4.2 Traffic Forwarding in IP Routing of Bridge Groups Fails......................................................................82
4.5 WLAN Troubleshooting...................................................................................................................................86
4.5.1 A STA Fails to Discover Radio Signals..................................................................................................86
4.5.2 WLAN Users Are Frequently Logged Out..............................................................................................90
5 WAN...............................................................................................................................................94
5.1 E1/T1 Troubleshooting.....................................................................................................................................95
5.1.1 E1/T1 Interface in Up State Fails to Correctly Send and Receive Data..................................................95
5.2 FR Troubleshooting..........................................................................................................................................99
5.2.1 Local Device Fails to Ping the Remote Device When the Link Protocol Status of Their Connected FR
Interfaces Is Up.................................................................................................................................................99
5.2.2 Troubleshooting Cases..........................................................................................................................106
5.3 MFR Troubleshooting....................................................................................................................................106
5.3.1 Local Device Fails to Ping the Remote Device When the Link Protocol Status of Their Connected MFR
Interfaces Is Up...............................................................................................................................................107
5.4 DCC Troubleshooting.....................................................................................................................................113
5.4.1 Failed to Initiate Calls............................................................................................................................113
5.4.2 Failed to Receive Calls..........................................................................................................................117
5.5 ISDN Troubleshooting...................................................................................................................................121
5.5.1 Link Failed to Be Established on ISDN Interfaces................................................................................121
5.6 PPPoE Troubleshooting..................................................................................................................................127
5.6.1 PPPoE Dialup Fails...............................................................................................................................127
5.7 PPP Troubleshooting......................................................................................................................................131
5.7.1 Protocol Status of a PPP Interface Is Down..........................................................................................131
5.8 xDSL Troubleshooting...................................................................................................................................136
5.8.1 Packets Fail to Be Forwarded on an ADSL Interface Working in ATM Mode....................................137
5.8.2 Packets Fail to Be Forwarded on a G.SHDSL Interface Working in ATM Mode................................141
5.9 3G Troubleshooting........................................................................................................................................146
Issue 02 (2012-03-30)


Troubleshooting
Contents
5.9.1 3G Calls Failed After Dialing Parameters Were Correctly Set.............................................................146
6 Voice.............................................................................................................................................152
6.1 Voice Service Troubleshooting......................................................................................................................153
6.1.1 No Dial Tone Is Heard After Offhook...................................................................................................153
6.1.2 Call Quality Is Low...............................................................................................................................155
6.1.3 A Call Fails to Be Connected................................................................................................................157
6.1.4 A SIP AG Cannot Work Properly.........................................................................................................160
7 IP Forwarding and Routing.....................................................................................................163

7.1 A Ping Operation Fails...................................................................................................................................164
7.1.1 The Ping Operation Fails.......................................................................................................................164
7.2 DHCP Troubleshooting..................................................................................................................................174
7.2.1 A Client Cannot Obtain an IP Address (the AR1200 Functions as the DHCP Server)........................174
7.2.2 A Client Cannot Obtain an IP Address (the AR1200 Functions as the DHCP Relay Agent)...............179
7.3 RIP Troubleshooting.......................................................................................................................................182
7.3.1 Device Does not Receive Partial or All the Routes...............................................................................183
7.3.2 Device Does not Send Some or All Routes...........................................................................................186
7.4 OSPF Troubleshooting...................................................................................................................................190
7.4.1 The OSPF Neighbor Relationship Is Down..........................................................................................190
7.4.2 The OSPF Neighbor Relationship Cannot Reach the Full State...........................................................195
7.4.3 Trouble Cases........................................................................................................................................199
7.5 BGP Troubleshooting.....................................................................................................................................205
7.5.1 The BGP Peer Relationship Fails to Be Established.............................................................................205
7.5.2 BGP Public Network Traffic Is Interrupted..........................................................................................211
7.5.3 BGP Private Network Traffic Is Interrupted.........................................................................................214
7.5.4 Trouble Cases........................................................................................................................................221
8 Multicast......................................................................................................................................234
8.1 Layer 3 Multicast Troubleshooting................................................................................................................235
8.1.1 Multicast Traffic Is Interrupted.............................................................................................................235
8.1.2 The PIM Neighbor Relationship Remains Down..................................................................................238
8.1.3 The RPT on a PIM-SM Network Fails to Forward Data.......................................................................241
8.1.4 The SPT on a PIM-SM Network Fails to Forward Data.......................................................................245
8.1.5 MSDP Peers Cannot Generate Correct (S, G) Entries...........................................................................250
8.1.6 The Multicast Device Cannot Generate IGMP Entries or MLD Entries...............................................255
9 QoS...............................................................................................................................................260
9.1 Traffic Policy Troubleshooting......................................................................................................................261
9.1.1 Traffic Policy Fails to Take Effect........................................................................................................261
9.2 Priority Mapping Troubleshooting.................................................................................................................264
9.2.1 Packets Enter Incorrect Queues.............................................................................................................264
9.2.2 Priority Mapping Results Are Incorrect................................................................................................267
Issue 02 (2012-03-30)

vi

Troubleshooting
Contents
9.3 Traffic Policing Troubleshooting...................................................................................................................274

9.3.1 Traffic Policing Based on Traffic Classifiers Fails to Take Effect.......................................................274
9.3.2 Interface-based Traffic Policing Results Are Incorrect.........................................................................275
9.4 Traffic Shaping Troubleshooting....................................................................................................................279
9.4.1 Queue-based Traffic Shaping Results Are Incorrect.............................................................................279
9.5 Congestion Avoidance Troubleshooting........................................................................................................284
9.5.1 Congestion Avoidance Fails to Take Effect..........................................................................................284
9.6 Congestion Management Troubleshooting.....................................................................................................287
9.6.1 Congestion Management Fails to Take Effect......................................................................................287
10 Security......................................................................................................................................293
10.1 AAA Troubleshooting..................................................................................................................................294
10.1.1 RADIUS Authentication Fails.............................................................................................................294
10.1.2 HWTACACS Authentication Fails.....................................................................................................299
10.1.3 Troubleshooting Cases........................................................................................................................305
10.2 ARP Security Troubleshooting.....................................................................................................................311
10.2.1 The ARP Entry of an Authorized User Is Maliciously Modified........................................................311
10.2.2 The Gateway Address Is Maliciously Changed..................................................................................314
10.2.3 User Traffic Is Interrupted by a Large Number of Bogus ARP Packets.............................................316
10.2.4 IP Address Scanning Occurs...............................................................................................................318
10.2.5 ARP Learning Fails.............................................................................................................................321
10.3 NAC Troubleshooting..................................................................................................................................324
10.3.1 802.1x Authentication of a User Fails.................................................................................................324
10.3.2 MAC Address Authentication of a User Fails.....................................................................................328
10.3.3 MAC Address Bypass Authentication of a User Fails........................................................................332
10.4 Firewall Troubleshooting.............................................................................................................................332
10.4.1 SYN Flood Attacks Are Detected on a Network.................................................................................332
10.5 ACL Troubleshooting...................................................................................................................................334
10.5.1 Packet Filtering Firewall Fails Because of Invalid ACL Configuration.............................................334
10.6 NAT Troubleshooting...................................................................................................................................336
10.6.1 Internal Users Fail to Access the Public Network...............................................................................336
10.6.2 External Hosts Fail to Access Internal Servers...................................................................................339
10.6.3 Internal Host with a Conflicting IP Address Fails to Access an External Server................................342
10.7 PKI Troubleshooting....................................................................................................................................346
10.7.1 Failed to Obtain a CA Certificate........................................................................................................346
10.7.2 Failed to Obtain a Local Certificate.....................................................................................................349
10.7.3 Failed to Obtain a CRL........................................................................................................................350
11 Reliability..................................................................................................................................353
11.1 Interface Backup Troubleshooting...............................................................................................................354
11.1.1 Interface Backup Fails to Take Effect.................................................................................................354
Issue 02 (2012-03-30)

vii

Troubleshooting
Contents

11.2 BFD Troubleshooting...................................................................................................................................359
11.2.1 BFD Session Cannot Go Up................................................................................................................359
11.2.2 Interface Forwarding Is Interrupted After a BFD Session Detects a Fault and Goes Down...............362
11.2.3 Changed BFD Session Parameters Do Not Take Effect......................................................................364
11.2.4 Dynamic BFD Session Fails to Be Created.........................................................................................366
11.3 VRRP Troubleshooting................................................................................................................................368
12 MPLS..........................................................................................................................................373
12.1 MPLS LDP Troubleshooting........................................................................................................................374
12.1.1 LDP Session Flapping.........................................................................................................................374
12.1.2 LDP Session Goes Down....................................................................................................................376
12.1.3 LDP LSP Flapping...............................................................................................................................379
12.1.4 LDP LSP Goes Down..........................................................................................................................380
13 VPN............................................................................................................................................385
13.1 GRE Troubleshooting...................................................................................................................................386
13.1.1 Failed to Ping the IP Address of the Remote Tunnel Interface...........................................................386
13.2 L3VPN Troubleshooting..............................................................................................................................392
13.2.1 VPN Users Cannot Communicate.......................................................................................................392
13.3 IPSec Troubleshooting.................................................................................................................................395
13.3.1 SAs Fail to Be Established Manually..................................................................................................395
13.3.2 SAs Fail to Be Established by Using IKE Negotiation.......................................................................399
13.3.3 IPSec Fails to Be Configured by Using an IPSec Policy Template....................................................406
13.3.4 NAT Traversal in IPSec Fails..............................................................................................................413
13.3.5 GRE over IPSec Fails..........................................................................................................................420
13.3.6 Failed to Establish an SA Using an IPSec Tunnel...............................................................................427
13.4 SSL VPN Troubleshooting...........................................................................................................................434
13.4.1 Users' Unsuccessful Login to the SSL VPN Gateway........................................................................434
13.5 DSVPN Troubleshooting..............................................................................................................................438
13.5.1 A Spoke Fails to Register with a Hub.................................................................................................438
13.5.2 Spokes Fail to Learn Routes from Each Other....................................................................................441
13.5.3 Spokes Fail to Communicate When They Have Only Summarized Routes to a Hub.........................445
Issue 02 (2012-03-30)

viii

Troubleshooting
1 Hardware
Hardware
About This Chapter

1.1 Board Registration Troubleshooting
Issue 02 (2012-03-30)


Troubleshooting
1 Hardware
1.1 Board Registration Troubleshooting

1.1.1 A Board Fails to Be Registered
Common Causes
This fault is commonly caused by one of the following:
l
The board is starting.
The board was reset.
Troubleshooting Flowchart
The troubleshooting roadmap is as follows:
l
Check whether the board is starting.
Check whether the board is in an unregistered state after the board has finished startup.
Check whether the board was reset. If the board was reset, locate the cause.
Figure 1-1 shows the troubleshooting flowchart.
Issue 02 (2012-03-30)


Troubleshooting
1 Hardware
Figure 1-1 A board fails to be registered
A board
fails to be
registered
Wait for the board Yes

to complete
startup
Is board
starting?
No
Was board
reset?
No
Yes
Locate fault
according to
instructions
Yes
Is fault
rectified?
No
Seek
technical
support
Yes
End
NOTE
Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
you will have a record of your actions to provide to Huawei technical support personnel.
Procedure
Step 1 Check whether the board is starting.
A board takes several minutes to complete registration after power-on. This period is called the
startup time. The startup times for specific boards are follows:
l The startup time of the SRU is less than 3 minutes. If the device restarts after the system
software is upgraded, the startup time is less than 5 minutes.
l The startup time of an LPU is less than 5 minutes. If the LPU needs to synchronize an update
from the SRU, the startup time is less than 10 minutes.
Issue 02 (2012-03-30)


Troubleshooting
1 Hardware
If the board is still within its startup time, wait until it starts.
If the board has exceeded its startup time, run the display device command to check the
board status. If the Register field of the board is displayed as Unregistered, go to step 2.
Step 2 Check whether the board was reset.

l
Run the display reset-reason [ slot slot-id ] command. If no information about board
resetting is displayed, the board has never been registered. Connect the board to a terminal
with a serial cable and check whether the system software has been loaded to the board
correctly. For details, see Board Software Loading Troubleshooting.
If information about board resetting is displayed, rectify the fault according to the
instructions in the command output.
If the fault persists, go to step 3.
Step 3 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 AR1200
----End
Relevant Alarms and Logs

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)


Troubleshooting
2 System
System
About This Chapter

2.1 CPU Troubleshooting
2.2 Telnet Troubleshooting
2.3 SSH Troubleshooting
This chapter describes common causes of the fault that the user fails to log in to the server through
SSH, and provides the corresponding troubleshooting flowcharts and examples.
2.4 Mirroring Troubleshooting
This chapter describes common causes of mirroring faults, and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
2.5 PoE Troubleshooting
This chapter describes common causes of power over Ethernet (PoE) faults, and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
2.6 SNMP Troubleshooting
2.7 RMON Troubleshooting
2.8 NQA Troubleshooting
2.9 NTP Troubleshooting
2.10 CWMP Troubleshooting
Issue 02 (2012-03-30)


Troubleshooting
2 System
2.1 CPU Troubleshooting

2.1.1 CPU Usage Is High
Common Causes
CPU usage is the percentage of the time during which the CPU executes codes to the total time
period. CPU usage is an important index to evaluate device performance.
To view CPU usage, run the display cpu-usage command. If you see that CPU usage exceeds
70%, CPU usage is high. A high CPU usage will cause service faults, for example, BGP route
flapping, frequent VRRP active/standby switchovers, and even failed device login.
High system CPU usage occurs when CPU usage of some tasks remains high. This fault is
commonly caused by one of the following:
l
A large number of packets are sent to the CPU when loops or DoS packet attacks occur.
STP flapping frequently occurs and a large number of TC packets are received, causing the
device to frequently delete MAC address entries and ARP entries.
The device generates a large number of logs, consuming a lot of CPU resources.
Issue 02 (2012-03-30)


Troubleshooting
2 System
Figure 2-1 CPU usage is high

CPU usage is high
Are a
large number of
packets sent to the
CPU?
Yes
Analyze packet
features to filter out
attack packets
Is fault
rectified?
Yes
No
No
Are a
large number of
TC packets
received?
Yes
Suppress TC-BPDUs
Is fault
rectified?
Yes
No
No
Does a loop
occur on the
network?
Yes
Eliminate the loop
Is fault
rectified?
Yes
No
No
Are a large
number of logs
generated?
Yes
Collect log files and

contact the Huawei
technical support
personnel
No
Seek technical
support
End
NOTE
you will have a record of your actions to provide Huawei technical support personnel.
The following procedures can be performed in any sequence.
The command output in the following procedures varies based on the device model. The following
procedures describe how to view related information.
Procedure
Step 1 Check the names of tasks with a high CPU usage.
Run the display cpu-usage command to check the CPU usage of each task .
Record the names of tasks with CPU usage exceeding 70%.
Issue 02 (2012-03-30)


Troubleshooting
2 System
NOTE
CPU usage of 70% does not necessarily affect services. Services may not be affected when some tasks
consume 70% of CPU resources, but may be affected when some tasks consume 30% of CPU resources.
This outcome depends on the actual situation.
Step 2 Check whether a large number of packets are sent to the CPU.
Run the display cpu-defend statistics command to check statistics about the packets sent to the
CPU and focus on the Drop field.
<Huawei> display cpu-defend statistics all
----------------------------------------------------------------------Packet Type
Pass Packets
Drop Packets
----------------------------------------------------------------------8021X
0
0
arp-miss
1
0
arp-reply
5
0
arp-request
1450113
25597
bfd
0
0
bgp
0
0
dhcp-client
114693
136586
dhcp-server
0
0
dns
0
0
fib-hit
0
0
ftp
717
0
fw-dns
0
0
fw-ftp
0
0
fw-http
0
0
fw-rtsp
0
0
fw-sip
0
0
gvrp
0
0
http
798
0
hw-tacacs
0
0
icmp
10
0
igmp
0
0
ipsec
0
0
isis
0
0
lacp
0
0
lldp
33959
0
ntp
0
0
ospf
1569
0
pim
0
0
pppoe
0
0
radius
0
0
rip
0
0
snmp
0
0
ssh
0
0
stp
0
0
tcp
7671
0
telnet
71149
0
ttl-expired
656
0
udp-helper
0
0
unknown-multicast
6
0
unknown-packet
94189
0
vrrp
0
0
-----------------------------------------------------------------------
l If the value of the Drop field of a certain type of packets is great and CPU usage is high,
packet attacks occur. Go to step 6.
l If the value of the Drop field is within the specified range, go to step 3.
Step 3 Check whether a large number of TC packets are received.
If STP is enabled on a device, the device deletes MAC address entries and ARP entries when
receiving TC-BPDUs. If an attacker sends pseudo TC-BPDUs to attack the device, the device
will receive a large number of TC-BPDUs within a short period and frequently deletes MAC
address entries and ARP entries. As a result, the device CPU usage becomes high.
Issue 02 (2012-03-30)


Troubleshooting
2 System
Run the display stp command to check statistics about the received TC packets and TCN packets.
<Huawei> display stp interface Eth0/0/1
----[CIST][Port2(Ethernet0/0/1)][FORWARDING]---Port Protocol
:Enabled
Port Role
:Designated Port
Port Priority
:128
Port Cost(Dot1T )
:Config=auto / Active=199999
Designated Bridge/Port
:4096.00e0-fc01-0005 / 128.2
Port Edged
:Config=default / Active=disabled
Point-to-point
:Config=auto / Active=true
Transit Limit
:147 packets/hello-time
Protection Type
:None
Port STP Mode
:MSTP
Port Protocol Type :Config=auto / Active=dot1s
PortTimes
:Hello 2s MaxAge 20s FwDly 15s RemHop 20
TC or TCN send
:1
TC or TCN received :0
BPDU Sent
:124008
TCN: 0, Config: 0, RST: 0, MST: 124008
BPDU Received
:0
TCN: 0, Config: 0, RST: 0, MST: 0
l If a large number of TC packets and TCN packets are received, run the stp tc-protection
command in the system view to suppress TC-BPDUs. After this command is used, only three
TC packets are processed within a Hello interval by default. Run the stp tc-protection
threshold command to set the maximum number of TC packets that can be processed. To
change the hello interval, run the stp timer hello command.
[Huawei] stp tc-protection
[Huawei] stp tc-protection threshold 5
[Huawei] stp timer hello 200
l If a small number of TC packets are received, go to step 4.

Step 4 Check whether loops occur on the network.
When multiple interfaces of a device belong to the same VLAN, if a loop occurs between two
interfaces, packets are forwarded only between these interfaces in the VLAN. Consequently,
CPU usage of the device becomes high.
Run the display current-configuration command to check whether the device is enabled to
generate an alarm when MAC address flapping is detected.
#
loop-detect eth-loop alarm-only
#
l If this function is not configured, run the loop-detect eth-loop alarm-only command to
configure this function. If a loop occurs on the network, an alarm is generated when two
interfaces of the device learn the same MAC address entry. For example:
Feb 22 2011 18:42:50 Huawei L2IFPPI/4/MAC_FLAPPING_ALARM:OID
1.3.6.1.4.1.2011.5.25.42.2.1.7.12The mac-address has flap value .
(L2IfPort=0,entPhysicalIndex=0, BaseTrapSeverity=4, BaseTrapProbableCause=549,
BaseTrapEventType=1, MacAdd=0000-c0a8-0101,vlanid=100,
FormerIfDescName=Ethernet1/0/0,CurrentIfDescName=Ethernet1/0/1,DeviceName=HUAWE
I)
Check the interface connection and networking information based on the alarm:
If no ring network is required, shut down one of the two interfaces based on the networking
diagram.
If the ring network is required, disable loop detection and enable loop prevention
protocols, such as STP.
l If the loop-detect eth-loop alarm-only command is used on the device but no alarm is
generated, go to step 5.
Issue 02 (2012-03-30)


Troubleshooting
2 System
Step 5 Check whether a large number of logs are generated on the device.
The device generates diagnostic information or logs continuously in some cases, for example,
attacks occur on the device, an error occurs during device operation, or an interface frequently
alternates between Up and Down states. If the storage device is frequently read or written, CPU
usage becomes high.
Run the display logbuffer command to check whether a large number of logs are generated. If
a certain log is repeatedly generated, go to step 6.
Step 6 Collect the following information and contact Huawei technical support personnel:
l Configuration files, log files, and alarm files of the device
----End

Relevant Alarms
None
Relevant Logs
None
2.2 Telnet Troubleshooting

2.2.1 The User Fails to Log in to the Server Through Telnet
Common Causes
l
The route is unreachable, and the user cannot set up a TCP connection with the server.
The number of users logging in to the server reaches the upper threshold.
An ACL is configured in the VTY user interface view.
The access protocol specified in the VTY user interface view is incorrect. For example,
when the access protocol is configured to SSH through the protocol inbound ssh
command, the user cannot log in to the server through Telnet.
Issue 02 (2012-03-30)

10

Troubleshooting
2 System
Figure 2-2 Troubleshooting flowchart for the fault that the client fails to log in to the server
through Telnet
The user fails to log
in to the server through
Telnet
Can the client

successfully ping the
server?
No
Locate and
rectify the fault
Yes
Is the fault
rectified?
No
Yes
Are all the current
VTY channels in use?
No
Increase the
maximum
number of users
allowed to log in
Yes
Is the fault
rectified?
No
Yes
Does the IP address
of the user exist in the
ACL?
No
Permit the IP
address of the
user in the ACL
Is the fault
rectified?
Yes
No
Yes
Is the user access
type set to
all or telnet?
No
Set the user

access type to all
or telnet
Yes
Is the fault
rectified?
No
Yes
Is the authentication
mode configured?
No
Configure the
authentication
mode
Is the fault
rectified?
Yes
No
Yes
Seek technical
support
End
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Issue 02 (2012-03-30)

11

Troubleshooting
2 System
Procedure
Step 1 Check whether the Telnet client can ping through the server.
Run the ping command to check the network connectivity. If the ping fails, the Telnet connection
cannot be established between the user and server.
If the ping fails, see The Ping Operation Fails to locate the problem so that the Telnet client
can ping through the server.
Step 2 Check whether the number of users logging in to the server reaches the upper threshold.
Log in to the server through a console interface and then run the display users command to
check whether all the current VTY channels are in use. By default, a maximum of 5 users can
log in to the server through VTY channels. Run the display user-interface maximum-vty
command to view the allowed maximum number of login users.
<Huawei> display user-interface maximum-vty
Maximum of VTY user:5
<Huawei> display users
User-Intf
Delay
Type
Network Address
+ 0
CON 0
00:00:00
Username : Unspecified
34 VTY 0
00:13:39 TEL
AuthenStatus
10.138.78.107
AuthorcmdFlag
no
no
If the number of users logging in to the server reaches the upper threshold, you can run the userinterface maximum-vty vty-number command to increase the maximum number of users
allowed to log in to the server through VTY channels to 15.
<Huawei> system-view
[Huawei] user-interface maximum-vty 15
Step 3 Check that an ACL is configured in the VTY user interface view.
[Huawei] user-interface vty 0 4
[Huawei-ui-vty0-4] display this
user-interface vty 0 4
acl 2000 inbound
authentication-mode aaa
user privilege level 3
idle-timeout 0 0
If an ACL is configured but the IP address of the client to be permitted is not specified in the
ACL, the user cannot log in to the server through Telnet. To enable a user with a specific IP
address to log in to the server through Telnet, permit the IP address of the user in the ACL.
Step 4 Check that the access protocol configured in the VTY user interface view is correct.
idle-timeout 0 0
protocol inbound ssh
Run the protocol inbound { all | ssh | telnet } command to configure the user access protocol.
By default, the user access protocol is Telnet.
l If the user access protocol is SSH, the user cannot log in to the server through Telnet.
l If the user access protocol is "all", the user can log in to the server through Telnet or SSH.
Step 5 Check that the authentication mode is configured in the user interface view.
Issue 02 (2012-03-30)

12

Troubleshooting
2 System
l If you run the authentication-mode password command to configure the authentication

mode for the user logging in to the server through the VTY channel to password, run the
set authentication password command to set the authentication password.
l If you run the authentication-mode aaa command to configure the authentication mode to
aaa, you should run the local-user command to add a local user.
l If you run the authentication-mode none command to configure the authentication mode
to none, the authentication mode does not affect your login.
Step 6 If the fault persists, collect the following information and contact Huawei technical support
personnel:
l Results of the preceding troubleshooting procedures
l Configuration files, log files, and alarm files of the devices
----End

Relevant Alarms
None.
Relevant Logs
None.
2.3 SSH Troubleshooting

This chapter describes common causes of the fault that the user fails to log in to the server through
SSH, and provides the corresponding troubleshooting flowcharts and examples.
2.3.1 The User Fails to Log in to the Server Through SSH

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the user fails to log in to the server through SSH.
Common Causes
l
The route is unreachable and the user cannot set up a TCP connection with the server.
SSH services are not enabled.
SSH is not configured in the user interface VTY view.
The RSA public key is not configured on the SSH server and the client.
The user service type, authentication type, and user authentication service type are not
configured.
The number of users logging in to the server reaches the upper threshold.
An ACL is configured in the user interface VTY view.
Issue 02 (2012-03-30)

13

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

14

Troubleshooting
2 System
On the SSH server, run the display rsa local-key-pair public command to check whether the
key pair is configured on the current server. if the key pair is not configured, run the rsa localkey-pair create command to create it.
[Huawei] rsa local-key-pair create
The key name will be: Host
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]: 768
Generating keys...
...........................++++++++
.++++++++
...............+++++++++
......+++++++++
Step 5 (Optional) Check whether an SSH user is configured on the SSH server.
An SSH user should be configured on the SSH server. Run the display ssh user-information
command to view the configuration of the SSH user. If no SSH user is configured, run the localuser user-name password { simple | cipher } password and local-user service-type ssh
commands in the AAA view to create an SSH user.
NOTE
If the SFTP service is enabled, run the local-user user-name ftp-directory directory command in the
AAA view to configure the SFTP directory for the SSH user.
l Create an SSH user.

[Huawei]
[Huawei]
[Huawei]
[Huawei]
aaa
local-user abc password simple abc-pass
local-user abc service-type ssh
local-user abc ftp-directory cfcard:/ssh
l The default authentication mode of the SSH user is password. To change the authentication
mode, run the ssh user authentication-type command.
Step 6 Check whether the number of SSH login users has reached the maximum.
For the STelnet and Telnet services, both STelnet users and Telnet users log in to the server
through VTY channels. The number of available VTY channels ranges from 5 to 15. When the
number of users attempt to log in to the server through VTY channels is greater than 15, the new
connection cannot be established between the user and the server.
Log in to the SSH server through a console interface and run the display users command to
check whether all the current VTY channels are used. By default, a maximum of 5 users can log
in to the server through VTY channels.
<Huawei> display user-interface maximum-vty
Maximum of VTY user:5
<Huawei> display users
User-Intf
Delay
Type
Network Address
34 VTY 0
03:31:35 TEL
10.1.1.1
35 VTY 1
03:51:58 TEL
10.1.1.2
36 VTY 2
00:10:14 TEL
10.1.1.3
37 VTY 3
02:31:58 TEL
10.1.1.4
+ 39 VTY 5
00:00:00 TEL
10.1.1.5
AuthenStatus
pass
AuthorcmdFlag
no
pass
no
pass
no
pass
no
pass
no
If the number of users logging in to the server reaches the upper threshold, you can run the userinterface maximum-vty vty-number command to increase the maximum number of users
allowed to log in to the server through VTY channels to 15.
Issue 02 (2012-03-30)

15

Troubleshooting
2 System
[Huawei] user-interface maximum-vty 15
Step 7 Check that an ACL is configured in the VTY user interface view on the SSH server.
Run the user-interface command on the SSH server to enter the SSH user interface view. Then,
run the display this command to check whether an ACL is configured in the VTY user interface
view. If an ACL is configured, record the ACL number.
Run the display acl command on the SSH server to check whether the SSH client address is
denied in an ACL. If an ACL is configured but the client address to be denied is not specified
in the ACL, the user will fail to log in to the server by means of STelnet or SFTP. To enable a
user with a specific IP address to log in to the server through STelnet, permit the user IP address
in the ACL.
Step 8 Check the SSH versions on the SSH client and SSH server.
On the SSH server, run the display ssh server status command to check the SSH version.
<Huawei> display ssh server status
SSH version
:1.99
SSH connection timeout
:60 seconds
SSH server key generating interval
:0 hours
SSH Authentication retries
:3 times
SFTP server
:Disable
If the client logging in to the server adopts SSHv1, the version compatible capability needs to
be enabled on the server.
[Huawei] ssh server compatible-ssh1x enable
Step 9 Check whether first-time authentication is enabled on the SSH client.

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

Relevant Alarms
None.
Issue 02 (2012-03-30)

16

Troubleshooting
2 System
Relevant Logs
None.
2.4 Mirroring Troubleshooting

This chapter describes common causes of mirroring faults, and provides the corresponding
2.4.1 Monitoring Device Does Not Receive Any Mirrored Packet

After Port Mirroring Is Configured
procedure for the failure to mirror packets to the monitoring device by port mirroring.
Common Causes
l
The mirrored port does not receive any packets.
The mirrored port or observing port is configured incorrectly, for example, the interface
index is incorrect.
After port mirroring is configured on the AR1200, the monitoring device does not receive any
mirrored packets.
Issue 02 (2012-03-30)

17

Troubleshooting
2 System
Figure 2-3 Troubleshooting flowchart for the port mirroring fault

Monitoring
device does not
receive mirrored
packets
Rectify fault on the

Does mirrored No
link between the
port receive
router and monitored
packets?
network
Yes
Is
mirrored port
configuration
correct?
No
Is the fault
rectified?
Yes
No
Specify correct
observing port index
Is the fault
rectified?
Yes
Yes
No
Does
No
observing port
send packets?
No
Is the
observing port
Up?
Rectify the link fault
Yes
Yes
Yes
Is the fault
rectified?
Yes
End
No
Seek technical
support
NOTE
Procedure
Step 1 Check whether the mirrored port receives packets.
Run the display interface command multiple times to view information about the mirrored port.
The Input field in the command output specifies the number of received packets. The Output
field in the command output specifies the number of sent packets.
Issue 02 (2012-03-30)

18

Troubleshooting
2 System
If the number of sent and received packets is 0 or remains unchanged, check the status of
the interface connected to the monitored network.
If the interface status is Down, bring the interface Up.
If the interface status is Up, no traffic is sent to the switch from the monitored network.
No action is necessary.
If the number of packets received by the mirrored port is not 0 and keeps increasing, go to
step 2.
Step 2 Check that the mirrored port is configured correctly.

When configuring the mirrored port, ensure that the observing port index specified in the
command is the same as the index of the configured observing port. Run the display mirrorport command to check the mapping between the observing port and mirrored port and the
direction of packets to which port mirroring is applied.
l
If the mirrored port configuration is incorrect, run the mirror (interface view) command
in the view of the mirrored port to specify the observing port index correctly.
If the mirrored port configuration is correct, go to step 3.
Step 3 Check whether the observing port sends packets to the monitoring device.
Run the display interface command multiple times to view information about the observing
port. The Output field in the command output specifies the number of packets sent by the
observing port.
l
If the number of sent packets is 0 or remains unchanged, check the status of the observing
port.
If the observing port is Down, bring it to Up.
If the observing port is Up, go to step 4.
If the number of packets sent by the observing port is not 0 and keeps increasing, go to step
4.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

19

Troubleshooting
2 System
2.4.2 Monitoring Device Does Not Receive Any Mirrored Packets

After Traffic Mirroring Is Configured
procedure for the failure to monitor packets to the monitoring device by traffic mirroring.
Common Causes
l
The link between the mirrored port and the monitored network is Down.
No traffic policy is applied or no packets match the traffic policy.
The observing port index specified in the traffic behavior is different from the index of the
configured observing port.
After traffic mirroring is configured on the AR1200, the monitoring device does not receive any
mirrored packets.
Issue 02 (2012-03-30)

20

Troubleshooting
2 System
Figure 2-4 Troubleshooting flowchart for the traffic mirroring fault

Monitoring
device does
not receive
mirrored
packets
Does
No
mirrored port
receive
packets?
Rectify fault on the

link between the
switch and
monitored network
Is the fault
rectified?
Yes
Yes
No
No
Is traffic policy
applied correctly?
Configure traffic
policy and apply it
correctly
Is the fault
rectified?
Yes
Yes
No
Does
No
observing port
send packets?
Is the observing
port Up?
No
Rectify link fault
Is the fault
rectified?
Yes
Yes
Is
No
observing port
index correct?
Yes
No
Specify correct
observing port index
in the traffic
behavior view
Is the fault
rectified?
Yes
Seek technical
support
Yes
No
End
NOTE
Procedure
Step 1 Check whether the mirrored port receives packets.
Run the display interface command to view information about the mirrored port. The Input
field in the command output specifies the number of received packets.
Issue 02 (2012-03-30)

21

Troubleshooting
2 System
If the number of packets received by the mirrored port is 0 or keeps unchanged, the link
between the router and the monitored network is faulty, for example, the mirrored port is
Down. Rectify the link fault.
If the number of packets received by the mirrored port is not 0 and keeps increasing, go to
step 2.
Step 2 Check whether the traffic policy is correctly applied.

1.
Check whether the traffic policy is applied.

A traffic policy can be applied to an interface, a VLAN, or the system. Run the display
traffic-policy policy-name applied-record command to check whether the traffic policy
is applied.
l If the traffic policy is not applied, apply it in the interface view, VLAN view, or system
view based on the network requirements.
l If the traffic policy is applied, check the traffic policy configuration.
2.
Check whether the traffic policy is configured correctly. Verify the traffic policy
configuration by checking the traffic statistics.
Run the statistic enable command in the traffic behavior view to enable the traffic statistics
function. Run the display traffic policy statistics command to check the statistics about
packets matching the traffic policy.
l If the number of packets matching the traffic policy is 0, rectify the fault of the traffic
policy first.
l If the number of packets matching the traffic policy is not 0, go to step 3.
Step 3 Check whether the observing port sends packets to the monitoring device.
Run the display interface to view information about the observing port. The Output field in
the command output specifies the number of packets sent by the observing port.
l
If the number of packets sent by the observing port is 0 or keeps unchanged, follow these
steps:
1.
Run the display interface command to check the status of the observing port. If the
observing port is in Down state, rectify the link fault. If the observing port is in Up
state. Go to step b.
2.
If the observing port is in Up state, check whether the observing port index specified
in the traffic behavior is the same as the index of the configured observing port. If not,
run the mirror (traffic behavior view) command to specify the correct observing
port index. Otherwise, go to step 4.
If the number of packets sent by the observing port is not 0 and keeps increasing, go to step
4.
l Configuration file, log file, and alarm file of the router
----End

Issue 02 (2012-03-30)

22

Troubleshooting
2 System
Relevant Alarms
None.
Relevant Logs
None.
2.4.3 Troubleshooting Cases

This section provides several mirroring troubleshooting cases.
Mirrored Packets Cannot Be Seen on the Monitoring Device After Port Mirroring
Is Configured
Fault Symptom
As shown in Figure 2-5, the R&D department connects to the Internet through the Router.
The IT department configures port mirroring on the Router to monitor traffic sent from the R&D
department to the Internet. Eth0/0/0 is the mirrored port, and Eth0/0/1 is the observing port.
After the configuration is complete, the IT department cannot see mirrored packets on the
monitoring device when the R&D department employees access the Internet.
Figure 2-5 Network diagram of port mirroring
Internet
LAN switchA
User
R&D
Department
Eth0/0/0
Router
Eth0/0/1
Monitoring
Device
Fault Analysis
1.
Issue 02 (2012-03-30)
Run the display interface command to check whether Eth0/0/0 receives packets from users.
23

Troubleshooting
2 System
In the command output, the value of Input is not 0 and keeps increasing, indicating that
Eth0/0/0 receives packets from users.
2.
Check whether the mirrored port is configured correctly.

Run the display mirror-port command. The command output shows that the mirrored port
is Eth0/0/0 and the observing port is Eth0/0/3. The configuration is incorrect.
Procedure
Step 1 Run the system-view command on Router to enter the system view.
Step 2 Run the observe-port interface ethernet 0/0/1 command to configure Ethernet 0/0/1 as the
observing port.
Step 3 Run the interface ethernet 0/0/0 command to enter the view of the mirrored port.
Step 4 Run the mirror to observe-port inbound command to configure port mirroring.
----End
Summary
If mirrored packets cannot be seen on the monitoring device, the possible cause is that the
mirrored port or observing port is configured incorrectly.
Mirrored Packets Cannot Be Seen on the Monitoring Device After Traffic

Mirroring Is Configured
Fault Symptom
As shown in Figure 2-6, the R&D department, sales department, and IT department are on
different network segments.
The sales department and IT department connect to the Internet through RouterA. The IT
department configures traffic mirroring on RouterA to monitor traffic sent from the R&D
department to the Internet. After the configuration is complete, the IT department cannot see
mirrored packets on the monitoring device.
Figure 2-6 Network diagram of traffic mirroring
R&D
Department
Internet
10.1.1.0/24
10.1.2.0/24
SwitchA
GE2/0/0
GE2/0/1
RouterA
Sales
Department
Monitoring
Device
Issue 02 (2012-03-30)

24

Troubleshooting
2 System
Fault Analysis
1.
Run the display interface command to check whether GigabitEthernet2/0/0 receives

packets from users.
In the command output, the value of Input is not 0 and keeps increasing, indicating that
GigabitEthernet2/0/0 receives packets from users.
2.
Check whether a traffic policy is applied.

Run the display traffic-policy policy-name applied-record command to check whether a
traffic policy is applied. The command output shows that the traffic policy tp1 is applied
to GigabitEthernet2/0/0.
3.
Check whether the user packets match the traffic policy.

Run the statistic enable command in the traffic behavior view to enable the traffic statistics
function. Run the display traffic policy statistics interface GigabitEthernet 2/0/0
inbound command to view statistics about packets matching the traffic policy. The
command output shows that the number of received packets matching the traffic policy is
0, that is, the packets do not match the traffic policy.
4.
Check whether the traffic classifier and the traffic behavior in the traffic policy are correctly
configured.
Run the display traffic policy user-defined command to check whether the traffic behavior
bound to the traffic policy contains the traffic mirroring action.
<Huawei> display traffic policy user-defined tp1
User Defined Traffic Policy Information:
Policy: tp1
Classifier: default-class
Behavior: be
-noneClassifier: tc1
Behavior: tb1
statistic: enable
Port-mirroring to observe-port 1
The preceding information indicates that the traffic classifier tc1 and the traffic behavior
tb1 are bound to the traffic policy, and tb1 is configured with the traffic mirroring action.
Run the display traffic classifier user-defined command to check whether the
configuration of the traffic classifier is correct. If an ACL is referenced in the traffic
classifier, run the display acl command to check the ACL rules.
<Huawei> display traffic classifier user-defined tc1
User Defined Classifier Information:
Classifier: tc1
Precedence: 10
Operator: AND
Rule(s) : if-match acl 3000
if-match inbound-interface GigabitEthernet 1/0/0
<Huawei> display acl 3000
Advanced ACL 3000, 1 rule
Acl's step is 5
rule 5 permit ip source 10.1.1.0 0.0.0.255
The preceding information indicates that the traffic classifier contains two matching rules:
ACL 3000 and inbound interface GigabitEthernet1/0/0. The logical relationship between
the matching rules is AND, If the rules are ANDed with each other, the packets must match
all the non-ACL rules and one of the ACL rules of the traffic classifier. The inbound
interface of user packets is GigabitEthernet2/0/0 but not GigabitEthernet1/0/0; therefore,
Issue 02 (2012-03-30)

25

Troubleshooting
2 System
the packets do not match the traffic classifier and mirrored packets cannot be seen on the
monitoring device.
Procedure
Step 1 Run the interface GigabitEthernet 2/0/0 command to enter the view of the mirrored port.
Step 2 Run the undo traffic-policy inbound command to delete the traffic policy from
GigabitEthernet2/0/0.
Step 3 Run the quit command to exit from the interface view.
Step 4 Run the traffic classifier tc1 command to enter the traffic classifier view.
Step 5 Run the undo if-match inbound-interface command to delete the matching rule for incoming
packets in the traffic classifier.
Step 6 Run the if-match inbound-interface GigabitEthernet 2/0/0 command to configure a new
matching rule for incoming packets onGigabitEthernet2/0/0.
Step 7 Run the quit command to exit from the traffic classifier view.
Step 8 Run the interface GigabitEthernet 2/0/0 command to enter the interface view.
Step 9 Run the traffic-policy tp1 inbound command to apply the traffic policy tp1 to
----End
Summary
When configuring traffic mirroring, ensure that the traffic policy matches the packets to be
mirrored. Otherwise, the packets cannot be copied to the observing port.
2.5 PoE Troubleshooting

This chapter describes common causes of power over Ethernet (PoE) faults, and provides the
2.5.1 PSE Cannot Detect a PD

procedure for the failure to detect a powered device (PD).
Common Causes
l
The PSE is not grounded.
The network cable between the power source equipment (PSE) and the powered device
(PD) is damaged.
The PD fails.
The PSE does not support the PD.
Issue 02 (2012-03-30)

26

Troubleshooting
2 System
A PD is connected to a port of the AR1200. After the display poe power-state slot slot-id
command is run on the port, the command output shows that the port is in detecting state.
Figure 2-7 Troubleshooting flowchart for the failure to detect a PD
PSE cannot
detect a PD
Is the PSE
grounded?
No
Ground the PSE

correctly
Is the fault
rectified?
Yes
Yes
No
No
Is cable
between PSE and
PD normal?
Replace the
network cable
Yes
Is the fault
rectified?
Yes
No
No
Is the PD
normal?
Replace the PD
Yes
Is the fault
rectified?
Yes
No
Does PSE
support
PD?
Yes
No
Seek technical
support
Enable PSE to
provide power for
PDs that do not
confirm to 802.3af
or 802.3at
Yes
Is the fault
rectified?
No
End
NOTE
Issue 02 (2012-03-30)

27

Troubleshooting
2 System
Procedure
Step 1 Check whether the AR1200 is grounded.
l
If the AR1200 is not grounded, ground the AR1200.
If the AR1200 is grounded, go to step 2.

NOTE
The network cable may undergo interference signals, for example, from a high-power base station. If the
AR1200 is not grounded, the interference signals may affect the detection signals in the network cable. In
this case, the AR1200 cannot detect the PD, and hence cannot provide power for the PD.
Step 2 Check whether the network cable between the PD and AR1200 functions properly.
l
If the network cable is damaged, replace it.
If the network cable functions properly, go to step 3.
Step 3 Check whether the PD functions properly.

Connect the PD to another working port, and run the display poe power-state slot slot-id
command to check the port status. If the port is in Delivering-power state, the previous port is
faulty. If this port is still in Detecting state, the PD is faulty.
l
If the PD is faulty, replace the PD.
If the PD functions properly, go to step 4.
Step 4 Check that the compatibility test function is enabled on the PSE.
Run the display this command on the interface connected to the PD to check whether the
compatibility test function is enabled.
l
If the compatibility test function is not enabled, run the poe legacy enable command to
enable this function.
If the compatibility test function is enabled, go to step 5.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.5.2 PSE Cannot Provide Power for a PD

procedure for the failure to provide power for a powered device (PD).
Issue 02 (2012-03-30)

28

Troubleshooting
2 System
Common Causes
l
The power management mode of the device is manual, but the port is not enabled to provide
power for the PD.
PoE function is not enabled on the port.
The available port power is less than the PD reference power.
High PoE power is reserved, so the PoE power supply cannot provide power for PDs.
The total power consumption of all the PDs on the device reaches the maximum power
configured for PDs.
After a PD is connected to a port of the AR1200 (PSE), the AR1200 detects the PD but cannot
provide power for the PD.
Issue 02 (2012-03-30)

29

Troubleshooting
2 System
Figure 2-8 Troubleshooting flowchart for the failure to provide power for a PD
PSE cannot
provide power
for a PD
Is power
No
management mode
set to auto?
Yes
Is PoE enabled
on the port?
No
Is
port enabled to No
provided
power?
Yes
Enable PoE on the

port
Yes
Enable the port to

provide power for
the PD
Is the fault
rectified?
Yes
No
Is the fault
rectified?
Yes
No
Is port max.
power greater No
than reference
power?
Increase the max.

output power of the
port
Is the fault
rectified?
Yes
No
Yes
DoesPower Yes
consumed
approximate the
max. power
configured for
PDs?
No
Yes
Reduce the
percentage of
reserved power
Seek technical
support
Is the fault
rectified?
No
End
NOTE
Procedure
Step 1 Check the device power management mode.
NOTE
The power management mode can be auto or manual. The default power management mode is auto. In this
mode, the PSE automatically provides power for a PD after detecting and classifying the PD. Run the
display poe information command to check the power management mode.
Issue 02 (2012-03-30)

30

Troubleshooting
2 System
If the device power management mode is manual, check whether the port is enabled to
provide power for the PD.
Run the display poe power-state slot slot-id command. The PowerOn/Off field in the
command output specifies whether the port is enabled to provide power for the PD.
If the port is not enabled to provide power for the PD, run the poe power-on
interface interface-type interface-number command in the system view to enable this
function.
If the port is enabled to provide power for the PD, go to step 2.
If the power management mode of the device is auto, go to step 2.
Step 2 Check that the PoE function is enabled on the port.

Run the display poe power-state slot slot-id command to check whether the PoE function is
enabled on the port. If the Enabled field is displayed as enable, the PoE function is enabled.
l
If the PoE function is not enabled, run the poe enable command in the interface view to
enable it.
If the PoE function is enabled, go to step 3.
Step 3 Check that the maximum power of the port is greater than the reference power of the PD.
The system identifies the maximum power of a PD, classifies the PD into a certain level, and
defines the reference power of each level. Run the display poe power-state interface interfacetype interface-number command to check the maximum power and reference power of the PD.
l
If the maximum power of the port is less than the reference power of the PD, run the undo
poe power command in the interface view to restore the default maximum power of the
port. Alternatively, run the poe power command to set a value greater than the reference
power after restoring the default maximum power.
If the maximum power of the port is greater than the reference power of the PD, go to step
4.
Step 4 Check that the available power of the power supply is greater than the reference power of the
PD.
Certain PoE power may be reserved on the device to meet emergency requirements. By default,
20% PoE Power is reserved. The maximum power for PDs is the total PoE power minus the
reserved power.
Run the display poe-power command to check the PoE information. In the command output,
Available power value(mW) specifies the total PoE power in the system, and Reserved power
percent specifies the percentage of the reserved power. If 100% of the PoE power is reserved,
no power can be provided for PDs.
Run the display poe information command. In the command output, Power Current Value
(mW) specifies the total PoE power consumption in the system.
l
If the total power consumption of all PDs approximates the maximum power configured
for PDs, the device cannot provide power for new PDs. To increase the maximum power
for PDs, run the poe power-reserved power-reserved command to reduce the reserved
power.
If the total power consumption of all PDs on the device is less than the maximum power
configured for PDs, go to step 5.
Issue 02 (2012-03-30)

31

Troubleshooting
2 System

----End

Relevant Alarms
None.
Relevant Logs
None.
2.6 SNMP Troubleshooting

2.6.1 An SNMP Connection Cannot Be Established
Common Causes
l
Packets cannot be exchanged between the host and the NMS.
Configurations are incorrect.
Issue 02 (2012-03-30)

32

Troubleshooting
2 System
Figure 2-9 Troubleshooting flowchart used when an SNMP connection cannot be established
SNMP connection
fails
Can AR and NMS

ping each other?
No
Rectify the fault

according to The Ping
Operation Fails
Yes
Is fault rectified?
No
Yes
Is
SNMP configured
correctly?
Yes
Is ACL configured
correctly?
No
Modify SNMP
configuration
Yes
Is fault rectified?
No
No
Modify ACL to allow

the NMS to access
the device
Yes
Yes
Is fault rectified?
No
Seek technical
support
End
NOTE
Procedure
Step 1 Run the ping command to check whether the host and the NMS can successfully ping each other.
l If the ping fails, see The Ping Operation Fails to locate the problem so that the host and
NMS can ping each other.
l If the ping succeeds, the host and the NMS are reachable. Go to Step 2.
Step 2 Check whether the SNMP configuration on the host is correct.
l If the SNMP configuration is incorrect, modify the configuration based on Table 2-1.
l If the SNMP configuration is correct, go to step 3.
Issue 02 (2012-03-30)

33

Troubleshooting
2 System
Table 2-1 SNMP configuration

Item
Method
Troubleshooting
Procedure
Check whether the host

supports the SNMP version
used by the NMS for sending
a login request.
Run the display snmp-agent

sys-info version command to
view the SNMP version of
the host.
If the host does not support

the SNMP version, run the
snmp-agent sys-info
version command to set the
SNMP version on the host.
View the community string

configured on the host.
Run the display snmp-agent

community command.
If the community string used

by the NMS for sending a
login request is different
from that configured on the
host, run the snmp-agent
community command to
configure a read-write
community string, which
must be identical to that
configured on the host.
If SNMPv3 is used, check

whether information about
the SNMP user group and
users is correct.
l Run the display snmpagent group command to

view information about
the SNMPv3 user group.
If information is incorrect,
modify the configurations.
l Run the display snmpagent usm-user

command to view the
SNMPv3 user
information.
l Run the snmp-agent

group command to view
information about the
SNMPv3 user group.
l Run the snmp-agent
usm-user command to
view information about
the SNMPv3 user.
Step 3 Run the display snmp-agent community command to view the community string configured
on the host.
l If the IP address from which the NMS sends login requests is denied by the ACL, run the
rule command to enable the ACL to permit the IP address from which the NMS sends login
requests.
l If the IP address from which the NMS sends login requests is permitted by the ACL, go to
Step 4.
----End

Relevant Alarms
None.
Issue 02 (2012-03-30)

34

Troubleshooting
2 System
Relevant Logs
None.
2.6.2 The NMS Fails to Receive Trap Messages from the Host
Common Causes
l
The trap message is lost.
The SNMP configuration on the host is incorrect. As a result, the host is unable to send
trap messages.
No trap message is generated on the host-side service module, or the trap message is
generated on the host-side service module, but the format of the trap messages is incorrect.
As a result, the trap message cannot be sent.
Figure 2-10 Troubleshooting flowchart used when the NMS fails to receive trap messages from
the host
The NMS fails to
receive trap messages
from the host
Are the SNMP

configuration correct?
No
Configure SNMP
correctly
Yes
View the system log and
rectified the fault based on
the table in troubleshooting
procedure
Yes
Is the fault rectified?
End
No
Seek technical support
Issue 02 (2012-03-30)

35

Troubleshooting
2 System
Context
NOTE
Procedure
Step 1 Check whether the SNMP configurations on the host are correct.
l If the SNMP configurations are correct, go to Step 2.
l If the SNMP configurations are incorrect, change the configuration based on the following
configuration cases.
Table 2-2 Typical SNMP configurations
Configuration Case
Command
Configure a destination host running

SNMPv2c, with the destination port
number being 162 (default value), the
security name being huawei, and the
IP address being 192.168.1.1.
[Huawei] snmp-agent target-host trapparamsname abc v2c securityname huawei
[Huawei] snmp-agent target-host traphostname aaa address 192.168.1.1 trapparamsnam abc

SNMPv3, with the user name being
huawei. The user belongs to the user
group named huawei_group and has
Huawei_view as the notify rights
(notify-view).
# Configure a MIB view.
NOTE
With Huawei_view, the user can access all
nodes from the iso subtree.

SNMPv3, with the user name being
huawei and the IP address being
192.168.1.1.
NOTE
huawei must be an existing user name.
[Huawei] snmp-agent mib-view Huawei_view
include iso
# Configure a user group.

[Huawei] snmp-agent group v3 huawei_group
noauth read-view Huawei_view write-view
Huawei_view notify-view Huawei_view
# Configure a user.
[Huawei] snmp-agent usm-user v3 huawei
huawei_group
[Huawei] snmp-agent target-host trapparamsname abc v3 securityname huawei
authentication
[Huawei] snmp-agent target-host traphostname aaa address 192.168.1.1 trapparamsname abc
Step 2 Run the display snmp-agent trap all command to check whether the trap function is enabled.
l If the trap function is not enabled, run the snmp-agent trap enable command to enable the
host to send trap messages.
l If the trap function is enabled, go to Step 3.
Step 3 Check whether the log message indicating that a specific trap is generated exists on the host.
Issue 02 (2012-03-30)

36

Troubleshooting
2 System
l If the log message indicating that a specific trap is generated does not exist on the host, the
trap is not generated. Go to Step 4.
l If the log message indicating that a specific trap is generated exists on the host, the trap has
been generated, but the NMS fails to receive the trap message. Go to Step 4.
NOTE
The log message indicating that a specific trap is generated is as follows: #Jun 10 2010 09:55:03 Quideway
IFNET/2/IF_PVCDOWN:OID 1.3.6.1.6.3.1.1.5.3 Interface 109 turned into DOWN state.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.7 RMON Troubleshooting

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

37

Troubleshooting
2 System
Figure 2-11 Troubleshooting flowchart for the failure of the NMS to receive RMON alarms
N M sta tio n
ca n n o t re ce ive
R M O N a la rm s.
Is
ro u te to N M sta tio n
re a ch a b le?
N o C o n fig u re ro u te s
to th e N M sta tio n
co rre ctly
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e S N M P
A la rm fu n ctio n
e n a b le d ?
No
C o n fig u re th e
S N M P a la rm
fu n ctio n co rre ctly
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e
No
R M O N sta tistics fu n ctio n
E n a b le th e R M O N
sta tistic fu n ctio n
e n a b le d?
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e
R M O N sta tistics e n try
cre a te d ?
N o C re a te th e R M O N
sta tistics e n try
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e
R M O N e ve n t e n try
cre a te d ?
e ve n t e n try
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e R M O N
a la rm e n try
cre a te d ?
a la rm e n try
Is fa u lt
re ctifie d ?
Yes
No
Yes
Is th e a la rm
va ria b le s e n a b le d
co rre ctly?
No
C o n fig u re th e
a la rm va ria b le s
co rre ctly
Is fa u lt
re ctifie d ?
Yes
No
S e e k te ch n ica l
su p p o rt.
End
NOTE
Issue 02 (2012-03-30)

38

Troubleshooting
2 System
Procedure
Step 1 Check whether there are reachable routes between the router and the NM station.
Ping the NM station interface from the router.
l If the ping succeeds, it indicates that the routes between the router and the NM station are
reachable,go to Step 2.
l If the ping fails, check the routes between the router and the NM station. For details of routing
troubleshooting, see the section The Ping Operation Fails.
Step 2 Check that the SNMP alarm function is configured correctly.
Check whether the NM station can receive other alarms. If not, do as follows:
l Run the display snmp-agent trap all command to check whether the alarm function of the
router is enabled
l Run the display snmp-agent target-host command to check whether the NM address
through which the router sends alarms is correct
Step 3 Check that the statistics of RMON is enabled.
Run the display this command on the specified interface to check whether the statistics of
RMON is enabled.If the statistics of RMON is disabled, run the rmon-statistics enable
command.
Step 4 Check that rmonStatsTable is configured.
Run the display rmon statistics command on the router to check whether rmonStatsTable is
configured. If rmonStatsTable is null, run the rmon statistics entry-number [ owner ownername ] command to create entries of the table.
Step 5 Check that the RMON eventTable is enabled.
Run the display rmon event [ entry-number ] command on the router interface to check whether
the RMON eventTable is enabled. If the eventTable is null, run the rmon event command to
create entries of the table.
Step 6 Check that the RMON alarmTable is enabled.
Run the display rmon alarm [ entry-number ] command on the router interface to check whether
the RMON alarmTable is enabled. If the alarmTable is null, run the rmon alarm command to
create entries of the table.
Step 7 Check that the alarm variables are configured correctly.
Run the display rmon alarm [ entry-number ] command on the router interface to view the
value of the configured alarm variables. On the NM station, check that the values of alarm
variables of the interface are consistent with those values configured on the router interface. If
the values are inconsistent, modify the values of the alarm variables to be consistent.
After the preceding operations are complete, if the NM station cannot receive the alarm values
of the RMON module on the router, contact the Huawei technical personnel.
----End
Issue 02 (2012-03-30)

39

Troubleshooting
2 System

Relevant Alarms
None.
Relevant Logs
None.
2.8 NQA Troubleshooting

2.8.1 A UDP Jitter Test Instance Fails to Be Started
Common Causes
l
The mandatory parameter of the test instance is incorrect.
Figure 2-12 Troubleshooting flowchart used when a UDP Jitter test instance fails to be started
A UDP jitter test
instance fails to be
started
Is the test
type Jitter?
No
Ensure that the test

type is Jitter
Yes
Yes
No
Is the
destination address
configured?
No
Ensure that the

destination address is
configured
Is the fault
rectified?
Yes
No
Yes
Is the
destination port
configured?
No
Ensure that the

destination port is
configured
Is the fault
rectified?
Yes
No
Yes
Issue 02 (2012-03-30)
Is the fault
rectified?

End
40

Troubleshooting
2 System
NOTE
All the following commands, except the display commands, are used in the NQA test instance view. The
display commands can be used in any views.
Procedure
Step 1 Run the display nqa-agent admin-name test-name [ verbose ] command on the NQA client or
the display this command in the NQA test instance view to check whether the test type is Jitter.
l If the test type is Jitter, go to Step 2.
l If the test type is not Jitter, run the test-type jitter command to configure the test type to
UDP Jitter.
If the fault is rectified, the operation ends.
If the fault persists, go to Step 2.
the display this command in the NQA test instance view to check whether the destination IP
address is configured.
l If the destination IP address is configured, go to Step 3.
l If the destination IP address is not configured, run the destination-address ipv4 ipaddress command in the NQA test instance view to configure the destination IP address.
the display this command in the NQA test instance view to check whether the destination port
is configured.
l If the destination port is configured, go to Step 4.
l If the destination port is configured, run the destination-port port-number command in the
NQA test instance view to configure the destination port.
personnel:
----End

Relevant Alarms
None.
Issue 02 (2012-03-30)

41

Troubleshooting
2 System
Relevant Logs
None.
2.8.2 A Drop Record Exists in the UDP Jitter Test Result

Common Causes
If the UDP jitter test result has drop records, the value of the "Drop operation number" field in
the display nqa results command output is not 0.
l
The destination IP address does not exist or the route to the network segment to which the
destination IP address belongs does not exist in the routing table.
The source IP address is incorrect.
Figure 2-13 Troubleshooting flowchart used when a drop record exists in the UDP jitter test
A drop record exists in
the UDP jitter test result
Is the
destination address
reachable?
No
Ensure that the

destination address
exists and is
reachable
Is the fault
rectified?
Yes
No
Yes
Is the
source address
configured?
No
Ensure that the

source address exists
and is reachable
Is the fault
rectified?
Yes
No
Yes
End
NOTE
Procedure
Step 1 Run the display ip routing-table command on the NQA client to check whether the route along
the test path exists.
Issue 02 (2012-03-30)

42

Troubleshooting
2 System
l If the route exists, run the ping command to check whether devices can successfully ping
each other.
If devices can successfully ping each other, go to Step 2.
If devices cannot successfully ping each other, see The Ping Operation Fails.
l If the route does not exist, run the corresponding command to reconfigure the route.
the display this command in the NQA test instance view to check whether the source IP address
is configured.
l If the source IP address is configured, run the display ip interface brief on the NQA client
to check whether the interface configured with the source IP address exists.
If the interface exists, run the display ip routing-table command on the NQA server to
check whether the route to the source IP address exists.
If the route exists, run the ping command to check whether the source IP address is
reachable.
If the source IP address is reachable, go to Step 3.
If the source IP address is unreachable, see The Ping Operation Fails.
If the route does not exist, run the corresponding command to reconfigure the route.
If the interface configured with the source IP address does not exist, run the corresponding
command to reconfigure IP addresses and recheck the configuration about NQA.
l If the source IP address is not configured, go to Step 3.
personnel:
----End

Relevant Alarms
None.
Relevant Logs
None.
2.8.3 A Busy Record Exists in the UDP Jitter Test Result

Common Causes
If the UDP jitter test result has busy records, the value of the "System busy operation number"
field in the display nqa results command output is not 0.
l
Issue 02 (2012-03-30)
The VPN route instance that is configured in the UDP Jitter test instance is unreachable.
43

Troubleshooting
2 System
Figure 2-14 Troubleshooting flowchart used when a busy record exists in the UDP jitter test
A busy record exists in
the UDP jitter test result
Is the VPN instance

configured?
No
Configure the VPN

instance
Yes
Is the fault
rectified?
No
Yes
Can devices in a VPN

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

44

Troubleshooting
2 System

Relevant Alarms
None.
Relevant Logs
None.
2.8.4 A Timeout Record Exists in the UDP Jitter Test Result

Common Causes
If the UDP jitter test result has timeout records, the value of the "operation timeout number"
field in the display nqa results command output is not 0.
l
The destination address does not exist, but the route to the network segment of the
destination address exists in the routing table.
The value of the parameter "nqa-jitter tag-version" is 2, and the receiver is not configured
with a UDP server.
Figure 2-15 Troubleshooting flowchart used when a timeout record exists in the UDP jitter test
A timeout record exists
in the UDP jitter test
result
Is the
destination address
reachable?
No
Ensure that the

destination address
exists and is
reachable
Yes
No
Yes
Is the NQA jitter tagversion 2?
Yes
Ensure that the NQA

server is configured
and is in the Active
state
Is the fault
rectified?
Yes
No
No
Issue 02 (2012-03-30)
Is the fault
rectified?

End
45

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

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

46

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

l
A drop record exists in the UDP jitter test result.
A timeout record exists in the UDP jitter test result.
The TTL expires.
The parameter frequency is incorrect.
The parameter fail-percent is incorrect.
Figure 2-16 Troubleshooting flowchart used when the UDP Jitter test result is "failed", "no
result", or "packet loss"
The UDP jitter test
result is failed or
packet loss
Yes
Is TTL configured?
Yes
Ensure that the

packet TTL is large
enough for the packet
to reach the
destination
Is the fault
rectified?
Ensure that the

frequency value is
large than (interval x
probe-count x jitterpacketnum)
Is the fault
rectified?
Set fail-percent to a
proper value
Is the fault
rectified?
No
Yes
Is frequency set?
No
Yes
Is fail-percent set?
No
Yes
No
Yes
No
No
Issue 02 (2012-03-30)
Yes

End
47

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

Relevant Alarms
None.
Issue 02 (2012-03-30)

48

Troubleshooting
2 System
Relevant Logs
None.
2.9 NTP Troubleshooting

2.9.1 The Clock is not Synchronized
Common Causes
l
The link flaps.
The link is faulty.
Context
NOTE
Procedure
Step 1 Check the NTP status.
[Huawei] display ntp-service status
clock status: unsynchronized
clock stratum: 16
reference clock ID: none
nominal frequency: 100.0000 Hz
actual frequency: 99.9995 Hz
clock precision: 2^18
clock offset: 0.0000 ms
root delay: 0.00 ms
root dispersion: 0.00 ms
peer dispersion: 0.00 ms
reference time: 14:25:55.477 UTC Jun 9 2010(CFBA22F3.7A4B76F6)
The "clock status" field is displayed as "unsynchronized", indicating that the local system clock
is not synchronized with any NTP server or a reference clock.
Step 2 Check the status of the NTP connection.
[Huawei] display ntp-service sessions
The value of the "reference" is 0.0.0.0, specifying that the local system clock is not synchronized
with any NTP server.
Step 3 Run the ping command on the NTP client to check the status of the link to the NTP server.
[Huawei] ping 20.1.14.1
PING 20.1.14.1: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
Issue 02 (2012-03-30)

49

Troubleshooting
2 System
--- 20.1.14.1 ping statistics --5 packet(s) transmitted

0 packet(s) received
100.00% packet loss
l The displayed information "100.00% packetloss" indicates that the link is faulty. To locate
the fault, refer to The Ping Operation Fails.
l If the packet loss percentage is not 100.00%, the link flaps. To locate the fault, refer to The
Ping Operation Fails.
l If the packet loss percentage is 0.00%, the link is normal. Then proceed to step 4.
personnel:
----End

Relevant Alarms
None.
Relevant Logs
The following log information indicates that the clock source with which the local device
synchronizes is lost.
NTP/4/SOURCE_LOST
The following log information indicates that the local clock has synchronized with a clock
source.
NTP/4/LEAP_CHANGE
NTP/4/STRATUM_CHANGE
NTP/4/PEER_SELE
2.10 CWMP Troubleshooting

2.10.1 Failed to Manage AR1200 Using CWMP
Common Causes
The fault symptoms are as follows:
l
The AR1200 cannot set up a connection with the ACS.
The ACS fails to issue configurations to the AR1200.

Issue 02 (2012-03-30)

50

Troubleshooting
2 System
The CWMP settings on the AR1200 are incorrect, for example, the setting of ACS's URL,
user name, or password is incorrect, or the CWMP function is disabled on the AR1200.
There is no reachable route between the AR1200 and the ACS.
The AR1200 does not support parameters in the packets received from the ACS.
Figure 2-17 CWMP troubleshooting flowchart
CWMP fails to
manage AR
Are CWMP
settings correct?
No
Yes
Is fault rectified?
Modify the settings

No
Yes
Is there
No
a reachable route
between AR and
ACS?
Yes
Configure a
reachable route
Is fault rectified?
No
Yes
Is any parameter
not supported by
AR?
Yes
End
No
NOTE
Procedure
Step 1 Verify the CWMP settings on the AR1200.
Run the display cwmp configuration command in the system view to check whether the CWMP
function is enabled and the ACS's URL, user name, and password are correctly set.
<Huawei> display cwmp configuration
CWMP is enabled
ACS URL:
http://www.acs.com:80/acs
ACS username:
hwcpe
ACS password:
asd123
Inform enable status:
disabled
Issue 02 (2012-03-30)

51

Troubleshooting
2 System
Inform interval:
Inform time:
Wait timeout:
Reconnection times:
600s
30s
3
l If the CWMP settings are correct, go to step 2.

l If the CWMP settings are incorrect, modify them based on Table 2-3, and run the undo
cwmp enable and cwmp enable commands to re-enable the CWMP function.
Table 2-3 CWMP settings
Item
Method
Enable the CWMP

function.
Run the cwmp enable command in the CWMP view.
Configure the URL used

by the AR1200 to connect
to the ACS.
Run the cwmp acs url url command in the CWMP view.
Configure the user name

used by the AR1200 to
connect to the ACS.
Run the cwmp acs username username command in the

CWMP view.
Configure the ACS's

password used by the
AR1200 to connect to the
ACS.
Run the cwmp acs password password command in the CWMP

view.
Step 2 Check that there is a reachable route between the AR1200 and ACS.
Run the ping command on the AR1200 to ping the ACS.
NOTE
If you have configured the ACS's URL as a domain name, use the display dns dynamic-host command
to obtain the IP address, and enter the IP address in the ping command.
<Huawei> display dns dynamic-host
No Domain-name
IpAddress
1
huawei.com
2.1.1.3
TTL
3579
Alias
l If the AR1200 fails to ping the ACS, rectify the ping fault based on 7.1.1 The Ping Operation
Fails.
l If the AR1200 can ping the ACS, go to step 3.
Step 3 Check whether the parameters in the packets received from the ACS are supported by the
AR1200.
Capture the packets exchanged between the ACS and the AR1200 using Ethereal or other packet
catchers, and check the parameters in <Name></Name>.
Issue 02 (2012-03-30)

52

Troubleshooting
2 System
l If the parameters are not supported by the AR1200, the ACS cannot manage the AR1200.
l If all parameters are supported by the AR1200, go to step 4.
----End

Relevant Alarms
None
Relevant Logs
None
Issue 02 (2012-03-30)

53

Troubleshooting
3 Physical Connection and Interfaces
Physical Connection and Interfaces
About This Chapter

3.1 Eth-Trunk Interface Troubleshooting
This chapter describes common causes of Eth-Trunk interface faults, and provides the
Issue 02 (2012-03-30)

54

Troubleshooting
3.1 Eth-Trunk Interface Troubleshooting

This chapter describes common causes of Eth-Trunk interface faults, and provides the
3.1.1 Eth-Trunk Interface Cannot Forward Traffic

procedure for the fault that an Eth-Trunk interface cannot forward traffic.
Common Causes
After an Eth-Trunk interface is configured, it cannot forward traffic.
l
Eth-Trunk member interfaces are faulty.
Configurations of Eth-Trunk member interfaces on the two ends are inconsistent.
The number of Up Eth-Trunk member interfaces is smaller than the lower threshold.
Negotiation between member interfaces of the Eth-Trunk interface in static LACP mode
fails.
On the network shown in Figure 3-1, the Eth-Trunk interface cannot forward traffic.
Figure 3-1 Eth-Trunk network diagram
Eth0/0/1
Eth0/0/2
Eth0/0/1
Eth0/0/2
RouterA
RouterB
Eth0/0/3
Eth0/0/3
Eth-Trunk1

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

Issue 02 (2012-03-30)

55

Troubleshooting
Figure 3-2 Troubleshooting flowchart

Eth-Trunk interface
cannot forward traffic
Eth-Trunk
member interfaces work
properly?
Yes
Check physical
links connecting
member interfaces
and rectify the link
fault
Is fault
rectified?
Yes
No
No
Member
interfaces on both ends
are consistent?
No
Modify the
configuration
Is fault
rectified?
Yes
No
Yes
Number of
Up member interfaces
is below the lower
threshold?
Yes
Change the lower

threshold
Is fault
rectified?
Yes
No
No
Negotiation
between Eth-Trunk
interfaces working in
static LACP
mode fails?
Yes
Locate the cause

of the negotiation
failure and modify
the configuration
Is fault
rectified?
Yes
No
No
End
NOTE
Procedure
Step 1 Check that Eth-Trunk member interfaces work properly.
Run the display eth-trunk 1 command in any view to check the status of the Eth-Trunk interface.
[RouterA] display eth-trunk 1
Eth-Trunk1's state information is:
WorkingMode: NORMAL
Hash arithmetic:According to SA-XOR-DA
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 8
Issue 02 (2012-03-30)

56

Troubleshooting
Operate status: down

Number Of Up Port In Trunk: 0
-------------------------------------------------------------------------------PortName
Ethernet0/0/1
Ethernet0/0/2
Ethernet0/0/3
Status
Down
Down
Down
Weight
1
1
1
If a member interface is Down, check the following items on the interface.

Check Item
Method
Whether the
interface was
manually shut
down
Run the interface interface-type interface-number command in the

system view to enter the interface view, and then run the display
this command to check the interface status. If the interface was shut
down by using the shutdown command, run the undo shutdown
command in the interface view.
Whether the link

fails
Replace the cable between RouterA and RouterB.
Whether the
interface fails
Configure other idle interfaces as member interfaces of the EthTrunk.
NOTE
If RouterA connects to RouterB using a twisted pair, select a new twisted
pair with a proper transmission distance according to the actual distance
between RouterA and RouterB.
If the interface remains in the Down state, go to Step 5.

l
If the member interface is Up, verify that each cable is correctly connected to interfaces.
Step 2 Check information about Eth-Trunk member interfaces on both ends.

Check information about member interfaces of the Eth-Trunk interface on Router A and
Router B.
WorkingMode: NORMAL
Hash arithmetic: According to SA-XOR-DA
Operate status: up
-------------------------------------------------------------------------------PortName
Status
Weight
Ethernet0/0/1
up
1
Ethernet0/0/2
up
1
Ethernet0/0/3
up
1
[RouterB] display eth-trunk 1
WorkingMode: NORMAL
Operate status: up
-------------------------------------------------------------------------------PortName
Status
Weight
Ethernet0/0/1
up
1
Ethernet0/0/2
up
1
l Check information about member interfaces of the Eth-Trunk interface on Router B.

l
Issue 02 (2012-03-30)
If the number of member interfaces of the Eth-Trunk interface on Router A differs from
the number on Router B, add the required physical interfaces to the Eth-Trunk interface.
57

Troubleshooting
If the number of member interfaces of the Eth-Trunk interface on Router A is the same as
the number on Router B, go to Step 3.
Step 3 Check whether the Eth-Trunk interface is configured with a lower threshold of Up member
interfaces.
Run the display eth-trunk 1 command on Router A and Router B to view the configuration of
the Eth-Trunk interface.
WorkingMode: NORMAL
-------------------------------------------------------------------------------PortName
Status
Weight
Ethernet0/0/1
up
1
Ethernet0/0/2
up
1
Ethernet0/0/3
up
1
The preceding command output shows that the lower threshold of Up member interfaces of the
Eth-Trunk interface has been set to 4. However, the number of Up member interfaces of the EthTrunk interface is actually 3, which causes the Eth-Trunk interface to go Down.
l
If the Eth-Trunk interface is configured with a lower threshold of Up member interfaces

and this threshold is greater than the actual number of Up member interfaces, set the lower
threshold to a smaller value.
If the Eth-Trunk interface is not configured with a lower threshold of Up member interfaces,
go to Step 4.
Step 4 Check whether Eth-Trunk interfaces work in static LACP mode.

Run the display eth-trunk 1 command on Router A and Router B to view the configuration of
the Eth-Trunk interface.
Local:
LAG ID: 1
WorkingMode: STATIC
Preempt Delay: Disabled
System Priority: 32768
System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 8
-------------------------------------------------------------------------------ActorPortName
Status
PortType PortPri PortNo PortKey PortState Weight
Ethernet0/0/1
Unselect 100M
32768
264
305
11100010 1
Ethernet0/0/2
Unselect 100M
32768
265
305
11100010 1
Ethernet0/0/3
Unselect 100M
32768
266
305
11100011 1
Partner:
-------------------------------------------------------------------------------ActorPortName
SysPri SystemID
PortPri PortNo PortKey
PortState
Ethernet0/0/1
0
0000-0000-0000 0
0
0
11100011
Ethernet0/0/2
0
0000-0000-0000 0
0
0
11100011
Ethernet0/0/3
0
0000-0000-0000 0
0
0
11100011
If the Eth-Trunk interface is configured to work in static LACP mode and no physical
interface is selected, LACP negotiation was unsuccessful. Possible causes for unsuccessful
LACP negotiation are as follows:
Member interfaces fail, causing timeout of LACP protocol packets.
To correct this problem, connect the cable to another idle interface and add the interface
to the Eth-Trunk.
Issue 02 (2012-03-30)

58

Troubleshooting
The Eth-Trunk interface on one end is configured to work in static LACP mode, but the
Eth-Trunk interface on the other end is not.
To correct this problem, make the configurations of the two ends of the Eth-Trunk link
consistent.
After the configurations are corrected and LACP negotiation succeeds, the output of the
display eth-trunk 1 command is as follows:
[RouterB] display eth-trunk 1
Local:
LAG ID: 1
WorkingMode: STATIC
Preempt Delay: Disabled
System Priority: 32768
System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 8
Operate status: up
------------------------------------------------------------------------------ActorPortName
Status
PortType PortPri PortNo PortKey PortState Weight
Ethernet0/0/1
Selected 100M
32768
264
305
11111100 1
Ethernet0/0/2
Selected 100M
32768
265
305
11111100 1
Ethernet0/0/3
Selected 100M
32768
266
305
11111100 1
Partner:
------------------------------------------------------------------------------ActorPortName
SysPri SystemID
PortPri PortNo PortKey
PortState
Ethernet0/0/1
32768 0018-823c-c473 32768
2056
305
11111100
Ethernet0/0/2
32768 0018-823c-c473 32768
2057
305
11111100
Ethernet0/0/3
32768 0018-823c-c473 32768
2058
305
11111100
If LACP negotiation fails after the configurations are corrected, go to Step 5.

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

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

59

Troubleshooting
Devices at the Two Ends of an Eth-Trunk Cannot Ping Each Other Due to
Inconsistent Aggregation Modes
Fault Symptom
As shown in Figure 3-3, RouterA is an AR1200, and RouterB is a non-Huawei device. An EthTrunk consisting of two Ethernet links is configured between the two devices. After the
configuration, the devices cannot ping each other's management IP address.
Figure 3-3 Network diagram of an Eth-Trunk
Eth-Trunk 1
Eth-Trunk 1
Eth-Trunk
RouterA
RouterB
Fault Analysis
1.
Run the display current-configuration interface eth-trunk command on RouterA and

RouterB. The command outputs show that the Eth-Trunk interfaces on the two ends belong
to the same VLAN.
2.
Check the connection between the member interfaces. The member interfaces on RouterA
are correctly connected to the member interfaces on RouterB.
3.
Run the display interface command on RouterA and RouterB to check the status of the
member interfaces. All the member interfaces are in Up state.
4.
Run the display trunkmembership eth-trunk command on RouterA and RouterB to

check the number of member interfaces in the Eth-Trunk. The two ends contain the same
number of member interfaces.
5.
Run the display mac-address command on RouterA and RouterB to check their MAC
address tables. The command outputs show that RouterA learns the MAC address of
RouterB, but RouterB does not learn the MAC address of RouterA. The negotiation
between the two ends may fail. On the network, LACP is enabled on RouterB, but
RouterA uses the manual aggregation mode. RouterA does not respond to the LACP
negotiation request sent by RouterB; therefore, the Eth-Trunk is Down.
Procedure
Step 1 Disable LACP on RouterB.
RouterA and RouterB can ping each other successfully.
----End
Summary
When connecting a Huawei switch to a non-Huawei switch by using an Eth-Trunk, ensure that
the two switches use the same link aggregation mode.
Issue 02 (2012-03-30)

60

Troubleshooting
Two Ends of an Eth-Trunk Cannot Communicate Because They Have Different

Numbers of Member Interfaces
Fault Symptom
Figure 3-4 shows the network diagram of an Eth-Trunk.
Figure 3-4 Networking diagram of Eth-Trunk
Eth0/0/1
Eth0/0/1
Eth-Trunk 1
Eth0/0/2
RouterA
Eth0/0/2
RouterB
RouterA and RouterB cannot communicate with each other.
Fault Analysis
1.
Run the display current-configuration interface eth-trunk command on RouterA and

RouterB to check the VLANs that the Eth-Trunk interfaces belong to. The command
outputs show that the Eth-Trunk interfaces on the two ends belong to the same VLAN.
2.
Check the connection between the member interfaces. The member interfaces on RouterA
are correctly connected to the member interfaces on RouterB.
3.
Run the display interface command on RouterA and RouterB to check the status of the
member interfaces. All the member interfaces are in Up state.
4.
Run the display trunkmembership eth-trunk command on RouterA and RouterB to

check the number of member interfaces. The Eth-Trunk interface on RouterA contains two
member interfaces, but the Eth-Trunk interface on RouterB contains only one member
interface (Eth0/0/1). The numbers of member interfaces on the two devices are different,
so they cannot communicate with each other.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the eth-trunk trunk-id command to add Eth0/0/2 to Eth-Trunk 1.
Step 4 Run the return command to return to the user view, and then run the save command to save the
configuration.
After the preceding operations are completed, RouterA and RouterB can communicate with each
other.
----End
Issue 02 (2012-03-30)

61

Troubleshooting
Summary
The two ends of an Eth-Trunk must have the same number of member interfaces; otherwise, the
two ends cannot communicate with each other.
Issue 02 (2012-03-30)

62

Troubleshooting
4 LAN
LAN
About This Chapter

4.1 VLAN Troubleshooting
This chapter describes common causes of VLAN faults, and provides the corresponding
4.2 MAC Address Table Troubleshooting
This chapter describes common causes of MAC address table faults, and provides the
4.3 MSTP Troubleshooting
This chapter describes common causes of MPLS faults, and provides the corresponding
4.4 Transparent Bridging Troubleshooting
This chapter describes common causes of transparent bridging faults, and provides the
4.5 WLAN Troubleshooting
Issue 02 (2012-03-30)

63

Troubleshooting
4 LAN
4.1 VLAN Troubleshooting

This chapter describes common causes of VLAN faults, and provides the corresponding
4.1.1 Users in a VLAN Cannot Communicate with Each Other

This section describes common causes of the communication failure between users in a portbased VLAN, and provides the corresponding troubleshooting flowcharts, troubleshooting
procedures, alarms, and logs.
Common Causes
l
The link between users is faulty.
The interfaces connected to the users are shut down manually or the physical interfaces are
damaged.
The device learns incorrect MAC addresses.
Port isolation is configured on the device.
Incorrect static Address Resolution Protocol (ARP) entries are configured on the user
terminals.
Incorrect mappings between interfaces and MAC addresses are configured on the device.
NOTE
If users in different VLANs cannot communicate with each other, rectify the fault according to the IP
Forwarding Troubleshooting.
Issue 02 (2012-03-30)

64

Troubleshooting
4 LAN
Figure 4-1 Troubleshooting flowchart for communication failure between users in a port-based
VLAN
Users in a VLAN
cannot
communicate
Are user interfaces

in the VLAN Up?
No
Bring the interfaces to

Up state
Yes
No
Yes
Are terminal
IP addresses
correct?
Is the fault
rectified?
No
Modify terminal IP
addresses
Is the fault
rectified?
Yes
No
Yes
Yes
Are the
learned MAC
address entries
correct?
No
Is VLAN
configuration
correct?
No
Modify VLAN
configuration
Is the fault
No
rectified?
Yes
No
Yes
Seek technical
support
Is port isolation
configured?
Yes
Disable port isolation
No
Modify static ARP

entries
Yes
Seek technical
support
Issue 02 (2012-03-30)
Yes
No
No
Are static ARP
entries on terminals
correct?
Is the fault
rectified?

Is the fault
rectified?
Yes
No
End
65

Troubleshooting
4 LAN
NOTE
Procedure
Step 1 Check that the interfaces connected to the user terminals are in Up state.
Run the display interface interface-type interface-number command in any view to check the
status of the interfaces.
l
If the interface is in Down state, check for the cause and make the interface Up. The
following table provides the common causes and troubleshooting methods.
Cause
Method
The interface was

manually shut
down.
Run the interface interface-type interface-number command in the

system view to enter the interface view, and then run the display
this command to check the interface status. If the interface was shut
down by using the shutdown command, run the undo shutdown
command in the interface view.
The link fails.
Replace the cable between the user terminal and the Router.
NOTE
If the user terminal is connected to the Router by using a twisted pair, select
a new twisted pair with a proper transmission according to the distance
between the user terminal and the Router.
Duplex modes and Run the speed, duplex, and negotiation auto commands to ensure
speeds of the local that the duplex modes and speeds of the interfaces are the same.
and remote
interfaces are
different.
The interface is
faulty.
Connect the devices using other idle interfaces.
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 Router are correct.
Run the display mac-address command on the Router to check whether the MAC addresses,
interfaces, and VLANs in the learned MAC address entries are correct. If the learned MAC
address entries are incorrect, run the undo mac-address mac-address vlan vlan-id command
on the interface to delete the current entries so that the Router can learn MAC address entries
again.
After the MAC address table is updated, check the MAC address entries again.
l If the MAC address entries are incorrect, go to Step 4.
Issue 02 (2012-03-30)

66

Troubleshooting
4 LAN
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
The VLAN has

been created.
Run the display vlan vlan-id command in any view to check whether
the VLAN has been created. If not, run the vlan command to create
the VLAN.
The interfaces
have been added to
the VLAN.
Run the display vlan vlan-id command in any view to check whether
the VLAN contains the interfaces. If not, add the interfaces to the
VLAN.
NOTE
If the interfaces are located on different devices, add the interfaces connecting
the devices to the VLAN.
l Add an access interface to the VLAN by using either of the

following methods:
NOTE
The default type of a router interface is hybrid. To change the interface
type to access, run the port link-type Access command in the interface
view.
1. Run the port default vlan command in the interface view.

2. Run the port command in the VLAN view.
l Add a trunk interface to the VLAN.
NOTE
type to trunk, run the port link-type trunk command in the interface
view.
Run the port trunk allow-pass vlan command in the interface

view.
l Add a hybrid interface to the VLAN by using either of the
following methods:
NOTE
type to hybrid, run the port link-type Hybrid command in the interface
view.
1. Run the port hybrid tagged vlan command in the interface

view.
2. Run the port hybrid untagged vlan command in the
interface view.
Connections
between interfaces
and user terminals
are correct.
Check the connections between interfaces and user terminals

according to the network plan. If any user terminal is connected to
an incorrect interface, connect it to the correct interface.
After the preceding operations:

If the MAC address entries are correct, go to Step 5.
Issue 02 (2012-03-30)

67

Troubleshooting
4 LAN
If the MAC address entries are incorrect, go to Step 7.

Step 5 Check whether port isolation is configured.
Run the interface interface-type interface-number command in the system view to enter the
interface view, and then run the display this command to check whether port isolation is
configured on the interface.
l If port isolation is configured, run the undo port-isolate enable command on the interface
to disable port isolation.
l If port isolation is not configured, go to Step 6.
Step 6 Check whether correct static Address Resolution Protocol (ARP) entries are configured on the
user terminals.
l If the static ARP entries are incorrect, modify them.
l If the static ARP entries are correct, go to Step 7.
----End

Relevant Alarms
None.
Relevant Logs
None.
4.2 MAC Address Table Troubleshooting

This chapter describes common causes of MAC address table faults, and provides the
4.2.1 Correct MAC Address Entries Cannot Be Generated

procedure for the MAC address table fault.
Common Causes
l
The device fails to learn correct MAC address entries because of incorrect configuration.
The learned MAC addresses are updated frequently because of a loop on the network.
The MAC address learning function on the interface is disabled.
Issue 02 (2012-03-30)

68

Troubleshooting
4 LAN
Blackhole MAC address entries and MAC address learning limit are configured on the
interface.
The number of learned MAC addresses exceeds the maximum.
MAC address entries cannot be generated on the device, so Layer 2 forwarding fails.
l
Check the binding relationship between the outbound interface and the VLAN.
Check whether a loop occurs on the network.
Check whether the configurations on the interface conflict or MAC address learning limit
is configured on the interface.
Check whether the number of learned MAC addresses exceeds the limit.
Issue 02 (2012-03-30)

69

Troubleshooting
4 LAN

MAC entries
cannot be
generated
Are
configuration
incorrect?
No
Bind MAC
address,
interface, and
VLAN correctly
Is fault Yes
rectified?
Remove the loop
Is fault Yes
rectified?
Yes
Does loop exist?
Yes
No
No
No
Is MAC address
learning
disabled?
Yes
Enable MAC
address learning
Is fault Yes
rectified?
No
No
Is blackhole
MAC or MAC
learning limit
configured?
Yes Delete blackhole

MAC or MAC
learning limit
Is fault Yes
rectified?
No
No
Does
the number of
MAC entries
exceed
limit?
No
Yes
Delete some
MAC entries
Is fault
rectified?
Yes
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check that the configurations on the interface are correct.
Run the display mac-address command in the system view to check whether the binding
relationships between the MAC address, VLAN, and interface are correct.
<Huawei> display mac-address 000f-e207-f2e0
-------------------------------------------------------------------------------
Issue 02 (2012-03-30)

70

Troubleshooting
4 LAN
MAC Address
VLAN/Bridge
Learned-From
Type
------------------------------------------------------------------------------0025-9e80-2494 1/Eth 0/0/1
dynamic
------------------------------------------------------------------------------Total items displayed = 1
If not, re-configure the binding relationships between the MAC address, VLAN, and interface.
If so, go to Step 2.
Step 2 Check whether a loop on the network causes MAC address flapping.
If a loop exists on the network, use either of the following methods to prevent MAC address
flapping:
l
Remove the loop from the network.
Run the loop-detect eth-loop command in the VLAN view to enable the MAC flapping
detection function. The AR1200 checks whether a MAC address moves from one interface
to another in the VLAN. If MAC address flapping occurs, the AR1200 blocks the interface
or MAC address.
If no loop exists, go to Step 3.

Step 3 Check that MAC address learning is enabled.
Check whether MAC address learning is enabled in the interface view.
[Huawei-Ethernet0/0/1] display this
#
interface Ethernet0/0/1
mac-address learning disable
port hybrid tagged vlan 10
undo negotiation auto
#
return
If the command output contains mac-address learning disable, MAC address learning is
disabled on the interface.
l
If MAC address learning is disabled, run the undo mac-address learning disable
command in the interface view to enable MAC address learning.
If MAC address learning is enabled on the interface, go to Step 4.
Step 4 Check whether any blackhole MAC address entry or MAC address limiting is configured.
If a blackhole MAC address entry or MAC address limiting is configured, the interface discards
packets.
1.
Run the display mac-address blackhole command to check whether any blackhole MAC
address entry is configured.
[Huawei] display mac-address
blackhole
M-----------------------------------------------------------------------------MAC Address
VLAN/Bridge
Learned-From
Type
-----------------------------------------------------------------------------0001-0001-0001 3333/blackhole
-----------------------------------------------------------------------------Total items displayed = 1
Issue 02 (2012-03-30)

71

Troubleshooting
4 LAN
If a blackhole MAC address entry is displayed, run the undo mac-address blackhole
command to delete it.
2.
Run the display this command in the interface view.

l If the command output contains mac-limit maximum, the number of learned MAC
addresses is limited. Run either of the following commands:
Run the undo mac-limit command in the interface view to disable MAC address
limiting.
Run the mac-limit command in the interface view to increase the maximum number
of learned MAC addresses.
l Run the display this command in the interface view. If the command output contains
port-security max-mac-num or port-security enable, the number of secure dynamic
MAC addresses is limited on the interface. Run either of the following commands:
NOTE
By default, the limit on the number of secure dynamic MAC addresses is 1 after port security is enabled.
Run the undo port-security enable command in the interface view to disable port
security.
Run the port-security max-mac-num command in the interface view to increase
the maximum number of secure dynamic MAC addresses on the interface.
Step 5 Check whether the number of learned MAC addresses has reached the maximum supported by
the AR1200.
Run the display mac-address summary command to check the number of MAC addresses in
the MAC address table.
l
If the number of learned MAC addresses has reached the maximum, no MAC address entry
can be created. Run the display mac-address command to view MAC address entries.
If the number of MAC addresses learned on an interface is much more than devices on
the network connected to the interface, the MAC address table may be maliciously
updated by an attacker. Check the device connected to the interface:
If the interface is connected to a device, run the display mac-address command on
the device to view its MAC address table. Locate the interface connected to the
malicious user according to the displayed MAC address entries. If the interface that
you find is connected to another device, repeat this step until you find the user of
the malicious user.
If the interface is connected to a computer, perform either of the following operations
after obtaining permission of the administrator:
Disconnect the computer. When the attack stops, connect the computer to the
network again.
Run the port-security enable command on the interface to enable port security
or run the mac-limit command to set the maximum number of MAC addresses
that the interface can learn to 1.
If the interface is connected to a hub, perform either of the following operations:
Configure port mirroring and use a packet capture tool to observe packets
received by the interface. Analyze the packet types to locate the attacking
computer. Disconnect the computer after obtaining permission of the
administrator. When the attack stops, connect the computer to the hub again.
Issue 02 (2012-03-30)

72

Troubleshooting
4 LAN
Disconnect computers connected to the hub one by one after obtaining

permission of the administrator. If the fault is rectified after a computer is
disconnected, the computer is the attacker. After it stops the attack, connect it to
the hub again.
If the number of MAC addresses on the interface is smaller than or equal to the number
of devices connected to the interface, the number of devices connected to the
AR1200 has exceeded the maximum supported by the AR1200. Adjust network
deployment.
l
If the number of MAC addresses has not reached the maximum supported by the
AR1200, go to Step 6.
l
Results of the preceding troubleshooting procedure
Configuration file, log file, and alarm file of the AR1200
----End

Relevant Alarms
None.
Relevant Logs
None.
4.3 MSTP Troubleshooting

This chapter describes common causes of MPLS faults, and provides the corresponding
4.3.1 MSTP Topology Change Leads to Service Interruption

Common Causes
When the topology on an MSTP network changes, services are interrupted.
l
MSTP is incorrectly configured.
Physical links flap, triggering a large number of TC messages.
An MSTP-aware device receives MSTP TC messages from clients or transparentlytransmitted MSTP TC messages.
Changing MSTP topology leads to service interruption on the network shown in Figure 4-3.
Issue 02 (2012-03-30)

73

Troubleshooting
4 LAN
Figure 4-3 Networking diagram of MSTP
AR1
AR2
Eth0/0/1
Eth0/0/2
Eth0/0/1
Eth0/0/2
Eth0/0/2
Eth0/0/2
Eth0/0/1
AR3
Eth0/0/1
AR4
CIST(MSTI0):
Root Switch: AR1

Blocked port
MSTI1:
Root Switch: AR1

Blocked port
MSTI2:
Root Switch: AR2

Blocked port

l
Check that the MSTP status is correct.
Check whether the device has received TC messages.
Check that no physical interface on the device alternates between Up and Down.
Check that the MSTP convergence mode is Normal.
Issue 02 (2012-03-30)

74

Troubleshooting
4 LAN
Figure 4-4 Troubleshooting flowchart for service interruption due to changes in MSTP topology
Services are
interrupted or the
device is
disconnected
MSTP status is
correct?
No
Check and modify the

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

flapping interface
Is fault rectified?
Yes
No
No
MSTP
convergence mode is
Normal?
No
Set the MSTP

convergence mode to
Normal
Yes
Is fault rectified?
No
Yes
Collect information
End
NOTE
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 4-3, there is only one MSTP ring, which means that each
instance can have only one blocked interface. Run the display stp brief command on each device
to check whether the status of each port is normal.
Issue 02 (2012-03-30)

75

Troubleshooting
4 LAN
Run the display stp brief command in any view to check the MSTP status on AR1. As shown
in Figure 4-3, in instances 0 and 1, AR1 functions as a root bridge and all ports on AR1 are
designated ports. In instance 2, one port on AR1 is a designated port and the other port is a root
port. Both ports are in the Forwarding state.
[AR1] display stp brief
MSTID
Port
0
Ethernet0/0/1
0
Ethernet0/0/2
1
Ethernet0/0/1
1
Ethernet0/0/2
2
Ethernet0/0/1
2
Ethernet0/0/2
Role
DESI
DESI
DESI
DESI
ROOT
DESI
STP State
FORWARDING
FORWARDING
FORWARDING
FORWARDING
FORWARDING
FORWARDING
Protection
NONE
NONE
NONE
NONE
NONE
NONE
in Figure 4-3, in instances 2, AR2 functions as a root bridge and all ports on AR2 are designated
ports. In other instances, one port on AR2 is a designated port and the other port is a root port.
Both of them are in the Forwarding state.
MSTID
Port
0
Ethernet0/0/1
0
Ethernet0/0/2
1
Ethernet0/0/1
1
Ethernet0/0/2
2
Ethernet0/0/1
2
Ethernet0/0/2
Role
ROOT
DESI
ROOT
DESI
DESI
DESI
STP State
FORWARDING
FORWARDING
FORWARDING
FORWARDING
FORWARDING
FORWARDING
Protection
NONE
NONE
NONE
NONE
NONE
NONE
in Figure 4-3, in instance 2, one port on AR3 is an Alternate port and the other port is a root
port. The Alternate port is blocked and in the Discarding state. In other instances, one port on
AR3 is a designated port and the other port is a root port. Both of them are in the Forwarding
state.
MSTID
Port
0
Ethernet0/0/1
0
Ethernet0/0/2
1
Ethernet0/0/1
1
Ethernet0/0/2
2
Ethernet0/0/1
2
Ethernet0/0/2
Role
DEST
ROOT
DEST
ROOT
ALTE
ROOT
STP State
FORWARDING
FORWARDING
FORWARDING
FORWARDING
DISCARDING
FORWARDING
Protection
NONE
NONE
NONE
NONE
NONE
NONE
in Figure 4-3, in instance 0, one port on AR4 is an Alternate port and the other port is a root
port. The Alternate port is blocked and in the Discarding state. In instance 2, one port on AR4
is a designated port and the other port is a root port. Both of them are in the Forwarding state.
MSTID
Port
0
Ethernet0/0/1
0
Ethernet0/0/2
1
Ethernet0/0/1
1
Ethernet0/0/2
2
Ethernet0/0/1
2
Ethernet0/0/2
Role
ALTE
ROOT
ALTE
ROOT
DESI
ROOT
STP State
DISCARDING
FORWARDING
DISCARDING
FORWARDING
FORWARDING
FORWARDING
Protection
NONE
NONE
NONE
NONE
NONE
NONE
On the network shown in Figure 4-3, each instance has only one port in the Discarding
state and the other port is in the Forwarding state. If several ports are in the Discarding
state, an MSTP calculation error occurs. To solve this problem, go to Step 6.
If the MSTP status is correct, go to Step 2.
Step 2 Check that the MSTP configuration is correct.

Issue 02 (2012-03-30)

76

Troubleshooting
4 LAN
Run the display stp region-configuration command to view mappings between VLANs and
instances.
[AR1] display stp region-configuration
Oper Configuration:
Format selector :0
Region name
:huawei
Revision level :0
Instance
0
1
2
Vlans Mapped
21 to 4094
1 to 10
11 to 20
Check whether mappings between VLANs and instances are correct. If the mapping
between a VLAN and an instance is incorrect, run the instance command to map the VLAN
to a specified spanning tree instance. Run the active region-configuration command to
active the mapping between the VLAN and instance configured by using the instance
command.
Run the display current-configuration command to view the MSTP configuration in the
configuration file of the device.
l
Check whether MSTP is disabled on the interfaces connecting to user terminals or the
interfaces are configured as edge interfaces.
Check whether interfaces are added to VLANs correctly. For VLAN configurations, see
the chapter "VLAN Configuration" in the AR1200 Configuration Guide - Ethernetlan.
If the MSTP configuration is correct, go to Step 3.
Step 3 Check that no MSTP recalculation is performed.

Run the display stp command in any view to check whether the device has received TC
messages.
[AR1] display stp
-------[CIST Global Info][Mode MSTP]------CIST Bridge
:57344.00e0-fc00-1597
Bridge Times
:Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC
:0
.0018-826f-fc7a / 20000
CIST RegRoot/IRPC
:57344.00e0-fc00-1597 / 0
CIST RootPortId
:128.2
BPDU-Protection
:disabled
TC count per hello :0
STP Converge Mode
:Normal
Time since last TC :2 days 14h:16m:15s
-------[MSTI 1 Global Info]------MSTI Bridge ID
:4096.00e0-fc00-1597
MSTI RegRoot/IRPC
:4096.00e0-fc00-1597 / 0
MSTI RootPortId
:0.0
Master Bridge
:57344.00e0-fc00-1597
Cost to Master
:0
TC received
:0
If values of the TC or TCN received, TC count per hello, TC received, and TC count per
hello fields in the command output increase, the device has received TC messages and the
network topology has changed. In this case, you need to view log messages MSTP/6/
SET_PORT_DISCARDING and MSTP/6/SET_PORT_FORWARDING to check
whether the role of an MSTP-enabled port changes.
If the port role does not change, go to Step 4.
If the port role changes, go to Step 6.
Issue 02 (2012-03-30)

77

Troubleshooting
4 LAN
If the values in the TC or TCN received, TC count per hello, TC received, and TC count
per hello fields in the command output are 0s, it indicates that the device does not receive
any TC message. In this case, contact Huawei technical support personnel.
Step 4 Check that no interface on the device alternates between Up and Down.
View the log message IFNET/4/IF_STATE to check whether an MSTP-enabled port alternates
between Up and Down.
l
If an MSTP-enabled interface alternates between Up and Down, it indicates that the

interface flaps. If a physical interface frequently alternates between Up and Down, the
MSTP status of the device on the network will become unsteady. As a result, a large number
of TC messages are generated; ARP entries and MAC entries are frequently deleted;
services are interrupted. Run the shutdown command on the flapping interface. If services
are not restored after the flapping interface is shut down, go to Step 5.
If no interface flaps, go to Step 5.
Step 5 Check that the MSTP convergence mode is Normal.

Run the display stp command in any view to check the MSTP convergence mode of the device.
[AR1] display stp
-------[CIST Global Info][Mode MSTP]------CIST Bridge
:57344.00e0-fc00-1597
Bridge Times
:Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC
:0
.0018-826f-fc7a / 20000
CIST RegRoot/IRPC
:57344.00e0-fc00-1597 / 0
CIST RootPortId
:128.2
BPDU-Protection
:disabled
STP Converge Mode
:Normal
Time since last TC :2 days 14h:16m:15s
-------[MSTI 1 Global Info]------MSTI Bridge ID
:4096.00e0-fc00-1597
MSTI RegRoot/IRPC
:4096.00e0-fc00-1597 / 0
MSTI RootPortId
:0.0
Master Bridge
:57344.00e0-fc00-1597
Cost to Master
:0
TC received
:0
If the convergence mode is Normal, go to Step 6.
If the convergence mode is Fast, run the stp converge normal command to change the
convergence mode to Normal. If services are not restored after the convergence mode is
changed, go to Step 6.
----End

Relevant Alarms
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
Issue 02 (2012-03-30)

78

Troubleshooting
4 LAN
MSTP_1.3.6.1.2.1.17.0.2 topologyChange
Relevant Logs
MSTP/6/RECEIVE_MSTITC
VOSCPU/4/CPU_USAGE_HIGH
4.4 Transparent Bridging Troubleshooting

This chapter describes common causes of transparent bridging faults, and provides the
4.4.1 Layer 2 Traffic Forwarding in a Bridge Group Fails

procedure for a Layer 2 traffic forwarding failure within a bridge group.
Common Causes
Figure 4-5 Networking diagram for local bridging
RouterA
Eth0/0/3
Eth0/0/4
Bridge-if1
User 1
User 2
1.1.1.1/24 1.1.1.2/24
VLAN11
Bridge-if2
Eth0/0/0
Eth0/0/1
GE0/0/0
User 3
1.1.1.3/24
User 4
User 5
1.1.1.4/24 1.1.1.5/24
VLAN12
As shown in Figure 4-5, Users 1, 2, 3, 4, and 5 belong to the same network segment but different
VLANs. Local bridging is configured to allow users in VLAN 11 to communicate with User 3
but to be isolated from users in VLAN 12. That is, users that need to communicate with each
other are added to the same bridge group, whereas users that do not need to communicate with
each other are added to different bridge groups. The problem is that users in different bridge
groups can be isolated from each other, but those in the same bridge group cannot communicate
with each other. This fault is commonly caused by one of the following:
l
Physical interfaces fail to be added to bridge groups.
Member interfaces in bridge groups become faulty.
Issue 02 (2012-03-30)

79

Troubleshooting
4 LAN
Figure 4-6 Troubleshooting flowchart for a Layer 2 traffic forwarding failure within a bridge
group
Layer 2 traffic
forwarding in a
bridge group fails
Are there
No
member interfaces in
bridge groups?
Add physical
interfaces to
bridge groups
Is fault
rectified?
Yes
No
Yes
Are member
interfacesin bridge
groups Up?
No
Troubleshoot
member
interfaces
Yes
Is fault
rectified?
Yes
No
Collect debugging
information
Seek technical
support
End
Context
NOTE
Procedure
Step 1 Check that every bridge group has member interfaces.
Use Router A as an example. Run the display bridge information command on Router A to
check whether the bridge group has member interfaces.
<RouterA> display bridge information
Bridge 1 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
: MAC learning : Enable
interface :total 2 interface(s) in the bridge
GigabitEthernet0/0/0 : Up
Issue 02 (2012-03-30)

80

Troubleshooting
Vlanif11 : Up
Bridge 2 :
Status
:
Bridging
:
Routing
:
MAC learning :
interface :total
Vlanif12 : Up
4 LAN
Undo Shutdown
IP, Others
Enable
1 interface(s) in the bridge
If the bridge group does not have any member interfaces, add physical interfaces to the
bridge group.
For details on how to add physical interface to a bridge group, see the chapter "Transparent
Bridge Configuration" in the AR1200 Configuration Guide - LAN.
If the bridge group has member interfaces, go to Step 2.
Step 2 Check that member interfaces in each bridge group are Up.
check the member interface status in the bridge group on Router A.
Bridge 1 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
GigabitEthernet0/0/0 : Up
Vlanif11 : Up
Bridge 2 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
Vlanif12 : Up
If any member interface is Down, troubleshoot the member interfaces in the bridge group.
For example, check whether the interface is up and the protocol configuration is correct.
If all member interfaces are Up, go to Step 3.
l Configuration, log, and alarm files
----End

Relevant Alarms
None
Relevant Logs
None
Issue 02 (2012-03-30)

81

Troubleshooting
4 LAN
4.4.2 Traffic Forwarding in IP Routing of Bridge Groups Fails

procedure for a traffic forwarding failure in a network configured with IP routing of bridge
groups.
Common Causes
Figure 4-7 Networking diagram for IP routing of bridge groups
Eth1/0/0
Eth2/0/0
RouterA
RouterB
Eth2/0/1
Network
Eth2/0/1
Eth2/0/0
Bridge-if1
Bridge-if2
User 1
User 2
1.1.1.1/24 1.1.1.2/24
Enterprise A
User 4
2.1.1.4/24
Enterprise C
As shown in Figure 4-7, Enterprise A and Enterprise C are on different network segments. To
allow the two enterprises to communicate with each other, IP routing has been configured for
bridge groups. The enterprises, however, cannot communicate with each other. This fault is
commonly caused by one of the following:
l
Physical interfaces fail to be added to bridge groups.
Member interfaces in bridge groups become faulty.
Routes between the two enterprises are unreachable.
Issue 02 (2012-03-30)

82

Troubleshooting
4 LAN
Figure 4-8 Troubleshooting flowchart for a traffic forwarding failure in a network configured
with IP routing of bridge groups
Traffic forwarding in
IP routing of bridge groups
fails
Are there
member interfaces
in bridge groups?
No
Add physical
interfaces to bridge
groups
Is fault Yes
rectified?
No
Yes
Are Bridge-if
interfaces Up?
No
Check member
interfaces in bridge
groups and rectify the
fault
Yes
Enable IP routing for
bridge groups and
No
Are routes reachable?
configure IP
addresses for Bridge-if
interfaces correctly
Yes
Are
network-side
interfaces added to
the same bridge
group?
No
Add network-side
interfaces to the same
bridge group
Is fault
rectified?
Yes
No
Is fault
rectified?
Yes
No
Is fault Yes
rectified?
No
Yes
Collect debugging
information
End
Seek technical
support
NOTE
Procedure
Step 1 Check that every bridge group has member interfaces.
check whether the bridge group on Router A has member interfaces.
Issue 02 (2012-03-30)

83

Troubleshooting
4 LAN

Bridge 1 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
: IP
MAC learning : Enable
Ethernet1/0/0 : Up
Ethernet2/0/0 : Up
Bridge 2 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
: IP
Ethernet2/0/1 : Up
If the bridge group does not have any member interfaces, add physical interfaces to the
bridge group as shown in Figure 4-7.
For details on how to add physical interface to a bridge group, see the chapter "Transparent
Bridge Configuration" in the AR1200 Configuration Guide - LAN.
If the bridge group has member interfaces, go to Step 2.
Step 2 Check that every Bridge-if interface is Up.

Use Router A as an example. Run the display interface bridge-if command on Router A to
check the Bridge-if interface status.
<RouterA> display interface bridge-if
Bridge-if1 current state : UP
Line protocol current state : UP
Last line protocol up time : 2011-01-07 15:13:49 UTC-08:00
Description:HUAWEI, AR Series, Bridge-if1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 1.1.1.3/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-057a-a000
Physical is BRIDGE-IF
Current system time: 2011-01-07 15:27:12-08:00
Last 300 seconds input rate 0 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
Realtime 24 seconds input rate 0 bits/sec, 0 packets/sec
Realtime 24 seconds output rate 0 bits/sec, 0 packets/sec
Input: 11 packets,0 bytes,
10 unicast,1 broadcast,0 multicast
0 errors,0 drops,0 unknownprotocol
Output:13 packets,0 bytes,
0 errors,0 drops
Input bandwidth utilization : 0.00%
Output bandwidth utilization : 0.00%
Bridge-if2 current state : UP
Description:HUAWEI, AR Series, Bridge-if2 Interface
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-057a-a000
Physical is BRIDGE-IF
Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec
Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec
Input: 139 packets,0 bytes,
0 errors,0 drops,0 unknownprotocol
Output:140 packets,0 bytes,
Issue 02 (2012-03-30)

84

Troubleshooting
4 LAN
0 errors,0 drops
If the Bridge-if interface is Down, troubleshoot the member interfaces in the bridge group.
For example, check whether the interface is up and the protocol configuration is correct.
If the Bridge-if interface is Up, go to Step 3.
Step 3 Check that the routes between different bridge groups are reachable.
Run the Ping command on Router A to check whether different bridge groups can ping each
other successfully.
l
If the ping fails, go to Step 4.
If the ping succeeds, go to Step 5.
Step 4 Check that IP routing is enabled for the bridge group.

Run the display bridge information command on Router A to check information about the
configured bridge group.
Bridge 1 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
: IP
Ethernet1/0/0 : Up
Ethernet2/0/0 : Up
Bridge 2 :
Status
: Undo Shutdown
Bridging
: IP, Others
Routing
: IP
Ethernet2/0/1 : Up
If IP routing is not enabled for the bridge group, run the routing ip command in the bridge
group view to enable IP routing.
If IP routing has been enabled for the bridge group, check whether the IP address is correctly
configured for the Bridge-if interface. For details, see the chapter "The Ping Operation
Fails" in the AR1200 Troubleshooting - IP Forwarding and Routing.
If different bridge groups still cannot ping each other successfully after the preceding steps are
complete, go to Step 5.
Step 5 Check that the network-side interfaces on Router A and Router B are added to the same bridge
group.
Run the display this command on Router A and Router B to check the configuration on networkside interfaces.
# Check the network-side interface configuration on Router A.
<RouterA> system-view
[RouterA] interface ethernet2/0/1
[RouterA-Ethernet2/0/1] display this
#
bridge 2
undo shutdown
#
return
Issue 02 (2012-03-30)

85

Troubleshooting
4 LAN
# Check the network-side interface configuration on Router B.

<RouterB> system-view
[RouterB] interface ethernet2/0/1
[RouterB-Ethernet2/0/1] display this
#
bridge 2
undo shutdown
#
return
If the network-side interfaces on Router A and Router B are added to the same bridge group,
go to Step 6.
If the network-side interfaces on Router A and Router B are not added to the same bridge
group, see the chapter "Transparent Bridge Configuration" in the AR1200 Configuration
Guide - LAN Access and MAN Access to add the network-side interfaces to the same bridge
group.
l Configuration, log, and alarm files
----End

Relevant Alarms
None
Relevant Logs
None
4.5 WLAN Troubleshooting

NOTE
The AR1200 functions as a fat AP to provide wireless Internet access service
4.5.1 A STA Fails to Discover Radio Signals

Common Causes
l
The wireless network adapter on the STA is faulty.
No antenna is installed on the AP.
The AP is faulty.
No VAP is created on the AR1200.
Issue 02 (2012-03-30)

86

Troubleshooting
SSID hiding is enabled for the VAP.
The radio interface is disabled on the AP.
A channel conflict occurs.
A low radio signal power is set for the AP on the AR1200.
4 LAN
Issue 02 (2012-03-30)

87

Troubleshooting
4 LAN
Figure 4-9 STA fails to discover radio signals

A STA fails to discover
radio signals
Does
the wireless network
adapter of the STA work
properly?
No
Replace it with a new

wireless network
adapter
Is fault
rectified?
Yes
No
Yes
Is an antenna installed
on the AP?
No
install an antenna on
the AP
Is fault
rectified?
Yes
No
Yes
Does the AP work
properly?
No
Reset the AP and

restart the AC
Is fault
rectified?
Yes
No
Yes
Is a VAP created?
No
Bind a service set to

a specified radio to
create a VAP
Is fault
rectified?
Yes
No
Yes
Is SSID hiding
enabled in the VAP?
Yes
Disable SSID hiding
Is fault
rectified?
Yes
No
No
Is the radio interface on

the AP enabled?
No
Enable the radio

interface
Is fault
rectified?
Yes
No
Yes
Does a channel conflict
occur?
Yes
Change the AP radio

channel to the channel
with less interference
signals
Is fault
rectified?
Yes
No
No
Is the
transmit power of the
radio too low?
Yes
Set a lower transmit

power level for the radio
Is fault
rectified?
Yes
No
No
End
Issue 02 (2012-03-30)

88

Troubleshooting
4 LAN
NOTE
Procedure
Step 1 Check that the wireless network adapter on the STA is working properly.
Use another wireless network adapter to check whether radio signals can be discovered.
l If radio signals can be discovered, the wireless network adapter on the original STA is faulty.
Replace it with a new wireless network adapter.
l If a radio signal cannot be discovered, go to step 2.
Step 2 Check that an antenna is installed on the AP.
l If no antenna is installed, install an antenna on the AP.
l If an antenna is installed, go to step 3.
Step 3 Check that the AP is working properly.
Run the display ap command on the AR1200 and check the State field.
l If the State field is displayed as fault, the AP is faulty. Run the ap-reset command to reset
the AP:
If the AP cannot transition to the normal state after it is reset, restart the AR1200. If the
AP still cannot transition to the normal state, go to step 9.
If the AP transitions to the normal state after it is reset, go to step 4.
l If the State field is displayed as normal, the AP is working properly. Go to step 4.
Step 4 Check that a VAP is created on the AR1200.
Run the display vap command on the AR1200 to check whether a VAP is created.
l If Error:VAP does not exist is displayed, no VAP is created. Run the service-set command
to bind a service set to a specified radio to create a VAP.
l If VAP information is displayed, a VAP has been created. Go to step 5.
Step 5 Check that SSID hiding is disabled in the VAP.
Run the display service-set command on the AR1200 to check whether SSID hiding is enabled
in the VAP.
l If the Hide SSID field is displayed as enable, SSID hiding has been enabled for the VAP.
Run the undo ssid-hide command to disable SSID hiding.
l If the Hide SSID field is displayed as disable, SSID hiding is disabled for the VAP. Go to
step 6.
Step 6 Check that the radio interface is enabled on the AP.
Run the display radio config command on the AR1200 to check the radio interface status.
l If the Administrate status field is displayed as disable, the radio interface is disabled. Run
the radio enable command to enable the radio interface.
Issue 02 (2012-03-30)

89

Troubleshooting
4 LAN
l If the Administrate status field is displayed as enable, the radio interface has been enabled.
Go to step 7.
Step 7 Check whether a channel conflict occurs.
Use the NetStumbler software to check whether a channel conflict occurs. If many radio signals
are transmitted over channel 11 but no radio signal is transmitted over channel 1, run the
channel command to change the AP radio channel to channel 1 from channel 11. If the fault
persists, go to step 8.
Step 8 Check the radio signal power configured for the AP on the AR1200.
Run the display actual channel-power command on the AR1200 to check the channel and
power parameters of the specified radio.
NOTE
The POWER-LEVEL field specifies the current transmit power level of a radio. The value of this field
ranges from 0 to 15. Level 0 indicates the maximum power. Level 1 is 1 dBm less than level 0; level 2 is
2 dBm less than level 0; and so on. A higher power level indicates a lower power. When the transmit power
level is set to 12, 13, 14, or 15, the POWER-LEVEL field is always displayed as 12.
l If the POWER-LEVEL field is displayed as 12 or a value near 12, the STA is unable to
discover radio signals because the current transmit power of the radio is too low. Run the
power-level command to set a lower transmit power level for the radio.
l If the POWER-LEVEL field is displayed as 0 or a value near 0, the current transmit power
of the radio is within the specified range. Go to step 9.
l Configuration files, log files, and alarm files of the AR1200
----End

Relevant Alarms
None
Relevant Logs
None
4.5.2 WLAN Users Are Frequently Logged Out

Common Causes
l
The wireless network adapter on the STA is faulty.
No antenna is installed on the AP.
Issue 02 (2012-03-30)

90

Troubleshooting
4 LAN
A channel conflict occurs.
A low radio signal power is set for the AP on the AR1200.
Other wireless devices interfere with the radio signals from the AP.
Figure 4-10 WLAN users are logged out frequently
WLAN users are logged
out frequently
Does
the wireless network
adapter of the STA
work properly?
No
Replace it with a new

wireless network
adapter
Is fault
rectified?
Yes
No
Yes
Is an
antenna installed on the
AP?
No
Install an antenna on
the AP
Is fault
rectified?
Yes
No
Yes
Does a channel conflict
occur?
Yes
Change the AP radio

channel to the channel
with less interference
signals
Is fault
rectified?
Yes
No
No
Is the transmit power of
the radio too low?
Yes
Set a lower transmit

power level for the
radio
Is fault
rectified?
Yes
No
No
Do other
wireless devices interfere
with AP's radio signals?
Yes
Turn off these devices
Is fault
rectified?
Yes
No
No
End
NOTE
Issue 02 (2012-03-30)

91

Troubleshooting
4 LAN
Procedure
Step 1 Check that the wireless network adapter on the STA is working properly.
Use another wireless network adapter to check whether WLAN users are logged out frequently.
l If no WLAN user is logged out unexpectedly, the wireless network adapter on the STA is
faulty. Replace it with a new wireless network adapter.
l If WLAN users are logged out frequently, go to step 2.
Step 2 Check that an antenna is installed on the AP.
l If no antenna is installed, install an antenna on the AP.
l If an antenna is installed, go to step 3.
Step 3 Check whether a channel conflict occurs.
Use the NetStumbler software to check whether a channel conflict occurs. If many radio signals
are transmitted over channel 11 but no radio signal is transmitted over channel 1, run the
channel command to change the AP radio channel to channel 1 from channel 11. If the fault
Step 4 Check the radio signal power configured for the AP on the AR1200.
Run the display actual channel-power command on the AR1200 to check the channel and
power parameters of the specified radio.
NOTE
The POWER-LEVEL field specifies the current transmit power level of a radio. The value of this field
ranges from 0 to 15. Level 0 indicates the maximum power. Level 1 is 1 dBm less than level 0; level 2 is
2 dBm less than level 0; and so on. A higher power level indicates a lower power. When the transmit power
level is set to 12, 13, 14, or 15, the POWER-LEVEL field is always displayed as 12.
of the radio is too low. As a result, WLAN users are frequently logged out. Run the powerlevel command to set a lower transmit power level for the radio.
of the radio is within the specified range. Go to step 5.
Step 5 Check whether there are other wireless devices interfering with the AR1200.
Check whether there are other wireless devices interfering with the AR1200, for example, a
working microwave oven. Other wireless devices will interfere with radio signals from the AP,
causing WLAN users to be logged out frequently.
l If there are other wireless devices interfering with the AR1200, turn off these devices and
connect WLAN users to the AP again.
l If there are no other wireless devices, go to step 6.
----End

Issue 02 (2012-03-30)

92

Troubleshooting
4 LAN
Relevant Alarms
None
Relevant Logs
None
Issue 02 (2012-03-30)

93

Troubleshooting
5 WAN
WAN
About This Chapter

5.1 E1/T1 Troubleshooting
5.2 FR Troubleshooting
5.3 MFR Troubleshooting
5.4 DCC Troubleshooting
5.5 ISDN Troubleshooting
5.6 PPPoE Troubleshooting
5.7 PPP Troubleshooting
5.8 xDSL Troubleshooting
This chapter describes how to locate and troubleshoot common xDSL faults with examples.
5.9 3G Troubleshooting
Issue 02 (2012-03-30)

94

Troubleshooting
5 WAN
5.1 E1/T1 Troubleshooting

5.1.1 E1/T1 Interface in Up State Fails to Correctly Send and Receive
Data
Common Causes
This fault occurs in the following situations:
l
No data is sent or received on the serial interface.
Data is incorrectly sent or received on the serial interface.

l
The CPLD logic version of the E1/T1 board is incorrect.
Timeslots of the remote interface are incorrectly bound.
Issue 02 (2012-03-30)

95

Troubleshooting
5 WAN
Figure 5-1 E1/T1 interface in Up state failing to correctly send and receive data
E1/T1 interface in Up
state fails to correctly
send and receive data
Are
configurations of
physical interfaces on
both ends the
same?
Yes
Are
configurations of
serial interfaces on
both ends the
same
No
No
Ensure that
configurations of
physical interfaces
on both ends are
the same
Ensure that
configurations of
serial interfaces on
both ends are the
same
Yes
Is the physical
status of the serial
interface Up?
No
Undo shut down

the serial interface
Is fault
rectified?
Yes
No
Is fault Yes
rectified?
No
Is fault
rectified?
Yes
No
Yes
Is the serial interface
sending data?
No
Reset the serial

interface
Is fault Yes
rectified?
No
Yes
Does the serial
interface receive error
packets?
No
Ensure that the

cable is properly
connected to the
serial interface
Is fault Yes
rectified?
No
Yes
End
NOTE
Procedure
Step 1 Check that the local and remote interfaces have the same configurations.
Run the display this command in the controller interface view to check the controller interface
configuration.
[Huawei]controller e1 1/0/0
[Huawei-E1 1/0/0]display this
[V200R001C00B000]
#
controller E1 1/0/0
Issue 02 (2012-03-30)

96

Troubleshooting
5 WAN
channel-set 0 timeslot-list 1
frame-format crc4
clock master
#
return
Check whether physical attributes of the local and remote controller interfaces are the same. For
example, check whether their frame formats are both CRC4, whether their encoding and
decoding modes are both HDB3, whether both of them are configured not to invert data, and
whether their timeslots bound to form a channel are the same. In addition, check whether the
two controller interfaces are configured to work in master clock mode and slave clock mode
respectively.
l
If the two controller interfaces have different configurations or frequently alternate between
Up and Down states, reconfigure the two interfaces.
If the two controller interfaces have the same configurations and remain Up, go to step 2.
Step 2 Check that the local and remote serial interfaces have the same configurations.
Run the display this command in the serial interface view to check the serial interface
configuration.
[Huawei-E1 1/0/0]int serial
1/0/0:0
[Huawei-Serial1/0/0:0]display
this
[V200R001C00B000]
#
interface Serial1/0/0:0
link-protocol ppp
timer hold 0
ip address 1.1.1.2 255.255.255.0
#
return
Check whether the two serial interfaces have the same protocol configurations and physical
attributes, whether they are encapsulated with PPP, and whether they use the default 16-bit CRC.
Check whether they have been shut down.
NOTE
If interfaces on both ends have different CRC configurations, communication between them will fail
because of CRC errors.
If the two serial interfaces have different configurations, reconfigure them.
If the two serial interfaces have the same configurations but cannot correctly send or receive
data, go to step 3.
Step 3 Check whether the local and remote serial interfaces are sending and receiving data.
Run the display this interface command in the serial interface view to check the serial interface
status.
[Huawei-Serial1/0/0:0] display this interface
Serial1/0/0:0 current state : UP
Description:HUAWEI, AR Series, Serial1/0/0:0 Interface
Route Port,The Maximum Transmit Unit is 1500, Hold timer is 0(sec)
Derived from E1 1/0/0, Timeslot(s) Used: 1, baudrate is 64000 bps
Link layer protocol is PPP
LCP opened, IPCP opened
Last physical up time
: 2008-01-08 02:59:52 UTC-05:13
Last physical down time : 2008-01-07 22:40:43 UTC-05:13
Issue 02 (2012-03-30)

97

Troubleshooting
5 WAN
Last 300 seconds input rate 213795 bytes/sec 1710360 bits/sec 4276 packets/sec
Last 300 seconds output rate 213796 bytes/sec 1710368 bits/sec 4276 packets/sec
Input: 140727 packets, 12665430 bytes
length errors:
0, giants:
0
CRC:
0, align errors:
0
aborts:
0, no buffers:
0
Output: 0 packets, 0 bytes
too long errors:
0
Check whether the two serial interfaces are sending data. If they are not sending data, upperlayer negotiation packets are not sent. Run the shutdown or undo shutdown command on
them to enable the upper layer to send packets.
If the two serial interfaces are sending and receiving data, go to step 4.
Step 4 Check whether the local and remote serial interfaces have sent and received error packets.
Run the display this interface command in the serial interface view to check the serial interface
status.
[Huawei-Serial1/0/0:0] display this interface
Serial1/0/0:0 current state : UP
Last line protocol up time : 2011-03-24 13:52:40
Description:HUAWEI, AR Series, Serial1/0/0:0 Interface
Derived from E1 4/0/0, Timeslot(s) Used: 1-31, baudrate is 1984000 bps
: 2011-03-24 13:46:02
Last physical down time : 2011-03-24 13:46:02
Current system time: 2011-03-24 14:03:31
Last 300 seconds input rate 213795 bytes/sec 1710360 bits/sec 4276 packets/sec
Last 300 seconds output rate 213796 bytes/sec 1710368 bits/sec 4276 packets/sec
length errors:
0, giants:
CRC:
1, align errors:
aborts:
0, no buffers:
too long errors:
0
0
0
1

Check whether the two serial interfaces have received a large number of CRC error packets.
If so, check whether the cable between them is properly installed.
If the fault persists after the cable is properly installed, go to step 5.
l
Configuration files, log files, and alarm files of the device
----End
Issue 02 (2012-03-30)

98

Troubleshooting
5 WAN
Relevant Alarms
l
Controller interface Up alarm: Nov 28 2007 21:13:47+08:00 AR1220 %%01IFPDT/4/

IF_STATE(l)[4]:Interface E1 1/0/0 has turned into UP state.
Controller interface Down alarm: Nov 28 2007 21:13:41+08:00 AR1220 %%01IFPDT/4/

IF_STATE(l)[0]:Interface E1 1/0/0 has turned into DOWN state.
Serial interface Up alarm: May 11 2011 17:21:30 AR1220 %%01IFNET/4/LINK_STATE

(l)[3332]:The line protocol PPP IPCP on the interface Serial1/0/0:0 has entered the UP
state.
Serial interface Down alarm: May 11 2011 17:21:26 AR1220 %%01IFNET/4/

LINK_STATE(l)[3330]:The line protocol PPP IPCP on the interface Serial41/0/0:0 has
entered the DOWN state.
Relevant Logs
None
5.2 FR Troubleshooting
5.2.1 Local Device Fails to Ping the Remote Device When the Link
Protocol Status of Their Connected FR Interfaces Is Up
Common Causes
A ping failure may occur in the following scenarios:
l
Basic FR is configured.
A PVC group is configured.

l
In the scenario where basic FR is configured:

1.
No IP address is assigned to the interface.
2.
The mapping between the PVC and peer IP address is not generated.
3.
The mapping between the PVC and peer IP address is generated but no route is
generated.
In the scenario where a PVC group is configured:

1.
No priority is configured for PVCs in the PVC group.
2.
The default PVC is not specified in the PVC group and some priorities are not
configured for PVCs in the PVC group.
NOTE
If a ping operation is performed between two indirectly connected devices, check whether static routes are
configured on the two devices in addition to checking the preceding items.
Issue 02 (2012-03-30)

99

Troubleshooting
5 WAN
Figure 5-2 shows the troubleshooting flowchart in the scenario where basic FR is configured.
Figure 5-2 Troubleshooting flowchart for a ping failure when basic FR is configured
A ping failure occurs
when the link protocol
status of two FR
interfaces is Up
Is a PVC
configured on the
DCE-side interface?
No
Configure a PVC
on the interface
Is fault
rectified?
Yes
No
Yes
Does
the number
of PVCs on the DTE-side
interface reach the
threshold?
Yes
Delete
unnecessary PVCs
Yes
No
No
Are IP addresses
assigned to interfaces
on both ends?
Is fault
rectified?
No
Assign IP
addresses to the
interfaces
Is fault
rectified?
Yes
No
Yes
Is InARP enabled?
No
Enable InARP
Is fault
rectified?
Yes
No
Yes
Is the mapping
between the PVC and
peer IP address
generated?
No
Configure the
mapping
Is fault
rectified?
Yes
No
Yes
Do both ends have

reachable routes to
each other?
No
Configure
reachable routes
Is fault
rectified?
Yes
No
Yes
End
Figure 5-3 shows the troubleshooting flowchart in the scenario where a PVC group is
configured.
Issue 02 (2012-03-30)

100

Troubleshooting
5 WAN
Figure 5-3 Troubleshooting flowchart for a ping failure when a PVC group is configured
status is Up
Is the PVC
group status of
interfaces Active?
No
Check the
physical status of
the interfaces
Is fault Yes
rectified?
No
Yes
Are all the
priorities in a PVC
group configured for
PVCs?
Yes
Configure
priorities for
PVCs
Is fault
rectified?
Yes
No
No
End
NOTE
Procedure
l
In the scenario where basic FR is configured:

1.
Check that a PVC is configured on the DTE-side interface.

Run the display fr pvc-info interface serial command in the system view to check
whether there is PVC information.
[Huawei]display fr pvc-info interface Serial
2/0/0:2
PVC statistics for interface Serial2/0/0:2 (DTE, physical
UP)
DLCI = 300, USAGE = UNUSED (00000000),
Serial2/0/0:2
create time = 2008/01/03 19:05:54, status =
ACTIVE
InARP = Enable, PVC-GROUP =
NONE
in packets = 0, in bytes =
0
out packets = 0, out bytes = 0
If no PVC information is displayed, no PVC exists on the interface. Configure the

PVC on the DCE-side interface. If you are sure that the PVC exists on the DCEside interface, you can also configure PVC on the DTE-side interface.
If the value of the status field is INACTIVE, there is a possibility that no PVC
exists on the DCE-side interface. Configure the PVC on the DCE-side interface.
If the value of the status field is ACTIVE, the PVC functions properly. Go to step
2.
Issue 02 (2012-03-30)

101

Troubleshooting
5 WAN
NOTE
If a sub-interface is configured on the DTE-side interface, configure a DLCI for the subinterface.
2.
Check that the number of PVCs configured on the DTE-side interface does not exceed
the threshold.
Run the display fr pvc-info command on the DTE-side interface to check the
configured PVCs.
[Huawei]display fr pvcinfo
PVC statistics for interface Serial2/0/0:2 (DTE, physical
UP)
Serial2/0/0:2
ACTIVE
NONE
0
out packets = 0, out bytes =
0
If the number of configured PVCs has reached the threshold, no more PVCs can be
created. The AR1200 supports a maximum of 128 PVCs.
If the number of configured PVCs has exceeded the threshold, delete unnecessary
PVCs.
If the number of configured PVCs does not exceed the threshold, go to step 3.
3.
Check that IP addresses have been assigned to interfaces on both ends.

Run the display this command in the FR interface view to check whether an IP address
is assigned to the interface.
this
[
V200R001C00B110]
#
interface
Serial2/0/0:2
link-protocol
fr
ip address 7.7.7.2
255.255.255.0
#
return
If no IP address is assigned to the interface, assign an IP address to this interface.

If an IP address has been assigned to the interface, go to step 4.
4.
Check that InARP is enabled on the interface.

Run the display this command on the interface to check the interface configuration.
this
[
V200R001C00B110]
#
interface
Serial2/0/0:2
link-protocol
Issue 02 (2012-03-30)

102

Troubleshooting
5 WAN
fr
undo fr
inarp
ip address 7.7.7.2
255.255.255.0
#
return
If the undo fr inarp command has been run on the interface, InARP has been
disabled on the interface. Run the fr inarp on the interface to enable InARP.
If InARP has been enabled on the interface, go to step 5.
5.
Check that the mapping between the PVC and peer address has been generated.
Run the display fr map-info command to check whether the mapping between the
PVC and peer address is generated.
[Huawei-Serial2/0/0:2]display fr mapinfo
Map Statistics for interface MFR0/0/0
(DCE)
DLCI = 100, bridge 1,
MFR0/0/0
ACTIVE
encapsulation = ietf, vlink = 0,
broadcast
Map Statistics for interface Serial2/0/0:2
(DTE)
DLCI = 300, IP INARP 7.7.7.1,
Serial2/0/0:2
ACTIVE
encapsulation = ietf, vlink = 9,
broadcast
If no mapping is generated, configure the mapping between the PVC and peer
address.
If the mapping has been generated, go to step 6.
6.
Check that both ends have reachable routes to each other.

Run the display fib command to check the routing table.
[Huawei-Serial2/0/0:0]display this
[
V200R001C00B130]
#
interface
Serial2/0/0:0
link-protocol
fr
fr interface-type
dce
fr dlci
22
ip address 7.7.7.2
255.255.255.0
#
return
fib
Route Flags: G - Gateway Route, H - Host Route,
U - Up
Route
S - Static Route, D - Dynamic Route, B - Black Hole
Route
----------------------------------------------------------------------------FIB
Table:
Issue 02 (2012-03-30)

103

Troubleshooting
5 WAN
Total number of Routes :

17
Destination/Mask
TunnelID
7.7.7.1/32
0x0
7.7.7.255/32
0x0
7.7.7.2/32
0x0
50.1.1.255/32
0x0
50.1.1.1/32
0x0
192.168.0.255/32
0x0
192.168.0.23/32
0x0
36.1.1.255/32
0x0
36.1.1.2/32
0x0
255.255.255.255/32
0x0
127.255.255.255/32
0x0
127.0.0.1/32
0x0
127.0.0.0/8
0x0
36.1.1.0/24
0x0
192.168.0.0/24
0x0
50.1.1.0/24
0x0
7.7.7.0/24
0x0
Nexthop
Flag TimeStamp
Interface
7.7.7.1
HU
t[2917]
S2/0/0:0
127.0.0.1
HU
t[2907]
InLoop0
127.0.0.1
HU
t[2907]
InLoop0
127.0.0.1
HU
t[2519]
InLoop0
127.0.0.1
HU
t[2519]
InLoop0
127.0.0.1
HU
t[495]
InLoop0
127.0.0.1
HU
t[495]
InLoop0
127.0.0.1
HU
t[492]
InLoop0
127.0.0.1
HU
t[492]
InLoop0
127.0.0.1
HU
t[484]
InLoop0
127.0.0.1
HU
t[484]
InLoop0
127.0.0.1
HU
t[484]
InLoop0
127.0.0.1
t[484]
InLoop0
36.1.1.2
t[492]
VT3
192.168.0.23
t[495]
GE0/0/0
50.1.1.1
t[2519]
S2/0/1:15
7.7.7.2
t[2907]
S2/0/0:0
In the command output, the local IP address is 7.7.7.2, the peer IP address is 7.7.7.1,
and the information in bold indicates the correct routing entry.
If the preceding routing entry is not displayed, configure this route.
If the preceding routing entry is displayed, go to step 7.
7.
Collect the following information and contact Huawei technical support personnel.
In the scenario where a PVC group is configured:

1.
Check that the PVC group status of FR interfaces on both ends is Active.
Run the display fr pvc-group command to check the PVC group status.
[Huawei-Serial2/0/0:0]display fr pvcgroup
PVC-GROUP-name
State
TosType
INARP
Interface
Type
PhyStatus
1
Active
PRECEDENCE Enable Serial2/0/0:0
DTE
Up
If the PVC group status is not displayed as Active, check the physical status of the
interfaces.
If the PVC group status has been displayed as Active, go to step 2.
Issue 02 (2012-03-30)

104

Troubleshooting
2.
5 WAN
Check that all the priorities in a PVC group are configured for PVCs in the PVC group.
Run the display this command in the interface view to check the interface
configuration.
[Huawei-Serial2/0/0:0]display this
interface
Serial2/0/0:0
link-protocol
fr
fr pvc-group
1
fr dlci
22
fr dlci
33
fr ip precedence 22 0
4
fr ip precedence 33
default
ip address 7.7.7.2
255.255.255.0
#
return
NOTE
Two types of priorities are available for IP packets: IP precedence and DSCP. The IP preference
value ranges from 0 to 7, and the DSCP value ranges from 0 to 63. If no default PVC is specified,
all the priorities need to be configured for PVCs in a PVC group. Only one type of priority
(either the IP precedence or DSCP) can be configured for PVCs in a PVC group.
If some priorities in the PVC group are not configured for PVCs in the PVC group,
reconfigure priorities for PVCs.
If all the priorities have been configured for PVCs in the PVC group, go to step 3.
3.
----End

Relevant Alarms
When the link protocol status of an FR interface alternates between Up and Down states, the
following alarms are generated:
FR/4/TRAP:OID 1.3.6.1.2.1.10.32.0.1 Interface 9 DLCI 22 turns into 2 state (invalid(1), active
(2),inactive(3)).
%%01IFNET/4/LINK_STATE(l)[3]:The line protocol on the interface Serial1/0/0:0 has entered
the UP state.
Relevant Logs
None
Issue 02 (2012-03-30)

105

Troubleshooting
5 WAN

Two Devices Fail to Ping Each Other When the Link Protocol Status of Their
Connected FR Interfaces Is Up Because No IP Address Is Assigned to One Device
Fault Symptom
As shown in Figure 5-4, two AR1200s are directly connected through two CE1 interfaces. An
FR link is established between the two CE1 interfaces, and the link protocol status of the two
CE1 interfaces is Up. The two devices, however, cannot ping each other.
Figure 5-4 Directly connected devices failing to ping each other
FR link
DTE
DCE
Fault Analysis
1.
Check whether a PVC is configured on the DCE-side interface.
2.
Check whether there is a PVC on the DTE-side interface.

Run the display fr pvc-info command to check whether there is a PVC on the DTE.
3.
Check whether a correct IP address is assigned to the DTE-side interface.

No IP address is assigned to the DTE-side interface.
Procedure
Step 1 Assign an IP address to the DTE-side interface.
After step 1 is completed, the two Huawei AR1200 Seriess can ping each other successfully.
----End
Summary
A DTE learns a PVC from a DCE using the LMI protocol after the link protocol status of the
FR interfaces becomes Up. After IP addresses are assigned to the FR interfaces, the DTE and
DCE learn their peer IP addresses using InARP on the PVC between the two interfaces to
generate routing entries. The DTE and DCE can ping each other successfully only when correct
routing entries are generated.
5.3 MFR Troubleshooting

Issue 02 (2012-03-30)

106

Troubleshooting
5 WAN
5.3.1 Local Device Fails to Ping the Remote Device When the Link
Protocol Status of Their Connected MFR Interfaces Is Up
Common Causes
Ping operations may be performed between directly connected devices or between indirectly
connected devices.
l
In the scenario where basic MFR is configured:

1.
No IP address is assigned to the interface.
2.
The mapping between the PVC and peer IP address is not generated.
3.
The mapping between the PVC and peer IP address is generated but no route is
generated.
In the scenario where PPPoMFR is configured:

1.
No IP address is configured in the virtual template interface.
2.
PPP negotiation fails.
Figure 5-5 shows the troubleshooting flowchart in the scenario where basic MFR is configured.
Issue 02 (2012-03-30)

107

Troubleshooting
5 WAN
Figure 5-5 Troubleshooting flowchart for a ping failure when basic MFR is configured
status of two MFR
interfaces is Up
Is a PVC
configured on the
DCE-side interface?
No
Configure a PVC
on the interface
Is fault
rectified?
Yes
No
Yes
Does the
number of PVCs on
the DTE-side interface
reach the
threshold?
Yes
Delete unnecessary
PVCs
Is fault
rectified?
Yes
No
No
Are IP addresses
assigned to interfaces
on both ends?
No
Assign IP
addresses to the
interfaces
Is fault
rectified?
Yes
No
Yes
No
Is InARP enabled on
both ends?
Enable InARP
Is fault
rectified?
Yes
No
Yes
Is the mapping
between the PVC and
peer IP address
generated?
No
Configure the
mapping
Is fault
rectified?
Yes
No
Yes
Do both ends have
reachable routes to
each other?
No
Configure
reachable routes
Is fault
rectified?
Yes
No
Yes
End
NOTE
Issue 02 (2012-03-30)

108

Troubleshooting
5 WAN
Procedure
l
In the scenario where a MFR is configured:

1.
Check that a PVC is configured on the DTE-side interface.

Run the display fr pvc-info interface serial command in the system view to check
whether there is PVC information.
[Huawei-MFR0/0/0]display fr pvc-info interface MFR
0/0/0
PVC statistics for interface MFR0/0/0 (DTE, physical
UP)
MFR0/0/0
ACTIVE
NONE
994
out packets = 22, out bytes = 950
If no PVC information is displayed, no PVC exists on the interface. Configure the

PVC on the DCE-side interface. If you are sure that the PVC exists on the DCEside interface, you can also configure PVC on the DTE-side interface.
If the value of the status field is INACTIVE, there is a possibility that no PVC
exists on the DCE-side interface. Configure the PVC on the DCE-side interface.
If the value of the status field is ACTIVE, the PVC functions properly. Go to step
2.
NOTE
If a sub-interface is configured on the DTE-side interface, configure a DLCI for the subinterface.
2.
Check that the number of PVCs configured on the DTE-side interface does not exceed
the threshold.
Run the display fr pvc-info command on the DTE-side interface to check the
configured PVCs.
[Huawei-MFR0/0/0]display fr pvcinfo
PVC statistics for interface MFR0/0/0 (DTE, physical
UP)
MFR0/0/0
ACTIVE
NONE
1218
out packets = 29, out bytes =
1160
If the number of configured PVCs has reached the threshold, no more PVCs can be
created. The AR1200 supports a maximum of 128 PVCs.
Issue 02 (2012-03-30)

109

Troubleshooting
5 WAN
If the number of configured PVCs has exceeded the threshold, run the undo fr dlci
dlci-number command to delete unnecessary PVCs.
If the number of configured PVCs does not exceed the threshold, go to step 3.
NOTE
PVCs can be deleted only when their DLCIs are deleted from both the DCE and DTE.
3.
Check that IP addresses have been assigned to interfaces on both ends.

Run the display this command in the MFR interface view to check whether an IP
address is assigned to the interface.
[Huawei-MFR0/0/0]display
this
[
V200R001C00B130]
#
interface
MFR0/0/0
ip address 5.5.5.2 255.255.255.0
If no IP address is assigned to the interface, assign an IP address to this interface.

If an IP address has been assigned to the interface, go to step 4.
4.
Check that InARP is enabled on the interface.

Run the display this command on the interface to check the interface configuration.
this
[
V200R001C00B130]
#
interface
MFR0/0/0
undo fr
inarp
ip address 5.5.5.2
255.255.255.0
#
return
If the undo fr inarp command has been run on the interface, InARP has been
disabled on the interface. Run the fr inarp on the interface to enable InARP.
If InARP has been enabled on the interface, go to step 5.
5.
Check that the mapping between the PVC and peer address has been generated.
Run the display fr map-info command to check whether the mapping between the
PVC and peer address is generated.
[Huawei]display fr map-info
Map Statistics for interface MFR0/0/0
(DTE)
DLCI = 22, IP INARP 5.5.5.1,
MFR0/0/0
Issue 02 (2012-03-30)

110

Troubleshooting
5 WAN

ACTIVE
encapsulation = ietf, vlink = 2, broadcast
If no mapping is generated, configure the mapping between the PVC and peer
address.
If the mapping has been generated, go to step 6.
6.
Check that both ends have reachable routes to each other.

Run the display fib command to check the routing table.
[Huawei-MFR0/0/0]display this
#
interface
MFR0/0/0
ip address 5.5.5.2
255.255.255.0
return
[Huawei-MFR0/0/0]display
fib
Route Flags: G - Gateway Route, H - Host Route,
U - Up
Route
S - Static Route, D - Dynamic Route, B - Black Hole
Route
----------------------------------------------------------------------------FIB
Table:
Total number of Routes :
17
Destination/Mask
TunnelID
5.5.5.1/32
0x0
5.5.5.255/32
0x0
5.5.5.2/32
0x0
50.1.1.255/32
0x0
50.1.1.1/32
0x0
192.168.0.255/32
0x0
192.168.0.23/32
0x0
6.6.6.255/32
0x0
6.6.6.2/32
0x0
255.255.255.255/32
0x0
127.255.255.255/32
0x0
127.0.0.1/32
0x0
127.0.0.0/8
0x0
6.6.6.0/24
0x0
192.168.0.0/24
0x0
Issue 02 (2012-03-30)
Nexthop
Flag TimeStamp
5.5.5.1
HU
t[2082]
MFR0/0/0
127.0.0.1
HU
t[1025]
InLoop0
127.0.0.1
HU
t[1025]
InLoop0
127.0.0.1
HU
t[545]
InLoop0
127.0.0.1
HU
t[545]
InLoop0
127.0.0.1
HU
t[501]
InLoop0
127.0.0.1
HU
t[501]
InLoop0
127.0.0.1
HU
t[496]
InLoop0
127.0.0.1
HU
t[496]
InLoop0
127.0.0.1
HU
t[487]
InLoop0
127.0.0.1
HU
t[487]
InLoop0
127.0.0.1
HU
t[487]
InLoop0
127.0.0.1
t[487]
InLoop0
6.6.6.2
t[496]
VT3
192.168.0.23
t[501]
GE0/0/0

Interface
111

Troubleshooting
5 WAN
50.1.1.0/24
0x0
5.5.5.0/24
0x0
50.1.1.1
t[545]
S2/0/1:23
5.5.5.2
t[1025]
MFR0/0/0
In the command output, the local IP address is 5.5.5.2, the peer IP address is 5.5.5.1,
and the information in bold indicates the correct routing entry.
If the preceding routing entry is not displayed, configure this route.
If the preceding routing entry is displayed, go to step 7.
7.
----End

Relevant Alarms
When the link protocol status of an MFR interface alternates between Up and Down states, the
following alarms are generated:
FR/4/TRAP:OID 1.3.6.1.2.1.10.32.0.1 Interface 9 DLCI 22 turns into 2 state (invalid(1), active
(2),inactive(3)).
%%01IFNET/4/LINK_STATE(l)[9]:The line protocol on the interface MFR0/0/0 has entered
the UP state
%%01IFNET/4/LINK_STATE(l)[11]:The line protocol PPP IPCP on the interface VirtualTemplate3:0 has entered the UP state.
Relevant Logs
None

Two Devices Fail to Ping Each Other When the Link Protocol Status of Their
Connected MFR Interfaces Is Up Because InARP Is Disabled on One Device
Fault Symptom
As shown in Figure 5-6, two Huawei AR1200 Seriess are directly connected through two CE1
interfaces. An MFR link is established between the two CE1 interfaces, and the link protocol
status of the two CE1 interfaces is Up. The two devices, however, cannot ping each other.
Figure 5-6 Directly connected devices failing to ping each other
MFR link
DTE
Issue 02 (2012-03-30)
DCE

112

Troubleshooting
5 WAN
Fault Analysis
1.
Check whether a PVC is configured on the DCE-side interface.

InARP is disabled.
Procedure
Step 1 Enable InARP.
After step 1 is completed, the two Huawei AR1200 Seriess can ping each other successfully.
----End
Summary
A DTE learns a PVC from a DCE using the LMI protocol after the link protocol status of their
connected MFR interfaces becomes Up. After IP addresses are assigned to the MFR interfaces,
the DTE and DCE learn their peer IP addresses using InARP on the PVC between the two
interfaces to generate routing entries. The DTE and DCE can ping each other successfully only
when correct routing entries are generated.
5.4 DCC Troubleshooting

5.4.1 Failed to Initiate Calls
Common Causes
l
A link is not set up.
The DCC configurations are incorrect.
The network-side device does not respond.
The AR rejects the call because the interaction packet type is incorrect.
The network-side device rejects the call because the interaction packet type is incorrect.
The data channel is not Up because negotiation fails.
Issue 02 (2012-03-30)

113

Troubleshooting
5 WAN
Figure 5-7 ISDN troubleshooting flowchart (failed to initiate calls)

The AR fails to
initiate calls
No
Is the link set up

successfully?
Rectify the ISDN

link fault
Is fault
rectified?
Yes
Yes
No
Is DCC properly
configured?
No
Yes
Modify DCC
configurations
Is fault
rectified?
Yes
No
Is a call
triggered?
No
Restart the AR
Is fault
rectified?
Yes
No
Yes
Does
No
network-side device
respond?
Restart the
network-side
device
Is fault
rectified?
Yes
Yes
No
Yes
Does AR
reject the call?
Restart the AR
Is fault
rectified?
No
Yes
No
Does
Yes
network-side
device reject the
call?
Restart the
network-side
device
Is fault
rectified?
No
Yes
No
Is the data
channel in Up
state?
No
Rectify the data

channel fault
Is fault
rectified?
Yes
Yes
No
Seek technical
support
End
Issue 02 (2012-03-30)

114

Troubleshooting
5 WAN
NOTE
Procedure
Step 1 Check that a link is set up successfully.
Run the display isdn call-info command to check the call status.
l If no information is displayed, the PRI interface is not created. Create a PRI interface.
l If the value of State in the command output is TEI_ASSIGNED or
AWAITING_ESTABLISHMENT, the link is not set up. Rectify the fault according to
5.5.1 Link Failed to Be Established on ISDN Interfaces.
l If the value of State in the command output is MULTIPLE_FRAME_ESTABLISHED,
the link has been set up. Go to step 2.
Step 2 Check that the DCC configurations are correct.
Run the display this command in the serial interface view or dialer interface view to check the
following interface configurations:
l Whether the dialer rule is configured and whether the dialer rule number is the same as the
dialer group number
l Whether the dialer number is correct if the dialer number mode is used
l Whether the IP address is correct if the dialer route IP mode is used
NOTE
Before using the display this command in the series interface view, run the display device command to
check the slot ID of 2E1/T1-M, which is the slot ID of the serial interface.
If the preceding configurations are incorrect, re-configure the DCC parameters. If they are
correct, run the debugging dialer all, debugging isdn cc, debugging isdn q931, terminal
debugging, and terminal monitor commands to check whether DCC triggers a call.
l If the command outputs do not contain DCC debugging information, DCC does not trigger
a call. Restart the AR1200.
l If the command outputs contain DCC debugging information, DCC has triggered a call, but
the call may be failed. Go to step 3.
The DCC debugging information is as follows:
<Huawei>
Oct 14 2007 09:07:40.760.1+08:00 AR1220 DCC/7/debug:DCC: try to find routing to
'4.4.4.2' on interface Dialer1
Oct 14 2007 09:07:40.760.2+08:00 AR1220 DCC/7/debug:DCC: the packet is
interesting.
Oct 14 2007 09:07:40.760.3+08:00 AR1220 DCC/7/debug:DCC: DCC_ProcPktForDialNum
called...
Oct 14 2007 09:07:40.760.4+08:00 AR1220 DCC/7/debug:DCC: DCC_ProcDialPktNoLink:
Dial to the remote host
Oct 14 2007 09:07:40.770.1+08:00 AR1220 DCC/7/debug:DCC: Try to find a free channel
to dial '012345678901234567890123456789' on the interface Dialer1
Oct 14 2007 09:07:40.770.2+08:00 AR1220 DCC/7/debug:DCC: Dialing
012345678901234567890123456789 on interface Serial1/0/0:15 of interface Dialer1
Oct 14 2007 09:07:40.770.3+08:00 AR1220 DCC/7/debug:DCC: DDR Dial :send
DDR_CONN_REQ message successfuly,sertype=8,IfIndex=0x9
Oct 14 2007 09:07:40.770.4+08:00 AR1220 DCC/7/debug:DCC: not set the queue! discard
this packet
Issue 02 (2012-03-30)

115

Troubleshooting
5 WAN
Oct 14 2007 09:07:40.780.1+08:00 AR1220 CC/7/

CC_Debug:
CC<-DDR :
ISDN_CONN_REQ
CallID=0xffffffff UserID=0x2 PortID=0x9 ServiceType=0x8 Channel=0x2
IsCompleted=0x0 Cause=0x00 szCalledNum=01234567890123456789456789
Step 3 Check that the network-side device sends response packets.

Run the debugging dialer all, debugging isdn cc, debugging isdn q931, terminal
debugging, and terminal monitor commands to check whether the network-side device sends
response packets.
l If the command outputs do not contain N->U, the network-side device does not send response
packets. Restart the network-side device.
l If the command outputs contain N->U, the network-side device has sent response packets.
Go to step 4.
Step 4 Check whether the AR1200 rejects the call.
Various interaction packets are sent during the setup of an ISDN call. If the AR1200 receives a
packet of a wrong type, the AR1200 rejects the call.
debugging, and terminal monitor commands to check whether the AR1200 rejects the call.
l If the following information is displayed, the AR1200 has rejected the call. Restart the
AR1200.
<Huawei> Oct 14 2007 08:56:10.30.1+08:00 AR1220 CC/7/CC_Debug:
CC <-DDR : ISDN_DISC_REQ
CallID=0x0 UserID=0x0 PortID=0x9 ServiceType=0x8 Channel=0x2 IsCompleted=0x0
Cause=0x00
Oct 14 2007 08:56:10.30.2+08:00 AR1220 CC/7/CC_Debug:
CC->Q931: PRIM_DISCONNECT_REQ
CCIndex=0x0 L3Index=0x1 PortID=0x9 CES=0x1 *cause=08 02 80 90
Oct 14 2007 08:56:10.40.1+08:00 AR1220 Q931/7/Q931_Debug: Serial1/0/0:15
U->N
DL_I_Data_Req CES = 1
cr= 01 01 DISCONNECT *cause=08 02 80 90
l If the command outputs do not contain the preceding information, the AR1200 has accepted
the call. Go to step 5.
Step 5 Check whether the network-side device rejects the call.
debugging, and terminal monitor commands to check whether the network-side device rejects
the call.
l If the following information is displayed, the network-side device has rejected the call.
Restart the network-side device.
<Huawei> Oct 14 2007 09:40:38.10.1+08:00 AR1220 Q931/7/Q931_Debug:
Serial1/0/0:15
N->U
DL_I_Data_Ind CES = 1
Oct 14 2007 09:40:38.10.2+08:00 AR1220 Q931/7/Q931_Debug:
[FUN: ProcMsgDisconnect, LINE: 545] ISDN Layer 3 call state change:->
CS_DISCONNECT_INDICATION
Oct 14 2007 09:40:38.10.3+08:00 AR1220 CC/7/CC_Debug:
CC<-Q931: PRIM_DISCONNECT_IND
Issue 02 (2012-03-30)

116

Troubleshooting
5 WAN
l If the command outputs do not contain the preceding information, the network-side device
has accepted the call. Go to step 6.
Step 6 Check that the protocol status of the data channel is Up.
Run the display isdn active-channel command to check the activated data channel.
<Huawei> display isdn active-channel
Serial1/0/0:15
------------------------------------------------------------------------------Channel Call
Call
Calling
Calling
Called
Called
Info
Property Type
Number
Subaddress Number
Subaddress
------------------------------------------------------------------------------B26
Digital
Out
88888204
88888206
Run the display interface serial 1/0/0:15 command to check the data channel corresponding to
the call. If the protocol status is Line protocol current state : Up, the protocol status of the data
channel is Up. Go to step 7.
If the protocol status is Line protocol current state : DOWN, the protocol status of the data
channel is Down. Rectify the fault according to Protocol Status of a PPP Interface Is Down.
----End

Relevant Alarms
None.
Relevant Logs
None.
5.4.2 Failed to Receive Calls

Common Causes
l
A link is not set up.
The AR1200 does not receive the call.
The AR rejects the call because the interaction packet type is incorrect.
The network-side device rejects the call because the interaction packet type is incorrect.
The data channel is not Up because negotiation fails.
Issue 02 (2012-03-30)

117

Troubleshooting
5 WAN
Figure 5-8 ISDN troubleshooting flowchart (failed to receive calls)
When a call is
initiated, ISDN line
dialup fails
Can
No
a link be established
between two ISDN
interfaces?
Ensure that a link is

established between
the two ISDN interfaces
Yes
Yes
Is fault rectified?
No
Does the AR
receive the call?
No
Yes
Check the configurations
on the call initiator
Yes
Is fault rectified?
No
Does the
network-side device
send response
packets?
No
Restart or replace the

network-side device
Yes
Yes
Is fault rectified?
No
Does the AR
refuse the call?
Yes
Yes
Restart or replace the AR
Is fault rectified?
No
No
Does the networkside device refuse
the call?
No
Is the data
channel protocol
status Up?
Yes
Restart or replace the

network-side device
Yes
Is fault rectified?
No
No
Rectify the data

channel fault
Yes
Yes
Is fault rectified?
No
End
Issue 02 (2012-03-30)

118

Troubleshooting
5 WAN
NOTE
Procedure
Step 1 Check that a link is set up successfully.
Run the display isdn call-info command to check the call status.
l If no information is displayed, no PRI interface is configured as a dialer interface. Create a
dialer interface.
l If the value of State in the command output is TEI_ASSIGNED or
AWAITING_ESTABLISHMENT, the link is not set up. Rectify the fault according to
5.5.1 Link Failed to Be Established on ISDN Interfaces.
l If the value of State in the command output is MULTIPLE_FRAME_ESTABLISHED,
the link has been set up. Go to step 2.
Step 2 Check whether the AR1200 receives the call.
debugging, and terminal monitor commands to check whether the AR1200 sends and receives
packets.
l
If the command outputs do not contain N->U, the AR1200 does not receive calls. Check
the configurations on the call initiator.
If the following information is displayed, the AR1200 has received the call. Go to step 3.
<Huawei>
Oct 14 2007 10:30:19.160.1+08:00 AR1220 Q931/7/Q931_Debug:
Serial1/0/0:15
N->U
DL_I_Data_Ind CES =
1
cr= 02 00 e7 SETUP *send_comp=a1 *bearer=04 02 88 90 *chan_id=18 03 a1 83 9a
*called_n=70 05 80 30 31 32 33
Step 3 Check whether the AR1200 rejects the call.

Various interaction packets are sent during the setup of an ISDN call. If the AR1200 receives a
packet of a wrong type, the AR1200 rejects the call.
debugging, and terminal monitor commands to check whether the AR1200 rejects the call.
l If the following information is displayed, the AR1200 has rejected the call. Restart the
AR1200.
<Huawei> Oct 14 2007 08:56:10.30.1+08:00 AR1220 CC/7/CC_Debug:
CC <-DDR : ISDN_DISC_REQ
CallID=0x0 UserID=0x0 PortID=0x9 ServiceType=0x8 Channel=0x2 IsCompleted=0x0
Cause=0x00
Oct 14 2007 08:56:10.30.2+08:00 AR1220 CC/7/CC_Debug:
CC->Q931: PRIM_DISCONNECT_REQ
Oct 14 2007 08:56:10.40.1+08:00 AR1220 Q931/7/Q931_Debug: Serial1/0/0:15
U->N
DL_I_Data_Req CES = 1
l If the command outputs do not contain the preceding information, the AR1200 has accepted
the call. Go to step 4.
Issue 02 (2012-03-30)

119

Troubleshooting
5 WAN
Step 4 Check whether the network-side device rejects the call.

Various interaction packets are sent during the setup of an ISDN call. If the network-side device
receives a packet of a wrong type, it rejects the call.
debugging, and terminal monitor commands to check whether the network-side device rejects
the call.
l If the following information is displayed, the network-side device has rejected the call.
Restart the network-side device.
<Huawei> Oct 14 2007 09:40:38.10.1+08:00 AR1220 Q931/7/Q931_Debug:
Serial1/0/0:15
N->U
DL_I_Data_Ind CES =
1
Oct 14 2007 09:40:38.10.2+08:00 AR1220 Q931/7/
Q931_Debug:
[FUN: ProcMsgDisconnect, LINE: 545] ISDN Layer 3 call state change:->
CS_DISCONNECT_INDICATION
Oct 14 2007 09:40:38.10.3+08:00 AR1220 CC/7/
CC_Debug:
CC<-Q931:
PRIM_DISCONNECT_IND
l If the command outputs do not contain the preceding information, the network-side device
has accepted the call. Go to step 5.
Step 5 Check that the protocol status of the data channel is Up.
Run the display isdn active-channel command to check the activated data channel.
<Huawei> display isdn activechannel
Serial1/0/0:15
------------------------------------------------------------------------------Channel Call
Call
Calling
Calling
Called
Called
Info
Property Type
Number
Subaddress Number
Subaddress
------------------------------------------------------------------------------B26
Digital
Out
88888204
88888206
Run the display interface serial 1/0/0:15 command to check the data channel corresponding to
the call. If the protocol status is Line protocol current state : Up, the protocol status of the data
channel is Up. Go to step 6.
If the protocol status is Line protocol current state : DOWN, the protocol status of the data
channel is Down.
----End
Issue 02 (2012-03-30)

120

Troubleshooting
5 WAN

Relevant Alarms
None.
Relevant Logs
None.
5.5 ISDN Troubleshooting

5.5.1 Link Failed to Be Established on ISDN Interfaces
Common Causes
l
The physical interface cannot go Up.
The cable between ISDN interfaces is faulty.
The interface configuration is incorrect.
Packets are incorrectly sent.
The network-side device is faulty.
Issue 02 (2012-03-30)

121

Troubleshooting
5 WAN
Figure 5-9 Link failing to be established on ISDN interfaces

A link fails to be
established between
two ISDN interfaces
Is the physical
interface Up?
No
Ensure that the

physical
interface is Up
Is fault
rectified?
Yes
No
Yes
Is the AR correctly
sending packets?
No
Is fault Yes
rectified?
Restart or
replace the AR
No
Yes
Does the
network-side device
send response
packets?
No
Replace the
network-side
device
Is fault
rectified?
Yes
No
Yes
End
NOTE
Procedure
Step 1 Check that the physical status of the interface is Up.
Run the display controller e1 command in the system view to check whether the physical status
of the interface is Up. The following information uses the display on E1 1/0/0 as an example.
l
If "E1 1/0/0 current state : Administratively DOWN" is displayed, E1 1/0/0 has been shut
down by the administrator. Run the undo shutdown command on E1 1/0/0 to enable it. If
"E1 1/0/0 current state : DOWN" is displayed after the undo shutdown command is run,
rectify the fault according to the following table.
If "E1 1/0/0 current state : DOWN" is displayed, check the following items.
Issue 02 (2012-03-30)

122

Troubleshooting
5 WAN
Item
Description
Follow-up Operation
Check that the

connection and
cable between the
local and remote
interfaces and
modules on
interfaces are
working properly.
If the Alarm State field is

displayed as Loss-of-Signal,
the following faults may occur:
Connect the two interfaces

properly. If the fault persists,
replace the cable or interface
board.
1. The local and remote

interfaces are not properly
connected.
2. The interface modules fail.
3. The cable between the two
interfaces is disconnected.
Check the working

mode of the local
and remote
interfaces.
The Work Mode field indicates

the working mode of an
interface:
l E1 FRAMED: The interface
works in framed mode.
l E1 UNFRAMED: The
interface works in unframed
mode.
If the local and remote

interfaces work in unframed
mode, run the pri-set command
on the CE1 interface view to set
the working mode to framed
mode.
The local and remote interfaces

must work in framed mode.
Check whether the
local and remote
interfaces use the
same frame
format.
The Frame-format field

indicates the frame format of an
interface:
l CRC4: The frame is a multiframe.
l NO-CRC4: The frame is a
basic frame, which is also
called a dual-frame or an
odd-even frame.

interfaces use different frame
formats, run the frame-format
command in the CE1 interface
view to reconfigure the frame
format so that the two interfaces
use the same frame format.

must use the same frame format.
Issue 02 (2012-03-30)
Check whether the

local and remote
interfaces use the
same encoding and
decoding mode.
The Line Code field indicates

the encoding and decoding
mode of an interface. The value
is HDB3.
must use the same encoding and
decoding mode.
If the remote interface does not

use the HDB3 mode, change it
to the HDB3 mode so that the
local and remote interfaces use
the same mode.
Check whether the

clock mode is
correctly
configured for the
local and remote
interfaces.
When two routers are directly

connected using two CE1
interfaces, the two CE1
interfaces work in master clock
mode and slave clock mode
respectively.
If the clock mode is incorrectly

configured for the local and
remote interfaces, run the
clock command in the CE1
interface view to correctly
configure the clock mode.

123

Troubleshooting
5 WAN
Item
Description
Follow-up Operation
Check whether the

loopback function
is configured on
the local and
remote interfaces.
Run the display this command

in the CE1 interface view to
check whether the loopback
function is configured on the
interface. If loopback local,
loopback payload, or
loopback remote is displayed,
the loopback function is
configured on the interface. The
loopback function will cause the
interface to alternate between
Up and Down states. Therefore,
disable the loopback function
after loopback detection is
complete.
If the loopback function has

been configured on the local and
remote interfaces, run the undo
loopback command in the CE1
interface view to disable the
loopback function.
NOTE
After the display controller e1
command is run in the system
view, if the Alarm State field is
displayed as Alarm-IndicationSignal, the loopback function may
be configured on the interface.
If "E1 1/0/0 current state : DOWN" is still displayed, go to step 4.

l
If "E1 1/0/0 current state : UP" is displayed, E1 1/0/0 is in Up state. Go to step 2.
Step 2 Check that packets are sent and received on the local and remote interfaces.
NOTE
After the display controller e1 command is run in the system view, if the Alarm State field is displayed
as Remote-Alarm-Indication, packets may be incorrectly sent or received on the local and remote
interfaces.
Run the debugging isdn q921, terminal debugging, and terminal monitor commands in
sequence to check sent packets. In the command output, U->N indicates a direction from the
user-side interface to the network-side interface, and Len indicates the SABME frame length.
The correct SABME frame length is 3 bytes and the contents of a SABME frame is 00 01 7F or
02 01 7F.
l
If the following information is displayed, the length and contents of the sent SABME frames
are incorrect. Restart or replace the device.
<Huawei>
Oct 12 2007 11:54:42.240.1+08:00 Huawei Q921/7/Q921_Debug:
Serial1/0/0:15
U->N Len=7 00 01 7F 00 00 00 00
U->N sapi=00 tei=00 c/r=0 SABME p=1
<Huawei>
Serial1/0/0:15
U->N Len=7 00 01 7F 00 00 00
00
<Huawei>
Issue 02 (2012-03-30)

124

Troubleshooting
5 WAN
Serial1/0/0:15
U->N Len=7 00 01 7F 00 00 00
00
U->N sapi=00 tei=00 c/r=0
SABME
p=1
If the following information is displayed, SABME frames are correctly sent. Go to step 3.
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
U->N sapi=00 tei=00 c/r=0
SABME
p=1
Step 3 Check that the network-side interface sends response packets.

NOTE
After the display controller e1 command is run in the system view, if the Alarm State field is displayed
as Remote-Alarm-Indication, packets may be incorrectly sent or received on the local and remote
interfaces; if the Alarm State field is displayed as Loss-of-Frame, an error occurs when packets are sent
on the remote interface.
Run the debugging isdn q921, terminal debugging, and terminal monitor commands in
sequence to check sent packets. In the command output, N->U indicates a direction from the
network-side interface to the user-side interface. If response packets have been received from
the remote end, information is displayed following N->U.
l
If the following information (only U->N information) is displayed, no response packet is

sent from the network-side interface. Check whether the network-side device is faulty.
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Oct 12 2007 14:28:52.430.1+08:00 Huawei Q921/7/
Q921_Debug:
[FUN: ISDN_Q921_T200Out, LINE: 2182] ISDN Layer 2 link state change ->
TEI_ASSIGNED
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Oct 12 2007 14:28:57.430.2+08:00 Huawei Q921/7/
Q921_Debug:
[FUN: ISDN_Q921_HandleEstablishReq, LINE: 185] ISDN Layer 2 link state change
-> AWAITING_ESTABLISHMENT
Issue 02 (2012-03-30)

125

Troubleshooting
5 WAN
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
U->N sapi=00 tei=00 c/r=0 SABME
p=1
Q921/7/
Q921_Debug:
[FUN: ISDN_Q921_T200Out, LINE: 2182] ISDN Layer 2 link state change ->
TEI_ASSIGNED
If the following information (both U->N and N->U information) is displayed, the networkside interface correctly sends response packets. Go to step 4.
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Serial1/0/0:15
U->N Len=3 00 01
7F
<Huawei>
Serial1/0/0:15
N->U Len=3 02 01
73
N->U sapi=00 tei=00 c/r=1 UA f=1
<Huawei>
Oct 12 2007 13:55:20.680.3+08:00 Huawei Q921/7/
Q921_Debug:
[FUN: ISDN_Q921_HandleOnTEIAssign, LINE: 1054] ISDN Layer 2 link state change
-> MULTIPLE_FRAME_ESTABLISHED
l
----End

Relevant Alarms
None
Relevant Logs
None
Issue 02 (2012-03-30)

126

Troubleshooting
5 WAN
5.6 PPPoE Troubleshooting

5.6.1 PPPoE Dialup Fails
Common Causes
The application of PPPoE involves PPPoE client and PPPoE server.
l
The interface configuration is incorrect.
The physical interface frequently alternates between Up and Down states.
User authentication fails.
No IP address is assigned to the PPPoE client.
No echo message is received.
Issue 02 (2012-03-30)

127

Troubleshooting
5 WAN
Figure 5-10 Troubleshooting flowchart for failed PPPoE dialup

PPPoE users fail to
dial in to the device
Is the physical
interface working
properly?
No
Check the physical

connection or
replace the cable
Is fault Yes
rectified?
No
Yes
Is the interface
configuration
correct?
No
Modify the
interface
configuration
Is fault Yes
rectified?
No
Yes
Is a correct IP
address assigned to
the client?
No
Check the address

pool usage and
use another IP
address pool
Yes
Does
the client correctly
receive heartbeat
messages?
No
Disable heartbeat
detection
Is fault
rectified?
Yes
No
Is fault Yes
rectified?
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check that the physical interface is working properly.
Run the display this interface command on the physical interface to check whether the physical
interface frequently alternates between Up and Down states.
l
If the physical interface frequently alternates between Up and Down states, check the
physical connection or replace the cable.
If the physical interface is working properly, go to step 2.
Step 2 Check that the configuration is correct.

On the PPPoE server, check the configurations of the virtual template interface and Ethernet
physical interface. On the PPPoE client, check the configurations of the dialer interface and
Ethernet physical interface. Run the display this command in the interface view to check the
interface configuration.
Issue 02 (2012-03-30)

128

Troubleshooting
5 WAN
On the PPPoE server:

[Huawei-A-Virtual-Template10]display this
ppp authentication-mode chap
[Huawei-A-aaa]display this
local-user ub password simple user1
On the PPPoE client:

[Huawei-B-Dialer10]display this
ppp chap user ub
ppp chap password simple ub
dialer-group 5
[Huawei-B-GigabitEthernet0/0/1]display this
pppoe-client dial-bundle-number
10
[Huawei-B-dialer-rule]display this
dialer-rule
dialer-rule 5 ip permit
If authentication is configured on the PPPoE server, check whether the user name and
password are correctly configured on the PPPoE client. If the dial-on-demand function is
configured on the PPPoE client, the PPP link is torn down when there is no traffic to be
transmitted. Ensure that the dialer-rule-number value in the dialer-rule command is the
same as the group-number value in the dialer-group command.
If the preceding configurations are all correct but the fault persists, go to step 3.
Step 3 Find out the dial-in failure cause.

On the PPPoE client, check whether the PPP protocol frequently alternates between Up and
Down states because authentication fails. Run the following commands to check the displayed
information. The dialer interface is the dialup interface of the PPP connection.
<Huawei-B>terminal monitor
Info: Current terminal monitor is on.
<Huawei-B>terminal debugging
Info: Current terminal debugging is on.
<Huawei-B>debugging ppp all interface Dialer 10
If the following information is displayed, authentication fails.

<Huawei-B>Jan 21 2008 17:40:56.420.1+08:00 AR1220-B MID_PPP/7/debug2:
PPP Packet:
Dialer10:0 Input CHAP(c223) Pkt, Len 33
State SendResponse, code FAILURE(04), id 2, len 29
Message: Illegal User or password.
PPP Packet:
Dialer10:0 Output LCP(c021) Pkt, Len 13
State reqsent, code ConfRej(04), id 1, len 9
AuthProto(3), len 5, CHAP c22305
PPP Packet:
Dialer10:0 Input LCP(c021) Pkt, Len 8
State opened, code TermReq(05), id 3, len 4
In the preceding command output, the first part of information indicates that a CHAP user name
is configured on the PPPoE client and the PPP client receives a Challenge message from the
PPPoE server and replies with a Response message. Because the CHAP password is incorrect
or the user name or password does not exist, the PPPoE server sends a Response Failed message
to the PPPoE client. The second part of information indicates that no authentication information
is configured on the PPPoE client or the authentication mode configured on the PPPoE client is
different from that configured on the PPPoE server so the client refuses the authentication request
from the server in LCP negotiation. If the client fails to be authenticated four times, the third
Issue 02 (2012-03-30)

129

Troubleshooting
5 WAN
part of information is displayed, indicating that the PPPoE server sends a request to tear down
the PPP connection between the server and client.
l
If authentication fails, check the authentication configuration and configure correct

authentication user name and password for the PPPoE client.
If authentication succeeds but the fault persists, go to step 4.
Step 4 Check that an IP address is correctly assigned to the PPPoE client.

If an IP address is incorrectly assigned to the PPPoE client, check the related configuration of
the PPPoE server. If IP addresses are assigned to the PPPoE client from a remote IP address
pool, check whether there are available IP addresses in the remote IP address pool. Log in to the
PPPoE server and run the following command to check the IP address pool.
[Huawei-A-ip-pool-mypoo]display ip pool name mypool
Pool-name
: mypool
Pool-No
: 0
Lease
: 1 Days 0 Hours 0 Minutes
Domain-name
: DNS-server0
: NBNS-server0
: Netbios-type
: Position
: Local
Status
: Unlocked
Gateway-0
: 20.1.1.1
Mask
: 255.255.255.0
VPN instance
: -----------------------------------------------------------------------------Start
End
Total Used Idle(Expired) Conflict Disable
----------------------------------------------------------------------------20.1.1.1
20.1.1.254
253
1
252
0
0
0
-----------------------------------------------------------------------------
If the Idle field is displayed as 0, there are no available IP addresses. Use an IP address pool
with available IP addresses instead of the IP address pool configured on the virtual template
interface of the PPPoE server. If the negotiated IP address of the PPPoE client conflicts with
another local IP address, the PPP protocol also frequently alternates between Up and Down
states.
l
If the PPPoE server fails to assign IP addresses to the PPPoE client, check the IP address
pool usage and use another IP address pool.
If the PPPoE server correctly assigns IP addresses to the PPPoE client, go to step 5.
Step 5 Check whether the PPPoE client correctly receives heartbeat messages.
Log in to the PPPoE client and run the following commands to check the command output.
<Huawei-B>terminal monitor
<Huawei-B>terminal debugging
Info: Current terminal debugging is on.
<Huawei-B>debugging ppp lcp all interface Dialer
10
If outgoing Echo Request messages are displayed but no incoming Echo Reply message is
displayed, the client cannot receive heartbeat messages.
[Huawei-B]
Jan 21 2008 19:20:37.790.2+08:00 AR1220-B MID_PPP/7/debug2:
PPP Packet:
Dialer10:0 Output LCP(c021) Pkt, Len 12
State opened, code EchoRequest(09), id c0, len 8
Magic Number 0560b017
Issue 02 (2012-03-30)

130

Troubleshooting
5 WAN
If the client does not receive any response to its consecutive four heartbeat messages, it tears
down the link with the server. If the client has received heartbeat messages but the fault persists,
go to step 6.
l
----End

Relevant Alarms
None
Relevant Logs
None
5.7 PPP Troubleshooting

5.7.1 Protocol Status of a PPP Interface Is Down
Common Causes
After an interface is configured with PPP, LCP negotiation fails, which causes the protocol status
of the interface to be Down.
l
PPP configurations on the two ends of the link are incorrect.
The physical status of the interface is Down.
PPP packets are discarded.
A loop occurs on the link.
The link delay is too long.
l
Check that PPP configurations on the two ends of the link are correct.
Check that the physical status of the interface is Up.
Check that the interface can sent and receive protocol packets.
Check that the link is loop-free.
Check that the link delay is tolerant.

Issue 02 (2012-03-30)

131

Troubleshooting
5 WAN
Figure 5-11 Troubleshooting flowchart for an LCP negotiation failure

LCP negotiation fails
PPP configurations
on the two ends of the link
are correct?
No
Modify PPP
configurations
Is fault rectified?
Yes
No
Yes
Physical status of the

interface is Up?
No Locate and rectify

transmission or
lower-layer faults
Yes
Is fault rectified?
No
Yes
Interface can
sent and receive protocol
packets?
No Locate and rectify

transmission or
lower-layer faults
Is fault rectified?
Yes
No
Yes
Link is loop-free?
No
Eliminate the
loop
Yes
Is fault rectified?
No
Yes
No
Link delay is tolerant
Check the link

delay
Yes
Is fault rectified?
No
Yes
End
NOTE
Procedure
Step 1 Check that PPP configurations on the two ends of the link are correct.
Run the display this command in the view of the interface whose protocol status is Down to
check PPP configurations.
[Huawei-Serial2/0/0] display this
#
interface Serial2/0/0
link-protocol ppp
undo shutdown
ip address 10.10.1.1 255.255.255.0
#
return
Issue 02 (2012-03-30)

132

Troubleshooting
5 WAN
Check whether the following configurations on the two ends match each other. If not,
modify the configuration referring to the chapter "PPP and MP Configuration" in the
AR1200 Configuration Guide - WAN Access.
Check whether the authenticator and authenticatee are configured with the same
authentication mode. The ppp authentication-mode authentication-mode command
indicates the authentication mode adopted by the local end that functions as the
authenticator. You need to check the authentication mode adopted by the peer. For
example, if the ppp pap local-user user-name password simple password command
has been configured, it means that the peer adopts PAP authentication.
Check whether both ends are bundled into an MP-group or neither of the two ends is
bundled into an MP-group. If one end has been bundled into an MP-group, the other
end must be bundled into the same MP-group. If the ppp mp interface-type interfacenumber command is configured, it means that the interface has been bundled into an
MP-group.
Check whether the authenticator and authenticatee are configured with the same
password for PPP authentication.
If PAP authentication is adopted, do as follows to check the configured user name
and password:
Check the user name and password of the authenticatee in the interface view.
#
link-protocol ppp
ppp pap local-user huawei password simple huawei
undo shutdown
#
return
Check the user name and password of the authenticator in the AAA view.
[Huawei] aaa
[Huawei-aaa] display this
#
aaa
local-user huawei password simple huawei
#
return
If the authenticator adopts CHAP authentication and is configured with a user name,
do as follows to check the user name and password:
Check the user name of the authenticatee in the interface view, and then check the
password in the AAA view based on the user name.
#
link-protocol ppp
ppp chap user huawei
undo shutdown
#
return
[Huawei-Pos1/0/0] aaa
#
aaa
#
return
[Huawei] aaa
Issue 02 (2012-03-30)

133

Troubleshooting
5 WAN
#
aaa
#
return
If the authenticator adopts CHAP authentication but is not configured with a user
name, do as follows to check the user name and password:
Check the user name and password of the authenticatee in the interface view.
#
link-protocol ppp
ppp chap user huawei
ppp chap password simple huawei
undo shutdown
#
return
[Huawei] aaa
#
aaa
#
return
If the preceding configurations are correct but the fault persists, go to Step 2.
Step 2 Check that the physical status of the interface is Up.

Run the display interface interface-type interface-number command to check the physical status
of the interface.
l
If the physical status of the interface is Down, you need to rectify the physical fault of the
interface. For detailed troubleshooting procedures, see "Physical Interconnection
Troubleshooting".
If the physical status of the interface is Up but the fault persists, go to Step 3.
Step 3 Check that the interface can sent and receive protocol packets.
Run the display interface interface-type interface-number command to check the number of
sent packets and received packets to determine whether the interface sends and receives protocol
packets.
[Huawei] display interface Serial 2/0/0
Serial2/0/0 current state : UP
Description:HUAWEI, AR Series, Serial2/0/0 Interface
The Vendor PN is HFBR-57E0P
The Vendor Name is AVAGO
Port BW: 155M, Transceiver max BW: 155M, Transceiver Mode: MultiMode
WaveLength: 1310nm, Transmission Distance: 2000m
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: none
Flag J0 "NetEngine
"
Flag J1 "NetEngine
"
Flag C2 22(0x16)
SDH alarm:
section layer: none
Issue 02 (2012-03-30)

134

Troubleshooting
5 WAN
line
layer: none
path
layer: none
SDH error:
section layer: B1 0
line
layer: B2 0 REI 44
path
layer: B3 0 REI 23
Statistics last cleared:never
Input error: 0 shortpacket, 0 longpacket, 0 CRC, 0 lostpacket
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
If the number of received or sent packets is 0, or the number does not increase, it indicates
that packets are discarded during transmission. Check whether the physical connection is
correct. For detailed information, see "Physical Interface Cannot Go Up".
If the physical connection is correct, you need to locate the cause of packet loss. For detailed
troubleshooting procedures, see "Packet Loss Troubleshooting".
If packets can be received and sent but the fault persists, go to Step 4.
CAUTION
Debugging affects the system performance. Therefore, after debugging, run the undo debugging
all command to disable it immediately.
In addition, you can run the debugging ppp all interface interface-type interface-number
command to check the number of sent and received protocol packets and the status changes of
the PPP state machine.
Jun 2 2010 17:19:41.310.1 Huawei PPP/7/debug2:Slot=1;
PPP Event:
Serial2/0/0 LCP TO+(Timeout with counter > 0) Event
state acksent , Retransmit = 4
PPP Packet:
Serial2/0/0 Output LCP(c021) Pkt, Len 18
State acksent, code ConfReq(01), id 3, len 14
MRU(1), len 4, val 1176
MagicNumber(5), len 6, val 00abb891
PPP Packet:
Serial2/0/0 Input LCP(c021) Pkt, Len 18
State acksent, code ConfAck(02), id 3, len 14
MRU(1), len 4, val 1176
MagicNumber(5), len 6, val 00abb891
PPP Event:
Serial2/0/0 LCP RCA(Receive Config Ack) Event
state acksent
Step 4 Check that the link is loop-free.

Run the display interface interface-type interface-number command to check the physical status
of the interface.
[Huawei] display interface Serial 2/0/0
Serial2/0/0 current state : UP
Line protocol current state : DOWN
Description:HUAWEI, AR Series, Serial 2/0/0 Interface
Issue 02 (2012-03-30)

135

Troubleshooting
5 WAN
Internet protocol processing : disabled

Link layer protocol is PPP, loopback is detected
LCP closed
The Vendor PN is HFBR-57E0P
The Vendor Name is AVAGO
Port BW: 155M, Transceiver max BW: 155M, Transceiver Mode: MultiMode
WaveLength: 1310nm, Transmission Distance: 2000m
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: local
Flag J0 "NetEngine
"
Flag J1 "NetEngine
"
Flag C2 22(0x16)
SDH alarm:
section layer: none
line
layer: none
path
layer: none
SDH error:
section layer: B1 22
line
layer: B2 94 REI 145
path
layer: B3 44 REI 86
Statistics last cleared:never
Input error: 0 shortpacket, 0 longpacket, 2 CRC, 0 lostpacket
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
If loopback is detected is displayed, it indicates that a loop occurs on the link. You need
to locate the cause of the loop and eliminate the loop.
If no loop occurs but the fault persists, go to Step 5.
Step 5 Check that the link delay is tolerant.

Use a tester to test the link delay. On a Huawei router, the transmission of a PPP packet times
out in 3 seconds, and the timeout period is configurable. The link delay must be smaller than the
timeout period.
l
If the link delay is too long, replace or maintain the relevant device.
If the link delay is tolerant but the fault persists, go to Step 6.
----End

Relevant Alarms
None.
Relevant Logs
None.
5.8 xDSL Troubleshooting

This chapter describes how to locate and troubleshoot common xDSL faults with examples.
Issue 02 (2012-03-30)

136

Troubleshooting
5 WAN
5.8.1 Packets Fail to Be Forwarded on an ADSL Interface Working

in ATM Mode
This section provides a troubleshooting flowchart and a step-by-step troubleshooting procedure
to use when packets fail to be forwarded on an ADSL interface working in ATM mode.
NOTE
An ADSL interface can work only in ATM mode.
Common Causes
l
The cable is not properly connected to the interface or the interface is shut down.
The local and remote ADSL interfaces are using different transmission standards.
Figure 5-12 Troubleshooting flowchart for the packet forwarding failure on an ADSL interface
working in ATM mode
Packets fail to be
forwarded on an
ADSL interface in
ATM mode
Is the physical
status of the ADSL
interface Up?
No
Ensure that the

physical status of
the ADSL
interface is Up
Is fault
rectified?
Yes
No
Yes
Is ATM correctly
configured?
No
Configure ATM
correctly
Is fault
rectified?
Yes
No
Yes
End
Issue 02 (2012-03-30)

137

Troubleshooting
5 WAN
Procedure
Step 1 Check that the physical status of the ADSL interface is Up.
Run the display interface atm command in the system view to check whether the physical status
of the ADSL interface is Up. The following information uses the display on ATM1/0/0 as an
example.
l
If "Atm1/0/0 current state : Administratively DOWN" is displayed, ATM1/0/0 has been

shut down. Run the undo shutdown command on ATM1/0/0 to enable it.
If "Atm1/0/0 current state : DOWN" is displayed, check the following items.

Item
Expected Result
Follow-up Operation
Check the
connection
between the local
and remote
interfaces.

are properly connected using a
cable.

connected, reconnect them. If
the fault persists, change the
cable between the two
interfaces.
Check the
transmission
standard of the
local ADSL
interface.
Run the display dsl interface

atm command in the system
view to check the parameters
settings of the local ADSL
interface. The value of the
Transmission mode field
indicates the transmission
standard of the local ADSL
interface, which must be the
same as the transmission
standard of the remote interface.

interfaces use different
transmission standards, run the
adsl standard command on the
local ADSL interface to change
its transmission standard to be
the same as the transmission
standard of the remote interface.
If "Atm1/0/0 current state : DOWN" is still displayed, go to step 3.

l
If "Atm1/0/0 current state : UP" is displayed, ATM1/0/0 is in the Up state. Go to step 2.
Step 2 Check that ATM is correctly configured.

l
Issue 02 (2012-03-30)
If IP packets are transmitted over ATM links, check the following items.
Item
Expected Result
Follow-up Operation
Run the display

this command in
the ADSL
interface view to
check whether the
IP address of the
local ADSL
interface is on the
same network
segment as the IP
address of the
remote interface.
IP addresses of the local

ADSL interface and the
remote interface are on the
same network segment.
If IP addresses of the local ADSL

interface and the remote interface
are on different network segments,
run the ip address command in the
ADSL interface view to assign the
local ADSL interface an IP address
that is on the same network
segment as the IP address of the
remote interface.

138

Troubleshooting
Issue 02 (2012-03-30)
5 WAN
Item
Expected Result
Follow-up Operation
Run the display

this command in
the ATM-PVC
view to check
whether IPoA
mapping is
correctly
configured on the
PVC.
The mapped IP address is the

IP address of the remote
interface.
If the mapped IP address is not the

IP address of the remote interface,
run the map ip command in the
ATM-PVC view to configure the IP
address of the remote interface as
the mapped IP address.
If IPoE packets are transmitted over ATM links, check the following items.
Item
Expected Result
Follow-up Operation
Run the display

this command in
the VE interface
view to check
whether the IP
address of the local
VE interface is on
the same network
segment as the IP
address of the
remote interface.
IP addresses of the local VE

interface and the remote
interface are on the same
network segment.
If IP addresses of the local VE

VE interface view to assign the
local VE interface an IP address
remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether IPoEoA
mapping is
correctly
configured on the
PVC.
IPoEoA mapping is
correctly configured.
If IPoEoA mapping is incorrectly

configured, run the map bridge
command in the ATM-PVC view to
reconfigure it on the PVC.
If PPP packets are transmitted over ATM links, check the following items.
Item
Expected Result
Follow-up Operation
Check whether the

local VT interface
and the remote
interface have the
same PPP user
name and
password.
The local VT interface and

the remote interface have the
same PPP user name and
password.
If the local VT interface and the

remote interface have different PPP
user names or passwords, run the
ppp pap local-user or ppp chap
password command in the VT
interface view to change the PPP
user name and password of the
local VT interface to be the same as
those of the remote interface.

139

Troubleshooting
5 WAN
Item
Expected Result
Follow-up Operation
Run the display

this command in
the ATM-PVC
view to check
whether PPPoA
mapping is
correctly
configured on the
PVC.
PPPoA mapping is correctly

configured.
If PPPoA mapping is incorrectly

configured, run the map ppp
If PPPoE packets are transmitted over ATM links, check the following items.
Item
Expected Result
Follow-up Operation
Check whether the

local dialer
interface and the
remote interface
have the same PPP
user name and
password.
The local dialer interface

and the remote interface
have the same PPP user
name and password.
If the local dialer interface and the

password command in the dialer
local dialer interface to be the same
as those of the remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether PPPoEoA
mapping is
correctly
configured on the
PVC.
PPPoEoA mapping is
If PPPoEoA mapping is incorrectly


----End

Relevant Alarms
None
Issue 02 (2012-03-30)

140

Troubleshooting
5 WAN
Relevant Logs
None
5.8.2 Packets Fail to Be Forwarded on a G.SHDSL Interface Working

in ATM Mode
This section provides a troubleshooting flowchart and a step-by-step troubleshooting procedure
to use when packets fail to be forwarded on a G.SHDSL interface working in ATM mode.
Common Causes
l
The cable is not properly connected to the interface or the interface is shut down.
The local and remote G.SHDSL interfaces are using different transmission standards.
The local and remote G.SHDSL interfaces are working in different PSD modes.
Issue 02 (2012-03-30)

141

Troubleshooting
5 WAN
Figure 5-13 Troubleshooting flowchart for the packet forwarding failure on a G.SHDSL
interface working in ATM mode
Packets fail to be
forwarded on a
G.SHDSL interface in
ATM mode
Is the
physical status
of the G.SHDSL
interface Up?
No
Ensure that the physical

status of the G.SHDSL
interface is Up
Is fault
rectified?
Yes
No
Yes
Do
the local
and remote G.SHDSL
interfaces use the same
transmission
standard?
No
Change the local

transmission standard to be
the same as the remote
transmission standard
Is fault
rectified?
Yes
No
Yes
Do
the local and
remote G.SHDSL
interfaces work in the
same PSD
mode?
No
Change the local PSD mode

to be the same as the
remote PSD mode
Is fault
rectified?
Yes
No
Yes
Is ATM correctly
configured?
No
Configure ATM correctly
Is fault
rectified?
Yes
No
Yes
End
Procedure
Step 1 Check that the physical status of the G.SHDSL interface is Up.
Run the display interface atm command in the system view to check whether the physical status
of the G.SHDSL interface is Up. The following information uses the display on ATM1/0/0 as
an example.
Issue 02 (2012-03-30)

142

Troubleshooting
5 WAN
If "Atm1/0/0 current state : Administratively DOWN" is displayed, ATM1/0/0 has been

shut down. Run the undo shutdown command on ATM1/0/0 to enable it.
If "Atm1/0/0 current state : DOWN" is displayed, check the following items.

Item
Expected Result
Follow-up Operation
Check the
connection
between the local
and remote
interfaces.

are properly connected using a
cable.

connected, reconnect them. If
the fault persists, change the
cable between the two
interfaces.
Run the display

dsl interface
command in the
system view to
check the binding
mode of
G.SHDSL
interfaces, number
of the main
interface, and
number of bound
interfaces.
The value of the Port bind

status field indicates the
interface binding status:
l Normal: indicates that the
G.SHDSL interface is not
bound.
If the binding modes of the

G.SHDSL interfaces, main
interfaces, or numbers of bound
interfaces on both ends are
different, perform the following
operations:
l MPair-X: indicates M-Pair

binding. X specifies the
number of bound interfaces.
1. Run the following

commands on the four
G.SHDSL interfaces:
l EFM-X: indicates EFM

binding. X specifies the
number of bound interfaces.
l Run the shutdown

command to shut down
the interfaces.
The Bind group master port

field indicates the main
interface. The requirements are
as follows:
l Run the undo shdsl

bind command to delete
the binding
configurations from the
interfaces.
l The local and remote

G.SHDSL interfaces use the
same binding mode.
l The numbers of bound
interfaces on both ends are
the same.
l The main interfaces on both
ends are the same.
2. Run the set workmode slot

slot-id shdsl { atm | ptm }
command in the system view
to change the local binding
mode to be the same as the
remote binding mode.
3. Find the local main interface
according to the remote
main interface. Run the
shdsl bind command on the
local main interface to
change the local bound
interface quantity to be the
same as the remote bound
interface quantity.
If "Atm1/0/0 current state : DOWN" is still displayed, go to step 5.

l
If "Atm1/0/0 current state : UP" is displayed, ATM1/0/0 is in the Up state. Go to step 2.
Step 2 Check that the local and remote G.SHDSL interfaces use the same transmission standard.
Issue 02 (2012-03-30)

143

Troubleshooting
5 WAN
Run the display dsl interface command in the system view to check the transmission standard
of the G.SHDSL interfaces. The value of the Port transmission mode field indicates the
transmission standard.
l
If the local and remote G.SHDSL interfaces use different transmission standards, run the
shdsl annex command on the local G.SHDSL interface to change its transmission standard
to be the same as the transmission standard of the remote G.SHDSL interface.
If the local and remote G.SHDSL interfaces use the same transmission standard, go to step
3.
Step 3 Check that the local and remote G.SHDSL interfaces work in the same PSD mode.
Run the display dsl interface command in the system view to check the PSD mode of the
G.SHDSL interfaces. The value of the Port power spectral density field indicates the PSD
mode.
l
If the local and remote G.SHDSL interfaces work in different PSD modes, run the shdsl
psd command in the G.SHDSL interface view to change its PSD mode to be the same as
the PSD mode of the remote G.SHDSL interface.
If the local and remote G.SHDSL interfaces work in the same PSD mode, go to step 4.
Step 4 Check that ATM is correctly configured.

l
Issue 02 (2012-03-30)
If IP packets are transmitted over ATM links, check the following items.
Item
Expected Result
Follow-up Operation
Run the display

this command in
the G.SHDSL
interface view to
check whether the
IP address of the
local G.SHDSL
interface is on the
same network
segment as the IP
address of the
remote interface.
IP addresses of the local

G.SHDSL interface and the
remote interface are on the
same network segment.
If IP addresses of the local

G.SHDSL interface and the remote
interface are on different network
segments, run the ip address
command in the G.SHDSL
interface view to assign the local
G.SHDSL interface an IP address
remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether IPoA
mapping is
correctly
configured on the
PVC.
The mapped IP address is the

IP address of the remote
interface.
If the mapped IP address is not the

IP address of the remote interface,
run the map ip command in the
ATM-PVC view to configure the IP
address of the remote interface as
the mapped IP address.
If IPoE packets are transmitted over ATM links, check the following items.

144

Troubleshooting
Issue 02 (2012-03-30)
5 WAN
Item
Expected Result
Follow-up Operation
Run the display

this command in
the VE interface
view to check
whether the IP
address of the local
VE interface is on
the same network
segment as the IP
address of the
remote interface.
IP addresses of the local VE

interface and the remote
interface are on the same
network segment.
If IP addresses of the local VE

VE interface view to assign the
local VE interface an IP address
remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether IPoEoA
mapping is
correctly
configured on the
PVC.
IPoEoA mapping is
If IPoEoA mapping is incorrectly

If PPP packets are transmitted over ATM links, check the following items.
Item
Expected Result
Operation
Check whether the

local VT interface
and the remote
interface have the
same PPP user
name and
password.
The local VT interface and

the remote interface have the
same PPP user name and
password.
If the local VT interface and the

password command in the VT
local VT interface to be the same as
those of the remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether PPPoA
mapping is
correctly
configured on the
PVC.
PPPoA mapping is correctly

configured.
If PPPoA mapping is incorrectly

configured, run the map ppp
If PPPoE packets are transmitted over ATM links, check the following items.

145

Troubleshooting
5 WAN
Item
Expected Result
Follow-up Operation
Check whether the

local dialer
interface and the
remote interface
have the same PPP
user name and
password.
The local dialer interface

and the remote interface
have the same PPP user
name and password.
If the local dialer interface and the

password command in the dialer
local dialer interface to be the same
as those of the remote interface.
Run the display

this command in
the ATM-PVC
view to check
whether PPPoEoA
mapping is
correctly
configured on the
PVC.
A correct VE interface is
specified.
If an incorrect VE interface is
specified, run the map bridge
correctly configure PPPoEoA
mapping on the PVC.

----End

Relevant Alarms
None
Relevant Logs
None
5.9 3G Troubleshooting
5.9.1 3G Calls Failed After Dialing Parameters Were Correctly Set
Common Causes
Issue 02 (2012-03-30)

146

Troubleshooting
5 WAN
The 3G modem is not functioning properly for some reasons such as improper installation
of the 3G modem.
The SIM card on the 3G modem is not functioning properly. The possible reasons are as
follows: the SIM card is not inserted properly; the SIM card needs to be unlocked using
PUK; the SIM card is suspended due to arrears.
The AR installed with a 3G card is not in the 3G coverage area.
The profile is not correctly configured on the 3G modem when a WCDMA network is used.
Figure 5-14 shows the troubleshooting flowchart for 3G calls.
Figure 5-14 Troubleshooting flowchart for 3G calls
3G calls failed after
dialing parameters are
correctly set
Does 3G modem
function properly?
No
Reinstall the 3G
modem
Yes
Is fault
rectified?
Yes
No
Does SIM
card work?
No Insert or unlock the

SIM card, ensure
the SIM card does
not have arrears
Yes
Is fault
rectified?
Yes
No
Is the 3G device in
coverage area?
No
Make calls in
coverage area
Is fault
rectified?
Yes
No
Is the profile
configured on WCDMA
network?
No
Configure a 3G
modem profile
Is fault
rectified?
Yes
No
Yes
End
Issue 02 (2012-03-30)

147

Troubleshooting
5 WAN
Context
NOTE
The AR supports WCDMA and CDMA2000, but does not support TD-SCDMA.
Procedure
Step 1 Run the display interface cellular interface-number command.
<Huawei> display interface cellular 0/0/0
Cellular0/0/0 current state : UP
Line protocol current state : UP (spoofing)
Description:HUAWEI, AR Series, Cellular0/0/0 Interface
Internet Address is negotiated, 192.168.70.94/32
: 2011-06-08 10:53:15
USB Modem State: Present
Last 300 seconds input rate 555 bytes/sec, 4440 bits/sec
Last 300 seconds output rate 0 bytes/sec, 0 bits/sec
Input: 87205 bytes
Output:6760917 bytes
l If the USB Modem State value in the command output is Not present, the 3G modem is
not installed properly, and it needs to be reinstalled.
l The value Present indicates that the 3G modem is functioning properly. Go to step 2.
Step 2 Run the display cellular interface-number all command.
If the following information is displayed, the 3G network is available. Go to step 3.
Network Information.
====================
Current Service Status = Service available
Current Service = Combined
Packet Service = Attached
Packet Session Status = Active
Current Roaming Status = Roaming
Network Selection Mode = Automatic
......
If the network is unavailable, for example, the Current Service Status value is No service or
Emergency, or the Packet Service value is Detached, perform the following operations:
l Run the plmn auto command in the 3G modem interface view to set the PLMN selection
mode to automatic.
l For a WCDMA network, run the mode wcdma wcdma-precedence command in the 3G
modem interface view. For a CDMA2000 network, run the mode cdma hybrid command
in the 3G modem interface view.
Step 3 Check whether the SIM card is working properly.
1.
Confirm with the network carrier: ensure that the 3G Internet access service has been
enabled and the SIM card does not have arrears.
2.
Run the display cellular interface-number all command.
Issue 02 (2012-03-30)

148

Troubleshooting
5 WAN
Command Output
Solution
If the following command output is

displayed, the SIM card is working
properly.
Go to step 4.
PIN Verification = Disabled

PIN Status =
Ready
Number of Retries remaining =
3
SIM Status = OK

displayed, no PIN code is entered.
Run the pin verify pin command in the 3G

modem interface view.
PIN Verification = Unknown

PIN Status = PIN Requirement
Number of Retries remaining = 3
SIM Status = Invalid
NOTE
If incorrect PIN codes are entered three times
consecutively, the PIN code is locked. Enter a
PUK code to unlock it.

displayed, a PUK code is required.
Run the pin unlockpuk pin command in

the 3G modem interface view.

PIN Status = PUK Requirement
Number of Retries remaining = 10
SIM Status = Invalid

displayed, no SIM card is available on the
3G modem.
Remove the data card from the 3G modem

and insert the SIM card. After the SIM card
is installed properly, insert the data card.

PIN Status = Unknown
SIM Status = Not insert
NOTE
The SIM card is not hot swappable.
Wait about 1 minute until the data card completes initialization. If a 3G call still fails, go
to step 4.
NOTE
There are two ways to initiate dialing:

l Triggered by data traffic: For example, when you attempt to open a web page, data traffic is
transmitted to the 3G interface. The 3G interface then triggers dialing.
l Automatic dialing: If you run the dialer number *99# autodial (WCDMA) or dialer number
#777 autodial (CDMA2000) command in the interface view, the system automatically connects
to the 3G network.
Step 4 Check whether the AR installed with a 3G card is in the 3G coverage area.
Use another 3G device, such as a 3G mobile phone, to check whether the 3G signal is normal.
l If the 3G mobile phone cannot receive wireless signals, the phone is out of the 3G network
coverage area. Check that the Radio Access Network (RAN) is working properly.
l If the 3G mobile phone successfully makes a call, go to step 5.
Step 5 If a WCDMA network is used, check whether the profile is properly configured on the 3G
modem.
Run the display cellular interface-number all command. If the following information is
displayed, no 3G modem profile is configured. Configure a 3G modem profile on the AR.
Profile Information.
====================
Issue 02 (2012-03-30)

149

Troubleshooting
5 WAN
Profile 1 = UNDEFINED
-------* - Default profile
Run the profile create 1 static apn-name command in the interface view to create a profile. The
APN is provided by your carrier.
l Configuration files, log files, and alarm files of the AR
----End
Troubleshooting Procedure (for Huawei Engineers Only)

NOTE
If you cannot rectify the fault after performing the preceding troubleshooting procedure, perform the
operations in this section.
Procedure
Step 1 Enable DCC debugging and dial up. Collect the debugging information and contact Huawei
technical support personnel.
NOTE
Run the terminal monitor and terminal debugging commands to display debugging information on the
terminal. After debugging, run the undo debugging all command to disable it immediately.
Command
Functions
debugging dialer all

debugging dialer info
Enables a dialup event and displays

debugging information.
debugging ppp lcp all
Enables PPP LCP debugging.
debugging ppp ipcp all
Enables PPP IPCP debugging.
----End

Alarms
None
Relevant Logs
l
Jun 5 2011 10:0 8:58+00:00 Huawei %%01IFPDT/4/IF_STATE(l)[1]:InFile: ppp_func.c,

Line: 1291. Callterface Cellular0/0/0 has turned into UP state.
Jun 5 2011 10:08:58+00:00 Huawei %%01IFNET/4/LINK_STAT32a771c

(PPP_CopyConfigToBChannelE(l)[2]):The line protocol on the interface Cellular0/0/0 has
entered the UP state.
Issue 02 (2012-03-30)

150

Troubleshooting
5 WAN
Jun 5 2011 10:08:558(DCC_TaskEntry) <-- 0x004c5f358+00:00 Huawei IFNET/6/

IF_PVCUP:OID 1.3.6.1.6.3.1.1.5.4 Interfa 0x04db8f74(vxTaskEntry) <-- 0x0ce 13 turned
into UP state.(AdminStatus 1,OperStatus 1,InterfacepuID: -1, TaskID: 166, Sn: 256> Name
Cellular0/0/0)
Jun 5 2011 10:08:59+00:00 Huawei %%01IFNET/4/LINK_STATE(l)[3]:The line

protocol PPP IPCP on the interface Cellular0/0/0 has entered the UP state.
Jun 5 2011 10:08:58+00:00 Huawei %%01IFPDT/4/IF_STATE(l)[1]:InFile: ppp_func.c,

Line: 1291. Callterface Cellular0/0/0 has turned into DOWN state.
Jun 5 2011 10:08:58+00:00 Huawei %%01IFNET/4/LINK_STAT32a771c

(PPP_CopyConfigToBChannelE(l)[2]):The line protocol on the interface Cellular0/0/0 has
entered the DOWN state.
Jun 5 2011 10:08:558(DCC_TaskEntry) <-- 0x004c5f358+00:00 Huawei IFNET/6/

IF_PVCUP:OID 1.3.6.1.6.3.1.1.5.4 Interfa 0x04db8f74(vxTaskEntry) <-- 0x0ce 13 turned
into DOWN state.(AdminStatus 1,OperStatus 1,InterfacepuID: -1, TaskID: 166, Sn: 256>
Name Cellular0/0/0)
Jun 5 2011 10:08:59+00:00 Huawei %%01IFNET/4/LINK_STATE(l)[3]:The line

protocol PPP IPCP on the interface Cellular0/0/0 has entered the DOWN state.
Issue 02 (2012-03-30)

151

Troubleshooting
6 Voice
Voice
About This Chapter

6.1 Voice Service Troubleshooting
Issue 02 (2012-03-30)

152

Troubleshooting
6 Voice
6.1 Voice Service Troubleshooting

6.1.1 No Dial Tone Is Heard After Offhook
Common Causes
l
The subscriber line is faulty.
The interface card connected to the telephone fails to be registered.
The SRU is faulty.
Figure 6-1 No dial tone is heard after offhook
No dial tone
is heard after
offhook
Is port status
correct?
No
Rectify fault of
line or port
Is fault
rectified?
No
Yes
Is interface
subcard
registered?
No
Rectify interface
subcard fault
Is fault
rectified?
No
Yes
Yes
Yes
Is SRU
working properly?
No
Rectify SRU
fault
Is fault
rectified?
No
Yes
Seek technical
support
Yes
End
Issue 02 (2012-03-30)

153

Troubleshooting
6 Voice
NOTE
Procedure
Step 1 Check the status of the port connected to the telephone.
Run the display voice port fxs state slotid/subcardid/portid command to check whether the
port status is in service after offhook.
[Huawei-voice] display voice port fxs state
1/0/0
port FXS state: 1/0/0
PTPSrvState
: Normal
PTPAdmState
: NoLoop,NoTest
CTPSrvState
: In
serivce
CTPAdmState
: StartSvc
LineState
: Normal
If the port status is not in service, repair or replace the subscriber line.
If the port status is in service, go to step 2.
Step 2 Check whether the interface card connected to the telephone has been successfully registered.
If the interface card fails to be registered, no dial tone can be displayed because the upper layer
protocol packets cannot be transmitted between the calling and called parties. Run the display
device command to check whether the interface card has been successfully registered. If
Registered is displayed, the interface card has been successfully registered. If Unregistered is
displayed, the interface card is not registered.
l
If the interface card fails to be registered, locate and rectify the fault on the interface card.
If the interface card has been successfully registered, go to step 3.
Step 3 Check that the SRU is working properly.

If the port and interface card connected to the telephone are working properly, this fault may be
caused by a fault in the SRU. Test the SRU.
l
If the SRU is not working properly, repair the SRU.
If the SRU is working properly, go to step 4.
l
Configuration files, log files, and alarm files of the AR1200
----End

Relevant Alarms
None.
Issue 02 (2012-03-30)

154

Troubleshooting
6 Voice
Relevant Logs
None.
6.1.2 Call Quality Is Low

Common Causes
l
Voice data flows are blocked in one direction. For example, a firewall on the network blocks
the port number of Real-time Transfer Protocol (RTP) media streams.
One of following situations occurs, causing noises in the call:

The AR1200 is not properly grounded.
There is signal interference.
A fault occurs on the bearer network.
The device hardware is faulty.
The echo suppression function is enabled on the softswitch.
Issue 02 (2012-03-30)

155

Troubleshooting
6 Voice
Figure 6-2 Call quality is low

The call quality
is low
Is there any
QoS alarm?
Yes
Rectify line fault
Is fault
rectified?
Yes
No
No
Is echo
suppression
enabled?
Yes
Disable echo
suppression
Is fault
rectified?
No
Yes
No
Yes
Is there
interference?
Remove
interference
Is fault
rectified?
Yes
No
No
Is
there noise
or unidirectional
communication?
Yes
Rectify network
fault
Is fault
rectified? Yes
No
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether there is any QoS alarm record.
View historical alarm records on the AR1200 to check whether there is any QoS alarm record.
l
If there are QoS alarm records, rectify network faults according to instructions in the alarms.
If there is no QoS alarm record, go to step 2.
Step 2 Check whether the echo suppression function is enabled on the softswitch.
l
If the echo suppression is enabled, disable it.
If the echo suppression is disabled, go to step 3.
Step 3 Check the surrounding environment.

Issue 02 (2012-03-30)

156

Troubleshooting
6 Voice
Check whether there is radio interference from stations or radio antennas and whether the
subscriber line is in contact with the power cable.
l
If there is interference, remove the interference.
If there is no interference, go to step 4.
Step 4 Locate the fault that causes noises in the call or unidirectional communication.
Capture packets and listen to the wav file to locate the fault that causes noises in the call or
unidirectional communication. Capture packets and listen to the wav file on local device
AR1200A and remote device AR1200B. If voice data packets can be transmitted only in one
direction or there are noises in the wav file, a fault occurs on the bearer network between
AR1200A and AR1200B.
l
If the fault that causes noises in the call or unidirectional communication is located, rectify
this fault.
If no fault occurs on the bearer network, go to step 5.
l
----End

Relevant Alarms
None.
Relevant Logs
None.
6.1.3 A Call Fails to Be Connected

Common Causes
l
The digitmap is incorrect.
A fault occurs on the network.
Media negotiation fails.
Issue 02 (2012-03-30)

157

Troubleshooting
6 Voice
Figure 6-3 A call fails to be connected

A call fails to
be
connected
No
Is calling
party configuration
complete?
Complete calling
party
configuration
Is fault
rectified?
No
Yes
Is the
calling number
restricted?
Yes
Cancel the
restriction
Is fault
rectified?
No
No
Is network
working properly?
No
Rectify network
fault
Is fault
rectified?
No
Yes
Is media
negotiation
successful?
No
Change the
codec mode
Is fault
rectified?
Yes
Yes
Yes
Yes
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether the calling party configuration is complete.
Run the display voice sipaguser command to check the configuration of the SIP AG user. If
some parameters are not configured, the user cannot make a call.
l
If some parameters are not configured, configure the parameters.
If all parameters are configured correctly, go to step 2.
Step 2 Check whether the softswitch restricts some functions of the calling party. For example, the
calling party may not have a right to make toll calls.
Capture signaling packets on the AR1200. Check whether the AR1200 has received the 100
Trying or 180 Ringing message after sending an Invite message.
Issue 02 (2012-03-30)

158

Troubleshooting
6 Voice
If the AR1200 has received the 4XX or 5XX message but not the 100 Trying or 180 Ringing
message, check that the calling number is configured correctly on the softswitch.
If no signaling packet is captured, go to step 3.
Step 3 Check that the network is functioning properly.

Trace SIP messages on the AR1200 and the device at the called party side. If SIP messages are
transmitted in only one direction, a fault occurs on the network.
If the AR1200 and the device at the called party side can ping each other but SIP messages
cannot be transmitted between them, check the SIP AG configuration.
<Huawei> display voice sipag 1 config
AGID
Dynamic signalling IP address name
Signalling IP
Signalling port
Dynamic media IP address name
Media IP
Transfer mode
Primary proxy IP 1
Primary proxy IP 2
Secondary proxy IP 1
Secondary proxy IP 2
Primary proxy port
Secondary proxy port
Primary proxy domain name
Secondary proxy domain name
Proxy address mode
Home domain name
SIP profile index
Service logic index
Server Address DHCP option
Description
AG domain name
Phone context
Register URI
Conference factory URI
Subscribe to UA profile
Subscribe to reg state
Subscribe to MWI
SDP negotiation mode
Mode of supporting proxy dual-homing
Proxy detection mode
Proxy refresh mode
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1
192.168.1.1
5060
192.168.1.1
UDP
2.2.2.2
255.255.255.255
255.255.255.255
255.255.255.255
5060
65535
IP
huawei.com
1: Default
0: Default
0: None
Enable
Disable
Disable
Remote
Manual switch over
Probe
If the network is not functioning properly, rectify the fault on the network.
If the network is functioning properly, go to step 4.
Step 4 Check whether media negotiation is successful.

Capture packets to check whether media negotiation is successful. Check the SDP information
in invite and 200 OK messages. If the SDP information on the device at the called party side is
the same as that on the AR1200, media negotiation is successful.
l
If media negotiation fails, change the codec mode on the device at the called party side or
change the preferred codec mode on the AR1200.
If media negotiation is successful, go to step 5.
l
----End
Issue 02 (2012-03-30)

159

Troubleshooting
6 Voice

Relevant Alarms
None.
Relevant Logs
None.
6.1.4 A SIP AG Cannot Work Properly

Common Causes
l
The data configuration on the SIP AG is incorrect.
There is no reachable route between the AR1200 and the softswitch.
Signaling packets are discarded on an intermediate device.
There are echoes or other environmental factors causing signal quality deterioration.
Issue 02 (2012-03-30)

160

Troubleshooting
6 Voice
Figure 6-4 A SIP AG cannot work properly

A SIP AG does
not work properly
Can softswitch
be pinged?
No
Is fault
rectified?
Rectify the network

fault
Yes
No
Yes
No
Is SIP AG
data same as that
on softswitch?
Configure correct
SIP AG data
Is fault
rectified?
Yes
No
Yes
Is profile of
SIP AG correct?
No
Change the profile
Is fault
rectified?
Yes
No
Yes
Can SIP
AG receive
signaling?
No
Locate the device

discarding signaling
packets and rectify
device fault
Yes
Is fault
rectified?
Yes
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether the AR1200 can ping the softswitch.
Run the display voice sipag command to check the status of the SIP AG. Ensure that it is in Up
state.
Ping the softswitch.
<Huawei> ping 172.183.20.13
If the ping operation fails, check the network connection and rectify faults on the network.
If the ping operation succeeds, go to step 2.
Step 2 Check whether the SIP AG configurations on the AR1200 are the same as that on the softswitch.
Run the display voice sipag [ sipag-interface-id { running | config } ] command to check the
SIP AG configuration. Pay attention to the IP addresses and port numbers of the proxy servers.
Issue 02 (2012-03-30)

161

Troubleshooting
If any of configurations are incorrect, modify the configurations.
If the SIP AG configurations are correct, go to step 3.
6 Voice
Step 3 Run the display voice sipag [ sipag-interface-id { running | config } ] command to check
whether the SIP AG uses the profile matching the softswitch type. By default, the profile
Default is used.
l
If the profile is incorrect, run the profile command to change the profile.
If the profile is correct, go to step 4.
Step 4 Check signaling interaction between the SIP AG and the remote device.
Capture signaling packets to check whether signaling packets are discarded on an intermediate
device.
l
If the intermediate device that discards signaling packets is located, rectify the fault on the
device.
If the intermediate device that discards signaling packets cannot be located, go to step 5.
l
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

162

Troubleshooting
7 IP Forwarding and Routing
IP Forwarding and Routing
About This Chapter

7.1 A Ping Operation Fails
This section provides a troubleshooting flowchart and describes step-by-step troubleshooting
procedures for a ping failure.
7.2 DHCP Troubleshooting
This chapter describes common causes of Dynamic Host Configuration Protocol (DHCP) faults,
and provides troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
7.3 RIP Troubleshooting
7.4 OSPF Troubleshooting
7.5 BGP Troubleshooting
Issue 02 (2012-03-30)

163

Troubleshooting
7.1 A Ping Operation Fails

This section provides a troubleshooting flowchart and describes step-by-step troubleshooting
procedures for a ping failure.
7.1.1 The Ping Operation Fails

Common Causes
If the source end does not receive any response to its Request packet from the destination end
within a specified period, the ping operation fails.
l
The link transmission delay is too long. Therefore, if the source end does not receive any
Response packet from the destination end within the waiting time, the ping operation fails.
There are improper configurations. For example, packet fragmentation is not enabled when
a large Ping packet is sent but the outbound interface of the packet has a smaller MTU.
Routing entries or ARP entries (for Ethernet links) are incorrect.
The hardware is faulty.
Issue 02 (2012-03-30)

164

Troubleshooting
Figure 7-1 Troubleshooting flowchart for a ping failure

The destination
address cannot be
pinged
Is the link transmission

delay too long?
Yes
Increase the value

of -t in the ping
command
Is fault
rectified?
Yes
No
No
Is the
ping operation
correct?
Yes
Correctly perform the

ping operation
Is fault
rectified?
Yes
No
No
Locate the direction and
device where the fault occurs
Is a CPU
attack defense policy
configured on the
device?
No
Configure an attack
defense policy on
the device
Is fault
rectified?
Yes
No
Yes
Do FIB and
ARP entries exist on the
device?
No
Ensure that FIB and

ARP entries are
correct
Yes
No
Yes
Do error
packets exist on
interfaces?
Yes
Clear faults on the link

and optical module
Is fault
rectified?
Yes
No
No
Does the
network layer of the
device work
properly?
Yes
Ensure that the

network layer works
properly
Is fault
rectified?
Yes
No
No
Issue 02 (2012-03-30)
Is fault
rectified?

End
165

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

1.
Check whether or not the ping -f command is run. If this command is run, it indicates that
packet fragmentation is not supported. In this case, check whether the MTU of the outbound
interface along the path is smaller than the size of the Ping packet. If the MTU is smaller
than the size of the Ping packet, packet loss will occur, in which case, you need to change
the size of the Ping packet to a value smaller than the MTU. Otherwise, go to Sub-step b.
You can run the following command to view the MTU of an interface:
<Huawei> display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Description:HUAWEI, AR Series, GigabitEthernet1/0/0 Interface
2.
Issue 02 (2012-03-30)
Check whether or not the ping -i command is run, that is, whether or not an outbound
interface is specified. If a broadcast interface such as an Ethernet interface is specified as
166

Troubleshooting
an outbound interface, the destination address to be pinged must be the address of the
directly connected interface. If this condition is not met, you need to specify the directly
connected interface as the outbound interface. If the fault persists, go to Step 3.
NOTE
If -f is specified in a ping command, it indicates that Ping packets do not support packet fragmentation. If
-i interface-name is specified in a ping command, it indicates that interface-name is specified as the
outbound interface of Ping packets and the destination address is used as the next-hop address.
Step 3 Locate the direction in which the fault occurs.

A ping operation involves three roles: the sending device (source end) of Ping packets,
intermediate device, and receiving device (destination end) of the Ping packets. If the ping
operation fails, the fault may occur in the sending or receiving direction of any of the three
devices and therefore you need to locate the direction and node where the fault occurs.
Figure 7-2 Application scenario of a ping operation
Ping packet
Source
Intermediate device
Destination
Check whether or not the fault occurs in the direction from the source end to the destination end
or in the reverse direction. Stop the ping operation on the source end and destination end, and
run the display icmp statistics command to check ICMP packet transmission. The following
information is displayed:
<Huawei> display icmp statistics
Input: bad formats
0
echo
36
source quench
0
echo reply
18
timestamp
0
mask requests
0
time exceeded
6
Mping request
0
Output:echo
20
source quench
0
echo reply
36
timestamp
0
mask requests
0
time exceeded
0
Mping request
0
bad checksum
destination unreachable
redirects
parameter problem
information request
mask replies
0
9
43
Mping reply
redirects
parameter problem
information reply
mask replies
0
71438
0
Mping reply
0
0
0
0
0
0
0
NOTE
Run the display icmp statistics command on the source end to view statistics about packets on the main control
board.
Run the display icmp statistics command on the destination end to view statistics about packets on a specified
interface board.
l If the number of ICMP packets does not increase, it indicates that the board or the device
does not receive other ICMP packets such as ICMP packets sent from the NMS. Do as follows
to locate the fault.
Perform a ping operation, and run the display icmp statistics command again to view
statistics about ICMP packets.
Issue 02 (2012-03-30)

167

Troubleshooting
According to the numbers of sent and received ICMP packets, you can locate the direction
in which the fault occurs:
If the following conditions are all met, it indicates that the source end sends Request
packets but does not receive any Response packet, and the destination end does not receive
the Request packets.
On the source end, the value of the Output:echo field increases normally but the value
of the Input:echo field does not increase.
On the destination end, the numbers of sent and received packets remain unchanged.
In this case, you can determine that the fault occurs in the direction from the source end
to the destination end.
If the following conditions are all met, it indicates that the source end sends Request
packets but does not receive any Response packet, and the destination end receives the
Request packets and sends Response packets.
On the source end, the value of the Output:echo field increases normally but the value
of the Input:echo field does not increase.
On the destination end, the numbers of sent and received packets increase normally.
In this case, you can determine that the fault occurs in the direction from the destination
end to the source end.
After determining the direction in which the fault occurs, go to Step 4.
l If the number of ICMP packets still increases, it indicates that the board or the device receives
other ICMP packets. Do as follows to locate the fault.
NOTE
Before performing subsequent operations, ensure that:

l Services on the current network will not be affected.
l No traffic policies are applied to interfaces.
1.
Configure an ACL on each device to match Ping packets by using source and destination
addresses.
Take the following configurations as an example:
statistics enable
#
acl number 3000
rule 5 permit ip source 1.1.1.1 0 destination 1.1.1.2 0
#
traffic classifier 3000 operator or
if-match acl 3000
#
traffic behavior 3000
#
traffic policy 3000
statistics enable
classifier 3000 behavior 3000
2.
Run the traffic-policy command in the interface view to configure a traffic policy and
apply the ACL to interfaces.
On the source end and destination end, apply the traffic policy in the inbound
direction of interfaces on both ends.
On the intermediate device, apply the traffic policy in both the inbound and outbound
directions of the associated interface.
Take the following configurations as an example:
#
interface GigabitEthernet1/0/0
Issue 02 (2012-03-30)

168

Troubleshooting
ip address 1.1.1.2 255.255.255.252

traffic-policy 3000 inbound
#
traffic-policy 3001 outbound
#
NOTE
If the ACL is applied to a trunk interface or VLANIF interface, you need to configure the traffic policy
on a physical member interface.
3.
Run the display traffic policy statisticsinterface command to view statistics about the
Ping packets that match the ACL on each interface.
<Huawei> display traffic policy statistics interface gigabitethernet 1/0/0
inbound
Interface: GigabitEthernet1/0/0
inbound: test
Traffic policy applied at 2007-08-30 18:30:20
Traffic policy Statistics enabled at 2007-08-30 18:30:20
Statistics last cleared: Never
Rule number: 7 IPv4, 1 IPv6
Current status: OK!
Item
Packets
Bytes
------------------------------------------------------------------Matched
1,000
100,000
+--Passed
500
50,000
+--Dropped
500
50,000
+--Filter
100
10,000
+--URPF
100
10,000
+--CAR
300
30,000
Missed
500
50,000
Last 30 seconds rate
If all Ping packets match the ACL, it indicates that the Ping packets are sent or
received normally. If the ping operation still fails, collect the preceding information
and contact Huawei technical support personnel.
If both incoming and outgoing Ping packets of the intermediate device match the
ACL, it indicates that the intermediate device works properly. Then, you need to
check whether or not a fault occurs on the source end or destination end.
If incoming Ping packets of one of the three devices do not match the ACL, it
indicates that the upstream device of this device becomes faulty. Then, go to Step
5.
Step 4 Locate the node where the fault occurs.
Locate the node according to the direction in which the fault occurs.
l If the fault occurs in the direction from the source end to the destination end, do as follows
to locate the node where the fault occurs, starting with the source end.
l If the fault occurs in the direction from the destination end to the source end, do as follows
to locate the node where the fault occurs, starting with the destination end.
Run the tracert dest-ip-address command to find the location where packet loss occurs.
<Huawei> tracert 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), max hops: 30, packet length: 40, press CTRL_C
to break
1 30.1.1.1 5 ms 4 ms 3 ms
2 89.0.0.2 10 ms 11 ms 8
3
* * *
...
The preceding command output shows that the next hop of the route to 89.0.0.2 (namely, the
node displayed as "3 * * *") becomes faulty. After locating the node where the fault occurs, go
to Step 5.
Issue 02 (2012-03-30)

169

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

170

Troubleshooting
After finding the node where the fault occurs, do as follows to locate the layer where the fault
occurs.
1.
Check whether or not ICMP packets are sent and received normally.
<Huawei> display icmp
Input: bad formats
echo
source quench
echo reply
timestamp
mask requests
time exceeded
Mping request
Output:echo
source quench
echo reply
timestamp
mask requests
time exceeded
Mping request
statistics
0
bad checksum
0
0
0
0
redirects
0
0
parameter problem
0
0
information request
0
0
mask replies
0
0
0
Mping reply
0
0
destination unreachable 476236
0
redirects
0
0
parameter problem
0
0
information reply
0
0
mask replies
0
0
0
Mping reply
0
If no ICMP packets are received or error packets are received, collect the preceding
information and contact Huawei technical support personnel.
If ICMP packets are received normally, go to Sub-step 3.
2.
Check whether the network layer is normal.

Run the display ip statistics command to check whether the network layer is normal.
<Huawei> display ip statistics
Input:
sum
bad protocol
bad checksum
discard srr
Output:
forwarding
dropped
Fragment: input
dropped
fragmented
Reassembling:sum
123174
0
0
0
0
0
0
0
0
0
local
bad format
bad options
TTL exceeded
local
no route
output
couldn't fragment
timeouts
0
0
0
0
268816
0
0
0
0
If error packet statistics (such as the values of the bad protocol, bad format, bad checksum,
bad options, discard srr, TTL exceeded, dropped, no route, and couldn't fragment fields)
displayed in the command output increase, it indicates that some error packets reach the
network layer and are dropped after validity check.
l If error packet statistics increase, it indicates that the board on the device may become
faulty. Then, collect the preceding information and contact Huawei technical support
personnel.
l If error packet statistics do not increase, go to Sub-step 3.
3.
Check whether or not ICMP packets can be delivered by the network layer normally.
Configure an ACL to check whether or not ICMP packets are delivered to an interface
board.
Take the following ACL configurations as an example:
acl number 3000
rule 5 permit icmp source 1.1.1.1 0 destination 1.1.1.2 0
Enable IP packet debugging.
Issue 02 (2012-03-30)

171

Troubleshooting
CAUTION
Enabling debugging affects the system performance. So confirm the action before you
enable debugging.
<Huawei> debugging ip packet acl 3000
<Huawei> terminal monitor
<Huawei> terminal debugging
Perform a ping operation, for example, send five Ping packets. On the terminal, check
whether five Ping packets are sent. If there is no information indicating that five Ping
packets are sent, it indicates that ICMP packets are not delivered to an interface board.
----End

Relevant Alarms
None.
Relevant Logs
None.

Pinging a Directly Connected Device Fails Because of an Incorrect ARP Entry
Fault Symptom
As shown in Figure 7-3, Router A and Router B are directly connected. Router A replaced
another device that was previously connected to Router B. After the network adjustment,
Router A cannot ping Router B, and the OSPF neighbor status on Router A is Exchange. After
Router A is replaced by the original device, the fault is rectified.
Issue 02 (2012-03-30)

172

Troubleshooting
Figure 7-3 Network diagram of directly connected devices
Area 0
RouterA
RouterB
GE1/0/0
1.1.1.1/24
GE1/0/0
1.1.1.2/24
Fault Analysis
1.
The original device could ping Router B, indicating that the link between the two devices
functions properly. Router A and Router B are directly connected, so the fault is not caused
by routing problems. The fault may be caused by errors in ARP learning.
2.
Run the display arp all command on Router A to check the ARP table.
<RouterA> display arp all
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE
INTERFACE
VPN-INSTANCE
VLAN/CEVLAN PVC
-----------------------------------------------------------------------------1.1.1.1 0025-9e80-2494
I GE1/0/0
1.1.1.2 0025-9e80-248e 18
D-0
GE1/0/0
-----------------------------------------------------------------------------Total:2
Dynamic:1
Static:0
Interface:1
The preceding command output shows that Router A has learned the ARP entry of
Router B.
3.
Run the display arp all command on Router B to check the ARP table.
<RouterB> display arp all
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE
INTERFACE
VPN-INSTANCE
VLAN/CEVLAN PVC
-----------------------------------------------------------------------------1.1.1.2 0025-9e80-248e
I GE1/0/0
1.1.1.1 0016-ecb9-0eb2 18
s
GE1/0/0
-----------------------------------------------------------------------------Total:2
Dynamic:0
Static:1
Interface:1
This ARP table shows that the IP address 1.1.1.1 maps the MAC address 0016-ecb9-0eb2.
The ARP entry type is S, indicating a static ARP entry. According to the ARP table on
Router A, however, 0016-ecb9-0eb2 is not the MAC address actually mapped to 1.1.1.1.
This static ARP entry was configured before the network adjustment. The ARP entry was
not updated after the network adjustment and therefore, Router A cannot ping Router B.
Procedure
Step 1 Run the system-view command on Router B to enter the system view.
Step 2 Run the undo arp static ip-address mac-address command to delete the static ARP entry.
Issue 02 (2012-03-30)

173

Troubleshooting
NOTE
After the static ARP entry is deleted, Router A can ping Router B. A new static ARP entry needs to be
configured to prevent ARP attacks.
Step 3 Run the arp static ip-address mac-address command to configure a new static ARP entry.
Router A can ping Router B. Run the display ospf peer command to check the status of the
OSPF neighbor. The OSPF neighbor is in Full state.
<RouterA> display ospf peer
OSPF Process 1 with Router ID 11.11.11.105
Neighbors
Area 0.0.0.0 interface 1.1.1.1(GigabitEthernet1/0/0)'s
neighbors
Router ID: 2.1.1.1
Address:
1.1.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: 1.1.1.2 BDR: 2.1.1.1 MTU: 0
Dead timer due in 30 sec
Retrans timer interval: 5
Neighbor is up for 00:28:17
Authentication Sequence: [ 0 ]
----End
Summary
If a static ARP entry is configured on a device, this entry must be modified after the MAC address
changes. If Router B is a non-Huawei device and you cannot log in to it to check the
configuration, configure the mirroring function to analyze packets transmitted between Router
A and Router B, and then ping Router B from Router A. Check whether the destination MAC
addresses of the packets are correct.
7.2 DHCP Troubleshooting

This chapter describes common causes of Dynamic Host Configuration Protocol (DHCP) faults,
and provides troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
7.2.1 A Client Cannot Obtain an IP Address (the AR1200 Functions

as the DHCP Server)
The AR1200 functions as a DHCP server and allocates IP addresses to clients in the same
network segment or different network segments.
Common Causes
l
A fault occurs on the link between the DHCP client and the DHCP server.
DHCP is disabled on the AR1200.
The DHCP address allocation mode is not set on an interface of the AR1200.
Issue 02 (2012-03-30)

174

Troubleshooting
When IP addresses are allocated from the global address pool, addresses contained in the
global address pool and the IP address of the VLANIF interface are in different network
segments.
When IP addresses are allocated from the global address pool:

If the client and server are located on the same network segment, all IP addresses in the
global address pool and the interface IP address on the AR1200 are on different network
segments.
If the client and server are located on different network segments and no relay agent is
deployed, all IP addresses in the global address pool and the interface IP address on the
relay agent are on different network segments.
There are no available addresses in the address pool.
Issue 02 (2012-03-30)

175

Troubleshooting
Figure 7-4 Troubleshooting flowchart for the failure to allocate an IP address from the DHCP
server to a client
A client cannot obtain
IP address from DHCP
server
No
Does link work

properly?
Is fault
rectified?
Rectify fault on link
Yes
No
Yes
No
Is DHCP
enabled?
Is fault
rectified?
Enable DHCP
Yes
No
Yes
Is address
allocation mode
set?
Yes
Does client obtain

IP from interface
address pool?
No
Is fault
rectified?
Set address
allocation mode
Yes
No
Is global IP pool and

interface
IP on same
No
network segment?
No
Yes
No Change interface
IP address
Yes
Are there available

IP addresses?
No
Yes
Seek
technical
support
No
Is fault
rectified?
Yes
No
Re-create a global
address pool or
reconfigure an IP address
for the interface
Is fault rectified?
Yes
End
NOTE
Saving the results of each troubleshooting step is recommended. If you are unable to correct the fault, you
will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check whether a fault occurs on the link between the client and the DHCP server.
l If the client and server are on the same network segment and no relay agent is deployed,
configure an IP address for the client network adapter connecting the client and the server.
Ensure that the IP address of the network adapter and the interface IP address are on the same
network segment. Ping the interface IP address from the client.
Issue 02 (2012-03-30)

176

Troubleshooting
If the ping operation fails, the link is faulty. Refer to 7.1 A Ping Operation Fails to rectify
the link fault.
l If the client and server are on different network segments and a relay agent is deployed, ping
the links between the client and the relay agent and between the relay agent and the server.
If the ping operation fails, the link is faulty. Refer to 7.1 A Ping Operation Fails to rectify
the link fault.
Step 2 Check that DHCP is enabled.
NOTE
If DHCP is disabled, the AR1200 does not process DHCP messages sent by the DHCP client.
Run the display current-configuration | include dhcp enable command to check whether
DHCP is enabled. By default, DHCP is disabled.
l If no DHCP information is displayed, DHCP is disabled. Run the dhcp enable command to
enable DHCP.
l If dhcp enable is displayed, DHCP is enabled. Go to step 3.
Step 3 Check whether DHCP address allocation mode is set on the interface of the AR1200.
NOTE
If the DHCP address allocation mode is not set on the interface of the AR1200, the client cannot obtain an
IP address in DHCP mode.
Run the display this command in the AR1200 interface view to check whether the DHCP address
allocation mode is set.
Information Displayed
Description
Subsequent Operation
dhcp select global
The AR1200 allocates IP

addresses to DHCP clients
from the global address pool
on the interface.
Perform step 4.
dhcp select interface
The AR1200 allocates IP

addresses to DHCP clients
from the interface address
pool on the interface.
Perform step 5.
No information displayed
The DHCP address

allocation mode is not set on
the interface.
Run the dhcp select global or

dhcp select interface
command to set the DHCP
address allocation mode on
the interface.
Step 4 Check whether addresses in the global address pool and the IP address of the interface are on
the same network segment.
1.
Issue 02 (2012-03-30)
Run the display ip pool command to check whether a global address pool has been created.
177

Troubleshooting
l If a global address pool has not been created, run the ip pool ip-pool-name and
network ip-address [ mask { mask | mask-length } ] commands to create a global
address pool and set the range of IP addresses that can be dynamically allocated.
l If the global address pool has been created, obtain the value of ip-pool-name. Then go
to step b.
2.
Run the display ip pool name ip-pool-name command to check any IP address in the global
address pool is on the same network segment as the interface IP address.
l The client and server are located on the same network segment and no relay agent is
deployed:
If any address in the global address pool is on a different network segment than the
interface IP address on the AR1200, run the network ip-address [ mask { mask |
mask-length } ] command to reconfigure the global address pool. Ensure that all IP
addresses in the address pool are on the same network segment as the interface IP
address on the AR1200.
If all addresses in the global address pool and the interface IP address on the
AR1200 are located on the same network segment, perform step 5.
l The client and server are located on different network segments and a relay agent is
deployed:
If all addresses in the global address pool and the interface IP address on the relay
agent are located on different network segments, run the ip address ip address
command to change the interface IP address to be on the same network segment as
all addresses in the global address pool.
If all addresses in the global address pool and the interface IP address on the relay
agent are located on the same network segment, perform step 5.
Step 5 Check whether the address pool contains available IP addresses.

Run the display ip pool name ip-pool-name command to check the availability of IP addresses
in the global or interface address pool.
l If the value of Idle(Expired) is equal to 0, no IP address can be allocated from the address
pool.
If the AR1200 has used the global address pool on the interface to allocate IP addresses
to clients, re-create a global address pool where the network segment can be connected
to the previous network segment but cannot overlap with the previous network segment.
If the AR1200 has used the interface address pool on the interface to allocate IP addresses
to clients, reconfigure an IP address for the interface. This IP address and the previous IP
address must be on different network segments.
l If the value of Idle(Expired) is greater than 0, there are idle (expired) IP addresses. Go to
step 6.
Step 6 Contact Huawei technical support personnel and provide them with the following information.
----End

Issue 02 (2012-03-30)

178

Troubleshooting
Relevant Alarms
None.
Relevant Logs
None.
7.2.2 A Client Cannot Obtain an IP Address (the AR1200 Functions

as the DHCP Relay Agent)
A DHCP client and the DHCP server are located on different network segment. The AR1200
functions as a DHCP relay agent. The DHCP server uses the DHCP relay agent to allocate IP
addresses to DHCP clients.
Common Causes
l
The link between the client and the DHCP server is faulty.
The link between the client and the DHCP relay agent is faulty.
The link between the DHCP relay agent and the DHCP server is faulty.
DHCP is disabled on the AR1200 globally. As a result, the DHCP function does not take
effect.
The DHCP relay function is disabled on the AR1200. As a result, the DHCP relay function
does not take effect.
The DHCP relay agent is not bound to the DHCP server.

The DHCP server IP address is not configured on the DHCP relay agent.
The interface on the DHCP relay agent is not bound to a DHCP server group or it is
bound to a server group that contains no DHCP server.
The configurations of other devices along the link are incorrect.
Issue 02 (2012-03-30)

179

Troubleshooting
Figure 7-5 Troubleshooting flowchart for the failure to allocate IP addresses using the DHCP
relay agent
A client cannot obtain
an IP address from
DHCP server by DHCP
relay agent
Does link work

properly?
No
Rectify fault on link
Is fault
rectified?
Yes
No
Yes
Is DHCP enabled
on DHCP relay
agent?
Yes
No
Is DHCP relay
enabled?
No
Enable DHCP
globally
Is fault
rectified?
Yes
No
Enable DHCP relay
Is fault
rectified?
Yes
No
Yes
Is DHCP relay
bound to DHCP
server?
No Bind the DHCP server

group or configure
DHCP servers
Is fault
rectified?
Yes
No
Yes
Are configurations
of other devices
correct?
No
Correctly configure
other devices
Is fault
rectified?
Yes
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether a fault occurs between the DHCP client and the DHCP server.
1.
Check whether DHCP snooping is enabled on devices between the client and server. If
DHCP snooping is enabled on a device, run the display dhcp snooping global command
to check DHCP snooping configuration. Ensure that the interface connected to the DHCP
server is a trusted interface.
2.
Check whether a fault occurs between the DHCP client and the DHCP relay agent.
Issue 02 (2012-03-30)

180

Troubleshooting
Manually configure an IP address on the DHCP client to be on the same network segment
as the user-side interface of the DHCP relay agent. This IP address must be different from
allocated IP addresses. Ping the peer device from the IP address to check whether the link
works properly.
l If the ping operation fails, Refer to 7.1 A Ping Operation Fails to rectify the link fault.
l If the ping operation succeeds, go to step b.
3.
Check whether a fault occurs between the DHCP relay agent and the DHCP server.
Run the ping -a source-ip-address destination-ip-address command on the DHCP relay
agent. source-ip-address specifies the user-side interface of the DHCP relay agent and
destination-ip-address specifies the IP address of the DHCP server.
l If the ping operation fails, Refer to 7.1 A Ping Operation Fails to rectify the link fault.
l If the ping operation succeeds, go to step 2.
Step 2 Check whether DHCP is enabled globally on the DHCP relay agent.
NOTE
If DHCP is not enabled globally, the AR1200 does not process DHCP messages sent by DHCP clients.
Run the display current-configuration | include dhcp enable command to check whether
DHCP is enabled. By default, DHCP is disabled.
l If no information is displayed, DHCP is disabled. Run the dhcp enable command to enable
DHCP.
l If the dhcp enable command is displayed, DHCP is enabled. Go to step 3.
Step 3 Check that the DHCP relay function is enabled.
NOTE
l If the DHCP relay function is disabled, the DHCP client cannot obtain an address on another network
segment.
l If the address allocation mode (global/interface) and relay are both configured on the AR1200, the
AR1200 will function as a DHCP server. If the DHCP server is unable to allocate IP addresses, the
AR1200 will function as a DHCP relay agent.
In the interface view on the AR1200, run the display this command to check whether the DHCP
relay function is enabled.
l If dhcp select relay is displayed, the DHCP relay function is enabled. Go to step 4.
l If no information is displayed, the DHCP relay function is disabled. Run the dhcp select
relay command to enable the DHCP relay function.
Step 4 Check that the DHCP relay agent is bound to the DHCP server.
NOTE
If the DHCP relay agent is not bound to the DHCP server, no DHCP server can allocate IP addresses to
DHCP clients connected to the DHCP relay agent.
In the interface view on the AR1200, run the display this command to check whether the DHCP
relay agent is bound to the DHCP server.
l If dhcp relay server-ip ip-address is displayed, the DHCP server IP address is configured
on the DHCP relay agent. Go to step 6.
l If dhcp relay server-select group-name is displayed, the interface on the DHCP relay agent
is bound to a DHCP server group. Go to step 5.
Issue 02 (2012-03-30)

181

Troubleshooting
l If no information is displayed, the DHCP server IP address is not configured on the DHCP
relay agent. Use either of the following methods to configure the DHCP server:
Run the dhcp relay server-ip ip-address command to configure the DHCP server IP
address on the DHCP relay agent.
Run the dhcp relay server-select group-name command to bind the interface to a DHCP
server group and run the dhcp-server command to add a DHCP server to the DHCP
server group.
Step 5 Check that DHCP servers have been added to the DHCP server group.
NOTE
If the interface of the DHCP relay agent is bound to a DHCP server group but no DHCP server has been
added to the DHCP server group, no DHCP server can allocate IP addresses to DHCP clients connected
to the DHCP relay agent.
Run the display dhcp server group group-name command to check whether DHCP servers
have been added to the DHCP server group.
l If the Server-IP field is displayed, DHCP servers have been added to the DHCP server group.
Go to step 6.
l If the Server-IP field is not displayed, no DHCP server has been added to the DHCP server
group. Run the dhcp-server command to add DHCP servers to the DHCP server group.
Step 6 Check that the configurations of other devices along the link between the DHCP client and the
DHCP server are correct, including DSLAMs, LAN switches, and other clients.
Check whether the configurations of other devices along the link are correct and modify
configurations as needed. If the client still cannot obtain an IP address after the above steps are
complete, go to step 7.
NOTE
For details on how to check the configurations of the DHCP server, see 7.2.1 A Client Cannot Obtain an
IP Address (the AR1200 Functions as the DHCP Server).
----End

Relevant Alarms
None.
Relevant Logs
None.
7.3 RIP Troubleshooting

Issue 02 (2012-03-30)

182

Troubleshooting
7.3.1 Device Does not Receive Partial or All the Routes

Common Causes
l
The incoming interface is not enabled with RIP.
The incoming interface is not in Up state.
The version number sent by the peer does not match with that received on the local interface.
The interface is disabled to receive the RIP packet.
The polic used to filter the received RIP routes is configured.
The metric of the received routes is larger than 16.
Other protocols have learned the same routes in the routing table.
The number of the received routes exceeds the upper limit.
The MTU value of the incoming interface is less than 532.
The authentication of sending and receiving interface is not matching.
If a router receives partial or none routes or the display ip routing-table command dose not
display routes learned by RIP, refer to the following troubleshooting flowchart, as shown in
Figure 7-6.
Issue 02 (2012-03-30)

183

Troubleshooting
Figure 7-6 RIP route receiving troubleshooting flowchart

Device does not
receive partial or all
the routes
Ingress is
enabled?
No
Enable the ingress
Is fault
rectified?
Yes
No
Yes
Ingress is normal?
No Ensure the normal

state on the
ingress
Is fault
rectified?
Yes
No
Yes
Version
numbers are
the same?
Ensure the same

No version number on
sending and
receiving interface
Is fault
rectified?
No
Yes
undo rip input
is configured?
Yes Cancel the undo

rip input
command
Is fault
rectified?
Yes Ensure the policy

does not filter out
received packets
Is fault
rectified?
Yes Reduce the value

of rip metricin
Is fault
rectified?
Yes
No
No
rip metricin
is configured?
Yes
No
No
Filtering policy
is configured?
Yes
Yes
No
No
Metric
is larger than
16?
No
Yes
There
are other better
routes?
No
Yes
Seek technical
support
End
NOTE
Issue 02 (2012-03-30)

184

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

185

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

Relevant Alarms
None.
Relevant Logs
None.
7.3.2 Device Does not Send Some or All Routes

Common Causes
l
The outgoing interface is not enabled with RIP.
The outgoing interface is not in the Up state.
The silent-interface command is configured on the outgoing interface so that the interface
is suppressed from sending RIP packets.
Issue 02 (2012-03-30)

186

Troubleshooting
The undo rip output command is configured on the outgoing interface so that the interface
is disabled to send the RIP packet.
The RIP split-horizon is disabled on the outgoing interface.
The policy for filtering imported RIP routes is configured in RIP.
The physical status of the interface is Down or Administratively Down, or the current
status of the protocol on the outgoing interface is Down. The IP address of the interface
cannot be added to the advertised routing table for RIP.
Although the outgoing interface does not support the multicast or broadcast mode, packets
must be sent to a multicast or broadcast address.
The MTU value of the outgoing interface is less than 52.
If a router sends partial or none routes, refer to the following troubleshooting flowchart, as shown
in Figure 7-7.
Issue 02 (2012-03-30)

187

Troubleshooting
Figure 7-7 RIP route sending troubleshooting flowchart
Device does not

send partial or all
the routes
Egress is
enabled?
No
Enable the egress
Is fault
rectified?
Yes
No
Yes
Egress is
normal?
No
Ensure the normal

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

output command
Is fault
rectified?
Yes
No
No
Split horizon
is configured?
Yes
No
Filtering policy
is configured?
Yes
Ensure the policy

does not filter out
routes imported by
RIP
No
Local
interface is
normal?
Yes
Any other
problems?
No
If packets are sent to

No local interface, ensure
the normal state on
local interface
Yes
Interface is enabled
multicast and peer
command is
configured correctly
Seek technical
support
Is fault
rectified?
Yes
No
Is fault
rectified?
Yes
No
Is fault
rectified?
Yes
No
End
Issue 02 (2012-03-30)

188

Troubleshooting
NOTE
Procedure
Step 1 Check whether the outgoing interface is enabled with RIP.
The network command is used to specify an interface network segment. Only an interface
enabled with RIP can receive and send RIP routes.
Run the display current-configuration configuration rip command to check information
about a network segment where RIP is enabled. Check whether the outgoing interface is enabled.
The network address enabled by using the network command must be that of the natural network
segment.
Step 2 Check whether the outgoing interface works normally.
Run the display interface command to check the operating status of the outgoing interface.
If the physical status of the interface is Down or Administratively Down, or the status of the
current protocol is Down, RIP cannot work properly on the interface.
Ensure that the interface is normal.
Step 3 Check whether the silent-interface command is configured on the outgoing interface.
The silent-interface command is used to suppress the interface from sending the RIP packet.
The display current-configuration configuration rip command is used to check whether the
interface is suppressed from sending RIP packets.
If the silent-interface command is configured, disable suppression on the interface.
Step 4 Check whether the undo rip output command is configured on the outgoing interface.
Run the display current-configuration command on the outgoing interface to view whether
the rip output command is configured.
The rip output command enables the interface to send RIP packets.
The undo rip output command disables the interface from sending RIP packets.
If the undo rip output command is configured on the outgoing interface, the RIP packet cannot
be sent on the interface.
Step 5 Check whether the rip split-horizon command is configured on the outgoing interface.
Run the display current-configuration command on the outgoing interface to view whether
the rip split-horizon command is configured. If the command is configured, split-horizon is
enabled on the outgoing interface.
By default, split-horizon is enabled on all outgoing interfaces, and the output of the command
does not contain configuration items about split-horizon.
For the outgoing interface (such as X.25, FR) on the NonBroadcast Multiple Access (NBMA)
network, if the display does not contain a configuration item about split-horizon, it indicates
split-horizon is not enabled on the outgoing interface.
Split-horizon means that the route learned from an interface is not advertised on the interface.
Issue 02 (2012-03-30)

189

Troubleshooting
Split-horizon is used to prevent a loop between adjacent neighbors from forming.

Step 6 Check whether the policy filtering the imported RIP route is configured in RIP.
Run the filter-policy export command to configure the filtering policy on the global interface.
Only routes that pass the filtering policy can be added to the advertised routing table of RIP.
These routes are advertised through the updated packet.
Step 7 Check the status of the interface when the route is sent to the local interface address.
Run the display interface command to check the operating status of the interface.
If the physical status of the interface is Down or Administratively Down, or the current status
of the protocol on the outgoing interface is Down, the IP address of the interface cannot be added
to the advertised routing table of RIP. Therefore, the routing information is not sent to the
neighbor.
Step 8 Check whether there are other problems.
If the outgoing interface does not support multicast or broadcast mode and a packet needs to be
sent to a multicast or broadcast address, this fault will occur.
This potential source of the fault can be removed by configuring the peer command in the RIP
mode to make routers send packets with unicast addresses.
Step 9 If the fault persists, contact Huawei technical support personnel and provide them with the
following information.
----End

Relevant Alarms
None.
Relevant Logs
None.
7.4 OSPF Troubleshooting

7.4.1 The OSPF Neighbor Relationship Is Down
Common Causes
l
Issue 02 (2012-03-30)
The BFD is faulty.

190

Troubleshooting
The other device is faulty.
CPU usage on the MPU or LPU of the faulty device is too high.
The link is faulty.
The interface is not Up.
The IP addresses of the two devices on both ends of the link are on different network
segments.
The router IDs of the two devices conflict.
The area types of the two devices are inconsistent.
The parameter settings of the two devices are inconsistent.
After OSPF is configured on the network, it is found that the OSPF neighbor relationship is
Down. Figure 7-8 shows the troubleshooting flowchart.
Figure 7-8 Troubleshooting flowchart for the fault that the OSPF neighbor relationship is Down
The OSPF neighbor
relationship is Down
Check logs or alarms to find

the value of the
NeighborDownImmediate
field
Neighbor Down
Due to Inactivity?
Yes
Check the
configurations of the
devices at both
ends of the link
Is fault
rectified?
Yes
No
No
Neighbor Down
Due to Kill Neighbor?
Yes
Check the interface

and BFD
Is fault
rectified?
Yes
No
No
Neighbor Down
Due to 1-Wayhello
Received?
Yes
Check the remote

device
Is fault
rectified?
Yes
No
No
Neighbor Down
Due to SequenceNum
Mismatch?
No
Yes
Check the remote

device
Is fault
rectified?
Seek technical
support
Yes
No
End
Issue 02 (2012-03-30)

191

Troubleshooting
NOTE
Procedure
Step 1 Check logs to find the cause of the fault.
Run the display logbuffer command, and you can find the following log information:
NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=
[USHORT], NeighborRouterId=[IPADDR], NeighborAreaId=[ULONG], NeighborInterface=
[STRING],NeighborDownImmediate reason=[STRING], NeighborDownPrimeReason=[STRING],
NeighborChangeTime=[STRING])
Check the NeighborDownImmediate reason field which records the cause of the fault. The
possible causes of the fault are as follows:
l Neighbor Down Due to Inactivity
If a device does not receive a Hello packet from its neighbor within the timeout period, the
OSPF neighbor relationship goes Down. In this case, go to Step 2.
l Neighbor Down Due to Kill Neighbor
If the interface is Down, BFD is Down, or the reset ospf process command is run, the OSPF
neighbor relationship goes Down. In this case, check the NeighborDownPrimeReason field
to determine the specific cause of the fault.
If the value of the NeighborDownPrimeReason field is Physical Interface State Change,
it indicates that the interface status has changed. In this case, run the display interface
[ interface-type [ interface-number ] ] command to check the interface status, and then
troubleshoot the interface fault.
If the value of the NeighborDownPrimeReason field is BFD Session Down, it indicates
that the BFD session status is Down. In this case, troubleshoot the BFD fault.
If the value of the NeighborDownPrimeReason field is OSPF Process Reset, it indicates
that the reset ospf process command has been run. The OSPF process is restarting. Wait
until OSPF re-establishes the OSPF neighbor relationship.
l Neighbor Down Due to 1-Wayhello Received or Neighbor Down Due to SequenceNum
Mismatch
When the OSPF status on the remote device goes Down first, the remote device sends a 1Way Hello packet to the local device, causing OSPF on the local device to go Down. In this
case, troubleshoot the fault that caused OSPF on the remote device to go Down.
l In other cases, go to Step 9.
Step 2 Check that the link between the two devices is normal.
Step 3 Check that the CPU usage is within the normal range.
Run the display cpu-usage command to check whether the CPU usage of the faulty device is
higher than 60%. If the CPU usage is too high, OSPF fails to normally send and receive protocol
packets, causing the neighbor relationship to flap. In this case, go to Step 9. If the CPU usage
is within the normal range, go to Step 4.
Step 4 Check that the interface status is Up.
Run the display interface [ interface-type [ interface-number ] ] command to check the physical
status of the interface. If the physical status of the interface is Down, troubleshoot the interface
fault.
Issue 02 (2012-03-30)

192

Troubleshooting
If the physical status of the interface is Up, run the display ospf interface command to check
whether the OSPF status of the interface is Down. The normal status is DR, BDR, DR Other, or
P2P.
<Huawei> display ospf interface
Interfaces
Area: 0.0.0.0
IP Address
Type
State
Cost
Pri
192.1.1.1
Broadcast
DR
1
1
DR
192.1.1.1
BDR
0.0.0.0
If the OSPF status of the interface is Down, run the display ospf cumulative command to
check whether the number of interfaces with OSPF enabled in the OSPF process exceeds
the upper threshold. If so, reduce the number of interfaces with OSPF enabled. For the
details about upper threshold of the interfaces, see the /License file of the product.
<Huawei> display ospf cumulative
Cumulations
IO Statistics
Type
Input
Output
Hello
0
86
DB Description
0
0
Link-State Req
0
0
Link-State Update
0
0
Link-State Ack
0
0
SendPacket Peak-Control: (Disabled)
ASE: (Disabled)
LSAs originated by this router
Router: 1
Network: 0
Sum-Net: 0
Sum-Asbr: 0
External: 0
NSSA: 0
Opq-Link: 0
Opq-Area: 0
Opq-As: 0
LSAs Originated: 1 LSAs Received: 0
Routing Table:
Intra Area: 1 Inter Area: 0 ASE: 0
Up Interface Cumulate: 1
If the OSPF status of the interface is not Down, go to Step 5.
Step 5 If the interface is connected to a broadcast network or an NBMA network, ensure that the IP
addresses of the two devices are on the same network segment.
l
If the IP addresses of the two devices are on different network segments, modify the IP
addresses of the devices to ensure that the IP addresses are on the same network segment.
If the IP addresses of the two devices are on the same network segment, go to Step 6.
Step 6 Check that the MTUs of the interfaces on both ends are consistent.
If the ospf mtu-enable command is run on interfaces on both ends, the MTUs of the two
interfaces must be consistent. If the MTUs are inconsistent, the OSPF neighbor relationship
cannot be established.
l If the MTUs of the two interfaces are inconsistent, run the mtu mtu command in the interface
view to change the MTUs of the two interfaces to be consistent.
l If the MTUs of the two interfaces are consistent, go to Step 7.
Step 7 Check whether there is an interface with a priority that is not 0.
Issue 02 (2012-03-30)

193

Troubleshooting
On broadcast and NBMA network segments, there must be at least one interface with a priority
that is not 0 to ensure that the DR can be correctly elected. Otherwise, the OSPF neighbor
relationship can only reach the two-way state.
Run the display ospf interface command to view the interface priority.
Interfaces
Area: 0.0.0.0
IP Address
Type
State
Cost Pri
1.1.1.41
Broadcast
DR
1
1
DR
1.1.1.41
BDR
0.0.0.0
Step 8 Ensure that the OSPF configurations on the two devices are correct.
1.
Check whether the OSPF router IDs of the two devices are the same.
<Huawei> display ospf brief
OSPF Protocol Information
If the IDs are the same, run the ospf router-idrouter-id command to modify the OSPF
router IDs of the two devices. The router ID of each device should be unique within an AS.
If the router IDs are not the same, proceed with this step.
2.
Check whether the OSPF area configurations on the two devices are consistent.
Interfaces
Area: 0.0.0.0
IP Address
Type
State
Cost Pri
111.1.1.1
Broadcast
BDR
1
1
DR
111.1.1.2
BDR
111.1.1.1
If the OSPF area configurations on the two devices are inconsistent, modify the OSPF Area.
If they are consistent, proceed with this step.
3.
Check whether other OSPF configurations on the two devices are consistent.
Run the display ospf error command every 10s for 5 m.
<Huawei> display ospf error
OSPF error statistics
General packet errors:
0
: IP: received my own packet
0
: Bad packet
0
: Bad version
0
: Bad checksum
0
: Bad area id
0
: Drop on unnumbered interface
0
: Bad virtual link
0
: Bad authentication type
0
: Bad authentication key
0
: Packet too small
0
: Packet size > ip length
0
: Transmit error
0
: Interface down
0
: Unknown neighbor
HELLO packet errors:
0
: Netmask mismatch
0
: Hello timer mismatch
0
: Dead timer mismatch
0
: Extern option mismatch
0
: Router id confusion
0
: Virtual neighbor unknown
0
: NBMA neighbor unknown
0
: Invalid Source Address
l Check the Bad authentication type field. If the value of this field keeps increasing, the
OSPF authentication types of the two devices that establish the neighbor relationship
are inconsistent. In this case, run the area-authentication-mode command to configure
the same authentication type for the two devices.
l Check the Hello timer mismatch field. If the value of this field keeps increasing, the
value of the Hello timers on the two devices that establish the neighbor relationship are
inconsistent. In this case, check the interface configurations of the two devices and run
the ospf timer hello command to set the same value for the Hello timers.
l Check the Dead timer mismatch field. If the value of this field keeps increasing, the
values of the dead timers on the two devices that establish the neighbor relationship are
Issue 02 (2012-03-30)

194

Troubleshooting
inconsistent. In this case, check the interface configurations of the two devices and run
the ospf timer dead command to set the same value for the dead timers.
l Check the Extern option mismatch field. If the value of this field keeps increasing,
the area types of the two devices that establish the neighbor relationship are inconsistent
(the area type of one device is common area, and the area type of the other device is
stub area or NSSA). In this case, configure the same area type for the two devices (in
the OSPF area view, the stub command indicates the area type is stub and the stub
command indicates the area type is nssa).
Step 9 Step 9 Contact Huawei technical support personnel and provide them with the following
information.
----End

Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
Relevant Logs
OSPF/4/NBR_DOWN_REASON
7.4.2 The OSPF Neighbor Relationship Cannot Reach the Full State
Common Causes
l
The link is faulty and the OSPF packets are dropped.
The configuration of the dr-priority on the interfaces is incorrect.
The OSPF MTUs of the local device and its neighbor are different.
Issue 02 (2012-03-30)

195

Troubleshooting
Figure 7-9 Troubleshoot flowchart for the fault that the OSPF neighbor relationship cannot
reach the Full state
The OSPF
relationship cannot
enter the Full state.
Check the status of the
OSPF neighbor relationship.
Can the status of the

neighbor relationship be
displayed?
Yes
See "OSPF
Neighbor
Relationship Is
Down" to rectify the
fault.
Is fault
rectified?
Yes
No
No
Is the neighbor
relationship always in
the Down state?
Yes
Check the interface

status.
Is fault
rectified?
Yes
No
No
Is the neighbor
the Init state?
Yes
Check the remote

device and the link.
Is fault
rectified?
Yes
No
No
Is the neighbor
the 2-Way state?
Yes
Check the interface

configured.
Is fault
rectified?
Yes
Yes
Perform the ping

operation.
Is fault
rectified?
Yes
No
Is the neighbor
the Exstart state?
No
No
Is the neighbor
the Exchange
state?
No
Yes
Perform the ping

operation.
Is fault
rectified?
Yes
No
Seek technical
support
End
NOTE
Issue 02 (2012-03-30)

196

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

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

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

197

Troubleshooting

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

Issue 02 (2012-03-30)

198

Troubleshooting
Relevant Alarms
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket
OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange
Relevant Logs
None.
7.4.3 Trouble Cases

Routes Are Abnormal Because the FA Fields in Type 5 LSAs Are Set Incorrectly
Fault Symptom
On the network shown in Figure 7-10, Router C is a non-Huawei device. Router A and
Router B are two routers. Router A and Router B have two upstream GE interfaces and are
configured with two static routes.
l
Router A
[RouterA] ip route-static 0.0.0.0 0.0.0.0 192.168.0.69
[RouterA] ip route-static 0.0.0.0 0.0.0.0 192.168.0.65
Router B
[RouterB] ip route-static 0.0.0.0 0.0.0.0 192.168.0.5
[RouterB] ip route-static 0.0.0.0 0.0.0.0 192.168.0.1
Router A and Router B advertise default routes to Router C in an unforced manner. Normally,
Router C has a default external route to Router A and another default external route to Router
B. Router C, however, has a route to only one of Routers A and B in the following situations:
l
The static route 192.168.0.65 on Router A is deleted, and other configurations remain
unchanged. In this case, Router C has an OSPF default route to only Router B.
The static route 192.168.0.1 on Router B is deleted, and other configurations remain
unchanged. In this case, Router C has an OSPF default route to only Router A.
Figure 7-10 Network diagram of the networking where routes on a device are abnormal
GE1/0/0
GE2/0/0 GE1/0/0
RouterA
192.168.1.253
GE2/0/0
RouterB
192.168.1.254
RouterC
Issue 02 (2012-03-30)

199

Troubleshooting
Fault Analysis
1.
Run the undo ip route-static 0.0.0.0 0.0.0.0 192.168.0.65 command on Router A, and then
view the details about the corresponding LSA on Router C. The FA field of the LSA is
incorrectly set by Router A. In this case, Router C has an OSPF default route to only
Router B, because Router C finds that the route to address 192.168.0.69 is unreachable
when performing SPF calculation.
2.
Run the undo ip route-static 0.0.0.0 0.0.0.0 192.168.0.1 command on Router B, and then
view the details about the corresponding LSA on Router C. The FA field of the LSA is
incorrectly set by Router B. In this case, Router C has an OSPF default route to only
Router A, because Router C finds that the route to address 192.168.0.5 is unreachable when
performing SPF calculation.
3.
The preceding analysis shows that the root cause of the fault is that Router A and Router
B incorrectly set the FA fields in the corresponding LSAs.
The rules the router uses to fill in the FA fields of LSAs and calculate routes are as follows:
l When the value of the FA field of a Type 5 LSA is 0.0.0.0, the router that receives the
LSA knows that the router sending the LSA is an advertising router (that is, an ASBR),
and calculates the next hop.
l When all of the following conditions are met, an ASBR fills in an address other than
0.0.0.0 in the FA field of a Type 5 LSA, and the router that receives the LSA calculates
the next hop based on the value of the FA field:
a.
OSPF is enabled on the interface connecting the ASBR to an external network.
b.
The interface connecting the ASBR to an external network is not configured as a

silent interface.
c.
The network type of the interface connecting the ASBR to an external network is
not P2P or P2MP.
d.
The address of the interface connecting the ASBR to an external network is within
the network address range advertised by OSPF.
If none of the preceding conditions are met, the FA field of an LSA is set to 0.0.0.0.
Procedure
Step 1 Do as follows to rectify the fault:
l Check the data configuration on Router A and Router B, the following information can be
found:
The network 192.168.0.68 0.0.0.3 command rather than the network 192.168.0.64
0.0.0.3 command is run in the OSPF process on Router A.
The network 192.168.0.4 0.0.0.3 command rather than the network 192.168.0.0
0.0.0.3 command is run in the OSPF process on Router B.
l In the OSPF process on Router A, delete the network command used to advertise the network
segment to which the next hop of the configured static route corresponds. Perform the same
operation on Router B. Then, the fault is rectified.
l Run the ospf network-type p2p command on the interface specified in the network
command run on the Router A to change the network type of the interface. Then, perform
the same operation on Router B. After that, the fault is rectified.
Issue 02 (2012-03-30)

200

Troubleshooting
l Set the corresponding interface on Router A to be a silent interface, or enable the routes from
Router C to all the next hops of the static routes of Router A to be reachable. Perform the
same operation on Router B. Then, the fault is rectified.
----End
Summary
The network segment addresses and interface types of OSPF interfaces must be correct
configured. This allows the router to correctly fill in the FA field in a Type 5 LSA and calculate
routes based on defined rules.
The router Receives Two LSAs with the Same LS ID but Fails to Calculate a Route
Based on One of the LSAs
Fault Symptom
On the network shown in Figure 7-11, traffic is unevenly distributed between the path from
Router A to the BAS and the path from Router B to the BAS. Load balancing between the path
Router A -> BAS -> destination and the path Router A -> RouterB -> BAS-> destination must
be configured for the traffic transmitted from Router A to the network segment to which the
BAS is connected.
Figure 7-11 Network diagram of the router receiving two LSAs with the same LS ID but fails
to calculate a route based on one of the LSAs
RouterA
RouterB
10.1.2.26
Static route
destined for
10.1.1.0
BAS
10.1.3.1
10.1.1.0
The following uses traffic sent to network segment 10.1.1.0 as an example.

On Router B, a static route to 10.1.1.0 is configured and OSPF is configured to import static
routes. Router A receives an ASE LSA with the LS ID 10.1.1.0 from Router B and an ASE LSA
with the same LS ID from the BAS. Router A can calculate a route based on the LSA received
from the BAS, but fails to calculate a route based on the LSA received from Router B.
Fault Analysis
The possible causes are as follows:
1.
Device configurations are incorrect.
2.
The FA field in the LSA sent by Router B is 10.1.2.26. The LSA is not calculated because
the FA field of the LSA is incorrect.
3.
The conditions required to generate routes for load balancing are not met.
Issue 02 (2012-03-30)

201

Troubleshooting
Based on the analysis of the preceding possible causes, it can be concluded:

1.
The configurations of the devices are normal.
2.
The LSA whose FA field meets the condition of route calculation.

<RouterA> ping 10.1.3.1
Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=255 time=1
ms
ms
ms
ms
ms

0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
<RouterA> display ip routing-table 10.1.3.1
Route Flags: R - relay, D - download to fib
-----------------------------------------------------------------------------Routing Table : Public
Summary Count : 2
Destination/Mask
Proto
Pre
10.1.3.1/32 O_ASE 150

GigabitEthernet1/0/0
O_ASE 150
Cost
Flags NextHop
10.1.2.45
10.1.2.49
Interface
Reply from 10.1.2.26: bytes=56 Sequence=1 ttl=254 time=1 ms

0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
<RouterA> display ip routing-table 10.1.2.26
10.1.2.24/30 OSPF
OSPF
3.
10
101
10
101
D
D
10.1.2.45
10.1.2.49
On this network, the costs of LSAs are 1. Compare the cost of the route to the ASBR and
the cost of the route to the FA.
For Type 2 ASE LSAs, OSPF equal-cost routes can be generated when the following
conditions are met:
a.
The costs of LSAs are the same.
b.
The cost of the route to the ASBR is the same as the cost of the route to the FA.
On the network, the cost of the route to the FA is 101.

l For the LSA with the FA field 0.0.0.0, the cost of the route to ASBR at 10.1.3.1 is 1.
l For the LSA with an FA field other than 0.0.0.0, the cost of the route to the FA at
10.1.2.26 is 101.
The LSA with the FA field being set is not calculated because the priority of the LSA is
lower. As a result, equal-cost routes cannot be formed.
Procedure
Step 1 To form equal-cost routes on the network, do as follows:
Issue 02 (2012-03-30)

202

Troubleshooting
On the BAS, run the network command to enable OSPF on the next-hop interface of the route
to 10.1.1.0. Run the ospf cost command to set the cost of the interface to 100 so that the interface
advertises LSAs with the FA field as the address of the interface.
Then, there will be two LSAs with FA fields on Router A. The cost of the route to one FA and
the cost of the route to the other FA are both 101. Thus, equal-cost routes can be formed.
----End
Summary
To form equal-cost routes, set the same cost on the interfaces so that the interfaces advertise
LSAs with the same FA field, the addresses of the interfaces.
The OSPF Neighbor Relationship Cannot Be Established Between Two Devices

Because the Link Between the Devices Is Faulty
Fault Symptom
In the networking shown in Figure 7-12, the OSPF neighbor relationship cannot be established
between Router A and its neighbor, and the neighbor is in the Exchange state.
Figure 7-12 Network diagram of the networking where the neighbor relationship cannot be
established between two devices
10.1.1.0
RouterA
RouterB
Fault Analysis
The possible causes are as follows:
l
The OSPF configurations are improper.
Parameters of the two devices are incorrectly set.
The OSPF packets are lost.
Check the configuration of Router A and find that Router A is correctly configured.
Check the OSPF parameters on the corresponding interfaces and find that the OSPF parameters
on the interfaces are set correctly.
Run the related debugging command on Router B and find that MTU negotiation fails.
The MTUs on the two devices are 4470. The debugging ospf packet dd command, however,
shows that the MTU contained in the packet received by Router B is 0, which indicates that the
MTU is not set on the peer device. It is concluded that the link is not working normally.
Run the following command on Router A to ping the peer device. Packet loss occurs.
Request time out
Issue 02 (2012-03-30)

203

Troubleshooting

Request time out
40.00% packet loss
Ensure that the link between intermediate transmission devices is normal. Collect traffic statistics
from Router A. It is found that packet loss does not occur on Router A. Thus, packet loss may
be occurring on the board of the peer device or on the link.
Collect traffic statistics on the peer device. It is found that packet loss occurs on the board on
Router B because the board is faulty
Procedure
Step 1 Replace the faulty board on Router B.
----End
Summary
Sometimes, OSPF packets are not received received. In this case, check connectivity at the link
layer first. Enable OSPF debugging with the commands such as the debugging ospf packet and
debugging ospf event commands to locate the fault, or run the display ospf error command to
view the various OSPF error statistics. If the OSPF configuration is correct, run the debugging
ip packet command to check whether packets are successfully forwarded at the IP layer.
An OSPF Routing Loop Occurs Because Router IDs of Devices Conflict

Fault Symptom
In the networking shown in Figure 7-13, OSPF multi-instance is run between PEs and CEs. The
CEs are Layer 3 switches of other manufacturers. The PEs deliver OSPF default routes to
interwork the networks of two cities.
CE1 can successfully ping PE1, and CE2 can successfully ping PE2. When a CE pings a remote
peer or a device on the remote network, packet loss occasionally occurs.
Figure 7-13 Network diagram of an OSPF routing loop that occurs because router IDs of the
devices conflict
PE1
PE2
City B
City A
CE1
Issue 02 (2012-03-30)
CE2

204

Troubleshooting
Fault Analysis
1.
10.1.1.33 is the largest IP address in the VPN instance to which the two PEs are bound,
and the following command is run to configure OSPF multi-instance:
<PE1> ospf 4 vpn-instance www
PE1 and PE2 select 10.1.1.33 as their router ID.

2.
On CE1, the router ID of PE1 is 10.1.1.33; on CE2, the router ID of PE2 is also 10.1.1.33.
3.
Debugging information on the CEs shows that a device with the router ID 10.1.1.33 sends
LSAs every five seconds and the sequence numbers of LSAs are incremental and unstable..
4.
The CEs receive LSAs sent by two devices with the same router ID. This causes the OSPF
default routes in the routing tables of the CEs constantly change. When the default route
of CE1 is learned by CE2 and the default route of CE2 is learned by CE1, a routing loop
occurs. As a result, routes are unreachable and packet loss occurs.
Procedure
Step 1 Run the ospf 4 router-id 10.2.2.9 vpn-instance www command on PE1 to specify the router
ID of the OSPF multi-instance as the unique address of PE1, and run the ospf 4 router-id
10.2.2.10 vpn-instance www command on PE2 to specify the router ID of the OSPF multiinstance as the unique address of PE2.
[PE1] ospf 4 router-id 10.2.2.9 vpn-instance www
[PE2] ospf 4 router-id 10.2.2.10 vpn-instance www
Step 2 Restart the OSPF process associated with the VPN instance on PE1, and then perform the same
operation on PE2. Services are restored after both OSPF processes restart.
----End
Summary
Specify the router ID of OSPF multi-instance as the unique addresses of the PEs.
7.5 BGP Troubleshooting

7.5.1 The BGP Peer Relationship Fails to Be Established
Common Causes
The BGP peer relationship fails to be established if the BGP peer relationship cannot enter the
Established state.
l
BGP packets fail to be forwarded.
An ACL is configured to filter packets with the destination port TCP port 179.
The peer router ID conflicts with the local router ID.
Issue 02 (2012-03-30)

205

Troubleshooting
The peer AS number is incorrect.
Loopback interfaces are used to establish the BGP peer relationship, but the peer connectinterface command is not configured.
Loopback interfaces are used to establish the EBGP peer relationship, but the peer ebgpmax-hop command is not configured.
The configurations of the peer valid-ttl-hops command are incorrect.
The number of routes sent by the peer exceeds the upper limit that is specified by the peer
route-limit command.
The peer ignore command is configured on the peer.
The address families of devices on both ends are inconsistent.
The BGP peer relationship fails to be established after the BGP protocol is configured.
Issue 02 (2012-03-30)

206

Troubleshooting
Figure 7-14 Troubleshooting flowchart for the failure to establish the BGP peer relationship
The BGP peer relationship fails to
be established
Can the ping operation

succeed?
No
Check the routes

used to establish
the BGP peer
relationship
Is fault rectified?
Yes
No
Yes
Is there an
ACL configured whose
destination port is The
TCP port 179?
Yes
Delete the
configuration
No
No
Does the peer

router ID conflict with the loca
l router ID?
Yes
Change the two

router IDs to
different values
Yes
Change the AS
number of the
remote peer to be
correct
Is fault rectified?
Yes
Is fault rectified?
No
No
Does BGP
configurations affect the
establishment of the BGP peer
relationship?
Yes
No
No
Whether the
displayed peer AS number is
configured correctly?
Yes
Is fault rectified?
Yes
Yes
Modify the BGP
configurations
No
Is fault rectified?
No
End
NOTE
Issue 02 (2012-03-30)

207

Troubleshooting
Procedure
Step 1 Run the ping command to check whether BGP peers can successfully ping each other.
l
If BGP peers can successfully ping each other, there are available routes between BGP
peers and link transmission is normal. In this case, go to Step 2.
NOTE
Run the ping -a source-ip-address -s packetsize host command to detect the connectivity of devices
on both ends. Because the source address is specified in this command, it is possible to check whether
the two devices have available routes to each other. Check whether large Ping packets can be normally
transmitted over the link by specifying the size of the Ping packet.
If the ping operation fails, check whether the two devices have routes to each other in
routing table of each device.
If there are no routes to the peer, check the associated routing protocol configurations.
For details, see the section The Ping Operation Fails.
If there are routes to the peer, contact Huawei technical support personnel.
Step 2 Check that no ACL is configured to filter the packets with the destination port TCP port 179.
Run the display acl all command on the two devices to check whether an ACL is configured to
filter the packets with the destination port TCP port 179.
<Huawei> display acl all
Total nonempty ACL number is 1
Advanced ACL 3001, 2 rules
Acl's step is 5
rule 5 deny tcp source-port eq bgp
rule 10 deny tcp destination-port eq bgp
If an ACL is configured to filter the packets with the destination port TCP port 179, run
the undo rule rule-id destination-port command and the undo rule rule-id source-port
command in the Advanced ACL view to delete the configuration.
If no ACL is configured to filter the packets with the destination port TCP port 179, go to
Step 3.
Step 3 Check that the peer router ID does not conflict with the local router ID.
View information about BGP peers to check whether the peer and local router IDs conflict. For
example, if the IPv4 unicast peer relationship fails to be established, run the display bgp peer
command to check whether the peer router ID conflicts with the local router ID. In the following
example command output, the local router ID is 223.5.0.109.
<Huawei> display bgp peer
BGP local router ID : 223.5.0.109
Local AS number : 41976
Total number of peers : 12
Peer
PrefRcv
8.9.0.8
10000
9.10.0.10
Peers in established state : 4
AS
MsgRcvd
MsgSent
100
1601
1443
200
1565
OutQ
1799
Up/Down
State
0 23:21:56 Established
9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, run the display bgp vpnv4 all peer command.
Issue 02 (2012-03-30)

208

Troubleshooting
If the peer router ID conflicts with the local router ID, run the router id command in the
BGP view to change the two router IDs to different values. Generally, a loopback interface
address is used as the local router ID.
If the peer router ID does not conflict with the local router ID, go to Step 4.
Step 4 Check that the peer AS number is configured correctly.

Run the display bgp peer command on each device to check whether the displayed peer AS
number is the same as the remote AS number.
<Huawei> display bgp peer
Total number of peers : 12
Peer
PrefRcv
8.9.0.8
10000
9.10.0.10
Peers in established state : 4
AS
MsgRcvd
MsgSent
100
1601
1443
200
1565
OutQ
1799
Up/Down
State
9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, you can run the display bgp vpnv4 all peer command.
If the peer AS number is incorrect configured, change it to be the same as the remote AS
number.
If the peer AS number is configured correctly, go to Step 5.
Step 5 Check whether BGP configurations affect the establishment of the BGP peer relationship.
Run the display current-configuration configuration bgp command to check BGP
configurations.
Item
Description
peer connect-interface interface-type

interface-number
If two devices use loopback interfaces to establish

the BGP peer relationship, run the peer connectinterface command to specify the associated
loopback interface as the source interface that
sends BGP packets.
peer ebgp-max-hop hop-count
When two directly connected devices use loopback

interfaces to establish the EBGP peer relationship
or two indirectly connected devices establish the
EBGP peer relationship, run the peer ebgp-maxhop command and specify the maximum number
of hops between the two devices.
l When two directly connected devices use
loopback interfaces to establish the EBGP peer
relationship, the hop count can be any number
greater than 1.
l When two indirectly connected devices
establish the EBGP peer relationship, specify
the number of hops based on the actual
situation.
Issue 02 (2012-03-30)

209

Troubleshooting
Item
Description
peer valid-ttl-hops hops
If the peer valid-ttl-hops hops command is

configured, check whether the value of hops is
correct. The valid TTL range of the detected packet
is [255 - hops + 1, 255]. hops specifies the number
of hops between devices on both ends. The number
of hops between two directly connected devices is
1.
NOTE
The peer valid-ttl-hops command must be configured
on devices on both ends.
peer route-limit limit
If the peer route-limit limit command is

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

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

devices on both ends match. For example, in order
to establish a BGP VPNv4 peer relationship, the
peer enable command must be configured in the
BGP-VPNv4 address families of both devices. If
the peer enable command is configured on only
one device, the BGP peer relationship on the other
device is displayed as No neg.
----End

Relevant Alarms
BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition
Issue 02 (2012-03-30)

210

Troubleshooting
Relevant Logs
BGP/3/STATE_CHG_UPDOWN
BGP/3/WRONG_ROUTERID
BGP/3/WRONG_AS
7.5.2 BGP Public Network Traffic Is Interrupted

Common Causes
This troubleshooting case describes how to clear the fault that traffic to be transmitted through
BGP public network routes is interrupted when the BGP peer relationship is normal.
l
Routes are inactive because the next hops are unreachable.
Routes fail to be advertised or received because routing policies are incorrectly configured.
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.
Issue 02 (2012-03-30)

211

Troubleshooting
Figure 7-15 Troubleshooting flowchart for interruption of BGP public network traffic
The BGP public network
traffic is interrupted
Is the next hop of the

route reachable?
No
Ensure that the next

hop is reachable
Yes
Is faulty rectified?
Yes
No
Is the routing policy

No
Correctly configure the

routing policy
Yes
No
Yes
Does the
number of routes exceed
the upper limit?
Yes
Reduce the number of

routes
Yes
No
No
End
NOTE
Procedure
Step 1 Verify that the next hops for the routes are reachable.
Run the display bgp routing-table network { mask | mask-length } command on the device that
sends routes (that is, the local device) to check whether the target route is active and whether it
has been sent to the peer. network specifies the prefix of the target route.
Assume that the target route is a route to 13.0.0.0/8. The following command output shows that
this route is valid and has been selected and sent to the peer at 3.3.3.3; the original next hop and
iterated next hop of this route are 1.1.1.1 and 172.1.1.1 respectively.
<Huawei> display bgp routing-table 13.0.0.0 8
Issue 02 (2012-03-30)

212

Troubleshooting
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: GigabitEthernet1/0/0
Original nexthop: 1.1.1.1
Qos information : 0x0
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best,
select, active, pre 255
Aggregator: AS 100, Aggregator ID 121.1.1.1
Advertised to such 1 peers:
3.3.3.3
If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If there is no route to the original next hop, the BGP route is not advertised
because the next hop of the BGP route is unreachable. Then, find out why there is no route
to the original next hop (this fault is generally associated with IGP or static routes).
If the target route is active and has been selected but there is no information indicating that
this route has been sent to the peer, go to Step 2 to check the outbound policy applied to
the local device.
Run the display bgp routing-table network { mask | mask-length } command on the peer to
check whether it has received the target route.
l
If the peer has received the target route, perform Step 1 again to check whether the next
hop of the route is reachable and whether this route has been selected.
If the peer has not received the target route, go to Step 2 to check the inbound policy applied
to the peer.
Step 2 Check that routing policies are configured correctly.

Run the display current-configuration configuration bgp command on the local device and
the peer to check whether inbound and outbound policies are configured.
<Huawei> display current-configuration configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 100
#
ipv4-family unicast
undo synchronization
filter-policy ip-prefix aaa import
filter-policy ip-prefix aaa export
peer 1.1.1.1 enable
peer 1.1.1.1 filter-policy acl-name acl-name import
peer 1.1.1.1 filter-policy acl-name acl-name export
peer 1.1.1.1 as-path-filter 1 import
peer 1.1.1.1 as-path-filter 1 export
peer 1.1.1.1 ip-prefix prefix-name import
peer 1.1.1.1 ip-prefix prefix-name export
peer 1.1.1.1 route-policy policy-name import
peer 1.1.1.1 route-policy policy-name export
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
return
If inbound and outbound policies are configured on the two devices, check whether the
target route is filtered by these policies. For detailed configurations of a routing policy, see
the Huawei AR1200 Series Enterprise Routers Configuration Guide - IP Routing.
If inbound and outbound policies are not configured on the two devices, go to Step 3.
Issue 02 (2012-03-30)

213

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

Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Relevant Logs
BGP/3/ROUTPRIX_EXCEED
7.5.3 BGP Private Network Traffic Is Interrupted

Issue 02 (2012-03-30)

214

Troubleshooting
Common Causes
This troubleshooting case describes how to clear the fault that BGP private network routes is
interrupted when the BGP peer relationship is normal.
l
Routes are inactive because the next hops are unreachable.
Routes fail to be advertised or received because routing policies are incorrectly configured.
Private network routes fail to be advertised because the number of labels exceeds the upper
limit.
Routes are inactive because they fail to be iterated to a tunnel.
Routes fail to be added to the VPN routing table because the configured import route-target
(RT) and export RT do not match.
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.
Issue 02 (2012-03-30)

215

Troubleshooting
Figure 7-16 Troubleshooting flowchart for interruption of BGP private network traffic
The BGP private network
traffic is interrupted
Is the next hop of the

VPN route reachable?
No
Ensure that the next

hop is reachable
No
Correctly configure the

routing policy
Yes
Does the
Number of labels exceed the
upper limit?
Yes
No
Yes
Is the routing policy is

Is fault rectified?
Yes
Is fault rectified?
No
Yes

routes or configure the
device to assign a label
to each instance
Yes
Is fault rectified?
No
No
Is the tunnel iterated

successfully?
No
Ensure that the tunnel

exists
Is fault rectified?
Yes
No
Yes
Does the export RT

match the import RT?
No
Ensure that they match
Is fault rectified?
Yes
No
Yes
Does the number
of routes exceed the upper
limit?
Yes

routes or increase the
upper limit of routes
No
Yes
Is fault rectified?
No
End
Issue 02 (2012-03-30)

216

Troubleshooting
NOTE
Procedure
Step 1 Check that next hops of routes are reachable.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address
[ mask | mask-length ] command on the PE that sends routes (that is, the local PE) to check
whether the target route exists. ipv4-address specifies the prefix of the target route.
l If the target route does not exist, check whether the route of a CE is advertised to the local
PE.
l If the target route exists, check whether it is active. The following is an example:
Assume that the target route is a route to 1.1.1.1/32. The following command output shows that
this route is active and selected. The original next hop and iterated next hop of this route are
3.3.3.3 and 20.1.1.2 respectively.
<Huawei> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
Paths:
1 available, 1 best, 1 select
From: 20.1.1.1 (1.1.1.1)
Route Duration: 00h00m03s
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, active, pre 255
Not advertised to any peer yet
If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If there is no route to the original next hop, the BGP route is not advertised
because the next hop of the BGP route is unreachable. In this case, find out why there is
no route to the original next hop (this fault is generally associated with IGP or static routes).
If the target route is active and selected but there is no information indicating that this route
is sent to the remote PE, go to Step 2 to check the outbound policy applied to the local PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the
remote PE to check whether it has received the target route.
l
If the remote PE has received the target route, perform Step 1 again to check whether the
next hop of the route is reachable and whether this route is selected.
If the remote PE has not received the target route, go to Step 2 to check the inbound policy
of the remote PE.
Step 2 Check that routing policies are configured correctly.

Run the display current-configuration configuration bgp command on the local PE and
remote PE to check whether inbound and outbound policies are configured.
NOTE
Only focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address family in this
troubleshooting case because private network traffic is interrupted.
Issue 02 (2012-03-30)

217

Troubleshooting
<Huawei> display current-configuration configuration bgp

#
bgp 100
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpna
#
return
If inbound and outbound policies are configured on the two devices, check whether the
target route fails to be transmitted because it is filtered by these policies. For detailed
configurations of a routing policy, see the Huawei AR1200 Series Configuration Guide IP Routing.
If inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check that routes can be iterated to a tunnel.

Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on
the remote PE to check whether the target route can be iterated to a tunnel.
Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface field
and Relay token field in the command output are not empty, it indicates that this route can be
iterated to a tunnel.
<Huawei> dis bgp vpnv4 all routing-table 50.1.1.2
Total routes of Route Distinguisher(1:2): 1
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: GigabitEthernet1/0/0
Relay token: 0x1002
Ext-Community:RT <1 : 1>
best, select, pre 255
Issue 02 (2012-03-30)

218

Troubleshooting

Total routes of vpn-instance vpna: 1
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: GigabitEthernet1/0/0
Relay token: 0x1002
best, select, active, pre 255
If the target route fails to be iterated to a tunnel, run the display ip vpn-instance
verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field is
not displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy is
configured for the VPN instance.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down to
locate the fault and ensure that the tunnel goes Up.
If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether routes fail to be added to the VPN routing table because the configured import
RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the local PE
and remote PE to check whether routes fail to be added to the VPN routing table of the remote
PE after being sent to the remote PE because the export RT of the local VPN instance does not
match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.
<Huawei> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
route-distinguisher 1:1
apply-label per-instance
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
ip vpn-instance vpnb
route-distinguisher 1:2
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
return
l If the export RT of the local VPN instance does not match the import RT of the remote VPN
instance, configure matching VPN-targets in the VPN instance.
l If the export RT of the local VPN instance matches the import RT of the remote VPN instance,
go to Step 5.
Step 5 Check that the number of labels is below the upper limit.
Check whether MPLS is enabled on the local PE. Run the display bgp vpnv4 all routingtable ipv4-address [ mask | mask-length ] command to check whether the target route is assigned
a VPN label.
If there is no Label information field in the command output, the number of labels may have
reached the upper limit. As a result, the target route is not assigned a label and is not advertised
to the peer.
Issue 02 (2012-03-30)

219

Troubleshooting
<Huawei> display bgp vpnv4 all routing-table 100.1.1.1

Total routes of Route Distinguisher(1:1): 1
Imported route.
Label information (Received/Applied): NULL/13312
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: NULL0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
255
Advertised to such 1 peers:
1.1.1.1
Total routes of vpn-instance vpna: 1
Imported route.
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: NULL0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
60
l If the number of labels has reached the upper limit, run the apply-label per-instance
command in the VPN instance view to configure the device to assign one label to each
instance to reduce label usage. Route summarization can also be configured to reduce the
number of routes.
l If the number of labels is below the upper limit, go to Step 6.
Step 6 Check that the number of routes is below the upper limit.
If the peer is added to a peer group, run the display current-configuration configuration bgp
| include peer destination-address command or the display current-configuration
configuration bgp | include peer group-name command on the remote PE to check whether
the upper limit on the number of routes to be received is configured on the remote PE.
For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded
after the remote PE receives five routes from the local PE at 1.1.1.1.
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations about the upper limit in the
command output.
peer 1.1.1.1 enable
In this case, run the display current-configuration configuration bgp | include peer groupname command to check configuration of this peer group.
Issue 02 (2012-03-30)

220

Troubleshooting
<Huawei> display current-configuration configuration bgp | include peer IBGP

peer IBGP route-limit 5 alert-only
peer IBGP enable
If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, the target route
is dropped because the number of routes received has exceeded the upper limit. In this case,
increase the upper limit.
NOTE
Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peer
relationship. Therefore, reducing the number of sent routes by configuring route summarization on the
local device is recommended.
----End

Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Relevant Logs
BGP/3/ROUTPRIX_EXCEED
7.5.4 Trouble Cases

Traffic Traverses the Egress Device of an AS Because BGP Delivers Default Routes
with Different MEDs
Fault Symptom
In Figure 7-17, EBGP peer relationships are established between devices in AS 100 and AS
200. IBGP peer relationships are established between devices inside each AS. After Router A
and Router B advertise BGP default routes, detailed information about BGP default routes on
Router C shows that outgoing traffic from AS 200 is directed to Router D. That is, the next hop
of BGP default routes is Router D. Consequently, outgoing traffic from AS 200 traverses
Router C.
Issue 02 (2012-03-30)

221

Troubleshooting
Figure 7-17 Outgoing traffic traversing the egress device of an AS
AS100
RouterA
RouterB
0.0.0.0 is delivered
(MED 88)
0.0.0.0 is delivered
(MED 80)
RouterC
RouterD
AS200
Default route
Outgoing traffic
Fault Analysis
Run the display bgp routing-table 0.0.0.0 command on Router C to view detailed information
about BGP default routes. The command output will show that different MEDs are set for
Router A and Router B. As a result, outgoing traffic from AS 200 traverses Router C.
Procedure
Step 1 Run the system-view command on Router B or Router A to enter the system view.
Step 2 Run the bgp as-number command to enter the BGP view.
Step 3 Run the ipv4-family unicast command to enter the BGP-IPv4 unicast address family view.
Step 4 Run the default med med command to modify the default MED of the BGP routes, and make
sure the MED of BGP routes on Router A matches the MED of BGP routes on Router B.
After performing the preceding operations, run the display bgp routing-table 0.0.0.0 command
on Router C to view detailed information about BGP default routes. The command output will
show that outgoing traffic from AS 200 is transmitted through Router C. This indicates that the
fault has been cleared.
----End
Issue 02 (2012-03-30)

222

Troubleshooting
Summary
When there are multiple egress devices between two ASs, set the same MED for the advertised
default routes. BGP prefers routes learned from EBGP peers because the delivered default routes
have the same route attributes, such as the local-preference and MED.
Routing Policies Delivered by a PE Do Not Take Effect Because There Are Multiple
Routing Policies with the Same Name
Fault Symptom
As shown in Figure 7-18, a PE is connected to VPN 1 and is connected to Router B in the
upstream direction. VPN 1 routes of the PE need to be advertised to the MAN. The PE controls
which routes to be advertised to Router B using routing policies. According to the configured
routing policies, Router B needs to learn only the VPN 1 summary route advertised by the PE
instead of specific routes. After the routing policies are configured, Router B learns both the
VPN 1 summary route and specific routes.
Figure 7-18 Routing policies delivered by a PE failing to take effect
PE
RouterB
VPN1
MAN
VPN
RouterA
RouterC
NOTE
The AR functions as the PE.
Fault Analysis
1.
Run the display current-configuration command on the PE to view the routing policy
configuration. The command output shows that no fault occurs.
2.
According to the fault symptom, it is possible that Router B learns the specific VPN 1 routes
advertised by the PE because the delivered routing policies do not take effect.
3.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer peeraddress { advertised-routes | received-routes [ active ] } command on the PE to view the
routes of other VPNs to which the PE is connected. Routes learned on Router B are summary
routes of these VPNs. Therefore, it can be concluded that the routing policies for VPN 1
are incorrect.
4.
Check the configuration file of the PE. The result shows that there are three routing policies
with the same name for the PE to advertise the routes of VPN 1. The ip-prefix NGN-A
referenced by the first routing policy is defined, and this routing policy is valid. The ip-
Issue 02 (2012-03-30)

223

Troubleshooting
prefix NGN-A1 and ip-prefix NGN-A2 referenced by the other two routing policies are
not defined, and therefore the two routing policies are invalid. The following is the detailed
configuration:
ipv4-family vpn-instance CDMA-NGN
peer 10.247.0.1 route-policy PE_NGN_OUT_MASTER export
route-policy PE_NGN_OUT_MASTER permit node 10
if-match ip-prefix NGN-A
if-match ip-prefix NGN-A1
if-match ip-prefix NGN-A2
ip ip-prefix NGN-A index 10 permit 10.247.0.0 21
The rules for referencing routing policies dictate that the relationship between the three
routing policies with the same name must be OR. That is, VPN 1 routes can be correctly
advertised as long as one of the routing policies with the same name is valid. However, the
redundant invalid routing policies with the same name can still cause VPN 1 routes to be
incorrectly advertised.
5.
After deleting the other two invalid routing policies, Router B learns only one summary
route, namely, the route with a prefix that is in the IP prefix list NGN-A. The fault is cleared.
Procedure
Step 1 Run the system-view command on the PE to enter the system view.
Step 2 Run the undo route-policy route-policy-name [ node node ] command to delete the two
redundant routing policies.
Step 3 Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer peeraddress advertised-routes command to view the routes of VPN 1 to which the PE is connected.
Only one summary route is found. The fault is cleared.
----End
Summary
According to the rules for referencing routing policies, the relationship between routing policies
with the same name must be OR. However, redundant routing policies still need to be deleted
to prevent routes from being incorrectly advertised.
A PE Fails to Establish the Public Network LSP Because the Path of IGP Routes Is
Incorrect
Fault Symptom
As shown in Figure 7-19, PE1 can receive VPNv4 routes reflected from RR1, but these routes
cannot be installed in the routing table of the VPN instance. That is, there is associated routing
information in the BGP VPNv4 routing table but not in the routing table of the IPv4 VPN instance
on PE1.
Issue 02 (2012-03-30)

224

Troubleshooting
Figure 7-19 Failure to establish a public network LSP on a PE
OSPF Area
P
(RR1)
P
(RR2)
PE1
PE2
Fault Analysis
1.
Run the display bgp vpnv4 all routing-table command on PE1 to view the BGP routing
table. The routing table contains the routes learned from the peer PE. This indicates that
the BGP neighbor relationship is normal and that VPN labels are assigned properly.
2.
Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose

command on PE1 to view detailed information about VPN routes. The Interface field is
displayed as NULL0. This indicates that VPN routes do not have a correct iterated outbound
interface on the public network. That is, these VPN routes are invalid and therefore are not
included in the routing table of the VPN instance.
3.
Run the display mpls ldp session command on PE1 to view the LDP session on the public
network. The LDP session works normally. This indicates that an LDP session can be
established between the Ps.
4.
Run the display mpls ldp lsp destination-address mask-length command on PE1 to view
the assignment of public network labels. The In/OutLabel field is displayed as Null and
the Next-Hop field is empty. This indicates that LDP sessions can be established between
the PEs and the Ps, but labels cannot be assigned.
5.
Run the display ip routing-table ip-address command on PE1 to view IGP routes to the
loopback interface address of the P. The 32-bit loopback interface address is learned from
PE2 instead of the P. Therefore, the assignment of public network labels cannot be triggered
although the LDP LSP can be established. In addition, no LDP is configured between the
two PEs. (If LDP is configured between the two PEs, public network labels can be assigned
and routes of the VPN instance can be generated.)
6.
Run the display current configuration and display ip routing-table ip-address

commands to view IGP configurations and IGP routes of devices. OSPF is not correctly
configured on the interface that connects RR1 to PE1.
Procedure
Step 1 Re-configure OSPF on the interface that connects RR1 to PE1 to ensure that the path of IGP
routes is correct. Then, routing information can be learned from the interfaces that connect the
PEs to the Ps.
Step 2 Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose
command on PE1 to view the assignment of MPLS labels and the iteration of the outbound
Issue 02 (2012-03-30)

225

Troubleshooting
interface of VPN routes. MPLS labels are assigned properly and the outbound interface of VPN
routes is iterated properly. The Interface field shows a correct iterated outbound interface on the
public network.
Step 3 Run the display mpls ldp lsp destination-address mask-length command on PE1 to check the
assignment of public network labels. Public network labels are assigned properly.
Step 4 Run the display ip routing-table vpn-instance vpn-instance-name command on PE1 to check
the routing table of the VPN instance. The routing table of the VPN instance contains the
associated VPN routes. This indicates that the fault is cleared.
----End
Summary
A public network LSP must be established to install VPN routes in the routing table of a VPN
instance. If public network labels fail to be assigned and LSPs cannot be established, check
whether the path of IGP routes can trigger label assignment and whether IGP routes are correct.
Next Hop of the Incoming Traffic Changes After a Master/Slave Switchover of the
Attached Non-Huawei Devices
Fault Symptom
As shown in Figure 7-20, VRRP is configured on Router A and Router B. Router A and
Router B are connected through a heartbeat link. The other devices are all non-Huawei devices.
Router C and Router D, which are attached to Router A and Router B, respectively, are loadbalancing devices and provide redundancy for each other. A routing policy is configured on the
interface that connects Router A to Router C to enable incoming traffic to be forwarded by the
specified interface and specifies Router G as the next hop.
After the master device Router C becomes faulty, CPU usage on Router C reaches 100%.
Because redundancy backup and automatic master/slave switchover are configured, incoming
traffic is switched to Router D. However, the next hop of the incoming traffic on Router A is
Router E. Therefore, the incoming traffic is not forwarded to the next hop specified by the
configured routing policy.
Issue 02 (2012-03-30)

226

Troubleshooting
Figure 7-20 Change in the next hop of incoming traffic
RouterE
RouterF
RouterG
RouterH
RouterA
RouterB
RouterC
RouterD
Data path before master/slave
switchover of attached devices
Data path after master/slave
switchover of attached devices
Fault Analysis
After a master/slave switchover of the non-Huawei devices, the path of incoming traffic is
Router D->Router B->heartbeat link->Router A. Because route redirection is not configured on
the interface of the heartbeat link, the next hop of the incoming traffic is not Router G as specified
but Router E. This indicates that the configured routing policy becomes invalid.
To clear the fault, configure a routing policy on the interface of the heartbeat link between
Router A and Router B to enable incoming traffic to be forwarded along the specified path,
which is the same as the path before the master/slave switchover. That is, configure route
redirection on the interface of the heartbeat link to forcibly change the next hop of the incoming
traffic to Router G.
Procedure
Step 1 Run the system-view command on Router A to enter the system view.
Step 2 Configure an ACL rule.
1.
Run the acl number acl-number command to create an ACL and enter the ACL view.
2.
Run the rule command to configure an ACL rule.
3.
Run the quit command to quit the ACL view.
Step 3 Match the ACL rule for route redirection.

1.
Run the traffic classifier classifier-name operator or command to define a traffic classifier
and enter the traffic classifier view.
2.
Run the if-match acl acl-number command to match the ACL.
3.
Run the quit command to quit the traffic classifier view.
Issue 02 (2012-03-30)

227

Troubleshooting
4.
Run the traffic behavior behavior-name command to define a traffic behavior and enter
the traffic behavior view.
5.
Run the redirect ip-nexthop ip-address command to perform route redirection, specifying
the next-hop address as the address of the interface that connects Router G to Router A.
6.
Run the quit command to quit the traffic behavior view.
7.
Run the traffic policy policy-name command to define a traffic policy and enter the traffic
policy view.
8.
Run the classifier classifier-name behavior behavior-name command to specify a traffic

behavior for the traffic classifier in the traffic policy.
Step 4 Apply the traffic policy to the interface of the heartbeat link on Router A.
1.
Run the interface eth-trunk trunk-id command to enter the view of the interface of the
heartbeat link.
2.
Run the traffic-policy policy-name inbound command to apply the traffic policy.
Step 5 Run the display ip routing-table command to check incoming traffic of Router A. The next
hop of the incoming traffic is Router G. This indicates that the fault is cleared.
----End
Summary
After a master/slave switchover is performed on network devices, pay attention to the impact of
the switchover on network traffic.
If incoming traffic fails to be forwarded along the path specified by the configured routing policy,
configure route redirection to specify the next hop of a link to solve the problem.
The BGP Peer Relationship Goes Down Because of Route Iteration

Fault Symptom
There are two links between Router A (a Huawei device) and Router B (a non-Huawei device).
One link is established through GigabitEthernet 1/0/0 interfaces and the other link is established
through GigabitEthernet 2/0/0 interfaces. Devices on both ends of a link establish the BGP peer
relationship through loopback interfaces. After the GigabitEthernet 1/0/0 interface on Router A
goes Down, the BGP peer relationship between Router A and Router B goes Down and remains
in the OpenSent state. Router A, however, can successfully ping the address of the loopback
interface on Router B.
Figure 7-21 Route iteration causes the BGP peer relationship to go Down
RouterA GE1/0/0
192.168.0.2/30
GE2/0/0
192.168.1.2/30
Loopback0
20.0.0.1
Issue 02 (2012-03-30)
GE1/0/0 RouterB
192.168.0.1/30
GE2/0/0
192.168.1.1/30
Loopback0
10.0.0.1

228

Troubleshooting
Fault Analysis
1.
After GigabitEthernet 1/0/0 on Router A goes Down, run the display ip routing-table ipaddress command on Router A to view the equal-cost routes to the public network. The
command output shows that there are two equal-cost routes with the same next-hop
addresses, 10.0.0.1. The outbound interfaces of the equal-cost routes are GigabitEthernet
2/0/0 and Null0. Before GigabitEthernet 1/0/0 on Router A goes Down, the outbound
interfaces of the two equal-cost routes are GigabitEthernet 2/0/0 and GigabitEthernet 1/0/0,
and have the same next hop address, 10.0.0.1.
Run the display bgp peer command on Router A to check the BGP peer relationship. The
BGP peer with the address 10.0.0.1 is in the OpenSent state.
2.
Route iteration may cause outbound interfaces of equal-cost routes to change. If no route
iteration occurs, after GigabitEthernet 1/0/0 goes Down, only one of the two equal-cost
routes exists, that is, the route with the outbound interface GigabitEthernet 2/0/0.
3.
Check the configuration of Router A and analyze why the outbound interface is iterated to
Null0. The configuration shows that the static routes with the 32-bit mask to the address
(10.0.0.1) of the loopback interface on Router B are configured on Router A.
ip route-static 10.0.0.1 255.255.255.255 192.168.1.1
ip route-static 10.0.0.1 255.255.255.255 192.168.0.1
After GigabitEthernet 1/0/0 on Router A goes Down, the preceding static route
configurations cause Router A to iterate routes. Check whether there is a route to
192.168.0.1 in the routing table. The configuration file contains the following static route
configuration:
ip route-static 192.168.0.0 255.255.255.0 NULL0 preference 255
Therefore, the outbound interface of one of the two upstream equal-cost routes becomes
Null0.
4.
Analyze why the BGP peer relationship goes Down after one outbound interface becomes
Null0. After GigabitEthernet 1/0/0 goes Down, two upstream routes of Router A are as
follows:
Destination/Mask
10.0.0.1/32
Proto
BGP
BGP
Pre
100
100
Cost
0
0
NextHop
10.0.0.1
10.0.0.1
Interface
NUll0
In this case, Router A can successfully ping the address (10.0.0.1) of the loopback interface
on Router B. In normal situations, the BGP peer relationship remains Up. Because there
are two links between Router A and Router B, hash calculation is triggered when packets
are exchanged between the two devices. If the ping command is run without specifying the
source address, the outbound interface calculated by the hash algorithm is
GigabitEthernet 2/0/0, in which case the ping succeeds. If the ping command is run with
loopback interface address 20.0.0.1 specified as the source address on Router A, the
outbound interface calculated by the hash algorithm is GigabitEthernet 1/0/0, in which case
the ping fails. Loopback interface addresses are used to establish the BGP peer relationship
between Router A and Router B. GigabitEthernet 1/0/0 is now iterated to the outbound
interface of Null0. Therefore, the BGP peer relationship between Router A and Router B
goes Down.
To clear the fault, disable route iteration on Router A.
Procedure
Issue 02 (2012-03-30)

229

Troubleshooting
After GigabitEthernet 1/0/0 on Router A goes Down, the static route with the outbound interface
GigabitEthernet 1/0/0 becomes unreachable and thus is deleted from the routing table. Then, all
packets destined for Router B are sent through only GigabitEthernet 2/0/0.
Step 2 Run the undo ip route-static 10.0.0.1 255.255.255.255 192.168.1.1 and undo ip route-static
10.0.0.1 255.255.255.255 192.168.0.1 commands to delete the original static route
configurations.
Step 3 Run the ip route-static 10.0.0.1 255.255.255.255 gigabitethernet 2/0/0 192.168.1.1 and ip
route-static 10.0.0.1 255.255.255.255 gigabitethernet 1/0/0 192.168.0.1 commands to
configure static routes with next hops and outbound interfaces.
Step 4 Run the display bgp peer command. The BGP peer with the address 10.0.0.1 is in the Established
state. This indicates that the BGP peer relationship is normal. The fault is cleared.
----End
Summary
Route iteration is enabled by default. Ensure that route iteration will not cause exceptions on a
network.
Static Routes Do Not Take Effect Because of the Relay Depth

Fault Symptom
As shown in Figure 7-22, Router A and Router B are connected through two GE links and
establish an EBGP peer relationship. The following two static routes are configured on Router
A:
ip route-static 2.2.2.2 255.255.255.255 gigabitethernet1/0/0 10.1.1.2
ip route-static 2.2.2.2 255.255.255.255 10.1.2.2
The routing table shows that routes to Router B have only one outbound interface
GigabitEthernet 1/0/0.
Figure 7-22 Static routes failing to take effect
Loppback0
1.1.1.1/32
RouterA
Loopback0
2.2.2.2/32
GE1/0/0
10.1.1.1/24
GE1/0/0
10.1.1.2/24
GE2/0/0
10.1.2.1/24
GE2/0/0
RouterB
10.1.2.2/24
Fault Analysis
Because the static route configured with the ip route-static 2.2.2.2 255.255.255.255
gigabitethernet 1/0/0 10.1.1.2 command is specified with an outbound interface, route relay is
not required and the relay depth is 0. Because no outbound interface is specified for the other
Issue 02 (2012-03-30)

230

Troubleshooting
static route configured with the ip route-static 2.2.2.2 255.255.255.255 10.1.2.2 command,
route relay needs to be performed once and the relay depth is 1.
BGP selects the static route with the smallest relay depth. Therefore, BGP selects the static route
with the relay depth 0, and the outbound interface of the static route configured with the ip routestatic 2.2.2.2 255.255.255.255 10.1.2.2 command becomes GigabitEthernet 1/0/0.
Procedure
Step 2 Run the undo ip route-static2.2.2.2 255.255.255.255 10.1.2.2 command to delete the static
route.
Step 3 Run the ip route-static 2.2.2.2 255.255.255.255 gigabitethernet 2/0/0 10.1.2.2 command to
configure a static route with an outbound interface.
After the preceding operations, both static routes are selected when BGP selects static routes
with the smallest relay depth. Therefore, the two outbound interfaces GigabitEthernet 1/0/0 and
GigabitEthernet 2/0/0 are displayed when checking the routing table of Router A.
----End
Summary
Specify outbound interfaces for static routes when configuring them. This prevents route relay.
Summary Routes Advertised by EBGP Flap Frequently Because Routing Protocols

Are Configured with Improper Preferences
Fault Symptom
As shown in Figure 7-23, Router C and Router D are two egress devices on an enterprise network
and are connected to Router A and Router B on the MAN through EBGP. Route suppression is
configured on devices on the MAN to suppress EBGP routes from egress devices on the
enterprise network. On the enterprise network, Router C and Router D are connected to the
attached devices through IS-IS and IBGP peer relationships are established between them. Some
traffic traverses the egress devices on the enterprise network. Therefore, to prevent link faults
from causing routing loops, Router C and Router D establish an IBGP peer relationship using
interface addresses and advertise enterprise network routes to devices on the MAN through static
blackhole routes imported with the network command.
After a fault occurs on a board or a link, the IBGP peer relationship between Router C and
Router D alternates between Up and Down states frequently and therefore all enterprise network
services are interrupted.
Issue 02 (2012-03-30)

231

Troubleshooting
Figure 7-23 Summary routes advertised by EBGP peer flap frequently
MAN
RouterA
RouterB
RouterD
RouterC
RouterE
RouterF
RouterG
RouterH
Enterprise network
Fault Analysis
The possible causes are:
l
Associated routing policies, including local and remote routing policies, are changed
manually.
Routes (mainly advertised summary routes) are added and then deleted two consecutive
times.
Static and dynamic routing protocols are configured with improper preferences. As a result,
some BGP summary routes cannot be advertised through the blackhole route imported with
the network command.
Checking device logs shows that no associated routing policies have been changed manually
and no routes have been added and then deleted.
Egress devices on the enterprise network advertise routes through blackhole routes imported
with the network command. Therefore, route addition or deletion is not involved. Checking
summary routes shows that the lifetime of these routes is very long. This indicates that service
interruption is unlikely to occur.
On Router C and Router D, the preference of the BGP protocol is set to 20, and the preference
of static blackhole routes defaults to 60. Therefore, if both IBGP routes and static routes exist,
Issue 02 (2012-03-30)

232

Troubleshooting
IBGP routes are advertised as summary routes first. As a result, when the IBGP peer relationship
between Router C and Router D alternates Up and Down, the advertised summary routes flap,
causing enterprise network services to be interrupted.
To solve this problem, change the preferences of BGP routes and static routes so that IBGP
routes have a lower preference than static routes.
Procedure
Step 1 Run the system-view command on Router C to enter the system view.
Step 2 Run the bgp as-number to enter the BGP view.
Step 3 Run the preference preference command to set the preference for the BGP protocol to a value
greater than 60.
After performing the preceding operations, perform the same operations on Router D to change
the preference of the BGP protocol. In this manner, enterprise network service transmission
recovers.
----End
Summary
Theoretically, enterprise network routes, which are advertised through blackhole routes
imported with the network command, do not flap. In this case, however, devices on the enterprise
network do not advertise routes as required because routing protocols are configured with
improper preferences.
Issue 02 (2012-03-30)

233

Troubleshooting
8 Multicast
Multicast
About This Chapter

8.1 Layer 3 Multicast Troubleshooting
Issue 02 (2012-03-30)

234

Troubleshooting
8 Multicast
8.1 Layer 3 Multicast Troubleshooting

8.1.1 Multicast Traffic Is Interrupted
Common Causes
l
Route configurations are incorrect.
Interface status is incorrect.
PIM routing entries are not created.
Multicast forwarding entries are not created.
After the Layer 3 multicast is configured, multicast traffic cannot be transmitted to users.
l
Check that a route destined for the multicast source is available.
Check that the VLANs on the inbound and outbound interfaces of the multicast route
function properly.
Check that the PIM routing entries are created.
Check that the multicast forwarding entries are created.
Issue 02 (2012-03-30)

235

Troubleshooting
8 Multicast
Multicast traffic
Cannot be
transmitted
Route to
multicast source is
reachable?
No Configure a route to
the multicast source
Is fault
rectified?
Yes
No
Yes
Is interface in Up
state?
No
Rectify the interface

fault
Is fault
rectified?
Yes
No
Yes
PIM
information
table has been
generated?
No
Yes
Check whether
forwarding entries have
been generated and
record the phenomena
Seek technical
support
End
NOTE
Procedure
Step 1 Check that a route destined for the multicast source is available.
Run the display ip routing-table ip-address command to check whether the local routing table
contains a route destined for the multicast source.
NOTE
ip-address specifies the multicast source address.
If not, configure a route destined for the multicast source.
If yes, go to step 2.
Step 2 Check that the inbound and outbound interfaces of the multicast forwarding entry function
properly.
Issue 02 (2012-03-30)

236

Troubleshooting
8 Multicast
Run the display interface command to view interface status.

l
If the interfaces are abnormal, the multicast forwarding entry cannot be created. Rectify
the fault.
In the following information, the status of GigabitEthernet 2/0/0 is Up.
<Huawei>display interface gigabitethernet
2/0/0
GigabitEthernet2/0/0 current state : UP
Description:HUAWEI, AR Series, GigabitEthernet2/0/0 Interface
Switch Port,PVID : 200,The Maximum Frame Length is 1628
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0fc01-0005
: 2008-01-31 19:19:06
Port Mode: COMMON COPPER
Speed : 100, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi
: AUTO
Input peak rate 736 bits/sec,Record time: 2008-01-31 19:05:00
Output peak rate 1624 bits/sec,Record time: 2008-01-31 19:19:26
Unicast:
0, Multicast:
Broadcast:
0, Jumbo:
Discard:
0, Total Error:
CRC:
Jabbers:
Runts:
Alignments:
Ignoreds:
0,
0,
0,
0,
0,
Giants:
Throttles:
DropEvents:
Symbols:
Frames:

Unicast:
0, Multicast:
Broadcast:
11170, Jumbo:
Discard:
0, Total Error:
Collisions:
Late Collisions:
Buffers Purged:
0,
0,
0
ExcessiveCollisions:
Deferreds:
11177
0
0
0
0
0
0
0
183273
0
0
0
0
Input bandwidth utilization threshold : 100.00%

Output bandwidth utilization threshold: 100.00%
If the interface status is normal, go to step 3.
Step 3 Check that the PIM routing entries are created.

Run the display pim routing-table command to check whether PIM routing entries are created.
l
If not, contact Huawei technical support personnel.
Step 4 Check whether the multicast forwarding entries are created.

Run the display multicast forwarding-table command to check that the multicast forwarding
entries are created.
l
Issue 02 (2012-03-30)
If the fault persists, record the command output and contact Huawei technical support
personnel.
237

Troubleshooting
8 Multicast
l
Configuration files, log files, and alarm files of the devices
----End

Relevant Alarms
None.
Relevant Logs
None.
8.1.2 The PIM Neighbor Relationship Remains Down

Common Causes
This fault is commonly caused by one of the following causes:
l
The interface is physically Down or the link-layer protocol status of the interface is Down.
PIM is not enabled on the interface.
PIM configurations on the interface are incorrect.
After PIM network configuration is complete, the PIM neighbor relationship remains Down.
Issue 02 (2012-03-30)

238

Troubleshooting
8 Multicast
Figure 8-2 Troubleshooting flowchart: the PIM neighbor relationship remains Down
The PIM neighbor
relationship remains
Down
Is PIM enabled
on the interface?
No
Enable PIM on the interface
Is fault rectified?
Yes
No
Yes
Is the PIM status

Up on the interface?
No
Yes
Is the interface
physically Up?
No
Refer to the
troubleshooting of
interface Down
Yes
No
Yes
Is the link status Up

on the interface?
No
No
Are the PIM

configurations on the
interface correct?
No
Change the PIM

configurations on the
interface
Is fault rectified?
Yes
Refer to the
troubleshooting of
interface Down
Is fault rectified?
Is fault rectified?
Yes
Yes
No
Yes
End
NOTE
a record of the actions taken will exist to provide to Huawei technical support personnel.
Procedure
Step 1 Check that PIM is enabled on the interface.
Issue 02 (2012-03-30)

239

Troubleshooting
8 Multicast
Run the display current-configuration interface interface-type interface-number command to

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

If "Warning: Please enable multicast routing in the system view first" is prompted when
you enable PIM, first run the multicast routing-enable command in the system view to
enable the multicast function. Then, go on to enable PIM-SM or PIM-DM on the interface.
If PIM has been enabled on the interface, go to Step 2.
Step 2 Check that the PIM status of the interface is Up.

Run the display pim interface interface-type interface-number command to check whether the
PIM status of the interface is Up.
l
If the PIM status is Down, run the display interface interface-type interface-number
command to check whether the physical status and link status of the interface are both Up.
1.
If the physical status is not Up, make the physical status go Up.
2.
If the link status is not Up, make the link status go Up.
If the PIM status of the interface is Up, go to Step 3.
Step 3 Check that PIM configurations on the interface are correct.

This fault may be caused by the following PIM configurations:
l The IP addresses of directly-connected interfaces are on different network segments.
l PIM silent is configured on the interface.
l A PIM neighbor filtering policy is configured on the interface and the address of the PIM
neighbor is filtered out by the policy.
l If the interface is configured to deny Hello messages without Generation IDs, the interface
discards all the Hello messages received from PIM neighbors without any Generation IDs.
As a result, the PIM neighbor relationship cannot go Up. This case applies to the scenario in
which Huawei devices are intercommunicating with non-Huawei devices.
check whether any of the preceding PIM configurations exist on the interface.
l
If any of the preceding PIM configurations exist, correct it.
If the fault persists after the preceding operations are complete, go to Step 4.
----End

Relevant Alarms
None.
Relevant Logs
PIM/4/NBR_DOWN
Issue 02 (2012-03-30)

240

Troubleshooting
8 Multicast
8.1.3 The RPT on a PIM-SM Network Fails to Forward Data

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

241

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

to the RP available?
No
Rectify the faults on the

static RP or BSR RP
Is fault
rectified?
Yes
No
Rectify the fault of unicast
routes
Is fault
rectified?
Yes
No
Yes
No
Is fault
rectified?
Is the
interface that forwards
multicast data the
receiver's DR?
Yes
Is a multicast
boundary configured on the
interface?
Yes
Remove the configurations

of the multicast boundary
No
Is a source-policy
configured?
Is fault
rectified?
Yes
No
Remove the configurations
Yes
of the source-policy or
change the configurations
of the ACL
No
Is fault
rectified?
Yes
No
End
Do correct (*, G)
entries exist?
Yes
No
Issue 02 (2012-03-30)

242

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

increasing, go to Step 3.
Step 3 Check that PIM-SM is enabled on interfaces.

The following interfaces are easy to be ignored in enabling PIM-SM:
Issue 02 (2012-03-30)

243

Troubleshooting
8 Multicast
l RPF neighboring interface to the RP

l RPF interface to the RP
l Interface directly connected to shared network segment of user hosts, that is, downstream
interface of the receiver's DR
Run the display pim interface verbose command to check PIM configurations on the interface.
Focus on checking whether PIM-SM is enabled on the preceding interfaces.
l
If the command output does not contain information about an interface of the device or the
PIM mode of an interface is dense, you need to run thepim sm command on the interface.
If the system prompts that "Warning: Please enable multicast routing first" when you
configure PIM-SM on the interface, run the multicast routing-enable command in the
system view to enable the multicast function first and enable PIM-SM on the interface.
If PIM-SM has been enabled on all the interfaces on the device, go to Step 4.
Step 4 Check that the RP information is correct.

Run the display pim rp-info command on the device to check whether the device has learnt
information about the RP serving a specific group and whether the RP information of the same
group on all other devices is consistent.
l
If no RP information is displayed or RP information on the devices are inconsistent, do as

follows:
If the static RP is used on the network, run the static-rp command on all the devices to
make information about the RP serving a specific group consistent.
If the dynamic RP is used, go to Step 10.
If RP information of a specific group is consistent on all the devices, go to Step 5.
Step 5 Check that an RPF route to the RP is available.

Run the display multicast rpf-info source-address command on the device to check whether
there is an RPF route to the RP.
l
If the command output does not contain any RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
If the command output contains an RPF route to the RP, do as follows:

If the command output shows that the RPF route is a static multicast route, run the
display current-configuration command to check whether the static multicast route
is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
If the command output contains an RPF route to the RP and the route is properly configured,
go to Step 6.
Step 6 Check that the interface that forwards multicast data is a receiver's DR.
Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.
l
Issue 02 (2012-03-30)
If the DR information in the command output is not marked with local, troubleshoot the
involved DR following the preceding steps.
244

Troubleshooting
8 Multicast
If the DR information in the command output is marked with local, go to Step 7.
Step 7 Check whether a multicast boundary is configured on the interface.

Run the display current-configuration interface interface-type interface-number command
on the device to check whether a multicast boundary is configured on the interface.
l
If the configuration of the interface contains multicast boundary, it indicates that a

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

Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.
l
If the configuration contains source-policy acl-number, it indicates a source-based

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

Relevant Alarms
None.
Relevant Logs
None.
8.1.4 The SPT on a PIM-SM Network Fails to Forward Data

Common Causes
Issue 02 (2012-03-30)

245

Troubleshooting
8 Multicast
The downstream interface on the multicast device does not receive any (S, G) Join
messages.
PIM-SM is not enabled on the interface.
The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
Configurations are incorrect. For example, the configurations of the TTL, MTU, switchover
threshold, or multicast boundary are improper.
After the PIM-SM network is configured, the SPT fails to forward data.
Issue 02 (2012-03-30)

246

Troubleshooting
8 Multicast
Figure 8-4 Troubleshooting flowchart: the SPT on a PIM-SM network fails to forward data
The RPT on a PIM-SM
network fails to forward data
Check the next hop along the

RPF path from the receiver's
DR to the multicast source
Re-check
the DR
Yes
Do correct (*, G) entries

exist?
No
Has the
downstream interface
received Join messages?
No
Ensure
that the current router is
an RP
Yes
Rectify the interface fault

No
No
Enable PIM-SM on interfaces
Yes
Yes
Is fault
rectified?
Yes
No
Is the RPF
route to the multicast
source available?
No
Rectify the fault of unicast

routes
Yes
No
Is fault
rectified?
No
Yes
Is PIM-SM enabled
on interfaces?
Seek technical
support
Is fault rectified?
Yes
No
Is the interface
that forwards multicast
data the receiver's DR?
Yes
Is the
outbound interface
of the RPF route to the RP
a TE tunnel interface?
Yes
Change the outbound interface

of the RPF route to the
multicast source, ensuring that
it is not a TE tunnel interface
Is fault rectified?
Yes
No
No
Is a multicast boundary
configured on the
interface?
Yes
Remove the configurations of

the multicast boudnary
No
Is fault
rectified?
Yes
No
Is a source-policy
configured?
Remove the configurations of the

source-policy or change the
configurations of the ACL
Yes
Is fault
rectified?
Yes
No
No
Do correct (*, G) entries
exist?
No
Yes
End
Issue 02 (2012-03-30)

247

Troubleshooting
8 Multicast
NOTE
Procedure
Step 1 Check that the PIM routing table contains correct (S, G) entries.
Run the display pim routing-table command on the device to check whether the PIM routing
table contains correct (S, G) entries.
l
If the PIM routing table contains correct (S, G) entries, check whether the downstream
interface list contains downstream interfaces to forward data to all group members.
If the (S, G) entries exist and are all correct in the PIM routing table, run the display
multicast forwarding-table command to view the (S, G) entries in the forwarding table
and check whether the value of the Forwarded field in the command output keeps
increasing. The value of the Matched field is not updated in time. Therefore, after
running the display multicast forwarding-table command, you need to wait for several
minutes.
If the value of the Matched field keeps increasing, it indicates that the upstream
device can normally forward multicast data to the current device but the current
device fails to forward the data downstream. Go to Step 9.
If the value of the Matched field remains unchanged, do as follows:
If the current device is not a source's DR, it indicates that the current device has
not received any multicast data. The fault may be caused by the upstream device.
Then check whether the PIM routing table on the upstream device contains
correct (S, G) entries.
If the PIM routing table on the upstream device does not contain correct (S,
G) entries, troubleshoot the upstream device following the preceding steps.
If the PIM routing table on the upstream device contains correct (S, G) entries,
but the value of the Matched field still remains unchanged, go to Step 9.
If the current device is already a source's DR, it indicates that SPT has been set
up but the source's DR fails to forward the multicast data along the SPT. Go to
Step 9.
If the PIM routing table does not contain correct (S, G) entries, go to Step 2.
Step 2 Check that the downstream interface has received Join messages.
NOTE
If the current device is a receiver's DR, skip this step.
If the downstream interface does not receive any (S, G) Join messages, the possible causes may
be as follows:
l A fault occurs on the downstream interface.
l PIM-SM is not enabled on the downstream interface.
Run the display pim control-message counters interface interface-type interface-number
message-type join-prune command to check whether the number of received Join/Prune
messages on the downstream interface keeps increasing.
Issue 02 (2012-03-30)

248

Troubleshooting
8 Multicast
If the number of received Join/Prune messages on the downstream interface does not
increase, run the display pim control-message counters interface interface-type
interface-number message-type join-prune command on the downstream device to check
whether it has sent Join/Prune messages upstream.
If the command output shows that the number of sent Join/Prune messages keeps
increasing, it indicates that the downstream device has sent Join/Prune messages. The
fault may be caused by a failure in PIM neighbor communication. In such a case, go to
Step 9.
If the command output shows that the number of sent Join/Prune messages does not
increase, it indicates the downstream device experiences a fault. Then locate the fault.
If the number of received Join/Prune messages on the downstream interface keeps

increasing, go to Step 3.
Step 3 Check that PIM-SM is enabled on interfaces.

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

Run the display multicast rpf-info source-address command on the device to check whether
there is an RPF route to the multicast source.
l
If the command output does not contain any RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
If the command output contains an RPF route to the multicast source, do as follows:
If the command output shows that the RPF route is a static multicast route, run the
display current-configuration command to check whether the static multicast route
is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
If the command output contains an RPF route to the RP and the route is properly configured,
go to Step 5.
Step 5 Check that the interface that forwards multicast data is the receiver's DR.
Issue 02 (2012-03-30)

249

Troubleshooting
8 Multicast
Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.
l
If the DR information in the command output is not marked with local, troubleshoot the
involved DR following the preceding steps.
If the DR information in the command output is marked with local, go to Step 6.
Step 6 Check whether a multicast boundary is configured on the interface.

Run the display current-configuration interface interface-type interface-number command
on the device to check whether a multicast boundary is configured on the interface.
l
If the configuration of the interface contains multicast boundary, it indicates that a

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

Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.
l
If the configuration contains source-policy acl-number, it indicates that a source filtering

rule is configured. If the received multicast data is denied by the ACL rule, the multicast
data is discarded. Then you need to run the undo source-policy command to delete the
configuration of the ACL rule or reconfigure an ACL rule to ensure that demanded multicast
data can be normally forwarded.
If no source policy is configured, go to Step 8.
Step 8 Check whether the PIM routing table contains correct (S, G) entries.
Run the display pim routing-table command on the device to check whether the PIM routing
table contains (S, G) entries. For details, see Step 1.
l
----End

Relevant Alarms
None.
Relevant Logs
None.
8.1.5 MSDP Peers Cannot Generate Correct (S, G) Entries

Issue 02 (2012-03-30)

250

Troubleshooting
8 Multicast
Common Causes
l
The MSDP peer to initiate SA messages is not configured on the RP.
The logical RP is not configured on the devices to be deployed with anycast RP or

configurations of the logical RP are incorrect.
MSDP peer relationships are not set up between every two members in a mesh group.
The used intra-domain multicast protocol is not PIM-SM.
The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
Configurations are incorrect. For example, the configurations of the SA policy, import
policy, TTL, switchover threshold, or multicast boundary are improper.
The SA message fails to pass RPF check.
After configurations are complete on a multicast network, MSDP peers cannot generate correct
(S, G) entries.
Issue 02 (2012-03-30)

251

Troubleshooting
8 Multicast
Figure 8-5 Troubleshooting flowchart: MSDP peers cannot generate correct (S, G) entries
MSDP peers cannot generate
correct (S, G) entries
Are MSDP
peers in the Up state?
Ensure that interfaces

No are correctly configured
and peers are reachable
through unicast routes
Is fault
rectified?
Yes
Is SA cache enabled?
No
No
Enable SA cache
Is fault Yes
rectified?
Yes
Have any SA
messages reached
MSDP peers?
No
Yes Ensure that MSDP peers
can receive SA
messages
Is fault Yes
rectified?
No
No
Are export
policies configured on MSDP
peers?
Yes Remove or change the

export policies
Is fault Yes
rectified?
No
No
Are import policies
configured on MSDP
peers?
Yes
Remove or change the

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

import-source policies
Is fault Yes
rectified?
No
No
Issue 02 (2012-03-30)

End
252

Troubleshooting
8 Multicast
NOTE
a record of the actions taken will exist to provide to Huawei technical support personnel.
Procedure
Step 1 Check that the status of MSDP peers is Up.
Run the display msdp brief command on the devices setting up an MSDP peer relationship to
check whether the status of MSDP peers is Up.
l
If the command output shows that the status of MSDP peers is Down, check whether the
MSDP peer interfaces are correctly configured and whether the MSDP peers can ping each
other successfully. If the ping fails, perform troubleshooting based on 7.1.1 The Ping
Operation Fails.
If the MSDP peers are both in the Up state, go to Step 2.
Step 2 Check that SA cache is enabled.

Run the display current-configuration configuration msdp command on MSDP peers to view
the current configurations in the MSDP view.
l
If the command output shows undo cache-sa-enable, SA cache is disabled in the MSDP
view. In this case, run the cache-sa-enable command in the MSDP view to enable SA
cache.
If SA cache has been enabled, go to Step 3.
Step 3 Check that SA messages have reached MSDP peers.

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

If the command output shows the configurations of the peer peer-address sa-policy
export command without any parameters, the MSDP peers are disabled from
forwarding messages received from the multicast source. Then run the undo peer peeraddress sa-policy export command to delete the configurations of export policies.
export acl advanced-acl-number command with an ACL specified, MSDP peers can
forward only the (S, G) entries permitted by the ACL. Then check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the
ACL. You can run the undo peer peer-address sa-policy export command to delete
the configurations of the ACL or change the configurations of the ACL rules.
l
Issue 02 (2012-03-30)
If no export policies are configured on MSDP peers, go to Step 5.

253

Troubleshooting
8 Multicast
Step 5 Check whether import policies are configured on MSDP peers.

the MSDP peers to view the current configurations.
l
If import policies are configured on MSDP peers, do as follows:

import command without any parameters, the MSDP peers are disabled from receiving
messages from the multicast source. Run the undo peer peer-address sa-policy
import command to delete the export policy configurations.
import acl advanced-acl-number command with an ACL specified, MSDP peers can
receive only the (S, G) entries permitted by the ACL. Check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the
ACL. Run the undo peer peer-address sa-policy import command to delete the
configurations of the ACL or change the configurations of the ACL rule.
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.
If the current MSDP peer receives multicast data from the multicast source, go to Step 7.
Step 7 Check whether the current MSDP peer is an RP.

Run the display pim routing-table command on the MSDP peer closest to the multicast source
to view the routing table.
l
If the (S, G) entry does not have a 2MSDP flag, the MSDP peer is not an RP. Change the
configurations of the RP or MSDP peer on the PIM-SM network to ensure that the MSDP
peer is an RP.
If the MSDP peer is an RP, go to Step 8.
Step 8 Check whether import-source policies are configured on the current MSDP peer.
The import-source [ acl acl-number ] command is used to enable an MSDP peer to filter the
(S, G) entries to be advertised based on source addresses when creating SA messages. The MSDP
peer can control the transmission of multicast source information. By default, SA messages can
be used to advertise information about all known multicast sources.
the MSDP peer closest to the multicast source to view the current configurations.
l
If import-source policies are configured on the MSDP peer, do as follows:

If the command output shows the configurations of the import-source command
without any parameters, the MSDP peer is disabled from advertising multicast source
information. Then run the undo import-source command to delete the import-source
policy configurations.
If the command output shows the import-source acl acl-number command with an
ACL specified, the MSDP peer advertises only (S, G) information matching the ACL.
Then check whether ACL-related commands are run on the MSDP peer and whether
(S, G) entries are permitted by the ACL. Then run the undo import-source command
to delete the configurations of the ACL or change the configurations of the ACL rule.
Issue 02 (2012-03-30)

254

Troubleshooting
8 Multicast
If no import policies are configured on the MSDP peers, go to Step 9.
personnel.
l Results of the preceding operation procedure
----End

Relevant Alarms
None.
Relevant Logs
None.
8.1.6 The Multicast Device Cannot Generate IGMP Entries or MLD

Entries
Common Causes
l
Multicast is not enabled on the device.
IGMP is not enabled on the interface or the configured IGMP version is incorrect.
The interface receives an EXCLUDE message in which the group address is within the
SSM group address range.
The interface is configured with a multicast boundary or a group policy.
The limit on the maximum number of IGMP group memberships is configured on the
interface.
After configurations are complete on a multicast network, the multicast device cannot generate
IGMP entries.
Issue 02 (2012-03-30)

255

Troubleshooting
8 Multicast
Figure 8-6 Troubleshooting flowchart for the fault that the multicast device cannot generate
IGMP entries
Multicast device cannot
generate IGMP entries
Is multicast enabled?
Enable multicast and

IGMP
Is fault
rectified?
No
No
Rectify the
interface fault
Is fault
rectified?
No
No
Enable IGMP on
interface
Is fault
rectified?
No
Yes
Yes
Ensure that the group

address is in the SSM
group address range
Is fault
rectified?
Yes
Yes
Is Interface in Up state?
Yes
Is IGMP
enabled on interface?
Yes
No
Yes
Yes
Multicast
Group in SSM group address
range?
No
Is range of groups
that hosts can join limited on
interface?
Yes
Ensure that the group

is in the range of the
groups that the
interface serves
No
Is fault
rectified?
Yes
No
No
Maximum
number of IGMP group
memberships limited on
interface?
Yes
Increase maximum
memberships on the
interface or remove limit
Is fault
rectified?
Yes
No
No
Maximum
Yes
of group memberships limited
Yes
in current instance?
Increase maximum
memberships in
interface or remove limit
No
Maximum
of IGMP group
memberships is limited
globally?
Yes
No
Are The
Number of Entries And
That of interfaces below the
upper limit?
Yes
Increase maximum of
global IGMP group
memberships on
interface or remove
limit
Re-plan network
deployment
No
Issue 02 (2012-03-30)

Is fault Yes
rectified?
No
Is fault
rectified?
Yes
No
Is fault
rectified?
Yes
No
End
256

Troubleshooting
8 Multicast
NOTE
Procedure
Step 1 Check that multicast is enabled on the device.
Run the display current-configuration command on the device that is directly connected to
hosts to check the current configurations of the device.
l
If the command output does not contain multicast routing-enable, run the multicast
routing-enable command in the system view to enable multicast on the device first and
then complete other IGMP configurations. For details, see the Huawei AR1200 Series
Enterprise Routers Configuration Guide - Multicast.
If multicast has been enabled on the device, go to Step 2.
Step 2 Check that the interface status is Up.

Run the display interface interface-type interface-number command on the device to check
configurations of the interface directly connected with the network segment of the hosts.
l
If the command output contains interface-type interface-number current state:

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

check the current configurations of the interface that is directly connected with the hosts.
l
If the command output does not contain igmp enable, it indicates that IGMP is not enabled
on the interface. Run the igmp enable command in the interface view to enable IGMP.
If IGMP has been enabled on the interface, go to Step 4.
Step 4 Check whether the multicast group G of the EXCLUDE message is in the SSM group address
range.
Issue 02 (2012-03-30)

257

Troubleshooting
8 Multicast
Run the display current-configuration configuration pim command on the device that is
directly connected to the hosts to check the current configurations in the PIM view. If the
command output contains ssm-policy basic-acl-number or ssm-policy acl-name, it indicates
that the SSM group address range is defined on the device. Then, run the display acl { aclnumber | name acl-name } command to check the ACL configurations.
l
If the command output shows that the multicast group G is in the address range permitted
by the ACL, it indicates that G belongs to the SSM group address range. Ensure that
IGMPv3 is running between the host and the interface of the device.
If the version of IGMP running on the host cannot be upgraded, you need to enable SSM
mapping on the interface of the device and create static SSM mapping rules for G.
If the command output shows that the multicast group G is in the address range denied by
the ACL, it indicates that G belongs to the ASM group address range. Then, you need to
adjust the group address range specified in the ACL so that G is in the address range
permitted by the ACL.
If the multicast group G is not in the SSM address range and the configured IGMP version
is correct, go to Step 5.
Step 5 Check whether the range of groups that the hosts cannot join is limited on the interface.
Run the display igmp interface interface-type interface-number command to check the current
configurations of the interface that is directly connected with the hosts.
l
If the group-policy field in the command output is not none, it indicates that the range of
groups the hosts can join is limited on the interface. IGMP then filters Report or Join
messages of the hosts according to the ACL. Check the range of the groups permitted by
the ACL. If the multicast group G is not in this range, modify the ACL or delete the ACL
configuration to ensure that IGMP can serve members of G.
If the range of groups that the hosts can join is not limited on the interface, go to Step 6.
Step 6 Check whether the maximum number of IGMP group memberships is limited on the interface.
Run the display igmp interface interface-type interface-number command to check the current
configurations of the interface that is directly connected with the hosts.
l
If the IGMP limit field in the command output does not display -, it indicates that the
maximum number of IGMP group memberships is limited on the interface. Then, run the
igmp limit number command to increase the IGMP limit, or run the undo igmp limit
command to delete the configured IGMP limit.
If the IGMP limit field in the command output displays -, go to Step 7.
Step 7 Check whether the maximum number of IGMP group memberships is limited in the current
instance.
Run the display current-configuration configuration igmp command to check the
configurations of the IGMP limit in the current instance.
l
If the command output contains the configurations of the IGMP limit for the instance, it
indicates that the maximum number of IGMP group memberships is limited in this instance.
Then, run the limit number command in the IGMP view of the instance to increase the
IGMP limit, or run the undo limit command in the IGMP view of the instance to delete
the configured IGMP limit.
If the command output does not contain the configurations of the IGMP limit for the
instance, go to Step 8.
Issue 02 (2012-03-30)

258

Troubleshooting
8 Multicast
Step 8 Check whether the maximum number of IGMP group memberships is limited globally.
Run the display current-configuration | include igmp global limit command to check the
global configurations of the IGMP limit.
l
If there is command output, it indicates that the maximum number of IGMP or MLD group
memberships is limited globally. Then, run the igmp global limit number command in the
system view to increase the IGMP limit, or run the undo igmp global limit command in
the system view to delete the set IGMP limit.
If there is no command output, go to Step 9.
Step 9 Check that the number of entries and number of interfaces are below the upper limit defined in
the product license.
l
If the number of entries and number of interfaces exceed the upper limit allowed by the
product, re-plan network deployment.
If the fault persists after the preceding troubleshooting procedures are complete, go to Step
10.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

259

Troubleshooting
9 QoS
QoS
About This Chapter

9.1 Traffic Policy Troubleshooting
This chapter describes common causes of traffic policy faults, and provides the corresponding
9.2 Priority Mapping Troubleshooting
9.3 Traffic Policing Troubleshooting
This chapter describes common causes of traffic policing faults, and provides the corresponding
9.4 Traffic Shaping Troubleshooting
This chapter describes common causes of traffic shaping faults, and provides the corresponding
9.5 Congestion Avoidance Troubleshooting
This chapter describes common causes of congestion avoidance faults, and provides the
9.6 Congestion Management Troubleshooting
This chapter describes common causes of congestion management faults, and provides the
Issue 02 (2012-03-30)

260

Troubleshooting
9 QoS
9.1 Traffic Policy Troubleshooting

This chapter describes common causes of traffic policy faults, and provides the corresponding
9.1.1 Traffic Policy Fails to Take Effect

procedure to use when the traffic policy fails to take effect.
Common Causes
l
The traffic policy fails to be applied.
The traffic policy is applied to an incorrect direction.
The packets do not match rules of the traffic classifier in the traffic policy.
The traffic behavior associated with the traffic classifier in the traffic policy is configured
incorrectly.
Issue 02 (2012-03-30)

261

Troubleshooting
9 QoS
Figure 9-1 Troubleshooting flowchart for the ineffective traffic policy

Traffic
policy
fails to be
applied
Traffic policy fails

to take effect
Traffic
policy
applied to
incorrect
direction
Is traffic policy
applied correctly?
Yes
Rectify fault
according to error
information
Change the
direction to which
traffic policy is
applied
Yes
Is fault rectified?
No
Do packets
match rules in traffic
classifier?
No
Does
No
information in
packets match
rules?
Modify rules in
traffic
classifier?
Yes
Yes
Is traffic behavior
bound to traffic classifier
correct?
No
Correctly
configure traffic
behavior
Yes
Is fault rectified?
No
Yes
End
NOTE
Procedure
Step 1 Check that the traffic policy is applied correctly.
Run the display traffic-policy applied-record command to check whether a traffic policy is
applied:
l If the value of Policy total applied times is 0, the traffic policy is not applied. Run the
traffic-policy command to apply the traffic policy to an interface or a sub-interface.
l If the value of state is success, check whether the traffic policy is applied to a correct
direction. The traffic policy must be applied to the inbound direction if the traffic policy
Issue 02 (2012-03-30)

262

Troubleshooting
9 QoS
matches packets received by the AR1200, and it must be applied to the outbound direction
if the traffic policy matches packets sent from the AR1200.
If the traffic policy is applied to an incorrect direction, run the undo traffic-policy
{ inbound | outbound } command to unbind the traffic policy, and then run the trafficpolicy policy-name { inbound | outbound } command to re-apply the traffic policy to a
correct direction.
If the traffic policy is applied to a correct direction, go to step 2.
l If the value of state is fail, the traffic policy fails to be applied. If the traffic policy fails to
be applied, the system displays an error message. Run the undo traffic-policy { inbound |
outbound } command to unbind the traffic policy, and then run the traffic-policy policyname { inbound | outbound } command to re-apply the traffic policy. Rectify the fault
identified in the error message.
Step 2 Check whether packets match the rules in the traffic classifier.
Run the display traffic policy statistics command to check the traffic statistics on an interface
to which a traffic policy is applied. If no information is displayed, packets do not match the rules
in the traffic classifier.
NOTE
Before viewing the traffic statistics, ensure that the statistic enable command has been used in the traffic
behavior view to enable the traffic statistics function.
l If packets match the rules in the traffic classifier, go to step 4.

l If packets do not match the rules in the traffic classifier, go to step 3.
Step 3 Check whether the information in packets matches the rules in the traffic classifier.
View the information (such as the IP address, MAC address, DSCP priority, VLAN ID, and
802.1p priority) in packets, run the display traffic-policy user-defined command to view the
traffic classifier in the traffic policy, and run the display traffic classifier user-defined
command to view the rules in the traffic classifier. Check whether the information in packets
matches the rules in the traffic classifier.
l If not, modify the rules to match the information in the packets.
l If yes, go to step 4.
Step 4 Check that the traffic behavior associated with the traffic classifier is configured correctly.
Run the display traffic-policy user-defined policy-name classifier classifier-name command
to check whether the traffic behavior associated with the traffic classifier is configured correctly.
l If not, run the traffic behavior command to enter the traffic behavior view and correctly
configure a traffic behavior.
----End
Issue 02 (2012-03-30)

263

Troubleshooting
9 QoS

Relevant Alarms
None.
Relevant Logs
None.
9.2 Priority Mapping Troubleshooting

9.2.1 Packets Enter Incorrect Queues
procedure to use when packets enter incorrect queues.
Common Causes
Packets enter incorrect queues in the following scenarios:
l
Packets with different priorities enter the same queue.
Packets with different priorities enter incorrect queues.
Packets with the same priority enter an incorrect queue.
Packets with the same priority enter different queues.

l
The type of the priority trusted by the inbound interface is incorrect.
Priority mapping in the priority mapping table is incorrect.
There are configurations affecting the queues that packets enter on the AR1200, including:
The qos car inbound command with remark-8021p or remark-dscp configured has
been used on the inbound interface of packets.
The traffic-policy inbound command with remark 8021p, remark dscp, or remark
local-precedence configured, or the car command with remark-8021p or remarkdscp configured has been used on the inbound interface of packets.
The traffic-policy outbound command with queue af, queue ef, or queue wfq
configured has been used on the outbound interface of packets.
Issue 02 (2012-03-30)

264

Troubleshooting
9 QoS
Figure 9-2 Troubleshooting flowchart for packets entering incorrect queues

Packets enter
incorrect queues
Is priority type trusted

by interface correct?
No
Correctly set
priority type trusted
by interface
Yes
Is fault rectified?
No
Yes
Is priority mapping
correct?
No
Correctly configure
priority mapping
Yes
Is fault rectified?
No
Yes
Are there
configurations affecting
packet enqueuing?
Yes
Delete or modify
configurations
Yes
Is fault rectified?
No
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check that the type of the priority trusted by the inbound interface is correct.
Run the display this command in the view of the inbound interface to view the configuration
of the trust command. (If the trust command is not used, the system does not trust any priority
by default.) Check whether the type of the priority trusted by the inbound interface is correct.
NOTE
If the trust command is not used, the AR1200 sends packets to queues based on the default 802.1p priority
configured by using the port priority command. As a result, all the packets enter the same queue and the
AR1200 cannot provide differentiated services.
l If the type of the priority trusted by the inbound interface is incorrect, run the trust command
to change the type of the priority trusted by the inbound interface.
Issue 02 (2012-03-30)

265

Troubleshooting
9 QoS
l If the type of the priority trusted by the inbound interface is correct, go to step 2.
Step 2 Check whether priority mappings are correct.
The AR1200 sends packets to queues based on the 802.1p priority; therefore, check the mappings
between packet priorities (DSCP, or 802.1p priorities) trusted by the interface and 802.1p
priorities.
Run the display qos map-table command to check whether priority mappings in the priority
mapping table are correct.
l If not, run the qos map-table command to enter the priority mapping table view and run the
input command to configure the priority mappings correctly.
Step 3 Check whether there are configurations affecting the queues that packets enter on the inbound
interface.
1.
Check whether traffic policing defining the re-marking action is configured on the inbound
interface.
Run the display this command in the view of the inbound interface to check whether the
qos car inbound command with remark-8021p or remark-dscp configured has been
used.
l If yes, cancel the re-marking action or run the undo qos car inbound command to
cancel traffic policing.
l If not, go to step b.
2.
Check whether the traffic policy defining the re-marking action is configured in the inbound
direction on the inbound interface.
traffic-policy inbound command has been used.
l If the traffic-policy inbound command has been used, run the display traffic-policy
applied-record command to check the traffic policy record and the traffic behavior in
the traffic policy. If the traffic policy is applied successfully, run the display traffic
behavior user-defined command to check whether the traffic behavior defines the remarking action (remark 8021p or remark dscp), or remark local-precedence.
If the traffic behavior contains the re-marking action, delete the re-marking action
from the traffic behavior or delete the traffic policy from the interface.
If the traffic policy fails to be applied or the traffic behavior does not contain the remarking action, go to step c.
l If the traffic-policy inbound command is not used, go to step c.
3.
Check whether the traffic policy defining the queuing action is configured in the outbound
direction on the outbound interface.
traffic-policy outbound command has been used.
l If the traffic-policy outbound command has been used, run the display traffic-policy
the traffic policy. If the traffic policy is applied successfully, run the display traffic
behavior user-defined command to check the traffic behavior configuration.
If the display traffic behavior user-defined command output contains Assured
Forwarding, Expedited Forwarding, or Flow based Weighted Fair Queuing, the
Issue 02 (2012-03-30)

266

Troubleshooting
9 QoS
traffic behavior contains the queuing action. Delete the queuing action from the
traffic behavior or delete the traffic policy from the interface.
If the traffic policy fails to be applied or the traffic behavior does not contain the
queuing action, go to step 4.
l If the traffic-policy outbound command is not used, go to step 4.
----End

Relevant Alarms
None.
Relevant Logs
None.
9.2.2 Priority Mapping Results Are Incorrect

procedure to use when priority mapping results are incorrect.
Common Causes
l
Packets do not carry the priority trusted by the inbound interface.
Priority mapping in the priority mapping table is incorrect.
There are configurations affecting priority mapping on the inbound interface, including:
qos car inbound with remark-8021p or remark-dscp configured
traffic-policy inbound with remark 8021p, remark dscp, or remark localprecedence configured, or car with remark-8021p or remark-dscp configured
There are configurations affecting priority mapping on the outbound interface, including:
qos car outbound with remark-8021p or remark-dscp configured
traffic-policy outbound with remark 8021p, remark dscp or remark localprecedence configured, or car with remark-8021p or remark-dscp configured
Issue 02 (2012-03-30)

267

Troubleshooting
9 QoS
Figure 9-3 Troubleshooting flowchart for incorrect priority mapping

Priority mapping
results are incorrect
Do packets enter
correct queues?
No
See Packets Enter

Incorrect Queues
Is fault rectified?
Yes
No
Yes
Is priority mapping
correct?
No
Correctly configure
priority mapping
Yes
Is fault rectified?
No
Yes
Are there settings

Yes
affecting priority mapping on
inbound interface?
Cancel relevant
settings
Yes
Is fault rectified?
No
No
Are there settings

Yes
affecting priority mapping on
outbound interface?
Cancel relevant
settings
Yes
Is fault rectified?
No
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether packets carry the priority trusted by the inbound interface.
Run the display this command in the view of the inbound interface to check the configuration
of the trust command. (If the trust command is not used, the AR1200 does not trust any priority
by default.) Capture packets on the inbound interface and check whether the priority of the
captured packets is trusted by the inbound interface.
Issue 02 (2012-03-30)

268

Troubleshooting
9 QoS
NOTE
If the trust command is not used or packets do not carry the priority trusted by the inbound interface, the
AR1200 searches the mappings between 802.1p priorities and other types of priorities based on the default
802.1p priority configured by using the port priority command, and changes packet priorities.
l If packets do not carry the priority trusted by the inbound interface, run the trust command
to configure the inbound interface to trust the priority in packets.
Step 2 Check whether priority mappings are correct.
Run the display qos map-table command to check whether the priority trusted by the interface
and priority mapping are correct.
l If not, run the qos map-table command to modify the configuration.
Step 3 Check whether there are configurations affecting priority mapping on the inbound interface.
1.
Check whether traffic policing defining the re-marking action is configured on the inbound
interface.
Interface-based traffic policing takes precedence over priority mapping. If interface-based
traffic policing defining remark-8021p or remark-dscp is configured on the inbound
interface, the AR1200 re-marks packet priorities.
qos car inbound command with remark-8021p or remark-dscp configured has been
used.
l If yes, delete the re-marking action or run the undo qos car inbound command to delete
traffic policing.
2.
Check whether the traffic policy defining the re-marking action is configured in the inbound
direction on the inbound interface.
A traffic policy takes precedence over priority mapping. If the traffic policy used on the
inbound interface contains priority re-marking, remark local-precedence, or car with
remark-8021p or remark-dscp, the AR1200 re-marks priorities of packets matching the
traffic classifier.
traffic-policy inbound command has been used.
l If the traffic-policy inbound command has been used, run the display traffic-policy
the traffic policy.
If the traffic policy has been applied successfully, run the display traffic behavior
user-defined command to check whether the traffic behavior contains packet priority
re-marking, internal priority re-marking, or car with remark-8021p or remark-dscp.
If the traffic policy fails to be applied or the traffic behavior does not contain the remarking action, go to step c.
l If the traffic-policy inbound command is not used, go to step c.
Step 4 Check whether there are configurations affecting priority mapping on the outbound interface.
Issue 02 (2012-03-30)

269

Troubleshooting
1.
9 QoS
Check whether traffic policing defining the re-marking action is configured on the outbound
interface.
Interface-based traffic policing takes precedence over priority mapping. If interface-based
traffic policing defining the re-marking action is configured on the outbound interface, the
AR1200 re-marks packet priorities.
qos car outbound command with remark-8021p or remark-dscp configured has been
used.
l If yes, delete the re-marking action or run the undo qos car outbound command to
delete traffic policing.
2.
Check whether the traffic policy defining the re-marking action is configured in the
outbound direction on the outbound interface.
A traffic policy takes precedence over priority mapping. If the traffic policy used on the
outbound interface contains priority re-marking, remark local-precedence, or car with
remark-8021p or remark-dscp, the AR1200 re-marks priorities of packets matching the
traffic classifier.
Run the display this command in the view of the outbound interface to check whether the
traffic-policy outbound command has been used.
l If the display traffic-policy applied-record command has been used, run the display
traffic-policy applied-record command to check the traffic policy record and the traffic
behavior in the traffic policy.
If the traffic policy has been applied successfully, run the display traffic behavior
user-defined command to check whether the traffic behavior contains packet priority
re-marking, internal priority re-marking, or car with remark-8021p or remark-dscp.
If the traffic policy fails to be applied or the traffic behavior does not contain the remarking action, go to step 5.
l If the traffic-policy outbound command is not used, go to step 5.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

270

Troubleshooting
9 QoS

This section provides priority mapping troubleshooting cases.
Packets Enter Incorrect Queues

Fault Symptom
Figure 9-4 Packets enter incorrect queues
RouterA
RouterB
Eth0/0/0
RouterC
Eth0/0/1
Eth0/0/1
As shown in Figure 9-4, packets from RouterA carry VLAN 100 and priorities 0 to 7. When
you run the display qos queue statistics command on RouterB to view the traffic statistics on
Eth0/0/1, the command output shows that packets enter incorrect queues.
NOTE
Before running the display qos queue statistics command to view the statistics, you must run the qos
queue-profile command to apply the queue profile to the interface.
<RouterB> display qos queue statistics interface ethernet 0/0/1
----------------------------------------------------------------------------Queue
Passed(Packets/Bytes)
Dropped(Packets/Bytes)
----------------------------------------------------------------------------0
116,975/0
0/0
----------------------------------------------------------------------------1
0/0
0/0
----------------------------------------------------------------------------2
0/0
0/0
----------------------------------------------------------------------------3
0/0
0/0
----------------------------------------------------------------------------4
0/0
0/0
----------------------------------------------------------------------------5
0/0
0/0
----------------------------------------------------------------------------6
0/0
0/0
----------------------------------------------------------------------------7
0/0
0/0
-----------------------------------------------------------------------------
The preceding command output indicates that all packets enter queue 0. Packets should enter
queues based on 802.1p priorities.
Fault Analysis
Packets enter incorrect queues because the mappings between priorities and queues are incorrect.
1.
Check the configuration of the inbound interface on RouterB and check whether there are
configurations affecting packet queuing.
a.
Run the display this command on the inbound interface Eth0/0/1 of RouterB to view
the priority mapping information.
[RouterB-Ethernet0/0/1] display this
#
Issue 02 (2012-03-30)

271

Troubleshooting
9 QoS
port link-type trunk
port trunk allow-pass vlan 100
#
return
The preceding command output indicates that Eth0/0/1 only allows packets from
VLAN 100 to pass through but is not configured to trust 802.1p priorities.
On the AR1200, if no trusted priority is configured on an inbound interface, the
inbound interface does not trust any priority. The AR1200 searches the mappings
between 802.1p priorities and 802.1p priorities based on the default 802.1p priority
of an interface, and sends packets to queues based on the mapped 802.1p priorities.
If the port priority command is not used on an interface, the default 802.1p priority
of the interface is used. By default, the default 802.1p priority of an interface is 0.
Therefore, all the packets enter queue 0.
2.
Check the mappings between 802.1p priorities and 802.1p priorities.

Run the display qos map-table dot1p-dot1p command to view the priority mapping table.
<RouterB> display qos map-table dot1p-dot1p
Input Dot1p
Dot1p
------------------0
0
1
1
2
2
3
3
4
4
5
5
6
6
7
7
The preceding command output indicates that the 802.1p priorities mapping 802.1p priority
0 is also 0. Therefore, all the packets enter queue 0.
Procedure
Step 1 Run the system-view command on RouterB to enter the system view.
Step 2 Run the interface ethernet 0/0/1 command to enter the view of the inbound interface
Eth0/0/1.
Step 3 Run the trust 8021p command to configure the interface to trust 802.1p priorities.
After the preceding configurations are complete, run the display qos queue statistics interface
ethernet 0/0/1 command. You can see that packets with 802.1p priorities 0 to 7 enter queues
based on priorities. The fault is rectified.
----End
Summary
By default, the AR1200 does not trust any packet priority. If packets need to enter queues based
on packet priorities, the inbound interface must be configured to trust packet priorities.
Priority Mapping Is Incorrect Because the Trusted Priority Is Not Set

Fault Symptom
As shown in Figure 9-5, voice, video, and data services on the LAN of the enterprise are sent
to Eth 0/0/1 and Eth 0/0/0 on RouterA through SwitchA and SwitchB, and are sent to the WAN
through GE 0/0/1 on RouterA.
Issue 02 (2012-03-30)

272

Troubleshooting
9 QoS
RouterA identifies and processes service packets on the LAN based on 802.1p priorities in
packets. When packets reach the WAN from GE 0/0/1, RouterA needs to provide differentiated
services based on DSCP priorities in the packets. Priority mapping is configured so that
RouterA can re-mark 802.1p priorities with DSCP priorities.
Figure 9-5 Priority mappings are incorrect
Video
802.1p=2
Data
802.1p=5
LAN
Voice
802.1p=6
Video
802.1p=2
Data
802.1p=5
SwitchA
GE0/0/1
Eth0/0/0
Eth0/0/1
SwitchB
RouterA
RouterB
WAN
Voice
802.1p=6
After the configuration is complete, the DSCP priorities in voice, video, and data flows from
Switch B received on Router B are the same.
Fault Analysis
1.
Capture packets sent from GE 0/0/1 on RouterA. You can see that the DSCP priorities in
voice, video, and data flows from Switch B are 56.
2.
Check whether priority mappings are correct.

Run the display qos map-table dot1p-dscp command to view the mappings between
802.1p priorities and DSCP priorities.
<RouterA> display qos map-table dot1p-dscp
Input Dot1p
DSCP
------------------0
0
1
8
2
16
3
24
4
32
5
40
6
48
7
56
The preceding command output indicates that 802.1p priorities 2, 5, and 6 are mapped to
DSCP priorities 16, 40, and 48. The mappings are correct.
3.
Check that the priority type trusted by the inbound interface is correct.
Run the display this command in the view of the inbound interface to check the
configuration of the inbound interface.
<RouterA> system-view
[RouterA] interface ethernet 0/0/0
Issue 02 (2012-03-30)

273

Troubleshooting
9 QoS
#
trust 8021p
[RouterA] interface ethernet 0/0/1
#
trust 8021p
traffic-policy tp1 inbound
The preceding command output indicates that Eth 0/0/1 and Eth 0/0/0 on RouterA are
configured to trust 802.1p priorities, and a traffic policy is applied to the inbound direction
of Eth 0/0/1.
4.
Check whether the traffic policy affects priority mapping.

Run the display traffic policy user-defined tp1 command to view the configuration of
the traffic policy tp1.
[RouterA] display traffic policy user-defined tp1
User Defined Traffic Policy Information:
Policy: tp1
Classifier: tc1
Operator: OR
Behavior: tb1
Marking:
Remark 8021p 7
[RouterA] display traffic classifier user-defined tc1
User Defined Classifier Information:
Classifier: tc1
Operator: OR
Rule(s) : if-match inbound-interface Ethernet0/0/1
The preceding command output indicates that the traffic policy is bound to the traffic
behavior Remark 8021p 7. This traffic behavior re-marks DSCP priorities of packets with
0 on the AR1200.
Procedure
Step 1 Run the interface ethernet 0/0/1 command to enter the view of the inbound interface Eth 0/0/1.
Step 2 Run the undo traffic-policy inbound command to delete the traffic policy tp1 from Eth 0/0/1.
After the preceding operations are complete, Router B receives voice, video, and data service
flows from RouterA. DHCP priorities of these flows are different. The fault is rectified.
----End
Summary
On the AR1200, if remark is configured in the traffic policy or interface-based traffic policing,
the priority mapping result may be incorrect.
9.3 Traffic Policing Troubleshooting

This chapter describes common causes of traffic policing faults, and provides the corresponding
9.3.1 Traffic Policing Based on Traffic Classifiers Fails to Take

Effect
procedure to use when traffic policing based on traffic classifiers fails to take effect.
Issue 02 (2012-03-30)

274

Troubleshooting
9 QoS
Traffic policing applies the traffic policy's Committed Access Rate (CAR) or aggregated CAR
action to packet flows. Its troubleshooting roadmap is the same as that for traffic policy faults.
For details, see 9.1.1 Traffic Policy Fails to Take Effect.
9.3.2 Interface-based Traffic Policing Results Are Incorrect

procedure to use when interface-based traffic policing results are incorrect.
Common Causes
Interface-based traffic policing results are incorrect in the following scenarios:
l
Traffic policing fails to take effect.
The CAR parameter values are incorrect.

l
The qos car command is not used on the interface.
Traffic policing is applied to an incorrect direction or CAR parameter values are incorrect.
Flow-based traffic policing and the qos car command are used in the same direction and
the CIR value for flow-based traffic policing is smaller than that for interface-based traffic
policing.
If interface-based traffic policing fails to take effect, see Figure 9-6. If the CAR parameter values
for interface-based traffic policing are incorrect, see Figure 9-7.
Figure 9-6 Troubleshooting flowchart for ineffective interface-based traffic policing
Interface-based
traffic policing rate is
incorrect
Do statistics
exist on interface?
No
Is interface-based
traffic policing set?
No Correctly configure
interface-based
traffic policing
Yes
Yes
No
Seek technical
support
Issue 02 (2012-03-30)
Is fault rectified?

End
275

Troubleshooting
9 QoS
Figure 9-7 Troubleshooting flowchart for the incorrect CAR parameter values
Interface-based
traffic policing rate is
incorrect
Do statistics
exist on interface?
Yes
Are CAR parameters

correct?
No
Correctly set CAR

parameters
Is fault rectified?
Yes
No
Yes
Is flow-based
Yes
traffic policing set on
interface?
No
No
Is
flow-based
CAR smaller than
interface-based
CAR?
Yes
Increase interfacebased CAR value or
delete flow-based traffic
policing
Is fault rectified?
Yes
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check the packet statistics on the interface configured with interface-based traffic policing.
Run the display qos car statistics command to view the statistics on forwarded and discarded
packets on the interface.
Issue 02 (2012-03-30)

276

Troubleshooting
9 QoS
l If there is no command output, the interface is not configured with interface-based traffic
policing or interface-based traffic policing fails to take effect. Go to step 2.
l If there is command output, interface-based traffic policing is configured successfully. Go
to step 3.
Step 2 Check whether the interface is correctly configured with interface-based traffic policing.
Run the display this command in the interface view to check whether the qos car command is
used.
l If not, run the qos car command to configure the QoS CAR correctly.
l If yes, check whether the qos car command is used in the correct direction. To limit the rate
of incoming packets, inbound must be configured. To limit the rate of outgoing packets,
outbound must be configured.
NOTE
On the AR1200, LAN-side boards only support interface-based traffic policing in the inbound direction.
If the qos car command is used in the incorrect direction, run the qos car command to
configure CAR in the correct direction.
If the qos car command is used in the correct direction, go to step 3.
Step 3 Check whether CAR parameters are set correctly.
Run the qos car command to check whether the CIR value is correct.
NOTE
If the CBS value is large, it may take a long time for traffic policing to take effect. Wait for a period of
time or reduce the CBS value, and then check whether traffic policing takes effect.
l If CAR parameters are set incorrectly, run the qos car command to modify CAR parameters.
l If CAR parameters are correct, go to step 4.
Step 4 Check whether the interface is configured with flow-based traffic policing.
NOTE
If interface-based traffic policing and flow-based traffic policing are applied to the same direction on an
interface, the smaller CIR value takes effect.
Run the display this command in the view of the inbound interface to check whether the trafficpolicy command is used in the same direction as the qos car command.
l If the traffic-policy command is used, run the display traffic-policy applied-record
command to check the traffic policy record and the traffic behavior in the traffic policy. If
the traffic policy is applied successfully, run the display traffic behavior user-defined
command to check the traffic behavior configuration.
If the traffic behavior contains the CAR action and the CIR value is smaller than the CIR
value for interface-based traffic policing, the CIR value in the traffic behavior takes effect.
Increase the CIR value in the traffic behavior or delete the traffic policy from the interface.
If the traffic policy fails to be applied, the traffic behavior does not contain the CAR
action, or the CIR value in the traffic behavior is greater than the CIR value for interfacebased traffic policing, go to step 5.
l If the traffic-policy command is not used, go to step 5.
Issue 02 (2012-03-30)

277

Troubleshooting
9 QoS

----End

Relevant Alarms
None.
Relevant Logs
None.

This section provides interface-based traffic policing troubleshooting cases.
Interface-based Traffic Policing Fails to Take Effect

Fault Symptom
As shown in Figure 9-8, to protect the enterprise network, traffic policing is configured on
Eth0/0/0 of RouterA to limit the rate of uplink traffic to 10 Mbit/s. When the traffic is sent from
the user network to RouterA at 20 Mbit/s, RouterA still forwards the traffic at 20 Mbit/s. Traffic
policing fails to take effect.
Figure 9-8 Networking diagram for ineffective interface-based traffic policing
User
network
Eth0/0/0
RouterA
Eth0/0/0
Enterprise
network
RouterB
Fault Analysis
1.
Check whether traffic policing is configured in the outbound direction on the outbound
interface of RouterA.
Run the display this command in the view of Eth0/0/0 on RouterA to check whether traffic
policing is configured in the outbound direction.
[V200R001C00B130]
#
ip address 10.0.0.1 255.255.255.0
qos car inbound cir 10000 cbs 1880000 pbs 3130000 green pass yellow pass red
discard
#
return
Issue 02 (2012-03-30)

278

Troubleshooting
9 QoS
The preceding command output indicates that traffic policing is configured in the inbound
direction on Eth0/0/0. Traffic policing only limits the rate of incoming packets.
Procedure
Step 1 Run the system-view command on RouterA to enter the system view.
Step 2 Run the interface ethernet 0/0/0 command to enter the view of Eth0/0/0.
Step 3 Run the qos car outbound cir 10000 command to configure traffic policing in the outbound
direction and set the CIR value to 10 Mbit/s.
After the preceding operations are complete, when traffic is sent to RouterA at 20 Mbit/s,
Eth0/0/0 forwards the traffic at 10 Mbit/s. Traffic policing takes effect and the fault is rectified.
----End
Summary
If interface-based traffic policing fails to take effect, check whether interface-based traffic
policing is configured in the correct direction. If qos car inbound is used, traffic policing takes
effect for only incoming packets. If qos car outbound is used, traffic policing takes effect for
only outgoing packets.
9.4 Traffic Shaping Troubleshooting

This chapter describes common causes of traffic shaping faults, and provides the corresponding
9.4.1 Queue-based Traffic Shaping Results Are Incorrect

procedure to use when queue-based traffic shaping results are incorrect.
Common Causes
l
Traffic shaping parameters are set incorrectly.
The CIR value for interface-based traffic shaping is smaller than the sum of CIR values for
traffic shaping in queues on the interface. As a result, the bandwidth required by queues
cannot be ensured.
Packets do not enter queues configured with traffic shaping because the configuration is
incorrect. For example, priority mapping is incorrect.
Each queue uses the combined scheduling mode and excess packets enter Priority Queuing
(PQ) queues. As a result, other queues cannot obtain sufficient bandwidth.
NOTE
In combined scheduling mode, if the bandwidth is insufficient, the CIR value of other queues cannot
be reached. This is a correct traffic shaping result.
Issue 02 (2012-03-30)

279

Troubleshooting
9 QoS
Figure 9-9 Troubleshooting flowchart for incorrect queue-based traffic shaping results
Queue-based traffic
shaping results are
incorrect
Are shaping
parameters correct?
No
Correctly set shaping

parameters
Is fault rectified?
No
Yes
No
Yes
Is interface-based
traffic shaping
configured?
Yes
Is CIR for
Interface-based traffic
shAping greater than sum of
CIR values for queues?
No
Ensure that CIR for

interface-based traffic
shaping greater than sum of
CIR values for queues
Is fault rectified?
Yes
No
Yes
Do packets
enter queues?
No
See Packets Enter

Incorrect Queues
Is fault rectified?
Yes
No
Yes
Do queues use
combined scheduling mode?
No
Yes
Do PQ
queues have excess
packets?
Yes
Re-plan scheduling
modes and weights
No
Yes
Is fault rectified?
No
Issue 02 (2012-03-30)

End
280

Troubleshooting
9 QoS
NOTE
Procedure
Step 1 Check that queue-based traffic shaping parameters are set correctly.
Run the display this command in the interface view to check whether the qos queue-profile
command is used.
l If the qos queue-profile command is used, run the display qos queue-profile queue-profilename command to check the queue profile configuration.
If the value of the GTS (CIR/CBS) field is -/-, queue-based traffic shaping is not
configured in the queue profile. Run the queue gts command in the queue profile view
to configure queue-based traffic shaping.
If the value of the GTS (CIR/CBS) field is not -/-, queue-based traffic shaping is
configured in the queue profile. Record the index of the queue configured with traffic
shaping and go to step 2.
l If the qos queue-profile command is not used, run the qos queue-profile command to
configure a queue profile.
Step 2 Check whether the interface is configured with interface-based traffic shaping.
Check whether the qos gts command is used on the interface.
l If not, go to step 4.
Step 3 Check whether the CIR value for interface-based traffic shaping is greater than the sum of CIR
values for traffic shaping in queues on the interface.
Compare the CIR value for interface-based traffic shaping with the sum of CIR values of traffic
shaping in queues on the interface:
l If the CIR value for interface-based traffic shaping is smaller than the sum of CIR values for
traffic shaping in queues on the interface, queues on the interface cannot obtain sufficient
bandwidth. The traffic shaping result may be incorrect. Run the qos gts command to modify
interface-based traffic shaping parameters to ensure that the CIR value for interface-based
traffic shaping is greater than the sum of CIR values for traffic shaping in queues on the
interface.
l If the CIR value for interface-based traffic shaping is greater than the sum of CIR values for
traffic shaping in queues on the interface, go to step 4.
Step 4 Check whether packets enter traffic shaping queues.
Run the display qos queue statistics interface interface-type interface-number command to
view the packet statistics on each queue on the interface.
l If the values of Passed and Dropped fields in the command output are 0/0, packets do not
enter traffic shaping queues. Rectify the fault according to 9.2.1 Packets Enter Incorrect
Queues.
l If the values of Passed and Dropped fields in the command output are not 0/0, packets enter
traffic shaping queues. Check whether a large number of packets enter PQ queues (for
Issue 02 (2012-03-30)

281

Troubleshooting
9 QoS
example, the rate of packets on the GigabitEthernet interface exceeds 100 Mbit/s and the rate
of packets on the Ethernet interface exceeds 10 Mbit/s).
If not, go to step 6.
Step 5 Check whether queues on the interface use the combined scheduling mode.
Run the display this command in the interface view to check the scheduling mode used by each
queue on the interface.
l If schedule pq and schedule wrr, schedule drr, or schedule wfq are configured for each
queue, the combined scheduling mode is used.
In combined scheduling mode, when traffic is transmitted on the interface, the traffic in PQ
queues is first processed, and then the traffic in Weighted Round Robin (WRR), Deficit
Round Robin (DRR), or Weighted Fair Queuing (WFQ) queues is processed. The remaining
bandwidth is allocated based on weights. If PQ queues contain excess packets, some packets
in WRR, DRR, WFQ queues may be not processed.
Run the qos queue-profile command in the queue profile view and run the schedule and
queue weight commands in the queue profile view to reconfigure the scheduling mode and
weight of each queue, reducing the number of packets that enter PQ queues.
NOTE
In combined scheduling mode, if the bandwidth is insufficient, the CIR value of other queues cannot
be reached. This is a correct traffic shaping result.
l If each queue uses PQ, WRR, DRR, or WFQ scheduling mode, go to step 6.
----End

Relevant Alarms
None.
Relevant Logs
None.

This section provides traffic shaping troubleshooting cases.
Queue-based Traffic Shaping Results Are Incorrect

Fault Symptom
As shown in Figure 9-10, the transmission rate of traffic on the LAN is higher than that on the
WAN-side interface; therefore, jitter may occur on the downlink interface GE0/0/1 of the
RouterA. To prevent jitter and ensure bandwidth of services, you must configure RouterA to
Issue 02 (2012-03-30)

282

Troubleshooting
9 QoS
send flows of voice, video, and data services to queue 6, queue 2, and queue 5 respectively. In
addition, traffic shaping must be configured to ensure that:
l
The rate limit of voice services is 100 kbit/s.
The rate limit of video services is 2000 kbit/s.
The rate limit of data services is 500 kbit/s.
Figure 9-10 Networking diagram for incorrect queue-based traffic shaping results
Voice
802.1p=6
802.1p=5
LAN
Eth0/0/0
Switch
Data
GE0/0/1
RouterA
WAN
RouterB
802.1p=2
Video
After the configuration is complete, the bandwidth for voice and video services is insufficient.
Fault Analysis
1.
Check whether service flows enter specified queues.

Run the reset qos queue statistics interface gigabitethernet 0/0/1 command on RouterA
to clear the queue-based traffic statistics on GE0/0/1.
Send flows of voice, video, and data services to RouterA and run the display qos queue
statistics command to view the queue-based traffic statistics on the interface. The following
command output indicates that flows of voice, video, and data services enter specified
queues.
<RouterA> display qos queue statistics interface gigabitethernet 0/0/1
----------------------------------------------------------------------------Queue
Passed(Packets/Bytes)
Dropped(Packets/Bytes)
----------------------------------------------------------------------------Protocol
0/0
0/0
0
0/0
0/0
1
0/0
0/0
2
3470/3470000
0/0
3
0/0
0/0
4
0/0
0/0
5
25600/256000
0/0
6
54354/5435400
0/0
7
0/0
0/0
2.
Check whether the sum of CIR values for traffic shaping in queues on the interface is greater
than the CIR value for interface-based traffic shaping.
Run the display this command in the view of the WAN-side interface on RouterA to check
traffic shaping parameters.
Issue 02 (2012-03-30)

283

Troubleshooting
9 QoS
[RouterA-GigabitEthernet0/0/1] display this

#
qos queue-profile qq1
qos gts cir 2000 cbs 50000
#
return
[RouterA-qos-queue-profile-qq1] display this
#
queue 2 gts cir 2000 cbs 50000
queue 2 weight 20
queue 5 weight 50
schedule wfq 0 to 5 pq 6 to 7
#
return
According to the preceding command output, interface-based traffic shaping and queuebased traffic shaping are configured on the WAN-side interface GE0/0/1. Queue 2 and
queue 5 use WFQ scheduling, and queue 6 uses PQ scheduling. Traffic shaping parameters
are correct. The CIR value for interface-based traffic shaping is smaller than the sum of
CIR values for traffic shaping in queues 2, 5, and 6 on the interface.
On the AR1200, if the CIR value for interface-based traffic shaping is smaller than the sum
of CIR values for traffic shaping in queues, the bandwidth required by queues cannot be
provided.
Procedure
Step 1 Run the interface gigabitethernet 0/0/1 command on RouterA to enter the view of GE0/0/1.
Step 2 Run the qos gts cir 3000 command to change the CIR value for interface-based traffic shaping
to 3000 kbit/s so that it is greater than the sum of CIR values for traffic shaping in queues.
After the preceding operations are complete, the bandwidth for voice services, video services,
and data services is sufficient.
----End
Summary
If queue-based traffic shaping results are incorrect, check whether interface-based traffic shaping
and queue-based traffic shaping are configured on the interface. If they are configured on the
interface and the CIR value for interface-based traffic shaping is smaller than the sum of CIR
values for traffic shaping in queues, the bandwidth required by queues cannot be provided.
9.5 Congestion Avoidance Troubleshooting

This chapter describes common causes of congestion avoidance faults, and provides the
9.5.1 Congestion Avoidance Fails to Take Effect

procedure to use when congestion avoidance fails to take effect.
Issue 02 (2012-03-30)

284

Troubleshooting
9 QoS
Common Causes
l
Congestion avoidance is not configured on the outbound interface.
WRED parameters are set incorrectly.
Packets enter incorrect queues.
Figure 9-11 Troubleshooting flowchart for ineffective congestion avoidance
Congestion
avoidance fails to
take effect
No
Is congestion
avoidance set on outbound
interface?
Configure a queue profile

on outbound interface
Is fault rectified?
Yes
No
Yes
Are WRED
parameters correct?
No
Set WRED parameters
Is fault rectified?
Yes
No
Yes
Do packets
enter specified
queues?
No
See Packets Enter

Incorrect Queues
No
Yes
Seek technical
support
Issue 02 (2012-03-30)
Yes
Is fault rectified?

End
285

Troubleshooting
9 QoS
NOTE
The congestion avoidance mechanism discards packets based on the maximum number of packets buffered
in a queue and the actual length of packets. If the upper and lower drop thresholds and the queue length
are not set properly, for example, the queue length is too long or the upper or lower drop threshold is too
high, congestion may occur.
Procedure
Step 1 Check whether congestion avoidance is configured on the outbound interface.
Check Item
Method
Queue-based congestion avoidance
Run the display this command in the view of

the outbound interface to check whether the
qos queue-profile command is used. If the
qos queue-profile command is used, run the
display this command in the queue profile
view to check whether the queue dropprofile command is used. If the queue dropprofile command is used, queue-based
congestion avoidance is configured on the
interface.
Flow-based congestion avoidance

traffic-policy command is used. If the
traffic-policy command is used, run the
display traffic policy user-defined
command to check whether the dropprofile command is used. If the dropprofile command is used, flow-based
congestion avoidance is configured.
NOTE
Flow-based congestion avoidance can be configured only for CBWFQ queues on WAN-side interfaces.
l If queue-based congestion avoidance or flow-based congestion avoidance is not configured,

configure it on the outbound interface.
l If queue-based congestion avoidance or flow-based congestion avoidance is configured, go
to step 2.
Step 2 Check whether WRED parameters are set correctly.
Run the display drop-profile command to check whether WRED parameters in the drop profile
are correct.
l If not (for example, when the upper and lower drop thresholds are 100, congestion avoidance
does not take effect if tail drop is used), run the dscp discard-percentage or ip-precedence
discard-percentage command to change the upper and lower drop thresholds.
Issue 02 (2012-03-30)

286

Troubleshooting
9 QoS
Step 3 Check whether packets enter specified queues.
Run the display qos queue statistics interface command to view queue-based traffic statistics
on the outbound interface. Check whether packets enter specified queues.
l If not, rectify the fault according to 9.2.1 Packets Enter Incorrect Queues.
----End

Relevant Alarms
None.
Relevant Logs
None.
9.6 Congestion Management Troubleshooting

This chapter describes common causes of congestion management faults, and provides the
9.6.1 Congestion Management Fails to Take Effect

procedure to use when congestion management fails to take effect.
Common Causes
l
Traffic shaping is not configured on the outbound interface.
Congestion management is not configured on the outbound interface.
Scheduling parameters are set incorrectly.
Packets enter incorrect queues.
If packets in a queue are not scheduled or scheduling results are incorrect, congestion
management fails to take effect. Follow procedures shown in the troubleshooting flowchart in
Figure 9-12.
Issue 02 (2012-03-30)

287

Troubleshooting
9 QoS
Figure 9-12 Troubleshooting flowchart for ineffective congestion management

Congestion
management fails to
take effect
Is traffic shaping set on

outbound interface?
No
Correctly set traffic

shaping on outbound
interface
Yes
Is fault rectified?
No
Yes
Is congestion
management set on
outbound interface?
No
Correctly set congestion

management on outbound
interface
Yes
Is fault rectified?
No
Yes
Are scheduling
parameters correct?
No
Correctly set scheduling

parameters
Yes
Is fault rectified?
No
Yes
Do packets enter
correct queues?
No
See Packets Enter

Incorrect Queues
Yes
Is fault rectified?
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check that traffic shaping is configured correctly on the outbound interface.
Run the display this command in the view of the outbound interface to check whether the qos
gts command is used.
Issue 02 (2012-03-30)

288

Troubleshooting
9 QoS
l If the qos gts command is not used or traffic shaping parameters are incorrect, run the qos
gts command.
l If the qos gts command is used, go to step 2.
Step 2 Check that congestion management is configured on the outbound interface.
Check Item
Method
Queue-based congestion management

qos queue-profile command is used. If the
qos queue-profile command is used, run the
display this command in the queue profile
view to check whether the schedule
command is used. If the schedule command
is used, queue-based congestion management
is configured on the interface.
Flow-based congestion management

traffic-policy command is used. If the
traffic-policy command is used, run the
display traffic policy user-defined
command to check whether the queue af,
queue ef, or queue wfq command is used. If
the queue af, queue ef, or queue wfq
command is used, flow-based congestion
management is configured.
NOTE
Flow-based congestion management can be configured only on WAN-side interfaces.
l If queue-based congestion management or flow-based congestion management is not

configured, configure it on the outbound interface.
l If queue-based congestion management or flow-based congestion management is configured,
go to step 3.
Step 3 Check whether scheduling parameters are set incorrectly.
l If queue-based congestion management is configured on the interface, run the display this
command in the queue profile view to view the scheduling mode and weight of each queue.
NOTE
By default, PQ scheduling is implemented for all queues. To smooth out the delay and jitter when
congestion occurs, use PQ scheduling for core services such as voice and video services, and use DRR,
WRR, or WFQ scheduling for non-core services. This configuration allows the switch to uniformly
process packets with the same priority, and process packets with different priorities based on weights.
If scheduling parameters are incorrect, run the schedule and queue weight commands to
reconfigure the scheduling mode and weight of each queue.
If scheduling parameters are correct, go to step 4.
l If flow-based congestion management is configured on the interface, run the display traffic
policy user-defined command to check whether scheduling parameters such as the
scheduling mode and minimum bandwidth are correct.
Issue 02 (2012-03-30)

289

Troubleshooting
9 QoS
If scheduling parameters are incorrect, run the queue af, queue ef, or queue wfq
command to reconfigure scheduling parameters.
If scheduling parameters are correct, go to step 4.
Step 4 Check whether packets enter correct queues.
Run the display qos queue statistics interface command to view queue-based traffic statistics
on the outbound interface. Check whether packets enter specified queues.
l If not, rectify the fault according to 9.2.1 Packets Enter Incorrect Queues.
----End

Relevant Alarms
None.
Relevant Logs
None.

This section provides congestion management troubleshooting cases.
Network Congestion Interrupts Services

Fault Symptom
As shown in Figure 9-13, the transmission rate of traffic on the LAN is higher than that on the
WAN-side interface; therefore, congestion may occur on the uplink interface GE0/0/1 of the
Router. To prevent jitter and ensure bandwidth of services, you must configure the Router to
send flows of voice, video, and data services to queue 6, queue 2, and queue 5 respectively. In
addition, congestion management must be configured to ensure that:
l
The bandwidth of the outbound WAN-side interface is 10000 kbit/s.
The maximum bandwidth of voice services is 3000 kbit/s.
Video and data packets share the remaining bandwidth and the ratio is 5:2.
Queue 6 use PQ scheduling; queue 2 and queue 5 use WFQ scheduling and their weights
are 50 and 20 respectively.
Issue 02 (2012-03-30)

290

Troubleshooting
9 QoS
Figure 9-13 Networking diagram
Voice
802.1p=6
802.1p=5
LAN
Eth0/0/0
Switch
Data
GE0/0/1
RouterA
WAN
RouterB
802.1p=2
Video
After the configuration is complete, the bandwidth of voice and video services cannot be
guaranteed, and voice and video signals are interrupted sometimes. Congestion management
fails to take effect.
Fault Analysis
1.
Check whether the downlink interface of the Router is correctly configured with traffic
shaping and queue scheduling parameters.
Run the display this command in the GE0/0/1 view to check the configuration of the
interface.
[Router-GigabitEthernet0/0/1] display this
#
ip address 192.168.0.1 255.255.255.0
qos gts cir 10000 cbs 250000
#
return
According to the preceding command output, interface-based traffic shaping is configured

on GE0/0/1, GE0/0/1 is bound to the queue profile qq1, and the interface-based traffic
shaping configuration is correct.
2.
Check whether traffic shaping parameters and queue scheduling parameters are set
correctly in the queue profile.
Run the display this command in the queue profile view to view the traffic shaping
parameters and queue scheduling parameters.
[Router-qos-queue-profile-qq1] display this
[V200R001C00B130]
#
queue 2 weight 50
queue 5 weight 20
schedule wfq 0 to 5 pq 6 to 7
#
According to the preceding command output, queue 2 and queue 5 use WFQ scheduling,
queue 6 and queue 7 use PQ scheduling, the weights of queue 2 and queue 5 are 50 and 20
Issue 02 (2012-03-30)

291

Troubleshooting
9 QoS
respectively, and the CIR value of queue 7 is 3000 kbit/s. Voice services enter queue 6 that
is not configured with traffic shaping. As a result, voice services may preempt all the
bandwidth of the interface. Video and data services are interrupted.
Procedure
Step 1 Run the system-view command on the Router to enter the system view.
Step 2 Run the qos queue-profile qq1 command to enter the view of the queue profile qq1.
Step 3 Run the undo queue 7 gts command to disable traffic shaping for queue 7.
Step 4 Run the queue 6 gts cir 3000 command to enable traffic shaping for queue 6 and set the CIR
value to 3 Mbit/s.
After the preceding operations are complete, the bandwidth for voice, video, and data services
is ensured.
----End
Summary
When configuring the combined scheduling mode, limit the bandwidth for queues that use PQ
scheduling. In combined scheduling mode, the AR1200 first schedules packets in PQ queues.
After packets in PQ queues are scheduled, the AR1200 schedules packets in DRR, WFQ, or
WRR queues. If bandwidth of PQ queues is not limited, service flows in PQ queues may occupy
all the bandwidth of the interface, causing service interruption in other queues.
Issue 02 (2012-03-30)

292

Troubleshooting
10 Security
10
Security
About This Chapter

10.1 AAA Troubleshooting
10.2 ARP Security Troubleshooting
10.3 NAC Troubleshooting
10.4 Firewall Troubleshooting
10.5 ACL Troubleshooting
10.6 NAT Troubleshooting
10.7 PKI Troubleshooting
Issue 02 (2012-03-30)

293

Troubleshooting
10 Security
10.1 AAA Troubleshooting

10.1.1 RADIUS Authentication Fails
Common Causes
l
The user name or password is incorrect. For example, the user name does not exist, or the
user name format (with or without the domain name) is different from the format configured
on the Remote Authentication Dial In User Service (RADIUS) server.
The RADIUS configuration on the AR1200 is incorrect, including the authentication mode
and the RADIUS server template.
The port number and shared key configured on the AR1200 are different from those on the
RADIUS server.
The number of online users reaches the maximum value.
A user fails to pass the Authentication Dial In User Service (RADIUS) authentication.
l
Check whether the link between the AR1200 and the RADIUS server is working.
Check whether the number of authenticated users has reached the maximum.
Check the RADIUS configuration on the AR1200, including the domain name, domain
status, RADIUS server template, authentication mode, and accounting mode.
Check whether the user name, password, and user access type configured on the RADIUS
server are correct and whether the router IP address, port number, shared key, and domain
name carry method and resolution method configured on the RADIUS server are the same
as those configured on the AR1200.
Issue 02 (2012-03-30)

294

Troubleshooting
10 Security
Figure 10-1 Troubleshooting flowchart for RADIUS authentication failure

RADIUS
authentication fails
Is link between
router and RADIUS
server faulty ?
Yes
Rectify link fault
Is the fault
rectified?
Yes
No
No
Does the
number of online users
reach maximum?
Yes
This is not a fault
No
Is RADIUS
configuration on
router correct?
No
Modify domain,
authentication mode,
accounting mode, or
RADIUS server template
Is the fault
rectified?
Yes
No
Yes
Does router send
RADIUS packets?
No
Ensure that the RADIUS

server template is applied
to the domain
Is the fault
rectified?
Yes
No
Yes
Does
router receive RADIUS
response packet?
No
Ensure that router IP

address and port number
on RADIUS server and
router are the same
Is the fault
rectified?
Yes
No
Yes
Does
RADIUS server record
authentication
failure?
Yes
Ensure that shared key

and user name format on
RADIUS server and router
are the same
Is the fault
rectified?
Yes
No
No
Issue 02 (2012-03-30)

End
295

Troubleshooting
10 Security
NOTE
Procedure
Step 1 Run the ping command to check whether the link between the AR1200 and the RADIUS server
is working.
l If the ping operation fails, rectify the link fault according to 7.1.1 The Ping Operation
Fails.
Step 2 Check whether the number of online users reaches the maximum.
Both the AR1200 and RADIUS server have a limit to the number of online users. Run the display
access-user command on the AR1200 to check the number of online users.
l If the number of online users reaches the maximum, you do not need to take any action. The
user can log in after the number of online users falls below the maximum.
l If the number of online users does not reach the maximum, check the maximum number of
online users set on the RADIUS server. If the maximum number of online users set on the
RADIUS server is not reached, go to step 3.
Step 3 Check that the RADIUS configuration on the AR1200 is correct.
Check the RADIUS configuration to ensure that:
l The authentication domain of the user is in Active state.
l The authentication scheme bound to the user domain is RADIUS authentication.
l The correct RADIUS server template is bound to the domain. The IP address and port of the
authentication server and accounting server are set correctly in the template. The source
address in the packet sent by the router must be the same as the allowed address configured
on the RADIUS server.
l The user name format and shared key specified in the template are the same as those on the
RADIUS server.
Before checking the last two items, connecting the AR1200 to a RADIUS server.
Issue 02 (2012-03-30)
Action
Command
Check the domain configuration.
display domain
Check which RADIUS server template is

bound to the domain.
display domain name domain-name
Check the authentication scheme bound to the

domain.
display authentication-scheme
Check the accounting scheme bound to the

domain.
display accounting-scheme

296

Troubleshooting
10 Security
Action
Command
Check the configuration of the RADIUS

server template.
display radius-server configuration
Step 4 Check information about the RADIUS packets sent and received by the AR1200.
Run the debugging radius packet command in the user view to enable RADIUS packet
debugging. Initiate RADIUS authentication or run the test-aaa command to send an
authentication request. Check whether any RADIUS packets have been sent and received by the
AR1200.
<Huawei> debugging radius packet
CAUTION
Debugging affects system performance. So, after debugging, run the undo debugging all
command to disable the debugging immediately.
l If no debugging information is displayed, the router configuration is incorrect. Check that
the RADIUS server template is bound to the domain.
The following configuration file shows that the RADIUS server template radius is bound to
the domain huawei.
#
radius-server template radius
radius-server authentication 1.1.1.1 1645
#
aaa
authentication-scheme default
authentication-scheme aaa
authentication-mode radius
authorization-scheme default
accounting-scheme default
domain default
domain default_admin
domain huawei
radius-server radius
l If debugging information is displayed, proceed according to the following debugging

information.
Issue 02 (2012-03-30)
Debugging Information
Solution
Nov 10 2010 15:23:34.260.6 Huawei RDS/

7/debug2:
Radius Sent a Packet
Server Template: 0
Server IP
: 192.168.1.128
Protocol: Standard
......
The RADIUS module sent an

authentication packet. This message
indicates that the AR1200 can send
RADIUS authentication packets.

297

Troubleshooting
10 Security
Solution
Nov 10 2010 15:23:34.260.6 Huawei %%

01RDS/4/RDAUTHDOWN(l):
RADIUS authentication server ( IP:
192.168.1.128 ) is down!
The RADIUS authentication server did not

send an authentication response packet.
This may be because the link between the
AR1200 and the RADIUS server failed or
the RADIUS server has not restarted.
Check that the router IP address and
RADIUS service port numbers configured
on the RADIUS server are the same as those
configured on the AR1200, and that the
RADIUS service is enabled.
Nov 10 2010 15:23:34.260.6 Huawei RDS/

7/debug2:
[RDS (Evt):] Send a msg (Auth reject)
Nov 10 2010 15:23:34.260.7 Huawei RDS/
7/debug2:
[RDS (Msg):]Msg type
:Auth reject
[RDS (Msg):]UserID
:16005
[RDS (Msg):]Template no:88.99
[RDS (Msg):]Authmethod :(pap)
[RDS (Msg):]ulSrcMsg
:Auth req
[RDS (Msg):]szBitmap
:00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
The RADIUS authentication server

returned an authentication failure packet.
The possible causes of authentication
failure are:
l The router IP address and the shared key
are not configured on the RADIUS
server.
l The shared key configured on the
RADIUS server is different from the
shared key configured on the AR1200.
l The user account is not configured on
the RADIUS server, or the user name
format configured in the RADIUS
server template is different from that on
the RADIUS server. For example, the
AR1200 sends the user name without the
domain name but the RADIUS server
requires the user name with the domain
name.
l The password entered by the user is
different from the password configured
on the RADIUS server.
If any of the preceding errors exist, modify
the configuration on the RADIUS server.
After configuration modification, check
whether the user can pass the
authentication. If the fault persists, go to
step 5.
Step 5 Check the user type.

l If the user is a Telnet user or an FTP user, rectify the fault according to "2.2.1 The User Fails
to Log in to the Server Through Telnet" or "The User Fails to Log in to the Server Through
FTP."
l If the user is a network access user, rectify the fault according to "10.3 NAC
Troubleshooting."
Issue 02 (2012-03-30)

298

Troubleshooting
10 Security
personnel:
----End

Relevant Alarms
None.
Relevant Logs
None.
10.1.2 HWTACACS Authentication Fails

Common Causes
l
The user name or password is incorrect. For example, the user name does not exist, or the
user name format (with or without the domain name) is different from the format configured
on the Huawei Terminal Access Controller Access Control System (HWTACACS) server.
The HWTACACS configuration on the AR1200 is incorrect, including the authentication

mode and HWTACACS server template.
The port number and shared key configured on the AR1200 are different from those on the
HWTACACS server.
The number of online users reaches the maximum value.
l
Check whether the link between the AR1200 and the HWTACACS server is working.
Check whether the number of authenticated users has reached the maximum.
Check the HWTACACS configuration on the AR1200, including the domain name, domain
status, HWTACACS server template, authentication mode, authorization mode, and
accounting mode.
Check whether the user name, password, and user access type configured on the
HWTACACS server are correct and whether the router IP address, port number, shared
key, and domain name mode and resolution method configured on the HWTACACS server
are the same as those configured on the AR1200.

Issue 02 (2012-03-30)

299

Troubleshooting
10 Security
Figure 10-2 Troubleshooting flowchart for HWTACACS authentication failure
HWTACACS
Authentication fails
Is link
between router and
HWTACACS server
faulty?
Yes
Yes
No
No
Yes
Does the
reach maximum?
No
Is HWTACACS
configuration on router
correct?
No
This is not a fault
Modify domain,
authentication mode,
authorization mode,
accounting mode, or
HWTACACS server
template
Is the fault
rectified?
Apply the HWTACACS

server template to the
domain
Is the fault
rectified?
Yes
Does router
send HWTACACS
packets?
Is the fault
rectified?
No
Yes
No
Yes
No
Yes
Does router
receive HWTACACS
response packet?
No
Ensure that router IP

addresses and port
numbers on the
HWTACACS server and
router are the same
Is the fault
rectified?
Yes
No
Yes
Does
HWTACACS server
record authentication
failure?
Yes
Ensure that the shared

key and user name
formats on the
HWTACACS server and
router are the same
Is the fault
rectified?
Yes
No
No
Issue 02 (2012-03-30)

End
300

Troubleshooting
10 Security
NOTE
Procedure
Step 1 Run the ping command to check whether the link between the AR1200 and the HWTACACS
server is working.
l If the ping operation fails, rectify the link fault according to 7.1.1 The Ping Operation
Fails.
Step 2 Check whether the number of online users has reached the maximum.
Both the AR1200 and HWTACACS server have a limit on the number of online users. Run the
display access-user command on the AR1200 to check the number of online users.
l If the number of online users has reached the maximum, you do not need to take any action.
The user can log in after the number of online users falls below the maximum.
l If the number of online users has not reached the maximum, check the maximum number of
online users set on the HWTACACS server. If the maximum number of online users set on
the HWTACACS server has not been reached, go to step 3.
Step 3 Check the HWTACACS configuration on the AR1200 to ensure that:
l The authentication domain of the user is in Active state.
l The authentication scheme bound to the user domain is HWTACACS authentication.
l The correct HWTACACS server template is bound to the domain. The IP address and port
of the authentication server, authorization server, and accounting server are set correctly in
the template. The source address in the packet sent by the router must be the same as the
allowed address configured on the HWTACACS server.
l The user name format and shared key specified in the template are the same as those on the
HWTACACS server.
Before checking the last two items, connecting the AR1200 to a HWTACACS server.
Issue 02 (2012-03-30)
Action
Command
Check the domain configuration.
display domain
Check which HWTACACS server template

is bound to the domain.
display domain name domain-name
Check the authentication scheme bound to the

domain.
display authentication-scheme
Check the authorization scheme bound to the

domain.
display authorization-scheme
Check the accounting scheme bound to the

domain.
display accounting-scheme

301

Troubleshooting
10 Security
Action
Command
Check the configuration of the HWTACACS

server template.
display hwtacacs-server template
Step 4 Check information about the HWTACACS packets sent and received by the AR1200.
Run the debugging hwtacacs all command in the user view to enable HWTACACS packet
debugging. Initiate HWTACACS authentication. Check whether any HWTACACS packets are
being sent or received by the AR1200.
<Huawei> debugging hwtacacs all
CAUTION
Debugging affects the system performance. So, after debugging, run the undo debugging all
command to disable the debugging immediately.
l If no debugging information is displayed, the router configuration is incorrect. Check that
the HWTACACS server template is applied to the domain.
The following configuration file shows that the HWTACACS server template hwtacacs is
bound to the domain huawei.
#
hwtacacs-server template hwtacacs
hwtacacs-server authentication 2.2.2.2
#
aaa
authentication-mode hwtacacs
domain default
domain huawei
hwtacacs-server hwtacacs
#
l If debugging information is displayed, proceed according to the debugging information.
Issue 02 (2012-03-30)

302

Troubleshooting
Issue 02 (2012-03-30)
10 Security
Solution
Nov 10 2010 15:43:35.500.6 Huawei TAC/

7/Event:HandleReqMsg: Session status
is not connect now.
Nov 10 2010 15:43:35.500.7 Huawei TAC/
7/Event:statistics: transmit flag:
1-SENDPACKET, server flag: 0authentication, packet flag: 0xff
Nov 10 2010 15:43:35.550.1 Huawei TAC/
7/Event:HandleResp: Session status is
connect now.
Nov 10 2010 15:43:35.550.2 Huawei TAC/
7/Event: Tac packet sending success!
version:c0 type:1-authentication
sequence:1 flag:1-UNENCRYPTED_FLAG
session id:908 length:24 serverIP:
10.138.88.209 vrf:0
The HWTACACS module sent an

authentication packet. This message
indicates that the AR1200 can send
HWTACACS authentication packets.
Nov 10 2010 15:49:18.430.6 Huawei TAC/

7/Event:HandleReqMsg: Session status
is not connect now.
Nov 10 2010 15:49:18.430.7 Huawei TAC/
7/Event:statistics: transmit flag:
1-SENDPACKET, server flag: 0authentication, packet flag: 0xff
Nov 10 2010 15:49:18.480.2 Huawei TAC/
7/Event:HandleResp: Session status is
connect now.
Nov 10 2010 15:49:18.480.3 Huawei TAC/
7/Event: Tac send packet error!
The HWTACACS authentication server did

not send any authentication response
packets. This may be because the link
between the AR1200 and the HWTACACS
server is Down, the HWTACACS server
has not restarted, or the HWTACACS
server fails.
In this case, check that the router IP address
and HWTACACS service port numbers
configured on the HWTACACS server are
the same as those configured on the
AR1200, and that the HWTACACS service
is enabled.

303

Troubleshooting
10 Security
Solution
Nov 10 2010 16:02:35.760.1 Huawei TAC/

7/Event:
version:c0 type:AUTHEN_REPLY
seq_no:6 flag:UNENCRYPTED_FLAG
session_id:0x4ff8 length:6
pstPacketAll->ulDataLen:6
pstAuthenReply:ucStatus=2 ucflags=0
usServerMsgLen=0 usDataLen=0
status:AUTHEN_STATUS_FAIL
flag:REPLY_FLAG_ECHO
server_msg len:0 data len:0
server_msg: data:
The HWTACACS server returned an

authentication failure packet. The possible
causes of authentication failure are:
l The router IP address and the shared key
are not configured on the HWTACACS
server.
l The shared key configured on the
HWTACACS server is different from
the shared key configured on the
AR1200.
l The user account is not configured on
the HWTACACS server, or the user
name format configured in the
HWTACACS server template is
different from that on the HWTACACS
server. For example, the AR1200 sends
the user name without the domain name
but the HWTACACS server requires the
user name with the domain name.
l The password entered by the user is
different from the password configured
on the HWTACACS server.
If any of the preceding errors exist, modify
the configuration on the HWTACACS
server. After configuration modification,
check whether the user can pass the
authentication. If the fault persists, go to
step 5.
Step 5 Check the user type.

l If the user is a Telnet user or an FTP user, rectify the fault according to "2.2.1 The User Fails
to Log in to the Server Through Telnet" or "The User Fails to Log in to the Server Through
FTP."
l If the user is a network access user, rectify the fault according to "10.3 NAC
Troubleshooting."
personnel:
----End
Issue 02 (2012-03-30)

304

Troubleshooting
10 Security
Relevant Alarms
None.
Relevant Logs
None.

Users Are Forced Offline 10-plus Seconds After They Log In
Fault Symptom
As shown in Figure 10-3, users access the network through RouterB, which provides
authentication, authorization, and accounting for users.
RouterB uses the RADIUS protocol to perform authentication and accounting. The RADIUS
server fails, and the administrator uses local authentication.
Users are forced offline 10-plus seconds after they log in.
Figure 10-3 Networking diagram of user access
Domain huawei
RouterB
Network
129.7.66.66/24
RouterA
Destination
network
Issue 02 (2012-03-30)

129.7.66.67/24
305

Troubleshooting
10 Security
Fault Analysis
1.
Run the display trapbuffer and display logbuffer commands on Router B to check
whether a trap or a log indicating that users are forced offline is recorded. The following
trap information is displayed:
AAA cut user!
2.
Run the display current-configuration command on Router B to check the AAA

configuration. The command output shows that local authentication and RADIUS
accounting are adopted. Details are as follows:
radius-server template provera
radius-server shared-key simple 123456
radius-server accounting 129.7.66.66 1813
undo radius-server user-name domain-included
#
aaa
local-user telenor password simple 123456
#
authentication-scheme provera
authentication-mode radius local
#
#
accounting-scheme provera
accounting-mode radius
accounting realtime 10
#
domain default
#
domain huawei
authentication-scheme provera
accounting-scheme provera
radius-server provera
#
set authentication password simple 123456
history-command max-size 256
screen-length 15
Because the RADIUS server is unavailable, real-time accounting fails. You can run the
accounting interim-fail command to configure a real-time accounting failure policy to
determine whether to keep users online or force them offline after the real-time accounting
fails. If the accounting interim-fail command is not configured, Router B adopts the
default setting to force users offline when real-time accounting fails.
It can therefore be concluded that RADIUS accounting failure causes users to be forced
offline. The period after which login users are forced offline is determined by the
retransmission timeout period and retransmission times, which are configured by using the
radius-server{ retransmit retry-times | timeout time-value }* command. By default, data
is retransmitted every 5 seconds for three consecutive times. If data fails to be retransmitted
15 seconds after login, users are forced offline.
Procedure
Step 2 Run the aaa command to enter the AAA view.
Issue 02 (2012-03-30)

306

Troubleshooting
10 Security
Step 3 Run the domain huawei command to enter the Huawei domain view.
Step 4 Run the undo accounting-scheme provera command to configure the default accounting
scheme (non-accounting) for users in the domain.
Select any of the following methods to clear the fault:
l Run the accounting-mode none command to change the accounting mode to nonaccounting.
Administrator users such as Telnet users and FTP users are not charged; therefore, you can
change their accounting mode to non-accounting.
l Run the accounting interim-fail online command to keep users online when real-time
accounting fails.
l Run the undo accounting-scheme provera command to configure the default accounting
scheme (non-accounting) for the domain.
In this troubleshooting case, RouterB mainly authenticates Telnet users that do not need to be
charged; therefore, the non-accounting scheme applies. You can run the undo accountingscheme provera command to configure the non-accounting scheme.
After the preceding configurations, users can log in without being forced offline. The fault is
cleared.
----End
Summary
On the access network using AAA authentication, if the remote server is unavailable and local
authentication is adopted, the accounting scheme must be non-accounting. Otherwise, users are
forced offline.
A User Cannot Pass the HWTACACS Authentication with Valid User Name and
Password
Fault Symptom
As shown in Figure 10-4, the four routers are in the same autonomous system (AS). They are
configured with the Interior Border Gateway Protocol (IBGP), Intermediate System To
Intermediate System (IS-IS), AAA, QoS, and the Simple Network Management Protocol
(SNMP). The customer wants to configure a private AS number on the routers, replace IBGP
with the Exterior Border Gateway Protocol (EBGP), and replace IS-IS with the Open Shortest
Path First (OSPF). The IS-IS routing table contains only the routes to the IP addresses of
connected interfaces and loopback interfaces.
Issue 02 (2012-03-30)

307

Troubleshooting
10 Security
Figure 10-4 HWTACACS authentication fails
202.97.30.227/32
Loopback0
Loopback0
RouterA
RouterB
TACACS server
202.102.216.245/24
RouterD
RouterC
Loopback0
Loopback0
After the configuration, the user fails to pass the Huawei Terminal Access Controller AccessControl System (HWTACACS) authentication by using the valid user name and password.
Fault Analysis
1.
Check the user name and password configured on the HWTACACS server. The configured
user name and password are the same as those entered by the user.
2.
Run the ping command on RouterA to ping the HWTACACS server. The ping operation
is successful.
3.
Run the display current-configuration command on RouterA to check the HWTACACS

configuration. The following configuration is displayed in the HWTACACS server
template:
hwtacacs-server source-ip 202.97.30.227
In the preceding information, 202.97.30.227 is the IP address of the loopback interface on

RouterA.
This IP address is contained in the IS-IS routing table and is used as the source IP address
of HWTACACS packets sent by RouterA. The IS-IS configuration has been deleted;
therefore, RouterA cannot receive the authentication response packet with the destination
address 202.97.30.227 sent from the HWTACACS server. This may be the cause for the
HWTACACS authentication failure.
4.
Run the ping -a 202.97.30.227 202.102.216.245 command on RouterA to check whether

the loopback interface address can ping the IP address of the HWTACACS server. Here,
the IP address of the HWTACACS server is 202.102.216.245. The ping operation fails.
5.
Run the display ip routing-table command on RouterA. The command output shows that
the IP address of this loopback interface is not advertised by the OSPF protocol.
According to the preceding information, you can confirm that the authentication fails
because the IS-IS configuration is deleted and the OSPF protocol does not advertise the
loopback interface address.
Issue 02 (2012-03-30)

308

Troubleshooting
10 Security
Procedure
Step 2 Run the ospf process-id command to enter the OSPF view.
Step 3 Run the area area-id command to enter the OSPF area view.
Step 4 Run the network address wildcard-mask command to advertise the IP address of loopback
interface.
After the configuration is complete, the user can log in by using the user name and password.
----End
Summary
Before modifying the routing protocol configuration, record the current configuration. After
modifying the configuration, check whether the new configuration meets the network
requirements and whether the modification has impacts on other configurations.
A Telnet User Fails to Log In Because the User Account Is Not Configured on the
RADIUS Server
Fault Symptom
On the AR1200, 802.1x is enabled and the authentication mode is set to Remote Authentication
Dial In User Service (RADIUS) authentication. After the configuration, 802.1x users pass the
authentication successfully, but a Telnet user fails to log in to the AR1200.
Fault Analysis
1.
The 802.1x users pass the authentication, indicating that the link between the AR1200 and
the RADIUS server works properly.
2.
Run the display current-configuration command on the AR1200 to check the current
configuration.
......
dot1x enable
#
radius-server template remote
radius-server shared-key simple 123456
radius-server accounting 192.168.1.27 1813
#
......
port hybrid pvid vlan 10
dot1x enable
dot1x max-user 1
dot1x port-method port
dot1x reauthenticate
......
aaa
authentication-scheme cams
authentication-mode radius
#
Issue 02 (2012-03-30)

309

Troubleshooting
10 Security
authorization-scheme cams
authorization-mode none
#
accounting-scheme account
accounting-scheme cams
#
domain default
radius-server remote
#
radius-server remote
#
......
#
user-interface maximum-vty 15
user-interface con 0
idle-timeout 0 0
#
The preceding information indicates that the user domain is default, the authentication
mode is RADIUS authentication, and the authorization mode is none. The 802.1x users use
port-based 802.1x authentication. Telnet users are authenticated and authorized by using
the default_admin domain. The default_admin domain uses RADIUS authentication and
has the same configurations as the default domain. The Telnet user fails in the RADIUS
authentication. The possible cause is that the user name and password of the Telnet user is
not configured on the RADIUS server.
3.
Check the configuration of the RADIUS server. The user name and password of the Telnet
user is not found on the RADIUS server.
To rectify the fault, add the user name and password of the Telnet user to the RADIUS server
or configure the authentication mode of the Telnet user to local authentication.
Procedure
l
Add the user name and password of the Telnet user to the RADIUS server. For the
configuration procedure, see the configuration guide of the RADIUS server.
Configure the authentication mode of the Telnet user to local authentication on the
AR1200.
Create a new domain for the Telnet user.
[Huawei] aaa
[Huawei-aaa] domain telnet
[Huawei-aaa-domain-telnet]
Use the default authentication, authorization, and accounting schemes in the domain, that
is, local authentication, local authorization, and no accounting.
<Huawei> display domain name telnet
Domain-name
Domain-state
Authentication-scheme-name
Issue 02 (2012-03-30)
: telnet
: Active
: default

310

Troubleshooting
Accounting-scheme-name
Authorization-scheme-name
Service-scheme-name
RADIUS-server-template
HWTACACS-server-template
10 Security
:
:
:
:
:
default
-
<Huawei> display authentication-scheme default

Authentication-scheme-name
: default
Authentication-method
: Local
Authentication-super method
: Super authentication-super
<Huawei> display authorization-scheme default
--------------------------------------------------------------------------Authorization-scheme-name
: default
Authorization-method
: Local
......
<Huawei> display accounting-scheme default
Accounting-scheme-name
Accounting-method
: default
: None
Create a local user whose user name contains the domain name. The Telnet user needs to
enter the domain name for authentication.
[Huawei] aaa
[Huawei-aaa] local-user telnetuser@telnet password simple 123456
[Huawei-aaa] local-user telnetuser@telnet service-type telnet
----End
Summary
Use different authentication modes for access users (such as 802.1x user), Telnet users, and
Secure Shell (SSH) users. When a Telnet user fails to log in to the AR1200, the possible cause
is that an incorrect authentication scheme is configured in the VTY user interface view and AAA
view of the AR1200, or on the remote authentication server.
10.2 ARP Security Troubleshooting

10.2.1 The ARP Entry of an Authorized User Is Maliciously
Modified
Common Causes
This fault is commonly caused by the following:
l
An attacker sends bogus ARP packets to modify the ARP entry of the authorized user.
An authorized user is disconnected from the Internet, but the links and routes are normal. The
possible cause is that an attacker sends bogus ARP packets to modify the ARP entry of the user
on the gateway. As a result, this user is disconnected from the network.
Issue 02 (2012-03-30)

311

Troubleshooting
10 Security

Figure 10-5 Troubleshooting flowchart for malicious modification to the ARP entry of an
authorized user
User ARP entry
is maliciously
modified
Is ARP
anti-spoofing
configured?
No
Configure ARP
anti-spoofing
Is the fault
rectified?
Yes
No
Yes
Is
MAC address
changed?
fixed-mac mode
No
Yes
Check type of ARP
anti-spoofing
Seek technical
support
fixed-all mode
No
Does the
router send ARP
requests?
send-ack mode
Yes
Yes
Increase rate-limit
value
Is the fault
rectified?
Yes
No
Are ARP replies

discarded by
CPCAR?
Yes
Is network
connection
normal?
No
No
No
Yes
Does the
router receive
ARP replies?
No
Is the fault
rectified?
Yes
Seek technical
support
End
End
Issue 02 (2012-03-30)

312

Troubleshooting
10 Security
NOTE
Procedure
Step 1 Run the display arp anti-attack configuration entry-check command on the AR1200 to check
that ARP anti-spoofing is enabled.
l If the following information is displayed, ARP anti-spoofing is not enabled.
ARP anti-attack entry-check mode: disabled
Run the arp anti-attack entry-check { fixed-mac | fixed-all | send-ack } enable command
to enable ARP anti-spoofing.
NOTE
Before enabling ARP anti-spoofing, run the reset arp interface interface-type interface-number
command to delete the ARP entries learned by the user-side interface.
l If the mode of ARP anti-spoofing is set to send-ack, go to step 2.

l If the mode of ARP anti-spoofing is set to fixed-mac, go to step 3.
l If the mode of ARP anti-spoofing is set to fixed-all, go to step 4.
Step 2 Perform the following steps to locate the fault in send-ack mode.
1.
Capture packets on the user-side interface by configuring port mirroring. If the AR1200
does not send an ARP request, go to step 4.
2.
If the AR1200 sends ARP requests but does not receive an ARP reply, check that the
network connection between the AR1200 and the user is normal.
3.
If the AR1200 receives ARP reply packets from the user, run the display cpu-defend
statistics packet-type arp-reply command to check statistics about ARP reply packets. If
the number of dropped ARP reply packets keeps increasing, the possible cause is that the
rate of ARP reply packets exceeds the CPCAR. In this case, increase the rate limit value
by using the packet-type command.
4.
Step 3 Run the display arp all | include ip-address command to check the modified information in the
ARP entry.
If the interface number or VLAN ID is changed, you do not need to take any action because it
is normal in fixed-mac mode. If the MAC address is changed, go to step 4.
----End

Relevant Alarms
l
Issue 02 (2012-03-30)
1.3.6.1.4.1.2011.5.25.165.2.2.2.2
313

Troubleshooting
10 Security
Relevant Logs
None.
10.2.2 The Gateway Address Is Maliciously Changed

Common Causes
l
l
An attacker sends bogus gratuitous ARP packets to users. Users change their gateway
address after receiving the gratuitous ARP packets.
An attacker sends bogus ICMP unreachable packets or ICMP redirect packets to users.
An attacker sends gratuitous ARP packets with the source IP address being the IP address of the
gateway on the LAN. After receiving the gratuitous ARP packets, hosts on the LAN change
their gateway MAC address to the MAC address of the attacker. As a result, the hosts cannot
access the network.
Figure 10-6 Troubleshooting flowchart for gateway address spoofing
The gateway
address is
maliciously changed
Does the
router function as the
gateway?
No
Yes
Configure the router as
the gateway
No
Yes
Is ARP
gateway anti-collision
configured?
No
Configure gateway anticollision
Is the fault
rectified?
Yes
No
Yes
Are gateway
anti-collision entries
generated?
Yes
Configure a policy to
discard attack packets
Is the fault
rectified?
Yes
No
No
Issue 02 (2012-03-30)
Is the fault
rectified?

End
314

Troubleshooting
10 Security
NOTE
Procedure
Step 1 Check that the AR1200 functions as the gateway. If the AR1200 is not the gateway, the gateway
anti-collision function does not take effect.
You can use either of the following methods to check whether the AR1200 is the gateway:
l Run the display arp command to view the type of the ARP entry corresponding to the
gateway IP address.
If the ARP entry type is displayed as I-, the gateway IP address is an interface address on
the AR1200.
<Huawei> display arp
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE
INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
-----------------------------------------------------------------------------1.1.1.1
0022-0033-0044
I Vlanif10
l Run the display ip routing-table gateway address command to check whether a route to the
gateway address exists.
If a route to the gateway address is displayed in the command output, the AR1200 is the
gateway.
<Huawei> display ip routing-table 1.1.1.1 (gateway address)
--------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination/Mask
Proto
Pre
1.1.1.1/24
Direct 0
Cost
0
Flags NextHop
D
127.0.0.1
Interface
Loopback0
If the AR1200 is not the gateway, configure it as the user gateway.

Step 2 Run the display arp anti-attack configuration gateway-duplicate command to check that
ARP gateway anti-collision is enabled.
If ARP gateway anti-collision is not enabled, run the arp anti-attack gateway-duplicate
enable command to enable this function.
Step 3 Run the display current-configuration command to check whether the AR1200 is enabled to
send gratuitous ARP packets.
l When the AR1200 functions as a gateway, the AR1200 needs to send gratuitous ARP packets
so that users can periodically update the ARP entry of the gateway. To enable the AR1200
to send gratuitous ARP packets, use the arp gratuitous-arp send enable command in the
system view or VLANIF interface view.
l By default, the AR1200 sends a gratuitous ARP packet every 90 seconds after this function
is enabled. You can set the interval by using the arp gratuitous-arp send interval command.
l If the AR1200 has been enabled to send gratuitous ARP packets, go to step 4.
Issue 02 (2012-03-30)

315

Troubleshooting
10 Security
Step 4 Run the display arp anti-attack gateway-duplicate item command to check the anti-collision
entries.
l If an entry is displayed, you can view it to find the IP address, MAC address, and source
interface of the attacker. Add the attacker to the blacklist or configure a blackhole MAC entry
according to attacker information. Subsequently, packets from the attacker will be discarded.
l If no entry is displayed, go to step 5.
----End

Relevant Alarms
l
1.3.6.1.4.1.2011.5.25.165.2.2.2.1
Relevant Logs
None.
10.2.3 User Traffic Is Interrupted by a Large Number of Bogus ARP

Packets
Common Causes
l
An attacker sends a large number of bogus ARP packets , thus increasing the load of the
destination network segment. These ARP packets are sent to the CPU, causing a high CPU
usage. DoS attacks may also be initiated in this case.
The AR1200 uses the CPCAR mechanism to limit the rate of ARP packets sent to the CPU. If
an attacker sends a large number of bogus ARP packets, valid ARP packets are also discarded
when the bandwidth limit is exceeded. Consequently, user traffic is interrupted.
Issue 02 (2012-03-30)

316

Troubleshooting
10 Security
Figure 10-7 Troubleshooting flowchart for traffic interruption caused by bogus ARP packets
User traffic is
interrupted by ARP
attack packets
Do user
ARP entries exist?
Yes
Yes
Is the fault
rectified?
No
No
Are ARP
packets discarded by
CPCAR?
No
Seek technical
support
Yes
Is CPU usage
of the router high?
Yes
Find attack source and

discard attack packets
No
Increase the rate limit for
ARP requests
Is the fault
rectified?
Yes
End
No
Seek technical
support
NOTE
ARP attack packets include ARP request packets and ARP reply packets. In the following procedure, the
ARP attack packets are ARP request packetes. If the ARP attack packets on your network are ARP reply
packets, change the arp-request parameter to arp-reply.
Procedure
Step 1 Run the display arp command on the AR1200 to view ARP entries of authorized users.
l If ARP entries of authorized users are displayed, the AR1200 has learned the ARP entries,
and traffic interruption is caused by a short link disconnection. In this case, rectify link faults.
Issue 02 (2012-03-30)

317

Troubleshooting
10 Security
l If no ARP entry is displayed, go to step 2.

Step 2 Run the display cpu-defend statistics packet-type arp-request command to view the statistics
about ARP requests.
l If the count of dropped ARP requests is 0, go to step 8.
l If the count of dropped ARP requests is not 0, the rate of ARP requests exceeds the CPCAR
rate limit and excess ARP requests are discarded. Go to step 3.
Step 3 Run the display cpu-usage command to check the CPU usage of the main control board.
l If the CPU usage is in the normal range but ARP requests are discarded, the rate limit is too
small. Go to step 4.
l If the CPU usage is high, the CPU may be attacked by ARP packets. Go to step 5.
Step 4 Run the packet-type command in the attack defense policy view to increase the rate limit for
ARP requests and apply the attack defense policy.
Step 5 Capture packets on the user-side interface, and find the attacker according to the source addresses
of ARP requests.
If a large number of ARP requests are sent from a source address, the AR1200 considers the
source address to be an attack source. Add the source address to the blacklist or configure a
blackhole MAC address entry to discard ARP requests sent by the attacker.
Step 6 Run the arp speed-limit source-ip command in the system view to set the rate limit for ARP
packets from the attack source.
By default, ARP packet suppression based on source IP addresses is enabled, and the maximum
rate of ARP requests is limited to 5 pps. After the rate of ARP requests reaches this limit, the
AR1200 discards subsequent ARP requests.
personnel:
----End

Relevant Alarms
l
1.3.6.1.4.1.2011.5.25.165.2.2.2.3
1.3.6.1.4.1.2011.5.25.165.2.2.2.4
1.3.6.1.4.1.2011.5.25.165.2.2.2.5
1.3.6.1.4.1.2011.5.25.165.2.2.2.6
1.3.6.1.4.1.2011.5.25.165.2.2.2.11
Relevant Logs
None.
10.2.4 IP Address Scanning Occurs

Issue 02 (2012-03-30)

318

Troubleshooting
10 Security
Common Causes
l
An attacker sends a large number of destination unreachable packets to the AR1200, and
the packets trigger a large number of ARP Miss messages. In addition, the AR1200 sends
ARP requests to trigger ARP learning, causing a high CPU usage.
An attacker sends a large number of destination unreachable packets to the AR1200. The packets
are sent to the CPU and trigger a large number of ARP Miss messages. In addition, the
AR1200 sends ARP requests to trigger ARP learning, causing a high CPU usage.
Figure 10-8 Troubleshooting flowchart for IP address scanning
IP address
scanning attack
causes a high CPU
usage
Is ARP
Miss suppression
configured?
No
Configure ARP Miss

suppression
Is the fault
rectified?
Yes
No
Yes
Is rate limit for

ARP Miss messages
too large?
Yes
Reduce the rate limit
Is the fault
rectified?
Yes
No
No
Seek technical
support
End
NOTE
Issue 02 (2012-03-30)

319

Troubleshooting
10 Security
Procedure
Step 1 Run the display cpu-usage command on the AR1200 to check the CPU usage of the board.
In the command output, ARP indicates the ARP packet processing task.
Step 2 Run the display arp command to view the learned ARP entries.
If the MAC address in an ARP entry is in Incomplete state, the AR1200 fails to learn the ARP
entry.
<Huawei> display arp
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE
INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
--------------------------------------------------------------------10.10.10.12
0018-82d2-0e08
I Vlanif10
10.10.10.13
Incomplete
0
D-0
Vlanif20
3004/10.10.10.14
Incomplete
0
D-0
Eth2/0/0
3004/20.20.20.33
000c-76bd-43d6
I Eth2/0/00
20.20.20.55
0013-7227-842f 17
D-0
Eth2/0/0
...
3003/-
Generally, the possible causes are: the AR1200 fails to send ARP requests, the ARP requests
are discarded during transmission, or no ARP reply is received. If the CPU usage of the ARP
task is high, the AR1200 fails to send ARP requests and generates ARP Miss messages. Go to
step 3.
Step 3 Capture packets on the user-side interface and check the source addresses of IP packets.
Step 4 Run the display arp anti-attack configuration arpmiss-speed-limit command to view the
configuration of ARP Miss suppression.
l If a source IP address is specified in the ARP Miss suppression command, the AR1200 checks
whether the specified IP address is the source address of the received IP packets. If so, the
AR1200 limits the rate of ARP Miss messages based on the rate limit configured in this
command. If not, the AR1200 limits the rate of the ARP Miss messages based on the limit
set in the command without a source IP address specified.
l By default, ARP Miss suppression is enabled, and the maximum rate of ARP Miss messages
is limited to 5 pps. When the rate of ARP Miss messages triggered by packets from the
specified IP address exceeds the limit, the AR1200 discards the packets sent from the IP
address. You can change the rate limit for ARP Miss messages by running the arp-miss
speed-limit source-ip command in the system view.
Step 5 Run the display arp anti-attack configuration arpmiss-rate-limit command on the AR1200
to view the configuration of ARP Miss suppression.
l If a large number of ARP Miss packets are triggered on an interface, in a VLAN, or on the
entire device within a certain period, the AR1200 is busy broadcasting ARP request packets
and its performance deteriorates. After ARP Miss suppression is configured, the AR1200
counts ARP Miss packets generated within a specified period and discards excess ARP Miss
packets.
l By default, the maximum rate of ARP Miss packets is 100 packets per second. To change
the rate limit of ARP Miss packets, run the arp-miss anti-attack rate-limit command in the
system view, VLAN view, or interface view.
personnel:
Issue 02 (2012-03-30)

320

Troubleshooting
10 Security

----End

Relevant Alarms
l
1.3.6.1.4.1.2011.5.25.165.2.2.2.8
1.3.6.1.4.1.2011.5.25.165.2.2.2.12
Relevant Logs
None.
10.2.5 ARP Learning Fails

Common Causes
The following table describes the possible causes of an ARP learning failure (assuming that the
AR1200 sends an ARP request to trigger ARP learning).
Condition
Possible Cause
The ARP request is not sent out.
A large number of ARP requests are triggered

by ARP Miss messages, and the AR1200 has
not processed this ARP request.
The remote device does not receive the ARP

request.
The link between the AR1200 and the remote

device is faulty, so the ARP request is
discarded on the network.
The remote device receives the ARP request

but discards it.
The remote device receives a large number of

ARP packets. The rate of ARP packets
exceeds the CAR, so the device discards the
ARP request sent by the AR1200.
The AR1200 does not receive the ARP reply The link between the AR1200 and the remote
sent by the remote device.
device is faulty, so the ARP request is
discarded on the network.
Issue 02 (2012-03-30)
The AR1200 receives the ARP reply but does

not send it to the CPU.
The rate of ARP packets received by the

AR1200 exceeds the CPCAR or ARP packet
rate limit, so the ARP reply is discarded.
The ARP reply is sent to the CPU but is

discarded.
The ARP module of the AR1200 is faulty.

321

Troubleshooting
10 Security
Figure 10-9 Troubleshooting flowchart for ARP learning failure
The router fails to
learn ARP entries
Does the link

between the router and
remote device function
properly?
No
Is the fault
rectified?
Yes
No
Yes
Does the router process

ARP packets correctly?
No
Rectify the fault according to

debugging information.
Ensure that the router sends
ARP requests and does not
discard ARP responses
Is the fault
rectified?
Ensure that the remote

device responds to ARP
requests
Is the fault
rectified?
No
Yes
Does the remote

device process ARP
packets correctly?
No
Yes
Yes
No
Yes

End
NOTE
Procedure
Step 1 Check that the link between the AR1200 and the remote device works properly.
l Perform ping operations between the AR1200 and the remote device. If the ping operations
fail, check the routing configuration on the two devices.
Issue 02 (2012-03-30)

322

Troubleshooting
10 Security
l View traffic statistics on the two devices to check whether packets are discarded on the link.
If any device on the link does not support the traffic statistics function, perform a ping test
to check whether packets are discarded on the device. If packets are discarded on the link,
rectify the link fault.
Step 2 Check that the AR1200 processes ARP packets properly.
Run the debugging arp packet interface interface-type interface-number command in the user
view to enable ARP debugging. Check whether information about ARP request and ARP reply
packets is displayed.
NOTE
In the debugging information, the operation field indicates the ARP packet type. The value 1 indicates
ARP request packets and the value 2 indicates ARP reply packets.
l If the AR1200 does not send any ARP request packet, rectify the fault according to 10.2.4
IP Address Scanning Occurs.
l If the AR1200 does not receive any ARP reply packet, the ARP reply packets sent by the
remote device may be discarded by the CPCAR mechanism. Go to step 3.
l If the AR1200 receives ARP reply packets, go to step 5.
Step 3 Check whether ARP reply packets are discarded.
l Run the display cpu-defend statistics packet-type arp-reply command to view statistics
about ARP reply packets.
If the Drop value keeps increasing, the rate of ARP reply packets exceeds the CPCAR. Run
the packet-type command to increase the CPCAR for ARP reply packets.
l Run the display this command in the interface view and system view to check whether a
rate limit is set for ARP packets.
If the rate limit is set and the rate of ARP packets is high, ARP reply packets may be discarded.
Run the arp anti-attack rate-limit command to increase the rate limit.
Step 4 Check that the remote device correctly receives ARP request packets and sends ARP reply
packets.
If the remote device is a Huawei device, perform step 2 on the device. If the remote device is a
non-Huawei device, see the manual of the device.
personnel:
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2012-03-30)

323

Troubleshooting
10 Security
10.3 NAC Troubleshooting

10.3.1 802.1x Authentication of a User Fails
Common Causes
l
Some parameters are set incorrectly or not set, such as the parameters of 802.1x
authentication, AAA authentication domain, authentication server, and authentication
server template.
The user name or password entered by the user is incorrect.
The number of online users reaches the maximum.
A user fails to pass the 802.1x authentication.
Issue 02 (2012-03-30)

324

Troubleshooting
10 Security
Figure 10-10 Troubleshooting flowchart for 802.1x authentication failure

A user fails to pass the
802.1x authentication
Is 802.1x
authentication enabled?
No Enable 802.1x globally and

on the interface
Is the fault
rectified?
Yes
No
Yes
Is 802.1x
No
Ensure authentication
method is the same as that
on the server
Yes
Is the fault
rectified?
Yes
No
Is AAA
No
Configure domain and

authentication server
template correctly
Is the fault
rectified?
Yes
No
Yes
Are user name and
password correct?
No
Use correct user name and

password
Is the fault
rectified?
Yes
No
Yes
Is the max
reached?
Yes
This is not a fault
End
No
NOTE
Procedure
Step 1 Check that 802.1x authentication is enabled on the AR1200.
Run the display dot1x command to check whether 802.1x authentication is enabled globally or
on the user-side interface. If Global 802.1x is enabled or 802.1x protocol is enabled is not
displayed, 802.1x authentication is not enabled. Run the dot1x enable command to enable
802.1x authentication globally and on the user-side interface.
Issue 02 (2012-03-30)

325

Troubleshooting
10 Security
CAUTION
802.1x authentication and MAC address authentication cannot be enabled on the same interface.
If MAC address authentication is enabled on the interface, the system displays an error message
when you run the dot1x enable command.
Step 2 Check that 802.1x authentication is configured correctly.
Run the display dot1x command to check the 802.1x configuration.
The AR1200 supports the following authentication methods for 802.1x: Password
Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and
Extensible Authentication Protocol (EAP). The authentication method is configured by using
the dot1x authentication-method command.
l The authentication method on the AR1200 must be the same as that on the authentication
server.
l EAP authentication and local authentication cannot be configured simultaneously. If the
authentication method for 802.1x users is EAP, go to step 3.
l If the authentication method for 802.1x users is PAP, check whether the client supports PAP
authentication. If the client does not support PAP authentication, change the authentication
method to CHAP or EAP.
Step 3 Check the AAA configuration.
1.
Check whether the user name contains the domain name.

l If user name does not contain the domain name, the user is authenticated in the default
domain. In this case, check the authentication template bound to the default domain.
l If the user name contains the domain name, the user should be authenticated in the
specified domain. However, if the domain name is not found, the authentication fails.
In this case, check the authentication template bound to the specified domain.
2.
Check the authentication scheme applied to the user domain on the AR1200.
l If RADIUS or HWTACACS authentication is configured for the user domain, check
whether the user account and the user attributes are created on the authentication server.
For details on RADIUS troubleshooting and HWTACACS troubleshooting, see 10.1.1
RADIUS Authentication Fails and 10.1.2 HWTACACS Authentication Fails. For
details on checking the authentication server, go to step 4.
l If local authentication is configured for the user domain, run the display local-user
command to check whether the local user name and password are created on the
AR1200. If not, run the local-user command to create the local user name and password.
l If the authentication scheme is none, go to step 6.
3.
Run the display accounting-scheme command to check the accounting scheme. If

accounting is configured on the AR1200 but the authentication server does not support
accounting, the user will be forced offline after going online. To allow the user to go online,
disable the accounting function in the user domain or run the accounting start-fail
online command in the accounting scheme view to configure the AR1200 to keep the user
online if the accounting fails.
Step 4 Check the configuration of the authentication server.

Issue 02 (2012-03-30)

326

Troubleshooting
10 Security
l If the user information does not exist on the authentication server, create the user name and
password on the authentication server.
l If user attributes on the authentication server contain VLAN authorization information but
the VLAN is not created on the AR1200, user authorization fails. To rectify the fault, create
the VLAN.
l If user attributes on the authentication server contain ACL authorization information (ACL
number or ACL content), but the ACL is not created on the AR1200 or the ACL format is
different from that required by the AR1200, user authorization fails. To rectify the fault,
create the ACL. Ensure that the ACL format used by the authentication server is the same
that required by the AR1200.
NOTE
The AR1200 requires the following ACL format in the user attributes:
acl acl-num key1 key-value1... keyN key-valueN permit/deny
If the display access-user user-id command output contains the user IP address and Dynamic ACL
desc (Effective), the ACL specified in the user attribute takes effect.
Table 10-1 Description

Field
Description
Field
Description
acl
Delivers the ACL

content.
acl-num
Specifies the ACL

number. The value
ranges from 10000
to 10999.
permit
Allows users
matching the rules
to access the
network.
deny
Prohibits users
matching the rules
from accessing the
network.
keyM (1 M N)
ndicates a keyword
in the ACL,
including src-ip
(source IP address),
src-ipmask (mask of
source IP address),
and tcp-srcport
(source TCP port
number).
key-valueM (1 < M
< N)
Specifies the value

of a keyword, which
can be an IP address,
a mask, or a port
number.
If the configurations of the AR1200 and the authentication server are correct, go to step 5.
Step 5 Check that the user name and password entered by the user are correct.
If RADIUS authentication is used and the authentication method is CHAP or PAP, run the testaaa command to check whether the user name and password can pass the RADIUS
authentication.
l If the authentication fails, check the configuration of the RADIUS server and RADIUS
configuration on the AR1200. For details, see Troubleshooting Procedure in 10.1.1
RADIUS Authentication Fails.
Issue 02 (2012-03-30)

327

Troubleshooting
10 Security
l If user passes the authentication, check the option settings on the client or capture packets
on the network adapter of the client to check whether the client sends authentication packets
correctly.
If preceding configurations are correct, go to step 6.
Step 6 Run the display dot1x interface interface-type interface-number command on the AR1200 to
check whether the number of online 802.1x users reaches the maximum.
If the number of online 802.1x users reaches the maximum, the AR1200 does not trigger
authentication for subsequent users, and subsequent users cannot go online.
personnel:
----End

Relevant Alarms
l
1.3.6.1.4.1.2011.5.25.40.4.2.1
Relevant Logs
None.
10.3.2 MAC Address Authentication of a User Fails

Common Causes
l
Some parameters are set incorrectly or not set, such as the parameters of MAC address
authentication, authentication domain, authentication server, and authentication server
template.
The number of online users reaches the maximum.
A user fails to pass the MAC address authentication.
Issue 02 (2012-03-30)

328

Troubleshooting
10 Security
Figure 10-11 Troubleshooting flowchart for MAC address authentication failure

A user fails to
pass MAC
authentication
Is MAC
authentication
enabled?
No
Enable MAC
authentication globally and
on interface
Is the fault
rectified?
Yes
No
Yes
Is
the user name
correct?
No
Modify user name

configuration
Is the fault
rectified?
Yes
No
Yes
Is AAA
No
Configure domain and

authentication server
template correctly
Is the fault
rectified?
Yes
No
Yes
Is the max
number of online
users reached?
Yes
This is not a fault
End
No
Seek technical
support
Context
When MAC address authentication is used, users do not need the dial-up software. The
authentication information such as the user name and password is generated according to the
MAC addresses of users. Similar to 802.1x authentication troubleshooting, when
troubleshooting MAC address authentication, check whether the user name and password on the
AR1200 are same as those on the authentication server and whether the domain name in the user
name is correct.
NOTE
Procedure
Step 1 Check that MAC address authentication is enabled on the AR1200.
Issue 02 (2012-03-30)

329

Troubleshooting
10 Security
Run the display mac-authen command to check whether MAC address authentication is enabled
globally or on the user-side interface. If MAC address authentication is enabled is not
displayed, MAC address authentication is not enabled. Run the mac-authen command to enable
MAC address authentication globally and on the user-side interface.
CAUTION
802.1x authentication and MAC address authentication cannot be enabled on the same interface.
If 802.1x authentication is enabled on the interface, the system displays an error message when
you run the mac-authen command.
Step 2 Check the configuration of the user name for MAC address authentication.
Run the display this command in the interface view to check the configuration of MAC address
authentication on the interface. If MAC address authentication is not configured on the interface,
the global configuration is used. Run the display mac-authen command to check the
configuration of global MAC address authentication.
MAC address authentication supports two user name formats: fixed user name and MAC
address.
l If the user MAC address is used as the user name, the AR1200 sends the MAC address of
the user terminal as the user name and password to the authentication server. The
authentication domain is configured by the mac-authen domain command. If no
authentication domain is configured, the default domain is used.
l When the fixed user name contains a domain name, this domain is used as the authentication
domain. If the fixed user name does not contain a domain name, the default domain is used
as the authentication domain.
NOTE
A MAC address may contain or not contain the delimiter (-). By default, a MAC address does not contain
the delimiter. You can use the mac-authen username macaddress format with-hyphen command to add
delimiters to a MAC address. During authentication, ensure that the format of the MAC address you entered
is the same as the MAC address format configured on the AR1200.
Check the authentication server template and AAA schemes bound to the authentication domain.
Go to step 3.
Step 3 Check the AAA configuration.
1.
Check the configuration of the authentication server template bound to the domain. Ensure
that the IP address and port of the authentication server are set correctly in the template,
and that the user name format and shared key specified in the template are the same as those
on the authentication server.
2.
Check the authentication scheme applied to the user domain on the AR1200.
l If RADIUS or HWTACACS authentication is configured for the user domain, check
whether the user account and the user attributes are created on the authentication server.
For details on RADIUS troubleshooting and HWTACACS troubleshooting, see 10.1.1
RADIUS Authentication Fails and 10.1.2 HWTACACS Authentication Fails. For
details on checking the authentication server, go to step 4.
l If local authentication is configured for the user domain, run the display local-user
command to check whether the local user name and password are created on the
AR1200. If not, run the local-user command to create the local user name and password.
Issue 02 (2012-03-30)

330

Troubleshooting
10 Security
l If the authentication scheme is none, go to step 5.

3.
Run the display accounting-scheme command to check the accounting scheme. If

accounting is configured on the AR1200 but the authentication server does not support
accounting, the user will be forced offline after going online. To allow the user to go online,
disable the accounting function in the user domain or run the accounting start-fail
online command in the accounting scheme view to configure the AR1200 to keep the user
online after the accounting fails.
Step 4 Check the configuration of the authentication server.

l If the user information does not exist on the authentication server, create the user name and
password on the authentication server.
l If user attributes on the authentication server contain VLAN authorization information but
the VLAN is not created on the AR1200, user authorization fails. To rectify the fault, create
the VLAN.
l If user attributes on the authentication server contain ACL authorization information (ACL
number or ACL content), but the ACL is not created on the AR1200 or the ACL format is
different from that required by the AR1200, user authorization fails. To rectify the fault,
create the ACL. Ensure that the ACL format used by the authentication server is the same as
that required by the AR1200.
NOTE
The AR1200 requires the following ACL format in the user attributes:
acl acl-num key1 key-value1... keyN key-valueN permit/deny
If the display access-user user-id command output contains the user IP address and Dynamic ACL
desc (Effective), the ACL specified in the user attribute takes effect.
Table 10-2 Description

Field
Description
Field
Description
acl
Delivers the ACL

content.
acl-num
Specifies the ACL

number. The value
ranges from 10000
to 10999.
permit
Allows users
matching the rules
to access the
network.
deny
Prohibits users
matching the rules
from accessing the
network.
keyM (1 M N)
ndicates a keyword
in the ACL,
including src-ip
(source IP address),
src-ipmask (mask of
source IP address),
and tcp-srcport
(source TCP port
number).
key-valueM (1 < M
< N)
Specifies the value

of a keyword, which
can be an IP address,
a mask, or a port
number.
If the configurations of the AR1200 and the authentication server are correct, go to step 5.
Issue 02 (2012-03-30)

331

Troubleshooting
10 Security
Step 5 Run the display mac-authen interface interface-type interface-number command on the
AR1200 to check whether the number of online MAC address authentication users has reached
the maximum.
If the number of online MAC address authentication users has reached the maximum, the
AR1200 does not trigger authentication for subsequent users, and they cannot go online.
personnel:
----End

Relevant Alarms
l
1.3.6.1.4.1.2011.5.25.171.2.1
Relevant Logs
None.
10.3.3 MAC Address Bypass Authentication of a User Fails

In MAC address bypass authentication, a user terminal first sends an Address Resolution
Protocol (ARP) packet or a Dynamic Host Control Protocol (DHCP) packet to the AR1200 to
trigger 802.1x authentication. If the AR1200 does not receive 802.1x packet from the terminal
within 30 seconds, the AR1200 sends the MAC address of the terminal as the user name and
password to the authentication server.
After MAC address bypass authentication is configured, the AR1200 starts MAC address
authentication automatically after a user fails to pass the 802.1x authentication. 802.1x
authentication and MAC address authentication cannot be enabled on the same interface. If
802.1x authentication is enabled on the interface, the system displays an error message when
you attempt to enable MAC address authentication. You can enable MAC address bypass
authentication by using the dot1x mac-bypass command. In MAC address bypass
authentication, the terminal MAC address is used as the user name and password. The process
of MAC address bypass authentication is the same as the process of MAC address authentication.
The troubleshooting procedure for MAC address bypass authentication failure is similar to the
troubleshooting procedure for MAC address authentication failure. For details, see 10.3.2 MAC
Address Authentication of a User Fails.
10.4 Firewall Troubleshooting

10.4.1 SYN Flood Attacks Are Detected on a Network
Due to resource restriction the TCP/IP protocol stack permits only a certain number of TCP
connections.
Issue 02 (2012-03-30)

332

Troubleshooting
10 Security
To initiate a SYN Flood attack, an attacker sends a SYN packet with a forged or nonexistent
source address to connect to a server. After receiving the SYN packet, the server replies with a
SYN-ACK packet. The receiver of the SYN-ACK packet does not exist, so a half-connection is
generated. If the attacker sends a large number of these packets, many half-connections are
generated on the attacked host. The resources on the attacked host are exhausted and users cannot
access the host until the half-connections time out.
Common Causes
l
SYN Flood attack defense is not enabled.
The packet rate threshold on the firewall is set to a large value.
Figure 10-12 shows the troubleshooting flowchart for SYN Flood attack defense.
Figure 10-12 Troubleshooting flowchart for SYN flood attack defense
SYN-Flood attack
defense is invalid
Is attack
defense enabled?
No
Enable SYNFlood attack

defense
Yes
Is the fault
rectified?
Yes
No
Yes
Is packet rate
threshold too large?
Reconfigure
packet rate
threshold
No
Is the fault
rectified?
Yes
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check that SYN Flood attack defense is enabled.
Issue 02 (2012-03-30)

333

Troubleshooting
10 Security
Run the display firewall defend flag command to check whether SYN Flood attack defense is
enabled. If the value of SYN Flood flag is Enable, SYN Flood attack defense has been enabled.
If SYN Flood attack defense is disabled, run the firewall defend syn-flood enable command
in the system view to enable it.
If SYN Flood attack defense has been enabled, go to step 2.
Step 2 Check whether the packet rate threshold is too large.
Run the display firewall defend syn-flood ip or display firewall defend syn-flood zone
command to view the IP address or zone-based packet rate threshold.
In the output information, MR(pps) indicates how many packets with the same destination IP
address can pass the firewall in one second.
NOTE
The default packet rate threshold is 1000 pps.
To set or change the packet rate threshold, run the firewall defend syn-flood command in
the system view.
If the packet rate threshold is set properly, go to step 3.
l Configuration files, log files, and alarm files of the switches
----End

Relevant Alarms
FIREWALL 1.3.6.1.4.1.2011.5.25.222.1.3.2 hwFwSecurityNotification
Relevant Logs
None.
10.5 ACL Troubleshooting

10.5.1 Packet Filtering Firewall Fails Because of Invalid ACL
Configuration
Common Causes
l
An incorrect ACL number is referenced.
The ACL rules are incorrect.
Issue 02 (2012-03-30)

334

Troubleshooting
10 Security
Figure 10-13 Troubleshooting flowchart for a packet filtering firewall failure
Packet filtering
firewall is invalid
Is referenced
ACL correct?
No
Modify ACL rules
Is the fault
rectified?
Yes
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check that the ACL referenced by the packet filtering firewall is configured correctly.
Run the display firewall interzone command to view the referenced ACL number and direction
in which the ACL is applied. Multiple ACLs may exist on the firewall. Ensure that the correct
ACL is referenced.
l If the ACL number or direction is incorrect, run the undo packet-filter { acl-number |
default { deny | permit }} { inbound | outbound } command in the interzone view to disable
packet filtering. Then run the packet-filter { acl-number | default { deny | permit }}
{ inbound | outbound } command to reconfigure the packet filtering function.
l If the ACL number and direction are correct, run the display acl command to check the
configuration of ACL rules. If the ACL rules are incorrect, modify them. If the ACL rules
are correct, go to 2.
l Configuration files, log files, and alarm files of the switches
----End
Issue 02 (2012-03-30)

335

Troubleshooting
10 Security

Relevant Alarms
None.
Relevant Logs
None.
10.6 NAT Troubleshooting

10.6.1 Internal Users Fail to Access the Public Network
Common Causes
l
Inbound and outbound interfaces through which internal users access the public network
go Down.
Outbound NAT is not properly configured on the outbound interface connected to the public
network.
The configuration of an ACL bound to outbound NAT is incorrect.
Issue 02 (2012-03-30)

336

Troubleshooting
10 Security
Figure 10-14 Troubleshooting flowchart for outbound NAT

Internal users fail
to access public
network
Does interface
receive packets ?
No
Modify configuration
so that packets can
be received on the
interface
Yes
Is ACL
configured
correctly?
No
Modify the ACL so

that internal packets
can pass through
NAT gateway
Yes
Is address
pool configured
correctly?
Yes
Is fault
rectified?
No
Reconfigure the
address pool
No
Seek technical
support
Is fault
rectified?
Yes
No
Is fault
rectified?
No
Yes
Is fault
rectified?
Yes
No
Yes
End
NOTE
Procedure
Step 1 Check whether packets are received on the interface.
Run the display interface interface-type interface-number command on the AR1200 to view
the value of the Input field.
l If the value of the Input field is 0, the AR1200 has not received any packets. Check the
configuration of the interface and ensure that packets can be received on the interface.
l If the value of the Input field is not 0, go to step 2.
Issue 02 (2012-03-30)

337

Troubleshooting
10 Security
NOTE
The AR1200 supports GE interfaces, FE interfaces, Eth-Trunk interfaces, and sub-interfaces. If an EthTrunk sub-interface is used to import traffic, run the display interface eth-trunk [ trunk-id
[.subnumber ] ] command to check whether the Eth-Trunk sub-interface has received packets.
Step 2 Check that the ACL rule bound to outbound NAT allows service packets to pass through.
Run the display nat outbound command on the AR1200 to check whether outbound NAT is
[Huawei]display nat outbound
NAT Outbound Information:
----------------------------------------------------------------Interface
Acl
Address-group/IP
Type
----------------------------------------------------------------GigabitEthernet0/0/0
2000
1
no-pat
----------------------------------------------------------------Total : 1
The preceding command output indicates that ACL 2000 has been bound to outbound NAT on
Check whether the rule of ACL 2000 is configured correctly. If the IP address, port number, or
protocol type in the rule of ACL 2000 is configured incorrectly, packets cannot be transmitted
properly.
Run the display acl 2000 command to view the configuration of outbound NAT bound to ACL
2000.
[Huawei] display acl 2000
Advanced ACL2000, 1 rule
Acl's step is 5
rule 5 permit source 192.168.1.100 0
The rule of ACL 2000 allows TCP packets with the source address of 192.168.1.100 to pass
through.
l If the ACL rule is configured incorrectly, reconfigure the ACL rule.
l If the ACL rule is configured correctly but the fault persists, go to step 3.
Step 3 Check that the address pool configuration is correct.
Run the display nat address-group command on the AR1200 to check whether the address
pool bound to outbound NAT on the outbound interface is correct.
[Huawei] display nat address-group 1
NAT Address-Group Information:
-------------------------------------Index
Start-address
End-address
-------------------------------------1
110.0.0.100
110.0.0.110
-------------------------------------Total : 1
To view Easy IP information on the outbound interface, run the display nat outbound command
on the AR1200. For example:
[Huawei] display nat outbound
----------------------------------------------------------------Interface
Acl
Address-group/IP
Type
----------------------------------------------------------------GigabitEthernet0/0/1
2000
30.30.30.1
easyip
----------------------------------------------------------------Total : 1
Issue 02 (2012-03-30)

338

Troubleshooting
10 Security
The preceding command output indicates that Easy IP has been configured on
GigabitEthernet0/0/1 and the address pool 30.30.30.1 bound to the interface is the address pool
advertised on the interface.
l If the bound IP address is the interface address, ensure that the interface address is valid.
l Check whether the bound IP address is a VRRP virtual address. If it is a VRRP virtual address,
ensure that the interface address exists and the VRRP status of the interface is master. The
display vrrp command can be run in the interface view to check the VRRP status of the
interface.
l
----End

Relevant Alarms
None.
Relevant Logs
None.
10.6.2 External Hosts Fail to Access Internal Servers

Common Causes
l
Application layer services on the internal NAT server are disabled.
The NAT server is configured on an incorrect interface, such as an outbound interface. (The
NAT server should be configured on an inbound interface through which external hosts
connect to the internal network.)
NAT server configurations are incorrect. For example, the public and private IP addresses
of internal servers are incorrect, and private ports configured for the NAT server are
different from ports enabled on internal servers.
Issue 02 (2012-03-30)

339

Troubleshooting
10 Security
Figure 10-15 Troubleshooting flowchart for a NAT server failure

External host fails to
access internal FTP server
Are services running

properly?
No
Check configuration
and ensure services
are running properly
Is fault
rectified?
Yes
No
Yes
Is NAT server
configured correctly ?
No
Correctly configure
the NAT server
Is fault
rectified?
Yes
No
Yes
Can external host

Ping interface address
of NAT server?
No
Check connection
between external
host and NAT server
Is fault
rectified?
Yes
No
Yes
Can external
Host ping address pool
of NAT server?
No
Check gateway
address or route on
internal FTP server
Is fault
rectified?
Yes
No
Yes
No
Is fault rectified?
Seek technical
support
Yes
End
NOTE
Procedure
Step 1 Check whether services on the internal NAT server are running properly.
Access the internal NAT server from an internal host to check whether services such as HTTP
and FTP are running properly on the internal NAT server.
Issue 02 (2012-03-30)

340

Troubleshooting
10 Security
l If services are not enabled, enable the services.

l If services on the internal NAT server are running properly but the fault persists, go to step
2.
Step 2 Check that the NAT server is configured correctly.
Run the display nat server command on the AR1200 to check that the NAT server is configured
on the correct outbound interface and the correct protocol type, port number, and IP address are
configured.
[AR1200]display nat server
Nat Server Information:
Interface : GigabitEthernet0/0/1
Global IP/Port
: 202.10.10.10
Inside IP/Port
: 10.10.10.2
Protocol : 6(tcp)
VPN instance-name : ---Total :
1
21(ftp)
21(ftp)
Ensure that the mapped internal addresses and port numbers are correct. FTP and TFTP use
several ports (some of them are randomly generated) to transmit data packets. To configure the
NAT server to provide FTP and TFTP, cancel limitation on ports so that the internal server can
provide services.
l If the NAT server is configured incorrectly, reconfigure the NAT server.
l If the NAT server is configured correctly but the fault persists, go to step 3.
Step 3 Check the connectivity between the external host and NAT server.
Check that the IP address of the outbound interface on the NAT server is correct and the external
IP address of the NAT server is correct. The IP addresses cannot conflict with the addresses on
other network segments. Ping the external interface of the NAT server from an external host.
Ensure that the external host can ping the NAT server successfully.
l If the external host cannot connect to the NAT server, check the connection.
l If the external host can connect to the NAT server but the fault persists, go to step 4.
Step 4 Check that the internal NAT server is configured with the correct gateway address or route.
The internal NAT server should be configured with the correct route or gateway address so that
packets destined for the external host can be sent to the gateway.
l If the gateway address or route configured on the internal NAT server is incorrect, reconfigure
it.
l If the gateway address or route configured on the internal NAT server is correct but the fault
l
----End

Issue 02 (2012-03-30)

341

Troubleshooting
10 Security
Relevant Alarms
None.
Relevant Logs
None.
10.6.3 Internal Host with a Conflicting IP Address Fails to Access

an External Server
Common Causes
l
Inbound and outbound interfaces through which internal users access the public network
go Down.
Outbound NAT is incorrectly configured on the outbound interface.
NAT ALG is disabled for the DNS protocol.
The DNS mapping entry is configured incorrectly. For example, the corresponding public
address is different from the IP address of an external server.
The route between the temporary address pool and the outbound interface is not configured.
Issue 02 (2012-03-30)

342

Troubleshooting
10 Security
Figure 10-16 Troubleshooting flowchart for twice NAT

Internal host A fails to
access external host B
Is outbound NAT
No
Correctly configure
outbound NAT
Is fault
rectified?
Yes
No
Yes
Is DNS mapping entry

set correctly?
No
Correctly configure a
DNS mapping entry
Is fault
rectified?
Yes
No
Yes
Is NAT ALG
enabled for DNS?
No
Enable NAT ALG for
the DNS protocol
Yes
Is fault
rectified?
Yes
No
Are mappings
between overlapped and
temporary address pools
correct?
No
Correctly configure
mappings between
overlapped and
temporary address
pools
Is fault
rectified?
Configure a route
between temporary
address pool and
outbound interface
Is fault
rectified?
Yes
Is there a route
between temporary
address pool and outbound
interface?
No
Yes
No
Yes
No
Yes
Is fault rectified?
No
Seek technical
support
Yes
End
NOTE
Issue 02 (2012-03-30)

343

Troubleshooting
10 Security
Procedure
Step 1 Check that outbound NAT is configured correctly.
Run the display nat outbound command on the AR1200 to check whether outbound NAT is
configured correctly.
[AR1200]display nat outbound
-------------------------------------------------------------------------------------------Interface
Acl
Address-group/IP
Type
-------------------------------------------------------------------------------------------GigabitEthernet0/0/1
3180
1
pat
-------------------------------------------------------------------------------------------Total : 1
The preceding command output indicates that ACL 3180 has been bound to outbound NAT and
the address pool index is 1. Check that outbound NAT uses a correct address pool. When
configuring an address pool, ensure that the destination address on the external network is
different from any address in the address pool. Run the display nat address-group command
to view the configuration of the address pool.
[AR1200]display nat address-group 1
NAT Address-Group Information:
-------------------------------------Index
Start-address
End-address
-------------------------------------1
202.10.10.10
202.10.10.100
-------------------------------------Total : 1
Check that ACL rules bound to outbound NAT are correct. The common problems of ACL rules
include incorrect settings of IP addresses, protocol types, or port numbers. When an ACL
problem occurs, packets on the internal network cannot be sent out or packets on the external
network cannot be sent to the internal network.
Run the display acl 3180 command to view the ACL bound to outbound NAT.
[AR1200]display acl 3180
Acl's step is 5
rule 5 permit tcp source 1.1.1.1 0
NOTE
The ACL strictly controls permitted address segments, protocol types, and port numbers according to
networking requirements. If some protocol packets are rejected by the NAT gateway, check whether this
type of protocol packets is permitted by the ACL.
l If outbound NAT is configured incorrectly, correct the configuration.

l If outbound NAT is configured correctly but the fault persists, go to step 2.
Step 2 Check that the DNS mapping entry is configured correctly.
Run the display nat dns-map command on the AR1200 to check that the NAT DNS Map is
configured on the correct outbound interface, and the correct protocol type, port number, and IP
address are configured.
[AR1200]display nat dns-map
NAT DNS mapping information:
Domain-name : test1
Global IP
: 10.1.1.1
Issue 02 (2012-03-30)

344

Troubleshooting
10 Security
Global port : 2012

Protocol
: tcp
Total : 1
l If the DNS mapping entry is configured incorrectly, run the nat dns-map command in the
system view to configure a DNS mapping entry correctly.
l If the DNS mapping entry is configured correctly but the fault persists, go to step 3.
Step 3 Check that NAT ALG is enabled for the DNS protocol.
Run the display nat alg command on the AR1200 to check whether NAT ALG is enabled for
the DNS protocol.
[AR1200]display nat alg
NAT Application Level Gateway Information:
---------------------------------Application
Status
---------------------------------dns
Disabled
ftp
Disabled
rtsp
Enabled
sip
Disabled
----------------------------------
l If NAT ALG is disabled, run the nat alg enable command to enable it.
l If NAT ALG is enabled but the fault persists, go to step 4.
Step 4 Check that the mappings between overlapped address pools and temporary address pools are
correct.
Run the display nat overlap-address command on the AR1200 to check whether all the
mappings between overlapped address pools and temporary address pools are correct.
[AR1200]display nat overlap-address all
Nat Overlap Address Pool To Temp Address Pool Map Information:
--------------------------------------------------------------------------------------------------------------Id Overlap-Address Temp-Address
Pool-Length
Inside-VPN-Instance-Name
--------------------------------------------------------------------------------------------------------------1
1.1.1.1
20.20.20.20
34
--------------------------------------------------------------------------------------------------------------Total : 1
NOTE
The temporary address pool contains available IP addresses on the AR1200. The IP addresses in the address
pool cannot conflict with any interface address, VRRP address, or NAT address. Inside-VPN-InstanceName in the command output specifies the VPN instance of the internal interface connected to the host.
l If the mappings are incorrect, reconfigure the mappings.

l If the mappings are correct but the fault persists, go to step 5.
Step 5 Check that the route between the temporary address pool and the outbound interface is
configured.
Run the display ip routing-table command on the AR1200 to view all the routes on the public
network.
[AR1200]display ip routing-table
-----------------------------------------------------------------------------Routing Tables: Public
Destinations : 99
Routes : 99
Issue 02 (2012-03-30)

345

Troubleshooting
Destination/Mask
10 Security
Proto
10.0.0.0/8
Static
10.10.10.10/32 Unr
Pre
Cost
60
64
0
0
Flags NextHop
D
D
10.164.50.1
127.0.0.1
Interface
Ethernet0/0/0
InLoopBack0
NOTE
If the name of the VPN instance to which the internal interface belongs has been configured, run the display
ip routing-table vpn-instance vpn-name command to view the routes.
l If there is no correct route, reconfigure a route.

l If the route is correct but the fault persists, go to step 5.
l
----End

Relevant Alarms
None.
Relevant Logs
None.
10.7 PKI Troubleshooting

10.7.1 Failed to Obtain a CA Certificate
Common Causes
l
A fault occurs on the network connection, for example, the network cable is broken or not
properly connected.
The CA certificate is not given a trusted name.
The RA server URL is not correct or not configured.
The enrollment mode (CA or RA) is incorrect.
No RA server is configured for the certificate enrollment.
The fingerprint for the CA certificate is configured incorrectly.
The device system clock does not synchronize with the CA clock.
Issue 02 (2012-03-30)

346

Troubleshooting
10 Security
Figure 10-17 Troubleshooting flowchart for a failure to obtain a CA certificate
Failed to obtain a CA
certificate.
Is network
working properly?
No
Rectify the fault on

the network
connection.
Is the fault
rectified?
Yes
No
Yes
Are
parameters properly
set?
No
Configure
Configure parameters
parameters
according
according to
to the
the
configuration
configuration manual.
manual.
Is the fault
rectified?
Yes
No
Yes
Is
device properly
connected to RA/CA
server?
No
Check network to
ensure proper
connection to
server.
Is the fault
rectified?
Yes
No
Yes
Is
RA/CA server correctly
configured?
No
Rectify faults on
the RA/CA server.
Yes
No
Yes
Does
device clock
synchronize with server
clock?
No
Configure device
clock to synchronize
with RA/CA server
clock.
Is the fault
rectified?
Yes
No
Yes
Issue 02 (2012-03-30)
Is the fault
rectified?
End

347

Troubleshooting
10 Security
Procedure
Step 1 Ensure that the network connection between the device and RA server functions properly.
Step 2 Verify that mandatory parameters are configured correctly.
Run the display pki realm command to check whether mandatory parameters in the PKI domain
are configured correctly.
If the CA ID is configured incorrectly, the CA certificate may fail to be obtained.
If the certificate's enrollment URL is configured incorrectly, the CA certificate may fail to be
obtained.
If an incorrect fingerprint is configured in the PKI domain, the device cannot obtain the CA
certificate. If no fingerprint is configured, the system prompts the user to enter the fingerprint.
Verify that the enrollment mode is correct. To obtain a certificate from an RA server, use the
RA enrollment mode. To obtain a certificate from a CA server, use the CA enrollment mode. If
the preceding configurations are all correct, but the fault persists, go to step 3.
Step 3 Run the ping command to check the connection between the device and the enrollment server.
If the device is properly connected to the enrollment server, but the fault persists, go to step 4.
Step 4 Check the authority in charge of certificate enrollment.
Check whether the RA or CA is configured correctly. If not, modify the configuration.
Step 5 Check whether the device clock synchronizes with the RA or CA clock.
If not, configure the device to synchronize with the RA or CA clock.
----End

Alarms
None.
Logs
None.
Issue 02 (2012-03-30)

348

Troubleshooting
10 Security
10.7.2 Failed to Obtain a Local Certificate

Common Causes
l
A fault occurs on the network connection, for example, the network cable is broken or not
properly connected.
The CA certificate is not given a trusted name.
The enrollment mode (CA or RA) is incorrect.
The fingerprint for the CA certificate is configured incorrectly.
The RA server URL is not correct or not configured.
No RA server is configured for the certificate enrollment.
The device system clock does not synchronize with the CA clock.
Some mandatory parameters are not configured on the entity.
Figure 10-18 shows how to troubleshooting flowchart.
Figure 10-18 Troubleshooting flowchart for a failure to obtain a local certificate
Failed to obtain a
local certificate.
Can CA
certificate be
obtained?
No
Rectify faults on
obtaining the CA
certificate.
Yes
No
Yes
Are entity
attributes correctly
configured?
No Configure the attributes

according to the
Is the fault
rectified?
Yes
Is the fault
rectified?
Yes
No
Yes
Can users
No
Enroll certificates from
RA/CA server
?
Yes
Seek technical
support
Issue 02 (2012-03-30)
Is the fault
rectified?
Configure the RA/CA

server to allow users
to enroll certificates.
No
End

349

Troubleshooting
10 Security
Procedure
Step 1 Check whether the CA certificate can be obtained.
If the CA certificate cannot be obtained, check the failure cause.
If the CA certificate can be obtained, go to step 2.
Step 2 Check whether entity attributes are configured correctly.
Check whether the mandatory parameters are configured and the entity name is the same as
configured in the domain.
Step 3 Check the authority in charge of certificate enrollment.
Check whether RA or CA allows the user to enroll a CA certificate.
----End

Alarms
None.
Logs
None.
10.7.3 Failed to Obtain a CRL

Common Causes
l
No CA certificate is obtained before the CRL is obtained.
The URL of the CRL distribution point (CDP) is incorrectly configured.
Issue 02 (2012-03-30)

350

Troubleshooting
10 Security
Figure 10-19 shows how to troubleshooting flowchart.

Figure 10-19 Troubleshooting flowchart for a failure to obtain a CRL
Failed to obtain a
CRL.
Is
the CA certificate
obtained?
No
Obtain the CA
certificate
Is the fault
rectified?
Yes
Is the fault
rectified?
Yes
No
Yes
Is the
CDP URL correctly
configured?
No
Configure a correct
CDP URL according to
Yes
Seek technical
support
No
End
Procedure
Step 1 Check whether the CA certificate can be obtained.
Run the display pki certificate command to check whether the CA certificate exists.
If the CA certificate does not exist, obtain it.
If the CA certificate exists, go to step 2.
Step 2 Check whether the CDP URL is correctly configured.
If no CDP URL is configured, configure it correctly. If th CDP URL is configured incorrectly,
modify the configuration.
----End

Issue 02 (2012-03-30)

351

Troubleshooting
10 Security
Alarms
None.
Logs
N/A
Issue 02 (2012-03-30)

352

Troubleshooting
11 Reliability
11
Reliability
About This Chapter

11.1 Interface Backup Troubleshooting
11.2 BFD Troubleshooting
11.3 VRRP Troubleshooting
Issue 02 (2012-03-30)

353

Troubleshooting
11 Reliability
11.1 Interface Backup Troubleshooting

11.1.1 Interface Backup Fails to Take Effect
Common Causes
As shown in Figure 11-1, RouterA and RouterB are connected.
Multiple interfaces on RouterA back up one another:
l
Interface1 is the primary interface.
Interface2 and interface3 are backup interfaces.
Figure 11-1 Networking diagram of interface backup
interface1
interface2
LAN1
LAN2
interface3
RouterA
RouterB
Interface backup cannot take effect in the following situations:

l
Backup interfaces become unavailable after the primary interface fails.
In load balancing mode, load balancing cannot be implemented among the primary and
backup interfaces because they cannot all be in Up state simultaneously.
In load balancing mode, traffic cannot be load balanced among multiple interfaces.

l
The physical status of backup interfaces is Down.
The link layer status of backup interfaces is Down.
In load balancing mode:

The load balancing threshold and maximum bandwidth are not configured for the
primary interface.
An equal-cost route is not generated.
Only one flow needs to be transmitted.
Issue 02 (2012-03-30)

354

Troubleshooting
11 Reliability
Figure 11-2 Interface backup failing to take effect

Interface backup fails
to take effect
Is the physical
status of the
backup interface
Up?
Yes
Is the
link layer status of
the backup
interface Up?
No
Ensure that the

physical status of
the backup interface
is Up
Are the load

balancing threshold
and bandwidth
configured?
No
Ensure that the link

layer status of the
backup interface is
Up
Is fault
rectified?
Yes
No
Seek technical
support
Configure the load

balancing threshold
and bandwidth for
the primary interface
Is fault
rectified?
Yes
No
No
Configure route
attributes
Is fault
rectified?
Yes
No
Yes
Are there multiple

flows?
Yes
No
Yes
Are equal-cost
routes generated?
Yes
No
Yes
Is the active/
standby mode
used for interface
backup?
No
Is fault
rectified?
No
Change the working

mode of interface
backup
Yes
Seek technical
support
Is fault
rectified?
Yes
No
End
NOTE
Issue 02 (2012-03-30)

355

Troubleshooting
11 Reliability
Procedure
Step 1 Check that the physical status of the backup interfaces is Up.
Run the display interface interface-type interface-number command on the local and remote
devices to check the current state field.
l
If the current state field is DOWN, check whether the cable is correctly connected and
whether interface parameters are correctly set.
If the current state field is UP, go to step 2.
Step 2 Check that the link layer status of backup interfaces is Up.
Run the display interface interface-type interface-number command on the local and remote
devices to check the Line protocol current state field.
l
If the Line protocol current state field is DOWN, check whether IP addresses and link
layer parameters are correctly set on the interfaces.
NOTE
When dialer interfaces are used as backup interfaces, IP addresses must be configured to trigger
dialup and a routing protocol must be configured on the dialer interfaces.
When the primary interface fails, dialer interfaces are enabled as backup interfaces. The configured
routing protocol sends protocol packets through the dialer interfaces, which triggers dialup and the
generation of routes.
If the Line protocol current state field is UP, go to step 3.
Step 3 Check whether the active/standby mode is used for interface backup.
Run the display this command in the primary interface view to check whether the load balancing
threshold and maximum bandwidth are configured for the primary interface.
l
If the load balancing threshold and maximum bandwidth are not configured for the primary
interface, the active/standby mode is used for interface backup. Check whether the active/
standby mode needs to be used for interface backup according to networking requirements:
If the active/standby mode is required for interface backup, go to step 6.
If the load balancing mode is required for interface backup, run the standby
threshold enable-threshold disable-threshold command on the primary interface to
configure the load balancing threshold, and run the standby bandwidth size command
to configure the maximum bandwidth for the primary interface.
If the load balancing threshold and maximum bandwidth are configured for the primary
interface, the load balancing mode is used for interface backup. Go to step 4.
Step 4 Check whether equal-cost routes are generated.

If traffic needs to be sent from multiple interfaces to the same destination address, equal-cost
routes must be generated to implement load balancing among these interfaces. Run the display
ip routing-table command to check whether equal-cost routes are generated. The following
command output shows that equal-cost routes are generated.
<Huawei>display ip routing-table
---------------------------------------------------------------------------Routing Tables: Public
Destinations : 7
Routes : 7
Destination/Mask
Proto
2.2.2.0/24 Static
Static
Issue 02 (2012-03-30)
Pre
Cost
Flags
NextHop
60
RD
192.168.1.2
60
RD
192.168.2.2

Interface
356

Troubleshooting
11 Reliability
If an equal-cost route is not generated, modify the related routing configuration:

Modify route attributes, such as the cost.
Configure static routes as shown in the preceding command output.
NOTE
The preceding example describes how to load balance traffic destined for the same destination
address. If multiple flows are destined for different destination addresses and these flows need to be
sent from the primary and backup interfaces, the flows can be load balanced among these interfaces
even if no equal-cost route is available.
The following conditions must be met to implement load balancing:
l When multiple interfaces among the primary and backup interfaces are working, these interfaces
have the routes destined for these destination addresses.
l To maintain stable load balancing, ensure that the traffic volume of the primary interface is greater
than the lower threshold. Otherwise, backup interfaces will be disabled.
If equal-cost routes are generated, go to step 5.
Step 5 Check whether multiple flows are transmitted over the links.
After equal-cost routes are generated, the device selects a route to forward packets according to
the hash algorithm. If only one flow needs to be transmitted, it cannot be load balanced among
multiple links. The device load balances traffic among multiple links only when multiple flows
need to be transmitted. Check whether multiple flows are transmitted over the links.
l
If only one flow is sent from the primary interface, use the active/standby mode for interface
backup.
If multiple flows are transmitted over links, but the fault persists, go to step 6.
----End

Relevant Alarms
None
Relevant Logs
None
Issue 02 (2012-03-30)

357

Troubleshooting
11 Reliability
In Load Balancing Mode, a Backup Interface Frequently Alternates Between Up

and Down States
Fault Symptom
As shown in Figure 11-3, interface backup is configured on RouterB, and the load balancing
mode is used for interface backup. When RouterA sends traffic to RouterD, a backup interface
frequently alternates between Up and Down states.
Figure 11-3 Networking diagram showing that a backup interface frequently alternates between
Up and Down
RouterA
RouterB GE1/0/0
192.168.1.1/24
GE2/0/0
192.168.2.1/24
GE1/0/0 RouterC
192.168.1.2/24
RouterD
GE2/0/0
192.168.2.2/24
Fault Analysis
1.
Check the physical connection and configurations of the primary and backup interfaces on
RouterB. The two interfaces are correctly connected and configured. The two interfaces
work properly when interface backup is not configured.
2.
Check the interface backup configuration on RouterB. Run the display this command on
the primary interface of RouterB. If the following command output is displayed, the load
balancing threshold and maximum bandwidth are configured for the primary interface. This
indicates that the load balancing mode is used for interface backup.
#
ip address 192.168.1.1 255.255.255.0
standby interface GigabitEthernet 2/0/0 30
bandwidth 10000
standby threshold 80 20
#
3.
Run the display ip routing-table command on RouterB. Equal-cost routes have been
generated.
---------------------------------------------------------------------------Routing Tables: Public
Destinations : 7
Routes : 7
Destination/Mask
Proto
2.2.2.0/24 Static
Static
4.
Issue 02 (2012-03-30)
Pre
Cost
Flags
NextHop
60
RD
192.168.1.2
60
RD
192.168.2.2
Interface
As shown in the command output, only traffic from RouterA to RouterD is sent through
the primary interface on RouterB. When no traffic needs to be transmitted, the primary
interface GE1/0/0 is in Up state, and the backup interface GE2/0/0 is in Standby state. When
the volume of traffic to be transmitted exceeds the upper threshold, the backup interface
GE2/0/0 is used. Because there is only one data flow and the backup interface is selected
based on the hash algorithm, all packets are sent from the backup interface, and no traffic
is sent from the primary interface GE1/0/0. When the traffic volume of the primary interface
falls below the lower threshold, the backup interface is disabled. Consequently, the backup
interface frequently alternates between Up and Down states.
358

Troubleshooting
11 Reliability
Procedure
Step 1 Run the undo standby bandwidth command in the primary interface view on RouterB to restore
the default configuration.
Step 2 Run the undo standby threshold command to delete the configured load balancing threshold.
The fault will be rectified after the preceding operations are performed.
----End
Summary
The load balancing mode is used for interface backup in the following situations:
l
Only the primary interface is used to transmit traffic, and the traffic volume on the primary
interface is above the upper threshold.
After traffic is load balanced, the traffic volume on the primary interface is still above the
lower threshold so that the backup interface remains enabled.
After the backup interface is enabled, traffic destined for multiple destination addresses
can be load balanced among the primary and backup interfaces, or there are equal-cost
routes for traffic destined for the same destination address on the primary and backup
interfaces:
There are routes destined for different destination addresses on the primary and backup
interfaces as shown in the following command output:
Destination/Mask
Proto
2.2.2.0/24 Static 60
3.3.3.0/24 Static 60
Pre
0
Cost
RD
NextHop
192.168.1.2
RD
192.168.2.2
Interface
There are equal-cost routes on the primary and backup interfaces as shown in the
following command output:
Destination/Mask
Proto
2.2.2.0/24 Static 60
Static 60
Pre
0
Cost
RD
NextHop
192.168.1.2
RD
192.168.2.2
Interface
11.2 BFD Troubleshooting

11.2.1 BFD Session Cannot Go Up
Common Causes
l
The discriminators of the two devices are inconsistent.
The link detected by the BFD session fails. As a result, BFD packets cannot be exchanged
between the two ends of the BFD session.
The BFD session status flaps.
Issue 02 (2012-03-30)

359

Troubleshooting
11 Reliability
Figure 11-4 Troubleshooting flowchart for the fault that a BFD session cannot go Up
A BFD session
cannot go Up
Configuration
of the BFD session is
committed?
No
Commit the
configuration
Is fault
rectified?
Yes
End
No
Yes
Discriminators
on both ends are
consistent?
No
Delete the
setting and set
the consistent
discriminators
on both ends
Is fault
rectified?
Yes
End
No
Yes
BFD packets
can be received and
sent correctly?
Yes
Seek
technical
support
No
Statistics
about error packets
exist?
Yes
Statistics
about the times the
BFD session goes
Down exist?
Yes
No
No
No
Is fault rectified?
Yes
No
Is fault rectified?
No
Two ends
Of the BFD session
can ping each
other?
Adjust the BFD

detection time
Yes
Yes
End
No
Check the link
Seek technical
support
End
Issue 02 (2012-03-30)

360

Troubleshooting
11 Reliability
Context
NOTE
Procedure
Step 1 Run the display current-configuration command to check that the configurations of the BFD
session is committed.
l If the commit command is displayed, the configuration of the BFD session has been
committed. Then, go to Step 2.
l If the commit command is not displayed, the configuration of the BFD session has not been
committed. In this case, run the commit command to commit the configurations. After doing
so, run the display bfd session all command to check the State field.
If the State field is Up, the BFD session is successfully established.
If the State field is not Up, go to Step 2.
Step 2 Run the display current-configuration command to check whether the discriminators of the
two devices are consistent.
l If they are inconsistent, run the undo bfd command to delete the existing bfd session, and
then run the bfd bind peer-ip command to create a new bfd session. At last run the
discriminator { local discr-value | remote discr-value } command to configure the local
and remote discriminators. Ensure that the local discriminator on the local end is the same
as the remote discriminator on the remote end and the remote discriminator on the local end
is the same as the local discriminator on the remote end. Then, go toStep 3.
l If they are consistent, go to Step 4.
Step 3 Run the display bfd session all command to check the State field.
l If the State field is Up, the BFD session is successfully established.
l If the State field is not Up, go to Step 4.
Step 4 Run the display bfd statistics session all command several times to view statistics about the
BFD packets of the BFD session.
l If the value of the Received Packets field does not increase, go to Step 5.
l If the value of the Send Packets field does not increase, go to Step 6.
l If the values of Received Packets and Send Packets fields increase, go to Step 9.
l If none of the values of the Received Packets, Send Packets, Received Bad Packets, and
Send Bad Packets fields increase, go to Step 7.
l If the value of the Down Count field increases, the BFD session flaps. Then, go to Step 7.
Step 5 Run the display bfd statistics session all command several times to check the Received Bad
Packets field.
Issue 02 (2012-03-30)

361

Troubleshooting
11 Reliability
l If the value of this field increases, the BFD packets have been received and discarded. Then,
go to Step 9.
l If the value of this field does not increase, the BFD packets have not been received. Then,
go to Step 7.
Step 6 Run the display bfd statistics session all command several times to check the Send Bad
Packets field.
l If the value of this field increases, the BFD packets sent by the BFD session have been
discarded. Then, go to Step 9.
l If the value of this field does not increase, the BFD packets failed to be sent. Then, go to
Step 7.
Step 7 Run the display bfd statistics session all command several times. If the BFD session still does
not go Up, run the ping command on one end to ping the other end of the BFD session.
l If the ping fails, it indicates that the link fails. See the section The Ping Operation Fails to
rectify the fault on the link.
l If the ping is successful, it indicates that the link is reachable. Then, go to Step 8.
Step 8 Run the display current-configuration command to view the min-tx-interval and min-rxinterval fields to check that the BFD detection period is longer than the delay on the link.
l If the BFD detection period is shorter than the delay on the link, run the detect-multiplier,
min-rx-interval, and min-tx-interval commands to adjust the values to make it longer than
the delay on the link.
l If the BFD detection time is longer than the delay time on the link, go to Step 9.
personnel.
----End

Relevant Alarms
None
Relevant Logs
None
11.2.2 Interface Forwarding Is Interrupted After a BFD Session

Detects a Fault and Goes Down
Common Causes
Issue 02 (2012-03-30)

362

Troubleshooting
11 Reliability
The BFD session status is associated with the interface status.
Figure 11-5 Troubleshooting flowchart for the fault that the interface forwarding is interrupted
after a BFD session detects a fault and goes Down
Interface forwarding
is interrupted after a
BFD session detects
a fault and goes
Down
Check the interface status
Interface
is DOWN
But the BFD session
status is
Down?
No
Rectify the fault in the

forwarding module
No
BFD session
status is associated
with interface
status?
End
Yes
BFD session is Up?
Yes
End
No
Yes
Context
NOTE
Procedure
Step 1 Run the display interface interface-type interface-number command to check the status of the
interface to which the BFD session is bound.
Issue 02 (2012-03-30)

363

Troubleshooting
11 Reliability
l If the Line protocol current state field displays DOWN(BFD status down), the interface
status is set to BFD status down after the BFD session detects a link fault. Then, go to Step
2.
l If the Line protocol current state field displays UP but the interface cannot forward packets,
the forwarding module is faulty. See the section The Ping Operation Fails to rectify the
forwarding fault.
Step 2 Run the display bfd session all command to view the status of the BFD session.
l If the BFD session is Down, go to Step 3.
l If the BFD session is Up, go to Step 4.
Step 3 Run the display current-configuration configuration bfd-session command to check that the
process-interface-status command is configured.
l If the process-interface-status command is configured, the interface is set to DOWN(BFD
status down) because the BFD session detected a fault and went Down.
l If the process-interface-status command is not configured, go to Step 4.
personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.
11.2.3 Changed BFD Session Parameters Do Not Take Effect

Common Causes
l
Issue 02 (2012-03-30)
After parameters of a BFD session have been changed, changed configurations are not
committed.

364

Troubleshooting
11 Reliability
Figure 11-6 Troubleshooting flowchart for the fault that the changed BFD session parameters
do not take effect
Changed BFD
session parameters
cannot take effect
Check the configuration of

the BFD session
BFD session
configuration is
committed
Yes
BFD session
configuration takes
effect?
No
Run the commit command to
make the configuration take
effect
Is fault rectified?
Yes
End
No
End
Seek technical
support
Context
NOTE
Procedure
Step 1 Run the display current-configuration configuration bfd-session command to check that the
commit command is configured.
l If the commit command is configured, the changed BFD session parameters have been
committed. Then, go to Step 3.
l If the commit command is not configured, the changed BFD session parameters have not
been committed. Then, run the commit command, and then go to Step 2.
Step 2 Run the display bfd session all command check whether the BFD session parameters are
specified values.
Issue 02 (2012-03-30)

365

Troubleshooting
11 Reliability
l If BFD session parameters are specified, the modified parameters take effect.
l If BFD session parameters are not specified, go to Step 3.
personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.
11.2.4 Dynamic BFD Session Fails to Be Created

Common Causes
l
BFD is not enabled for the protocol.
The route to the peer of the BFD session does not exist in the routing table.
The interface is prohibited from creating a BFD session.
Issue 02 (2012-03-30)

366

Troubleshooting
11 Reliability
Figure 11-7 Troubleshooting flowchart for the fault that a dynamic BFD session fails to be
created
Dynamic BFD session
fails to be created
Check the configuration of the

BFD session
BFD is enabled
for the protocol?
No
Enable BFD for

the protocol
Dynamic BFD session Yes

sucess to be created?
No
Yes
Routes exist in the

routing table?
No
Enable the
interface to
create a BFD
session
Yes
Interface is
prohibited from creating
a BFD session?
Yes
Rectify the fault

on the link
No
End
Context
NOTE
Issue 02 (2012-03-30)

367

Troubleshooting
11 Reliability
Procedure
Step 1 Run the display current-configuration configuration bfd command to check that BFD is
enabled for a protocol.
l If BFD is not enabled for a protocol, enable BFD. Then, go to Step 2.
l If BFD is enabled, go to Step 3.
Step 2 Run the display bfd session all command to view the state field.
l If the state field in the command output is Up, it indicates that the BFD section has been
created.
l If the state field in the command output is not Up, go to step 3.
Step 3 Run the display ip routing-table command to check whether the route of the link detected by
the BFD session exists.
l If the route exists, go to step 4.
l If the route does not exist, the BFD session associated with the protocol fails to be created.
see the section The Ping Operation Fails.
Step 4 Run the interfaceinterface-typeinterface-number command to enter the view of the existing
interface,then run the display this command to check that a command is configured to disable
an interface to dynamically create a BFD session.
l If such a command is configured, Run the undo ospf bfd blockcommand to enable the
interface to dynamically create a BFD session. Then, run the display bfd session all
command to check whether the BFD session is Up. If the session is not up, go to step 5.
l If such a command is not configured, go to step 5.
personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.
11.3 VRRP Troubleshooting

Issue 02 (2012-03-30)

368

Troubleshooting
11 Reliability
Data Packets Are Discarded on a VRRP Network

Fault Symptom
As shown in Figure 11-8, a VRRP backup group is configured on RouterA and RouterB.
RouterA functions as a master device and RouterB functions as a backup device. RouterC, as a
switch, connects RouterA and RouterB.
Figure 11-8 VRRP networking diagram
RouterA
GE0/0/1
RouterC
Eth0/0/0
RouterD
Eth0/0/1
Eth0/0/2
RouterB
Eth-trunk
GE0/0/1
RouterE
After the preceding configurations are complete, a large number of packets sent from RouterE
to RouterD are discarded.
Fault Analysis
1.
Run the display vrrp [ interface interface-type interface-number ] [ virtual-router-id ]

statistics command on RouterA and RouterB to view the traffic on GE0/0/1 on RouterA
and GE0/0/1 on RouterB. A small volume of traffic is transmitted on GE0/0/1 of RouterA,
and no traffic is transmitted on GE0/0/1 of RouterB.
Run the display interface counters command on RouterC to view traffic on Eth0/0/0,
Eth0/0/1, and Eth0/0/2. A small volume of traffic is transmitted on Eth0/0/1 and no traffic
is transmitted on Eth0/0/2, while a large volume of traffic is transmitted on Eth0/0/0. This
indicates that traffic has been discarded on RouterC.
2.
Run the display mac-address dynamic command on RouterC to check MAC addresses.
Based on the command output, the learned MAC address of RouterA is sent by Eth0/0/0
but not Eth0/0/1 connected to RouterA or Eth0/0/2 connected to RouterB, indicating that
the learned MAC address is incorrect.
MAC address table of slot
1:
-----------------------------------------------------------------------------MAC Address
VLAN/
PEVLAN CEVLAN Port
Type
LSP/
VSI/SI
MACTunnel
Issue 02 (2012-03-30)

369

Troubleshooting
11 Reliability
-----------------------------------------------------------------------------0000-0a0a-0102 1
Eth0/0/0
dynamic
0000-5e00-0101 1
Eth0/0/0
dynamic
0098-0113-0005 1
Eth0/0/0
dynamic
0018-824f-f5d1 1
Eth0/0/2
dynamic
------------------------------------------------------------------------------
3.

command on RouterC to view the configuration of Eth0/0/0.
#
undo shutdown
loopback internal
portswitch
port default vlan 1
According to the preceding command output, the loopback function has been configured
on Eth0/0/0, indicating that Eth0/0/0 loops traffic back after receiving it.
4.
Run the display interface counters command on RouterC to view traffic on Eth0/0/0,
Eth0/0/1, and Eth0/0/2. A large volume of traffic is transmitted on Eth0/0/0. This indicates
that traffic loss is caused by the loopback function on Eth0/0/0. A small volume of traffic
is transmitted on Eth0/0/2.
5.
Run the display mac-address dynamic command multiple times on RouterC to check
MAC addresses. The following command output shows that RouterC has learned the same
MAC address 0000-5e00-0101 from Eth0/0/0 and Eth0/0/1.
[RouterC] display mac-address
dynamic
1:
-----------------------------------------------------------------------------MAC Address
VLAN/
PEVLAN CEVLAN Port
Type
LSP/
VSI/SI
MACTunnel
-----------------------------------------------------------------------------0000-0a0a-0102 1
Eth0/0/0
dynamic
0000-5e00-0101 1
Eth0/0/0
dynamic
0098-0113-0005 1
Eth0/0/2
dynamic
0018-824f-f5d1 1
Eth0/0/0
dynamic
-----------------------------------------------------------------------------Total matching items on slot 1 displayed =

4
[RouterC] display mac-address dynamic
1:
------------------------------------------------------------------------------
Issue 02 (2012-03-30)

370

Troubleshooting
MAC Address
11 Reliability
VLAN/
PEVLAN CEVLAN Port
Type
LSP/
VSI/SI
MAC-
Tunnel
-----------------------------------------------------------------------------0000-0a0a-0102 1
Eth0/0/0
dynamic
0000-5e00-0101 1
Eth0/0/1
dynamic
0098-0113-0005 1
Eth0/0/2
dynamic
0018-824f-f5d1 1
Eth0/0/0
dynamic
-----------------------------------------------------------------------------Total matching items on slot 1 displayed=4
In a VRRP backup group, a device with a higher priority functions as a master device. The
master device sends a VRRP packet to the backup device every 1 second by default. If the
backup device fails to receive packets from the master device for three intervals, the backup
device becomes the master device and sends a VRRP packet indicating that it has become
the master. In general, the backup device does not send any VRRP packets.
NOTE
If the IP address of a device is the same as the virtual IP address, the device priority is considered to
be the highest and the device always functions as the master device.
On this network, a VRRP packet sent by the master device arrives at the switch. The switch
learns the source MAC address (in this example, 0000-5e00-0101), VLAN ID, and interface
connected to the master device, and adds them to the MAC address table. The switch
searches the MAC address table for the interface connected to the master device to forward
the packet to the backup device. If a VRRP switchover occurs, the backup device becomes
the master device and then sends a VRRP packet. After receiving the VRRP packet, the
switch learns the MAC address and maps it to the interface connected to the new master
device.
After receiving a VRRP packet that is sent every 1 second, RouterC learns the MAC address
of RouterA and forwards the VRRP packet to all the interfaces in VLAN 1. Eth0/0/0 of
VLAN 1 receives the VRRP packet and loops the VRRP packet back using the loopback
function. After receiving the returned VRRP packet, RouterC adds a mapping entry
between Eth0/0/0 and MAC address 0000-5e00-0101 to the MAC address table to overwrite
the previous mapping entry.
Consequently, when the master device sends a VRRP packet every 1 second, the newlylearned MAC address overwrites the previous one. The first MAC address learned by
RouterC is correct, so traffic can be forwarded correctly. The newly-learned MAC address
is incorrect, so traffic cannot be forwarded correctly and traffic loss occurs. Traffic can be
forwarded correctly only when a correct MAC address is learned.
Procedure
Step 1 Run the system-view command on RouterC to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the view of Eth0/0/0.
Step 3 Run the undo loopback command to disable the loopback function on the interface.
After the preceding operations are performed, no traffic is discarded. The fault is rectified.
----End
Issue 02 (2012-03-30)

371

Troubleshooting
11 Reliability
Summary
Enabling the loopback function on the interface of a Layer 2 device is not recommended. If the
loopback function is enabled, incorrect MAC addresses will be learned.
Issue 02 (2012-03-30)

372

Troubleshooting
12 MPLS
12
MPLS
About This Chapter

12.1 MPLS LDP Troubleshooting
Issue 02 (2012-03-30)

373

Troubleshooting
12 MPLS
12.1 MPLS LDP Troubleshooting

12.1.1 LDP Session Flapping
Common Causes
l
The configuration of the LDP GR timer, the LDP MTU, LDP authentication, the LDP
Keepalive timer , or the LDP transport address is set, changed, or deleted.
An interface flaps.
Routes flap.
After an LDP session is configured, the LDP session flaps.
l
Check that LDP GR, a Keepalive timer, LDP authentication, MTU signaling, or a transport
address is configured.
Check that the interface does not alternate between Down and Up.
Check that the routes do not alternate between unreachable and reachable.

Figure 12-1 Troubleshooting flowchart for LDP session flapping
LDP session
flaps
LDP session
is recreated?
Yes
Yes
Wait 10 seconds
Is fault rectified?
No
No
Interface flaps?
Yes
See the section

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

"IGP Route
Troubleshooting"
Yes
Is fault rectified?
No
No
Seek technical
support
Issue 02 (2012-03-30)

End
374

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

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

375

Troubleshooting
12 MPLS
If routes alternate between unreachable and reachable or no route exists, see The Ping
Operation Fails.
If the routes do not flap, go to Step 4.
Step 4 Collect the following information, and contact Huawei technical support personnel.
l Configuration files, logs, and alarms
----End

Relevant Alarms
LDP_1.3.6.1.2.1.10.166.4.0.4 mplsLdpSessionDown
LDP_1.3.6.1.2.1.10.166.4.0.3 mplsLdpSessionUp
Relevant Logs
None.
12.1.2 LDP Session Goes Down

Common Causes
l
The interface on which the LDP session is established is shut down.
The undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
No route exists.
An LDP Keepalive timer expires.
An LDP Hello-hold timer expires.
After an LDP session is configured, the LDP session goes Down.
l
Check that the interface on which the LDP session is established is shut down.
Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer is run.
Check that the routes exist.
Check that an LDP Hello-hold timer expires.
Check that an LDP Keepalive-hold timer expires.

Issue 02 (2012-03-30)

376

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

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

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

"Link Forwarding
Fails"
Yes
Is fault rectified?
No
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check that the interface on which the LDP session is established is shut down.
Run the display this command in the interface view. If the following information is displayed,
the interface has been shut down.
Issue 02 (2012-03-30)

377

Troubleshooting
12 MPLS
shutdown
If the interface has been shut down, run the undo shutdown command to restart the
interface.
If the interface is Up, go to Step 2.
Step 2 Check that the undo mpls, undo mpls ldp, or undo mpls ldp remote peer command is run.
Run the display current-configuration command.
l If the command output does not include the following information, MPLS is disabled.
mpls
l If the command output does not include the following information, MPLS LDP is disabled.
mpls ldp
l If the command output does not include the following information, the remote LDP session
is deleted.
mpls ldp remote peer
If an MPLS-associated configuration is deleted, re-perform the configuration.
If no MPLS-associated configuration is performed, go to Step 3.
Step 3 Check that the routes to the peer are reachable.

Run the display ip routing-table command to view the Destination/Mask field and a route to
the peer. If no route to the peer is displayed, a TCP connection cannot be established. If the route
to the peer is displayed, run the ping host command. If the ping succeeds, the route is reachable.
If the ping fails, the route is unreachable.
l
If no route to the peer is displayed, see OSPF Troubleshooting or IS-IS Troubleshooting

to troubleshoot the problem.
If the route to the peer is displayed but is unreachable, see The Ping Operation Fails.
If the route to the peer is displayed and is reachable, go to Step 4.
Step 4 Check that an LDP Hello-hold timer expires.

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

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

378

Troubleshooting
12 MPLS

Relevant Alarms
Relevant Logs
LDP/4/SSNHOLDTMREXP
12.1.3 LDP LSP Flapping

Common Causes
l
The route between LSP peers is flapping.
The LDP session flaps.
This section describes the troubleshooting flow of LDP LSP flapping.
After an LDP LSP is established, the LDP LSP flaps.
l
Check that the routes do not alternate between unreachable and reachable.
Check that the LDP session flaps.

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

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

"LDP Session
Flaps"
Yes
Is fault rectified?
No
No
Seek technical
support
Issue 02 (2012-03-30)

End
379

Troubleshooting
12 MPLS
This section describes the troubleshooting procedure of LDP LSP flapping.
NOTE
Procedure
Step 1 Check that the routes alternate between unreachable and reachable.
Run the display ip routing-table command to check information about the routes to the
destination of the LSP. Run this command at 1-second interval. If routes exist, routing
information is displayed. If no routes exist, no routing information is displayed. If sometimes
routing information is displayed but sometimes not after the command is run several times, the
routes alternate between unreachable and reachable.
l
If routes alternate between unreachable and reachable or no route is displayed, see The
Ping Operation Fails and rectify the fault in IGP routes.
If the routes are always reachable, go to Step 2.
Step 2 Check that the LDP session flaps.

Run the display mpls ldp session command to check the Status field. Running this command
every second is recommended. If Operational and Initialized are displayed alternatively, the
LDP session flaps.
l
If the LDP session flaps, see LDP Session Flapping.
If the LDP session does not flap, go to Step 3.
----End

Relevant Alarms
Relevant Logs
None.
12.1.4 LDP LSP Goes Down

Issue 02 (2012-03-30)

380

Troubleshooting
12 MPLS
Common Causes
l
Routes become unreachable.
The LDP session goes Down.
Resources are insufficient. The number of resources defined in the PAF/license file, the
number of tokens, or the number of labels reaches the upper limit, or memory is insufficient.
The policy for establishing an LSP is configured.
After an LDP LSP is established, the LDP LSP goes Down.
l
Check that the routes exist.
Check that the LDP session is successfully established.
Check that resources are insufficient. The number of resources defined in the PAF/license
file, the number of tokens, or the number of labels reaches the upper limit, or memory is
insufficient.
Check that a policy for establishing LSPs is configured.
Issue 02 (2012-03-30)

381

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

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

"LDP Session
Goes Down"
Is fault rectified?
Yes
No
Yes
Resources
are insufficient?
Yes
Increase the
upper limit or
delete unwanted
LSPs
Is fault rectified?
Change the
policy for setting
up an LSP
Is fault rectified?
No
Policy for
setting up an
LSP exists?
Yes
Yes
No
Yes
No
No
Seek technical
support
End
NOTE
Procedure
Step 1 Check that routes exist.
Run the display ip routing-table ip-address mask-length verbose command to check
information about the route to the destination of the LSP.
ip-address mask-length specifies the destination address of the LSP.
If routing information is displayed and the value of the State field is Active Adv in the command
output, a route reachable and is in the active state. If the route is a BGP route of a public network,
Issue 02 (2012-03-30)

382

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

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

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

383

Troubleshooting
12 MPLS
----End

Relevant Alarms
Relevant Logs
None.
Issue 02 (2012-03-30)

384

Troubleshooting
13 VPN
13
VPN
About This Chapter

13.1 GRE Troubleshooting
This section describes how to troubleshoot common GRE faults and provides sample
troubleshooting scenarios in the following sections.
13.2 L3VPN Troubleshooting
This section describes how to locate and troubleshoot common L3VPN faults.
13.3 IPSec Troubleshooting
13.4 SSL VPN Troubleshooting
13.5 DSVPN Troubleshooting
Issue 02 (2012-03-30)

385

Troubleshooting
13 VPN
13.1 GRE Troubleshooting

This section describes how to troubleshoot common GRE faults and provides sample
troubleshooting scenarios in the following sections.
13.1.1 Failed to Ping the IP Address of the Remote Tunnel Interface

Common Causes
l
Interfaces on both ends of a tunnel use different tunnel encapsulation modes.
No IP address is assigned to interfaces on either end, or no tunnel source or destination

address is configured on the two interfaces.
No reachable route exists between the tunnel source and destination addresses.
After each device is configured as shown in Figure 13-1, PC1 and PC2 cannot communicate.
To rectify the fault, follow the troubleshooting flowchart shown in Figure 13-2.
Figure 13-1 GRE networking diagram
RouterA
RouterB
Tunnel
PC1
10.1.1.1/24
Issue 02 (2012-03-30)
RouterC
PC2
10.2.1.1/24

386

Troubleshooting
13 VPN
Figure 13-2 Troubleshooting flowchart for the ping failure

Failed to ping
IP address of the
remote tunnel
interface
Is
the Network
Protocol status
of two tunnel
interfaces
Up?
No
Are
Tunnel
encapsulation
modes on both
ends the
same?
Yes
No
Is
the
Network Protocol Yes
status of two tunnel
interfaces
Up?
Configure the
same tunnel
encapsulation
mode on both
ends
No
Yes
Are
tunnel interface
configurations
correct?
No
Is
the
Yes
Network Protocol
interfaces
Up?
Ensure that
tunnel interface
configurations
on both ends are
correct
No
Yes
Are there
Reachable
routes between
tunnel source and
destination
addresses
No
Is
the
Yes
Network Protocol
interfaces
Up?
Configure routes
between the two
addresses
No
Yes
Seek technical
support
Are the
No
GRE key
configurations on
both ends the
same?
Ensure that
The GRE key
configurations on
both ends are
the same
Yes
No
Can the
Local end ping Yes
the remote tunnel
interface?
No
Are there
reachable routes
between both
ends?
Yes
No
Configure
reachable routes
between both ends
Can the
Local End ping
the remote tunnel
interface?
Can the
Yes
Local end ping
the remote tunnel
interface?
Yes
End
No
Seek technical
support
NOTE
Save the results of each troubleshooting step. If troubleshooting fails to correct the fault, you will have a
record of your actions to provide to Huawei technical support personnel.
Procedure
l
Issue 02 (2012-03-30)
To troubleshoot when the network layer protocol of one or both ends of a tunnel is Down,
perform the following steps:
387

Troubleshooting
1.
13 VPN
Check that interfaces on both ends of a tunnel use the same tunnel encapsulation mode.
Run the display this interface command in the tunnel interface view to check whether
interfaces on both ends use the same tunnel encapsulation mode. If Tunnel protocol/
transport GRE/IP is displayed, the tunnel encapsulation mode is GRE.
If the two interfaces use different tunnel encapsulation modes, run the tunnelprotocol command in the tunnel interface view to reconfigure the tunnel
encapsulation mode.
NOTE
After you reconfigure the tunnel encapsulation mode, reconfigure the tunnel source and
destination addresses because configurations of the original source and destination
addresses were lost.
If the two interfaces use the same tunnel encapsulation mode, go to step 2.
2.
Check that IP, tunnel source, and tunnel destination addresses are configured for
interfaces on both ends of the tunnel. A tunnel source address and a tunnel destination
address uniquely identify a tunnel.
Check whether the local tunnel source address is the peer tunnel destination address
and the local tunnel destination address is the peer tunnel source address. If not, no
tunnel can be established between the two interfaces.
Run the display this command in the tunnel interface view to check the interface
configuration. Ensure that the local tunnel source address is the peer tunnel destination
address and the local tunnel destination address is the peer tunnel source address.
If the tunnel source and destination addresses are incorrect, reconfigure the
addresses in the tunnel interface view.
If the tunnel source and destination addresses are correct, go to step 3.
3.
Check that reachable routes exist between the tunnel source and destination addresses.
If the interface configurations on both ends are correct but the tunnel status is still
Down, check whether reachable routes exist between interfaces on both ends of the
tunnel:
If the tunnel is established between two indirectly connected interfaces, check
whether reachable routes exist between the two interfaces.
If the tunnel is established between two directly connected interfaces, routes are
not required.
Run the display ip routing-table command to view the IP routing table. If the IP
routing table is correct, run the display fib command to check the forwarding table
(FIB table) and check whether data can be forwarded correctly. Routing information
in the FIB table must be consistent with that in the routing table.
If no reachable route exists between the tunnel source and destination addresses,
configure static routes or a dynamic routing protocol to ensure that reachable routes
exist between the tunnel source and destination addresses.
If there are reachable routes between the tunnel source and destination addresses
but the fault persists, go to step 4.
4.
Configuration file, log file, and alarm file of the device
Issue 02 (2012-03-30)

388

Troubleshooting
13 VPN
To troubleshoot when the network layer protocol of interfaces on both ends of a tunnel is
Up, perform the following steps:
1.
Check that GRE key configurations of interfaces on both ends are consistent.
Run the display interface tunnel command on the two interfaces to check whether
their GRE key configurations are consistent. Ensure that:
Neither interface is configured with a GRE key.
Both interfaces are configured with the same key number.
If GRE key configurations of interfaces on both ends are consistent but the fault
2.
Check IP addresses of interfaces on both ends of the tunnel.

If the network protocol status of the two interfaces is Up but they cannot ping each
other, check whether their IP addresses are on the same network segment:
If IP addresses of the two interfaces are on different network segments, configure
static routes or a dynamic routing protocol to ensure that reachable routes exist
between the two devices.
If IP addresses of the two interfaces are on the same network segment or reachable
routes exist between the two devices, go to step 3.
3.
Configuration file, log file, and alarm file of the device
----End

Relevant Alarms
None
Relevant Logs
None

This section provides troubleshooting examples.
Issue 02 (2012-03-30)

389

Troubleshooting
13 VPN
Local Tunnel Interface Fails to Ping the Remote Tunnel Interface Although Their
Network Protocol Status Is Up
Fault Symptom
Figure 13-3 Networking between local and remote tunnel interfaces
network
Loopback1
1.1.1.1/32
Loopback1
2.2.2.2/32
GRE Tunnel
Tunnel0/0/1
RouterA 11.1.1.1/24
Tunnel0/0/1
21.1.1.1/24
RouterB
The network layer protocol is Up on Tunnel0/0/1 of RouterA and Tunnel0/0/1 of RouterB, but
the two interfaces cannot ping each other.
Fault Analysis
Possible causes are as follows:
l
GRE key configurations of the two interfaces are inconsistent.
IP addresses of the two interfaces are on different network segments and no reachable routes
exist between the two ends.
Run the display interface tunnel interface-number command on the two tunnel interfaces to
check whether their GRE key configurations are consistent.
<RouterA> display interface tunnel 0/0/1
Tunnel0/0/1 current state : UP
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Encapsulation is TUNNEL, loopback not set
Tunnel source 1.1.1.1 (LoopBack1), destination 2.2.2.2
Tunnel protocol/transport GRE/IP, key 2
keepalive disabled
Checksumming of packets disabled
......
<RouterB> display interface tunnel 0/0/1
Tunnel0/0/1 current state : UP
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Encapsulation is TUNNEL, loopback not set
Tunnel source 2.2.2.2 (LoopBack1), destination 1.1.1.1
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Issue 02 (2012-03-30)

390

Troubleshooting
13 VPN
Checksumming of packets disabled

......
The command output shows that a GRE key is configured on RouterA and the key number is 2,
but no GRE key is configured on RouterB. Perform one of the following steps to ensure that
GRE key configurations of the two interfaces are consistent.
Procedure
l
Run the undo gre key command on RouterA to delete the configured GRE key.
Run the gre key 2 command on RouterB to configure a GRE key for RouterB. The
configured key number 2 is the same as the GRE key of RouterA.
After you perform either of the preceding steps, GRE key configurations become consistent,
and tunnel interfaces on both ends can ping each other successfully.
----End
Summary
To successfully establish a GRE tunnel between two tunnel interfaces, ensure that their network
protocol status is Up, their GRE key configurations are consistent, and routes reachable to IP
addresses of the two tunnel interfaces on both ends exist.
Two PCs Fail to Ping Each Other Although Tunnel Interfaces on Both Ends Can
Ping Each Other
Fault Symptom
In Figure 13-4, configurations of tunnel interfaces on both ends are correct, and the two
interfaces can ping each other. However, PC1 and PC2 cannot ping each other.
Figure 13-4 Networking diagram
RouterC
RouterA
PC1
10.1.1.1/16
Tunnel0/0/2
Tunnel
Tunnel0/0/1
RouterB
PC2
10.2.1.1/16
Fault Analysis
Possible causes are as follows:
l
Routes from RouterA to PC2 do not exist.
Routes from RouterB to PC1 do not exist.
Issue 02 (2012-03-30)

391

Troubleshooting
RouterA is not specified as the default gateway of PC1.
RouterB is not specified as the default gateway of PC2.
13 VPN
Run the display ip routing-table command on RouterA to check whether routes from
Tunnel0/0/1 of RouterA to PC2 at 10.2.0.0/16 exist, and run the display ip routing-table
command on RouterB to check whether routes from Tunnel0/0/2 of RouterB to PC1 at
10.1.0.0/16 exist.
If no required route exists, run the ip route-static command in the system view to configure
static routes. The following example uses the configuration of RouterA:
[RouterA] ip route-static 10.2.0.0 255.255.0.0 tunnel 0/0/1
If the fault persists after you configure static routes, check whether RouterA is specified as the
default gateway of PC1 and whether RouterB is specified as the default gateway of PC2.
Procedure
Step 1 Check that a route from Tunnel0/0/1 of RouterA to PC2 at 10.2.0.0/16 exists.
Step 2 Check that a route from Tunnel0/0/2 of RouterB to PC1 at 10.1.0.0/16 exists.
Step 3 Check that RouterA is specified as the default gateway of PC1.
Step 4 Check that RouterB is specified as the default gateway of PC2.
----End
Summary
To correctly forward GRE encapsulated packets between two devices, ensure that interfaces on
both ends of a GRE tunnel can ping each other successfully and reachable routes to IP addresses
of the two interfaces on both ends exist.
13.2 L3VPN Troubleshooting

This section describes how to locate and troubleshoot common L3VPN faults.
13.2.1 VPN Users Cannot Communicate

Common Causes
l
No reachable route exists between user hosts and CEs.
CEs do not advertise routing information to directly connected PEs.
The local PE does not advertise private network routes to the remote PE.
Issue 02 (2012-03-30)

392

Troubleshooting
13 VPN
Figure 13-5 Troubleshooting flowchart for interruption of BGP private network traffic
VPN users cannot
communicate

Yes
Can the local

CE ping the
remote CE?
Yes
No
Are there
No
reachable routes
between hosts and
CEs?
Configure routes
between hosts
and CEs
Is fault
rectified?
Yes
No
Have CEs
advertised VPN
routes to PEs?
No
Is fault
rectified?
Check routes between

CEs and PEs
Yes
End
No
Yes
Has the local
No
PE advertised
VPN routes to the
remote PE?
Have PEs
established the BGP
peer relationship?
No
Check the
routing
configurations of
PEs
Yes
Yes
Check the MPLS

configurations of PEs and
establish an LSP between
them
Seek technical
support
No
Is fault rectified?
Yes
End
Procedure
Step 1 Check that reachable routes exist between CEs.
On the local CE, ping the remote CE.
l
If the ping succeeds, a reachable route exists between the two CEs. The fault might have
occurred on the link between a VPN user host and CE, but not on the link between CEs.
Check whether the VPN user host and CE are reachable. If the user host and CE are
unreachable, a route is required. If the user host and CE are reachable but cannot ping each
other, contact the Huawei technical support personnel.
If the ping fails, run the display ip routing-table command on the local CE to check
whether the route to the remote CE exists in the local routing table. Run the display ip
routing-table command on the remote CE to check whether a route to the local CE exists.
If neither CE has a route to each other or only one CE has a route to the other, a routing
failure occurs between the CEs. Go to step 2.
Issue 02 (2012-03-30)

393

Troubleshooting
13 VPN
Step 2 Check routes to the network segments between the CEs.

There are three network segments between the CEs:
l Network segment from the local CE to local PE
l Network segment from the local PE to remote PE
l Network segment from the remote PE to remote CE
To rectify the routing failure between the local CE and local PE, and between the remote PE
and remote CE, go to step 3. To rectify the routing failure between the local PE and remote PE,
go to step 4.
Step 3 Check that the local and remote CEs have advertised routing information to directly connected
PEs.
Run the display ip routing-table vpn-instance vpn-instance-name command on the PEs to
check whether their VPN routing tables contain the routing entries advertised from directly
connected CEs.
l
If the CEs do not advertise routing information to directly connected PEs, modify routing
configurations of the CEs and PEs.
If the CEs advertise routing information to directly connected PEs, go to step 4.
Step 4 Check that the local PE has advertised private network routes on the remote PE.
l Run the display ip routing-table vpn-instance vpn-instance-name command on the remote
PE to check whether there are routes to the local CE in the VPN routing table.
l If routes to the local CE exist, run the display ip routing-table vpn-instance vpn-instancename command on the local PE. If routes to the remote CE also exist, reachable routes exist
between the PEs.
l If no route to the local CE is displayed in the VPN routing table on the remote PE, run the
display bgp vpnv4 all peer command to check whether the BGP VPNv4 peer relationship
is established between the PEs.
l If the BGP VPNv4 peer relationship is established between the PEs, check whether VPN
targets of the two PEs match. The export VPN target of the local PE must be the same as the
import VPN target of the remote PE, and the import VPN target of the local PE must be the
same as the export VPN target of the remote PE. If not, modify the configurations to match.
l If the BGP VPNv4 peer relationship is not established between the PEs, run the display bgp
peer command to check the public network BGP peers of the PEs. To rectify the BGP routing
failure between PEs, see IP routing troubleshooting.
----End

Relevant Alarms
None
Issue 02 (2012-03-30)

394

Troubleshooting
13 VPN
Relevant Logs
None
13.3 IPSec Troubleshooting

13.3.1 SAs Fail to Be Established Manually
Common Causes
l
The link is faulty.
Data flows are not forwarded from a specified interface.
The settings of IPSec proposals at both ends of the IPSec tunnel are different.
The settings of IPSec policies at both ends of the IPSec tunnel do not match. For example,
the IP addresses of local and remote devices are incorrect or SA parameters at both ends
do not match.
The ACLs referenced by IPSec policies at both ends do not mirror each other.
After being configured manually, IPSec cannot protect data.
Issue 02 (2012-03-30)

395

Troubleshooting
13 VPN
Figure 13-6 Troubleshooting flowchart for a failure to set up SAs manually

SAs fail to be
established manually
Can both interfaces be

pinged?
No
See "Ping
Operation
Failed"
No
Yes
Are protected
data flows sent from
specified interface?
No
Yes
Are IPSec proposals at

both ends the same?
No
Modify
configurations so
that data flows
are sent from
specified
interface
Is fault
rectified?
Modify
configurations so
that IPSec
proposals are the
same
Is fault
rectified?
No
Modify
configurations so
that IPSec
policies match
No
Yes
Is fault
rectified?
Yes
No
Yes
Do ACLs at
both ends mirror each
other?
Yes
No
Yes
Do IPSec policies
at both ends match?
Is fault Yes
rectified?
No
Modify
configurations so
that the ACLs
mirror each other
Yes
Is fault
rectified?
Yes
No
End
NOTE
Issue 02 (2012-03-30)

396

Troubleshooting
13 VPN
Procedure
Step 1 Check whether the interfaces at both ends of the IPSec tunnel can ping each other.
Run the undo ipsec policy command on the Router interfaces at both ends of the IPSec tunnel
to delete IPSec policies. Run the ping command to check whether the ping operation succeeds.
l
If the ping operation fails, check whether there are routes to the peer ends in the routing
tables at both ends according to 7.1.1 The Ping Operation Fails.
If the ping operation succeeds, there are reachable routes at both ends of the IPSec tunnel.
Reconfigure the IPSec policies on interfaces at both ends, and go to step 2.
Step 2 Check whether data flows protected by the IPSec tunnel can be forwarded by a specified
interface.
Ensure that outgoing data flows are sent by the interface to which the IPSec policy is applied.
The operations are as follows:
l Run the display ip routing-table command on both devices to view the routes to each other.
Check whether the outbound interface in a route with a reachable next hop is the specified
interface. If the outbound interface is not the specified interface, modify the routing
configuration according to Huawei AR1200 Series Enterprise Routers Configuration Guide
- IP Routing.
l Run the display arp command on both devices to check whether the interface in the ARP
entry matching the peer IP address is the specified interface. If not, run the reset arp
command to delete the ARP entry from the ARP mapping table.
If data flows protected by the IPSec tunnel are forwarded by a specified interface, go to step 3.
Step 3 Check whether the settings of IPSec proposals at both ends of the IPSec tunnel are the same.
Run the display ipsec proposal command on both devices to check the following fields.
Issue 02 (2012-03-30)
Field
Check Standard and Operation
IPsec
Proposal
Name
The IPSec proposals bound to IPSec policies at both ends must be the same.
If not, run the ipsec proposal command to change the IPSec proposal names
to be the same.
Encapsulatio
n Mode
The encapsulation modes must be the same. If not, run the encapsulationmode { transport | tunnel } command to change the encapsulation modes
to be the same.
Transform
The IPSec protocols must be the same. If not, run the transform { ah | esp |
ah-esp } command to change the IPSec protocols to be the same.
AH Protocol
The authentication algorithms used by the AH protocol must be the same. If

not, run the ah authentication-algorithm { md5 | sha1 | sha2-256 |
sha2-384 | sha2-512 } command to change the authentication algorithms to
be the same.
ESP Protocol
The authentication algorithm and encryption algorithm used by the ESP

protocol at both ends must be the same. If not, run the esp authenticationalgorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ] command to
change the authentication algorithm or run the esp encryption-algorithm
[ 3des | des | aes-128 | aes-192 | aes-256 ] command to change the encryption
algorithm.

397

Troubleshooting
13 VPN
If the settings of IPSec protocols at both ends are the same, go to step 4.
Step 4 Check whether the settings of IPSec policies at both ends of the IPSec tunnel match.
Run the display ipsec policy command on both devices to check the following fields.
Field
Tunnel local
address
The IP addresses at both ends must be correct. If not, run the tunnel local
command to change the IP address at the local end or run the tunnel
remote command to change the IP address at the remote end.
Tunnel
remote
address
Inbound/
Outbound
AH/ESP
setting
The SA parameters SPI, string-key, authentication-hex, and encryptionhex at both ends of the IPSec tunnel must match. The inbound parameters on
the local device must be the same as the outbound parameters on the remote
device, and the outbound parameters on the local device must be the same as
the inbound parameters on the remote device. If these parameters do not
match, modify the configuration according to Huawei AR1200 Series
Enterprise Routers Configuration Guide - IPSec.
If the settings of IPSec policies match, go to step 5.

Step 5 Check whether the ACLs referenced by IPSec policies at both ends of the IPSec tunnel mirror
each other.
Run the display acl command on the Router. If the following information is displayed, the ACLs
referenced by IPSec policies at both ends of the IPSec tunnel mirror each other.
# Display the ACL configuration on RouterA.
<Router A>display acl 3101
Acl's step is 5
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
# Display the ACL configuration on RouterB.

<Router B>display acl 3101
Acl's step is 5
If the ACLs referenced by IPSec policies at both ends of the IPSec tunnel do not mirror
each other, modify the configuration according to Huawei AR1200 Series Enterprise
Routers Configuration Guide - IPSec.
If the ACLs referenced by IPSec policies at both ends of the IPSec tunnel mirror each other,
go to step 6.
----End

Issue 02 (2012-03-30)

398

Troubleshooting
13 VPN
Relevant Alarms
None.
Relevant Logs
None.
13.3.2 SAs Fail to Be Established by Using IKE Negotiation

Common Causes
l
The link is faulty.
Data flows do not match the ACL.
the IPSec negotiation modes are different or the Perfect Forward Secrecy (PFS) settings
are different.
The settings of IKE proposals at both ends of the IPSec tunnel are different.
The settings of IKE peers at both ends of the IPSec tunnel are different. For example, IKE
negotiation modes are different, IKE versions are incorrect, IP addresses of IKE peers do
not match, or names of IKE peers do not match.
After being configured by using IKE negotiation, IPSec cannot protect data.
Figure 13-7, Figure 13-8, and Figure 13-9 show the troubleshooting flowcharts.
Issue 02 (2012-03-30)

399

Troubleshooting
13 VPN
Figure 13-7 Troubleshooting flowchart for a failure to set up SAs by using IKE negotiation
SAs fail to be
established by using IKE
negotiation
Are SAs set up

successfully?
No
See "IPSec SAs

Fail to Be
Established"
Yes
Are
protected data flows
sent from specified
interface?
No
No
Modify
configurations so
that data flows
are sent from
specified
interface
Is fault
rectified?
Modify the ACL

configuration
Is fault
rectified?
Yes
Issue 02 (2012-03-30)
Yes
No
Yes
Do data flows
match the ACL?
Is fault
rectified?

Yes
No
Yes
No
End
400

Troubleshooting
13 VPN
Figure 13-8 Troubleshooting flowchart for a failure to set up IPSec SAs by using IKE
negotiation
IPSec SAs fail to be
negotiation
Are IKE SAs set up

successfully?
No
See "IKE SAs

Fail to Be
Established"
No
Modify
configurations so
that IPSec
proposals are the
same
Yes
Do IPSec policies
at both ends match?
No
Modify
configurations so
that IPSec
policies match
Yes
Is fault
rectified?
Yes
No
No
Modify
configurations so
that the ACLs
mirror each other
Yes
Issue 02 (2012-03-30)
Is fault
rectified?
No
Yes
Do ACLs at both
ends mirror each other?
Yes
No
Yes

both ends the same?
Is fault
rectified?

Is fault
rectified?
Yes
No
End
401

Troubleshooting
13 VPN
Figure 13-9 Troubleshooting flowchart for a failure to set up IKE SAs by using IKE negotiation
IKE SAs fail to be
negotiation

pinged?
No
See "Ping
Operation
Failed"
Is fault
rectified?
No
Yes
Are configurations of
IKE peers correct?
No
Modify
configurations of
IKE peers
Is fault
rectified?
Yes
No
Yes
Are IKE proposals of

IKE peers the same?
Yes
No
Modify
configurations to
be the same
Is fault
rectified?
Yes
Yes
No
End
NOTE
Procedure
Step 1 Check whether the IPSec SA and IKE SA are established successfully.
Run the display ike sa command to check the SAs established by a peer in certain phases
according to the Peer, Flag, and Phase fields. The command output shows that the peer at
30.0.0.1 establishes the IKE SA in phase 1 and the IPSec SA in phase 2 by using IKE negotiation.
<RouterA>display ike sa
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------397
30.0.0.1
0
RD
2
367
30.0.0.1
0
RD
1
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
LKG--LAST KNOWN GOOD SEQ NO.
BCK--BACKED UP
Issue 02 (2012-03-30)

402

Troubleshooting
13 VPN
NOTE
If IKEv1 is used at both ends, run the display ike sa command to view information about IKE SAs. If
IKEv2 is used at both ends, run the display ike sa v2 command to view information about IKE SAs.
If the IPSec SA and IKE SA are established successfully, go to step 2.
If the IPSec SA fails to be established but the IKE SA is established successfully, go to

step 4.
If the IKE SA fails to be established, go to step 8.
interface.
- IP Routing.
Step 3 Check whether data flows match the ACL.
Analyze the source and destination IP addresses and port numbers of data flows to check whether
the data flows match the ACL referenced by the IPSec policy.
l
If the data flows do not match the ACL, they cannot enter the IPSec tunnel. Instead, the
data flows are forwarded directly. To modify the matching rule, see Huawei AR1200
Series Enterprise Routers Configuration Guide - IPSec.
If the data flows match the ACL, go to step 10.
Issue 02 (2012-03-30)
Field
IPsec
Proposal
Name
to be the same.
Encapsulatio
n Mode
to be the same.
Transform
AH Protocol

be the same.
403

Troubleshooting
13 VPN
Field
ESP Protocol

algorithm.
Check
Item
IPSec
negotiati
on mode
Run the display ipsec policy brief command to view the Mode field. If the IPSec
negotiation modes at both ends are different, run the ipsec policy isakmp
command to change the IPSec negotiation modes to be the same.
DiffieHellman
(DH)
group
If PFS is specified on the local device, PFS must be specified on the remote device.
The two ends must use the same DH group; otherwise, IKE negotiation fails. Run
the display ipsec policy command to view the Perfect Forward Secrecy field.
If the DH groups at both ends are different, run the pfs { dh-group1 | dhgroup2 } command to change the DH groups to be the same.
If the settings of IPSec policies at both ends of the IPSec tunnel match, go to step 6.
each other.
<RouterA>display acl 3101
Acl's step is 5

<RouterB>display acl 3101
Acl's step is 5
go to step 2.
Issue 02 (2012-03-30)

404

Troubleshooting
13 VPN
Run the undo ipsec policy command on the interfaces of the Router at both ends of the IPSec
tunnel to delete IPSec policies. Run the ping command to check whether the ping operation
succeeds.
l
Step 8 Check whether the configurations of IKE peers are correct.

Run the display ike peer command to check the following fields.
Field
Exchange
mode
The IKE negotiation modes in phase 1 must be the same. If not, run the
exchange-mode { main | aggressive } command to change the IKE
negotiation modes to be the same.
Negotiated
IKE version
The IKE versions must be the same. If not, run the ike peer command to
change the IKE versions to be the same.
Peer ip
address
The peer IP address of the local end must be the same as the local IP address
of the remote end, and the local IP address of the local end must be the same
as the peer IP address of the remote end. If IP addresses of IKE peers do not
match, run the local-address command to change the local IP address of the
IKE peer or run the remote-address command to change the peer IP address
of the IKE peer.
Local ip
address
Remote
name
The remote name of the local end must be the same as the local name of the
peer end. If not, run the remote-name command to change the name of the
remote peer.
NOTE
The name of the remote peer is used in the following scenarios:
l IKEv1 and the aggressive mode are used, and the name is used for authentication.
l IKEv2 is used and the remote IKE peer ID type is name.
If the configurations of IKE peers are correct, go to step 9.

Step 9 Check whether the settings of IKE proposals at both ends of the IPSec tunnel are the same.
Run the display ike proposal command on both devices to check whether the settings of IKE
proposals at both ends of the IPSec tunnel are the same.
l
If the settings of IKE proposals at both ends of the IPSec tunnel are different, reconfigure
IKE proposals according to Huawei AR1200 Series Enterprise Routers Configuration
Guide - IPSec.
If the settings of IKE proposals are the same, go to step 2.

NOTE
If preshared key authentication is used, configure a preshared key for each peer. The preshared keys of
peers that establish a connection must be the same. If not, run the pre-shared-key command to change the
preshared key.
Issue 02 (2012-03-30)

405

Troubleshooting
13 VPN
l Configuration files, log files, and alarm files of the Router

----End

Relevant Alarms
None.
Relevant Logs
None.
13.3.3 IPSec Fails to Be Configured by Using an IPSec Policy

Template
Common Causes
l
The link is faulty.
IKE negotiation is not initiated by the remote device.
the PFS configurations are different.
The settings of IKE peers at both ends of the IPSec tunnel are different. For example, IKE
After IPSec is configured by using an IPSec policy template, IPSec cannot protect data.
Issue 02 (2012-03-30)

406

Troubleshooting
13 VPN
Figure 13-10 Troubleshooting flowchart for a failure to configure IPSec by using an IPSec
policy template
IPSec fails to be
configured by using an
IPSec policy template
Are IPSec SAs set up

successfully?
No
See "IPSec SAs

Fail to Be
Established
Yes
Are protected
No
No
Modify
configuration so
that data flows
are sent from
specified
interface
Is fault
rectified?
Modify the ACL

configuration
Is fault
rectified?
Yes
Issue 02 (2012-03-30)
Yes
No
Yes
Do data flows
match the ACL?
Is fault
rectified?

Yes
No
Yes
No
End
407

Troubleshooting
13 VPN
Figure 13-11 Troubleshooting flowchart for a failure to configure IPSec SAs by using an IPSec
policy template
established by using an
IPSec policy template
Does remote device

initiate negotiation?
No
Yes
Are IKE SAs set up

successfully?
No
Modify
configurations so
that remote
device initiates
negotiation
Is fault
rectified?
See "IKE SAs

Fail to Be
Established
Is fault
rectified?
No
Modify
configurations so
that IPSec
proposals are
the same
No
Modify
configurations so
that IPSec
policies match
No
Modify
configurations so
that the ACLs
mirror each other
Yes
Issue 02 (2012-03-30)
Is fault
rectified?
Yes
Is fault
rectified?
Yes
No
Yes
Do ACLs at both
Yes
No
Yes
Do IPSec policies
at both ends match?
No
No
Yes

both ends the same?
Yes

Is fault
rectified?
Yes
No
End
408

Troubleshooting
13 VPN
Figure 13-12 Troubleshooting flowchart for a failure to configure IKE SAs by using an IPSec
policy template
IKE SAs fail to be
established

pinged?
No
See "Ping
Operation Failed"
Is fault
rectified?
No
Yes
IKE peers correct?
No
Modify
configurations of
IKE peers
Is fault
rectified?
Yes
No
Yes
Are IKE
proposals at both ends
the same?
Yes
No
Modify
configurations to
be the same
Is fault
rectified?
Yes
Yes
No
End
NOTE
Procedure
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------397
30.0.0.1
0
RD
2
367
30.0.0.1
0
RD
1
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
Issue 02 (2012-03-30)

409

Troubleshooting
13 VPN
NOTE

step 4.
interface.
- IP Routing.
l
Issue 02 (2012-03-30)
Field
IPsec
Proposal
Name
to be the same.
Encapsulatio
n Mode
to be the same.
Transform
AH Protocol

be the same.
410

Troubleshooting
13 VPN
Field
ESP Protocol

algorithm.
Step 5 Check whether the automatic mode of triggering ISAKMP SAs is used.
Run the display ipsec policy command on the remote device to check whether the value of SA
trigger mode is Automatic. If the IPSec policy on the local device is configured by using an
IPSec policy template or the traffic-based triggering mode is used, the local device does not
initiate negotiation. The remote device must initiate negotiation and the automatic mode must
be used.
l
If the automatic mode is not used, run the sa trigger-mode auto command to change the
mode.
If the automatic mode is used, go to step 6.
Check
Item
Whether
acls at
both
ends can
mirror
eath
other
NOTE
If an IPSec policy template is used, you can choose to configure ACLs. If the ACLs are
configured, ensure that the ACLs at both ends mirror each other.
You are advised not to configure ACLs if an IPSec policy template is used.
If ACLs are configured, run the display acl command on both Routers. If the
following information is displayed, the ACLs referenced by IPSec policies at both
ends of the IPSec tunnel mirror each other.
# Display the ACL configuration on Router A.
Acl's step is 5
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255
# Display the ACL configuration on Router B.

Acl's step is 5
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0
0.0.0.255
If the ACLs do not mirror each other, change the ACL at the remote end.
DiffieHellman
(DH)
group
Issue 02 (2012-03-30)

411

Troubleshooting
13 VPN
l

Field
Exchange
mode
Negotiated
IKE version
Peer ip
address
IKE peer.
Local ip
address
Remote
name
remote peer.
NOTE

l
Guide - IPSec.

NOTE
preshared key.
Issue 02 (2012-03-30)

412

Troubleshooting
13 VPN

----End

Relevant Alarms
None.
Relevant Logs
None.
13.3.4 NAT Traversal in IPSec Fails

Common Causes
l
The link is faulty.
The settings of IPSec proposals at both ends of the IPSec tunnel are different or ESP is not
used.
are different.
The settings of IKE peers at both ends of the IPSec tunnel are incorrect. For example, the
aggressive mode is not used, IKE versions are different, IP addresses of IKE peers do not
match, names of IKE peers do not match, NAT traversal is disabled, or the IKE peer ID
type is not name.
Issue 02 (2012-03-30)

413

Troubleshooting
13 VPN
Figure 13-13 Troubleshooting flowchart for a failure of NAT traversal in IPSec

NAT traversal in IPSec
fails
Are
IPSec SAs set up
successfully?
No
See "IPSec SAs

Fail to Be
Established
Yes
Are protected
No
No
Modify
configurations so
that data flows
are sent from
specified
interface
Is fault
rectified?
Modify the ACL

configuration
Is fault
rectified?
Yes
Issue 02 (2012-03-30)
Yes
No
Yes
Do data flows
match the ACL?
Is fault
rectified?

Yes
No
Yes
No
End
414

Troubleshooting
13 VPN

established by NAT
traversal
Are
IKE SAs set up
successfully?
No
See "IKE SAs Fail to

Be Established
Yes

both ends the same?
No
Modify configurations
so that ipsec
protocols at both ends
are the same and the
protocol is ESP
No
so that IPSec policies
match
Yes
Is fault
rectified?
Yes
No
No
so that the ACLs
mirror each other
Yes
Issue 02 (2012-03-30)
Is fault
rectified?
No
Yes
Do ACLs at both
Yes
No
Yes
Do IPSec policies
at both ends match?
Is fault
rectified?

Is fault
rectified?
Yes
No
End
415

Troubleshooting
13 VPN

IKE SAs fail to be
established by NAT
traversal in IPSec

pinged?
No
See "Ping
Operation
Failed"
Is fault
rectified?
Yes
IKE peers correct?
No
No
Modify
configurations of
IKE peers
Is fault Yes
rectified?
Yes

IKE peers the same?
Yes
No
No
Modify
configurations to
be the same
Is fault
rectified?
Yes
Yes
No
End
NOTE
Procedure
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------397
30.0.0.1
0
RD
2
367
30.0.0.1
0
RD
1
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
Issue 02 (2012-03-30)

416

Troubleshooting
13 VPN
NOTE

step 4.
interface.
- IP Routing.
l
Step 4 Check that the settings of IPSec proposals at both ends of the IPSec tunnel are the same and ESP
is used.
Issue 02 (2012-03-30)
Field
IPsec
Proposal
Name
to be the same.
Encapsulatio
n Mode
to be the same.
Transform
The IPSec protocols must be the same. If not, run the transform esp
command to change the IPSec protocols to be the same.

417

Troubleshooting
13 VPN
Field
ESP Protocol

protocol at both ends must be the same. If not, run the ah authenticationalgorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 } command to
algorithm.
If the settings of IPSec proposals at both ends of the IPSec tunnel are the same and ESP is used,
go to step 5.
NOTE
If an IPSec policy template is used, you can choose to configure ACLs. If the ACLs are configured, ensure
that the ACLs at both ends mirror each other.
Check
Item
IPSec
negotiati
on mode
DiffieHellman
(DH)
group
each other.
Acl's step is 5

Acl's step is 5
Issue 02 (2012-03-30)

418

Troubleshooting
13 VPN
go to step 2.
l

Field
Exchange
mode
For IKEv1, the aggressive mode must be used in phase 1. If not, run the
exchange-mode aggressive command to change the negotiation mode.
Negotiated
IKE version
Peer ip
address
IKE peer.
Local ip
address
Remote
name
remote peer.
NATtraversal
NAT traversal must be enabled. If not, run the nat traversal command to
enable NAT traversal.
Local id type
The type of the local IKE peer ID must be name. If not, run the local-idtype command to modify the type of the local IKE peer ID.
Peer id type
The type of the remote IKE peer ID must be name. If not, run the local-idtype command to modify the type of the remote IKE peer ID.

l
Issue 02 (2012-03-30)
Guide - IPSec.
419

Troubleshooting
13 VPN

NOTE
preshared key.
----End

Relevant Alarms
None.
Relevant Logs
None.
13.3.5 GRE over IPSec Fails

Common Causes
l
The link is faulty.
The data flows encapsulated on the GRE tunnel does not match the ACL referenced by the
IPSec policy.
are different.
The settings of IKE peers at both ends of the IPSec tunnel are incorrect. For example, IKE
Issue 02 (2012-03-30)

420

Troubleshooting
13 VPN
Figure 13-16 Troubleshooting flowchart for a GRE over IPSec failure

GRE over IPSec fails
Are
IPSec SAs set up
successfully?
No
See "IPSec SAs

Fail to Be
Established
Yes
Are
Protected Data flows
sent from specified
interface?
No
No
Modify
configurations so
that data flows
are sent from
specified
interface
Is fault
rectified?
Modify the ACL

configuration
Is fault
rectified?
Yes
Issue 02 (2012-03-30)
Yes
No
Yes
Does IP
header encapsulated on
GRE tunnel match
ACL?
Is fault
rectified?

Yes
No
Yes
No
End
421

Troubleshooting
13 VPN
Figure 13-17 Troubleshooting flowchart for a failure to establish IPSec SAs by using GRE over
IPSec
established by GRE
over IPSec
Are IKE SAs set up

successfully?
No
See "IKE SAs

Fail to Be
Established "
Yes

both ends the same?
No
Modify
configurations so
that IPSec
proposals are the
same
No
Modify
configurations so
that IPSec
policies match
Yes
Is fault
rectified?
Yes
No
No
Modify
configurations so
that the ACLs
mirror each other
Yes
Issue 02 (2012-03-30)
Is fault
rectified?
No
Yes
Do ACLs at both
Yes
No
Yes
Do IPSec policies
at both ends match?
Is fault
rectified?

Is fault
rectified?
Yes
No
End
422

Troubleshooting
13 VPN
Figure 13-18 Troubleshooting flowchart for a failure to establish IKE SAs by using GRE over
IPSec
IKE SAs fail to be
established by GRE
over IPSec

pinged?
No
See "Ping
Operation
Failed"
Is fault
rectified?
No
Yes
IKE peers correct?
No
Modify
configurations of
IKE peers
Is fault
rectified?
Yes
No
Yes

IKE peers the same?
Yes
No
Modify
configurations to
be the same
Is fault
rectified?
Yes
Yes
No
End
NOTE
Procedure
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------397
30.0.0.1
0
RD
2
367
30.0.0.1
0
RD
1
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
Issue 02 (2012-03-30)

423

Troubleshooting
13 VPN
NOTE

step 4.
interface.
- IP Routing.
l
Issue 02 (2012-03-30)
Field
IPsec
Proposal
Name
to be the same.
Encapsulatio
n Mode
to be the same.
Transform
AH Protocol

not, run the ah authentication-algorithm { md5 | sha1 } command to change
the authentication algorithms to be the same.

424

Troubleshooting
13 VPN
Field
ESP Protocol

protocol at both ends must be the same. If not, run the esp authenticationalgorithm [ md5 | sha1 ] command to change the authentication algorithm
or run the esp encryption-algorithm [ 3des | des | aes-128 | aes-192 |
aes-256 ] command to change the encryption algorithm.
If the settings of IPSec protocols are the same, go to step 5.

Check
Item
IPSec
negotiati
on mode
DiffieHellman
(DH)
group
each other.
NOTE
If an IPSec policy template is used, you can choose to configure ACLs. If the ACLs are configured, ensure
that the ACLs at both ends mirror each other.
Acl's step is 5

Acl's step is 5
Issue 02 (2012-03-30)
425

Troubleshooting
13 VPN
go to step 2.
l

Field
Exchange
mode
Negotiated
IKE version
Peer ip
address
IKE peer or run the remote-address command to change the peer IP address
of the IKE peer.
Local ip
address
remote-name
remote peer.
NOTE

l
Guide - IPSec.

NOTE
preshared key.
Issue 02 (2012-03-30)

426

Troubleshooting
13 VPN
----End

Relevant Alarms
None.
Relevant Logs
None.
13.3.6 Failed to Establish an SA Using an IPSec Tunnel

Common Causes
l
The link between the IKE peers fails.
The tunnel interfaces are configured incorrectly.
Two ends of the IPSec tunnel use different security proposals.
The IPSec policy configurations are different on two ends of the IPSec tunnel. For example,
the perfect forward secrecy (PFS) configurations are different.
The IKE proposal configurations on two ends of the IPSec tunnel are different.
The IKE peers are configured incorrectly. For example, the two ends use different IKE
negotiation modes or IKE versions, or the peer IP addresses or peer names do not match.
After an IPSec tunnel is configured, an SA fails to be established.
Issue 02 (2012-03-30)

427

Troubleshooting
13 VPN
Figure 13-19 Troubleshooting flowchart for a failure to set up an SA using an IPSec tunnel
An SA fails to be
set up using an
IPSec tunnel
Has IPSec SA
been set up?
Yes
No
No
Has IKE SA
been set up?
Yes
Are tunnel
interfaces configured
correctly?
No
Modify tunnel
interface
configuration
Yes
Is fault
rectified?
Yes
No
Do two
ends use same IPSec
proposal?
No
Configure the same

IPSec proposal for
both ends
Is fault
rectified?
Yes
No
Yes
Do two
ends use same IPSec
profile?
No
Configure the same

IPSec profile for
both ends
Is fault
rectified?
Yes
No
Yes
Are IKE peer
configurations
correct?
No
Modify IKE peer

configuration
Is fault
rectified?
Yes
No
Yes
Do two
ends use same IKE
profile?
No
Configure the same

IKE proposal for
both ends
Is fault
rectified?
Yes
No
Yes
Seek technical
support
End
NOTE
Procedure
Step 1 Check whether an IPSec SA and an IKE SA have been established successfully.
Run the display ike sa [ v2 ] command. Check the Peer, Flag, and Phase fields in the command
output to check IKE peer and the SA phase. The following command output shows that the local
Issue 02 (2012-03-30)

428

Troubleshooting
13 VPN
device has established an IKE SA in phase 1 and an IPSec SA in phase 2 peer with IKE peer
30.0.0.1.
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------397
30.0.0.1
0
RD
2
367
30.0.0.1
0
RD
1
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
If both an IPSec SA and an SA have been established, IKE negotiation is successful, and
IPSec can protect data.
If an IPSec SA fails to be established but an IKE SA is established successfully, go to step

2.
If an IKE SA fails to be established, go to step 6.
Step 2 Check the tunnel interface configuration on both ends of the IPSec tunnel.
Run the undo ipsec profile command on the tunnel interfaces at both ends to unbind the IPSec
profile from the tunnel interfaces. Then check the tunnel interface configuration on both ends:
l If the tunnel interfaces are GRE tunnel interfaces, run the ping command on one interface
to ping the IP address of the other. If the ping fails, check whether the source and destination
IP addresses on the GRE tunnel interfaces match. If not, modify the configuration.
NOTE
Each GRE tunnel interface must have a source IP address and a destination IP address. The source IP
address of one end must be the same as the destination IP address of the other end.
l If the tunnel interfaces are IPSec tunnel interfaces, check the source and destination IP
addresses on the interfaces. One of the IPSec tunnel interfaces must have a source IP address
and a destination IP address, and you do not need to configure the destination IP address for
the other interface. The source IP address of a tunnel interface must be the IP address of the
corresponding physical interface. If the addresses are incorrect, modify the configuration.
If the tunnel interfaces are configured correctly, go to step 3.
Step 3 Check the IPSec proposal configurations on both ends of the IPSec tunnel.
Run the display ipsec proposal command on devices on both ends to check the IPSec proposal
configuration. The following table lists the fields in the command output that you need to check
and follow-up operations.
Issue 02 (2012-03-30)
Field
IPsec
Proposal
Name
The devices must use the same IPSec proposal. If not, run the ipsec
proposal command to specify the same IPSec proposal for the devices.
Encapsulatio
n Mode
The devices must use the same encapsulation mode. If not, run the
encapsulation-mode { transport | tunnel command to configure the same
encapsulation mode for the devices.
Transform
The devices must use the same security protocol. If not, run the transform
{ ah | esp | ah-esp } command to specify the same protocol for the devices.

429

Troubleshooting
13 VPN
Field
AH Protocol
If the Authentication Header (AH) protocol is used, the devices must use the
same AH authentication algorithm. If not, run the ah authenticationalgorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 } command to
specify the same authentication algorithm for the devices.
ESP Protocol
If the Encapsulation Security Protocol (ESP) is used, the devices must use
the same ESP authentication algorithm and encryption algorithm. If the
authentication algorithms are different, run the esp authenticationalgorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ] command to
specify the same authentication algorithm for the devices. If the encryption
algorithms are different, run the esp encryption-algorithm [ 3des | des |
aes-128 | aes-192 | aes-256 ] command to specify the same encryption
algorithm for the devices.
If the devices use the same IPSec protocol configuration, go to step 4.

Step 4 Check the IPSec profile configurations on both ends of the IPSec tunnel.
Run the display ipsec profile command on devices on both ends to check the IPSec profile
configuration.
l
If the IPSec profile configurations on the devices are different, modify the configuration
according to the Huawei AR1200 Series Enterprise Routers Configuration Guide IPSec.
If the devices use the same IPSec profile configuration, go to step 5.
Step 5 Check the IKE peers on both ends.

Run the display ike peer command on both ends to check the IKE peer configuration. The
following table lists the fields in the command output that you need to check and follow-up
operations.
Field
Negotiated
IKE version
The devices must use the same IKE version. If not, run the ike peer command
to specify the same IKE version for the devices.
Remotename
The value of Remote-name must be the same as the local host name of the
IKE peer. If not, run the remote-name command to modify the configuration.
If the IKE peer configurations on both ends are correct, go to step 6.

Step 6 Check the IKE proposal configurations on both ends.
Run the display ike proposal command on both ends to check whether their IKE proposal
settings are the same.
l
If the IKE proposal configurations on the devices are different, modify the configuration
according to the Huawei AR1200 Series Enterprise Routers Configuration Guide IPSec.
If the IKE proposal configurations on both ends are the same, go to step 7.
Issue 02 (2012-03-30)

430

Troubleshooting
13 VPN
NOTE
If preshared key authentication is used, configure a preshared key for each peer. Two devices can establish
a secure connection only if they have the same preshared key. If two ends use different preshared keys,
run the pre-shared-key command to configure the same preshared key for the devices.
----End

Alarms
None.
Logs
None.

Only One End of the Manually Configured IPSec Tunnel Can Encrypt and Decrypt
Data Packets Because the ACL Is Configured Incorrectly
Fault Symptom
As shown in Figure 13-20, GE1/0/0 on Router A and GE1/0/0 on Router B are the two ends of
the IPSec tunnel. IPSec services are deployed on GE1/0/0 and GE1/0/0 so that the IPSec tunnel
can protect the traffic between PC A and PC B.
Figure 13-20 Only one end of the manually configured IPSec tunnel can encrypt and decrypt
data packets because the ACL is configured incorrectly
18.18.18.1/24
GE1/0/0
12.12.12.1/24
GE1/0/0
Internet
RouterA
PC A
10.1.1.1/24
Issue 02 (2012-03-30)
RouterB
PC B
10.1.2.1/24

431

Troubleshooting
13 VPN
Fault Analysis
1.
Run the display ipsec statistics ah/esp command on Router A and Router B to check the
statistics on IPSec packets. On Router A, there are only the statistics on incoming
decapsulated packets, but there are no statistics on outgoing packets. On Router B, there
are only the statistics on outgoing encapsulated packets, but there are no statistics on
incoming decapsulated packets. The packets sent from PC A to PC B may not enter the
IPSec tunnel after being sent out from Router A.
2.
Run the display ipsec sa policy command on Router A and Router B to check the
configuration of the IPSec SAs. Inbound and outbound IPSec SAs are generated at both
ends, the protocol types of the IPSec SAs at both ends are the same, and the SPIs, encryption
modes, and authentication keys at both ends match. The SAs are correct.
3.
Run the display ipsec policy command to check the ACL referenced by the IPSec policy
on Router A. ACL 3101 is applied to Router A and Router B. Then run the display
acl3101 command to check the ACL rule. The ACLs at both ends are the same.
<Router A> display acl 3101
Acl's step is 5
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0
ti
mes matched)
<Router B> display acl 3101
Acl's step is 5
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0
ti
mes matched)
Procedure
Step 2 Run the acl 3101 command to enter the view of ACL 3101.
Step 3 Run the undo rule 5 and rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255 commands to ensure that the ACLs referenced by IPSec policies on Router A and
Router B mirror each other.
Step 4 Run the return command to return to the user view, and then run the save command to save the
configuration.
Step 5 After the preceding operations are complete, run the display ipsec statistics ah/esp command
to view the statistics. The fault is rectified.
----End
Summary
When deploying IPSec services, ensure that flows entering the IPSec tunnel match the ACLs
referenced by the IPSec policies and the ACLs referenced by IPSec policies at both ends of the
IPSec tunnel mirror each other.
Both Peers Cannot Negotiate the SA When an IPSec Policy Template Is Used
Fault Symptom
As shown in Figure 13-21, an IPSec policy is applied to GE1/0/0 on Router A and an IPSec
policy configured by using an IPSec policy template is used on Router B. The data flows
Issue 02 (2012-03-30)

432

Troubleshooting
13 VPN
transmitted between PC A and PC B are protected and the tunnel is used to encapsulate IP
packets. After the configuration is complete, no SA is generated by using IKE negotiation.
Figure 13-21 Both peers cannot negotiate the SA when an IPSec policy template is used
18.18.18.1/24
Eth1/0/0
12.12.12.1/24
Eth1/0/0
Internet
RouterA
RouterB
PC A
10.1.1.1/24
PC B
10.1.2.1/24
Fault Analysis
1.
Run the display ike sa command on Router A and Router B. No SA is established.
2.
Run the ping 18.18.18.1 command on Router A. The ping operation succeeds, indicating
that the network is running properly.
3.
Check the settings of IKE proposals at both ends. The settings of IKE proposals at both
ends are the same.
4.
Check the settings of IPSec proposals at both ends. The settings of IPSec proposals at both
ends are the same.
5.
Check the settings of IPSec policies at both ends. The IPSec policy applied to Router B is
configured by using an IPSec policy template. Run the display ipsec policy command on
Router A to check the configuration of the IPSec policy on Router A. The IPSec policy
applied to Router A uses the traffic-based triggering mode.
<Router A> display ipsec policy name zpolicy005
===========================================
IPsec Policy Group: "zpolicy005"
Using interface: {GE1/0/0}
===========================================
SequenceNumber: 10000
Security data flow: 3300
IKE-peer name: zytpeer
Perfect forward secrecy: None
Proposal name: h
IPsec SA local duration(time based): 9000 seconds
IPsec SA local duration(traffic based): 3600 kilobytes
SA trigger mode: Traffic-based
The IPSec policy applied to Router B is configured by using an IPSec policy template;
therefore, Router B does not initiate negotiation. The IPSec policy applied to Router A uses
the traffic-based triggering mode; therefore, Router A does not initiate negotiation. In this
case, no SA is generated by using IKE negotiation.
Procedure
l
Issue 02 (2012-03-30)
Use the following methods to solve the problem:

433

Troubleshooting
1.
Change the SA triggering mode on Router A.

a.
2.
13 VPN
Run the sa trigger-mode auto command in the system view on Router A to

change the SA triggering mode to automatic.
Construct data flows to trigger negotiation.

a.
Run the ping 10.1.2.1 command on PC A to construct ping packets to match the
ACL referenced by the IPSec policy.
After the preceding operations are complete, run the display ike sa command on Router A
and Router B. SAs are generated.
----End
Summary
After IPSec policies are configured at both ends, at least one end initiates IKE negotiation. If an
IPSec policy template is used, the remote end must initiate negotiation. The SA triggering mode
can be automatic or traffic-based triggering.
13.4 SSL VPN Troubleshooting

13.4.1 Users' Unsuccessful Login to the SSL VPN Gateway
Common Causes
NOTE
AR1200 serves as a Secure Sockets Layer (SSL) virtual private network (VPN) gateway.

l
There is no reachable route between the user and AR1200, so the user and AR1200 cannot
ping each other.
The browser installed on the remote terminal is either Internet Explorer or Firefox. The
installed browser does not support JavaScript or enable the cookie function.
AR1200 does not load the web.zip package containing an sslpvn folder.
The Hypertext Transfer Protocol Secure (HTTPS) is not completely configured on the
AR1200.
The virtual gateway is not completely configured on the AR1200.
A user does not enter the correct user name or password.
Issue 02 (2012-03-30)

434

Troubleshooting
13 VPN
Figure 13-22 Troubleshooting flowchart used when a user fails to log in to the SSL VPN gateway
A user fails to log in to
the SSL VPN gateway.
Is the virtual gateway

completely configured?
No
Configure the virtual

gateway completely
Solve the
problem?
Yes
No
Yes
Is there a reachable
route between the user
and the AR3200?
No
Rectify the route fault
Yes
Solve the
problem?
No
Yes
Does the browser
on the remote terminal
meet requirements?
No
Install a proper
browser
Solve the
problem?
Yes
No
Yes
Has the gateway
loaded the web.zip
package containing a
sslvpn folder?
No
Load a web.zip
package containing a
sslvpn folder
Solve the
problem?
Yes
No
Yes
Is HTTPS completely
Configured on the
gateway device?
No
Configure HTTPS
completely
No
Yes
Does the number
of online users reach the
maximum number?
Yes
Contact the
administrator
Does the user enter

the correct user name and
password?
Solve the
problem?
Yes
No
No
No
Check whether the

entered user name
and password is
identical with the user
information configured
on the virtual gateway
Contact Huawei technical

support personnel

Yes
Solve the
problem?
No
Yes
Issue 02 (2012-03-30)
Yes
Solve the
problem?
End
435

Troubleshooting
13 VPN
Context
NOTE
Procedure
Step 1 Check whether the virtual gateway is completely configured on the AR1200.
l If the web page for login is not displayed, run the display sslvpn gateway [ gatewayname ] command to check whether the virtual gateway connects to an extranet interface and
whether the interface is a Layer 3 interface and configured with an IP address.
l If the web page for login is displayed but no virtual gateway is available, run the display
sslvpn gateway [ gateway-name ] command to check whether the virtual gateway function
is enabled and the entered IP address is the same as that of the corresponding extranet
interface.
l If the virtual gateway is completely configured on the AR1200 and the fault persists, go to
step 2.
Step 2 Check whether there is a reachable route between the user and AR1200 using ping.
l If the ping operation fails, rectify the route fault according to 7.1.1 The Ping Operation
Fails.
Step 3 Check the browser on the remote terminal.
The browser on the remote terminal must meet the following requirements:
l Version: Internet Explorer 6.0 or later versions or Firefox 3.0 or later versions
l Enabled with the JavaScript function
l Enabled with the cookie function
If the browser meets these requirements and the fault persists, go to step 4.
Step 4 Check whether the AR1200 has loaded the web.zip package containing an sslvpn folder.
Run the display current-configuration command in any view to check whether the AR1200
has loaded the web.zip package containing an sslvpn folder.
If the following message is displayed, the AR1200 has loaded the web.zip package containing
an sslvpn folder.
<Huawei> display current-configuration
...
http server load web.zip
...
NOTE
The administrator can define the web.zip package name, but the web.zip package must contain a folder named
sslvpn.
Issue 02 (2012-03-30)

436

Troubleshooting
13 VPN
If the AR1200 does not load the web.zip package containing an sslvpn folder, run the http server
load command.
If the AR1200 has loaded the web.zip package containing an sslvpn folder and the fault persists,
go to step 5.
Step 5 Check whether Hypertext Transfer Protocol Secure (HTTPS) is completely configured on the
AR1200.
NOTE
Ensure that the AR1200 has obtained a digital certificate. If the AR1200 has not obtained a digital certificate,
obtain a digital certificate according to 10.7 PKI Troubleshooting.
Run the display current-configuration command in any view to check whether HTTPS is
completely configured on the AR1200.
If the following message is displayed, HTTPS is completely configured on the AR1200.
<Huawei> display current-configuration
...
http secure-server ssl-policy
user
http secure-server enable
...
If HTTPS is not completely configured on the AR1200, configure HTTPS according to Huawei
AR1200 Series Enterprise Routers Configuration Guide-Security HTTPS Configuration.
If HTTPS is completely configured on the AR1200 and the fault persists, go to step 6.
Step 6 Check whether the number of online users reaches the maximum number allowed by the virtual
gateway or the AR1200.
Access the web page for login and click Login. The system displays a message indicating that
the number of online users reaches the maximum number allowed by the virtual gateway or the
AR1200. View the logs to check whether the maximum number of online users is set
appropriately and contact the administrator for adjustment.
Step 7 Check whether the user name and password are correct.
Enter the web page for login, enter the user name and password, and click Login. If the system
displays a message indicating that the user name or password is incorrect, run the display sslvpn
gateway gateway-name access-user [ user-name ] command to check whether the entered user
name and password are identical with the user information configured on the virtual gateway.
If the user name and password are correct, rectify the RADIUS authentication fault according
to 10.1.1 RADIUS Authentication Fails.
Step 8 Collect the following information. Contact Huawei technical support personnel if the
troubleshooting is unsuccessful.
l Configuration files, log files, and alarm files of the AR
----End

Alarms
N/A
Issue 02 (2012-03-30)

437

Troubleshooting
13 VPN
Logs
l
SVPN_UM/4/DEVICE_MAX_USER
SVPN_UM/4/GATEWAY_MAX_USER
13.5 DSVPN Troubleshooting

13.5.1 A Spoke Fails to Register with a Hub
Common Causes
l
There is no reachable route between the spoke and its remote spoke, or between the spoke
and hub.
Tunnel interfaces of the spoke and hub are Down.
GRE key configurations of the spoke and hub are different.
NHRP authentication string configurations of the spoke and hub are different. For example,
an NHRP authentication string is configured on the hub but not on the spoke; or different
NHRP authentication strings are configured on the spoke and hub.
IPSec profile configurations of the spoke and hub are different.
After DSVPN is configured, a spoke fails to register with a hub.
Issue 02 (2012-03-30)

438

Troubleshooting
13 VPN
Figure 13-23 Troubleshooting flowchart used when a spoke fails to register with a hub
A spoke fails to
register with a
hub
Yes
Are IPSec
profiles bound to
interfaces on the spoke
and hub?
Unbind IPSec
profiles from
the interfaces
No
Are there
reachable routes
between spokes, and
between spokes and
the hub?
No
Ensure that
reachable
routes exist
Is fault Yes
rectified?
No
Yes
Are tunnel
interfaces of
the spoke and
hub Up?
No
Ensure that
tunnel
interfaces are
Up
No
Yes
Are
configurations of
spokes and the
hub the same?
Is fault Yes
rectified?
No
Ensure that
configuration
s on both
ends are the
same
Is fault
rectified?
Yes
No
Yes
Do spokes
and the hub send
NHRP Registration
Request and Reply
packets?
No
No
Check the
configuration
Yes
Is fault
rectified?
No
Yes
Need
IPSec profiles be
bound to
interfaces?
Yes
Is an IPSec SA
established?
Yes
Does the NHRP

work properly?
No
No
See IPSec
troubleshooting
Yes
Seek technical
support
Is fault rectified?
Yes
End
Issue 02 (2012-03-30)

439

Troubleshooting
13 VPN
NOTE
Procedure
Step 1 Check whether IPSec profiles have been bound to interfaces on the spoke and hub.
l If IPSec profiles have been bound to interfaces on the spoke and hub, run the undo ipsec
profile command on the interfaces to unbind the IPSec profiles from the interfaces, and go
to step 2.
l If no IPSec profile is bound to interfaces on the spoke and hub. go to step 2.
Step 2 Check that the spoke has reachable routes to the remote spoke and hub.
Run the display ip routing-table command on the spoke to check whether it has routes to the
remote spoke, and run the display ip routing-table command on the hub to check whether the
hub has routes to the spoke.
l If there is no reachable route between the spoke and its remote spoke, or between the spoke
and hub, check the configurations of routes on the spoke and hub. For the configurations of
routes, see the Huawei AR1200 Series Enterprise Routers Configuration Guide - IP
Routing.
l If there are reachable routes between the spoke and its remote spoke, and between the spoke
and hub, go to step 3.
Step 3 Check that tunnel interfaces of the spoke and hub are Up.
Run the display interface interface-type interface-number command on the spoke and hub to
check whether their connected tunnel interfaces are Up. If some tunnel interfaces are Down, run
the undo shutdown command to enable the interfaces to go Up.
If tunnel interfaces on both ends are Up, go to step 4.
Step 4 Check that configurations of the spoke and hub are correct.
Run the display nhrp peer command on the spoke and hub to check NHRP mapping entries.
If the hub does not have dynamic NHRP mapping entries of the spoke, run the display this
command on tunnel interfaces of the spoke and hub to check whether the configurations on both
ends are the same. The following table lists the fields in the command output that you need to
check and follow-up operations.
Item
NHRP
authenticatio
n
Check whether NHRP authentication string configurations of the spoke and

hub are the same. If they are different, run the nhrp authentication command
to modify the configurations.
GRE key
Check whether the GRE key configurations of the spoke and hub are the same.
If they are different, run the gre key command to modify the configurations.
If the preceding configurations on the spoke and hub are correct, go to step 5.
Issue 02 (2012-03-30)

440

Troubleshooting
13 VPN
Step 5 Check that the spoke has sent NHRP Registration Request packets to the hub and the hub has
replied with NHRP Registration Reply packets.
Run the reset nhrp statistics interface interface-type interface-number command on the spoke
and hub to clear NHRP packet statistics. Enable the spoke to re-register with the hub, and run
the display nhrp statistics interface interface-type interface-number command to check
statistics about NHRP Registration Request and Reply packets.
l If the RegisterRequestSendSuccess field displays 0, the spoke fails to send NHRP
Registration Request packets. Go to step 7.
l If the RegisterRequestSendSuccess field displays a non-zero value but the
RegisterReplyCorrectRecv field displays 0, the spoke has sent NHRP Registration Request
packets to the hub but has not received NHRP Registration Reply packets from the hub. Go
to step 7.
l If both the RegisterRequestSendSuccess and RegisterReplyCorrectRecv fields display nonzero values, NHRP mapping entries of the spoke have been generated on the hub. If IPSec
profiles still need to be bound to interfaces on the spoke and hub, go to step 6.
Step 6 Bind IPSec profiles to interfaces on the spoke and hub.
Run the ipsec profile command on each interface to bind a specified IPSec profile to it. Run the
display ipsec sa command on the spoke and hub to check whether an IPSec SA is established
on interfaces on both ends.
l If an IPSec SA has been established, run the display nhrp peer command on the hub to
check whether NHRP mapping entries of the spoke have been generated. If NHRP mapping
entries of the spoke have been generated on the hub, the fault is rectified. Otherwise, go to
step 7.
l If no IPSec SA is established, rectify the fault according to IPSec Troubleshooting.
----End

Alarms
None.
Logs
None.
13.5.2 Spokes Fail to Learn Routes from Each Other

Common Causes
Issue 02 (2012-03-30)

441

Troubleshooting
13 VPN
There is no reachable route between spokes, and between spokes and the hub.
Tunnel interfaces of spokes and the hub are Down.
A spoke fails to register with the hub.
Spokes fail to learn routes from each other.
Issue 02 (2012-03-30)

442

Troubleshooting
13 VPN
Figure 13-24 Troubleshooting flowchart used when spokes fail to learn routes from each other
Spokes fail to
learn routes from
each other
Yes
Are IPSec
profiles bound to
and hub?
Unbind IPSec
profiles from
the interfaces
No
Are subnet
routes available between
spokes, and between spokes
and the hub?
No
Ensure that
subnet routes
are available
Is fault
rectified?
Yes
No
Yes
Are
NHRP mapping entries
of spokes generated on
hub?
No
Ensure that
NHRP
mapping
entries exist
Is fault
rectified?
Yes
No
Yes
Do spokes
generate NHRP mapping
entries of each other?
No
Yes
No
Need IPSec profiles be

bound to interfaces?
Yes
Is an
IPSec SA
established?
No
Yes
Does
the NHRP work
properly?
No
Yes
See IPSec
troubleshooting
Is fault rectified?
Yes
End
Issue 02 (2012-03-30)

443

Troubleshooting
13 VPN
NOTE
Procedure
to step 2.
Step 2 Check that subnet routes are available between spokes, and between spokes and the hub.
If subnets are configured on spokes and the hub, run the display ip routing-table command on
the local spoke to check whether subnet routes to the remote spoke exist in the local IP routing
table, and run this command on the hub to check whether subnet routes to spokes exist in the
local IP routing table.
l If no subnet route is available between spokes, and between spokes and the hub, configure
subnet routes. For the configurations of routes, see the Huawei AR1200 Series Enterprise
Routers Configuration Guide - IP Routing.
l If subnet routes are available between spokes, and between spokes and the hub, go to step 3.
Step 3 Check that NHRP mapping entries of spokes have been generated on the hub.
Run the display nhrp peer command on the hub to check NHRP mapping entries.
l If no NHRP mapping entry of spokes is generated on the hub, rectify the fault according to
13.5.1 A Spoke Fails to Register with a Hub.
l If NHRP mapping entries of spokes have been generated on the hub, go to step 4.
Step 4 Check that spokes have generated NHRP mapping entries of each other.
l Run the diagnose command in the system view on a spoke to enter the diagnostic view.
l Run the debugging nhrp condition all command to enable NHRP debugging.
l Run the reset nhrp statistics interface interface-type interface-number command to clear
NHRP packet statistics. Enable one spoke to send traffic to the other spoke, and run the
display nhrp statistics interface interface-type interface-number command to check
statistics about NHRP Resolution Request and Reply packets.
If the ResolutionRequestSendSuccess field displays 0, the local spoke fails to send NHRP
Resolution Request packets to the remote spoke. When this occurs, the two spokes cannot
generate NHRP mapping entries of each other. Go to step 6.
If both the ResolutionRequestSendSuccess and ResolutionReplyCorrectRecv fields
display non-zero values, the local spoke has sent NHRP Resolution Request packets to
and has received NHRP Resolution Reply packets from the remote spoke. When this
occurs, the two spokes can generate NHRP mapping entries of each other. If IPSec profiles
still need to be bound to interfaces on the spoke and hub. go to step 5.
Issue 02 (2012-03-30)

444

Troubleshooting
13 VPN
step 6.
----End

Alarms
None.
Logs
None.
13.5.3 Spokes Fail to Communicate When They Have Only

Summarized Routes to a Hub
Common Causes
l
There is no reachable route between spokes and the hub.
Tunnel interfaces of spokes and the hub are Down.
A spoke fails to register with the hub.
Spokes fail to communicate with each other when they have only summarized routes to the hub.
Issue 02 (2012-03-30)

445

Troubleshooting
13 VPN
Figure 13-25 Troubleshooting flowchart used when spokes fail to communicate when they have
only summarized routes to a hub
Spokes fail to
communicate when they
have only summarized
routes to the hub
Yes
Unbind IPSec
profiles from
the interfaces
Are IPSec
profiles bound to
and hub?
No
Are subnet routes
available between spokes
and the hub?
No
Ensure that
subnet routes
are available
No
Yes
Are there NHRP
mapping entries of spokes
on the hub?
Is fault Yes
rectified?
No
Ensure that
NHRP
mapping
entries exist
Is fault Yes
rectified?
No
Yes
Do
spokes generate NHRP
mapping entries of each
other?
No
Yes
Are subnet
routes available between
spokes?
No
Yes
No
Need
IPSec profiles be bound
to interfaces?
Yes
Is an IPSec
SA established?
Yes
Does the
NHRP work
properly?
No
No
See IPSec troubleshooting
Yes
Is fault rectified?
Seek technical
support
Yes
End
Issue 02 (2012-03-30)

446

Troubleshooting
13 VPN
NOTE
Procedure
to step 2.
Step 2 Check that subnet routes are available between spokes and the hub.
If subnets are configured on spokes and the hub, run the display ip routing-table command on
the hub to check whether subnet routes to spokes exist in the local IP routing table.
l If no subnet route is available between spokes and the hub, configure subnet routes. For the
configurations of routes, see the Huawei AR1200 Series Enterprise Routers Configuration
Guide - IP Routing.
l If subnet routes are available between spokes and the hub, go to step 3.
Step 3 Check that NHRP mapping entries of spokes have been generated on the hub.
Run the display nhrp peer command on the hub to check NHRP mapping entries.
l If no NHRP mapping entry of spokes is generated on the hub, rectify the fault according to
13.5.1 A Spoke Fails to Register with a Hub.
l If NHRP mapping entries of spokes have been generated on the hub, go to step 4.
Step 4 Check that spokes have generated NHRP mapping entries of each other.
l Run the diagnose command in the system view on a spoke to enter the diagnostic view.
l Run the debugging nhrp condition all command to enable NHRP debugging.
l Run the reset nhrp statistics interface interface-type interface-number command to clear
NHRP packet statistics. Enable one spoke to send traffic to the other spoke, and run the
display nhrp statistics interface interface-type interface-number command to check
statistics about NHRP Redirect packets.
If the RedirectIndicationSendSuccess field displays 0, the hub fails to send Redirect
packets to the local spoke. Go to step 7.
If both the RedirectIndicationSendSuccess and RedirectIndicationCorrectRecv fields
display non-zero values, the hub has sent Redirect packets to the local spoke, and the local
spoke has received Redirect packets from the hub. If subnet routes are still unavailable
between spokes, go to step 5.
Step 5 Check that subnet routes are available between spokes.
Run the display ip routing-table command on one spoke to check whether it has subnet routes
to the other spoke.
l If no subnet route to the remote spoke is generated on the local spoke, go to step 7.
Issue 02 (2012-03-30)

447

Troubleshooting
13 VPN
l If the subnet route to the remote spoke is generated on the local spoke, and IPSec profiles
still need to be bound to interfaces on the spoke and hub, go to step 6.
step 7.
----End

Alarms
None.
Logs
None.
Issue 02 (2012-03-30)

448

Troubleshooting (V200R002C00 02) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting (V200R002C00 02) PDF

Uploaded by

Copyright:

Available Formats

Huawei AR1200 Series Enterprise Routers

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

About This Document

About This Document

System maintenance engineers

Network monitoring engineers

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

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

Provides additional information to emphasize or supplement

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

About This Document

The keywords of a command line are in boldface.

Command arguments are in italics.

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

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

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

A line starting with the # sign is comments.

Changes in Issue 02 (2012-03-30)

6.1.1 No Dial Tone Is Heard After Offhook

The following information is deleted:

Calling Number Is Not Displayed on the Called Party's Telephone

Busy Tone Is Heard After Offhook

Fax Service Fails

Changes in Issue 01 (2011-12-30)

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

2.10.1 Failed to Manage AR1200 Using CWMP.............................................................................................50

3 Physical Connection and Interfaces.........................................................................................54

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

5.9.1 3G Calls Failed After Dialing Parameters Were Correctly Set.............................................................146

7 IP Forwarding and Routing.....................................................................................................163

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

9.3 Traffic Policing Troubleshooting...................................................................................................................274

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

11.1.2 Troubleshooting Cases........................................................................................................................357

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

About This Chapter

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

1.1 Board Registration Troubleshooting

The board is starting.

The board was reset.

Check whether the board is starting.

Figure 1-1 shows the troubleshooting flowchart.

Huawei Proprietary and Confidential

Huawei AR1200 Series Enterprise Routers

Figure 1-1 A board fails to be registered