Troubleshooting - Physical Connection and Interfaces (V600R003C00 - 02)

HUAWEI NetEngine80E/40E Router
V600R003C00
Troubleshooting - Physical
Connection and Interfaces
Issue 02
Date 2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

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

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2011-09-10) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
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 the troubleshooting workflow and methods for HUAWEI
NetEngine80E/40E. This document describes the troubleshooting of HUAWEI NetEngine80E/
40E with various services, including information collection methods, common processing flows,
common troubleshooting methods, and troubleshooting cases.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine80E/40E
Router
V600R003C00

Intended Audience
This document describes how to troubleshoot the services of the NE80E/40E device in terms of
common faults and causes, troubleshooting cases, and FAQs.
This document describes the procedure and method for troubleshooting for the NE80E/40E
device.
This document is intended for:
l System maintenance engineers
l Commissioning engineers
Troubleshooting - Physical Connection and Interfaces About This Document
ii
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 of risk, which if not
avoided, will result in death or serious injury.
WARNING
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
TIP
Indicates a tip that may help you solve a problem or save
time.
NOTE
Provides additional information to emphasize or supplement
important points of the main text.

Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. Several items or no item can be selected.
iii
Convention Description
&<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 02 (2011-09-10)
Second commercial release.There is no change relative to the previous version.
Changes in Issue 01 (2011-05-30)
Initial field trial release.
iv
Contents
About This Document.....................................................................................................................ii
1 POS Interface Troubleshooting..................................................................................................1
1.1 The Physical Status of POS Interfaces Cannot Go Up.......................................................................................2
1.1.1 Common Causes........................................................................................................................................2
1.1.2 Troubleshooting Flowchart........................................................................................................................2
1.1.3 Troubleshooting Procedure........................................................................................................................3
1.1.4 Relevant Alarms and Logs........................................................................................................................5
1.2 Related Troubleshooting Cases..........................................................................................................................5
1.2.1 POS Interfaces Connecting the NE80E/40E and a Non-Huawei Device Cannot Be Up at the Link Layer
............................................................................................................................................................................5
1.2.2 Changed MTU on a POS Interface Does Not Take Effect........................................................................7
1.2.3 Different C2 Values Cause Ping Failures..................................................................................................8
1.2.4 Inconsistent CRC Code Lengths Cause Communication Failures............................................................9
1.2.5 Inconsistent C2 Values and Scrambling Status Cause the NE80E/40E Unable to Receive Packets from
the Peer.............................................................................................................................................................10
1.2.6 Configuring J0 and J1 When a POS Interface Is Down at the Physical Layer Causes a POS Link Unable
to Go Up...........................................................................................................................................................11
1.2.7 Fault in the Optical Module of a POS Interface Causes Dial-up Users Unable to Open Web Pages
..........................................................................................................................................................................12
1.2.8 A Large Number of Packets Are Dropped When Two routers Are Directly Connected by POS Interfaces
..........................................................................................................................................................................13
1.2.9 OSPF Neighbor Relationships Cannot Be Established Because Optical Fibers Are Incorrectly Attached
to POS Interfaces..............................................................................................................................................15
1.2.10 Slow Internet Access Is Caused by Inconsistent Working Modes of Two Interfaces at Two Ends of a
CE1 Link...........................................................................................................................................................16
1.2.11 Standby ATM Interface Cannot Go Up after the standby interface Command Has Been Configured on
the Active Interface..........................................................................................................................................17
1.2.12 Optical Module Failure Causes an Interface to Be Up and the Other Interface to Be Physically Down at
Two Ends of a Link..........................................................................................................................................18
2 Eth-Trunk Interface Troubleshooting.....................................................................................20
2.1 Eth-Trunk Interface Cannot Forward Traffic...................................................................................................21
2.1.1 Common Causes......................................................................................................................................21
2.1.2 Troubleshooting Flowchart......................................................................................................................21
2.1.3 Troubleshooting Procedure......................................................................................................................22
2.1.4 Relevant Alarms and Logs......................................................................................................................26
Troubleshooting - Physical Connection and Interfaces Contents
v
2.2 Related Troubleshooting Cases........................................................................................................................26
2.2.1 Certain Users Cannot Access the Internet by Dialing Up After a Member Interface of the Eth-Trunk
Interface Becomes Faulty.................................................................................................................................26
3 GE Interface Troubleshooting..................................................................................................28
3.1 Related Troubleshooting Cases........................................................................................................................29
3.1.1 10GE Interfaces Connecting Two Devices Cannot Be Up......................................................................29
3.1.2 Interconnected Interfaces Alternate Between Up/Down States...............................................................30
3.1.3 Severe Packet Loss Occurs After the FE Optical Module Is Mistakenly Inserted into a GE Optical Interface
..........................................................................................................................................................................31
3.1.4 A Device Cannot Go Up Because the 10GE WAN Board Does Not Match the Multi-mode Optical Module
..........................................................................................................................................................................31
4 ATM Interface Troubleshooting..............................................................................................33
4.1 Two ATM Interfaces Fail to Ping Each Other.................................................................................................34
4.1.1 Common Causes......................................................................................................................................34
4.1.2 Troubleshooting Flowchart......................................................................................................................34
4.1.3 Troubleshooting Procedure......................................................................................................................35
4.1.4 Relevant Alarms and Logs......................................................................................................................37
Troubleshooting - Physical Connection and Interfaces Contents
vi
1 POS Interface Troubleshooting
About This Chapter
NOTE
POS interfaces cannot be configured on the X1 and X2 models of the NE80E/40E.
1.1 The Physical Status of POS Interfaces Cannot Go Up
1.2 Related Troubleshooting Cases
Troubleshooting - Physical Connection and Interfaces 1 POS Interface Troubleshooting
1
1.1 The Physical Status of POS Interfaces Cannot Go Up
1.1.1 Common Causes
This fault is commonly caused by one of the following:
l Interfaces at both ends of the connection are shut down.
l The optical module specification or the link is faulty.
l SDH alarms exist at both ends of the connection.
l The fiber is not properly connected.
l The fiber is inserted into the transmit optical port/receive optical port of the optical module
on one end but is inserted into the receive optical port/transmit optical port of the optical
module on the other end.
l The board or the optical module is faulty.
1.1.2 Troubleshooting Flowchart
When POS interfaces of two NE80E/40Es are connected, the physical status of POS interfaces
cannot go Up.
The troubleshooting flowchart is as follows:
l Run the command to check whether configurations of the local device are correct.
l Check the fiber, optical module, and board on site.
Figure Figure 1-1 shows the troubleshooting flowchart.
2
Figure 1-1 Troubleshooting flowchart of the fault that the physical status of POS interfaces
cannot be Up
Run the undo
shutdown command to
turn on interfaces.
Change the optical
module or adjust the link
to ensure that the
receiving or transmitting
optical power is within
the normal range.
Is the fault
rectified?
End
No
No
Yes
seek technical support.
No
No
Is the fault
rectified?
Is the fault
rectified?
Is the fault
rectified?
No
No
Is the fault
rectified?
Clear SDH alarms.
Properly insert the fiber.
Insert the two ends of
the fiber into correct
interfaces.
Replace the board or
optical module and then
restore the link.
No
Is the fault
rectified?
Yes
Yes
Yes
Yes
Physical layer of the POS
interface goes Down.
Are the board and
optical module normal?
Are
the two ends of the fiber
inserted into correct
interfaces?
Is
the fiber or the optical
module properly
inserted?
Are
SDH alarms cleared on
interfaces?
Are
the receiving and
transmitting optical
power on the interfaces
winthin the normal
range?
Are
interfaces at both ends
of the connection turned
on?
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No

