Troubleshooting - Layer 2 Network

HUAWEI NetEngine40E/80E Universal Service
Router
V600R006C00
Troubleshooting - Layer 2 Network
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 - Layer 2 Network 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
WARNING injury.
CAUTION indicates a potentially hazardous situation

CAUTION that, 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 - Layer 2 Network Contents
Contents
About This Document.....................................................................................................................ii

1 QinQ Troubleshooting.................................................................................................................1
1.1 Related Troubleshooting Cases......................................................................................................................................2
1.1.1 Some DHCP Clients Cannot Obtain IP Addresses from the DHCP Server When the DHCP Relay Agent Is Configured
with a Sub-Interface for Dot1q VLAN Tag Termination.....................................................................................................2
1.1.2 Network Segments Cannot Successfully Ping Each Other In Dot1q Termination Access.........................................3
2 Ethernet OAM Troubleshooting................................................................................................6

2.1 Ethernet OAM 802.1ag Trace Fails................................................................................................................................7
2.1.1 Common Causes..........................................................................................................................................................7
2.1.2 Troubleshooting Flowchart..........................................................................................................................................8
2.1.3 Troubleshooting Procedure..........................................................................................................................................8
2.1.4 Relevant Alarms and Logs........................................................................................................................................10
3 MSTP Troubleshooting..............................................................................................................11
3.1 MSTP Topology Change Leads to Service Interruption..............................................................................................12
3.1.1 Common Causes........................................................................................................................................................12
3.1.2 Troubleshooting Flowchart........................................................................................................................................12
3.1.3 Troubleshooting Procedure........................................................................................................................................14
4 RRPP Troubleshooting...............................................................................................................19
4.1 RRPP Loop Occurs Temporarily..................................................................................................................................20
4.1.1 Common Causes........................................................................................................................................................20
5 PPP and MP Troubleshooting...................................................................................................23

5.1 Protocol Status of a PPP Interface Is Down.................................................................................................................24
5.1.1 Common Causes........................................................................................................................................................24
5.2 Related Troubleshooting Cases....................................................................................................................................30
Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

Troubleshooting - Layer 2 Network Contents
5.2.1 Half of Packets Are Discarded the First Minute After an MP-Group Link Fails......................................................30
5.2.2 Incorrect Configurations of Member Interfaces Cause the MP-group Link to Work Unstably................................31
Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi

Troubleshooting - Layer 2 Network 1 QinQ Troubleshooting
1 QinQ Troubleshooting
About This Chapter
1.1 Related Troubleshooting Cases
Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

1.1.1 Some DHCP Clients Cannot Obtain IP Addresses from the

DHCP Server When the DHCP Relay Agent Is Configured with a
Sub-Interface for Dot1q VLAN Tag Termination
After the DHCP relay agent is configured to terminate packets from multiple VLANs through
the same sub-interface, some DHCP clients cannot obtain IP addresses from the DHCP server.
Fault Symptom
In the networking shown in Figure 1-1, Router A functions as the DHCP server; Router B
functions as the DHCP relay agent. A PC, that is, a DHCP client, is connected to Router B
through Switch A. After the configuration, the DHCP client cannot obtain an IP address from
the DHCP server.
Figure 1-1 Networking for a DHCP client to obtain an IP address from the DHCP server
RouterA
DHCP Server
RouterB
DHCP Relay
GE1/0/1.100
SwitchA
PC
VLAN10 VLAN20 VLAN30
DHCP Clients
Fault Analysis
1. Assign an IP address from the address pool to the PC. Ping the gateway address of Router
B from the PC. The ping is successful, indicating that the Layer 2 network runs properly.

Capture packets on the PC. The PC succeeds in sending a DHCPDISCOVER message but
fails to receive a DHCPOFFER message.
2. Ping the IP address of Router A from Router B. The ping is successful.
3. Capture packets transmitted between Router B and Switch A through port mirroring. A
DHCPOFFER message has been sent from Router B to Switch A.
4. Analyze the DHCPOFFER message sent from Router B. When the sub-interface for Dot1q
VLAN tag termination sends the DHCPOFFER message to the PC, Router B adds only the
VLAN tag with the smallest VLAN ID of the sub-interface for Dot1q VLAN tag termination
to the DHCPOFFER message. In this example, the Router B adds only VLAN 10, shown
in Figure 1-1, to the DHCPOFFER message. The PC, however, belongs to VLAN 20.
Therefore, the DHCPOFFER message is discarded by Switch A.
The Option field in a DHCP message is used to carry control information and parameters
that are not defined in common protocols. If you require that the Option field carry the
VLAN ID of a tagged packet sent from a client, you can enable the Option 82 function on
the DHCP relay agent.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface { ethernet | gigabitethernet } interface-number.subinterface-number
command to enter the Ethernet sub-interface view.
Step 3 Run the dhcp option82 insert enable command to enable Option 82 insertion for DHCP
messages on the sub-interface.
After the preceding operations are completed, the PC can obtain an IP address from the DHCP
server. The fault is thus rectified.
----End
Summary
The Option 82 field is a DHCP Relay Agent Information option recording the location
information of a DHCP client. It is a special field contained in a DHCP message.
The DHCP relay agent appends the Option 82 field to a DHCPDISCOVER message sent from
a client to the server. Upon receipt of the DHCPDISCOVER message that carries the Option 82
field, the DHCP server responds to the DHCP relay agent with a DHCPOFFER message that
contains the same Option 82 field. The DHCP relay agent then determines to where the
DHCPOFFER message is destined based on the Option 82 field carried in the message.
1.1.2 Network Segments Cannot Successfully Ping Each Other In

