handling common faults and alarms on the rtn network-20110711-a

Handling Common Faults and Alarms on the RTN Network2011-5-5
A
1
Huawei Confidential
:32-35pt : R153 G0 B0 : FrutigerNext LT Medium : Arial :30-32pt : R153 G0 B0 : :20-22pt (2-5) :18pt : : FrutigerNext LT Regular : Arial :18-20pt (2-5):18pt : :

.
3
1
4
5
10
Huawei Confidential

.
3
Huawei Confidential

.
Check the flow of services, including service add/drop nodes, network topologies, and configuration of convergence NEs.
Check the time when service interruption occurs and the triggered events, the time when services recover and the triggered events.
Check current and historical alarms and current and historical 15-minute and 24-hour events reported by the NMS and NEs.
Check black box records, errlog records, debugbuf logs, and dopra logs.
Check records of manual operations, operation records on the NMS, and oplog records on NEs. Check version information, NE configuration, and board configuration.
Collect fault information by using specific tools.
4
Huawei Confidential

.
3
1
4
5
10
Huawei Confidential

.
6
Huawei Confidential

.
Fault Type
Common Cause
Rx power is always lower than normal value.
Antennas are not aligned. Antennas have different polarization directions. Transmission is blocked by mountains or buildings. Antennas malfunction or the connection between antennas and ODUs is faulty, such as wet waveguide interface and loosely-installed flexible waveguide. The ODU is faulty.
Slow up-fading causes abnormal Rx power.
There is external interference.
Fading margin is insufficient.
Multipath fading is severe.
Rx power is normal, but the microwave link is faulty unidirectionally.
There is external interference.
Huawei Confidential

.
Handling Procedure
Handling Method
Check for incorrect operations.
Focus on: Whether the ODU is powered off Whether the ODU is muted Whether a loopback is performed on the IF board Whether the configuration is consistent at the two ends Whether the configuration matches the models of ODUs and combiners Whether the E1 capacity is consistent at the two ends for the Hybrid microwave
8
Huawei Confidential

.
Handling Procedure
Handling Method
Handle abnormal Tx power.
Huawei Confidential

.
Handling Procedure
Handling Method
Handle lower-than-normal Rx power.
If Rx power declines rapidly and remains lower than normal, check the installation of antennas and ensure that the azimuth of antennas meets the planning requirements. Check the antenna direction. Especially, check whether the received signal is from the main lobe. If antennas are not aligned, align antennas. On a 1+1 HSB microwave link, if the Rx power difference between the active and standby ODUs at one end is higher than 9 dB (for non-balanced combiners) or 5 dB (for balanced combiners), perform 1+1 switching or replace ODUs/combiners to determine the faulty component. If the RSL difference between the two ends is higher than 10 dB, replace ODUs to determine the faulty component. Check the polarization directions of antennas and adjust the incorrect polarization direction. Replace ODUs/combiners to determine the faulty component. Check whether transmission is blocked by any mountains or buildings. Check the antenna gain at the two ends and replace the antennas that do not provide required antenna gain.
10
Huawei Confidential

.
Handling Procedure
Handling Method
Handle fading.
To handle down-fading: Increase the installation heights of antennas. Reduce the transmission distance. Increase the antenna gain. Increase Tx power. To handle fast fading: Contact the network planning department for appropriate plan changes, such as: Adjust the position of the antenna to block the reflected wave or make the reflection point fall on the ground that has a small reflection coefficient, reducing multipath fading. Configure 1+1 SD for microwave links. For microwave links with 1+1 SD, adjust the height difference between two antennas to make one's Rx power higher than the other's Rx power. Increase fading margins by using larger-diameter antennas or raising antennas' Tx power. To handle up-fading: Check for co-channel interference. Use a spectrum analyzer to analyze interference sources. Contact the spectrum management department for clearing the interference spectrum, or change plans to minimize the interference.
11
Huawei Confidential

.
Handling Procedure
Handling Method
Handle interference.
Check for co-channel interference. Check for adjacent channel interference. Use a spectrum analyzer to analyze interference sources. Contact the spectrum management department for clearing the interference spectrum, or change plans to minimize the interference.
Locate faults by performing loopbacks.
Perform an inloop on the IF port. Replace the IF board if the fault persists. Check cable connectors and redo the substandard ones. Check IF cables and replace those that are soggy, broken, or pressed. Replace the ODU. If the fault is rectified after replacement, you can infer that the ODU is faulty.
12
Huawei Confidential

.
Locating Faults of Microwave Links - Common Alarms
The CONFIG_NOSUPPORT is an alarm indicating that the configuration is not supported.
Possible Causes
Cause 1: The model and configuration parameters of the ODU do not meet the requirements.
Cause 2: On Hybrid microwave links, the configured ODU's Tx power is beyond the allowed range. (On Hybrid microwave links, which are composed of IFH2 boards, the maximum Tx power of ODUs is determined by the IF modulation mode and AM enabling status.)
Handling Procedure
Cause 1: The model and configuration parameters of the ODU do not match the requirements.
Check the alarm parameters to determine the configuration parameters that do not meet the requirements.
If the alarm parameter is 0x01-0x03, check whether the configuration parameters of the ODU port meet the requirements of network planning.
If the alarm parameter is 0x04-0x06, check whether the configuration parameters of the IF port meet the requirements of network planning. If not, change the parameter settings.
13
Huawei Confidential

.
The RADIO_RSL_LOW is an alarm indicating that the RSL is over low.
Possible Causes
Cause 1: Certain other alarms occur at the opposite site.
Cause 2: The opposite Tx power is over low.
Cause 3: Signal attenuation on the microwave link is heavy.
14
Huawei Confidential

.
Handling Procedure
Cause 1: Certain other alarms occur at the opposite site. Check whether any of the following alarms is reported at the opposite site. If yes, clear the alarm immediately.
RADIO_MUTE
CONFIG_NOSUPPORT
RADIO_TSL_LOW
BD_STATUS
Cause 2: The opposite Tx power is over low.
Check whether the opposite Tx power is normal. If not, replace the opposite ODU.
Check whether the opposite NE is powered off.
15
Huawei Confidential

.
Cause 3: Signal attenuation on the microwave link is heavy.
Check whether the alarm is repeatedly reported among historical alarms. If the alarm is reported occasionally, contact the network planning department for improving anti-fading performance.
Check whether the antennas at both ends are aligned. If not, realign the antennas.
Check whether transmission is blocked by any mountains or buildings. If yes, contact the network planning department for avoiding the block.
Check whether the polarization direction is set correctly for the antennas, ODUs, and combiners at both ends. If not, correct the polarization direction.
Check whether the outdoor units such as antennas, combiners, ODUs, and flexible waveguides are wet, damp, or damaged. If yes, replace the faulty component.
Check the antenna gain at the two ends and replace the antennas that do not provide required antenna gain.
16
Huawei Confidential