1.1.3 Troubleshooting Procedure
3
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 interfaces at both ends of the connection are shut down, the transmit/receive optical
power is normal, and SDH alarms exist on the interfaces at both ends of the connection.
Run the display interface pos [ interface-number ] command to check the following items:
l If the current field state is "Administratively down", it indicates that the POS interfaces are
shut down. In this case, you need to run the undo shutdown command in the view of the
POS interface.
l If the transmit optical power is not within the normal range, you need to replace the optical
module.
l If the receive optical power falls below the receiver sensitivity of the optical module, you
need to replace the optical module or adjust the link.
l If the SDH alarm field is not "none" and the SDH error fields indicates that the number of
B1, B2, or B3 error codes increases:
The number of B1, B2, and B3 error codes increases:Check the transmission stability of
the link (including optical modules at both ends of the link) between the router and the
SDH transmission device. If the direct link is a WDM link, you need to check the
transmission stability of the WDM link.
The number of only B3 error codes increases: This problem occurs in the scenario where
the router and the SDH transmission device are directly connected through a link. In this
case, you need to check the transmission stability of the direct link. If the direct link is a
WDM link, you need to check the transmission stability of the WDM link.
If the fault persists, go to Step 2.
Step 2 Check whether the optical modules or the fiber is properly connected.
Both the optical module and the fiber have card fasteners. If a "clap" sound is heard during the
insertion of the fiber or the optical module, it indicates that the fiber or the optical module has
been properly inserted.
Step 3 Check whether the two ends of the fiber are inserted into correct optical interfaces.
Remove the fiber and then change the optical interface into which one end of the fiber is inserted,
for example, if the one end of the fiber is inserted into the transmit optical interface of the optical
module, insert it into the receive optical interface of the optical module. If the fault is rectified,
it indicates that the two ends of the fiber are inserted into incorrect optical interfaces.
If the fault persists, do not change the optical interfaces into which the two ends of the fiber are
inserted and go to Step 4.
Step 4 Perform the loopback test on the local fiber.
Use a fiber in good condition to connect the transmit optical interface to the receive optical
interface of the local optical module:
4
l If the physical status of the two interface goes Up, all SDH alarms on the interfaces are cleared
and the number of B1, B2, or B3 error codes is not increased. It can thus be concluded that
the board and the optical module on the local device are normal. You need to check the link
or the peer device.
l If the physical status of the two interface remains Down, it can be concluded that the board
or the optical module of the local device is faulty. You need to replace the board or the optical
module, or cut over services on the faulty interface to another interface that runs normally.
NOTE
When performing the loopback test on the local fiber, you need to set the clock mode of the interface as Master.
Step 5 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
None.
Relevant Logs
None.
1.2.1 POS Interfaces Connecting the NE80E/40E and a Non-Huawei
Device Cannot Be Up at the Link Layer
Fault Symptom
The NE80E/40E is connected to a non-Huawei device through an intermediate transmission
device. When HDLC runs on the interconnected POS interfaces, the POS interfaces are Up at
the physical layer but HDLC is Down.
Fault Analysis
1. Run the display interface pos command in user view of the NE80E/40E to view the
physical layer information about the POS interface.
<HUAWEI> display interface pos 1/0/0
Pos1/0/0 current state : UP
Line protocol current state : DOWN
Description : Pos1/0/0 Interface
Route Port,The Maximum Transmit Unit is 4470 bytes, Hold timer is 10(sec)
Internet Address is 1.1.1.1/24
5
Link layer protocol is HDLC
LCP opened, IPCP opened
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: PPLM
SDH error:
section layer: B1 0
line layer: B2 0 REI 0
path layer: B3 0 REI 0
Statistics last cleared:2006-12-20 09:20:21
Last 300 seconds input rate 0 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
Input: 24 packets, 12593 bytes
Input error: 4 shortpacket, 60 longpacket, 80 CRC, 0 lostpacket Output:
604 packets, 9688 bytes
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
2. The command output shows that B1, B2, B3, line REI, and path REI values are not
increased, which indicates that the transmission link is normal.
3. The number of longpacket, however, increases, which indicates that the scrambling modes
of interfaces at both ends are different.
Run the undo scramble command to disable the scrambling function. Then, longpacket
stops increasing, and the interface can receive packets from the other interface. HDLC,
however, is still Down.
4. The command output also shows that there is a PPLM alarm, which is generated due to
inconsistency of C2 values.
NOTE
When two NE80E/40Es are interconnected, inconsistency of C2 values does not cause the physical
layer to go Down. When the NE80E/40E is connected to a non-Huawei device, however, packet loss
occurs when the C2 values of the two devices are different.
Procedure
Step 1 Run the system-view view to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the POS interface view.
Step 3 Run the flag c2 c2-value command to set the C2 value of the POS interface to that of the peer
interface. After the preceding operations, the PPLM alarm is cleared and the protocol goes Up.
The fault is thus rectified.
----End
Summary
When the NE80E/40E is connected to a non-Huawei device, ensure that B1, B2, B3, line REI,
path REI, and C2 values on both devices are the same.
6
1.2.2 Changed MTU on a POS Interface Does Not Take Effect
Fault Symptom
Two routers are connected by using two POS 1/0/0 interfaces. After the MTU on POS 1/0/0 of
one router is changed to 1500 bytes by using the mtu command, the MTU does not take effect.
The following configurations of POS 1/0/0 are displayed in the display current-configuration
interface command output:
[HUAWEI] display current-configuration interface pos 1/0/0
#
interface Pos1/0/0
link-protocol ppp
mtu 1500
undo shutdown
The following configurations of POS 1/0/0 are displayed in the display interface pos command
output:
[HUAWEI] display interface pos 1/0/0
Line protocol current state : UP
Last line protocol up time : 2008-08-05 09:23:34
Description:HUAWEI, Pos1/0/0 Interface
Route Port,The Maximum Transmit Unit is 1492, Hold timer is 10(sec)
Link layer protocol is PPP
Fault Analysis
1. Run the shutdown and undo shutdown commands on the POS interface to restart it.
2. Run the display interface pos command. The effective MTU is 1492 bytes.
3. Check the MTU of the peer. The MTU of the peer POS interface is 1492 bytes.
Note that during MRU negotiation, a smaller MTU between two MTUs on two ends of a PPP
link takes effect. Therefore, the 1492-byte MTU rather than the 1500-byte MTU takes effect.
Procedure
Step 1 Change the MTU of the peer POS interface to 1500 bytes and then restart the interface.
After the configuration, the MTUs on both ends of the PPP link are 1500 bytes, and thus the
1500-byte MTU takes effect. The fault is then rectified.
----End
Summary
During MRU negotiation, a smaller MTU between two MTUs on two ends of a PPP link takes
effect.
7
1.2.3 Different C2 Values Cause Ping Failures
Fault Symptom
On the network shown in Figure 1-2, Router A and Router B are connected through POS
interfaces. The POS interface on Router A and the POS interface on Router B are Up at both the
physical layer and the data link layer, but the POS interfaces fail to ping each other.
Figure 1-2 Networking diagram of the case where different C2 values cause ping failures
RouterA Router
Transmission
Device

