Troubleshooting - IP Forwarding and Routing

HUAWEI NetEngine40E/80E Universal Service
Router
V600R006C00
Troubleshooting - IP Forwarding and

Routing
Issue 03
Date 2013-08-20
HUAWEI TECHNOLOGIES CO., LTD.

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

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

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Forwarding and Routing About This Document
About This Document
Purpose
NOTE
l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line
Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On
the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions
of LPUs and SFUs to exchange and forward packets.
This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/
40E in terms of common faults and causes, troubleshooting cases, and FAQs.
This document describes the procedure and method for troubleshooting for the HUAWEI
NetEngine80E/40E.
CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential ii

Product Name Version
HUAWEI NetEngine80E/40E V600R006C00

Router
Intended Audience
This document is intended for:
l System maintenance engineers

l Commissioning engineers
l Network monitoring engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER indicates a hazard with a high level or medium

level of risk which, if not avoided, could result in death or
DANGER
serious injury.
WARNING indicates a hazard with a low level of risk which,

if not avoided, could result in minor or moderate injury.
WARNING
CAUTION indicates a potentially hazardous situation that,

CAUTION if not avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP TIP indicates a tip that may help you solve a problem or save
time.
NOTE NOTE provides additional information to emphasize or

supplement important points of the main text.
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.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential iii

Convention Description
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
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 03 (2013-08-20)

The third commercial release.

The second commercial release.

Initial commercial release.
Issue 03 (2013-08-20) Huawei Proprietary and Confidential iv

Troubleshooting - IP Forwarding and Routing Contents
Contents
About This Document.....................................................................................................................ii

1 ARP Troubleshooting...................................................................................................................1
1.1 The ARP Entries on the Local Device Cannot Be Learnt By the Peer...........................................................................2
1.1.1 Common Causes..........................................................................................................................................................2
1.1.2 Troubleshooting Flowchart..........................................................................................................................................2
1.1.3 Troubleshooting Procedure..........................................................................................................................................3
1.1.4 Relevant Alarm and Log Messages.............................................................................................................................5
1.2 Related Troubleshooting Cases......................................................................................................................................5
1.2.1 PCs on the Same Network Segment Cannot Access Each Other Because ARP Proxy Is Not Enabled.....................5
1.2.2 The Webpage Cannot Be Opened After Service Cutover Due to Improper Static ARP Configurations....................6
1.2.3 ARP Entries on the NE80E/40E Fail to Be Updated in Time Because the Received Gratuitous ARP Packets Do Not
Comply with the RFC Standard............................................................................................................................................9
2 IP Forwarding...............................................................................................................................12
2.1 The Ping Operation Fails..............................................................................................................................................13
2.1.1 Common Causes........................................................................................................................................................13
2.1.2 Troubleshooting Flowchart........................................................................................................................................13
2.1.3 Troubleshooting Procedure........................................................................................................................................15
2.1.4 Relevant Alarms and Logs........................................................................................................................................21
2.2 The Tracert Operation Fails..........................................................................................................................................21
2.2.1 Common Causes........................................................................................................................................................21
2.3 Troubleshooting Cases.................................................................................................................................................24
2.3.1 Improper Static Route Configuration Causes Service Interruption After Any of Multiple Links Fails....................24
3 OSPF Troubleshooting...............................................................................................................27
3.1 The OSPF Neighbor Relationship Is Down.................................................................................................................28
3.1.1 Common Causes........................................................................................................................................................28
Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

3.2 The OSPF Neighbor Relationship Cannot Reach the Full State..................................................................................33
3.2.1 Common Causes........................................................................................................................................................33
3.3 Related Troubleshooting Cases....................................................................................................................................37
3.3.1 OSPF Neighbor Relationship Cannot Become Full Due to Redirection Configured on the Interface......................37
3.3.2 Routes Are Abnormal Because the FA Fields in Type 5 LSAs Are Set Incorrectly.................................................39
3.3.3 The router Receives Two LSAs with the Same LS ID but Fails to Calculate a Route Based on One of the LSAs
............................................................................................................................................................................................41
3.3.4 The OSPF Neighbor Relationship Cannot Be Established Between Two Devices Because the Link Between the
Devices Is Faulty................................................................................................................................................................44
3.3.5 An OSPF Routing Loop Occurs Because Router IDs of Devices Conflict...............................................................45
3.3.6 Services on the Master Plane Are Interrupted Because a Device on the Slave Plane Performs Master/Slave Switchover
on a Bearer Network...........................................................................................................................................................46
3.3.7 User with the Correct User Name and Password Fails to Pass HWTACACS Authentication.................................48
3.3.8 OSPF Neighbor Status Cannot Reach the Full State Because Interface MTUs of Devices on Both Ends of the Link
Are Different.......................................................................................................................................................................50
3.3.9 Why Cannot the OSPF Neighbor Relationship Be Established Between Two Devices Enabled with the Opaque-LSA
Capability?..........................................................................................................................................................................51
3.3.10 Inappropriate OSPF Costs Cause Traffic Interruption During a Link Switchover.................................................53
3.3.11 Downstream Traffic Cannot be Load Balanced Due to the Inappropriate Routing Protocol Route Preference
............................................................................................................................................................................................54
4 IS-IS Troubleshooting................................................................................................................57
4.1 The IS-IS Neighbor Relationship Cannot Be Established............................................................................................58
4.1.1 Common Causes........................................................................................................................................................58
4.2 A Device Fails to Learn Specified IS-IS Routes from Its Neighbor............................................................................63
4.2.1 Common Causes........................................................................................................................................................63
4.3 The IS-IS Neighbor Relationship Flaps........................................................................................................................67
4.3.1 Common Causes........................................................................................................................................................67
4.4 IS-IS Routes Flap..........................................................................................................................................................70
4.4.1 Common Causes........................................................................................................................................................70
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi


4.5.1 An Upper-layer Device Cannot Learn IS-IS Routes Due to Differences in the Types of Routes Imported by IS-IS on
a Huawei Device and a Non-Huawei Device.....................................................................................................................72
5 BGP Troubleshooting.................................................................................................................75
5.1 The BGP Peer Relationship Fails to Be Established....................................................................................................76
5.1.1 Common Causes........................................................................................................................................................76
5.2 BGP Public Network Traffic Is Interrupted.................................................................................................................81
5.2.1 Common Causes........................................................................................................................................................81
5.3 BGP Private Network Traffic Is Interrupted................................................................................................................85
5.3.1 Common Causes........................................................................................................................................................85
5.4.1 Traffic Traverses the Egress Device of an AS Because BGP Delivers Default Routes with Different MEDs.........92
5.4.2 MAN Users Fail to Access the Internet Because of BGP Route Flapping................................................................93
5.4.3 Routing Policies Delivered by a PE Do Not Take Effect Because There Are Multiple Routing Policies with the Same
Name...................................................................................................................................................................................95
5.4.4 A PE Fails to Establish the Public Network LSP Because the Path of IGP Routes Is Incorrect...............................97
5.4.5 Next Hop of the Incoming Traffic Changes After a Master/Slave Switchover of the Attached Non-Huawei Devices
............................................................................................................................................................................................99
5.4.6 The BGP Peer Relationship Goes Down Because of Route Iteration.....................................................................101
5.4.7 Static Routes Do Not Take Effect Because of the Relay Depth..............................................................................102
5.4.8 The Outgoing Traffic Is Not Balanced Because BGP Load Balancing Is Not Enabled..........................................104
5.4.9 Summary Routes Advertised by EBGP Flap Frequently Because Routing Protocols Are Configured with Improper
Preferences........................................................................................................................................................................106
5.4.10 Traffic Is Not Load Balanced Between Two Links Because Load Balancing Is Not Configured on the Peer End
..........................................................................................................................................................................................108
5.4.11 A Router Does Not Receive the Route Advertised by Its IBGP Peer Because the AS_PATH Attribute of the Route
Carries the AS Number of the Peer..................................................................................................................................110
6 RIP Troubleshooting.................................................................................................................113
6.1 Device Does not Receive Partial or All the Routes....................................................................................................114
6.1.1 Common Causes......................................................................................................................................................114
6.1.2 Troubleshooting Flowchart......................................................................................................................................114
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vii

6.1.3 Troubleshooting Procedure......................................................................................................................................116

6.1.4 Relevant Alarms and Logs......................................................................................................................................117
6.2 Device Does not Send Some or All Routes................................................................................................................118
6.2.1 Common Causes......................................................................................................................................................118
6.2.2 Troubleshooting Flowchart......................................................................................................................................118
6.2.3 Troubleshooting Procedure......................................................................................................................................119
6.2.4 Relevant Alarms and Logs......................................................................................................................................121
Issue 03 (2013-08-20) Huawei Proprietary and Confidential viii

Troubleshooting - IP Forwarding and Routing 1 ARP Troubleshooting
1 ARP Troubleshooting
About This Chapter
1.1 The ARP Entries on the Local Device Cannot Be Learnt By the Peer
1.2 Related Troubleshooting Cases
Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1 The ARP Entries on the Local Device Cannot Be Learnt

By the Peer
1.1.1 Common Causes

This fault is commonly caused by one of the following:
l The interface connecting the local device to the peer is not physically Up.
l The IP addresses of the interfaces connecting the local device and the peer are on different
network segments.
l The local device is under ARP attacks.
l The link transmission is unstable or the optical power is insufficient.
l The device software is faulty.
1.1.2 Troubleshooting Flowchart

The HUAWEI NetEngine80E/40E is connected to a peer device but cannot learn the ARP entries
on the peer device.
Figure 1-1 shows the detailed troubleshooting procedure.

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

on the peer device
Is the No Ensure that the Yes

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

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

Are the IP addresses of the
addresses of the interface No interface and the peer Is the fault Yes
and the peer device on the device are on the rectified?
same network same network
segment? segment
Yes No
Does the
number of sent broadcast Yes Ensure that the peer Is the fault Yes
packets and received device and the link
rectified?
unicast packets are normal
increase?
No
No
Seek technical support End
1.1.3 Troubleshooting Procedure
Context
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Run the display interface interface-type interface-number command in the user view to view
the physical status of the interface connecting the local device to the peer.

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

l Configuration files, log files, and alarm files of the devices
----End
1.1.4 Relevant Alarm and Log Messages
Alarm Messages
None.
Log Messages
None.
1.2.1 PCs on the Same Network Segment Cannot Access Each Other
Because ARP Proxy Is Not Enabled
Fault Symptom
On the network shown in Figure 1-2, PC1 and PC2 reside on the same network segment
192.168.0.0/16. The two routers have static routes to the network segment of each other.
After the configuration is complete, PC1 fails to ping PC2.
Figure 1-2 Networking diagram for the scenario that the PCs on the same network segment
cannot access each other
RouterA RouterB
Network Network
PC1 PC2
192.168.1.2/16 192.168.1.1/24 192.168.2.1/24 192.168.2.2/16

00e0-fc39-80aa 00e0-fc39-80bb
Fault Analysis
1. Run the arp -a command on PC1 to check all ARP entries. You can find that there is no
mapping between the IP address and MAC address of PC2. It indicates that the ARP entry
is not learned when the ping command is run. When Router A receives the ARP Request
packet from PC1, it finds that the destination IP address in the packet is not the IP address
of the local interface. Therefore, Router A discards the ARP Request packet.

NOTE
Usually, when the router receives an ARP Request packet, it checks whether the packet is for itself. If yes,
the router sends an ARP Reply packet; if no, the router discards the ARP Request packet.
If routed proxy ARP is enabled, the router does not directly discard a received ARP Request packet that
is not for itself. Instead, it checks its own routing table to see if there is a route to the intended destination
of the ARP Request packet. If there is such a route and conditions permit, the router offers its own MAC
address to the sender of the ARP Request packet in reply as a proxy. Then, the sender of the ARP Request
packet sends the packets to the router, which will forward the packets to the intended destination.
Procedure
Step 1 Run the system-view command to enter the system view on RouterA (or RouterB).
Step 2 Run the interface interface-type interface-number command to enter the view of the customer-
facing interface.
Step 3 Run the arp-proxy enable command to enable routed proxy ARP on the interface.
Step 4 Run the ping 192.168.2.2 command on PC1 to ping the IP address of PC2. Then, run the arp -
a command on PC1. You can find that the MAC address corresponding to the IP address of PC2
is the MAC address of the interface connected to PC1 on RouterA.
C:\Documents and Settings\Administrator>arp -a
Interface: 192.168.1.2 --- 0x2
Internet Address Physical Address Type
192.168.2.2 00e0-fc39-80aa dynamic
When the configuration is complete, PC1 can successfully ping PC2, and the fault is rectified.
----End
Summary
Proxy ARP is a technique by which a device serving as a proxy on a given network answers the
ARP requests for a network address that is not on that network. There are three proxy ARP
modes that can be applied in different situations:
l Routed proxy ARP: enables the communications between computers on the same network
segment but on different physical networks.
l Proxy ARP within a VLAN: enables the communications between computers within a
VLAN configured with user isolation.
l Proxy ARP between VLANs: enables Layer 2 communications between computers in
different VLANs.
1.2.2 The Webpage Cannot Be Opened After Service Cutover Due