.
The MW_LOF is an alarm indicating the loss of microwave frames.
Possible Causes
Cause 1: The microwave link performance degrades.
Cause 2: The IF working mode of the local site is different from that of the opposite site.
Cause 3: The operating frequency of the local ODU is different from that of the opposite ODU.
Cause 4: The transmit unit of the opposite site is faulty.
Cause 5: The receive unit of the local site is faulty.
Handling Procedure
17
Huawei Confidential

.
The MW_FECUNCOR is an alarm indicating that uncorrectable errors exist in the forward error correction (FEC) coding of microwave frames.
Possible Causes
Cause 1: The receive power of the ODU is abnormal.
Cause 2: The transmit unit of the opposite site is faulty.
Cause 3: The receive unit of the local site is faulty.
Cause 4: Interference exists.
18
Huawei Confidential

.
The HARD_BAD is an alarm indicating hardware errors.
Possible Causes
Cause 2: The alarmed board has hardware errors.
Handling Procedure
Cause 1: Clock tracing is looped.
Check the alarm parameter. The value 0x06 indicates that clock signals are interlocked and therefore the timing loop needs to be cleared.
Cause 2: The alarmed board has hardware errors.
Replace the alarmed board.
Huawei Confidential

.
The BD_STATUS is an alarm indicating that the board cannot be detected.
Possible Causes
Cause 1: If the IDU reports the alarm, the possible causes are as follows:
The board is installed in an incorrect slot.
The board and the backplane are connected incorrectly.
The slot that houses the board is faulty.
The board is faulty.
Cause 2: If the ODU reports the alarm, the possible causes are as follows:
Check whether the IF board reports the HARD_BAD, BD_STATUS, IF_CABLE_OPEN, or VOLT_LOS alarm. If yes, clear the alarm immediately.
The ODU is faulty. Replace the faulty ODU.
20
Huawei Confidential

.
Handling Procedure
Cause 1: If the IDU reports the alarm, handle the alarm as follows:
Check whether the physical slot and logical slot of the alarmed board are the same.
Re-install the alarmed board.
Cause 2: If the ODU reports the alarm, handle the alarm as follows:
Check whether the alarm is caused by other alarms.
Replace the faulty ODU.
Huawei Confidential

.
22
Huawei Confidential

.
ETH
Possible Causes
1. Fiber cuts 2. Faulty optical modules 3. Excessive optical attenuation
ETH_LINK_DOWN
Possible Causes
1. Negotiation fails due to different working modes at the two ends. 2. Electrical cables, fiber connections, or opposite units are faulty.
MAC_FCS_EXC
Possible Causes
1. Excessive bit errors are detected at the MAC layer. 2. Line signals degrade. 3. Fiber performance deteriorates. 4. Optical ports are dirty.
BTS 1
Huawei Confidential

.
Common Alarms on Ethernet Ports (1)
The ETH_LOS is an alarm indicating loss of connection on Ethernet ports.
Possible Causes
Cause 1: The electrical cable or fiber on the Ethernet port is incorrectly connected.
Cause 2: The electrical cable or fiber on the Ethernet port is faulty.
Cause 3: The local Rx power is over low.
Cause 4: The alarmed board is faulty.
Handling Procedure
Cause 1: The electrical cable or fiber on the Ethernet port is incorrectly connected.
Verify that the electrical cable or fiber on the Ethernet port is correctly connected.
Cause 2: The electrical cable or fiber on the Ethernet port is faulty.
Replace the faulty electrical cable or fiber.
Cause 3: The local Rx power is over low.
Check for the OUT_PWR_ABN alarm on the opposite NE and clear the alarm immediately if it is reported. If the alarm persists then, clean the receive optical port and fiber connector. If the alarm persists then, verify that the flange and optical attenuator are used correctly. If the alarm persists then, add or remove optical attenuators to achieve normal Rx power.
Replace the alarmed board. If the alarm persists, replace the mapping board at the opposite end.
24
Huawei Confidential

.
The ETH_LINK_DOWN is an alarm indicating that the connection on the network port is faulty.
Possible Causes
Cause 1: Negotiation fails due to different working modes at the two ends.
Cause 2: An inloop is performed on the port.
Cause 3: The fiber is connected to an incorrect port.
Cause 4: A certain board is faulty.
Handling Procedure
Cause 1: Negotiation fails due to different working modes at the two ends.
Verify that the working modes are the same at the two ends.
Cause 2: An inloop is performed on the port.
Check for the LOOP_ALM alarm at the two ends and clear the alarm immediately if it is reported.
Cause 3: The fiber is connected to an incorrect port.
Check whether the fiber on the alarmed port is connected to an incorrect port. If yes, connect the fiber to a correct port.
Check for hardware-related alarms (such as HARD_BAD) at the two ends and replace the board that reports any of these alarms.
25
Huawei Confidential

.
The MAC_FCS_EXC is an alarm indicating that excessive bit errors are detected at the MAC layer.
Possible Causes
Cause 2: The input optical power is abnormal.
Cause 3: The fiber connector is dirty.
Handling Procedure
Cause 1: The line signals deteriorate.
Check for the LOOP_ALM alarm on the NMS and clear the alarm immediately if it is reported. If the alarm persists then, check for DOS attacks and eradicate any sources that transmit a large amount of invalid data. If the alarm persists then, verify that the fiber and electrical cable are normal.
Cause 2: The input optical power is abnormal.
Check whether the alarmed port also reports IN_PWR_ABN. If yes, clear the IN_PWR_ABN alarm immediately.
Cause 3: The fiber connector is dirty.
Clean the fiber connector and the receive optical port.
26
Huawei Confidential

.
ETH
Possible Causes
1. Fiber cuts 2. Excessive loss on the line 3. Malfunction of opposite transmit units
R_LOC
Possible Causes
1. Failure in received signals 2. Malfunction of clock extraction modules
R_LOF
Possible Causes
1. Excessive attenuation of received signals 2. Unframed structure of signals from the opposite site 3. Malfunction of local receive units
BTS 1
Huawei Confidential

.
Common Alarms on SDH Ports (1)
The R_LOS is an alarm indicating loss of signals on the receive side of the line.
Possible Causes
Cause 1 of lasers: The local optical port is not used but the local laser is open.
Cause 2 of lasers: The local laser is open but the opposite laser is closed, so there is no output of optical signals.
Cause 1 of fibers: No pigtail is connected to the local optical port or the pigtail on the local optical port is connected incorrectly.
Cause 2 of fibers: Fiber cuts occur.
Cause 3 of fibers: Rx power is over low.
Cause 1 of boards: The local receive board is faulty.
Cause 2 of boards: The opposite transmit board is faulty.
Handling Procedure
Cause 1 of lasers: The local optical port is not used but the local laser is open.
Check the enabling status of the local laser on the NMS and close the laser if it is open.
Cause 2 of lasers: The local laser is open but the opposite laser is closed, so there is no output of optical signals.
Check the enabling status of the opposite laser on the NMS and open the laser if it is closed.
28
Huawei Confidential