Fault Analysis
1. Run the display interface pos 1/0/0 command on Router A to check the clock mode and
whether the scrambling function is enabled.
Scramble enabled in the command output indicates that the scrambling function has been
enabled on Router A. The display interface pos 1/0/0 command output on Router B shows
that the scrambling function has also been enabled.
clock master in the command output indicates that the clock mode is master. In addition,
it is confirmed that the clock mode of the peer is slave, which means the clock modes
configured on the two devices are correct.
2. Run the display pos interface pos 1/0/0 command on Router A to check the overhead byte
configured for this interface.
SDH
OverHead:
Rx C2 Value:0xff, Tx C2 Value:0x16
The command output shows that the C2 values configured for the transmitting end and the
receiving end are different and therefore the receiving end fails to forward packets. The
ping fails.
Procedure
Step 1 Run the system-view command on Router A to enter the system view.
Step 2 Run the interface pos 1/0/0 command on Router A to enter the POS interface view.
Step 3 Run the flag c2 c2-value command on Router A to set the C2 value of the POS interface to the
same as that of the POS interface on Router B.
After the operations, the two ends are configured with the same C2 value, and thus they can ping
each other successfully. The fault is rectified.
----End
8
Summary
When using POS interfaces to connect two devices, ensure that the two interfaces are configured
with the same overhead byte; both are enabled or disabled with the scrambling function; one is
configured with the master clock mode and the other is configured with the slave clock mode.
1.2.4 Inconsistent CRC Code Lengths Cause Communication
Failures
Fault Symptom
On the current network, the NE80E/40E is connected to a non-Huawei device through a POS
interface. The display interface pos 1/0/0 command is run in the POS interface view. The POS
interface is Up at the physical layer but is Down at the data link layer.
Fault Analysis
1. Run the display interface pos 1/0/0 command on the router. The result shows that the data
link protocol of the POS interface is PPP, which is the same as the data link protocol of the
peer.
Link layer protocol is PPP
The Vendor Name is FINISAR CORP. , The Vendor PN is FTLF1321P1BTL-HW
Transceiver BW: 2.5G, Transceiver Mode: Single Mode
WaveLength: 1310nm, Transmission Distance: 2km
Rx Power: -12.29dBm, normal range: [-23.97, 0.75]dBm
Tx Power: -5.43dBm, normal range: [-13.49, 1.00]dBm
Physical layer is Packet Over SDH,
The preceding information shows that the CRC code length configured for the POS
interface is 32 bits, different from the CRC code length (16 bits) configured on the peer
POS interface. This causes the POS interface on the router to fail to communicate with the
POS interface on the peer device.
Procedure
Step 1 Run the system-view command on the router to enter the system view.
Step 2 Run the interface pos 1/0/0 command on the router to enter the POS interface view.
Step 3 Run the crc 16 command on the router to change the CRC code length of the POS interface to
16 bits.
After the operations, run the display interface pos 1/0/0 command on the router to check the
interface status. The interface is Up at both the physical layer and the data link layer. The fault
is rectified.
----End
9
Summary
A POS interface can be configured with either 16-bit CRC or 32-bit CRC. When using POS
interfaces to connect devices, ensure that the two interfaces are configured with the same CRC
code length. Otherwise, communication will fail.
1.2.5 Inconsistent C2 Values and Scrambling Status Cause the
NE80E/40E Unable to Receive Packets from the Peer
Fault Symptom
On the network shown in Figure 1-3, Router A is connected to Router B and Router C through
an optical splitter over POS links. After the configuration, Router C can receive packets from
Router A but B cannot.
Figure 1-3 Networking diagram of the case where the NE80E/40E cannot receive packets from
the peer
Optical
Splitter
RouterA
RouterC
RouterB

Fault Analysis
1. Remove the optical fiber connecting the optical splitter to Router C and insert the fiber into
Router B. Router B still cannot receive packets from Router A, excluding the possibility
that the fault is caused by the optical splitter and optical fiber.
2. Replace the optical module inserted into the POS interface on Router B. The fault persists,
excluding the possibility that the fault is caused by this optical module.
3. Run the display interface pos 1/0/0 command on Router B. The POS interface on
Router B is Up at both the physical layer and the data link layer. In addition, the data link
protocol is HDLC, which is the same as the data link protocol of the peer.
The Vendor Name is FINISAR CORP. , The Vendor PN is FTLF1321P1BTL-HW
Transceiver BW: 2.5G, Transceiver Mode: Single Mode
Physical layer is Packet Over SDH,
10
Flag C2 22(0x16)
The preceding information shows that the C2 value of Router B is 22, which is different
from the C2 value (16) of Router A. Additionally, Router B is enabled with the scrambling
function but Router A is disabled with the scrambling function. It is concluded that
inconsistent configurations of POS interfaces on Router A and Router B cause Router B
unable to receive packets from Router A.
Procedure
Step 1 Run the system-view command on Router B to enter the system view.
Step 2 Run the interface pos 1/0/0 command on Router B to enter the POS interface view.
Step 3 Run the flag c2 16 command to change the C2 value of the POS interface to 16, which is the
same as the C2 value of the POS interface on Router A.
Step 4 Run the undo scramble command on Router B to disable the scrambling function.
After the operations, Router B can receive packets from Router A. The fault is rectified.
----End
Summary
Before two devices communicate with each other, ensure that the default settings of the two ends
are the same, preventing communication failures. Otherwise, the link will go Down, and thus
services cannot be transmitted.
1.2.6 Configuring J0 and J1 When a POS Interface Is Down at the
Physical Layer Causes a POS Link Unable to Go Up
Context
On the live network, the NE80E/40E is connected to a non-Huawei device through a POS
interface. The POS interface needs to be configured with the flag j0 peer and flag j1 peer
commands so that the POS interface can learn the corresponding parameters configured on the
peer. The display interface pos 1/0/0 command is used in the view of the POS interface on the
NE80E/40E. The POS interface is Up at the physical layer but is Down at the data link layer.
Fault Analysis
Default settings of devices of different vendors are probably different. Therefore, when the
NE80E/40E is connected to a non-Huawei device, you need to configure J0 and J1 to learn the
corresponding parameters configured on the peer. If the flag j0 peer and flag j1 peer commands
are run when the interface is Down at the physical layer, generated parameters are not learned
from the peer and no parameter negotiation is performed even if this interface goes Up at the
physical layer. As a result, parameter negotiation between the two POS interfaces fails, and thus
the POS interface cannot go Up at the data link layer.
11
Procedure
Step 1 Run the display interface pos 1/0/0 command on the NE80E/40E to check whether the POS
interface is Up at the physical layer. If the interface is Down at the physical layer, you need to
rectify the physical layer fault before performing the following operations.
Step 2 Run the interface pos 1/0/0 command on the NE80E/40E to enter the POS interface view.
Step 3 Run the undo flag command on the NE80E/40E to delete the configuration of the SDH overhead
byte.
Step 4 Run the display interface pos 1/0/0 command on the NE80E/40E to check whether the POS
interface is physically Up. If the physical status of the POS interface is Down, rectify the fault
at the physical layer, and perform the following configurations.
Step 5 Run the flag j0 peer and flag j1 peer commands on the NE80E/40E to configure SDH overhead
bytes.
After the operations, run the display interface pos 1/0/0 command on the router to check the
interface status. The interface is Up at both the physical layer and the data link layer. The fault
is rectified.
----End
Summary
Before using the flag j0 peer and flag j1 peer commands to learn J0 and J1 values configured
on the peer, ensure that the interface is Up at the physical layer.
1.2.7 Fault in the Optical Module of a POS Interface Causes Dial-
up Users Unable to Open Web Pages
Fault Symptom
On the network shown in Figure 1-4, the router is connected to a BRAS through a POS interface.
Dial-up users attached to the BRAS access the Internet through the router. After the
configuration, dial-up users cannot open Web pages.
Figure 1-4 Networking diagram of the case where a fault in the optical module of a POS interface
causes dial-up users unable to open Web pages
PC BRAS Router

