ATN 910&910I&910B&950B V200R003C10 Fault Diagnosis 01 (U2000)

ATN 910&910I&910B&950B Multi-Service Access
Equipment
V200R003C10
Fault Diagnosis
Issue 01
Date 2014-01-31
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. 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 01 (2014-01-31) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Equipment
Fault Diagnosis About This Document
About This Document
Purpose
This manual describes alarm shooting and diagnosis tools of U2000 for ATN.
The usage precautions are as follows:

l A device can store keys in plaintext, reversible algorithm encryption, or irreversible
algorithm encryption mode. The plaintext mode has the low security level, and the
irreversible algorithm encryption mode has the highest security level. Use different storage
modes for different scenarios. Exercise caution when using an insecure storage mode. The
system automatically selects the irreversible algorithm encryption mode to store local user
keys. Generally, the reversible algorithm encryption mode is used to store protocol keys to
meet interworking requirements.
l If the plaintext mode is used, a password is stored in plaintext in the configuration file. This
results in high security risks. The plaintext mode applies only to scenarios with special
requirements, such as compatibility and interworking requirements.
Related Version
The following table lists the product version related to this document.
Product Name Version
l ATN 910 V200R003C10

l ATN 910I
l ATN 910B
l ATN 950B
Huawei iManager U2000 V200R001C00
Intended Audience
This document is intended for:
l System maintenance engineers
Issue 01 (2014-01-31) Huawei Proprietary and Confidential ii

Equipment
Fault Diagnosis About This Document
Symbol Conventions
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
GUI Conventions
Convention Description
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 01 (2014-01-31)

This document is the first release of the V200R003C10 version.
Issue 01 (2014-01-31) Huawei Proprietary and Confidential iii

Equipment
Fault Diagnosis Contents
Contents
About This Document.....................................................................................................................ii

1 Roadmap and Process...................................................................................................................1
2 Locating Faults Based on Alarm Information..........................................................................5
2.1 Common Alarm Locating...............................................................................................................................................6
2.2 Locating Performance Faults..........................................................................................................................................8
2.3 Locating Service Faults................................................................................................................................................10
2.4 Top Alarm Handling Examples....................................................................................................................................14
2.4.1 Interface CRC Error...................................................................................................................................................16
2.4.2 Alarm that an NE Is Offline (No Response to Ping).................................................................................................17
2.4.3 Fan Invalid.................................................................................................................................................................19
2.4.4 Board Power Off........................................................................................................................................................20
2.4.5 Optical Remove.........................................................................................................................................................20
2.4.6 Optical Invalid...........................................................................................................................................................21
2.4.7 Alarm that the Tx Power of an Optical Module Is Greater Than the Maximum Value............................................22
2.4.8 Alarm that the Tx Power of an Optical Module Is Less Than the Minimum Value.................................................24
2.4.9 Alarm that the Rx Power of an Optical Module Is Greater Than the Maximum Value............................................25
2.4.10 Alarm that the Rx Power of an Optical Module Is Less Than the Minimum Value...............................................28
2.4.11 Alarm that the Optical Module Is Not Functioning Properly..................................................................................31
2.4.12 BGP Status Changed...............................................................................................................................................31
2.4.13 Tunnel Group Down................................................................................................................................................47
2.4.14 Alarm that an MPLS Tunnel Is Down.....................................................................................................................50
2.4.15 MPLS LDP Session Down......................................................................................................................................59
2.4.16 Tunnel Primary LSP Down.....................................................................................................................................61
2.4.17 Tunnel Hot-standby LSP Down..............................................................................................................................66
2.4.18 L3VPN VRF Down.................................................................................................................................................72
2.4.19 Alarm that a CCC VC Is Down...............................................................................................................................76
2.4.20 VPLS VC Down......................................................................................................................................................78
2.4.21 Alarm About Clock Source Switching....................................................................................................................83
3 Locating Faults Based on Path Visualization.........................................................................87

4 Common Fault Diagnosis Tools...............................................................................................91
4.1 OAM Diagnosis............................................................................................................................................................92
Issue 01 (2014-01-31) Huawei Proprietary and Confidential iv

Equipment
Fault Diagnosis Contents
4.2 Test and Diagnosis........................................................................................................................................................98

4.3 NE-side Alarm Fault Detection..................................................................................................................................100
Issue 01 (2014-01-31) Huawei Proprietary and Confidential v

Equipment
Fault Diagnosis 1 Roadmap and Process
1 Roadmap and Process
This topic describes the types, symptoms, and troubleshooting suggestions for faults occurred
on an IP network.
The U2000 provides a complete set of fault diagnosis methods based on fault symptoms.
Issue 01 (2014-01-31) Huawei Proprietary and Confidential 1

Equipment
Figure 1-1 IP network troubleshooting process
Start
Receive No
alarm?
Yes
Locating Faults Based on Locating Faults Based on

Alarm Information Path Visualization
Yes
Resolved?
No
Performance Service Others
Locating Locating Manual

Performance Faults Service Faults Handling
End
Trouble Symptom Suggestion

shootin
g
Method
Locate Alarms are generated on the On the Browse Current Alarm tab page,
faults U2000 by IP NEs. select the alarm. For a correlative alarm,
based on NOTE select the associated root alarm.
alarm This symptom is applicable to the Right-click and choose Fault Locate from
informat NEs for which the value of Alarm
the shortcut menu to obtain the fault detection
ion. Source is the name of an NE\CX
\ATN\PTN6900\ME\S series NE. result and handling suggestions.
For details, see 2.1 Common Alarm
Locating.

Equipment
Trouble Symptom Suggestion

shootin
g
Method
Performance alarms or TCAs are If the collected performance data exceeds the
generated on the U2000. threshold, a TCA is generated on the U2000.
NOTE View alarm details and jump to the
The names of these alarms contain performance monitoring module to query
Performance or threshold, for
historical and real-time performance data,
example, Port Performance
Minor Alarm or The number of analyze threshold-crossing causes, and
BRAS accesses exceeds the provides a network optimization solution.
threshold. For details, see 2.2 Locating Performance
Faults.
Service-related alarms are The U2000 provides the fault locating

generated on the U2000. function for tunnel, PWE3, L3VPN, and
Refer to the Trail Domain to VPLS services. This method provides fault
check whether the alarm affects locating for service faults. Check Steps for
services, as shown in Figure fault locating specifies the check items and
1-2. sequence and no configuration is required.
This ensures comprehensive diagnosis and
reduces troubleshooting complexity. Various
types of ping testing, including LSP Ping,
MAC Ping, VCCV Ping, and VRF Ping, to
check connectivity at various layers are
supported. In addition, traceroute operations
and collection of key service information
such as LDP sessions are available to locate
positions on which faults occur.
For details, see 2.3 Locating Service
Faults.
Locate Path visualization can be used to If the IP/MPLS fault diagnosis function is
faults locate and troubleshoot faults enabled, the U2000 automatically discovers
based on including incontinuous calls or and displays service paths in the topology
path voice services of poor quality view after you specify the source and sink
visualiza caused by packet loss or delay. interfaces or set desired IP address. In
tion addition, the Node, Link, Optical Module
Information, and Alarm tabs display
performance data, basic information about
optical modules, and alarm records. All these
data provides a reference for fault locating
and one-click fault diagnosis.
For details, see 3 Locating Faults Based on
Path Visualization.

Equipment
Figure 1-2 Viewing the trail domains of faults

Equipment
Fault Diagnosis 2 Locating Faults Based on Alarm Information
2 Locating Faults Based on Alarm Information
About This Chapter
The U2000 supports monitoring of network-wide alarms and notifies maintenance engineers of
the alarms in time in order to ensure effective troubleshooting. Alarm information is the first
choice for maintenance engineers to obtain fault information. This topic describes fault diagnosis
roadmaps for different alarm types.
2.1 Common Alarm Locating

This topic describes the common alarm locating. The U2000 can perform detection items for
common alarms and display the detection results and handling suggestions to help rapidly locate
and rectify faults.
2.2 Locating Performance Faults

The names of these performance alarms contain Performance or threshold, for example, Port
Performance Minor Alarm or The number of BRAS accesses exceeds the threshold.
2.3 Locating Service Faults

Service alarms are the alarms that the U2000 receives from IP NEs, namely, alarms for which
the values of Trail Domain on the Browse Current Alarm tab page are specific services. For
example, if the value of Trail Domain is VPLS, the alarm is a VPLS service alarm.
2.4 Top Alarm Handling Examples

This topic provides fault locating examples for top alarms.

Equipment
2.1 Common Alarm Locating

This topic describes the common alarm locating. The U2000 can perform detection items for
common alarms and display the detection results and handling suggestions to help rapidly locate
and rectify faults.
Context
The roadmap for locating alarms is as follows:
1. On the Browse Current Alarm tab page, select the alarm. For a correlative alarm, select
the associated root alarm.
2. Right-click and choose Fault Locate from the shortcut menu to obtain the fault detection
result and handling suggestions.
3. After the alarm is cleared, perform the associated detection items and check whether the
check result is normal.
In the Fault Locate window, the following alarms support fault detection:
l Board Removed
l Subcard Removed
l Physical Port Down
l Link Down
l IS-IS Adjacency Changes
l BGP Status Changes
l OSPF Adjacency Changes
l OSPF Interface Status Changes
l PW VC Down
Procedure
Step 1 View alarms.
1. Choose Fault > Browse Current Alarm from the main menu.
2. In the Filter dialog box, set filter criteria. For example, set filter criteria to
Unacknowledged and Uncleared and Equipment to view only unacknowledged and
uncleared alarms and equipment alarms. Click OK.

Equipment
Step 2 On the Browse Current Alarm tab page, elect the alarm, right-click, and choose Fault
Locate from the shortcut menu.
NOTE
The alarms for which the value of Status is Cleared and the alarm record is in the light green background
do not need to be handled. If such an alarm is selected, the shortcut menu option Fault Locate is unavailable.
l The Fault Locate dialog box lists fault detection items for common IP NE alarms. You can
perform fault detection and view detection results in this dialog box, and rectify faults based
on fault locating results.
NOTE
If the Fault Locate dialog box lists detection items, keeping the dialog box unclosed during fault
rectification is recommended. After performing operations described in the handling suggestions, return
to the Fault Locate dialog box and click Refresh All for alarms for which the U2000 can automatically
perform detection items, and check whether the fault detection result is normal. You cannot right-click a
Cleared alarm in the alarm list and choose fault locating option from the shortcut menu. You can only
refresh Cleared alarms in the opened Fault Locate dialog box.
l The Locate Fault dialog box does not list fault detection items for non-common IP NE
alarms. You can rectify faults based on handling suggestions.

Equipment
----End
2.2 Locating Performance Faults

The names of these performance alarms contain Performance or threshold, for example, Port
Performance Minor Alarm or The number of BRAS accesses exceeds the threshold.
Prerequisites
The names of these alarms contain Performance or threshold, for example, Port Performance
Minor Alarm or The number of BRAS accesses exceeds the threshold.
Performance monitoring instances are started on the Performance Management page and
Threshold is set for performance indicators. If an indicator value exceeds the threshold, a
performance TCA is generated and reported to the U2000.
Procedure
Step 1 Choose Fault > Browse Current Alarm from the main menu.
Step 2 Select a performance TCA and view alarm details.
l In the Details area, view alarm details, including the resources for generating the alarm, the
associated alarm indicators, indicator thresholds, and indicator values at the time when the
alarm is generated.