.
Handling Procedure
Cause 1 of fibers: No pigtail is connected to the local optical port or the pigtail on the local optical port is connected incorrectly.
Verify that the pigtail on the local optical port is correctly connected.
Cause 2 of fibers: Fiber cuts occur.
Replace broken fibers.
Cause 3 of fibers: Rx power is over low.
Check for the OUT_PWR_ABN alarm on the opposite transmit port and clear the alarm immediately if it is reported. If the alarm persists then, clean the receive optical port and fiber connector. If the alarm persists then, verify that the flange and optical attenuator are used correctly. If the alarm persists then, add or remove optical attenuators to achieve normal Rx power.
Cause 1 of boards: The local receive board is faulty.
If the local Rx power is normal, set an inloop for the local receive port. If the alarm persists, the local board is faulty and needs to be replaced.
Cause 2 of boards: The opposite transmit board is faulty.
Replace the opposite transmit board. If the alarm persists, replace the opposite cross- connect board.
29
Huawei Confidential

.
Common Alarms on SDH Ports (2)
The R_LOF is an alarm indicating loss of frames on the receive side of the line.
Possible Causes
Cause 1: Different types of optical modules are used at the two ends.
Cause 3: Fibers are misconnected.
Cause 4: The signals transmitted from the opposite site do not have the frame structure.
Cause 5: The local receive board is faulty.
Handling Procedure
Cause 1: Different types of optical modules are used at the two ends.
Verify that optical modules of one type are used at the two ends.
Check whether the alarmed port also reports IN_PWR_ABN. If yes, clear the IN_PWR_ABN alarm immediately.
30
Huawei Confidential

.
Handling Procedure
Verify that fibers are connected correctly.
Cause 4: The signals transmitted from the opposite site do not have the frame structure.
Check for the HARD_BAD alarm on the opposite transmit board and clear this alarm immediately if it is reported.
Cause 5: The local receive board is faulty.
Check for the HARD_BAD alarm on the local receive board and clear this alarm immediately if it is reported.
31
Huawei Confidential

.
ETH
Possible Causes
1. E1/T1 services are not received. 2. Fibers on the DDF-side E1/T1 output ports are disconnected or loosely connected. 3. Fibers on local E1/T1 output ports are disconnected or loosely connected. 4. A certain board is faulty. 5. The electrical cable is faulty.
ALM_E1RAI
BTS 1
Huawei Confidential

.
Common Alarms on E1 Ports (1)
The T_ALOS is an alarm indicating loss of signals on E1 ports.
Possible Causes
Cause 1: The opposite site does not transmit any E1 services.
Cause 2: E1 cables are disconnected or loosely connected.
Cause 3: The opposite equipment is faulty.
Cause 4: The electrical cable is faulty.
Handling Procedure
Cause 1: The opposite site does not transmit any E1 services.
Verify that the opposite site transmits E1 services properly.
Cause 2: E1 cables are disconnected or loosely connected.
Verify that E1 cables are correctly connected.
33
Huawei Confidential

.
Handling Procedure
Cause 3: The opposite equipment is faulty.
Perform a self-loop for the alarmed channel on the DDF side. If the alarm clears, the opposite equipment is faulty and the fault needs to be rectified.
Cause 4: The electrical cable is faulty.
Perform a self-loop for the alarmed channel on the DDF side. If the alarm persists, perform a self-loop for the alarmed channel on the interface board side. If the alarm clears, the E1 cable is faulty and needs to be replaced.
Perform a self-loop for the alarmed channel on the interface board side. If the alarm persists, set an inloop for the alarmed channel on the NMS. If the alarm clears, the interface board is faulty and needs to be replaced.
34
Huawei Confidential

.
The UP_E1_AIS is an alarm indicating upstream E1 signals. This alarm is reported when the upstream E1 signal is all 1s.
Possible Causes
Cause 2: An inloop is set for the E1 port.
Cause 3: Some boards are faulty.
Handling Procedure
Cause 1: The opposite site reports the T_ALOS alarm.
Check for the T_ALOS alarm on the opposite site and clear this alarm immediately if it is reported.
Cause 2: An inloop is set for the E1 port.
Check whether the E1 port reports the LOOP_ALM alarm on the NMS. If yes, release the inloop on the E1 port.
On the NMS, check whether the local NE and the opposite NE report any hardware-related alarms such as HARD_BAD. If yes, perform a cold reset for the boards that report hardware-related alarms. If the alarm persists then, replace the boards that may be faulty.
35
Huawei Confidential

.
The DOWN_E1_AIS is an alarm indication for downstream 2 Mbit/s signals. This alarm is reported when the downstream E1 signal is all 1s.
Possible Causes
Cause 1: The alarmed board also reports the UP_E1_AIS or T_ALOS alarm.
Handling Procedure
Cause 1: The alarmed board also reports the UP_E1_AIS or T_ALOS alarm.
Check whether the alarmed board reports the UP_E1_AIS or T_ALOS alarm on the NMS. If yes, clear the UP_E1_AIS or T_ALOS alarm immediately.
On the NMS, check whether the alarmed board and local cross-connect board report any hardware-related alarms such as HARD_BAD. If yes, perform a cold reset for the boards that report hardware-related alarms. If the alarm persists, replace the boards that may be faulty.
36
Huawei Confidential

.
Common Alarms on Other Links (1)
The IN_PWR_ABN is an alarm indicating that the input optical power is abnormal.
Possible Causes
Cause 1: The opposite transmit power is abnormal.
Cause 2: The local receive power is higher than the upper threshold.
Cause 3: The local receive power is lower than the lower threshold.
Cause 4: The receive board is faulty.
Handling Procedure
Cause 1: The opposite transmit power is abnormal.
On the NMS, check whether the opposite site reports the OUT_PWR_ABN alarm. If yes, clear this alarm immediately and check whether the IN_PWR_ABN is cleared. If the alarm persists, query the local receive power and handle the alarm according to other causes.
Cause 2: The local receive power is higher than the upper threshold.
Add proper optical attenuators to the receive optical port and adjust the input optical power to a normal value.
37
Huawei Confidential

.
Handling Procedure
Cause 3: The local receive power is lower than the lower threshold.
Verify that the bending radius of the pigtail on the local site is no smaller than 6 cm. If the alarm persists, use proper optical attenuators and correctly connect the local optical module. If the alarm persists, replace the optical module and clean the fiber connectors at the two ends.
Cause 4: The receive board is faulty.
Check whether the processing board and cross-connect board on the local site report any hardware-related alarms such as HARD_BAD and TEMP_OVER. If yes, replace the boards that report hardware-related alarms.
38
Huawei Confidential

.
The OUT_PWR_ABN is an alarm indicating that the output optical power is abnormal.
Possible Causes
Cause 1: The output optical power is over high or over low.
Handling Procedure
Cause 1: The output optical power is over high or over low.
Replace the optical module of the alarmed port.
Huawei Confidential

.
The LOOP_ALM is an alarm of loopbacks.
Possible Causes
Handling Procedure
Cause 1: The port is looped back.
On the NMS, check whether the alarmed port is looped back. If yes, release the loopback.
Cause 2: The service is looped back.
On the NMS, check whether the service is looped back. If yes, release the loopback. For Ethernet services, enable the automatic shutdown function for looped-back ports.
40
Huawei Confidential