to Improper Static ARP Configurations
Fault Symptom
Users access the backbone network through Router A and Router B. Traffic from the access
network is sent to Router A through Eth-Trunk 1.
Router A then sends the traffic to a packet analyzer to which Router A is connected through GE
1/0/2. The packet analyzer is deployed to analyze the packets from the access network and

packets from the backbone network. After analyzing the packets, the packet analyzer returns the
packets through the interface from which the packet analyzer receives the packets.
Figure 1-3 The Webpage Cannot Be Opened After Service Cutover Due to Improper Static ARP
Configurations
Backbone
Network
192.168.100.50 RouterA RouterB
Packets GE 1/0/2
Analyzer
Eth-Trunk 1
SwitchA SwitchB
Access
Network
After service cutover, it is found that the webpage cannot be opened.
Fault Analysis
1. Check the routing table on Switch A.
You can find that the routing table of Switch A is correct. Packets destined for the target
network are load balanced to Router A.
2. Run the display current-configuration command on Router A to check the current
configuration. You can find that a traffic policy is configured on the associated interface.
[RouterA] display current-configuration
#
interface Eth-Trunk1
description HUAWEI-RouterA
ip address 10.1.1.1 255.255.255.252
traffic-policy Fivedai inbound
pim sm
ospf cost 1000
mpls

mpls ldp
#
traffic policy Fivedai
classifier Fivedai behavior Fivedai
traffic classifier Fivedai operator or
if-match acl 3100
traffic behavior Fivedai
redirect ip-nexthop 192.168.100.50
acl number 3100
rule 5 permit tcp destination-port eq www
All packets sent by Switch A for accessing the webpage are redirected to the packet
analyzer.
3. Run the display traffic policy statistics command to check the packets matching the traffic
policy. You can find that all the packets match the traffic policy.
[RouterA] display traffic policy statistics interface GigabitEthernet 1/0/0
inbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet1/0/0
Traffic policy inbound: Fivedai
Traffic policy applied at 2009-07-02 21:04:40
Statistics enabled at 2009-07-10 02:39:28
Statistics last cleared: Never
Rule number: 5 IPv4, 0 IPv6
Current status: OK!
Classifier: Fivedai operator or

if-match ACL 3100
rule 5 permit tcp destination-port eq www
584,574,637 bytes, 4,505,760 packets
Last 30 seconds rate 1,858 pps, 2,270,232 bps
4. Run the display current-configuration command on Router A to check the related

configurations of GE 1/0/2 and the packet analyzer.
[RouterA] display current-configuration
#
arp static 192.168.100.50 00e0-1111-1111
You can find that Router A has a static ARP entry with the MAC address being the MAC
address of the packet analyzer and the IP address being the IP address of the packet analyzer.
When a packet is sent from GE 1/0/2 to the packet analyzer, the destination MAC address
of the packet is 00e0-1111-1111. After the packet analyzer returns the analyzed packet, the
MAC address of the packet received on GE 1/0/2 is still 00e0-1111-1111, not the MAC
address (2222-2222-2222) of GE 1/0/2. As a result, the packet is discarded.
So far, the fault has been located.
Procedure
Step 1 Run the system-view command on Router A to enter the system view.
Step 2 Run the undo arp static 192.168.100.50 00e0-1111-1111 command to delete the original ARP
configurations.
Step 3 Run the arp static 192.168.100.50 2222-2222-2222 command to reconfigure a static ARP entry
and change the MAC address of the ARP entry to the MAC address of GE 1/0/2.
After the configuration, the MAC address of a packet sent by GE 1/0/2 to the packet analyzer
is the MAC address of GE 1/0/2. Therefore, the MAC address of the packet returned by the

packet analyzer is the MAC address of GE 1/0/2, and the packet can be received and forwarded.
The user can normally open the webpage. Therefore, the fault is rectified.
----End
Summary
When configuring static ARP on a device connected to a special device, fully consider the
impacts of packet processing by the special device.
1.2.3 ARP Entries on the NE80E/40E Fail to Be Updated in Time

Because the Received Gratuitous ARP Packets Do Not Comply with
the RFC Standard
Fault Symptom
A CE, which is a non-Huawei device, is connected to two switches for accessing two NE80E/
40Es that are in a VRRP backup group. Router A serves as the master device, and Router B
serves as the backup device. GE 1/0/0 and GE 1/0/1 on the CE are connected to the two switches
respectively. The networking diagram is as follows:
Figure 1-4 Typical Network Diagram for VRRP

Router A Router B
GE1/0/0 GE1/0/0
GE2/0/0 GE2/0/0
Switch A Switch B
GE1/0/0 GE1/0/1
0007-7243-8778 0007-7266-c77a
CE
168.1.1.1 168.1.1.2
After the link between Switch A and the CE is disconnected, services are interrupted immediately
and then restored 20 minutes later. During service interruption, packets are lost in the ping from
the CE to an extranet server or to the master device in the VRRP backup group.
Fault Analysis
1. To check the connectivity between Router A and the CE, first change the MTUs on GE
1/0/0 of Router A, and GE 1/0/0 and GE 2/0/0 of Router B to 2000. Then, send 100 jumbo
frames longer than 1518 bytes from Router A to GE 1/0/1 on the CE. One jumbo frame is
found lost.

NOTE
Since the jumbo frames on the network are only a few, using jumbo frames in the ping operation
facilitates checking the connectivity between devices. So, the MTU is increased to allow the
transmission of jumbo frames. Before changing the MTU, you need to evaluate whether the change
has any impact on the existing services. If the change will affect the existing services, do not change
the MTU.
<RouterA>ping -c 100 -s 2000 -m 10 -vpn cnc_signal 168.1.1.2
PING 168.1.1.2: 2000 data bytes, press CTRL_C to break
Request time out
--- 168.1.1.2 ping statistics ---

100 packet(s) transmitted
99 packet(s) received
1.00% packet loss
round-trip min/avg/max = 4/15/928 ms
2. Check the status of GE 1/0/0 and GE 2/0/0 on Router B. The statistics on the two interfaces
show that Router B has received all the 100 jumbo frames and forwarded them to the CE.
In the reverse direction, however, only 99 packets have been returned to Router B, and
Router B has forwarded all the packets to Router A. It indicates that the forwarding between
the two devices is normal and packet loss occurs on the CE.
<RouterB>display interface GigabitEthernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Description : Cc-Cc#GE#2585.2/0/8-HX.1/0/4-B, Switch Port
The Maximum Transmit Unit is 2000 bytes
Statistics last cleared: 2009-08-04 04:18:10
Last 30 seconds input rate: 12240 bits/sec, 18 packets/sec
Last 30 seconds output rate: 830976 bits/sec, 476 packets/sec
Input: 257912 bytes, 910 packets
Output: 4222228 bytes, 18610 packets
Input:
Unicast: 354, Multicast: 471
Broadcast: 85, Jumbo: 100
CRC: 0, Symbol: 0
Overrun: 0 , InRangeLength: 0
LongPacket: 0 , Jabber: 0, Alignment: 0
Fragment: 0, Undersized Frame: 0
RxPause: 0
Output:
Lost: 0, Overflow: 0, Underrun: 0
TxPause: 0
<RouterB>display interface GigabitEthernet 2/0/0
GigabitEthernet2/0/0 current state : UP
Description : CC-CC#GE#2585.H40.1/0/4-2511.H7810.0/0/11-B, Switch Port
The Maximum Transmit Unit is 2000 bytes
Statistics last cleared: 2009-08-04 04:18:10
Last 30 seconds input rate: 307248 bits/sec, 156 packets/sec
Last 30 seconds output rate: 304576 bits/sec, 156 packets/sec
Input: 1458695 bytes, 5993 packets
Output: 1448674 bytes, 5992 packets
Input:
CRC: 0, Symbol: 0
Overrun: 0 , InRangeLength: 0
LongPacket: 0 , Jabber: 0, Alignment: 0
Fragment: 0, Undersized Frame: 0
RxPause: 0
Output:

Lost: 0, Overflow: 0, Underrun: 0

TxPause: 0
3. Run the display arp interface gigabitethernet 2/0/0 command on Router B to check the
dynamic entries in the ARP mapping table on GE 2/0/0. The command output shows that
the MAC address of GE 1/0/1 on the CE is not contained in the mapping table.
4. Get packets head on Router B. It is found that gratuitous ARP packets are continuously
sent by the CE, but the format of the packets does not comply with the relevant RFC
standard. Therefore, the Router A directly discards such packets and does not update the
ARP entries in the ARP mapping table. After 20 minutes, services are restored when the
ARP entries are aged out and updated automatically.
Procedure
Step 1 Run the reset arp all command in user view to reset ARP entries and force the device to learn
ARP entries again. The CE successfully responds to the ARP Request packet and services are
restored.
The preceding operations are performed on Router A and Router B.
Step 2 Run the system-view command to enter the system view.
Step 3 Run the interface gigabitethernet 1/0/0 command to enter the view of GE 1/0/0.
Step 4 Run the mtu command to restore the original MTU setting.
----End
Summary
If the format of gratuitous ARP packets does not comply with the relevant standard, the ARP
entries on the connected devices cannot be updated in time.

Troubleshooting - IP Forwarding and Routing 2 IP Forwarding
2 IP Forwarding
About This Chapter
2.1 The Ping Operation Fails
2.2 The Tracert Operation Fails
2.3 Troubleshooting Cases

2.1 The Ping Operation Fails

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

Figure 2-1 shows the troubleshooting flowchart.

Figure 2-1 Troubleshooting flowchart for a ping failure

The destination
address cannot be
pinged
Yes Increase the value Yes

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

Correctly perform the Is fault
ping operation
ping operation rectified?
correct?
No No
Do FIB and No Ensure that FIB and Yes

Is fault
ARP entries exist on the ARP entries are
rectified?
device? correct
No
Yes
Locate the direction and

device where the fault occurs
Is a CPU
No Configure an attack Yes
attack defense policy Is fault
defense policy on
configured on the rectified?
the device
device?
Yes No
Do error Yes Yes

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


NOTE
Save the results of each troubleshooting step. If your troubleshooting fails to correct the fault, you will
have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check whether 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 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 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.
If the fault persists, go to Step 2.
NOTE
To ping a private network address from a PE, you need to run the ping -vpn-instance vpn-name destination-
address command. The parameter -vpn-instance vpn-name specifies the VPN instance to which the pinged
destination address belongs.
Step 2 Check that there are no incorrect operations.

1. Check whether 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 (ifindex:6)
Line protocol current state : UP
Last line protocol up time: 2008-08-30 10:56:22

Description:HUAWEI, GigabitEthernet1/0/0 Interface

Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
2. Check whether the ping -i command is run, that is, whether an outbound interface is
specified. If a broadcast interface such as an Ethernet interface is specified as an outbound
interface, the destination address to be pinged must be the address of the directly connected
interface. If this condition is not met, you need to specify the directly connected interface
as the outbound interface. If the fault persists, go to Step 3.
NOTE
If -f is specified in a ping command, it indicates that Ping packets do not support packet fragmentation. If
-i interface-name is specified in a ping command, it indicates that interface-name is specified as the
outbound interface of Ping packets and the destination address is used as the next-hop address.
Step 3 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.
l Check whether the value of the CRC field on an Ethernet interface increases after this display
command is run again.
l Check whether the value of the SDH alarm field or SDH error field on a POS 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 4.
Step 4 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 2-2 Application scenario of a ping operation

Ping packet
Source Intermediate device Destination
Check whether 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 [ slot slot-id ] command to check ICMP packet transmission. The
following information is displayed:
<HUAWEI> display icmp statistics
Input: bad formats 0 bad checksum 0
echo 36 destination unreachable 9
source quench 0 redirects 43
echo reply 18 parameter problem 0
timestamp 0 information request 0

mask requests 0 mask replies 0

time exceeded 6
Mping request 0 Mping reply 0
Output:echo 20 destination unreachable 71438
timestamp 0 information reply 0
time exceeded 0
NOTE
Run the display icmp statistics command on the source end to view statistics about packets on the main control
board.
Run the display icmp statistics slot slot-id 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.
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 5.
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 using source and destination
addresses.
Use 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.
Use the following configurations as an example:
#
interface GigabitEthernet2/0/0
ip address 1.1.1.2 255.255.255.252
traffic-policy 3000 inbound
#
interface GigabitEthernet3/0/0
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 statistics interface 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 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
6.
Step 5 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 6.
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 6 Check whether a local attack defense policy is configured on the node where the fault occurs.
If some devices have been attacked by ICMP packets, the rate at which ICMP packets are sent
to the CPU is decreased and excess ICMP packets are dropped to protect against attacks. As a
result, the ping operation fails.
Run the display current-configuration | include cpu-defend command to check whether there
are configurations of a CPU attack defense policy in the configuration file of the device.
l If a CPU attack defense policy is configured, run the display cpu-defend policy policy-
number and display cpu-defend car commands to check the following:
Check whether the blacklist that contains the source or destination IP address of ping
packets is configured.
Check whether the CAR is configured. If the CAR is configured, check whether 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 7.
l If no CPU attack defense policy is configured, go to Step 7.
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.