Fault Analysis
1. Run the display interface pos 1/0/0 command on the router to check the configuration of
the POS interface.
12
The command output shows that the MTU of the POS interface connecting the router to
the BRAS is 1024 bytes, but the MTU of the directly-connected POS interface on the BRAS
is 1500 bytes. The MTU values of the two POS interfaces are unmatched.
2. On the POS interface of the router, use an optical fiber to connect the transmitter to the
receiver. Run the mtu 1500 command to change the MTU to 1500 bytes. Run the display
interface pos 1/0/0 command. The MTU of the POS interface on the router is still 1024
bytes, indicating that the SFP optical module of the POS interface is faulty.
Procedure
Step 1 Replace the optical module of the POS interface on the router.
Step 2 Run the display interface pos 1/0/0 command on the router. The MTU value of the local POS
interface is the same as the MTU value of the peer POS interface, and the local interface is Up.
After the operations, dial-up users attached to the BRAS can open Web pages. The fault is
rectified.
----End
Summary
Before using POS interfaces to communicate, create a self-loop to check whether parameters of
the two interfaces are the same. Services can be processed only when the parameters configured
on the two ends of a link are the same.
1.2.8 A Large Number of Packets Are Dropped When Two routers
Are Directly Connected by POS Interfaces
Fault Symptom
On the network shown in Figure 1-5, a POS interface of Router A is directly connected to a
POS interface of Router B through an optical fiber. After Router A pings Router B, a large
number of packets are dropped. After Router B pings Router A, no packet is dropped but the
number of incorrect packets is large keeps increasing on the POS interface of Router B.
Figure 1-5 Networking diagram of the case where a large number of packets are dropped when
two routers are directly connected by POS interfaces
RouterA RouterB

Fault Analysis
1. Run the display interface pos 1/0/0 command on Router A to check information about the
POS interface.
13
Internet protocol processing : enabled
LCP opened
The Vendor PN is FTRJ8519P1BNL-HW
The Vendor Name is FINISAR CORP.
Port BW: 2.5G, Transceiver max BW: 1G, Transceiver Mode: MultiMode
WaveLength: 850nm, Transmission Distance: 550m
Physical layer is Packet Over SDH
Scramble enabled, clock slave, CRC-32, loopback: none
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
section layer: B1 3554
line layer: B2 689530 REI 113076
path layer: B3 28473 REI 4
Statistics last cleared:never
Last 300 seconds input rate 8 bits/sec, 0 packets/sec
Last 300 seconds output rate 80 bits/sec, 0 packets/sec
Input: 8736 packets, 25483760 bytes
Input error: 6 shortpacket, 1 longpacket, 88 CRC, 0 lostpacket
Output: 14510 packets, 928640 bytes
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.01%
Based on the comparison of the command output and the configuration information about
Router B. The encapsulation modes (HDLC) and intervals (10s) set on Router A and
Router B are the same. The configurations are correct.
2. In addition, the clock modes of the POS interfaces on Router B and Router A are slave.
The problem occurs because no master clock is configured on either of routers connected
by the optical fiber.
Procedure
Step 2 Run the interface pos 1/0/0 command to enter the POS interface view.
Step 3 Run the clock master command to set the clock mode of the POS interface to Master.
After the preceding operations, on Router A, ping Router B. No packet is dropped. The fault is
then rectified.
----End
Summary
In the case that the POS interfaces of both Router A and Router B are configured with the slave
clock mode, and no transmission device functioning as a master clock to provide clock signals
for Router A or Router B, one of POS interfaces on Router A and Router B must be configured
with the master clock mode so that services can be forwarded properly.
14
1.2.9 OSPF Neighbor Relationships Cannot Be Established Because
Optical Fibers Are Incorrectly Attached to POS Interfaces
Fault Symptom
On the network shown in Figure 1-6, Router B is connected to Router A through a 155M POS
link and Router B is connected to Router C through a 155M POS link. The connected interfaces
are configured with PPP at the data link layer and OSPF at the network layer. After the
configuration, no traffic is transmitted on either of the two links. Router B can successfully ping
Router A and Router C. The display ospf peer command output shows that the State field
displays Init, indicating that the OSPF neighbor relationships are in Init state.
OSPF Process 1 with Router ID 10.1.1.2
Neighbors
Area 0.0.0.0 interface 10.1.1.2(Pos1/0/0)'s neighbors
Router ID: 10.1.1.1 Address: 10.1.1.1 GR State: Normal
State: Init Mode:Nbr is Slave Priority: 1
DR: 10.1.1.1 BDR: None MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:00:05
Authentication Sequence: [ 0 ]
Figure 1-6 Networking diagram of the case where the OSPF neighbor relationships cannot be
established because optical fibers are incorrectly attached to POS interfaces
RouterA RouterB RouterC
POS1/0/0
POS1/0/0
POS2/0/0
POS2/0/0