.
The FLOW_OVER is an alarm indicating the traffic received by the port is higher than the threshold.
Possible Causes
Cause 1: The traffic received by the port is higher than the preset threshold of the port.
Handling Procedure
Cause 1: The traffic received by the port is higher than the preset threshold of the port.
Check whether the actual received traffic indicated by the alarm parameter is higher than the port bandwidth. If yes, reduce the data transmitted by the opposite site.
Configure the service on an unused port.
41
Huawei Confidential

.
3
1
4
5
10
Huawei Confidential

.
43
Huawei Confidential

.
Fault Type
Common Cause
Equipment faults
Over high board temperature causes bit errors. Clock tracing fails and the upstream link clocks need to be checked. The board reports the HARD_BAD alarm, and clock tracing needs to be checked or some boards need to be replaced.
Regenerator section (RS) errors
The line is faulty. On optical lines, optical power is abnormal, fiber performance deteriorates, or fiber splice and fiber connectors are dirty. On STM-1 electrical lines, electrical cables deteriorate, grounding is incorrect, or connectors are incorrectly connected. On microwave links, the MW_FEC_UNCOR or RPS_INDI alarm is reported. The line board fails. The clock unit fails. Clock quality deteriorates on the network. Clock quality deterioration on the network causes pointer justifications.
44
Huawei Confidential

.
Fault Type
Common Cause
There are multiplex section (MS) errors and higher order path (HOP) errors, but not RS errors.
The line board is faulty. Clock quality deteriorates on the network. Clock quality deterioration on the network causes pointer justifications. Operating temperature on the line board is over high.
There are only lower order path (LOP) errors.
The PDH service processing board or Ethernet service processing board is faulty. The cross-connect board is faulty. The PDH service processing board or Ethernet service processing board has over high working temperature. The working temperature on the cross-connect board is over high. Unstable power supply, incorrect grounding, or external interference exists.
45
Huawei Confidential

.
Procedure
Handle pointer justifications.
Analyze and process clock alarms. Ensure that the configuration is correct and fibers are correctly connected. Locate the sites with clock asynchronization by changing clock configuration. Replace the components with poor performance.
46
Huawei Confidential

.
Procedure
Handle the RS errors on the SDH optical interface board.
Exchange the fiber cores in the transmit and receive directions on a section of optical channel. If errors change after the fiber cores are exchanged, the fibers are faulty or the equipment malfunctions at the two ends. If fibers are faulty, check whether the fiber from the equipment to the optical distribution frame (ODF) and the fiber that is led out from the telecommunications room are pressed, and whether any fiber connector is dirty or damaged. If the equipment at the two ends is faulty, locate the fault by performing loopbacks on optical ports. If the fault persists after the loopback on a site, the line board on the site is faulty. If the equipment at the two ends is faulty, replace the alarmed board or exchange the slots of the alarmed board and anther working SDH optical interface board. If the alarm is still reported by the alarmed board, the alarmed board is faulty.
Handle the RS errors on the IF board.
Check for the MW_FEC_UNCOR and RPS_INDI alarms. If any of these alarms is reported, clear the alarm immediately. If none of these alarms is reported, replace the IF board.
47
Huawei Confidential

.
Procedure
Handle the RS errors on the STM-1 electrical interface board.
Exchange the electrical cables in the receive and transmit directions. If errors change after the exchange, the electrical cables are faulty or the equipment at the two ends is faulty. Check whether the electrical cables are grounded properly and whether the cable connectors and cables are damaged. If the equipment at the two ends is faulty, locate the fault by performing loopbacks on electrical ports. If the fault persists after a loopback is performed on a site, the line board on the site is faulty. If the equipment at the two ends is faulty, replace the alarmed board or exchange the slots of the alarmed board and anther working SDH electrical interface board. If the alarm is still reported by the alarmed board, the alarmed board is faulty.
Handle the MS errors and HOP errors.
Perform a loopback on the alarmed board. If the alarm persists, replace the alarmed board. If the alarm clears, replace the transmit line board, which corresponds to the alarmed board. If the alarm persists after board replacement, check for unstable power supply, improper grounding, and external interference on the SDH electrical interface board.
1
Huawei Confidential

.
Procedure
Handle LOP errors.
Replace PDH service processing boards, Ethernet service processing boards, or cross-connect boards along the overlapped route of errored services. If the alarm persists after board replacement, check for unstable power supply, improper grounding, and external interference.
2
Huawei Confidential

.
Locating Faults of TDM Services - Common Alarms
The MW_CFG_MISMATCH is an alarm indicating a configuration mismatch on microwave links.
Possible Causes
Cause 1: The number of E1 signals is different on both ends of a microwave link (including the number of E1 signals
on the active page and the number of E1 signals on the standby page).
Cause 2: The AM enabling is different on both ends of a microwave link.
Cause 3: The IEEE 1588 overhead enabling is different on both ends of a microwave link.
Cause 4: The modulation mode is different on both ends of a microwave link.
Cause 5: The channel spacing is different on both ends of a microwave link.
Handling Procedure
Cause 1: The number of E1 signals is different on both ends of a microwave link.
Cause 2: The AM enabling is different on both ends of a microwave link.
Cause 3: The IEEE 1588 overhead enabling is different on both ends of a microwave link.
Cause 4: The modulation mode is different on both ends of a microwave link.
Cause 5: The channel spacing is different on both ends of a microwave link.
Determine the possible cause of the alarm according to the alarm parameters. Then, check the configuration on both ends of the microwave link. Ensure that the configuration is the same on both ends of the microwave link.
3
Huawei Confidential

.
3
1
4
5
10
Huawei Confidential

.
5
Huawei Confidential

.
Symptom
Huawei Confidential

.
Symptom
HARD_BAD, TEMP_OVER, or BUS_ERR
7
Huawei Confidential

.
Locating Faults of CES Services - Common Causes
Cause 1: The board carrying CES services cannot work properly due to hardware errors, over-high temperature, or inter-board communication failure.
Cause 2: The signal transmitted to the processing board or interface board is lost or degrades.
Cause 3: The tunnel or PW carrying CES services is interrupted.
Cause 4: On the NE, the priority of synchronization clock source is lost, or the synchronization clock source is lost.
Cause 5: On the PW carrying CES services, the number of lost packets, errored packets, or jitters within a time unit crosses the threshold.
8
Huawei Confidential

.
Locating Faults of CES Services - Handling Method
Cause 1: The board carrying CES services cannot work properly due to hardware errors, over-high temperature, or inter-board communication failure.
Handle the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm if any of them is reported.
Cause 2: The signal transmitted to the processing board or interface board is lost or degrades.
Handle the T_ALOS, UP_E1_AIS, DOWN_E1_AIS, R_LOS, LASER_MOD_ERR, LSR_WILL_DIE, IN_PWR_ABN, TEM_HA, or LSR_BCM_ALM alarm if any of them is reported.
Cause 3: The tunnel or PW carrying CES services is interrupted.
Enable MPLS OAM. Handle the MPLS_TUNNEL_LOCV alarm if it is reported.
Cause 4: On the NE, the priority of synchronization clock source is lost, or the synchronization clock source is lost.
Handle the SYNC_C_LOS or LTI alarm if any of them is reported.
Cause 5: On the PW carrying CES services, the number of lost packets, errored packets, or jitters within a time unit crosses the threshold.
Handle the CES_LOSPKT_EXC, CES_MISORDERPKT_EXC, CES_STRAYPKT_EXC, CES_JTRUDR_EXC, or CES_JTROVR_EXC alarm if any of them is reported.
9
Huawei Confidential

