Troubleshooting - Reliability

HUAWEI NetEngine40E/80E Universal Service
Router
V600R006C00
Troubleshooting - Reliability
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 - Reliability 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 - Reliability Contents
Contents
About This Document.....................................................................................................................ii

1 BFD Troubleshooting...................................................................................................................1
1.1 BFD Session Cannot Go Up...........................................................................................................................................2
1.1.1 Common Causes..........................................................................................................................................................2
1.1.2 Troubleshooting Flowchart..........................................................................................................................................3
1.1.3 Troubleshooting Procedure..........................................................................................................................................4
1.1.4 Relevant Alarms and Logs..........................................................................................................................................5
1.2 Interface Forwarding Is Interrupted After a BFD Session Detects a Fault and Goes Down..........................................6
1.2.1 Common Causes..........................................................................................................................................................6
1.3 Changed BFD Session Parameters Do Not Take Effect.................................................................................................8
1.3.1 Common Causes..........................................................................................................................................................8
1.4 Dynamic BFD Session Fails to Be Created....................................................................................................................9
1.4.1 Common Causes..........................................................................................................................................................9
1.4.2 Troubleshooting Flowchart........................................................................................................................................10
1.4.3 Troubleshooting Procedure........................................................................................................................................10
1.4.4 Relevant Alarms and Logs........................................................................................................................................11
1.5 Related Troubleshooting Cases....................................................................................................................................11
1.5.1 Traffic Loss Occurs in a Network Enabled with BFD-based IP FRR.......................................................................12
1.5.2 A BFD Session for a Specific PW Cannot Go Up....................................................................................................13
2 VRRP Troubleshooting..............................................................................................................16
2.1 Double Master Devices Exist in a VRRP Backup Group............................................................................................17
2.1.1 Common Causes........................................................................................................................................................17
2.2 VRRP Status of the Backup Device Flaps....................................................................................................................20
Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

2.2.1 Common Causes........................................................................................................................................................20

2.3 Related Troubleshooting Cases....................................................................................................................................23
2.3.1 Pinging a VRRP Interface Address Fails..................................................................................................................23
2.3.2 No VRRP Switchover Is Performed After a GRE Board Fails.................................................................................24
2.3.3 Data Packets Are Discarded on a Network Configured with VRRP.........................................................................26
2.3.4 The VRRP Non-preemption Mode Does Not Take Effect........................................................................................29
3 MPLS OAM Troubleshooting...................................................................................................32

3.1 MPLS OAM Detection Does Not Work at the Source Point.......................................................................................33
3.1.1 Common Causes........................................................................................................................................................33
3.2 MPLS OAM Detection Does Not Work at the Sink Point...........................................................................................35
3.2.1 Common Causes........................................................................................................................................................35
3.3 OAM Detection Status at the Source Point Is Inconsistent With That at the Sink Point.............................................38
3.3.1 Common Causes........................................................................................................................................................38
3.4 MPLS OAM-enabled Devices Cannot Communicate with Each Other.......................................................................39
3.4.1 Common Causes........................................................................................................................................................39
4 Y.1731 Troubleshooting..............................................................................................................41
4.1 Troubleshooting of the Fault that No Single-ended Frame Loss Statistics Are Collected Though Single-ended Frame
Loss Measurement Is Configured for a VLAN..................................................................................................................43
4.1.1 Common Causes........................................................................................................................................................43
4.2 Troubleshooting of the Fault that No Dual-ended Frame Loss Statistics Are Collected Though Dual-ended Frame Loss
Measurement Is Configured for a VLAN...........................................................................................................................46
4.2.1 Common Causes........................................................................................................................................................46
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi


4.3 Troubleshooting of the Fault that One-way Delay Is Not Collected Though One-way Frame Delay Measurement Is
Configured for a VLAN.....................................................................................................................................................48
4.3.1 Common Causes........................................................................................................................................................48
4.4 Troubleshooting of the Fault that Two-way Delay Is Not Collected Though Two-way Frame Delay Measurement Is
Configured for a VLAN.....................................................................................................................................................52
4.4.1 Common Causes........................................................................................................................................................52
Loss Measurement Is Configure for a VPLS Network.......................................................................................................55
4.5.1 Common Causes........................................................................................................................................................55
4.6 Troubleshooting of the Fault that No Dual-ended Frame Loss Statistics Are Collected Though Dual-ended Frame Loss
Measurement Is Configure for a VPLS Network...............................................................................................................58
4.6.1 Common Causes........................................................................................................................................................58
Configured for a VPLS Network........................................................................................................................................60
4.7.1 Common Causes........................................................................................................................................................61
Configured for a VPLS Network........................................................................................................................................64
4.8.1 Common Causes........................................................................................................................................................64
Loss Measurement Is Configure for a VLL Network.........................................................................................................67
4.9.1 Common Causes........................................................................................................................................................67
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vii


4.10 Troubleshooting of the Fault that No Dual-ended Frame Loss Statistics Are Collected Though Dual-ended Frame
Loss Measurement Is Configure for a VLL Network.........................................................................................................71
4.10.1 Common Causes......................................................................................................................................................71
4.10.2 Troubleshooting Flowchart......................................................................................................................................71
4.10.3 Troubleshooting Procedure......................................................................................................................................72
4.10.4 Relevant Alarms and Logs......................................................................................................................................73
Configured for a VLL Network..........................................................................................................................................74
4.11.1 Common Causes......................................................................................................................................................74
Configured for a VLL Network..........................................................................................................................................77
4.12.1 Common Causes......................................................................................................................................................77
5 MPLS-TP OAM Troubleshooting............................................................................................81

5.1 ME Cannot Go Up........................................................................................................................................................82
5.1.1 Common Causes........................................................................................................................................................82
6 Multi-Device Backup Troubleshooting..................................................................................86

6.1 User Information Fails to Be Backed Up.....................................................................................................................87
6.1.1 Common Causes........................................................................................................................................................87
6.2 A User Fails to Log In Through the Backup Device....................................................................................................89
6.2.1 Common Causes........................................................................................................................................................89
6.3 After IP Redirection Protection Tunnels Are Deployed for Public Network Users, the Return Traffic Is Interrupted
............................................................................................................................................................................................91
6.3.1 Common Causes........................................................................................................................................................91
Issue 03 (2013-08-20) Huawei Proprietary and Confidential viii

6.4 After the Tunnel Policy Is Deployed for Public Network Users, the Return Traffic Is Interrupted............................95
6.4.1 Common Causes........................................................................................................................................................95
6.5 Return Traffic Is Interrupted After the VPN Tunnel Is Deployed for Private Network Users....................................97
6.5.1 Common Causes........................................................................................................................................................98
6.6 Multicast Entries Cannot Be Backed Up to the Backup Device................................................................................100
6.6.1 Common Causes......................................................................................................................................................100
6.7 Automatically Advertising Route Cost Values Fails..................................................................................................103
6.7.1 Common Causes......................................................................................................................................................103
6.8 User Traffic Imbalance Based on Odd and Even MAC Addresses............................................................................105
6.8.1 Common Causes......................................................................................................................................................105
6.9 NAT Troubleshooting in Dual-System Backup for Distributed NAT Services.........................................................107
6.9.1 Common Causes......................................................................................................................................................107
6.10 Troubleshooting Cases.............................................................................................................................................110
6.10.1 After the Tunnel Is Deployed, the Return Traffic Is Interrupted...........................................................................110
7 APS Troubleshooting............................................................................................................... 112

7.1 APS Failure or Slow APS Troubleshooting...............................................................................................................113
7.1.1 Common Causes......................................................................................................................................................113
Issue 03 (2013-08-20) Huawei Proprietary and Confidential ix

Troubleshooting - Reliability 1 BFD Troubleshooting
1 BFD Troubleshooting
About This Chapter
1.1 BFD Session Cannot Go Up
1.2 Interface Forwarding Is Interrupted After a BFD Session Detects a Fault and Goes Down
1.3 Changed BFD Session Parameters Do Not Take Effect
1.4 Dynamic BFD Session Fails to Be Created
1.5 Related Troubleshooting Cases
Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1 BFD Session Cannot Go Up
1.1.1 Common Causes

This fault is commonly caused by one of the following:
l The discriminators of the two devices are inconsistent.
l The link detected by the BFD session fails. As a result, BFD packets cannot be exchanged
between the two ends of the BFD session.
l The BFD session status flaps.

1.1.2 Troubleshooting Flowchart
Figure 1-1 Troubleshooting flowchart for the fault that a BFD session cannot go Up
A BFD session
cannot go Up
Configuration No Yes
Commit the Is fault
of the BFD session is End
configuration rectified?
committed?
Yes No
Delete the
Discriminators No setting and set Yes
Is fault
on both ends are the consistent End
rectified?
consistent? discriminators
on both ends
No
Yes
BFD packets Yes Seek

can be received and technical
sent correctly? support
No
Statistics
Statistics Yes Yes
about the times the Adjust the BFD
about error packets
BFD session goes detection time
exist?
Down exist?
No
No
No
Yes
Is fault rectified? No
Is fault rectified?
No Yes
Two ends Yes
Of the BFD session
can ping each End
other?
No
Check the link Seek technical

support
End

1.1.3 Troubleshooting Procedure
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 Run the display current-configuration command to check that the configuration of the BFD
session is committed.
l If the commit command is displayed, the configuration of the BFD session has been
committed. Then, go to Step 2.
l If the commit command is not displayed, the configuration of the BFD session has not been
committed. In this case, run the commit command to commit the configurations. After doing
so, run the display bfd session all command to check the State field.
If the State field is Up, the BFD session is successfully established.
If the State field is not Up, go to Step 2.
Step 2 Run the display current-configuration command to check whether the discriminators of the
two devices are consistent.
l If they are inconsistent, run the undo bfd command to delete the existing bfd session, and
then run the bfd bind peer-ip command to create a new bfd session. At last run the
discriminator { local discr-value | remote discr-value } command to configure the local
and remote discriminators. Ensure that the local discriminator on the local end is the same
as the remote discriminator on the remote end and the remote discriminator on the local end
is the same as the local discriminator on the remote end. Then, go to Step 3.
l If they are consistent, go to Step 4.
Step 3 Run the display bfd session all command to check the State field.
l If the State field is Up, the BFD session is successfully established.
l If the State field is not Up, go to Step 4.
Step 4 Run the display bfd statistics session all slot slot-id command several times to view statistics
about the BFD packets of the BFD session.
l If the value of the Received Packets field does not increase, go to Step 5.
NOTE
For single-hop BFD, if two devices that have created a BFD session learn ARP entries with different
VLAN IDs, there is a possibility that the Received Packets count will not increase and the BFD session
will go Down.
l If the value of the Send Packets field does not increase, go to Step 6.
l If the values of Received Packets and Send Packets fields increase, go to Step 9.
l If none of the values of the Received Packets, Send Packets, Received Bad Packets, and
Send Bad Packets fields increase, go to Step 7.

l If the value of the Down Count field increases, the BFD session flaps. Then, go to Step 7.
Step 5 Run the display bfd statistics session all slot slot-id command several times to check the
Received Bad Packets field.
l If the value of this field increases, the BFD packets have been received and discarded. Then,
go to Step 9.
l If the value of this field does not increase, the BFD packets have not been received. Then,
go to Step 7.
Step 6 Run the display bfd statistics session all slot slot-id command several times to check the Send
Bad Packets field.
l If the value of this field increases, the BFD packets sent by the BFD session have been
discarded. Then, go to Step 9.
l If the value of this field does not increase, the BFD packets failed to be sent. Then, go to
Step 7.
Step 7 Run the display bfd statistics session all slot slot-id command several times. If the BFD session
still does not go Up, run the ping command on one end to ping the other end of the BFD session.
l If the ping fails, it indicates that the link fails. See the section The Ping Operation Fails to
rectify the fault on the link.
l If the ping is successful, it indicates that the link is reachable. Then, go to Step 8.
Step 8 Run the display current-configuration command to view the min-tx-interval and min-rx-
interval fields to check that the BFD detection period is longer than the delay on the link.
l If the BFD detection period is shorter than the delay on the link, run the detect-multiplier,
min-rx-interval, and min-tx-interval commands to adjust the values to make it longer than
the delay on the link.
l If the BFD detection time is longer than the delay time on the link, go to Step 9.
Step 9 If the fault persists, collect the following information and contact Huawei technical support
personnel.
l Results of the preceding troubleshooting procedure.
l Configuration files, log files, and alarm files of the devices.
----End
1.1.4 Relevant Alarms and Logs
Relevant Alarms
BFD/3/BFD_DOWN_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.1 Session changes to DOWN.
(Index=16389, ConfigurationName=2/1/0, PeerIp=224.0.0.108, BindIfIndex=134217985,
BindIfName=GigabitEthernet2/1/0, Diagnosis=1, BindVrfIndex=0, BindVpnName="",
SessionType=1, DefaultIp=2, BindType=1, StaticLspName="", PwSecondary=0,
NextHop=224.0.0.108, VcId=0, VsiName="", VsiPeerAddress=0.0.0.0, DiscrAuto=2)
BFD/3/BFD_UP_TRAP:OID 1.3.6.1.4.1.2011.5.25.38.3.2 Session changes to UP.
(Index=16389, ConfigurationName=2/1/0, PeerIp=224.0.0.108, BindIfIndex=134217985,
BindIfName=GigabitEthernet2/1/0, Diagnosis=1, BindVrfIndex=0, BindVpnName="",
SessionType=1, DefaultIp=2, BindType=1, StaticLspName="", PwSecondary=0,
NextHop=224.0.0.108, VcId=0, VsiName="", VsiPeerAddress=0.0.0.0, DiscrAuto=2)

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

Detects a Fault and Goes Down
1.2.1 Common Causes