Equipment
Check whether the value of Threshold is set properly.

If the value of Threshold is not set properly, change the value of Threshold on the
Performance Management page.
If the value of Threshold is set properly, refer to the alarm causes to adjust the hardware
or services. For example, if the bandwidth indicator remains exceeding the threshold,
increase the link bandwidth.
l In the Handling Suggestions area, view suggestions on the alarm. Click Click here to show
detail Information to view suggestion details.
Step 3 View real-time and historical performance data to check whether the alarm is generated
continuously and provides the associated measures.
1. Select a performance TCA, right-click, and choose Performance > Monitor Real-Time
Performance from the shortcut menu.
2. In the RPT area, check whether the performance indicator remains exceeding the threshold.

Equipment
3. Select an alarm, right-click, and choose Performance > Query Performance Data from
the shortcut menu.
4. In the Browse Historical Performance Data dialog box, view historical data about the
performance indicator.
NOTE
l If the performance indicator exceeds the threshold only at a specific time point, the cause of the
fault may be that the device or network becomes abnormal occasionally and no measure needs
to be taken.
l If the performance indicator remains exceeding the threshold for a long time, refer to the alarm
cause to adjust the hardware or services. For example, if the bandwidth indicator remains
exceeding the threshold, increase the link bandwidth.
----End
2.3 Locating Service Faults

Service alarms are the alarms that the U2000 receives from IP NEs, namely, alarms for which
the values of Trail Domain on the Browse Current Alarm tab page are specific services. For
example, if the value of Trail Domain is VPLS, the alarm is a VPLS service alarm.
Procedure
Step 1 Perform the following operations to locate desired service alarms:
1. Choose Fault > Browse Current Alarm from the main menu.

Equipment
2. In the Filter dialog box, set filter criteria. For example, set filter criteria to
Unacknowledged and Uncleared to view only unacknowledged and uncleared alarms.
Click OK.
3. On the Browse Current Alarm tab page, click the Trail Domain column to sort the
attribute values and locate the service-affecting alarm. Then right-click and choose Alarm
Affect Object specific service from the shortcut menu to switch to the associated service
management window.
NOTE
View the Details and Handling Suggestions tab pages to learn about the alarm causes and handling
methods.
Step 2 Perform the following operations to locate and rectify faults:

If you have determined that the fault point is a VSI (for VPLS services), PW (for VPLS or PWE3
services), or VRF (for L3VPN services), select the desired service in the service management
window, click the Topology tab, select the desired object such as a VSI, PW, or VRF, right-
click, and choose Fast Diagnose from the shortcut menu. Then the fault diagnosis starts. If the
fault point is not a VSI, PW, or VRF, perform the following operations:
1. Select the desired service in the service management window, right-click, and choose Test
and Check from the shortcut menu.
Locating a VPLS service fault is used an example to describe the procedure. The locating
procedure for a tunnel, VPLS, or L3VPN service fault is the same.

Equipment
2. On the Configuration tab page, select the trail to be commissioned. On Diagnosis

Option tab page, select Fault Check.
l With the predefined check items and sequences of the U2000, the Fault Check function
checks VPLS services comprehensively, simplifying the configuration for fault locating
and implementing one-click fault locating. Check Steps for fault locating are sequenced
logically. You can reference it for troubleshooting.
l One or more check items can be specified. For example, you can select Query LSP
Information and LSP Ping to check VPLS services.

Equipment
3. Click Run to perform test on one or more trails to be commissioned.

4. After fault locating is complete, view the result on the Result tab page. Then rectify the
fault based on the result.
On the Result tab page, you can check whether the testing operations succeed. For details,
click the ... button under Details.

Equipment
5. View the topology of checked trails in the topology view for the check result. Select the
faulty NE in the topology, right-click, and choose OAM Tools or Collect Information
from the shortcut menu to further detect the NE.
NOTE
l The topology is displayed on the Check Result tab page only when the diagnosis item is set to
Fault Check.
l The check items displayed when you right-click in the topology view are the same as those
described in Step 2.2. The navigation path here is to facilitate the single-NE check.
----End
Follow-up Procedure
In routine service management, you can perform the following operations to diagnose services
on a daily, weekly, or monthly basis.
Select the desired service in the service management window, right-click, and choose
Diagnose > Create Test Suit from the shortcut menu. Set the service diagnosis period to one
day, one week, or one month.
2.4 Top Alarm Handling Examples

This topic provides fault locating examples for top alarms.
Alarm Type Symptom Reference Topic
Physical entity The interface CRC is incorrect. 2.4.1 Interface CRC Error
alarm
The NE is offline or does not 2.4.2 Alarm that an NE Is
respond to the ping operation. Offline (No Response to Ping)

Equipment
The fan is faulty. 2.4.3 Fan Invalid
The board is powered off. 2.4.4 Board Power Off
The optical module is removed. 2.4.5 Optical Remove
The optical module is faulty. 2.4.6 Optical Invalid
The physical port is down. 2.1 Common Alarm Locating
The link is down. 2.1 Common Alarm Locating
The transmit power of the optical 2.4.7 Alarm that the Tx Power
module is greater than the of an Optical Module Is Greater
maximum value. Than the Maximum Value
The transmit power of the optical 2.4.8 Alarm that the Tx Power
module is lower than the of an Optical Module Is Less
minimum value. Than the Minimum Value
The receive power of the optical 2.4.9 Alarm that the Rx Power
module is greater than the of an Optical Module Is Greater
maximum value. Than the Maximum Value
The receive power of the optical 2.4.10 Alarm that the Rx Power
module is lower than the of an Optical Module Is Less
maximum value. Than the Minimum Value
The optical module does not 2.4.11 Alarm that the Optical
function properly. Module Is Not Functioning
Properly
Routing protocol The IS-IS neighbor relationship 2.1 Common Alarm Locating
alarm cannot be established.
The BGP status changes. 2.4.12 BGP Status Changed
The IS-IS neighbor relationship 2.1 Common Alarm Locating

changes.
The OSPF neighbor status 2.1 Common Alarm Locating

changes.
The OSPF interface status 2.1 Common Alarm Locating

changes.
MPLS tunnel alarm The tunnel group is disconnected. 2.4.13 Tunnel Group Down
The MPLS LDP session is Down. 2.4.15 MPLS LDP Session

Down
The active LSP for the MPLS 2.4.16 Tunnel Primary LSP
tunnel is disconnected. Down

Equipment
The hot-standby LSP for the 2.4.17 Tunnel Hot-standby LSP

MPLS tunnel is disconnected. Down
The MPLS tunnel is Down. 2.4.14 Alarm that an MPLS

Tunnel Is Down
VPN service alarm The L3VPN VRF is Down. 2.4.18 L3VPN VRF Down
The CCC VC is Down. 2.4.19 Alarm that a CCC VC Is

Down
The PW VC is Down. 2.1 Common Alarm Locating
The VPLS VC is Down. 2.4.20 VPLS VC Down
Clock alarm The clock source is switched. 2.4.21 Alarm About Clock
Source Switching
2.4.1 Interface CRC Error
Description
This alarm is generated when the number of interface CRC errors exceeds the preset threshold
in a specified period.
Attribute
Alarm ID Alarm Severity Alarm Type
1103100 Minor Processing
Impact on the System

Some service data on the interface is lost.
Possible Causes
l The optical module does not function properly.
l The fiber does not function properly.
l The number of packets discarded because of CRC failures exceeds the upper threshold.
l Another transmission medium, such as an ODF, exists on the transmission path.
Procedure
Step 1 View If Name and If Index in the Location Information field of the alarm record. Select the
alarm, right-click, and choose Locating in NE Panel from the shortcut menu to locate the port

Equipment
on the NE panel. View Operating Status of the port. If the operating status is physical Down,
proceed to next step.
Step 2 Replace the optical module, and check whether the alarm has been cleared. If interface CRC
succeeds, the fault has been rectified. If the fault persists, go to Step 3.
Step 3 Replace the fiber, and check whether the fault has been rectified. If interface CRC succeeds, the
fault has been rectified.
Step 4 Check whether another medium exists on the transmission path. If interface CRC succeeds, the
fault has been rectified. If the fault persists, collect the alarm information, logs, and
configurations of the NE and contact Huawei technical support engineers.
----End
2.4.2 Alarm that an NE Is Offline (No Response to Ping)
Description
This alarm is generated in any of the following situations:
l Multiple NEs are disconnected from the U2000.

NE icons turn gray in the Main Topology view, and multiple NE offline alarms are
generated.
l A single NE is disconnected from the U2000.
The NE icon turns gray on the Main Topology.
l NEs go offline frequently.
NE offline alarms are generated frequently and then cleared automatically by the U2000.
Attribute
1100454 Major Communication

-
Possible Causes
l The possible causes of the problem where most NEs are disconnected from the U2000 are
as follows:
A network fault occurs. For example, an NE does not function properly or a network
cable connected to the U2000 becomes loose.
The firewall rules for the U2000 server or NEs are changed.
The system on the U2000 server functions abnormally.
Intermittent interruption or congestion occurs on the network, resulting in NEs
becoming frequently disconnected from the U2000.

Equipment
l The possible causes of the problem where an NE is disconnected from the U2000 are as
follows:
The NE does not function properly, or NE configurations such as SNMP and ACL
settings are changed, but the changes are not synchronized with the U2000.
The network on which the NE resides does not function properly.
Procedure
Step 1 Select the alarm, right-click, and choose Locate in Topology from the shortcut menu to start
the NE Explorer.
Step 2 Run the ping command on the U2000 to check whether the U2000 server can ping the problem
NEs.
1. Select the problem NEs on the U2000 Main Topology, right-click, and choose Tool >
Ping from the shortcut menu.
l If the U2000 server can ping the problem NEs, the network between the U2000 server
and NEs has been torn down for an unspecified length of time. Wait several minutes.
If the NEs are still disconnected from the U2000, collect log information about the NE
Explorer.
l If the U2000 server cannot ping the problem NEs, go to the next step.
2. Check whether the interface configurations such as the IP address and mask on the U2000
server are correct. This operation applies only to the Solaris operating system.
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.112.167.21 netmask fffffc00 broadcast 10.112.167.255
ether 0:14:4f:72:f1:f4
l If the interface configurations are incorrect, correct the errors.

Equipment
l If the interface status is Down, check whether the switch connected directly to the U2000
server is functioning properly. If the switch is functioning properly, run the ifconfig
bge0 up command to change the interface status to Up.
3. Check the routing table for the U2000 server.
Run the netstat -rn command to view routing entries and check whether entries for the
problem NEs exist.
Step 3 If the problem persists, collect the alarm information, logs, and NE configurations and contact
Huawei technical support engineers.
----End
2.4.3 Fan Invalid
Description
This alarm is generated when the FAN does not function properly.
Attribute
2505238 Major Equipment