.
The CES_JTROVR_EXC/CES_JTRUDR_EXC is an alarm indicating the overflow/underflow of CES jitters.
Possible Causes
Cause 2: Link quality deteriorates, causing more jitters.
Cause 3: The size of buffer area is set to a low value.
Cause 4: There are too many hops of microwave link on the network side, which generates a large number of jitters.
Handling Procedure
Cause 1: Clock synchronization cannot be performed.
On the NMS, check whether the LTI or other clock alarms are reported. If yes, clear these alarms.
Cause 2: Link quality deteriorates, causing more jitters.
Check whether the alarmed port also reports IN_PWR_ABN or TEM_HA. If yes, clear the IN_PWR_ABN or TEM_HA alarm immediately.
Cause 3: The size of buffer area is set to a low value.
On the NMS, increase the size of buffer area if possible.
Cause 4: There are too many hops of microwave link on the network side, which generates a large number of jitters.
Reduce the number of hops on the network side.
10
Huawei Confidential

.
Common Alarms of CES Services (2)
The CES_LOSPKT_EXC is an alarm indicating packet loss of CES services.
Possible Causes
Cause 2: Parameter settings are different at the two ends of CES services.
Cause 3: The tunnel or PW carrying CES services is congested.
Cause 4: The link signal deteriorates or is interrupted due to a fault of cables, optical fibers, or optical modules.
Handling Procedure
Modify the parameter settings to the same.
On the NMS, check whether the bandwidth configured for the tunnel or PW is too low and whether the QoS parameters are set properly. If the bandwidth and QoS settings cannot meet the requirements of CES services, increase the bandwidth, replan the service trail, and change QoS settings.
Verify that electrical cables and fibers are correctly connected to the ports. Clean the fiber connectors and optical modules. If the alarm persists, replace the cables, fibers, or optical modules that may be faulty.
11
Huawei Confidential

.
The CES_MALPKT_EXC is an alarm indicating deformed packets of CES services.
Possible Causes
Cause 1: Parameters of CES services are set incorrectly.
Handling Procedure
Modify the incorrect parameter settings on the NMS.
12
Huawei Confidential

.
The CES_MISORDERPKT_EXC is an alarm indicating disordered packets of CES services.
Possible Causes
Handling Procedure
13
Huawei Confidential

.
The CES_STRAYPKT_EXC is an alarm indicating errored packets of CES services.
Possible Causes
Cause 2: Fibers or cables are connected incorrectly.
Handling Procedure
Modify the parameter settings to the same.
Reconnect the fibers or cables correctly.
14
Huawei Confidential

.
15
Huawei Confidential

.
Symptom
LASER_SHUT or LSR_WILL_DIE
HARD_BAD, TEMP_OVER, or BUS_ERR
Huawei Confidential

.
Locating Faults of ETH Services - Common Causes
Cause 1: The board carrying ETH services cannot work properly due to hardware errors, over-high temperature, or inter-board communication failure.
Cause 2: The signal is lost in the receive direction.
Cause 3: Negotiation between Ethernet ports fails due to incorrect connections on Ethernet ports.
Cause 4: Loopbacks are performed for Ethernet ports.
Cause 5: Traffic limit on Ethernet ports is set to a low value or parameter settings are different on source and sink ports.
17
Huawei Confidential

.
Locating Faults of ETH Services - Handling Method
Cause 1: The board carrying ETH services cannot work properly due to hardware errors, over-high temperature, or inter-board communication failure.
Handle the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm if any of them is reported.
Cause 2: The signal is lost in the receive direction.
Handle the ETH_LOS, R_LOS, LASER_SHUT, or LSR_WILL_DIE alarm if any of them is reported.
Cause 3: Negotiation between Ethernet ports fails due to incorrect connections on Ethernet ports.
Handle the ETH_LINK_DOWN alarm if it is reported.
Cause 4: Loopbacks are performed for Ethernet ports.
Handle the LOOP_ALM or ETH_EFM_LOOPBACK alarm if any of them is reported.
Cause 5: Traffic limit on Ethernet ports is set to a low value or parameter settings are different on source and sink ports.
Handle the FLOW_OVER or ETH_CFM_UNEXPERI alarm if any of them is reported.
Check whether the working modes of interconnected Ethernet ports are the same.
18
Huawei Confidential

.
19
Huawei Confidential

.
Common Symptoms
MPLS tunnels cannot be created, and therefore services cannot be provisioned.
MPLS tunnels are faulty, causing service interruption.
Protection switching fails, causing service interruption, packet loss, or bit errors.
Common Causes
Cause 2: The physical links carrying the tunnels are faulty.
Cause 3: Protection switching fails.
20
Huawei Confidential

.
Cause 1: Cross-connections cannot be created.
1. Check the IP address of each NE on the LSP. If the IP addresses of two NEs are on the same network segment, change the IP addresses to values on different network segments.
2. Check whether incompatible features are configured for the tunnel.
3. Check whether the number of created tunnels reaches the maximum value. If yes, replan tunnels or delete redundant tunnels.
Cause 2: The physical links carrying the tunnels are faulty.
1. Handle the HARD_BAD, R_LOS, ETH_LOS, MPLS_TUNNEL_BDI, MPLS_TUNNEL_Excess, MPLS_TUNNEL_FDI, or MPLS_TUNNEL_LOCV alarm if any of them is reported.
2. Check whether any exceptions (such as board failure or NE reset) occur on the opposite equipment. If yes, handle the exceptions.
Cause 3: Protection switching fails.
1. MPLS APS protection switching fails. Handle the failure.
21
Huawei Confidential

.
Locating Tunnel Faults – Common Alarms (1)
The MPLS_TUNNEL_LOCV is an alarm indicating the loss of tunnel connectivity.
Possible Causes
Cause 1: The ingress node on the tunnel stops transmitting CV/FFD packets.
Cause 2: The physical link carrying the tunnel is faulty.
Cause 3: Some boards on the ingress node are being reset.
Cause 4: The service interface is configured incorrectly.
Cause 5: Severe congestion occurs on the network.
Cause 6: The CPU is highly occupied and cannot process ARP protocol packets.
Handling Procedure
Cause 1: The ingress node on the tunnel stops transmitting CV/FFD packets.
1. Check whether the settings of detection mode and detection packet type are consistent on the two ends. If not, make consistent settings.
2. Check the parameter of CV/FFD status on the ingress node. If the CV/FFD status is disabled, change it to enabled.
Cause 2: The physical link carrying the tunnel is faulty.
On the NMS, check whether the egress node reports the HARD_BAD, ETH_LOS, or ETH_LINK_DOWN alarm. If yes, clear this alarm.
22
Huawei Confidential