This fault is commonly caused by the following:
l The BFD session status is associated with the interface status.

Figure 1-2 Troubleshooting flowchart for the fault that the interface forwarding is interrupted
after a BFD session detects a fault and goes Down
Interface forwarding
is interrupted after a
BFD session detects
a fault and goes
Down
Check the interface status
Interface
is DOWN No Rectify the fault in the
But the BFD session End
forwarding module
status is
Down?
Yes
No BFD session Yes

BFD session is Up? status is associated End
with interface
status?
Yes No
Seek technical support

Context
NOTE
Procedure
Step 1 Run the display interface interface-type interface-number command to check the status of the
interface to which the BFD session is bound.
l If the Line protocol current state field displays DOWN(BFD status down), the interface
status is set to BFD status down after the BFD session detects a link fault. Then, go to Step
2.
l If the Line protocol current state field displays UP but the interface cannot forward packets,
the forwarding module is faulty. See the section The Ping Operation Fails to rectify the
forwarding fault.
Step 2 Run the display bfd session all command to view the status of the BFD session.
l If the BFD session is Down, go to Step 3.

l If the BFD session is Up, go to Step 4.
Step 3 Run the display current-configuration configuration bfd-session command to check that the
process-interface-status command is configured.
l If the process-interface-status command is configured, the interface is set to DOWN(BFD

status down) because the BFD session detected a fault and went Down.
l If the process-interface-status command is not configured, go to Step 4.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.

1.3 Changed BFD Session Parameters Do Not Take Effect
1.3.1 Common Causes

This fault is commonly caused by the following:
l After parameters of a BFD session have been changed, changed configurations are not
committed.

Figure 1-3 Troubleshooting flowchart for the fault that the changed BFD session parameters do
not take effect
Changed BFD
session parameters
cannot take effect
Check the configuration of

the BFD session
BFD session Yes BFD session

configuration is configuration takes
committed? effect?
No
Run the commit command to Yes

make the configuration take Is fault rectified? End
effect
No
Seek technical
End
support
Context
NOTE

Procedure
Step 1 Run the display current-configuration configuration bfd-session command to check that the
commit command is configured.
l If the commit command is configured, the changed BFD session parameters have been
committed. Then, go to Step 3.
l If the commit command is not configured, the changed BFD session parameters have not
been committed. Then, run the commit command, and then go to Step 2.
Step 2 Run the display bfd session all command check whether the BFD session parameters are
specified values.
l If BFD session parameters are specified, the modified parameters take effect.
l If BFD session parameters are not specified, go to Step 3.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
1.4 Dynamic BFD Session Fails to Be Created
1.4.1 Common Causes

l BFD is not enabled for the protocol.
l The route to the peer of the BFD session does not exist in the routing table.
l The interface is prohibited from creating a BFD session.


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

fails to be created
Check the configuration of the

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

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

prohibited from creating
on the link
a BFD session?
No
Seek technical support

End
Context
NOTE

Procedure
Step 1 Run the display current-configuration configuration bfd command to check that BFD is
enabled for a protocol.
l If BFD is not enabled for a protocol, enable BFD. Then, go to Step 2.

l If BFD is enabled, go to Step 3.
Step 2 Run the display bfd session all command to view the state field.
l If the state field in the command output is Up, it indicates that the BFD section has been
created.
l If the state field in the command output is not Up, go to step 3.
Step 3 Run the display ip routing-table command to check whether the route of the link detected by
the BFD session exists.
l If the route exists, go to step 4.

l If the route does not exist, the BFD session associated with the protocol fails to be created.
see the section The Ping Operation Fails.
Step 4 Run the interfaceinterface-typeinterface-number command to enter the view of the existing
interface, then run the display this command to check that a command is configured to disable
an interface to dynamically create a BFD session.
l If such a command is configured, Run the undo ospf bfd block command to enable the
interface to dynamically create a BFD session. Then, run the display bfd session all
command to check whether the BFD session is Up. If the session is not up, go to step 5.
l If such a command is not configured, go to step 5.
personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.

1.5.1 Traffic Loss Occurs in a Network Enabled with BFD-based IP

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

2. Run the undo bfd cfg-name command to delete the BFD session between Router A
and Router B.
3. Run the bfd cfg-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between Router A and Router B.
4. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
5. Run the discriminator local discr-value command to set the local discriminator.
6. Run the discriminator remote discr-value command to set the remote discriminator.
7. Run the commit command to make the BFD session configurations take effect.
l Configure a single-hop BFD session on Router A to detect the direct link between Router
A and Router C.
1. Run the system-view command to enter the system view.
2. Run the undo bfd cfg-name command to delete the BFD session between Router A
and Router C.
3. Run the bfd cfg-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between Router A and Router C.
4. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
5. Run the discriminator local discr-value command to set the local discriminator.
6. Run the discriminator remote discr-value command to set the remote discriminator.
7. Run the commit command to make the BFD session configuration take effect.
----End
Summary
During the configuration of BFD-based IP FRR, the process-pst command must be run to bind
a BFD session with the interface status in the port status table (PST). The process-pst command
is only applicable to a single-hop BFD session that has been bound to an interface. The parameter
interface interface-type interface-number must be specified before a single-BFD session is
configured.
1.5.2 A BFD Session for a Specific PW Cannot Go Up
Fault Symptom
As shown in Figure 1-6, CE1 and CE2 are connected to U-PE1 and U-PE2 respectively using
PPP. U-PE1 and U-PE2 are connected over the MPLS backbone network. A dynamic multi-hop
PW is set up between U-PE1 and U-PE2 through an LSP, with S-PE functioning as the transit
node. A BFD session is created between U-PE1 and U-PE2. The TTL value is set to 1 on U-
PE1, and the TTL value is automatically calculated on U-PE2. After the configuration, the BFD
session becomes Down.

Figure 1-6 Networking for the fault that a BFD session for a specific PW cannot go Up
Loopback0 Loopback0 Loopback0
2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
P1 POS1/0/0 POS1/0/0 P2
20.1.1.2/24 30.1.1.2/24
POS1/0/0 POS2/0/0 POS2/0/0 POS2/0/0
10.1.1.2/24 20.1.1.1/24 S-PE 30.1.1.1/24 40.1.1.2/24
Loopback0 Loopback0
1.1.1.9/32 100 PW 5.5.5.9/32
PW 200
POS2/0/0 POS1/0/0
10.1.1.1/24 40.1.1.2/24
U-PE1 U-PE2
POS1/0/0 POS2/0/0
POS1/0/0 POS1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Fault Analysis
1. After the display mpls l2vc interface interface-type interface-number command is run on
U-PE1 and U-PE2 respectively, the session state, AC state, and AC state fields are all
displayed as Up. Therefore, the PW functions properly.
<U-PE1> display mpls l2vc
total LDP VC : 1 1 up 0 down
*client interface : LoopBack0
Administrator PW : yes
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : IP-interworking
destination : 3.3.3.9
local VC label : 1034 remote VC label : 1031
control word : disable
forwarding entry : exist
local group ID : 0
manual fault : not set
active state : active
link state : up
local VC MTU : 1500 remote VC MTU : 1500
tunnel policy name : --
traffic behavior name: --
PW template name : to3
primary or secondary : primary
create time : 0 days, 4 hours, 51 minutes, 2 seconds
up time : 0 days, 4 hours, 49 minutes, 57 seconds
last change time : 0 days, 4 hours, 49 minutes, 57 seconds
VC last up time : 2010/12/07 11:41:02
VC total up time : 0 days, 4 hours, 49 minutes, 57 seconds

CKey : 23
NKey : 22
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
2. After the display bfd session all verbose command is run on U-PE1, the PW TTL field
is displayed as 1; after the display bfd session all verbose command is run on U-PE2, the
PW TTL is displayed as 2. The TTL values on two ends are different. In this case, the TTL
values on both ends should be changed to the number of hops of the PW.
<U-PE1> display current-configuration configuration bfd-lsp-session
#
bfd pe1tope2 bind pw interface LoopBack0 remote-peer 5.5.5.9 pw-ttl 1
e
discriminator local 1
discriminator remote 2
commit
<U-PE2> display current-configuration configuration bfd-lsp-session
#
bfd pe2tope1 bind pw interface LoopBack0 remote-peer 1.1.1.9 pw-ttl 2
e
discriminator local 2
discriminator remote 1
commit
Procedure
Step 1 Run the system-view command to enter the system view of U-PE1.
Step 2 Run the undo bfd cfg-name command to delete the BFD session detecting the PW.
Step 3 Run the bfd cfg-name bind pw interface interface-type interface-number remote-peer remote-
peer-address pw-ttl auto-calculate command to configure the BFD session for a specific PW
again.
Step 4 Run the commit command to make the configuration take effect.
----End
Summary
When a BFD session for a specific PW is configured, if you specify the TTL value, ensure that
the TTL value is the number of S-PE nodes plus 1. You can also configure the auto-calculate
parameter in this command to automatically calculate the TTL value. Note that remote-peer
remote-peer-address specifies the address of the remote U-PE.

Troubleshooting - Reliability 2 VRRP Troubleshooting
2 VRRP Troubleshooting
About This Chapter
2.1 Double Master Devices Exist in a VRRP Backup Group
2.2 VRRP Status of the Backup Device Flaps

2.1 Double Master Devices Exist in a VRRP Backup Group
2.1.1 Common Causes

l The VRRP backup group configurations on two devices do not match.
l The link over which VRRP Advertisement messages are transmitted fails.
l STP is not enabled, causing a loop, and then an interface is blocked on the link over which
VRRP Advertisement messages are transmitted.
l The lower-priority device in the VRRP backup group considers the received VRRP
Advertisement message as illegal and discards it.


Figure 2-1 Troubleshooting flowchart for the fault that double master devices exist in a VRRP
backup group
Dual master
devices occur in a
VRRP backup
group
Ensure VRIDs and

VRRP parameters No virtual IP addresses on Is fault Yes
On two ends are the two end are correct rectified?
consistent? and are the same
No
Yes
On STP-enabled Yes
interfaces, an interface Seek technical
is blocked after a loop support
occurs?
No
VRRP-enabled No Ensure VRRP-enabled

Is fault Yes
interfaces are correctly interfaces are correctly
connected and go rectified?
connected and go Up
Up?
No
Yes
VRRP-enabled No Yes
Is fault
interface can ping each Rectify the link fault
rectified?
other?
No
Yes
A backup Check devices on the

VRRP device Yes user access side to Yes
Is fault
receives an illegal ensure valid VRRP
rectified?
VRRP Advertisement Advertisement
message? messages are sent
No
No
Seek technical support End

Context
NOTE
Procedure
Step 1 Check whether the configurations of the VRRP backup group on two devices match.
On an interface configured with the VRRP backup group, run the display this command to check
whether the configurations of the VRRP backup group on two devices match, including VRIDs,
virtual IP addresses, network segment of interface addresses.
l If not, change the configurations to make them on the two devices be the same. Then, go to
Step 2.
l If so, go to Step 3.
Step 2 Run the display vrrp command to check that there is one master device and one backup device
in the VRRP backup group.

l If there are still two master devices, go to Step 3.
Step 3 Run the display stp brief command on two devices configured with the VRRP backup group
and other devices through which the VRRP Advertisement message passes to check whether an
interface is blocked.
l If the STP State field displays FORWARDING, it indicates that the interface is not blocked.
Then, go to Step 4.
l If the STP State field displays DISCARDING, it indicates that the interface is blocked.
Then, go to Step 9.
Step 4 Check that the interfaces transmitting VRRP Advertisement messages are correctly connected
and run the display interface interface-type interface-number command several times to check
whether the interfaces transmitting VRRP Advertisement messages are being Up.
l If the interfaces are correctly connected and are always in the Up state, go to Step 6.
l If the interfaces are incorrectly connected, connect the interface correctly. After the interfaces
go Up, go to Step 5.

Step 6 Check that the two interfaces configured with the VRRP backup group can ping each other.
l If the ping succeeds, go to Step 8.

l If the ping fails, it indicates that the link fails. See the section The Ping Operation Fails to
rectify the fault on the link and then go to Step 7.


Step 8 Run the display vrrp statistics command to check that the lower priority device in the VRRP
backup group receives an illegal VRRP Advertisement message.
l If not, go to Step 9.
personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the devices
Step 10 End.
----End
Relevant Alarms
None.
Relevant Logs
None.
2.2 VRRP Status of the Backup Device Flaps
2.2.1 Common Causes

l The link transmitting VRRP Advertisement packets flaps.
l VRRP advertisement packets are filtered before being forwarded because of packet
congestion.

Figure 2-2 Troubleshooting flowchart for the fault that the VRRP status of the backup device
flaps
VRRP status on the

backup device flaps
No
Timer expiration
Seek technical
causes the backup to
support
become the master?
Yes
Link transmitting Yes Yes

Rectify the fault on Is fault
VRRP Advertisement
the link rectified?
packets flaps?
No
No
Packet
Yes Delete the Yes
congestion causes VRRP Is fault
configuration of
Advertisement packets to rectified?
filtering traffic
be filtered?
No
No
Context
NOTE
Procedure
Step 1 Check whether the following log message is displayed, which indicates that the backup device
becomes the master device because the VRRP timer expires.

%%01VRRP/4/STATEWARNING(l): Virtual Router state BACKUP changed to MASTER, because

of protocol timer expired. (Interface=Vlanif1005, VrId=4)
l If the preceding log message is displayed, go to Step 2.