Fault Analysis
1. Run the display current-configuration configuration ospf command on each Router to
check OSPF configurations. The configurations are correct.
2. Run the display interface pos interface-number command on the POS interface of each
Router to check the MTU. MTUs on all POS interfaces are 1526 bytes. The problem is not
caused by the inconsistent MTUs at two ends of each link.
3. Run the display this command in the POS interface view on each Router. The IP address
of POS 1/0/0 on Router A is 10.1.2.1/24; the IP address of POS 1/0/0 on Router B is
10.1.1.2/24; the IP address of POS 2/0/0 on Router B is 10.1.2.2/24; the IP address of POS
2/0/0 on Router C is 10.1.1.1/24. The command output shows that the IP addresses of two
interfaces that should have been in the same network segment are not in the same segment.
This indicates that the optical fibers have been interchanged.
Procedure
Step 1 Interchange the optical fibers attached to the POS interfaces on Router B.
15
After the preceding operations, run the display ospf peer command to check the OSPF neighbor
status. The State field displays Full. The fault is rectified.
----End
Summary
PPP does not check the peer IP address during negotiation although the IP addresses of connected
interfaces are in different network segments, and the two devices can successfully ping each
other. Ensure that IP addresses of interfaces at both ends of a PPP link are in the same network
segment and the optical fibers are not interchanged during the configuration of a PPP link.
1.2.10 Slow Internet Access Is Caused by Inconsistent Working
Modes of Two Interfaces at Two Ends of a CE1 Link
Fault Symptom
On the network shown in Figure 1-7, Router A and Router B are connected by a CE1 link. The
link bandwidth is set to 2 Mbit/s. After the configuration, the transmission delay is in an
acceptable range when there is no traffic on the CE1 interface on Router A, but the transmission
delay increases to over 300s when there is traffic. Users attached to Router A access the Internet
at low speeds.
Figure 1-7 Networking diagram of the case where slow Internet access is caused by inconsistent
working modes of two interfaces at two ends of a CE1 link
RouterA RouterB
PC1
PC2
CE11/0/0

Fault Analysis
1. Run the display this interface command in the CE1 interface view of Router A. The
maximum bandwidth of the interface is only 500 Mbit/s. The traffic volume is small and
thus does not cause slow Internet access.
2. Run the display controller e1 command on Router A. The frame format on the CE1
interface is crc4, but the frame format on the CE1 interface of Router B is no-crc4. These
different settings cause slow Internet access.
E1 1/0/0 current state : UP
Description : E1 1/0/0 Interface
16
Physical layer is Packet Over CRC4
clock master, linecode hdb3 , loopback none
section layer:
alarm: LOS
line layer:
alarm: none
path layer:
alarm: none
Procedure
Step 2 Run the controller e1 1/0/0 command on Router A to enter the CE1 interface view.
Step 3 Run the frame-format no-crc4 command on Router A to change the frame format to no-crc4.
After the preceding operations, the frame formats of both Routers are no-crc4. Users attached
to Router A access to the Internet at normal speeds. The fault is rectified.
----End
Summary
Services are properly processed only when the frame formats configured on interfaces at the two
ends of a CE1 link are the same.
1.2.11 Standby ATM Interface Cannot Go Up after the standby
interface Command Has Been Configured on the Active Interface
Fault Symptom
The router accesses an ATM network shown in Figure 1-8 through an ATM switch. The
router is connected to the ATM switch through an active link and a standby link. The active
interface is Serial 1/0/0 and its bandwidth is 2 Mbit/s. The standby interface is ATM 2/0/0 and
its bandwidth is 155 Mbit/s. The active link is connected and the standby link is removed. After
the active link fails, the standby link is connected. The standby ATM interface cannot go Up.
Figure 1-8 Networking diagram of the case where the standby ATM interface cannot go Up
after the standby interface command has been configured on the active interface
Serial1/0/0
ATM2/0/0
Router Switch
ATM network

Fault Analysis
1. Run the display this command in the view of Serial 1/0/0 on the router. The standby
interface ATM2/0/0 command has been configured to use ATM 2/0/0 as a backup for
Serial 1/0/0.
17
When both the active link and standby link are connected, the standby interface goes Up
at the data link layer if the active interface goes Down at the data link layer. If the standby
link is disconnected at the physical layer when the active link works properly and then is
reconnected after the active link fails, the backup function cannot take effect and thus ATM
2/0/0 cannot go Up at the data link layer.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface serial1/0/0 command to enter the serial interface view.
Step 3 Run the undo standby interface atm2/0/0 command to disable the ATM interface from serving
as the standby interface.
After the preceding operations, ATM 2/0/0 goes Up at the data link layer. The fault is rectified.
----End
Summary
Ensure that the standby interface is Up at the data link layer during the configuration of interface
backup; otherwise, the standby interface cannot work after the active interface fails.
1.2.12 Optical Module Failure Causes an Interface to Be Up and the
Other Interface to Be Physically Down at Two Ends of a Link
Context
Two routers are connected by using a multi-mode optical fiber. After a period of operation, the
indicator on router A is On but the physical status on the interface of router B is Down, indicating
that the link is disconnected.
Fault Analysis
1. Run the display this command in the interface view on Router B. The interface is not
configured with the shutdown or loopback command.
2. Run the shutdown command on the interface of Router B. The physical status of the
interface on Router A is Down. This indicates that the optical fiber is correctly connected.
3. Remove the optical module from the interface and then insert it to another interface on
Router B. The problem persists, indicating that the optical module fails.
Procedure
Step 1 Replace the optical module on Router B.
After the preceding operation, the link status becomes Up at both ends of the link. The fault is
rectified.
----End
Summary
The indicator on Router A is On, only indicating that Router A has received signals from
Router B. Without the help of an optical power meter, replace the optical module at one end and
18
then at the other end to check whether the RX port or the TX port becomes faulty in the case
that the optical fiber works properly.
19
2 Eth-Trunk Interface Troubleshooting
About This Chapter
2.1 Eth-Trunk Interface Cannot Forward Traffic
Troubleshooting - Physical Connection and Interfaces 2 Eth-Trunk Interface Troubleshooting
20
2.1 Eth-Trunk Interface Cannot Forward Traffic
2.1.1 Common Causes
After an Eth-Trunk interface is configured, it cannot forward traffic.
l Eth-Trunk member interfaces are faulty.
l Configurations of Eth-Trunk member interfaces on the two ends are inconsistent.
l The number of Up Eth-Trunk member interfaces is smaller than the lower threshold.
l Negotiation between member interfaces of the Eth-Trunk interface in static LACP mode
fails.
l BFD, which is used to detect an Eth-Trunk member interface, is incorrectly configured.
On the network shown in Figure 2-1, the Eth-Trunk interface cannot forward traffic.
Figure 2-1 Networking diagram of Eth-Trunk interfaces
RouterA RouterB
GE1/0/1
GE1/0/2
Eth-Trunk1
Eth-Trunk1
GE1/0/3
GE1/0/1
GE1/0/2
GE1/0/3