If the U2000 is equipped with a standby FAN, the alarm does not affect services on devices.
However, if the temperature of the telecommunications room exceeds the upper limit, the
temperature of the FAN increases and as a result the system does not work properly.
Possible Causes
Possible causes are as follows:
l The 48 V power supply of the FAN does not function properly. Power supply problems are
the most common cause of this alarm.
l The detection circuit of the FAN does not function properly.
Procedure
Step 1 Refer to the alarm information to locate the FAN slot.
Step 2 Check whether a 48 V power supply fault has generated the alarm.
Step 3 If the power supply is normal, replace the FAN.
----End

Equipment
2.4.4 Board Power Off
Description
This alarm is generated when a board is powered off.
Attribute

3069131 Major Equipment

All services on the board are switched or interrupted.
Possible Causes
l The board is powered off manually.
l The board is powered off for unknown reasons. For example, the cable connected to the
interface may have become loose.
Procedure
Step 1 Locate the board slot based on the alarm information.
Step 2 Check whether the board has been powered off manually. If it has, power on the board again. If
it has not, go to the next step.
Step 3 Check whether the cable is loosely connected to an interface. If it is, connect the cable to the
interface securely. If it is not, go to the next step.
Step 4 If the problem persists, collect alarm information and logs and contact Huawei technical support
engineers.
----End
2.4.5 Optical Remove
Description
This alarm is generated when an optical module is removed.
Attribute
2505220 Critical Equipment

Equipment

If the optical interface is enabled with a protocol or configured with a tunnel, services on the
interface may be switched or interrupted after the optical module is removed.
Possible Causes
The optical module is manually removed or loosely connected.
Procedure
Step 1 Check whether the interface is properly connected to the optical module and whether the slot
and subcard of the interface are correct based on the alarm information.
Step 2 Check whether the optical module is removed. If so, insert the optical module again. If not, go
to the next step.
Step 3 Collect alarm information and logs and contact Huawei technical support engineers.
----End
2.4.6 Optical Invalid
Description
This alarm is generated when the optical module is not functioning properly.
Attribute

Services on the optical module may be affected; as a result, code error or packet loss may occur
and services may be interrupted.
Possible Causes
The possible causes are as follows:
l The optical module components are faulty.

l The input power for the optical module exceeds the threshold.
l The fiber does not function properly.

Equipment
Procedure
Step 1 View PhysicalName and FaultCause in the Location Information field of the alarm record.
Select the alarm, right-click, and choose Locating to NE Panel from the shortcut menu to locate
the optical module interface on which the alarm is generated.
Step 2 Replace the optical module for the local interface and check whether the alarm has been cleared.
If not, go to the next step.
Step 3 Replace the fiber and check whether the alarm has been cleared. If not, go to the next step.
Step 4 Check whether the alarm is generated on the peer interface and whether the input powers for
optical modules on both ends are consistent. Replace the optical module for the peer interface
and check whether the alarm has been cleared. If not, go to the next step.
Step 5 Collect alarm information and logs and contact Huawei technical support engineers.
----End
2.4.7 Alarm that the Tx Power of an Optical Module Is Greater Than

the Maximum Value
Description
This alarm is generated if the Tx power of an optical module is greater than the maximum value.
The Tx power of an optical module must be within a specified range. This ensures that the peer
end properly receives and processes signals.
Attribute
3067694 Major NE

All the services running on the port where the optical module is inserted are interrupted.
Possible Causes
The optical module does not function properly.
Procedure
Step 1 Obtain information about the relevant optical module and port based on the alarm information.
Step 2 In the NE Explorer, choose Device Management > Optical Power Management from the
service tree. On the Optical Power Management tab page, view optical module information
about the port. If the Tx power of the port is within the specified range, go to Step 4.
Alternatively, select an optical module interface, right-click, and choose Monitor Real-time
Performance from the shortcut menu to view the change trend of the Tx power.

Equipment
Figure 2-1 Viewing optical module information
Figure 2-2 Viewing performance data
Step 3 Replace the optical module, and check whether the alarm has been cleared and no longer occurs.
Step 4 If the alarm persists, collect alarm, log, and configuration information, and contact Huawei
technical support engineers.
----End

Equipment
2.4.8 Alarm that the Tx Power of an Optical Module Is Less Than

the Minimum Value
Description
This alarm is generated if the Tx power of an optical module is less than the minimum value.
The Tx power of an optical module must be within a specified range. This ensures that the peer
end properly receives and processes signals.
Attribute
3067695 Major NE

All the services running on the port where the optical module is inserted are interrupted.
Possible Causes
The optical module does not function properly.
Procedure
Step 1 Obtain information about the relevant optical module and port based on the alarm information.
Step 2 In the NE Explorer, choose Device Management > Optical Power Management from the
service tree. On the Optical Power Management tab page, view optical module information
about the port. If the Tx power of the port is within the specified range, go to Step 4.
Performance from the shortcut menu to view the change trend of the Tx power.

Equipment
Step 3 Replace the optical module and check whether the alarm has been cleared.
----End
2.4.9 Alarm that the Rx Power of an Optical Module Is Greater Than

the Maximum Value
Description
This alarm is generated if the Rx power of an optical module is greater than the maximum value.
The Rx power of an optical module must be within a specified range. This ensures that the optical
module properly processes signals. If the problem that the Rx power of an optical module is
greater than the maximum value persists for a long period of time, the optical module will be
damaged.
Attribute
3067696 Major NE

All the services running on the port where the local optical module is inserted are interrupted.

Equipment
Possible Causes
l The local optical module does not function properly.
l The peer optical module does not support the actual transmission distance.
l The peer optical module is damaged.
Procedure
Step 1 In the NE Explorer of the local NE, choose Device Management > Optical Power
Management from the service tree. On the Optical Power Management tab page, view optical
module information about the local port. If the Rx power of the port is within the specified range,
go to Step 6.
Performance from the shortcut menu to view the change trend of the Rx power.

Equipment
Step 2 Obtain information about the relevant port based on the alarm information and view the relevant
link information in the topology view. Then obtain information about the peer NE and port based
on the link.
Figure 2-7 Viewing link information in the topology view

Equipment
Step 3 In the NE Explorer of the peer NE, choose Device Management > Optical Power
Management from the service tree to query information about the peer optical module and check
whether the optical module supports the actual transmission distance.
Step 4 The peer optical module may be damaged. Check whether the alarm that the Tx power of an
optical module is greater than the maximum value is generated. For details, see 2.4.8 Alarm
that the Tx Power of an Optical Module Is Less Than the Minimum Value. If this alarm is
generated, replace the peer optical module and check whether the alarm has been cleared.
Step 5 Replace the local optical module and check whether the alarm has been cleared.
----End
2.4.10 Alarm that the Rx Power of an Optical Module Is Less Than

the Minimum Value
Description
This alarm is generated if the Rx power of an optical module is less than the minimum value.
The Rx power of an optical module must be within a specified range. This ensures that the optical
module properly processes signals.
Attribute
3067697 Major NE

1. If the port where the local optical module is inserted is not in use, this alarm has no impact
on the system.
2. If this port is in use, all the services running on the port are interrupted.
Possible Causes
l The local port is not connected to any fiber.
l The local optical module does not function properly.
l The peer optical module does not support the actual transmission distance.
l The peer optical module does not function properly.
Procedure
Step 1 In the NE Explorer of the local NE, choose Device Management > Optical Power
Management from the service tree. On the Optical Power Management tab page, view optical
module information about the local port. If the Rx power of the port is within the specified range,
go to Step 8.

Equipment
Performance from the shortcut menu to view the change trend of the Rx power.
Step 2 Obtain information about the relevant port based on the alarm information and view the relevant
link information in the topology view. Then obtain information about the peer NE and port based
on the link.

Equipment
Figure 2-10 Viewing link information in the topology view
Step 3 Check whether the local and peer ports are in use and whether the ports are properly connected
with a fiber. If the ports are in use but no fiber exists between them, connect a fiber to both ports
and check whether the alarm has been cleared.
Step 4 Check whether the fiber is functioning properly. If not, replace the fiber and check whether the
alarm has been cleared.
Step 5 Replace the local optical module and check whether the alarm has been cleared.
Step 6 In the NE Explorer of the peer NE, choose Device Management > Optical Power
Management from the service tree to query information about the peer optical module and check
whether the optical module supports the actual transmission distance.
Step 7 The peer optical module may be damaged. Check whether the alarm that the Tx power of an
optical module is less than the minimum value is generated. For details, see 2.4.8 Alarm that
the Tx Power of an Optical Module Is Less Than the Minimum Value. If this alarm is
generated, replace the peer optical module and check whether the alarm has been cleared.
----End

Equipment
2.4.11 Alarm that the Optical Module Is Not Functioning Properly
Description
This alarm is generated when the physical entity of a service subboard is faulty because the
optical module is not functioning properly.
Attribute

The services on the board are affected. The bit error or error packets may be generated, and the
services may be interrupted.
Possible Causes
The optical module on the service subboard is not functioning properly.
Procedure
Step 1 Replace the fiber. Choose Fault > Browse Current Alarm from the main menu. In the dialog
box that is displayed, set the filter criteria. Check whether the alarm is cleared.
Step 2 Select the alarm, right-click, and choose Locate in Topology from the shortcut menu. In the
Main Topology, select the link connected to the abnormal optical module, right-click, and choose
Object Attributes from the shortcut menu.
Step 3 In the Attribute dialog box, check the status of the destination port. If an alarm is generated,
replace the optical module on the destination port. Check whether the alarm is cleared as Step
1.
Step 4 In the Attribute dialog box, check the status of the source port. If an alarm is generated, replace
the optical module on the source port. Check whether the alarm is cleared as Step 1.
Step 5 If the fault persists, collect the alarm information, logs, and configurations of the NE and contact
Huawei technical support engineers.
----End
2.4.12 BGP Status Changed
Description
This alarm is generated when the BGP finite state machine (FSM) moves from a higher numbered
state, namely, Openconfirm or Established, to a lower numbered state.

Equipment
Attribute
1100476 Critical Communication

The BGP peer connection is torn down, the BGP route from the peer is withdrawn, and packet
forwarding based on the BGP route fails.
Possible Causes
The possible causes are as follows:
l The BGP hold timer times out and Keepalive packets are not received.
l Incorrect BGP packets are received.
l The BGP peer relationship is reset and automatically interrupted.
l The Notification packet from a peer is received.
Procedure
Step 1 View BGP Peer IP in the Location Information field of the alarm record. Select the alarm,
right-click, and choose Locating to NE Panel from the shortcut menu to start the NE Explorer.
Step 2 Check the Error field in the BGP peer log information. Error Code and Sub Error Code in
the received Notification packet are displayed in the [ErrorCode][ErrorSubCode] format.
1. Choose Route Management > BGP Route > BGP Instance from the service tree.
2. Click Query.
3. In the Peer area on the Peer(Group) page, select a peer record, right-click, and choose
View Running Information > BGP Peer Log Information from the shortcut menu.
NOTE
The selected peer record is the record associated with BGP Peer IP in the Location Information
field.
4. In the BGP Peer Log Information dialog box, click Display.
The error information is in the [ErrorCode][ErrorSubCode] format.
l If the error code of the Notification packet is 1, BGP has received packets with incorrect
packet headers. Go to step 20.
l If the error code of the Notification packet is 2, BGP has received incorrect Open packets.
Go to step 20.
l If the error code of the Notification packet is 3, BGP has received incorrect Update packets.
Go to step 20.
l If the error code of the Notification packet is 4, the BGP hold timer times out and Keepalive
packets are not received. Go to step 4.
l If the error code of the Notification packet is 5, the BGP FSM does not function properly.
Go to step 20.