.
Handling Procedure
Cause 3: Some boards on the ingress node are being reset.
On the NMS, check whether the ingress node reports the COMMUN_FAIL alarm. If yes, clear this alarm.
Cause 4: The service interface is configured incorrectly.
Check whether the tunnel is configured on a proper port according to the NE planning table.
Cause 5: Severe congestion occurs on the network.
Check the bandwidth utilization of each port on the LSP. If the bandwidth of some ports is exhausted, allocate some traffic to other links or increase the bandwidth of congested ports.
Cause 6: The CPU is highly occupied and cannot process ARP protocol packets.
Check for the CPU_BUSY alarm on the NMS and clear this alarm immediately if it is reported.
23
Huawei Confidential

.
The MPLS_TUNNEL_BDI/MPLS_TUNNEL_FDI is an alarm indicating defects in the forward/backward direction of a tunnel.
Possible Causes
Cause: The upstream NE detects that the tunnel at the physical layer is faulty
Handling Procedure
Cause: The upstream NE detects that the tunnel at the physical layer is faulty
On the physical link between the local NE and its upstream NE, check for the faults such as fiber cuts, failure in optical modules, and board failure. Rectify the fault if any.
24
Huawei Confidential

.
Common Symptoms
PWs cannot be created, and therefore services cannot be provisioned.
PWs are faulty, causing service interruption, packet loss, or bit errors.
Common Causes
Cause 1: The physical link carrying the PW is faulty.
Cause 2: Cross-connections of PWs cannot be created.
Cause 3: The tunnels carrying PWs are faulty.
25
Huawei Confidential

.
Cause 1: The physical link carrying the PW is faulty.
1. Check whether the physical link between the ingress and egress nodes is normal. Handle the HARD_BAD, LASER_MOD_ERR, R_LOS, or ETH_LOS alarm if any of them is reported.
2. Check whether any exceptions (such as board failure or NE reset) occur on the opposite equipment. If yes, handle the exceptions.
Cause 2: Cross-connections of PWs cannot be created.
1. Check whether the number of created PWs reaches the maximum value. If yes, replan PWs or delete redundant PWs.
Cause 3: The tunnels carrying PWs are faulty.
1. Handle the faults on tunnels.
26
Huawei Confidential

.
Locating PW Faults – Common Alarms
The PW_DROPPKT_EXC is an alarm indicating that the number of lost packets on the PW crosses the threshold.
Possible Causes
Cause: A small number of packets are lost on the PW.
Handling Procedure
Cause 1: A small number of packets are lost on the PW.
Check whether any service ports on the PW are congested. If yes, replan the trail of services or increase the bandwidth of congested ports.
27
Huawei Confidential

.
3
1
4
5
10
Huawei Confidential

.
Fault Symptoms
1+1 protection switching cannot be triggered.
After the working channel of a 1+1 protection group is restored, services cannot be switched from the protection channel to the working channel.
The following hardware- and service-related alarms occur:
POWER_FAIL, VOLT_LOS, RADIO_TSL_HIGH, RADIO_TSL_LOW, RADIO_RSL_HIGH, IF_INPWR_ABN, CONFIG_NOSUPPORT, R_LOC, R_LOF, R_LOS, MW_LOF, HARD_BAD, MW_RDI
The packet services transmitted on the Hybrid microwave link are unavailable.
1+1 protection switching is delayed.
29
Huawei Confidential

.
Possible Causes
Cause 1: The 1+1 protection group is in forced switching state.
Cause 2: The 1+1 protection group works in non-revertive mode or works in RDI state.
Cause 3: Hardware-related alarms occur.
Cause 4: Connections between the IF board and the EMS6 board are incorrect, or the cable connectors are in poor contact.
Cause 5: Switching is triggered again upon the RDI alarm; anti-jitter function is performed upon service alarms and the RDI alarm; the NE is being reset; the switching between active and standby SCC boards is being performed.
Cause 6: IF cables are connected incorrectly.
30
Huawei Confidential

.
Handling Procedure
Cause 1: The 1+1 protection group is in forced switching state.
Clear the forced switching state.
Cause 2: The 1+1 protection group works in non-revertive mode or works in RDI state.
Set the revertive mode of the protection group to revertive.
Cause 3: Hardware-related alarms occur.
Handle these alarms.
Cause 4: Connections between the IF board and the EMS6 board are incorrect, or the cable connectors are in poor contact.
Re-connect the network cables between the IF board and the EMS6 board or use new cable connectors.
Cause 5: Switching is triggered again upon the RDI alarm; anti-jitter function is performed upon service alarms and the RDI alarm; the NE is being reset; the switching between active and standby SCC boards is being performed.
Perform the 1+1 switching 30 minutes later.
Cause 6: IF cables are connected incorrectly.
Connect IF cables correctly.
Huawei Confidential

.
The RPS_INDI is a microwave protection switching alarm indication.
Possible Causes
Handling Procedure
Troubleshoot the working channel.
Set the revertive mode of the 1+1 protection group to revertive.
32
Huawei Confidential

.
Fault Symptoms
The following hardware- and service-related events occur: performance events of SDH SNCP protection switching
Possible Causes
Cause 1: SNCP switching fails because the NE software version mismatches the board software version.
Cause 2: The working and protection channels of an SNCP protection group fail.
Cause 3: TU_AIS insertion upon E1_AIS is not provided (for OptiX RTN 600 V100R005 and OptiX RTN 900 V100R002C01 and later versions).
33
Huawei Confidential

.
Handling Procedure
Cause 1: SNCP switching fails because the NE software version mismatches the board software version.
Upgrade the NE software or board software.
Cause 2: The working and protection channels of an SNCP protection group fail.
Troubleshoot the channels.
Cause 3: TU_AIS insertion upon E1_AIS is not provided (for OptiX RTN 600 V100R005 and OptiX RTN 900 V100R002C01 and later versions).
Set the TU_AIS insertion upon E1_AIS on the NMS.
34
Huawei Confidential

.
The PS is an alarm indicating protection switching.
Possible Causes
Handling Procedure
Troubleshoot the active channel.
Set the revertive mode of the SNCP protection group to revertive.
35
Huawei Confidential

.
36
Huawei Confidential

.
Symptom
Alarm Reported
The APS protection group is configured incorrectly or APS frames cannot be received.
ETH_APS_PATH_MISMATCH
ETH_APS_LOST
ETH_APS_SWITCH_FAIL
ETH_APS_TYPE_MISMATCH
MPLS_TUNNEL_LOCV
MPLS_TUNNEL_MISMERGE
MPLS_TUNNEL_MISMATCH
MPLS_TUNNEL_Excess
MPLS_TUNNEL_SD
MPLS_TUNNEL_SF
MPLS_TUNNEL_UNKNOWN
37
Huawei Confidential