l If the preceding log message is not displayed and the fault persists, go to Step 7.
Step 2 Run the display interface interface-type interface-number command several times to check
whether the physical status of the interface transmitting VRRP Advertisement packets flaps.
l If the physical interface alternates between Up and Down, repair the network cable or rectify
the fault on the interface. Then, go to Step 3.
l If the physical interface status is stable and the fault persists, go to Step 3.
Step 3 Run the display vrrp command several times to check whether the VRRP status of the backup
device is always Backup.
l If not, go to Step 4.
Step 4 Run the display this command in the slot-view to check whether a policy for filtering packets
is configured on the LPU.
l If cpu-defend-policy is displayed in the command output, go to Step 5.

l If cpu-defend-policy is not displayed in the command output, it indicates that no policy for
filtering packets is configured. Then, go to Step 7.
Step 5 Run the display this command in the slot-view to check whether a policy (for example, an ACL
rule) for filtering VRRP Advertisement packets is configured on the LPU.
l If a policy filtering VRRP Advertisement packets is configured, go to Step 6.

l If no policy filtering VRRP Advertisement packets is configured, go to Step 7.
Step 6 Run the display cpu-defend car user-defined-flow command to check whether statistics about
discarded packets are displayed.
l If the Dropped packet(s) field displays a non-zero value, it indicates that certain VRRP
Advertisement packets have been discarded. Then, go to Step 7.
l If the Dropped packet(s) field displays zero, it indicates that no VRRP Advertisement
packets are discarded. Then, go to Step 7.
personnel.
Step 8 End.
----End
Relevant Alarms
None.

Relevant Logs
VRRP/4/STATEWARNINGEXTEND: Virtual Router state BACKUP changed to MASTER, because
of protocol timer expired.
2.3.1 Pinging a VRRP Interface Address Fails
Fault Symptom
On the network shown in Figure 2-3, VRRP backup group 1, functioning as the gateway of a
service server, is configured on GE 1/0/0 of Router A and GE 1/0/0 of Router B. Router A
functions as a master device and Router B functions as a backup device. After the configurations,
the service server fails to ping GE 1/0/0 of Router A.
Figure 2-3 Networking diagram of a failure in pinging the IP address of a VRRP interface
VRRP backup group 1

RouterA
GE1/0/0
Eth-Trunk1
Service
server Eth-Trunk1
GE1/0/0
RouterB
Fault Analysis
1. Run the display arp all command on Router A to check the MAC ADDRESS field.
Router A has learned the MAC address of the service server. It indicates that the problem
is not caused by a link failure.
2. Run the display vrrp command on Router A and Router B to check the State field. The
state of Router A is Master and the state of Router B is Backup, indicating that the VRRP
backup group has been successfully created.

3. Configure STP on Router A, Router B, and the switch to eliminate loops on the network.
After the configuration, the service server still fails to ping GE 1/0/0 of Router A. It indicates
that the problem is not caused by the loop on the network.
4. After running the ping command on the service server to ping GE 1/0/0 of Router A, run
the debug arp packet command to capture an ARP packet in the user view on Router A.
Information about the ARP packet sent by Router A is as follows:
*0.3964282271 XJ-WLMQ-HBL-CE-1.CDMA ARP/7/arp_send:Slot=1;Send an ARP Packet,
op
eration : 1, sender_eth_addr : 0018-8288-2cba,sender_ip_addr : 10.255.192.66,
ta
rget_eth_addr : 0000-0000-0000, target_ip_addr :
10.255.192.90
Information about the ARP packet received by Router A is as follows:

*0.3964282271 XJ-WLMQ-HBL-CE-1.CDMA ARP/7/arp_rcv:Slot=4;Receive an ARP
Packet,
operation : 2, sender_eth_addr : 0012-3f1c-8649, sender_ip_addr :
10.255.192.90,
target_eth_addr : 0018-8288-2cba, target_ip_addr : 10.255.192.66
The preceding packet information shows that the ARP packet is sent by the LPU in slot 1
and received by the LPU in slot 4. Run the display current-configuration command. The
command output shows that the arp learning strict command has been configured on
Router A, causing the service server to fail to ping GE 1/0/0 of Router A. In this case, run
the arp learning strict force-disable command to disable the strict MAC address learning
function on GE 1/0/0 of Router A. The fault is then cleared.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the arp learning strict force-disable command to disable the strict MAC address learning
function.
----End
Summary
The strict MAC address learning function may cause a ping operation to fail. Therefore,
configure this function with caution.
2.3.2 No VRRP Switchover Is Performed After a GRE Board Fails
Fault Symptom
On the network shown in Figure 2-4, Router A and Router B are configured with GRE and a
VRRP backup group. Router A and Router B are connected to the public network through tunnel
interfaces. VRRP tracks the upstream physical interfaces connected to the public network,
improving the reliability of the routers.

Figure 2-4 Networking diagram of GRE and VRRP
Master
VRRP RouterA
VRID 1
GRE tunnel
Network
SwitchC
GRE tunnel
RouterB
Backup
After the configurations, a GRE board on Router A fails but no switchover is performed within
the VRRP backup group.
Fault Analysis
Run the display vrrp command on Router A and Router B to check whether the parameters of
the VRRP backup group on Router A are the same as those on Router B. The parameters on
these two routers are the same. In addition, the VRRP backup group tracks the upstream physical
interface status, rather than the tunnel interface status.
On each router, a GRE board that transmits GRE services is connected to the network using a
tunnel interface. The GRE board is disconnected from the network if the tunnel interface goes
Down, and the tunnel interface will be deleted if the GRE board fails. On this network, the GRE
board fails and therefore the tunnel interface configuration is deleted. The upstream physical
interface tracked by the VRRP backup group works properly. Therefore, no VRRP switchover
is performed though the GRE board fails. As a result, services are interrupted.
Procedure
Step 3 Run the vrrp vrid virtual-router-id track interface interface-type interface-number
[ increased value-increased | reduced value-reduced ] command to configure VRRP to track
the tunnel interface status, therefore implementing a fast master/backup switchover based on
tunnel interface status.
NOTE
A VRRP backup group can track the status of a maximum of eight interfaces. It is recommended to configure
the VRRP backup group to track only one tunnel interface on a single GRE board because a GRE board
failure will cause all tunnel interface configurations on this board to be deleted.

After the preceding operations, a VRRP switchover can be properly performed, ensuring proper
service transmission. The fault is cleared.
----End
Summary
On a network configured with logical interfaces, a VRRP backup group must be configured to
track both the logical interface status and the physical interface status. In this manner, the
situation that no VRRP switchover is triggered when the physical interface works properly but
the logical interface fails is avoided.
2.3.3 Data Packets Are Discarded on a Network Configured with

VRRP
Fault Symptom
On the network shown in Figure 2-5, a VRRP backup group is configured on Router A and
Router B. Router A functions as a master device and Router B functions as a backup device.
Router C functions as a switch connecting Router A and Router B.
Figure 2-5 Networking diagram of a VRRP backup group

RouterA
GE4/0/2 GE1/0/7
RouterC RouterD
GE2/0/4 GE2/0/3 GE1/0/7 GE1/0/2
GE2/0/5
RouterB
Eth-trunk
GE3/0/3
RouterE
After the configurations, a large number of packets sent from Router E to Router D are discarded.
Fault Analysis
1. Run the display vrrp [ interface interface-type interface-number ] [ virtual-router-id ]
statistics command on Router A and then Router B to check traffic on GE4/0/2 of
Router A and GE3/0/3 of Router B. A small volume of traffic is transmitted on GE4/0/2 of
Router A connected to Router C, and no traffic is transmitted on GE3/0/3 of Router B
connected to Router C.
Run the display interface-statistics interface-type interface-number command on
Router C to check traffic on GE 2/0/4, GE 2/0/3, and GE 2/0/5. A small volume of traffic
is transmitted on GE 2/0/3 connected to GE4/0/2, and no traffic is transmitted on GE 2/0/5

connected to GE3/0/3. A large amount of traffic is transmitted on GE 2/0/4. The statistics

show that traffic is dropped on Router C.
2. Run the display mac-address dynamic command on Router C to check MAC addresses.
The learned MAC address of Router A is sent by GE 2/0/4, but not GE 2/0/3 connected to
Router A or GE 2/0/5 connected to Routerr B, indicating that the learned MAC address is
incorrect. For example:
MAC address table of slot
2:
------------------------------------------------------------------------------
-
MAC Address VLAN/ PEVLAN CEVLAN Port Type
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic
-
0000-5e00-0101 1 - - GE2/0/4 dynamic
-
0098-0113-0005 1 - - GE2/0/4 dynamic
-
0018-824f-f5d1 1 - - GE2/0/3 dynamic
-
------------------------------------------------------------------------------
-
3. Run the display current-configuration interface interface-type interface-number

command on Router C to check the configuration on GE 2/0/4. For example:
#
interface GigabitEthernet2/0/4
undo shutdown
loopback local
portswitch
port default vlan 1
The loopback function has been configured on GE 2/0/4, indicating that GE 2/0/4 loops
traffic back after receiving it.
4. Run the display interface-statistics interface-type interface-number command on
Router C to check traffic on GE 2/0/3, GE 2/0/4, and GE 2/0/5. A great amount of traffic
is transmitted on GE 2/0/4. A small volume of traffic is transmitted on GE 2/0/3. This
indicates that traffic loss is caused by the loopback function on GE 2/0/4.
5. Run the display mac-address dynamic command multiple times on Router C to check
MAC addresses. Router C learns different MAC addresses at different times. For example:
[RouterC] display mac-address dynamic
2:
------------------------------------------------------------------------------
-
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic

-
0000-5e00-0101 1 - - GE2/0/4 dynamic
-
0098-0113-0005 1 - - GE2/0/5 dynamic
-
0018-824f-f5d1 1 - - GE2/0/4 dynamic
-
------------------------------------------------------------------------------
-
Total matching items on slot 2 displayed =
4
[RouterC] display mac-address dynamic
2:
------------------------------------------------------------------------------
-
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic
-
0000-5e00-0101 1 - - GE2/0/3 dynamic
-
0098-0113-0005 1 - - GE2/0/5 dynamic
-
0018-824f-f5d1 1 - - GE2/0/4 dynamic
-
------------------------------------------------------------------------------
-
Total matching items on slot 2 displayed=4
In a VRRP backup group, a router with a higher priority functions as a master device. If
the IP address of a router is the same as the virtual IP, the router priority is considered
highest and always functions as the master device. The master device sends a VRRP packet
to the backup device every one second by default. If a backup device fails to receive three
consecutive packets from the master device, the backup device preempts to be the master
device and sends a VRRP packet indicating that it becomes the master. In normal situations,
the backup device does not send VRRP packets.
NOTE
If a router is assigned an IP address the same as the virtual IP address, the router always functions
as the master router.
On this network, a packet sent by the master device arrives at the switch. The switch learns
the source MAC address (in this example, 0000-5e00-0101), VLAN ID, and interface
connected to the master device, and adds them to the MAC address table. The switch
searches the MAC address table for the interface connected to the master device, therefore
forwarding the packet to the backup device. If a VRRP switchover occurs, the backup
device becomes the master device and then sends a VRRP packet. After receiving the VRRP
packet, the switch learns the MAC address and maps it to another interface connected to
the new master device.
On this network, after receiving a VRRP packet that is sent every one second, Router C
learns the MAC address of Router A and forwards the VRRP packet to all interfaces
belonging to VLAN 1. GE 2/0/4 of VLAN 1 receives the VRRP packet, and then loops the
VRRP packet back using the loopback function. After receiving the returned VRRP packet,

Router C adds the mapping between GE 2/0/4 and 0000-5e00-0101 to the MAC address
table to overwrite the previous mapping. In this manner, the newly-learned MAC address
overwrites the previous one repeatedly, causing traffic loss.
Procedure
Step 3 Run the undo loopback command to disable the loopback function on the interface.
After the preceding operations, no traffic is discarded. The fault is cleared.
----End
Summary
Do not enable the loopback function on an interface of a Layer 2 device; otherwise, incorrect
MAC addresses are learned.
2.3.4 The VRRP Non-preemption Mode Does Not Take Effect
Fault Symptom
On the network shown in Figure 2-6, Router A and Router B are connected with a switch through
Eth-Trunk sub-interfaces. VRRP is run on the Eth-Trunk sub-interfaces. The VRRP status of
Router B is Master and the VRRP status of Router A is Backup. VRRP adopts the non-
preemption mode.
After the configuration, it is found that the backup device preempts to be the master device.
After Router B is restarted or the shutdown and undo shutdown commands are run on the Eth-
Trunk sub-interface of Router B, the backup device still preempts to be the master device.
Figure 2-6 The VRRP non-preemption mode failing to take effect

RouterA RouterB
Backup Master
ETH-Trunk10.200 VRRP200 ETH-Trunk11.200
Switch

Fault Analysis
1. Check the log information on Router B.
a. After Router B is restarted or the interface connecting Router B to the switch is shut
down, VRRP enters the Init state.
VRRP/4/STATEWARNING(l): Virtual Router state CREATED changed to
INITIALIZE, because of create INITIALIZE. (Interface=Eth-Trunk11.200,
VrId=200)
b. After the interface connecting Router B to the switch goes Up, VRRP enters the
Backup state.
VRRP/4/STATEWARNING(l): Virtual Router state INITIALIZE changed to
BACKUP, because of interface UP. (Interface=Eth-Trunk11.200, VrId=200)
c. After the VRRP timer times out, VRRP enters the Master state.
VRRP/4/STATEWARNING(l): Virtual Router state BACKUP changed to MASTER,
because of protocol timer expired. (Interface=Eth-Trunk11.200, VrId=200)
The preceding information shows that VRRP preemption does not occur. Because Router
B does not receive any VRRP packet from the Router A , after the VRRP timer times out,
Router B considers that there is no master on the network, and therefore enters the master
state.
2. Check the information about Router A and the switch. You can find that Router A sends
VRRP packets but the switch does not forward the VRRP packets to Router B. View the
log information of the switch. You can find that the interface connecting the switch to
Router B is not in the Forwarding time during the timeout period of the VRRP timer and
therefore discards the packets.
As defined in STP, after the interface becomes Up, the interface enters the Forwarding state
after 50s. As a result, the VRRP packets are discarded, and it is shown that Router B
preempts to be the Master device.
Procedure
Step 1 Adjust the STP parameters of the switch so that the interface connecting the switch to Router
B can immediately enter the Forwarding after going Up.
After the preceding operations, the backup device does not preempt to be the master device.
Therefore, the fault is rectified.
----End
Summary
VRRP has the following modes:
l Preemption mode: In this mode, if the backup device receives a VRRP packet carrying a
priority lower than the priority of the backup device, the backup device preempts to be the
master device.
l Non-preemption mode: In this mode, the backup device does not preempt to be the master
device.
The non-preemption mode, however, does not mean that the backup device does not become
the master device. After the link between router B and the switch goes Down or Up, the interface