l Check whether the value of the CRC field on an Ethernet interface increases after this display
command is run again.
l Check whether the value of the SDH alarm field or SDH error field on a POS 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.
After finding the node where the fault occurs, do as follows to locate the layer where the fault
occurs.
1. Check whether ICMP packets are sent and received normally.

time exceeded 0
time exceeded 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 [slot slot-num ] command to check whether the network layer
is normal.
<HUAWEI> display ip statistics slot 2
Input: sum 123174 local 0
bad protocol 0 bad format 0
bad checksum 0 bad options 0
discard srr 0 TTL exceeded 0
Output: forwarding 0 local 268816
dropped 0 no route 0
Fragment: input 0 output 0
dropped 0
fragmented 0 couldn't fragment 0
Reassembling:sum 0 timeouts 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 ICMP packets can be delivered by the network layer normally.
Configure an ACL to check whether ICMP packets are delivered to an interface board.
Use 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.
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.
l Results of the preceding troubleshooting procedure
----End
2.1.4 Relevant Alarms and Logs
Relevant Alarms
None.
Relevant Logs
None.
2.2 The Tracert Operation Fails
2.2.1 Common Causes

l Routing entries or ARP entries are incorrect.

l Tracert packets are modified. As a result, these packets are dropped because they fail
validity check at the network layer.


Figure 2-3 Troubleshooting flowchart for a tracert failure
The user cannot tracert

the destination address
No Rectify the Yes

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

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

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

Rectify the forwarding Yes
destination end reply Is fault
with ICMP error fault rectified?
packets?
No No
Context
NOTE
Save the results of each troubleshooting step. If your troubleshooting fails to correct the fault, you will
have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that FIB entries and ARP entries are correct.
Run the display fib slot-number dest-ip-address command on each device to check whether
there is a route to the destination address.

l If there is no route to the destination address, see the OSPF Troubleshooting or IS-IS
Troubleshooting.
l If there is a route to the destination address and Tracert packets are transmitted over an
Ethernet link, run the display arp slot slot-number command to check whether the required
ARP entry exists. If the required ARP entry does not exist, go to Step 3. If the fault persists,
go to Step 2.
Step 2 Check that the device sending Tracert packets (the source end) does not receive ICMP error
packets.
Run the display icmp statistics command on the source end to check whether it receives ICMP
error packets.
time exceeded 12
time exceeded 0
During the tracert operation, run the display icmp statistics command several times to check
the tracert result. If the increased value of the total number of Destination Unreachable packets
and Time Exceeded packets in the Input field equals the number of sent Tracert packets, it
indicates that the source end receives ICMP error packets but the ICMP error packets are
discarded by the source end. Contact Huawei technical support personnel. Otherwise, go to Step
3.
----End

None.

2.3 Troubleshooting Cases

2.3.1 Improper Static Route Configuration Causes Service
Interruption After Any of Multiple Links Fails
Networking Environment
On the network shown in Figure 2-4, there are three links between Router A and Router B. On
Router A, three static routes to 10.1.3.0/24 are configured for traffic load balancing.
After one of the three links is interrupted, services between Router A and Router B are all
interrupted, and traffic is not switched to the other two links for being forwarding.
Figure 2-4 Networking diagram for traffic load balancing among static routes
10.1.3.0/24
RouterA RouterB RouterC
Table 2-1 Interfaces and IP addresses
Local Device Local Interface Remote Interface Remote Device

and Its IP Address and Its IP Address
Router A GE 1/0/0.1 GE 1/0/0.1 Router B

172.168.68.46/27 172.168.68.54/27

172.168.68.110/27 172.168.68.118/27

172.168.68.174/27 172.168.68.180/27
Router B GE 1/0/1 GE 1/0/0 Router C

10.1.3.1/24 10.1.3.2/24
Fault Analysis
1. Run the display ip routing-table ip-address [ mask | mask-length ] command on Router
A to view detailed information about the routes to 10.1.3.0/24. The command output shows
that a route becomes a blackhole route.
<HUAWEIA> display ip routing-table 10.1.3.0 24
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public

Summary Count : 3
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.3.0/24 Static 60 0 RD 172.168.68.54 NULL0

Static 60 0 RD 172.168.68.118
GigabitEthernet1/0/0.2
Static 60 0 RD 172.168.68.180
GigabitEthernet1/0/0.3
If a device has multiple routes working in load balancing mode and one of the routes is a
blackhole route, the device forwards packets based on the first routing entry in the routing
table, but does not perform traffic load balancing among multiple routes. Based on the
sequence in which Forwarding Information Base (FIB) entries are delivered, the FIB entry
with NULL0 as an outbound interface is always the first entry. As a result, all packets are
forwarded based on the blackhole route and are discarded, causing all services to be
interrupted.
2. Run the display current-configuration command on Router A to view the static route
configuration.
#
ip route-static 10.1.3.0 255.255.255.0 NULL0 preference 100
ip route-static 10.1.3.0 255.255.255.0 172.168.68.54
ip route-static 10.1.3.0 255.255.255.0 172.168.68.118
ip route-static 10.1.3.0 255.255.255.0 172.168.68.180
#
In normal situations, a router forwards packets based on the second route in the routing
table, and finds an outbound interface GE 1/0/0.1 based on the next hop address of the
direct route 172.168.68.54/27 of GE 1/0/0.1. When GE 1/0/0.1 is faulty, this direct route
is withdrawn. The router needs to iterate another route to find another outbound interface
based on the next hop address 172.168.68.54, and finally selects the fifth route in the routing
table. The outbound interface of the fifth route is NULL0. In the route iteration process,
the route preference is the default value 60, not the route preference 100 after iteration.
Therefore, the iterated route is selected to forward packets and traffic is sent out from
NULL0, causing service interruption.
Procedure
Step 2 Run the undo ip route-static ip-address { mask | mask-length } nexthop-address command to
delete all static route configurations.
[HUAWEIA] undo ip route-static 10.1.3.0 255.255.255.0 172.168.68.54
Step 3 Run the ip route-static ip-address { mask | mask-length } interface-type interface-number

nexthop-address command to configure a static route and specify a next hop and an outbound
interface.
[HUAWEIA] ip route-static 10.1.3.0 255.255.255.0 GigabitEthernet 1/0/0.1
172.168.68.54
172.168.68.118
172.168.68.180
Step 4 Run the display ip routing-table ip-address [ mask | mask-length ] command to view detailed
routing information. The command output shows that the blackhole route is deleted and the
traffic is switched to the other two links that are working properly.

----End
Summary
If an outbound interface is specified for a configured static route, this static route will be deleted
when a link is faulty. This prevents incorrect route iteration.

Troubleshooting - IP Forwarding and Routing 3 OSPF Troubleshooting
3 OSPF Troubleshooting
About This Chapter
3.1 The OSPF Neighbor Relationship Is Down
3.2 The OSPF Neighbor Relationship Cannot Reach the Full State

3.1 The OSPF Neighbor Relationship Is Down
3.1.1 Common Causes

l The BFD is faulty.

l The other device is faulty.
l CPU usage on the MPU or LPU of the faulty device is too high.
l The link is faulty.
l The interface is not Up.
l The IP addresses of the two devices on both ends of the link are on different network
segments.
l The router IDs of the two devices conflict.
l The area types of the two devices are inconsistent.
l The 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 3-1 shows the troubleshooting flowchart.

Figure 3-1 Troubleshooting flowchart for the fault that the OSPF neighbor relationship is Down
The OSPF neighbor
relationship is Down
Check the logs to find the

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

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

Check the remote Is fault
Due to SequenceNum
device rectified?
Mismatch
No No
Seek technical
support
End
Context
NOTE
Saving the results of each troubleshooting step is recommended. If you are unable to correct the fault, you
will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check logs to find the cause of the fault.
Run the display logbuffer command, and you can find the following log information:
NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=
[USHORT], NeighborRouterId=[IPADDR], NeighborAreaId=[ULONG], NeighborInterface=
[STRING],NeighborDownImmediate reason=[STRING], NeighborDownPrimeReason=[STRING],
NeighborChangeTime=[STRING])
Check the NeighborDownImmediate reason field which records the cause of the fault. The
possible causes of the fault are as follows:

l Neighbor Down Due to Inactivity

If a device does not receive a Hello packet from its neighbor within the timeout period, the
OSPF neighbor relationship goes Down. In this case, go to Step 2.
l Neighbor Down Due to Kill Neighbor
If the interface is Down, BFD is Down, or the reset ospf process command is run, the OSPF
neighbor relationship goes Down. In this case, check the NeighborDownPrimeReason field
to determine the specific cause of the fault.
If the value of the NeighborDownPrimeReason field is Physical Interface State Change,
it indicates that the interface status has changed. In this case, run the display interface
[ interface-type [ interface-number ] ] command to check the interface status, and then
troubleshoot the interface fault(Refer to Troubleshooting - Layer 2 Network).
If the value of the NeighborDownPrimeReason field is BFD Session Down, it indicates
that the BFD session status is Down. In this case, troubleshoot the BFD fault (See the
section BFD Session Cannot Go Up ).
If the value of the NeighborDownPrimeReason field is OSPF Process Reset, it indicates
that the reset ospf process command has been run. The OSPF process is restarting. Wait
until OSPF re-establishes the OSPF neighbor relationship.
l Neighbor Down Due to 1-Wayhello Received or Neighbor Down Due to SequenceNum
Mismatch
When the OSPF status on the remote device goes Down first, the remote device sends a 1-
Way Hello packet to the local device, causing OSPF on the local device to go Down. In this
case, troubleshoot the fault that caused OSPF on the remote device to go Down.
l In other cases, go to Step 9.
Step 2 Check that the link between the two devices is normal.
Check whether the link between the two devices is normal, and whether the transmission devices
are normal. For the details, see the section Physical Connection and Interfaces. If the link is
normal, go to Step 3.
Step 3 Check that the CPU usage is within the normal range.
Run the display cpu-usage command to check whether the CPU usage on the MPU or LPU 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 (See the section HUAWEI NetEngine80E/40E Router - Layer 2 Network ).
If the physical status of the interface is Up, run the display ospf interface command to check
whether the OSPF status of the interface is Down. The normal status is DR, BDR, DR Other, or
P2P.
<HUAWEI> display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)
IP Address Type State Cost Pri DR BDR
192.1.1.1 Broadcast DR 1 1 192.1.1.1 0.0.0.0

l If the OSPF status of the interface is Down, run the display ospf cumulative command to
check whether the number of interfaces with OSPF enabled in the OSPF process exceeds
the upper threshold. If so, reduce the number of interfaces with OSPF enabled. For the
details about upper threshold of the interfaces, see the FAF/License file of the product.
<HUAWEI> display ospf cumulative
Cumulations
IO Statistics
Type Input Output
Hello 0 86
DB Description 0 0
Link-State Req 0 0
Link-State Update 0 0
Link-State Ack 0 0
SendPacket Peak-Control: (Disabled)
ASE: (Disabled)
LSAs originated by this router
Router: 1
Network: 0
Sum-Net: 0
Sum-Asbr: 0
External: 0
NSSA: 0
Opq-Link: 0
Opq-Area: 0
Opq-As: 0
LSAs Originated: 1 LSAs Received: 0
Routing Table:
Intra Area: 1 Inter Area: 0 ASE: 0
Up Interface Cumulate: 1
l If the OSPF status of the interface is not Down, go to Step 5.
Step 5 If the interface is connected to a broadcast network or an NBMA network, ensure that the IP
addresses of the two devices are on the same network segment.
l If the IP addresses of the two devices are on different network segments, modify the IP
addresses of the devices to ensure that the IP addresses are on the same network segment.
l If the IP addresses of the two devices are on the same network segment, go to Step 6.
Step 6 Check that the MTUs of the interfaces on both ends are consistent.
If the ospf mtu-enable command is run on interfaces on both ends, the MTUs of the two
interfaces must be consistent. If the MTUs are inconsistent, the OSPF neighbor relationship
cannot be established.
l If the MTUs of the two interfaces are inconsistent, run the mtu mtu command in the interface
view to change the MTUs of the two interfaces to be consistent.
l If the MTUs of the two interfaces are consistent, go to Step 7.
Step 7 Check whether there is an interface with a priority that is not 0.
On broadcast and NBMA network segments, there must be at least one interface with a priority
that is not 0 to ensure that the DR can be correctly elected. Otherwise, the OSPF neighbor
relationship can only reach the two-way state.
Run the display ospf interface command to view the interface priority.
Interfaces


1.1.1.41 Broadcast DR 1 1 1.1.1.41 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
111.1.1.1 Broadcast BDR 1 1 111.1.1.2 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
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
3.2 The OSPF Neighbor Relationship Cannot Reach the Full