Equipment
l If the error code of the Notification packet is 6, go to step 2.
Step 3 If the value of Error Code in the Result area in the BGP Peer Log Information dialog box is
6, the BGP disconnection occurs because BGP tears down the connection. Check the
Notification field and determine whether the Notification packet is sent by the NE that generates
the alarm.
l If Send Notification is displayed, the local NE sends the Notification packet. Go to step 3.
l If Receive Notification is displayed, the local NE receives the Notification packet. Go to
step 19.

Equipment
Step 4 In the Result area in the BGP Peer Log Information dialog box, click , search for the reset
bgp all and reset bgp ipv4-address commands, and check the log to determine whether BGP
is reset on the local NE, or search for the peer ipv4-address enable command and check whether
the peer is enabled in other address families on the local NE or whether BGP connection
parameters are set.
l If any of the preceding check items is matched, the alarm is caused by configurations and no
action is required. Go to step 21.
l If none of the preceding check items is matched, go to step 20.
Step 5 If the value of Error Code in the Result area in the BGP Peer Log Information dialog box is
4, the BGP disconnection occurs because the hold timer expires. Check whether the IP address
of the BGP neighbor can be pinged.
1. Choose Fault > IP NE Test from the main menu.
2. In the Test dialog box, choose Network Layer Diagnosis > ICMP Ping from the
navigation tree.
3. Set the source and destination addresses, and click Run.
NOTE
Select a running NE as the source and select BGP Peer IP in the Location Information field as the
destination.
l If the displayed information shows that the source and destination are interconnected, go to
step 18.

Equipment
l If the displayed information shows that the source and destination are not interconnected, go
to step 5.
Step 6 Check the Destination/Mask field in the routing table to determine whether the route to the peer
address is available.
1. Choose Route Management > Routing Information from the service tree.
2. Select Routing Table from the View Routing Information drop-down list, click
Condition, set the destination IP address to the peer address, and click Display.
If much information is displayed, click More repeatedly until this button is dimmed. Then
all the queried information is displayed in the Result area.
3. In the Result area, check whether the route to the peer address is displayed.
l If the route to the peer address is displayed, go to step 7.
l If the route to the peer address is not displayed, go to step 8.
Step 7 Check whether the ACL rule that denies TCP port 179 has been configured on the NE.
1. Choose IP Application Service > ACL Management > ACL Rules > Advanced Rule
from the service tree.
2. Click Query.
3. In the query result area, check whether the ACL rule that denies TCP port 179 has been
configured.
l If such an ACL rule has been configured, go to step 9.
l If such an ACL rule has not been configured, go to step 10.

Equipment
Step 8 Check whether the values of Administrative Status and Operating Status for the outbound
interface are both Up.
1. Choose Interface Management > Interface Information from the service tree.
2. Click Query.
3. In the query result area, locate the desired interface and check whether the values of
Administrative Status and Operating Status are Up.
l If the values of both parameters are Up, go to step 20.

l If the value of either parameters is not Up, go to step 11.

Equipment
Step 9 In the routing table, check the origin of the BGP peer address.
1. Choose Route Management > Routing Information from the service tree.
2. Select Routing Table from the View Routing Information drop-down list, and click
Display.
If much information is displayed, click More repeatedly until this button is dimmed. Then
all the queried information is displayed in the Result area.
l If the route originates from OSPF, go to step 12.
l If the route originates from IS-IS, go to step 13.
l If the route originates from neither OSPF nor IS-IS, go to step 20.
Step 10 Delete the ACL rule that denies TCP port 179. Then check whether the alarm about BGP session
establishment is generated.
1. Choose IP Application Service > ACL Management > ACL Rules > Advanced Rule
2. Click Query.
3. In the query result area, delete the ACL rule that denies TCP port 179.
Check whether the alarm about BGP session establishment is generated.

Equipment
l If the alarm is generated, go to step 21.

l If the alarm is not generated, go to step 10.
Step 11 Check whether Loopback interfaces are used to establish the BGP peer relationship.
2. Click Query.
3. In the Peer area on the Peer(Group) page, select a peer record and click View.
4. On the Address Family page in the dialog box that is displayed, select the record to be
viewed and click View.
5. Click the Advanced tab and check whether the value of Connect Interface is a loopback
interface.
l If Loopback interfaces are used to establish the BGP peer relationship, go to step 14.
l If Loopback interfaces are not used to establish the BGP peer relationship, go to step 15.

Equipment
Step 12 Check whether the associated interfaces have been manually disabled.
1. Choose Interface Management > Interface Information from the service tree.
2. Click Query.
3. Locate the desired interface and check whether the value of Administrative Status is
Down.
l If the value is Down, select the interface, right-click, and choose Up from the shortcut menu.
l If the value is not Down, go to step 19.

Equipment
Step 13 Check whether the OSPF neighbor relationship has been established.
1. Choose Route Management > OSPF Route > OSPF Process from the service tree.
2. Click Query.
3. In the query result area, select the desired OSPF process and click Configure. In the dialog
box that is displayed, click the Peer tab and check whether the OSPF neighbor relationship
has been established.
l If the OSPF neighbor relationship has been established, go to step 20.
l If the OSPF neighbor relationship has not been established, rectify the fault in the same way
as you handle the alarm that the OSPF neighbor relationship changes.
Step 14 Check whether the IS-IS neighbor relationship has been established.
1. Choose Route Management > IS-IS Route > IS-IS Process from the service tree.
2. Click Query.
3. In the query result area, select the desired IS-IS process, click IS-IS Neighbor, and check
whether the IS-IS neighbor relationship has been established.
l If the IS-IS neighbor relationship has been established, go to step 20.
l If the IS-IS neighbor relationship has not been established, rectify the fault in the same way
as you handle the alarm that the IS-IS neighbor relationship changes.

Equipment
Step 15 In the peer configurations, check whether the connection interface has been configured.
2. Click Query.
4. On the Address Family page in the dialog box that is displayed, select the record to be
viewed and click View.
5. Click the Advanced tab to check whether Connect Interface has been set.
l If this parameter has been set, go to step 15.
l If this parameter has not been set, go to step 16.

Equipment
Step 16 If BGP is the EBGP neighbor relationship and multiple hops exist between EBGP neighbors,
check whether the Max. Hops check box is selected on the Advanced page in the View Peer
(Group) Information dialog box.
l If the Max. Hops check box is selected, go to step 18.
l If the Max. Hops check box is not selected, go to step 17.

Equipment
Step 17 Set parameters in the Connect Interface area. Ensure that Connect Interface is set to a local
interface connecting to the BGP peer. Check whether the alarm about BGP neighbor relationship
l If the alarm about BGP neighbor relationship establishment is generated, go to step 21.
l If the alarm about BGP neighbor relationship establishment is not generated, go to step 20.

Equipment
Step 18 Select the Max. Hops check box. Check whether the alarm about BGP peer relationship

Equipment
Step 19 Check whether the CPU usage remains 100% for a certain period of time.
1. Choose Device Management > NE Panel from the service tree.
2. Select the board in the NE Panel, right-click, and choose View Board CPU from the
shortcut menu.
3. In the dialog box that is displayed, check whether the CPU usage remains 100% for a certain
period of time.
l If the CPU usage remains 100% for a certain period of time, go to step 20.
l If the CPU usage does not remain 100% for a certain period of time, go to step 6.

Equipment
Click Refresh to check the current CPU usage.
Alternatively, check the CPU usage in a certain period of time by viewing the real-time board
performance data.
Step 20 Contact peer NE maintenance engineers and check whether BGP has been reset on the peer NE,
the peer has been enabled in other address families on the local NE, or BGP connection
parameters have been set. Check whether the alarm about BGP peer relationship establishment
is generated.
1. Choose Route Management > BGP Route > Address Family > IPv4 Unicast Address
Family from the service tree.
2. Click Query.
4. On the Route Property tab in the dialog box that is displayed, check whether the Disable
a BGP device from exchanging routes with a specified peer or peer group check box
is selected.
5. Choose Route Management > BGP Route > Address Family > VPN Instance Address
6. Click Query.

Equipment
7. In the Peer area on the Peer(Group) page, check whether the associated peer record is
displayed.
8. Choose Route Management > BGP Route > Address Family > VPN IPv4 Address
9. Click Query.
10. In the Peer area on the Peer(Group) page, check whether the associated peer record is
displayed.
Check whether the alarm about BGP neighbor relationship establishment is generated.
Step 21 Collect the alarm information, logs, and configurations of the NE and contact Huawei technical
support engineers.
Step 22 End.
----End
2.4.13 Tunnel Group Down
Description
This alarm is generated when all the tunnels in a tunnel group do not function properly. If tunnels
in a tunnel group do not function properly, the relevant NE reports an alarm, which carries
information such as the destination address and tunnel policy, to notify users of the fault.
Attribute
2600151 Major Processing

Services are interrupted.
Possible Causes
l The link does not function properly.
l NE configurations are changed so that no tunnel to the specified destination address is
available.
Procedure
Step 1 View the tunnel policy name in the Location Information field of the alarm record. If a tunnel
policy is configured, go to Step 2. If the tunnel policy name is empty, no tunnel policy is
configured. Go to Step 6.

Equipment
Step 2 Select the alarm, right-click, and choose Locating to NE Panel from the shortcut menu to switch
to the NE Explorer. Choose VPN Management > Tunnel Policy Management from the service
tree. Click Query. On the Tunnel Policy Management tab page, select the record of the tunnel
policy bound to the faulty tunnel group.
Step 3 Click Configure. In the dialog box that is displayed, view tunnel policy parameters.
l If the tunnel policy is set to Tunnel Selection Sequence, go to Step 4.

l If the tunnel policy is set to Bind Application to Tunnel, go to Step 7.

Equipment
Step 4 Choose MPLS Management > TE Tunnel Configuration from the service tree. Check whether
any tunnel type listed in Priority Sequence of the tunnel policy is available.
l If such a tunnel is available, go to Step 7.

l If such a tunnel is unavailable, go to Step 3 and change the tunnel policy used for VPN
services.
Step 5 If the tunnel policy is set to Bind Application to Tunnel, choose Interface Management >
Interface Information from the service tree. On the Interface Information tab page, check
whether the required tunnel interface is Up.
l If the tunnel interface is Up, go to Step 7.

l If the tunnel interface is not Up, go to Step 4 and set TE interface parameters.
Step 6 Choose MPLS Management > Static LSP Segment from the service tree. On the Static LSP
Segment tab page, check whether an LSP named with a bound interface is available.

Equipment
l If such an LSP is available, go to Step 7.