The troubleshooting roadmap is as follows:
l Check that Eth-Trunk member interfaces work properly.
l Check information about Eth-Trunk member interfaces on both ends.
l Check that the number of Up member interfaces is greater than the configured lower
threshold.
l Check that LACP negotiation succeeds if the Eth-Trunk interface is in static LACP mode.
l Check that BFD configurations are correct if BFD is configured to track the status of an
Eth-Trunk member interface.
Figure 2-2 shows the troubleshooting flowchart.
21
Figure 2-2 Troubleshooting flowchart for the fault that the Eth-Trunk interface cannot forward
traffic
Eth-Trunk
member interfaces
work properly?
Member
interfaces on both ends
are consistent?
Number of
Up member interfaces
is below the lower
threshold?
Negotiation
between Eth-Trunk
interfaces working in
static LACP mode
fails?
Collect information
Check physical links
connecting member
interfaces and rectify
the link fault
Change the lower
threshold
Locate the cause of the
negotiation failure and
modify the
configuration
Modify the
configuration
Eth-Trunk interface
cannot forward traffic
Yes
No
Seek technical support
No
End
Is fault rectified?
Is fault rectified?
Is fault rectified?
Is fault rectified?
Yes
Yes
Yes
Yes
Yes
No
No
No
No
BFD is
configured to track
the status of an Eth-
Trunk member
interface?
Check and modify BFD
configurations
Is fault rectified?
Yes
No
Yes
No
Yes
No
Yes
No

NOTE
22
Procedure
Step 1 Check that Eth-Trunk member interfaces work properly.
Run the display eth-trunk 1 command in any view to check the status of the Eth-Trunk interface.
[HUAWEI] display eth-trunk 1
Eth-Trunk1's state information is:
WorkingMode: NORMAL Hash arithmetic: According to flow
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 16
Operate status: down Number Of Up Port In Trunk: 0
--------------------------------------------------------------------------------
PortName Status Weight
GigabitEthernet1/0/1 Down 1
l If a member interface is Down, you need to troubleshoot the physical interface. For detailed
troubleshooting procedures, see "Physical Interconnection Troubleshooting".
l If all member interfaces are Up, go to Step 2.
Step 2 Check information about Eth-Trunk member interfaces on both ends.
l Check information about member interfaces of the Eth-Trunk interface on Router A.
[RouterA] display eth-trunk 1
Operate status: up Number Of Up Port In Trunk: 3
-------------------------------------------------------------------------------
-
GigabitEthernet1/0/1 Up 1
l Check information about member interfaces of the Eth-Trunk interface on Router B.
[RouterB] display eth-trunk 1
-------------------------------------------------------------------------------
-
l If the number of member interfaces of the Eth-Trunk interface on Router A is different
from that on Router B, add the required physical interfaces to the Eth-Trunk interface.
l If the number of member interfaces of the Eth-Trunk interface on Router A is the same as
that on Router B, go to Step 3.
Step 3 Check whether the Eth-Trunk interface is configured with a lower threshold of Up member
interfaces.
Run the display eth-trunk 1 command on Router A and Router B to view the configuration of
the Eth-Trunk interface.
--------------------------------------------------------------------------------
23
The preceding command output shows that the lower threshold of Up member interfaces of the
Eth-Trunk interface has been set to 4. However, the number of Up member interfaces of the Eth-
Trunk interface is actually 3, which causes the Eth-Trunk interface to go Down.
l If the Eth-Trunk interface is configured with a lower threshold of Up member interfaces
and the configured lower threshold is greater than the actual number of Up member
interfaces, set the lower threshold to a proper value.
l If the Eth-Trunk interface is not configured with a lower threshold of Up member interfaces,
go to Step 4.
Step 4 Check whether Eth-Trunk interfaces work in static LACP mode.
Run the display eth-trunk 1 command on Router A and Router B to view the configuration of
the Eth-Trunk interface.
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 32768 System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 16
--------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState Weight
GigabitEthernet1/0/1 Unselect 1GE 32768 264 305 11100010 1
Partner:
--------------------------------------------------------------------------------
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
GigabitEthernet1/0/1 0 0000-0000-0000 0 0 0 11100011
l If the Eth-Trunk interface is configured to work in static LACP mode and no physical
interface is selected, it indicates that LACP negotiation is unsuccessful. Possible causes for
unsuccessful LACP negotiation are as follows:
Member interfaces fail, causing timeout of LACP protocol packets.
In this case, you need to troubleshoot member interfaces.
The Eth-Trunk interface on one end is configured to work in static LACP mode, whereas
the Eth-Trunk interface on the other end is not.
Correct the configurations of the two ends of the Eth-Trunk link to make them
consistent.
After the configurations are corrected and LACP negotiation succeeds, the output of the
display eth-trunk 1 command is as follows:
[RouterB] display eth-trunk 1
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 32768 System ID: 0018-826f-fc7a
Least Active-linknumber: 1 Max Active-linknumber: 16
------------------------------------------------------------------------------
--
ActorPortName Status PortType PortPri PortNo PortKey PortState
24
Weight
GigabitEthernet1/0/1 Selected 1GE 32768 264 305 11111100 1
Partner:
------------------------------------------------------------------------------
--
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
GigabitEthernet1/0/1 32768 0018-823c-c473 32768 2056 305 11111100
If LACP negotiation fails after the configurations are corrected, go to Step 5.
l If the Eth-Trunk interface is not configured to work in static LACP mode, go to Step 5.
Step 5 Check whether BFD is configured to track the status of an Eth-Trunk member interface.
Run the display current-configuration command to view the configuration files of the devices
at the two ends of the Eth-Trunk link to check whether BFD is configured to track the status of
an Eth-Trunk member interface.
l If a device is configured with bfd Eth-Trunk bind peer-ip default-ip interface
gigabitethernet 1/0/1, it indicates that the device has been configured with BFD to track
the status of an Eth-Trunk member interface.
If the BFD configuration is modified but the commit command is not used, the member
interface of the Eth-Trunk interface will go Down. The output of the display interface
interface-type interface-number command in the interface view shows that this member
interface is Up.
For detailed information about BFD configurations, see the chapter "BFD Configuration"
in the NE80E/40E Configuration Guide - Reliability.
l If no device is configured with BFD to track the status of Eth-Trunk member interfaces,
go to Step 6.
CAUTION
Debugging affects the system performance. Therefore, after debugging, run the undo debugging
all command to disable it immediately.
l display interface interface-type interface-number
l display eth-trunk [ trunk-id [ interface interface-type interface-number | verbose ] ]
l debugging trunk lagmsg slot slot-id
l debugging trunk lagmsg
l debugging trunk state-machine
l debugging trunk lacp-pdu slot slot-id
l debugging trunk lacp-pdu
l terminal debugging
25
l terminal monitor
----End
None.
2.2.1 Certain Users Cannot Access the Internet by Dialing Up After
a Member Interface of the Eth-Trunk Interface Becomes Faulty
Fault Symptom
As shown in Figure 2-3, the NE80E/40E is connected to the authentication server through an
Eth-Trunk. Certain PPPoE users attached to the NE80E/40E cannot access the Internet by dialing
up. These users are widely distributed and do not reside in one physical area.
Figure 2-3 Networking diagram of user access
Dial-up user 1
DSLAM Router Server
Dial-up user 2
Dial-up user 3
Eth-Trunk