State
3.2.1 Common Causes

l The link is faulty and the OSPF packets are dropped.

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


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

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

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

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

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

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

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

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

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

Intra Area: 1 Inter Area: 0 ASE: 0

Up Interface Cumulate: 1
l The neighbor relationship is always in the Init state.

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

111.1.1.1 Broadcast DROther 1 0 111.1.1.2 0.0.0.0
If the DR priorities of the interfaces with OSPF enabled are 0 and the state is
DROther, both the local device and its neighbor are not the DR or BDR and they do not
need to exchange LSAs. In this case, no action is required.
If the DR priorities of the interfaces enabled with OSPF are not 0, go to Step 2.
l The neighbor relationship is always in the Exstart state.
If the status of the neighbor relationship is always displayed as Exstart, it indicates that the
devices are exchanging DD packets but fail to synchronize LSDBs, which occurs in the
following cases:
Packets that are too long cannot be normally sent and received.
Run the ping -s 1500 neighbor-address command to check the sending and receiving of
packets that are too long. If the two devices fail to ping each other, solve the link problem
first.
The OSPF MTUs of the two devices are different.
If the ospf mtu-enable command is run on the OSPF interfaces, check whether the OSPF
MTUs on the two interfaces are the same. If they are not the same, change the MTUs of
the interfaces to ensure that the MTUs of the interfaces are the same.
l The neighbor relationship is always in the Exchange state.
If the status of the neighbor relationship is always displayed as Exchange, the two devices
are exchanging DD packets. In this case, follow the troubleshooting procedure provided for
when the neighbor relationship is in the Init state. If the fault persists, go to Step 2.
l The neighbor relationship is always in the Loading state.
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
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.
3.3.1 OSPF Neighbor Relationship Cannot Become Full Due to

Redirection Configured on the Interface
Fault Symptom
As shown in Figure 3-3, Router A is dual-homed to Router C and Router D. After link and IP
address adjustment, GE 1/0/2 on Router A is connected to Router C, as shown in Figure 3-4.
Figure 3-3 Networking diagram of the fault that OSPF neighbor relationship cannot become
Full (before link adjustment)
Router C Router D
GE1/0/5
GE1/0/4 GE1/0/5
GE1/0/4
GE1/0/1 GE1/0/2
GE1/0/2 GE1/0/1
Router A Router B

Figure 3-4 Networking diagram of the fault that OSPF neighbor relationship cannot become
Full (after link adjustment)
Router C Router D
GE1/0/5
GE1/0/4 GE1/0/5
GE1/0/4
GE1/0/1 GE1/0/2
GE1/0/2
GE1/0/1
Router A Router B
After the adjustment, the OSPF neighbor relationship cannot be established between Router A
and Router C, and the neighbor relationship on Router C remains in the ExStart state.
Fault Analysis
1. Run the display ospf peer command on Router C to view the State field. The command
output shows that the OSPF neighbor relationship is in the ExStart state.
It indicates that Router C has received a Hello packet from the neighbor and replied with
a DD packet but not received any DD packet from the neighbor.
2. Receiving the Hello packet from the neighbor indicates that the link between Router A and
Router C works properly. Therefore, the fault may have occurred because Router C
discarded received DD packets instead of sending them to the CPU.
Run the interface interface-type interface-number command to enter the interface view.
Then, run the display this command. The command output shows that the interface is
configured with a traffic policy as shown below.
<HUAWEI> system-view
[HUAWEI] interface gigabitethernet 1/0/4
[HUAWEI-GigabitEthernet1/0/4] display this
#
interface gigabitethernet 1/0/4
undo shutdown
ip address 222.61.1.185 255.255.255.252
traffic-policy Redirect inbound
#
Based on the traffic policy and the corresponding traffic classifier and traffic behavior, the
IP address of GE 1/0/3 on Router A matches ACL 3000. Therefore, packets are redirected
to GE 1/0/3 instead of being sent to the CPU.
[HUAWEI] display traffic policy user-defined Redirect
User Defined Traffic Policy Information:
Policy: Redirect
Share-mode
Classifier: default-class
Behavior: be
-none-
Classifier: user
Behavior: toCR
Redirecting:
Redirect Ip-NextHop 222.61.1.241 Interface GigabitEthernet1/0/3

[HUAWEI] display traffic classifier user-defined user

User Defined Classifier Information:
Classifier: user
Operator: OR
Rule(s) : if-match acl 3000
[HUAWEI] display acl 3000
Advanced ACL 3000, 1 rule
Acl's step is 5
rule 15 permit ip source 222.61.0.0 0.0.63.255
Because the destination address of Hello packets is a reserved multicast address, Hello
packets are not redirected but are sent to the CPU for further processing. A DD packet is a
unicast packet carrying an interface address, and therefore it is redirected to another
interface and fails to be sent to the CPU.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the undo traffic-policy inbound command to delete the traffic policy.
After deleting the traffic policy, you can run the display ospf peer command to view the OSPF
neighbor relationship. The command output shows that the OSPF neighbor relationship is Full.
The fault is rectified.
NOTE
After the OSPF neighbor relationship becomes Full, you can run the traffic-policy command to re-apply
the traffic policy to the interface. Running this command does not affect the OSPF neighbor relationship.
If the OSPF neighbor relationship becomes Down due to link changes or removal of optical fibers, the
OSPF neighbor relationship cannot become Full again.
----End
Summary
The destination address of a Hello packet is a reserved multicast address, whereas a DD packet
is a unicast packet. Hello packets whose destination addresses are reserved multicast addresses
will not be redirected and therefore can be sent to the CPU; DD packets are redirected to another
interface, which causes the OSPF neighbor relationship to remain in the ExStart state.
3.3.2 Routes Are Abnormal Because the FA Fields in Type 5 LSAs

Are Set Incorrectly
Fault Symptom
On the network shown in Figure 3-5, 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
l 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.
l 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 3-5 Network diagram of the networking where routes on a device are abnormal
GE1/0/0 GE1/0/1 GE1/0/0 GE1/0/1
RouterA RouterB
192.168.1.253 192.168.1.254
RouterC
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. The route to the interface of the ASBR's next hop is reachable.
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.
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 correctly
configured. This allows the router to correctly fill in the FA field in a Type 5 LSA and calculate
routes based on defined rules.
3.3.3 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 3-6, 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 3-6 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
BAS 10.1.1.0
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.
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

0.00% packet loss
<RouterA> display ip routing-table 10.1.3.1
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 2
10.1.3.1/32 O_ASE 150 1 D 10.1.2.45

GigabitEthernet1/0/5

O_ASE 150 1 D 10.1.2.49


0.00% packet loss

<RouterA> display ip routing-table 10.1.2.26
10.1.2.24/30 OSPF 10 101 D 10.1.2.45

OSPF 10 101 D 10.1.2.49 GigabitEthernet1/0/6
3. 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:
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. Therefore, 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.

3.3.4 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 3-7, the OSPF neighbor relationship cannot be established
between Router A and its neighbor, and the neighbor is in the Exchange state.
Figure 3-7 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.

l Parameters of the two devices are incorrectly set.
l 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
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. Therefore, packet loss
may be occurring on the board of the peer device or on the link.

Collect traffic statistics on the peer device. It is found that packet loss occurs on the board on
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. 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.
3.3.5 An OSPF Routing Loop Occurs Because Router IDs of Devices

Conflict
Fault Symptom
In the networking shown in Figure 3-8, 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. PE1 and PE2 are connected to the same UMG. The same
IP address, 10.1.1.33, is set for the interface connecting PE1 to the UMG and the interface
connecting PE2 to the UMG, and the two interfaces are bound to the VPN instance of the UMG.
Normally, the link between the UMG and PE2 is Down. The two interfaces with the IP address
10.1.1.33 on the two PEs cannot both be in the Up state simultaneously.
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 3-8 Network diagram of an OSPF routing loop that occurs because router IDs of the
devices conflict
PE1 PE2
City A City B
CE1 CE2

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 multi-
instance 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.
3.3.6 Services on the Master Plane Are Interrupted Because a Device

on the Slave Plane Performs Master/Slave Switchover on a Bearer
Network
Fault Symptom
On the bearer network shown in Figure 3-9, there are two planes working in master and slave
mode. The traffic model of the master plane is UMGCE1AR1BR1AR1'CE1', which
is the same as the return path.
During the master/slave switchover of AR2 on the slave plane, packet loss (which lasts 1 second)
occurs on the master plane. Similarly, during the master/slave switchover of AR1 on the master
plane, packet loss also occurs on the slave plane.

Figure 3-9 Diagram of that the services on the master plane are interrupted because a device on
the slave plane performs master/slave switchover on a bearer network
CE1 AR1 BR1 AR1' CE1'
UMG UMG'
CE2 AR2 BR2 AR2' CE2'
Fault Analysis
The analysis about the topology and routes of the current network shows that the master and
slave planes are independent of each other. Therefore, it is impossible that the master/slave
switchover of a device on one plane affects the services on the other plane. By viewing the
configurations of the devices on the current network, you can find that the route aggregation
command is run in the OSPF multi-instance on all ARs.
ospf 1 vpn-instance 123
asbr-summary 10.0.0.0 255.0.0.0
The network command is run to configure BGP to advertise routes. The routes to the remote
end are therefore aggregated into a route 10.0.0.0/8. Based on the route aggregation rules on the
ABR, the cost of the aggregated route is the largest among the costs of the routes that are
aggregated (after route aggregation, the ASBR and the ABR send the aggregated route with the
largest cost). For example, there are the following routes to be aggregated:
l 10.1.1.1/24 cost 10
l 10.2.1.1/24 cost 100
l 10.3.1.1/24 cost 1000
The aggregated route is 10.0.0.0/8 with the cost being 1000.
After AR1 on the master plane performs the master/slave switchover, AR2 needs to reconverge
private network routes. If AR2 receives a route 10.x.x.x with the cost smaller than 200, the cost
of the aggregated route 10.0.0.0/8 advertised by AR2 to CE2 become smaller, and the aggregated
route is advertised to CE1 by OSPF. The traffic model on the master plane becomes UMG
CE1CE2AR2BR2AR2'CE2'.
Because the network scale is large, AR2 has not completed route convergence yet, that is, AR2
has no specific route to the destination. As a result, the fault occurs.
Procedure
Step 1 When using the asbr-summary command in OSPF view to configure route aggregation, specify
the cost of the aggregated route to prevent route re-selection when a route with a smaller cost is
received.
ospf 1 vpn-instance 123
asbr-summary 10.0.0.0 255.0.0.0 cost 300

After the preceding operations, no traffic passes through the link between CE1 and CE2, and
traffic on the master plane is always forwarded on the master plane.
----End
Summary
During the planning of a network with dual planes, prevent the two planes from affecting each
other due to the factors such as IS-IS checksum errors, incorrect costs of OSPF routes, and
incorrect costs of IS-IS routes.
3.3.7 User with the Correct User Name and Password Fails to Pass
HWTACACS Authentication
During network configuration adjustment, the new routing protocol does not advertise loopback
addresses. As a result, a user who uses a loopback address as the source IP address cannot
communicate with the TACACS server.
Fault Symptom
On the core network shown in Figure 3-10, Routing protocol, AAA, QoS, and SNMP are
configured on Router A, Router B, Router C, and Router D. The four devices belong to the same
AS and are configured with IBGP and IS-IS. IS-IS advertises the IP addresses of loopback
interfaces and interconnected interfaces. The devices are re-configured based on a new private
AS number, IBGP is replaced by EBGP and IS-IS is replaced by OSPF.
Figure 3-10 Networking diagram of HWTACACS authentication on a core network
Loopback0 Loopback0
RouterA
RouterB
TACACS
server
RouterD
RouterC
Loopback0 Loopback0
After the configurations, an HWTACACS user with the correct user name and password can no
longer pass the HWTACACS authentication.

Fault Analysis
1. Check whether the user name and password of the user are the same as those recorded on
the TACACS server. The user name and password are correct.
2. Run the ping command on Router A to check whether Router A can ping the TACACS
server. The ping succeeds.
3. Run the display current-configuration command on Router A to check whether the
HWTACACS configuration is correct. The following command is found in the
HWTACACS server template:
hwtacacs-server source-ip 192.168.1.227
In this command, 192.168.1.227 is the loopback address of Router A.

As the deleted IS-IS configuration includes loopback addresses and HWTACACS uses the
loopback address of Router A as the source IP address, it is possible that HWTACACS
authentication fails because Router A cannot receive authentication response packets with
the destination address being 192.168.1.227 from the TACACS server.
4. Run the ping -a 192.168.1.227 100.1.1.245 command on Router A (100.1.1.245 is the IP
address of the TACACS server) to check whether the loopback address can ping the
TACACS server address. The ping fails.
5. Run the display ip routing-table command on Router A to check whether routing protocols
have advertised this loopback address. The command output shows that the IP address of
Loopback0 is not advertised.
Therefore, it can be concluded that the loopback address is deleted when the IS-IS
configuration is deleted during network configuration adjustment. Because OSPF does not
advertise this loopback address, Router A cannot receive authentication response packets
from the TACACS server, and as a result, HWTACACS authentication fails.
Procedure
Step 2 Run the ospf process-id command to enter the OSPF view.
Step 3 Run the area area-id command to enter the OSPF area view.
Step 4 Run the network address wildcard-mask command to advertise the loopback address.
After the preceding configurations, the user can successfully log in. The fault is cleared.
----End
Summary
Before changing protocols on network devices, you need to record the original configurations.
After the configuration of new protocols , ensure that the new configurations meet all the service
requirements before the change and whether the new configurations affect other configurations.