connecting the switch to router B does not enter the Forwarding state immediately. As a result,
VRRP packets are not forwarded in time. Consequently, the VRRP timer times out, VRRP
master/slave switchover occurs, and there are two master devices on the network.
Therefore, when deploying VRRP, fully consider the network environment.

Troubleshooting - Reliability 3 MPLS OAM Troubleshooting
3 MPLS OAM Troubleshooting
About This Chapter
3.1 MPLS OAM Detection Does Not Work at the Source Point
3.2 MPLS OAM Detection Does Not Work at the Sink Point
3.3 OAM Detection Status at the Source Point Is Inconsistent With That at the Sink Point
3.4 MPLS OAM-enabled Devices Cannot Communicate with Each Other

3.1 MPLS OAM Detection Does Not Work at the Source

Point
3.1.1 Common Causes

The MPLS OAM detection status is always Stop at the source point, indicating that MPLS OAM
detection does not work. This fault is commonly caused by one of the following:
l mpls oam ingress enable command is not performed.
l The TE tunnel to be detected by MPLS OAM is not Up.
l No OAM board is selected.

Figure 3-1 Troubleshooting flowchart for the problem that MPLS OAM detection does not work
at the source point
MPLS OAM does
not work at the
source point
No OAM starts Yes

MPLS OAM is After being enabled at
enabled? the source point?
Yes No
Rectify
No the fault on the Yes
TE tunnel is Up? TE tunnel and ensure
the tunnel
Is Up?
Yes No
No Yes
Correct OAM OAM is enabled at the
board is selected? source point?
Yes No
Seek technical
End
support

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 Check that MPLS OAM is enabled at the source point.
l If MPLS OAM is enabled, go to Step 2.
l If MPLS OAM is not enabled, run the mpls oam ingress enable command to enable MPLS
OAM.
NOTE
The mpls oam ingress enable command must be run before MPLS OAM at the source point starts to detect a
TE tunnel.
Step 2 Check that the TE tunnel is Up.

l If the TE tunnel is Up, go to Step 3.
l If the TE tunnel is Down, see MPLS TE Troubleshooting to rectify the fault.
Step 3 Run the display mpls oam ingress tunnel interface-number command to check that an OAM
board is selected. If "--" is displayed in the Oamselect board field, no OAM board is selected.
NOTE
MPLS OAM is supported by the LPUF, LPUK, and LPUN.
l If the OAM board fails to be selected, an OAM-capable board needs to be installed.
l If the OAM board is successfully selected but MPLS OAM detection still does not work, go
to Step 4.
personnel.
Step 5 End.
----End
Relevant Alarms
None.
Relevant Logs
None.

3.2 MPLS OAM Detection Does Not Work at the Sink Point
3.2.1 Common Causes

The MPLS OAM detection status is always Stop, indicating that MPLS OAM detection does
not work at the sink point. Common causes for this fault are as follows:
l MPLS OAM is not enabled.
l MPLS OAM is not enabled after Auto OAM is enabled.
l The TE tunnel to be detected by MPLS OAM is not Up.
l An OAM board fails to be selected.


Figure 3-2 Troubleshooting flowchart for the problem that MPLS OAM detection does not work
at the sink point
MPLS OAM does

not work at the
sink point
Enabled
Auto OAM is Yes at the source point, Yes
enabled? OAM is enabled at the
sink point?
No
No
OAM
starts after being Yes
OAM is enabled? enabled at the source
point?
Yes
Rectify the
No tunnel fault. After the Yes
TE tunnel is Up? tunnel is Up, OAM is
enabled at the sink
point?
Yes
No
Select an Yes
No
Correct OAM board OAM board. OAM is
is selected? enabled at the sink
point?
Yes
No
Seek technical
End
support


Context
NOTE
Procedure
Step 1 Check that Auto OAM is enabled. The sink point can be configured with either Auto OAM or
the mpls oam egress enable command.
l If Auto OAM is enabled, go to Step 3.
l If Auto OAM is not enabled, go to Step 2.
NOTE
By default, if no detection type is specified at the sink point, Auto OAM is enabled. Auto OAM, a Huawei-
proprietary feature, allows the sink point to automatically start OAM detection when OAM is enabled at the
source point.
Step 2 Check that MPLS OAM is enabled at the source point.

l If MPLS OAM is enabled, go to Step 2.
l If MPLS OAM is not enabled, run the mpls oam ingress enable command to enable MPLS
OAM at the source point.
NOTE
The mpls oam ingress enable command must be run before MPLS OAM at the source point starts to detect a
TE tunnel.
Step 3 Check that the TE tunnel is Up.

l If the TE tunnel is Up, go to Step 3.
l If the TE tunnel is Down, see MPLS TE Troubleshooting and rectify the fault.
Step 4 Run the display mpls oam ingress tunnel interface-number command to check that an OAM
board is selected. If "--" is displayed in the Oamselect board field, no OAM board is selected.
l If the OAM board fails to be selected, an OAM-capable board needs to be installed.
l If the OAM board is successfully selected but MPLS OAM detection still does not work, go
to Step 5.
personnel.
Step 6 End.
----End

Relevant Alarms
None.

Relevant Logs
None.
3.3 OAM Detection Status at the Source Point Is Inconsistent

With That at the Sink Point
3.3.1 Common Causes

This fault is commonly caused by the lack of reverse tunnel at the sink point.
Figure 3-3 Troubleshooting flowchart for the fault that the OAM detection status at the source
point is inconsistent with that at the sink point
OAM status at the
source point does
not match that at
the sink point
After a
A backward No Yes
backward tunnel is set up,
tunnel is set up at End
parameters at both ends
the sink point?
are the same?
Yes
No
Seek technical
support
Context
NOTE
Procedure
Step 1 Check that a reverse tunnel is configured at the sink point. MPLS OAM goes Up at the source
point after an Advertisement message sent by the sink point is received by the source point.
OAM at the sink point must be configured with a reverse tunnel so that OAM at the source point
can synchronize the OAM detection status with the sink point.

l If a reverse tunnel is configured, go to Step 3.

l If no reverse tunnel is configured, go to Step 2.
personnel.
Step 3 End.
----End

Relevant Alarms
None.
Relevant Logs
None.
3.4 MPLS OAM-enabled Devices Cannot Communicate

with Each Other
3.4.1 Common Causes

Products from different vendors implement OAM in compliance with different standards (RFC
and ITU standards). As a result, OAM packets at two points are encapsulated in different formats,
causing a communication failure.

Figure 3-4 Troubleshooting flowchart for the problem that MPLS OAM-enabled devices cannot
communicate with each other
Devices cannot
communicate with
each other
ITU No Yes
Two ends have the
encapsulation is same encapsulation End
performed? mode?
Yes
No
Seek technical
support

Context
NOTE
Procedure
Step 1 On one MPLS OAM-enabled device, run the display this command in the MPLS view to check
whether the device is configured with the mpls oam based-itu command.
l If the command has been run, check whether ITU standard is supported on the other device.
If ITU standard is supported, run the mpls oam based-itu command on the other device. By
doing so, both devices implement OAM in compliance with ITU standard. If ITU standard
is not supported, run the undo mpls oam command on this device. By doing so, both devices
implement RFC standard.
l If the command has not been run, go to Step 2.
personnel.
Step 3 End.
----End
Relevant Alarms
None.
Relevant Logs
None.

Troubleshooting - Reliability 4 Y.1731 Troubleshooting
4 Y.1731 Troubleshooting
About This Chapter
This chapter describes common causes of a Y.1731 fault, and provides the corresponding
troubleshooting flowchart, troubleshooting procedure, alarms, and logs.
4.1 Troubleshooting of the Fault that No Single-ended Frame Loss Statistics Are Collected
Though Single-ended Frame Loss Measurement Is Configured for a VLAN
4.2 Troubleshooting of the Fault that No Dual-ended Frame Loss Statistics Are Collected
Though Dual-ended Frame Loss Measurement Is Configured for a VLAN
4.3 Troubleshooting of the Fault that One-way Delay Is Not Collected Though One-way Frame
Delay Measurement Is Configured for a VLAN
This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that one-way delay is not collected though one-way frame delay
measurement is configured for a VLAN.
4.4 Troubleshooting of the Fault that Two-way Delay Is Not Collected Though Two-way Frame
Delay Measurement Is Configured for a VLAN
procedure for the fault that two-way delay is not collected though two-way frame delay
Though Single-ended Frame Loss Measurement Is Configure for a VPLS Network
Though Dual-ended Frame Loss Measurement Is Configure for a VPLS Network
Delay Measurement Is Configured for a VPLS Network
Delay Measurement Is Configured for a VPLS Network
Though Single-ended Frame Loss Measurement Is Configure for a VLL Network

Though Dual-ended Frame Loss Measurement Is Configure for a VLL Network
procedure for the fault that no dual-ended frame loss statistics are collected though dual-ended
frame loss measurement is configured for a VLL network.
Delay Measurement Is Configured for a VLL Network
Delay Measurement Is Configured for a VLL Network

4.1 Troubleshooting of the Fault that No Single-ended

Frame Loss Statistics Are Collected Though Single-ended
Frame Loss Measurement Is Configured for a VLAN
4.1.1 Common Causes

This fault is commonly caused in one of the following situations:
l The service link is faulty.
l The action of displaying single-ended frame loss is not performed on the local MEP.
l LMM reception is not enabled on the remote MEP.
l The direction in which the MEP faces is not outward.
l The remote MEP ID is specified for single-ended frame loss measurement but the local
MEP has not learned MAC address from the remote MEP.
l The remote MAC address is specified for single-ended frame loss measurement but the
specified MAC address is not the MAC address of the remote MEP.

In VLAN networking, no single-ended frame loss statistics are collected though single-ended
frame loss measurement is configured.
Figure 4-1 shows the troubleshooting flowchart.

Figure 4-1 Troubleshooting flowchart for the fault that no single-ended frame loss statistics are
collected though single-ended frame loss measurement is configured for a VLAN
No single-ended frame
loss statistics are collected
though single-ended frame
loss measurement is
configured for a VLAN
Does the service No Check and reconfigure Is fault Yes

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

direction correct? the MEP direction rectified?
No
Yes
Is a RMEP
ID specified for single- No
ended frame loss
measurement?
Has the
Yes
Yes local MEP learned
the MAC address of
the RMEP?
Is the Yes No
specified MAC address
the MAC address of the Check CFM configurations and
remote MEP? ensure that the CC is in the Up
state so that the local MEP can
No learn MAC address of the RMEP
Correct the specified MAC
address, ensuring that is the MAC No Yes
address of the remote MEP Is fault rectified?
Collect debugging Seek technical

Is fault rectified?
No information support
Yes
End

Context
NOTE
Procedure
Step 1 Check that the service link works properly.
Run the display vlan vlan-id verbose command to view the VLAN state field.
l If the VLAN state field in the command output displays Up, go to Step 2.
l If the VLAN state field in the command output does not display Up, check VLAN
configurations. For the correct VLAN configuration, see "VLAN Configuration in the VRP
Configuration Guide - LAN Access and MAN Access.
Step 2 Check that the action of displaying single-ended frame loss is performed on the local MEP.
The single-ended frame loss is collected by the local MEP that sends LMM frames. If the action
of displaying single-ended frame loss is performed on the local MEP, go to Step 3.
Step 3 Check whether the loss-measure single-ended receive command (LMM reception) is
configured on the remote MEP.
Run the display this command in the MD view of the remote MEP to view configuration
information.
l If the loss-measure single-ended receive command is configured in the MD view, go to
Step 4.
l If the loss-measure single-ended receive command is not configured in the MD view, run
the loss-measure single-ended receive command to enable LMM reception on the remote
MEP.
Step 4 Check whether the direction in which the MEP faces is correct.
Run the display cfm mep command on MEPs at both link ends to view the Direction field.
l If the Direction field in the command output displays outward on both MEPs, the direction
in which the MEP faces is correct. Then go to Step 5.
l If the Direction field in the command output does not display outward on both MEPs, the
direction in which the MEP faces is incorrect. Then reconfigure the direction in which the
MEP faces use the command mep mep-id interface interface-type interface-num outward.
Step 5 Check the parameter specified for single-ended frame loss measurement.
If remote-mep mep-id mep-id is specified, run the display cfm remote-mep md md-name
ma ma-name mep-id mep-id command to view the value of the MAC field and check whether
the local MEP has learned the MAC address of the remote MEP.
l If the MAC field is displayed as -, check CFM configurations and ensure that the CC is Up
so that the local MEP can learn the MAC address of the remote MEP.

l If the MAC field is not displayed as -, go to Step 6.
If mac mac-address is specified, check whether the value of mac-address is the MAC address
of the remote MEP.
l If the value of mac-address is the MAC address of the remote MEP, go to Step 6.
l If the value of mac-address is not the MAC address of the remote MEP, correct the specified
MAC address, ensuring that it is the MAC address of the remote MEP.
Step 6 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedures.
l Configuration files, log files, and alarm files of the device.
Step 7 End.
----End

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