Dot1q Termination Access
Fault Symptom
In the networking shown in Figure 1-2, users on the network segment A access the router through
the BAS; users on the network segment B access the router through the sub-interface for Dot1q
VLAN tag termination on the router. After ping operations are performed between network
segment A and network segment B, it is found that some addresses cannot successfully ping

each other. The router, however, can successfully ping both network segment A and network
segment B.
Figure 1-2 Networking for network segments failing to ping each other in Dot1q termination
access
Switch
GE1/0/0.2
User Network GE1/0/0.1 User Network
A GE2/0/0.1 B
GE2/0/0.2
BAS Router
Switch
Fault Analysis
1. Run the display this command in the view of sub-interfaces of GE 1/0/0 on the router to
view information about the sub-interfaces of GE 1/0/0. The information is displayed as
follows:
#
interface GigabitEthernet1/0/0.1
control-vid 10 dot1q-termination
dot1q termination vid 3
ip address 10.1.1.1 255.255.255.0
arp broadcast enable
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
2. Run the display this command in the view of sub-interfaces of GE 2/0/0 on the router to
view information about the sub-interfaces of GE 2/0/0. The information is displayed as
follows:
#
undo shutdown
vlan-type dot1q 10
ip address 10.2.1.1 255.255.255.0
#
undo shutdown
vlan-type dot1q 10
ip address 10.2.1.2 255.255.255.0
#
3. You can find that GE 1/0/0.1 is configured as the sub-interface for Dot1q VLAN tag
termination, whereas other sub-interfaces are configured to terminate VLAN packets

through the vlan-type dot1q command. If a user needs to access the router through a sub-
interface for Dot1q VLAN tag termination and also supports network segment routes, it is
required that rt-protocol be configured and the configured user VLAN ID be the same as
the control VLAN ID. In this case, you can change the configuration of GE 1/0/0.1 to rectify
the fault.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the sub-interface view.
Step 3 Run the control-vid vid dot1q-termination rt-protocol command to configure the control
VLAN for the sub-interface for Dot1q VLAN tag termination.
NOTE
If rt-protocol is configured when configuring the control VLAN, ensure that the user VLAN ID is the
same as the control VLAN ID when running the dot1q termination vid command.
Step 4 Run the vlan-group group-id command to configure a user VLAN group.
Step 5 Run the statistic enable command to enable the QinQ statistics function for the user VLAN
group on the sub-interface.
Step 6 Run the quit command to return to the sub-interface view.
Step 7 Run the dot1q termination vid low-pe-vid vlan-group group-id command to configure the sub-
interface for Dot1q VLAN tag termination.
After the preceding operations, network segment A and network segment B can successfully
ping each other.
----End
Summary
Network segment A is connected to the router through the BAS. Therefore, the router can
successfully ping network segment A. The router is directly connected to network segment B at
Layer 2. Therefore, the router can successfully ping network segment B.
Some addresses on network segment A and network segment B cannot successfully ping each
other due to incorrect Dot1q termination configurations of a sub-interface on the router. If a user
needs to access the router through a sub-interface for Dot1q VLAN tag termination and also
supports network segment routes, it is required that rt-protocol be configured and the configured
user VLAN ID be the same as the control VLAN ID.

Troubleshooting - Layer 2 Network 2 Ethernet OAM Troubleshooting
2 Ethernet OAM Troubleshooting
About This Chapter
2.1 Ethernet OAM 802.1ag Trace Fails

2.1 Ethernet OAM 802.1ag Trace Fails
2.1.1 Common Causes

On the network shown in Figure 2-1, Router A fails to perform the 802.1ag MAC trace operation
to trace Router C.
[RouterA-md-one-ma-one] trace mac-8021ag mac 0018-823c-c449
Tracing the route to 0018-823c-c449 over a maximum of 64 hops:
Request timed out.
Figure 2-1 Troubleshooting flowchart for the fault that Ethernet OAM 802.1ag trace fails
GE8/0/13 GE1/0/10
GE1/0/13 GE2/0/10
RouterA RouterB RouterC
This fault is commonly caused by one of the following:

l Devices on the traced link run Ethernet OAM 802.1ag of different versions.
l A MEP configured on Router C (the traced node) is at a different level from that on Router
A (the trace-initiating node).
l A MEP on an intermediate node has the same level as or higher level than that on Router
A.
l An intermediate node has no MAC address entry for Router C.