Fault Analysis
1. Check the MAC addresses of the users where faults occur. The result shows that these MAC
addresses are widely distributed and do not have common characteristics. Therefore, it can
be inferred that the NE80E/40E or the authentication server is not configured with
restrictions on these users.
2. Run the ping command to check the connectivity of each link between the user and the
authentication server. The result shows that packet loss occurs on the link connecting the
NE80E/40E and the authentication server.
26
3. Run the display interface interface-type interface-number command on the NE80E/40E
to check the status of each member interface.
The result shows that one member interface cannot forward data although the interface is
Up at the physical and link layers.
Load balancing is implemented on member interfaces of an Eth-Trunk interface based on the
Hash algorithm. Therefore, once a member interface is faulty, the traffic on the faulty interface
cannot be forwarded.
Procedure
Step 1 Run the shutdown command on the interface of the faulty link to shut down the link so that the
Eth-Trunk can sense the link fault.
Step 2 Replace the faulty link between the NE80E/40E and the authentication server.
After the preceding operations, users can normally access the Internet by dialing up. The fault
is rectified.
----End
Summary
l When users in different physical areas cannot access the Internet, check whether these users
have common characteristics, for example, whether their MAC addresses are close to each
other. If so, do as follows:
Check whether the link connecting the user is faulty.
Check whether a specific policy is configured on the NE80E/40E or the authentication
server to restrict users.
l When users that reside in different areas cannot access the Internet, check whether there is
a Trunk. If so, check the status of member interfaces. If a member interface is faulty, the
traffic on the faulty interface cannot be forwarded.
27
3 GE Interface Troubleshooting
About This Chapter
Troubleshooting - Physical Connection and Interfaces 3 GE Interface Troubleshooting
28
3.1.1 10GE Interfaces Connecting Two Devices Cannot Be Up
Fault Symptom
When two NE80E/40Es are connected through 10GE interfaces, the interfaces cannot be Up.
Fault Analysis
1. Run the display interface GigabitEthernet 1/0/0 command in the system view to view
interface information.
GigabitEthernet1/0/0 current state : DOWN
Description:TO[HUAWEI-A1]-10G-14/0/0
Route Port,The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-82b1-7c2d
The Transceiver Vendor Name is FINISAR CORP.
The Transceiver Vendor PN is FTLX1412M3BCL
BW: 10G, Transceiver Mode: SingleMode
The receiving optical power and transmitting optical power displayed through the Rx
Power and Tx Power items respectively are both in the normal range, which indicates that
the fault is not caused by optical power.
2. Replace the optical fiber. The fault persists, which indicates that the fault is not caused by
the optical fiber.
3. Replace the optical module. The fault persists, which indicates that the fault is not caused
by the optical module.
4. Check the boards on the two interconnected devices. It is found that the 10GE interface on
the local device is in the LAN transmission mode whereas the 10GE interface on the remote
device is in the WAN transmission mode. Therefore, it can be inferred that the 10GE
interfaces cannot be Up because their transmission modes do not match.
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 set transfer-mode wan command to set the transmission mode of the interface to WAN
so that the transmission modes of the two interfaces can match.
----End
Summary
When two interfaces are connected through 10GE interfaces whereas the 10GE interfaces cannot
be Up, you can check the following items to rectify the fault:
29
1. Optical power
2. Optical fiber
3. Optical module
4. Transmission modes of the two interconnected interfaces
10GE interfaces can work in either WAN or LAN transmission mode. In different modes,
physical frames are encapsulated in different manners. Therefore, a 10GE interface working in
WAN transmission mode cannot communicate with a 10GE interface working in LAN
transmission mode. In this case, when the two devices are connected through 10GE interfaces,
ensure that their transmission modes are the same.
3.1.2 Interconnected Interfaces Alternate Between Up/Down States
Fault Symptom
Two devices are directly connected through GE interfaces by optical fibers. The GE interfaces,
however,alternate between Up/Down states. The following log messages are displayed:
%Nov 12 11:00:10 2007 HUAWEI PHY/2/PHY:Slot=2;GigabitEthernet2/0/0: change status
to down
%Nov 12 11:00:11 2007 HUAWEI PHY/2/PHY:Slot=2;GigabitEthernet2/0/0: change status
to up
Fault Analysis
1. Run the display interface [ interface-type interface-number ] command in any view on the
two interconnected interfaces, and you can find that both interfaces receive CRC error
packets. The possible causes are as follows:
(1) Data transmission is interfered and error codes occur.
(2) The optical power is unstable.
(3) The transmit interface on the peer device fails.
(4) An error occurs during packet resolution on the local device.
2. Through the preceding log messages, you can find that the two interfaces do not turn Up
or Down at the same time.
If auto-negotiation is configured, the interconnected interfaces automatically send
negotiation frames afer receiving optical signals. If both interfaces receive negotiation
frames, they both go Up. In this troubleshooting case, the two interfaces do not turn Up or
Down at the same time, which indicates that one interface receives negotiation frames
whereas the other does not receive any. Therefore, it can be inferred that a fault occurs
during packet transmission over the link.
Through the preceding analysis, it can be determined that a fault occurs on the transmission
link. In this case, the following describes how to locate the fault on the transmission link:
3. Through on-site measurement, it is found that both the receive optical power of the two
interfaces is -20db, which meets the optical modules' requirement. Therefore, the possibility
of a module or optical fiber fault is ruled out.
4. Check the optical fibers and optical modules for other anomalies. You can find that the
fiber end is contaminated.
It can be identified that error codes occur on the receive interface due to contamination of the
fiber end.
30
Procedure
Step 1 After the fiber end is cleaned, the receive interface goes Up.
The fault is thus rectified.
----End
Summary
In the case of long-distance transmission, ensure that the optical fiber is bent at less than 90
degrees, free from damage or contamination, and properly connected.
3.1.3 Severe Packet Loss Occurs After the FE Optical Module Is
Mistakenly Inserted into a GE Optical Interface
Fault Symptom
Users connected to GE 1/0/0 on the board of the NE80E/40E report that the Internet is slow and
severe packet loss occurs.
Fault Analysis
1. Check logs on the NE80E/40E. No exception is displayed.
2. Run the display interface gigabitethernet1/0/0 command to check the interface status. It
is found that the interface and protocol are both Up and no CRC error occurs.
The maximum bandwidth of the interface is 1 Gbit/s whereas the maximum bandwidth of
the optical module is 155 Mbit/s. It can be inferred that the optical module mismatches the
interface, which causes severe packet loss.
Procedure
Step 1 Replace the FE optical module with a GE optical module and insert the GE optical module into
the interface. Then, users can access the Internet normally and the fault is rectified.
----End
Summary
The mismatch between the optical module and the interface causes severe packet loss. The
appearances of the FE optical module and the GE optical interface module are the same. Thus,
check the parameters of the optical module carefully before inserting the optical module into
the interface.
3.1.4 A Device Cannot Go Up Because the 10GE WAN Board Does
Not Match the Multi-mode Optical Module
Fault Symptom
Router A and Router B are connected through two 10GE WAN interfaces that are installed with
two multi-mode optical modules. Indicators on both interfaces are off, indicating that the status
of the two interfaces is Down.
31
Figure 3-1 Networking diagram for the problem that a device cannot go Up because the 10GE
WAN board does not match the multi-mode optical module
Router A Router B
GE1/0/1 GE1/0/2
Fault Analysis
1. Run the display interface gigabitethernet 1/0/1 command to check the interface status.
The command output shows that both the input optical power (Rx Power) and output optical
power (Tx Power) of the interface are in the normal range.
2. Replace the current multi-mode optical module and optical fiber with another multi-mode
optical module and optical fiber. The interface still cannot go Up.
3. Replace the current multi-mode optical module and optical fiber with a single-mode optical
module and optical fiber and the interface goes Up. Then, replace the single-mode optical
module and optical fiber with the multi-mode optical module and optical fiber, the fault
occurs again.
Because another two devices using 10GE WAN boards installed with multi-mode optical
modules can communicate on the current network, the possibility that 10GE WAN boards do
not support multi-mode optical modules is excluded. It is confirmed that the multi-mode optical
modules used on the current network may be from different manufacturers. Only optical modules
of certain manufacturers are applicable to both 10GE WAN boards and 10GE LAN boards, and
optical modules of other manufacturers are applicable to only 10GE LAN boards. For security,
use multi-mode optical modules on 10GE LAN boards rather than WAN boards or POS boards.
Procedure
Step 1 Replace 10GE WAN boards on the two devices with 10GE LAN boards.
----End
Summary
Using 10GE LAN boards rather than 10GE WAN boards on the devices connected through
multi-mode optical fibers is recommended. 10GE WAN boards are usually used for connecting
transmission devices.
32
4 ATM Interface Troubleshooting
About This Chapter
4.1 Two ATM Interfaces Fail to Ping Each Other
Troubleshooting - Physical Connection and Interfaces 4 ATM Interface Troubleshooting
33
4.1 Two ATM Interfaces Fail to Ping Each Other
4.1.1 Common Causes
l Optical fibers do not match optical modules on ATM interfaces.
l Optical fibers of ATM interfaces are damaged.
l The configurations on the interconnecting ATM interfaces are inconsistent. The frame
format, clock mode, or scrambling function on one interface is different from that on the
other interface.
After two NE80E/40Es are connected to each other using ATM interfaces and configured with
the ATM service, the two ATM interfaces fail to ping each other.
Figure 4-1 shows the troubleshooting flowchart.
34
Figure 4-1 Troubleshooting flowchart for the ping failure between interconnecting ATM
interfaces
The ATM
interfaces cannot
communicate with
each other
The
State of the
physical layer
is up
Check fibers and
other hardware
The problem is
solved?
The
configurations on
both ends are
consistent?
No
Reconfigure both
ends and enable the
m to be consistent
The problem is
solved?
No
No
No
Yes
The OAM is
initiated?
Initiate OAM and set
the frequencies on
both ends to be
consistent
The problem is
solved?
No
No
Yes
End
Yes
Yes
The ARP entries
are generated?
The problem is
solved?
No
No
Yes
Yes
The state of PVC is
up?
The problem is
solved?
No
Yes
Reconfigure both
ends and enable the
m to be consistent
The problem is
solved?
No
Check the count on
both ends
Yes
Yes
Yes
Yes
Seek technology
support
End
No
ARP troubleshooting