Loss Statistics Are Collected Though Dual-ended Frame
Loss Measurement Is Configured for a VLAN
4.2.1 Common Causes

l The remote MEP is not Up.

In VLAN networking, no dual-ended frame loss statistics are collected though dual-ended frame
loss measurement is configured.

Figure 4-2 Troubleshooting flowchart for the fault that no dual-ended frame loss statistics are
collected though dual-ended frame loss measurement is configured for a VLAN
No dual-ended frame loss

statistics are collected
though dual-ended frame
loss measurement is
configured for a VLAN
Check and Yes

No Is fault
Does the service link work reconfigure the
rectified?
properly? service link
No
Yes
Is the MEP No Modify the MEP Is fault Yes

direction is conrrect? direction to outward rectified?
No
Yes
Check CFM
No configurations to Yes
Is the remote MEP Is fault
ensure that the
in the Up state? rectified?
remote MEP is in
the Up state
Yes No
Collect debugging information
Context
NOTE
Procedure

Configuration Guide - LAN Access and MAN Access
MEP faces using the mep mep-id interface interface-type interface-num outward command.
Step 3 Check that the remote MEP is Up.
Run the display cfm remote-mep md md-name ma ma-name mep-id mep-id command on the
local MEP to view the CFM Status field.
l If the CFM Status field in the command output displays Up, go to Step 4.
l If the CFM Status field in the command output does not display Up, check the CFM
configurations.
----End

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

Collected Though One-way Frame Delay Measurement Is
Configured for a VLAN
procedure for the fault that one-way delay is not collected though one-way frame delay
4.3.1 Common Causes

l The action of displaying one-way frame delay measurement is not performed on the remote
MEP.
l The receive command is not configured on the remote MEP.

l The remote MEP ID is specified for one-way frame delay measurement but the local MEP
has not learned MAC address from the remote MEP.
l The remote MAC address is specified for one-way frame delay measurement but the

In VLAN networking, the one-way delay is not collected though one-way frame delay
measurement is configured.

Figure 4-3 Troubleshooting flowchart for the fault that the one-way delay is not collected though
one-way frame delay measurement is configured for a VLAN
No one-way delay is
collected though one-way
frame delay measurement
is configured for a VLAN
Check and
Does the service No Is fault Yes
reconfigure the
link work properly? rectified?
service link
Yes No
Is the action of
No Display one-way Yes
displaying one-way frame Is fault
frame delay on the
delay is performed on the rectified?
local MEP
local MEP?
No
Yes
Check whether the
Is DMM No Receive command
Is fault Yes
reception enabled on the (DMM reception) is
rectified?
remote MEP No
Yes

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

Is fault rectified?
information support
End

Context
NOTE
Procedure
Step 2 Check that the action of displaying one-way delay is performed on the remote MEP.
The one-way delay is collected only by the remote MEP that receives DMM frames but not by
the initiator of one-way frame delay measurement (local MEP). If the action of displaying one-
way delay is performed on the remote MEP, go to Step 3.
Step 3 Check whether the delay-measure one-way receive command is configured on the remote
MEP.
information.
l If the delay-measure one-way receive command is not configured, configure this command.
l If the delay-measure one-way receive command is configured, go to Step 4.
Step 5 Check the parameter specified for one-way frame delay measurement.

of the remote MEP.
----End

None.
4.4 Troubleshooting of the Fault that Two-way Delay Is Not

Collected Though Two-way Frame Delay Measurement Is
Configured for a VLAN
procedure for the fault that two-way delay is not collected though two-way frame delay
4.4.1 Common Causes

l The action of displaying two-way frame delay is not performed on the local MEP.
l Displaying two-way delay is not performed on the local MEP.
l The Receive command (DMM reception) is not configured on the remote MEP.
l The direction in which the MEP faces is not Outward.
l The remote MEP ID is specified for two-way frame delay measurement but the local MEP
l The remote MAC address is specified for two-way frame delay measurement but the

In VLAN networking, the two-way delay is not collected though two-way frame delay

Figure 4-4 Troubleshooting flowchart for the fault that the two-way delay is not collected though
two-way frame delay measurement is configured for a VLAN
No two-way delay is
collected though two-way
is configured for a VLAN
No Check and
Does the service Is fault Yes
reconfigure the
service link
Yes No
Is displaying No Two-way delay

Is fault Yes
two-way delay performed on collected by the local
rectified?
the local MEP? MEP is dispalyed
No
Yes
Check whether the
Receive command
Is DMM reception No (DMM reception) is Is fault Yes
enabled on the remote configured on the rectified?
MEP? remote MEP
No
Yes

No
Yes
Is a RMEP
ended frame loss
measurement?
Has the
No local MEP learned the
Yes MAC address of the
RMEP?
Is the
Yes Yes
the MAC address of the
Check CFM configurations
remote MEP?
address, ensuring that is the MAC
address of the remote MEP No Yes
Is fault rectified?

Is fault rectified?
information support
Yes End

Context
NOTE
Procedure
Step 2 Check that displaying two-way delay is performed on the local MEP.
The two-way delay is collected by the local MEP. If the action of displaying two-way frame
delay is performed on the local MEP, go to Step 3.
Step 3 Check whether the delay-measure two-way receive command is configured on the remote
MEP.
information.
l If the delay-measure two-way receive command is not configured, configure this command.
l If the delay-measure two-way receive command is configured, go to Step 4.
Step 5 Check the parameter specified for two-way frame delay measurement.
of the remote MEP.

----End

None.

Frame Loss Measurement Is Configure for a VPLS Network
4.5.1 Common Causes

l The direction in which the MEP faces does not match the usage scenario.

In VPLS networking, no single-ended frame loss statistics are collected though single-ended

collected though single-ended frame loss measurement is configured for a VPLS network
No single-ended frame loss
loss measurement is
configured for a VPLS

Yes
No
Is the action of
Is fault
rectified?
the local MEP? MEP
No
Yes
Check whether the
Is fault
rectified?
remote MEP
Yes No

Yes No
Is a RMEP
ended frame loss
measurement?
Has the
Yes
local MEP learned
Yes the MAC address of
the RMEP?
Is the
Yes No
No state so that the local MEP can
learn MAC address of the RMEP
address, ensuring that is the MAC No Yes

Is fault rectified?
Yes
End

Context
NOTE
Procedure
Run the display vsi vsi-name verbose command to view the VSI state field.
l If the VSI state field in the command output displays Up, go to Step 2.
l If the VSI state field in the command output does not display Up, check VSI configurations.
For the correct VSI configuration, see "VPLS Configuration in the VRP Configuration Guide
- VPN.
NOTE
In Y.1731, trunk interfaces cannot be used as public network-side PW interfaces.
Step 3 Check that the loss-measure single-ended receive command is configured on the remote MEP.
information.
l If the command output shows that the loss-measure single-ended receive command has
been configured in the MD view, go to Step 4.
l If the command output shows that the loss-measure single-ended receive command has not
been configured in the MD view, proceed to the following steps:
If single-ended frame loss measurement is configured at the PW side, run the loss-
measure single-ended receive peer-ip peer-ip vc-id vd-id to enable LMM reception.
If single-ended frame loss measurement is configured at the AC side , run the loss-
measure single-ended receive command to enable LMM reception.
l If single-ended frame loss measurement is configured at the PW side, the direction in which
the MEP faces must be inward. If the Direction field in the command output displays
inward on both MEPs, the direction in which the MEP faces is correct. Then go to Step 5.
If the Direction field in the command output does not display inward, run the mep mep-id
interface interface-type interface-num inward command to reconfigure the direction in
which the MEP faces.
l If single-ended frame loss measurement is configured at the AC side, the direction in which
the MEP faces must be outward. If the Direction field in the command output displays
outward on both MEPs, the direction in which the MEP faces is correct. Then go to Step

5. If the Direction field in the command output does not display outward, run the mep mep-
id interface interface-type interface-num outward command to reconfigure the direction in
of the remote MEP.
----End

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

Loss Statistics Are Collected Though Dual-ended Frame
Loss Measurement Is Configure for a VPLS Network
4.6.1 Common Causes


In VPLS networking, no dual-ended frame loss statistics are collected though dual-ended frame

collected though dual-ended frame loss measurement is configured for a VPLS network
loss measurement is
configured for a VPLS

Yes No
Is the MEP No Correctly configure the Is fault Yes

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

- VPN.
NOTE
the MEP faces must be Inward. If the Direction field in the command output displays
Inward on both MEPs, the direction in which the MEP faces is correct. Then go to Step 3.
If the Direction field in the command output does not display Inward, run the mep mep-
id interface interface-type interface-num inward command to reconfigure the direction in
configurations.
----End

None.

Configured for a VPLS Network

4.7.1 Common Causes

l The action of displaying single-ended frame loss is not performed on the remote MEP.
l Displaying one-way delay is not performed on the remote MEP.
l 1DM reception is not enabled on the remote MEP.
l The remote MAC address is specified for one-way frame delay measurement but the

In VPLS networking, the one-way delay is not collected though one-way frame delay

Figure 4-7 Troubleshooting flowchart for the fault that the one-way delay is not collected though
one-way frame delay measurement is configured for a VPLS network
No one-way delay is
is configured for a VPLS
Check and
reconfigure the
service link
Yes No
Is the action of
frame delay on the
local MEP
local MEP?
No
Yes
Check whether the
Is fault Yes
rectified?
remote MEP No
Yes
Yes No
Is a RMEP
ID Specified for single- No
ended frame loss
measurement?
Has the local
address of the
RMEP?
Is the
Yes
Yes
MAC address of the remote
MEP? Check CFM configurations
address of the remote MEP No
Yes
Yes Is fault rectified?

Is fault rectified?
information support
End

Context
NOTE
Procedure
- VPN.
Step 2 Check that the action of displaying one-way frame delay is performed on the remote MEP.
The one-way frame delay is collected by the remote MEP that sends DMM frames. If the action
of displaying one-way frame delay is performed on the remote MEP, go to Step 3.
Step 3 Check whether the delay-measure one-way receive command (DMM reception) is configured
on the remote MEP.
information.
l If the receive command is configured in the MD view, go to Step 4.
l If the receive command is not configured in the MD view, proceed to the following steps:
If one-way frame delay measurement is configured at the PW sided , run the delay-
measure one-way receive peer-ip peer-ip vc-id vd-id command to enable DMM
reception.
If one-way frame delay measurement is configured at the AC side, run the delay-measure
one-way receive command to enable DMM reception.
l If one-way frame delay measurement is configured at the PW side, the direction in which
If the Direction field in the command output does not display inward, reconfigure the
direction in which the MEP faces.
l If one-way frame delay measurement is configured at the AC side, the direction in which the
MEP faces must be outward. If the Direction field in the command output displays
5. If the Direction field in the command output does not display outward, reconfigure the
direction in which the MEP faces.

of the remote MEP.
----End

None.
4.8 Troubleshooting of the Fault that Two-way Delay Is Not

Collected Though Two-way Frame Delay Measurement Is
Configured for a VPLS Network
4.8.1 Common Causes

l DMM reception is not enabled on the remote MEP.
l the direction in which the MEP faces does not match the usage scenario.
l The remote MAC address is specified for two-way frame delay measurement but the

In VPLS networking, the two-way delay is not collected though two-way frame delay

Figure 4-8 Troubleshooting flowchart for the fault that the two-way delay is not collected though
two-way frame delay measurement is configured for a VPLS network
No two-way delay is
is configured for a VPLS
No Check and
reconfigure the
service link
Yes No

Is fault Yes
rectified?
No
Yes
Check whether the
No Receive command Yes
Is DMM reception Is fault
(DMM reception) is
enabled on the remote rectified?
configured on the
MEP?
remote MEP No
Yes

Yes No
Is a RMEP
ended frame loss
measurement?
Has the
Yes
MAC address of the
RMEP?
Is the
specified MAC address Yes Yes
remote MEP?
Is fault rectified?

Is fault rectified?
Yes End

Context
NOTE
Procedure
- VPN.
Step 2 Check that the action of displaying two-way frame delay is performed on the local MEP.
The two-way frame delay is collected by the local MEP that sends LMM frames. If the action
of displaying two-way frame delay is performed on the local MEP, go to Step 3.
Step 3 Check that the delay-measure two-way receive command is configured on the remote MEP.
information.
l If the command output shows that the delay-measure two-way receive command has been
configured in the MD view, go to Step 4.
l If the command output shows that the delay-measure two-way receive command has not
been configured in the MD view, proceed to the following steps:
If two-way frame delay measurement is configured at the PW sided, run the delay-
measure two-way receive peer-ip peer-ip vc-id vd-id command to enable DMM
reception.
If two-way frame delay measurement is configured at the AC side, run the delay-measure
two-way receive command to enable DMM reception.
l If two-way frame delay measurement is configured at the PW side, the direction in which
direction in which the MEP faces using the mep mep-id interface interface-type interface-
num inward command.
l If two-way frame delay measurement is configured at the AC side, the direction in which the

num outward command.
of the remote MEP.
----End

None.

Frame Loss Measurement Is Configure for a VLL Network
4.9.1 Common Causes



In VLL networking, no single-ended frame loss statistics are collected though single-ended

collected though single-ended frame loss measurement is configured for a VLL network
No single-ended frame loss
loss measurement is
configured for a VLL

No
Yes
Is the action of
Is fault
rectified?
the local MEP? MEP
No
Yes
Check whether the
Is fault
rectified?
remote MEP No
Yes