2.1.2 Troubleshooting Flowchart
Figure 2-2 Troubleshooting flowchart for the fault that Ethernet OAM 802.1ag trace fails
802.1ag trace fails
802.1ag of
the same version No Yes
Change the 802.1ag
is run on Router A, Is fault rectified?
version to be the same
Router B, and
Router C?
No
Yes
Configure a MEP on
A higher-level No Yes
Router C at the same
MEP is configured on Is fault rectified?
level as the MEP on
Router C?
Router A
No
Yes
Configure a MEP on
A higher-level Yes Yes
Router B at the same
MEP is configured on Is fault rectified?
level as the MEP on
Router B? Router A
No
No
Perform 802.1ag MAC

Router B has a ping on Router A to Yes
No
MAC address entry of ping Router C and Is fault rectified?
Router C? allow Router B to learn
the MAC address
No
Yes
Collect information
Seek techincal support End
2.1.3 Troubleshooting Procedure
Procedure
Step 1 Run the display oam global configuration command to check that only 802.1ag Draft 7 or only
Standard 802.1ag-2007 is run on all devices along the traced link.

l If only 802.1ag Draft 7 or only Standard 802.1ag-2007 is run on all devices along the traced
link, go to Step 2.
l If 802.1ag Draft 7 and Standard 802.1ag-2007 are run on different devices along the traced
link, run the cfm version command to change all devices to run only 802.1ag Draft 7 or only
Standard 802.1ag-2007.
If Router A successfully performs the MAC trace operation to trace Router C, go to Step
6.
If Router A fails to perform the MAC trace operation, go to Step 2.
Step 2 Run the display this command to check that the MEP configured on Router C has the same level
as the MEP configured on Router A.
l If so, go to Step 3.
l If not, run the cfm md command to set the MEP level on Router C the same as that on Router
A.
6.
Step 3 Run the display cfm mep command to check that the level of the MEP on an intermediate node
is the same as or higher than that on Router A.
NOTE
After 802.1ag packets in a lower-level MD enter a higher-level MD, the 802.1ag packets will be discarded;
802.1ag packets in a higher-level MD can successfully travel through a lower-level MD. 802.1ag packets in an
MD of a specified level cannot travel through an MD with the same level.
l If the level of the MEP on an intermediate node is lower than that on Router A, go to Step
4.
l If the level of the MEP on an intermediate node is the same as or higher than that on Router
A, run the cfm md command to set the level of the MEP on the intermediate node lower than
that on Router A.
6.
Step 4 Run the display mac-address dynamic unit unit-id command on each intermediate node to
check that the MAC address entry of Router C exists.
l If so, go to Step 5.
l If not, run the ping mac-8021ag command to allow the intermediate node to learn the MAC
address of Router C.
6.
Step 5 If the fault persists, contact Huawei technical support personnel.
----End

2.1.4 Relevant Alarms and Logs
Relevant Alarms
EOAM1AG/4/CCFAULTALARM:OID 1.3.6.1.4.1.2011.5.25.136.1.6.1 MEP is disconnected or
reconnected with one or more MEPs. (CfmMdIndex=[GAUGE], CfmMaIndex=[GAUGE], RmepId=
[GAUGE], CfmMdIndex=[GAUGE], CfmMdIndex=[GAUGE], CfmMaIndex=[GAUGE], Dmac=
[OPAQUE], HighestDefect=[INTEGER], MdName=[STRING], MdLevel=[INTEGER], MaName=
[STRING])
EOAM1AG/4/CCFAULTALARM:OID 1.3.6.1.4.1.2011.5.25.136.1.6.1 A MEP has lost contact.
(CfmMdIndex=[GAUGE], CfmMaIndex=[GAUGE], RmepId=[GAUGE], CfmMdIndex=[GAUGE],
CfmMdIndex=[GAUGE], CfmMaIndex=[GAUGE], Dmac=[OPAQUE], HighestDefect=[INTEGER],
MdName=[STRING], MdLevel=[INTEGER], MaName=[STRING])
Relevant Logs
None

Troubleshooting - Layer 2 Network 3 MSTP Troubleshooting
3 MSTP Troubleshooting
About This Chapter
This chapter describes common causes of MPLS faults, and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
3.1 MSTP Topology Change Leads to Service Interruption

3.1 MSTP Topology Change Leads to Service Interruption
3.1.1 Common Causes

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

l MSTP is incorrectly configured.
l Physical links flap, triggering a large number of TC messages.
l An MSTP-aware device receives MSTP TC messages from clients or transparently-
transmitted MSTP TC messages.

Changing MSTP topology leads to service interruption on the network shown in Figure 3-1.

Figure 3-1 Networking diagram of MSTP
S1 S2
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
GE1/0/2 GE1/0/2
GE1/0/1 GE1/0/1
S3 S4
CIST(MSTI0):
Root Switch: S1
Blocked port
MSTI1:
Root Switch: S1
Blocked port
MSTI2:
Root Switch: S2
Blocked port
The troubleshooting roadmap is as follows:

l Check that the MSTP status is correct.
l Check whether the device has received TC messages.
l Check that no physical interface on the device alternates between Up and Down.
l Check that the MSTP convergence mode is Normal.
Figure 3-2 shows the troubleshooting flowchart.

Figure 3-2 Troubleshooting flowchart for service interruption due to changes in MSTP topology
Services are
interrupted or the
device is
disconnected
No Check and modify Yes