l If such an LSP is unavailable, go to Step 4 and check whether LSP configurations, such as
LDP LSP, BGP LSP, and static LSP configurations, are correct.
support engineers.
----End
2.4.14 Alarm that an MPLS Tunnel Is Down
Description
An MPLS tunnel failure indicates that an MPLS TE tunnel becomes Down. If this failure occurs,
the VPN service carried by the tunnel is interrupted in a scenario where no backup tunnel is
available. You must remove the failure immediately.
Attribute

Packet forwarding based on this tunnel is interrupted.
Possible Causes
l A failure occurred on the NE or interface specified for the explicit path.

Equipment
l A static LSP was bound to the tunnel, but the next hop configured for the static LSP and
that in the routing table were inconsistent after routes changed.
l A link fault occurs or the link bandwidth was insufficient.
Procedure
Step 1 View the alarm records of Mpls Tunnel ID and MPLS Tunnel Name in the Location
Information column. Select the alarm, right-click, and choose Locating to NE Panel from the
shortcut menu. Choose MPLS Management > TE Tunnel Configuration from the service
tree. Then click Query. Select the tunnel that is not functioning properly, right-click, and choose
View Tunnel Interface Information from the shortcut menu. Select the Last Error check box,
and click Display.
NOTE
If none of the displayed TE tunnel configurations is about the tunnel with MPLS Tunnel Name specified
in the alarm records, the TE tunnel has been deleted. Go to Step 6.
l One of the following error messages may be displayed:

If the message "Cspf failed to calculate a path for Tunnel." is displayed, CSPF is enabled
on the ingress node but CSPF fails to calculate a path. Go to Step 2.
If the message "Trigger Rsvp failed" is displayed, go to Step 2.
If the message "One LSP is deleted at smooth period" is displayed, go to Step 6.
If the message "One LSP is deleted at Tunnel aging period" is displayed, go to Step 6.
If other error messages are displayed, go to Step 6.
l If no error message is displayed, go to Step 2.

Equipment
Step 2 Select the tunnel that is not functioning properly, right-click, and choose LSP Ping from the
shortcut menu. In the dialog box that is displayed, set LSP ping parameters, set LSP Test
Type to LSP Path, and select a destination address. Click Run.
Bandwidth restriction
(optional, manually specified)
Explicit path (optional,

manually specified)
Path calculation
(CSPF)
Path setup (RSPF)
Topology discovery
(OSPF, IS-IS)
l If the ingress node cannot ping the destination address, rectify the route fault and enable the
ingress node to ping the destination address. Then check whether an alarm that an MPLS
tunnel is Up is generated.
If an alarm that an MPLS tunnel is Up is generated, go to Step 7.
If no such an alarm is generated, go to Step 3.
l If the ingress node can ping the destination address, go to Step 3.

Equipment
Step 3 Choose MPLS Management > MPLS Configuration > Global MPLS Configuration from
the service tree. Check whether CSPF is enabled.
Involved nodes or interfaces up or down

Related protocol enabled or not
Outbound interface bandwidth sufficient or not
Inbound Transit Transit Outbound

node node node node
Route reachable or not

CSPF enabled or not
l If CSPF is enabled, go to Step 4.

l If CSPF is not enabled, go to Step 5.
Step 4 Choose MPLS Management > TE Tunnel Configuration from the service tree. Select the
tunnel that is not functioning properly, right-click, and choose View Running Information >
Path Information from the shortcut menu. In the dialog box that is displayed, click Display.

Equipment
Check whether a path meeting the constraints is available. If such a path is available, the path
information is displayed and CSPF path calculation succeeds. If such a path is unavailable, no
path information is displayed and CSPF path calculation fails.
l If CSPF path calculation fails, go to Step 5.

l If CSPF path calculation succeeds, click the MPLS TE tab to check whether MPLS Auto
FRR is configured.
If MPLS Auto FRR is configured, automatic protection is used for the tunnel. In this
case, you can determine the active tunnel based on tunnel configurations.
If MPLS Auto FRR is not configured, determine the primary and backup tunnels based
on TE tunnel configurations.
1. Choose MPLS Management > TE Tunnel Configuration from the service tree.
Select the tunnel that is not running properly and click Configure. Click the
Protection tab and then the FRR tab to view information about the following
parameters: Configure the tunnel as a bypass tunnel and Fast Reroute.

Equipment
2. Click the Tunnel Adjustment tab to view the record route label configurations.

Equipment
3. Click the Advanced tab to view the name of the explicit path bound to the tunnel.

Equipment
4. Click the Protection tab and check whether affinity attributes have been set for the
tunnel.

Equipment
5. Choose MPLS Management > TE Tunnel Configuration from the service tree.
Select the tunnel that is not functioning properly, right-click, and choose View
Running Information > Path Information from the shortcut menu. In the dialog
box that is displayed, click Display. Set constraint parameters, such as Explicit
Path and Bandwidth, based on the tunnel configurations. Check whether a path
meeting the constraints is available.
If such a path is available, the path information is displayed and CSPF path
calculation succeeds. If such a path is unavailable, no path information is displayed
and CSPF path calculation fails. Check whether the constraint parameters, including
Explicit Path, Bandwidth, Affinity Value, and Hop Limit, are set correctly.
Step 5 Check tunnel configurations and status of all interfaces along the tunnel.
1. Choose MPLS Management > TE Tunnel Configuration from the service tree. Right-
click the desired tunnel and choose Configure from the shortcut menu. Click the
Advanced tab to view the name of the explicit path bound to the tunnel.
2. Choose Interface Management > Interface Information from the service tree. View
information about all interfaces along the tunnel. If an interface goes Down, right-click the
interface and choose Up from the shortcut menu. Choose Fault > Browse Current
Alarm from the main menu. Check whether an alarm that an MPLS tunnel is Up is
generated.
l If an alarm that an MPLS tunnel is Up is generated, go to Step 7.

Equipment
l If no such an alarm is generated, go to Step 6.

Step 6 Collect the alarm information, logs, and configurations, and contact Huawei technical support
personnel.
Step 7 End.
----End
2.4.15 MPLS LDP Session Down

Description
Label Distribution Protocol (LDP) is used for label distribution and switching between NEs.
The LDP session between two NEs helps to establish LDP LSPs, PWE3 services, and VPLS
services, and to distribute inner and outer labels. If an LDP session becomes Down, all the
associated LDP LSPs and PWE3 services are interrupted.
A local LDP session is automatically established between two directly connected NEs; a remote
LDP session needs to be manually established based on service requirements.
Figure 2-11 Local and remote LDP sessions

Remote LDP session
Local LDP session
Attribute

All services based on the LDP session are interrupted.
Possible Causes
The LDP session between two NEs is established and maintained by Hello messages, and the
packets are forwarded by TCP. The possible causes leading to the alarm that an MPLS LDP
session is Down are as follows:

Equipment
l Some configurations are changed. For example, LDP is disabled on the relevant NE or port,
or remote LDP peer configurations are deleted.
l A failure occurs on the ports or links of transit node, resulting in route interruption.
Procedure
Step 1 Check whether the current alarm is a correlated alarm. If it is a correlated alarm, locate the
associated root alarm.
Step 2 Choose Service > Tunnel > Manage LDP Session from the main menu. Check whether the
LDP session is running. It is normal if the state is OPERATIONAL. Further check is needed if
the state is not OPERATIONAL or the LDP session is not found.
Figure 2-12 Checking the state of the LDP session
Step 3 Check the running status of interfaces and whether interface Down alarms are generated. To
perform the check, choose Interface Management > Interface Information from the service
tree. On the Interface Information tab page, check whether interfaces are running and whether
some interfaces have been shut down.
Step 4 Choose MPLS Management > MPLS Configuration > MPLS Interface from the service tree.
On the MPLS Interface tab page, check whether LDP is disabled on the interfaces.
Figure 2-13 Checking the running status of interfaces and whether LDP is disabled
support engineers.
----End

Equipment
2.4.16 Tunnel Primary LSP Down
Description
This alarm is generated when the primary LSP in an MPLS tunnel does not function properly.
Attribute

If the primary LSP in the MPLS tunnel is not used to forward services, this alarm has no impact
on traffic forwarding. If the primary LSP in the MPLS tunnel is used to forward services and a
backup LSP is available in the tunnel, the traffic to be forwarded needs to be switched to that
LSP. Otherwise, traffic forwarding is interrupted.
Possible Causes
l The interface is Down.
l The link does not function properly.
l Tunnel configurations are incorrect.
Procedure
shortcut menu. In the NE Explorer, choose MPLS Management > TE Tunnel
Configuration from the service tree. Then click Query.
NOTE
Step 2 Select a tunnel that is not functioning properly, right-click, and choose View Tunnel Interface
Information from the shortcut menu. Select the Last Error check box, and click Display.

Equipment
The following messages may be displayed.

l If the message "Cspf failed to calculate a path for Tunnel." is displayed, CSPF is enabled on
the ingress node but CSPF fails to calculate a path. Go to Step 3.
l If the message "Trigger Rsvp failed." is displayed, go to Step 3.
l If the message "One LSP is deleted at smooth period." is displayed, go to Step 7.
l If the message "One LSP is deleted at Tunnel aging period." is displayed, go to Step 7.
l If an error message different from any of the above messages is displayed, go to Step 7.
Step 3 Select the tunnel, right-click, and choose LSP Ping from the shortcut menu.
In the dialog box that is displayed, set LSP Ping parameters, set LSP Test Type to LSP Path,
and enter a destination tunnel address in the Destination Address field.
Step 4 Click Run.

If the test result is displayed as Disconnected, go to Step 5. If the test result is displayed as
Connected, go to Step 7.

Equipment
the service tree. Click the MPLS TE tab. Check whether CSPF is enabled.
If CSPF is enabled, go to Step 6. If CSPF is not enabled, go to Step 7.
Step 6 Choose MPLS Management > TE Tunnel Configuration from the service tree.
1. Select a tunnel and click Configure. Click the Advanced tab and view the name of the
explicit path bound to the tunnel.

Equipment
2. Click the Advanced tab and check whether bandwidth parameters have been set.
3. Click the Protection tab and check whether affinity parameters have been set.
4. Select the tunnel, right-click, and choose View Running Information > Path
Information from the shortcut menu. In the dialog box that is displayed, click Display.
Set constraints, such as priority, bandwidth, explicit path, affinity attribute, and hop count
limit, based on tunnel configurations. Check whether a path meeting the constraints is
available.

Equipment
If such a path is available, the path information is displayed and CSPF path calculation
succeeds. If such a path is unavailable, no path information is displayed and CSPF path
calculation fails.
l If explicit path-based path calculation fails, check whether every interface along the
path is Up and has been enabled with MPLS, MPLS TE, and RSVP-TE. To perform
the check, choose MPLS Management > MPLS Configuration > MPLS Interface
l If explicit path-based path calculation succeeds, check whether affinity attribute-based
or bandwidth-based path calculation succeeds. To perform the check, choose MPLS
Management > TE Tunnel Configuration from the service tree. Click Configure. In
the dialog box that is displayed, click the Advanced tab.
l If affinity attribute-based path calculation fails, modify the affinity attributes. To
perform the check, choose MPLS Management > TE Tunnel Configuration from the
service tree. Click Configure. In the dialog box that is displayed, click the Advanced
tab.
l If bandwidth-based path calculation fails, check whether the bandwidth for the outbound
interfaces along the tunnel is sufficient. To perform the check, choose MPLS
Management > MPLS Configuration > MPLS Interface from the service tree. Click
Configure. In the dialog box that is displayed, click the MPLS TE tab.
NOTE
To check whether the link bandwidth is sufficient, choose Inventory > Link Management from
the main menu.
If the bandwidth is sufficient, the tunnel with a higher priority preempts the bandwidth
used by the current tunnel. The bandwidth needs to be increased for the required
interfaces.