3.3.8 OSPF Neighbor Status Cannot Reach the Full State Because
Interface MTUs of Devices on Both Ends of the Link Are Different
Fault Symptom
As shown in Figure 3-11, Router A and Router B are directly connected. Router A is a Huawei
device, and Router B is a non-Huawei device. The OSPF neighbor relationship is established
between Router A and Router B. After the interface MTU of Router A is set to 1520 bytes,
Router A cannot ping Router B. In addition, the OSPF neighbor status of Router A remains in
the Exchange state and cannot reach the Full state.
Figure 3-11 Diagram of the OSPF neighbor status cannot reach the full state because interface
MTUs of devices on both ends of the link are different
RouterA RouterB
Fault Analysis
1. Run the ping -s 1500 host command on Router A. The command output shows that
Router A can successfully ping Router B.
2. Run the display ospf peer command on Router A to check the OSPF neighbor status and
interface MTU. The command output shows that the OSPF neighbor status is Exchange
and the interface MTU is 1506 bytes.
3. Check the OSPF neighbor status and interface MTU of Router B. The display shows that
the interface MTU is 1520 bytes.
Because Router B is a non-Huawei device, its MTU implementation mechanism is different

from that of Router A. In addition, the interface MTU of Router B includes a 14-byte Layer 2
header, whereas the interface MTU of Router A does not include any Layer 2 header. When the
same interface MTU (1520 bytes) is set for Router A and Router B, the actual interface MTU
(1520 bytes) of Router A is greater than the actual interface MTU (1506 bytes) of Router B.
Additionally, because Router A does fragment a packet when sending it to Router B, Router B
cannot identify the received packet. As a result, the OSPF neighbor negotiation between
Router A and Router B fails. Consequently, the OSPF neighbor status of Router A and Router
B cannot reach the Full state.
Procedure

Step 2 Run the interface interface-type interface-number command on Router A to enter the interface
view.
Step 3 Run the mtu 1506 command on Router A to set the interface MTU to 1506 bytes.
Step 4 Run the display ospf peer command on Router A. The command output shows that the OSPF
neighbor status reaches the Full state, indicating that the fault is cleared.
----End
Summary
If the OSPF neighbor status cannot reach the Full state, possible causes are as follows:
l The link fails.

l The OSPF neighbor configurations are incorrect.
In addition, different manufacturers use different methods to calculate interface MTUs.

Therefore, when a Huawei device communicates with a non-Huawei device, confirm the method
of calculating the interface MTU of the peer device and ensure that interface MTUs of the two
devices are the same.
If the ospf mtu-enable command is run on an OSPF interface, check whether interface MTUs
of devices on both ends are the same. If interface MTUs of devices on both ends are different,
change interface MTU of one device to be the same as that of the other device.
l If the interface MTU in the received packet is greater than the locally configured interface
MTU, the device receiving the packet discards the received DD packet, and therefore its
OSPF neighbor status remains in the Exstart state.
l If the interface MTU in the received packet is smaller than the locally configured interface
MTU, the device receiving the packet accepts the received DD packet, and its OSPF
neighbor status reaches the Exchange state.
3.3.9 Why Cannot the OSPF Neighbor Relationship Be Established

Between Two Devices Enabled with the Opaque-LSA Capability?
Fault Symptom
As shown in Figure 3-12, Router A and Router B attempt to set up an OSPF neighbor relationship
and run MPLS TE services. Router A is a non-Huawei device, and is enabled with the Opaque-
LSA capability by default. Router B is a Huawei device. The opaque-capability enable
command is run in the OSPF process of Router B. Router A and Router B fail to set up an OSPF
neighbor relationship. The OSPF neighbor relationship on Router A reaches the Full state,
whereas the neighbor relationship on Router B is always in the Loading state.

Figure 3-12 Diagram of the networking where the OSPF neighbor relationship cannot be set up
between devices enabled with the Opaque-LSA capability
RouterA RouterB
Fault Analysis
1. Run the display ospf peer command on Router B to check the status of the neighbor
relationship. The command output shows that the OSPF neighbor relationship is in the
Loading state (the State field is displayed as Loading), indicating that the LSA requested
from the neighbor exists in the request list.
2. Run the display ospf request-queue command to check whether Router B is always
requesting an Opaque LSA. The command output shows that Router B is always requesting
an Opaque-Area LSA.
3. Run the debugging ospf packet update filter src acl-number command on Router B. The
command output shows that Router A is always sending LSAs carrying only header
information.
Router B is a Huawei device, and cannot process any LSA carrying only header information.
During the establishment of an OSPF neighbor relationship between a Huawei device and a non-
Huawei device, if the DD packets sent by the non-Huawei device carry Opaque LSAs that have
only header information, the Huawei device will request the Opaque LSAs from the non-Huawei
device. Then, the non-Huawei device sends the requested LSAs by using LSUs. The Huawei
device, however, discards the requested LSAs because it cannot process these LSAs, and
continues to request LSAs from the non-Huawei device. As a result, the neighbor relationship
on the Huawei device is always in the Loading state.
Procedure
Step 2 Run the ospf process-id command to enter the view of a specified OSPF process.
Step 3 Run the undo opaque-capability enable command to disable the Opaque-LSA capability. The
fault is then rectified.
----End
Summary
When a Huawei device enabled with the Opaque-LSA capability is connected to a non-Huawei
device, check whether the non-Huawei device is enabled with the Opaque-LSA capability by
default.

3.3.10 Inappropriate OSPF Costs Cause Traffic Interruption During

a Link Switchover
Fault Symptom
Figure 3-13 shows the cost of each link. On the network shown in Figure 3-13, OSPF is running
on each device. The primary link is Router M -> Router A -> Router B -> Router C -> Router
D -> Router E -> Router N. The secondary link is Router M -> Router A -> Router F ->
Router G -> Router H -> Router I -> Router J -> Router E -> Router N. If a fault occurs on the
primary link or a master device, traffic on Router A is immediately switched to the secondary
link. If a fault occurs on the link between Router B and Router A (for example, the shutdown
command is run on Router B), traffic from Router M to Router N is interrupted for 5 seconds.
Figure 3-13 Networking of traffic interruption caused by inappropriate OSPF costs during a
link switchover
RouterA RouterB RouterC RouterD RouterE
1 1 1 1
RouterM RouterN
10 20 30 21 11
1 1 1 1
RouterF RouterG RouterH RouterI RouterJ
Fault Analysis
1. Run the display ip routing-table ip-address command on Router A to check its IP routing
table. In this example, the next hop of the route to Router N is Router F. This indicates that
traffic is switched to Router F after a fault occurs on the link between Router B and
Router A.
2. Run the tracert host command on Router A. In this example, Router A and Router N are
reachable. Traffic is switched to the secondary link Router A -> Router F -> Router G ->
Router H -> Router I -> Router J -> Router E -> Router N. This indicates that the fault is
temporary rather than a continuous packet loss.
3. Run the undo shutdown command and the shutdown command on Router B so that a fault
occurs on the link between Router B and Router A. Then, run the tracert host command
on Router A immediately. In this example, Router A and Router N are not reachable. A
loop has occurred between Router A and Router F. The further analysis shows that the link
Router A -> Router B -> Router C -> Router D -> Router E has the lowest cost before the
fault occurs. Traffic between Router M and Router N is forwarded through the primary
link. The link Router F -> Router A -> Router B -> Router C -> Router D -> Router E has
the lowest cost between Router F and Router E. The next hop of the route from Router F

to Router E is Router A. Therefore, if a fault occurs on the link between Router B and
Router A, Router A switches traffic to its outbound interface connected to Router F.
Router F is a device that has low performance. Before Router F completes route
convergence, it forwards the traffic received from Router A back to Router A. As a result,
a loop occurs between them. After Router F completes route convergence, traffic between
Router M and Router N is forwarded through the secondary link. Therefore, this fault is
caused by inappropriate OSPF costs.
Procedure
Step 1 Run the system-view command on Router A, Router B, Router C, Router D, and Router E to
enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the ospf cost cost command for multiple times to configure the costs of Router A ->
Router B -> Router C -> Router D -> Router E to be 2, 2, 2, and 2 respectively. This ensures
that traffic between Router M and Router N is forwarded through the primary link if no fault
occurs and is forwarded through the secondary link if a fault occurs.
----End
Summary
If users want to determine the primary and secondary links by configuring the costs of these
links, note to consider the route next hops during and after the route convergence.
3.3.11 Downstream Traffic Cannot be Load Balanced Due to the

Inappropriate Routing Protocol Route Preference
Fault Symptom
On the network shown in Figure 3-14, IS-IS is running on Router A, Router B, and Router C.
These devices belong to Area 1. The configuration is as follows:
l Two default static routes are configured on Router D with next hops Router A and
Router B respectively. Upstream traffic is forwarded through and load balanced along the
link Router D -> Router A -> Router C and the link Router D -> Router B -> Router C.
l Configure two static routes with next hops being Router D on Router A and RouterB
respectively. Downstream traffic is forwarded through and load balanced between the link
Router C -> Router A -> Router D and the link Router C -> Router B -> Router D.
l Import the static routes configured on Router A and Router B to IS-IS.
After the configuration is complete, upstream traffic is load balanced, but downstream traffic is
forwarded only through the link Router C -> Router B -> Router D.

Figure 3-14 IS-IS networking on which downstream traffic cannot be load balanced
RouterC
Area1
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
RouterA RouterB
GE2/0/0
GE2/0/0
20.1.1.1/24
30.1.1.1/24/30
RouterD
Segment: 40.1.1.0/24
Fault Analysis
1. Upstream traffic is load balanced and downstream traffic is forwarded through one link, so
the problem is not caused by a link failure.
2. Run the display ip routing-table command on Router A to check its IP routing table. The
command output shows that the route destined for 40.1.1.0/24 is a static route. Run the
display ip routing-table command on Router B to check its IP routing table. The command
output shows that the route destined for 40.1.1.0/24 is an imported IS-IS route. The static
route has a lower preference than the IS-IS route, so this problem is caused by the
inappropriate IS-IS route preference.
<RouterA> display ip routing-table
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 9 Routes : 9
1.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0

2.2.2.2/32 ISIS 15 10 D 10.1.1.2 GigabitEthernet1/0/0
40.1.1.0/24 Static 60 0 RD 20.1.1.2 GigabitEthernet2/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/0
<RouterB> display ip routing-table

------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 7 Routes : 7

Procedure
Step 1 Run the system-view command on Router A and Router B to enter the system view.
Step 2 Run the ip route-static default-preference preference command to configure the default
preference of static routes.
NOTE
The default preference value of static routes must be lower than the IS-IS preference value.
----End
Summary
l Static routes are configured on both devices. After these routes are imported to IS-IS, they
are sent to the neighbors. Because static routes have a lower preference than the IS-IS routes,
the static routes configured on both devices do not take effect and are both withdrawn. After
that, the imported IS-IS routes are automatically removed. Then, the static routes take effect
again. This process is repeated and therefore route flapping occurs. In the end, one static
route takes effect on one device and one IS-IS route takes effect on the other device due to
the intervals when Update and Withdraw messages are sent.
l The default preference of static routes is 60 and that of IS-IS routes is 15 on Huawei devices.
The configurations on non-Huawei devices are different than Huawei devices. Therefore,
if you use Huawei devices to communicate with non-Huawei devices, pay attention to
preference differences when you run a routing protocol on these devices.

Troubleshooting - IP Forwarding and Routing 4 IS-IS Troubleshooting
4 IS-IS Troubleshooting
About This Chapter
4.1 The IS-IS Neighbor Relationship Cannot Be Established
4.2 A Device Fails to Learn Specified IS-IS Routes from Its Neighbor
4.3 The IS-IS Neighbor Relationship Flaps
4.4 IS-IS Routes Flap

4.1 The IS-IS Neighbor Relationship Cannot Be Established
4.1.1 Common Causes

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


Figure 4-1 Flowchart for troubleshooting the fault that the IS-IS neighbor relationship cannot
be established
The IS-IS neighbor
relationship cannot
be normally
established.
Is the No Check the MTU and Yes

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