MSTP status is
the MSTP Is fault rectified?
correct?
configuration
No
Yes
Yes Seek technical

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

convergence mode is convergence mode Is fault rectified?
Normal? to Normal
Yes No
Collect information
Seek technical support End
Context
NOTE
Save the results of each troubleshooting step. If your troubleshooting fails to correct the fault, you will
have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check the status of interfaces on MSTP devices.
Check the role of each MSTP-enabled port in each instance.

On the network shown in Figure 3-1, there is only one MSTP ring, which means that each
instance can have only one blocked interface. Run the display stp brief command on each device
to check whether the status of each port is normal.
Run the display stp brief command in any view to check the MSTP status on S1. As shown in
Figure 3-1, in instances 0 and 1, S1 functions as a root bridge, and all ports on S1 are designated
ports. In instance 2, one port on S1 is a designated port, and the other port is a root port. Both
ports are in the Forwarding state.
[S1] display stp brief
MSTID Port Role STP State Protection
0 GigabitEthernet1/0/1 DESI FORWARDING NONE
2 GigabitEthernet1/0/1 ROOT FORWARDING NONE
Figure 3-1, in instances 2, S2 functions as a root bridge, and all ports on S2 are designated ports.
In other instances, one port on S2 is a designated port, and the other port is a root port. Both of
them are in the Forwarding state.
Figure 3-1, in instance 2, one port on S3 is an Alternate port and the other port is a root port.
The Alternate port is blocked and in the Discarding state. In other instances, one port on S3 is
a designated port and the other port is a root port. Both of them are in the Forwarding state.
0 GigabitEthernet1/0/1 DEST FORWARDING NONE
1 GigabitEthernet1/0/1 DEST FORWARDING NONE
2 GigabitEthernet1/0/1 ALTE DISCARDING NONE
Figure 3-1, in instance 0, one port on S4 is an Alternate port, and the other port is a root port.
The Alternate port is blocked and in the Discarding state. In instance 2, one port on S4 is a
designated port, and the other port is a root port. Both of them are in the Forwarding state.

l On the network shown in Figure 3-1, each instance has only one port in the Discarding
state and the other port is in the Forwarding state. If several ports are in the Discarding
state, an MSTP calculation error occurs. To solve this problem, go to Step 6.
l If the MSTP status is correct, go to Step 2.
Step 2 Check that the MSTP configuration is correct.

Run the display stp region-configuration command to view mappings between VLANs and
instances.
[S1] display stp region-configuration
Oper Configuration:
Format selector :0
Region name :huawei
Revision level :0
Instance Vlans Mapped

0 21 to 4094
1 1 to 10
2 11 to 20
l Check whether mappings between VLANs and instances are correct. If a mapping is
incorrect, run the instance command to map the VLAN to a specified spanning tree
instance. Run the active region-configuration command to activate the mapping between
the VLAN and instance configured (using the instance command).
Run the display current-configuration command to view the MSTP configuration in the
configuration file of the device.
l Check interface configurations to confirm that MSTP-enabled interfaces have been
configured with the bpdu-tunnel enable command to enable protocol packets to be sent
to the CPU.
l Check whether MSTP is disabled on the interfaces that connect to user terminals or the
interfaces are configured as edge interfaces.
l If an MSTP-enabled device is configured with a BPDU tunnel, check whether the BPDU
tunnel configuration is correct. For BPDU tunnel configurations, see "BPDU Tunnel
Configuration" in the NE80E/40E Configuration Guide - LAN Access and MAN Access .
l Check whether interfaces are added to VLANs correctly. For VLAN configurations, see
"VLAN Configuration" in the NE80E/40E Configuration Guide - LAN Access and MAN
Access.
l If the MSTP configuration is correct, go to Step 3.
Step 3 Check that no MSTP recalculation was performed.
Run the display stp command in any view to check whether the device received TC messages.
[S1] display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge :57344.00e0-fc00-1597
Bridge Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC :0 .0018-826f-fc7a / 20000
CIST RegRoot/IRPC :57344.00e0-fc00-1597 / 0
CIST RootPortId :128.2
BPDU-Protection :disabled
TC or TCN received :0
TC count per hello :0
STP Converge Mode :Normal
Time since last TC :2 days 14h:16m:15s
-------[MSTI 1 Global Info]-------

MSTI Bridge ID :4096.00e0-fc00-1597

MSTI RegRoot/IRPC :4096.00e0-fc00-1597 / 0

MSTI RootPortId :0.0
Master Bridge :57344.00e0-fc00-1597
Cost to Master :0
TC received :0
l If the values of TC or TCN received, TC count per hello, TC received, and TC count per
hello fields in the command output increase, the device has received TC messages, and the
network topology has changed. View the log messages MSTP/6/
SET_PORT_DISCARDING and MSTP/6/SET_PORT_FORWARDING to check
whether the role of an MSTP-enabled port changed.
If the port role did not change, go to Step 4.
If the port role changed, go to Step 6.
NOTE
If a multi-process has been created on the device, and TC notification was configured in the multi-
process, when the topology of the multi-process changes, a TC message is sent to process 0 to instruct
devices in process 0 to refresh their MAC and ARP address tables. Then, devices on the network can
re-select links to forward traffic, ensuring non-stop traffic.
l If the values of the TC or TCN received, TC count per hello, TC received, and TC count
per hello fields in the command output are 0s, the device does not receive any TC message.
Contact Huawei technical support personnel.
Step 4 Check that no interface on the device alternates between Up and Down.
View the log message IFNET/4/IF_STATE to check whether an MSTP-enabled port alternates
between Up and Down.
l If an MSTP-enabled interface alternates between Up and Down, the interface flaps. If a