Yes No
Is a RMEP ID
Specified for single-ended No
frame loss
measurement?
Has the
Yes
local MEP learned
Yes the MAC address of
the RMEP?
Is the
Yes No
No state so that the local MEP can
learn MAC address of the RMEP
No Yes

Is fault rectified?
Yes
End

Context
NOTE
Procedure
Run the display mpls l2vc command to view the session state, AC status, and VC state fields.
l If the three fields in the command output all display Up, go to Step 2.
l If any of the three fields in the command output does not display Up, check VLL
configurations. For the correct VLL configuration, see "VLL Configuration in the VRP
Configuration Guide - VPN.
NOTE
Step 3 Check that the loss-measure single-ended receive command is configured on the remote MEP.
information.
l If the command output shows that the loss-measure single-ended receive command has
been configured in the MD view, go to Step 4.
l If the command output shows that the loss-measure single-ended receive command has not
been configured in the MD view, run the loss-measure single-ended receive command to
enable LMM reception.
If the Direction field in the command output does not display inward, run the mep mep-id
interface interface-type interface-num inward command to reconfigure the direction in

of the remote MEP.
----End

None.
4.10 Troubleshooting of the Fault that No Dual-ended

Frame Loss Statistics Are Collected Though Dual-ended
Frame Loss Measurement Is Configure for a VLL Network
procedure for the fault that no dual-ended frame loss statistics are collected though dual-ended
frame loss measurement is configured for a VLL network.
4.10.1 Common Causes


In VLL networking, no dual-ended frame loss statistics are collected though dual-ended frame

collected though dual-ended frame loss measurement is configured for a VLL network

loss measurement is
configured for a VLL
No Check and
reconfigure the
service link
Yes No
Is the MEP No Correctly configure the Is fault Yes

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

Procedure
NOTE
Step 2 Check the direction in which the MEP faces.
the MEP faces must be Inward. If the Direction field in the command output displays
Inward on both MEPs, the direction in which the MEP faces is correct. Then go to Step 3.
If the Direction field in the command output does not display Inward, run the mep mep-
id interface interface-type interface-num inward command to reconfigure the direction in
configurations.
----End

None.


Configured for a VLL Network

l The action of displaying one-way frame delay is not performed on the local MEP.
l 1DM reception is not enabled on the remote MEP.

In VLL networking, the one-way delay is not collected though one-way frame delay

Figure 4-11 Troubleshooting flowchart for the fault that the one-way delay is not collected
though one-way frame delay measurement is configured for a VLL network
No one-way delay is
is configured for a VLL
Check and
reconfigure the
service link
Yes No
Is the action of
frame delay on the
local MEP
local MEP?
No
Yes
Check whether the
Is fault Yes
rectified?
remote MEP No
Yes
Yes No
Is a RMEP No
ID specified for single-ended
frame loss measurement?
Has the local

address of the
Is the
Yes RMEP?
MAC address of the remote
Yes
MEP?
No and ensure that the CC is in
the Up state so that the local
Correct the specified MAC MEP can learn MAC address
of the RMEP
address of the remote MEP
Yes No
Yes
Is fault rectified?

Is fault rectified?
information support
End

Context
NOTE
Procedure
Step 2 Check that the action of displaying one-way frame delay is performed on the remote MEP.
The one-way frame delay is collected by the local MEP that sends DMM frames. If the action
of displaying one-way frame delay is performed on the remote MEP, go to Step 3.
Step 3 Check whether the delay-measure one-way receive command (DMM reception) is configured
on the remote MEP.
information.
l If the delay-measure one-way receive command is configured in the MD view, go to Step
4.
l If the delay-measure one-way receive command is not configured in the MD view, run the
delay-measure one-way receive command to enable DMM reception.
l If one-way frame delay measurement is configured at the PW side, the direction in which
direction in which the MEP faces by the mep mep-id interface interface-type interface-
num inward command.
l If one-way frame delay measurement is configured at the AC side, the direction in which the
direction in which the MEP faces by the mep mep-id interface interface-type interface-

of the remote MEP.
----End

None.
4.12 Troubleshooting of the Fault that Two-way Delay Is

Not Collected Though Two-way Frame Delay Measurement
Is Configured for a VLL Network

l DMM reception is not enabled on the remote MEP.

In VLL networking, the two-way delay is not collected though two-way frame delay

Figure 4-12 Troubleshooting flowchart for the fault that the two-way delay is not collected
though two-way frame delay measurement is configured for a VLL network
No two-way delay is
is configured for a VLL
No Check and
reconfigure the
service link
Yes No

Is fault Yes
rectified?
No
Yes
Check whether the
No Receive command Yes
Is DMM reception Is fault
(DMM reception) is
enabled on the remote rectified?
configured on the
MEP?
remote MEP No
Yes

Yes No
Is a RMEP
ended frame loss
measurement?
Has the
Yes
MAC address of the
Is the RMEP?
specified MAC address Yes Yes
remote MEP?
Is fault rectified?

Is fault rectified?
Yes
End

Context
NOTE
Procedure
Step 2 Check that the action of displaying two-way frame delay is performed on the local MEP.
The two-way frame delay is collected by the local MEP that sends DMM frames. If the action
of displaying two-way frame delay is performed on the local MEP, go to Step 3.
Step 3 Check that the delay-measure two-way receive command is configured on the remote MEP.
information.
l If the command output shows that the delay-measure two-way receive command has been
configured in the MD view, go to Step 4.
l If the command output shows that the delay-measure two-way receive command has not
been configured in the MD view, run the delay-measure two-way receive command to
enable DMM reception.
l If two-way frame delay measurement is configured at the PW side, the direction in which
direction in which the MEP faces using the display cfm remote-mep md md-name ma ma-
name mep-id mep-id inward command.
l If two-way frame delay measurement is configured at the AC side, the direction in which the

of the remote MEP.
----End

None.

Troubleshooting - Reliability 5 MPLS-TP OAM Troubleshooting
5 MPLS-TP OAM Troubleshooting
About This Chapter
This chapter describes common causes of MPLS-TP OAM faults, and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, logs, and
commands.
5.1 ME Cannot Go Up
procedure for the fault that an ME cannot go Up.

5.1 ME Cannot Go Up
procedure for the fault that an ME cannot go Up.
5.1.1 Common Causes

l The link is faulty.
l The ME configuration is incorrect.
l The MEG configuration is incorrect.
l The intervals between sending CCMs on both ends are inconsistent.
l The CCM sending function is disabled.
l The CCM receiving function is disabled.


Figure 5-1 Troubleshooting flowchart for a failure that an ME cannot go Up
ME cannot be Up
No Yes
Check whether the Change the ME Is the fault
ME configuration is configuration rectified?
correct
No
Yes
No Yes
Check whether the Change the MEG Is the fault
MEG configuration configuration rectified?
is correct
No
Yes
Check
whether the periods No Yes
Change them to the Is the fault
for sending CCMs same value rectified?
are the same
No
Yes
No Yes
Check whether Is the fault
CCM sending is Enable CCM sending
rectified?
enabled
No
Yes
No Yes
Check whether Enable CCM receiving Is the fault
CCM receiving is rectified?
enabled
No
Yes
Ask for technical support End

NOTE
Procedure
Step 1 Verify the fiber connection.
l If the fiber is disconnected, see "Physical Interconnection Troubleshooting" for details
about how to troubleshoot the fiber connection fault.