35
Context
NOTE
Procedure
Step 1 Check that the physical status of ATM interfaces is Up.
Run the display interface atm command to view physical status of the local ATM interface.
l If the current state field displays Administratively down, run the undo shutdown
command in the interface view to start the interface.
l If the current state field displays down, perform the following operations:
Check whether the ATM interface is connected to the peer end using optical fibers,
whether the optical fibers in the sending and receiving directions are properly connected
and securely inserted, and whether the related status indicator is on.
Check whether alarm information is displayed under the SDH alarm or SONET error
field.
If the preceding check items of the local ATM interface are normal, repeat the preceding
operations to check whether the physical status of the ATM interface on the peer end is Up.
If the fault persists, go to the next step.
Step 2 Check that configurations on the two ATM interfaces are consistent.
1. Run the display interface atm command to check whether the following configurations
on the two interfaces are consistent:
l If the Scramble fields on the two ends display different information, run the
scramble or undo scramble command to enable or disable the scrambling function on
the two interfaces.
l If the MTU fields on the two ends display different information, run the MTU command
on the two interfaces to configure a same MTU on the two ends.
l If the values of the clock fields on the two interfaces do not match each other, take
measures to ensure that:
If a device serves as data connection equipment (DCE), the ATM interface on the
device is configured to work in master clock mode.
If a device serves as data terminal equipment (DTE), the ATM interface on the device
is configured to work in slave clock mode.
If the two ATM interfaces are directly connected using optical fibers, or connected
based on Wavelength Division Multiplexing (WDM), one ATM interface is
configured to work in master clock mode, and the other one is configured to work
in slave clock mode.
If the two ATM interfaces are connected using a SONET or an SDH device, the two
ATM interfaces are configured to work in slave clock mode.
By default, an ATM interface works in master clock mode.
2. Run the display this command to check whether
the frame-format sonet field is configured on the two ATM interfaces. If configuration
inconsistency exists, run the frame-format command to configure the same encapsulation
mode on both ATM interface.
36
3. Run the display atm pvc-info command to check whether the ENCAP fields show that
the two ends use the AAL5 encapsulation mode for PVC. If the two ends use different
encapsulation modes, run the encapsulation command on the ATM interface views to
configure a same encapsulation mode.
Step 3 Check that the local end has the ARP entry corresponding to the peer end.
Run the display arp slot command to check whether the two ends learn ARP entries correctly.
If one end does not learn the ARP entry corresponding to the other end, locate the fault based
on "Troubleshooting-IP Forwarding and Routing".
Step 4 Check that permanent virtual channel (PVC) status on the two ends is Up.
Run the display atm pvc-info command to check whether the PVC STATE field displays
Up.
If the VPI or VCI values of the PVC on the two ends are different, run the pvc command in the
ATM interface views to configure a same VPI or VCI value.
Step 5 Check that OAM is enabled and OAM configurations are correct on the two ends.
Run the display this command on the ATM interface views to check whether OAM is enabled,
and whether OAM cell sending frequencies are consistent on the two ends.
If the peer end is enabled with the OAM F5 Loopback function, but the local end is not configured
with OAM or does not support response to OAM Loopback cells, the PVC will go Down. If the
OAM cell sending frequencies are inconsistent on the two ends, there is a possibility that the
PVC goes Down. (After being enabled with the OAM F5 Loopback function, the peer end will
continuously send OAM Loopback cells to the local end, and request for Replay packets from
the local end. If the peer end receives no response from the local end within a specific period,
it will send OAM RDI alarm cells. At the same time, the PVC will go Down.)
----End
None.
37

Troubleshooting - Physical Connection and Interfaces (V600R003C00 - 02)

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Troubleshooting - Physical Connection and Interfaces (V600R003C00 - 02)

Enviado por

Direitos autorais:

Formatos disponíveis

HUAWEI NetEngine80E/40E Router

Você também pode gostar