physical interface frequently alternates between Up and Down, the MSTP status of the
device on the network becomes unsteady. As a result, a large number of TC messages are
generated, ARP entries and MAC entries are frequently deleted, and services are
interrupted. Run the shutdown command on the flapping interface. If services are not
restored after the interface is shut down, go to Step 5.
l If no interface flaps, go to Step 5.
Step 5 Check that the MSTP convergence mode is Normal.
Run the display stp command in any view to check the MSTP convergence mode of the device.
[S1] display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge :57344.00e0-fc00-1597
Bridge Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC :0 .0018-826f-fc7a / 20000
CIST RegRoot/IRPC :57344.00e0-fc00-1597 / 0
CIST RootPortId :128.2
BPDU-Protection :disabled
TC or TCN received :0
STP Converge Mode :Normal
Time since last TC :2 days 14h:16m:15s
-------[MSTI 1 Global Info]-------

MSTI Bridge ID :4096.00e0-fc00-1597
MSTI RegRoot/IRPC :4096.00e0-fc00-1597 / 0
MSTI RootPortId :0.0
Master Bridge :57344.00e0-fc00-1597
Cost to Master :0

TC received :0
l If the convergence mode is Normal, go to Step 6.

l If the convergence mode is Fast, run the stp converge normal command to change the
convergence mode to Normal. If services are not restored after the convergence mode is
changed, go to Step 6.
Step 6 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 device
----End
Relevant Alarms
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
Relevant Logs
MSTP/6/RECEIVE_MSTITC
VOSCPU/4/CPU_USAGE_HIGH

Troubleshooting - Layer 2 Network 4 RRPP Troubleshooting
4 RRPP Troubleshooting
About This Chapter
4.1 RRPP Loop Occurs Temporarily

4.1 RRPP Loop Occurs Temporarily
4.1.1 Common Causes

After RRPP is configured on a device, a loop occurs temporarily.

l The configuration is incorrect.
l Values of the Failtime timers configured for nodes along the RRPP ring are different.

Temporary RRPP loop troubleshooting is based on the network shown in Figure 4-1.
Figure 4-1 RRPP networking

Ethernet0/0/4
Ethernet0/0/2 Ethernet0/0/4
SwitchA
SwitchB
Ethernet0/0/1 Ethernet0/0/8
SwitchC Ethernet0/0/8

l Check that every node on the RRPP ring is configured correctly.
l Check that the Failtime timer of every node on the RRPP ring is set to the same value.

Figure 4-2 Troubleshooting flowchart for the fault that an RRPP loop occurs temporarily
RRPP loop occurs

temporarily
Every node No Yes

Modify the
on The RRPP ring is Is fault rectified?
configurations
correctly configured?
No
Yes
Failtime timer
No Yes
of every node on the Correct the
Is fault rectified?
RRPP ring is set to the configurations
same value?
No
Yes
Collect information

NOTE
Save the results of each troubleshooting step. If your troubleshooting fails to correct the fault, you will
have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that every node on the RRPP ring is configured correctly.
Run the display this command in the RRPP view of each node on the RRPP ring to view RRPP
configurations.
[RouterA-rrpp-domain-region1] display this
#
rrpp domain 1
control-vlan 100
protected-vlan reference-instance 0
timer hello-timer 1 fail-timer 3
ring 1 node-mode master primary-port Ethernet1/0/2 secondary-port Ethernet1/0/4
level 0
ring 1 enable
#
return

Check whether all nodes on the RRPP ring belong to the same domain, whether the nodes are
configured with the same control VLAN ID and instance number, and whether the RRPP ring
has only one master node.
l If all configurations are correct, go to Step 2.
l If any of the preceding configurations is incorrect, RRPP configurations may be incorrect.
For correct configurations, see "RRPP Configuration" in the NE80E/40E Configuration
Guide - LAN Access and MAN Access.
Step 2 Check that the Failtime timer of every node on the RRPP ring is set to the same value.
Run the display rrpp verbose domain domain-id command in any view to check detailed RRPP
configurations.
[RouterA-rrpp-domain-region1] display rrpp verbose domain 1
Domain Index : 1
Control VLAN : major 20 sub 21
Hello Timer : 1 sec(default is 1 sec) Fail Timer : 3 sec(default is 3 sec)
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Ring State : Complete
Is Enabled : Enable Is Active : Yes
Primary port : Port status: UP
Secondary port: Port status: BLOCKED
l If the Failtime timers of the nodes on the RRPP ring are set to different values, correct the
configurations according to "RRPP Configuration" in the NE80E/40E Configuration Guide
- LAN Access and MAN Access.
l If the Failtime timer of every node on the RRPP ring is set to the same value, go to Step
3.
l Configuration files, log files, and alarm files of the device
----End
Relevant Alarms
None
Relevant Logs
RRPP/3/FAIL
RRPP/5/PBLK
RRPP/5/RESTORE