l If the fiber is connected securely, go to Step 2.
Step 2 Run the display mpls-tp oam meg command on the ingress and egress to verify that the ingress
has ME and MEG information consistent with that on the egress.
l If inconsistency occurs, change the configuration on one end to ensure that the ingress has
ME and MEG information consistent with that on the egress. If the fault persists, go to
Step 3.
l If the ingress has ME and MEG information consistent with that on the egress, go to Step
3.
Step 3 Run the display mpls-tp oam meg command on the ingress and egress to view the CC
configuration. If there is any inconsistency, select one command in the following situations:
l If the intervals at which CCMs are sent are different, then run the cc interval command to
set the same interval for the two ends.
l If the ingress or egress is disabled from sending CCMs, run the cc send enable command
to enable it to send CCMs.
l If the ingress or egress is disabled from receiving CCMs, run the cc receive enable
command to enable it to receive CCMs.
l If the fault persists, go to Step 4.
l Results of the preceding troubleshooting procedures
l Configuration files, log files, and alarm files of the device
----End
Relevant Alarms
MPLS-TPOAM/5/OID [OID] loss of continuity alarm start. (MegId=[MegId],MeType=
[MeType],MeDirection=[MeDirection],IfName=[IfName],PeerIP=[PeerIP],VcId=
[VcId],VcType=[VcType],RemoteIp=[RemoteIp],Ttl=[Ttl],MepId=[MepId],RemoteMepId=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected MEG alarm end. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected MEP alarm start. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected MEP alarm end. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected period alarm start. (MegId=[MegId],MeType=
[RemoteMepId])
MPLS-TPOAM/5/OID [OID] unexpected period alarm end. (MegId=[MegId],MeType=
[RemoteMepId])

Relevant Logs
None

Troubleshooting - Reliability 6 Multi-Device Backup Troubleshooting
6 Multi-Device Backup Troubleshooting
About This Chapter
6.1 User Information Fails to Be Backed Up
6.2 A User Fails to Log In Through the Backup Device
6.3 After IP Redirection Protection Tunnels Are Deployed for Public Network Users, the Return
Traffic Is Interrupted
6.4 After the Tunnel Policy Is Deployed for Public Network Users, the Return Traffic Is
Interrupted
6.5 Return Traffic Is Interrupted After the VPN Tunnel Is Deployed for Private Network Users
6.6 Multicast Entries Cannot Be Backed Up to the Backup Device
6.7 Automatically Advertising Route Cost Values Fails

This section describes how to troubleshoot the problem that a device fails to automatically
advertise the cost value of a network segment route of an address pool.
6.8 User Traffic Imbalance Based on Odd and Even MAC Addresses
This section describes how to troubleshoot user traffic imbalance based on odd and even MAC
addresses.
6.9 NAT Troubleshooting in Dual-System Backup for Distributed NAT Services

This section describes the flow and procedure for troubleshooting NAT services after a master-
slave BRAS switchover in dual-system backup for distributed NAT services.
6.10 Troubleshooting Cases

6.1 User Information Fails to Be Backed Up
6.1.1 Common Causes

l No RBS is configured in the RBP, or an RBS is incorrectly configured.

l The source IP addresses and peer IP addresses are incorrectly configured on the master and
slave devices or the TCP port is incorrectly configured.
l The peer IP addresses of the master and slave RBSs cannot be pinged.

An RUI entry is generated on the primary device, after the user logs in. The RUI entry, however,
is not backed up the backup device. In this case, you can troubleshoot this fault according to the
following troubleshooting flowchart.

Figure 6-1 Troubleshooting flowchart for the user information backup failure
RUI user entries are

generated on the primary
device rather than the
secondary device
Whether the Whether the

No TCP port numbers Yes Yes
RBS connection status on Whether the peer IP
the primary and secondary corresponding to the IP addresses can ping
devices is Conn- addresses are each other?
-ected? the same?
No No No
Modify the RBS

configuration
Check link faults to ensure
that the peer IP addresses of
the RBSs on the primary and
secondary devices can ping
each other
Whether the
Yes No
RBS connection
status on the primary
and secondary devices
is Connected? No
Problem solved?
Check whether an RBS

is configured on the RBP Yes
Yes
No
Configure an RBS on the RBP

and request the user to log in
again
Problem solved? Technical support
No
Yes
End
Procedure
Step 1 Check the RBS status of the primary and backup devices.

Run the display remote-backup-service command to view the status of the RBS.
l If the status of the RBS is "connected", go to step 2.

l If not, go to step 3.
Step 2 Check whether an RBS is configured on the RBP.
Run the display remote-backup-profile command to check whether an RBS is configured on

the RBP and whether the RBS configuration is correct.
l If no RBS is correctly configured, reconfigure the RBS and request the user to log in again.
If the fault persists, contact Huawei technical support personnel.
l If an RBS is correctly configured, contact Huawei technical support personnel.
Step 3 Check whether the peer IP address of the primary device corresponds to the source IP address
of the secondary device and whether the TCP port numbers on the primary and backup devices
are the same.
l If the RBS configurations are inconsistent, modify the RBS configuration and perform step
1 again.
l If the RBS configurations are consistent, go to step 4.
Step 4 Check whether the peer IP addresses on the primary and backup RBSs can ping each other.
l If the peer IP address can be pinged, contact Huawei technical support personnel.
l If the peer IP address cannot be pinged, check the route configuration or the link. If the fault
persists, contact Huawei technical support personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.2 A User Fails to Log In Through the Backup Device
6.2.1 Common Causes

l The RBP is not applied to the relevant BRAS interface.

l The backup IDs in the RBPs on the master and slave devices are different.
l The device is incorrectly configured.


After the user logs in to the primary device, information about the user is backed up to the backup
device and the RUI user entry is generated on the backup device. The user, however, fails to log
in to the backup device.
Figure 6-2 Troubleshooting flowchart for the failure of logging in through the backup device
Users cannot log in to

the secondary device
although RUI user entries
are generated
Whether RBP Bind the RBP to the

No
is bound to the BRAS BRAS interface on the
interface on the secondary
secondary device
device?
Yes
No
Check whether the Configure the same backup ID
backup IDs are the and log in the user again
same
Yes
Check the BRAS No

configuration on the Technical support
backup device
Yes
Modify Configuration of
BRAS on the
backup device
No
Problem solved?
Yes
End

Procedure
Step 1 Check whether the RBP is configured on the BRAS interface of the backup device.
Run the display remote-backup-profile command to check whether a corresponding BRAS

interface is bound to the RBP.
l If yes, go to step 2.
l If not, enter the BRAS interface view and run the remote-backup-profile command to
configure RBP on the interface. If the fault persists, go to step 2.
Step 2 Check whether the backup IDs configured for the RBPs of the primary and backup devices are
the same.
Run the display remote-backup-profile command to check whether the backup IDs configured
for the RBPs of the primary and backup devices are the same.
l If not, run the backup-id id remote-backup-service name command in the RBP view to
configure the same backup ID. If the fault persists, go to step 3.
Step 3 Check whether the BRAS configuration on the backup device is correct.
For the method of check the BRAS configuration on the backup device, refer to the
Troubleshooting-User Access.
l If the BRAS configuration is incorrect, modify the BRAS configuration. If the fault persists,
contact Huawei technical support personnel.
l If the BRAS configuration is correct, contact Huawei technical support personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.3 After IP Redirection Protection Tunnels Are Deployed

for Public Network Users, the Return Traffic Is Interrupted
6.3.1 Common Causes


l There is no host route.

l The device is currently in the master state.
l No IP redirection tunnel is configured.
l The IP redirection tunnel is in the Down state.
l There is no backup route for the current user.

After an IP redirection tunnel for public network users is configured, the user return traffic is
interrupted. You can troubleshoot the fault as shown in Figure 6-3.

Figure 6-3 Troubleshooting flowchart for the failure of an IP redirection tunnel for public
network users
User return traffic is

interrupted after IP
redirection tunnel is Technical
configured support
Yes
Check whether No No Yes

Whether users are User goes online Problem
the user route again
on line solved?
exists
Yes No
The current No Check whether Yes Yes Whether the No

Whether the
device is the an IP redirection user backup
Tunnel is Up
primary one? tunnel is config- path exists
-ured
Yes
No No
Yes
Can the Whether a Yes
Yes
Configure a tunnel peer IP correct outbound
tunnel address be interface is
pinged? specified
No No
Yes No Configure the IP

Configure a
address or the
Problem solved? correctoutbound
loopback interface
interface
address
No No
Problem solved Problem solved?
Yes Yes
Yes
No Deploy a direct line No Whether the
Problem solved? and set up the tunnel tunnel is set up on
on the direct line the direct link
Yes
Technical
support
End
Procedure
Step 1 Check whether the user route exists.
You can run the display fib command to check whether the user route exists.

l If the user route does not exist, check whether the user is online.
If the user is offline, log on the user.
If the user is online but the user route does not exist, contact Huawei technical support
personnel.
l If the user route exists, go to step 2.
Step 2 Check whether the current device is the primary device.
You can run the display remote-backup-profile command to view the status of the current
device.
l If the current device is the primary one, it indicates that the primary path of the user fails. In
this case, refer to the Troubleshooting-User Access.
l If the current device is the secondary one, go to step 3.
Step 3 Check whether an IP redirection tunnel is configured.
You can run the display remote-backup-service command to check whether an IP redirection
tunnel is configured on the RBS of the interface through which the user goes online.
l If no IP redirection tunnel is configured, run the protect redirect ip-nexthop ip-address

interface interface-type interface-number command in the RBS view to configure an IP
redirection tunnel.
l If an IP redirection tunnel is configured, go to step 4.
Step 4 Check whether the IP redirection tunnel is Up.
You can run the display remote-backup-service command to check whether the current tunnel
is Up.
l If the current tunnel is not Up, you can ping the next hop address configured for the tunnel.
If the next hop address cannot be pinged, check whether the IP address of the interface
or the Loopback interface learnt through IGP.
If the next hop address can be pinged but the tunnel is still not Up, check whether the
specified outbound interface is correct. If the specified outbound interface is correct but
the fault persists, contact Huawei technical support personnel.
l If the current tunnel is Up. contact Huawei technical support personnel.
Step 5 Check whether the backup user route exists.
You can run the display fib command to check whether backup user route exists.
l If the backup route exists, check whether the IP redirection tunnel is deployed on the direct
line between the primary and secondary devices.
If no direct line is available, deploy the tunnel on the direct line.
If a direct line is available and the IP redirection tunnel is deployed on the direct line,
contact Huawei technical support personnel.
l If the route does not exist, go to step 5.
----End

Relevant Alarms
None.
Relevant Logs
None.
6.4 After the Tunnel Policy Is Deployed for Public Network

Users, the Return Traffic Is Interrupted
6.4.1 Common Causes


l No protection tunnel is configured on the RBS.
l The tunnel is currently in the Down state.

After an IP redirection tunnel for public network users is configured, the user return traffic is
interrupted. Then, you can locate the fault by referring to the following troubleshooting
flowchart.

Figure 6-4 Troubleshooting flowchart for the failure of a tunnel-policy tunnel for public network
users
User return traffic is

interrupted after
tunnel-policy tunnel Technical
is configured support
Yes
Check whether No Whether users

No User goes Problem
Yes
the user route are on line. online solved?
exists
Yes No
Whether a
The current No protection tunnel Yes Whether the Yes
device is the
is configured tunnel is Up
primary one?
for RBS
Yes No No
Whether Whether a
Configure a tunnel Tunnel-policy is Yes correct outbound Yes
properly interface is
configured specified
No No No
Yes Problem
solved? Configure Tunnel- Configure a correct
policy outbound interface
No No
Problem solved? Problem solved?
Yes Yes
Technical
support
End
Procedure
Step 1 Check whether the user route exists.
You can run the display fib command to check whether the user route exists.
l If the user route does not exist, check whether the user is online.
If the user is offline, log on the user.

If the user is online but the user route does not exist, refer to the Troubleshooting-User
Access.
Step 2 Check whether the current device is the primary device.
device.
l If the current device is the primary one, it indicates that the primary path of the user fails. In
l If the current device is the secondary one, go to step 3.
Step 3 Check whether there is a protection tunnel on the RBS.
You can run the display remote-backup-service command to check whether a tunnel-policy
tunnel is configured on the RBS of the interface through which the user goes online.
l If no tunnel policy tunnel is configured, configure a tunnel policy globally. Then, run the
protect tnl-policy policy-name peer-ip ip-address interface interface-type interface-
number command in the RBS view to configure a protection tunnel. Note that the value of
policy-name must be a globally existing tunnel policy.
l If a tunnel policy tunnel is configured, go to step 4.
Step 4 Check whether the status of the current interfaces is Up.
is Up.
l If not, check the configuration of the tunnel policy.

If the configuration is correct, check whether the outbound interface that is specified or
automatically selected is correct.
If the configuration is incorrect, reconfigure the tunnel policy.
l If the tunnel is Up, contact Huawei technical support personnel.
----End
Relevant Alarms
None.
Relevant Logs
None.
6.5 Return Traffic Is Interrupted After the VPN Tunnel Is

Deployed for Private Network Users

6.5.1 Common Causes

l No VPN tunnel is configured on the RBS.
l The tunnel is currently in the Down state.

Figure 6-5 Troubleshooting flowchart for MPLS VPN
User return traffic
is interrupted after
VPN tunnel is
configured
Check whether No Yes

Whether users No User goes
the user route online again Problem solved?
are on line.
exists.
Yes Yes No
Problem
solved?
Whether a
The current No Yes
VPN tunnel is Whether the Yes
device is the
configured for tunnel is Up
primary one?
the RBS
Yes No No
Whether a
Configure a tunnel Whether the Yes correct outbound Yes
VPN is correctly
interface is
configured
specified
Yes No No No
Problem
solved? Configure a correct
Configure VPN
outbound interface
Problem No No
Problem
solved? solved?
Yes Yes
Technical
support
End

Procedure
Step 1 Check that the user private network route exists.
You can run the display fib command to check whether the user private network route exists.
l If the route does not exist, check whether the user is online.
If the user is offline, request the user to log on.
If the user is online but the route does not exist, refer to the Troubleshooting-User
Access.
Step 2 Check that the current device is the primary device.
device.
l If the current device is in primary state, it indicates that the primary path of the user fails. In
l If the current device is in secondary state, go to step 3.
Step 3 Check that there is a VPN tunnel on the RBS.
You can run the display remote-backup-service command to check whether a VPN tunnel is
configured on the RBS of the interface through which the user goes online.
l If not, configure a VPN instance globally and check whether a VPN is set up for Router A,
Router B, and RouterC. Then, run the protect ip-vpn-instance vpn-instance-name peer-ip
ip-address interface interface-type interface-number command in the RBS view to configure
a tunnel. Note that the specified vpn-instance-name must correspond to a globally existing
VPN instance.
Step 4 Check that the status of the current interfaces is Up.
is Up.
l If not, check the VPN configuration.

If the configuration is correct, check whether the outbound interface that is specified or
automatically selected is correct.
If the configuration is incorrect, reconfigure the VPN.
l If the tunnel is Up, contact Huawei technical support personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.
6.6 Multicast Entries Cannot Be Backed Up to the Backup

Device
6.6.1 Common Causes

This fault is commonly caused by one of the following reasons:
l The multicast hot backup function is disabled.

l In a multicast VPN, the VPN names on the master and backup devices are different.
l No profile is bound to the interface of the master or backup device.
l RBP status on the master or backup device is incorrect.


Figure 6-6 Troubleshooting flowchart for the problem that multicast entries cannot be backed
up to the backup device
Multicast entries
cannot be backed
up to the backup
device
Is the multicast hot No Is the fault No

backup function Enable the multicast hot
rectified?
enabled? backup function remotely
Yes No
Are the
No Configure the master and Yes
names of the VPNs Is the fault
bound to the master and backup devices to have rectified?
backup devices the the same VPN name
same?
Yes No
Are the Yes

RBPs bound to the No Bind the RBPs to the Is the fault
interfaces on the master
and backup devices? interfaces rectified?
Yes No
Check the multi-device

Is the configurations on the Yes
status of the RBPs on the No master and backup devices.
If the configuration on either
Is the fault
master and backup rectified?
devices correct? device is incorrect, modify
the configuration for the
device
Yes No
Contact Huawei
technical End
engineers

NOTE
Saving the results of each troubleshooting step is recommended. If troubleshooting fails to rectify the fault,
you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that the multicast hot backup function is enabled.
Run the display this command in the remote backup profile (RBP) view to check whether the
multicast hot backup function is enabled. If the following information is displayed, the multicast
hot backup function is enabled.

remote-backup-profile profile profile-name

service-type multicast
l If the multicast hot backup function is disabled, run the service-type multicast command to
enable the remote backup function for multicast services.
l If the multicast hot backup function has been enabled, go to Step 2.
Step 2 Check that the VPN names bound to the master and backup devices are the same.
Run the display this command in the main user access interface views on the master and backup
devices to check whether the multicast VPN names on the master and backup devices are the
same.
l If the multicast VPN names on the master and backup devices are different, run the multicast
binding vpn-instance vpn-instance-name command to configure the two devices to have
the same multicast VPN name.
l If the multicast VPN names on the master and backup devices are the same, go to Step 3.
Step 3 Check that the RBPs have been bound to the interfaces on the master and backup devices.
Run the display this command in the user access interface views on the master and backup
devices to check whether the RBPs have been bound to the interfaces. If the following
information is displayed, the RBPs have been bound to the interfaces.
interface GigabitEthernet2/1/0.1
remote-backup-profile profile1
bas
l If the RBPs are not bound to the interfaces, run the remote-backup-profile profile-name
command in the interface views to bind them to the interfaces.
l If the RBPs have been bound to the interfaces, go to Step 4.
Step 4 Check that the RBPs on the master and backup devices work properly.
Run the display remote-backup-profile profile-name command in the system views of the
master and backup devices to check whether the RBP on the master device is in the Master state,
and the RBP on the backup device is in the Slave state.
l If the RBP status on the master device or the backup device is incorrect, check whether the
multi-device backup configuration is correct. If any problem is found out, see the chapter
"Configuring Multi-device Backup" in the Configuration Guide-Reliability.
l If the status of the master and backup devices are incorrect, go to Step 5.
----End
Relevant Alarms
None

Relevant Logs
None
6.7 Automatically Advertising Route Cost Values Fails

This section describes how to troubleshoot the problem that a device fails to automatically
advertise the cost value of a network segment route of an address pool.
6.7.1 Common Causes

l A device is disabled from automatically updating the cost value of the network segment
route of an address pool.
l An address pool is not bound to the RBP.
l Tunnel status is Up.

If the function that enables a device to automatically advertise route cost values cannot take
effect, follow the troubleshooting procedures shown in Figure 6-7.
Figure 6-7 Failure in automatically advertising route cost values

Automatically advertising
route costs fails to take
effect
Automatically No Enable the function Yes

advertising route that automatically Is fault rectified?
costs is enabled? advertises route costs
No
Yes
No Bind an address pool Yes

An address pool is Is fault rectified?
bound to an RBP? to an RBP
No
Yes
No Ensure that the Yes

Tunnel goes Down? Is fault rectified?
tunnel goes Down
No
Yes
Seek technical
support
End

Context
NOTE
Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
Procedure
Step 1 Check that a device is enabled to automatically advertise the cost value of a network segment
route of an address pool.
Run the display current-configuration command in the system view. Check whether the peer-
backup route-cost auto-advertising command is displayed.
l If this command is not displayed, the function is disabled. Run the peer-backup route-cost
auto-advertising command in the system view to enable this function.
l If this command is displayed but the fault persists, go to step 2.
Step 2 Check that an address pool is bound to the RBP.
Run the display this command in the RBP view. Check whether the ip-pool pool-name
command is displayed.
l If this command is not displayed, no address pool is bound to the RBP. Run the ip-pool pool-
name command in the RBP view to bind an address pool to the RBP.
l If this command is displayed but the fault persists, go to step 3.
Step 3 Check that the tunnel is Down.
Run the display remote-backup-service service-name command in the system or user view.
Check whether the Tunnel-state field displays DOWN.
l If the tunnel is Down, go to step 4.

l If the tunnel is Up, the function that enables a device to automatically advertise the cost value
of the network segment route of an address pool cannot take effect.
----End
Relevant Alarms
None

Relevant Logs
None
6.8 User Traffic Imbalance Based on Odd and Even MAC

Addresses
This section describes how to troubleshoot user traffic imbalance based on odd and even MAC
addresses.
6.8.1 Common Causes

l VRRP priority values are set incorrectly.

l An address pool is incorrectly bound to two VRRP devices that back up each other in an
AAA domain.

If user traffic imbalance occurs, follow the troubleshooting procedures shown in Figure 6-8.
Figure 6-8 User traffic imbalance

User traffic cannot
be load-balanced
Reduce a VRRP
Upstream No priority value to No
No RBP is the master in Is fault Yes
traffic is load- ensure that RBP
two VRRP backup rectified?
balanced? is the master in
groups?
both groups
Yes Seek technical

support
Two Set two address
Address pools are pools on the
Downstream No No master and bacup Is fault Yes
set on the master and
traffic is load- devices in rectified?
backup in opposite
balanced? opposite
sequences?
sequences
No
Yes
Seek technical
support
End

Context
NOTE
Procedure
Step 1 Check that upstream or downstream user traffic is load-balanced.
Run the display interface brief command to view the InUti and OutUti columns. Check
whether the upstream or downstream user traffic is load-balanced.
l If upstream user traffic is not load-balanced, go to step 2.

l If downstream user traffic is not load-balanced, go to step 3.
Step 2 Check whether VRRP devices bound to the RBP are in the Master state.
Run the display remote-backup-profile command to check the status of each device.
l If one VRRP device is in the Master state and the other is in the Slave state, go to step 4.
l If both devices are in the Master state, run the vrrp vrid virtual-router-id priority priority-
value command on one device to reduce the VRRP priority value.
Step 3 Check that address pools are correctly bound to an AAA domain.
Run the display this command in the AAA domain view on each device to view the number of
IP address pools and the configuration sequence.
l If the same two IP address pools are configured in the same sequence on two devices, change
the configuration sequence on one device. Run the undo ip-pool pool-name command to
delete a later configured address pool on one device and ip-pool pool-name command to
reconfigure the address pool, changing the configuration sequence. The modification
prevents addresses from being repeatedly allocated after a master/slave device switchover in
the scenario where load balancing is performed.
l If a single IP address pool is configured on each device, run the ip-pool pool-name command
to add a specific address pool on each device and ensure that the configuration sequences of
IP address pools on the two devices are opposite.
l If two IP address pools are configured and the configuration sequences are opposite on the
two devices, go to step 4.
----End

Relevant Alarms
None
Relevant Logs
None
6.9 NAT Troubleshooting in Dual-System Backup for

Distributed NAT Services
This section describes the flow and procedure for troubleshooting NAT services after a master-
slave BRAS switchover in dual-system backup for distributed NAT services.
6.9.1 Common Causes

The common causes of this fault are as follows:
l No standby address pool is configured for the NAT instance.

l The NAT instance bound to the RBS is incorrect.
l The NAT instance tracked by VRRP is incorrect.
l The user information on the new master and slave BRASs is inconsistent after a master-
slave switchover.

After dual-system backup for distributed NAT services is configured on BRASs that work in
hot backup mode, if users cannot access the Internet after a master-slave BRAS switchover,
perform troubleshooting by referring to Figure 6-9.

Figure 6-9 Troubleshooting flowchart
Users cannot access the Internet.
Whether
the standby address No Configure the standby Whether Yes
pool is configured on both address pool on both the the fault is rectified?
the master and slave master and slave BRASs.
BRASs?
No
Yes
Whether
No Bind the correct NAT Whether Yes
the NAT instance bound to
instance to the RBS. the fault is rectified?
the RBS is correct?
No
Yes
Whether Whether Yes

No Configure VRRP to track
the NAT instance tracked by the fault is rectified?
the correct NAT instance.
VRRP is correct?
No
Yes
Whether
user information on
the new master and Yes Whether Yes
slave BRASs is consistent the fault is rectified?
after a master-slave
switchover?
No
No
Contact Huawei technical End

support engineers.
Context
NOTE
Procedure
Step 1 Check whether the standby address pool is configured on both the master and slave BRASs.
On both the master and slave BRASs, run the display nat instanceinstance-name command to
check whether the standby address pool is configured. Example command output:

nat address-group 2 2.2.3.2 2.2.3.12 rui-slave
l Yes: Go to step 2.
l No: Run the nat address-group command in the NAT instance view to configure the standby
address pool.
NOTE
The same NAT instance and active and standby address pools must be configured on both the master and
slave BRASs. The active address pool on the master BRAS must be configured as the standby address pool
on the slave BRAS, and the standby address pool on the master BRAS must be configured as the active
address pool on the slave BRAS.
Step 2 Check whether the NAT instance bound to the RBS is correct.
Run the display remote-backup-service service-name command to check whether the NAT
instance bound to the RBS is correct.
l No: Run the nat-instance instance-name command in the RBS view to bind the correct NAT
instance.
Step 3 Check whether the NAT instance tracked by VRRP is correct.
Run the display this command in the interface view to check whether the NAT instance traced
by VRRP is correct. Example command output:
vrrp vrid 100 track nat-instance abc reduced 60
l No: Run the vrrp vrid virtual-router-id track nat-instance instance-name [reduced value-
reduced] command to configure the correct NAT instance.
Step 4 Check whether the user information on the new master and slave BRASs is consistent after a
master-slave switchover.
On the new master and slave BRASs, run the display nat user-information command to check
whether CPE IP, Public IP, and Initial Port Range in user information are the same on the master
and slave BRASs.
l Yes: Go to step 5 if the fault persists.

l No: Go to step 5.
l Results of the troubleshooting procedure
l Configuration files, log files, and alarm files of BRASs
----End
Relevant Alarms
None

Relevant Logs
None
6.10 Troubleshooting Cases
6.10.1 After the Tunnel Is Deployed, the Return Traffic Is

Interrupted
Faulty Symptom
Multi-device backup is configured on the network as shown in Figure 6-10; on Router A, an IP
redirection tunnel to Router B is configured.
After the configuration, users can go online through Router A and the traffic is normal. After
the interface (GE 2/0/0.2) through which users go online, is shut down, the return traffic is
interrupted.
Figure 6-10 Typical Network of Multi-device Backup
Loopback0
1.1.1.1/32
GE2/0/0.1
10.0.0.1/24 Master
GE2/0/0.2 RouterA
bas Loopback0
3.3.3.3/32
GE3/0/0
30.0.0.1/24
GE1/0/2 GE1/0/0
GE1/0/1
30.0.0.2/24 RouterC
DSLAM PE-AGG GE3/0/0
GE2/0/0.1 RouterB
10.0.0.2/24 Slave
GE2/0/0.2
bas Loopback0
2.2.2.2/32
Fault Analysis
1. On Router A, enter the view of the interface through which users go online, and then run
the display this command. You can find the RBP bound to the interface.
2. Run the display remote-backup-profile command to view the RBS bound to the RBP.
3. Run the display remote-backup-service command to view the status of the tunnel on the
RBS.

4. The tunnel is still Down. This indicates that the specified outbound interface is incorrect.
Procedure
Step 1 Allocate addresses of the same network segment to the GE 3/0/0 interfaces on Router A and
Router B. Or, check whether the Loopback interfaces on Router A and Router B can ping each
other.
Step 2 Enter the RBS view on Router A. Run the protect redirect ip-nexthop ip-address interface
gigabitEthernet3/0/0 command to configure a protection tunnel. Specify a correct outbound
interface.
NOTE
The public network protection tunnel must be in IP redirection or tunnel policy mode.
Step 3 Run the return command to return to the user view and then run the save command to save the
modification.
----End
Summary
This possible causes of this fault include that no direct line is configured, the peer route of the
tunnel is unreachable, and the specified outbound interface is incorrect. To rectify this fault, you
can reconfigure the IP redirection tunnel.

Troubleshooting - Reliability 7 APS Troubleshooting
7 APS Troubleshooting
About This Chapter
7.1 APS Failure or Slow APS Troubleshooting

7.1 APS Failure or Slow APS Troubleshooting
7.1.1 Common Causes

This fault is most commonly caused due to the following reasons:
l APS configurations on both ends of a link are inconsistent.

l APS is configured with the protection lock function, preventing services from being
switched to the protection link.
l A fault occurs on both working and protection links or an alarm is generated for both links,
preventing services from being switched between links.
l On an E-APS network, PWs are incorrectly configured or loopback interfaces of the RSGs
on both ends are unreachable.

None.

NOTE
Procedure
Step 1 Check that APS configurations on both ends of a link are correct.
NOTE
An APS failure is usually caused by inconsistent APS configurations on both ends of a link. After an APS
failure occurs, checking the APS configurations on both ends of the link first is recommended.
Run the interface interface-type interface-number or controller cpos cpos-number command

to enter the views of the working interfaces and protection interfaces on both ends, and run the
display this command to check whether APS configurations on both ends of a link are correct.
l Check that the working interface and protection interface on each end of the link are added
to the same APS group or the same trunk interface.
l Check that the protection mode and switchback time of the protection interfaces on both ends
of the link are the same.
l Check whether the switchback time is set too short. If the switchback time is set too short,
temporary packet loss may occur during service switchback. The recommended switchback
time is 5 minutes.
NOTE
If the working link recovers after services are switched to the protection link, services will be switched
back to the working link after the switchback time expires.
If the APS configurations on both ends of the link are correct, go to Step 2.

Step 2 Check that protection lock is configured on the protection interfaces on both ends of the link.
Check whether the aps switch-command lockout command is configured on the protection
interfaces.
If the aps switch-command lockout command has been configured on either of the protection
interfaces, services will not be switched to the protection link even though the working link
becomes unavailable. Run the undo aps switch-command lockout command to delete the
configuration.
If the aps switch-command lockout command has not been configured on the protection
interfaces on both ends of the link, go to Step 3.
Step 3 Check that the working and protection link statuses are correct.
NOTE
By default, an APS group is in automatic protection mode. An APS group behaves in the following manner
when it is in automatic protection mode:
When services are running on the working link and a Signal Failure (SF) or a Signal Degrade (SD) occurs
on the working link, services will be switched to the protection link. Otherwise, services will not be switched
to the protection link.
When services are running on the protection link and the working link recovers, if the revertive mode was
adopted, services will be switched back to the working link after the switchback time expires; when services
are running on the protection link and an SF occurs on the protection link, services will be immediately
switched back to the working link. Otherwise, services will not be switched back to the working link.
Run the display aps group command to check whether the APS status is displayed as sf in the
W-State and P-State fields. If the APS status of the working link or protection link is displayed
as sf, the link may become unavailable due to an optical fiber fault, an optical module fault, or
a Down event of an interface.
If both the protection and working links are working properly, go to Step 4.
Step 4 When E-APS is deployed, check that the PW configurations are correct.
As shown in Figure 7-1, E-APS is configured on RSG1 and RSG2.
Figure 7-1 Network of E-APS

RSG1
P rim a ry P W
N e tw o rk
IC B P W
Node B
CSG RNC
B a ck u p P W
RSG2
1. Check whether RSG1 and RSG2 can ping the loopback address of each other successfully.
If the pings fail, no reachable route exists between two routers and APS is always
implemented to switch services to the protection link and no longer switch them back to
the working link. Configure a reachable route between RSG1 and RSG2.

2. On an E-APS network, check whether the mpls l2vpn redundancy independent command
or the mpls l2vpn redundancy master command is configured on the CSG interfaces
where the primary and secondary PWs are set up. If not, slow APS or even an APS failure
may occur. Configure the mpls l2vpn redundancy independent command or the mpls
l2vpn redundancy master command on the CSG interfaces where the primary and
secondary PWs are set up.
3. On an E-APS network, check whether the mpls l2vpn stream-dual-receiving command
is configured on the CSG interfaces where the primary and secondary PWs are set up. If
the command is not configured, a great number of packets are discarded during the APS.
Configure the mpls l2vpn stream-dual-receiving command on the CSG interfaces where
the primary and secondary PWs are set up.
If E-APS is not deployed, go to Step 5.
Step 5 Collect the following information and contact Huawei technical support personnel:
l Results of the preceding operation procedure
----End
Relevant Alarms
None.
Relevant Logs
None.


Troubleshooting - Reliability

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Troubleshooting - Reliability

Transféré par

Droits d'auteur :

Formats disponibles

HUAWEI NetEngine40E/80E Universal Service

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

2.2.1 Common Causes........................................................................................................................................................20

3 MPLS OAM Troubleshooting...................................................................................................32

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

4.2.3 Troubleshooting Procedure........................................................................................................................................47

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

4.9.4 Relevant Alarms and Logs........................................................................................................................................71

5 MPLS-TP OAM Troubleshooting............................................................................................81

6 Multi-Device Backup Troubleshooting..................................................................................86

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

7 APS Troubleshooting............................................................................................................... 112

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

About This Chapter

1.1 BFD Session Cannot Go Up

1.3 Changed BFD Session Parameters Do Not Take Effect

1.4 Dynamic BFD Session Fails to Be Created

1.5 Related Troubleshooting Cases

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

1.1 BFD Session Cannot Go Up

1.1.1 Common Causes

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

1.1.2 Troubleshooting Flowchart

BFD packets Yes Seek

Check the link Seek technical

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

1.1.3 Troubleshooting Procedure

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

1.1.4 Relevant Alarms and Logs

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

1.2 Interface Forwarding Is Interrupted After a BFD Session

1.2.1 Common Causes

1.2.2 Troubleshooting Flowchart

Check the interface status

No BFD session Yes

Seek technical support

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