normally sent and packets are lost. rectified?
received?
Yes No
Is local
No Yes
IS-IS parameters are Modify the IS-IS Is fault
matched with the parameters. rectified?
neighbor's?
No
Yes
Seek technical
support.
End
Context
NOTE
Procedure
Step 1 Check the status of IS-IS interfaces.
Run the display isis interface command to check the state of interfaces enabled with IS-IS (the
value of the IPv4.State or IPv6.State item).
l If the state is Mtu:Up/Lnk:Dn/IP:Dn, go to Step 2.
l If the state is Mtu:Dn/Lnk:Up/IP:Up, run the display current-configuration interface
interface-type [ interface-number ] command to check the MTUs on the interfaces. Run
the display current-configuration configuration isis command to check the lengths of
LSPs in an IS-IS process.

NOTE
If the lengths of LSPs cannot be viewed by using the display current-configuration

configuration isis command, the default LSP lengths are used. The default LSP lengths can be viewed
by using the display default-parameter isis command. The value of the LSP-Originate-Length
field is the maximum length of a originated LSP, and the value of the LSP-Receive-Length field is
the maximum length of a received LSP.
If the MTU cannot be viewed by using the display current-configuration interface interface-
type [ interface-number ] command, the default MTU lengths are used. The default MTU length is
4470 bytes on the POS and 1500 bytes on the other interfaces.
On a P2P interface, the LSP length should not be greater than the MTU on the P2P interface.
On a broadcast interface, the value obtained by the MTU on the interface subtracted by the
LSP length should be equal to or greater than 3. If the condition is not met, run the lsp-
length command in the IS-IS view to change the LSP length, or run the mtu command in
the interface view to change the MTU.If there is different between the two poles
interfaces,modify and make them equal.
If the fault is still not rectified, go to Step 4.
l If the state is Down, run the display current-configuration configuration isis command
to check the configuration of the IS-IS process. Check whether the NET is configured in
the IS-IS process. If not, configure the network-entity command in the IS-IS process.
l If the state is Up, go to Step 4.
Step 2 Check that the interface status is Up.
Run the display ip interface [ interface-type [ interface-number ] ] command to check the status
of specified interfaces.
l If the interface link status (Line protocol current state field in the output information ) is
not Up, troubleshoot the interface fault. See the section "Physical Connection and
Interfaces" or "L2 Network".
l If the interface status is Up, go to Step 3.
Step 3 Check that the IP addresses of the two interfaces at both ends of the link are on the same network
segment.
l If the IP addresses of the two interfaces are on different network segments, change the IP
addresses of the two interfaces to ensure that the two IP addresses are on the same network
segment. If the fault is still not rectified, go to Step 4.
l If the IP addresses of the two interfaces are on the same network segment, go to Step 4.
Step 4 Check that IS-IS can normally receive and send Hello packets.
Run the display isis statistics packet [ interface interface-type interface-number ] command
to check whether IS-IS can normally receive and send Hello packets.
NOTE
The default interval at which IS-IS sends Hello packets is 10s. Therefore, run this command every 10s to
check whether the packet statistics increase (L1 IIH or L2 IIH).
On a broadcast interface, Hello packets have IS-IS levels, and therefore you can view the statistics about
Hello packets based on the levels of established neighbor relationships. On a P2P interface, Hello packets
have no IS-IS levels and are recorded as L2 IIH packets.

l If the number of received Hello packets does not increase for a certain period, check whether
the IS-IS packets are lost.
For Broadcast interface, run the debugging ethernet packet isis interface-type
interface-number command. The following information indicates the interface can
normally receive and send IS-IS Hello packets.
*0.75124950 HUAWEI ETH/7/eth_rcv:Slot=3;Receive an Eth Packet, interface :
Ethernet1/0/0, eth format: 3, length: 60, protoctype: 8000 isis,
src_eth_addr: 00e0-fc37-08c1, dst_eth_addr: 0180-c200-0015
*0.75124950 HUAWEI ETH/7/eth_send:Slot=3;Send an Eth Packet, interface :
Ethernet1/0/0, eth format: 3, length: 112, protoctype: 8000 isis,
src_eth_addr: 00e0-fc26-f9d9, dst_eth_addr : 0180-c200-0015
For P2P interface, run the debugging ppp osi-npdu packet interface-type interface-
number command. The following information indicates the interface can normally
receive and send IS-IS Hello packets.
*0.85102199 HUAWEI PPP7/debug2:Slot=2;
PPP Packet:
Pos2/0/0 Output OSI-NPDU(0023) Pkt, Len 1004
*0.85102199 HUAWEI PPP7/debug2:Slot=2;
PPP Packet:
Pos2/0/0 Input OSI-NPDU(0023) Pkt, Len 1501
NOTE
If the DIS field shown in the output of the display isis interface interface-type interface-
numbercommand is "--", it indicates the interface type is P2P. Otherwise, the interface type is
Broadcast.
If the device cannot normally receive and send Hello packets, go to Step 9.
l If the device can normally receive Hello packets, go to Step 5.
If the interfaces at both ends of the link are trunk interfaces, check whether the numbers
of the member interfaces in the Up state in the trunk interfaces are the same. If numbers
of the member interfaces in the Up state in the trunk interfaces are different, add the
required physical interfaces to the Trunk interface correctly. Otherwise, go to Step 2
If the interfaces at both ends of the link are not trunk interfaces, go to Step 2.
Step 5 Check that the devices at both ends of the link are configured with different system IDs.
Run the display current-configuration configuration isis command to check whether the
system IDs of the two devices are the same.
l If the system IDs of the two devices are the same, set different system IDs for the two
devices.
l If the system IDs of the two devices are different, go to Step 6.
Step 6 Check that the IS-IS levels of the two devices at both ends of the link match.
Run the display current-configuration configuration isis | include is-level command to check
the levels of the IS-IS processes on the two devices. Then, run the display current-
configuration interface interface-type interface-number | include isis circuit-level command
to check whether the IS-IS levels of the interfaces at both ends of the link match. The IS-IS
neighbor relationship can be established only when the IS-IS levels of the two interfaces match.

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

authentication-mode command to check whether the IS-IS authentication configurations of the
two interfaces at both ends of the link are the same.
l If the authentication types on the two interfaces are different, run the isis authentication-
mode command in the view of each of the two interfaces to set the same authentication
type for the two interfaces.
l If the authentication passwords on the two interfaces are different, run the isis
authentication-mode command in the view of each of the two interfaces to set the same
authentication password for the two interfaces.

l If the authentication configurations of the two devices are the same, go to Step 9.
----End
Relevant Alarms
ISIS_1.3.6.1.3.37.2.0.12 isisAreaMismatch
ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure
ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure
Relevant Logs
None.
4.2 A Device Fails to Learn Specified IS-IS Routes from Its

Neighbor
4.2.1 Common Causes

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

After IS-IS is configured on the network, it is found that the device cannot learn specified IS-IS
routes from its neighbor.
The troubleshooting roadmap is as follows:

l Check whether another protocol also learns specified routes.

l Check whether IS-IS calculates routes.

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

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

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

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

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

Run the display isis peer command on every device on the path to check whether the IS-IS
neighbor relationships are normally established.
l If the State field is not Up, troubleshoot the fault The IS-IS Neighbor Relationship
Cannot Be Established.
l If the State field is Up, go to Step 6.

----End
Relevant Alarms
ISIS_1.3.6.1.3.37.2.0.8 isisSequenceNumberSkip
ISIS_1.3.6.1.3.37.2.0.9 isisAuthenticationTypeFailure
ISIS_1.3.6.1.3.37.2.0.10 isisAuthenticationFailure
Relevant Logs
None.
4.3 The IS-IS Neighbor Relationship Flaps
4.3.1 Common Causes

l Packet loss occurs because the link is unstable or devices work abnormally.
l The member interfaces of the trunk interface are incorrectly connected.

After IS-IS is configured on the network, it is found that the IS-IS neighbor relationship flaps.

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

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

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

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

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

4.4 IS-IS Routes Flap
4.4.1 Common Causes

l The IS-IS neighbor relationship flaps.

l The MPLS LSP flaps.
l The two devices import the same external routes to IS-IS, and the preferences of the
imported external routes are lower than those of IS-IS routes.
l The two devices are configured with the same system ID.

After IS-IS is configured on the network, it is found that IS-IS routes flap.
Figure 4-4 Troubleshooting flowchart when IS-IS routes flap
IS-IS routes flap
Check the routing table

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

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

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

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

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

configure a route filtering policy in the IS-IS view to control the routes to be added to the
IP routing table.
l In other cases, go to Step 3.
----End
Relevant Alarms
None.
Relevant Logs
None.
4.5.1 An Upper-layer Device Cannot Learn IS-IS Routes Due to

Differences in the Types of Routes Imported by IS-IS on a Huawei
Device and a Non-Huawei Device
Fault Symptom
On the network shown in Figure 4-5, Router B and Router C are located at the core layer and
are connected to two SR devices, that is, Router A, and Router D. Router D is a non-Huawei
device. To implement load balancing, Router A and Router D are configured to the same
network, and direct routes and static routes are imported to IS-IS in related IS-IS processes. After
the configuration, you can find that Router B and Router C can learn routes from only Router
D.

Figure 4-5 Diagram of the network where devices cannot learn IS-IS routes
RouterA
Router B Route rC
Route rD
Fault Analysis
By default, the type of static routes imported by IS-IS on Router D is internal and the cost of
the routes equals to the original cost of the imported route, whereas the type of static routes
imported by IS-IS on Router A is external and the cost of the routes equals to the sum of original
cost of the imported route and 64. Router B, and Router C selects routes only from Router D
rather than Router A because the costs are different.
NOTE
The trouble occurs only when the cost-style is narrow.
Procedure
Step 2 Run the isis process-id command to enter the IS-IS view.
Step 3 Run the import-route direct cost-type internal command to configure IS-IS to import direct
routes and set cost-type to internal.
Step 4 Run the import-route static cost-type internal command to configure IS-IS to import static
routes and set cost-type to internal.
NOTE
Modify the cost-type from external to internal, the cost of the imported routes equals to the original cost
of the imported route, rather than the sum of original cost of the imported route and 64.
After the preceding operations, run the display isis route command on Router B and Router C
to view routing information. You can find that there are two IS-IS routes to the same network
segment and that load balancing is performed by Router A and Router D.
----End

Summary
In the networking with devices of different manufacturers, note the implementation differences
between the devices.

Troubleshooting - IP Forwarding and Routing 5 BGP Troubleshooting
5 BGP Troubleshooting
About This Chapter
5.1 The BGP Peer Relationship Fails to Be Established
5.2 BGP Public Network Traffic Is Interrupted
5.3 BGP Private Network Traffic Is Interrupted

5.1 The BGP Peer Relationship Fails to Be Established
5.1.1 Common Causes

The BGP peer relationship fails to be established if the BGP peer relationship cannot enter the
Established state.
l BGP packets fail to be forwarded.

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

The BGP peer relationship fails to be established after the BGP protocol is configured.

Figure 5-1 Troubleshooting flowchart for the failure to establish the BGP peer relationship
The BGP peer relationship fails to

be established
Check the routes

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

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

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

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

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

PrefRcv
8.9.0.8 4 100 1601 1443 0 23:21:56 Established
10000
9.10.0.10 4 200 1565 1799 0 23:15:30 Established 9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, run the display bgp vpnv4 all peer command.

l If the peer router ID conflicts with the local router ID, run the router id command in the
BGP view to change the two router IDs to different values. Generally, a loopback interface
address is used as the local router ID.
l If the peer router ID does not conflict with the local router ID, go to Step 4.
Step 4 Check that the peer AS number is configured correctly.
Run the display bgp peer command on each device to check whether the displayed peer AS
number is the same as the remote AS number.
<HUAWEI> display bgp peer
Total number of peers : 12 Peers in established state : 4
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

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

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

interface-number the BGP peer relationship, run the peer connect-
interface command to specify the associated
loopback interface as the source interface that
sends BGP packets.
peer ebgp-max-hop hop-count When two directly connected devices use loopback
interfaces to establish the EBGP peer relationship
or two indirectly connected devices establish the
EBGP peer relationship, run the peer ebgp-max-
hop command and specify the maximum number
of hops between the two devices.
l When two directly connected devices use
loopback interfaces to establish the EBGP peer
relationship, the hop count can be any number
greater than 1.
l When two indirectly connected devices
establish the EBGP peer relationship, specify
the number of hops based on the actual
situation.

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.
Step 6 Contact Huawei technical support personnel and provide them with the following information.
----End
Relevant Alarms
BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Relevant Logs
BGP/3/STATE_CHG_UPDOWN
5.2 BGP Public Network Traffic Is Interrupted
5.2.1 Common Causes

This troubleshooting case describes how to clear the fault that traffic to be transmitted through
BGP public network routes is interrupted when the BGP peer relationship is normal.
l Routes are inactive because the next hops are unreachable.

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

BGP public network traffic is interrupted after the BGP protocol is configured.

Figure 5-2 Troubleshooting flowchart for interruption of BGP public network traffic
The BGP public network

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

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

Reduce the number of
number of routes exceed Is faulty rectified?
routes
the upper limit?
No No

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


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

Step 3 Check that the number of routes is lower than the upper limit.
Run the display current-configuration configuration bgp | include peer destination-

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