Troubleshooting - Layer 2 Network 5 PPP and MP Troubleshooting
5 PPP and MP Troubleshooting
About This Chapter
5.1 Protocol Status of a PPP Interface Is Down

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the protocol status of a PPP interface is Down.

5.1 Protocol Status of a PPP Interface Is Down

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the protocol status of a PPP interface is Down.
5.1.1 Common Causes

After an interface is configured with PPP, LCP negotiation fails, which causes the protocol status
of the interface to be Down.
l PPP configurations on the two ends of the link are incorrect.

l The physical status of the interface is Down.
l PPP packets are discarded.
l A loop occurs on the link.
l The link delay is too long.

l Check that PPP configurations on the two ends of the link are correct.
l Check that the physical status of the interface is Up.
l Check that the interface can send and receive protocol packets.
l Check that the link is loop-free.
l Check that the link delay is tolerant.

Figure 5-1 Troubleshooting flowchart for an LCP negotiation failure
LCP negotiation fails
No
PPP configurations Modify PPP Yes
on the two ends of the link Is fault rectified?
configurations
are correct?
No
Yes
No Locate and rectify Yes

Physical status of the
transmission or Is fault rectified?
interface is Up?
lower-layer faults
No
Yes
Interface can No Locate and rectify Yes

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

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 PPP configurations on the two ends of the link are correct.
Run the display this command in the view of the interface whose protocol status is Down to
check PPP configurations.
[HUAWEI-Pos1/0/1] display this
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.10.1.1 255.255.255.0
#
return

l Check whether the following configurations on the two ends are consistent. If not, modify
the configuration referring to the chapter "PPP and MP Configuration" in the NE80E/
40E Configuration Guide - WAN Access.
Check whether the authenticator and authenticate are configured with the same
authentication mode. The ppp authentication-mode authentication-mode command
indicates the authentication mode adopted by the local end that functions as the
authenticator. You need to check the authentication mode adopted by the peer. For
example, if the ppp pap local-user user-name password simple password command
has been configured, it means that the peer adopts PAP authentication.
Check whether both ends are bundled into an MP-group or neither of the two ends is
bundled into an MP-group. If one end has been bundled into an MP-group, the other
end must be bundled into the same MP-group. If the ppp mp mp-group interface-
number command is configured, it means that the interface has been bundled into an
MP-group.
Check whether both ends are configured with the endpoint discriminators. The endpoint
discriminator check is applicable only to an MP-group or global MP-group interface.
By default, the router is configured with an endpoint discriminator. If the undo
discriminator command is configured, it indicates that no endpoint discriminator is
configured. For a non-Huawei device, you need to check whether it is configured with
an endpoint discriminator according to the configuration manual and relevant product
description of the device.
Check whether the authenticator and authenticate are configured with the same
password for PPP authentication.
If PAP authentication is adopted, do as follows to check the configured user name
and password:
Check the user name and password of the authenticate in the interface view.
#
interface Pos1/0/0
link-protocol ppp
ppp pap local-user huawei password simple huawei
undo shutdown
#
return
Check the user name and password of the authenticator in the AAA view.
[HUAWEI] aaa
[HUAWEI-aaa] display this
#
aaa
local-user huawei password simple huawei
#
return
If the authenticator adopts CHAP authentication and is configured with a user name,
do as follows to check the user name and password:
Check the user name of the authenticate in the interface view, and then check the
password in the AAA view based on the user name.
#
interface Pos1/0/0
link-protocol ppp
ppp chap user huawei
undo shutdown
#

return
[HUAWEI-Pos1/0/0] aaa
#
aaa
#
return
[HUAWEI] aaa
#
aaa
#
return
If the authenticator adopts CHAP authentication but is not configured with a user
name, do as follows to check the user name and password:
Check the user name and password of the authenticate in the interface view.
#
interface Pos1/0/0
link-protocol ppp
ppp chap user huawei
ppp chap password simple huawei
undo shutdown
#
return
[HUAWEI] aaa
#
aaa
#
return
l If the preceding configurations are correct but the fault persists, go to Step 2.
Step 2 Check that the physical status of the interface is Up.
Run the display interface interface-type interface-number command to check the physical status
of the interface.
l If the physical status of the interface is Down, you need to rectify the physical fault of the
interface. For detailed troubleshooting procedures, see "Physical Interconnection
Troubleshooting".
l If the physical status of the interface is Up but the fault persists, go to Step 3.
Step 3 Check that the interface can send and receive protocol packets.
Run the display interface interface-type interface-number command to check the number of
sent packets and received packets to determine whether the interface sends and receives protocol
packets.
[HUAWEI] display interface Pos 1/0/0
Pos1/0/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2010-02-05 06:35:43
Description:HUAWEI, Quidway Series, Pos1/0/0 Interface
Route Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec)