.
Locating APS Faults - Common Causes
Cause 1: The settings of the APS protection group differ between the two ends.
Cause 2: The APS protection group is deactivated.
Cause 4: APS frames cannot be transmitted because hardware-related alarms occur
on the board that carries the protection channel.
Cause 5: The system reports clock alarms.
Cause 6: The working tunnel or protection tunnel is faulty.
38
Huawei Confidential

.
Locating APS Faults - Handling Method
Check for the ETH_APS_PATH_MISMATCH and ETH_APS_TYPE_MISMATCH alarms. If any of them is reported, handle the alarm.
Check for the ETH_APS_LOST and ETH_APS_SWITCH_FAIL alarms. If any of them is reported, handle the alarm.
Reconnect the fibers or cables.
39
Huawei Confidential

.
Locating APS Faults - Handling Method
Cause 4: APS frames cannot be transmitted because hardware-related alarms occur on the board that carries the protection channel.
Check whether any hardware-related alarms (such as HARD_BAD, COMMUN_FAIL, and BUS_ERR) occur on the board that carries the protection channel. If yes, clear these alarms.
Cause 5: The system reports clock alarms.
Check whether the system reports clock alarms such as TR_LOC, SYNC_C_LOS, and LTI. If yes, clear these alarms.
Cause 6: The working tunnel or protection tunnel is faulty.
Check for tunnel-level alarms. If a tunnel reports a tunnel-level alarm, the tunnel is faulty. Troubleshoot the tunnel.
40
Huawei Confidential

.
Page *
Common APS Alarms (1)
The ETH_APS_LOST is an alarm indicating that APS frames are lost.
Possible Causes
Cause 1: The opposite NE is not configured with APS protection.
Cause 4: The service on the protection channel is interrupted.
Handling Procedure
Cause 1: The opposite NE is not configured with APS protection.
On the NMS, check whether the opposite NE is configured with APS protection. If the opposite NE is configured with APS protection, create a matching APS protection group on the opposite NE and activate the APS protocol.
On the NMS, check whether the settings of the APS protection group are the same at the two ends. If the settings differ between the two ends, change them to the same.
Check whether the APS protocol is activated at both ends. If the APS protocol is deactivated at one end, deactivate the APS protocol at the other end and then activate the APS protocol at both ends.
Cause 4: The service on the protection channel is interrupted.
*
Huawei Confidential

.
Page *
The ETH_APS_SWITCH_FAIL is an alarm indicating a protection switching failure.
Possible Causes
Handling Procedure
On the NMS, check whether the settings of the APS protection group are the same at the two ends. If the settings differ between the two ends, change them to the same. Then, deactivate and activate the APS protection group at the two ends.
The ETH_APS_TYPE_MISMATCH is an alarm indicating a protection scheme mismatch.
Possible Causes
Handling Procedure
Cause: The switching type, switching mode, or revertive mode of the protection group differs between the two ends.
*
Huawei Confidential

.
Page *
*
Huawei Confidential

.
Page *
Symptom
Alarm Reported
The LAG is invalid, all the member ports cannot be used, and the services are interrupted.
LAG_DOWN
The member ports in the LAG cannot be used, and the service has packet loss.
LAG_MEMBER_DOWN
LOOP_ALM
ETH_LOS
ETH_LINK_DOWN
Huawei Confidential

.
Page *
Locating ETH LAG Faults - Common Causes
Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
Cause 2: The working mode of the member ports in the LAG is set to half-duplex.
Cause 3: The loopback is configured on the member ports in the LAG.
*
Huawei Confidential

.
Page *
Locating ETH LAG Faults - Handling Method
Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
(1) Query current alarms and check whether the LAG_DOWN or LAG_MEMBER_DOWN alarm exists.
(2) Check whether the configurations of the NEs at the two ends of the LAG are consistent. If the configurations are inconsistent, modify the configuration as the same, and then check whether the alarm is cleared.
Cause 2: The working mode of the member ports in the LAG is set to half-duplex.
Check whether the working mode of each member port in the LAG is set to half-duplex. If the working mode is set to half-duplex, modify the working mode of each port to full-duplex.
Cause 3: The loopback is configured on the member ports in the LAG.
(1) Check whether the LOOP_ALM alarm exists on each member port in the LAG. If yes, release the loopback on each port to clear the LOOP_ALM alarm.
(2) Check whether the ETH_EFM_LOOPBACK alarm exists on each member port in the LAG. If yes, release the remote loopback to clear the ETH_EFM_LOOPBACK alarm.
Cause 4: The connections of the member ports in the LAG are faulty or lost.
*
Huawei Confidential

.
Page *
Common ETH LAG Alarms (1)
The LAG_DOWN is an alarm indicating that the LAG is unavailable.
Possible Causes
Cause 1: The opposite NE is not configured with any LAGs.
Cause 2: All member ports in the LAG are unavailable.
Handling Procedure
Cause 1: The opposite NE is not configured with any LAGs.
On the NMS, check whether the opposite NE is configured with a LAG. If the opposite NE is not configured with a LAG, configure one on the opposite NE and check whether the alarm clears.
Cause 2: All member ports in the LAG are unavailable.
*
Huawei Confidential

.
Page *
Common ETH LAG Alarms (2)
The LAG_MEMBER_DOWN is an alarm indicating that a member port of a LAG is unavailable.
Possible Causes
Cause 2: The port receives no LACP packet.
Cause 3: The port works in half-duplex mode.
Handling Procedure
Cause 1: The port link is unavailable.
On the NMS, check whether the port in the LAG is enabled. If the port is not enabled, enable the port in the LAG and check whether the alarm clears. If the alarm persists, check whether an ETH_AUTO_LINK_DOWN alarm occurs on the port that reports the LAG_MEMBER_DOWN alarm. If yes, clear the LAG_MEMBER_DOWN alarm.
Cause 2: The port receives no LACP packet.
On the NMS, check whether the opposite port is added to the LAG. If the opposite port is not added to the LAG, add the opposite port to the LAG and check whether the alarm clears. If the alarm persists, check whether an ETH_LOS or FLOW_OVER alarm occurs on the port that reports the LAG_MEMBER_DOWN alarm. If yes, clear the LAG_MEMBER_DOWN alarm.
Cause 3: The port works in half-duplex mode.
Change the working mode of the port to auto-negotiation or full-duplex.
Release the loopback on the port.
*
Huawei Confidential

.
Page *
Contents
3
1
4
5
10
Huawei Confidential

.
Page *
Fault Symptoms
The system control, cross-connect, and timing board reports an EXT_SYNC_LOS/LTI/S1_SYN_CHANGE/SYNC_C_LOS/SYNC_DISABLE alarm.
Possible Causes
Cause 1: The priority of the synchronous clock source on the service board is absent from the priority list.
Cause 2: The synchronous clock source is lost and the clock of the NE works improperly.
Cause 3: The clock source is switched in SSM mode and the clock source traced by the NE is also switched.
Cause 4: The signals of the synchronous clock source are degraded.
Cause 5: The external clock source is lost.
Cause 6: The settings of clock tracing are incorrect.
*
Huawei Confidential