Equipment
5. If path calculation based on other constraints fails, go to Step 7 and check whether the
Tunnel Hot-standby LSP UP alarm is generated.
Choose Fault > Browse Current Alarm from the main menu.
l If the Tunnel Hot-standby LSP UP alarm is generated, the diagnosis process is complete.
l If the Tunnel Hot-standby LSP UP alarm is not generated, go to Step 7.
personnel.
----End
2.4.17 Tunnel Hot-standby LSP Down
Description
This alarm is generated when the hot-standby LSP in an MPLS tunnel does not function properly.
Attribute

If the hot-standby LSP in the MPLS tunnel is not used to forward services, this alarm has no
impact on traffic forwarding. If the hot-standby LSP in the MPLS tunnel is used to forward
services and another LSP is available in the tunnel, the traffic to be forwarded needs to be
switched to that LSP. Otherwise, traffic forwarding is interrupted.
Possible Causes
Cause 1: The interface is Down.
Cause 2: The link does not function properly.
Cause 3: The primary and hot-standby LSPs are configured on the same path and the secondary
LSP is not configured with any explicit path.

Equipment
Procedure
shortcut menu. In the NE Explorer, choose MPLS Management > TE Tunnel
Configuration from the service tree. Then click Query.
NOTE
Step 2 Select a tunnel that is not functioning properly, right-click, and choose View Tunnel Interface
Information from the shortcut menu. Select the Last Error check box, and click Display.
The following messages may be displayed.
l If the message "Cspf failed to calculate a path for Tunnel." is displayed, CSPF is enabled on
the ingress node but CSPF fails to calculate a path. Go to Step 3.
l If the message "Trigger Rsvp failed." is displayed, go to Step 3.
l If the message "One LSP is deleted at smooth period." is displayed, go to Step 8.
l If the message "One LSP is deleted at Tunnel aging period." is displayed, go to Step 8.
l If an error message different from any of the above messages is displayed, go to Step 8.
Step 3 Select the tunnel, right-click, and choose LSP Ping from the shortcut menu.
In the dialog box that is displayed, set LSP Ping parameters, set LSP Test Type to LSP Path,
and enter a destination tunnel address in the Destination Address field.

Equipment
Step 4 Click Run.
If the test result is displayed as Disconnected, go to Step 5. If the test result is displayed as
Connected, go to Step 8.
the service tree. Click the MPLS TE tab. Check whether CSPF is enabled.
If CSPF is enabled, go to Step 6. If CSPF is not enabled, go to Step 7.

Equipment
Step 6 Choose MPLS Management > TE Tunnel Configuration from the service tree.
1. Select a tunnel and click Configure. Click the Advanced tab and view the name of the
explicit path bound to the tunnel.
2. Click the Advanced tab and check whether bandwidth parameters have been set.
3. Click the Protection tab and check whether affinity parameters have been set.

Equipment
4. Select the tunnel, right-click, and choose View Running Information > Path
Information from the shortcut menu. In the dialog box that is displayed, click Display.
Set constraints, such as priority, bandwidth, explicit path, affinity attribute, and hop count
limit, based on tunnel configurations. Check whether a path meeting the constraints is
available.
If such a path is available, the path information is displayed and CSPF path calculation
succeeds. If such a path is unavailable, no path information is displayed and CSPF path
calculation fails.

Equipment
l If explicit path-based path calculation fails, check whether every interface along the
path is Up and has been enabled with MPLS, MPLS TE, and RSVP-TE. To perform
the check, choose MPLS Management > MPLS Configuration > MPLS Interface
l If explicit path-based path calculation succeeds, check whether affinity attribute-based
or bandwidth-based path calculation succeeds. To perform the check, choose MPLS
Management > TE Tunnel Configuration from the service tree. Click Configure. In
the dialog box that is displayed, click the Advanced tab.
l If affinity attribute-based path calculation fails, modify the affinity attributes. To
perform the modification, choose MPLS Management > TE Tunnel Configuration
from the service tree. Click Configure. In the dialog box that is displayed, click the
Advanced tab.
l If bandwidth-based path calculation fails, check whether the bandwidth for the outbound
interfaces along the tunnel is sufficient. To perform the check, choose MPLS
Management > MPLS Configuration > MPLS Interface from the service tree. Click
Configure. In the dialog box that is displayed, click the MPLS TE tab.
NOTE
To check whether the link bandwidth is sufficient, choose Inventory > Link Management from
the main menu.
If the bandwidth is sufficient, the tunnel with a higher priority preempts the bandwidth
used by the current tunnel. The bandwidth needs to be increased for the required
interfaces.
5. If path calculation based on other constraints fails, go to Step 8 and check whether the
Tunnel Hot-standby LSP UP alarm is generated.
Choose Fault > Browse Current Alarm from the main menu.
l If the Tunnel Hot-standby LSP UP alarm is generated, the diagnosis process is complete.
l If the Tunnel Hot-standby LSP UP alarm is not generated, go to Step 7.
Step 7 If neither an explicit path nor the overlap attribute has been configured for the hot-standby LSP
and the primary LSP is Up, configure an explicit path for the hot-standby LSP.
Choose MPLS Management > TE Tunnel Configuration from the service tree. Click
Create. Click the Protection tab. Check whether the Overlapped Path check box is selected.
If the check box is not selected, the overlap attribute is not configured. Click the Advanced tab
and select an explicit path.
l If the Tunnel Hot-standby LSP UP alarm has been generated, the location process is complete.
l If this alarm has not been generated, go to Step 8.

Equipment
personnel.
----End
2.4.18 L3VPN VRF Down
Description
As shown in the following figure, a VPN Routing and Forwarding (VRF) instance is an L3VPN
service instance on an NE for route learning and packet forwarding. The alarm that an L3VPN
VRF is Down indicates that a failure occurred on the current NE and packets cannot be properly
forwarded. This alarm needs to be cleared immediately.
Figure 2-14 Service interruption caused by this alarm
Attribute

The VPN instance is not bound to any available interface.
Possible Causes
The preceding figure shows that VRF receives packets through the bound interface, and forwards
these packets to the network side according to the forwarding table or forwards the packets
received from the network side to User-to-Network Interfaces (UNIs). Therefore, the alarm that

Equipment
an L3VPN VRF is Down is generated if all the bound interfaces become Down or all the bound
interfaces are unbound. This alarm leads to the failure to forward packets.
Figure 2-15 Alarm that an L3VPN VRF is Down is generated when the bound interfaces become
Down
Figure 2-16 Alarm that an L3VPN VRF is Down is generated when all the bound interfaces are
unbound
According to the preceding analysis, checking the status of bound interfaces is the main method
to find out why this alarm is generated. The procedure for handling this alarm is as follows:
Procedure
Step 1 Check whether the alarm is a correlated alarm. If it is a correlated alarm, locate the associated
root alarm. Then clear the root alarm, and the correlated alarm will be automatically cleared.
NOTE
The icon on the left of the alarm severity as indicates that the alarm is a correlated alarm, indicates
that the alarm is a root alarm.
Figure 2-17 Checking the alarm correlation

Equipment
Step 2 If the alarm is not a correlative alarm. record L3VPN VRF Name in the alarm locating
information. Select the alarm, right-click, and choose Locating to NE Panel from the shortcut
menu to start the NE Explorer.
Step 3 Choose VPN Management > L3VPN Management > VRF Management from the navigation
tree. Click Query. Select the faulty VRF and click the Bind Interface tab. View the bound
interface. Possible scenarios and handling procedures are as follows:
Figure 2-18 VRF management window
l If the bound interface list is empty, the current alarm is generated because the bound interface
is deleted. Acknowledge the current alarm directly if deleting the bound interface is required
(for example, to interrupt the user access through the interface). Otherwise, rebind the
associated interface. As shown in the following figure, select a VRF record on the VRF
Management tab page and click Configure. In the Configure VRF dialog box, click Add
on the Bind Interface tab page to add the desired interface.

Equipment
Figure 2-19 Adding a bound interface
l If all the bound interfaces are Down, locate the cause. An interface fault will cause a
LinkDown alarm; therefore, locate the disconnection cause of the link connected to the
interface. For details, see 2.1 Common Alarm Locating.
Step 4 Pay attention to the following points.
If no IP address is configured for the interface bound to the VRF, the alarm that an L3VPN VRF
is Down is not generated, but the service may be interrupted. To set an IP address, select a bound
interface on the VRF Management tab page and click Configure. In the Configure VRF dialog
box, click Configure on the Bind Interface tab page to set an IP address. The following figure
shows how to set an IP address.
Figure 2-20 Setting an IP address for a bound interface
The alarm that an L3VPN VRF is Down is not generated if there is no BGP peer or tunnel
between VRFs or the BGP peer or tunnel between VRFs fails.
However, these two problems may result in service interruption. The status of a BGP peer and
a tunnel can be detected by using the test and check function provided by an L3VPN service.
The detailed procedure is as follows:

Equipment
1. Choose Service > L3VPN Service > Manage L3VPN Service from the main menu. In
the service list, select a desired service, right-click, and choose Test and Check from the
shortcut menu.
2. On the Configuration tab page, select the trail to be commissioned. On the Diagnosis
Option tab page, select a diagnosis item, as shown in the following figure.
3. Click Run to perform testing on one or more trails to be commissioned.
4. After the check is complete, view the Results column on the Check Result page to check
whether the test is successful. Click ... next to Details to view details about the test result.
Restore the service as prompted.
Figure 2-21 Test and check function provided by an L3VPN service
----End
2.4.19 Alarm that a CCC VC Is Down
Description
This alarm is generated when a CCC VC is Down.
Attribute
2501071 Minor Communication

Equipment

The CCC service is interrupted.
Possible Causes
l The NE that uses the CCC service is not enabled with MPLS globally.
l The inbound or outbound interface for the CCC service is Down.
Procedure
Step 1 Check whether the current MPLS configurations are the same as the original MPLS
configurations.
Check whether MPLS is enabled globally or on the outbound interface for the CCC service.
l In the NE Explorer, choose MPLS Management > MPLS Configuration > Global MPLS
Configuration from the service tree, and check whether MPLS is enabled globally. If the
Enable MPLS check box is selected, the NE is enabled with MPLS globally.
l In the NE Explorer, choose MPLS Management > MPLS Configuration > MPLS
Interface from the service tree, and check whether MPLS is enabled on the outbound
interface for the CCC service. If the outbound interface for the CCC service is displayed in
the MPLS interface list, MPLS is enabled on the outbound interface.
If MPLS is enabled globally or on the outbound interface for the CCC service, go to Step 3. If
MPLS is not enabled globally or on the outbound interface for the CCC service, go to Step 2.
Step 2 Restore the MPLS configurations.