Internet Address is 108.108.1.1/24

Link layer protocol is PPP
LCP opened, IPCP opened
The Vendor PN is HFBR-57E0P
The Vendor Name is AVAGO
Port BW: 155M, Transceiver max BW: 155M, Transceiver Mode: MultiMode
WaveLength: 1310nm, Transmission Distance: 2000m
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: none
Flag J0 "NetEngine "
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
section layer: B1 0
line layer: B2 0 REI 44
path layer: B3 0 REI 23
Statistics last cleared:never
Last 300 seconds input rate 24 bits/sec, 0 packets/sec
Last 300 seconds output rate 24 bits/sec, 0 packets/sec
Input: 70945 packets, 1135144 bytes
Input error: 0 shortpacket, 0 longpacket, 0 CRC, 0 lostpacket
Output: 70945 packets, 1135140 bytes
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
l If the number of received or sent packets is 0, or the number does not increase, it indicates
that packets are discarded during transmission. Check whether the physical connection is
correct. For detailed information, see "Physical Interface Cannot Go Up".
l If the physical connection is correct, you need to locate the cause of packet loss. For detailed
troubleshooting procedures, see "Packet Loss Troubleshooting".
l If packets can be received and sent but the fault persists, go to Step 4.
CAUTION
Debugging affects the system performance. Therefore, after debugging, run the undo debugging
all command to disable it immediately.
In addition, you can run the debugging ppp all interface interface-type interface-number
command to check the number of sent and received protocol packets and the status changes of
the PPP state machine.
Jun 2 2010 17:19:41.310.1 HUAWEI PPP/7/debug2:Slot=1;
PPP Event:
Pos1/0/0 LCP TO+(Timeout with counter > 0) Event
state acksent , Retransmit = 4
PPP Packet:
Pos1/0/0 Output LCP(c021) Pkt, Len 18
State acksent, code ConfReq(01), id 3, len 14
MRU(1), len 4, val 1176
MagicNumber(5), len 6, val 00abb891
PPP Packet:
Pos1/0/0 Input LCP(c021) Pkt, Len 18
State acksent, code ConfAck(02), id 3, len 14
MRU(1), len 4, val 1176

MagicNumber(5), len 6, val 00abb891

PPP Event:
Pos1/0/0 LCP RCA(Receive Config Ack) Event
state acksent
Step 4 Check that the link is loop-free.
Run the display interface interface-type interface-number command to check the physical status
of the interface.
[HUAWEI] display interface Pos 1/0/2
Pos1/0/2 current state : UP
Line protocol current state : DOWN
Description:HUAWEI, Quidway Series, Pos1/0/2 Interface
Route Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec)
Internet protocol processing : disabled
Link layer protocol is PPP, loopback is detected
LCP closed
The Vendor PN is HFBR-57E0P
The Vendor Name is AVAGO
Port BW: 155M, Transceiver max BW: 155M, Transceiver Mode: MultiMode
WaveLength: 1310nm, Transmission Distance: 2000m
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: local
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
section layer: B1 22
line layer: B2 94 REI 145
path layer: B3 44 REI 86
Statistics last cleared:never
Last 300 seconds input rate 56 bits/sec, 0 packets/sec
Last 300 seconds output rate 56 bits/sec, 0 packets/sec
Input: 40530 packets, 890400 bytes
Input error: 0 shortpacket, 0 longpacket, 2 CRC, 0 lostpacket
Output: 36512 packets, 946612 bytes
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
l If loopback is detected is displayed, it indicates that a loop occurs on the link. You need
to locate the cause of the loop and eliminate the loop.
l If no loop occurs but the fault persists, go to Step 5.
Step 5 Check that the link delay is tolerant.

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


Relevant Alarms
None.
Relevant Logs
None.
5.2.1 Half of Packets Are Discarded the First Minute After an MP-
Group Link Fails
Fault Symptom
Router A and Router B are connected by using an MP-group interface consisting of two CE1
interfaces. All timeslots of each CE1 interface are bundled into a synchronous serial interface
to transmit services.
Figure 5-2 Networking for half of packets discarded the first minute after an MP-Group link
fails
MP-Group
CE1 1/0/0 CE1 1/0/0
CE1 1/0/1 CE1 1/0/1

RouterA RouterB
After the link of CE1 1/0/0 fails, 50% packets are dropped in the first minute, and the link
recovers and no packet is dropped in two minutes.
Fault Analysis
After an MP-group member link becomes unavailable, the traffic transmitted over this link
automatically switches to the other available link.
In addition, a PPP-enabled router sets the PPP status of the link to Down after failing to receive
10 consecutive Hold time messages.
A Hold time message is sent every 10 seconds by default, and it takes 100s to send 10 Hold time
packets. This is why the peer router can detect that the link is Down about two minutes (100s)
after the PPP status is set down.
Router B continues to send messages along the failed link 100s after the failure occurs. As a
result, half of packets are dropped during this period of time. After Router A sets the PPP status
to Down, Router B detects that the link goes Down and no longer sends messages along the
failed link, and therefore no message is dropped.