5.3 BGP Private Network Traffic Is Interrupted
5.3.1 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.

l Routes fail to be advertised or received because routing policies are incorrectly configured.
l Private network routes fail to be advertised because the number of labels exceeds the upper
limit.
l Routes are inactive because they fail to be iterated to a tunnel.
l Routes fail to be added to the VPN routing table because the configured import route-target
(RT) and export RT do not match.
l The received routes are dropped because there is an upper limit on the number of routes on
the device.

BGP private network traffic is interrupted after the BGP protocol is configured.

Figure 5-3 Troubleshooting flowchart for interruption of BGP private network traffic
The BGP private network

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

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

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

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

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

End

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
Relay IP Out-Interface: Pos1/0/0
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, active, pre 255
Not advertised to any peer yet
l If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If 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).
l If the target route is active and selected but there is no information indicating that this route
is sent to the remote PE, go to Step 2 to check the outbound policy applied to the local PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the
remote PE to check whether it has received the target route.
l If the remote PE has received the target route, perform Step 1 again to check whether the
next hop of the route is reachable and whether this route is selected.
l If the remote PE has not received the target route, go to Step 2 to check the inbound policy
of the remote PE.
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.
<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
l 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 NetEngine80E/40E Configuration
Guide - IP Routing.
l 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 IP Out-Interface: Pos1/0/0
Relay Tunnel Out-Interface: Pos1/0/0

Relay token: 0x1002

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

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

configured in the tunnel policy view, you also need to configure the mpls te reserved-for-binding
command in the tunnel interface view.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or TE
Tunnel Is Down to locate the fault and ensure that the tunnel goes Up.
l If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether routes fail to be added to the VPN routing table because the configured import
RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the local PE
and remote PE to check whether routes fail to be added to the VPN routing table of the remote
PE after being sent to the remote PE because the export RT of the local VPN instance does not
match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.
<HUAWEI> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
route-distinguisher 1:1
apply-label per-instance
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
ip vpn-instance vpnb
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 routing-
table ipv4-address [ mask | mask-length ] command to check whether the target route is assigned
a VPN label.
If there is no Label information field in the command output, the number of labels may have
reached the upper limit. As a result, the target route is not assigned a label and is not advertised
to the peer.
<HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1

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 group-
name command to check 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 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

5.4.1 Traffic Traverses the Egress Device of an AS Because BGP

Delivers Default Routes with Different MEDs
Fault Symptom
In Figure 5-4, Router A and Router B reside on the backbone network. 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.
Figure 5-4 Outgoing traffic traversing the egress device of an AS
AS100
RouterA RouterB
0.0.0.0 is delivered 0.0.0.0 is delivered

(MED 88) (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-plain | as-number-dot } 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
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.
5.4.2 MAN Users Fail to Access the Internet Because of BGP Route
Flapping
Fault Symptom
Figure 5-5 shows how a specific carrier's MAN is connected to its backbone network.
Figure 5-5 Networking of the MAN before service cutover
RouterE RouterF
RouterA RouterD
Backbone
network
MAN
RouterC RouterB
A Site B Site
The carrier optimizes the MAN and the backbone network to better facilitate the growing service
requirements. Networking of the MAN after service cutover is shown in Figure 5-6.

l Router A in Site A changes from the backbone network's egress router to the MAN's egress
router, connects to Router E, and establishes the EBGP peer relationship with Router E.
l Router D in Site B is directly connected to Router F and establishes the EBGP peer
relationship with Router G.
l The IBGP peer relationship is established between Router A and Router D.
l Router C and Router B are removed from the networking.
Figure 5-6 Networking of the MAN after service cutover
RouterE RouterF
Backbone
network
EBGP EBGP
MAN
IBGP
RouterA RouterD
A Site B Site
Service cutover is successfully performed in Site A, and then service cutover begins to be
performed in Site B. During service cutover in Site B, the version of Router D needs to be
upgraded first. After Router D is restarted during version upgrade, a large number of users in
internet caf and PPPoE users fail to access the Internet.
Fault Analysis
1. Users in the MAN cannot ping the carrier's DNS and then run the tracert command to
tracert the carrier's DNS. The result shows that traffic is interrupted after reaching Router
A.
2. Run the display bgp peer on Router A to check the BGP peer relationship. The command
output shows that the BGP peer relationship is normal. Then, ping the carrier's DNS from
Router A. The result shows that the ping succeeds.
3. Run the display ip routing-table statistics command on Router A repeatedly to check the
number of updated BGP routes and then check whether routing loops exist. The command
output shows that no routing loops exist.
4. Run the display ip routing-table command on Router E of the backbone network to check
routes. The command output shows that there are no BGP routes to the MAN.
5. Run the display bgp peer command on Router E to check the BGP peer relationship. The
command output shows that the EBGP peer relationship between Router E and Router A
is not in the Established state.
6. Check logs on Router E. The log information shows that EBGP routes to Router A are
suppressed because BGP routes are updated frequently, which causes MAN traffic unable
to be sent outside the MAN.

BGP routes are suppressed because the BGP routes are updated frequently. Possible causes
of frequent route updates are as follows:
a. Router A advertises BGP routes to Router E by using the network command. Then,
these routes are updated one by one and this update process is recorded.
b. Router D is restarted during version upgrade, causing the BGP routes to be updated
again. Consequently, the number of BGP route updates reaches the route suppression
threshold set on Router E.
Procedure
Step 1 Run the system-view command on Router E to enter the system view.
Step 2 Run the bgp as-number command on Router E to enter the BGP view.
Step 3 Run the undo dampening command on Router E to cancel BGP route suppression.
Step 4 Run the display bgp peer command on Router E. The command output shows that the EBGP
peer relationship between Router E and Router A is in the Established state. Then, the BGP
routes are reconverged, indicating that the fault is cleared.
Step 5 Run the dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-name ]
* command on Router E to restore the configuration of BGP route suppression.
----End
Summary
Route instability is reflected by route flapping. That is, a route in a routing table disappears and
reappears frequently. Generally, BGP is applicable to complex networks where routes change
frequently. Frequent route flapping, however, consumes lots of bandwidths and CPU resources
and even seriously affects the normal operation of networks. BGP route suppression helps to
avoid the impact of frequent route flapping.
During network adjustment, if there are a large number of updated BGP routes, canceling BGP
route suppression is recommended. This operation helps to prevent services from being affected
by route suppression that is caused by frequent route flapping. After network adjustment, BGP
route suppression needs to be restored.
There are three methods of implementing BGP route suppression: route summarization, route
dampening, and setting the minimum interval for updating routes.
5.4.3 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 5-7, a PE is connected to VPN 1 and is connected to GSR1 in the upstream
direction. VPN 1 routes of the PE need to be advertised to the backbone network. The PE controls
which routes to be advertised to GSR1 using routing policies. According to the configured
routing policies, GSR1 needs to learn only the VPN 1 summary route advertised by the PE
instead of specific routes. After the routing policies are configured, GSR1 learns both the VPN
1 summary route and specific routes.