l In the NE Explorer, choose MPLS Management > MPLS Configuration > Global MPLS
Configuration from the service tree, and enable MPLS globally.
l In the NE Explorer, choose MPLS Management > MPLS Configuration > MPLS
Interface from the service tree, and enable MPLS on the outbound interface for the CCC
service.
In the NE Explorer, choose VPN Management > CCC Management from the service tree, and
check whether the fault is rectified. If the value of Deployment Status for the CCC service is
Up, the fault is rectified.
If the fault is rectified, the alarm handling is complete. If the fault persists, go to Step 3.
Step 3 Choose Fault > Browse Current Alarm from the main menu. On the Browse Current
Alarm tab page, click OK to view the cause of the fault that the interface status is Down.
Make the interface Up based on the handling suggestions and check whether the alarm is cleared.
If the alarm is cleared, the alarm handling is complete. If the alarm persists, go to Step 4.
Step 4 Collect information about alarms, logs, and configurations, and contact Huawei technical
support engineers.
----End

Equipment
2.4.20 VPLS VC Down
Description
This alarm is generated when a VC goes Down. Services on this VC are interrupted.
Attribute

The associated VPLS service is interrupted and service packets cannot be forwarded.
Possible Causes
The status of the related link changes or the configurations for NEs at both ends of the link
change.
Procedure
Step 1 In the NE Explorers for the local and peer NEs, choose VPN Management > VSI
Management from the service tree and view VSI information.
NOTE
If the VSIs are Martini service VSIs, check whether VSIs on the local and peer NEs have the same VSI
ID. If the VSIs are Kompella service VSIs, check whether VSIs on the local and peer NEs have the same
VPN target.

Equipment
1. On the Bind Interface tab page, view the value of Operating Status. If the operating status
is Down, go to Step 2.
2. On the General tab page, view the value of Administrative Status. If the administrative
status is Down, go to Step 3.
3. On the General tab page, view the value of Encapsulation Type. On the Advanced VSI
Configuration tab page, view the value of MTU. If the encapsulation types and MTU
values on the local and peer NEs are different, go to Step 4.
4. On the Configure VC tab page, view the information about the available record. If no
record is displayed, the related PW is unavailable. Go to Step 5.
5. On the Configure VC tab page, view the value of Operating Status. If the operating status
is Down, go to Step 10.
Step 2 In the NE Explorers for the local and peer NEs, choose Interface Management > Interface
Information from the service tree.
Select the interface bound to the VSI, right-click, and choose Up from the shortcut menu. Then
check whether the alarm is cleared.
Step 3 Choose VPN Management > VSI Management from the service tree. Select the desired VSI,
right-click, and choose Enable from the shortcut menu.

Equipment
Step 4 Choose VPN Management > VSI Management from the service tree. Select the desired VSI
and click Configure. Set the same MTU value for the VSIs on the local and peer NEs.
Step 5 Choose VPN Management > VSI Management from the service tree and check the VSI type.
l For Martini service VSIs, click the Configure VC tab to check the VC running status.
If the VC is Down, go to Step 6.
If the VC is Up, go to Step 7.

Equipment
l For Kompellar service VSIs, choose Route Management > BGP Route > Public Network
Route > Peer from the service tree. Check whether the BGP connection to the VPLS address
family on the peer NE is established.
If yes, go to Step 11.
If no, go to Step 8.
Step 6 In the NE Explorer for the peer NE, choose MPLS Management > MPLS Detection > LDP
Session from the service tree.
Check whether the session to the the peer NE is in the Operational state.
If yes, go to Step 11.
If no, go to Step 9.

Equipment
Step 7 In the NE Explorer, choose VPN Management > VSI Management from the service tree. On
the Configure VC tab page, check whether the tunnel policy for the VSI peer is available. If
yes, go to Step 10. If no, go to Step 9.
Step 8 In the NE Explorer, choose Route Management > BGP Route > Public Network Route >
Peer from the service tree.
Configure BGP and establish the BGP connection. Check whether the alarm is cleared. If the
alarm is cleared, go to Step 12. If the alarm is not cleared, go to Step 11.
Step 9 Check the status of the interface on the public network. If the interface is Down, restore its status
to Up and check LDP configurations. In the NE Explorer, choose MPLS Management > MPLS
Detection > LDP Session from the service tree. Check whether the alarm is cleared after the
session is in the Operational state.

Equipment
If the alarm is cleared, go to Step 12. If the alarm is not cleared, go to Step 11.
Step 10 Check the configurations for routes and interfaces on the public network. If the configurations
are correct, go to Step 12. If the configurations have any error, address the problem. Check
whether the alarm is cleared.
If the alarm is cleared, go to Step 12. If the alarm is not cleared, go to Step 11.
support engineers.
Step 12 End.
----End
2.4.21 Alarm About Clock Source Switching
Description
If the clock source traced by an NE does not function properly, the NE traces a backup or local
clock source. O&M engineers can also manually perform forcible clock source switching. If this
alarm is generated because of the former reason, rectify the related fault and check whether the
alarm has been cleared.
Attribute
2501581 Minor Processing

l If the clock source is switched to empty, the time signal weakens slightly.
l If the quality of the clock source improves after clock source switching, services relying
on the clock source are not affected.
l If the quality of the clock source deteriorates, the time signal weakens slightly.
Possible Causes
l The attributes of a clock device on the network are changed.
l The associated link or interface is Down.
l The clock source is manually switched using the Manual or Force clock source selection
mode.
Procedure
Step 1 In the main topology, switch to Clock View, right-click the desired NE, and choose View Clock
Config from the shortcut menu. Click the Physical Clock tab and then the Clock Source
Attributes tab to view information about the running mode of the clock source (System trace
source state).

Equipment
l If the clock source is running in free-run mode, go to Step 6.

l If the clock source is running in hold mode, go to Step 6.
l If the clock source is running in lock mode, go to Step 2.
Step 2 Click the Physical Clock tab and then the Configurations tab to view information about the
clock source selection mode (sys pll).
l If the clock source selection is in manual or force mode, the clock source is switched forcibly.
In this case, go to Step 6.

Equipment
l If the clock source selection is in auto mode, go to Step 3.
Step 3 Click the Physical Clock tab and then the Clock Source Attributes tab to check whether the
clock source status is normal (Source).
l If the clock source is not in normal state, go to Step 5.

l If the clock source is in normal state, go to Step 4.
Step 4 Click the Physical Clock tab and then the Clock Source Attributes tab to check whether the
clock source attribute changes (Source).

Equipment
l If the clock source attribute changes, go to Step 6.

l If the clock source attribute does not change, go to Step 5.
Step 5 Collect information about alarms, logs, and configurations, and contact Huawei technical
support engineers.
Step 6 End.
----End

Equipment
Fault Diagnosis 3 Locating Faults Based on Path Visualization
3 Locating Faults Based on Path Visualization
After the source and sink IP addresses or the interface on one side has been configured, the IP/
MPLS fault locating function allows the U2000 to automatically discover service paths and
display them in the topology view.In addition, the Node, Link, Optical Module Information,
and Alarm tabs display performance data, basic information about optical modules, and alarm
records. All these data provides a reference for the preliminary stage of fault diagnosis. You can
perform fast diagnosis to detect faults in one-click mode.
Prerequisites
To display nodes and links exceeding performance thresholds in the topology view, perform the
following operations to set performance thresholds:
1. Choose Fault > IP/MPLS Fault Location from the main menu.
2. Click the shortcut icon.

3. In the dialog box that is displayed, check whether the default values for performance
parameter thresholds meet requirements. For example, the threshold is 80% for CPU
Usage and Memory Usage and 60% for Bandwidth Usage. If the thresholds do not meet
requirements, change them as required. After setting the thresholds, click OK.
Context
The IP/MPLS fault diagnosis function can locate specific fault points and provide solutions for
faults resulted from the following causes.
Table 3-1 Fault symptoms and causes
Symptom Possible Cause
The response speed for services carrying large The MTU for the transmission link is small.
packets is slow. For example, large pictures on
web pages fail to be displayed for a long period The MTU for the related router interface is
of time. small.
Voice calls are intermittent in peak hours. Bandwidth insufficiency causes network
congestion.

Equipment
Symptom Possible Cause
Service quality deteriorates (for example, voice The operating modes of interfaces at both
calls are intermittent), call loss occurs for a long ends of a link are different.
period of time, or service traffic in the two
directions is asymmetrical. The models of optical modules at both ends
of a link are different.
The IP/MPLS fault diagnosis function can locate the point-to-point fault area for a fault that
occurs due to one of the preceding causes. The points on the two sides can be interface boards,
ports, optical modules, or fibers.
The following uses an example to describe how to use the IP/MPLS fault diagnosis function to
diagnose faults.
l Fault symptom: Service quality deteriorates and call loss occurs.
l The IP address of the base station carrying this service is 20.20.1.2, and the IP address of
the base station controller is 30.30.1.3.
Procedure
Step 1 Access the IP/MPLS fault location main window and discover paths through either of the
following navigation paths:
l Main menu
1. Choose Fault > IP/MPLS Fault Location from the main menu.
2. In the Enter the IP Address/Interface of Source and Sink Nodes area, click ... to
select the source and sink IP addresses or interfaces, and click Discover trails.
l Main Topology
1. In the Main Topology, select the source and sink NEs, right-click, and choose
Discover Service Trails from the shortcut menu. In the Select Interface dialog box,
select the desired interface and click OK.

Equipment
NOTE
If you select an interface without any IP address for the source NE, you will directly switch to
the IP/MPLS fault location window. In this case, you can discover service paths without
selecting an interface for the sink NE.
2. Optional: After the pointer is displayed as a plus sign (+), click the sink NE. In the
Select Interface dialog box, select the desired interface and click OK.
In the right-hand topology view, the path from the source node to the sink node is displayed. If
is displayed in a link in the topology view, , the links form a trunk. Click to expand and
view the physical links belonging to the trunk. Click for a physical link to combine physical
links to display as a trunk. If the performance of an NE or a link exceeds the threshold, a message
is displayed in the topology view.
Step 2 Click the Node, Link, Optical Module Information, and Alarm tabs to view NE and link
performance data, optical module information, and existing alarms on NEs and links.
Step 3 Right-click in the blank area of the topology view and choose Quickly Diagnosis > 20.20.1.2-
>30.30.1.3 from the shortcut menu.
20.20.1.2->30.30.1.3 indicates the path between the source and sink NEs to perform fast
diagnosis. If multiple paths exist in the topology view, select the path to perform fast diagnosis
according to the source and sink NEs.
After the preceding operation, the U2000 automatically performs segment-by-segment and
layer-by-layer path detection. In the topology view, the blinking dashed line in yellow indicates
the path that is being detected.
Step 4 On the Diagnosis Records tab page, view diagnosis results and troubleshoot the fault.

Equipment
l The diagnosed fault is marked with in the topology view for you to locate the position
where the fault occurs.
l The Possible Causations area provides the possible fault cause, that is, the operating modes
of interfaces are different (one interface operates in full-duplex mode, and the other interface
operates in half-duplex mode). Click the underlined blue interface name in Guide for
Resolve the Fault to switch to the NE Explorer for modifying interface configurations.
l Click View to view diagnosis details.
----End