.
Page *
Handling Procedure
Cause 1: The priority of the synchronous clock source on the service board is absent from the priority list.
Check for the SYNC_C_LOS alarm. If the SYNC_C_LOS alarm occurs, clear the SYNC_C_LOS alarm.
Cause 2: The synchronous clock source is lost and the clock of the NE works improperly.
Check for the LTI alarm. If the LTI alarm occurs, clear the LTI alarm.
Cause 3: The clock source is switched in SSM mode and the clock source traced by the NE is also switched.
Check for the S1_SYN_CHANGE alarm. If the S1_SYN_CHANGE alarm occurs, clear the S1_SYN_CHANGE alarm.
Cause 4: The signals of the synchronous clock source are degraded.
Select a different clock source (by performing a clock source switchover or re-configure the clock source priority list) and find out signal degrade causes along the clock tracing path.
Cause 5: The external clock source is lost.
Check for the EXT_SYNC_LOS alarm. If the EXT_SYNC_LOS alarm occurs, clear the EXT_SYNC_LOS alarm.
Cause 6: The settings of clock tracing are incorrect.
Set clock tracing again according to network planning information.
*
Huawei Confidential

.
Page *
Common Clock Alarms (1)
The EXT_SYNC_LOS is an alarm indicating the loss of the external clock source.
Possible Causes
Cause 1: The external clock source is configured in the clock source priority list, but the external clock source cannot be detected or become invalid.
Handling Procedure
Cause 1: The external clock source is configured in the clock source priority list, but the external clock source cannot be detected or become invalid.
*
Huawei Confidential

.
Page *
The LTI is an alarm indicating that the synchronous clock source is lost.
Possible Causes
Cause 1: The clock configuration is incorrect.
Cause 2: All the clock sources in the clock source priority list fail.
Handling Procedure
Cause 1: The clock configuration is incorrect.
Query the clock synchronization status and check whether the data in the clock source priority list meets the network planning requirement.
Cause 2: All the clock sources in the clock source priority list fail.
*
Huawei Confidential

.
Page *
The S1_SYN_CHANGE is an alarm indicating that the clock source is switched in SSM or extended SSM mode.
Possible Causes
Cause 1: The original clock source is lost when the SSM protocol or extended SSM protocol is enabled.
Handling Procedure
Cause 1: The original clock source is lost when the SSM protocol or extended SSM protocol is enabled.
*
Huawei Confidential

.
Page *
The SYNC_C_LOS is an alarm indicating that the synchronization source is lost.
Possible Causes
Handling Procedure
Cause 1: The clock source is lost.
*
Huawei Confidential

.
Page *
The SYNC_DISABLE is an alarm indicating that the automatic synchronization of SCC boards is disabled.
Possible Causes
Cause 1: The status of the automatic synchronization of SCC boards changes from enabled to disabled.
Handling Procedure
Cause 1: The status of the automatic synchronization of SCC boards changes from enabled to disabled.
*
Huawei Confidential

.
Page *
Contents
3
1
4
5
10
Huawei Confidential

.
Page *
*
Huawei Confidential

.
Page *
Common Causes
Cause 1: On a network, the NE IDs, NE IP addresses or subnet masks conflict.
Cause 2: The inband DCN port of the faulty NE is not enabled, or parameter settings for the interconnected ports are inconsistent.
Cause 3: The physical connection between the faulty NE and the NMS is interrupted.
Cause 4: The received signals of the faulty NE are lost, or the received optical power is excessively low, and therefore the DCN packets cannot be extracted.
Cause 6: A DCN storm or DCN interruption occurs as the third-party network that the DCN packets traverse is faulty.
Cause 7: The bandwidth configured for the inband DCN channel is excessively small.
Cause 8: The SCC board on the faulty NE is being reset or switched, and therefore the inband DCN packets cannot be responded.
Common Symptoms
The communication between the NMS and the NE is interrupted. The NE icon on the NMS is gray, and the NE is unreachable to the NMS.
The operations on the NMS are not responded. If the response interruption time lasts for more than two minutes, the communication between the NMS and the NE is interrupted.
*
Huawei Confidential

.
Page *
Locating Inband DCN Faults - Handling Method
Cause 1: On a network, the NE IDs, NE IP addresses or subnet masks conflict.
It is usually caused by the new NE on the network. According to the NE plan table, check whether the NE ID, NE IP address and subnet mask of the new NE are correctly configured. If any parameters are incorrect or conflict with the configuration of another NE, re-configure these parameters.
Cause 2: The inband DCN port of the faulty NE is not enabled, or parameter settings for the interconnected ports are inconsistent.
(1) Check whether the ports, which support the DCN function by default, are connected to fibers or cables. If the fibers or cables are not connected to the ports whose DCN function is enabled by default, change the present port to a port whose DCN function is enabled by default.
(2) Check whether the ports at the two ends of the link are enabled. If not, enable the inband DCN for the ports.
(3) Check whether the configurations of the ports at the two ends are consistent, such as the working mode of the Ethernet port. If inconsistent, modify the configurations to match each other.
Cause 3: The physical connection between the faulty NE and the NMS is interrupted.
Check whether the network cables or fibers of the faulty NE are disconnected from the ports. If the network cables or fibers are disconnected from the ports, insert the network cables or fibers again.
Cause 4: The received signals of the faulty NE are lost, or the received optical power is excessively low, and therefore the DCN packets cannot be extracted.
Check whether the R_LOS, ETH_LOS, or IN_PWR_ABN alarm exists on the board configured with the inband DCN channel. If the alarm exists, clear it.
*
Huawei Confidential

.
Page *
Locating Inband DCN Faults - Handling Method (Continued)
Cause 6: A DCN storm or DCN interruption occurs as the third-party network that the DCN packets traverse is faulty.
If the DCN packets traverse a third-party network, check whether a port loop or physical link interruption occurs in the third-party network. If yes, rectify the faults in the third-party network first.
Cause 7: The bandwidth configured for the inband DCN channel is excessively small.
(1) When the number of services configured on the port exceeds a certain number, part of the query information may be lost. In this case, you should properly increase the bandwidth configured for the inband DCN channel.
(2) If a DCN gateway manages a large number of NEs, a network congestion may occur, especially during package loading. If a network congestion occurs, change the position of the DCN gateway and the number of NEs that the DCN gateway manages. Generally, a DCN gateway manages a maximum of 64 NEs.
Cause 8: The SCC board on the faulty NE is being reset or switched, and therefore the inband DCN packets cannot be responded.
(1) Observe whether the PROG indicator on the SCC board is blinking green. If the indicator is blinking green, it indicates that the SCC board is in the reset state. After the PROG indicator is steady on (green), the reset of the SCC board is complete and the DCN connection is automatically recovered.
(2) If the DCN connection is not recovered, check whether a protection switchover occurs on a board. A protection switchover on a board will reroute DCN packets.
*
Huawei Confidential

.
Page *
Contents
3
1
4
5
10
Huawei Confidential

.
Page *
Fault Symptoms
A cold reset or warm reset occurs on an NE.
Possible Causes
Cause 2: The power supply of the NE is abnormal.
Cause 4: Certain tasks

handling common faults and alarms on the rtn network-20110711-a

Documents