Figure 5-7 Routing policies delivered by a PE failing to take effect
PE GSR1
VPN1
Backbone
VPN
RouterA GSR2
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 GSR1 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 peer-
address { 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 GSR1 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-
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, GSR1 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 peer-
address 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.
5.4.4 A PE Fails to Establish the Public Network LSP Because the

Path of IGP Routes Is Incorrect
Fault Symptom
As shown in Figure 5-8, 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.
Figure 5-8 Failure to establish a public network LSP on a PE
OSPF Area
P P
(RR1) (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
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.

5.4.5 Next Hop of the Incoming Traffic Changes After a Master/

Slave Switchover of the Attached Non-Huawei Devices
Fault Symptom
As shown in Figure 5-9, 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 load-
balancing 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.
Figure 5-9 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 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.
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.

5.4.6 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 POS interfaces and the other link is established through GE
interfaces. Devices on both ends of a link establish the BGP peer relationship through loopback
interfaces. After the POS 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 5-10 Route iteration causing the BGP peer relationship to go Down
RouterA POS5/0/0 POS5/0/0 RouterB

192.168.0.2/30 192.168.0.1/30
GE1/0/0 GE1/0/0
192.168.1.2/30 192.168.1.1/30
Loopback0 Loopback0
20.0.0.1 10.0.0.1
Fault Analysis
1. After POS 5/0/0 on Router A goes Down, you can run the display ip routing-table ip-
address command on Router A to check equal-cost routes to the public network. The
command output shows that there are two equal-cost routes with next-hop addresses both
being 10.0.0.1 and outbound interfaces being GE 1/0/0 and Null0 respectively. Before POS
5/0/0 on Router A goes Down, you can find that the outbound interfaces of two equal-cost
routes with next-hop addresses both being 10.0.0.1 are GE 1/0/0 and POS 5/0/0
respectively.
Run the display bgp peer command on Router A to check the BGP peer relationship, and
you can find that 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 POS 5/0/0 goes Down, only one of the two equal-cost routes exists,
that is, the route with the outbound interface being GE 1/0/0.
3. Check configurations of Router A and analyze why the outbound interface is iterated to
Null0. Configurations show 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 POS 5/0/0 on Router A goes Down, the preceding static route configurations cause
Router A to iterate routes. Then, check whether there is a route to 192.168.0.1 in the routing
table. By checking the configuration file, you can find the following static route
configurations:

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 POS 5/0/0 goes Down, two upstream routes of Router A are as follows:
Destination/Mask Proto Pre Cost NextHop Interface
10.0.0.1/32 BGP 100 0 10.0.0.1 GigabitEthernet1/0/0
BGP 100 0 10.0.0.1 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 keeps 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 you run the ping command without specifying the
source address, the outbound interface calculated by the Hash algorithm is GE 1/0/0, in
which case the ping succeeds. If you run the ping command with loopback interface address
20.0.0.1 being the source address on Router A, the outbound interface calculated by the
Hash algorithm is POS 5/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. POS 5/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, change static route configurations to prevent incorrect router iteration on
Router A.
Procedure
After POS 5/0/0 on Router A goes Down, the static route with the outbound interface being POS
5/0/0 becomes unreachable and therefore is deleted from the routing table. Then, all packets
destined for Router B are sent through GE 1/0/0 only.
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 original static route configurations.
Step 3 Run the ip route-static 10.0.0.1 255.255.255.255 gigabitethernet 1/0/0 192.168.1.1 and ip
route-static 10.0.0.1 255.255.255.255 pos 5/0/0 192.168.0.1 commands to configure the static
routes with next hops and outbound interfaces.
Step 4 Run the display bgp peer command, and you can find that the BGP peer with the address 10.0.0.1
is in the Established state. This indicates that the BGP peer becomes normal. The fault is cleared.
----End
Summary
Route iteration is enabled by default. Ensure that route iteration will not cause exceptions on a
network.
5.4.7 Static Routes Do Not Take Effect Because of the Relay Depth

Fault Symptom
As shown in Figure 5-11, Router A and Router B are connected through two POS links and
establish the EBGP peer relationship. The following two static routes are configured on
Router A:
ip route-static 2.2.2.2 255.255.255.255 pos1/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 POS 1/0/0.
Figure 5-11 Static routes failing to take effect

Loppback0 Loopback0
1.1.1.1/32 2.2.2.2/32
POS1/0/0 POS1/0/0
10.1.1.1/24 10.1.1.2/24
POS2/0/0 POS2/0/0
RouterA RouterB
10.1.2.1/24 10.1.2.2/24
Fault Analysis
Because the static route configured through the ip route-static 2.2.2.2 255.255.255.255
pos1/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 static route
configured through the ip route-static 2.2.2.2 255.255.255.255 10.1.2.2 command, route relay
needs to be performed one time 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 through the ip
route-static 2.2.2.2 255.255.255.255 10.1.2.2 command become POS 1/0/0.
Procedure
Step 2 Run the undo ip route-static 2.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 pos2/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, you can find two outbound interfaces POS 1/0/0 and
POS 2/0/0 when checking the routing table of Router A.
----End

Summary
When configuring static routes, specify outbound interfaces for them. In this way, route relay is
avoided.
5.4.8 The Outgoing Traffic Is Not Balanced Because BGP Load

Balancing Is Not Enabled
Fault Symptom
As shown in Figure 5-12, Router A, Router B, Router C, and Router D are four egress devices
on the MAN; Router E, Router F, Router G, and Router H are four devices on the provincial
backbone network. Before service cutover, the four egress devices on the MAN are connected
to the four devices on the provincial backbone network by using EBGP as shown in Figure
5-12.
The networking is adjusted to meet service requirements. After service cutover, the four egress
devices on the MAN are connected to the four devices on the provincial backbone network
through EBGP as shown in Figure 5-13. Traffic fails to be balanced between the two outbound
interfaces of each egress device on the MAN, and most traffic is transmitted over one link.
Figure 5-12 Networking before service cutover
RouterG RouterH
RouterF
RouterE
RouterC RouterD
RouterA RouterB
MAN A MAN B

Figure 5-13 Networking after service cutover
RouterG RouterH
RouterF
RouterE
RouterC RouterD
RouterA RouterB
MAN A MAN B
Fault Analysis
Two equal-cost routes are generated on each egress device on the MAN. Because BGP load
balancing is not enabled, most traffic is transmitted over one link. To solve this problem, you
need to enable BGP load balancing on the four egress devices on the MAN.
Procedure
Step 2 Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.
Step 3 Run the maximum load-balancing number command to set the maximum number of equal-
cost routes to 2 or a larger value.
After the preceding operations, perform the same operations on Router B, Router C, and
Router D.
----End
Summary
With the rapid development of networks, MANs and backbone networks as shown in Figure
5-12 are widely deployed. When devices on two MANs access each other, equal-cost routes are
generated. If BGP load balancing is not enabled on egress devices on the MAN, the route
advertised by the device with the smallest router ID is preferred according to BGP route selection
rules. Consequently, the fault described in this case occurs.
It is recommended to enable load balancing on egress devices on the MAN and set the maximum
number of equal-cost routes to the maximum value to facilitate capacity expansion. If there are

both Huawei devices and non-Huawei devices on a network, take the maximum number of equal-
cost routes supported on non-Huawei devices into consideration.
5.4.9 Summary Routes Advertised by EBGP Flap Frequently

Because Routing Protocols Are Configured with Improper
Preferences
Fault Symptom
As shown in Figure 5-14, Router C and Router D are two egress devices on a MAN and are
connected to Router A and Router B on the backbone network through EBGP. Route suppression
is configured on devices on the backbone network to suppress EBGP routes from egress devices
on the MAN. On the MAN, Router C and Router D are connected to their attached devices
through IS-IS and IBGP peer relationships are established between them. Some traffic traverses
egress devices on the MAN. Therefore, to prevent link faults from causing routing loops,
Router C and Router D establish the IBGP peer relationship by using interface addresses and
advertise MAN routes to devices on the backbone network through static blackhole routes
imported by 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 MAN services are
interrupted.

Figure 5-14 Summary routes advertised by EBGP peer flapping frequently
Backbone
network
RouterA RouterB
RouterC RouterD
RouterE RouterF RouterG RouterH
MAN
Fault Analysis
Possible causes of route flapping are as follows:
l Associated routing policies, including local and remote routing policies, are changed
manually.
l Routes (mainly refer to the advertised summary routes) are added and then deleted for two
consecutive times.
l 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 by
the network command.
By checking logs on devices, you can find that no associated routing policies are changed
manually and no routes are added and then deleted.
Egress devices on the MAN advertise routes through blackhole routes imported by the
network command. Therefore, route addition or deletion is not involved. By checking summary
routes, you can find 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,

IBGP routes are advertised as summary routes first. As a result, when the IBGP peer relationship
between Router C and Router D alternates between Up and Down states, the advertised summary
routes flap, therefore causing MAN services to be interrupted.
To solve this problem, you need to 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-plain | as-number-dot } 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 the preceding operations, perform the same operations on Router D to change the
preference of the BGP protocol. In this manner, MAN service transmission recovers.
----End
Summary
Theoretically, MAN routes, which are advertised through blackhole routes imported by the
network command, do not flap. In this case, however, devices on the MAN do not advertise
routes as required because routing protocols are configured with improper preferences.
5.4.10 Traffic Is Not Load Balanced Between Two Links Because

Load Balancing Is Not Configured on the Peer End
Fault Symptom
AS1, AS2, and AS3 belong to three different carriers. AS1 is connected to Router B through
two links, and traffic is load balanced on the two links with the load balancing weight being 2:1.
After the two links are cut over to Router A, among traffic from AS1 to AS3, the volume of
traffic received by POS 1/0/2 reaches 120 Mbit/s whereas the volume of traffic received by POS
1/0/1 reaches only 1 to 3 Mbit/s. This indicates that traffic from AS1 to AS3 is not load balanced
among the two links between AS1 to Router A.

Figure 5-15 Typical Network Diagram for Load Balancing
AS1
AS2
POS1/0/3
1.1.1.1
1.1.1.2
POS1/0/2 POS1/0/1 Router B
Router A
AS3
10.111.128.0 10.111.144.0
255.255.240.0 255.255.240.0
Link before cutover
Link after cutover
Fault Analysis
It is inferred that devices in AS1 do not load balance traffic among the routes learned by AS3
from AS2. Devices in AS1 forward traffic only along the optimal path, therefore causing this
fault. You can change the path to be selected by the peer end by modifying the Multi-Exit-
Discriminator (MED) of Router A.
Procedure
Step 2 Run the ip ip-prefix med-prefix index 10 permit 10.111.128.0 20 command to configure an
IP prefix list named med-prefix to allow only the routes with the prefix being 10.111.128.0/20
to pass.
Step 3 Run the route-policy med-500 permit node 10 command to set a route-policy named
med-500 with its node number being 10 in permit mode.
Step 4 Run the if-match ip-prefix med-prefix command to set a matching rule based on the IP prefix
list named med-prefix.
Step 5 Run the apply cost 500 command to set the cost of the routes with the prefix being
10.111.128.0/20 to 500.
Step 6 Run the quit command to exit from the route-policy view.

Step 7 Run the route-policy med-500 permit node 15 command to set a route-policy named
med-500 with its node number being 15 in permit mode.
Step 8 Run the apply cost 0 command to set the cost of the routes destined for other network segments
to 0.
Step 9 Run the quit command to exit from the route-policy view.
Step 10 Run the bgp 3 command to enter the BGP view.
Step 11 Run the ipv4-family unicast command to enter the IPv4 unicast address family view.
Step 12 Run the peer 1.1.1.1 route-policy med-500 export command to apply a route-policy named
med-500 to the routes to be advertised to the peer.
Step 13 Run the display interface pos 1/0/1 command. The command output shows that the volume of
incoming traffic of POS 1/0/1 increases greatly. This indicates that the configured route-policy
has taken effect. To split more traffic to POS 1/0/1, add network segments in the configured IP
prefix list.
----End
Summary
The MED attribute is transmitted between two neighboring ASs only. That is, devices in an AS
do not advertise the received MED attribute to any devices in any other ASs. The MED is similar
to the metric used by an IGP and is used to determine the optimal route for the traffic that enters
an AS. When a BGP Router obtains multiple routes with the same destination address but
different next hops through EBGP peers, the route with the smallest MED is selected as the
optimal route if the other conditions of the routes are the same.
5.4.11 A Router Does Not Receive the Route Advertised by Its IBGP
Peer Because the AS_PATH Attribute of the Route Carries the AS
Number of the Peer
Fault Symptom
Multiple ASs exist in a region. To access each other, these ASs must exchange their local routes.
As multiple routers exist in the ASs, there are a large number of routes that change frequently.
How to transmit a great deal of routing information efficiently between ASs without consuming
lots of bandwidth resources has become a problem. BGP can be used to solve this problem. On
the network shown in Figure 5-16, Router A is in AS 65008, and Router B and Router C are in
AS 65009. The routing tables of these routers have many routes, and the routes change
frequently. After BGP is enabled on these routers, the routers can exchange routing information.
When routes of one router change, this router will send Update messages to its peers carrying
only changed routing information. This greatly reduces bandwidth consumption.
After the configuration is complete, Router A cannot ping Router C.

Figure 5-16 Networking on which a router does not receive routes advertised by its IBGP peer
AS 65009
10.2.1.1/24 10.1.1.1/24
10.1.1.2/24
RouterB RouterC
RouterA
AS 65008
Fault Analysis
1. Run the ping host command on Router A. In this example, Router A can ping Router B,
which indicates that the link between Router A and Router B functions properly.
2. Run the ping host command on Router B. In this example, Router B can ping Router C,
which indicates that the link between Router B and Router C functions properly.
3. Run the display bgp routing-table command on Router B to check its BGP routing table.
In this example, Router B has learned the route 10.2.1.1 from its EBGP peer Router A.
4. Run the display ip routing-table command on Router C to check its IP routing table. In
this example, Router C has not learned the route 10.2.1.1. The possible causes are as
follows:
l Cause 1: The routing policy of Router B prevents Router C from learning this BGP
route.
l Cause 2: AS_PATH attribute of the route that Router B advertised to Router C has the
AS number of Router C. BGP loop prevention mechanism prevents Router C from
learning this route.
5. Run the display current-configuration command on Router B to check its BGP
configuration information. In this example, Router B does not have any routing policy
configured for its IBGP peer. Therefore, cause 1 can be ruled out.
6. Run the display bgp routing-table peer ipv4-address advertised-routes command on
Router B to check the route that it advertised to its IBGP peer Router C. In this example,
the AS_PATH attribute of the route has the same AS number as Router C.
7. Run the display current-configuration command on Router B to check its BGP
configuration information. In this example, a routing policy is configured on Router B and
enables it to add its local AS number to the AS_PATH attribute of the route received from
its EBGP peer. Therefore, cause 2 caused this problem.
Procedure
Step 1 Run the system-view command on Router B to enter the system view.
Step 2 Run the route-policy route-policy-name permit node node command to enter the route-policy
view.

Step 3 Run the apply as-path as-number additive command to add AS number 65008 of Router A to
the route received from Router A.
After the preceding configuration is complete, Router A can ping Router C.
NOTE
In this example, you can also run the peer ipv4-address route-policy import command on Router B in the
BGP-IPv4 unicast address family view to delete the routing policy configured for the route that Router B
receives from its EBGP peer.
----End
Summary
To modify the AS_PATH attribute on a router, run the apply as-path as-number additive
command. Note the following points: a. Add the AS number of its peer to the route that it receives
from its peer; b. Add its local AS number to the route that it advertises to its peer. By doing so,
this router's IBGP peer can receive the route advertised by its EBGP peer.

Troubleshooting - IP Forwarding and Routing 6 RIP Troubleshooting
6 RIP Troubleshooting
About This Chapter
6.1 Device Does not Receive Partial or All the Routes
6.2 Device Does not Send Some or All Routes

6.1 Device Does not Receive Partial or All the Routes
6.1.1 Common Causes

l The incoming interface is not enabled with RIP.

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

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 6-1.

Figure 6-1 RIP route receiving troubleshooting flowchart

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

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

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

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

is configured? of rip metricin rectified?
No No
Metric Yes
is larger than
16?
No
Ensure same
Yes authentication on the
Authentication Is fault
Is matching? sending and rectified?
receiving interface
Yes
There Yes
are other better
routes?
No
Seek technical End
support

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

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

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

6.2 Device Does not Send Some or All Routes
6.2.1 Common Causes

l The outgoing interface is not enabled with RIP.

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

If a router sends partial or none routes, refer to the following troubleshooting flowchart, as shown
in Figure 6-2.

Figure 6-2 RIP route sending troubleshooting flowchart

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

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

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

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

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

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

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


Troubleshooting - IP Forwarding and Routing

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Troubleshooting - IP Forwarding and Routing

Diunggah oleh

Hak Cipta:

Format Tersedia

HUAWEI NetEngine40E/80E Universal Service

Troubleshooting - IP Forwarding and

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential i

About This Document

Issue 03 (2013-08-20) Huawei Proprietary and Confidential ii

Product Name Version

HUAWEI NetEngine80E/40E V600R006C00

l System maintenance engineers

DANGER indicates a hazard with a high level or medium

WARNING indicates a hazard with a low level of risk which,

CAUTION indicates a potentially hazardous situation that,

NOTE NOTE provides additional information to emphasize or

Boldface The keywords of a command line are in boldface.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.

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

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

[ x | y | ... ] Optional items are grouped in brackets and separated by

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

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 03 (2013-08-20)

Changes in Issue 02 (2013-04-15)

Changes in Issue 01 (2012-11-10)

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iv

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

Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi

4.4.3 Troubleshooting Procedure........................................................................................................................................71

Issue 03 (2013-08-20) Huawei Proprietary and Confidential vii

6.1.3 Troubleshooting Procedure......................................................................................................................................116

Issue 03 (2013-08-20) Huawei Proprietary and Confidential viii

About This Chapter

1.2 Related Troubleshooting Cases

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1 The ARP Entries on the Local Device Cannot Be Learnt

1.1.1 Common Causes

1.1.2 Troubleshooting Flowchart

Figure 1-1 shows the detailed troubleshooting procedure.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 2

Failing to learn the ARP entries

Is the No Ensure that the Yes

Is there Ensure that there is

Ensure that the IP

Seek technical support End

1.1.3 Troubleshooting Procedure

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 3

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 4

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

1.1.4 Relevant Alarm and Log Messages

1.2 Related Troubleshooting Cases

After the configuration is complete, PC1 fails to ping PC2.

192.168.1.2/16 192.168.1.1/24 192.168.2.1/24 192.168.2.2/16

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 5

1.2.2 The Webpage Cannot Be Opened After Service Cutover Due

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 6

192.168.100.50 RouterA RouterB

After service cutover, it is found that the webpage cannot be opened.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 7

Classifier: Fivedai operator or

4. Run the display current-configuration command on Router A to check the related