Equipment
Fault Diagnosis 4 Common Fault Diagnosis Tools
4 Common Fault Diagnosis Tools
About This Chapter
This topic describes the usage scenarios and operation methods of the common OAM diagnosis
tools and test diagnosis tools of the U2000.
4.1 OAM Diagnosis

This tool sends detection packets on schedule or manually to check network connectivity.
4.2 Test and Diagnosis

The test and diagnosis tool supports connectivity testing for various protocol layers and services
to assist fault locating and troubleshooting. Diagnosis Policy can be set to perform testing at
scheduled time. The network scanning function can test the network-wide network connectivity.
4.3 NE-side Alarm Fault Detection

With this function, you can detect SNMP configurations related to NE alarms.

Equipment
4.1 OAM Diagnosis

This tool sends detection packets on schedule or manually to check network connectivity.
Prerequisites
l Ethernet OAM:
Telnet or STelnet parameters must be set on the U2000 for accessing equipment and
equipment configurations must be synchronized to the U2000.
CFM must be enabled on the Ethernet OAM Global Configuration tab page.
An MD and MAmust exist.
l ATM OAM:
Telnet or STelnet parameters must be set on the U2000 for accessing equipment and
equipment configurations must be synchronized to the U2000.
The ATM interface on the NE has been configured with a PVP/PVC.
Context
Usage scenario of Ethernet OAM
Ethernet OAM sends detection packets on schedule or manually to check network connectivity
and provides functions similar to the Ping and Traceroute functions to acknowledge and locate
Ethernet faults(LB similar to the Ping, and LT similar to the Traceroute). The following is a
typical networking diagram.

Equipment
The U2000 Ethernet OAM management provides the following functions:

l Supporting global information management.
l Supporting the functions related to Ethernet Service OAM.
These functions include the configuration and management of the MD, MA, CFM-BFD
binding, CFM-CFM binding, local MEP, remote MEP, and MIP.
l Supporting the functions related to Ethernet Link OAM.
These functions include protocol configuration, port query, EFM-BFD binding, EFM-CFM
binding, and loopback detection.
l Supporting the test diagnosis.
l Supporting the OAM statistics.
Usage scenario and principle for ATM OAM
ATM OAM is an end-to-end OAM function oriented for ATM servcies. Some OAM cells with
standard structure are designed for cell streams to detect ATM links and check the quality of
ATM services that traverse multiple NEs. The following is a typical networking diagram.

Equipment
In ATM, VPI/VCI is used to identify a logical connection. The VPI/VCI value only has local
significance. VPI is used to identify the virtual path (VP) number of the virtual circuit connection
(VCC). VCI is used to identify the VC number of the VP. The combination of VPI and VCI
comprises the connection identifier.
As shown in Figure 4-1, a VCC contains multiple VPs, and a VP contains multiple VCs.
Figure 4-1 Diagram of the relationship between VP and VC
ATM Network
CX-A CX-B
ATM 1/1/0 ATM 1/1/1
VC1 VC1
VP VP
Physical VC2 VC2 Physical
VP VP
channel channel
VCC VCC
When creating an ATM OAM detection task, select an ATM interface and the associated VPI/
VCI and determines a service channel. Set Detection Type and other parameters to check the
running status of links and locate ATM link faults.
Procedure
Step 1 Example of typical Ethernet Service OAM configurations
The following uses LB test as an example to describe typical networking and procedure.

Equipment
NOTE
Create an MD, an MA, a local MEP, and a remote MEP before creating an LB test case.
1. In the service tree, expand OAM Management > Ethernet OAM Management, and then
click Test Diagnosis.
2. On the Test Diagnosis tab page, click the Task Type drop-down button and select Test
Diagnosis Task.
3. Click Create, or right-click in the query result area and select Create on the shortcut menu.
4. Set test diagnosis parameters in the Create Test Diagnosis Task dialog box.
5. After all parameters are set, click OK or Apply.

6. If the Run immediately check box is selected, the Confirm dialog box is displayed. Click
OK.

Equipment
The U2000 creates a test diagnosis task and runs the task based on the set parameters.
In the Running Result area, view the result of diagnosis. After the operation is complete,
click Close to close the dialog box.
If the test result is shown in the preceding figure, the device can ping through the destination
device and the connection is proper.
If the LB test result is The request timed out, the device cannot ping through the destination
device and you must check hardware resources and links for the device.
Step 2 Example of typical ATM OAM configurations

The following uses CC detection as an example to describe the typical ATM networking and
procedure.
In the ATM network, create a CC detection task on a PE to check the connectivity between the
PE to the NodeB or RNC.
1. Choose OAM Management > ATM OAM Management > ATM OAM Global
Detection from the service tree.
2. On the ATM OAM Global Detection tab page, click Create. Alternatively, right-click in
the query result area and choose Create from the shortcut menu.
3. In the Create ATM OAM Global Detection dialog box , set related parameters.

Equipment
Figure 4-2 Creating ATM OAM detection
NOTE
An ATM link is determined by both an interface and a PVC. You can select the relevant PVC when
selecting an interface.
On an ATM network, OAM functions are implemented by two types of nodes: end point
and segment point.
l End point
An end point is a point where all OAM cells are terminated. If the selected ATM
interface resides on the edge of an ATM network, Attribute of the Connection must
be set to End point. After detecting a link fault, the end point does not insert OAM cells
into the downstream but inserts end Remote Defect Indication (RDI) cells into the
upstream to notify the upstream of the link fault.
l Segment point
A segment point is a point where all segment cells, not end cells, are terminated. If the
selected ATM interface resides on an intermediate node of an ATM network, Attribute
of the Connection must be set to Segment point. After detecting a fault, the segment
point inserts end Alarm Indication Signal (AIS) cells into the downstream and segment
RDI cells into the upstream.
4. Click OK.
5. View test results on the Statistics tab page.

Equipment
If the test result is shown in the preceding figure, the NodeB or RNC is connected to the
PE.
If the test result is loopback ping failed., the NodeB or RNC is not connected to the PE
and you must check hardware resources and links for the device.
----End
4.2 Test and Diagnosis

The test and diagnosis tool supports connectivity testing for various protocol layers and services
to assist fault locating and troubleshooting. Diagnosis Policy can be set to perform testing at
scheduled time. The network scanning function can test the network-wide network connectivity.
Context
According to the network protocol layers, the test cases are classified as follows:
l Application Layer Diagnosis: DNS, FTP, DHCP, DHCP simulation, HTTP, SNMP, VoIP.
l Transport Layer Diagnosis: TCP, UDP.
l Network Layer Diagnosis: ICMP Ping, ICMP Trace, ICMP VRF Ping, ICMP VRF Trace,
ICMP Jitter, Multicast Ping, Multicast Trace, Multicast VRF Trace, MTU Ping.
l MPLS Diagnosis: LSP Ping, LSP Trace, LSP Jitter, PWE3 Ping, PWE3 Trace, VPLS MAC
Ping, VPLS MAC Trace, Service Ping, MAC Study, MFIB Ping, MFIB Trace, VPLS PW
Ping, VPLS PW Trace.
l Data Link Layer Diagnosis: Ethernet Service MAC Ping, CE ping.
Usage Scenario
The following uses DHCP simulation diagnosis as an example to describe how to perform test
and diagnosis.
After a user reports a fault to a carrier, maintenance engineers use the DHCP simulation function
of the U2000 to simulate the process of making the user online on an access device and checks
the connectivity between the access device and the remote server.

Equipment
Procedure
Step 1 Choose Fault > IP NE Test from the main menu.
Step 2 In the dialog box that is displayed, choose Application Layer Diagnosis > DHCP Emulate.
You must enter the MAC address and Option field for the user as well as remote server IP
addresses. A maximum of five remote servers are supported.
Step 3 Click Run.
Step 4 Refer to the operation result and ping test result to determine the fault causes.

Equipment
l If the simulate test succeeds, the DHCP server can properly assign IP addresses to the user.
l If the ping test succeeds, the remote server can be properly accessed.
----End
Follow-up Procedure
Use the same method to perform DHCP simulation on access devices at different layers on the
network and determine the layer at which devices do not function properly.
4.3 NE-side Alarm Fault Detection

With this function, you can detect SNMP configurations related to NE alarms.
Context
Errors of SNMP configurations related to NE alarms are the major cause of the failure that the
U2000 cannot receive alarms from NEs. Using this function, you can detect related SNMP
configurations. The SNMP configuration check and modification efficiency is improved.
Procedure
Step 1 In the Main Topology, select the desired NE, right-click, and choose NE-site Alarm Fault
Detection from the shortcut menu.
Step 2 Click Start Detection.

The following figure indicates that the detection is in progress.
The following figure indicates that the detection has finished and detection results are displayed.

Equipment
----End
Follow-up Procedure
The following figure illustrates the detection result page.
The following figure illustrates the detection result details page.


ATN 910&910I&910B&950B V200R003C10 Fault Diagnosis 01 (U2000)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ATN 910&910I&910B&950B V200R003C10 Fault Diagnosis 01 (U2000)

Încărcat de

Drepturi de autor:

Formate disponibile

ATN 910&910I&910B&950B Multi-Service Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2014-01-31) Huawei Proprietary and Confidential i

About This Document

The usage precautions are as follows:

Product Name Version

l ATN 910 V200R003C10

Huawei iManager U2000 V200R001C00

l System maintenance engineers

Issue 01 (2014-01-31) Huawei Proprietary and Confidential ii

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Changes in Issue 01 (2014-01-31)

Issue 01 (2014-01-31) Huawei Proprietary and Confidential iii

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

3 Locating Faults Based on Path Visualization.........................................................................87

Issue 01 (2014-01-31) Huawei Proprietary and Confidential iv

4.2 Test and Diagnosis........................................................................................................................................................98

Issue 01 (2014-01-31) Huawei Proprietary and Confidential v

1 Roadmap and Process

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 1

Figure 1-1 IP network troubleshooting process

Locating Faults Based on Locating Faults Based on

Performance Service Others

Locating Locating Manual

Trouble Symptom Suggestion

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 2

Trouble Symptom Suggestion

Service-related alarms are The U2000 provides the fault locating

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 3

Figure 1-2 Viewing the trail domains of faults

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 4

2 Locating Faults Based on Alarm Information

About This Chapter

2.1 Common Alarm Locating

2.2 Locating Performance Faults

2.3 Locating Service Faults

2.4 Top Alarm Handling Examples

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 5

2.1 Common Alarm Locating

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 6

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 7

2.2 Locating Performance Faults

Step 2 Select a performance TCA and view alarm details.

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 8

Check whether the value of Threshold is set properly.

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 9

2.3 Locating Service Faults

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 10

Step 2 Perform the following operations to locate and rectify faults:

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 11

2. On the Configuration tab page, select the trail to be commissioned. On Diagnosis

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 12

3. Click Run to perform test on one or more trails to be commissioned.

Issue 01 (2014-01-31) Huawei Proprietary and Confidential 13

2.4 Top Alarm Handling Examples