You can set a shorter interval at which a Hold time message is sent to rectify the fault.
Run the following commands on two routers on the two ends of the PPP link:
Procedure
Step 2 Run the interface serial 1/0/0:0 command to enter the view of the synchronous serial interface
composed of CE1 interfaces.
Step 3 Run the timer hold 1 command to set the interval at which a Hold time message is sent to 1
second.
Step 4 Run the shutdown and undo shutdown commands to restart the CE1 interface.
After the configurations, run the ping command on Router A or Router B to ping the peer. No
packet is dropped. The fault is then rectified.
----End
Summary
Set a smaller interval at which a Hold time message is sent on both ends of a PPP link, enabling
a rapid response to the link status change on an unstable network.
5.2.2 Incorrect Configurations of Member Interfaces Cause the MP-

group Link to Work Unstably
Fault Symptom
RouterA functions as the egress of the network and accesses the Internet through RouterB.
RouterA and RouterB intercommunicate through an MP-group link on which there is a
transmission device. An MP-group link is formed by bundling eight CE1 links.
Figure 5-3 Networking diagram of MP-Group
MP-Group MP-Group
Users Internet
RouterA Transmission RouterB

Device
When a user attached to RouterA accesses the Internet, the DNS server sometimes cannot be
pinged successfully; the long delay of packets and packet loss may frequently occur; the webpage
sometimes cannot be accessed.
Fault Analysis
1. On the transmission device, check the status of the physical interface and optical fiber. The
physical interface and optical fiber are detected normal.

2. On RouterA and RouterB, run the display interface command to view information about
the MP-group interface and its member interfaces.
Check the following information:
l Whether the interface becomes Up
l Whether the clock mode is correct
l Whether the line coding/decoding formats on both ends are consistent
l Whether loopback is configured
l Whether alarms are generated
[RouterA] display controller e1 1/0/0
E1 1/0/0 current state : UP
Description : HUAWEI, Quidway Series, E1 1/0/0 Interface
Physical layer is Packet Over NO-CRC4
clock master, linecode hdb3 , loopback none
Alarm: LOS
[RouterB] display controller e1 1/0/0
E1 1/0/0 current state : UP
Description : HUAWEI, Quidway Series, E1 1/0/0 Interface
Physical layer is Packet Over NO-CRC4
clock master, linecode hdb3 , loopback none
Alarm: LOS
When a transmission device is on the link, the router needs to obtain clock signals from the
transmission device, which requires the router to work in slave clock mode.
The CE1 interface on RouterA is configured to work in slave clock mode, whereas the CE1
interface on RouterB is configured to work in master clock mode. Therefore, the link is
unstable due to incorrect clock configuration.
Procedure
Step 1 Run the system-view command on RouterB to enter the system view.
Step 2 Run the controller e1 1/0/0 command to enter the CE 1 interface view.
Step 3 Run the clock slave command to change the clock mode of the CE1 interface to the slave clock
mode.
Step 4 Configure the same on each member interface of the MP-group interface.
Check the status of the CE1 interfaces on the routers on both ends. You can find that the link is
stable and packets can be transmitted and received normally. The fault is rectified.
----End
Summary
Functioning as the synchronous interface, the CE1 interface can work in data terminal equipment
(DTE) mode and data circuit-terminating equipment (DCE) mode. In addition, the interface
requires a clock mode.
On the CE1 interface, you can select one of the following clock modes:
l Master clock mode: uses the internal clock signal.
l Slave clock mode: uses the line clock signal.

When the CE1 interfaces of two devices are directly connected, one interface should be
configured to work in master clock mode and the other interface should be configured to work
in slave clock mode.
When the CE1 interface of a device is connected to a transmission device, the CE1 interface
must be configured to work in salve clock mode and obtains clock signals from the transmission
device.


Troubleshooting - Layer 2 Network

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Troubleshooting - Layer 2 Network

Hochgeladen von

Copyright:

Verfügbare Formate

HUAWEI NetEngine40E/80E Universal Service

Troubleshooting - Layer 2 Network

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

CAUTION indicates a potentially hazardous situation

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

2 Ethernet OAM Troubleshooting................................................................................................6

5 PPP and MP Troubleshooting...................................................................................................23

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

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

About This Chapter

1.1 Related Troubleshooting Cases

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

1.1 Related Troubleshooting Cases

1.1.1 Some DHCP Clients Cannot Obtain IP Addresses from the

VLAN10 VLAN20 VLAN30

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

1.1.2 Network Segments Cannot Successfully Ping Each Other In

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

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

Step 6 Run the quit command to return to the sub-interface view.

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

2 Ethernet OAM Troubleshooting

About This Chapter

2.1 Ethernet OAM 802.1ag Trace Fails

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

2.1 Ethernet OAM 802.1ag Trace Fails

2.1.1 Common Causes

This fault is commonly caused by one of the following:

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

2.1.2 Troubleshooting Flowchart

802.1ag trace fails

Perform 802.1ag MAC

Seek techincal support End

2.1.3 Troubleshooting Procedure

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

Step 5 If the fault persists, contact Huawei technical support personnel.

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

2.1.4 Relevant Alarms and Logs

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

About This Chapter