UA5000 Troubleshooting(V100R019C02 01)

UA5000 Universal Access UnitV100R019C02

Troubleshooting

Issue 01

Date 2011-07-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2011-07-30) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

About This Document

Intended AudienceThis document describes how to troubleshoot common faults and deal with emergencies inservices and functions provided by the UA5000. In addition, this document provides typicalcases and common operations for troubleshooting the faults.

Reading through this document helps you learn how to troubleshoot common faults and dealwith emergencies, thus rectifying the faults and making the services return to the normal state.When a fault cannot be rectified according to the procedures described in this document, reportthe fault information to Huawei technical support engineers for further diagnosis and analysisaccording to the methods provided in this document.

The intended audience of this document is:

l System maintenance engineersl Field maintenance engineersl Network monitoring engineers

Symbol ConventionsThe following symbols may be found in this document. They are defined as follows

Symbol Description

Indicates a hazard with a high level of risk which, if notavoided, will result in death or serious injury.

Indicates a hazard with a medium or low level of risk which,if not avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation that, if notavoided, could cause equipment damage, data loss, andperformance degradation, or unexpected results.

Indicates a tip that may help you solve a problem or saveyour time.

Provides additional information to emphasize orsupplement important points of the main text.

UA5000 Universal Access UnitTroubleshooting About This Document


ii

Command ConventionsConvention Description

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[ ] Items (keywords or arguments) in square brackets [ ] areoptional.

{ x | y | ... } Alternative items are grouped in braces and separated byvertical bars. One is selected.

[ x | y | ... ] Optional alternative items are grouped in square bracketsand separated by vertical bars. One or none is selected.

{ x | y | ... } * Alternative items are grouped in braces and separated byvertical bars. A minimum of one or a maximum of all canbe selected.

GUI ConventionsConvention Description

Boldface Buttons, menus, parameters, tabs, window, and dialog titlesare in boldface. For example, click OK.

> Multi-level menus are in boldface and separated by the ">"sign. For example, choose File > Create > Folder.

Update HistoryUpdates between document issues are cumulative. Therefore, the latest document issue containsall updates made in previous issues.

Updates in Issue 01 (2011-07-30)Compared with issue 02 (2011-03-25) of V100R019C01, This issue has the following changes:

Modified:

l 15.3.6 Single Ended Loop Test

UA5000 Universal Access UnitTroubleshooting About This Document


iii

Contents

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

1 Required Reading for Maintenance Engineers.......................................................................11.1 Skill Requirements.............................................................................................................................................21.2 Troubleshooting Precautions..............................................................................................................................21.3 Troubleshooting Procedure.................................................................................................................................3

1.3.1 Determining Whether a Fault Is an Emergency........................................................................................31.3.2 Collecting and Recording the Fault Information.......................................................................................41.3.3 Locating and Rectifying the Fault.............................................................................................................41.3.4 Checking Whether the Fault Is Rectified..................................................................................................41.3.5 Contacting Huawei for Assistance............................................................................................................4

1.4 Frequently Used Methods for Troubleshooting..................................................................................................61.4.1 Configuration Data Analysis.....................................................................................................................61.4.2 Alarm Analysis..........................................................................................................................................71.4.3 Comparison Analysis.................................................................................................................................71.4.4 Substitution Analysis.................................................................................................................................71.4.5 Exclusion Method......................................................................................................................................81.4.6 Protocol Analysis.......................................................................................................................................81.4.7 Parameter Test...........................................................................................................................................91.4.8 Performance Analysis................................................................................................................................9

2 Troubleshooting Internet Access Service Faults...................................................................102.1 Failure to Access the Internet...........................................................................................................................112.2 Failure to Obtain an IP Address.......................................................................................................................16

2.2.1 Failure to Obtain an IP Address in PPPoE Dialup..................................................................................162.2.2 Failure to Obtain an IP Address in DHCP Mode....................................................................................202.2.3 Failure to Obtain an IP Address in PPPoA Dialup..................................................................................252.2.4 Failure to Obtain an IP Address in IPoA Dialup.....................................................................................28

2.3 A Low Internet Access Rate.............................................................................................................................332.4 Frequent Internet Access Interruption..............................................................................................................382.5 Failure to Make a Phone Call...........................................................................................................................44

3 Troubleshooting Video Service Faults (the MVLAN Mode)..............................................463.1 Failure to Go Online.........................................................................................................................................473.2 Failure to Watch a Program Even After Successfully Accessing the Program................................................50

UA5000 Universal Access UnitTroubleshooting Contents


iv

3.3 The Program Can Be Ordered Successfully But the Program Quality Is Poor................................................523.4 The Program Is Interrupted...............................................................................................................................533.5 Program Switching Fault..................................................................................................................................55

4 Troubleshooting Video Service Faults (the Non-MVLAN Mode)....................................584.1 Failure to Go Online.........................................................................................................................................594.2 Failure to Watch a Program Even After Successfully Accessing the Program................................................624.3 The Program Can Be Ordered Successfully But the Program Quality Is Poor................................................644.4 The Program Is Interrupted...............................................................................................................................654.5 Program Switching Fault..................................................................................................................................67

5 Troubleshooting VoIP PSTN Service Faults..........................................................................705.1 There Is No Power Feed After Offhook...........................................................................................................725.2 No Tone Is Played After Offhook....................................................................................................................735.3 Busy Tone Is Played After Offhook.................................................................................................................775.4 CLIP Is Abnormal............................................................................................................................................805.5 One-Way Audio or No Audio Occurs..............................................................................................................835.6 There Is Noise During Communication............................................................................................................845.7 Echo Exists.......................................................................................................................................................86

6 Troubleshooting VoIP ISDN BRA Service Faults................................................................896.1 Failure to Log In to a Console..........................................................................................................................906.2 Video Phone Service Is Faulty.........................................................................................................................91

7 Troubleshooting V5 PSTN Telephone Service Faults.........................................................947.1 There Is No Power Feed After Offhook...........................................................................................................967.2 No Tone Is Played After Offhook....................................................................................................................977.3 Busy Tone Is Played After Offhook...............................................................................................................1017.4 The Phone of the Called Party Does Not Ring...............................................................................................1047.5 The Ringing Does Not Meet Requirements...................................................................................................1067.6 CLIP Is Abnormal..........................................................................................................................................1097.7 There Is Noise During Communication..........................................................................................................111

8 Troubleshooting Fax and Modem Service Faults................................................................1148.1 Fax Service Is Abnormal................................................................................................................................1158.2 Modem Service Is Abnormal..........................................................................................................................117

9 Troubleshooting TDM G.SHDSL Service Faults................................................................120

10 Troubleshooting Faults on Remote Slave Subracks Cascaded in E1 Mode.................123

11 Troubleshooting Private Network and Data Service Faults...........................................12611.1 Troubleshooting Party Line Service Faults..................................................................................................12711.2 Troubleshooting SRX Service Faults...........................................................................................................12911.3 Troubleshooting DDU2 Synchronous 64 kbit/s Data Service Faults...........................................................132

12 Troubleshooting System Faults............................................................................................13612.1 NMS Fails to Manage a Device....................................................................................................................137



v

12.2 Service Board Is in the Failed State..............................................................................................................13912.3 ADSL Service Board Is Always in the config State....................................................................................14012.4 Service Board Resets Repeatedly.................................................................................................................14212.5 Control Board Resets Abnormally...............................................................................................................144

13 Troubleshooting Environment Monitoring Faults...........................................................14713.1 Fan Is in the Fault State................................................................................................................................14813.2 ESC Board Is in the Fault State...................................................................................................................14913.3 Power Monitoring Module Is in the Fault State..........................................................................................151

14 Emergency Handling..............................................................................................................15414.1 Precautions for Emergency Handling...........................................................................................................15514.2 Troubleshooting Common Emergencies......................................................................................................155

14.2.1 Service Interruptions Encountered by All the Users of a Single Device.............................................15514.2.2 Service Interruptions Encountered by All the Users of Multiple Devices Under an Upper Layer BRASor Router.........................................................................................................................................................15714.2.3 Service Interruptions Encountered by All the Users of All Devices Under an Upper Layer BRAS orRouter.............................................................................................................................................................157

15 Common Operation.................................................................................................................15915.1 Loopback......................................................................................................................................................161

15.1.1 Performing the Loopback on an ADSL2+ Port...................................................................................16115.1.2 Performing the Loopback on an SHDSL Port.....................................................................................16215.1.3 Performing the Loopback on a VDSL2 Port.......................................................................................16515.1.4 Performing the Loopback on an E1 Line.............................................................................................16615.1.5 Performing the Loopback on an E1 Port.............................................................................................168

15.2 Performing a Test on the Optical Port..........................................................................................................17115.2.1 Testing the Average Transmit Optical Power of the Single-Fiber Bi-Directional Optical Port..........17115.2.2 Testing the Average Transmit Optical Power on the Two-Fiber Bi-Directional Optical Port............17315.2.3 Testing the Receiver Sensitivity of the Single-Fiber Bi-Directional Optical Port..............................17515.2.4 Testing the Receive Sensitivity on the Two-Fiber Bi-Directional Optical Port..................................177

15.3 Line Test.......................................................................................................................................................17915.3.1 Analog Subscriber Circuit Line Test...................................................................................................17915.3.2 Analog Subscriber Line Test...............................................................................................................18015.3.3 Digital Subscriber Circuit Line Test....................................................................................................18115.3.4 Digital Subscriber Line Test................................................................................................................18315.3.5 Meter Test............................................................................................................................................18515.3.6 Single Ended Loop Test......................................................................................................................186

15.4 Configuring the File Transfer Mode.............................................................................................................18715.4.1 Configuring Xmodem File Transfer Mode..........................................................................................18715.4.2 Configuring the FTP File Transfer Mode............................................................................................18915.4.3 Configuring TFTP File Transfer Mode...............................................................................................19115.4.4 Configuring the SFTP File Transfer Mode..........................................................................................193

15.5 Backing Up the Database File......................................................................................................................19515.5.1 Backing Up the Database File Manually.............................................................................................195



vi

15.5.2 Backing Up the Database File Automatically.....................................................................................19715.6 Resetting the System....................................................................................................................................19715.7 Resetting the Control Board.........................................................................................................................19815.8 Active/Standby Switchover..........................................................................................................................19915.9 Cleaning the Connector of the Optical Fiber................................................................................................20115.10 Checking the Optical Fiber Link................................................................................................................20315.11 Mirroring Packet Capture (IPM)................................................................................................................20515.12 Mirroring Packet Capture (PVM)...............................................................................................................20515.13 Changing the Line Profile or Line Template of an xDSL Port...................................................................20615.14 Changing the Traffic Profile of an xDSL Port...........................................................................................20815.15 Troubleshooting the MG Interface Fault....................................................................................................20815.16 Troubleshooting the V5 Interface Fault......................................................................................................210

16 Troubleshooting Cases...........................................................................................................21316.1 By Fault........................................................................................................................................................214

16.1.1 Board Fault..........................................................................................................................................21416.1.2 Environment Monitoring Fault............................................................................................................24416.1.3 NMS Losing Control over the NE.......................................................................................................25316.1.4 Service Exception................................................................................................................................26416.1.5 Service Interruption.............................................................................................................................39016.1.6 Other Faults.........................................................................................................................................405

16.2 By Feature.....................................................................................................................................................42416.2.1 VoIP Service........................................................................................................................................42416.2.2 xDSL Service.......................................................................................................................................44216.2.3 Ethernet Service...................................................................................................................................44416.2.4 Narrowband Service............................................................................................................................47216.2.5 Multicast Service.................................................................................................................................56816.2.6 QoS......................................................................................................................................................57216.2.7 Other Faults.........................................................................................................................................573

16.3 By Alarm......................................................................................................................................................63516.3.1 ALM-0x02310000 Board Fault Alarm................................................................................................63516.3.2 ALM-0x0a300013 Line-caused ADSL Port Auto Deactivation.........................................................63816.3.3 ALM-0x0a300052 ADSL Port Link Loss...........................................................................................64016.3.4 ALM-0x0e210000 CPU Occupancy Exceeds the Threshold..............................................................64216.3.5 ALM-0x12100001 DSP Resources Insufficient Alarm.......................................................................64316.3.6 ALM-0x15411000 EMU Fault Alarm.................................................................................................64316.3.7 ALM-0x15411010 Battery Off Alarm................................................................................................64516.3.8 ALM-0x0230001c Failed to Resume Configuration Data of Device Alarm......................................64716.3.9 ALM-0x09200000 Different patch files in Active Board and Standby Board Alarm........................648

A Acronyms and Abbreviations................................................................................................649



vii

1 Required Reading for MaintenanceEngineers

About This Chapter

Maintenance engineers responsible for troubleshooting must have at least one year of experiencewith engineering or equipment maintenance. After familiarizing themselves with this document,these engineers will understand what skills they need to troubleshoot the UA5000, as well asunderstanding troubleshooting procedures and methods.

1.1 Skill RequirementsMaintenance engineers must master key troubleshooting skills to succeed.

1.2 Troubleshooting PrecautionsBefore locating and troubleshooting faults, pay careful attention to the following precautions.

1.3 Troubleshooting ProcedureUnderstand the carrier's troubleshooting procedure and especially the procedures for handlingemergencies. The following describes a general troubleshooting procedure, but in many casestroubleshooting procedures must be adapted to meet the requirements of a particular carrier.

1.4 Frequently Used Methods for TroubleshootingVarious methods can be used to locate faults. In practice, several methods are used together.Efficient troubleshooting depends on mastering and using these methods properly.

UA5000 Universal Access UnitTroubleshooting 1 Required Reading for Maintenance Engineers


1

1.1 Skill RequirementsMaintenance engineers must master key troubleshooting skills to succeed.

Maintenance engineers should be familiar with:

1. Basic communications technologies:l Computer network technologies, such as Ethernet and TCP/IPl X digital subscriber line (xDSL) access technologiesl Multicast service principles

2. UA5000 networking, services, and functions:l Familiarity with live network and networking conditionsl UA5000 hardware structure and performance specificationsl UA5000 board and board slot functionsl Operating principles of UA5000 services and functionsl UA5000 service configurationsl Connections between the UA5000 and other devices on the networkl Protocols used between the UA5000 and other devices on the network

3. Common measures for locating UA5000 faults and, in addition, when these procedures areused, engineers must be aware:l Which measures may completely or partially interrupt servicesl Which measures may result in customer complaintsl Which emergency or backup measures are availablel Which measures may damage equipment

4. Use of common testing tools and instruments, including:l Multimeterl Line testerl Optical power meterl Optical attenuator

5. Methods for determining and handling device emergencies (These methods can be masteredthrough practice. The methods vary according to different carriers, and thereforemaintenance engineers need to know standards and requirements of the carrier beforeperforming troubleshooting operations.)

6. How to seek additional help in the event of a fault. This includes referring to troubleshootingdocuments or contacting Huawei for technical support

1.2 Troubleshooting PrecautionsBefore locating and troubleshooting faults, pay careful attention to the following precautions.

Maintenance engineers should:

l Bear in mind precautions for handling emergencies. For details, see 14.1 Precautions forEmergency Handling.



2

l First check whether a fault is an emergency. For details, see 1.3.1 Determining Whethera Fault Is an Emergency. If the fault is an emergency, use pre-defined emergency handlingprocedures to return the faulty module to normal and restore services.

l Strictly follow operational and industrial safety regulations to prevent personal injury andequipment damage.

l When replacing or maintaining device parts, take measures to prevent static electricitydischarge (for example, wear the ESD wrist strap).

l Keep detailed records of any problems that occur during troubleshooting.l Keep records of all important operations, such as restarting a device or erasing a database).

Before qualified engineers undertake such an operation, make sure that the operation isfeasible, that all preparatory measures have been completed, and that contingency andsecurity measures are in place

l To improve troubleshooting efficiency when a fault occurs, make the following advancepreparations:– Collect information about physical connections for all on-site devices.– Prepare a table containing information (including VLAN, IP address, interconnected

port ID, firewall configurations, and user name and password) about thecommunications, interconnection, and rights for devices and components.

– Keep a record of hardware and software configurations and versions for all on-sitedevices and components, as weel as a log of configuration and version change.

– Keep backup devices in good working order. Ensure that hardware configurations,software versions, and other parameters match those of working devices on the livenetwork. If a working device fails, it can be replaced quickly with a backup device.

– Regularly check remote access devices and fault diagnosis tools (including the testingtools and the packet capture tools) to ensure that they are in good working order.

– Have up to date documentation (including the Troubleshooting, Alarm Reference, andRoutine Maintenance documents) available and easily accessible. (The latest documentscan be obtained at http://support.huawei.com.)

1.3 Troubleshooting ProcedureUnderstand the carrier's troubleshooting procedure and especially the procedures for handlingemergencies. The following describes a general troubleshooting procedure, but in many casestroubleshooting procedures must be adapted to meet the requirements of a particular carrier.

1.3.1 Determining Whether a Fault Is an EmergencyAfter learning of a fault, determine whether it constitutes an emergency based on criteriaestablished by the carrier.

Different carriers define "emergency" differently. Be familiar with the definition used by thecarrier whose network you maintain.

If the fault is an emergency, use pre-defined emergency handling procedures to restore services.For details of precautions and an operating guide, see 14 Emergency Handling.



3

1.3.2 Collecting and Recording the Fault InformationA clear description of a fault facilitates and speeds fault location. Whether the fault will bereported to the carrier or to Huawei, collect information about the fault at the earliest possiblemoment.

Collect information on the fault and complete a "Form for reporting a fault." This can be usedto output a troubleshooting report later and helps when 1.3.5 Contacting Huawei forAssistance.

1.3.3 Locating and Rectifying the FaultFind out the root cause of the fault based on the methods for locating the fault provided by thedevice and then take appropriate troubleshooting measures (for example, repairing a line,replacing faulty parts, or modifying configuration data). Such measures are the core oftroubleshooting. For specific procedures, see information in this document for troubleshootingparticular services or functions.

1.3.4 Checking Whether the Fault Is RectifiedAfter the troubleshooting measures have been taken, test whether the affected services andfunctions are working properly. If the fault has not been rectified, fill in a "Form for reportinga fault" and contact Huawei for assistance.

1.3.5 Contacting Huawei for AssistanceIf the fault persists even after the troubleshooting measures described in this document havebeen taken, contact Huawei for assistance (Huawei engineers will provide guidance remotelyor on site on troubleshooting).

Call local Huawei branches or representative offices or contact Huawei Customer ServiceCenter.

Contact Huawei Customer Service Center: [email protected].

Before contacting Huawei for technical support, fill in the form for reporting a fault shown inTable 1-1 and deliver this form to Huawei by fax or email. This can help us rectify the faultquickly for you. The more detailed and accurate the fault information you provide, the morehelpful for subsequent fault locating.

Table 1-1 Form for reporting a fault

[YYYY-MM-DD XX (carrier name) in XX (region name)] XX (brief description of afault)

Full name of the office wherethe fault occurs

Name and telephone number(mobile/fixed line telephonenumber) of the contactperson



4


Remote access parameters A remote maintenance environment needs to be set up andremote access parameters need to be provided.

Fault symptom Including but not limited to:l Detailed fault symptom: Describe the fault symptom in

detail.l Background information about the fault: Describe what

operations have been performed by users or maintenanceengineers before the fault occurs and whether datamodification or relevant operations are performed onother devices in a same networking.

l Fault time: Write down the time when the fault occurs.l Fault range: Describe whether the fault occurs on single

offices or all offices, or on a single port or all ports, or ona single board or all boards.

l Fault probability: Describe whether the fault occurs ona probability basis.

Networking information Describe all networking information (do not write down onlythe name of the access network equipment. Instead, providethe detailed description of connections between the lowerequipment and the upper equipment). The networkingdiagram can be provided.The description is specific to the minimum NE, includingrelevant equipment such as access network equipment,transmission equipment, and switches. This aims to knowabout the peripheral equipment of the access network.

Version Information Including but not limited to:l Equipment version and patch information: Run the display

language, display version, and display patch commandsrespectively.

l Board configuration, board software, bar codeinformation: Run the display board 0, and displayversion commands to query the board information. Youcan read the bar code (close to the ejector level) on thefront panel of the board.

l If terminals are involved, relevant information about theterminals (such as terminal type and terminal vendor)needs to be provided.

l If network management system (NMS) equipment or corenetwork equipment is involved, its version informationneeds to be provided.

l In the case of faults in the VoIP service, the DSP versionID needs to be provided. (The DSP version ID can bequeried by running the display version command.)



5


(Optional) Fault causeanalysis

Based on the obtained fault information, analyze possiblecauses. This item is optional.

Operations that have alreadybeen performed and relevantresults

CAUTIONWhen finding a fault (except an emergency that needs to be handledaccording to the pre-defined contingency method), follow theguidance described in this document for troubleshooting in the firstplace.

l If before fault reporting, certain troubleshootingoperations have already been performed for the faultunder the other guidance than that described in thisdocument, record all operations (including datamodification and maintenance operations) and provideoperation steps, time, and result.

Operation 1: xxx Result 1: xxx

Operation 2: xxx Result 2: xxx

l If a fault is troubleshot under the guidance described in

this document, attach the specified information here.

Database file andconfiguration file

Run the save command to save the database file andconfiguration file. Then, output these two files and attach themhere.

1.4 Frequently Used Methods for TroubleshootingVarious methods can be used to locate faults. In practice, several methods are used together.Efficient troubleshooting depends on mastering and using these methods properly.

1.4.1 Configuration Data AnalysisFaults can be caused by errors that occur when configurations are modified or expanded, orerrors that exist in current configurations. Therefore, analyzing configuration data is an importantpart of locating and troubleshooting faults.

Consider, for example, a situation in which UA5000 users are unable to watch multicastprograms. A check of the configuration data reveals that the time to live (TTL) value preset inthe multicast source is very small. Because TTL is 0, multicast streams are discarded when theyare forwarded on the UA5000 and this results in a fault.

There is a great deal of configuration data. You must determine from fault symptoms which ofthis data to check. To do this effectively, you must master implementation principles andconfiguration procedures for different services and functions, as described in 1.1 SkillRequirements. This helps you avoid attempting to locate faults blindly and improvestroubleshooting efficiency. This document provides different methods for checkingconfiguration data in order to locate common faults. For details, see the following topics.



6

1.4.2 Alarm AnalysisAnalyzing alarms allows you to determine the cause of certain faults. Alarm analysis combinedwith other troubleshooting methods can help locate faults.

An alarm is an important prompt when a fault or an event occurs. When a fault occurs on theUA5000, an alarm may be generated. You can use an alarm management system, such as anetwork management system (NMS) or a command line interface (CLI) terminal to query alarms.

Alarm information includes a detailed description, a possible cause for the fault or abnormality,and troubleshooting advice. An alarm provides information about various factors, includinghardware, links, services, and CPU usage. The extensive, full information provided by alarmsserves as a basis for locating and analyzing faults.

When a fault occurs, check whether the system has generated an alarm. If an alarm has beengenerated, analyze alarms associated with the fault. Then, refer to IPM Alarms Reference orPVM Alarms Reference to clear the alarm and rectify the fault.

For example, after maintenance engineers run the display alarm history command to querycritical alarms, they found that a "system resource is exhausted" alarm is generated, as well asa suggestion to decrease system load.

huawei(config)#display alarm history alarmlevel { level<E><critical,major,minor,warning> }:critical { <cr>|detail<K>|list<K>|start-number<1,1900>||<K> }: Command: display alarm history alarmlevel critical ALARM 11951 EVENT CRITICAL 0x36400001 ----- 2007-05-11 20:12:09 ALARM NAME : System resource exhausted PARAMETERS : Resource type 1 (1-memory,2-message) DESCRIPTION : System resource is exhausted CAUSE : System resource is exhausted ADVICE : Decrease system load, for example, restrict the number of online users --- END

1.4.3 Comparison AnalysisComparison analysis compares faulty components or abnormal conditions with properlyworking components or normal conditions. Differences are identified and these are used to locatefaults. This could, for example, involve comparing line parameters of faulty and normal servicesor comparing devices at the same layer.

Comparison analysis is used to identify faults that have a single cause.

For example, if an ADSL user frequently loses an online connection, locate the fault by replacingthe user's modem or determining whether other ADSL users are losing their connections.

1.4.4 Substitution AnalysisIf a fault cannot be located after parts have been replaced, use substitution analysis to locate andtroubleshoot the fault.

substitution analysis refers to substituting a part (such as a board or cable) that may be faultywith a part working properly, and then comparing before and after running conditions to locatea fault. This method is useful in the following scenarios:

l After parts are replaced, the scope or location of a fault can still not be determines.



7

l The fault has multiple causes.

CAUTIONSubstitution operation can be risky. If, for example, a short-circuited board is installed in anormal running shelf, a shelf fault may occur. To prevent another fault from occurring, exercisecaution when using substitution analysis.

1.4.5 Exclusion MethodWhen a fault is complicated and impacts multiple segments, use the exclusion method to analyzenetwork devices, components, links, and configurations, eliminating segments which are normaland arriving eventually at the segment where the fault is located.

Use of the exclusion method requires that you first determine on which segments a fault mayoccur. You must use appropriate methods (such as various loopback operations or configurationdata analysis) to locate the fault. To accomplish this, you must be familiar with:

l System architecture and working principles for the UA5000l Segments where the fault may occurl Fault diagnosis procedures such as loopback and configuration data analysisl Use of testing equipment

Consider, for example, a multicast program ordered by a user is repeatedly interrupted. After aninterruption, the user orders the program again, and the program runs properly for a time. Ananalysis of the principles for implementing multicast services suggest several possible causesfor this fault:

l The multicast server is faulty.l The multicast router is configured incorrectly.l The set top box (STB) is faulty.

Finally, check the STB, upper-layer multicast server, and multicast router to locate the fault.This illustrates the exclusion method.

NOTE

Implementation of the exclusion method includes all segments on the network. Organize the process toreduce troubleshooting costs and improve efficiency. Begin at the remote end and work towards the localend. Examine most likely causes first and then less likely possibilities. Work from simple to complexprocesses.

1.4.6 Protocol AnalysisProtocol analysis is used to locate and troubleshoot faults that occur when the UA5000 is norproperly interconnected to upper layer devices. This method is used mainly to troubleshootPoint-to-Point Protocol over Ethernet (PPPoE) dialup, multicast service, and voice service faults.

Protocol analysis traces the signaling and uses packet capture to analyzes faults.

Use of protocol analysis requires you to have a thorough understanding of protocols and thepacket exchange process used by each protocol. Fault causes can be determined by examiningcaptured packets.



8

For example, a user fails to order multicast programs. An analysis of captured packets revealsthat the broadband remote access server (BRAS) discards the Internet Group ManagementProtocol (IGMP) packets sent from the user.

1.4.7 Parameter TestMeasurement and testing devices are used to record actual performance parameter values. Theseare then compared with normal values for the purpose of locating and troubleshooting faults.

These devices provide both visual and quantitative data indicating device running status andplay an important role in troubleshooting

The following testing devices are commonly used for troubleshooting:

l Multimeterl Line testerl Optical power meterl Optical attenuator

An optical power meter, for example, is used to measure the average transmit power of an opticalport. By measuring the average transmit power, you can check whether an optical module fortransmitting signals is working properly. You can also use a multimeter to test voltage, resistance,and current during power commissioning.

1.4.8 Performance AnalysisPerformance analysis uses performance statistics provided by the UA5000 to analyzeperformance indexes of a faulty service in order to locate a fault.

The type of fault being targeted determines which performance statistics need to be queried.You must be familiar with:

l System architecture and operating mechanismsl Types of statistics provided by the systeml Method for querying and analyzing the statistics

For example, run the display port statistics command in Ethernet port mode to query statisticson Ethernet ports. Checking these statistics will tell you whether the system is running properly.

l If the number of CRC error frames is increasing rapidly, links between devices may beabnormal, the port negotiation mode may be incorrect, or a physical fault may have occurredon the port.

l If a large number of frames are discarded, the traffic transmitted from an interconnecteddevice exceeds the receiving capability of the local port.



9

2 Troubleshooting Internet Access ServiceFaults

About This Chapter

This topic describes how to troubleshoot common faults in the Internet access service, includingthe following faults: Internet access failure, low Internet access rate, frequent interruption inaccessing the Internet, and failure to make a phone call in the xDSL mode.

2.1 Failure to Access the InternetThis topic describes how to troubleshoot a fault when a user fails to access the Internet.

2.2 Failure to Obtain an IP AddressThis topic describes how to troubleshoot the fault through the CLI when a user fails to accessthe Internet because no IP address can be obtained.

2.3 A Low Internet Access RateThis topic describes how to troubleshoot a fault when the Internet access rate is low.

2.4 Frequent Internet Access InterruptionThis topic describes how to troubleshoot a fault when a user connected to the UA5000 accessesthe Internet but the connection is frequently interrupted.

2.5 Failure to Make a Phone CallThis topic describes how to troubleshoot a fault when a user connected to the UA5000 cannotmake a phone call.

UA5000 Universal Access UnitTroubleshooting 2 Troubleshooting Internet Access Service Faults


10

2.1 Failure to Access the InternetThis topic describes how to troubleshoot a fault when a user fails to access the Internet.

Fault Location ProcedureUse the following guidelines to locate the fault:

1. Check whether the user PC is faulty (for example, the Internet Explorer on the PC is faulty).2. Check whether the user PC obtains an IP address successfully.3. Check whether unknown traffic occupies user bandwidth.4. Check whether the bandwidth of the uplink port is insufficient.5. Check whether packets are lost on the xDSL line.6. Check whether packets are lost on the uplink port.7. Check whether MAC address flapping occurs.8. Check whether the maximum transmission unit (MTU) and maximum segment size (MSS)

settings of the BRAS are incorrect.

CAUTIONTo facilitate reporting faults, save the results for each of the following steps.

Procedure

Step 1 Check whether the user PC is faulty (mainly check whether the Internet Explorer is faulty). Ifsuch problems are occurring, rectify the fault. Then, check whether the service is restored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 2.

Step 2 Check the dialup mode of the user.l In the case of the IPoE (DHCP) or PPPoE user, go to Step 3.l In the case of the PPPoA user, go to Step 4.l In the case of the IPoA user, go to Step 5.l In the case of the user with a static IP address, go to Step 7.

Step 3 On the Disk Operating System (DOS) of the PC, enter ipconfig and press Enter. In theinformation that is displayed, check whether the PC obtains an IP address.l If the PC obtains an IP address, go to Step 7.l If the PC does not obtain an IP address, do as follows:

– For PPPoE users, refer to 2.2.1 Failure to Obtain an IP Address in PPPoE Dialup torectify the fault. Then, go to Step 6.

– For IPoE (DHCP) users, refer to 2.2.2 Failure to Obtain an IP Address in DHCPMode to rectify the fault. Then, go to Step 6.



11

Step 4 Run the display pppoa user port frameid/slotid/portid command to check whether sessionidof the user is 0.

sessionid indicates a session ID and identifies a PPPoA connection. If sessionid is not 0, thePPPoA user obtains an IP address successfully.

l If sessionid is 0, refer to 2.2.3 Failure to Obtain an IP Address in PPPoA Dialup torectify the fault. Then, go to Step 6.

l If sessionid is not 0, go to Step 7.

Step 5 Run the display ipoa user port frameid/slotid/portid command to check whether DSTMAC isobtained successfully.

DSTMAC indicates the destination MAC address of a permanent virtual channel (PVC).Generally, this MAC address is the MAC address of an upper layer broadband remote accessserver (BRAS). If the destination MAC address is obtained, the IPoA user obtains an IP address.

l If DSTMAC is obtained, go to Step 7.

l If DSTMAC is not obtained, refer to 2.2.4 Failure to Obtain an IP Address in IPoADialup to rectify the fault. Then, go to Step 6.

Step 6 Check whether Internet access is successful.

l If Internet access is successful, go to Step 28.

l If Internet access fails, go to Step 7.

Step 7 Stop sending Internet access requests from the PC and run the display traffic command on theUA5000 to query the real-time traffic on the affected port.

Rx Traffic (Kbps) indicates the current upstream traffic and Tx Traffic(Kbps) indicates thecurrent downstream traffic. Normally, when the user stops Internet access, the upstream anddownstream traffic is very light (far lower than the user bandwidth) and is close to 0.

l If the upstream or downstream traffic is very heavy, unknown traffic occupies the userbandwidth. In this case, go to Step 8.

l If the upstream or downstream traffic is very light (far lower than the user bandwidth) andis close to 0, go to Step 9.

Step 8 Use a packet capture tool, such as Ethereal, to capture packets on the PC. Check the source ofthe unknown traffic and clear the unknown traffic. (For example, check whether the systemsending the unknown traffic is infected with viruses.) Then, check whether the service is restored.

l If the service is restored, go to Step 28.

l If the service is not restored, go to Step 9.

Step 9 Check whether the bandwidth of the uplink port is insufficient.

1. In IPM mode, run the display port state portid command to query the maximum permittedbandwidth of the uplink port (the value of Ethernet port rate in the query result, in unitof Mbit/s).

2. Have the user attempt to access the Internet, and run the display port traffic commandmultiple times (10 times are recommended) to query the real-time traffic of the uplink port.The interval between two queries is 20s. Then, check whether the current occupiedbandwidth of the uplink port is close to the maximum permitted bandwidth.



12

NOTE

The traffic may be burst traffic. Therefore, you are advised to query the traffic multiple times.The queried real-time traffic is in the unit of octets/s, and the conversion relationship between octets/s and Mbit/s is 1 Mbit/s = 131072 octets/s.

l After you calculate the real-time traffic of the uplink port in Mbits/s, if the current occupiedbandwidth of the uplink port is close to the maximum permitted bandwidth, the bandwidthof the uplink port of the site is insufficient. In this case, go to Step 10.

l If the current occupied bandwidth of the uplink port is far lower than the maximumpermitted bandwidth, go to Step 11.

Step 10 Increase the maximum permitted bandwidth of the uplink port (for example, replace the 100Mbit/s daughter board with the 1000 Mbit/s daughter board, or run the speed command toconfigure a higher bandwidth of the uplink port), or use multiple uplink ports (uplink portaggregation) to provide the user bandwidths, or decrease the number of users configured on thedevice (migrate certain users to other devices). Then, check whether the service is restored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 11.

NOTE

The maximum permitted bandwidth of the uplink port is associated with the hardware capability and theconfigurations. You can run the display board 0 command to query the type of the current daughter board(a 100 Mbit/s or 1000 Mbit/s daughter board) used by the control board.l If the negotiation function of the uplink port is enabled (run the auto-neg command to configure the

negotiation function), the maximum permitted bandwidth of the uplink port is determined by thenegotiation between the uplink port and the port on the interconnected device.

l If the negotiation function of the uplink port is disabled, the maximum permitted bandwidth of theuplink port is the value configured by running the speed command.

Step 11 In ADSL mode, run the display statistics performance portid current-15minutes commandmultiple times (10 times are recommended) to query the performance statistics of the faulty port.(In SHDSL mode, the corresponding command is display statistics performance portidcurrent. In VDSL mode, the corresponding command is display statistics performance portidchannel co current-15minutes.) The interval between two queries is 20s. Then, check whetherthe number of CRC packet loss on the line of the user port increases.l If Count of all blocks received with uncorrectable errors of the ADSL port, CRC

anomaly count in 15 minutes of the SHDSL port, or Count of coding violations of theVDSL port increases, CRC packets are lost on the line. In this case, go to Step 12.

l If neither of the preceding values increases, go to Step 14.

Step 12 Replace the modem and check whether the service is restored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 13.

Step 13 Check the line conditions. That is, check whether the cables are old or damaged, and whetheran interference source exists. If the cables are aged or damaged, and an interference source exists,replace the cables and remove the interference source. Then, check whether the service isrestored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 14.

Step 14 In IPM mode, run the display port statistics command multiple times (10 times arerecommended) to query the performance statistics of the uplink port. The interval between twoqueries is 20s. Then, check whether the number of CRC packets lost on the uplink port increases.



13

l If Number of CRC error frames increases, it indicates that CRC packets are lost on theuplink port. The packet loss may occur because the upstream link is abnormal, portnegotiation is incorrect, or the port is faulty. In this case, go to Step 15.

l If Number of CRC error frames does not increase, go to Step 16.

Step 15 Troubleshoot the uplink port fault and then check whether the service is restored.1. Troubleshoot the uplink port fault.

l If the optical port is used for upstream transmission, check whether the negotiation modeof the local port is the same as the negotiation mode of the port on the interconnecteddevice. Run the display port state portid command to check the negotiation mode ofthe local uplink port.At the same time, check whether optical fibers are loose and whether the opticaltransceiver is matched. Run the display port opticstate portid command to query theinformation about the optical transceiver, and mainly check whether the type,wavelength, and transmission distance of the local and interconnected opticaltransceivers are consistent respectively. Make sure that the negotiation modes of portsare the same, and optical fibers are firmly inserted. If necessary, see Replacing theOptical Transceiver to replace an optical transceiver.

l If the electrical port is used for upstream transmission, check whether the negotiationmode of the local port is the same as the negotiation mode of the port on theinterconnected device. Run the display port state portid command to check thenegotiation mode of the local uplink port. At the same time, check whether networkcables are normal. Make sure that the negotiation modes of ports are the same. Ifnecessary, see Replacing the Network Cable to replace a network cable.

2. Check whether the service is restored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 16.

Step 16 In global config mode, run the display location mac-address command multiple times (overthree times are recommended) to query the ports that learn the user MAC address. Then, checkwhether user MAC address flapping occurs.

In the query, the input mac-addr is the user MAC address. If a modem is used for dialup, theuser MAC address is the MAC address of the modem. If a PC is used for dialup, the user MACaddress is the MAC address of the PC.

In results, F/S/P is the user port that learns the user MAC address. Normally, the queried portis the port connected to the user. Otherwise, user MAC address flapping occurs.

l If user MAC address flapping occurs, check whether a ring network or user attack exists.If any, troubleshoot the fault (for example, run the security anti-macspoofing enablecommand to enable the anti-MAC address spoofing function, disconnect the ring network,and deactivate the port where the attack is from). Then, go to Step 17.

l If user MAC address flapping does not occur, go to Step 18.

Step 17 Check whether the service is restored.l If the service is restored, go to Step 28.l If the service is not restored, go to Step 18.

Step 18 Run the display location command multiple times (over three times are recommended) to querythe ports that learn the BRAS MAC address. Then, check whether BRAS MAC address flappingoccurs.



14

In the query, the input mac-addr is the BRAS MAC address.

In results, F/S/P is the uplink port that learns the BRAS MAC address. Normally, the queriedport is the uplink port connected to the BRAS. Otherwise, BRAS MAC address flapping occurs.

l If BRAS MAC address flapping occurs, check whether a ring network or user attack exists.If any, troubleshoot the fault (for example, run the security mac-filter command toconfigure the MAC address filtering function, disconnect the ring network, and deactivatethe port where the attack is from). Then, go to Step 19.

l If BRAS MAC address flapping does not occur, go to Step 20.


Step 20 On the DOS of the PC, type Ping -n 100 x.x.x.x. x.x.x.x indicates the IP address of the domainname server (DNS), and 100 indicates that 100 packets are sent to the DNS for the ping test.

NOTE

Do as follows to obtain the IP address of the DNS:

1. In the Windows operating system of the PC, click Start, and then click Run. In the Run dialog boxthat is displayed, enter cmd.

2. Type ipconfig/all in the command prompt. Then, the IP addresses of DNS Servers are displayed inthe command output.

l If you can ping the IP address of the DNS, go to Step 22.l If you cannot ping the IP address of the DNS, it indicates that the DNSis incorrectly

configured or the DNS is faulty. In this case, check the configuration of the DNS and therunning status of the DNS to rectify the fault. Then, go to Step 21.


Step 22 Try to access multiple websites to check whether only certain websites cannot be opened.l If only certain websites cannot be opened, go to Step 23.l If all the websites cannot be opened, go to Step 25.

Step 23 On the DOS of the PC, type Ping -n 100 x.x.x.x -l y. x.x.x.x indicates the IP address of thewebsite (it can be the IP address or domain name of the access-failed website), and 100 indicatesthat 100 packets with the length of y are sent to the website for the ping test.

Increase y gradually (100 octets, 500 octets, 1000 octets, and 1500 octets are recommended).Normally, the ping test is successful by using the packets with any different length. If the pingtest is successful by using the short packets but fails by using the long packets, it indicates thatthe MTU of the BRAS is very small but the MSS of the BRAS is very large.

l If the MTU of the BRAS is very small but the MSS of the BRAS is very large, increase theMTU of the BRAS and decrease the MSS of the BRAS. Then, go to Step 24.

l If the MTU and MSS of the BRAS are correct, go to Step 27.




15

Step 25 On the DOS of the PC, type Ping -n 100 x.x.x.x -l y. x.x.x.x indicates the IP address of theBRAS, and 100 indicates that 100 packets with the length of y are sent to the BRAS for the pingtest.

Increase y gradually (100 octets, 500 octets, 1000 octets, and 1500 octets are recommended).Normally, the ping test is successful by using the packets with any different length. If the pingtest is successful by using the short packets but fails by using the long packets, it indicates thatthe MTU of the BRAS is very small but the MSS of the BRAS is very large.

l If the MTU of the BRAS is very small but the MSS of the BRAS is very large, increase theMTU of the BRAS and decrease the MSS of the BRAS. Then, go to Step 26.

l If the MTU and MSS of the BRAS are correct, go to Step 27.

Step 26 Check whether the service is restored.



Step 27 Record the results of the preceding steps in a fault report (see Form for Reporting a Fault), fillout the entire form, and then submit the form to Huawei for technical support (see ContactingHuawei for Assistance).

Step 28 End.

----End

2.2 Failure to Obtain an IP AddressThis topic describes how to troubleshoot the fault through the CLI when a user fails to accessthe Internet because no IP address can be obtained.

2.2.1 Failure to Obtain an IP Address in PPPoE DialupThis topic describes how to troubleshoot a fault when a user fails to access the Internet becauseno IP address can be obtained in PPPoE dialup.

Fault Location Procedure

Use the following guidelines to locate the fault:

1. Check whether the connectivity between the device and the modem is normal.

2. Check whether the uplink port is added to the upstream VLAN and whether the upstreamlink is in the online state.

3. Check whether the PITP configuration is correct.

4. Check whether the PPPoE MAC address configuration is correct.

5. Check whether the MAC address flapping occurs.

6. Check whether security feature configuration is correct.

7. Check whether the ACL rule that limits PPPoE packets is configured.

8. Check whether user data of the upper-layer BRAS is correct and whether the user accountis limited.



16

CAUTIONTo facilitate reporting faults, save the results for each of the following steps.The UA5000 supports the PPPoE emulation test function. You can run the pppoe simulatecommand to enable the PPPoE emulation test function. After the test is complete, run the displaypppoe simulate info command to query the test result. If the test result (displayed in Result) isSuccess, the network from the user port to the BRAS is normal. Then, check whether the faultoccurs on the user side by referring to the following steps.The following section uses commonly used methods to describe how to troubleshoot the faultand does not use the PPPoE emulation test function.

Procedure

Step 1 In xDSL mode, run the atm-ping portid vpi vci command to check whether the device can pingthe modem of the user.l If the device can ping the modem, go to Step 6.l If the device fails to ping the modem, go to Step 2.

CAUTIONl The xDSL mode includes the ADSL mode, SHDSL mode, and VDSL mode.l In SHDSL or VDSL mode, this step is not required when the working mode is PTM. In this

case, directly perform Step 2.

Step 2 Run the display port state portid command to check whether the port to which the user connectsis activated. (In other words, check whether Status is Activated.)l If the port is activated, go to Step 4.l If the port is not activated, run the activate portid command to activate the user port. Then,

go to Step 3.


Step 4 In global config mode, run the display service-port port frameid/slotid/portid command tocheck whether the VPI and VCI of the service stream are the same as those configured on themodem.l If the VPI and VCI of the service stream are the same as those configured on the modem,

go to Step 6.l If the VPI and VCI of the service stream are different from those configured on the modem,

modify the VPI and VCI of the UA5000 to be the same as those configured on the modem,or modify the VPI and VCI of the modem to be the same as those configured on theUA5000. If the VPI and VCI of the UA5000 are to be modified, run the undo service-port command to delete the original service port, and then run the service-port commandto configure the new VPI and VCI. Then, go to Step 5.



17




Step 6 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN. In other words, check whether the query result contains theupstream VLAN ID.

l If the uplink port is added to the upstream VLAN, go to Step 8.

l If the uplink port is not added to the upstream VLAN, run the port vlan command to addthe uplink port to the upstream VLAN. This VLAN must be the same as the VLANconfigured for the upper-layer device. Then, go to Step 7.




Step 8 Run the display board frameid/slotid command to check whether the link to the uplink port isin the online state.

l If the link to the uplink port is in the online state, go to Step 10.

l If the link to the uplink port is not in the online state, connect the upstream physical linkto ensure that the upstream link is normal. Then, go to Step 9.




Step 10 Run the display pitp config command to query the PITP configuration, and then run the displayraio-mode command to check whether the RAIO working mode is the same as that configuredon the BRAS.

l If the RAIO mode is the same as that configured on the BRAS, go to Step 12.

l If the RAIO mode is different from that configured on the BRAS, modify the RAIO modeto be the same as that configured on the BRAS. Run the pitp and raio-mode commandsto modify the configuration on the UA5000, or modify the configuration on the BRAS.Then, go to Step 11.




Step 12 Run the display mac-address command to query the number of the MAC addresses learned bythe user port, run the display mac-address max-mac-count command to query the permittedmaximum number of MAC addresses dynamically learned by the user port, and then checkwhether the number of the MAC addresses learned by the user port currently is the same as thepermitted maximum number of MAC addresses dynamically learned by the user port.

l If the number of the MAC addresses learned by the user port currently is the same as thepermitted maximum number of MAC addresses dynamically learned by the user port, runthe mac-address max-mac-count command to increase the permitted maximum numberof MAC addresses dynamically learned by the user port. Then, go to Step 13.



18

l If the number of the MAC addresses learned by the user port currently is different from thepermitted maximum number of MAC addresses dynamically learned by the user port, goto Step 18.


Step 14 In global config mode, run the display location command multiple times (over three times arerecommended) to query the ports that learn the user MAC address. Then, check whether userMAC address flapping occurs.



l If user MAC address flapping occurs, check whether a ring network or user attack exists.If a ring network or user attack exists, troubleshoot the fault (for example, run the securityanti-macspoofing enable command to enable the anti-MAC address spoofing function,disconnect the ring network, and deactivate the port where the attack is from). Then, go toStep 15.






l If BRAS MAC address flapping occurs, check whether a ring network or user attack exists,if any, troubleshoot the fault (for example, run the security mac-filter command toconfigure the MAC address filtering function, disconnect the ring network, and deactivatethe port where the attack is from). Then, go to Step 17.



Step 18 Run the display security config command to check whether the anti-MAC address spoofingfunction is enabled.l If the anti-MAC address spoofing function is enabled, go to Step 19.l If the anti-MAC address spoofing function is disabled, go to Step 21.



19

Step 19 Run the display mac-address static command to check whether the user service stream isconfigured with a static MAC address.

If the static MAC address is configured and the anti-MAC address spoofing function is enabledas well, the user fails to go online.

l If the user service stream is configured with a static MAC address, according to the serviceplanning, run the security anti-macspoofing disable command to disable the anti MACspoofing function or run the undo mac-address static command to delete the static MACaddress configured for the user service stream. Then, go to Step 20.

l If the user service stream is not configured with a static MAC address, go to Step 21.


Step 21 Run the display packet-filter port frameid/slotid/portid command to check whether the userport is configured with an ACL rule.l If the user port is configured with an ACL rule, go to Step 22.l If the user port is not configured with any ACL rule, go to Step 24.

Step 22 Run the display acl command to check whether the ACL rule limits the PPPoE packets.l If the ACL rule limits the PPPoE packets, modify the limitation or cancel the ACL

configuration of the port. Then, go to Step 23.l If the ACL rule does not limit the PPPoE packets, go to Step 24.

Step 23 Check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not covered to normal, go to Step 24.

Step 24 Check whether user data of the upper-layer BRAS is correct and whether the user account islimited.l If user data of the upper-layer BRAS is not correct or the account of the user is limited,

modify the BRAS configuration, and then go to Step 25.l If user data of the upper-layer BRAS is correct and the account of the user is not limited,

go to Step 26.



Step 27 End.

----End

2.2.2 Failure to Obtain an IP Address in DHCP ModeThis topic describes how to troubleshoot a fault when a user fails to access the Internet becauseno IP address can be obtained in DHCP mode.



20


1. Check the connectivity between the device and the modem.2. Check whether the uplink port is added to the upstream VLAN and whether the upstream

link is in the online state.3. Check the security feature configuration.4. Check whether the UA5000 can communicate with the DHCP server.5. Check whether the MAC address flapping occurs.


Procedure

Step 1 In xDSL mode, run the atm-ping portid vpi vci command to check whether the device can pingthe modem.l If the device can ping the modem, go to Step 6.l If the device cannot ping the modem, go to Step 2.

CAUTIONl The xDSL mode includes the ADSL mode, SHDSL mode, and VDSL mode.l In SHDSL or VDSL mode, this step is not required when the working mode is PTM. In this

case, directly perform Step 2.

Step 2 Run the display port state portid command to check whether the port to which the user belongsis activated (Status is Activated).l If the port is activated, go to Step 4.l If the port is not activated, run the activate portid command to activate the user port. Then,

go to Step 3.




modify the VPI and VCI of the UA5000 to be the same as those configured on the modem,



21

or modify the VPI and VCI of the modem to be the same as those configured on theUA5000. If the VPI and VCI of the UA5000 are to be modified, run the undo service-port command to delete the original service port, and then run the service-port commandto configure the new VPI and VCI. Then, go to Step 5.


Step 6 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN. In other words, check whether the query result contains theupstream VLAN ID.l If the service is restored, go to Step 8.l If the uplink port is not added to the upstream VLAN, run the port vlan command to add

the uplink port to the upstream VLAN. This VLAN must be the same as the VLANconfigured for the upper-layer device. Then, go to Step 7.


Step 8 Run the display board frameid/slotid command to check whether the state of the linkcorresponding to the uplink port is online.l If the state of the link corresponding to the uplink port is online, go to Step 10.l If the link corresponding to the uplink port is not online, connect the upstream physical link

to ensure that the upstream channel is normal. Then, go to Step 9.


Step 10 Run the display dhcp option82 config and display dhcp option82 service-port frameid/slotid/portid commands to check whether the configuration of the DHCP option82 function on theservice port of the user who is affected by the fault is the same as the configuration of the DHCPoption82 function on the DHCP server.l If the configuration of the DHCP option82 function is the same as the configuration of the

DHCP option82 function on the DHCP server, go to Step 12.l If the configuration of the DHCP option82 function is different from the configuration of

the DHCP option82 function on the DHCP server, modify them to be the same, and thengo to Step 11.

NOTE

The configuration of the DHCP option82 function on the service port takes effect only when the globalDHCP option82 function and the DHCP option82 function on the service port are both enabled. You canconfigure the global DHCP option82 function by running the dhcp option82 command and configure theDHCP option82 function on the service port by running the dhcp option82 service-port command.


Step 12 Run the display bind xdsl frameid/slotid/portid vpi vpi vci vci command to check whether theservice channel is bound with the static IP address.



22

l If the service channel is bound with the static IP address, run the undo bind command tocancel the binding. Then, go to Step 13.

l If the service channel is not bound with the static IP address, go to Step 14.


Step 14 Run the display security mac-filter command to check whether the user MAC address isincorrectly configured in the filter list.l If the user MAC address is incorrectly configured in the filter list, run the undo security

mac-filter command to delete the user MAC address from the filter list. Then, go to Step15.

l If the user MAC address is not configured in the filter list, go to Step 16.


Step 16 Run the display mac-address static command to check whether the static MAC address of othertraffic streams is the same as the MAC address of the traffic stream of the user who is affectedby the fault.l If the static MAC address of other traffic streams is the same as the MAC address of the

traffic stream of the user who is affected by the fault, run the undo mac-address staticcommand to delete the static MAC address of other traffic streams. Then, go to Step 17.

l If the static MAC address of other traffic streams is different from the MAC address of thetraffic stream of the user who is affected by the fault, go to Step 18.


Step 18 Run the display security bind mac command (do not type any parameter) to query informationabout all the dynamically bound MAC addresses. Then, check whether the user MAC addressis bound to other traffic streams.l If the user MAC address is bound to other traffic streams, MAC spoofing exists. In this

case, check the fault and then troubleshoot it. Then, go to Step 19.l If the user MAC address is not bound to other traffic streams, go to Step 20.


Step 20 Run the display dhcp config command to query the forwarding mode of DHCP relay.l If DHCP relay mode is layer-2, go to Step 29.l If DHCP relay mode is layer-3, go to Step 21.

Step 21 Run the display interface vlanif command to check whether the upstream VLAN L3 interfaceis in the UP state.l If the upstream VLAN L3 interface is in the UP state, go to Step 23.



23

l If the upstream VLAN L3 interface is not in the UP state, check configurations of the uplinkport connection and the upstream VLAN, and make sure that the L3 interface is in theUP state. Then, go to Step 22.


Step 23 Run the Ping command to ping the IP address of the DHCP server.l If you can ping the IP address of the DHCP server, go to Step 29.l If you cannot ping the IP address of the DHCP server, check the configuration of the router

connecting the UA5000 to the DHCP server and make sure that the UA5000 cancommunicate with the DHCP server. Then, go to Step 24.















24



Step 30 End.

----End

2.2.3 Failure to Obtain an IP Address in PPPoA DialupThis topic describes how to troubleshoot a fault when a user fails to access the Internet becauseno IP address can be obtained in PPPoA dialup.


1. Check whether the PPPoA to PPPoE conversion function is enabled.2. Check whether the MAC address pool is correct and whether MAC addresses in the MAC

address pool are exhausted.3. Check the attribute of the upstream VLAN and the VLAN cannot be a QinQ VLAN.4. Check whether the uplink port is added to the upstream VLAN and whether the upstream

link is in the online state.5. Check whether the user port is activated.6. Check whether the VPI and the VCI are the same as those configured on the modem.7. Check whether the PVC is encapsulated in PPPoA mode and whether the encapsulation

mode is the same as that configured on the modem.8. Check whether MAC address flapping occurs.


Procedure

Step 1 Run the display pppoa config command to check whether the PPPoA to PPPoE conversionfunction is enabled.l If the PPPoA to PPPoE conversion function is enabled, go to Step 3.l If the PPPoA to PPPoE conversion function is disabled, run the pppoa enable command

to enable the PPPoA to PPPoE conversion function. Then, go to Step 2.




25

Step 3 Run the display mac-pool all command to check whether the MAC address is configured andwhether MAC addresses in the MAC address pool are exhausted.

If MAC addresses is the same as Addresses in use, it indicates that MAC addresses areexhausted.

The system supports a maximum of 20 MAC address pools, and a maximum of 1024 MACaddresses can be configured.

l If the MAC address is not configured or MAC addresses in the MAC address pool areexhausted, run the mac-pool command to configure the MAC address pool. Then, go toStep 4.

l If the MAC address is configured and MAC addresses in the MAC address pool are notexhausted, go to Step 5.


Step 5 Run the display vlan vlanid command to query the attribute of the upstream VLAN.l If the upstream VLAN is a QinQ VLAN, configure the VLAN again and use a non-QinQ

VLAN as the upstream VLAN. Then, go to Step 6.l If the upstream VLAN is not a QinQ VLAN, go to Step 7.


Step 7 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN. In other words, check whether the query result contains theupstream VLAN ID.l If the uplink port is added to the upstream VLAN, go to Step 9.l If the uplink port is not added to the upstream VLAN, run the port vlan command to add



Step 9 Run the display board frameid/slotid command to check whether the state of the linkcorresponding to the uplink port is online.l If the link corresponding to the uplink port is online, go to Step 11.l If the link corresponding to the uplink port is not online, connect the upstream physical link



Step 11 In xDSL mode, run the display port state portid command to check whether the port to whichthe user belongs is activated (Status is Activated).



26

The xDSL mode can be the ADSL mode, SHDSL mode, and VDSL mode.

l If the port is activated, go to Step 13.l If the port is not activated, run the activate portid command to activate the user port. Then,

go to Step 12.




modify the VPI and VCI of the UA5000 to be the same as those configured on the modem,or modify the VPI and VCI of the modem to be the same as those configured on theUA5000. If the VPI and VCI of the UA5000 are to be modified, run the undo service-port command to delete the original service port, and then run the service-port commandto configure the new VPI and VCI. Then, go to Step 14.


Step 15 Run the display encapsulation frameid/slotid/portid command to check whether the PVC isencapsulated in PPPoA mode.

In query results, ENCAP indicates the PVC encapsulation mode. The encapsulation modecorresponding to PPPoA is vc_ppp or llc_ppp.

l If the PVC is encapsulated in PPPoA mode, go to Step 17.l If the PVC is not encapsulated in PPPoA mode, run the encapsulation frameid/slotid/

portid command to set the PVC encapsulation mode to PPPoA. Then, go to Step 16.


Step 17 Check whether the encapsulation mode configured on the modem is the same as the query resultin Step 15.l If the encapsulation mode configured on the modem is the same as the query result, go to

Step 23.l If the encapsulation mode configured on the modem is different from the query result,

modify the modem configuration to be the same as that of the UA5000. Then, go to Step18.




27














Step 24 End.

----End

2.2.4 Failure to Obtain an IP Address in IPoA DialupThis topic describes how to troubleshoot a fault when a user fails to access the Internet becauseno IP address can be obtained in IPoA dialup.




28

1. Check whether the IPoA to IPoE conversion function is enabled.2. Check whether the MAC address pool is correct and whether MAC addresses in the MAC

address pool are exhausted.3. Check the attribute of the upstream VLAN and the VLAN cannot be a QinQ VLAN.4. Check whether the uplink port is added to the upstream VLAN and whether the upstream

link is in the online state.5. Check whether the user port is activated.6. Check whether the VPI and the VCI are the same as those configured on the modem.7. Check the associated configurations of PVC encapsulation mode.8. Check whether the IPoA default gateway or the destination IP address is correctly

configured.9. Check whether MAC address flapping occurs.


Procedure

Step 1 Run the display ipoa config command to check whether the IPoA to IPoE conversion functionis enabled.l If the IPoA to IPoE conversion function is enabled, go to Step 3.l If the IPoA to IPoE conversion function is disabled, run the ipoa enable command to enable

the IPoA to IPoE conversion function. Then, go to Step 2.


Step 3 Run the display mac-pool all command to check whether the MAC address is configured andwhether MAC addresses in the MAC address pool are exhausted.

If MAC addresses is the same as Addresses in use, MAC addresses are exhausted.

The system supports a maximum of 20 MAC address pools, and a maximum of 1024 MACaddresses can be configured.

l If the MAC address is not configured or MAC addresses in the MAC address pool areexhausted, run the mac-pool command to configure the MAC address pool. Then, go toStep 4.

l If the MAC address is configured and MAC addresses in the MAC address pool are notexhausted, go to Step 5.


Step 5 Run the display vlan vlanid command to query the attribute of the upstream VLAN.



29

l If the upstream VLAN is a QinQ VLAN, configure the VLAN again and use a non-QinQVLAN as the upstream VLAN. Then, go to Step 6.

l If the upstream VLAN is not a QinQ VLAN, go to Step 7.


Step 7 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN. In other words, check whether the query result contains theupstream VLAN ID.l If the uplink port is added to the upstream VLAN, go to Step 9.l If the uplink port is not added to the upstream VLAN, run the port vlan command to add



Step 9 Run the display board frameid/slotid command to check whether the state of the linkcorresponding to the uplink port is online.l If the link corresponding to the uplink port is online, go to Step 11.l If the link corresponding to the uplink port is not online, connect the upstream physical link



Step 11 In xDSL mode, run the display port state portid command to check whether the port to whichthe user belongs is activated (Status is Activated).

The xDSL mode can be the ADSL mode, SHDSL mode, and VDSL mode.

l If the VPI and VCI of the service stream are the same as those configured on the modem,go to Step 13.

l If the port is not activated, run the activate portid command to activate the user port. Then,go to Step 12.


Step 13 In global config mode, run the display service-port port frameid/slotid/portid command tocheck whether VPI and VCI of traffic streams are the same as VPI and VCI configured on themodem.l If the VPI and VCI of the service stream are the same as those configured on the modem,


modify the VPI and VCI of the UA5000 to be the same as those configured on the modem,or modify the VPI and VCI of the modem to be the same as those configured on the



30

UA5000. If the VPI and VCI of the UA5000 are to be modified, run the undo service-port command to delete the original service port, and then run the service-port commandto configure the new VPI and VCI. Then, go to Step 14.


Step 15 Run the display encapsulation frameid/slotid/portid command to query the PVC encapsulationmode.

In query results, ENCAP indicates the PVC encapsulation mode. The encapsulation modecorresponding to IPoA is vc_ip or llc_ip.

l If ENCAP is llc_ip, SRCIP is configured, and SRCIP is the same as the IP addressconfigured on the modem, go to Step 17.

l If ENCAP is llc_ip, SRCIP is configured, and SRCIP is different from the IP addressconfigured on the modem, modify SRCIP of the UA5000 to be the same as the IP addressconfigured on the modem, or modify the IP address configured on the modem to be thesame as SRCIP of the UA5000. If SRCIP of the UA5000 is modified, run theencapsulation command to configure new SRCIP. Then, go to Step 16.

l If ENCAP is llc_ip, SRCIP is not configured, and the modem reports the source IP addressthrough the InAtmArp protocol, go to Step 17.

l If ENCAP is llc_ip, SRCIP is not configured, and the modem does not report the sourceIP address through the InAtmArp protocol, run the encapsulation frameid/slotid/portidcommand to configure the source IP address for the traffic streams and this IP address isthe same as the IP address configured on the modem. Then, go to Step 16.

l If ENCAP is vc_ip, SRCIP is configured, and SRCIP is the same as the IP addressconfigured on the modem, go to Step 17.

l If ENCAP is vc_ip, SRCIP is configured, and SRCIP is different from the IP addressconfigured on the modem, modify SRCIP of the UA5000 to be the same as the IP addressconfigured on the modem, or modify the IP address configured on the modem to be thesame as SRCIP of the UA5000. If SRCIP of the UA5000 is modified, run theencapsulation command to configure new SRCIP. Then, go to Step 16.

l If ENCAP is vc_ip, SRCIP is not configured, run the encapsulation frameid/slotid/portid command to configure the source IP address for the traffic streams and this IP addressis the same as the IP address configured on the modem. Then, go to Step 16.

l If ENCAP is auto and the encapsulation mode configured on the modem is llc, go to Step17.

l If ENCAP is auto and the encapsulation mode configured on the modem is vc-mux, modifythe encapsulation mode to llc. Then, go to Step 16.


Step 17 Run the display encapsulation frameid/slotid/portid command to query the PVC encapsulationmode and check whether the destination IP address (DSTIP) is configured.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 20.



31

Step 18 Check whether the destination IP address is valid.

If the upper-layer device connected to the uplink port and the UA5000 are in the same networksegment, the destination IP address is the IP address of the upper-layer device.

If the upper-layer device connected to the uplink port and the UA5000 are in different networksegments, the destination IP address is the IP address of the upstream VLAN L3 interface. TheIP address of the upstream VLAN L3 interface and the IP address of the upper-layer device mustbe in the same network segment.

l If the destination IP address is valid, go to Step 26.l If the destination IP address is invalid, modify it to be a valid IP address. Then, go to Step

19.


Step 20 Run the display ipoa config command to check whether the valid default gateway is configured.

If the destination IP address of IPoA is not configured, the system uses the default gateway ofIPoA as the destination IP address. Therefore, the default gateway is generally configured as thesame as the destination IP address.

If the upper-layer device connected to the uplink port and the UA5000 are in the same networksegment, the default gateway is the IP address of the upper-layer device.

If the upper-layer device connected to the uplink port and the UA5000 are in different networksegments, the default gateway is the IP address of the upstream VLAN L3 interface. The IPaddress of the upstream VLAN L3 interface and the IP address of the upper-layer device mustbe in the same network segment.

l If the valid default gateway is configured, go to Step 26.l If the valid default gateway is not configured, modify it to be a valid IP address of the

gateway. Then, go to Step 21.









32









Step 27 End.

----End

2.3 A Low Internet Access RateThis topic describes how to troubleshoot a fault when the Internet access rate is low.



1. Check whether the traffic rate of the user is limited on the BRAS.2. Check whether the line activation rate meets the user's bandwidth requirement.3. Check whether the limited rate configured in the traffic profile meets the user bandwidth

requirement.4. Check whether user bandwidth is occupied by unknown traffic.5. Check whether the bandwidth of the uplink port is insufficient.6. Check whether packets are lost on the xDSL line.7. Check whether packets are lost on the uplink port.8. Check whether MAC address flapping occurs.9. Check whether packets are lost in transmission from the user to the BRAS or from the user

to the website.



33


Procedure

Step 1 Check whether the traffic rate of the user is limited on the BRAS.l If the traffic rate of the user is limited on the BRAS, go to Step 3.l If the traffic rate of the user is not limited on the BRAS, go to Step 2.

Step 2 Cancel the traffic rate limit on the BRAS. Then, check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 3.

Step 3 Run the display line operation port command to check whether the line activation rate of thefaulty port meets the user's bandwidth requirement.

Downstream channel rate (Kbps) indicates the current downstream activation rate, andUpstream channel rate (Kbps) indicates the current upstream activation rate. If the upstreamor downstream activation rate does not meet the user's bandwidth requirement, the Internetaccess rate will be low.

l If the upstream or downstream activation rate does not meet the user's bandwidthrequirement, modify the line profile by referring to 15.13 Changing the Line Profile orLine Template of an xDSL Port. Then, go to Step 4.

l If the upstream or downstream activation rate meets the user's bandwidth requirement, goto Step 5.


Step 5 Run the display service-port port command to query the index of the traffic profile bound withthe faulty port.

Rx indicates the index of the Rx (downstream) traffic profile, and TX indicates the index of theTx (upstream) traffic profile.

Step 6 Run the display traffic table command to check whether the limited rates of the Rx and Txtraffic profiles meet user's bandwidth requirement.

CAR indicates the maximum committed access rate. If the CAR value is smaller than the user'sbandwidth requirement, the user's Internet access rate is low.

l If the limited rates of the Rx and Tx traffic profiles do not meet the user's bandwidthrequirement, modify the traffic profile by referring to 15.13 Changing the Line Profile orLine Template of an xDSL Port. Then, go to Step 7.

l If the limited rates of the Rx and Tx traffic profiles meet the user's bandwidth requirement,go to Step 8.

Step 7 Check whether the service is restored.l If the service is restored, go to Step 27.



34


Step 8 Stop the user from accessing the Internet, and run the display traffic command to query thereal-time traffic on the faulty port.

Rx Traffic (Kbps) indicates the current upstream traffic and Tx Traffic (Kbps) indicates thecurrent downstream traffic. Normally, when the user stops Internet access, the upstream anddownstream traffic is very light (far lower than the user bandwidth) and is close to 0.

l If the upstream or downstream traffic is very heavy, unknown traffic occupies the userbandwidth. In this case, go to Step 9.

l If the upstream or downstream traffic is very light (far lower than the user bandwidth) andis close to 0, go to Step 10.

Step 9 Capture packets by using a packet capture tool, such as Ethereal installed on the PC to checkthe source of the unknown traffic and to further clear the unknown traffic (For example, checkwhether the system that sends the unknown traffic is infected with viruses). Then, check whetherthe service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 10.

Step 10 Check whether the bandwidth of the uplink port is insufficient.1. In IPM mode, run the display port state portid command to query the maximum permitted

bandwidth of the uplink port (the value of Ethernet port rate in the query result, in unitof Mbit/s).

2. Ask the user to continue the attempt to access the Internet, and then run the display porttraffic command multiple times (10 times are recommended) to query the real-time trafficof the uplink port. The interval between two queries is 20s. Then, check whether the currentoccupied bandwidth of the uplink port is close to the maximum permitted bandwidth.

NOTE

The traffic may be burst traffic; therefore, it is recommended that you query the traffic multiple times.

The queried real-time traffic is in the unit of octets/s, and the conversion relationship between octets/s and Mbit/s is 1 Mbit/s = 131072 octets/s.

l After you calculate the bandwidth in Mbit/s, if the current occupied bandwidth of the uplinkport is close to the maximum permitted bandwidth, the bandwidth of the uplink port of thesite is insufficient. In this case, go to Step 11.

l If the current occupied bandwidth of the uplink port is far lower than the maximumpermitted bandwidth, go to Step 12.

Step 11 Increase the maximum permitted bandwidth of the uplink port (for example, replace the 100Mbit/s daughter board with the 1000 Mbit/s daughter board, or run the speed command toconfigure a higher bandwidth of the uplink port), or use multiple uplink ports (uplink portaggregation) to provide the user bandwidths, or decrease the number of users configured on thedevice (migrate certain users to other devices). Then, check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 12.



35

NOTE

The maximum permitted bandwidth of the uplink port is associated with the hardware capability (a 100Mbit/s or 1000 Mbit/s daughter board, and you can run the display board 0 command to query the typeof the current daughter board used by the control board) and the configurations.

l If the negotiation function of the uplink port is enabled (run the auto-neg command to configure thenegotiation function), the maximum permitted bandwidth of the uplink port is determined by thenegotiation between the uplink port and the port on the interconnected device.

l If the negotiation function of the uplink port is disabled, the maximum permitted bandwidth of theuplink port is the value configured by running the speed command.

Step 12 In ADSL mode, run the display statistics performance portid current-15minutes commandmultiple times (10 times are recommended) to query the performance statistics of the faulty port.(In SHDSL mode, the corresponding command is display statistics performance portidcurrent. In VDSL mode, the corresponding command is display statistics performance portidchannel co current-15minutes.) The interval between two queries is 20s. Then, check whetherthe number of CRC packet loss on the line of the user port increases.l If Count of all blocks received with uncorrectable errors of the ADSL port, CRC

anomaly count in 15 minutes of the SHDSL port, or Count of coding violations of theVDSL port increases, CRC packets are lost on the line. In this case, go to Step 13.

l If neither of the preceding values increases, go to Step 15.

Step 13 Replace the modem and check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 14.

Step 14 Check the line environment. That is, check whether the cables are old or damaged, and whetheran interference source exists. If the cables are aged or damaged, and an interference source exists,troubleshoot the faults. Then, check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 15.

Step 15 In IPM mode, run the display port statistics command multiple times (10 times arerecommended) to query the performance statistics of the uplink port. The interval between twoqueries is 20s. Then, check whether the number of CRC packets lost on the uplink port increases.l If Number of CRC error frames increases, CRC packets are lost on the uplink port. The

packet loss may occur because the upstream link is abnormal, port negotiation is incorrect,or the port is faulty. In this case, go to Step 16.



l If the optical port is used for upstream transmission, check whether the negotiation modeof the local port is the same as the negotiation mode of the port on the interconnecteddevice. Run the display port state portid command to check the negotiation mode ofthe local uplink port. At the same time, check whether optical fibers are loose andwhether the optical transceiver is matched. Run the display port opticstate portidcommand to query the information about the optical transceiver, and mainly checkwhether the type, wavelength, and transmission distance of the local and interconnectedoptical transceivers are consistent respectively. Make sure that the negotiation modesof ports are the same, and optical fibers are firmly inserted. If necessary, see Replacingthe Optical Transceiver to replace an optical transceiver.



36












l If BRAS MAC address flapping occurs, check whether a ring network or user attack exist.If any, troubleshoot the fault (for example, run the security mac-filter command toconfigure the MAC address filtering function, disconnect the ring network, and deactivatethe port where the attack is from). Then, go to Step 20.



Step 21 Check whether this fault occurs only when certain websites are opened.l If this fault occurs only when certain websites are opened, check the connections between

the device and these websites. Then, go to Step 22.



37

l If this fault occurs when opening all websites, check the connection between the deviceand the BRAS. Then, go to Step 24.

Step 22 On the DOS of the PC, type Ping -n 100 x.x.x.x. x.x.x.x indicates the IP address of the website(it can be the domain name of the Website), and 100 indicates that 100 packets are sent to thewebsite for the ping test. Then, go to Step 23.

Step 23 On the DOS of the PC, type Ping -l 1200 -n 100 x.x.x.x. x.x.x.x indicates the IP address of thewebsite (it can be the domain name of the Website), and 1200 indicates that 100 packets withthe length of 1200 octets are sent to the website for the ping test. Then, go to Step 24.

Step 24 On the DOS of the PC, type Ping -n 100 x.x.x.x. x.x.x.x indicates the IP address of the BRAS,and 100 indicates that 100 packets are sent to the BRAS for the ping test. Then, go to Step 25.

Step 25 On the DOS of the PC, type Ping -l 1200 -n 100 x.x.x.x. x.x.x.x indicates the IP address of theBRAS, and 1200 indicates that 100 packets with the length of 1200 octets are sent to the BRASfor the ping test. Then, go to Step 26.


Step 27 End.

----End

2.4 Frequent Internet Access InterruptionThis topic describes how to troubleshoot a fault when a user connected to the UA5000 accessesthe Internet but the connection is frequently interrupted.



1. Check whether the service board status is normal.

2. Check whether the service port is deactivated frequently.

3. Check whether packets are lost on the uplink port.

4. Check whether the user MAC address flapping occurs.

5. Check whether the BRAS MAC address flapping occurs.

6. Check line parameters of the faulty port.

7. Check the physical line.

8. Replace the modem.




38

ProcedureStep 1 In diagnose mode, run the display reset-record command to check whether the board that houses

the faulty port is reset repeatedly.l If the board that houses the faulty port is reset repeatedly, see 12.4 Service Board Resets

Repeatedly.l If the board that houses the faulty port is not reset repeatedly, go to Step 2.

Step 2 Run the display alarm history command to check whether the port deactivation alarm of theuser who is affected by the fault is recorded in historical alarms.l If the port deactivation alarm of the user who is affected by the fault is recorded in historical

alarms, go to Step 9.l If the port deactivation alarm of the user who is affected by the fault is not recorded in

historical alarms, go to Step 3.

Step 3 In IPM mode, run the display port statistics command multiple times (10 times arerecommended) to query the performance statistics of the uplink port. The interval between twoqueries is 20s. Then, check whether the number of CRC packets lost on the uplink port increases.l If Number of CRC error frames increases, CRC packets are lost on the uplink port. The

packet loss may occur because the upstream link is abnormal, port negotiation is incorrect,or the port is faulty. In this case, go to Step 4.



l If the optical port is used for upstream transmission, check whether the negotiation modeof the local port is the same as the negotiation mode of the port on the interconnecteddevice. Run the display port state portid command to check the negotiation mode ofthe local uplink port. At the same time, check whether optical fibers are loose andwhether the optical transceiver is matched. Run the display port opticstate portidcommand to query the information about the optical transceiver, and mainly checkwhether the type, wavelength, and transmission distance of the local and interconnectedoptical transceivers are consistent respectively. Make sure that the negotiation modesof ports are the same, and optical fibers are firmly inserted. If necessary, see Replacingthe Optical Transceiver to replace an optical transceiver.







39











Step 9 Check line parameters of the user port.l In the case of an ADSL2+ port, in ADSL mode, run the display line operation portid

command to check whether the following line parameters are correct (compared with theempirical values or compared with other normal ports).

– Downstream channel SNR margin– Upstream channel SNR margin– Downstream channel rate– Upstream channel rate– Downstream channel attenuation– Upstream channel attenuation

l In the case of a VDSL2 port, in VDSL mode, run the display line operation portid commandto check whether the following line parameters are correct (compared with the empiricalvalues or compared with other normal ports).

– Line SNR margin downstream– Line SNR margin upstream– Actual line rate downstream– Actual line rate upstream



40

– Line attenuation downstream

– Line attenuation upstream

l In the case of an SHDSL port, in SHDSL mode, check whether the following line parametersare correct (compared with the empirical values or compared with other normal ports).

– Run the display line state command to query CurrLineRate.

– Run the display statistics performance portid current command to query Current SNRmargin.

– Run the display statistics performance portid current command to query CurrentLoopAttenuation.

If the preceding parameters are correct, go to Step 14.

If only certain preceding parameters are correct, go to Step 10.

Step 10 Modify line parameters and then check whether the service is restored.

1. Modify line parameters according to the requirements.

l In the case of an ADSL2+ port, in ADSL mode, run the following commands:

– Run the adsl line-profile modify command to change the values of the followingparameters:

– Target SNR margin in downstream

– Minimum SNR margin in downstream

– Maximum SNR margin in downstream

– Target SNR margin in upstream

– Minimum SNR margin in upstream

– Maximum SNR margin in upstream

– Run the adsl extline-profile modify command to change the values of the followingparameters:

– Minimum INP on downstream direction

– Minimum INP on upstream direction

l In the case of a VDSL2 port, in VDSL mode, run the vdsl line-profile modify commandto change the values of the following parameters:

– Target SNR margin downstream

– Minimum SNR margin downstream

– Maximum SNR margin downstream

– Target SNR margin upstream

– Target SNR margin upstream

– Maximum SNR margin upstream

l In the case of an SHDSL port, in SHDSL mode, run the shdsl line-profile modifycommand to change the values of the following parameters:

– Downstream current target SNR margin and Downstream worst case targetSNR margin

– Upstream current target SNR margin and Upstream worst case target SNRmargin.



41

NOTE

After the values of the preceding parameters are changed, run the shdsl line-profilemodify command to set Target SNR margin bitmap to 0xF to make the preceding fourSNR margins take effect.

2. Check whether the service is restored.l If the service is restored, go to Step 24.l If the service is not restored, rectify the fault in the following conditions:

– If the affected port is an SHDSL or VDSL port, go to Step 13.– If the affected port is an ADSL2+ port, go to Step 11.

Step 11 In ADSL mode, run the display line operation port command to check whether the upstreamand downstream noise margins of the faulty port change frequently, whether the upstream ordownstream noise margin of the faulty port is a negative value, or whether the upstream ordownstream noise margin is a very small positive value. Then, run the display line bit-allocation command to check whether multiple curves exist in the bit allocation map of thefaulty port.l If multiple curves exist in the bit allocation map of the faulty port, there is interference

around the line. In this case, go to Step 12.l If no curves exist in the bit allocation map of the faulty port, go to Step 13.

Step 12 Check the line environment. That is, check whether an interference source exists. If aninterference source exists, troubleshoot the fault. Then, check whether the service is restored.l If the service is restored, go to Step 24.l If the service is not restored, go to Step 13.

Step 13 Check the line environment. That is, check whether the cables are aged or damaged. If the cablesare aged or damaged, troubleshoot the faults. Then, check whether the service is restored.l If the service is restored, go to Step 24.l If the service is not restored and the service board is configured with a built-in splitter, go

to Step 16. If the service is not restored and the service board is configured with an externalsplitter, go to Step 14.

Step 14 Check whether cable connection on the splitter is correct.l If cable connection on the splitter is correct, go to Step 16.l If cable connection on the splitter is incorrect, connect cables again, and then go to Step

15.


Step 16 Check whether connectors of drop cables and phone lines are connected properly.l If connectors of drop cables and phone lines are connected properly, go to Step 18.l If connectors of drop cables and phone lines are not connected properly, connect them again

to ensure that they are connected properly. Then, go to Step 17.




42

Step 18 Check whether other devices except for the PC are connected to the modem.l If other devices are connected to the modem except for the PC, remove the connected

device, and then go to Step 19.l If only the PC is connected to the modem, go to Step 20.


Step 20 Check whether strong interference sources exist around the subscriber end, such as the radioBTS or the high frequency switch power system.l If strong interference sources exist around the subscriber end, it can be determined that

interruption in accessing the Internet is caused by interference sources. In this case, seekhelp from the associated departments. Then, go to Step 24.

l If no strong interference sources exist around the subscriber end, go to Step 21.

Step 21 Collect the port statistics and then go to the next step.l For an ADSL2+ port, in ADSL mode, run the following commands:

– display statistics performance portid current-15minutes (It is recommended that youquery the performance information over three times at intervals of 20s.)

– display statistics performance portid current-24hoursl For a VDSL2 port, in VDSL mode, run the following commands:

– display statistics performance portid channel co current-15minutes (It isrecommended that you query the performance information over three times at intervalsof 20s.)

– display statistics performance portid channel co current-24hours– display statistics performance portid channel cpe current-15minutes (It is

recommended that you query the performance information over three times at intervalsof 20s.)

– display statistics performance portid channel cpe current-24hours– display statistics performance portid line-initial current- 15minutes (It is


– display statistics performance portid line-initial current- 24hours– display statistics performance portid line-showtime co current-15minutes (It is


– display statistics performance portid line-showtime co current-24hours– display statistics performance portid line-showtime cpe current-15minutes (It is


– display statistics performance portid line-showtime cpe current-24hoursl For an SHDSL port, in SHDSL mode, run the following command:

– display statistics performance portid current (It is recommended that you query theperformance information over three times at intervals of 20s.)

Step 22 Replace a modem to perform a test.



43

l If the fault does not persist, go to Step 24.l If the fault persists, go to Step 23.


Step 24 End.

----End

2.5 Failure to Make a Phone CallThis topic describes how to troubleshoot a fault when a user connected to the UA5000 cannotmake a phone call.


1. If the user can access the Internet, check whether the physical connection between theUA5000 and the narrowband switch is normal.

2. If the user cannot access the Internet, check whether the subscriber line is properlyconnected.


Procedure

Step 1 Check whether the user can access the Internet.l If the user can access the Internet, go to Step 2.l If the user cannot access the Internet, go to Step 4.

Step 2 Check whether the physical connection between the UA5000 and the narrowband switch isnormal.l If the physical connection between the UA5000 and the narrowband switch is normal, go

to Step 6.l If the physical connection between the UA5000 and the narrowband switch is abnormal,

troubleshoot the physical connection fault, and then go to Step 3.

NOTE

Check whether the cable connection between the UA5000 and the narrowband switch is normal and whethercables are properly connected and damaged.




44

Step 4 Check whether the subscriber line is properly connected.l If the subscriber line is properly connected, go to Step 6.l If the subscriber line is improperly connected, troubleshoot the physical connection fault,

and then go to Step 5.

NOTE

l In the case of an external splitter board, check whether wiring is correct and properly connected.

l If a cable distribution box is used indoors, check whether the cable distribution box is properlyconnected and complies with the local standard (mainly the high frequency and low frequency).



Step 7 End.

----End



45

3 Troubleshooting Video Service Faults (theMVLAN Mode)

About This Chapter

This chapter describes how to troubleshoot common MVLAN multicast service faults, whichinclude online access failures, no image when accessing a program, poor program quality,program interruption, and program change failures.

3.1 Failure to Go OnlineThis section describes how to troubleshoot the failure in which a multicast user who is in theoffline or blocked state on the UA5000 cannot order a program.

3.2 Failure to Watch a Program Even After Successfully Accessing the ProgramThis section describes how to troubleshoot the failure where no image is displayed when usersorder multicast programs.

3.3 The Program Can Be Ordered Successfully But the Program Quality Is PoorThis section describes how to troubleshoot poor program quality (for example, a blurry image)when multicast users order programs.

3.4 The Program Is InterruptedThis section describes how to troubleshoot program interruptions when multicast users arewatching programs.

3.5 Program Switching FaultThis section describes how to troubleshoot program change failures. There are four commoncauses for program change failures: changing to a new program fails, no image after changingto a new program, poor program quality (for example, a blurry image) after changing to a newprogram, and an extended wait time when switching between programs.

UA5000 Universal Access UnitTroubleshooting 3 Troubleshooting Video Service Faults (the MVLAN Mode)


46

3.1 Failure to Go OnlineThis section describes how to troubleshoot the failure in which a multicast user who is in theoffline or blocked state on the UA5000 cannot order a program.


1. Check whether the user's modem is operating normally.2. Check whether the line between the UA5000 and the user's modem is normal.3. Check whether the user port has been activated.4. Check whether the virtual path identifier (VPI) and virtual channel identifier (VCI)

configured on the UA5000 for the multicast user and on the modem are the same.5. Check whether the user is a member of the multicast virtual local area network (VLAN).6. Check whether the program ordered by the user actually exists.7. Check whether the user has permission to watch the program.8. Check whether the user is provided with sufficient bandwidth.


Procedure

Step 1 Check the user's modem and the line between the UA5000 and the modem.1. Check the indicator status on the modem to determine whether the modem is activated.

l If the modem is activated, go to Step 8.l If the modem is not activated, go to Step 1.2.

2. Replace the modem and then check whether the modem can be activated.l If the modem can be activated, go to Step 1.3.l If the modem cannot be activated, go to Step 1.4.


4. Check whether the line between the UA5000 and the user's modem is not connectedproperly or whether the line is old. Reconnect the line properly or replace the old line asneeded to ensure good line quality. Then, check whether the modem can be activated.l If the modem can be activated, go to Step 1.5.l If the modem cannot be activated, go to Step 2.

5. Check whether the service is restored.l If the service is restored, go to Step 16.



47


Step 2 Run the display board frameid/slotid command to check whether the user port is deactivated(the value of the Status parameter is Deactivated).l If the user port is deactivated, go to Step 3.l If the user port is not deactivated, go to Step 15.

Step 3 Run the activate portid command to activate the user port.l If the user port can be activated, go to Step 4.l If the user port cannot be activated, go to Step 5.


Step 5 Run the atm-ping portid vpi vci command in xDSL mode to check whether the UA5000 canping the affected user's modem.l If the UA5000 can ping the modem, go to Step 8.l If the UA5000 cannot ping the modem, go to Step 6.

Step 6 Run the display service-port port frameid/slotid/portid command in global config mode tocheck whether the VPI and VCI configured for the user's service port are the same as the VPIand VCI configured on the user's modem.l If the configurations are the same, go to Step 8.l If the configurations are different, go to Step 7.

Step 7 Change the service port or modem's VPI and VCI configurations as needed so that bothconfigurations are the same. Then, check whether the service is restored.l To change the service port's VPI and VCI configurations, run the undo service-port

command to delete the user's original service port, and then run the service-port commandto configure a new service port with the same VPI and VCI configurations as the user'smodem.

l Change the settings directly on the modem so that they match the VPI and VCI configurationsof the service port.

l If the service is restored, go to Step 16.l If the service is not restored, go to Step 8.

Step 8 Run the display service-port port frameid/slotid/portid command to check whether dataconfigurations of the user's service port, such as the VLAN ID and port ID, are correct.l If these data configurations are correct, go to Step 10.l If these data configurations are incorrect, go to Step 9.

Step 9 Run the undo service-port command to delete the original service port. Run the service-portcommand to configure a new service port. Then, check whether the service is restored.l If the service is restored, go to Step 16.l If the service is not restored, go to Step 10.

Step 10 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN.l If the uplink port is added to the upstream VLAN, go to Step 12.



48

l If the uplink port is not added to the upstream VLAN, run the port vlan command to addthe uplink port to the upstream VLAN, which must have the same configuration as the upperlayer device. Then, go to Step 11.


Step 12 Check the multicast configuration on the UA5000.1. Run the display igmp multicast-vlan member command to check whether the user is a

multicast VLAN member.l If the user is a multicast VLAN member, go to Step 12.3.l If the user is not a multicast VLAN member, run the igmp multicast-vlan member

command to add the user to the multicast VLAN. Then, go to Step 12.2.2. Check whether the service is restored.

l If the service is restored, go to Step 16.l If the service is not restored, go to Step 12.3.

3. Run the display igmp program all command to query the multicast program list todetermine whether the user's MVLAN contains the program ordered by the user.l If the MVLAN contains the ordered program, go to Step 12.5.l If the MVLAN does not contain the ordered program, go to Step 12.4.

4. Re-order a program contained in the MVLAN to check whether the program can be orderedsuccessfully.l If the program can be ordered, the user does not have permission to watch the previously

ordered program. Then, go to Step 16.l If the program still cannot be ordered, go to Step 12.5.

5. Run the display igmp user port frameid/slotid/portid grant-program-list command toquery the list of programs that the user has permission to watch and then check whetherthe program that could not be ordered is in the list.l If the program is in the list, go to Step 13.l If the program is not in the list, the user does not have permission to watch the program.

Go to Step 16.

Step 13 Check the bandwidth provided for the user.1. Run the following commands to enable monitoring multicast terminals.

huawei(config)#terminal monitorhuawei(config)#terminal debugginghuawei(config)#debugging igmp all

2. Re-order a program.3. Run the following commands to disable the debugging function after the command output

is displayed.huawei(config)#undo debugging igmphuawei(config)#undo terminal debugginghuawei(config)#undo terminal monitor

4. Check the debugging information displayed on the command line interface (CLI).l If Warning: the user fails to pass bandwidth CAC is displayed and the user is already

using the provided maximum bandwidth, the user can only order a program requiringless bandwidth. Go to Step 16.



49

l If Warning: the user fails to pass bandwidth CAC is displayed and the user'sbandwidth can be increased according to the service operation conditions, run the igmpuser modify command to allocate more bandwidth to the user. Then, have the user goonline again, because the re-allocated bandwidth takes effect the next time the user goesonline. Then, go to Step 14.

l If Warning: the user fails to pass bandwidth CAC is not displayed, go to Step 15.



Step 16 End.

----End

3.2 Failure to Watch a Program Even After SuccessfullyAccessing the Program

This section describes how to troubleshoot the failure where no image is displayed when usersorder multicast programs.


1. Check whether the multicast stream can reach the uplink port on the device.2. Check whether the multicast stream can reach the user port.3. Check whether the multicast user port has been activated.4. Check whether the multicast uplink port is added to the multicast user's MVLAN.5. Check whether the upper layer device can receive IGMP packets but cannot transmit the

program stream.


Procedure

Step 1 In BTV mode, run the display multicast flow-statistic vlan 10 ip 224.1.1.2 command to querythe traffic statistics of the ordered program to check whether the program stream can reach theuplink port. Assume that the MVLAN ID is 10 and the IP address of the multicast program is224.1.1.2.l If the traffic statistics of the ordered program can be queried on the uplink port, the program

stream can reach the uplink port. Go to Step 2.



50

l If the traffic statistics of the ordered program cannot be queried on the uplink port, anexception occurs before the program stream can reach the uplink port. Go to Step 7.

Step 2 Run the display board frameid/slotid command to query the status of the user port where thefault occurs.

l If the user port is activated, go to Step 5.

l If the user port is deactivated, go to Step 3.

Step 3 Query historical alarms, events, and operation logs in the system and then identify why the userport is deactivated.

1. Run the display alarm history all command to query the historical alarms.

2. Run the display event history all command to query the historical events.

3. Run the display log command to query the operation logs.

l If an alarm or event associated with a ring network is detected, the user port where the faultoccurs is deactivated because a ring network has formed on the user side. Remove the ringnetwork and re-activate the user port. Then, go to Step 4.

l If a port deactivation alarm or event or a manual port deactivation record is detected, usethis alarm and event information to identify why the port is deactivated. Ensure that theuser port is deactivated. Then, go to Step 4.

Step 4 Re-order the program. Then, check whether the program runs normally.

l If the program runs normally, go to Step 11.

l If the program does not run normally, go to Step 5.

Step 5 In global config mode, run the display traffic frameid/slotid/portid command to query thetransmit traffic on the multicast user port.

NOTE

This operation is used to check whether the multicast traffic is forwarded from the uplink port on theUA5000 to the user port. Normally, the transmit traffic is almost equal to the multicast traffic.

l If the transmit traffic is normal, go to Step 7.

l If the transmit traffic is abnormal, go to Step 6.

Step 6 Check whether the modem is normal and whether the virtual path identifier (VPI) and virtualchannel identifier (VCI) configured on the modem and on the terminal are the same. Rectify anyfaults you encounter. Then, check whether the service is restored.



Step 7 Check the configuration of the multicast uplink port.

1. Run the display igmp uplink-port all command to query the uplink port corresponding tothe MVLAN where the ordered program is listed.

2. Run the display port vlan frameid/slotid/portid command to check whether the uplink portis in the MVLAN where the ordered program is listed.

l If the uplink port is in the MVLAN, go to Step 9.

l If the uplink port is not in the MVLAN, run the port vlan command to add the uplinkport to the MVLAN. Then, go to Step 8



51

NOTE

Multicast packets carrying the MVLAN tag can be forwarded through the uplink port only when theMVLAN is contained in the VLAN that the multicast uplink port belongs to. Otherwise, the multicastpackets are discarded. Assume that the MVLAN ID is 10 and the multicast uplink port ID is 0/2/0.l In MVLAN mode, run the igmp uplink-port 0/2/0 command to set the uplink port in MVLAN

10 to 0/2/0.l In global config mode, run the port vlan 10 0/2 0 command to add uplink port 0/2/0 to MVLAN

10.

Step 8 Re-order the program. Then, check whether the program runs normally.l If the program runs normally, go to Step 11.l If the program does not run normally, go to Step 9.

Step 9 Check whether the upper layer device can receive IGMP packets but does not transmit theprogram stream, and rectify any faults as needed. Re-order the program. Then, check whetherthe program runs normally.l If the program runs normally, go to Step 11.l If the program does not run normally, go to Step 10.


Step 11 End.

----End

3.3 The Program Can Be Ordered Successfully But theProgram Quality Is Poor

This section describes how to troubleshoot poor program quality (for example, a blurry image)when multicast users order programs.

Fault Location ProcedureCheck whether the total bandwidth of the multicast programs ordered exceeds the maximumavailable bandwidth provided for the multicast user.


ProcedureStep 1 Run the display igmp user port frameid/slotid/portid vpi vci command to query the maximum

available bandwidth for the affected user port and the total bandwidth of the multicast programsordered. Then, go to Step 2.

Step 2 Check whether the total bandwidth of the programs ordered by the user exceeds the maximumavailable bandwidth.



52

l If the total bandwidth of the programs ordered by the user exceeds the maximum bandwidthavailable to the user based on the service plan, inform the user to order programs only whentraffic is light to avoid this fault. Then, go to Step 6.

l If the total bandwidth of the programs ordered by the user exceeds the maximum availablebandwidth, and more bandwidth can be provided for the user based on the service plan, goto Step 3.

l If the total bandwidth of the programs ordered by the affected user does not exceed themaximum available bandwidth, go to Step 4.

Step 3 In BTV mode, run the igmp user modify command to increase the maximum multicastbandwidth allocated to the user, and ensure that the available bandwidth is greater than the totalbandwidth of the multicast programs ordered by the user. Then, re-order the programs to checkwhether the service is restored.l If the service is restored, go to Step 6.l If the service is not restored, go to Step 4.

NOTE

If the required bandwidth exceeds the maximum downstream line activation rate of the port, and thebandwidth of the port can be increased based on the service plan, modify the traffic profile or modify theline profile to provide a greater rate for the port. The actual activation rate of the port is the lesser valuebetween the rate defined in the traffic profile and the rate defined in the line profile.

Step 4 Use the mirroring function to capture packets from the affected program on the uplink port onthe UA5000. Then, go to Step 5.


Step 6 End.

----End

3.4 The Program Is InterruptedThis section describes how to troubleshoot program interruptions when multicast users arewatching programs.


1. Check whether the program automatically stops when the program has been watched forthe maximum preview duration.

2. Check whether the modem and other user terminals are working normally.3. Check whether the user port is operating normally.




53

Procedure

Step 1 Run the display igmp profile profile-index 1 command to query the information about therights profile bound to the user. Assume that the index of the rights profile is 1.l If Right (the user's program rights) is watch, the user can watch the program. Go to Step

2.l If Right is preview, the user can only preview the program. When the program has been

watched for the maximum preview duration, it automatically stops. If this is the case, notifythe user that they must purchase the program if they wish to watch it. Go to Step 13.

NOTE

The program rights, in descending order of priority, are forbidden, preview, watch, and idle. If a user isbound to multiple rights profiles and the program rights for each profile are different, the rights with thehighest priority apply. The rights priority can be reconfigured by running the igmp right-prioritycommand.

Step 2 Run the display igmp user port frameid/slotid/portid command to check whether the user isstill online. If the State parameter is online, the user is online.l If the user is still online, go to Step 3.l If the user is offline, go to Step 5.

Step 3 Check whether the modem and other user terminals are working normally.l If the modem and other user terminals are normal, go to Step 5.l If the modem and other user terminals are abnormal, go to Step 4.

Step 4 Rectify any faults on the modem or other user terminals, and then check whether the service isrestored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 5.

Step 5 Run the display board frameid/slotid command to query the status of the user port where thefault occurs.l If the user port is activated, go to Step 12.l If the user port is deactivated, go to Step 6.

Step 6 Run the display ring check command to check whether the ring network detection function isenabled on the device.l If the ring network detection function is enabled, go to Step 7.l If the ring network detection function is disabled, go to Step 9.

Step 7 Using the logs and alarms, check whether the user port is deactivated because a ring networkhas formed on the user side.l If the user port is deactivated because of a ring network on the user side, go to Step 8.l If the user port is not deactivated because of a ring network on the user side, go to Step

9.

Step 8 Remove the ring network and re-activate the user port. Also ensure that the modem and otheruser terminals are working normally. Then, check whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 11.



54

Step 9 Using the logs and alarms, check whether the port is physically faulty or was deactivatedmanually.l If the port is physically faulty or was deactivated manually, go to Step 10.l If the port is functioning normally and was activated manually, go to Step 12.

Step 10 Move the user to another port and reconfigure the service data for the user or identify why theport was manually deactivated. Ensure that the port providing service to the user is activated,and that the modem and other user terminals are working normally. Then, check whether theservice is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 11.

Step 11 Perform the following steps to collect information.1. Enable multicast terminal monitoring.

huawei(config)#terminal monitor huawei(config)#terminal debugging huawei(config)#debugging igmp all

2. Re-order a program.3. Run the following commands to disable the debugging function after the command output

is displayed.huawei(config)#undo debugging igmp huawei(config)#undo terminal debugging huawei(config)#undo terminal monitor

4. Go to Step 12.


Step 13 End.

----End

3.5 Program Switching FaultThis section describes how to troubleshoot program change failures. There are four commoncauses for program change failures: changing to a new program fails, no image after changingto a new program, poor program quality (for example, a blurry image) after changing to a newprogram, and an extended wait time when switching between programs.

Fault Location ProcedureCheck whether the quick leave attribute for the multicast user is configured properly.


Procedure

Step 1 Check whether the user can change to a new program and watch the program normally.



55

l If the user cannot change to a new program, refer to 3.1 Failure to Go Online.l If the user can change to a new program but there is no image, refer to 3.2 Failure to Watch

a Program Even After Successfully Accessing the Program.l If the user can change to a new program but the program quality is deteriorated, for example,

the image is blurry, refer to 3.3 The Program Can Be Ordered Successfully But theProgram Quality Is Poor.

l If there is an extended wait time when changing between programs, then the user can watchthe ordered program normally, go to Step 2.

Step 2 Run the display igmp user port command to query the quick leave attribute configured for theuser.

In the query result, the value of Quick leave indicates the quick leave attribute configured forthe multicast user. It has the following three modes:

l disable: The quick leave attribute is disabled. When the quick leave attribute is disabled, thesystem sends a group-specific query packet after receiving a leave packet from the multicastuser. If the system does not receive the report packet from the multicast user within a specifiedmulticast user timeout period, the system assumes that the multicast user has left. The defaultmulticast user timeout period is 0 seconds, which means the system assumes the multicastuser has left without sending the group-specific query packet.

l immediate: When the quick leave attribute is immediate, the system forces the user offlineafter receiving a leave packet from the multicast user. The immediate mode, however, hasa limitation: when multiple STBs are connected to a user, a blank screen may be displayedtemporarily after the user goes offline.

l mac-based: Whether the user goes offline is based on the STBs' MAC addresses. Whenmultiple STBs are connected to a single user, the system checks whether the last STB sendsthe multicast user's leave packet. If the last STB sends the packet, the system forces the useroffline immediately. Otherwise, the user remains online. The mac-based mode addressesthe limitation of the immediate mode.

Based on the preceding mode description, check whether the quick leave attribute is properlyconfigured for the user.

l If the quick leave attribute is properly configured, go to Step 4.l If the quick leave attribute is not properly configured, run the igmp user modify port

frameid/slotid/portid quickleave command to modify the quick leave attribute for the user.Then, go to Step 3.


Step 4 Perform the following steps to collect information.1. Enable multicast terminal monitoring.

huawei(config)#terminal monitor huawei(config)#terminal debugging huawei(config)#debugging igmp all

2. Try to order another program.3. Run the following commands to disable the debugging function after the command output

is displayed.huawei(config)#undo debugging igmp huawei(config)#undo terminal debugging huawei(config)#undo terminal monitor



56

4. Go to Step 5.


Step 6 End.

----End



57

4 Troubleshooting Video Service Faults (theNon-MVLAN Mode)

About This Chapter

This topicr describes how to troubleshoot common non-MVLAN mode multicast service faults,which include a failure to go online, image absence after accessing a program, poor programquality, program interruptions, and a failure to change programs.

4.1 Failure to Go OnlineThis section describes how to troubleshoot a failure to order a program by a multicast user, whois in the offline or blocked state on the UA5000.

4.2 Failure to Watch a Program Even After Successfully Accessing the ProgramThis topic describes how to troubleshoot the fault when a user fails to watch a program evenafter successfully accessing the program.

4.3 The Program Can Be Ordered Successfully But the Program Quality Is PoorThis topic describes how to troubleshoot a fault when the multicast user goes online andsuccessfully orders programs but the program display quality is poor (for example, the imageon the screen gets garbled during the display of the video service).

4.4 The Program Is InterruptedThis topic describes how to troubleshoot a program interruption when the multicast user iswatching the program.

4.5 Program Switching FaultThis topic describes how to troubleshoot a fault when a user switches the current program to anew program, including the following faults: The current program cannot be switched to a newprogram; the current program can be switched to a new program, but the new program cannotbe watched; the current program can be switched to a new program, but the quality of the newprogram is poor (a garbled image); the current program can be switched to a new program andthe new program can be watched, but the switching waiting time is long.

UA5000 Universal Access UnitTroubleshooting

4 Troubleshooting Video Service Faults (the Non-MVLANMode)


58

4.1 Failure to Go OnlineThis section describes how to troubleshoot a failure to order a program by a multicast user, whois in the offline or blocked state on the UA5000.


1. Check whether the user's modem is normal.2. Check whether the line between the UA5000 and the user's modem is normal.3. Check whether the user port is activated.4. Check whether the virtual path identifier (VPI) and virtual channel identifier (VCI)

configurations for the multicast user on the UA5000 are the same as the VPI and VCIconfigurations on the modem.

5. Check whether the program ordered by the user exists.6. Check whether the user has rights to order the program.7. Check for the bandwidth provided for the user.


Procedure

Step 1 Check the user's modem and the line between the UA5000 and the modem.1. Check the indicator status on the modem to determine whether the modem is activated.

l If the modem is activated, go to Step 8.l If the modem is not activated, go to Step 1.2.

2. Replace the modem and check whether the modem can be activated.l If the modem can be activated, go to Step 1.3.l If the modem cannot be activated, go to Step 1.4.


4. Check whether the line between the UA5000 and the user's modem is connected properlyor the line is old. Reconnect the line or replace the old line as needed to ensure good linequality. Then, activate the modem and check whether the modem can be activated.l If the modem can be activated, go to Step 1.5.l If the modem cannot be activated, go to Step 2.

5. Check whether the service is restored.l If the service is restored, go to Step 16.




59


Step 2 Run the display board frameid/slotid command to check whether the user port is deactivated(the Status parameter value is Deactivated).l If the user port is deactivated, go to Step 3.l If the user port is not deactivated, go to Step 15.

Step 3 Run the activate portid command to activate the user port. Then, check whether the user portis activated.l If the user port is activated, go to Step 4.l If the user port is not activated, go to Step 5.


Step 5 Run the atm-ping portid vpi vci command in xDSL mode to check whether the UA5000 canping the affected user's modem.l If the UA5000 can ping the affected user's modem, go to Step 8.l If the UA5000 cannot ping the affected user's modem, go to Step 6.

Step 6 Run the display service-port port frameid/slotid/portid command in global config mode tocheck whether the VPI and VCI configured for the user's service port are the same as the VPIand VCI configured on the user's modem.l If the configurations are the same, go to Step 8.l If the configurations are different, go to Step 7.

Step 7 Change the service port or modem's VPI and VCI configurations as needed so that bothconfigurations are the same. Then, check whether the service is restored.l To change the service port's VPI and VCI configurations, run the undo service-port

command to delete the user's original service port, and run the service-port command toconfigure a new service port with the same VPI and VCI configurations as the user's modem.

l Change the settings directly on the modem so they match the VPI and VCI configurationsof the service port.


Step 8 Run the display service-port port frameid/slotid/portid command to check whether such dataconfigurations of the user's service port as the VLAN ID and port ID are correct.l If these data configurations are correct, go to Step 10.l If these data configurations are incorrect, go to Step 9.


Step 10 Run the display port vlan frameid/slotid/portid command to check whether the uplink port isadded to the upstream VLAN.l If the uplink port is added to the upstream VLAN, go to Step 12.




60

l If the uplink port is not added to the upstream VLAN, run the port vlan command to addthe uplink port to the upstream VLAN, which must have the same configuration as the upperlayer device. Then, go to Step 11.


Step 12 Check the multicast data configuration on the UA5000.1. Run the display igmp program all command to check whether the program list contains

a program ordered by the user.l If the program list contains an ordered program, go to Step 12.3.l If the program list does not contain an ordered program, order a program from the

program list. Then, go to Step 12.2.2. Check whether the service is restored.

l If the service is restored, the program ordered by the user is incorrect. Then, go to Step16.

l If the service is not restored, go to Step 12.3.3. Run the display igmp user port frameid/slotid/portid grant-program-list command to

query the list of programs that the user has rights to order and check whether the order-failed program is in the list.l If the program is in the list, go to Step 13.l If the program is not in the list, the user has no rights to order the program. Then, go to

Step 16.

Step 13 Check for the bandwidth provided for the user.1. Run the following commands to enable the terminal monitoring function for the user.


2. Reorder a program.3. Run the following commands to disable the debugging function after the command output

is displayed.huawei(config)#undo debugging igmphuawei(config)#undo terminal debugginghuawei(config)#undo terminal monitor

4. Check for the debugging information displayed on the command line interface.l If the command output displays Warning: the user fails to pass bandwidth CAC and

the user is already using the provided maximum bandwidth, the user can order a programrequiring a smaller bandwidth. Then, go to Step 16.

l If the command output displays Warning:the user fails to pass bandwidth CAC andthe user's bandwidth can be increased according to the service operation conditions, runthe igmp user modify command to allocate more bandwidths to the user and requestthe user to go online again because the re-allocated bandwidth takes effect when theuser goes online the next time. Then, go to Step 14.

l If the preceding information is not displayed, go to Step 15.





61



Step 16 End.

----End

4.2 Failure to Watch a Program Even After SuccessfullyAccessing the Program

This topic describes how to troubleshoot the fault when a user fails to watch a program evenafter successfully accessing the program.


1. Check whether multicast streams are transmitted to the uplink port on the device.2. Check whether multicast streams are transmitted to the user port.3. Check whether the multicast user port is activated.4. Check whether the upper layer device has received the IGMP packets but fails to forward

the packets.


Procedure

Step 1 In BTV mode, run the display multicast flow-statistic vlan 10 ip 224.1.1.2 command to querythe traffic statistics of the ordered program on the uplink port and check whether the orderedprogram stream has reached the uplink port (this scenario assumes that the MLAN is 10 and theIP of the multicast program is 224.1.1.2).l If the program traffic statistics are displayed, the ordered program stream has reached the

uplink port. Then, go to Step 2.l If the program traffic statistics are not displayed, an exception occurs before the program

stream reaches the uplink port. Then, go to Step 7.

Step 2 Run the display board frameid/slotid command to query the status of the faulty port.l If the port is activated, go to Step 5.l If the port is deactivated, go to Step 3.

Step 3 Query the historical system alarms, historical events, and operation logs to find out the causesleading to the deactivation of the port.1. Run the display alarm history all command to query the historical system alarms.




62

2. Run the display event history all command to query the historical events.3. Run the display log command to query the operation logs.l If an alarm or event associated with a ring network is detected, the user port where the fault

occurs is deactivated because a ring network is formed on the user side. Remove the ringnetwork and re-activate the user port. Then, go to Step 4.

l If an alarm or event indicating port deactivation or a manual port deactivation record isdetected, identify the cause of port deactivation based on alarm and event information, andensure that the port providing services for users is deactivated. Then, go to Step 4.

Step 4 Re-order the program. Then, check whether the program display quality is good.l If the program display quality is good, go to Step 11.l If the program display quality is poor, go to Step 5.

Step 5 In global config mode, run the display traffic frameid/slotid/portid command to query thetransmit (Tx) traffic on the multicast user port.

NOTE

This operation checks whether the multicast traffic is forwarded from the uplink port on the UA5000 tothe user port. Normally, the Tx traffic almost reaches the multicast traffic.

l If the Tx traffic is normal, go to Step 7.l If the Tx traffic is abnormal, go to Step 6.

Step 6 Check whether the modem is normal and the VPI and VCI configurations of the modem are thesame as the VPI and VCI configurations of the terminal. Rectify the fault as needed. Then, checkwhether service is restoredl If the service is restored, go to Step 11.l If the service is not restored, go to Step 7.

Step 7 Check the configuration of the multicast uplink port.1. Run the display igmp program ip command to query the ID of the upstream VLAN and

the uplink port (VLAN ID and Uplink port) of the demanded multicast program.2. Run the display port vlan frameid/slotid/portid command to check whether the uplink port

is added to the upstream VLAN. The query result contains the upstream VLAN ID.l If the uplink port is added to the upstream VLAN, go to Step 9.l If the uplink port is not added to the upstream VLAN, run the port vlan command to

add the uplink port to the VLAN. Then, go to Step 8.

Step 8 Re-order the program. Then, check whether the program display quality is good.l If the program display quality is good, go to Step 11.l If the program display quality is poor, go to Step 9.

Step 9 Check whether the upper layer device has received the IGMP packets but fails to forward theprogram stream. Rectify the fault as needed and re-order the program to check whether theprogram display quality.l If the program display quality is good, go to, Step 11.l If the program display quality is poor, go to Step 10.





63

Step 11 End.

----End

4.3 The Program Can Be Ordered Successfully But theProgram Quality Is Poor

This topic describes how to troubleshoot a fault when the multicast user goes online andsuccessfully orders programs but the program display quality is poor (for example, the imageon the screen gets garbled during the display of the video service).


If the multicast user goes online and successfully orders programs but the program quality ispoor, check whether the total bandwidth of the ordered multicast programs exceeds themaximum available bandwidth provided for the multicast user.


Procedure

Step 1 Calculate the maximum available bandwidth provided for the multicast user.

1. Run the display service-port port command to query the ID of the traffic profile boundto the user port where the fault occurs. In this command, Rx specifies the ID of the trafficprofile for the receive (downstream) direction. Make a note of this value.

2. Run the display traffic table command to query the committed access rate (CAR) of theRx traffic profile.

3. Run the display line operation port command to query the CAR of the port line profile.In this command, Downstream channel rate (kbps) specifies the downstream CAR. Thesmaller value between this value and the CAR obtained in the preceding step is themaximum downstream line activation rate of this port.

4. Run the display igmp config command to query the percentage of bandwidth allocated tothe user port where the fault occurs, specifically, the value of the Bandwidth assigned foruser parameter in the query result. Multiply this value by the maximum line activation rate,which is obtained from the preceding step. The result represents the maximum availablebandwidth for the multicast user. Then, go to Step 2.

Step 2 Calculate the sum of the actual bandwidths of all the current multicast programs ordered by theuser who encounters the fault.

1. In BTV mode, run the display igmp user port frameid/slotid/portid command to query allthe current multicast programs ordered by the user, and make a note of the IP addresses ofthe ordered programs.

1. Run the display multicast flow-statistic ip command to query and make a note of theactual bandwidths of the preceding programs. Add the actual bandwidths of these programs




64

and the result is the sum of the actual bandwidths of all the current multicast programsprdered by the user. Then, go to Step 3.

Step 3 According to the calculation result in the preceding step, check whether the sum of the actualbandwidths of all the current multicast programs ordered by the user exceeds the maximumavailable bandwidth provided for the user.

l If the sum of the actual bandwidths exceeds the maximum available bandwidth, and theuser can only use the current bandwidth according to the service plan, ask the user to orderprograms with light traffic to prevent poor program quality problems. Then, go to Step 7.

l If the sum of the actual bandwidths exceeds the maximum available bandwidth, and theuser can be provided with higher bandwidth according to the service plan, go to Step 4.

l If the sum of the actual bandwidths does not exceed the maximum available bandwidth, goto Step 5.

Step 4 Run the igmp user-bandwidth-utilization command to increase the bandwidth allocated to theuser, and ensure that the available bandwidth is greater than the sum of the actual bandwidthsof all the current programs ordered by the user. Then, ask the user to order programs again tocheck whether the service is restored.



NOTE

If the required bandwidth exceeds the maximum downstream line activation rate of the port, and thebandwidth of the port can be increased according to the service plan, you can run the modify the trafficprofile or modify the line profile command to provide higher rate for the port. The actual activation rateof the port is the smaller value between the CAR of the traffic profile and the CAR of the line profile.

Step 5 Capture the packets about the faulty program on the uplink port on the UA5000 throughmirroring. Then, go to Step 6.


Step 7 End.

----End

4.4 The Program Is InterruptedThis topic describes how to troubleshoot a program interruption when the multicast user iswatching the program.



1. Check whether the program automatically stops when the maximum preview duration timesout.

2. Check whether the modem and other terminal devices of the user are working properly.

3. Check whether the user port is working properly.




65


Procedure

Step 1 Run the display igmp profile profile-index 1 command to query the multicast rights profilebound to the user (this scenario assumes that the index of the multicast rights profile is 1).l If the user's multicast rights are watch, the user has the rights to watch the program. Then,

go to Step 2.l If the user's multicast rights are preview, the user has only the rights to preview the program.

When the preview duration of the user times out, the program stops automatically. In sucha case, inform the user of purchasing the program if needed. Then, go to Step 13.

NOTE

The program rights are forbidden, preview, watch, and idle. If a user is bound with multiple rights profilesand the rights for the same program in these profiles are different, the user has the rights with the highestpriority. The rights priorities are forbidden, preview, watch, and idle in descending order by default, whichcan be set by running the igmp right-priority command.

Step 2 Run the display igmp user port frameid/slotid/portid command to check whether the user isstill online, that is, check whether the State parameter is online.l If the user is still online, go to Step 3.l If the user is not online, go to Step 5.

Step 3 Check whether the modem and other terminal devices of the user are working properly.l If the modem and other terminal devices of the user are working properly, go to Step 5.l If the modem and other terminal devices of the user are not working properly, go to Step

4.

Step 4 Rectify the modem or other terminal devices of the user, and check whether the service isrestored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 5.

Step 5 Run the display board frameid/slotid command to query the status of the user port where thefault has occurred.l If the port is activated, go to Step 12.l If the port is deactivated, go to Step 6.

Step 6 Run the display ring check command to query whether the device is enabled with the ringnetwork detection function.l If the device is enabled with the ring network detection function, go to Step 7.l If the device is not enabled with the ring network detection function, go to Step 9.

Step 7 Based on the logs and alarms, check whether the user port is deactivated because of a ringnetwork that is formed on the user side.l If the user port is deactivated because a ring network formed on the user side, go to Step

8.




66

l If the user port is deactivated, but not because a ring network formed on the user side, goto Step 9.

Step 8 Remove the ring network and re-activate the user port on the prerequisite that the modem andother terminal devices of the user are working properly. Then, check whether the service isrestored.



Step 9 Based on the logs and alarms, check whether the port is faulty or deactivated manually.

l If the port is faulty or deactivated manually, go to Step 10.

l If the port is not faulty or deactivated manually, go to Step 12.

Step 10 Connect the user to a normal port (in this case, you need to re-configure the service data for theuser) or identify the causes of the manual deactivation. Ensure that the port that provides theservice for the user is in activated, and that the modem and other terminal devices of the userare working properly. Then, check whether the service is restored.



Step 11 Perform the following steps to collect information.

1. Enable the function of monitoring the multicast user.huawei(config)#terminal monitorhuawei(config)#terminal debugginghuawei(config)#debugging igmp all

2. Ask the user to order programs again.

3. After the command line outputs information, run the following commands to disable thecommissioning function.huawei(config)#undo debugging igmphuawei(config)#undo terminal debugginghuawei(config)#undo terminal monitor

4. Step 12.


Step 13 End.

----End

4.5 Program Switching FaultThis topic describes how to troubleshoot a fault when a user switches the current program to anew program, including the following faults: The current program cannot be switched to a newprogram; the current program can be switched to a new program, but the new program cannotbe watched; the current program can be switched to a new program, but the quality of the newprogram is poor (a garbled image); the current program can be switched to a new program andthe new program can be watched, but the switching waiting time is long.




67


If a fault occurs when a user switches the current program to a new program, check whether thequick leave attribute of the multicast user is correct.


Procedure

Step 1 Check whether the current program can be switched to a new program and whether the newprogram can be watched.

l If the current program can be switched to a new program, see 4.1 Failure to Go Online.

l If the current program can be switched to a new program but the new program cannot bewatched, see 4.2 Failure to Watch a Program Even After Successfully Accessing theProgram.

l If the current program can be switched to a new program but the quality of the new programis poor (a garbled image), see 4.3 The Program Can Be Ordered Successfully But theProgram Quality Is Poor.

l If the current program can be switched to a new program and the new program can bewatched, but the switch waiting time is too long, go to Step 2.

Step 2 Run the display igmp user port command to query the quick leave configuration of the user.

In query results, Quick leave specifies the quick leave attribute of a multicast user, and it hasthe following three modes:

l disable: The quick leave attribute is disabled. When a multicast user is not configured withthis attribute, the system sends a group-specific query packet after receiving the leave packetfrom the user. If the system does not receive the Report packet from the multicast user withinthe preset aging time, it considers that the multicast user has left. The default aging time ofa multicast user is 0s. That is, the user is regarded as offline when the packet of the group-specific query packet is not sent.

l immediate: When the user is configured with the quick leave attribute of the immediatemode, the system forces the user to go offline after receiving the leave packet from the user.The immediate mode, however, has weak points. For example, when a user terminal isconnected to multiple STBs, a temporary black screen may occur if a user is offline.

l mac-based: It specifies the quick offline based on the MAC address. If a user terminal isconnected to multiple STBs, when the system receives the leave packet from the user, itdetermines whether the packet is sent from the last STB. If the packet is sent from the lastSTB, the system forces the user to go offline. Otherwise, the user is still online. Thisprocedure avoids weak points of immediate.

Check whether the quick leave attribute of the user is correct according to the preceding threemodes.

l If the quick leave attribute is correct, go to Step 4.




68

l If the quick leave attribute of the user is incorrect, run the igmp user modify port frameid/slotid/portid quickleave command to change the quick leave attribute of the user. Then,go to Step 3.


Step 4 Collect the information by performing the following steps.1. Run the following commands to enable the monitoring function of the multicast user.


2. Switch a program again.3. After command lines are printed, run the following commands to disable the debugging

function.huawei(config)#undo debugging igmphuawei(config)#undo terminal debugginghuawei(config)#undo terminal monitor

4. Go to Step 5.


Step 6 End.

----End




69

5 Troubleshooting VoIP PSTN Service Faults

About This Chapter

This topic describes how to troubleshoot common VoIP PSTN service faults, such as no powerfeed after offhook, no tone after offhook, and busy tone after offhook. VoIP is the acronym forvoice over IP. PSTN is the acronym for public switched telephone network.

5.1 There Is No Power Feed After OffhookThis topic describes how to troubleshoot a fault when there is no power feed after offhook. Whenthis fault occurs, the phone has no reaction after offhook, and the phone in-use indicator is off,which means that the phone has no power feed.

5.2 No Tone Is Played After OffhookThis topic describes how to troubleshoot a fault when no tone is played after the calling partypicks up the phone off the hook.

5.3 Busy Tone Is Played After OffhookThis topic describes how to troubleshoot a fault when the busy tone is played after offhook. (Innormal cases, the dial tone is played after offhook).

5.4 CLIP Is AbnormalThis topic describes how to troubleshoot a fault when the calling line identification presentation(CLIP) is abnormal. In other words, the caller ID cannot be displayed, or the caller ID displayis incomplete or incorrect.

5.5 One-Way Audio or No Audio OccursThis topic describes how to troubleshoot a fault when one-way audio or no audio occurs. Whena one-way audio fault occurs, the phone of the called party can ring normally but only one partycan hear the voice of the peer party after the called party goes offhook. When a no audio faultoccurs, the phone of the called party can ring normally, but neither the calling party nor thecalled party can hear the voice of the peer party after the called party goes offhook.

5.6 There Is Noise During CommunicationThis topic describes how to troubleshoot a fault when there is noise during normalcommunication.

5.7 Echo Exists

UA5000 Universal Access UnitTroubleshooting 5 Troubleshooting VoIP PSTN Service Faults


70

This topic describes how to troubleshoot a fault when there is echo during normalcommunication.



71




1. Identify the fault scope. Specifically, check whether the fault occurs on some ports, occurson all the ports on some boards, or occurs on all the ports on the entire UA5000.

2. Check whether the phone is working normally.3. Check whether the loop line and circuit line are normal.4. Check whether the service boards are working normally.5. Check whether the power board is working normally.


Procedure

Step 1 Check whether the fault occurs on some ports, occurs on all the ports on some boards, or occurson all the ports on the entire UA5000.l If the fault occurs on some ports, go to Step 2.l If the fault occurs on all the ports on some boards, go to Step 7.l If the fault occurs on all the ports on the entire UA5000, go to Step 8.

Step 2 Replace the phone to test whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 3.

Step 3 Perform a loop line test in the onhook state.l If the test result (shown in Conclusion) is Normal, go to Step 5.l If the test result (shown in Conclusion) is not Normal, the loop line is faulty. In this case,

directly connect a phone to the MDF, perform the test to check on which section of the loopline the fault occurs, and then rectify a loop line fault (for example, replace the loop line)if necessary. Then, go to Step 4.

Step 4 Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault still persists, go to Step 5.

Step 5 Perform a circuit line test in the onhook state.



72

l If the test conclusion (the Off-hook item) is Normal, go to Step 8.l If the test conclusion (the Off-hook item) is not Normal, go to Step 6.

Step 6 Use another port on the same board to test whether the fault is rectified.l If the fault is rectified, the port on the board is faulty. Go to Step 10.l If the fault persists, go to Step 7.

Step 7 Replace the board to test whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault still persists, go to Step 8.

Step 8 Check whether the secondary power board is working normally. For example, check the VIN(RUN) indicator on the secondary power board. If the indicator is on for 1s and off for 1srepeatedly, the secondary power board is working normally.l If the secondary power board is working normally, go to Step 10.l If the secondary power board is not working normally, go to Step 9.

Step 9 Verify that the POWER switch of the secondary power board is turned on, and check the powersupply device. If necessary, replace the power board by referring to Replacing the SecondaryPower Board to ensure that the power supply device provides power normally. Then, checkwhether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 10.


Step 11 End.

----End

5.2 No Tone Is Played After OffhookThis topic describes how to troubleshoot a fault when no tone is played after the calling partypicks up the phone off the hook.


1. Check whether there is power feed after offhook. Specifically, check whether the phonein-use indicator is on after offhook.

2. Identify the fault scope. Specifically, check whether the fault occurs on some ports, all theports on some boards, or all the ports on the entire UA5000.

3. Check whether the data configuration of the port on the UA5000 is the same as the dataconfiguration of the port on the softswitch.

4. Check whether the phone is working normally.5. Check network quality. Specifically, check whether packet loss occurs on the network.6. Check whether signaling interaction is normal.



73

7. Check whether the port is in the Busy state after offhook.8. Check whether the loop line is normal.9. Check whether the UA5000 hardware and the surrounding environment are normal.


Procedure

Step 1 Ask the user to pick up the phone off the hook. Check whether the phone in-use indicator is on.l If the phone in-use indicator is on, go to Step 2.l If the phone in-use indicator is not on, rectify the fault by referring to 5.1 There Is No

Power Feed After Offhook.

Step 2 Check whether the fault occurs on some ports, all the ports on some boards, or all the ports onthe entire UA5000.l If the fault occurs on some ports, go to Step 3.l If the fault occurs on all the ports on some boards, go to Step 16.l If the fault occurs on all the ports on the entire UA5000, go to Step 17.

Step 3 Check whether the data configuration of the port on the UA5000 is the same as the dataconfiguration of the port on the softswitch.l If the data configurations are the same, go to Step 5.l If the data configurations are different, go to Step 4.

Step 4 Modify the data configurations and ensure that they are the same. Then, check whether theservice is restored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 5.

Step 5 Replace the phone to test whether the service is restored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 6.




Step 8 In the offhook state and global config mode, run the display port state frameid/slotid/portidcommand to query the user port status.



74

l If the user port (the result shown in State) is Busy, go to Step 9.l If the user port (the result shown in State) is not Busy, go to Step 18.

Step 9 Run the ping command to ping the IP address of the softswitch.l If the IP address of the softswitch cannot be pinged or packet loss occurs, go to Step 10.l If the IP address of the softswitch can be pinged and no packet loss occurs, go to Step 11.

Step 10 Check whether the connection between the UA5000 and the softswitch is normal and whethera transmission device is working normally. If necessary, rectify a fault until the IP address ofthe softswitch can be pinged and no packet loss occurs. Then, check whether the service isrestored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 11.

Step 11 Use the Toolbox tool to trace H.248 signaling and select the port trace mode.

Normally, the UA5000 reports an offhook event (al/of) and the softswitch issues a dial toneevent (cg/dt) after the phone goes offhook.

l If the UA5000 does not report the offhook event, go to Step 12.l If the UA5000 reports the offhook event but the softswitch does not issue the dial tone

event, the softswitch is faulty. In this case, contact softswitch engineers to locate the fault.Then, go to Step 19.

Step 12 Perform a circuit line test in the onhook state.l If the test result of Off-hook is Normal, go to Step 13.l If the test result of Off-hook is not Normal, go to Step 15.

Step 13 Directly connect a phone to the MDF to perform a test.l If the dial tone is played normally, the loop line is faulty. Rectify the fault by performing

a corresponding operation, such as replacing the loop line. Then, go to Step 14.l If the fault persists, go to Step 15.


Step 15 Use another port on the same board to perform the test.l If the dial tone is played normally, go to Step 19.l If the fault persists, go to Step 16.

Step 16 Replace the board to perform the test.l If the dial tone is played normally, go to Step 19.l If the fault persists, go to Step 17.

Step 17 Check the UA5000 hardware and the surrounding environment.1. Check the grounding of the device.

Check whether the grounding is proper according to the installation requirements describedin the related document (refer to Running Environment). If possible, use a ground resistancetester to test whether the grounding resistance is less than 10 ohms.



75

l If the grounding does not meet the requirements, ground the device again until thegrounding is proper. Then, go to Step 17.2.

l If the grounding meets the requirements, go to Step 17.3.2. Check whether the service is restored.

l If the service is restored, go to Step 17.3.l If the service is not restored, go to Step 17.3.

3. Check whether the control board is properly installed.l If the control board is properly installed, go to Step 17.5.l If the control board is not properly installed, install the control board properly. Then,

go to Step 17.4.4. Check whether the service is restored.


5. Check whether the subrack is normal.

Observe the top of the cabinet and the subrack. Check for leaks in the roof of the cabinet,water trails on the subrack, and evidence of vermin. Also check whether the cabinet isproperly sealed.

l Wipe away any water and clear away any unwanted debris. Ensure that the equipmentroom is waterproof and the cabinet is properly sealed. (The cabinet keeps insects orrodents out of the cabinet.) Then, go to Step 17.6.

l If there is no evidence of water or vermin, go to Step 17.7.6. Check whether the service is restored.


7. Check whether the cable is properly connected.

If the port in the slave subrack or extended subrack is faulty, check whether the HW cableis properly connected to the HW transfer board.

l If the cable is not properly connected, connect the cable properly or replace the HWcable, subscriber cable, HW transfer board (front-access), or HW transfer board (rear-access) by referring to Replacing the HW Cable, Replacing the Subscriber Cable,Replacing the HW Transfer Board (Front-Access), or Replacing the HW Transfer Board(Rear-Access). Then, go to Step 17.8.

l If the cable is properly connected, go to Step 17.9.8. Check whether the service is restored.


9. Check the -48 V power output.

Use a multimeter to check whether the -48 V voltage for the subrack is in the range of -38.4V to -60 V. For the multimeter, select the DC shift, namely, 100 V shift, and perform thetest on the power distribution box (PDB).

l If the -48 V voltage for the subrack is not in the specified range, adjust the voltage andensure that the primary power supply is stable. Then, go to Step 17.10.



76

l If the -48 V voltage for the subrack is in the specified range, go to Step 18.10. Check whether the service is restored.



Step 19 End.

----End



1. Check whether the board where the fault occurs is normal.2. Check whether the user port is configured with data and whether the data is consistent with

the data configured on the softswitch.3. Check whether the port where the fault occurs is normal.4. Check whether the media gateway (MG) interface is normal.5. Check whether there are available digital signal processor (DSP) resources in the system.6. Check whether signaling interaction is normal.7. Check whether the loop line is normal.8. Check whether the UA5000 hardware and the surrounding environment are normal.

CAUTIONTo facilitate reporting faults, save the results for each of the following steps.Before you remove and insert a board, take antistatic measures.

Procedure


Step 2 Run the display board frameid command to check whether the board where the fault occurs isnormal.



77

l If the board is normal, go to Step 4.l If the board is abnormal, go to Step 3.

Step 3 Remove and then insert the board where the fault occurs. Wait for five minutes. If the board isabnormal, replace the board. Wait until the board works in the Normal state. Then, checkwhether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 4.

Step 4 In onhook state, run the display mgpstnuser frameid/slotid/portid command to check whetherthe user port is configured with data and whether the data is consistent with the data configuredon the softswitch.l If the data is configured and it is consistent with the data configured on the softswitch, go

to Step 6.l If the data is configured but it is inconsistent with the data configured on the softswitch,

go to Step 5.

Step 5 In ESL user mode, run the mgpstnuser add command to configure the user port data (if no datais configured), or run the mgpstnuser modify command to modify the user port data. (If thedata is inconsistent with the data configured on the softswitch, you can also run an associatedcommand to modify the data configured on the softswitch so that the data configured on thesoftswitch is consistent with the data configured on the UA5000.) Ensure that the user data ofthe UA5000 is consistent with the user data of the softswitch. Then, check whether the serviceis restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 6.

Step 6 In global config mode, run the display port state frameid/slotid/portid command to query thestatus of the user port where the fault occurs.l If the port is in the Idle state, go to Step 10.l If the port is in the Failed state, go to Step 7.l If the port is in the Testing state, go to Step 8.

Step 7 Perform the test on the port that is in the Idle state to check whether the service is restored.l If the service is restored, the port on the board is faulty. Go to Step 26.l If the service is not restored, go to Step 9.

Step 8 After the test is complete and the port goes into the Idle state, perform the test again to checkwhether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 9.

Step 9 In ESL user mode, run the display port state frameid/slotid/portid command to query the servicestatus of the port.l If the service status is StartSvc, go to Step 15.l If the service status is LBlock, go to Step 10.l If the service status is AutoBlk, go to Step 20.l If the service status is RemoBlk, go to Step 11.

Step 10 Run the undo endservice frameid/slotid/portid command to restart a stopped service. Checkwhether the service is restored.



78


Step 11 Run the display if-h248 all command to check whether the MG interface is normal.l If the MG interface is normal, go to Step 12.l If the MG interface is abnormal, rectify the fault by referring to Rectifying the Fault of

the MG Interface.

Step 12 Run the display mgpstnuser frameid/slotid/portid command to check whether the user dataconfigured on the UA5000 is consistent with the user data configured on the softswitch.l If they are consistent, go to Step 14.l If they are inconsistent, go to Step 13.

Step 13 Run the #amgpstnuser_modify command to modify the configuration data of the user port toensure that the user data configured on the softswitch is consistent with the user data configuredon the UA5000. In normal cases, the service status of the port is StartSvc. Then, pick up thephone off the hook to check whether the dial tone is played.l If the dial tone is played, go to Step 27.l If the dial tone is not played, go to Step 14.

Step 14 In global config mode, run the display board frameid command to check whether the controlboard is configured with a DSP daughter board. Specifically, check whether command outputdisplays any board in Sub0 / Sub1 and whether the board is working normally.l If the control board is configured with the DSP daughter board and the DSP daughter board

is working normally, go to Step 16.l If the control board is not configured with the DSP daughter board, go to Step 15.

Step 15 Add a required DSP daughter board and perform the test to check whether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 16.

Step 16 Run the display dsp state frameid/slotid/subbid command in Narrow resource mode to checkwhether there are available DSP resources.l If there are available DSP resources, go to Step 18.l If there are no available DSP resources, go to Step 17.

Step 17 Wait until there is an idle DSP channel. Perform the test again to check whether the service isrestored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 18.

Step 18 Perform a loop line test and a circuit line test. Check whether the test result is normal.l If the test result is normal, go to Step 22.l If the test result is abnormal, go to Step 19.

Step 19 Rectify a fault according to the results of the loop line test and the circuit line test. Then, checkwhether the service is restored.l If the service is restored, go to Step 27.l If the service is not restored, go to Step 22.



79

Step 20 Run the board reset command to reset the service board where the fault occurs. Check whetherthe service is restored.



Step 21 Replace the service board. Check whether the service is restored.



Step 22 Use the Toolbox tool to trace H.248 signaling and select the port trace mode.

Normally, the UA5000 reports an offhook event (al/of) and the softswitch issues a dial toneevent (cg/dt) after the phone goes offhook.

NOTE

The softswitch issues a busy tone event cg/bt.

l If the UA5000 does not report the offhook event, go to Step 23.

l If the UA5000 reports the offhook event but the softswitch issues a busy tone event, thesoftswitch is faulty. In this case, contact softswitch engineers to locate the fault. Then, goto Step 27.

Step 23 Check the grounding of the device.

Check whether the grounding is proper according to the installation requirements described inthe related document (refer to Running Environment). If possible, use a ground resistance testerto test whether the grounding resistance is less than 10 ohms.

l If the grounding does not meet the requirements, ground the device again until the groundingis proper. Then, go to Step 24.

l If the grounding meets the requirements, go to Step 25.




Step 25 Run the display esl online-info and display dsp state frameid/slotid/subbid commands tocollect the information. Then, go to Step 26.


Step 27 End.

----End




80


1. Check whether the phone supports the CLIP function.2. Check whether the called party has the rights to use the CLIP function.3. Check whether the called party uses the phone properly. For example, check whether the

called party picks up the phone off the hook too quickly.4. Check whether the CLIP format supported by the UA5000 is the same as the CLIP format

supported by the phone.5. Check whether the CLIP function is supported only in a specific ringing mode.6. Check whether the grounding of the device is proper.7. Check whether the caller ID cannot be displayed if the phone is connected to a splitter and

whether the caller ID can be displayed normally if the phone is directly connected to theUA5000.

8. Check whether the subscriber line is too long.


Procedure

Step 1 Check whether the phone supports the CLIP function.l If the phone supports the CLIP function, go to Step 3.l If the phone does not support the CLIP function, go to Step 2.

Step 2 Replace the phone with a phone that supports the CLIP function. Perform a test to check whetherthe service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 3.

Step 3 Check on the softswitch whether the called party has the rights to use the CLIP function.l If the called party has the rights to use the CLIP function, go to Step 4.l If the called party does not have the rights to use the CLIP function, notify the called party

that the CLIP service is not provided. Then, go to Step 17.

Step 4 Pick up the phone off the hook after the phone rings four or five times. Then, check whether theservice is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 5.

Step 5 In ESL user mode, run the display pstnport clip command to check whether the CLIP formatsupported by the UA5000 is the same as the CLIP format supported by the phone.l If the CLIP formats are the same, go to Step 7.l If the CLIP formats are different, go to Step 6.



81

Step 6 Run the pstnport clip set command to change the CLIP format supported by the UA5000 sothat the CLIP format supported by the UA5000 is the same as the CLIP format supported by thephone. Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 7.

Step 7 In MG interface mode, run the display mg-ringmode attribute command to check whether theringing mode configured on the UA5000 meets carrier requirements.l If the ringing mode meets carrier requirements, go to Step 9.l If the ringing mode does not meet carrier requirements, go to Step 8.

Step 8 Run the mg-ringmode modify command to change the ringing mode on the UA5000. Then,check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 9.

Step 9 Check whether the phone that cannot display the caller ID normally is connected to a splitter.l If the phone is connected to a splitter, go to Step 10.l If the phone is not connected to any splitters, go to Step 12.

Step 10 Connect the phone that cannot display the caller ID normally to the MDF of the UA5000. Then,check whether the service is restored.l If the service is restored, go to Step 11.l If the service is not restored, go to Step 12.

Step 11 In ESL user mode, run the pstnport electric set command to change the impedance of the userport. Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 12.

NOTE

You can change the impedance of the user port by referring to the settings of other normal ports or accordingto the empirical value. If no reference value is available, change the impedance several times to differentvalues within the impedance range to see whether the service is restored.

Step 12 Check whether the subscriber line is too long. Generally, the subscriber line is less than 5 km.l If the subscriber line is too long, go to Step 13.l If the length of the subscriber line is proper, go to Step 14.

Step 13 Run the pstnport attribute set frameid/slotid/portid voicegain voicegain command to increasethe gain of the user port on the UA5000. Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 14.

Step 14 Check whether the grounding is proper according to the installation requirements described inthe corresponding document (refer to Running Environment). If it is possible, use a groundresistance tester to test whether the grounding resistance is less than 10 ohms.l If the grounding does not meet the requirements, ground the device again until the

grounding is proper. Then, go to Step 15.l If the grounding meets the requirements, go to Step 16.



82



Step 17 End.

----End

5.5 One-Way Audio or No Audio OccursThis topic describes how to troubleshoot a fault when one-way audio or no audio occurs. Whena one-way audio fault occurs, the phone of the called party can ring normally but only one partycan hear the voice of the peer party after the called party goes offhook. When a no audio faultoccurs, the phone of the called party can ring normally, but neither the calling party nor thecalled party can hear the voice of the peer party after the called party goes offhook.


1. Check whether the network between the UA5000 and the peer access gateway (AG),integrated access device (IAD) or trunk gateway (TG) is normal.

2. Check whether the phone is working normally.3. Check whether the uplink port on the standby control board is shut down. (Check this item

only in the scenario where the data is transmitted upstream over a single physical linkthrough a combo connector adapter.)


Procedure

Step 1 Run the ping command to ping the peer gateway (AG, IAD, or TG) from the UA5000 on whichthe fault occurs.l If pinging the peer gateway fails or a great number of packets are lost, go to Step 2.l If pinging the peer gateway is successful and no packet loss occurs, go to Step 3.

Step 2 Check whether the network between the UA5000 and the peer gateway is normal and whethera transmission device is normal. If there are some faults on the network or devices, rectify thefaults and ensure that pinging the peer gateway from the UA5000 is successful and that no seriouspacket loss occurs. Then, check whether the service is restored.l If the service is restored, go to Step 8.l If the service is not restored, go to Step 3.



83

Step 3 Replace the phone. Check whether the service is restored.l If the service is restored, go to Step 8.l If the service is not restored, go to Step 4.

Step 4 Check whether the UA5000 on which the fault occurs transmits data upstream over a singlephysical link through a combo connector adapter.l If the UA5000 transmits data upstream over a single physical link through a combo

connector adapter, go to Step 5.l If the UA5000 does not transmit data upstream over a single physical link through a combo

connector adapter, go to Step 6.

Step 5 Run the uplink tps off command to shut down the uplink port on the standby control board.Check whether the service is restored.l If the service is restored, go to Step 8.l If the service is not restored, go to Step 6.

Step 6 Use the Toolbox to trace the H.248 signaling (select the port trace mode) from the time thecalling party goes offhook to the time the called party goes offhook on both the local and peerdevices. Save the signaling tracing result. Then, go to Step 7.


Step 8 End.

----End



1. Check whether a calling line identification presentation (CLIP) signal interferes with thefault.

2. Check whether the DSP gain and the PSTN port gain of the UA5000 are properly set.3. Check whether the comfort noise power of the UA5000 is too great.4. Check whether the phone is working normally.5. Check whether the loop line is normal.6. Check whether an interference source exists.




84

Procedure

Step 1 Check whether the affected user is provided with the CLIP function.l If the user is provided with the CLIP function, go to Step 2.l If the user is not provided with the CLIP function, go to Step 6.

Step 2 Call the affected user and pick up the phone off the hook after the caller ID is displayed. Then,check whether the noise exists.l If the noise exists, go to Step 3.l If the noise does not exist, a CLIP signal interferes with the fault. To prevent the noise,

pick up the phone off the hook after the caller ID is displayed on the phone. Go to Step12.

Step 3 Replace the phone. Then, check whether the service is restored.l If the service is restored, go to Step 12.l If the service is not restored, go to Step 4.




Step 6 Check whether the noise is generated at the local end or at the peer end.l If the noise is generated at the local end, go to Step 7.l If the noise is generated at the peer end, go to Step 8.

Step 7 In global config mode, run the dsp attribute command to reduce the output gain of the DSPchip. In ESL user mode, run the pstnport attribute set command to reduce the voice gain ofthe PSTN port. Then, check whether the service is restored.

Set the gain according to the empirical value. If no empirical value is available, change the gainseveral times to different values within the gain range (from small to large) to see whether thefault is rectified when the gain is changed.


Step 8 In global config mode, run the dsp attribute command to reduce the input gain of the DSP chip.In ESL user mode, run the pstnport attribute set command to reduce the voice gain of thePSTN port. Then, check whether the service is restored.





85


Step 9 In global config mode, run the oversea parameters command to reduce the comfort noise power.(Specifically, set overseas parameter 34 again). Then, check whether the service is restored.

Set the comfort noise power according to the empirical value. If no empirical value is available,change the comfort noise power several times to different values within the value range (fromsmall to large) to see whether the noise can be eliminated when the comfort noise power ischanged.


Step 10 Check whether a strong interference source, such as a wireless base station or a high-frequencyswitch power system, exists around the UA5000 or the user.l If a strong interference source exists around the UA5000 or the user, the noise is caused

by the interference source. Contact associated departments to rectify the fault. Then, go toStep 12.

l If no strong interference source exists around the UA5000 or the user, go to Step 11.


Step 12 End.

----End

5.7 Echo ExistsThis topic describes how to troubleshoot a fault when there is echo during normalcommunication.


1. Check whether the echo is the acoustic echo caused by a phone.2. Check whether the transmit gain of the PSTN port is too great.3. Check whether the input gain (PCM > IP) of the DSP chip is too great.4. Check whether the echo cancellation (EC) function is enabled on the peer device during

the conversation.


Procedure

Step 1 Check whether the fault occurs on some ports or occurs on all the ports on the entire UA5000.



86

l If the fault occurs on some ports, go to Step 2.l If the fault occurs on all the ports on the entire UA5000, go to Step 5.

Step 2 During the conversation, cover the phone transmitter at the peer end where the echo occurs.Then, check whether the echo disappears.l If the echo disappears, the peer phone is faulty. Then, go to Step 3.l If the echo persists, go to Step 4.

Step 3 Replace the phone to check whether the echo disappears.l If the echo disappears, go to Step 12.l If the echo persists, go to Step 4.

Step 4 Run the pstnport attribute set command to reduce the voice gain of the PSTN port where thefault occurs. Then, check whether the service is restored.



Step 5 Run the dsp attribute command to reduce the input gain of the DSP chip. Then, check whetherthe service is restored.



Step 6 Check whether the peer device is a UA5000.l If the peer device is a UA5000, go to Step 7.l If the peer device is not a UA5000, contact maintenance engineers of the peer device to

locate the fault. Then, go to Step 12.

Step 7 During the conversation of the affected user, run the display esl online-info all command inglobal config mode of the peer device to check whether the EC function of the peer device isenabled. Specifically, check whether EC is On.l If EC is On, go to Step 11.l If EC is Off, go to Step 8.

Step 8 Use the Toolbox tool to trace H.248 signaling and select the port trace mode to trace the signalingfrom the called party.

Normally, EC in the signaling issued by the softswitch for enabling a channel is ON (tdmc/ec=ON).

l If EC in the signaling issued by the softswitch for enabling the channel is ON, go to Step11.

l If EC in the signaling issued by the softswitch for enabling the channel is not ON, go toStep 9.



87

Step 9 Run the display dsp attribute command to check whether the EC function is enabled.Specifically, check whether DSP echo check is Open in the query result.l If DSP echo check is Open, go to Step 11.l If DSP echo check is not Open, go to Step 10.

Step 10 Run the dsp attribute echoflag command to enable the EC function. Then, check whether theservice is restored.l If the service is restored, go to Step 12.l If the service is not restored, go to Step 11.


Step 12 End.

----End



88

6 Troubleshooting VoIP ISDN BRA ServiceFaults

About This Chapter

This topic describes how to troubleshoot common VoIP ISDN BRA service faults, such as afailure to log in to a console and a video phone service fault. VoIP is the acronym for voice overIP. ISDN is the acronym for integrated services digital network. BRA is the acronym for basicrate access.

6.1 Failure to Log In to a ConsoleThis topic describes how to troubleshoot a failure to log in to a console.

6.2 Video Phone Service Is FaultyThis topic describes how to troubleshoot a fault when the video phone service is faulty. Thevideo phone service fault includes image freeze and voice without image.

UA5000 Universal Access UnitTroubleshooting 6 Troubleshooting VoIP ISDN BRA Service Faults


89

6.1 Failure to Log In to a ConsoleThis topic describes how to troubleshoot a failure to log in to a console.


1. Check whether the data configuration of the console is correct.2. Check whether the service board where the fault occurs is normal.3. Check whether the port where the fault occurs is normal.4. Check whether cables are connected properly.5. Check whether the CTX card is normal.6. Check whether the grounding of the device is proper.7. Check whether an interference source exists.


Procedure

Step 1 Check whether the data configuration of the console is correct.

The service data of the console refers to the ISDN BRA service data. Check whether the dataconfiguration of the access gateway (AG) is the same as the data configuration of the softswitch.

l If the data configuration of the console is correct, go to Step 3.l If the data configuration of the console is incorrect, go to Step 2.

Step 2 Modify the data configuration. Then, check whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 3.

Step 3 Run the display board frameid/slotid command to query the status of the affected service board.l If the service board is in normal, go to Step 5.l If the service board is abnormal, go to Step 4.

Step 4 Replace the board. Ensure that the board is normal. Then, check whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 5.

Step 5 Directly connect an ISDN phone to the ISDN port that is connected to the console. After pickingup the phone off the hook, run the display port state frameid/slotid/portid command to querythe port status.l If the port is in the Active state, go to Step 7.



90

l If the port is not in the Active state, connect the ISDN phone to another port and performthe test until the port is in the Active state. Then, go to Step 6.

Step 6 Connect the cable to the console properly. Then, attempt to log in to the console again.l If the login is successful, go to Step 13.l If the login fails, go to Step 7.

Step 7 Observe the indicator status of the CTX card during the login to the console.l If the indicator blinks quickly, go to Step 8.l If the indicator blinks slowly (on for 1s and off for 1s repeatedly), go to Step 11.

Step 8 Check whether the UA5000 subrack, the PC that has the console installed, or the grounding ofthe power source is proper. If necessary, check whether the grounding resistance is normal.l If the grounding is proper, go to Step 10.l If the grounding is improper, ground the device again until the grounding is proper. Then,

go to Step 9.


Step 10 Check whether a strong interference source, such as a wireless base station or a high-frequencyswitch power system, exists around the UA5000 or the user.l If a strong interference source exists around the UA5000 or the user, the fault is caused by

the interference source. Contact associated departments to rectify the fault. Then, go toStep 13.


Step 11 Replace the CTX card. Then, check whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 12.


Step 13 End.

----End

6.2 Video Phone Service Is FaultyThis topic describes how to troubleshoot a fault when the video phone service is faulty. Thevideo phone service fault includes image freeze and voice without image.


1. Check network quality. Specifically, check whether packet loss occurs on the network.2. Check whether the preset delay is too great.



91

3. Check whether the softswitch and the UMG use the clearmode codec mode.4. Check whether the grounding of the UA5000 is proper.5. Check whether the clock source is correctly configured.6. Check whether the NT1 is faulty.7. Check whether the two video terminals that communicate with each other use the same

codec mode.


Procedure

Step 1 Run the ping command to ping the IP address of the softswitch.l If the IP address of the softswitch cannot be pinged or packet loss occurs, go to Step 2.l If the IP address of the softswitch can be pinged and no packet loss occurs, go to Step 3.

Step 2 Check whether the route configuration, network connection, and transmission devices betweenthe UA5000 and the softswitch are correct and normal. If there are faults, rectify the faults andensure that the softswitch can be pinged and no packet loss occurs. Then, check whether theservice is restored.l If the service is restored, go to Step 15.l If the service is not restored, go to Step 3.

Step 3 Run the dsp attribute max-fixed-jb command to reduce the maximum fixed jitter buffer of theDSP channel. Then, check whether the service is restored.

Set the jitter buffer according to the empirical value. If no empirical value is available, changethe jitter buffer several times to different values within the value range (from small to large) tosee whether the fault is rectified when the jitter buffer is changed.


Step 4 Reduce the packetization duration on the softswitch side. Then, check whether the service canbe restored.

Set the packetization duration according to the empirical value. If no empirical value is available,change the packetization duration several times to different values within the value range (fromsmall to large) to see whether the fault is rectified when the packetization duration is changed.


Step 5 Set the codec mode of the softswitch and the UMG to clearmode. Then, check whether the serviceis restored.l If the service is restored, go to Step 15.l If the service is not restored, go to Step 6.



92

Step 6 Check whether the UA5000 subrack is grounded proper by referring to grounding requirementsdescribed in Running Environment.l If the grounding is proper, go to Step 8.l If the grounding is improper, ground the device again until the grounding is proper. Then,

go to Step 7.


Step 8 Check whether the two video terminals that communicate with each other are connected to thesame device.l If they are connected to the same device, go to Step 10.l If they are not connected to the same device, go to Step 9.

Step 9 Ensure that both the terminals access the TDM clock. Then, check whether the service is restored.l If the service is restored, go to Step 15.l If the service is not restored, go to Step 10.

NOTE

If the video terminals are connected to the same UA5000, connect the E1 cable from the PVM board ofthe UA5000 to the UMG, and run the clock source and clock priority commands to configure the clocksource.

Step 10 Replace the NT1 to perform the test. Check whether the service is restored.l If the service is restored, go to Step 15.l If the service is not restored, go to Step 11.

Step 11 Check whether the two video terminals that communicate with each other use the same codecmode.l If they use the same codec mode, go to Step 14.l If they use different codec modes, change the codec modes so that they are the same. Then,

go to Step 12.


Step 13 Capture packets. Then, go to Step 14.


Step 15 End.

----End



93

7 Troubleshooting V5 PSTN TelephoneService Faults

About This Chapter

This topic describes how to troubleshoot common V5 PSTN telephone service faults, such asno power feed after offhook, no tone after offhook, and busy tone after offhook. PSTN is theacronym for public switched telephone network.


7.2 No Tone Is Played After OffhookThis topic describes how to troubleshoot a fault when no tone is played after offhook the callingparty picks up the phone off the hook.


7.4 The Phone of the Called Party Does Not RingThis topic describes how to troubleshoot a fault when the phone of the called party does not ring.When this fault occurs, the phone of the called party does not ring after the called party is called.The called party, however, can still communicate with the calling party after offhook.

7.5 The Ringing Does Not Meet RequirementsThis topic describes how to troubleshoot a fault when the ringing mode of a phone does not meetuser requirements.


7.7 There Is Noise During Communication

UA5000 Universal Access UnitTroubleshooting 7 Troubleshooting V5 PSTN Telephone Service Faults


94

This topic describes how to troubleshoot a fault when there is noise during normalcommunication.



95





2. Check whether the phone is working normally.3. Check whether the loop line and circuit line are normal.4. Check whether the service boards are working normally.5. Check whether the power board is working normally.


Procedure


Step 2 Replace the phone to test whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 3.



Step 4 Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 5.

Step 5 Perform a circuit line test in the onhook state.



96

l If the test result (shown in Off-hook) is Normal, go to Step 8.l If the test result (shown in Off-hook) is not Normal, go to Step 6.

Step 6 Use another port on the same board to test whether the fault can be rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 7.

Step 7 Replace the board to test whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 8.

Step 8 Check whether the secondary power board is working normally. For example, check the VIN(RUN) indicator on the secondary power board. If the indicator is on for 1s and off for 1srepeatedly, the secondary power board is working normally.l If the secondary power board is working normally, go to Step 10.l If the secondary power board is not working normally, go to Step 9.

Step 9 Verify that the POWER switch of the secondary power board is turned on, and check the powersupply device. If necessary, replace the power board by referring to Replacing the SecondaryPower Board to ensure that the power supply device provides power normally. Then, checkwhether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 10.


Step 11 End.

----End

7.2 No Tone Is Played After OffhookThis topic describes how to troubleshoot a fault when no tone is played after offhook the callingparty picks up the phone off the hook.


1. Check whether there is power feed after offhook. Specifically, check whether the phonein-use indicator is on after offhook.

2. Identify the fault scope. Specifically, check whether the fault occurs on some ports, all theports on some boards, or all the ports on the entire UA5000.

3. Check whether the data configuration of the port on the UA5000 is the same as the dataconfiguration of the port on the softswitch.

4. Check whether the phone is working normally.5. Check whether signaling interaction is normal.6. Check whether the port is in the Busy state after offhook.



97

7. Check whether the loop line is normal.8. Check whether the V5 interface connected to the affected user is normal.9. Check whether the device hardware and the surrounding environment are normal.


Procedure

Step 1 Ask the user to pick up the phone off the hook. Check whether the phone in-use indicator is on.l If the phone in-use indicator is on, go to Step 2.l If the phone in-use indicator is not on, rectify the fault by referring to 7.1 There Is No

Power Feed After Offhook.


Step 3 Check whether the data configuration of the port on the UA5000 is the same as the dataconfiguration of the port on the softswitch.l If the data configurations are the same, go to Step 5.l If the data configurations are different, go to Step 4.

Step 4 Modify the data configurations and ensure that they are the same. Then, check whether theservice is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 5.


Step 6 Perform a loop line test in the onhook state.l If the test result (shown in Conclusion) is Normal, go to Step 8.l If the test result is not Normal, the loop line is faulty. Go to Step 7.

Step 7 Directly connect a phone to the MDF, perform the test to check on which section of the loopline the fault occurs, and then rectify a loop line fault (for example, replace the loop line). Checkwhether the service is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 8.

Step 8 In the offhook state and global config mode, run the display port state frameid/slotid/portidcommand to query the user port status.



98

l If the user port (the result shown in State) is Busy, go to Step 9.l If the user port (the result shown in State) is not Busy, go to Step 17.

Step 9 Use the Toolbox tool to trace V5 signaling and select the port trace mode.

Normally, after the user goes offhook, the UA5000 first reports an offhook event (displayed asbold in the following information):

#@AN->LE #@User port=83 #@ESTABLISH #@Steady signal,Off hook (loop closed) #@48 01 53 00 03 01 84

Then, the softswitch responds to the UA5000 with a reply message and sends a resourceallocation message to the UA5000 (displayed as bold in the following information):

#@LE->AN #@User port=83 #@ESTABLISH ACK #@ #@48 01 53 01#@LE->AN #@BCC Reference Number=272 #@ALLOCATION #@User port identification,value =83|V5 time slot identification,V5 2M link ID=5,V5 time slot=4 #@48 04 10 20 40 02 01 53 42 02 05 04

Finally, the UA5000 responds to the softswitch with a message indicating that the resource isallocated successfully (displayed as bold in the following information):

#@AN->LE #@BCC Reference Number=272 #@ALLOCATION COMP #@ #@48 04 10 21

l If the UA5000 does not report the offhook event, go to Step 10.l If the UA5000 does not respond to the softswitch with a message indicating that the resource

is allocated successfully, go to Step 17.l If the UA5000 reports the offhook event but the softswitch does not respond or send a

resource allocation message, the softswitch is faulty. In this case, contact softswitchengineers to locate the fault. Then, go to Step 18.

Step 10 Perform a circuit line test in the onhook state.l If the test result (shown in Off-hook) is Normal, go to Step 11.l If the test result (shown in Off-hook) is not Normal, go to Step 13.

Step 11 Directly connect a phone to the MDF to perform a test.l If the dial tone is played normally, the loop line is faulty. Then, go to Step 12.l If the fault persists, go to Step 13.

Step 12 Rectify the loop line fault (for example, replace the loop line). Check whether the service isrestored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 17.

Step 13 Use another port on the same board to perform the test.l If the dial tone is played normally, go to Step 18.l If the fault persists, go to Step 14.

Step 14 Run the display user data frameid/slotid command in Narrow user mode to query the V5interface ID configured for the user. Then, run the display if-v5 state v5id command in globalconfig mode to check whether the V5 interface is working normally.l If the V5 interface is working normally, go to Step 15.l If the V5 interface is not working normally, rectify the fault by referring to Rectifying the

V5 Interface Fault.

Step 15 Replace the board and then test whether the dial tone is played.



99

l If the dial tone is played normally, go to Step 18.l If the fault persists, go to Step 16.

Step 16 Check the UA5000 hardware and the surrounding environment.1. Check the grounding of the device.

Check whether the device is grounded properly according to the installation requirementsdescribed in the related document (refer to Running Environment). If possible, use a groundresistance tester to test whether the grounding resistance is less than 10 ohms.

l If the grounding does not meet the requirements, go to Step 16.2.l If the grounding meets the requirements, go to Step 16.3.

2. Ground the device again until the grounding is proper. Check whether the service isrestored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 16.3.

3. Check whether the control board is installed properly.l If the control board is installed properly, go to Step 16.5.l If the control board is not installed properly, go to Step 16.4.

4. Install the control board properly. Check whether the service is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 16.5.

5. Check whether the subrack is normal.

Observe the top of the cabinet and the subrack. Check for leaks in the roof of the cabinet,water trails on the subrack, and evidence of vermin. Also check whether the cabinet isproperly sealed.

l If an abnormality occurs, go to Step 16.6.l If no abnormality occurs, go to Step 16.7.

6. Wipe away any water and clear away any unwanted debris. Ensure that the equipment roomis waterproof and the cabinet is properly sealed. (The cabinet keeps insects or rodents outof the cabinet.) Then, check whether the service is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 16.7.

7. Check whether cables are connected properly.

If the fault occurs on a slave or extended subrack, check whether the HW cable is connectedproperly to the HW transfer board.

l If the cables are connected properly, go to Step 16.9.l If the cables are not properly connected, go to Step 16.8.

8. Connect the cables properly, or replace the HW cable, replace the subscriber cable, replacethe HW transfer board (front-access), or replace the HW transfer board (rear-access). Then,check whether the service is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 16.9.

9. Check the -48 V power output.



100

Use a multimeter to check whether the actual output of the -48 V voltage for the subrackis in the range of -38.4 V to -60 V. Use the DC shift, namely, the 100 V shift, and performthe test on the power distribution box (PDB).

l If the -48 V voltage for the subrack is not in the specified range, go to Step 16.10.l If the -48 V voltage for the subrack is in the specified range, go to Step 17.

10. Adjust the voltage and ensure that the primary power supply is stable. Then, check whetherthe service is restored.l If the service is restored, go to Step 18.l If the service is not restored, go to Step 17.


Step 18 End.

----End



1. Check whether the board where the fault occurs is normal.2. Check whether the port is configured with data and whether the data is consistent with the

data configured on the softswitch.3. Check whether the user port where the fault occurs is normal.4. Check whether the V5 interface is normal.5. Check whether there are available digital signal processor (DSP) resources in the system.6. Check whether signaling interaction is normal.7. Check whether the loop line is normal.8. Check whether the device hardware and the surrounding environment are normal.


Procedure

Step 1 Check whether the fault occurs on some ports, occurs on all the ports on some boards, or occurson all the ports on the entire UA5000.



101

l If the fault occurs on some ports, go to Step 4.l If the fault occurs on all the ports on some boards, go to Step 2.l If the fault occurs on all the ports on the entire UA5000, go to Step 14.

Step 2 Run the display board frameid command to check whether the board where the fault occurs isin the Normal state.l If the board is in the Normal state, go to Step 4.l If the board is not in the Normal state, go to Step 3.

Step 3 Remove and then insert the board where the fault occurs. Wait for five minutes. If the board isabnormal, replace the board. Wait until the board works in the Normal state. Then, checkwhether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 4.

Step 4 In onhook state, run the display pstnport attribute frameid/slotid/portid command to checkwhether the user port is configured with data and whether the data is consistent with the dataconfigured on the softswitch.l If the data is configured and it is consistent with the data configured on the softswitch, go

to Step 6.l If the data is configured but it is inconsistent with the data configured on the softswitch,

go to Step 5.

Step 5 In ESL user mode, run the mgpstnuser add command to configure the user port data (if no datais configured), or run the mgpstnuser modify command to modify the user port data. (If thedata is inconsistent with the data configured on the softswitch, you can also run an associatedcommand to modify the data configured on the softswitch so that the data configured on thesoftswitch is consistent with the data configured on the UA5000.) Ensure that the user data ofthe UA5000 is consistent with the user data of the softswitch. Then, check whether the serviceis restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 6.

Step 6 In global config mode, run the display port state frameid/slotid/portid command to query thestatus of the user port where the fault occurs.l If the port is in the Idle state, go to Step 12.l If the port is in the Failed state, go to Step 7.l If the port is in the Testing state, go to Step 8.

Step 7 Perform the test on the port that is in the Idle state to check whether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 9.

Step 8 After the test is complete and the port status goes into the Idle state, perform the test again tocheck whether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 9.

Step 9 Run the board reset command to reset the service board where the fault occurs. Check whetherthe service is restored.



102


Step 10 Replace the service board. Check whether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 11.

Step 11 In Narrow user mode, run the display port state frameid/slotid/portid command to query theservice status of the port.l If the port is in the StartSvc state, go to Step 16.l If the port is in the LBlock state, go to Step 12.l If the port is in the AutoBlk state, go to Step 7.l If the port is in the RemoBlk state, go to Step 13.

Step 12 Run the undo endservice frameid/slotid/portid command to restart a stopped service. Checkwhether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 21.

Step 13 In Narrow user mode, run the display user data frameid/slotid command to query the V5interface ID configured for the user. Then, run the display if-v5 state v5id command in globalconfig mode to check whether the V5 interface is working normally.l If the V5 interface is working normally, go to Step 14.l If the V5 interface is not working normally, rectify the fault by referring to Rectifying the

V5 Interface Fault.

Step 14 In Narrow user mode, run the display pstnport attribute frameid/slotid/portid command tocheck whether the user data configured on the UA5000 is consistent with the user data configuredon the softswitch.l If the data on the two sides is consistent, go to Step 16.l If the data on the two sides is inconsistent, go to Step 15.

Step 15 Run the pstnuser modify to modify the data configured on the user port to ensure that the dataon the UA5000 is consistent with the data on the softswitch. In normal cases, the service statusof the user port is StartSvc. Then, pick up the phone off the hook to check whether the dial toneis played.l If the dial tone is played, go to Step 22.l If the dial tone is not played, go to Step 16.

Step 16 Perform a loop line test and a circuit line test. Then, check whether the test result is normal.l If the test result is normal, go to Step 17.l If the test result is abnormal, go to Step 18.

Step 17 Rectify the fault according to the results of the loop line and circuit line tests. Then, checkwhether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 18.

Step 18 Use the Toolbox tool to trace V5 signaling and select the port trace mode.



103

Normally, after the user goes offhook, the UA5000 first reports an offhook event (displayed asbold in the following information):

#@AN->LE #@User port=83 #@ESTABLISH #@Steady signal,Off hook (loop closed) #@48 01 53 00 03 01 84

Then, the softswitch responds to the UA5000 with a reply message and sends a resourceallocation message to the UA5000 (displayed as bold in the following information):

#@LE->AN #@User port=83 #@ESTABLISH ACK #@ #@48 01 53 01#@LE->AN #@BCC Reference Number=272 #@ALLOCATION #@User port identification,value =83|V5 time slot identification,V5 2M link ID=5,V5 time slot=4 #@48 04 10 20 40 02 01 53 42 02 05 04

Finally, the UA5000 responds to the softswitch with a message indicating that the resource isallocated successfully (displayed as bold in the following information):

#@AN->LE #@BCC Reference Number=272 #@ALLOCATION COMP #@ #@48 04 10 21

l If the UA5000 does not report the offhook event, go to Step 15.l If the UA5000 does not respond to the softswitch with a message indicating that the resource

is allocated successfully, go to Step 21.l If the UA5000 reports the offhook event but the softswitch does not respond or send a

resource allocation message, the softswitch is faulty. In this case, contact softswitchengineers to locate the fault. Then, go to Step 22.







Step 22 End.

----End

7.4 The Phone of the Called Party Does Not RingThis topic describes how to troubleshoot a fault when the phone of the called party does not ring.When this fault occurs, the phone of the called party does not ring after the called party is called.The called party, however, can still communicate with the calling party after offhook.




104


2. Check whether the phone is working normally.3. Check whether the loop line is normal.4. Check whether the service boards are working normally.5. Check whether the power board is working normally.6. Check whether the grounding of the device is proper.7. Check whether the power supply system of the device is stable.


Procedure






Step 5 Replace the board to test whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 6.

Step 6 Check whether the secondary power board is working normally. For example, check the VIN(RUN) indicator on the secondary power board. If the indicator is on for 1s and off for 1srepeatedly, the secondary power board is working normally.l If the power board is working normally, go to Step 8.l If the power board is not working normally, go to Step 7.



105

Step 7 Verify that the POWER switch of the secondary power board is turned on, and check the powersupply device. If necessary, replace the power board by referring to Replacing the SecondaryPower Board to ensure that the power supply device provides power normally. Then, checkwhether the service is restored.










Step 10 Check whether the power supply system is working stably. For example, check whether thevoltage is stable and whether the system is frequently powered off.

l If the power supply system is working stably, go to Step 12.

l If the power supply system is not working stably, go to Step 11.

Step 11 Verify that the power supply system is working stably. If the power supply system is not workingstably because of some objective causes, you can use a standby power source that can workstably, such as batteries, to provide power for the device. Then, check whether the service isrestored.




Step 13 End.

----End

7.5 The Ringing Does Not Meet RequirementsThis topic describes how to troubleshoot a fault when the ringing mode of a phone does not meetuser requirements.



1. Check whether the ringing mode configured in the system meets user requirements.



106

2. Check whether this fault has been rectified in a patch corresponding to the control boardversion.

3. Check whether the phone is working normally.4. Check whether the loop line is normal.5. Check whether the secondary power board is working normally.6. Check whether the grounding of the device is proper.7. Check whether an interference source exists.


Procedure

Step 1 Run the display ringmode attribute command to check whether the ringing mode configuredon the V5 interface to which the user port belongs meets user requirements.l If the configured ringing mode meets user requirements, go to Step 3.l If the configured ringing mode does not meet user requirements, reconfigure the ringing

mode by referring to Configuring Software Parameters of a SIP Interface. Then, go to Step2.


Step 3 Check whether this fault has been rectified in a patch corresponding to the control board version.l If the fault has been rectified in a patch, go to Step 4.l If the fault has not been rectified in any patches, go to Step 6.

Step 4 Check whether this patch is correctly loaded to the current system by referring to thecorresponding patch release notes.l If this patch is correctly loaded to the current system, go to Step 6.l If this patch is not correctly loaded to the current system, go to Step 5.

Step 5 Load, activate, and run the patch according to the instructions described in the correspondingpatch release notes. Check whether the service is restored.l If the service is restored, go to Step 16.l If the service is not restored, go to Step 6.



directly connect a phone to the MDF, perform the test to check on which section of the loop



107

line the fault occurs, and then rectify a loop line fault (for example, replace the loop line)if necessary. Then, go to Step 8.




Step 9 Check whether the secondary power board is working normally. For example, check the VIN(RUN) indicator on the secondary power board. If the indicator is on for 1s and off for 1srepeatedly, the secondary power board is working normally.

l If the secondary power board is working normally, go to Step 11.

l If the secondary power board is not working normally, go to Step 10.

Step 10 Verify that the POWER switch of the secondary power board is turned on, and check the powersupply device. If necessary, replace the power board by referring to Replacing the SecondaryPower Board to ensure that the power supply device provides power normally. Then, checkwhether the service is restored.










Step 13 Check whether a strong interference source, such as a wireless base station or a high-frequencyswitch power system, exists around the UA5000 or the user.

l If a strong interference source exists around the UA5000 or the user, the fault is caused bythe interference source. Contact associated departments to rectify the fault. Then, go toStep 16.


Step 14 Use the Toolbox tool and select the port trace mode to trace the V5 signaling transmitted in thewhole process of the communication, and save the signaling tracing result. Then, go to Step15.


Step 16 End.

----End



108



1. Check whether the phone supports the CLIP function.2. Check whether the called party has the rights to use to the CLIP service.3. Check whether the called party uses the phone correctly. For example, check whether the

called party picks up the phone off the hook too quickly.4. Check whether the loop line is normal.5. Check whether the clock locked in the system is the clock of the E1 line that is directly

connected to the softswitch.6. Check whether any alarm of the E1 line connected to the user port is generated.7. Check whether the E1 line connected to the user port is crossed with other lines.8. Check whether the grounding of the device is proper.9. Check whether an interference source exists.


Procedure

Step 1 Check whether the phone supports the CLIP function.l If the phone supports the CLIP function, go to Step 3.l If the phone does not support the CLIP function, go to Step 2.

Step 2 Replace the phone with a phone that supports the CLIP function. Perform a test to check whetherthe service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 3.

Step 3 Check on the softswitch whether the called party has the rights to use the CLIP function.l If the called party has the rights to use the CLIP function, go to Step 4.l If the called party does not have the rights to use the CLIP function, notify the called party

that the CLIP service is not provided. Then, go to Step 17.

Step 4 Pick up the phone off the hook after the phone rings four or five times. Then, check whether theservice is restored.l If the service is restored, go to Step 17.



109


Step 5 Perform a loop line test in the onhook state.l If the test conclusion (shown in Conclusion) is Normal, go to Step 7.l If the test conclusion (shown in Conclusion) is not Normal, the loop line is faulty. In this

case, directly connect a phone to the MDF, perform the test to check on which section ofthe loop line the fault occurs, and then rectify a loop line fault (for example, replace theloop line) if necessary. Then, go to Step 6.


Step 7 In global config mode, run the display clock source command to check whether the clock lockedin the system is the clock of the E1 line that is directly connected to the softswitch.l If the clock locked in the system is the E1 line clock, go to Step 9.l If the clock locked in the system is not the E1 line clock, go to Step 8.

Step 8 Reconfigure the system clock by referring to Configuring the System Clock, and ensure that thesystem clock is the clock of the E1 line that is directly connected to the softswitch. Then, checkwhether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 9.

Step 9 Run the display alarm history command to check whether the alarm records contain an alarmassociated with the E1 link connected to the affected user.l If such an alarm is generated, go to Step 10.l If such an alarm is not generated, go to Step 11.

Step 10 Clear the alarm by referring to the PVM Alarm Reference. Check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 11.

Step 11 In V5 interface mode, run the link identify command to identify the ID of the E1 link connectedto the affected user, to determine whether the E1 line is crossed with other lines.l If the link ID identification is successful, the E1 line is not crossed with other lines. Then,

go to Step 13.l If the link ID identification fails, the E1 line is crossed with other lines. Then, go to Step

12.

Step 12 Check the physical E1 line and resolve the cross-line problem (for example, the E1 line isconnected to an incorrect port on the softswitch). Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 13.

Step 13 Check whether the device is grounded properly according to the installation requirementsdescribed in the related document (refer to Running Environment). If possible, use a groundresistance tester to test whether the grounding resistance is less than 10 ohms.l If the grounding does not meet the requirements, ground the device again until the

grounding is proper. Then, go to Step 14.



110




the interference source. Contact associated departments to rectify the fault. Then, go toStep 17.



Step 17 End.

----End



1. Check whether the voice gain of the PSTN port is set properly.2. Check whether the phone is normal.3. Check whether the loop line is normal.4. Check whether the clock locked in the system is the clock of the E1 line that is directly

connected to the softswitch.5. Check whether any alarm of the E1 line connected to the user port is generated.6. Check whether the E1 line connected to the user port is crossed with other lines.7. Check whether the grounding of the device is proper.8. Check whether an interference source exists.


Procedure

Step 1 Check whether the noise exists at the local end or at the peer end.



111

l If the noise exists at the local end, go to Step 2.l If the noise exists at the peer end, go to Step 3.

Step 2 Run the pstnport attribute set command in Narrow user mode to reduce the voice gain of thePSTN port where the fault occurs. Check whether the service is restored.



Step 3 Run the pstnport attribute set command in Narrow user mode to reduce the voice gain of thepeer PSTN port. Check whether the service is restored.




Step 5 Perform a loop line test in the onhook state.l If the test conclusion (shown in Conclusion) is Normal, go to Step 7.l If the test conclusion (shown in Conclusion) is not Normal, the loop line is faulty. In this

case, directly connect a phone to the MDF, perform the test to check on which section ofthe loop line the fault occurs, and then rectify a loop line fault (for example, replace theloop line) if necessary. Then, go to Step 6.


Step 7 In global config mode, run the display clock source command to check whether the clock lockedin the system is the clock of the E1 line that is directly connected to the softswitch.l If the clock locked in the system is the clock of the E1 line that is directly connected to the

softswitch, go to Step 9.l If the clock locked in the system is not the clock of the E1 line that is directly connected

to the softswitch, go to Step 8.

Step 8 Reconfigure the system clock by referring to Configuring the System Clock, and ensure that thesystem clock is the clock of the E1 line that is directly connected to the softswitch. Then, checkwhether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 9.

Step 9 Run the display alarm history command to check whether the alarm records contain an alarmassociated with the E1 link connected to the affected user.



112

l If such an alarm is generated, go to Step 10.l If such an alarm is not generated, go to Step 11.

Step 10 Clear the alarm by referring to the PVM Alarm Reference. Check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 11.

Step 11 In V5 interface mode, run the link identify command to identify the ID of the E1 link connectedto the affected user, to determine whether the E1 line is crossed with other lines.l If the link ID identification is successful, the E1 line is not crossed with other lines. Then,

go to Step 13.l If the link ID identification fails, the E1 line is crossed with other lines. Then, go to Step

12.

Step 12 Check the physical E1 line and resolve the cross-line problem (for example, the E1 line isconnected to an incorrect port on the softswitch). Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 13.

Step 13 Check whether the device is grounded properly according to the installation requirementsdescribed in the related document (refer to Running Environment). If possible, use a groundresistance tester to test whether the grounding resistance is less than 10 ohms.l If the grounding does not meet the requirements, ground the device again until the

grounding is proper. Then, go to Step 14.l If the grounding meets the requirements, go to Step 15.



the interference source. Contact associated departments to resolve the problem. Then, goto Step 17.



Step 17 End.

----End



113

8 Troubleshooting Fax and Modem ServiceFaults

About This Chapter

This topic describes how to troubleshoot fax and modem service faults.

8.1 Fax Service Is AbnormalThis topic describes how to troubleshoot a fault when the fax service is abnormal. For example,the fax fails, the fax is blurred, or the fax rate decreases.

8.2 Modem Service Is AbnormalThis topic describes how to troubleshoot a fault when the modem service, such as lottery andPOS services, is abnormal. The abnormality of the modem service includes a dialup Internetaccess failure and frequent Internet access offline.

UA5000 Universal Access UnitTroubleshooting 8 Troubleshooting Fax and Modem Service Faults


114

8.1 Fax Service Is AbnormalThis topic describes how to troubleshoot a fault when the fax service is abnormal. For example,the fax fails, the fax is blurred, or the fax rate decreases.

Fault Location ProcedureThe fax over IP (FoIP) service has strict requirements on the quality of a next generation network(NGN) bearer network, working of a terminal, and compatibility between the UA5000 and amedia gateway controller (MGC). Therefore, the FoIP service problems frequently occur on theexisting network.


1. Check whether the user operates the fax machine according to the related instructions andwhether the fax machine is normal.

2. Check whether the data configuration on the UA5000 and the MGC is correct.3. Check whether the quality of the bearer network meets fax service requirements.4. Check whether signaling interaction between the UA5000 and the MGC is normal.5. Check whether the phone line is normal.


Procedure

Step 1 Check whether the user operates the fax machine according to the related instructions andwhether the fax machine is normal.l If the user operates the fax machine properly and the fax machine is normal, go to Step

3.l If the user does not operate the fax machine properly or the fax machine is faulty, go to

Step 2.

NOTE

Fax machine operations are complex, especially some fax machines that provide multiple functions.Therefore, the operation is error-prone. If any fault occurs, check whether any of the following cases istrue:

l The user presses Start to send the fax without hearing the fax tone sent by the peer fax machine.

l No paper is ready for faxing on the peer fax machine, the fax paper is not placed properly, the printingink box runs out, the fax machine is not powered on, or some parts on the fax machine are faulty.

l The fax machine is enabled with the receive rejection function. In other words, the fax machine cansend fax only.

l The fax machine is not enabled with or does not support the automatic receive function. No manualoperation is performed for receiving fax. Therefore, the fax cannot be received.

Step 2 Rectify any fax machine fault you encounter. Perform operations according to the instructions.Then, check whether the service is restored.



115



Step 3 Run the display fax parameters and display dsp attribute commands on the local and peerUA5000s to check whether the fax parameter and fax training mode (Fax Train Mode) areconsistent with the data plan. In addition, ask MGC engineers to check whether the dataconfigurations of the MGC are consistent with the data plan.

l If the configurations are consistent with the data plan, go to Step 5.

l If the configurations are inconsistent with the data plan, run the fax parameters and dspattribute commands to change the data configurations of the UA5000, or ask MGCengineers to change the data configurations of the MGC. Ensure that the data configurationsare consistent with the data plan. Then, go to Step 4.




Step 5 Check whether the quality of the bearer network meets fax service requirements. You can usea tool to test or run the ping command on the UA5000 to ping the peer access gateway (AG).The fax service in the transparent transmission mode has strict requirements on the bearernetwork. The expected packet loss ratio of the bear network should be less than 0.5%.

l If the peer AG cannot be pinged or the packet loss ratio is great, go to Step 6.

l If the peer AG can be pinged and no packet loss occurs, go to Step 7.

Step 6 Check whether the connection between the UA5000 and the peer AG and whether transmissiondevices are normal. Rectify any fault you encounter until the peer AG can be pinged and nosevere packet loss occurs. Then, check whether the service is restored.



Step 7 Run the display fax parameters command to check whether Fax transfers mode of the affecteduser is Selfswitch thoroughly or Selfswitch T38.

l If Fax transfers mode is Selfswitch thoroughly or Selfswitch T38, go to Step 10.

l If Fax transfers mode is not Selfswitch thoroughly or Selfswitch T38, go to Step 8.

Step 8 Use the Toolbox tool to trace H.248 signaling and select the port trace mode. Then, checkwhether signaling interaction between the UA5000 and the MGC is normal.

1. Check whether the UA5000 on the receive side reports a fax event (dtt=ANS,dtt=ANSAM, dtt=ANSbar, dtt=ANSAMbar, or dtt=V21flag).

2. Check whether the MGC issues a channel switching command and correct echocancellation parameters after the UA5000 on the receive side reports the fax event.

l The signaling of the low-speed transparent transmission fax must contain tdmc/ec=ON and ctyp/calltyp=FAX.

l The signaling of the low-speed T.38 fax must contain tdmc/ec=ON and ctyp/calltyp=FAX.

l The signaling of the high-speed fax must contain tdmc/ec=OFF and ctyp/calltyp=DATA.

3. Check whether signaling interaction is normal according to the result of the preceding step.



116

l If the UA5000 on the receive side reports the fax event, and the MGC issues the channelswitching command and correct echo cancellation parameters, go to Step 10.

l If the UA5000 on the receive side does not report the fax event, go to Step 9.l If the UA5000 on the receive side reports the fax event but the MGC does not issue the

channel switching command or correct echo cancellation parameters, the MGC is faulty.Contact MGC engineers to rectify the fault. Then, go to Step 15.

Step 9 Check whether the MGC issues fax detection signaling.Specifically, check whether the MGC issues signaling that contains ctyp/dtone before the faxstarts.l If the MGC issues fax detection signaling, go to Step 10.l If the MGC does not issue fax detection signaling, the MGC is faulty. Contact MGC

engineers to rectify the fault. Then, go to Step 15.

Step 10 In the onhook state, perform a loop line test.l If the test result (shown in Conclusion) is Normal, go to Step 12.l If the test result (shown in Conclusion) is not Normal, the loop line is faulty. In this case,

directly connect a fax machine to the MDF to perform the test and determine which sectionof the loop line is faulty. Rectify any fault you encounter. For example, replace the loopline. Then, go to Step 11.


Step 12 Use another port on the same board to perform a test.l If the fax service is normal, go to Step 15.l If the fault persists, go to Step 13.

Step 13 Replace the board to perform the test.l If the fax service is normal, go to Step 15.l If the fault persists, go to Step 14.


Step 15 End.

----End

8.2 Modem Service Is AbnormalThis topic describes how to troubleshoot a fault when the modem service, such as lottery andPOS services, is abnormal. The abnormality of the modem service includes a dialup Internetaccess failure and frequent Internet access offline.

Fault Location ProcedureThe modem over IP (MoIP) service has strict requirements on the quality of a next generationnetwork (NGN) bearer network, working of a terminal, and compatibility between the



117

UA5000 and a media gateway controller (MGC). Therefore, the FoIP service problemsfrequently occur on the existing network.


1. Check whether the phone call service for the affected user is normal.2. Check whether the modem configuration is correct.3. Check whether the data configuration on the UA5000 and the MGC is correct.4. Check whether the quality of the bearer network meets modem service requirements.5. Check whether signaling interaction between the UA5000 and the MGC is normal.


Procedure

Step 1 Replace the calling party modem and the called party modem with phones. Make phone calls tocheck whether the communication is normal.l If the communication is normal, go to Step 2.l If the communication is abnormal, see 5 Troubleshooting VoIP PSTN Service Faults.

Step 2 Connect the called party modem properly, and use the calling party phone to call the called partymodem. Check whether the modem tone is played after the call is connected.l If the modem tone is played, go to Step 4.l If the modem tone is not played, the called party modem cannot start the modem service

automatically. In this case, check the configurations of the called party modem and ensurethat the modem can start the modem service automatically. Then, go to Step 3.


Step 4 Run the display modem parameters command on the UA5000s on the local and peer sides tocheck whether the modem configurations are consistent with the data plan. In addition, ask MGCengineers to check whether the data configurations of the MGC are consistent with the data plan.l If the configurations are consistent with the data plan, go to Step 6.l If the configurations are inconsistent with the data plan, run the modem parameters

command to change the data configurations of the UA5000, or contact MGC engineers tochange the data configurations of the MGC. Ensure that the data configurations areconsistent with the data plan. Then, go to Step 5.


Step 6 Check whether the quality of the bearer network meets modem service requirements. You canuse a tool to test or run the ping command on the UA5000 to ping the peer access gateway (AG).



118

The modem service has strict requirements on the bearer network. The expected packet loss ratioof the bear network should be less than 0.5%.l If the peer AG cannot be pinged or the packet loss ratio is great, go to Step 7.l If the peer AG can be pinged and no packet loss occurs, go to Step 8.

Step 7 Check whether the network connection between the UA5000 and the peer AG is normal andwhether transmission devices are normal. Rectify any fault you encounter until the peer AG canbe pinged and no severe packet loss occurs. Then, check whether the service is restored.l If the service is restored, go to Step 12.l If the service is not restored, go to Step 8.

Step 8 Use the Toolbox tool to trace H.248 signaling and select the port trace mode. Then, checkwhether signaling interaction between the UA5000 and the MGC is normal.1. Check whether the UA5000 on the receive side reports a modem event (dtt=ANS,

dtt=ANSAM, dtt=ANSbar, or dtt=ANSAMbar).2. Check whether the MGC issues a channel switching command and correct echo

cancellation parameters after the UA5000 on the receive side reports the modem event.l The signaling of the low-speed modem must contain tdmc/ec=ON and ctyp/

calltyp=DATA.l The signaling of the high-speed modem must contain tdmc/ec=OFF and ctyp/

calltyp=DATA.3. Check whether signaling interaction is normal according to the result of the preceding step.

l If the UA5000 on the receive side reports the modem event, and the MGC issues thechannel switching command and correct echo cancellation parameters, go to Step 10.

l If the UA5000 on the receive side does not report the modem event, go to Step 9.l If the UA5000 on the receive side reports the modem event but the MGC does not issue

the channel switching command or correct echo cancellation parameters, the MGC isfaulty. In this case, contact MGC engineers to rectify the fault. Then, go to Step 12.

Step 9 Check whether the MGC issues modem detection signaling.Specifically, check whether the MGC issues signaling that contains ctyp/dtone before the datatransmission starts.l If the MGC issues modem detection signaling, go to Step 10.l If the MGC does not issue modem detection signaling, the MGC is faulty. In this case,

contact MGC engineers to rectify the fault. Then, go to Step 12.

Step 10 Run the dsp attribute command on the UA5000 to change the initial fixed jitter buffer (nominal-fixed-jb parameter) value of the DSP channel to the value that is double of the packetizationduration (which can be queried on the MGC). Then, check whether the service is restored.l If the service is restored, go to Step 12.l If the service is not restored, go to Step 11.


Step 12 End.

----End



119

9 Troubleshooting TDM G.SHDSL ServiceFaults

This topic describes how to troubleshoot TDM G.SHDSL service faults. TDM is the acronymfor time division multiplexing. SHDSL is the acronym for single-pair high-speed digitalsubscriber line.


1. Check whether the hardware of the affected service board is faulty.2. Check whether the in-use E1 cable matches the E1 port.3. Check whether the E1 cable is connected properly. Specifically, check whether the

sequence of the receive and transmit wires is correct.4. Check whether a clock source is locked on the service board.5. Check whether the clock source locked on the service board is reliable.6. Check whether the data configuration is correct.7. Check whether a terminal, such as a modem, connected to the line is working properly.8. Check whether the data configuration of the terminal is correct.


ProcedureStep 1 Replace the service board. Check whether the service is restored.


Step 2 Check the settings of the dual in-line package (DIP) switch or jumpers on the board and querythe impedance of the E1 port. (For details about the impedance configuration on the SDLE board,see SDLE Board). Then, check whether the in-use E1 cable matches the E1 port.

UA5000 Universal Access UnitTroubleshooting 9 Troubleshooting TDM G.SHDSL Service Faults


120

l If the E1 cable matches the E1 port, go to Step 4.l If the E1 cable does not match the E1 port, go to Step 3.

Step 3 Change the impedance of the E1 port or replace the E1 cable based on site requirements. Then,check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 4.

Step 4 Check whether the E1 cable is connected properly. Specifically, check whether the sequence ofthe receive and transmit wires is correct. (For details about the wire sequences of a 75-ohm E1cable and a 120-ohm E1 cable, see 75-ohm E1 Cable from SDLE to DDF and 120-ohm E1 Cablefrom SDLE to DDF.)l If the E1 cable is connected properly, go to Step 6.l If the E1 cable is not connected properly, go to Step 5.

Step 5 Connect the E1 cable properly to ensure that the sequence of the receive and transmit wires iscorrect. Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 6.

Step 6 Run the display clock state command in SDL mode to check whether a clock source is lockedon the service board.l If a clock source is locked on the service board, go to Step 8.l If a clock source is not locked on the service board, go to Step 7.

Step 7 Run the clock source command to configure a reliable clock source for the service board. Then,check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 12.

Step 8 Use a meter, such as an oscilloscope, to check whether the clock source locked on the serviceboard is reliable.l If the clock source is reliable, go to Step 10.l If the clock source is unreliable, go to Step 9.

Step 9 Run the clock source command to configure a reliable clock source for the service board, suchas the clock source locked in the normal TDM service. Then, check whether the service isrestored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 10.

Step 10 Check whether the service data configuration is correct by referring to Configuring the TDMG.SHDSL Service.l If the service data configuration is correct, go to Step 12.l If the service data configuration is incorrect, go to Step 11.

Step 11 Correct the service data configuration by referring to Configuring the TDM G.SHDSL Service.Then, check whether the service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 12.



121

Step 12 Check whether the terminal on the line is working normally.l If the terminal is working normally, go to Step 14.l If the terminal is not working normally, go to Step 13.

Step 13 Maintain the faulty terminal to ensure that the device is working normally. Then, check whetherthe service is restored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 14.

Step 14 Check whether the data configuration of the terminal is correct.l If the data configuration is correct, go to Step 16.l If the data configuration is incorrect, go to Step 15.

Step 15 Modify the data configuration according to the data plan. Then, check whether the service isrestored.l If the service is restored, go to Step 17.l If the service is not restored, go to Step 16.


Step 17 End.

----End



122

10 Troubleshooting Faults on Remote SlaveSubracks Cascaded in E1 Mode

This topic describes how to troubleshoot service failures on remote slave subracks, such as PV8s,RSPs, and RSUs, connected to the UA5000 by E1 cables in a cascade formation.


1. Check whether the E1 cable is connected to a remote slave subrack properly.2. Check whether the settings of the jumpers and the dual in-line package (DIP) switches on

the control board of the remote slave subrack are correct.3. Check whether the sequence of transmit (Tx) and receive (Rx) wires in the E1 cable

connected between the master and slave subracks is correct.4. Check the settings of the jumpers and DIP switches on the master subrack boards to

determine whether the impedance of the E1 ports on the boards matches the impedance ofthe connected E1 cables.

5. Check whether the remote slave subrack configuration on the UA5000 is correct.6. Check whether the upper layer transmission device is working properly.


Procedure

Step 1 Run the display alarm history command to check whether the 0x0a310078 PCM lineabnormality alarm is generated in the system.l If the alarm is generated, go to Step 2.l If the alarm is not generated, go to Step 10.

Step 2 Check whether the sequence of the Tx and Rx wires in the E1 cable connected between themaster and slave subracks is correct.


10 Troubleshooting Faults on Remote Slave SubracksCascaded in E1 Mode


123

For details about the wire sequences of a 75-ohm E1 cable and a 120-ohm E1 cable, see 75-ohmE1 Cable from SDLE to DDF and 120-ohm E1 Cable from SDLE to DDF.

l If the wire sequence is correct, go to Step 4.l If the wire sequence is incorrect, go to Step 3.

Step 3 Ensure that the Tx and Rx wire sequence of the E1 cable is correct. Then, check whether theservice is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 4.

Step 4 Check whether the E1 cable is connected to the remote slave subrack correctly.l If the E1 cable is connected correctly, go to Step 6.l If the E1 cable is not connected correctly, go to Step 5.

Step 5 Reconnect the E1 cable to the remote slave subrack correctly. Then, check whether the serviceis restored.

NOTE

The E1 cable connections on the PV8 board and RSP board are as follows:

l The E1 cable on the PV8 board must be connected to pin rows 17-24 or pin rows 25–32 on the upperheader.

l The E1 cable on the RSP board must be connected to pin rows 17-24 or pin rows 25–32 on the upperheader and all DIP switches on the board panel must be set to OFF.


Step 6 Check the settings of the jumpers on the master subrack boards to determine whether theimpedance of the E1 ports on the boards matches the impedance of the connected E1 cables.

For the jumper settings of the PVMB board, see PVMB Board. For the jumper settings of thePVMD board, see PVMD Board. For the jumper settings of the EDTB board, see EDTB Board.

l If the impedances matches, go to Step 8.l If the impedances do not match, go to Step 7.

Step 7 Change the impedance of the E1 port or replace the E1 cable as needed. Then, check whetherthe service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 8.

Step 8 Check the settings of the jumpers and the DIP switch on the control board of the remote slavesubrack to determine whether the impedance of the E1 ports on the board is correct.l If the settings are correct, go to Step 10.l If the settings are incorrect, go to Step 9.

Step 9 Reset the jumpers and the DIP switches on the control board of the remote slave subrack so thatthe impedance of the E1 ports on the board is correct. Then, check whether the service is restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 10.

Step 10 Check whether the data configuration on the UA5000 is correct.




124

1. Run the display port stateframeid/slotid command to check whether the E1 port is normal.l If the E1 port is normal, go to Step 10.3.l If the E1 port is faulty, go to Step 12. If the E1 port is in a loopback operation, go to

Step 10.2.2. Cancel the loopback on the E1 port and check whether the service is restored.

For EDTB boards, run the undo loopback portid command in EDT mode to cancel theloopback operation. For PVMB or PVMD boards, run the undo port loopback portidcommand in PVM mode to cancel the loopback operation.


3. Run the display frame info and display frame link commands to check whether the dataconfiguration of the slave subrack is correct.l If the data configuration is correct, go to Step 11.l If the data configuration is incorrect, go to Step 10.4.

4. Configure the data for the slave subrack and check whether the service is restored.

NOTE

Use the following guidelines to configure the data for the slave subrack.

l Run the undo frame link command to delete the incorrectly configured link between the masterand slave subracks, and run the frame delete command to delete the incorrectly configured slavesubrack.

l Run the frame add command to add a new slave subrack, and run the frame link command toadd a new link between the master and slave subracks.

l Run the board confirm frameid command to confirm the added slave subrack.


Step 11 Ensure that the upper layer transmission device is working properly. Check whether the serviceis restored.l If the service is restored, go to Step 13.l If the service is not restored, go to Step 12.


Step 13 End.

----End




125

11 Troubleshooting Private Network andData Service Faults

About This Chapter

This topic describes how to troubleshoot faults that may occur in the party line service, sub-rate(SRX) service, and DDU2 synchronous 64 kbit/s data service.

11.1 Troubleshooting Party Line Service FaultsThis topic describes how to troubleshoot party line service faults.

11.2 Troubleshooting SRX Service FaultsThis topic describes how to troubleshoot SRX service faults.

11.3 Troubleshooting DDU2 Synchronous 64 kbit/s Data Service FaultsThis topic describes how to troubleshoot DDU2 synchronous 64 kbit/s data service faults.

UA5000 Universal Access UnitTroubleshooting 11 Troubleshooting Private Network and Data Service Faults


126

11.1 Troubleshooting Party Line Service FaultsThis topic describes how to troubleshoot party line service faults.



1. Determine the fault scope.2. Check whether the VFB board is normal.3. Check whether data configuration is correct.4. Check whether the port is working normally.5. Check whether the loop line is normal.6. Check whether the data terminal is normal.7. Check whether the DSP daughter board is normal.


Procedure

Step 1 Check whether the fault occurs on some ports or occurs on all the party line user ports of theentire UA5000.l If the fault occurs on some ports, go to Step 12.l If the fault occurs on all the party line user ports of the entire UA5000, go to Step 2.

Step 2 Run the display board frameid command to check whether the affected board is normal.l If the board is normal, go to Step 4.l If the board is not normal, go to Step 3.

Step 3 Remove and then insert the affected board. If the service board is still not in the Normal state,replace the board. Wait until the board is working normally. Then, perform the test again tocheck whether the service is restored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 4.

Step 4 Run the display spc connectid connectid command to check whether the port is configured withthe party line service. (Specifically, check whether the semi-permanent connection (SPC) typeof the port is conf-spc.)l If the port is configured with the party line service, go to Step 6.l If the port is not configured with the party line service, run the spc add command to

configure the party line service data on the port. Then, go to Step 5.



127


Step 6 Run the display port state frameid/slotid/portid command to check port status.l If the port is in the BUSY state, go to Step 7.l If the port is in the FAULT state, go to Step 9.

Step 7 Check whether the data configuration of the party line service is correct. For a network thatinvolves a single network element (NE), run the display spc confer-Group command to checkwhether the party line group IDs that are configured on all the VFB user ports under the involvedparty line group are the same. For a network that comprises multiple NEs, run the display spcframeid/slotid/portid command to check whether the timeslot IDs (channel IDs) of twointerconnected E1 ports are the same, and check whether cable connection between the partyline group members is correct.l If the data configuration is correct, go to Step 10.l If the data configuration is incorrect, go to Step 8.

Step 8 Run the spc modify command to modify the data configuration to ensure that the dataconfiguration of the party line service is correct. For a network that comprises multiple NEs,verify that cable connection between the party line group members is correct. Then, checkwhether the service is restored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 10.

Step 9 Replacing the Service Board. Check whether the service is restored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 10.


Check whether the device is grounded properly according to the installation requirementdescribed in the related document (refer to Running Environment). If it is possible, use a groundresistance tester to test whether the grounding resistance is less than 10 ohms.

l If the grounding does not meet requirements, ground the device again until the grounding isproper. Then, go to Step 11.

l If the grounding meets requirements, go to Step 12.


Step 12 Check whether the loop line is connected correctly. Specifically, check whether the loop line isbroken or short-circuited.l If the loop line is connected correctly and is working properly, go to Step 14.l If the loop line is connected incorrectly or the line is faulty, connect the loop line properly

or rectify the fault. Replace the loop line if necessary. Then, go to Step 13.




128


Step 14 Check whether the data terminal is normal.l If the data terminal is normal, go to Step 16.l If the data terminal is abnormal, contact terminal maintenance personnel to rectify the fault.

Then, go to Step 15.


Step 16 Run the display board frameid command to check whether the DSP daughter board configuredfor the control board is the H602ETCA, H602ETCB, or H602ETCC board.l If the DSP daughter board is the H602ETCA, H602ETCB, or H602ETCC board, go to

Step 18.l If the DSP daughter board is not the H602ETCA, H602ETCB, or H602ETCC board, go to

Step 17.

Step 17 Replace the daughter board to ensure that the DSP daughter board configured for the controlboard is the H602ETCA, H602ETCB, or H602ETCC board. Then, check whether the service isrestored.l If the service is restored, go to Step 19.l If the service is not restored, go to Step 18.

CAUTIONBefore you replacing the DSP daughter board, the control board must be removed and serviceswill be interrupted temporarily. Therefore, save data before replacing the daughter board andexercise caution when replacing the daughter board.


Step 19 End.

----End

11.2 Troubleshooting SRX Service FaultsThis topic describes how to troubleshoot SRX service faults.


1. Determine the fault scope.2. Check whether the SRX board is normal.3. Check whether data configuration is correct.



129

4. Check whether the port is working normally.5. Check whether the loop line is normal.6. Check whether the data terminal is normal.7. Check whether the system locks a correct clock source.8. Check whether the grounding of the device is proper.


Procedure

Step 1 Check whether the fault occurs on some ports, occurs on all the ports on some boards, or occurson all the SRX user ports of the entire UA5000.l If the fault occurs on some ports, go to Step 4.l If the fault occurs on all the ports on some boards, go to Step 2.l If the fault occurs on all the SRX ports of the entire UA5000, go to Step 18.

Step 2 Run the display board frameid command to check whether the affected board is in theNormal state.l If the board is in the Normal state, go to Step 4.l If the board is not in the Normal state, go to Step 3.


Step 4 Run the display spc frameid/slotid/portid command to check whether the port is configured withthe semi-permanent connection (SPC) service.

l If the port is configured with the SPC service, go to Step 6.l If the port is not configured with the SPC service, reconfigure the SPC service. (For details

about how to configure the SRX service, see Configuring the Sub-rate Service). Then, goto Step 5.


Step 6 Run the display port state frameid/slotid/portid command to check port status.l If the port is in the BUSY state, go to Step 7.l If the port is in the FAULT state, go to Step 11.

Step 7 In srx mode, run the display board set and display port set commands to check whether theparameter configurations of the related SRX ports are the same. For a network that involves a



130

single network element (NE), in other words, the services are carried on the same UA5000,check whether the configurations of the two SRX ports that carry the services are the same. Fora network that comprises multiple NEs, in other words, the services are carried on differentUA5000s, check whether the configurations of the SRX ports on different UA5000s are thesame.l If the parameter configurations are the same, go to Step 12.l If the parameter configurations are different, go to Step 8.

Step 8 Run the board set and port set commands to configure the related parameters to be the same.Then, check whether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 12 in the case of a network that involves a single

NE; and go to Step 9 in the case of a network that comprises multiple NEs.

Step 9 Run the display spc frameid/slotid/portid command on the UA5000 that carries the SRX serviceto check whether the timeslot configurations of interconnected E1 ports are the same.l If the timeslot configurations are the same, go to Step 12.l If the timeslot configurations are different, go to Step 10.

Step 10 Run the spc modify command to modify the data configurations to ensure that the timeslotconfigurations of interconnected E1 ports are the same. Then, check whether the service isrestored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 12.












131





Step 18 Check whether the faulty services are carried on the same UA5000.l If the services are carried on the same UA5000, go to Step 21.l If the services are carried on different UA5000s, go to Step 19.

Step 19 Run the display clock source command on the UA5000 that carries the SRX service to checkwhether the systems use the same clock source.l If the systems use the same clock source, go to Step 21.l If the systems use different clock sources, go to Step 20.

Step 20 Run the clock source and clock priority commands to change the system clock of theUA5000 on one side to ensure that the UA5000s that carry the SRX service use the same clocksource. Then, check whether the service is restored.l If the service is restored, go to Step 22.l If the service is not restored, go to Step 21.


Step 22 End.

----End

11.3 Troubleshooting DDU2 Synchronous 64 kbit/s DataService Faults

This topic describes how to troubleshoot DDU2 synchronous 64 kbit/s data service faults.


1. Determine the fault scope.2. Check whether the DDU2 board is normal.3. Check whether data configuration is correct.4. Check whether the port is working normally.5. Check whether the loop line is normal.6. Check whether the data terminal is normal.



132

7. Check whether the system locks a correct clock source.8. Check whether the grounding of the device is proper.


Procedure

Step 1 Check whether the fault occurs on some ports, occurs on all the ports on some boards, or occurson all the DDU2 user ports of the entire UA5000.l If the fault occurs on some ports, go to Step 4.l If the fault occurs on all the ports on some boards, go to Step 2.l If the fault occurs on all the DDU2 user ports of the entire UA5000, go to Step 17.

Step 2 Run the display board frameid command to check whether the affected board is in theNormal state.l If the board is in the Normal state, go to Step 4.l If the board is not in the Normal state, go to Step 3.


Step 4 Run the display spc frameid/slotid/portid command to check whether the port is configured withthe semi-permanent connection (SPC) service.l If the port is configured with the SPC service, go to Step 6.l If the port is not configured with the SPC service, run the spc add command to configure

the SPC data. Then, go to Step 5.


Step 6 Run the display port state frameid/slotid/portid command to check port status.l If the port is in the BUSY state, go to Step 9 in the case of a network that involves a single

network element (NE); and go to Step 7 in the case of a network that comprises multipleNEs.

l If the port is in the FAULT state, go to Step 10.

Step 7 Run the display spc frameid/slotid/portid command on the UA5000 that carries the DDU2service to check whether the timeslot configurations of interconnected E1 ports are the same.l If the timeslot configurations are the same, go to Step 9.l If the timeslot configurations are different, go to Step 8.



133

Step 8 Run the spc modify command to modify the data configurations to ensure that the timeslotconfigurations of interconnected E1 ports are the same. Then, check whether the service isrestored.l If the service is restored, go to Step 21.l If the service is not restored, go to Step 9.

Step 9 Check on site whether the indicators on the board panel corresponding to the ports are steadyon.l If the indicators are steady on, go to Step 11.l If the indicators are not steady on, go to Step 20.













Step 17 Check whether the faulty services are carried on the same UA5000.l If the services are carried on the same UA5000, go to Step 20.l If the services are carried on different UA5000s, go to Step 18.



134

Step 18 Run the display clock source command on the UA5000 that carries the DDU2 synchronous 64kbit/s data service to check whether the systems use the same clock source.l If the systems use the same clock source, go to Step 20.l If the systems use different clock sources, go to Step 19.

Step 19 Run the clock source and clock priority commands to change the system clock of theUA5000 on one side to ensure that the UA5000s that carry the DDU2 synchronous 64 kbit/sdata service use the same clock source. Then, check whether the service is restored.l If the service is restored, go to Step 21.l If the service is not restored, go to Step 20.


Step 21 End.

----End



135

12 Troubleshooting System Faults

About This Chapter

This topic describes how to troubleshoot common faults in a UA5000 system. The faults includethe following: the network management system (NMS) fails to manage the UA5000, a serviceboard is in the Failed state, an ADSL service board is in the config state, a service board resetsrepeatedly, and a control board resets abnormally.

12.1 NMS Fails to Manage a DeviceThis topic describes how to troubleshoot a fault when the NMS fails to manage a UA5000.

12.2 Service Board Is in the Failed StateThis topic describes how to troubleshoot a fault when a service board of the UA5000 is in theFailed state.

12.3 ADSL Service Board Is Always in the config StateThis topic describes how to troubleshoot a fault when an ADSL service board in the UA5000IPM system is always in the config state.

12.4 Service Board Resets RepeatedlyThis topic describes how to troubleshoot a fault when a service board of the UA5000 resetsrepeatedly.

12.5 Control Board Resets AbnormallyThis topic describes how to troubleshoot a fault when a control board of the UA5000 resetsabnormally. A control board reset is also called a system reset.

UA5000 Universal Access UnitTroubleshooting 12 Troubleshooting System Faults


136

12.1 NMS Fails to Manage a DeviceThis topic describes how to troubleshoot a fault when the NMS fails to manage a UA5000.


1. Identify the fault scope.2. Check whether the UA5000 can ping the NMS.3. Check whether configurations of the UA5000 and the NMS are correct.


Procedure

Step 1 Check whether the same NMS fails to manage other devices. In other words, check whether thefault occurs on a large number of devices managed by the same NMS.l If the same NMS fails to manage other devices, go to Step 2.l If the same NMS can manage other devices, go to Step 4.

Step 2 Check whether the NMS version matches the host version.l If the NMS version matches the host version, go to Step 4.l If the NMS version does not match the host version, use an NMS version that corresponds

to the host version. Then, go to Step 3.


Step 4 Run the ping command to ping the NMS.l If the NMS can be pinged, go to Step 11.l If the NMS cannot be pinged, go to Step 5.

Step 5 Check whether the IPM or PVM device is faulty.l If the IPM device is faulty, go to Step 6.l If the PVM device is faulty, go to Step 9.

Step 6 Run the display ip routing-table command to check whether there is a route to the NMS server.l If there is a route to the NMS server, check the upstream link to ensure that the device can

communicate with the NMS normally. Then, go to Step 8.l If there is no route to the NMS server, run the ip route-static command to add a static route

to the NMS server. Then, go to Step 7.



137

Step 7 Check whether the fault is rectified.

l If the fault is rectified, go to Step 13.

l If the fault persists, check the upstream link to ensure that the device can communicate withthe NMS normally. Then, go to Step 8.

Step 8 Check whether the fault is rectified.


l If the fault persists, go to Step 11.

Step 9 Check whether the network management IP address and the gateway IP address are configuredcorrectly on the NMS for the faulty device.

l If they are configured correctly, go to Step 11.

l If they are configured incorrectly, go to Step 10.

NOTE

If the inband network management mode is used, the network management IP address and the main serviceIP address of the UA5000 can ping each other. The main service IP address is the IP address of the firstservice network port queried by running the display ip address command. If the outband networkmanagement mode is used, the network management IP address and the outband network managementinterface IP address of the UA5000 can ping each other. The outband network management interface IPaddress can be queried by running the display ip address command.

Step 10 Modify the configurations of the network management IP address and gateway IP address onthe NMS for the fault device. Then, check whether the fault is rectified.



Step 11 Check the Simple Network Management Protocol (SNMP) configurations of the UA5000 andNMS. Ensure that the configurations are correct. Then, check whether the fault is rectified.



NOTE

Perform the following operations to check the SNMP configurations:

l Run the display snmp-agent community read command to check whether the read community nameof the device is the same as that of the NMS. If they are different, run the snmp-agent communityread command to add the same read community name to the device as that of the NMS.

l Run the display snmp-agent community write command to check whether the write community nameof the device is the same as that of the NMS. If they are different, run the snmp-agent communitywrite command to add the same write community name to the device as that of the NMS.

l Run the display snmp-agent target-host command to check whether the NMS server IP address isincluded in the list of destination hosts for traps. If the NMS server IP address is not included, run thesnmp-agent target-host trap-hostname command to add the NMS server IP address to the list andrun the snmp-agent target-host trap-paramsname command to configure parameters for sendingtraps.

l Run the display snmp-agent trap enable command to check whether trap sending from the device tothe NMS is enabled. If trap sending from the device to the NMS is disabled, run the snmp-agent trapenable command to enable trap sending from the device to the NMS.




138

Step 13 End.

----End

12.2 Service Board Is in the Failed StateThis topic describes how to troubleshoot a fault when a service board of the UA5000 is in theFailed state.



1. Check whether the actually used service board is the same as that configured in the system.2. Check whether the service board is installed properly.3. Check whether the power supply for the subrack where the affected service board is

installed is normal.4. Check whether the service board hardware is normal.

CAUTIONTo facilitate reporting faults, save the results for each of the following steps.Take electrostatic discharge (ESD) measures when removing and inserting a service board.

Procedure

Step 1 Run the display board frameid/slotid command to query the name of the faulty board. Checkwhether the actually used service board is the same as that configured in the system.l If they are the same, go to Step 3.l If they are different, check whether the system configurations are correct.

If the system configurations are correct, insert a board of the correct type into the slot andthen go to Step 2.If the system configurations are incorrect and the system is the IPM system, run the boarddelete command to delete the original configurations.After the system displays a message indicating that the board is automatically found, runthe board confirm command to confirm the board.If the system configurations are incorrect and the system is the PVM system, run the boarddelete command to delete the original configurations, run the board add command to addthe board of the correct type, and then run the board confirm command to confirm theboard.Then, go to Step 2.

Step 2 Wait for about five minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 9.l If the fault persists, go to Step 3.



139

Step 3 Check whether the service board is installed properly.l If the service board is installed properly, go to Step 5.l If the service board is not installed properly, remove and insert the service board, and ensure

that the service board is installed properly. Then, go to Step 4.


Step 5 Check whether the power supply for the subrack is normal.l If the power supply for the subrack is normal, go to Step 7.l If the power supply for the subrack is abnormal, check the power supply device and ensure

that the device provides power normally. Then, go to Step 6.


Step 7 Replace the service board. Check whether the new service board can start normally.l If the new service board can start normally, go to Step 9.l If the new service board cannot start normally, go to Step 8.


Step 9 End.

----End

12.3 ADSL Service Board Is Always in the config StateThis topic describes how to troubleshoot a fault when an ADSL service board in the UA5000IPM system is always in the config state.


1. Check whether the ADSL board software saved in the flash memory of the control boardmatches the host version.

2. Reset the affected service board and check whether the board can start normally.3. Check whether the service board hardware is normal.4. Check whether the backplane of the subrack is normal.




140

Procedure

Step 1 Check whether the faulty board is in a master or slave subrack.

l If the faulty board is in a master subrack, go to Step 2.

l If the faulty board is in a slave subrack, go to Step 3.

Step 2 Run the display flash state command to query the board software information saved in the flashmemory of the active control board in the master subrack. Then, check whether the versionnumbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters are the same as thosedescribed in the release notes.

l If the version numbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters arethe same as those described in the release notes, go to Step 5.

l If the version numbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters aredifferent from those described in the release notes, go to Step 4.

Step 3 Run the display flash state command to query the board software information saved in the flashmemory of the active control board in the slave subrack. Then, check whether the versionnumbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters are the same as thosedescribed in the release notes.

l If the version numbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters arethe same as those described in the release notes, go to Step 5.

l If the version numbers of the Adsl2p-3 firmware and Adsl2p-3 program2 parameters aredifferent from those described in the release notes, go to Step 4.

Step 4 In diagnose mode, run the load linecard command to reload the Adsl2p-3 firmware andAdsl2p-3 program2 software. After the loading is complete, run the board reset command inglobal config mode to reset the board. Then, check whether the board can start normally.

l If the board can start normally, go to Step 10.

l If the board cannot start normally, go to Step 6.

Step 5 In global config mode, run the board reset command to reset the board. Then, check whetherthe board can start normally.


l If the board cannot start normally, go to Step 6.

Step 6 Insert the faulty service board in another vacant slot that is working normally. Then, checkwhether the board can start normally.


l If the board cannot start normally, the service board hardware is faulty. In this case, replacethe service board by referring to Replacing the Service Board. Then, go to Step 10.

Step 7 Remove a normal service board from another slot and insert the board in the slot that houses thefaulty board. Then, check whether the board can start normally.


l If the board cannot start normally, the backplane of the subrack is faulty. In this case, restorethe service by inserting the board in another normal slot. Then, go to Step 9.

Step 8 In diagnose mode, run the display reboot-record command. Then, go to Step 9.



141


Step 10 End.

----End

12.4 Service Board Resets RepeatedlyThis topic describes how to troubleshoot a fault when a service board of the UA5000 resetsrepeatedly.


1. Check whether the actually used service board is the same as that configured in the system.2. Check whether fans are working normally.3. Check whether the service board is installed properly.4. Check whether the power supply for the subrack where the affected service board is

installed is normal.5. Check whether the service board hardware is normal.6. Check whether the backplane of the subrack is normal.


Procedure

Step 1 Run the display board frameid/slotid command to query the name of the faulty board. Checkwhether the actually used service board is the same as that configured in the system.l If they are the same, go to Step 3.l If they are different, check whether the system configurations are correct.

If the system configurations are correct, insert a board of the correct type into the slot andthen go to Step 2.If the system configurations are incorrect and the system is the IPM system, run the boarddelete command to delete the original configurations.After the system displays a message indicating that the board is automatically found, runthe board confirm command to confirm the board.If the system configurations are incorrect and the system is the PVM system, run the boarddelete command to delete the original configurations, run the board add command to addthe board of the correct type, and then run the board confirm command to confirm theboard.



142

Then, go to Step 2.

Step 2 Wait for about five minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 15.l If the fault persists, go to Step 3.

Step 3 Check whether fans are working properly.

If fans are faulty, the temperature of the subrack is greater than the maximum value. In this case,a service board resets repeatedly.

l If fans are working normally, go to Step 5.l If fans are faulty, troubleshoot the fault by referring to 13.1 Fan Is in the Fault State.

Then, go to Step 4.


Step 5 Check whether the service board is installed properly.l If the service board is installed properly, go to Step 7.l If the service board is not installed properly, remove and insert the service board, and ensure

that the service board is installed properly. Then, go to Step 6.


Step 7 Check whether the power supply for the subrack is normal. For example, for the PVM system,check whether the VIN(RUN) indicator on the secondary power board is on for one second andoff for one second repeatedly.l If the power supply for the subrack is normal, go to Step 9.l If the power supply for the subrack is abnormal, go to Step 8.

Step 8 Check the power supply device. For example, for the PVM system, check whether the POWERswitch on the secondary power board is turned on. Replacing the Secondary Power Board ifnecessary to ensure that the power supply device is working normally. Then, check whether thefault is rectified.l If the fault is rectified, go to Step 15.l If the fault persists, go to Step 9.

Step 9 Check whether the faulty service board is in a slave or extended subrack.l If the faulty service board is in a slave or extended subrack, go to Step 10.l If the faulty service board is not in a slave or extended subrack, go to Step 12.

Step 10 Check whether the cascading cable is properly connected to the slave or extended subrack orwhether the cascading cable is worn out.l If the cascading cable is not properly connected to the slave or extended subrack or the

cascading cable is worn out, go to Step 11.l If the cascading cable is properly connected to the slave or extended subrack and the

cascading cable is in good condition, go to Step 12.



143

Step 11 Reconnect the cascading cable or replace the cascading cable. Ensure that the cascading cableis properly connected to the slave or extended subrack and the cascading cable is in goodcondition. Then, check whether the fault is rectified.l If the fault is rectified, go to Step 15.l If the fault persists, go to Step 12.

Step 12 Insert the faulty service board in another vacant slot that is working normally. Check whetherthe board can start normally without resetting.l If the board can start normally without resetting, go to Step 13.l If the board can start normally but resets, the service board is faulty. In this case, replace

the service board by referring to Replacing the Service Board. Then, go to Step 15.

Step 13 Insert a normal service board of the same type from another slot to the slot that houses the faultyboard. Check whether the board can start normally without resetting.l If the board can start normally without resetting, go to Step 14.l If the board can start normally but resets, the backplane of the subrack is faulty. Use the

board in another normal slot to restore the service. Then, go to Step 14.


Step 15 End.

----End

12.5 Control Board Resets AbnormallyThis topic describes how to troubleshoot a fault when a control board of the UA5000 resetsabnormally. A control board reset is also called a system reset.


1. Check whether the control board is restored to the normal state after resetting.2. Check whether the reset is caused by manual operations.3. Check whether the temperature of the subrack is greater than the maximum value.4. Check whether the power supply for the subrack where the affected control board is

installed is normal.5. Check whether protection switchover occurs because optical fibers or network cables to

the uplink port are loose or are not connected.6. Check whether the port connecting an upper layer device to the UA5000 is working

normally.



144

CAUTIONAn abnormal control board reset has a significant negative impact on system running. Therefore,when such a reset occurs, restore services according to predefined contingency measures. Then,follow the steps described in this document to troubleshoot faults.To facilitate reporting faults, save the results for each of the following steps.

Procedure

Step 1 After the control board resets, check whether the RUN indicator on the panel is on for one secondand off for one second repeatedly.l If the RUN indicator on the panel is on for one second and off for one second repeatedly,

go to Step 2.l If the RUN indicator on the panel is not on for one second and off for one second repeatedly,

go to Step 11.

Step 2 Run the display log all command to check whether a user issued the reboot command or theNMS issued a message to reset the control board.l If a user issued the reboot command or the NMS issued a message to reset the control

board, go to Step 12.l If neither a user issued the reboot command nor the NMS issued a message to reset the

control board, go to Step 3.

NOTE

After the display log all command is run, the system may display the following messages that have differentmeanings:

l If the system displays the "hwFrameAdminStatus: 3" message, the NMS issued a message to reset thesystem.

l If the system displays the "hwSlotAdminStatus: 3" message, the NMS issued a message to reset a board(a service board or a control board).

Step 3 Check whether fans are working normally.

If fans are faulty, the temperature of the subrack is greater than the maximum value. In this case,the control board resets abnormally.

l If fans are working normally, go to Step 5.l If fans are faulty, troubleshoot the fault by referring to 13.1 Fan Is in the Fault State.

Then, go to Step 4.

Step 4 Check whether the control board resets abnormally.l If the control board resets abnormally, go to Step 5.l If the control board does not reset abnormally, go to Step 12.

Step 5 Check whether the power supply for the subrack is normal. For example, for the PVM system,check whether the VIN(RUN) indicator on the secondary power board is on for one second andoff for one second repeatedly.l If the power supply for the subrack is normal, go to Step 7.l If the power supply for the subrack is abnormal, go to Step 6.



145

Step 6 Check the power supply device. For example, for the PVM system, check whether the POWERswitch on the secondary power board is turned on. Replacing the Secondary Power Board ifnecessary to ensure that the power supply device is working normally. Then, check whether thecontrol board still resets abnormally.l If the control board still resets abnormally, go to Step 7.l If the control board does not reset abnormally, go to Step 12.

Step 7 Check whether optical fibers or network cables to the uplink port are loose or are not connected.l If optical fibers or network cables to the uplink port are loose or are not connected, connect

fibers or cables again to ensure a firm connection. Then, go to Step 8.l If optical fibers or network cables of the uplink port are connected properly, go to Step 9.

Step 8 Check whether the control board still resets abnormally.l If the control board resets abnormally, go to Step 9.l If the control board does not reset abnormally, go to Step 12.

Step 9 Check whether the port connecting an upper layer device to the UA5000 is working normally.l If the port is working normally, go to Step 11.l If the port is not working normally, troubleshoot the port fault of the upper layer device.


Step 10 Check whether the control board resets by the abnormality.l If the control board resets abnormally, go to Step 11.l If the control board does not reset abnormally, go to Step 12.


Step 12 End.

----End



146

13 Troubleshooting EnvironmentMonitoring Faults

About This Chapter

This topic describes how to troubleshoot common faults of an environment monitoring unit(EMU). The faults include the following: a fan is in the Fault state, an ESC board is in theFault state, and a power monitoring module is in the Fault state.

13.1 Fan Is in the Fault StateThis topic describes how to troubleshoot a fault when a fan of the UA5000 is in the Fault state.

13.2 ESC Board Is in the Fault StateThis topic describes how to troubleshoot a fault when an ESC board of the UA5000 is in theFault state.

13.3 Power Monitoring Module Is in the Fault StateThis topic describes how to troubleshoot a fault when a power monitoring module of theUA5000 is in the Fault state.

UA5000 Universal Access UnitTroubleshooting 13 Troubleshooting Environment Monitoring Faults


147

13.1 Fan Is in the Fault StateThis topic describes how to troubleshoot a fault when a fan of the UA5000 is in the Fault state.



1. Check whether the fan tray is installed properly.2. Check whether dual in-line package (DIP) switch settings of the fan are the same as those

configured in the system.3. Check whether the jumper on the transfer board is correctly configured.4. Check whether the hardware of the transfer board or fan tray is normal.


Procedure

Step 1 Ensure that the fan tray is installed properly. Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 2.

Step 2 Run the display emu emuid command to check whether the configured subnode IDs(Subnode) of the DIP switch on the fan monitoring board are the same as the subnode settingsof DIP switch on the fan monitoring board. (You need to remove the fan tray to view the settingsof DIP switch on the fan monitoring board. For subnode IDs corresponding to different DIPswitches, see Checking the DIP Settings on the Monitoring Board of the Fan.)l If the configured subnode IDs are the same as the subnode settings of the DIP switch on

the fan monitoring board, go to Step 4.l If the configured subnode IDs are different from the subnode settings of the DIP switch on

the fan monitoring board, adjust the DIP switch according to the data plan. Alternatively,run the emu del command to delete the original fan configurations and then run the emuadd command to configure the fan tray to ensure that the configured subnode IDs are thesame as the subnode settings of the DIP switches on the fan monitoring board. Then, go toStep 3.

Step 3 Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 4.

Step 4 Check whether the affected fan tray is a front-access fan tray.l If it is a front-access fan tray, go to Step 5.l If it is not a front-access fan tray, go to Step 9.



148

Step 5 Check whether the jumper on the transfer board is correctly configured.l If the jumper on the transfer board is correctly configured, go to Step 7.l If the jumper on the transfer board is incorrectly configured, correctly configure the jumper

by referring to HWCF Transfer Board. Then, go to Step 6.

NOTE

Configuring the jumper on the transfer board allows you to select the IPM or PVM control board to monitorfan status. If the jumper settings do not match an actual IPM or PVM control board, the IPM or PVMcontrol board cannot monitor fan status.

Step 6 Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 7.

Step 7 Replace the transfer board (front-access) by referring to Replacing the Transfer Board (Front-Access). Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 11.l If the fault persists, go to Step 8.

Step 8 Replace the fan tray (front-access) by referring to Replacing the Fan Tray (Front-Access). Checkwhether the new fan tray is normal.l If the new fan tray is normal, go to Step 11.l If the new fan tray is abnormal, go to Step 10.

Step 9 Replace the fan tray (rear-access) by referring to Replacing the Fan Tray (Rear-Access). Checkwhether the new fan tray is normal.l If the new fan tray is normal, go to Step 11.l If the new fan tray is abnormal, go to Step 10.


Step 11 End.

----End

13.2 ESC Board Is in the Fault StateThis topic describes how to troubleshoot a fault when an ESC board of the UA5000 is in theFault state.


1. Check whether the environment monitoring unit (EMU) type configured in the system isthe same as the actual EMU type.

2. Check whether the physical connection between the ESC board and the UA5000 is correct.3. Check whether the serial cable connected to the ESC board is normal.4. Check whether the jumper on the ESC board is correctly configured.



149

5. Check whether the ESC board is properly installed.

6. Check whether the jumper on the transfer board is correctly configured.

7. Check whether the hardware of the transfer board or the ESC board is normal.


Before you remove and insert a board, take antistatic measures.

Procedure

Step 1 Check whether the EMU type configured in the system is the same as the actual EMU type.

l If they are the same, go to Step 3.

l If they are different, run the emu del command to delete the incorrect EMU and run theemu add command to add an EMU so that it is the same as the actually used EMU. Then,go to Step 2.

Step 2 Wait for about three minutes. Check whether the fault is rectified.


l If the fault is not rectified, go to Step 3.

Step 3 Check whether the physical connection between the ESC board and the UA5000 is correct.

l If the physical connection is correct, go to Step 5.

l If the physical connection is incorrect, modify the connection by referring to EnvironmentMonitoring. Then, go to Step 4.




Step 5 Check whether the serial cable connected to the ESC board is normal.

l If the serial cable connected to the ESC board is normal, go to Step 7.

l If the serial cable connected to the ESC board is abnormal (for example, it is damaged),replace the serial cable. Ensure that the environment monitoring cable corresponding to thesubrack is used. Then, go to Step 6.




Step 7 Check whether the jumper settings of the ESC board configured in the system are the same asthe actual settings. For the jumper settings of the ESC board, see Checking the Settings of DIPSwitches and Jumpers of Environment Monitoring Boards.

l If the jumper settings of the ESC board configured in the system are the same as the actualsettings, go to Step 9.



150

l If the jumper settings of the ESC board configured in the system are different from theactual settings, set the jumper on the ESC board by referring to Checking the Settings ofDIP Switches and Jumpers of Environment Monitoring Boards. Then, go to Step 8.

Step 8 Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 16.l If the fault is not rectified, go to Step 9.

Step 9 Remove and then insert the ESC board. Wait for about three minutes. Check whether the faultis rectified.l If the fault is rectified, go to Step 16.l If the fault is not rectified, go to Step 10.

Step 10 Check whether the affected subrack is a front-access subrack.l If it is a front-access subrack, go to Step 11.l If it is not a front-access subrack, go to Step 14.

Step 11 Check whether the jumper on the transfer board is correctly configured.l If the jumper on the transfer board is correctly configured, go to Step 13.l If the jumper on the transfer board is not correctly configured, configure the jumper on the

transfer board by referring to HWCF Transfer Board. Then, go to Step 12.NOTE

Configuring the jumper on the transfer board allows you to select the IPM or PVM control board to managethe ESC board. If the jumper settings do not match an actual IPM or PVM control board, the IPM or PVMcontrol board cannot manage the ESC board normally.


Step 13 Replace the transfer board (front-access) by referring to Replacing the Transfer Board (Front-Access). Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 16.l If the fault is not rectified, go to Step 14.

Step 14 Replace the ESC board by referring to Replacing the Environment Monitoring Board. Then,check whether the new ESC board is normal.l If the new ESC board is normal, go to Step 16.l If the new ESC board is abnormal, go to Step 15.


Step 16 End.

----End

13.3 Power Monitoring Module Is in the Fault StateThis topic describes how to troubleshoot a fault when a power monitoring module of theUA5000 is in the Fault state.



151



1. Check whether the physical connection between the power module and the UA5000 iscorrect.

2. Check whether the serial cable connected to the power monitoring module is normal.3. Check whether the power module is properly installed.4. Check whether the jumper on the transfer board is correctly configured.5. Check whether the hardware of the transfer board or power monitoring module is normal.


Procedure

Step 1 Check whether the physical connection between the power module and the UA5000 is correct.l If the physical connection is correct, go to Step 3.l If the physical connection is incorrect, modify the connection by referring to Environment

Monitoring. Then, go to Step 2.


Step 3 Check whether the serial cable connected to the power monitoring module is normal.l If the serial cable connected to the power monitoring module is normal, go to Step 5.l If the serial cable connected to the power monitoring module is abnormal (for example, it

is damaged), replace the serial cable. Ensure that the environment monitoring cablecorresponding to the subrack is used. Then, go to Step 4.


Step 5 Remove and then insert the power monitoring module. Wait for about three minutes. Checkwhether the fault is rectified.l If the fault is rectified, go to Step 13.l If the fault is not rectified, go to Step 6.

Step 6 Remove and then insert the power rectifier module. Wait for about three minutes. Check whetherthe fault is rectified.l If the fault is rectified, go to Step 13.l If the fault is not rectified, go to Step 7.



152

Step 7 Check whether the affected subrack is a front-access subrack.l If it is a front-access subrack, go to Step 8.l If it is not a front-access subrack, go to Step 11.

Step 8 Check whether the jumper on the transfer board is correctly configured.l If the jumper on the transfer board is correctly configured, go to Step 10.l If the jumper on the transfer board is not correctly configured, configure the jumper on the

transfer board by referring to HWCF Transfer Board. Then, go to Step 9.

NOTE

Configuring the jumper on the transfer board allows you to select the IPM or PVM control board to managethe ESC board. If the jumper settings do not match an actual IPM or PVM control board, the IPM or PVMcontrol board cannot manage the ESC board normally.


Step 10 Replace the transfer board (front-access) by referring to Replacing the Transfer Board (Front-Access). Wait for about three minutes. Check whether the fault is rectified.l If the fault is rectified, go to Step 13.l If the fault is not rectified, go to Step 11.

Step 11 Replace the power monitoring module by referring to Replacing the Monitoring Unit. Then,check whether the new power monitoring module is normal.l If the new power monitoring module is normal, go to Step 13.l If the new power monitoring module is abnormal, go to Step 12.


Step 13 End.

----End



153

14 Emergency Handling

About This Chapter

If an emergency occurs, take predefined emergency handling measures to recover servicesquickly and then locate and rectify faults by following the steps provided in this document.

14.1 Precautions for Emergency HandlingThis topic describes the precautions that you need to pay attention to when predefining or takingemergency handling measures.

14.2 Troubleshooting Common EmergenciesAfter restore services by taking emergency handling measures, you need to locate and rectifyfaults. This topic provides fault location guidance on handling several common emergencies.

UA5000 Universal Access UnitTroubleshooting 14 Emergency Handling


154

14.1 Precautions for Emergency HandlingThis topic describes the precautions that you need to pay attention to when predefining or takingemergency handling measures.

An emergency is hazardous and has a significant negative impact. To improve emergencyhandling efficiency and minimize the loss as much as possible, you need to pay attention to thefollowing precautions:

l When an emergency occurs, services must be restored quickly and devices must runproperly. Therefore, to improve emergency handling, refer to this document to predefineemergency handling measures based on site requirements; for example, restart the system,perform an active/standby switchover, back up and restore the database and configurationfile, and cut over all services to a standby service network. In addition, periodically (oncein a quarter is recommended) have associated personnel learn and practice emergencyhandling.

l Before performing emergency handling, emergency handling personnel must have attendedrequired training and have mastered methods for determining and handling emergencies.For detailed requirements, see 1.1 Skill Requirements.

l Be clear about 1.2 Troubleshooting Precautions.l If carriers have signed a service level agreement (SLA) with Huawei, contact Huawei for

assistance by referring to 1.3.5 Contacting Huawei for Assistance at the earliest possiblemoment in case of an emergency.

l In case of an emergency, maintenance engineers must keep their composure and takepredefined emergency handling measures. Analyze faulty part or module first and thenrestore services. Restart the system after a prudent decision.

14.2 Troubleshooting Common EmergenciesAfter restore services by taking emergency handling measures, you need to locate and rectifyfaults. This topic provides fault location guidance on handling several common emergencies.

14.2.1 Service Interruptions Encountered by All the Users of aSingle Device

This topic describes how to troubleshoot a fault when all the users of a single UA5000 encounterservice interruptions.

Procedure

Step 1 Check whether the power supply is normal.

If the indicators of all the boards are off, the power input or the power supply itself has problems.Rectify any problems you encounter.

If the power supply is normal but the indicators of all the boards are still off, contact Huaweifor technical support.

Step 2 Check whether the control board is normal.



155

Observe the RUN indicator on the front panel. If the indicator is on for one second and off forone second repeatedly, the control board is normal. Otherwise, the control board is faulty.Replace the control board if necessary.

Step 3 Check whether the link to the uplink port is in the online state.

Step 4 Check the configuration of an upper layer BRAS or router.

If multiple UA5000s (including the device where the fault occurs) are connected to the upper-layer BRAS or router and other UA5000s are normal, check the configurations of the BRAS orrouter and the configurations of the affected UA5000 port, such as VLAN transparenttransmission configuration and route configuration.

Step 5 Check the port that connects the UA5000 to a transmission device.

If the upper layer transmission device is connected to multiple UA5000s (including the devicewhere the fault occurs) and other UA5000s are normal, check the data configurations of the portthat connects the UA5000 to the transmission device.

Step 6 Confirm history operations.

1. Check the operations carried out on the UA5000 before and after the fault occurs.

l Check whether any maintenance engineer operates the UA5000 before the fault occurs,and whether any alarm is generated on the maintenance terminal during the operations.

l Check whether any maintenance engineer operates the device after the fault occurs. Ifa maintenance engineer operates the device after the fault occurs, obtain the impacts ofsuch operations.

For the UA5000, it is recommended that you run the display log all command to collectall the log information.

NOTE

In the UA5000 system:

l Logs are stored in the static random access memory (SRAM). Therefore, the logs still exist evenif the system is reset or powered off.

l The maximum number of logs stored depends on the memory capacity. If the actual number oflogs exceeds the upper limit, the earliest records are automatically overwritten. Therefore, recordthe logs immediately after a fault occurs, to prevent the loss of any useful information. To obtainlarger log storage space, it is recommended that you use an NMS or a log server to record logs.

2. Check whether the maintenance personnel operate upper layer and lower layer devicesbefore and after the fault.

3. Check whether any construction is carried out in the local or remote equipment room. Focuson the routing of optical fibers and network cables during the construction. Check whetherthe construction affects the original optical fibers and network cables.

Step 7 Check service configurations.

For detailed operations, see the chapters covering specific service troubleshooting in thisdocument.

Step 8 If the fault cannot be rectified by performing the preceding steps, fill in a form for reporting afault and then contact Huawei for technical support.

----End



156

14.2.2 Service Interruptions Encountered by All the Users ofMultiple Devices Under an Upper Layer BRAS or Router

This topic describes how to troubleshoot a fault when all the users of multiple UA5000s underan upper layer broadband remote access server (BRAS) or router encounter service interruptions.

Procedure

Step 1 Contact a BRAS or router maintenance engineer to check whether the port that connects theBRAS or router to the UA5000 is normal.

Step 2 Contact the BRAS or router maintenance engineer to check whether the data configurations ofthe BRAS or router are correct.

Step 3 Contact an engineer in charge of maintaining transmission devices to check whether thetransmission devices are interconnected correctly.

Step 4 Compare the faulty device with a normal device of the same level, and find differences todetermine whether the fault is caused by these differences.

Step 5 Check whether the service configurations of the UA5000 are correct.

For example, check the following for the multicast service:

l Whether a video server is configured correctly.l Whether the time to live (TTL) value is large enough for a program. Ensure that the maximum

TTL value is greater than the number of hops from the server to the user.


----End

14.2.3 Service Interruptions Encountered by All the Users of AllDevices Under an Upper Layer BRAS or Router

This topic describes how to troubleshoot a fault when all the users of all UA5000s under anupper layer broadband remote access server (BRAS) or router encounter service interruptions.

Procedure

Step 1 Contact a BRAS or router maintenance engineer to check whether the BRAS or router is workingnormally.

Step 2 Contact the BRAS or router maintenance engineer to check whether the data configurations ofthe BRAS or router are correct.

Step 3 Contact an engineer in charge of maintaining transmission devices to check whether thetransmission devices are interconnected correctly.

Step 4 Check whether the service configurations of the UA5000 are correct.

For example, check the following for the multicast service:

l Whether a video server is configured correctly.



157

l Whether the time to live (TTL) value is large enough for a program. Ensure that the maximumTTL value is greater than the number of hops from the server to the user.


----End



158

15 Common Operation

About This Chapter

This topic describes the prerequisite, tools, impacts on the system, and detailed procedures ofcommon operations of the UA5000.

15.1 LoopbackThis topic describes how to configure loopback of each type. Loopback is used to check whethera loop is in the normal state. This helps to locate a fault quickly.

15.2 Performing a Test on the Optical PortThis topic describes how to check whether the optical signal transmit and receive modules arein the normal state by measuring the mean transmit optical power and the actual input opticalpower in the case of bit error or interruption on the optical channel.

15.3 Line TestThis topic describes various line tests supported by the UA5000.

15.4 Configuring the File Transfer ModeThis topic describes how to configure the file transfer modes such as Xmodem and Trivial FileTransfer Protocol (TFTP).

15.5 Backing Up the Database FileThis topic describes how to back up the database file.

15.6 Resetting the SystemThis topic describes how to reset the system.

15.7 Resetting the Control BoardThis topic describes how to reset the control board.

15.8 Active/Standby SwitchoverThis topic describes how to perform the active/standby switchover manually (forcible active/standby switchover).

15.9 Cleaning the Connector of the Optical FiberThis topic describes how to clean the connector of the optical fiber. Frequent insert and removeor no dust-proof treatment for a longtime causes the connector to be dirty and aged, which resultsin deterioration of the line quality. Therefore, you need to periodically clean the connector of

UA5000 Universal Access UnitTroubleshooting 15 Common Operation


159

the optical fiber, including the ends of the optical fiber connector, optical port of the opticaltransceiver, and adapter, and take measures to prevent dust.

15.10 Checking the Optical Fiber LinkThis topic describes how to check the optical fiber link on the upstream optical port on theUA5000. In the case of optical signal interruption, bit error, and abnormality alarm report, youcan locate and troubleshoot the fault by checking the connection of the optical fiber and testingthe quality of the optical fiber link. This operation can also be used as a maintenance item forperiodical check.

15.11 Mirroring Packet Capture (IPM)The IPM device provides the mirroring packet capture function on the Ethernet upstream port.Through the mirroring packet capture function, you can obtain packets. Based on the analysisof the packets, you can determine whether the service interaction between the device and theinterconnected device is normal.

15.12 Mirroring Packet Capture (PVM)The PVM device provides the mirroring packet capture function on the Ethernet upstream port.Through the mirroring packet capture function, you can obtain packets. Based on the analysisof the packets, you can determine whether the service interaction between the device and theinterconnected device is normal.

15.13 Changing the Line Profile or Line Template of an xDSL PortThis topic describes how to change the line profile or line template bound to an xDSL port whenthe line profile of the ADSL2+ or SHDSL port or the line template of the VDSL2 port cannotmeet the requirement for the service.

15.14 Changing the Traffic Profile of an xDSL PortThis topic describes how to change the traffic profile when the traffic profile bound to the xDSLport cannot meet the requirements for the rate and the 802.1p priority.

15.15 Troubleshooting the MG Interface FaultThis topic describes how to troubleshoot the media gateway (MG) interface fault when it is inthe abnormal state to ensure that the MG interface, namely, the virtual access gateway (VAG)can register with the softswitch successfully.

15.16 Troubleshooting the V5 Interface FaultThis topic describes how to troubleshoot the V5 interface fault when it is in the abnormal stateto ensure that the V5 interface can start normally.



160

15.1 LoopbackThis topic describes how to configure loopback of each type. Loopback is used to check whethera loop is in the normal state. This helps to locate a fault quickly.

15.1.1 Performing the Loopback on an ADSL2+ PortThis topic describes how to perform the loopback on an ADSL2+ port when the service carriedby the ADSL2+ port is abnormal. This helps to locate the fault by checking whether the serviceboard where the ADSL2+ port is located communicates with the backplane normally. Note thatthe faults on the existing network are generally located segment by segment after a series ofloopbacks are performed.

Prerequisitel The ADSL2+ port must be in the deactivated state.l The ADSL2+ service must be in the ATM mode.l The ADSL2+ service must be in the normal state before the fault occurs (Ensure that the

downstream direction from the control board to the ADSL2+ service board carries theservice traffic.)

Impact on the Systeml If a port is in the loopback state, the port cannot forward packets normally and all the

services carried on the port are interrupted.l If a port that is in the loopback state is not isolated, a broadcast storm may occur. Therefore,

after the loopback test, run the undo loopback command to cancel the loopback in time.

PrecautionsThe loopback type supported by a board depends on the hardware structure of the board. Thesystem displays an error message when a loopback operation that is not supported by the boardis performed on the board.

ProcedureStep 1 In the ADSL mode, run the loopback command to start the port loopback. Select a proper

loopback type, UTOPIA or AFE as required. Hybrid loopback is not supported.For example, to perform the UTOPIA loopback on port 0/9/0, do as follows:huawei(config-if-adsl-0/9)#loopback 0 UTOPIA

Step 2 In ADSL mode, run the atm-ping command to check whether the loop is normal.For example, to check the loop that is formed in the preceding step (the VPI/VCI correspondingto the traffic stream of the port is 0/35), do as follows:huawei(config-if-adsl-0/9)#atm-ping 0 0 35

----End

ReferenceThe ports on the ADSL2+ board support only the local loopback.



161

Local loopback

Local loopback, also named inloop, refers to the loopback from the port processing module ofthe board to the backplane. In the local loopback, the signals that are transmitted from thebackplane to the port are directly sent to the backplane to check whether the board is in thenormal state. Figure 15-1 shows the local loopback.

Figure 15-1 Local loopback

Board

Local loopback

Bac

kpla

ne

intre

face

mod

ule

Por

t pro

cess

ing

mod

ule

ADSL2+ port local loopback

The ADSL2+ board supports two types of local loopback, namely, universal test & operationsPHY interface for ATM (UTOPIA) and analog front end (AFE).

l UTOPIA loopback refers to the loopback of "backplane <-> UTOPIA port <-> backplane",as shown in Figure 15-2 (1). This loopback type is used to check whether the path betweenthe backplane and the logic is normal.

l AFE loopback refers to the loopback of "backplane <-> AFE <-> backplane", as shown inFigure 15-2 (2). This loopback type is used to check whether the path between thebackplane and the inner side of the chipset is normal.

Figure 15-2 ADSL2+ port local loopback

逻

辑

UTOPIA

Hybrid

AFE

背

接

模块

1 2

Board

Logic chip

HybridAFEUTOPIA

Backpane interface module

Chipset

(1) (2)

15.1.2 Performing the Loopback on an SHDSL PortThis topic describes how to perform the loopback on an SHDSL port when the service carriedon the SHDSL port is abnormal. This helps to locate the fault by checking whether the associatedservice board communicates with the backplane normally (local loopback) and whether theassociated service board communicates with the device on the user side normally (remoteloopback). Note that the faults on the existing network are generally located segment by segmentafter a series of loopback is performed.



162

Prerequisitel When you perform the local loopback, the SHDSL port must be deactivated.l When you perform the remote loopback, the SHDSL port must be activated.l The SHDSL service must run in ATM mode.l The SHDSL service must run normally before the fault occurs. (When performing the local

loopback, ensure that traffic streams exist in the downstream direction from the controlboard to the SHDSL service board of the device; when performing the remote loopback inremote mode, ensure that traffic streams exist in the upstream direction from the device onthe user side to the SHDSL service board; when performing the remote loopback in STU-R mode, ensure that traffic streams exist in the downstream direction from the SHDSLservice board to the device on the user side. The remote loopback in STU-R mode is notdescribed because it is not commonly used.)

Impact on the Systeml After you perform the loopback on the port, the port cannot forward data packets correctly

and all the services carried on the port are interrupted.l After you perform the loopback on the port, a broadcast storm may occur if the port is not

isolated. Therefore, when performing the loopback, set the loopback duration according tothe actual requirement, or after the loopback test is complete, run the undo loopbackcommand in time to cancel the loopback.

PrecautionsThe type of the loopback supported by the board is associated with the hardware structure of theboard. When you perform the loopback that is not supported by the board, the system displaysan error message.

Procedurel Configure the local loopback.

1. In SHDSL mode, run the loopback command to perform the local loopback on theport.For example, to perform the local loopback on port 0/9/0 for two minutes, do asfollows:huawei(config-if-shl-0/9)#loopback 0 local time 2

2. In SHDSL mode, run the atm-ping command to check whether the channel is normal.For example, to check the channel after the loopback is performed in the precedingstep (the VPI/VCI corresponding to the traffic stream on the port is 0/35), do asfollows:huawei(config-if-shl-0/9)#atm-ping 0 0 35

l Configure the remote loopback.1. Connect the device on the user side to the packet sender to send packets to the device.

(It is recommended that you connect the device on the user side to the instrument thatcan receive and send data packets and analyze bit errors. Otherwise, you need toseparately connect an idle port on the SHDSL modem to the packet receiver and thebit error analyzer.)

2. In SHDSL mode, run the loopback command to perform the remote loopback on theport.



163

For example, to perform the remote loopback on port 0/9/0 for five minutes, do asfollows:huawei(config-if-shl-0/9)#loopback 0 remote time 5

3. Check whether the device on the user side can receive the data packets sent by itselfand whether no severe bit error occurs.

If the device on the user side cannot receive the data packets sent by itself or severebit errors occur, it indicates that the subscriber line is faulty.

----End

ReferencesThe SHDSL board supports the local and remote loopback on the port.

Introduction to Local Loopback

Local loopback, also called inloop, refers to the loopback from the port processing module insidethe board to the backplane. The signals from the backplane to the port are directly returned tothe backplane, which helps to check whether the control board communicates with the modulesinside the service board normally. Figure 15-3 shows the local loopback.


Board

Local loopback

Bac

kpla

ne

intre

face

mod

ule

Por

t pro

cess

ing

mod

ule

Introduction to Remote Loopback

Remote loopback, also called outloop, refers to the loopback from the port processing moduleinside the board to the line. The signals from the device on the user side (such as the modem)to the signal receiving module of the port are directly sent back to the device on the user sideafter passing the signal sending module of the port and the subscriber line, which helps to checkwhether the service board communicates with the device on the user side normally. Figure15-4 shows the remote loopback.

Figure 15-4 Remote loopback

Remote loopback

Board

Bac

kpla

ne

intre

face

mod

ule

Por

t pro

cess

ing

mod

ule

Dev

ice

on th

e us

er s

ide



164

NOTE

l Remote loopback on the SHDSL port is special because the SHDSL port requires the remote loopbacknot only in remote mode but also in STU-R mode. For the remote loopback in STU-R mode, the deviceon the user side is required to support such a remote loopback in STU-R mode.

l The difference between the remote loopback in STU-R mode and the remote loopback in remote modeis as follows: For the remote loopback in STU-R mode, the tested traffic streams are in the downstreamdirection from the service board to the device on the user side, and the signals from the service boardto the device on the user side are directly returned to the service board from the device on the user side.The similarity between the remote loopback in STU-R mode and the remote loopback in remote modeis that they test the same link.

15.1.3 Performing the Loopback on a VDSL2 PortThis topic describes how to perform the loopback on a VDSL2 port when the service carried bythe VDSL2 port is abnormal. This helps to locate the fault by checking whether the service boardwhere the VDSL2 port is located communicates with the backplane normally. Note that the faultson the existing network are generally located segment by segment after a series of loopbacksare performed.

Prerequisitel The VDSL2 port must be deactivated.l The VDSL2 service must run in the ATM mode.l The VDSL2 service must run normally before a fault occurs. (Ensure that service streams

exist in the downstream direction from the control board to the VDSL2 service board ofthe device.)

Impact on the Systeml After you perform the loopback on the port, the port cannot forward data packets and the

service carried by the corresponding port is interrupted.l After you perform the loopback on the port, the broadcast storm may occur if the port is

not isolated. Therefore, after the loopback test is complete, run the undo loopbackcommand in time to cancel the loopback.

Precautions

The type of the loopback on the port supported by the board is related to the hardware structureof the board. When you perform the loopback that is not supported by the board, the systemdisplays an error message.

Procedure

Step 1 In the VDSL mode, run the loopback command to perform the loopback on the port.For example, to perform the local loopback on port 0/9/0, do as follows:huawei(config-if-vdsl-0/9)#loopback 0 local

Step 2 In the VDSL mode, run the atm-ping command to check whether the channel is normal.For example, to check the channel after the loopback is performed in the preceding step (theVPI/VCI corresponding to the service stream on the port is 0/35), do as follows:



165

huawei(config-if-vdsl-0/9)#atm-ping 0 0 35

----End

ReferenceThe VDSL2 board supports only the local loopback on the port.

Introduction to Local Loopback

Local loopback indicates the loopback from the port processing module inside the board to thebackplane. The signals from the backplane to the port are returned to the backplane directly,which helps to check whether the control board can communicates with the service boardsnormally. Figure 15-5 shows the local loopback.


Board

Local loopback

Bac

kpla

ne

intre

face

mod

ule

Por

t pro

cess

ing

mod

ule

15.1.4 Performing the Loopback on an E1 LineThe E1 line loopback is also called the 2M link physical loopback. When the services on an E1port are abnormal, you can perform the loopback on the E1 line to check whether the E1 port isnormal and whether the internal communication of the system is normal. This helps locate thefault. Generally, in the actual fault location process on the existing network, you need to performa series of loopback on the link to locate the fault segment by segment.

PrerequisiteThe services carried on the E1 port run normally before the fault occurs, that is, the tested loopmust carry service streams.

Tools, Meters, and Materialsl E1 self-loop line (When accurate test for the signal quality is not required, use the E1 self-

loop line to perform the loopback on the E1 line.)l Bit error meter (When accurate test for the signal quality is required, use the bit error meter

to perform the loopback on the E1 line.)

Impact on the Systeml After the E1 line loopback is configured, the E1 port cannot forward data packets correctly,

and all the services carried on the port are interrupted. Therefore, back up the service databefore performing the loopback, or perform the operation when the traffic is light.



166

l After the E1 line loopback is configured, the broadcast storm may occur if the E1 port isnot isolated. Therefore, it is recommended that you cancel the loopback in time after theloopback test is complete.

PrecautionsNone

Procedure

Step 1 Connect the transmit and receive ends of the tested E1 line to the E1 self-loop line or thecorresponding ports on the bit error meter, and ensure that the contact is proper.

Step 2 Verify the loopback result.l When you use the E1 self-loop line to perform the loopback, run the display port state

frameid/slotid[/portid command to query the status of the port involved in the loopback. Ifthe port is in the normal state, it indicates that the E1 port and the internal communicationof the system are normal.

l When you use the bit error meter to perform the loopback, you can determine whether theE1 port and the internal communication of the system are normal through the indication(whether there is signal stream or not) on the bit error meter. In addition, you can determinethe signal quality of the line according to the indication on the bit error meter.

----End

ReferencesThe E1 line loopback is a type of hardware loopback, namely, the loopback on a manually createdhardware loop. Figure 15-6 shows the E1 line loopback.

Figure 15-6 E1 line loopback

Board

E1 line loopback

UA5000

E1 self-loop line

Or bit error meter

Backplane interface m

odule

Port processing m

odule

When you use the bit error meter (using PFA-35 meter as an example) to perform the loopbackon an E1 line to test the bit errors on the line, configure the meter as Table 15-1 and Table15-2 list.



167

Table 15-1 Parameter settings for Menu1

Parameter Value

Mode Rx/Tx

Interface V.35

Framing OFF

Emulation DTE

Tx clock EXT: TC

Rx clock EXT: RC

Table 15-2 Parameter settings for Menu3

Parameter Value

Timer OFF

Autoprint OFF

G.821 USER

Alarms ALL ON

Resolution HRS/MINS

Beeper OFF

15.1.5 Performing the Loopback on an E1 PortThis topic describes how to perform the loopback on an E1 port when the service carried by theE1 port is abnormal. This helps locate the fault by checking whether the service board wherethe E1 port is located communicates with the backplane (local loopback) normally, and whetherthe service board communicates with the peer device (remote loopback) normally. When theresult of the E1 line loopback is abnormal, you can perform this operation to further locate thefault.

PrerequisiteNone

Tools, Meters, and MaterialsEmulation terminal (such as the E10 meter)



168

NOTE

The emulation terminal is optional. When you perform the remote loopback if no service stream is carriedon the tested link, you can use the emulation terminal to emulate the peer device to send packets. In addition,you can determine the link status according to the indication on the meter. In the local loopback, theemulation terminal is not needed, but you still can determine the link status according to the indication onthe meter.

Impact on the Systeml After the port loopback is configured, the port cannot forward data packets correctly, and

all the services carried on the port are interrupted. Therefore, back up the service data beforeperforming the loopback, or perform the operation when the traffic is light.

l After the port loopback is configured, the broadcast storm may occur if the port is notisolated. Therefore, it is recommended that you run the undo loopback command to cancelthe loopback in time after the loopback test is complete.

PrecautionsWhat type of port loopback is supported by a board depends on the hardware structure of theboard. The system displays the corresponding error prompts when a loopback that is notsupported by a board is performed on the board.

Procedurel Configure remote loopback on the E1 port.

1. (Optional; perform this operation when using the emulation terminal.) Connect thetransmit and receive ends of the E1 line on the tested E1 port to the correspondingports on the emulation terminal, and ensure that the contact is proper.

2. Start the port loopback.For example, in the EDT mode, run the loopback command to perform the remoteloopback on port 0/6/0.huawei(config-if-edt-0/6)#loopback 0 remoteFor example, in the SDL mode, run the port loopback command to perform the remoteloopback on port 0/11/0.huawei(config-if-sdl-0/11)#port loopback 0 remote

3. Verify the loopback result. By checking whether the peer device receives the signalsent by itself (for example, if the remote loopback is started on a port, the user of thepeer device should hear the voice of himself/herself when making calls), you candetermine whether the tested link is accessible. If an emulation terminal such as theE10 meter is used, you can determine the result according to the meter indication.

l Configure local loopback on the E1 port.1. (Optional; perform this operation when using the emulation terminal.) Connect the

transmit and receive ends of the E1 line on the tested E1 port to the correspondingports on the emulation terminal, and ensure that the contact is proper.

2. Start the port loopback.For example, in the EDT mode, run the loopback command to perform the localloopback on port 0/6/0.huawei(config-if-edt-0/6)#loopback 0 localFor example, in the SDL mode, run the port loopback command to perform the localloopback on port 0/11/0.



169

huawei(config-if-sdl-0/11)#port loopback 0 local3. Verify the loopback result. By checking whether the local device receives the signal

sent by itself (for example, if the local loopback is started on a port, the user of thelocal device should hear the voice of himself when making or answering calls), youcan determine whether the tested link is accessible. If an emulation terminal such asthe E10 meter is used, you can determine the result according to the meter indication.

----End

ReferencesThe E1 port supports local loopback and remote loopback, both of which are software loopback.

Local loopback on the E1 port

Local loopback, also named inloop, refers to the loopback from the port processing module ofthe board to the backplane. In the local loopback, the signals that are transmitted from thebackplane to the E1 port are directly sent back to the backplane to check whether the board thathouses the E1 port can communicate with the backplane normally. Figure 15-7 shows the localloopback on the E1 port. Generally, in the actual fault location process on the existing network,you need to perform a series of loopback on the link to locate the fault segment by segment (theblue dotted line in the following figure means that you need to perform the loopback on otherline segments before performing the local loopback as shown in the red dotted line).

Figure 15-7 Local loopback on the E1 port

Board

Local loopback

UA5000

Peer device or em

ulation term

inal

Backplane

interface module

Port processing

module

Remote loopback on the E1 port

Remote loopback, also named outloop, refers to the loopback from the port processing moduleof the board to the line. In the remote loopback, the signals that are transmitted from the peerdevice (such as the PBX or switch) to the signal receiving module of the port are directly sentback to the peer device after passing the subscriber line. The remote loopback is performed tocheck whether the board that houses the E1 port can communicate with the peer device normally.Figure 15-8 shows the remote loopback on the E1 port.



170

Figure 15-8 Remote loopback on the E1 port

Board

Peer device or

emulation term

inal

Port processing

module

Backplane

interface module

Remote loopback

15.2 Performing a Test on the Optical PortThis topic describes how to check whether the optical signal transmit and receive modules arein the normal state by measuring the mean transmit optical power and the actual input opticalpower in the case of bit error or interruption on the optical channel.

15.2.1 Testing the Average Transmit Optical Power of the Single-Fiber Bi-Directional Optical Port

This topic describes how to check whether the optical signal transmit module is in the normalstate in the case of code error or service interruption on the single-fiber bi-directional opticalport.

Prerequisitel The port to be tested must be in the idle state.l Service streams must run on the port to be tested, and must run normally before the code

error or service interruption occurs on the optical link.

Impact on the SystemDuring the test of the average transmit optical power of the single-fiber bi-directional opticalport, the tested optical port cannot carry services.

Tools, Meters, and Materialsl Optical power meterl Fiber jumper with different connectors (choose proper fiber jumper according to the

requirement)



171

Precautions

DANGERDo not look directly into the optical fiber connector or the laser transmit port on the optical portboard without eye protection.

l Use the dBm unit of the optical power meter for the test.l The fiber jumper connector and the optical transceiver on the panel of the optical port board

must be clean and must be connected properly.l Use a new and short fiber jumper with a length within 1 m.l Do not break the fiber jumper. A broken fiber jumper affects the test result.

Procedure

Step 1 Remove the optical fiber connected to the tested port. Connect one end of the fiber jumper tothe port to be tested and the other end to the optical power meter, as shown in Figure 15-9.

Figure 15-9 Testing the average transmit optical power of the single-fiber bi-directional opticalport

接口板/主控板

Optical power meter

Tx

Rx

Optical port

/TxRx Tested port

NOTE

The ports on different optical power meters may be different. Therefore, use the fiber jumper with a properconnector.

Step 2 Set the testing wavelength of the optical power meter to be the same as the working wavelengthof the tested port.



172

Step 3 Check the reading on the optical power meter. Record the value when the reading becomesstable. The value indicates the actual average transmit optical power on the port.

Step 4 Repeat Steps 3 (it is recommended to repeat more than three times), and measure and record themaximum and minimum values of the average transmit optical power. Check whether the valueof the transmit optical power meets the technical requirements.l The range of the normal average transmit optical power of the GPON uplink port is 1.5 dBm

to 5.0 dBm.l The range of the normal average transmit optical power of the EPON uplink port is 2 dBm

to 7 dBm.

NOTE

The optical interface indexes of different optical transceivers are different. Therefore, in the actual test,you need to use the actual index of the optical transceiver to determine whether the optical transceiver isnormal.

Step 5 Reconnect the fiber to the port.

----End

15.2.2 Testing the Average Transmit Optical Power on the Two-Fiber Bi-Directional Optical Port

This topic describes how to check whether the optical signal transmit module is in the normalstate by measuring the average transmit optical power in the case of bit error or interruption onthe two-fiber bi-directional optical channel.

PrerequisiteThe port to be tested must be in the idle state.

Impact on the SystemDuring the test of the average transmit optical power of the two-fiber bi-directional optical port,the port being tested cannot carry services.

Tools, Meters, and Materialsl Optical power meterl Fiber jumper with different connectors (choose proper fiber jumper according to the

requirement)

Precautions

DANGERDo not look into the optical fiber connector or the laser transmit port on the optical port boardwithout eye protection.

l Use the dBm unit of the optical power meter for the test.



173

l If the optical transceiver is a single-mode type, use the single-mode fiber jumper. If theoptical transceiver is a multi-mode type, use the multi-mode fiber jumper.

l The fiber jumper connector and the optical connector on the panel of the optical port boardmust be clean and must be connected properly.

l Use a new and short fiber jumper with a length within 1 m.l Do not break the fiber jumper. A broken fiber jumper affects the test result.

Procedure

Step 1 Connect one end of the fiber jumper to the Tx port of the port to be tested, and the other end tothe optical power meter, as shown in Figure 15-10.

Figure 15-10 Testing the average transmit optical power on the two-fiber bi-directional opticalport

接口板/主控板

Optical power meter

Tx

Rx

Port to be tested

Tx

Rx

NOTE

Select the proper fiber jumper with different connectors to meet the requirements because an optical powermeter can have different ports.

Step 2 Set the testing wavelength of the optical power meter to be consistent with the workingwavelength of the port to be tested.

Step 3 Check the reading on the optical power meter. Record the value when it becomes stable. Thevalue indicates the actual average transmit optical power.

Step 4 Repeat Steps 3 (it is recommended that you repeat more than three times), measure and recordthe maximum and minimum value of the average transmit optical power. Check whether thetested value of the optical power meets the technical requirements.l The average transmit optical power of the 100Base-FX port is -15 dBm to -8 dBm for the

single-mode port at a transmission distance of 15 km, -5 dBm to 0 dBm for the single-modeport at a transmission distance of 40 km, and -19 dBm to -14 dBm for the multi-mode portat a transmission distance of 40 km.

l The average transmit optical power of the 1000Base-Sx port is -9.5 dBm to -4.0 dBm.



174

l The average transmit optical power of the 1000Base-Lx port is -11 dBm to -3 dBm.l The average transmit optical power of the 1000Base-Zx port is -5 dBm to 0dBm for the

single-mode port at a transmission distance of 40 km, and -3 dBm to 2 dBm for the single-mode port at a transmission distance of 80 km.

NOTE



----End

15.2.3 Testing the Receiver Sensitivity of the Single-Fiber Bi-Directional Optical Port

This topic describes how to check whether the optical signal receive module is in the normalstate by measuring the receiver sensitivity when code error or service interruption occurs on thesingle-fiber bi-directional optical port.

Prerequisitel The port to be tested must be in the idle state.l Service streams must be run on the port to be tested, and must be run normally before the

code error or service interruption occurs on the single-fiber bi-directional optical port.

Impact on the SystemDuring the measurement of the receiver sensitivity of the single-fiber bi-directional optical port,the tested port cannot carry services.

Tools, Meters, and Materialsl Optical power meterl Adjustable optical attenuatorl Fiber jumper with different connectors (choose proper fiber jumper according to the

requirement)

Precautions


l Use the dBm unit of the optical power meter for the test.l The fiber jumper connector and the optical transceiver on the panel of the optical port board

must be clean and must be connected properly.



175

l Use a new and short fiber jumper with a length within 1 m.l Do not break the fiber jumper. A broken fiber jumper affects the test result.

Procedure

Step 1 Connect the device according to Figure 15-11.

Figure 15-11 Testing the receiver sensitivity of the single-fiber bi-directional optical port

光接口

Peer device

Tx

Rx

接口板/主控板

Tx

Optical portOptical port

RX/TXODFODF ODFODF

Tested port

RX/TX

optical power meter

Optical attenuator

Step 2 Set the testing wavelength of the optical power meter to be the same as the working wavelengthof the port to be tested.

Step 3 Increase the optical attenuation slowly. When a few packets are lost, decrease the opticalattenuation slowly. When no packets are lost within a short time, stop adjusting the opticalattenuation. Make sure that the adjustment is smooth and slow.

Step 4 Remove the fiber from the tested port, and connect the removed fiber to the optical power meter.Record the input optical power that is indicated on the optical power meter.

Step 5 Repeat Steps 3 and 4 (it is recommended to repeat more than three times), and obtain the averagevalue as the value of the receiver sensitivity. Then, check whether this value meets the technicalrequirements.l The range of the normal receiver sensitivity of the GPON uplink port is less than -28 dBm.l The range of the normal receiver sensitivity of the EPON uplink port is less than -27 dBm.

NOTE



----End



176

15.2.4 Testing the Receive Sensitivity on the Two-Fiber Bi-Directional Optical Port

This topic describes how to check whether the optical signal receive module is in the normalstate by measuring the receive sensitivity in the case of bit error or interruption on the two-fiberbi-directional optical channel.

Prerequisitel The port to be tested must be in the idle state.

l Service streams must be running on the port to be tested, and must be running normallybefore the occurrence of the bit error or interruption on the two-fiber bi-directional opticalchannel.

Impact on the System

During the test of the receiver sensitivity on the two-fiber bi-directional optical port, the portbeing tested cannot carry services.

Tools, Meters, and Materialsl Optical power meter

l Adjustable optical attenuator

l Fiber jumper with different connectors (choose proper fiber jumper according to therequirement)

Precautions


l Use the dBm unit of the optical power meter for the test.

l If the optical transceiver is a single-mode type, use the single-mode fiber jumper. If theoptical transceiver is a multi-mode type, use the multi-mode fiber jumper.

l The fiber jumper connector and the optical connector on the panel of the optical port boardmust be clean and connected properly.

l Use a new and short fiber jumper with a length within 1 m.

l Do not break the fiber jumper. A broken fiber jumper affects the test result.

Procedure

Step 1 Connect the device according to Figure 15-12.



177

Figure 15-12 Testing the receive sensitivity on the two-fiber bi-directional optical port

光接口

Peer device

Tx

Rx

接口板/主控板

TX

Rx

Tx

Optical interface

Optical power meter

Tx

Rx

Optical interface

TX

Rx

ODF ODF

Port to be tested

Optical attenuator

Step 2 Set the testing wavelength of the optical power meter to be consistent with the workingwavelength of the port to be tested.

Step 3 Increase the optical attenuation slowly. When a few packets are lost, decrease the opticalattenuation slowly. When no packets are lost within a short time, stop adjusting the opticalattenuation. Make sure that the adjustment is stable and slow.

Step 4 Unplug the Rx patch cord from the tested port, and connect the Rx patch cord to the opticalpower meter. Record the input optical power.

Step 5 Repeat Steps 3 and 4 (it is recommended that you repeat more than three times), and obtain theaverage value as the value of the receiver sensitivity. Then, check whether this value meets thetechnical requirements.l The average receiver sensitivity of the 100base-FX port is smaller than -31 dBm for the

single-mode port with a transmission distance of 15 km, smaller than -36 dBm for the single-mode port with a transmission distance of 40 km, and smaller than -30 dBm for the multi-mode port with a transmission distance of 40 km.

l The average receiver sensitivity of the 1000Base-Sx port is smaller than -17 dBm.l The average receiver sensitivity of the 1000Base-Lx port is smaller than -19 dBm.l The average receiver sensitivity of the 100base-Zx port is smaller than -21 dBm for the single-

mode port with a transmission distance of 40 km, and smaller than -23 dBm for the single-mode port with a transmission distance of 80 km.NOTE



----End



178

15.3 Line TestThis topic describes various line tests supported by the UA5000.

15.3.1 Analog Subscriber Circuit Line TestThis topic describes how to perform the analog subscriber (POTS subscriber) circuit line test.The circuit line test is used to test certain functions (such as ringing, power feeding, and dialtone) and parameters (such as feed voltage and ringing current voltage) of the internal circuit ofthe board. The test result is used to locate problems.

PrerequisiteThe subscriber port to be tested must not be configured with any semi-permanent connection(SPC) service.

Impact on the SystemThe circuit line test interrupts the services carried on the port to be tested.

Precautionsl To perform the analog subscriber circuit line test, configure a transfer board (that provides

the line capture function) for certain boards.l If a forced test needs to be performed on a busy port, select the mandatory test on busy

option when starting the forced test.l When the test result is abnormal, run the test-board self-test command to perform the self-

test on the TSS board to check whether the TSS board is normal. If the TSS board isabnormal, replace the board and then perform the test again.

Procedure

Step 1 In the test mode, run the testgroup set command to create a test group.For example, to create a test group for shelf 0 (the TSS board is in slot 17 of shelf 0), do asfollows:huawei(config)#testhuawei(config-test)#testgroup set 0/17

NOTE

This step is optional because the system automatically creates a test group for the shelf after the TSS boardis added to the shelf.

Step 2 In the test mode, run the display testgroup command to query the available test group.huawei(config-test)#display testgroup

Step 3 In global config mode, run the frame set command to configure the test group used on the shelfhousing the service board to be tested.For example, to configure shelf 0 to use test group 0, do as follows:huawei(config-test)#quithuawei(config)#frame set 0 testgroup 0



179

Step 4 In the test mode, run the pots circuit-test command to perform the analog subscriber circuit linetest.For example, to perform the analog subscriber circuit line test on POTS port 0/9/1, do as follows:huawei(config)#testhuawei(config-test)#pots circuit-test 0/9/1

----End

ReferenceIn many cases, the abnormality of certain functions (such as the signal tone, polarity reversal,and ringing) of the voice service is caused by the internal circuit. Therefore, the circuit line testcan be used to test whether the functions or parameters of the internal circuit are normal. Thishelps locate the problems.

15.3.2 Analog Subscriber Line TestThis topic describes how to perform the analog subscriber (POTS subscriber) line test. Theanalog subscriber line test is used to test the performance or indexes (such as the capacitanceand resistance between lines) of the subscriber line. The test result is used to locate problems.

PrerequisiteThe subscriber port to be tested must not be configured with any semi-permanent connection(SPC) service.

Impact on the SystemThe subscriber line test interrupts the services carried on the port to be tested.

Precautionsl To perform the analog subscriber line test, configure a transfer board (that provides the line

capture function) for certain boards.l If a forced test needs to be performed on a busy port, select the mandatory test on busy



Procedure

Step 1 In the test mode, run the testgroup set command to create a test group.For example, to create a test group for shelf 0 (the TSS board is in slot 17 of shelf 0), do asfollows:huawei(config)#testhuawei(config-test)#testgroup set 0/17

NOTE


Step 2 In the test mode, run the display testgroup command to query the available test group.



180

huawei(config-test)#display testgroup

Step 3 In the global config mode, run the frame set command to configure the test group used on theshelf housing the service board to be tested.For example, to configure shelf 0 to use test group 0, do as follows:huawei(config-test)#quithuawei(config)#frame set 0 testgroup 0

Step 4 In the test mode, run the pots loop-line-test command to perform the analog subscriber line test.For example, to perform the line test on POTS port 0/9/1, do as follows:huawei(config)#testhuawei(config-test)#pots loop-line-test 0/9/1

The conclusions of the analog subscriber line test are as follows:l Normal: The subscriber line is normal.l Touching the power line: The subscriber line is in touch with the electrical line.l Line A and line B mixed with other lines: Line A and line B are in touch with other subscriber

lines.l Line A mixed with other lines: Line A is in touch with other subscriber lines.l Line B mixed with other lines: Line B is in touch with other subscriber lines.l Line A and line B grounding: Line A and line B are connected to the ground.l Line A grounding: Line A is connected to the ground.l Line B grounding: Line B is connected to the ground.l Self-mixed: Line A is in touch with line B.l Poor insulation between line A and line B: The insulation between line A and line B is poor.l Creepage of line A and line B to ground: Creepage to ground occurs on line A and line B.l Creepage of line A to ground: Creepage to ground occurs on line A.l Creepage of line B to ground: Creepage to ground occurs on line B.l Telephone unconnected (line broken): The subscriber line is not connected to a phone or the

line is broken.l Persistent offhook: The phone of the subscriber is always in the offhook state.

----End

References InformationIn many cases, the voice service faults (such as no tone after offhook or noise during thecommunication) are caused by the subscriber line. Therefore, the subscriber line test is used tocheck whether the subscriber line is normal. This helps locate the problems.

15.3.3 Digital Subscriber Circuit Line TestThis topic describes how to perform the digital subscriber (ISDN BRA subscriber) circuit linetest. The circuit line test is used to test certain functions (such as activation and deactivation)and parameters (such as feed voltage) of the circuit of the board. The test result is used to locateproblems.

Prerequisitel The subscriber port to be tested must be in the idle, locked, or blocked state.



181

l The subscriber port to be tested must not be configured with any semi-permanentconnection (SPC) service.

Impact on the SystemThe circuit line test interrupts the services carried on the tested port.

Precautionsl To perform the digital subscriber circuit line test, configure a transfer board (that provides

the line capture function) for certain boards.l If a forced test needs to be performed on a busy port, select the mandatory test on busy



Procedure

Step 1 Run the testgroup set command in Test mode to create a test group.For example, to create a test group for shelf 0 (the TSS board is in slot 17 of shelf 0), do asfollows:huawei(config)#testhuawei(config-test)#testgroup set 0/17

NOTE


Step 2 Run the display testgroup command in Test mode to query the available test group.huawei(config-test)#display testgroup

Step 3 Run the frame set command in global config mode to configure the test group used by the shelfthat houses the board to be tested.For example, to configure test group 0 for shelf 0, do as follows:huawei(config-test)#quithuawei(config)#frame set 0 testgroup 0

Step 4 Run the bra circuit-test command to perform the digital subscriber circuit line test.For example, to perform the circuit line test on BRA port 0/15/0, do as follows:huawei(config-test)#bra circuit-test 0/15/0Frame 0 slot 15 port 0 ( telno - mgid 0 terminalid 0 )under testing, Please wait......

huawei(config-test)# Testing port: 0/15/0 Telno : - MGid : 0 Terminalid : 0 -------------------------------------------------------------------- Item Result -------------------------------------------------------------------- Active Abnormal Deactive Normal LT supply power (V) 93.300 LT current protect LT current not protect Cut line voltage (V) 56.853



182

Switch on voltage (V) 93.300 Conclusion Abnormal --------------------------------------------------------------------

----End

ReferencesIn many cases, the abnormality of the ISDN BRA service is caused by the internal circuit.Therefore, the circuit line test can be used to test whether the functions or parameters of theinternal circuit are normal. This helps locate the problems.

In the preceding test result:l Test items Active and Deactive indicate whether the circuits for implementing the

activation and deactivation functions on the DSL board are normal. (Activation/deactivation here means the establishment/interruption of the physical layercommunication of the U interface between the network side and the subscriber side.)

l If the LT supply power, Cut line voltage, and Switch on voltage tests are successful, theactual values for the three items are displayed.

l Test item LT current protect indicates whether the tested port supports the overcurrentprotection function and whether the system can be restored after overcurrent protection.

15.3.4 Digital Subscriber Line TestThis topic describes how to perform the digital subscriber (ISDN BRA subscriber) line test. Thedigital subscriber line test is used to test the performance or indexes (such as the capacitanceand resistance between lines) of the subscriber line. The test result is used to locate problems.

Prerequisitel The user port to be tested must be in the idle, locked, or blocked state.l The user port to be tested must not be configured with any semi-permanent connection

(SPC) service.

Impact on the SystemThe subscriber line test interrupts the services carried on the tested port.

Precautionsl To perform the digital subscriber line test, configure a transfer board (that provides the line

capture function) for certain boards.l If a forced test needs to be performed on a busy port, select the mandatory test on busy



Procedure

Step 1 Run the testgroup set command in Test mode to create a test group.For example, to create a test group for shelf 0 (the TSS board is inserted in slot 17 of shelf 0),do as follows:



183

huawei(config)#testhuawei(config-test)#testgroup set 0/17

NOTE


Step 2 Run the display testgroup command in Test mode to query the available test group.huawei(config-test)#display testgroup

Step 3 Run the frame set command in global config mode to configure the test group used by the shelfthat houses the board to be tested.For example, to configure test group 0 for shelf 0, do as follows:huawei(config-test)#quithuawei(config)#frame set 0 testgroup 0

Step 4 Run the bra loop-line-test command to perform the digital subscriber line test.For example, to perform the subscriber line test on BRA port 0/15/0, do as follows:huawei(config-test)#bra loop-line-test 0/15/0Frame 0 slot 15 port 0 ( telno - mgid 0 terminalid 0 )under testing, Please wait......

huawei(config-test)# Testing port: 0/15/0 Telno : - MGid : 0 Terminalid : 0 ------------------------------------------------------------------------- Test item Result ------------------------------------------------------------------------- A->ground AC voltage (V) 0.098 B->ground AC voltage (V) 0.098 A->B AC voltage (V) 0.000 A->ground DC voltage (V) 0.009 B->ground DC voltage (V) 0.006 A->B DC voltage (V) 0.003 A->ground insulation resistance (ohm) >10M B->ground insulation resistance (ohm) >10M A->B insulation resistance (ohm) >10M A->ground capacitance (uF) 0.008 B->ground capacitance (uF) 0.008 A->B capacitance (uF) 0.006 Conclusion No NT1 -------------------------------------------------------------------------

The conclusions of the digital subscriber line test are as follows:l Normal: The subscriber line is normal.l Contact with the power line: The subscriber line is in touch with the electrical line.l Mixed with others (two lines): Line A and line B are in touch with other subscriber lines.l A line mixed with others: Line A is in touch with other subscriber lines.l B line mixes with others: Line B is in touch with other subscriber lines.l AB grounding: Line A and line B are connected to the ground.l A line grounding: Line A is connected to the ground.l B line grounding: Line B is connected to the ground.l Self-mixed: Line A is in touch with line B.l A-B poor insulation: The insulation between line A and line B is poor.l AB ground leakage: Electrical leakage to ground occurs on line A and line B.



184

l A-ground leakage: Electrical leakage to ground occurs on line A.l B-ground leakage: Electrical leakage to ground occurs on line B.l No NT1: The subscriber line is not connected to a phone or the subscriber line is broken.l Off-hook: The phone of the subscriber is always in the offhook state.

----End

ReferencesIn many cases, the abnormality of the ISDN BRA service is caused by the subscriber line.Therefore, the subscriber line test is used to test whether the subscriber line is normal. This helpslocate the problems.

15.3.5 Meter TestThis topic describes how to perform the meter test for the analog subscriber (POTS subscriber)and digital subscriber (ISDN BRA subscriber). The meter test is used to test certain items forthe circuit and subscriber line tests by using external meters such as the digital multimeter, ratherthan the TSS board.

Prerequisitel The subscriber port to be tested must be in the idle, locked, or blocked state.l The subscriber port to be tested must not be configured with any semi-permanent

connection (SPC) service.

Tools, Meters, and Materialsl Serial port linel Meter, such as the digital multimeter (use a proper meter according to the specific test item)

Impact on the SystemThe meter test interrupts the services carried on the tested port.

Precautionsl To perform the meter test, configure a transfer board (that provides the line capture

function) for certain boards.l Reset the meter at zero before the test.

ProcedureStep 1 Connect the serial port line to the corresponding port (on the panel of the TSS board) that is

connected to the meter.

The TSS board provides the MTI, ISDN, and LTI ports on the panel, and all of the ports can beconnected to the external meter. For the use of the ports and cable connectors, see TSSB Board.

Step 2 Start the meter test.For example, to test the ringing current voltage (which is a circuit line test item) on POTS port0/9/1 by using the meter test method, do as follows:huawei(config)#test



185

huawei(config-test)#pots meter-test 0/9/1 type 0For example, to test the loop resistance ("A->B loop resistance", which is a subscriber line testitem) on ISDN BRA port 0/15/0 by using the meter test method, do as follows:huawei(config)#testhuawei(config-test)#bra meter-test 0/15/0 type 1

Step 3 Read the test result.

Step 4 Stop the meter test.For example, to stop the meter test on POTS port 0/9/1, do as follows:huawei(config-test)#undo pots meter-test 0/9/1For example, to stop the meter test on ISDN BRA port 0/15/0, do as follows:huawei(config-test)#undo bra meter-test 0/15/0

----End

15.3.6 Single Ended Loop TestThe single ended loop test (SELT) is started from the central office (CO) and it does not requirethe cooperation of terminal devices. That is, an xDSL modem does not need to be connected onthe user side). In SELT, the UA5000 sends test signals from the device side, and then analyzesline parameters according to the signals returned from the device. The line parameters that canbe tested include the line length, attainable rate of the line, and signal to noise ratio (SNR) margin.

PrerequisiteThe service board on which the port to be tested must be normal. You can run the displayboard command to query the status of the board.

Precautionsl Only one port can perform SELT at a time in the system.l Ensure that the peer end of the line is not connected to the modem during the test. Otherwise,

the test result may be inaccurate.

NetworkingFigure 15-13 and Figure 15-14 show the example network of the SELT.

Figure 15-13 Example network of the SELT (ADSL)

UA5000

CSRB

IPMB

Transfer board

300-2800 m



186

Figure 15-14 Example network of the SELT (VDSL)

UA5000

VDMB

IPMB

300m～2800m

Procedurel This section considers ADSL2+ port 0/12/0 as an example for the networking shown in

Figure 15-13.1. Deactivate the port to be tested.

huawei(config)#interface adsl 0/12huawei(config-if-adsl-0/12)#deactivate 0

2. Start the SELT.huawei(config-if-adsl-0/12)#adsl selt 0

l This section considers VDSL2+ port 0/12/3 as an example for the networking shown inFigure 15-14.1. Deactivate the port to be tested.

huawei(config)#interface vdsl 0/12huawei(config-if-vdsl-0/12)#deactivate 3

2. Start the SELT.huawei(config-if-vdsl-0/12)#vdsl selt 3

----End

Test ResultYou can find the test result of the SELT reported by the system on the CLI within three minutesafter the SELT is started. You can also run the display adsl selt command to query the test resultof the SELT.

15.4 Configuring the File Transfer ModeThis topic describes how to configure the file transfer modes such as Xmodem and Trivial FileTransfer Protocol (TFTP).

15.4.1 Configuring Xmodem File Transfer ModeThis topic describes how to configure the Xmodem file transfer mode. To upload or downloadfiles through the maintenance serial port on the UA5000, configure the Xmodem file transfer



187

mode according to this operation guide. Then, the console and the UA5000 can communicatewith each other normally and transfer files in Xmodem mode.

PrerequisiteYou must be logged in to the UA5000 from the console (also called maintenance terminal)through the serial port, and must enter the global config mode.

Tools, Meters, and MaterialsRS-232 serial port cable (used for logging in to the UA5000 from the console through the serialport)

Impact on the SystemNone

PrecautionsNOTE

l The speed of transferring files in Xmodem mode through the serial port is limited. Therefore, the systemdoes not support file transfer in the Xmodem mode for large-size files such as program packet filesand configuration files.

l It is recommended to tranfer files through other modes as much as possible, such as TFTP, even if filetransfer in the Xmodem mode is supported.

l The baud rate of the serial port on the UA5000 must be the same as the baud rate of theserial port on the console.

l The Xmodem transfer mode is applicable to only the active control board.l Telnet users are prohibited from transferring files in Xmodem mode.

Procedure

Step 1 Query the baud rate of the serial port on the UA5000.huawei(config)#display baudrate Current active serial baudrate: 9600 bps

Step 2 (This step is optional but is required when you reconfigure the baud rate of the serial port.) Runthe baudrate command on the UA5000 to configure the baud rate of the serial port on theUA5000. The high baud rate can increase the transmission speed.For example, reconfigure the baud rate on the UA5000 to 9600 bit/s:huawei(config)#baudrate 9600

Step 3 Open the HyperTerminal on the console to configure the baud rate of the serial port on theconsole to be the same as the baud rate on the UA5000.



188

----End

15.4.2 Configuring the FTP File Transfer ModeThis topic describes how to configure the File Transfer Protocol (FTP) file transfer mode. Whentransferring files (uploading or downloading files) through the inband or outband network porton the UA5000, you can configure the FTP file transfer mode according to this operation guideto implement the communication between the FTP server and the UA5000, and thusimplementing the file transfer in FTP mode.

PrerequisiteYou must log in to the UA5000 from the console (also called maintenance terminal) in telnetmode, and must enter the global config mode.


Procedure

Step 1 Configure the IP address of the Ethernet port on the FTP server.

Configure the IP address of the Ethernet port on the FTP server according to the IP addressplanning of the actual networking. Ensure that the Ethernet port on the FTP server can ping theinband or outband network port on the UA5000 from each other successfully.



189

For example, if the Ethernet port on the FTP server is directly connected to the outband networkport on the device, the IP address of this Ethernet port must be in the same subnet as the IPaddress of the outband network port on the device.

Step 2 Run the FTP application on the FTP server and configure the required parameters.

The following content considers FTP tool Wftpd32.exe as an example to describe how toconfigure the required parameters. In this example, the user name is ftpuser, the password isftp123, and the root directory for saving the file is D:\.

1. After running the FTP program on the FTP server, choose Security > Users/rights... in thedialog box that is displayed.

2. In the User/Rights Security Dialog box, click New User... to create a user. Then, the NewUser dialog box is displayed.

3. In the User Name text box, enter ftpuser.

4. Click OK.NOTE

The users created in the system must be unique. Therefore, if you create a user with a name thatalready exists in the system, the system displays a prompt This user already exists!

5. Enter ftp123 in the New Password text box, and enter the password again in the VerifyPassword text box to confirm the password. Then, click OK.

6. Return to the User/Rights Security Dialog box, and enter D:\ in the Home Directory textbox.



190

7. click Done.

Step 3 (When you need to configure manual file transfer, perform this operation.) Run the ftp setcommand on the UA5000 to configure the FTP user name and password.huawei(config)#ftp set User Name(<=40 chars):ftpuser //The name must be the same as the user name configured on the FTP server. User Password(<=40 chars):ftp123 //The input is not displayed on the CLI, but the password must be the same as the password configured on the FTP server.

NOTE

The default FTP user name and password of the UA5000 are anonymous and [email protected].

Step 4 (When you need to configure automatic file transfer, perform this operation.) Run the file-server command on the UA5000 to configure the FTP user name, password, and port ID.

For example, to configure the function of automatically backing up the database file, do asfollows (assume that the IP address of the FTP server is 10.10.20.1 and the backup file is savedin folder test):huawei(config)#file-server auto-backup data primary 10.10.20.1 ftp path test user User Name(<=40 chars):ftpuser //The name must be the same as the user name configured on the FTP server. User Password(<=40 chars):ftp123 //The input is not displayed on the CLI, but the password must be the same as the password configured on the FTP server.

NOTE

The device with the PVM control board does not support the function of automatically backing up thedatabase file and therefore does not support this configuration.

----End

Referencesl Any PC that runs the FTP software can be used as an FTP server.

l The user name and password need to be verified during file transfer through the FTPprotocol. The user name and password must be configured on both the FTP server and theFTP client (such as the UA5000) and the user name and password configured on the FTPclient must be consistent with the user name and password configured on the FTP server.

15.4.3 Configuring TFTP File Transfer ModeThis topic describes how to configure the TFTP file transfer mode. To upload and downloadfiles through the inband or outband Ethernet port on the UA5000, configure the TFTP transfermode according to this operation guide. Then, the TFTP server and the UA5000 cancommunicate with each other normally and transfer files in TFTP mode.



191

Prerequisite

You must be logged in to the UA5000 from the console (also called maintenance terminal) inthe Telnet mode, and must enter the global config mode.


None

Procedure

Step 1 Configure the IP address of the Ethernet port on the TFTP server.

Configure the IP address of the Ethernet port on the TFTP server according to the IP addressplanning of the actual networking. Ensure that the Ethernet port on the TFTP server can pingthe inband or outband Ethernet port on the UA5000 from each other successfully.

For example, if the Ethernet port on the TFTP server is directly connected to the outband Ethernetport on the device, the IP address of this Ethernet port must be in the same subnet as the IPaddress of the outband Ethernet port on the device.

Step 2 Run the TFTP application on the TFTP server and configure the required parameters.1. Run the TFTP application on the TFTP server to display the interface as shown in Figure

15-15. Select the IP address that is configured in step 1 from the Server interfaces drop-down list.

Figure 15-15 TFTP application interface

2. On the interface as shown in Figure 15-15, click Settings.3. In the dialog box that is displayed, click Browse to select the path for saving files, as shown

in Figure 15-16.



192

Figure 15-16 Configuring TFTP parameters

----End

Referencel Any PC that runs the TFTP software can be used as a TFTP server.l The IP address in the Server interfaces drop-down list is the IP address of the TFTP server.

The TFTP application can automatically identify the IP address of the TFTP server. If theTFTP server has multiple IP addresses, select the correct one.

l If the file transfer in TFTP mode fails, check the following aspects:– Whether the selected IP address of the TFTP server is correct.– Whether the IP address of the TFTP server can ping the IP address of the inband or

outband Ethernet port on the UA5000 successfully through the Ping command.– Whether the TFTP application runs on the TFTP server.– Whether the directories in the TFTP application are configured correctly.– Whether the entered file name is correct.

15.4.4 Configuring the SFTP File Transfer ModeThis topic describes how to configure the Secure File Transfer Protocol (SFTP) file transfermode. When transferring files (uploading or downloading files) through the inband or outbandnetwork port on the UA5000, you can configure the SFTP file transfer mode according to this



193

operation guide to implement the communication between the SFTP server and the UA5000,and thus implementing the file transfer in SFTP mode.

PrerequisiteYou must log in to the UA5000 from the console (also called maintenance terminal) in telnetmode, and must enter the global config mode.


Procedure

Step 1 Configure the IP address of the Ethernet port on the SFTP server.

Configure the IP address of the Ethernet port on the SFTP server according to the IP addressplanning of the actual networking. Ensure that the Ethernet port on the SFTP server can pingthe inband or outband network port on the UA5000 from each other successfully.

For example, if the Ethernet port on the SFTP server is directly connected to the outband networkport on the device, the IP address of this Ethernet port must be in the same subnet as the IPaddress of the outband network port on the device.

Step 2 Run the SFTP application on the SFTP server and configure the required parameters.

The following content considers SFTP tool msftpsrvr.exe as an example to describe how toconfigure the required parameters. In this example, the user name is sftpuser, the password issftp123, and the root directory for saving the file is D:\.

1. After running the SFTP program on the SFTP server, configure the user name, password,port number, and root directory in the Core FTP mini-sftp-server dialog box, as shownin the following figure.

2. click Start.

Step 3 (When you need to manually configure file transfer, perform this operation.) Run the ssh sftpset command on the UA5000 to configure the SFTP user name, password, and port ID.huawei(config)#ssh sftp set User Name(<=40 chars):sftpuser //The name must be the same as the user name configured on the SFTP server.



194

User Password(<=40 chars):sftp123 //The input is not displayed on the CLI, but the password must be the same as the password configured on the SFTP server. Listening Port(0--65535):22 //The port number must be the same as the port number configured on the SFTP server.

NOTE

The UA5000 does not have the default SFTP user name, password, or port ID.

Step 4 (When you need to configure automatic file transfer, perform this operation.) Run the file-server command on the UA5000 to configure the SFTP user name, password, and port ID.For example, to configure the function of automatically backing up the database file, do asfollows (assume that the IP address of the SFTP server is 10.10.20.1 and the backup file is savedin folder test):huawei(config)#file-server auto-backup data primary 10.10.20.1 sftp path test user User Name(<=40 chars):sftpuser //The name must be the same as the user name configured on the SFTP server.

User Password(<=40 chars):sftp123 //The input is not displayed on the CLI, but the password must be the same as the password configured on the SFTP server.

NOTE

The device with the PVM control board does not support the function of automatically backing up thedatabase file and therefore does not support this configuration.

----End

Referencesl Any PC that runs the SFTP software can be used as an SFTP server.l The user name and password need to be verified during file transfer through the SFTP

protocol. The user name, password, and port ID must be configured on both the SFTP serverand the SFTP client (such as the UA5000) and must be consistent with the user name,password, and port ID configured on the SFTP server.

15.5 Backing Up the Database FileThis topic describes how to back up the database file.

15.5.1 Backing Up the Database File ManuallyThis topic describes how to back up the database file manually. The database file can be backedup either manually or automatically by the system. (The device with the PVM control boarddoes not support the automatic backup.)

PrerequisiteFile transfer mode to be used must be configured. The "specified server" mentioned in thefollowing text refers to the file server specified in the configuration. For details of theconfiguration, see 15.4 Configuring the File Transfer Mode.

Tools, Meters, and MaterialsFor the tools required in the file transfer in different modes, see 15.4 Configuring the FileTransfer Mode.



195


None

Precautions

None

Procedurel Method 1 (Refer to this method if the function of automatically backing up the database

file is not configured.)1. Run the save data command to save the database file.

huawei(config)#save data

2. Run the backup data command to manually back up the database file to the specifiedserver.For example, to manually back up the database file in Xmodem mode, do as follows:

(1) Start the backup on the UA5000.huawei(config)#backup data xmodem Current baud rate is 9600bps, and it can be modified by 'baudrate' command Are you sure to use this baud rate? (y/n)[n]:y

(2) On the HyperTerminal of the console, choose Transfer > Receive file from themain menu. Then, in the dialog box that is displayed, set the path for the file tobe saved and select Xmodem for the receiving protocol.

For example, to manually back up the database file in FTP mode, with the IP addressof the FTP server 10.10.20.1, do as follows:huawei(config)#backup data ftp 10.10.20.1 huawei.dat

For example, to manually back up the database file in TFTP mode, with the IP addressof the TFTP server 10.10.20.2, do as follows:huawei(config)#backup data tftp 10.10.20.2 huawei.dat

For example, to manually back up the database file in SFTP mode, with the IP addressof the SFTP server 10.10.20.3, do as follows:huawei(config)#backup data sftp 10.10.20.3 huawei.dat

3. Run the display progress backup command to query the backup progress.huawei(config)#display progress backup

4. Check the file backed up in the corresponding path on the server. The name of thebacked up file is the same as the configured file name.

l Method 2 (Refer to this method if the function of automatically backing up the databasefile is configured; this method cannot be adopted for the device with the PVM control boardbecause it does not support the function of automatically backing up the database file.)1. Run the save data command to save the database file.

huawei(config)#save data

2. Run the auto-backup period data disable command to disable the function ofautomatically backing up the database file.huawei(config)#auto-backup period data disable

3. Run the auto-backup manual data command to manually back up the database fileto the specified server.huawei(config)#auto-backup manual data



196

NOTE

The specified server here is the server configured in Backing Up the Database FileAutomatically.

4. You can find the manually backed up file on the server.

----End

15.5.2 Backing Up the Database File AutomaticallyThis topic describes how to back up the database file automatically. The database file can bebacked up either manually or automatically by the system. (The device with the PVM controlboard does not support the automatic backup.)

PrerequisiteFile transfer mode to be used must be configured. The file server specified for configuration isthe "automatic backup server". For details of the configuration, see 15.4 Configuring the FileTransfer Mode.

Tools, Meters, and MaterialsFor the tools required in the file transfer in different modes, see 15.4 Configuring the FileTransfer Mode.


PrecautionsRun the save data command to save the database file. Optionally, run the autosave interval orautosave time command to configure the function of automatically saving the data.

Procedure

Step 1 Run the auto-backup period data enable command to enable the function of automaticallybacking up the database file.huawei(config)#auto-backup period data enable

Step 2 Run the auto-backup period data command to configure the period and the start time forautomatically backing up the database file.For example, to configure the period for automatically backing up the database file to two days,and the start time for the backup to 21:00, do as follows:huawei(config)#auto-backup period data interval 2 time 21:00

Step 3 You can find the automatically backed up file on the server at the specified time.

----End

15.6 Resetting the SystemThis topic describes how to reset the system.



197

PrerequisiteThe power supply of the device must be normal.

Impact on the SystemResetting the system causes the loss of the data that is not saved and interrupts all the ongoingservices (including the Telnet communication between the UA5000 and the remote maintenanceterminal, and the communication between the UA5000 and the NMS).

Precautions

CAUTIONResetting the system interrupts the ongoing service. Therefore, reset the system only whennecessary. In general, reset the system after a new program or database is loaded.

If the database of the system is blank, the system reset takes about four minutes. If the databaseof the system is in full configuration, the system reset takes about 15 minutes. After the reset,you can log in to the system to maintain the device.

Procedure

Step 1 Run the save command to save the current database file and configuration file of the system.

Step 2 Run the reboot system command to reset the system.

If the system cannot be reset through the CLI, it is recommended that you wait for three to fiveminutes, and then perform operations according to the prompts. If the problem persists, in thecase that only one control board is configured, proceed with Step 3 to reset the system forcibly.This may cause certain problems such as data loss.

Step 3 Press the reset button on the front panel of the control board to reset system by resetting thecontrol board.

----End

15.7 Resetting the Control BoardThis topic describes how to reset the control board.

PrerequisiteThe power supply of the device must be normal.

Impact on the Systeml When the system is configured with an active control board and a standby control board:

– Resetting the active control board is equivalent to Active/Standby Switchover.– Resetting the standby control board has no impact on the system.



198

l When the system is configured with only one control board, resetting the control board isequivalent to Resetting the System. For the impact on the system in this case, see "Impacton the System" in Resetting the System.

Precautions

CAUTIONResetting the control board may interrupt the ongoing service. Therefore, reset the control boardonly when necessary.

l The board reset command cannot be used to reset the control board.l When the system is configured with only one control board, resetting the control board is

equivalent to Resetting the System. For the precautions in this case, see "Precautions" inResetting the System.

Procedure


Step 2 (This step is optional but is required when you need to reset the active control board.) Run thereboot active command to reset the active control board.

Step 3 (This step is optional but is required when you need to reset the standby control board.) Run thereboot standby command to reset the standby control board.

----End

15.8 Active/Standby SwitchoverThis topic describes how to perform the active/standby switchover manually (forcible active/standby switchover).

Prerequisitel An active control board and a standby control board must be configured on the device, and

the cables on the boards must be connected correctly.l The patch status and hardware environment of the active control board must be the same

as the patch status and hardware environment of the standby control board.

NOTE

l When the active control board is faulty but the standby control board is normal, the system performsthe active/standby switchover automatically.

l To replace the control board, you can perform the active/standby switchover manually.


After the active/standby switchover, the board in the auto-find state is reset and other serviceboards remain in the status before the switchover.



199

Precautions

CAUTIONThe active/standby switchover affects the ongoing or connecting services to certain extent.Therefore, perform this operation when the traffic is light.

l When the data is being loaded, saved, copied, or erased, the active/standby switchover isprohibited.

l When the communication between the active and standby control boards fails, the standbycontrol board does not exist, or the standby control board is faulty, the active/standbyswitchover is prohibited.

l When the status of any board changes (change duration: two minutes in general), the active/standby switchover is prohibited.

l When the configuration data and basic running data of the active and standby control boardsis not fully synchronized, or the cyclic redundancy check (CRC) results of the active andstandby control boards are different, the active/standby switchover is prohibited.

l When the dynamic data synchronization between the active and standby control boards isnot fully executed, the system cannot perform automatic active/standby switchover. In thiscase, you can perform forcible active/standby switchover, but this may cause the data loss.Therefore, this operation is not recommended.

Procedure


Step 2 Run the display data sync state command to query the status of the data synchronizationbetween the active and standby control boards.l if all the data is synchronized, proceed with Step 3.l Otherwise, wait for the system to complete data synchronization. During this period, you

can repeat this step every several minutes to check the data synchronization status.

Step 3 After the data synchronization, run the system switch-over command to perform the active/standby switchover manually.

Step 4 Check the switchover result.l After the active/standby switchover is successful, the ACT LED on the original standby

control board is on. This indicates that the original standby control board now functions asthe active control board and that the original active control board functions as the standbycontrol board.

l After the active/standby switchover is successful, run the display board 0 command to querythe status of each board. The result shows that the original standby control board nowfunctions as the active control board and the original active control board functions as thestandby control board.

l After the active/standby switchover is successful, the board in the auto-find state is reset andother service boards remain in the status before the switchover.

----End



200

ReferenceFor details of the active/standby switchover, see "Active/Standby Switchover" in the UA5000Feature Description.

15.9 Cleaning the Connector of the Optical FiberThis topic describes how to clean the connector of the optical fiber. Frequent insert and removeor no dust-proof treatment for a longtime causes the connector to be dirty and aged, which resultsin deterioration of the line quality. Therefore, you need to periodically clean the connector ofthe optical fiber, including the ends of the optical fiber connector, optical port of the opticaltransceiver, and adapter, and take measures to prevent dust.

PrerequisiteCleaning tools must be prepared before cleaning, and "Precautions" must be followed.

Tools, Meters, and Materialsl Dust-free cotton: It is a long silk cotton specially used for cleaning the ends of the optical

fiber connector.l Dust-free bar: It is used for cleaning the optical port of the optical transceiver and adapter

(flange). It has two specifications: ф2.5 mm and ф1.25 mm. You can select one accordingto the port type (use the dust-free bar with ф2.5 mm for the ports of SC and FC types, anduse that with ф1.25 mm for the ports of LC and MTRJ types).

l Dust-proof cap: It is used for ends of the optical connector, optical port of the opticaltransceiver, and adapter.

l Cleaning tool box: It is used for placing the dust-free cotton and the dust-free cap. Placethe dust-free cotton and the dust-free cap separately from other tools.

l Cleaning reagent (alcohol) : It is used for cleaning the connector of the optical fiber. It isinflammable, and must be securely saved and kept clean.

l Optical fiber section magnifier: It is a microscope (400*) used for checking whether theends of the optical fiber connector is clean and without damage.

Impact on the SystemThe optical transceiver needs to be powered off before you clean the connector of the opticalfiber. In this case, servers carried on the optical port will be interrupted.

Precautions

DANGERl Do not look directly into the optical fiber connector or the laser transmit port on the optical

port board without eye protection. Exposure of the combustible to the laser light must beavoided.

l Do not clean any optical module before powering off the optical transceiver.



201

l To clean the optical transceiver that can be removed and inserted, wear an ESD wrist strapor wear ESD gloves.

l Put the dust-free cap into the cleaning tool box immediately after taking it off. Place thedust-free cap not used in the cleaning tool box, or in the ESD bag for sealed save. Clean itquarterly (it is recommended to clean it with the ultrasonic cleaner).

l Keep your hands clean and dry before tailoring the dust-free cotton, and place the dust-freecotton not used in the clean ESD bag or the cleaning tool box for sealed save.

l After the cleaning, cover the optical fiber connector, optical transceiver, and adapter thatwill not be immediately used with the dust-free caps.

ProcedureStep 1 Clean the ends of the optical fiber connector.

1. Clip a piece of dust-free cotton into 32 clips with the same size.2. Use two clips of dry dust-free cotton (double-layer) to clean the ends of the optical fiber

connector along one direction for one time. For the dirty connector, use the clips of dust-free cotton (two-layer) dipped with little cleanser to clean the ends of the optical fiberconnector along one direction for one time. Use another dry dust-free cotton clip to cleanthe ends of the optical fiber connector along one direction once. Make sure that the endsof the optical fiber connector is dry.

NOTEDon not cyclically use the dust-free cotton. Use the dust-free cotton not touched by your hands.

3. After the cleaning, cover the optical fibers that will not be immediately used with the dust-free caps.

Step 2 Clean the optical port of the optical transceiver.1. If the optical transceiver can be removed and inserted, wear ESD gloves or an ESD wrist

strap to remove it.2. Select dust-free cotton bars with different diameters according to the type of the optical

port, dip one bar with the cleaning reagent, insert the bar into the inner of the optical port,and then clean it by rotating the bar 360 degrees along the inner wall of the optical port.

3. Use another dry dust-free cotton bar with the same diameter to insert it into the optical port,and then clean it by rotating the bar 360 degrees along the inner wall of the optical port.

4. After the cleaning, cover the optical fibers that will not be immediately used with the dust-free caps. Wear the ESD gloves or ESD wrist strap to insert the optical transceiver securelyat the place where it is removed.

Step 3 Clean the adapter (flange).1. Select dust-free cotton bars with different diameters according to the type of the adapter,

insert one bar into the sleeve of the adapter, and then clean it by rotating the bar 360 degreesalong the inner wall of the sleeve.

2. Use another dry dust-free cotton bar with the same diameter to insert it into the sleeve ofthe adapter, and then clean it by rotating the bar 360 degrees along the inner wall of thesleeve.

NOTEUse the ultrasonic cleaner to clean the adapters that need to be cleaned uniformly.

3. After the cleaning, cover the optical fibers that will not be immediately used with the dust-free caps.

----End



202

15.10 Checking the Optical Fiber LinkThis topic describes how to check the optical fiber link on the upstream optical port on theUA5000. In the case of optical signal interruption, bit error, and abnormality alarm report, youcan locate and troubleshoot the fault by checking the connection of the optical fiber and testingthe quality of the optical fiber link. This operation can also be used as a maintenance item forperiodical check.

Prerequisite

Traffic streams must exist on the optical fiber link.

Tools, Meters, and Materialsl Optical power meterl Optical time domain reflectometer (OTDR)

NOTEThe preceding meters are commonly used meters for checking the optical fiber link for your reference only.


None

Precautions

CAUTIONDo not look directly into the optical fiber connector or the laser transmit port on the optical portboard without eye protection.

Procedure

Step 1 Check the connection of the OUT port on the optical splitter, the connection of the upstreamoptical port on the UA5000, and the connections of other physical ports on the entire opticallink. Ensure that the connection is proper.

Step 2 Check whether the optical ports (the OUT port on the optical splitter, the optical fiber connector,the adapter, and the upstream optical port on the UA5000) are clean. If they are dirty, clean themin time. For the detailed procedure, see 15.9 Cleaning the Connector of the Optical Fiber.

Step 3 Check the line quality by using link check tools (such as the optical power meter and the OTDR).That is, test the optical attenuation values at two ends of the OUT port on the optical splitter,the optical fiber, or other optical ports (including the cold connection point, fusion point, activeconnector, and quick connector) to check whether the optical attenuation values comply withthe standard. For detailed reference values, see the optical attenuation parameters in References.If the optical attenuation value is too great, it indicates that the optical fiber is damaged or aged,or the optical port is damaged. In this case, replace the optical fiber in time.



203

Step 4 Test the receive and transmit optical powers of the upstream optical port on the UA5000. Forthe detailed procedure, see 15.2 Performing a Test on the Optical Port. If the receive andtransmit optical powers of the optical transceiver do not comply with the standard, use anotheroptical transceiver for test. For the procedure for changing the optical transceiver, see Replacingthe Optical Transceiver.

Step 5 Verify the result of testing the optical fiber link.

The connection of the optical fiber recovers to the normal state, and a recovery alarm is generated.The optical attenuation values tested by the link check tools comply with the standard.

----End

ReferencesDescription of optical attenuation parameters

Table 15-3 Optical attenuation parameters

Item Type Average Loss (dB)

Connection point Cold connection ≤ 0.2

Fusion connection ≤ 0.1

Active connector ≤ 0.3

Quick connector < 0.5

Optical splitter 1:64 (PLC) ≤ 20.5

1:32 (PLC) ≤ 17

1:16 (PLC) ≤ 13.8

1:8 (PLC) ≤ 10.6

1:4 (PLC) ≤ 7.5

1:2 (FBT) ≤ 3.8

Optical fiber (G.652D) 1310 nm (1 km) ≤ 0.35

1550 nm (1 km) ≤ 0.21

Optical fiber (G.657A) 1310 nm (1 km) ≤ 0.38

1550 nm (1 km) ≤ 0.25

Description of the link test meter

l Optical power meter (ordinary optical power meter): Only the upstream or downstreamoptical power can be tested at a time. The properly connected line needs to be disconnectedduring the test.

l OTDR: Implements single-end zero-loss test. This meter, featuring high test speed andaccurate fault location, can accurately test the attenuation values of the line, fusion



204

connection point, optical splitter, and adapter. The OTDR is mainly used for checking theline quality and locating the fault on the line.

15.11 Mirroring Packet Capture (IPM)The IPM device provides the mirroring packet capture function on the Ethernet upstream port.Through the mirroring packet capture function, you can obtain packets. Based on the analysisof the packets, you can determine whether the service interaction between the device and theinterconnected device is normal.

Prerequisitel You have logged in to the system by using the operator account or a user account at a higher

level.l The PC used for packet capture must be properly connected to the destination mirroring

port through the network cable and the PC must be installed with the packet capture tool,such as Ethereal. If the destination mirroring port is an optical port, you can use an O/Econverter for signal conversion.


PrecautionsAfter the operation of mirroring packet capture is complete, disable the mirroring packet capturefunction on the port in time.

Procedure

Step 1 In global config mode, run the interface ipm command to enter IPM mode.

Step 2 Run the mirror port command to configure the mirroring packet capture function on the port.

Step 3 (Optional) Run the display mirror command to check whether the mirroring packet capturefunction is configured on the port successfully.

Step 4 Start the packet capture tool to capture packets until the packet capture operation is complete.

Step 5 Run the undo mirror port command to disable the mirroring packet capture function on theport.

Step 6 (Optional) Run the display mirror command to check whether the mirroring packet capturefunction is disabled on the port successfully.

----End

15.12 Mirroring Packet Capture (PVM)The PVM device provides the mirroring packet capture function on the Ethernet upstream port.Through the mirroring packet capture function, you can obtain packets. Based on the analysisof the packets, you can determine whether the service interaction between the device and theinterconnected device is normal.



205

Prerequisitel You have logged in to the system by using the operator account or a user account at a higher

level.

l The PC used for packet capture must be properly connected to the destination mirroringport through the network cable and the PC must be installed with the packet capture tool,such as Ethereal. If the destination mirroring port is an optical port, you can use an O/Econverter for signal conversion.


None

Precautions

After the operation of mirroring packet capture is complete, disable the mirroring packet capturefunction on the port in time.

Procedure

Step 1 In global config mode, run the diagnose command to enter Diagnose mode.

Step 2 Run the port mirror command to configure the mirroring packet capture function on the port.

Step 3 (Optional) Run the display mirror state command to check whether the mirroring packetcapture function is configured on the port successfully.

Step 4 Start the packet capture tool to capture packets until the packet capture operation is complete.

Step 5 Run the undo port mirror command to disable the mirroring packet capture function on theport.

Step 6 (Optional) Run the display mirror state command to check whether the mirroring packetcapture function is disabled on the port successfully.

----End

15.13 Changing the Line Profile or Line Template of anxDSL Port

This topic describes how to change the line profile or line template bound to an xDSL port whenthe line profile of the ADSL2+ or SHDSL port or the line template of the VDSL2 port cannotmeet the requirement for the service.

Prerequisite

None


The port needs to be deactivated. As a result, the service carried by the port is interrupted.



206

Precautions

None

Procedurel Change the line profile of the ADSL2+ port.

1. Run the interface adsl command to enter the ADSL mode.

2. Run the display adsl line-profile command to check whether a line profile that meetsthe requirement exists in the system.

– If a line profile that meets the requirement exists in the system, run thedeactivate command to deactivate the port whose line profile needs to be changed.Then, run the activate command to activate the port and bind the port with the lineprofile that meets the requirement.

– If no line profile that meets the requirement exists in the system, run the adsl line-profile add command to add a new line profile that meets the requirement. Then,run the deactivate command to deactivate the port whose line profile needs to bechanged. Lastly, run the activate command to activate the port and bind the portwith the new profile.

l Change the line profile of the SHDSL port.

1. Run the interface sdl command to enter the SHDSL mode.

2. Run the display shdsl line-profile command to check whether a line profile that meetsthe requirement exists in the system.

– If a line profile that meets the requirement exists in the system, run thedeactivate command to deactivate the port whose line profile needs to be changed.Then, run the activate command to activate the port and bind the port with the lineprofile that meets the requirement.

– If no line profile that meets the requirement exists in the system, run the shdsl line-profile add command to add a new line profile that meets the requirement. Then,run the deactivate command to deactivate the port whose line profile needs to bechanged. Lastly, run the activate command to activate the port and bind the portwith the new profile.

l Change the line template of the VDSL2 port.

1. Run the interface vdsl command to enter the VDSL mode.

2. Run the display vdsl line-template command to check whether a line template thatmeets the requirement exists in the system.

– If a line template that meets the requirement exists in the system, run thedeactivate command to deactivate the port whose line template needs to bechanged. Then, run the activate command to activate the port and bind the portwith the line template that meets the requirement.

– If no line template that meets the requirement exists in the system, run the vdslline-template add command to add a new line template that meets the requirement.Then, run the deactivate command to deactivate the port whose line template needsto be changed. Lastly, run the activate command to activate the port and bind theport with the new template.

----End



207

15.14 Changing the Traffic Profile of an xDSL PortThis topic describes how to change the traffic profile when the traffic profile bound to the xDSLport cannot meet the requirements for the rate and the 802.1p priority.

PrerequisiteNone

Impact on the SystemThe service port (also called PVC) needs to be deleted before the profile change. As a result, theservice carried on the service port will be interrupted.

PrecautionsNone

Procedure

Step 1 Run the display traffic table command to check whether a traffic profile that meets therequirement exists in the system.l If a traffic profile that meets the requirement exists in the system, proceed to Step 2.l If no traffic profile that meets the requirement exists in the system, run the traffic table

command to create a traffic profile and then proceed to Step 2.

Step 2 Run the undo service-port command to delete the original service port.

CAUTIONThe service port cannot be deleted in the following conditions:l The service port is encapsulated in PPPoA, IPoA, or Auto mode.l The service port is configured with a multicast user.l The service port is bound with an IP address or MAC address.l The service port is configured with a static MAC address.

Step 3 Run the service-port command to re-configure the service port and bind the service port witha new traffic profile.

----End

15.15 Troubleshooting the MG Interface FaultThis topic describes how to troubleshoot the media gateway (MG) interface fault when it is inthe abnormal state to ensure that the MG interface, namely, the virtual access gateway (VAG)can register with the softswitch successfully.



208

Prerequisite

The UA5000, upper layer gateway, and softswitch must work in the normal state.


After the MG interface fault is rectified, the MG interface can register with the softswitchsuccessfully. Accordingly, the services carried on this interface can be provided successfully.

Precautions

None

Procedure

Step 1 Run the reset coldstart command to reset the MG interface. Then, check whether the fault ofthe MG interface is rectified.l If the fault of the MG interface is rectified, the procedure ends.l If the fault persists, go to Step 2.

Step 2 Run the display if-h248 attribute command to check whether the configuration of the MGinterface parameters on the UA5000 side is the same as the configuration of the MG interfaceparameters on the softswitch side.l If the configuration of the MG interface parameters on the UA5000 side is the same as the

configuration of the MG interface parameters on the softswitch side, go to Step 4.l If the configuration of the MG interface parameters on the UA5000 side is different from

the configuration of the MG interface parameters on the softswitch side, go to Step 3.

Step 3 Modify the configuration of MG interface parameters on the softswitch side; or run the if-h248attribute command on the UA5000 to change the configuration of MG interface parameters,and then run the reset coldstart command to reset the interface to make the configuration takeeffect. Ensure that the configuration of the MG interface parameters on the UA5000 side is thesame as the configuration of the MG interface parameters on the softswitch side. Then, checkwhether the fault of the MG interface is rectified.l If the fault of the MG interface is rectified, the procedure ends.l If the fault persists, go to Step 4.

Step 4 In global config mode, run the ping and tracert commands to check whether the connectionbetween the UA5000 and the upper-layer AG and between the UA5000 and the softswitch is ingood condition and whether the upstream line is in good condition.l If the connectivity and the upstream line are in good condition, go to 1.3.5 Contacting

Huawei for Assistance.l If the connectivity and the upstream line are not in good condition, go to Step 5.

Step 5 Check whether the physical upstream line is in good condition. In addition, check theconfigurations of the UA5000, upper-layer AG, and softswitch. Ensure that the connectionbetween interconnected devices is in good condition. Then, check whether the fault of the MGinterface is rectified.l If the fault of the MG interface is rectified, the procedure ends.l If the fault persists, go to 1.3.5 Contacting Huawei for Assistance.



209

NOTE

The link failure is always due to the interconnection failure between the Ethernet port on the UA5000 andthe upper-layer device. It is recommended that you perform the following operations:

l For the network in the independent upstream transmission mode, run the display fe command to checkwhether the working mode of the uplink port is the same as the working mode of the uplink port onthe peer device. If the working mode of the uplink port is different from the working mode of the uplinkport on the peer device, run the fe mode command to change the working mode of the uplink port tobe the same as the working mode of the uplink port on the peer device. You can also change theconfiguration of the port on the peer device.

l For the network in the integrated upstream transmission mode, run the display port state commandto check whether the working mode of the Ethernet uplink port is the same the working mode of theEthernet uplink port on the peer device. The working mode includes the duplex mode, port rate, andtraffic control setting. If the working mode of the Ethernet uplink port is different from the workingmode of the Ethernet uplink port on the peer device, run the duplex, speed, and flow-control commandsto change the configuration of the Ethernet uplink port to be the same as the corresponding configurationof the Ethernet uplink port on the peer device. You can also change the configuration of the port onthe peer device.

----End

15.16 Troubleshooting the V5 Interface FaultThis topic describes how to troubleshoot the V5 interface fault when it is in the abnormal stateto ensure that the V5 interface can start normally.

PrerequisiteThe UA5000, upper layer transmission device, and switch must work in the normal state.

Impact on the SystemAfter the V5 interface fault is rectified, the V5 interface can start and communicate with thesoftswitch normally. Accordingly, the services carried on this interface can be providedsuccessfully.

PrecautionsNone

Procedure

Step 1 In global config mode, run the display port state command to query the status of E1 port onwhich the V5 interface is configured.l If the port status (State item) is not "Failed", go to Step 4.l If the port status (State item) is "Failed", go to Step 2.

Step 2 Perform the E1 line loopback by referring E1 Line Loopback on the E1 port that is configuredwith the V5 interface. Then, check whether the port is in the normal state.l If the port is in the normal state, go to Step 4.l If the port is not in the normal state, go to Step 3.

Step 3 Configure the data of the V5 interface on an E1 port that is in the normal state. Then, checkwhether the V5 interface recovers.



210

l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 4.

Step 4 In V5 interface mode, run the link identify command to identify the link of E1 port.l If the link is identified successfully, go to Step 6.l If the link is not identified, go to Step 5.

Step 5 Check the connection of the E1 cable (especially the wire sequence) to ensure that the E1 cableis connected correctly (no cross-connection). Then, check whether the V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 6.

Step 6 Check whether the E1 cable is normal. If necessary, replace the E1 cable by referring toReplacing the E1 Cable and ensure that the E1 cable connection, especially the wire sequence,is correct. Then, check whether the V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 7.

Step 7 Replace the transfer board (for how to replace the front-access transfer board, see Replacing theTransfer Board (Front-Access); for how to replace the rear-access transfer board, see Replacingthe Transfer Board (Rear-Access)). Then, check whether the V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 8.

Step 8 Check whether the data configuration on the UA5000 is consistent with the data configurationon the switch.1. Check whether the configurations of the impedance and the CRC check on the E1 port are

consistent with the configurations of the impedance on the E1 port and the CRC check onthe switch.l If they are consistent, go to Step 8.3.l If they are inconsistent, go to Step 8.2.

NOTE

l If the E1 port is located on the PVM board, run the display port command in PVM mode toquery the configurations of the impedance and CRC check of the E1 port. For the impedance onthe E1 port, ensure that the result queried through the CLI is the same as the configuration of thephysical jumper on the PVM board. For the relationship between the physical jumper on the PVMboard and the impedance value, see the associated description in Introduction to Board.

l If the E1 port is located on the EDTB board, run the display port mode command in EDT modeto query the configurations of the impedance and CRC check of the E1 port. The impedancevalue depends on the configuration of the physical jumper on the EDTB board. (For therelationship between the physical jumper on the EDTB board and the impedance value, see EDTBBoard.)

2. Modify the data configuration on the UA5000 or switch so that the data configuration onthe UA5000 is consistent with the data configuration on the switch. Then, check whetherthe V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 8.3.

3. Run the display v5-software parameters command to check whether the value of theparameter with index 2 is the same as the value of the associated parameter of the switch.



211

l If the value of the parameter with index 2 is the same as the value of the associatedparameter of the switch, go to Step 9.

l If the value of the parameter with index 2 is not the same as the value of the associatedparameter of the switch, go to Step 8.4.

NOTE

The parameter with index 2 adapts to interface start procedures of different switches. The meaningsof different values of the parameter with index 2 are as follows:

l 0: Common switch

l 1: Non-accelerated synchronization switch

l 2: AN being started (including the accelerated synchronization)

l 3: AN being started (not including the accelerated synchronization)

4. Modify the data configuration on the UA5000 or switch so that the data configuration onthe UA5000 is consistent with the data configuration on the switch. Then, check whetherthe V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 9.

Step 9 In V5 interface mode, run the reset command to reset the V5 interface. Then, check whether theV5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 10.

Step 10 Check whether the physical upstream line is in good condition. In addition, check theconfigurations of the UA5000, upper-layer gateway, and switch. Ensure that the interconnecteddevices can communicate with each other. Then, check whether the V5 interface recovers.l If the V5 interface recovers, the procedure ends.l If the V5 interface fails to recover, go to Step 11.

Step 11 Run the display if-v5 state command to query the status of the V5 interface. Then, go to Step12.

Step 12 Use Toolbox to trace the V5 signaling (in addition, select two tracing modes, namely, V5 L2message tracing and V5 message tracing), save the tracing result. Then, go to 1.3.5 ContactingHuawei for Assistance.

----End



212

16 Troubleshooting Cases

About This Chapter

16.1 By Fault

16.2 By Feature

16.3 By Alarm

UA5000 Universal Access UnitTroubleshooting 16 Troubleshooting Cases


213

16.1 By Fault

16.1.1 Board FaultThis topic provides the analysis of the cases related to the board fault.

TC-A0005 The Service Boards of the Lower Half Shelf Are Faulty Because theHWCB Board Is Not Inserted into the HABA Shelf

This topic describes how to troubleshoot the fault when the service boards of the lower half shelfare faulty because the HWCB board is not inserted into the HABA shelf.

Fault TypeNarrowband service

Board fault

Board fault alarm

Phenomenon Descriptionl The cabinet has an HABA shelf that is fully configured with the A32 service boards. After

the device is powered on and the data is configured, it is found that the service boardsstarting from slot 18 are faulty and the service boards in slots 6 to 12 are in the normal state.

l Log in to the system through the HyperTerminal, and then run the display board 0command to query the board status. It is found that the A32 boards in slots 6 to 12 are inthe normal state, but the A32 boards in slots 18 to 35 are faulty. The LEDs of the faultyboards fast blink three times, turn off, and then fast blink again.

Alarm InformationAlarm "Board Fault Alarm" is displayed on the HyperTerminal indicating that the board is faulty.

Cause AnalysisThe possible causes are as follows:

l The NE software and board software do not match.l The 48 V power supply or the ±5 V power supply for the narrowband service board is

abnormal.l The control board or the backplane is faulty.l The transfer board that is connected to the slave shelf is faulty.

Procedure

Step 1 Insert the A32 board in slot 18 into the front slot, and the service board is in the normal state.Insert the service board in the front slot into the slot after slot 18, and the service board is faulty.This indicates that the service board is in the normal state.



214

Step 2 Insert the PVM control board of this office into the devices of other sites, and the service boardsfrom slot 18 are in the normal state. This indicates that the PVM control board is in the normalstate and the data configuration is correct.

Step 3 Replace two power boards, and the fault persists.

Step 4 Replace the backplane, and the fault persists.

Step 5 Compare the delivery list of this time with the previous delivery list. It is found that the HABAshelf is not configured with an HWCB board, which is used to subtend the slave shelf. Thisoffice, however, does not use the slave shelf. Therefore, the carrier did not purchase the HWCBboard. Use an HWCB board from another office and insert it into the shelf of this office. Then,the service boards in slots 18 to 35 are in the normal state and the fault is rectified.

----End

Suggestion and SummaryIt is recommended that you configure the HWCB board in the master shelf regardless of whetherthe master shelf subtends the slave shelf. Otherwise, the service boards of the lower half shelfare faulty.

TC-A0015 The Service Board Cannot Work in the Normal State Because the PVMBBoard Is Abnormal

This topic describes how to troubleshoot the fault when the service board cannot work in thenormal state because the PVMB board is abnormal.

Fault TypeOther

Board fault

Board fault alarm

KeywordService board fault

LED RUN

Fails to work

PVMB

Phenomenon DescriptionIn the case of an F01E400 cabinet, after the power supply is cut off and then resumed, the serviceboards cannot work in the normal state and LED RUN is off, but the PVMB board and powerboard are in the normal state. The MA5105 in the cabinet works in the normal state.




215

Cause Analysis

The possible causes are as follows:

l The hardware of the service board is faulty.

l The NE software and board software do not match.

l The ± 5 V power supply for the narrowband service board is abnormal.

l The 48 V power supply is abnormal.

l The control board or the backplane is faulty.

Procedure

Step 1 Check the LEDs of the power boards. It is found that the status is normal. Replace two powerboards with new ones, and the fault persists.

Step 2 Remove all the service boards and then insert one normal service board, and the fault persists.

Step 3 The F01E400 is an HABD shelf that is not configured with a fuse. The fault may be caused byinsufficient power. Power off the storage battery and the MA5105 in the cabinet, remove thepower monitoring module, and perform a test on the UA5000. LED RUN of the service board,however, is still off.

Step 4 Use a multimeter to measure the input voltage of the cabinet. The input voltage is about 56 V,and the voltage is stable. Therefore, the fault is not caused by the power supply.

Step 5 The backplane may be faulty. Through the observation, it is found that the LED RUN of theservice board fast blinks and then turns off when the power board, service board, or PVMB boardis removed and then inserted. In this case, the service slot can be powered on. Therefore, thefault is not caused by the backplane.

Step 6 Insert a new PVMB board to which the matched program has been loaded. Then, the serviceboard works in the normal state and the fault is rectified.

----End

Suggestion and Summary

None

TC-A0056 The UA5000 Reports an Alarm Indicating that the Control Board DoesNot Match the Shelf Because the Control Board Was Originally Installed in aDifferent Shelf

This case describes how to troubleshoot the fault wherein the UA5000 reports an alarm indicatingthat the control board does not match the shelf because the control board was originally installedin a different shelf.

Fault Type

Other

Board fault



216

Keyword

Database configuration file

Command line configuration file

Fault Description

During the deployment of an office, an IPMB board that was originally installed on the HABAshelf is inserted into the HABC shelf and the service is provided when the originally configureddata is not erased. Then, the service runs in the normal state but the system frequently generatesthe alarm indicating that the control board does not match the shelf.

Alarm Information

An alarm, "Failure: Failed to resume configuration data of device", indicating that issuing theconfiguration data fails is displayed on the HyperTerminal.

The system frequently reports alarms indicating that the control board does not match the shelf.

Cause Analysis

The information about the type of the mother board is saved in the database of the IPMB controlboard of the UA5000, and different data files are created for different types of mother boards.When the new shelf is used, if you directly configure data for the shelf without running the eraseflash data command to erase the data about the original database, the system generates the alarmindicating that the control board does not match the shelf.

Procedure

Step 1 In the case of local operation performed directly on the device, you can run the erase flashdata command to erase the original database information and then re-configure all the servicesto rectify the fault.

Step 2 In the case of remote operation, you can perform the following steps to rectify the fault:1. Run the save configuration command to save the configuration file in the flash memory

in the form of command lines.2. Run the active configuration command to restart the system. During the startup, the system

uses the configuration file in the form of command lines, rather than the configuration filein the form of database, to restore the system configuration. Thus, the control board neednot read the information about the shelf type in the database file. Consequently, the systemidentifies the HABC shelf correctly after the device is restarted.

3. Run the save command to overwrite the database file in the flash memory to ensure thatthe system reads the correct database file when being restarted next time.

----End

Suggestions and Summaryl The database file saved in the flash memory of the control board of the UA5000 records

the shelf type. Therefore, when you insert a control board that is originally used in a differenttype of shelf, you need to erase the original database file of the control board.



217

l If you run the save command to save the configuration, the system generates a configurationfile in the form of database. If you run the save configuration command to save theconfiguration, the system generates a configuration file in the form of command lines.

l In the case of remote operation on the UA5000, there is a risk that the control board cannotstart up normally after being reset. Therefore, it is recommended that you reset or restartthe control board locally.

TC-A0057 The Boards in Slots 29-35 in the Slave Shelf of the UA5000 Fail to RegisterNormally Because the E1 Lines of the Master and Slave Shelves Are ConnectedInversely

This case describes how to troubleshoot the fault wherein the boards in slots 29-35 in the slaveshelf of the UA5000 fail to register normally because the E1 lines of the master and slave shelvesare connected inversely.

Fault TypeOther

Board fault

KeywordC&C08

RSU

Fault DescriptionIn an office, the C&C08 switch is connected to a UA5000 that is configured with two shelves(each shelf is configured with one RSU board that functions as the VRSP board). During thecapacity expansion for the slave shelf on site, the network management system (NMS) displaysthat seven service boards (in slots 29-35) fail after being inserted into the corresponding slots.

Alarm InformationNone


l The data configuration of the C&C08 switch is incorrect.l The DIP switches of the RSU board are set incorrectly.l The service board is faulty.l The HWCB board is faulty.l The E1 (2M) line is connected to the RSU board in an incorrect sequence.

Procedure

Step 1 The data configuration of the C&C08 switch is checked, and it is found that the configurationis correct. Then, the E1 line connection of the faulty shelf is exchanged with the connection of



218

a normal shelf at another site on the digital distribution frame (DDF) of the switch. It is foundthat the fault of the UA5000 shelf persists. This indicates that the data configuration of theC&C08 switch is correct.

Step 2 The version of the RSU board is checked. It is found that the version is 5125. The DIP switchsettings of the RSU board of this version determine that the shelf type is HABA. Therefore, itindicates that the settings of the DIP switches of the RSU board are correct.

Step 3 The A32 service boards in slots 29-35 are replaced. It is found that the fault persists. Thisindicates that the service boards are normal.

Step 4 The HWCB transfer board is replaced, and it is found that the fault persists.

Step 5 The slave shelf is removed and inserted again, and it is found that the service board can registernormally. When this service board is removed from the shelf, however, the NMS of the C&C08generates an alarm for shelf 0 instead of generating an alarm for shelf 1 normally. This indicatesthat the connections of the master and slave shelves may be incorrect. The subsequent checkshows that the E1 lines of the master and slave shelves are connected inversely. After the E1lines of the two shelves are connected again properly, it is found that the boards in slots 29-35can register normally. Thus, the fault is rectified.

NOTE

The master shelf of the UA5000 provides 18 slots. Slots 0 and 1 are designed to house secondary powerboards, slots 2 and 3 to house broadband control boards, slots 4 and 5 to house narrowband control boards,and slot 17 is already configured with the TSSB test board. The remaining 11 slots support a maximum of11 service boards. After the E1 lines of the master and slave shelves are connected inversely, the mastershelf data of the switch corresponds to the slave shelf hardware of the UA5000. As a result, the serviceboards in seven slots fail to register normally.

----End

Suggestions and Summary

During the project deployment, you must check the installation of the cabinet, cable connections,and data configuration of the device carefully, to avoid resource wastage due to incorrect basicconfigurations. After a fault occurs, you are suggested to check the upper and lower-layer devicesto locate the fault, based on the entire network rather than on a single device.

TC-A0060 The Service Board Is Faulty Because the Hardware Configuration of theHW Transfer Board Is Incorrect

This case describes how to troubleshoot the fault wherein the service board is faulty because thehardware configuration of the HW transfer board is incorrect.

Fault Type

Other

Board fault

Keyword

HWTF

HWCF



219

Fault Description

During a new deployment of the UA5000, the A32 service board is in the faulty state after beingadded in the HABD shelf and confirmed. The HABD shelf is also configured with the broadbandcontrol board and broadband service board. The display board 0 command is executed to checkthe status of other boards. The check result shows that other boards are in the normal state.

Alarm Information

None

Cause Analysis


l The –48 V power supply is abnormal.

l The service board is faulty.

l The PVM narrowband control board is faulty.

l The PWX power board is faulty.

l The mother board of the HABD shelf is faulty.

l The HW transfer board is faulty.

Procedure

Step 1 The broadband control board and broadband service board are in the normal state. This indicatesthat the –48 V power supply used by the shelf is normal.

Step 2 The A32 service board is replaced. It is found that the fault persists. This indicates that the faultis not caused by the faults on certain service boards.

Step 3 The PVM narrowband control board is replaced, and it is found that the fault persists.

Step 4 The PWX board is replaced, and it is found that the fault persists.

Step 5 The HABD shelf is replaced, and it is found that the fault persists.

Step 6 The configuration of the shelf is checked. It is found that the shelf is configured with the HWTFtransfer board, which actually should be used in the master shelf. After the HWTF transfer boardis replaced by the HWCF board, the status of the service board becomes normal and the fault isrectified.

----End


There are multiple types of transfer boards for the UA5000. The knowledge about the functionsof each type of transfer board and the type and characteristics of the corresponding board (towhich the service is to be transferred) helps locate the hardware configuration problems quickly.For the associated information, see the corresponding Product Description manual.



220

TC-A0067 All the Service Boards in the Slave Shelf of the UA5000 Fail to Registerwith the System Because One DSL Board in the Shelf Is Faulty

This case describes how to troubleshoot the fault wherein all the service boards in the slave shelfof the UA5000 fail to register with the system because one DSL board in the shelf is faulty.

Fault TypeOther

Board fault

KeywordSlave shelf

HWTB

Fault Descriptionl Networking: UA5000 -> bearer network -> softswitchl Fault description: The slave shelf of a UA5000 is installed with the ASL and DSL boards,

but all the boards in the shelf fail to register with the system.

Alarm Informationl The display board 1 command is executed to query the board status. The query result

shows that all the boards in the slave shelf are faulty.l The shelf panels are checked. It is found that all the indicators on one DSL board are on.l The alarm records are checked. It is found that the board error alarms have been generated,

and the earliest board alarm is an alarm for the DSL board.


l The transfer board connected to the HW line or the HW connection line is faulty.l The DSL board is faulty.

ProcedureStep 1 The HWTB board of the slave shelf is replaced. It is found that the fault still persists.

Step 2 The board add and board delete operations can be performed on the slave shelf before and afterthe HWTB board is replaced. Therefore, this indicates that the fault is not caused by the HWTBboard and the HW connection line.

Step 3 The faulty DSL board is removed from the slave shelf and the board status of the slave shelf ischecked again. It is found that the status of each board returns to normal and the service recovers.

----End

Suggestions and SummaryNone



221

TC-A0075 The VRSP Board of a Newly-Deployed E200 Is Faulty Because One 2MLine on the Backplane of the OLT Is Faulty

This case describes how to troubleshoot the fault wherein the VRSP board of a newly-deployedE200 is faulty because one 2M line on the backplane of the OLT is faulty.

Fault TypeOther

Board fault

KeywordBoard hardware

Connection lines

Fault Descriptionl Networking: E200 (VRSP) -> OLT (DTE)l Fault description: On a newly-deployed E200, the RSU4 board is used as the virtual RSP

(VRSP) board. After the data is configured through the NMS, the NMS displays that theRSP board is faulty.



l The data configuration of the RSU4 board is incorrect.l The version of the RSU4 board is incorrect or the DIP switches are set incorrectly.l The RSU4 board is faulty or the PWX board is faulty.l The 2M transfer port and the 2M line on the E200 are faulty.l The third-party transmission device is faulty.l The data configuration on the OLT is incorrect.

Procedure

Step 1 The data configuration of the RSU4 board is checked. It is found that the configuration is correct.The RSU4 board is added again. It is found that the fault persists.

Step 2 The version of the RSU4 board is checked. It is found that the version of the RSU4 board matchesthe E200. Then, the settings of the DIP switches of the RSU4 board are checked. It is found thatthe DIP switch settings are correct.RSUA>show versionBoard type: H601RSU8Board Soft Ver: 5128PCB Ver: FBasic bios Ver: 100Ext bios Ver: 105



222

CPLD Ver: 102Logic Ver: 109Node Ver: 3103 Compiling Time: Jul 25 2007 14:28:18

Step 3 The RSU4 board is replaced with a normal RSU4 board. The subsequent test shows that the faultpersists. Then, the PWX board is replaced with a normal PWX board. The subsequent test showsthat the fault still persists.

Step 4 A loopback from the digital distribution frame (DDF) in the branch office to the E200 isperformed on the DDF, and then the show runstate command is executed to check the statusof the 2M line. It is found that the 2M line is in the normal state. This indicates that the fault isnot caused by the 2M transfer on the E200.

Step 5 A loopback from the DDF in the general equipment room to the remote E200 is performed onthe DDF, and then the status of the 2M line on the RSU4 board is checked again. It is found thatthe 2M line is in the normal state. The 2M line on the DDF is disconnected. It is found that thestatus of the 2M line on the corresponding RSU4 board changes to "Fail". This indicates thatthe transmission is normal.

Step 6 The distance of the 2M line from the backplane of the OLT to the DDF in the general equipmentis only 10 meters. A loopback from the DDF to the DTE board is performed on the DDF, andthen the indicator on the DTE board is checked. It is found that the corresponding indicator isoff. Then, the 2M connector on the DDF is disconnected, and the corresponding indicator onthe DTE board is checked again. It is found that the indicator is still off. 30s later, the indicatorturns on. Therefore, it can be determined that this 2M line is faulty. After the 2M line is removedfrom the DTE backplane and a new 2M line is connected to the backplane, the RSP indicatorturns green. The subsequent test shows that the service is restored.

----End

Suggestions and SummaryWhen functioning as the VRSP board, the RSU4/PVM board has similar functions with the RSPboard. When an RSP board fault occurs, you need to check whether the 2M transmission line isnormal.

TC-A0104 The Echo Is Loud During the Call of Users Connected to the UA5000Because the Service Board Is Faulty

This case describes how to troubleshoot the fault wherein the echo is loud during the call ofusers connected to the UA5000 because the service board is faulty.

Fault TypeOther

Board fault

KeywordFAR

ASL

Echo



223

Echo

Fault Description

Networking: UA5000 -> switch -> SoftX3000

During the call of certain users connected to the UA5000, the peer user hears the loud echo inthe communication.

Alarm Information

None

Cause Analysis


l The DSP gain is incorrect.l The port gain is incorrect.l The service board is faulty.

Procedure

Step 1 The DSP input gain and output gain are adjusted to the minimal values. It is found that the echostill exists.

Step 2 The port gain is adjusted to the minimal value. It is found that the echo still exists though it isnot as loud as before.

Step 3 The service boards in slot 8 and slot 13 are interchanged. It is found that the fault is relevant tothe boards. This indicates that the fault is caused by a service board.

Step 4 The further check shows that the fault occurs on the FAR board, which is a long-distance boardused when the feeder distance is longer than 5 kilometers. The users connected to the device,however, are in the neighboring buildings and the distance is within 200 meters. Therefore, theFAR board is replaced with the ASL board. Then, the fault is rectified.

----End


You must use the corresponding board as required.

TC-A0121 The UA5000 Cannot Go Online Because the GAUA Board Is Faulty

This case describes how to troubleshoot the fault wherein the UA5000 cannot go online becausethe GAUA board is faulty.

Fault Type

Other

Board fault



224

Keyword

GAUA

Optical fiber

Fault Description

Networking: The IPMB control boards in slots 2 and 3 on the CMSAN are connected to theGAUA boards in slots 6 and 7 on the AMSAN respectively through the optical fibers. Theservices are converged on the AMSAN and then sent upstream to the upper-layer network. TheN2000 BMS manages devices on the entire network.

Fault description: When the IPMB control board in slot 2 functions as the active control board,the CMSAN is found online from the N2000 BMS client. When the optical fiber of the GAUAboard in slot 6 on the AMSAN is removed, the active/standby switchover is performed on theIPMB control boards of the CMSAN. The IPMB control board in slot 3 functions as the activecontrol board and the CMSAN is found offline from the N2000 BMS client.

Alarm Information

The N2000 BMS client reports the CMSAN offline alarm.

Cause Analysis


l The versions of the active and standby IPMB control boards on the CMSAN are different.l The optical fiber between the control board in slot 3 on the CMSAN and the GAUA board

in slot 7 on the AMSAN is faulty.l The optical transceiver is faulty.l The IPMB control board in slot 3 on the CMSAN is faulty.l The GAUA board in slot 7 on the AMSAN is faulty.

Procedure

Step 1 The versions of the active and standby IPMB control boards on the CMSAN are checked and itis found that they are the same.

Step 2 The optical fiber between the control board in slot 3 on the CMSAN and the GAUA board inslot 7 on the AMSAN is replaced. It is found that the fault persists.

Step 3 The optical transceiver is replaced and it is found that the fault persists.

Step 4 The IPMB control board in slot 3 on the CMSAN is replaced and it is found that the fault persists.

Step 5 The GAUA board in slot 7 on the AMSAN is replaced and the fault is rectified.

Step 6 The optical fibers in slot 6 and 7 on the AMSAN are removed and inserted repeatedly. Theactive/standby switchover is performed on the IPMB control boards on the CMSAN and no NEis found offline from the N2000 BMS client. The fault is rectified.

----End



225


TC-A0124 Digits Are Underreported Because the DSP Daughter Board of theUA5000 Is Faulty

This case describes how to troubleshoot the fault wherein digits are underreported because theDSP daughter board of the UA5000 is faulty.


Board fault

KeywordOffhook

Underreported digits

Fault DescriptionNetworking: UA5000 -> SoftX3000

Fault description: At a new site, all users connected to the AG can act as the called party normally;however, when they make phone calls, certain digits are underreported. The message tracing onthe softswitch side also proves this symptom.



l The data configuration on the softswitch (such as the issued digitmap and prefix) isincorrect.

l The telephone is faulty, which fails to report the digits correctly.l The service board is faulty (for example, the impedance does not match or the gains of the

port are incorrect).l The quality of the network is poor (for example, packet loss occurs).l The DSP chip is faulty.

Procedure

Step 1 The fault message sent back from the on-site engineer is checked. It is found that 1 in the phonenumber 13812345678 is not reported.

Step 2 Other AG users call the 13812345678 phone number again. It is found that the phone numbercan be called normally. This indicates that the digitmap and prefix issued by the softswitch are



226

correct (this can be confirmed in the H.248 message). At the same time, certain digits fail to bereported on the AG side. This indicates that the fault is not caused by the packet loss on thenetwork.

Step 3 Another normal telephone is used and then the test is performed again. It is found that the faultpersists. A fault occurs once every two calls and the fault message is the same as that shown inthe preceding step.

Step 4 The impedance and gains of the port on the service board are modified. It is found that the faultpersists.

Step 5 The host software version is checked. It is found that the host software configuration is normal.

Step 6 The dialing test is performed on site. It is found that the fault occurs once every two calls.According to the queried information about the DSP port occupied by the MG users, it is foundthat the fault occurs when the port under the dialing test occupies the DSP daughter boardresources of the active PVM board. Therefore, the DSP daughter board of the active PVM boardmay be faulty.

Step 7 All DSP channels of the active PVM board are disabled and then a dialup test is perform. It isfound that the fault does not recur. This indicates that the fault is caused by the DSP daughterboard of the active PVM board.

Step 8 The DSP daughter board on the active PVM board is replaced. The fault is rectified.

----End

Suggestions and SummaryOn the UA5000, when the fault that digits are underreported after offhook occurs in the voiceservice transmitted upstream over the IP network, you need to check whether the chip of theDSP daughter board is faulty.

TC-A0126 Ports on the A32 Service Board of the UA5000 Are Faulty Because theCables of the Accounting Device Are Connected Incorrectly

This case describes how to troubleshoot the fault wherein ports on the A32 service board of theUA5000 are faulty because the cables of the accounting device are connected incorrectly.

Fault TypeOther

Board fault

KeywordAccounting device

Hookflash

Fault DescriptionThe VoIP service is provided for a hotel user through the UA5000, After offhook, the busy toneis played for certain phones. Phone calls can be made normally after onhook and offhook. Thefault, however, recurs after a certain period of time. When phones that are not connected to the



227

UA5000 call the faulty phones, a voice message, indicating that the faulty phones cannot be putthrough, is played. When phones that are connected to the UA5000 call the faulty phones, avoice message, indicating that the subscriber line is faulty, is played.



l The A32 board is faulty.l The PVMB control board is faulty.l The subscriber line or accounting device is faulty.l The backplane is faulty.

Procedure

Step 1 The A32 board is replaced and the status of ports on the A32 board is checked. It is found thatthe ports are in the normal state after replacement but are in the failed state after a certain periodof time. This indicates that the fault is not caused by an A32 board fault.

Step 2 The PVMB control board is replaced. It is found that the ports on the A32 board are in thenormal state after replacement but are in the failed state after a certain period of time. Thisindicates that the fault is not caused by a PVMB control board fault.

Step 3 The subscriber line and accounting device are disconnected from the MDF. It is found that theports on the A32 board are still in the failed state. The A32 board is removed and then inserted.It is found that the ports on the A32 board are always in the normal state and the communicationis normal. This indicates that the fault is caused by a subscriber line fault or an accounting devicefault.

Step 4 The accounting device is removed and the exchange side terminal block is connected to thesubscriber line through a jumper. It is found that the ports on the A32 board are in the normalstate.

Step 5 The subscriber line is removed and a phone set is directly connected to the accounting device.It is found that the ports on the A32 board are in the failed state. This indicates that the fault iscaused by an accounting device fault. A further test is performed. It is found that the leading-incable and leading-out cable of the accounting device are connected conversely. After the cablesare connected correctly, the fault is rectified.

----End


TC-A0131 The Standby PV4 Control Board Fails to Work Normally BecauseTransport Settings Are Inappropriate

This case describes how to troubleshoot the fault wherein the standby PV4 control board failsto work normally because transport settings are inappropriate.



228

Fault Type

Other

Board fault

Keyword

Fault on the standby PV4 control board

Fault Description

The PV4 service shelves of the low-density UA5000 are connected to the MD5500. Sites areconnected through optical transport devices to form a loop or link. The transport device at thecentral site is OptiX 2500+ and the transport device at other sites is Metro 1000 or Metro 155C.Two PV4 boards are configured in the control shelf at the outdoor ONU site CCC1004. Theactive PV4 control board works normally whereas the standby PV4 control board is faulty.Services of the entire site are normal. Nevertheless, a strange symptom exists. Only two E1 ports(19/5/0 and 19/5/1) are configured on the PV4 board in slot 5. The first two E1 ports of the PV4board in slot 5 are in the normal state but the third E1 port is also in the normal state. In normalcases, the third E1 port is in the failed state because the third E1 is not configured. E1 port 0 ofthe standby PV4 control board is in the failed state.

Alarm Information

None

Cause Analysis


l The standby PV4 control board is faulty.l The backplane hardware is faulty.l The hardware cable is faulty.l The MD5500 is connected to PV4 shelves through optical transport devices. The fault may

be caused by inappropriate transport settings.

Procedure

Step 1 The standby PV4 control board is replaced. It is found that the fault persists.

Step 2 It is difficult to replace the backplane. Therefore, replacing the backplane is the last solution tobe used.

Step 3 The cable from the 155C to the PV4 board hardware is replaced. It is found that the fault persists.

Step 4 The status of the E1 port is a physical state that is directly displayed. Three E1 ports of the activePV4 control board are normal. The E1 cable that should be connected from the transport deviceto the standby PV4 control board may be mistakenly connected to the active PV4 control board.

Step 5 Transport device engineers are contacted to analyze the fault. It is found that the transport settingsare incorrect. Then, the E1 cable connected to the third E1 port of the active PV4 control boardis connected to the first port of the standby PV4 control board.



229

Step 6 After the cable is connected correctly, the standby PV4 control board is still faulty.

Step 7 An E1 cable is used to connect to the 155C and the physical loopback is performed on the E1cable. Note that the inner copper conductor and the outer shielded cable of the E1 cable must beshort-circuited in the physical loopback of the E1 cable. It is found that the port of the MD5500is normal. This indicates that the fault is rectified after the transport settings are modified.

Step 8 The PV4 boards are replaced or the active and standby PV4 control boards are interchanged. Itis found that the fault is rectified. This indicates that the contact between the PV4 boards andthe backplane is inappropriate.

----End

Suggestions and SummaryNo data is configured on the PV4 board and the PV4 board contains only the hardware and boardsoftware. It is the same as a service board to a certain extent. For faults occurring on the PV4board, the location means are insufficient and only the hardware loopback and hardwarereplacement can be used to locate faults. You must be patient when rectifying such faults.

TC-A0065 The Power Module of the E400 Is Damaged Because the Voltage Betweenthe N-Line of the Power Network and the Ground Is Excessively High

This case describes how to troubleshoot the fault wherein the power module of the E400 isdamaged because the voltage between the N-line of the power network and the ground isexcessively high.

Fault TypeOther

Power fault

KeywordF01E400

N-line to ground voltage

Fault DescriptionThe power module of an outdoor integrated access device F01E400 is damaged, and the devicecannot use the AC power. As a result, all the services are interrupted.

Alarm InformationThe alarm LED on the PSM monitoring module is on.


l The output of the AC voltage is abnormal.l The mains supply is cut.



230

l The power module system is faulty.

Procedure

Step 1 The AC voltage of the L-N output terminal on the site is tested. The tested voltage is 225 V,which is in the normal range.

Step 2 The AC MCB of the 4845 power is measured. If the voltage is 225 V, it indicates that the 4845power is normal.

Step 3 The MCB of the battery is measured. It is found that the input voltage after the 4845 powerconversion is 0 V, and the voltage of the binding post on the battery is 42 V.

Step 4 The 4845 power module is replaced. Then, it is found that the device can be powered on andcan work normally. The alarm LED on the PSM monitoring module is on, which indicates thatthe 4845 power module is faulty.

Step 5 The L-line to ground voltage and N-line to ground voltage are measured again. It is found thatthe L-line to ground voltage reaches 395 V and the N-line to ground voltage reaches 160 V,which both exceed the normal mains power standard. The power supplier is requested to adjustthe voltage, and then the fault is rectified.

----End


When installing the outdoor devices, you must measure the AC N-line to ground voltage due tothe uncertainty of the external environment and power. If the voltage exceeds the standard (<20 V), you must contact the power supplier to adjust the voltage before powering on the devicefor long-term operation.

TC-A0081 There Is No Power Feed After Users of a Half Shelf Go Off Hook Becausethe -48 V Power for the Lower Half HABA Shelf Is Faulty

This case describes how to troubleshoot the fault wherein there is no power feed after users ofthe half shelf go off hook because the -48 V power for the lower half HABA shelf is faulty.

Fault Type

Other

Power fault

Keyword

Mutual aid

Fault Descriptionl Networking: UA5000 (HABA shelf) -> layer-2 switch -> softswitchl Fault description: All the ASL boards of the UA5000 are displayed in the normal state, but

there is no power feed after the users connected to the lower half shelf of the HABA shelfgo off hook.



231



l The user cable is faulty.l The service board is faulty.l The power board or the power is faulty.

Procedure

Step 1 The status of the service board is checked after the login to the device. It is found that the serviceboard is normal and the RUN indicator on the board is also normal (on for 1s and off for 1s).The power is measured on the main distribution frame that the subscriber line is not connectedto the board. It is found that the fault on the board still persists. Then, the power of the user portis directly measured on the pins of the backplane. It is found that the voltage is only -0.5 V. Thisindicates that the fault is not caused by the subscriber line.

Step 2 The service board on which the fault occurs is exchanged with a normal board and only oneservice board is used in the shelf to test. It is found that the fault persists.

Step 3 The power board is checked and replaced. It is found that the fault persists.

Step 4 The further check finds that one -48 V DC port is provided for each of the upper half HABAshelf and lower half HABA shelf. The voltage of the power line connected to the -48 V DC portfor the lower half shelf, however, is zero, after being measured through a multimeter. Then, anormal -48 V power line is used, and it is found that the fault is rectified. Thus, it can bedetermined that the fault is caused by the -48 V power input.

----End

Suggestions and SummaryThe -48 V power for the upper and lower half shelves of the HABA shelf provide power foronly the corresponding half shelf (cannot provide power for each other), but the upper and lowerhalf shelves that use +/-5 V working voltage can provide mutual aid for each other, that is, whenthe power for one half shelf fails, the power for the other half shelf can be used to provide powerfor the entire shelf.

TC-A0094 Power Module of the E400 Is Damaged by Surge Current That IsGenerated When the AC L Line and N Line Are Connected Inversely

This case describes how to troubleshoot the fault wherein the power module of the E400 isdamaged by surge current that is generated when the AC L line and N line are connectedinversely.

Fault TypeOther

Power fault



232

KeywordL line and N line

Power module

Fault DescriptionThe power module of the F01E400, an outdoor integrated access device, is damaged when theelectrical network is unstable or surge current (such as lightning strike) is generated. As a result,the device cannot use the AC power and all the services are interrupted when the battery poweris used up.

Alarm InformationThe alarm indicator on the PSM monitoring module is on.


l The mains supply is cut.l The power module system is faulty.l The AC power is faulty.

ProcedureStep 1 The AC voltage of the input circuit breaker on the device is measured. The voltage measures

226 V, which is in the normal range.

Step 2 The voltage of the AC circuit breaker on the 4845 power module is measured. The voltagemeasures 0 V, which indicates that there is no AC voltage.

Step 3 Based on the fact that the alarm indicator of the PSM monitoring module is on, it can bedetermined that the 4845 power module has no AC power supply.

Step 4 The 4845 power module is replaced, and then it is found that the device can be powered on andwork normally.

Step 5 The rectifier module of the 4845 power is disassembled. It is found that the electrical componenton the N line side is burnt but the fuse on the L line side is normal. This indicates that the ACL line and N line are connected inversely.

Step 6 The AC power input is checked. It is found that the L line and N line are indeed connectedinversely. After the two lines are connected properly, the fault is rectified.

----End

Suggestions and SummaryRectifier HRS850-9000C of the 4845 power of the E400 cabinet is designed with a protectionmeasure for L line, that is, a fuse is installed on the input side, which can well protect the linein the case of voltage fluctuation. The N line, however, is not provided with any protectionmeasure. Therefore, when installing the AC power, you must be very cautious of the portsmarked on the circuit breaker of the device for connecting to the L line and N line. The two linesmust not be connected inversely.



233

TC-A0101 The ADRB Board Is Not in the Working State Because the -48 V Inputfor the Lower Half Shelf of the HABA Shelf Is Abnormal

This case describes how to troubleshoot the fault wherein the ADRB board is not in the workingstate because the -48 V input for the lower half shelf of the HABA shelf is abnormal.

Fault TypeOther

Board fault

Keyword-48 V input

Fault DescriptionFault description: An ADRB board is inserted into slot 0/35 of the rear access HABA shelf onthe UA5000. After the HABA shelf is powered on, the ADRB board is not in the working state,and the RUN LED is off. When the board information is queried after the IPMB system is loggedin, and the system prompts "Unmanageable". The model of the IPMB board is H602IPMB andthe model of the ADRB board is H603ADRB.



l The ADRB board is faulty.l The slot 0/35 of the HABA shelf is faulty.l The power system of the shelf is faulty.

Procedure

Step 1 The ADRB board is inserted into slot 0/16 of the upper half shelf. It is found that the ADRBboard can start. This indicates that the fault is not caused by the ADRB board fault.

Step 2 The ADRB board is inserted into other slots of the lower half shelf. It is found that the ADRBboard cannot start.

Step 3 It is considered that the slot of the HABA shelf may be faulty. The backplane of the shelf isreplaced. It is found that the fault persists.

Step 4 The input voltage of the lower half shelf is tested. It is found that the voltage is 0 V, which meansthat there is no voltage input. Then, the output port of the 4845 power module is checked. It isfound that there is no voltage output. The power output port is replaced with a normal port. It isfound that the ADRB board in slot 0/35 can start normally and the ADRB board can also startnormally in other slots. The fault is rectified.

----End



234


The upper half HABA shelf and the lower half HABA shelf provide one -48 V DC port each tosupply the -48 V DC power input to the upper half HABA shelf and lower half HABA shelfrespectively.

The broadband service board requires -48 V DC input. The boards related to the narrowbandservice can be started normally only when the secondary power board is powered on normally.These boards include the boards for providing narrowband services of the broadband andnarrowband combo device, narrowband service boards, and narrowband control boards.

TC-A0204 Absence of Dial Tone on Certain Users Due to Unsecured Connectionof the Board

This case describes the troubleshooting of the absence of the dial tone on certain users of aUA5000 because the board was not inserted properly.

Fault Type

Narrowband service

Board failure

Keywords

Backplane

Secure insertion of the board

Fault Description

No dialing tone was displayed on many ports on the distribution frame.

Alarm Information

None

Cause Analysis

The possible causes were as follows:

l The service boards were faulty.l The slots were faulty.l The backplane or the network cable was faulty.l The board was not inserted securely.

Procedure

Step 1 The query result showed that most of the ports on the board had no power. The board may befaulty. The boards were replaced. The fault, however, persisted and the ports that had no powerwere not the original ones.



235

Step 2 Each time after the board was replaced, it was found that certain ports were normal. However,the ports that were faulty changed without rules.

Step 3 The board was inserted in another slot and it was found that the board was normal.

Step 4 The backplane and cable were checked and found to be normal.

Step 5 It was found that the board in the faulty slot seems to be 2 mm longer than other boards. Thisboard was pushed into the slot securely. The faulty board was tested again. It was found that thefault recovered and the dialing tone was normal. The fault was rectified.

----End

Suggestions and SummarySome serious faults may be caused by mistakes in detail, and therefore, great care must be takenin troubleshooting.

TC-A0245 ETH Port Failure Due to H601PVMD Board Not Configured withOutband Network Management IP Address

This case describes how to troubleshoot the ETH port that cannot work normally because theH601PVMD board is not configured with the outband network management IP address.

Fault TypeOther

Board fault

KeywordsOutband maintenance

ETH outband

Fault DescriptionThe UA5000 on a site uses the H601PVMD board for upstream transmission in integrated mode.When the PVMD version is upgraded on site, it is found that the LINK indicator of the ETHport is off after the ETH port is connected to the PC through a network cable. As a result, filescannot be transmitted in TFTP mode.

Alarm InformationNo alarm is generated in this case.

Cause AnalysisThe possible causes are as follows:l The network cable is faulty.l The PC is connected to an incorrect port.l The software configuration is incorrect.



236

l The port hardware is faulty.

Procedure

Step 1 Replace the network cable. It is found that the LINK indicator of the ETH port is off regardlessof using the crossover or straight-through network cable.

Step 2 Run the display working mode command to check for the data configuration. It is found thatthe data configuration is correct and that the ETH port is used for outband maintenance.huawei#display working mode working mode:integrated outband port:ETH port service port:Inner port

Step 3 Run the display ip address command to check whether the ETH port is configured with anoutband network management IP address. It is found that the ETH port is not configured withsuch an IP address.huawei(interface-outband)#display ip address Failure: This IP record does not exist

Step 4 Run the #GUIDA5AF2EAF-284B-4C7F-8852-816DC7A1C893_3 command to configure anoutband network management IP address for the ETH port. It is found that the ETH port worksnormally and the LINK indicator of the port is on. This indicates that the fault is rectified.

----End

Suggestions and SummaryWhen the outband network management mode is used to manage the UA5000 (PVM), the devicemust be configured with an outband network management IP address, and then the outbandnetwork port can be activated successfully (the LINK indicator turns on after the port isconnected to a PC through a network cable).

TC-A0251 No Ringing Tone for Some Subscribers Due to Faulty A32 BoardThis case describes how to troubleshoot the absence of ringing tones for some subscribers dueto a faulty A32 service board in the UA5000 to which these subscribers are connected.

Fault TypeBoard fault

Narrowband service

KeywordsNo ringing tone for the called party

Fault DescriptionNetwork topology: UA5000 -> router -> SoftX3000

Fault symptom: Some subscribers connected to the UA5000 can make calls successfully buttheir phones do not ring when they are being called. If these phones are called, however, andthe subscribers answer the phone, they can communicate with the calling parties withoutproblems.



237

Alarm InformationNo alarm is generated.

Cause Analysisl The PWX board is faulty.l The ringing current relay on the backplane is faulty.l One of the A32 boards is faulty.

ProcedureStep 1 Check the PWX board and system alarms. It is found that the status indicators on the board are

running properly and that no PWX board alarm is generated in the system, indicating that thePWX board is functional.

Step 2 Replace the subrack and the backplane. It is found that the fault persists, indicating that the faultis not caused by the ringing current relay on the original backplane.

Step 3 Use the minimum configuration method to identify the fault cause. That is, remove the A32boards in the subrack one by one and perform circuit and subscriber line tests on the remainingA32 boards each time. It is found that the ringing voltage is normal after the A32 board in slot8 is removed. Replace the A32 board in slot 8. It is found that the fault is rectified.

----End

Suggestion and SummaryWhen a service failure occurs on the UA5000, you can use the device's circuit and subscriberline test functions and the minimum configuration method to locate the fault quickly. Theminimum configuration method may affect the services on the live network and should only beused when network traffic is light.

NOTE

The minimum configuration method involves removing the service boards one by one, performing testson the remaining boards each time, and then re-inserting the board into the slot to determine which boardcauses the fault.

TC-A0258 Failures of A32 Board and GE Port on IPMD Board Due to PSTF BoardFaults

This case describes how to troubleshoot the failures of the A32 board and GE port on the IPMDboard of a UA5000, which are caused by faults in the PSTF board.


Other

KeywordsLINK indicator off

RUN indicator on



238

Fault Description

The UA5000 on a site is configured to transmit data in integrated mode. After the data isconfigured, the LINK indicator of the GE optical port on the IPMD board is off after an opticalfiber is connected to the port. In addition, the RUN indicator on the A32 board is continuouslyon, representing an A32 board fault.

Alarm Information

No alarm is generated.

Cause Analysisl The working modes of the IPMD board's communication ports on the backplane are set

incorrectly.

l The optical module is faulty.

l The working modes of the interconnection ports set on the UA5000 and the peer deviceare different.

l The transmit and receive fibers are connected out of sequence.

l The PSTF board is not in proper contact with the backplane.

l The PSTF board is faulty.

Procedure

Step 1 Run the display port state command to check the working modes of the IPMD board'scommunication ports on the backplane. It is found that both the ports are in the correct workingmode, GE-Optical.

Step 2 Run the display port opticstate command to check the optical module for about the IPMDboard. The system displays the "Optics/electric module status is normal" message, indicatingthat the optical module is normal.

Step 3 Check the working modes of the interconnection ports on the UA5000 and the peer device. It isfound that the working modes are the same.

Step 4 Check the connection sequence of the transmit and receive fibers. It is found that the transmitand receive fibers are connected correctly, indicating that the fault is not associated with theoptical fiber connection.

Step 5 Given that the running indicators on the IPMD and PVMD boards are green and they are on forone second and off for one second, the subrack housing the two boards is receiving power. TheRUN indicator on the A32 board, however, is continuously on, indicating that the -48 V powersource of the device may be disconnected. Remove the PSTF board and re-insert it. It is foundthat the fault persists.

Step 6 Replace the PSTF board with another. It is found that the RUN indicator on the A32 board runsproperly and that the LINK indicator of the GE optical port on the IPMD board is continuouslyon, indicating that the fault is rectified.

----End



239

Suggestion and Summaryl The PSTF board is a front-access power transfer board used to provide -48 V power for the

system. When the -48 V power supply for a subrack cannot be detected, replacing the PSTFboard may address the problem.

l Failures of the -48 V power supply may cause faults on some modules in the system. Whenthe IPMD board of a UA5000 is not working properly, replacing the PSTF board mayaddress the problem.

l The A32 board uses -48 V power for operation. If the RUN indicator on the A32 board iscontinuously on, replacing the PSTF board may address the problem.

TC-A0264 Circuit and Subscriber Line Test Failures on the CSRB Board Due toHWCB Board Faults

This case describes how to troubleshoot the circuit and subscriber line test failures on the CSRBboard due to HWCB board faults.

Fault TypeService abnormality

Narrowband service


Fault DescriptionThe UA5000 is configured with HABA rear-access subracks, PVMB control boards, and CSRBand A32 service boards. A circuit or subscriber line test performed on a CSRB board failswhereas the test on an A32 board is successful.


Cause Analysisl No RATB board is configured.l The CSRB board is faulty.l The RATB board is faulty.l The HWCB board is faulty.

Procedure

Step 1 Check board configurations. It is found that the RATB board has been configured correctly.

Step 2 Perform a circuit or subscriber line test on the CSRB boards in other slots in the HABA subrack.The test fails. This temporarily indicates that the CSRB boards are normal. The RATB boardsin an entire subrack generally are not faulty at the same time. Therefore, the RATB boards aretemporarily considered normal.



240

Step 3 Replace the HWCB board and perform a test. It is found that the fault is rectified.

----End

Suggestions and Summaryl If the circuit and subscriber line tests on the A32 boards in the same subrack are successful,

the TSSB board, test bus, and test group are normal.

l When the circuit or subscriber line test on the A32 boards in the same subrack is successfulwhereas the test on the CSRB boards fails, replace the transfer board to check whether thefault can be rectified.

l A32 boards support the line capturing function whereas CSRB boards do not support sucha function. Therefore, an RATB transfer board, is powered by a HWCB transfer board, isrequired to support the function.

TC-A0021 The Number Unobtainable Tone Is Played in the Case of the UA5000Voice Service with High-Volume Traffic Due to Severe Packet Loss of the BearerNetwork

This topic describes how to troubleshoot the fault when the number unobtainable tone is playedin the case of the UA5000 voice service with high-volume traffic due to severe packet loss ofthe bearer network.

Fault Type

Narrowband service

Packet loss

Keyword

Number unobtainable tone

Phenomenon Description

The frequency of the number unobtainable tone played after dialing is high and not all the callscan be made successfully.

Alarm Information

None

Cause Analysis


l The telephone set is faulty.

l The digit collection mode is incorrect.

l The bearer network is faulty.



241

Procedure

Step 1 Replace the telephone set with the telephone sets of various types, and the fault persists.

Step 2 Check the data on site. It is found that the data is correct. Trace the signaling of the softswitch.It is found that the digitmap matching is correct.

Step 3 In the transit exchange, trace signaling system number 7 (SS7). It is found that the receivednumber and the dialed number are different, and certain dialed digits are lost. Sending the pingpackets to the gateway proves severe packet loss, and the packet loss rate reaches 35%. Thebandwidth of the egress of the transit exchange is 100 Mbit/s. The broadband services, NGNservices, and data detection occupy 90 Mbit/s. After the bandwidth is expanded, the fault isrectified.

----End

Suggestion and SummaryPacket loss on the network causes information loss and in this case the received number and thedialed number are different, and thus the number unobtainable tone is played.

TC-A0078 A Large Number of UA5000 Users Go Offline Because the Upper-LayerSoftswitch Processes the H.248 Messages Incorrectly

This case describes how to troubleshoot the fault wherein a large number of UA5000 users gooffline because the upper-layer softswitch processes the H.248 messages incorrectly.

Fault TypeOther

Service exception

KeywordDatabase

Configuration file

Fault Descriptionl Networking: UA5000 -> switch -> softswitchl Fault description: On a newly-deployed site, all the users are connected normally, but a

large number of users go offline during calls. The symptom is relieved after the active andstandby PVM boards of the UA5000 are switched over. The fault, however, recurs one daylater.





242

l The quality of the bearer network is poor.l The softswitch is faulty.

Procedure

Step 1 The display h248statics command is executed to check the send-and-receive information aboutthe H.248 messages. It is found that the numbers of re-sent and re-received H.248 messages areincreasing.

Step 2 The packets are pinged to check the quality of the bearer network. It is found that the networktransmission condition is good, no packet is lost, and no packet with long delay is transmitted.

Step 3 The H.248 messages are traced. It is found that the UA5000 sends a large number of user on-hook messages.

Step 4 The on-hook messages are further analyzed. It is found that the transaction IDs (TIDs) in theon-hook messages are different from the TIDs of the current calls. In addition, it is found that alarge number of on-hook messages are constantly sent with the TIDs corresponding to the portsthat do not carry any calls. After the analysis of the messages for the current calls, it is foundthat the UA5000 fails to receive the acknowledge messages from the softswitch after sendingthe on-hook messages. Therefore, it is determined that the UA5000 constantly retransmits theon-hook messages because the upper-layer device processes the messages incorrectly.

Step 5 The softswitch is upgraded by the maintenance personnel through a patch. Then, it is found thatthe fault is rectified.

----End


TC-A0168 Occasional Absence of Dial Tone After Offhook Due to Packet LossThis case describes the troubleshooting of the occasional absence of dial tone after offhook,which occurred on the user of a UA5000. The fault occurred due to the packet loss on the network.


Packet loss

KeywordPacket loss on the network

Fault DescriptionNetwork topology: UA5000 -> OLT (MA5680T) -> router -> softswitch

Fault symptom: After the user of the UA5000 took the phone off the hook, there wouldoccasionally be no dial tone, even though the power feed was normal. The service would bespontaneously restored after a certain period of time.



243

Alarm Information

An alarm "QOS Exceeds Threshold Alarm" was displayed on the HyperTerminal.

Cause Analysis


l Packets loss occurred on the network.

l The DSP daughter board was faulty.

Procedure

Step 1 The alarm history on the device was checked. No DSP chip fault alarm was found, indicatingthat the DSP resource allocation was normal.

Step 2 The softswitch was pinged from the UA5000. Occasional packet loss was found.huawei(config)#ping 101.144.82.114 PING 101.144.82.114: 56 data bytes, press CTRL_C to break Reply from 101.144.82.114: bytes=56 Sequence=999 ttl=28 time=2 ms

--- 101.144.82.114 ping statistics --- 100 packet(s) transmitted 999 packet(s) received 0.10% packet loss round-trip min/avg/max = 2/2/5 ms

Step 3 Packets were captured on the UA5000. The analysis showed that the user was not released bythe softswitch but was still in the previous context when the fault occurred. The result was thatthe softswitch failed to send a dial tone when the user took the phone off the hook. The suspectedcause of the fault was that the port status on the softswitch and the port status on the AG wereinconsistent because of the loss of the detection event sent after the user hung up at the end ofthe previous call. The detection event loss was caused by the packet loss in the last call.

Step 4 The fault was rectified by executing the if-h248 attribute command on the UA5000 to changethe transmission protocol to UDP, and the h248stack command to change the transmission modeto fixed retransmission mode. The commands for the two operations are as follows:huawei(config-if-h248-0)#if-h248 attribute transfer alf/udphuawei(config-if-h248-0)#h248stack tr retransmode fixed 1000

----End


When a packet loss alarm is generated on the network, the first consideration is to troubleshootnetwork problems, which is a fundamental measure to resolve the problem. If packet loss onlyoccurs occasionally, and the loss is not critical, the fault can also be rectified by setting theredundancy transmission mode on the UA5000.

16.1.2 Environment Monitoring FaultThis topic provides the analysis of the case related to the environment monitoring fault.



244

TC-A0177 Battery Power Supply Failure After Mains Power Cutoff, Due to the Faulton the EPMU in a Newly Deployed E200 Cabinet

This case describes the troubleshooting of the battery power supply failure after mains powercutoff. The fault occurred because the power monitoring module EPMU of the newly deployedE200 cabinet was faulty.

Fault Type

Other

Environment monitoring fault

Key Word

EPS30-4815AF

Fault Description

Problem symptom:

l The new deployed E200 cabinet used EPS30-4815AF for AC-DC power conversion. Thecontrol board was RSU4 and the virtual control board was VRSP. In addition, themonitoring module was EPMU and the rectifier module was GERM4815T.

l When the external mains power was cut off, it was found that the E200 cabinet could notswitch to the battery power supply mode.

Alarm Information

The following alarms were displayed in the alarm system of the BAM:

2009-10-30 11:35:29 Battery power-off Alarm ID 0830 Alarm source ESC2009-10-30 11:35:29 Battery circuit 1 is disconnected Alarm ID 0831 Alarm source ESC2009-10-30 11:35:29 High temperature battery power-off alarm Alarm ID 0855 Alarm source ESC

Cause Analysis


l The voltage of the battery set was very low, resulting in the failure of power supply by thebattery.

l The connection between the battery set and the E200 was incorrect.

l The data confirmation of the device for power monitoring was incorrect.

l The power monitoring module of the device was faulty.

Procedure

Step 1 The total voltage of the battery set was tested. It was found that the total voltage was –52 V.Then, the voltage of a single battery was tested. It was found that the voltage of each batterywas about -13 V, indicating that the battery set was normal.



245

Step 2 The internal circuit connection of the E200 was checked by using a multimeter according to theinternal circuit diagram of the device. It was found that the circuit conductivity was normal.

Step 3 The power configuration window of the H303ESC board was opened in the BAM monitoringsystem. In the configuration window, serial port 1 was configured to no power supply, and thenthe ESC board on the NE was deleted after the configuration was submitted. After the ESC boardwas deleted successfully, the H303ESC board was re-added and serial port 1 was configured toPS4845 power. Then, the configuration was submitted again and a test was performed againafter the mains power was cut off. It was found that the fault persisted.

Step 4 The real-time parameters of the battery were checked in the BAM monitoring system. It wasfound that the battery power supply state was power-off, the circuit was in the disconnectedstatus, and the battery temperature was 80°C. In addition, the battery power-off due to hightemperature alarm was reported in the alarm system. Therefore, it was hypothesized that thetemperature of the battery was excessively high and thus the monitoring module automaticallypowered off the battery as a protection mechanism, resulting in the failure of the system to switchto the battery power supply mode when the mains power was cut off.

Step 5 The surface of the battery was touched to check whether the temperature was high. It was foundthat the temperature was not high. However, the battery set was replaced with a new battery set.It was found that the fault persisted.

Step 6 The monitoring module was removed on site. The subsequent test showed that the batterysupplies power normally. After the monitoring module was replaced with a new monitoringmodule, it was found that the fault was rectified.

----End

Suggestions and SummaryThe fault of the monitoring module may result in incorrect measurement of the batterytemperature. Therefore, it is necessary to pay attention to the monitoring module problems whenlocating a fault wherein the battery works abnormally.

TC-A0183 POWER4845 EMU Fault Due to the HWCF BoardThis case describes the troubleshooting of the POWER4845 environment monitoring unit(EMU) that was faulty due to an HWCF board fault.

Fault TypeOther


KeywordEMU

Fault DescriptionA UA5000 that used POWER4845 EMU reported an EMU fault.

Alarm InformationThe "EMU Fault Alarm" was displayed on the HyperTerminal.



246

Cause AnalysisThe possible causes were as follows:

l The data configuration of the EMU was incorrect.l The PSM module was faulty.l The environment monitoring cable was connected incorrectly.l The HWCF transfer board was faulty.

Procedure

Step 1 The PSM module was checked on site. It was found that the hardware model of the PSM modulewas PSM-B9, and that the DIP switches were all set to OFF after the PSM module was removed.In addition, it was found that the type of the EMU was POWER4845 and that the sub-node IDwas 0, indicating that the data configuration of the EMU was correct.

Step 2 The indicators on the PSM module were checked. It was found that the ALARM indicator wasoff and that the RUN indicator blinked slowly, indicating that the PSM worked in the normalstate.

Step 3 The cable connection on the EMU was checked. It was found that the COM port and MS porton PSM-B9 were connected to the STACK OUT port on the HWCF board, and that other cableswere also connected properly, indicating that the fault was not caused by cable connectionproblems of the EMU.

Step 4 The HWCF board was suspected of causing the fault. After the HWCF board was replaced, thefault was rectified.

----End

Suggestions and SummaryThe HWCF board is used to transfer the HW signals from the slave and extended shelves, andthe EMU messages. Note that the narrowband services on the slave and extended shelves areinterrupted when you replace the HWCF board.

TC-A0185 Automatic Power-Off of the Battery Set in F01D500 Cabinet Due to Over-High Temperature

This case describes the troubleshooting of the automatic power-off of batteries used in anF01D500 cabinet because the temperature of the battery set was very high.

Fault TypeOther

Environment monitoring

KeywordsBattery power-off

Battery loop broken

Integrated device



247

Fault DescriptionThe "Battery off Alarm" and "Battery Loop Broken Alarm" were frequently reported on aUA5000 that used F01D500 cabinet.

Alarm InformationThe "Battery off Alarm" and "Battery Loop Broken Alarm" were displayed on theHyperTerminal.


l The voltage was very low after discharging of the battery set.l The temperature of the battery set was very high.

Procedure

Step 1 Given that the "Battery off Alarm" was generated before the "Battery Loop Broken Alarm", thefirst step was to check whether the power-off was caused by low battery voltage. After the mainspower supply was cut off, it was found that the mains power cutoff alarm was reported normally.In this case, however, the fact was that no mains power cutoff alarm was reported before the"Battery off Alarm", indicating that the mains power supply was not cut off. Therefore, it wasdetermined that the battery set did not discharge, indicating that the fault was not caused by lowbattery voltage.

Step 2 The display power run info command was executed to check the battery configuration of thedevice. It was found that the "battery power-off permit state" parameter was set to "permitted".After the alarm logs are checked, it was found that all the alarms were generated at about 11:00AM or 12:00 AM, and that the alarms were cleared at night or before daybreak. Given that ahigh-temperature alarm was generated before the battery power-off, it was hypothesized that thefault was caused by high temperature. The result of executing the display power run infocommand was as follows:huawei(config-if-power4845-0)#display power run infoEMU ID: 0Running information about the power system----------------------------------------------------------------------------Current restriction state: not restrictedEven-float charging conversion control status: auto control Charging state: float chargingLoad power-off permit state: permittedBattery power-off permit state: permittedNumber of power units: 2Address of power unit 0: 1Type of the power unit 0: 2Address of power unit 1: 2Type of the power unit 1: 2Address of power unit 2: not configuredType of power unit 2: not configuredTotal line bank voltage: 53.174AC voltage (V): 232.812Total current of the power unit (A): 13.074Current of battery group 0 (A): 0.373Load high-temperature power-off permit state: permittedLoad high-temperature power-off temperature(¡æ): 65Battery high-temperature power-off permit state: permittedBattery high-temperature power-off temperature(¡æ): 50Remaining capacity of the battery: 100 %



248

---------------------------------------------------------------------------huawei(config-if-power4845-0)#display power environment info EMU ID: 0Analog Parameter Information---------------------------------Battery group temperature: 29.413¡æAmbient temperature: 25.817¡æAmbient humidity: 24.444%R.H(If you do not connect the EMU with any of the previous three sensors, the previous values are the default and the upper/lower alarm thresholds are invalid.)Analog parameter ID Name Current value Unit 2 Current on the current restriction point 20.500 A 3 Output voltage of monitoring control module 53.140 V ----------------------------------------------------------------------------

Step 3 The running status of the heat exchanger was checked to locate the fault that caused hightemperature. It was found that the RUN indicator on the heat exchanger was on whereas theALARM indicator was off, indicating that the heat exchanger worked normally. After thereset button on the heat exchanger was pressed, the heat exchanger was reset and auto-checked.It was found that the internal circulation and external circulation fans worked normally.

Step 4 A further check showed that there was a large volume of wind at the upper and lower ventilationopenings inside of the cabinet, indicating that the heat circulation inside the cabinet was normal.

Step 5 The heat exchanger was powered off and the cover on the external circulation fan of the heatexchanger was removed. It was found that a lot of dust blocked the areas below the cooling fins,affecting the external circulation to a great extent. After the dust was cleaned, the devicetemperature returned to a normal value and no battery power-off alarm was generated on thedevice any more.

----End


It is necessary to maintain and clean the heat exchanger regularly, to prevent the battery power-off because of the high temperature inside of the cabinet.

TC-A0189 Absence of Ringing Tone Due to Burn-Out of the Connector on thePower Interface Board in HABD Shelf in F01D500 Cabinet

This case describes the troubleshooting of the absence of ringing tone for uses of a UA5000 dueto the burn-out of the connector on the power interface board in the HABD shelf in F01D500cabinet.

Fault Type

Other


Keywords

Subtending

Power board



249

Fault Description

l The ringing tone was not played for all the users connected to the HABD shelf of theUA5000, but the users could make or answer phone calls normally.

l The indicators on the secondary power board were abnormal, that was, the VIN (RUN)indicator was on, the VA0 indicator was off, the VB0 indicator was on, the VC0 indicatorwas on, and the FAIL indicator blinked.

Alarm Information

None

Cause Analysis


From the symptom that the absence of ringing tone occurred on all the users connected to theHABD shelf whereas the conversation by phone could still be successful, it could be determinedthat the ringing current provided by the power board was abnormal. In addition, the symptomthat the VAO indicator on the power board also showed that the ringing current on the powerboard was abnormal.

Procedure

Step 1 After the secondary power board was replaced, it was found that the fault persisted and that theindicators on the power board were still abnormal.

Step 2 During the process of replacing the secondary power board, a sign of circuit burn-out was foundon the power interface board in the most left part of the shelf. The power interface board providesthe following connectors:l PWRIO-48V, which connects to the output port of the -48 V DC power.l PWRIO+5V, which connects to the +5V power port on the HABF shelf of the UA5000 by

using an inter-shelf +5 V power cable.l PWRIO-5V/RNG, which connects to the -5V/ringing current power port on the HABF shelf

of the UA5000 by using an inter-shelf -5V/ringing current power cable.

Step 3 The shelf was powered off and the cable connected to the PWRIO-5V/RNG port wasdisconnected on the rear side of the power interface board. Then, the device was powered onagain. It was found that the indicators on the secondary power board returned to normal stateand that the ringing tones could be played normally for users.

NOTE

The disconnection of the subtending cable to the PWRIO-5V/RNG port did not affect the service becausethe extended shelf of the UA5000 was not configured with the service.

----End


Similar power problems often occur on outdoor cabinets of the UA5000 in a thunderstormweather. To troubleshoot such problems, it is necessary to master the skills of cabling andconnecting of the power cable.



250

TC-A0207 Rotation Stop on the External Circulation Fans of the Heat Exchanger ona D500 Due to -48 V Power Supply Input Failure

This case describes the troubleshooting of the rotation stop on the external circulation fans ofthe heat exchanger on the d500 due to -48 v power supply input failure.

Fault Type

Other


Keywords

Fan fault

Heat exchanger

Fault Description

l The temperature inside the D500 outdoor cabinet on a site was very high. Fans inside thecabinet (inner cycle system) rotated normally, however, the lower fans (external cyclesystem) did not rotate.

l The indicators (including the power indicator and the alarm indicator) on the front panelof the heat exchanger were on.

NOTE

The heat exchanger consists of internal cycle fan, external cycle fan, heat exchange plates, and monitoringbox. The working voltage of the fan was 220 V AC and the working voltage of the monitoring board was-48 V DC.

Alarm Information

None

Cause Analysis


l The AC power supply was abnormal.

l The monitoring board was faulty or worked abnormally.

l A fan was faulty.

Procedure

Step 1 The AC voltage in the site was measured. It was found that the voltage was normal (230 V).

Step 2 The DC power supply system of the heat exchanger was checked. It was found that the miniaturecircuit breaker (MCB) was disconnected. Then, the MCB was connected. The alarm LED wasoff and the lower fans did not rotate.

Step 3 Several minutes later, the lower fans began to rotate and then worked normally.



251

NOTE

The fan system was controlled by the temperature by default, and the fans began to rotate for several minutesafter the MCB was connected.

----End

Suggestions and Summaryl Whether the lower fans work normally is not only related to the 220 VAC power system

but also related to the normal running of the monitoring board.

l You can query the power alarm "Load fuse 0" status (connect, disconnect) of Power4845on site to determine whether the heat exchanger works in the normal state. See the followingexample:huawei(config-if-power4845-0)#display power alarm EMU ID: 0 Power alarm information ---------------------------------------------------------------------------- Mains supply yes : Yes Mains supply lack : Normal Total Vol lack : Normal Load fuse 0 : Connect Second fuse : Connect Load off : On Battery off : On Battery 0 loop : Connect Environment Temperature : Normal Environment Humidity : Normal Door alarm : Normal Water alarm : Normal Fog alarm : Normal Wiring alarm : Normal Module 0 : Normal Module 1 : Normal Module 2 : Normal Battery temperature off state : Normal Load temperature off state : Normal ---------------------------------------------------------------------------- Name State |Name State Spare Dig0 Alarm |Spare Dig1 Alarm Spare Dig2 Alarm |Spare Dig3 Alarm Spare Dig4 Normal|Spare Dig5 Alarm Spare Dig6(rejiaohuanqi) Normal --------------------------------------------------------------------------

TC-A0253 Abnormal Output Voltage of the Rectifier Module Caused by IncorrectPower Protocol File

This case describes how to troubleshoot the abnormal output voltage of a UA5000 rectifiermodule caused by an incorrect power protocol file loaded on the UA5000.

Fault Type


Other

Keywords

EMU


Power

Monitoring module



252

Fault DescriptionThe output voltage of the power rectifier module on a UA5000 is 62144955547648.000 V.


Cause Analysisl The power monitoring module is faulty.l The system processes data incorrectly.l The power protocol file loaded on the device is incorrect.

ProcedureStep 1 Replace the power monitoring module on the device with another one. It is found that the fault

persists, indicating that the power monitoring module is functional.

Step 2 Given that the fault did not occur on the UA5000s loaded with the same system software onother sites, perform an active/standby switchover on the affected UA5000. It is found that thefault persists, indicating that the fault is not caused by a data processing problem on the UA5000.

Step 3 Run the display esc power run info command to check the power protocol file loaded on theUA5000. It is found that the loaded file is incorrect.

Step 4 Run the load universal-power-protocol command to load the correct power protocol file onthe UA5000, and then perform another test. It is found that the fault is rectified.

----End

Suggestion and SummaryWhen the output voltage of the power rectifier module is abnormal, check whether the powerprotocol file loaded on the device is correct.

16.1.3 NMS Losing Control over the NEThis topic provides the analysis of the cases related to NMS losing control over the NE.

TC-A0055 Upstream Service Transmission Fails Because the Uplink Port Mode ofthe PVMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the upstream service transmission failsbecause the uplink port mode of the PVMD board is selected incorrectly.

Fault TypeOther

NMS losing control over the device

KeywordUplink port mode



253

ETH1

Fault Description

The PVMD board of the UA5000 works in the independent mode for the upstream transmission,and the services are transmitted upstream through the ETH1 electrical port. After the networkcable is connected to the ETH1 port, however, the indicator of the port is off and the board cannotping the gateway successfully.

Alarm Information

None

Cause Analysis


l The network cable is faulty.

l The configuration of the PVMD board is incorrect.

Procedure

Step 1 A normal network cable is used to connect to the uplink port. If it is found that the fault stillexists, it indicates that the fault is not caused by the network cable fault.

Step 2 The display working mode command is executed to check the working mode of the PVMDboard. It is found that the uplink mode of the board is the independent mode and that the uplinkport is an FE optical port. The uplink port, however, is required to be an ETH1 electrical port.huawei#display working mode working mode:alone outband port:ETH port service port:FE optic port

Step 3 The up-linkport set workmode command is executed to change the uplink port mode to ETH1port. Then, it is found that the indicator of the ETH1 port is on and that the PVMD board canping the upper-layer device successfully. This indicates that the fault is rectified.huawei(config)#up-linkport set workmode { workmode<E><ETH1,FE-O,GE-O> }:ETH1 Command: up-linkport set workmode ETH1

----End


Compared with the PVMB board, the PVMD board supports the upstream transmission throughthe optical port. Therefore, when the PVMD board is used as the control board of the UA5000,you must configure the mode of the uplink port to optical port or electrical port mode accordingto the actual attributes of the physical port.



254

TC-A0071 The Upgraded UA5000 Fails to Register with the Softswitch of CompanyB Because the Versions Before and After the Upgrade Are Inconsistent

This case describes how to troubleshoot the fault wherein the upgraded UA5000 fails to registerwith the softswitch of company B because the versions before and after the upgrade areinconsistent.

Fault TypeOther

Service exception

KeywordCutover

Fault DescriptionA UA5000 is upgraded from V100R011B02D078 to V100R013C05B051 because it needs toregister with the softswitch of company B from the original softswitch. After the upgrade issuccessful, it is found that the registration address of the UA5000 is changed and the H.248interface cannot register with the softswitch normally after being reset. The display if-h248all command is executed to check the information about the H.248 interface. It is found that theMGC/DOmainName parameter is displayed in the form of domain name, rather than IP address.



l The MIDType parameter of the MGC is not set to IP4_ADDR.l The H.248 interface is not cold started after the registration address of the UA5000 is

changed.l The H.248 interface parameters of the UA5000 are configured incorrectly.l An error occurs when the UA5000 is upgraded from R011B02D078 to R013C05B051.

Procedure

Step 1 The MIDType parameter of the MGC is set to IP4_ADDR and the reset coldstart command isexecuted to reset the H.248 interface. Then, the display if-h248 all command is executed on theUA5000 to check the information about the H.248 interface. It is found that the MGC/DOmainName parameter is still displayed in the form of a domain name, rather than IP address.

Step 2 The display if-h248 attribute command is executed on the UA5000 to check the parameters ofthe H.248 interface, and then the parameters are compared with the H.248 parameters of theUA5000 that has already registered successfully with the softswitch of company B. It is foundthat the Active MGC MGC Domain Name parameter of the successfully registered UA5000 isnull.



255

Step 3 The if-h248 attribute command is executed on the abnormal UA5000 to reconfigure the mgc-domain-name1 parameter to null, and then the H.248 interface is reset. It is found that the serviceis restored.

----End

Suggestions and Summaryl This fault does not occur when the UA5000 that is upgraded from V100R011D087 or

V100R013C03B032 to V100R013C05B051 registers with the softswitch of company Bfrom the original softswitch. Therefore, before the upgrade, you need to read through therelease notes and patch release notes of the target version of the upgrade, and learn theversion differences in advance.

l If the UA5000 fails to register normally, you can compare the H.248 parameters of thenormal UA5000 with the corresponding parameters of the abnormal UA5000. This helpslocate the fault rapidly.

TC-A0072 The UA5000 Fails to Register with the Softswitch Server Because thedual-homing function of the UA5000 is disabled

This case describes how to troubleshoot the fault wherein the UA5000 fails to register with thesoftswitch server because the dual-homing function of the UA5000 is disabled.

Fault Type

Other


Keyword

Dual-homing

Fault Description

During a new deployment, the UA5000 is connected to the softswitch. The IP addresses of thegateway and the softswitch can be pinged through from the UA5000, but the UA5000 fails toregister with the softswitch after the MG interface is reset on the UA5000.

Alarm Information

None

Cause Analysis


l The optical fiber jumpers are abnormal.l The negotiation data configured on the softswitch is inconsistent with the corresponding

data on the UA5000.l The address of the UA5000 for the registration with the softswitch is incorrect.



256

Procedure

Step 1 The LINK indicator for the optical fiber is checked. It is found that the indicator is on. In addition,considering the fact that the IP addresses of the network management system (NMS) and otherdevices can be pinged through from the UA5000, it can be determined that the fault is not causedby the optical fiber.

Step 2 The operator is contacted to check the data configured on the softswitch. It is found that the dataconfigured on the softswitch is consistent with the data on the UA5000.

Step 3 The messages are traced. It is found that the registration message reported by the UA5000 isinconsistent with the message returned by the softswitch. The message traced on the softswitch,however, shows that the softswitch fails to receive the message sent by the UA5000. TheUA5000 may fail to register with the correct softswitch.

Step 4 The display mg-software parameter 2 command is executed to check the dual-homing functionof the UA5000. It is found that the dual-homing function of the UA5000 for registering with thesoftswitch is disabled. As a result, after the UA5000 fails to register with one softswitch, it cannotregister with another softswitch. After this cause is identified, the mg-software parameter 22 command is executed to enable the dual-homing function of the UA5000. Then, the fault isrectified.

----End


TC-A0076 The Network Port Cannot Be Activated Because the Mode of the UplinkPort on the IPMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the network port cannot be activatedbecause the mode of the uplink port on the IPMD board is incorrect.

Fault TypeOther


KeywordElectrical port

Fault Descriptionl Networking: UA5000 (IPMD) -> Ethernet switchl Fault description: A newly-deployed UA5000 is connected to the switch through the ETH0

port on the IPMD control board. After the two devices are connected, the network portcannot be activated.




257


l The network cable is faulty.l The Ethernet port on the peer device is configured incorrectly.l The configuration of the ETH0 port on the IPMD board is incorrect, or the control board

of the UA5000 is faulty.

Procedure

Step 1 The in-use network cable is replaced by another normal straight through network cable. Thesubsequent test shows that the fault persists.

Step 2 The peer device is directly connected to a PC through the network cable. It is found that thenetwork port can be activated. This indicates that the peer device is normal. After the PC isdirectly connected to the IPMD board, it is found that the port cannot be activated. This indicatesthat the fault occurs on the IPMD control board.

Step 3 The fault may be caused by incorrect port configuration, because the IPMD board supports twomodes for upstream transmission, namely, electrical port mode and optical port mode. Therefore,the display port state 0 command is executed to query the status of the ETH0 port. The queryresult is as follows:huawei(config-if-ipm-0/2)#display port state 0 ----------------------------------------------------------------------------- Port Port Native MDI Speed Duplex Flow- Active Link Type VLAN (Mbps) Control State ----------------------------------------------------------------------------- 0 GE-Optic 3 - 1000 full off active offline

The command output shows that port ETH0 is configured to an optical port. Then, the mode 0GE-Electrical command is executed to forcibly change the mode of the ETH0 port to a Gigabitelectrical port. The port, however, still cannot be activated.

Step 4 The further confirmation verifies that the port on the peer device is a Megabit electrical port.Therefore, the speed 0 100 command is executed in IPM mode to change the mode of ETH0port to a Megabit electrical port. Then, the test shows that the network port can be activatednormally.

----End

Suggestions and SummaryThe IPMD control board uses the Gigabit optical port mode for upstream transmission by default.In the actual application, if a Gigabit optical port or electrical port is required for upstreamtransmission, the port mode must be changed accordingly. In addition, the data configuration ofthe port on the peer device must be consistent with the data configuration of the port on theUA5000.

TC-A0122 The Broadband N2000BMS on the UA5000 Always Loses Control overDevices Because the Number of Learnable MAC Addresses of the ONU Is Small

This case describes how to troubleshoot the fault wherein the broadband N2000BMS on theUA5000 always loses control over devices because the number of learnable MAC addresses ofthe ONU is small.



258

Fault Type

Other

N2000 BMS losing control over the device

Keyword

Lose control

Fault Description

Fault description: The UA5000 adopts the integrated upstream mode, and the IPMB board isconnected upstream to the ONU. The N2000 BMS controls the PVMB board normally but losescontrol over the IPMB board.

Alarm Information

The N2000 BMS reports the "NE communication interruption" alarm.

Cause Analysis


l The quality of the upper-layer network is poor.

l The IPMB board is faulty.

l The ONU is faulty.

Procedure

Step 1 When the N2000 BMS loses control over the IPMB board, the management IP address of theIPMB board cannot be pinged from the N2000 BMS. The management IP address (the signalingVLAN is the same as the N2000 BMS VLAN) of the PVMB board, however, can be pinged.Therefore, the fault is not caused by the upper-layer network.

Step 2 The IPMB board is replaced. It is found that the fault persists. This indicates that the fault is notcaused by the IPMB board fault.

Step 3 The MAC address learning information is checked on the ONU. It is found that the number oflearnable MAC addresses on the ONU reaches 64. The MAC addresses of the signaling VLANof the PVMB board are included, but the MAC addresses of the management VLAN of the IPMBboard are not included. It is considered that the number of learnable MAC addresses on the ONUmay reach the limit. As a result, the N2000 BMS always loses control over the IPMB boardbecause of the overflow of MAC addresses. The ONU is replaced with an ONU with a largernumber of learnable MAC addresses. The fault that the N2000 BMS loses control over the IPMBboard is rectified.

----End


None



259

TC-A0173 Inaccessibility of Network Management Channel of a UA5000 Due to aLoop on the Upper-Layer Switch

This case describes the troubleshooting of a UA5000 on which the network management channelwas inaccessible due to a loop on the upper-layer switch.



KeywordsNMS

Self-loop

Fault DescriptionNetwork topology: UA5000 -> S3900 -> S8512 -> NE40E

NOTEThe network management gateway was configured on the S3900 and the voice service gateway was configuredon the NE40E. The UA5000 transmitted services upstream in integrated mode, and the IPMB broadband controlboard and PVMB narrowband control board were configured in the same network segment.

Fault symptom: Pinging the network management IP address of the PVMB control board fromthe IPMB control board failed, and both the voice service channel and network managementchannel of the UA5000 were inaccessible.



l The data configuration on the UA5000 was incorrect.l The internal ports on the PVMB and IPMB control boards were faulty.l The MAC address of the PVMB control board was in a conflict with the MAC address of

another device.l A loop occurred on the upper-layer switch.

Procedure

Step 1 The data configurations of the IPMB and PVMB control boards were checked and found to becorrect.

Step 2 The status of the internal ports on the IPMB and PVMB control boards was checked by runningthe display port state command on the two boards. It was found that the internal ports wereboth online and in 100 Mbit/s full-duplex working mode, indicating that the internal ports onthe two boards were normal.



260

Step 3 The display arp x.x.x.x command (x.x.x.x represents the network management IP address ofthe PVMB control board) was executed on the IPMB control board to query the ARP mappinginformation. It was found that the network management IP address of the PVMB control boardwas learned on the uplink port rather than on the internal port of the IPMB control board.Therefore, it was suspected that a loop had occurred on the upper-layer switch or the MACaddress of the PVMB control board was in a conflict with the MAC address of another device.

Step 4 The MAC address of the PVMB control board was changed. A test showed that the faultpersisted.

Step 5 The upstream optical fiber connected to the IPMB control board was removed. It was found thatthe IPMB control board learned the ARP information about the PVMB control board from theinternal port, and that the IPMB control board communicated with the PVMB control boardnormally.

Step 6 The upper-layer switch was checked. It was found that the MAC address of the PVMB controlboard drifted between two ports. Then, after the two ports were shut down on the switch, thenetwork management channel of the UA5000 was accessible.

Step 7 The layer-2 switch connected to the S3900 was checked. It was found that a loop (optical fiberself-loop) occurred on the layer-2 switch. When the loop problem was resolved and the twoshutdown ports were opened, the fault on the UA5000 was rectified.

----End

Suggestions and SummaryIn normal state, the IPMB control board can communicate with the PVMB control board. If thetwo boards fail to communicate with each other, check whether the IPMB control board canlearn the ARP information of the PVMB control board normally. If the IPMB control boardlearns the ARP information about the PVMB control board from the uplink port, it is mostpossible that a loop occurs on the upper-layer switch of the UA5000. In such a case, the MACaddress of the PVMB control board drifts on the switch.

TC-A0200 Communication Failure Between the UA5000 and the NMS Server Dueto the Lack of Network Management Route

This case describes the troubleshooting of the communication failure between the UA5000 andthe network management system (NMS) server because the network management route was notadded.

Fault TypeOther


KeywordRoute configuration

NMS management

Fault DescriptionNetwork topology: UA5000 (PVMD) -> router (S8505) –> NMS server



261

The PVMD board was connected to the NMS through the ETH port in the outband networkmanagement mode. The IP address of the NMS server and that of the PVMD were not in thesame subnet. After the outband network management IP address of the PVMD was configured,the PVMD failed to ping the NMS server.



l The route on the bearer network was unreachable.l The routing entry on the S8505 was incorrect.l The network management route was not configured on the PVMD board.

Procedure

Step 1 The PVMD board could normally ping its own gateway and the gateway could ping the NMSserver too. Therefore the gateway from the PVMB board to the gateway was normal. The linkfrom the NMS server to the gateway was normal. Therefore, the bearer network was normal.

Step 2 It was suspected that the gateway of PVMD and the routing entry of S8505 may not be updated.After the routing entry was updated, the fault persisted.

Step 3 It was found that the PVMD board was a newly manufactured board. Therefore, a route mustbe added for outband network management.huawei(diagnose)%%outband { route<K> }:route { add<K>|delete<K> }:add { ip_address<X.X.X.X> }:10.144.5.6 /* The IP address of the NMS server.*/ { submask<M><X.X.X.X> }:255.255.255.0

After the network management route was added, the communication between the PVMD boardand the NMS server was restored.

----End


TC-A0201 Failure of UA5000 to Register by Using the Domain Name Due to theLack of MIDType Configuration

This case describes the troubleshooting of a UA5000 that failed to register with the Softswitchby using the domain name because the MIDType was not configured.





262

Keywords

Midtype

Domain name

Fault Description

The UA5000 failed to register with the softswitch by using the domain name.

Alarm Information

None

Cause Analysis


l The domain name was configured incorrectly.l The UA5000 MG interface was not reset.l The data configuration of the softswitch was incorrect.

Procedure

Step 1 The domain name of the UA5000 was checked. It was found that the domain name wasconfigured correctly and the MG interface had been reset. However, the fault persisted.

Step 2 The interconnection parameters on the softswitch and the UA5000 were checked. It was foundthat the interconnection parameters were consistent on both sides.

Step 3 The display if-h248 attribute command was executed to check parameter domain name of theUA5000. It was found that the value of the MIDType was IP4_ADDR.

NOTE

MIDType was an information identifier. It was displayed in the message header to identify the messagesender. The default parameter ip4Address was used to configure the MID type of H.248 messages of aspecified MG interface.

Step 4 The if-h248 attribute command was executed to change the message identifier (MID) type ofH.248 messages to domainName, and thus the UA5000 can register by using the domain name.The specific configurations were as follows:huawei(config-if-h248-1)#if-h248 attribute miDType{ MIDTypeVal<E><ip4Address,domainName,deviceName> }:domainName

Step 5 After the MID of H.248 messages was modified, the MG interface was reset. As a result, theUA5000 could register normally by using the domain name, and the problem was solved.

----End


As for H.248 messages, the MID type is not mandatory under the H.248 protocol. By default,the UA5000 registers with MGC by using the IP address+port number. When registering theUA5000 by using a domain name, the interface attributes must be configured.



263

16.1.4 Service ExceptionThis topic provides the analysis of the cases related to service exception.

TC-A0001 A UA5000 Fails to Copy the Multicast Stream to All the STBs Becausethe Traffic Exceeds the Traffic Restriction of the UA5000

This topic describes how to troubleshoot the fault when a UA5000 fails to copy the multicaststream to all the set top boxes (STBs) because the traffic exceeds the traffic restriction of theUA5000.

Fault TypeMulticast service

Service exception

Phenomenon Descriptionl When multiple STBs are added to a multicast group, a UA5000 cannot copy the multicast

stream to all the STBs (certain users cannot watch this program).l The traffic of a single multicast stream is 5.4 Mbit/s and in total, 461 multicast users request

for this program.l When you reduce the number of STBs or request for a multicast program with a low traffic,

the UA5000 can copy the multicast stream to all the STBs.



l The total traffic of the multicast stream exceeds the traffic restriction of the UA5000 IPM.l Multicast streams are copied on logics. The maximum traffic between the logics and 251

chip is restricted to 1 Gbit/s and the UA5000 IPM has two 251 chips. Therefore, themaximum multicast traffic supported by the UA5000 IPM is 2 Gbit/s = 2048 Mbit/s.Currently, however, there are 461 multicast users in the system and each user requests forthe multicast stream with the bandwidth of 5.4 Mbit/s. Therefore, the total traffic is 5.4Mbit/s x 461 = 2849.4 Mbit/s that exceeds the traffic restriction (2 Gbit/s) of the UA5000IPM. As a result, the multicast stream cannot be copied to all the STBs.

NOTE

The maximum forwarding capability (that is, the upper limit of the total traffic) of the UA5000 IPM isrelevant to the IPM control board of the system. Before analyzing the problem, you need to know aboutthe related performance indexes of the faulty device.



264

Procedure

Step 1 Reduce the number of STBs (that is, reduce the number of users) or request for the multicastprogram with a low traffic to ensure that the traffic of a single multicast program x the numberof users ≤ the total traffic of the device so that the fault is rectified.

----End


The total traffic of the UA5000 IPM is restricted. When the service with a heavy traffic, suchas the multicast service, is provided, the service may be affected if the traffic exceeds the trafficrestriction. The performance indexes (such as the maximum forwarding capability) of the devicehelp test and troubleshooting in daily maintenance.

TC-A0008 Only One ISDN Telephone Is in the Normal State Under the NT1Because the Working Mode of the BRA Port Is Set Improperly

This topic describes how to troubleshoot the fault when only one ISDN telephone is in the normalstate under the network termination 1 (NT1) because the working mode of the basic rate access(BRA) port is set improperly in the case of the integrated services digital network (ISDN) voiceservice.

Fault Type

Narrowband service

Service exception

Phenomenon Descriptionl Networking: ISDN telephone -> NT1 -> UA5000 -> softswitch

NOTE

The UA5000 is led out to the NT1 (of another vendor) from a port on the DSL board. The NT1provides two ISDN ports connected to two telephones.

l Fault phenomenon: Only one ISDN telephone can establish a conversation. Telephone Acan establish a normal conversation after the offhook but telephone B plays no dialing toneupon offhook; or after telephone B is hooked off, telephone A does not play the dialingtone upon offhook. No exception is found on the softswitch side.

Alarm Information

None

Cause Analysis


l The service port is faulty or is not activated.l The NT1 is faulty.l The telephone is faulty.



265

l The cooperation between the NT1 provided by different vendors and the UA5000 is in theabnormal state.

l The data configuration is incorrect.

Procedure

Step 1 According the fault phenomenon, one telephone is in the normal state. Therefore, the fault is notcaused by the service port.

Step 2 Check the NT1 status, and it is in the normal state.

Step 3 Replace the ISDN telephones, and the fault persists.

Step 4 In ESL user mode, run the display braport attribute command to query the attribute of theBRA port. It is found that the working mode of the BRA port is set to p2p.The meanings of the working mode of the BRA port are as follows:l p2p: Indicates the point to point mode. It is applicable to the scenario where the ISDN BRA

port communicates with one terminal user.l p2mp: Indicates the point to multi-point mode. It is applicable to the application scenario

where the ISDN BRA port simultaneously communicates with multiple terminal users.

Step 5 In this troubleshooting case, it is required that the ISDN BRA port communicate with twoterminal users simultaneously. Therefore, run the braport attribute set command to change theworking mode of the BAR port to p2mp. Then, the fault is rectified.

----End


It is recommended that you see the related documentation before the configuration. Otherwise,service exceptions may occur.

TC-A0009 MoIP Dialup Fails Because the Remote Server Changes the CodecWithout Reason

This topic describes how to troubleshoot the fault when modem over IP (MoIP) dialup failsbecause the remote server changes the codec without reason.

Fault Type

Narrowband service

Service exception


A UA5000 is interconnected with the trunk gateway (TG). In an MoIP test, the MoIP is used todial up to the IP network and the dialup fails.

Alarm Information

None



266


l The account and password are incorrect.l Communicating with the remote server fails.l The operation process on the modem is incorrect.

Procedure

Step 1 Change the dialup account and password. If the fault persists, it indicates that the fault is notcaused by the account.

Step 2 Dial the remote server from a telephone directly. If the negotiation tone of the modem is played,it indicates that communicating with the remote server is in the normal state.

Step 3 After eliminating the preceding causes, capture packets. It is found that in the negotiationprocess, the remote server changes the codec without reason but the softswitch does not notifythe UA5000 that the UA5000 needs to switch the codec. As a result, the codecs between the twosides are inconsistent and the negotiation fails.

Step 4 Through the analysis of the softswitch, perform certain configurations on the softswitch. Afterthe softswitch issues consistent codecs according to the actual conditions of the two sides, thefault is rectified.

----End

Suggestion and SummaryDuring the handling of a VoIP, Fax, or MoIP service fault, it helps a lot to be familiar with theH.248 , MGCP and SIP protocol and skilled in using the packet capture tool.

TC-A0010 The UA5000 Fax Service Fails Due to Low Port GainThis topic describes how to troubleshoot the fault when the UA5000 fax service fails due to lowport gain.

Fault TypeVoIP service

Service exception

Phenomenon Descriptionl Networking: UA5000 -> universal media gateway (UMG) -> IP network -> softswitchl The UA5000 and the UMG communicate with each other through the V5 interface. Services

go upstream to the IP network after conversion in the UMG. In this networking mode, whenthe fax mode is set to V2 or V3 transparent transmission, the service is successful. Whenthe fax mode is set to T.38, the fax service fails.




267

Cause Analysis


l The fax terminal is faulty. The fax finally fails because the negotiation between the twofax terminals fails.

l Due to network factors, the negotiation signal is damaged, and finally the fax service fails.

Procedure

Step 1 The fax service can be transparently transmitted normally. This indicates that the fault is notcaused by the fax terminal.

Step 2 According to analysis on the UMG side, the UMG receives a fax signal from the UA5000 butthe UMG considers the weak signal as an echo signal and filters it. As a result, the fax fails.

Step 3 After the fault cause is located, run the following commands:huawei(config-esl-user)#display pstnport attribute 0/7/0 huawei(config-esl-user)#pstnport attribute set 0/7/0 voicegain 0

Adjust the port gain, that is, set the receive gain to 0 dB and the transmit gain to –3.5 dB. Then,the fault persists.

Step 4 Re-adjust the gain to 5. Set voicegain to 5, that is, set the receive gain to 3 dB and the transmitgain to –12 dB. Then, the fax service is in the normal state and the fault is rectified.

Step 5 Re-adjust the gain by running the following commands. Set voicegain to 5, that is, set the receivegain to 3 dB and the transmit gain to –12 dB. Then, the fax service is in the normal state and thefault is rectified.huawei(config-esl-user)#display pstnport attribute 0/7/0 huawei(config-esl-user)#pstnport attribute set 0/7/0 voicegain 5

----End


If a problem relates to the interconnecting with the product of another vendor, it is necessary tolearn the requirement of the product on the UA5000. Then, make adjustments accordingly tosolve the problem quickly.

TC-A0011 Fax Interconnecting Fails Because Codecs Are Inconsistent

This topic describes how to troubleshoot the fault when fax interconnecting fails because theUA5000 interconnects with the access equipment of company A and their codecs areinconsistent.

Fault Type

Narrowband service

Service exception

Phenomenon Descriptionl Networking: fax -> UA5000 -> softswitch -> access equipment of company A -> fax



268

l Fault phenomenon: When the UA5000 interconnects with the access equipment ofcompany A to implement the fax service, the fax service fails.

Alarm Information

None

Cause Analysis


l The fax terminal is faulty. The fax terminal requires special negotiation signals, but anotherfax terminal does not support these special negotiation signals. As a result, the faxnegotiation fails.

l The cooperation between the softswitch and the UA5000 is abnormal. The fax negotiationfails because the cooperation between the softswitch and the access equipment is abnormal.

l The fax negotiation fails because codecs are inconsistent.

Procedure

Step 1 Replace the fax with a new fax. If the fax UA5000 still fails, it indicates that the fault is notcaused by the fax terminal.

Step 2 Use the two faxes under the same UA5000 to send faxes. It is found that the faxes are in thenormal state. This indicates that the cooperation between the softswitch and the access equipmentis in the normal state.

Step 3 Capture signaling along with the engineer of company A. It is found that the μ-law is firstnegotiated on both sides (the softswitch sends codecs to the UA5000 and G.711μ is the firstcodec). In this case, the service is in the normal state. The access equipment of company A,however, forcibly changes the codec to G.711A and does not notify the softswitch of the change.As a result, the codecs are inconsistent on the two sides and the negotiation fails.

Step 4 On the softswitch side, change the codec type to G.711A, and then the fault is rectified.

NOTE

Consult the engineer of company A and it is confirmed that the fax service of company A supports onlyA-law and does not support μ-law. Therefore, the negotiation fails because the access equipment ofcompany A forcibly changes the codec in the negotiation process.

----End


It helps a lot in troubleshooting a fax service fault to understand the fax principle, to be familiarwith the H.248 protocol, and capture packets for analysis.

TC-A0012 One-Way Audio and Continuous Dialing Tone Occur in the Subscriberof the Slave Shelf Because the HW Transfer Board Is Faulty

This topic describes how to troubleshoot the fault when the subscriber of the slave shelf cannothear the dialing tone (that is, one-way audio) and the dialing tone cannot be stopped because theHW transfer board is faulty.



269


Service exception

Phenomenon Descriptionl When a call is initiated from the local to the peer in the pulse telephone mode, the peer end

is alerted, and the ringback tone is played to the local end. After the call is connected, thelocal end hears the peer end but the peer end does not hear the local end.

l When a call is initiated from the local to the peer in the voice dialing mode, the local endhears only a continuous dialing tone.

l When a call is initiated from the peer to the local and the local uses the pulse dialing mode,the local end is alerted and the ringback tone is played to the peer end but when the call isanswered, the peer end does not hear the local end.

l When a call is initiated from the peer to the local and the local uses the voice dialing mode,the local end is alerted and the ringback tone is played to the peer end but when the call isanswered, the peer end does not hear the local end.

l Services under the master shelf are in the normal state. Call originations and conversionsare all in the normal state.Shelf type:

0 MAIN_HABM_30(HABA) Normal 1 SLAVE_HABS_30(HABA) Normal



l The A32 board in the slave shelf is damaged.l The fault occurs in the slave shelf and the master shelf is in the normal state. The physical

link between the master and slave shelves must be faulty. Possibly, the cable between themis in loose connection, either or both of the HW transfer boards HWCB and HWTB betweenthe master and slave shelves are faulty, or the hardware of the control board is faulty.

NOTE

According to the fault phenomenon, it is found that voices are not transmitted but pulse signals aretransmitted successfully. Therefore, the physical link may be faulty.

Procedure

Step 1 Replace the A32 board of the slave shelf, and the fault persists.

Step 2 Replace the HW transfer board HWTB of the slave shelf, and the fault persists.

Step 3 Replace the HW transfer board HWCB of the master shelf and perform the test again. The one-way audio and continuous dialing tone fault is rectified.

----End



270

Suggestion and SummaryIf a fault occurs only in the slave shelf but not in the master shelf, check the cable connectionbetween the master shelf and the slave shelf and their transfer boards. Make a replacement whennecessary.

TC-A0014 The Last Digit of the Caller ID Is Not Displayed for the Reason of theTelephone Set

This topic describes how to troubleshoot the fault when the last digit of the caller ID is notdisplayed for the reason of the telephone set.


Other

KeywordNarrowband voice service

Non-local PLMN number

Phenomenon DescriptionA UA5000 is deployed in an office. The UA5000 is attached to the softswitch. Subscriberscomplain that their phones do not display the last digit of the phone number of the call made bya non-local mobile subscriber.



l The cooperation between the softswitch and the UA5000 is in the abnormal state. As aresult, the last digit of the caller ID is lost.


Procedure

Step 1 Trace the H.248 signaling on the softswitch side. It is found that the caller ID is completely sent.This indicates that the cooperation between the softswitch and the UA5000 is in the normal state.

Step 2 Perform the dialing test using the non-local mobile phone. It is found that the caller ID is9013XXXXXXX. It is confirmed that the calling party is a virtual network subscriber. Thedisplayed first digit 9 represents an outgoing number and the subsequent digits 013XXXXXXXare the PLMN number of the calling party, but the last digit of the PLMN is not displayed.

Step 3 Perform the dialing test using another telephone set. The caller ID is displayed normally and theproblem is solved. Observe the difference between the two telephone sets. It is found that the



271

LCD of the telephone set that cannot completely display the caller ID can display only 12 digits,but a normal telephone set can display 14 digits.

----End

Suggestion and SummaryNone

TC-A0016 The Narrowband Leased Line Service Fails Due to Incorrect ModemConfigurations

This topic describes how to troubleshoot the fault when the narrowband leased line service failsdue to incorrect modem configurations.

Fault TypeOther

Service exception

KeywordNarrowband data and leased line service

SHDSL leased line

Phenomenon Descriptionl Networking: The customer requires to implement the 3 x 64 kbit/s = 192 kbit/s leased line

service through the following networking: router -> TDM SHDSL modem -> SDL SHDSLport -> SDL E1 port -> switch

l When an E1 cable is connected to the upstream port on the UA5000 PVM, the HABA shelfis emulated as the RSP shelf. The working mode is HABA. Services are in the normal state.On the UA5000, configure an intra-board semi-permanent connection from the SDLSHDSL port to the SDL E1 port (the start timeslot of the SHDSL port is 0/15/4/0 and theend timeslot is 0/15/4/2; the start timeslot of the E1 port is 0/15/0/1 and the end timeslot is0/15/0/3), with a bandwidth of 3 x 64 kbit/s = 192 kbit/s.

l Fault phenomenon: After the configurations, it is found that the physical layer between thetwo routers is UP but the protocol layer is DOWN and that neither of the two routers canbe pinged from each other.



l The data configurations of the UA5000 are incorrect.l The upper-layer link is faulty.l The modem configurations are incorrect.



272

Procedure

Step 1 Check the device status. The service boards work in the normal state, SHDSL port 0/15/4 is inthe active state, and E1 port 0/15/0 receives RRA alarms from the remote end. This indicatesthat the data on the AN side cannot be transmitted successfully.

Step 2 Check the data configurations of the UA5000, focusing on the timeslot usage and the frameformat. The data configurations are all correct.

Step 3 Connect the E1 tester to the E1 cable routed out of the CX. The test result is in the normal range.Connect the E1 tester to the E1 port on the SDL board. The test results are all zeros and they arein the normal range. This indicates that the upper-layer link is in the normal state.

Step 4 Check the modem configurations. It is found that DIVCLOCK is set to 1. Set DIVCLOCK toNORMAL, save the data, and restart the modem. After that, the status of the router protocollayer is changed from DOWN to UP, and the two routers can be pinged from each other. Thefault is rectified.

----End


When one timeslot is required to provide a 64 kbit/s service, you need to set DIVCLOC to 1.When three or more timeslots are required, you need to set DIVCLOCK to NORMAL.

TC-A0017 The CLIP Is Abnormal Because the Resistance of the Protective Unit IsToo Large

This topic describes how to troubleshoot the fault when the calling line identificationpresentation (CLIP) is abnormal because the resistance of the protective unit is too large.

Fault Type

VoIP service

Service exception

Keyword

CLIP

Abnormal CLIP

Protective unit


About 20 commercial subscribers of the AG report that abnormal CLIP occurs frequently (6 to8 out of 10 times).

Alarm Information

None



273

Cause Analysis


l The telephone set is faulty.l An error occurs when the softswitch is processing the CLIP.l An error occurs when the bearer network transmits the phone number.l Processing operations is faulty inside the AG.l The link is faulty.l The ODF and the protective unit are faulty.

Procedure

Step 1 The fault is not caused the telephone set because all the subscribers of the AG report this fault.

Step 2 Check the data configurations on the softswitch. No abnormality is found.

Step 3 Trace the CLIP signaling on the softswitch. It is found that CLIP signaling has been issuednormally.

Step 4 Track the CLIP signaling on the AG. No abnormality is found. Therefore, the fault is not causedby the processing operations inside the AG.

Step 5 Check the grounding situations in the equipment room. No abnormality is found. Therefore, thefault is not caused by the line problem.

Step 6 Remove the protective unit and perform a circuit test. No abnormality is found. Then, re-installthe protective unit and perform a test. The fault recurs. It can be determined that the protectiveunit is faulty. After a test, it is found that the resistance of the protective unit is 28 ohms, but anormal value should be within 20 ohms.

----End


The protective unit is a primary protection facility, which is used to prevent the equipment andoperator from the over-voltage and over-current damage. The resistance of the protective unitmay result in the abnormality of the CLIP.

TC-A0020 ISDN Subscribers Cannot Hear the Dialing Tone After the Offhook Dueto the Inconsistency Between the IUA Interface ID of the UA5000 and the IUAInterface ID of the Softswitch

This topic describes how to troubleshoot the fault when ISDN subscribers cannot hear the dialingtone after the offhook due to the inconsistency between the IUA interface ID of the UA5000and the IUA interface ID of the softswitch.

Fault Type

Narrowband service

Service exception



274

KeywordISDN

No dialing tone

Interfaceid

Phenomenon DescriptionISDN subscribers cannot hear the dialing tone after the offhook.



l The NT1 or telephone set is faulty.l The data configuration of the UA5000 is incorrect.l The data configuration of the softswitch is incorrect.

Procedure

Step 1 On the UA5000 side, check the status of the port. It is found that the port is activated. Thisindicates that the fault is not caused by the NT1 or telephone set.

Step 2 Check the data configurations of the UA5000 and the softswitch. It is found that the interfaceID of the UA5000 is configured to 0 and the interface ID of the softswitch is configured to 192.

Step 3 Change the interface ID of the UA5000 to 192. Then, the fault is rectified.huawei(config-esl-user)#mgbrauser modify 0/18/0 interfaceid 192

----End

Suggestion and SummaryCompare the data configuration of the UA5000 with the data configuration of the softswitch.The related parameters on two sides should be consistent with each other.

TC-A0023 Making Long Distance Calls Fails Because Commas Exist in theDigitmap Issued by the Softswitch

This topic describes how to troubleshoot the fault when making long distance calls fails becausecommas exist in the digitmap issued by the softswitch.


Service exception



275

KeywordDigitmap

Syntax error

Dialing tone

Phenomenon DescriptionWhen the interconnection between the UA5000 PVM and the softswitch is tested, making along-distance call fails, and the second dialing tone cannot be heard after digit 8 is dialed.


Cause AnalysisAccording to the error message "Syntax error in message", the possible causes are as follows:

l The UA5000 fails to identify the syntax error in the signaling.l The format of the digitmap is incorrect, which contains the invalid parameters or symbols

that do not comply with the protocol.

Procedure

Step 1 According to the signaling captured when the fault occurs, the previous signaling before theerror message is the digitmap issued by the softswitch and its contents are shown as follows:#@ 7210 #@20080828.15:51:26.960 #@MGC->MG #@!/2 [192.168.199.131]:2944 T=10497250{C=-{MF=A1{DM=DM469199180354 {(1[2,4,8,9]x|[3,4,7,8,9]xxxxxxxxx|10xxxxxxxxxxx.|1[2,4,8,9]x|[2,5][1-5]xxx.|10xxx.|2[6-9]xxx.|5[0,6-9]xxx.)},E=10543282{dd/ce{DM=DM469199180354 },al/on,al/fl},SG{cg/dt}}}}

At this time, the UA5000 returns a message "Syntax error in message":

#@ 7211 #@20080828.15:51:26.960 #@MG->MGC #@!/2 [192.168.201.40]:2944 ER=400{"Syntax error in message"}

Step 2 Analyze the digitmap issued by the softswitch. It is found that multiple commas exist in thedigitmap, such as [2,4,8,9]. Commas in the digitmap are not compliant with relevant protocols.

Step 3 Modify the digitmap and stop using the digitmap containing commas. Then, the fault is rectified.

----End

Suggestion and SummaryThe dialup fault is often caused by the digitmap. To locate such a fault, it is recommended thatyou capture and analyze packets.

TC-A0024 The UA5000s in Different VLANs Cannot Communicate with EachOther Due to Configuration Errors in Subnet Masks

This topic describes how to troubleshoot the fault when the UA5000s in different VLANs cannotcommunicate with each other due to configuration errors in subnet masks.



276

Fault Type

VoIP service

Service exception

Keyword

Ping

Subnet

Service failure

Phenomenon Descriptionl Networking: UA5000 -> MA5680T -> switch -> router

l Fault phenomenon: The gateway of the UA5000 is on the switch. The UA5000s of VLAN301 cannot communicate with or ping the UA5000s of VLAN 302; however, all theUA5000s of these two VLANs can normally call other devices.

Alarm Information

None

Cause Analysis

In this networking mode, the possible causes are as follows:

l The data configuration of the switch interface is incorrect.

l The data configuration of the softswitch is incorrect.

l The IP address of the UA5000 is configured incorrectly.

Procedure

Step 1 Check the data configurations of the two VLANs on the switch. No abnormality is found. Thisindicates that the fault is not caused by the data configuration of the switch.

Step 2 All the UA5000s of the two VLANs cannot ping each other, and therefore the fault is locatedon the route or the data link layer. Check the data configuration of the softswitch, but noabnormality is found. This indicates that the fault is not caused by the data configuration of thesoftswitch.

Step 3 Check the data configurations of the UA5000s. It is found that the subnet mask of the UA5000sof VLAN 301 is 255.255.255.0 and the subnet mask of UA5000s of VLAN 302 is255.255.255.192. After confirmation with the customer, it is learned that the planned subnetmask is 255.255.255.192. In the earlier stage, attention is not paid to the subnet maskconfiguration of the UA5000s of VLAN 301, which results in this fault. Change the subnet maskof VLAN 301 to 255.255.255.192. Then, the fault is rectified.

----End



277

Suggestion and SummaryWhen configuring UA5000s, pay attention to the customer′s data plan. Configure the data forsubnet planning in strict accordance with the data plan. Otherwise, unexpected problems mayoccur.

TC-A0025 No Ringing Current Is Generated on the Subscriber Lines of the F01D500Subtending Shelf Because the Ringing Current Cable of the F01D500 SubtendingShelf Is Burned

This topic describes how to troubleshoot the fault when no ringing current is generated on thesubscriber lines of the F01D500 subtending shelf because the ringing current cable of theF01D500 subtending shelf is burned.


Service exception

KeywordRinging current

Subtending

Phenomenon DescriptionNo ringing current is generated on the subscriber lines of the F01D500 subtending shelf, andthe CLIP is in the normal state when the subscriber makes a call or answers a call.


Cause AnalysisThe ringing current passes through the power module, the backplane of the master shelf, PWX2,the ringing current cable of the subtending shelf, and the backplane of the subtending shelf, andthen finally arrives at the service board of the subtending shelf. The possible causes of the faultare as follows:

l The power board is faulty.l The backplane of the master shelf is faulty.l The ringing current cable of the subtending shelf is faulty.

Procedure

Step 1 After checking, LEDs PWX2 VA0 and Fail are off, and no ringing current is generated on thesubscriber lines of the subtending shelf. After the power board is replaced, the fault persists.

Step 2 It is suspected that the backplane of the master shelf is faulty. After the shelf is replaced, thefault persists.



278

Step 3 After checking again, it is found that the ringing current cable of the subtending shelf is burned.After the ringing current cable is replaced, the fault is rectified.

----End


In the case of this fault, you need to check whether the ringing current cable is damaged inadvance.

TC-A0027 IC Card Telephones Connected to the UA5000 Cannot Make Calls Dueto Configuration Errors on the Intelligent Network

This topic describes how to troubleshoot the fault when IC card telephones connected to theUA5000 cannot make calls due to configuration errors on the intelligent network (IN).

Fault Type

Narrowband service

Service exception

Keyword

Intelligent network

IC card

Phones that can answer calls but cannot make calls

Phenomenon Descriptionl Networking: IC card telephone -> UA5000 -> intelligent network

l In the case of two IC card telephones connected to a UA5000, calls can be answered andemergency calls can be made, but calls to other subscribers such as fixed line phonesubscribers, Little Smart subscribers, and mobile subscribers cannot be made.

Alarm Information

None

Cause Analysis


l The IC card has insufficient balance or has expired.

l The digitmap mapping is incorrect.


l The settings of the intelligent network do not match the settings of the IC card.



279

Procedure

Step 1 Use the IC card in other telephones. If the calls can be made normally, it indicates that the ICcard has available balance or does not expire.

Step 2 Check digitmaps using the Toolbox. It is found that the softswitch has issued the digitmap tothe subscribers connected to the UA5000 and the signaling procedure is correct.

Step 3 Check the digit collection mode of the IC card telephone. It is found that the mode is UM, whichis consistent with that of other IC card telephones connected to UA5000s on other sites.

Step 4 Check the upper-layer intelligent network. It is found that the customer individually configuresthe intelligent public telephone (IPT) service and IC card service. The call barring is configuredon the IPT users who can make only 200, 300, and emergency calls and cannot make commoncalls, but the IC card users can make common calls after installing the IC card in the IPT. Duringthe deployment, the IC card phones are mistakenly configured with the IPT services, whichresults in this fault. Reconfigure the IC card telephones with normal IC card services, and thenthe fault is rectified.

----End

Suggestion and SummaryTo facilitate fault locating, you’d better know the service type before troubleshooting the faultthat the phones can answer calls but cannot make calls.

TC-A0030 Busy Tone Is Played in the Outgoing Callings of the Intelligent PayPhone Due to the Incorrect Parameter Settings of the MG Interface Software

This topic describes how to troubleshoot the fault when busy tone is played in the outgoingcallings of the intelligent pay phone due to the incorrect parameter settings of the MG interfacesoftware.


Service exception

KeywordIntelligent pay phone

Busy tone

Phenomenon Descriptionl Networking: UA5000 -> switch -> softswitchl Fault phenomenon: The incoming and outgoing calls of the common subscribers are normal

but the busy tone is played in the outgoing calls of the intelligent pay phone.




280

Cause Analysis

The matching mode between the digitmap issued by the softswitch and the default digitmap ofthe UA5000 is incorrect.

Procedure

Step 1 Trace the message on the UA5000. It is found that after the subscriber dials a complete number,the UA5000 reports only four digits, that is "4445", and the digitmap matching mode is completematch. Therefore, the digitmap matching mode of the UA5000 may be incorrect.

Step 2 Run the display mg-software parameter command to query the maximum digitmap matchingflag parameter of the MG interface. It is found that the maximum digitmap matching flagparameter value of the MG interface is 0, indicating "minimum match". Run the mg-softwareparameter command to change the value of the parameter to 1, indicating "maximum match",and then the outgoing call of the intelligent pay phone is in the normal state.

----End


When a device in a new office is faulty, in the case of the board providing the service, checkwhether the basic configurations of the device are correct, and then check whether the matchingmode between the UA5000 and the softswitch is correct.

TC-A0031 The Calling Party of an IP Public Telephone Is Not Charged Because thePolarity Reversal Pulse Attributes for the PSTN Port Is Not Set

This topic describes how to troubleshoot the fault when the calling party of an IP public telephoneis not charged because the polarity reversal pulse attributes for the PSTN port is not set.

Fault Type

VoIP service

Service exception

Keyword

IP public telephone

Polarity reversal pulse


A UA5000 is deployed in an office. When the polarity reversal service is provided to thesubscriber, the called party of the IP public telephone is charged and the calling party is notcharged.

Alarm Information

None



281

Cause AnalysisThe polarity reversal pulse attributes for the corresponding PSTN port on the UA5000 is not set.

Procedure

Step 1 Check the service board. It is found that the service board is CC0HASL, port 16 is enabled toprovide the polarity reversal service, and the port supports the polarity reversal feature.

Step 2 Replace the accounting terminal, and the fault persists.

Step 3 Check the configuration data of the UA5000. It is found that only the polarity reversal accountingfunction of the PSTN port for the subscriber is enabled. After the pstnport reversepole_pulseset command is executed to set the polarity reversal pulse attributes for the PSTN port, the faultis rectified.

NOTE

By default, the width of the high-level pulse of the PSTN port is 300 ms.

----End

Suggestion and SummaryWhen a device in a new office is faulty, first check whether the basic configurations of the deviceare correct in the case of the board providing the service.

TC-A0048 The ID of the Slot Where the Board in the Slave Shelf Is Inserted IsDisplayed Incorrectly Because the Shelf Type Is Selected Incorrectly

This topic describes how to troubleshoot the fault when the ID of the slot where the board in theslave shelf is inserted is displayed incorrectly because the shelf type is selected incorrectly.

Fault TypeOther

Service exception

KeywordShelf type is incorrect

Board

Slot

Phenomenon DescriptionDuring the deployment, one MD5500 is connected to the C&C08 upstream through the V5interface. After the MD5500 is configured with shelves and boards, enable the V5 interface. Itis found that the V5 interface works in the normal state and the subscribers on the master shelfcan make calls in the normal state. The IDs of the slave-shelf slots, however, are displayedincorrectly. Slot 8 is displayed as slot 6. The IDs of the slots behind slot 8 are increased by tworespectively. Therefore, the boards in slots 6 and 7 cannot be displayed.



282

Alarm Information

None

Cause Analysis


l The HW line or the transfer board that is connected to the salve shelf is faulty.

l The control board is faulty.

l The backplane is faulty.

l The data is configured incorrectly.

Procedure

Step 1 Replace the HW line of the MD5500. It is found that the fault persists. This indicates that thefault is not caused by the HW line.

Step 2 Switch over the active and standby control boards. It is found that the fault persists. This indicatesthat the fault is not caused by the control board.

Step 3 The backplane cannot be replaced because no spare part is available for the backplane. Thedevice is newly delivered. Therefore, the backplane is rarely faulty. This indicates that the faultis not caused by the backplane.

Step 4 Check the data configuration. It is found that the shelf type is incorrect. In the deployment, themaster shelf of the MD5500 is the HABA shelf and the slave shelf of the MD5500 is the HABBshelf. Shelf type 5:SLAVE_HABS_30(HABA) is selected. Actually, shelf type4:SLAVE_HABS_32(HABB) should be selected. The HABA shelf provides 30 slots and theHABB shelf provides 32 slots. In this case, slot 6 and slot 7 cannot be displayed because theHABA shelf is two slots less than the HABB shelf. Change the shelf type. Then, the boards aredisplayed correctly and the fault is rectified.

----End


The MD5500 is composed of the master shelf, slave shelf, and extended shelf. The three shelvesuse different backplanes. Therefore, make sure that the shelf types are selected correctly whenadding shelves. Otherwise, the fault occurs.

TC-A0054 The Fault Wherein No Tone Is Played After Offhook Frequently Occurson the UA5000 Users Because the HSCI Board of the Softswitch Is Faulty

This case describes how to troubleshoot the fault wherein no tone is played after offhookfrequently occurs on the UA5000 users because the HSCI board of the softswitch is faulty.

Fault Type

VoIP service

Service exception



283

Keyword

Packet loss

HSCI board

Fault Descriptionl Networking: Phone of the user -> UA5000 -> softswitch

l Fault description: The fault wherein no tone is played after offhook frequently occurs on agreat number of users.

Alarm Information

None

Cause Analysis


l The network quality is poor.

l The softswitch fails to send the dial tone event correctly.

l An error occurs during the interconnection of the H.248 protocol between the softswitchand the UA5000.

l The board of the softswitch is faulty.

Procedure

Step 1 The ping command is executed on the UA5000 to send 1000 ping packets to the softswitch. Ifit is found that no packet is lost and the delay is normal, it indicates that fault is not caused bythe network quality problem.

Step 2 The packets are captured on the softswitch and the UA5000 and then the packet capture resultsare compared.

1. The analysis of the packets captured on the UA5000 is as follows: After the UA5000 sendsthe offhook signal, the softswitch issues a dial tone event signal cg/dtu, rather than cg/dt.The UA5000, however, cannot identify the cg/dtu signal because cg/dtu is not a descriptordefined in the H.248 protocol. Therefore, the UA5000 fails to issue the dial tone. In addition,the softswitch sends five MODIFY packets consecutively to continue issuing the dial tone,because it fails to receive the response from the UA5000.

2. The analysis of the packets captured on the softswitch is as follows: After the UA5000 usertakes the phone off the hook, the softswitch sends five MODIFY packets consecutively toissue the dial tone to the user, and the dial tone event is cg/dt. Then, the re-transmissionmechanism is triggered because the UA5000 fails to reply. After sending five MODIFYpackets consecutively, the softswitch stops issuing the dial tone. The debug information iscaptured to analyze the fault causes. It is found that a packet is issued incorrectly duringthe packet distribution process because the HSCI board is faulty.

Step 3 After the HSCI board is replaced, the fault is rectified.

----End



284

FAQ

Question: Why the signaling traced by the softswitch is different from the signaling traced bythe UA5000? (The network packets captured on the AG, namely the UA5000, through theETHEREAL tool indicates that the received dial tone signal is cg/dtu, whereas the signal tracedby the softswitch through the network management software is cg/dt.)

Answer: The signaling traced by the UA5000 is analyzed based on the packets that are capturedthrough the universal packet capture tool, rather than based on the internal signaling of theUA5000. Therefore, the credibility of the analysis on the basis of the captured packets is high.The softswitch uses the module-based design so that different modules perform differentfunctions. The signaling traced by the softswitch is the signaling sent by the protocol processingmodule. However, when this signaling is normal, it does not mean that the signaling sent by thesoftswitch is certainly normal.

TC-A0058 The Intelligent Public Telephone Service Fails Because the SoftswitchIssues an Improper Digitmap

This case describes how to troubleshoot the fault wherein the intelligent public telephone (IPT)service fails because the softswitch issues an improper digitmap.

Fault Type

VoIP service

Service exception

Keyword

Charging

Fault Descriptionl Networking: UA5000 -> EPON access device -> bearer network -> softswitch

l Fault description: After the normal IPT service of an office is cut over to the UA5000,outgoing calls cannot be made. After the offhook, a voice message is played prompting theuser to query the call charge first. Then, the busy tone is played, which indicates that thecall is disconnected automatically.

Alarm Information

None

Cause Analysis


l The polarity reversal settings of the UA5000 are incorrect.

l The number collection function of the UA5000 is abnormal.

l The IPT phone is faulty.

l The UA5000 fails to cooperate with the IPT phone normally.



285

Procedure

Step 1 The display pstnport attribute command is executed to check whether the UA5000 isconfigured with the polarity-reversing pulse attribute. It is found that the polarity reversalsettings of the device are correct.

NOTE

Polarity-Reverse indicates whether the polarity-reversing pulse is supported. The values are as follows:

l Not supported: Polarity-reversing pulse is not supported.

l Supported: Polarity-reversing pulse is supported.

The default value is "Not supported".

Step 2 As indicated by the voice message, the user cannot dial the number because the call detail record(CDR) of the previous call is not downloaded after the communication is complete. After theCDR is cleared, the test shows that the call can be made successfully but the call charge is notdisplayed after the communication is complete. Therefore, the fault is considered to be causedby the failure to query the call charge.

Step 3 Packets are captured through a packet capture tool, the captured data is restored to a voice filethrough the audio processing software CAPSEN, and then the whole process of dialing,communication, and onhook over the IPT phone is analyzed through the COOLEDIT audioprocessing tool. It is found that the whole process is normal. After the communication iscomplete, however, it is found that the IPT phone reports 45549 and 11#, at an interval less than4s.

NOTE

The digitmap {([2-8]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|F|x.F|[0-9].L)} issued by thesoftswitch is analyzed. From the digitmap, it is found that the UA5000 sends 4554911 as a single unit(sends the numbers consecutively) to the softswitch because a digitmap for accurately matching 45549 isnot available. The softswitch considers 4554911 as a phone number and thus sets up a call. As a result, thequery of the call charge by the IPT phone fails. Furthermore, in each subsequent call initiated by the IPTphone, the intelligent platform plays a voice message prompting the user to query the call charge first, andhence the outgoing calls cannot be made.

Step 4 In this case, the cause of the fault is that the timer for starting the match between the digitmapissued by the softswitch and the number 45549 dialed on the IPT phone is set too long. To rectifythis problem, you can re-plan the digitmap on the softswitch to shorten the duration of matchingthe phone number 45549. You can also run the h248stack command on the UA5000 to changethe previously-mentioned timer to 3s, because the digitmap on the softswitch takes effectglobally.

----End


The general procedure of the IPT service is as follows:

l Before the user dials the number after picking the phone off the hook, the IPT phoneautomatically reports access code 45549 and connects to the intelligent platform.

l The user dials the number and makes a call.

l After the communication is complete, the user places the phone on the hook and the IPTphone automatically reports 45549 and 11# to the upper-layer device. 45549 is theintelligent access code, and 11# is sent to the intelligent platform for querying the callcharge.



286

TC-A0062 The H.248 Protocol Packets Cannot Be Retransmitted Because theInterface Attributes Are Configured Incorrectly

This case describes how to troubleshoot the fault wherein the H.248 protocol packets cannot beretransmitted because the interface attributes are configured incorrectly.

Fault Type

Narrowband service

Service exception

Keyword

alf/udp

Fault Description

The analysis of the packets captured on site shows that the UA5000 fails to receive the replymessage from the softswitch when the packet loss occurs on the network. As a result, the UA5000does not retransmit the packets as allowed by the H.248 protocol.

Alarm Information

None

Cause Analysis


l The transaction reliability parameter of the H.248 protocol stack is configured incorrectly.

l The interface attributes are configured incorrectly.

Procedure

Step 1 The display h248stack command is executed to check whether the transaction reliabilityparameter of the H.248 protocol stack is configured correctly. It is found that the parameter isconfigured correctly.

Step 2 The display h248stack command is executed to check the configuration of MG interfaceattributes. It is found that the attributes of the MG interface of this version is different from theattributes of the MG interfaces of the previous versions.

NOTE

In the Transmode parameters that contain TCP and UDP, parameter alf/udp is added. In the UA5000V100R017C02B107, to enable the protocol retransmission mechanism, Transmode must be configured toalf/udp, whereas in other versions, Transmode is generally configured to UDP.

Step 3 The if-h248 attribute command is executed to change the interface attribute to alf/udp, and thenthe interface is reset. After that, it is found that the fault is rectified.

----End



287


None

TC-A0063 No Dial Tone Is Played After Offhook Because the Voice File Is NotLoaded to the System

This case describes how to troubleshoot the fault wherein no dial tone is played after offhookbecause the voice file is not loaded to the system.

Fault Type

Narrowband service

Service exception

Keyword

display version

Fault Description

A newly-deployed UA5000 in an office needs to support the EPON upstream transmission inintegrated mode, and thus the device is upgraded from UA5000 V100R013 to UA5000V100R017. After the services are provided through the UA5000, the broadband service isnormal, the H.248 interface is normal, but no dial tone is played after the narrowband user picksup the phone off the hook. The phone, however, is normal.

Alarm Information

None

Cause Analysis


l The configuration of the softswitch is incorrect.l The interconnection parameters are configured incorrectly.l The voice file is not loaded to the system successfully after the UA5000 is upgraded.

Procedure

Step 1 The signaling tracing is performed on the softswitch. The tracing result shows that theconfiguration of the softswitch is correct.

Step 2 The interconnection parameters are checked. The check result shows that the interconnectionparameters are configured correctly.

Step 3 The display version 0/3 command is executed to query the version information about the controlboard. It is found that version number 002 is not displayed after the "Voice" parameter. Instead,the version number following the "Voice" parameter is null. Therefore, the fault is consideredto be caused by the failure of the loading of the voice file.



288

Step 4 The load voice command is executed to load the voice file named voice_new.efs again. Then,the fault is rectified.

----End


After the upgrade of the device, you need to run the display language command to check whetherthe version is upgraded successfully. In addition, you also need to run the display version 0/3command to query the detailed version information about the control board to check whetherthe voice file is loaded successfully.

TC-A0064 Dialing of the Welfare Lottery User Fails Because the 16-Port ServiceBoard Is Abnormal

This case describes how to troubleshoot the fault wherein the dialing of the welfare lottery userfails because the 16-port service board is abnormal.

Fault Type

Narrowband service

Service exception

Keyword

Welfare lottery

Fault Description

A UA5000 is used to process the voice service (implemented through dialup) provided forwelfare lottery users. A welfare lottery user reports a fault wherein the call is frequentlydisconnected and the dialing fails.

Alarm Information

None

Cause Analysis



l The lottery machine is faulty.

l The quality of the subscriber line is poor.

l The parameter configuration of the UA5000 is incorrect.

l The board of the UA5000 cannot work with the lottery machine normally.



289

Procedure

Step 1 A test is performed on site, and no fault such as packet loss that affects the network quality isdetected on the network. This indicates that the fault is not caused by the network qualityproblems.

Step 2 A normal lottery machine is used to test whether the fault can be rectified. It is found that thefault persists. This indicates that the lottery machine is normal.

Step 3 The lottery machine is moved to the equipment room to be tested (the lottery machine isconnected to the UA5000 not through the subscriber line). It is found that the fault persists. Thisindicates that the fault is not caused by the quality problem of the subscriber line.

Step 4 The configuration of the user parameters and the oversea parameters is checked. It is found thatthe parameter configuration is correct.

Step 5 As the fault (call disconnection and dialing failure) occurs on only one welfare lottery user amongthe three welfare lottery users, the board of the on-site UA5000 is checked. It is found that theUA5000 uses an old A16 service board. The old A16 service board is replaced by an A32 boardand then the device is tested. It is found that the fault does not occur on the welfare lottery useragain, that is, the fault is rectified.

----End

Suggestions and SummaryThis case shows that the old service board fails to work with the new device normally. In certainservices that have strict requirements on the dialing function, such as the welfare lottery service,you must use the matching service board on the device as the configuration information requires.

TC-A0066 The Call Forwarding Service of the UA5000 User Fails Because theSoftswitch Sends the Digitmap Incorrectly

This case describes how to troubleshoot the fault wherein the call forwarding service of theUA5000 user fails because the softswitch sends the digitmap incorrectly.


Service exception

KeywordCall forwarding

Fault Descriptionl Networking: UA5000 -> bearer network -> softswitchl Fault description: After user A presses * and #, the special dial tone cannot be played and

the call forwarding function cannot be performed.l The procedure of the call forwarding service is as follows:

– Users A and B are both Centrex group users, and user A has the right to use the callforwarding service.



290

– A non-Centrex group user C calls user A. After answering the call, user A presses * and# to play the two-stage dial tone, and then dials the short number 8771 of user B toforward the call to user B.

– User A places the phone on the hook, and user C continues the conversation with userB.

Alarm Information

None

Cause Analysis


l The softswitch does not provide the call forwarding service for the user.

l The phone is faulty.

l The softswitch processes the operations incorrectly.

Procedure

Step 1 The user data configured on the softswitch is checked. It is found that the call forwarding serviceis provided for user A on the softswitch.

Step 2 The user phone is replaced and a test is performed. It is found that the fault persists.

Step 3 The H.248 messages are traced. It is found that after user A presses * and # to trigger the callforwarding service procedure, the softswitch sends an incorrect Modify message, in which thedigitmap contains two right brackets. The UA5000 cannot collect numbers according to thisdigitmap, and therefore the call forwarding service fails.

!/2 [10.37.3.102]:2944 T=1610257119{C=39{MF=AG153501000704{DM=DM381029697179 {(FF|ExxEx.F|FxxF|ExxF|ExxEx.Ex.F|FxxExxF|ExxExxExxF|EExx|FxxEx.F|ExxExxxxExxxxExxxxF|E6[28]x.|[0-8]xxx|9[2-8][0-9]xxxxxx|920x|910xxx.|912[0-268]|911[0-9]Sx.|912[3-579]Sx.|91[79]xSx.|916xxSxxxx|918xSx|99xxxxSx.|913xxxxxxxxx|9013xxxxxxxxx|915xxxxxxxxx|9015xxxxxxxxx|9010xxxSxxxxx|902xxxxSxxxxx|90[3-9]xxxxxSxxxx|90311xxxSxxxxx|9037[13679]6xxSxxxxx|904[135]1xxxSxxxxx|9051[0-9]xxxSxxxxx|9052[37]xxxSxxxxx|9053[12]xxxxxxxx|9057[1345679]xxxSxxxxx|9059[15]xxxSxxxxx|9075[57]xxxSxxxxx|90769xxxSxxxxx|90898xxxSxxxxx|900xxSx.|9[48]00xxxxxxx|900852xxxxxxxx|9xxxxxxxxxx)|EF)},E=1609730116{dd/ce{DM=DM381029697179 },al/on,al/fl},SG{cg/dt}}}}For this digitmap, error code 400 is returned by the UA5000:msg from mg([10.37.86.4]:2944) to mgc([10.37.3.102]:2944): !/2 [10.37.86.4]:2944 ER=400{"Syntax error in message"}

Step 4 The processing procedure of the call forwarding service is modified on the softswitch. Afterthat, the softswitch sends the correct digitmaps, and the fault is rectified.

----End


In the supplementary services such as call forwarding and third-party services, the UA5000performs the corresponding operations just according to the instructions from the softswitch.When similar cases occur, you need to analyze the H.248 messages carefully to locate the faultcauses. In addition, you need to know the processing procedure of the associated service.



291

TC-A0069 The External Call Through the UA5000 Fails Because the IP Address ofthe Outband Network Port on the UA5000 Is Configured Incorrectly

This case describes how to troubleshoot the fault wherein the external call through the UA5000fails because the IP address of the outband network port on the UA5000 is configured incorrectly.


Service exception

KeywordExternal call

Fault DescriptionWhen the UA5000 user dials a cross-softswitch external telephone number, no tone can be heardby the peer end. The internal call (made and answered by users connected to the same softswitch)supported by the UA5000, however, is normal.



l The signaling interaction between the softswitch and the UA5000 is incorrect.l The subscriber line or the hardware is faulty.l The grounding of the main distribution frame (MDF) is not proper.l The peer device or the local phone is faulty.

Procedure

Step 1 The grounding and hardware connection of the MDF, and the local phone are checked. It isfound that the grounding, hardware connection, and local phone are normal.

Step 2 Based on the fact that the internal call supported by the UA5000 is normal, packets are capturedto check whether the interaction between the UA5000 and the remote softswitch is normal. Thecaptured packets show that when the remote softswitch sends a signal to request the UA5000 toset up a connection with the remote softswitch whose IP address is 172.17.43.11, the UA5000sends the voice information to 0.0.0.0 instead. This indicates that the UA5000 fails to set up aconnection with the remote softswitch. As a result, the UA5000 user cannot make calls with thepeer end user. The further check of the UA5000 finds that the IP address of the local outbandnetwork port is the same as the IP address of the peer device. Then, the ip address command isexecuted to change the IP address of the local network port on the UA5000. The subsequent testshows that the external call through the UA5000 is normal.

----End



292

Suggestions and SummaryIn the data plan, the IP address of the outband network port cannot be configured to any IPaddress that is already used on the network.

TC-A0070 The Emergency Channel Service of the UA5000 Fails Because a SoftwareParameter of the MG Interface Is Configured Incorrectly

This case describes how to troubleshoot the fault wherein the emergency channel service of theUA5000 fails because a software parameter of the MG interface is configured incorrectly.


Service exception

KeywordEmergency channel

Fault DescriptionA new service of the UA5000, namely the emergency channel service, is provided for a privatenetwork. During the test, it is found that no dial tone is played after the user picks up the phoneoff the hook. As a result, the emergency channel service cannot be implemented normally.



l The working mode of the CDI port is not configured on the UA5000.l The heartbeat detection function is not enabled on the UA5000.l The digitmap for the emergency channel service is not configured on the UA5000.l The MG interface software parameter of the UA5000 is configured incorrectly.

Procedure

Step 1 The display port attribute command is executed to check the working mode of the CDI port.It is found that the working mode of the CDI port is configured to DDI (Direct Dialing In)correctly.

Step 2 The display mg-software parameter command is executed to check the MG software parameterconfiguration of the UA5000. It is found that the heartbeat detection function of the UA5000 isenabled, but the MG interface is interrupted during the test of the emergency channel service.

Step 3 The display digitmap command is executed to check the digitmap configuration of the UA5000.It is found that the digitmap for the emergency channel service is already configured on theUA5000.



293

Step 4 The display mg-software parameter command is executed to check the MG software parameterconfiguration of the UA5000. It is found that a parameter value corresponding to the MGinterface software parameter name index 11 is set to 0, which means that the MG interface doesnot support the emergency channel service. Then, the mg-software parameter 11 3 commandis executed to set value to 3. The subsequent test shows that the emergency channel servicereturns to the normal state.

----End

Suggestions and SummaryThe emergency channel is used when the network of the calling party is down. In this case, thecalling party can be connected to an outgoing-call port through the CDI port that is configuredwith the emergency channel service. In this manner, the calling party can make external callswith this outgoing-call port as an agent. To implement the emergency channel service, you mustdefine the required software parameters of the MG interface correctly.

TC-A0074 The Phone Conversation of the User Is Discontinuous Because the MediaIP Address of the UA5000 Conflicts with the IP Address of Another Port on theUpper-Layer Switch

This case describes how to troubleshoot the fault wherein the phone conversation of the user isdiscontinuous because the media IP address of the UA5000 conflicts with the IP address ofanother port on the upper-layer switch.


Service exception

KeywordIP address conflict

Fault Descriptionl Networking: UA5000 -> O/E converter -> O/E converter -> switch -> softswitchl Fault description: The communication quality of the UA5000 user is poor, that is, the phone

conversation is discontinuous frequently.



l The UA5000 board is faulty.l The network quality is poor.l The IP address conflict occurs.



294

Procedure

Step 1 The UA5000 is logged in and the board status of the device is checked. It is found that all theboards of the device are normal. This indicates that the fault is not caused by the board fault.

Step 2 The optical-to-electrical (O/E) converter is connected with one PC at each end, and the two PCsare pinged from each other. It is found that no packet is lost and the optical path is normal.

Step 3 The gateway of the media IP address is pinged from the UA5000. It is found that a large numberof packets are lost.

Step 4 The gateway of the signaling IP address is pinged from the UA5000. It is found that no packetis lost.

Step 5 The upper-layer device is checked. It is found that one terminal connected to the softswitch usesan IP address that is the same as the media IP address of the UA5000.

Step 6 The data about the conflicting device is deleted from the switch. Then, the gateway of the mediaIP address is pinged from the UA5000. The subsequent test shows that the phone conversationis normal.

----End


None

TC-A0077 The Packets Cannot Be Transmitted Upstream to the EP1A BoardThrough the Backplane Because the Port Type of the Daughter Board of the IPMBBoard Does Not Match the Backplane

This case describes how to troubleshoot the fault wherein the packets cannot be transmittedupstream to the EP1A board through the backplane because the port type of the daughter boardof the IPMB board does not match the backplane.

Fault Type

Other

Service exception

Keyword

Database

Configuration file

Fault Descriptionl Networking: UA5000 (IPMB) -> MA5680T

l Fault description: The UA5000 IPMB board transmits data upstream to the MA5680Tthrough the EP1A board. The uplink port on the IPMB board, however, is always in theoffline state.



295

Alarm Information

None

Cause Analysis


l The data configuration of the port is incorrect.l The hardware connection is incorrect.

Procedure

Step 1 Based on the fact that the IPMB board transmits data to the EP1A board through auto-negotiation(no manual configuration is required), a network cable is used to directly connect the uplink porton the IPMB board to the network port on the EP1A board. It is found that the statuses of thetwo ports on the IPMB and EP1A boards are normal.

Step 2 The daughter board of the IPMB board is removed during the on-site deployment, and then theerase flash data command is executed to clear the database. It is found that the fault is rectifiedafter the board registers with the system again.

----End

Suggestions and Summaryl If the IPMB board is configured with an electrical daughter board, the packets of the device

can be transmitted upstream only through the Ethernet port by default, and the packetscannot be transmitted upstream through the backplane.

l The packets can be automatically transmitted upstream to the EP1A board through thebackplane only when the uplink port on the IPMB board is an optical port, or the IPMBboard is not configured with a daughter board.

TC-A0079 The Webpage Cannot Be Opened Because the Data Configuration of theIPMB Board Is Incorrect

This case describes how to troubleshoot the fault wherein the webpage cannot be opened becausethe data configuration of the IPMB board is incorrect.

Fault Type

xDSL service

Service exception

Keyword

Internet access

Fault Descriptionl Networking: UA5000 (IPMB) -> layer-2 switch -> access server (5200F)



296

l Fault description: A new private line service is provided for the UA5000 users. After theservice provisioning, the users can dial up successfully but cannot open the webpages. TheInternet access service of the ordinary PPPoE users, however, is normal.



l The configuration of the traffic profile of the IPMB board is incorrect.l The ports on the service board are faulty.l The traffic restriction configuration on the upper-layer device is incorrect.

Procedure

Step 1 The data configuration on the IPMB board of the UA5000 is checked. It is found that the trafficrestriction parameters are not configured in the traffic profile. Then, the traffic profile is changedto 2M, 4M, and 10M profiles, and each profile is re-activated. It is found that the fault persists.

Step 2 The VLAN configuration of the private line service is checked. It is found that the VLANconfiguration is correct and the upper-layer device can transmit the VLAN packets transparentlywithout traffic restriction. A PC is directly connected to the layer-2 switch to test the Internetaccess service. It is found that the service is normal. This indicates that the PC and the upper-layer device are normal.

Step 3 An attempt to log in to QQ, a type of instant messaging software, is made. It is found that thelogin is successful. Therefore, it is considered that the IPMB board may filter the Internet accessTCP packets in the private line service.

Step 4 The access control list (ACL) configured on the device is checked. It is found that the list containssuch a rule, namely, rule 1 deny tcp (0 times matched). The application of this rule filters theTCP packets. After this rule is deleted, the test shows that the Internet access service is normal.

----End


TC-A0080 The Network Port Cannot Work Normally Because the Working Modeof the Uplink Port on the H601PVMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the network port cannot work normallybecause the working mode of the uplink port on the H601PVMD board is incorrect.

Fault TypexDSL service

Service exception



297

Keyword

up-linkport

Fault Descriptionl Networking: UA5000 -> transmission device -> router (NE40E) -> switch (S3528) ->

softswitchl Fault description: A UA5000 uses the ETH1 port on the H601PVMD control board to

transmit services. After the network cable is inserted into the ETH1 port on the controlboard, the indicator of the ETH1 port is off.

Alarm Information

None

Cause Analysis

The possible cause is as follows:

l The network cable is faulty.l The network port is down because it does not match the working mode of the uplink port.

As a result, the service fails.

Procedure

Step 1 The network cable connected to the ETH1 port is removed and inserted into the network interfacecard (NIC) of a portable PC. It is found that the indicator of the NIC is on. This indicates thatthe fault is not caused by the network cable.

Step 2 The UA5000 is logged in and the display fe active eth1 command is executed to check the statusof the ETH1 port. The command output is as follows:huawei(config)#display fe active eth1 link state:down config mode:100M Full duplex

Step 3 The display working mode command is executed to check the working mode of the board. Thecommand output is as follows:huawei(config)#display working mode working mode:alone outband port:ETH port service port:GE optic port

Step 4 It is found that the network port on the service board is a GE optical port. Then, the up-linkportset workmode command is executed to change the working mode of the uplink port. After thechange, it is found that the network port works normally and the service is restored.huawei(config)#up-linkport set workmode eth1

----End


When the H601PVMD board is used in the deployment of the UA5000, you must change theworking mode of the uplink port according to the actual conditions.



298

TC-A0083 Voice Users Fail to Call Mobile or Fixed-Line Phone Numbers ThatContain Digit 3 Because of the Subscriber Lines Are Crossed

This case describes how to troubleshoot the fault wherein the voice users fail to call mobile andfixed-line numbers with digit 3 because of the subscriber lines are crossed.


Service exception

KeywordCrossed line

Dialing failure

Fixed-line phone number


Fault description: Certain users of the UA5000 fail to call mobile phone or fixed-line phonenumbers that contain digit 3.



l The digitmap configuration on the SoftX3000 is incorrect or a fault occurs when theSoftX3000 sends the digitmap.

l The PVM control board is faulty.l The port on the service board is faulty.l The subscriber line is faulty.l The phone is faulty.

Procedure

Step 1 Based on the fact that only certain users fail to call numbers that contain digit 3, it can bedetermined that the SoftX3000 and the PVM control boards are normal.

Step 2 The H.248 signaling is traced on the SoftX3000 and UA5000. It is found that all the numbersreported in the NOTIFY messages do not contain digit 3, whereas the users confirm that theypress the key of digit 3. Based on the fact that calling other numbers that do not contain digit 3can be successful, the phone of a user who encounters the fault is exchanged with a normalphone. Then, it is found that the fault still persists. Therefore, it can be determined that the faultis not caused by the phone.



299

Step 3 The test performed on the main distribution frame in the central office shows that the service isnormal. Therefore, it can be determined that the subscriber line is faulty.

Step 4 After the fault location by the subscriber line maintenance personnel, the fault is determined tobe caused by the subscriber lines that are crossed. Then, the detected subscriber lines arereplaced. The subsequent tests at the users' homes show that the services return to normal.

----End


When locating the fault causes, it is recommended that you firstly locate the direction of thefault causes and then eliminate the possible causes one by one.

TC-A0084 Brushing Bankcard Fails Because the Switching Mode of the POSMachine Is Set Incorrectly

This case describes how to troubleshoot the fault wherein brushing the bankcard fails becausethe switching mode of the point of sale (POS) machine is set incorrectly.

Fault Type

Narrowband service

Service exception

Keyword

POS

Brushing bankcard

Fault Description

The POS machine service of a UA5000 user fails.

Alarm Information

None

Cause Analysis


l The network quality is poor.l The settings of the modem are incorrect.l The switching mode of the POS machine is set incorrectly.

Procedure

Step 1 The time report mode of the modem is changed to buffer report. It is found that the fault persists.Then, the time report mode is changed to direct report. It is found that the fault still persists.



300

Step 2 The POS machine is replaced with a normal POS machine, and the subsequent test shows thatthe service is normal. This indicates that the network quality is good but the original POSmachine is faulty.

Step 3 The switching mode of the POS machine is changed from "C" to "E". The subsequent test showsthat the fault is rectified.

----End


None

TC-A0088 Playing the Dial Tone After the UA5000 User Goes Off Hook Is DelayedBecause the ARP Entry on the Upper-Layer Switch Cannot Age Out

This case describes how to troubleshoot the fault wherein playing the dial tone after the UA5000user goes off hook is delayed because the ARP entry on the upper-layer switch cannot age out.

Fault Type

Narrowband service

Service exception

Keyword

ARP aging

Delay

Fault Description

Networking: UA5000 -> H813E -> MA5680T (OLT) -> S7806 -> softswitch

Fault description: The gateway of the UA5000 is the IP address of the S7806. It is found thatthe dial tone after the voice user of the UA5000 goes off hook is played with a delay of about3s.

Alarm Information

None

Cause Analysis


l The intermediate link connecting the UA5000 to the softswitch is faulty (the ONU, OLT,and upper-layer switch pass through the link).

l The data configuration on the UA5000 is incorrect.l The PVM control board or the voice daughter board of the UA5000 is faulty.l The ARP entry on the upper layer device is faulty.



301

Procedure

Step 1 The IP address of the softswitch is pinged from the UA5000. It is found that the delay is 150ms, which is relatively long, and that the packet loss ratio reaches 8% occasionally. This indicatesthat the link is faulty. The optical link between the H813E and the OLT is checked. It is foundthat the link is normal. Then, the H813E is replaced to be tested. It is found that the fault persists.

Step 2 The packets are captured on the UA5000. It is found that after the UA5000 sends the offhooksignaling, the softswitch sends the dial tone with a delay of about 3s. The PVM control boardand voice daughter board of the UA5000 are replaced to be tested. It is found that the faultpersists.

Step 3 The data configuration on the UA5000 is checked. It is found that the media and voice signalingIP addresses are the same. Then, the media IP address is changed to the voice signaling IP addressto be tested. It is found that the fault persists.

Step 4 The ARP entry on the S7806 is checked. It is found that the ARP entry of the S8706 learns onlythe media IP address of the UA5000 before the change whereas does not learn the media IPaddress after the change. The further check proves that the ARP entry aging mechanism of theS7806 has a bug of occasional failure. After the ARP entry is cleared and re-learned, the faultis rectified.

----End

Suggestions and SummaryWhen dealing with complicated network problems, make analysis on a basis of whole networkand accordingly look for a breakthrough to locate the fault.

TC-A0091 Apple PC Fails to Access the Internet Through Dialup After the UA5000Is Enabled with the PITP (V Mode) Function

This case describes how to troubleshoot the fault wherein Apple PC fails to access the Internetthrough dialup after the UA5000 is enabled with the PITP (V mode) function.


Service exception

KeywordPITP

Dialup failure

Fault DescriptionThe broadband users of a UA5000 find that if they use the Apple MAC OS or Apple airportbroadband router, the access to the Internet fails.




302


l The layer 2 link, namely, the link between the user PC and the broadband remote accessserver (BRAS), is faulty.

l The BRAS authentication fails.

Procedure

Step 1 A dialup test is performed on the user side. It is found that the Internet access through all thePCs installed with the Microsoft Windows XP OS can be successful. This indicates that the layer2 link is normal.

Step 2 The Apple PC is used to dial up and at the same time the packets are captured. It is found thatthe PPPoE dialup is terminated by the PADT packet sent by the PC during the dialup. Theanalysis of the captured packets shows that the "LC configuration request" packet is receivedby the Apple PC before the PADS packet. In this case, the Apple OS considers that the proceduredoes not comply with the protocol and therefore sends the PADT packet to terminate the dialupconnection.

Step 3 After receiving the PADR packet, the BRAS sends the "LC configuration request" packet at thesame time of responding the PC with the PADS packet. The PADS packet, however, needs tobe processed by the CPU of the UA5000 because the UA5000 is enabled with the PITP (V mode)function. As a result, the "LC configuration request" packet arrives at the PC before the PADSpacket.

Step 4 After the PITP function is disabled on the UA5000 or the "LC configuration request" packet issent by the BRAS with a delay, the fault is rectified.

----End

Suggestions and SummaryTo delay the time of sending the "LC configuration request" packet by the BRAS, you canconfigure the "ppp delay-lcp-negotiation" function on the BRAS in VT mode.

TC-A0099 A Large Number of IP Address Conflict Alarms Are Generated on theUA5000 Because the BRAS Fails to Process the ARP Proxy Packets Properly

This case describes how to troubleshoot the fault wherein a large number of IP address conflictalarms are generated on the UA5000 because the BRAS fails to process the ARP proxy packetsproperly.

Fault TypeOther

Service exception


ARP proxy



303

Fault DescriptionNetworking: UA5000 (EPON upstream) -> MA5680T -> convergence switch -> third-partyBRAS

Fault description: All the new UA5000s connected to the third-party BRAS continuously reportIP address conflict alarms. The MAC addresses in the generated alarms are the MAC addressof the same BRAS, and the alarms are generated at an average frequency of one alarm in oneminute.

Alarm InformationIP address conflict alarm


According to the TCP/IP protocol stack, the host checks whether its IP address is occupied byusing the free ARP request mechanism in the following two modes:

l Proactive mode: In this mode, the host sends the free ARP request to detect whether therequest is responded. The source IP address and the requested IP address are the IP addressof the host, which means that the host requests the IP address of itself to be resolved. If thehost receives an ARP response to the IP address of itself, it indicates that a host on thenetwork uses the same IP address.

l Passive mode: In this mode, if the host receives a free ARP request sent by another host,and the requested IP address is the IP address of the host that sends the request packet, itindicates that a host on the network uses the same IP address.

According to the preceding principle, to solve the IP address conflict problem, you can checkwhether the data plan and data configuration use identical IP addresses. If the problem still cannotbe solved, you can capture packets, and then analyze and locate the fault based on the ARPprinciples.

ProcedureStep 1 The data plan and the configurations of the BRAS, convergence switch, MA5680T, and UA5000

are checked. It is found that these devices do not use the identical IP address.

Step 2 It is considered that the IP address may be incorrect. Then, the IP address of the UA5000 ischanged to another IP address. It is found that the fault still persists. The UA5000 is disconnectedand then the original IP address that reports conflict is pinged. It is found that the IP addresscannot be pinged through. This indicates that this IP address is not configured by another deviceon the network.

Step 3 According to the analysis of the TCP/IP protocol stack, it is determined that if an IP addressconflict alarm is generated on the UA5000, the UA5000 must receive a free ARP request orresponse targeting the IP address of itself. The analysis of the captured packets shows that theUA5000 sends one free ARP request in each minute, whereas each time after the UA5000 sendsthe ARP request, the third-party BRAS responds to the UA5000 with the MAC address of itself.This indicates that the processing on the UA5000 is normal and the fault is associated with theprocessing on the BRAS.

Step 4 After the query, it is known that the third-party BRAS is enabled with an L3 interface for thevoice service VLAN of the UA5000, and that the BRAS is enabled with the ARP proxy function.



304

When the third-party BRAS is enabled with the ARP proxy function, the BRAS responds to allthe ARP requests (including the free ARP requests) with its MAC address.

Step 5 It is determined that the ARP proxy mechanism of the third-party BRAS is faulty. The deviceof Huawei does not respond to free ARP requests after being enabled with the ARP proxyfunction. Then, the ARP proxy function of the BRAS is disabled, and the MA5680T is configuredwith an L3 interface and is enabled with the ARP proxy function. The subsequent tests find thatno IP address conflict alarm is generated, and the voice and data services carried on the UA5000are normal. Thus, the fault is rectified.

----End


To solve the IP address conflict problem, you can check whether the data plan and dataconfiguration use identical IP addresses. If the problem still cannot be solved, you can capturepackets, and then analyze and locate the fault based on the ARP principles.

TC-A0102 The Interface Cannot Register with the Softswitch After InterruptionBecause the Signaling IP Addresses of Two AGs Conflict

This case describes how to troubleshoot the fault wherein the interface cannot register with thesoftswitch after interruption because the signaling IP addresses of two AGs conflict.

Fault Type

Narrowband service:

Service exception

Keyword

Registration failure

Signaling IP address conflict

Fault Description

Fault description: In an office, the bearer network is upgraded. The MG interface of an AGcannot recover after upgrade. The fault persists even when the MG interface is reset after thelogin to the AG.

Alarm Information

None

Cause Analysis


l The network quality is poor.l The AG cannot communicate with the softswitch normally.



305

l The H.248 signaling interaction channel is faulty. For example, there is IP address conflictor MAC address conflict on the channel.

Procedure

Step 1 The AG is pinged remotely and it is found that no packet loss occurs.

Step 2 The softswitch is pinged from the AG and it is found that no packet loss occurs.

Step 3 The signaling is traced on the AG. It is found that the AG sends the registration requestcontinuously. The softswitch, however, does not respond. The AG configuration is checked onthe softswitch side. When the softswitch queries nodes, two MGs that share the same IP addressare found. An IP address is modified, and then the registration is successful after the MG interfaceis reset.

----End


None

TC-A0105 Sometimes No Tone Is Played After Offhook Because the Software BIOSVersions of Two RSU Boards Are Different

This case describes how to troubleshoot the fault wherein sometimes no tone is played afteroffhook because the software BIOS versions of two RSU boards are different.

Fault Type

Narrowband service

Service exception

Keyword

RSU

No tone is played after offhook

Fault Description

Networking: VRSP -> OLT -> C&C08

Fault description: The fault wherein no tone is played after offhook occurs on certain users, butthe users can make phone calls normally after a period of time.

Alarm Information

None

Cause Analysis




306

l The DSP resources are insufficient.

l The 2M link quality is poor.

l The subscriber line is faulty.

l The MDF and the device are grounded inappropriately.

l The BIOS versions of two RSU boards are different.

Procedure

Step 1 The resources are checked. When the resources are sufficient, the user hears the busy tone afteroffhook.

Step 2 The 2M cable is replaced by another 2M cable. It is found the fault persists.

Step 3 A call test is performed directly on the cable distribution frame. It is found that the fault persists.This indicates that the fault is not caused by the subscriber line.

Step 4 The grounding is checked and the grounding resistance is tested. It is found that the groundingis proper and the grounding resistance complies with standards. This indicates that the fault isnot caused by the grounding.

Step 5 An RSU board is removed and only one RSU board is configured. It is found that the fault doesnot recur. It is considered that the versions of the two RSU boards may be inconsistent.

Step 6 The display version command is executed to check the software versions and BIOS versionsof the two RSU boards. It is found that the BIOS versions are different. The software versionsand BIOS versions of the two RSU boards are upgraded, and then it is found that the fault isrectified.

----End


In this troubleshooting case, the two RSU boards run normally, and hence it is hard to identifywhether they match each other. Therefore, to identify the causes of the fault, you need to usethe exclusion method or run the associated commands to obtain required information.

TC-A0108 The Service Router and Softswitch Are Down Because Loop OccursBetween the UA5000 and T64G

This case describes how to troubleshoot the fault wherein the service router and the softswitchare down because loop occurs between the UA5000 and T64G.

Fault Type

Other

Service exception

Keyword

Loop



307

Fault Description

Networking: The UA5000 is connected through its optical port to the upstream T64G of anothercompany, and the optical port on the T64G is connected to the upstream service router (T64E).

Fault description: After the UA5000 is connected to the T64G, the T64E is down and all theports on the softswitch are blocked . Signaling is captured on the softswitch. It is found that theUA5000 sends about 3000 packets to the softswitch in a second.

Alarm Information

None

Cause Analysis


l The UA5000 software is faulty.

l The data configuration on the UA5000 is incorrect.

l The UA5000 hardware is faulty.

l Loop occurs on the UA5000 or T64G.

Procedure

Step 1 On site, the S3552F is connected between the UA5000 and T64G. It is found that loop alarm isgenerated when you log in to the S3552F. Furthermore, the loop alarm still exists when theUA5000 is disconnected.

Step 2 The UA5000 is disconnected. On the T64G, the UA5000 uplink port is mirrored to an Ethernetport for capturing packets. It is found that 450 thousand packets are captured in ten seconds.

Step 3 The provider of the softswitch is contacted to handle the problem. It is found that the loop occurson VLAN 1. The T64G data is checked. It is found that the data of native VLAN 1 is configuredon the port connected to the UA5000. The data is changed and then the port is connected to theUA5000 again. No fault is found in the observation in the following two days. This indicatesthat the fault is rectified.

----End


For the network from the UA5000 to the T64G, pay attention to the data of native VLAN 1 onthe T64G.

TC-A0114 The Connection of the Automatic Meter Reading Terminal Fails to BeSet Up Because Codecs Are Switched in the Negotiation Flow of the Softswich ofAnother Company

This case describes how to troubleshoot the fault wherein the connection of the automatic meterreading terminal fails to be set up because codecs are switched in the negotiation flow of thesoftswich of another company.



308

Fault Type

Narrowband service

Service exception

Keyword

Automatic meter reading

Dialing between modems

Fault Description

Networking: User terminal -> UA5000 -> S6506R -> C7609 -> softswitch

Fault description: The UA5000 of an operator is connected to the automatic meter readingterminal (modem of a certain model) of a water supply company. The remote meter reading(dialing between modems) service is normal on the PSTN network. The connection of theautomatic meter reading terminal fails to be set up when it is cut over to the UA5000 of Huawei.The services such as the plain old voice service are normal and the communication quality isgood.

Alarm Information

None

Cause Analysis


l The flow of issuing signaling by the softswitch is incorrect.l The parameters of the deployed modem on the UA5000 of Huawei are incorrect.l The modem used in the water supply company has special flows.

Procedure

Step 1 Packets are captured on site for analysis. The softswitch issues packets, requiring the peer endto support the 804 codec. In fact, it is the AG of Huawei that chooses to support the 804 codec.It is found that the parameter 8 comes first. Therefore, the AG respond to parameter 8preferentially. The AG of Huawei chooses the parameter 8, which indicates that the AG supportsthe G.711A codec.

Step 2 The softswitch issues the ANSAMbar signal and negotiates with the modem. Note that the AGof Huawei uses the G.711A codec for negotiation. The softswitch issues a command to changethe codec. It is found that the parameter 8 follows the parameter 0 this time. The AG of Huaweialso supports the parameter 0, so it responds to the parameter 0. In this way, codecs are switchedin the negotiation flow and the modem negotiation fails.

Step 3 The maintenance personnel of the softswitch company are contacted to modify the softswitchtemplate to use the G.711A codec. Then, it is found that the fault is rectified.

----End



309

Suggestions and SummaryFor this fault, analyzing captured packets can be used to quickly locate the fault to prevent themisunderstanding of Huawei's devices by customers.

TC-A0115 The 678 Error Is Displayed During the Dialup of Broadband UsersConnected to the UA5000 Because the Wire Sequence of the Upstream Straight-Through Cable Is Incorrect

This case describes how to troubleshoot the fault wherein the 678 error is displayed during thedialup of broadband users connected to the UA5000 because the wire sequence of the upstreamstraight-through cable is incorrect.


Service exception

KeywordWire sequence of the straight-through network cable

678 error

Fault DescriptionNetworking: UA5000 (IPMB) -> SDH -> OSN3500 -> 6650 -> MA5200G

Fault description: The UA5000 supports FE in the upstream direction. A site has been runningservices for half a year. The 678 error is displayed for all users when they dial up every month.The IPMB control board is restarted and it is found that the fault persists. The dialup is sometimesnormal and sometimes abnormal after the entire shelf is powered off.



l Sometimes the dialup is normal and the IPMB uplink port is normal after the entire shelfis powered off. It is considered that the IPMB control board or the O2FN daughter boardmay be faulty.

l The upper-layer device needs to be configured with selected QinQ. Therefore, the data onthe upper-layer device may be faulty.

Procedure

Step 1 Sometimes the dialup is normal and the IPMB uplink port is normal after the entire shelf ispowered off. It is considered that the IPMB control board or the O2FN daughter board may befaulty. The IPMB control board and the O2FN daughter board are replaced. It is found that the



310

fault does not occur for several minutes. When the IPMB control board is powered off, it is foundthat the 678 error is displayed again. This indicates that the fault is not caused by the UA5000.

Step 2 It is considered that the data on the upper-layer device may be faulty. A switch is brought to thesite for test. It is found that each dialup is normal. This indicates that the upper-layer device isnormal.

Step 3 The networkings of the IPMB and the switch are compared and it is found that only one networkcable is different. Then, the upstream network cables are checked and it is found that the wiresequence is incorrect. A straight-through cable is replaced and the service is normal. The serviceis normal even when the IPMB control board is powered off.

----End

Suggestions and SummaryThe wire sequence of the straight-through cable is "white, orange, orange, white, green, green,white, blue, blue, white, brown, and brown", which does not comply with the standard of thestraight-through cable (white, orange, orange, white, green, blue, white, blue, green, white,brown, and brown). This type of fault is related to many upper-layer devices. Therefore, you areadvised to locate the fault segment by segment.

TC-A0116 Partial Calls Fail to Be Connected Because the DSP Daughter Board onthe UA5000 Is Faulty

This case describes how to troubleshoot the fault wherein partial calls fail to be connectedbecause the DSP daughter board on the UA5000 is faulty.


Service exception

KeywordWrong number

Connection


Fault description: When the user makes phone calls, a message is occasionally prompted afterdialup indicating that the dialed number is incorrect.





311

l The telephone is faulty.

l The softswitch is faulty.

l Packet loss, network jitter, and delay occur.

l The port gain and impedance are incorrect.

l The DSP daughter board is faulty.

Procedure

Step 1 The signaling of abnormal communication is captured on the AG. It is found that digits are notreported completely. This indicates that the fault is not caused by the network or softswitch.

Step 2 Other types of telephones are used for testing. It is found that the fault persists. This indicatesthat the fault is not caused by the telephone.

Step 3 The port gain and impedance are modified for testing. It is found that the fault persists. Thisindicates that the fault is not caused by the port configuration fault.

Step 4 It is considered that the DSP daughter board processing may be faulty. The DSP channelsoccupied in the normal communication and abnormal communication are observed. It is foundthat the fault occurs when the DSP channel is on the daughter board in slot 0/5/1. The DSPchannel on the daughter board in slot 0/5/1 is disabled. Then the test is performed again. It isfound that the communication is normal.

Step 5 The H602ETCA daughter board in slot 0/5/1 is replaced and the fault is rectified.

----End


None

TC-A0118 No Dial Tone Is Played After Users Connected to the UA5000 GoOffhook Because the Signaling Issued by the Softswitch Contains the abj Package

This case describes how to troubleshoot the fault wherein no dial tone is played after usersconnected to the UA5000 go offhook because the signaling issued by the softswitch containsthe abj package.

Fault Type

Narrowband service

Service exception

Keyword

abj package

dial tone



312

Fault Description

Fault description: When the interconnection between the UA5000 and the softswitch of a peervendor is tested, no dial tone is played after offhook after data on the softswitch and UA5000 isconfigured. The signaling is traced and the following information is found.

l ERROR Descriptor: ER=440{"Unsupported or unknown Package"}

l ERROR Descriptor: ER=411{"The transaction refers to an unknown ContextID"}

Alarm Information

None

Cause Analysis


l The 440 error is caused by the abj package that the UA5000 does not support.

l The 411 error is caused by the unknown context. The softswitch issues signaling {C=*{S=A0}} and then {C=99 {W-S=*}}. This error can be ignored.

l No dial tone is played because a fault occurs in ADD and the softswitch does not issue thedial tone.

Procedure

Step 1 According to the error prompt obtained in the signaling tracing, it is found that the fault is causedby the abj package contained in the signaling that the softswitch issues. The UA5000 currentlydoes not support the abj package.

Step 2 The parameter on the softswitch is changed so that the softswitch does not issue the abj package.The parameter Jitter buffer is changed from fixed to adaptive.

Step 3 A test is performed again and it is found that the dial tone is played. The fault is rectified. Inaddition, the captured packets after modification are checked. It is found that the signaling doesnot contain the abj package.

----End


For this fault, you are advised to first check whether the physical connection is correct. If thephysical connection is correct, capture the signaling for analysis.

A simple method of checking whether the physical connection is correct is as follows: Hook offthe telephone and then log in to the UA5000 to check whether the corresponding port is in thebusy state after manual offhook. If the port is not in the busy state, it indicates that the physicalconnection is incorrect. Thus, no dial tone is played. If the physical connection is correct, checkthe configuration of the UA5000 and the softswitch.

Then, capture the signaling for analysis. Rectify the fault step by step to quickly locate the fault.



313

TC-A0119 No Ringing Tone Is Played for Users Connected to the A32 Service BoardBecause the Relay Is Faulty

This case describes how to troubleshoot the fault wherein no ringing tone is played for usersconnected to the A32 service board because the relay is faulty.

Fault Type

Narrowband service

Service exception

Keyword

A32

Ringing tone

Fault Description

Fault description: When a user on the A32 service board is called by another user, no ringingtone is played.

Alarm Information

None

Cause Analysis


The A32 service board is faulty. The fault is always caused by the relay of the correspondingport and the relay fault occurs because the carbon granules inside the relay cannot roll freely.

Procedure

Step 1 The pots circuit-test command is executed to perform a circuit test for the user. It is found thatthe test result Ringing is abnormal.

Step 2 The A32 service board is removed and the relay of the corresponding user port is found. Therelay is knocked ten times with a pen to shake the carbon granules inside the relay. Then, thecarbon granules can roll freely. The A32 service board is inserted again. After the board runsnormally, a dialing test is performed and it is found that the ringing is normal.

----End


During the maintenance, the fault that no ringing tone is played occurs frequently. Generally,the A32 service board is sent back to the HQ for maintenance. The freight, however, is expensive,which increases the cost. The method used in this case has been applied on site many times.Therefore, when similar fault occurs, it is recommend that you first use this method.



314

TC-A0120 The Voice Service Fails Because the H.248 Protocol Versions on the MGInterface and Softswitch Are Different

This case describes how to troubleshoot the fault wherein the voice service fails because the H.248 protocol versions on the MG interface and softswitch are different.

Fault Type

Narrowband service

Service exception

Keyword

Ringing interruption

Ringback tone interruption

Fault Description

Networking: UA5000 -> bearer network -> SoftX3000

Fault description: The calling party can hear the first ringback tone and then hears the busy tone.After that, the ringing is interrupted. The called party hears the first ringing tone and then theringing is interrupted. The calling party hears the busy tone. The UA5000 on the softswitch side,however, is normal.

Alarm Information

MG interface disconnection alarm

Cause Analysis


l The line quality of the upstream link is poor.

l The parameters of the UA5000 do not match those of the softswitch.

Procedure

Step 1 The alarm record is checked. It is found except the MG interface interruption alarm, no otherimportant alarms exist in the alarm record. Therefore, the UA5000 can be remotely logged in.

Step 2 The display if-mgcp state command is executed to check the status of the MG interface and itis found that the MG interface is in the normal state.

Step 3 The signaling of a number is traced on the softswitch side. It is found that the latest H.248protocol version in the attributes of the MG interface is different from that on the softswitch.

Step 4 The H.248 protocol version on the UA5000 is changed to the same as that on the softswitch. Anew call test is performed, and it is found that the communication is normal. The fault is rectified.

----End



315

Suggestions and SummaryWhen a call problem occurs, check the alarm information and H.248 signaling first, which helpsyou locate the fault quickly.

TC-A0123 The IUA Link on the UA5000 Fails to Be Activated Because the Port onthe SoftSwitch Firewall Is Disabled

This case describes how to troubleshoot the fault wherein the IUA link on the UA5000 fails tobe activated because the port on the softSwitch firewall is disabled.


Service exception

KeywordIUA link

Activate

Fault DescriptionFault description: In an office, the UA5000 ISDN service is configured. After the IUA link setand IUA link are configured, the IUA link fails to be activated and the IAU link is in the downstate.



l The MG interface on the UA5000 is faulty.l The data on the UA5000 is inconsistent with the data on the softswitch.l The network device masks the port of the IUA link.

ProcedureStep 1 The MG interface on the UA5000 is checked and it is found that the MG interface is normal.

Step 2 The data on the UA5000 and softswitch is checked. It is found that the data is consistent and theport ID and the IP address correspond with each other.

Step 3 The SCTP signaling is checked. It is found that the softswitch does not send the link-establishsignaling. Therefore, it is considered that the softswitch may mask the port of the IUA link. Theconfigurations of the UA5000, softswitch, and the intermediate network device are checked. Itis found that the local port for the IUA link that the UA5000 uses is disabled on the softswitchfirewall. Then, the configuration of the firewall is modified and the fault is rectified.

----End



316

Suggestions and SummaryThe IUA link and MG interface use different ports to register with the softswitch. The bearernetwork and softswitch should enable the port of the IUA link.

TC-A0125 Users Cannot Answer Calls Normally Because the DSL Board Is FaultyThis case describes how to troubleshoot the fault wherein the users cannot answer calls normallybecause the DSL board is faulty.


Service exception

KeywordDSL board

Press hookflash

Fault DescriptionNetworking: A high-density UA5000 (with one HABA shelf) is connected to the OLT. At thesame time, the softswitch is configured with the Centrex group and a console is available.

Fault description: Users supported by the HABA shelf occasionally cannot hear any voice whenthey pick up the phone after the ringing tone. They have to press hookflash to start a normalconversation. Because the user port is not fixed, this fault recurs irregularly.



l The telephone of the user is faulty or the quality of the subscriber line is poor.l The hardware of the UA5000 is faulty.l The upper-layer device is faulty.

Procedure

Step 1 The telephone is replaced and a test is performed on the MDF side. It is found that the faultrecurs. This indicates that the fault is not caused by the telephone or the subscriber line.

Step 2 One service board, the control board, and the backplane are replaced and other service boardsare removed. It is found that the fault persists. This indicates that the fault is not caused by thehardware fault.

Step 3 The DSL board is removed and then a test is performed. It is found that the fault does not recur.After disconnected from the console, the DSL board is inserted and then a test is performed



317

again. It is found that the fault recurs. This indicates that the fault is caused by the DSL boardfault.

Step 4 The DSL board is replaced and the fault is rectified. (The DSL board may be aged or theelectronic components interferes with the DSL board. Therefore, the reporting of the offhooksignals is abnormal and this fault occurs.)

----End

Suggestions and SummaryThe DSL board is normal at other ONU512 sites. Therefore, the DSL board is not consideredto be faulty at first. You are advised to pay attention to each detail during troubleshooting.

TC-A0128 A Card Fails to Be Used on a POS Machine Connected to the UA5000Because the Access Code Attribute of the Softswitch Is Set Incorrectly

This case describes how to troubleshoot the fault wherein a card fails to be used on a POSmachine connected to the UA5000 because the access code attribute of the softswitch is setincorrectly.


Service exception

KeywordPOS machine

Card using failure

Fault DescriptionNetworking: UA5000 -> softswitch -> trunk gateway (TG)

Fault description: The UA5000 is connected to the core network softswitch used on the fixednetwork of an operator. The UA5000 provides the VoIP service for users and communicateswith the softswitch over the H.248 protocol. A voice user fails to use cards on an early-versionPOS machine connected to the UA5000. The POS service flow is as follows: After the user dialsthe access code xxxxxxx, the media streams are sent to the peer POS machine through the TG.



l The POS machine is faulty.l The configuration of the AG is incorrect.l The H.248 protocol negotiation is incorrect.



318

l The negotiation flow of the modem is incorrect.

Procedure

Step 1 The POS machine is connected to the old stored program control switch through subscriber lines.It is found that the card can be used successfully. This indicates that the fault is not caused by aPOS machine fault.

Step 2 H.248 packets in the call flow are captured through Ethereal, and the captured packets areanalyzed. It is found that the H.248 signaling is normal, the G.711 transparent transmission modeis used, VAD is disabled, EC is enabled, and CNG is disabled, which are displayed in thesignaling. After the card fails to be used on the POS machine, the card is reused on the POSmachine multiple times. The operation, however, still fails. H.248 packets are analyzed. Noproblem is found. This indicates that the fault is not caused by incorrect H.248 negotiation flow.

Step 3 The configuration of the AG is checked. It is found that the G.711 transparent transmission modeis configured on the AG modem, and the event reporting mode is immediate reporting, whichis correct. This indicates that the fault is not caused by incorrect AG configuration.

Step 4 UDP packets in the call flow are captured through Ethereal. The UDP voice packets are restoredto a voice file through the capsens software. The frequency of the voice file is analyzed throughcooledit.1. According to the analysis of the voice file through cooledit, the 2100 Hz ANS signal

responded by the TG is divided into three parts.2. When the POS machine connected to the UA5000 responds to the received ANS signal,

the response signal is the 980 Hz and 1180 Hz frequency shift keying (FSK) signal, whichis a call menu (CM) signal. According to the V.8 protocol, the POS machine sends the CMsignal after detecting the ANSam signal. Actually, the modem sends the ANS signals. Thedifference between the ANSam and ANS signals is that the amplitude modulation of theANSam signal is 15 Hz wider than that of the ANS signal.

3. According to the modem flow defined in the ITU-T V.8 protocol, the ANSam message isa 2100 Hz audio signal and the audio signal is reversed once every 450 ms. Nevertheless,according to the modem flow defined in the ITU-T V.25 protocol, the ANS message is anuninterrupted 2100 audio signal.

4. After the access code is dialed on the POS machine, the TG sends the ANS signal and usesthe flow defined in the V.25 protocol. The ANS signal returned by the TG is cut off. As aresult, the POS machine detects the ANS signal as the ANSam signal mistakenly. Then,the POS machine starts the flow defined in the V.8 protocol and sends the CM signal to thepeer end, which results in the negotiation failure.

5. The NGN is switched from the voice channel to the data channel in the call flow and signalsare interrupted during the switchover. The possible causes of packet loss are as follows:

l The EC of the TG does not completely cancel the initial signal in the echo cancellation.l After the VBD is enabled on the TG and the TG detects the ANS signal, the TG switches

to the data channel and disables the EC.l The TG is switched from the voice channel to the data channel.

Step 5 The data service of the modem has very strict requirements for network carrying. Especially,certain modems of earlier versions are sensitive to the network delay and packet loss. Thegateway serves as the source end of the IP network, and thus the delay and packet loss need tobe reduced on the gateway. When the VoIP service is used on the NGN, the memory of the codecis initialized during the switchover from the voice channel to the data channel, which definitelyresults in the signal interruption and cannot be prevented. In conclusion, the cause of the fault



319

is as follows: The signal sent by the TG is interrupted. As a result, the POS machine mistakenlydetects the ANS signal defined in the V.25 protocol as the ANSam signal defined in the V.8protocol. Then, the negotiation flow fails.

Step 6 The access code attribute of the POS machine is set to Internet access code on the softswitch.In this way, the softswitch instructs the TG to switch from the voice channel to the data channelduring number analysis. No packet loss occurs in the subsequent modem negotiation. After theaccess code attribute is modified, the card can be used normally.

----End

Suggestions and SummaryWhen a similar fault occurs in the same networking, you can check the access code attribute ofthe softswitch if the card fails to be used on the POS machine, no problem is found in the H.248protocol analysis, and the fault cannot be located.

TC-A0129 A Message, Indicating No Dial Tone, Is Displayed During theAuthentication of a POS Machine Connected to the UA5000 Because the DigitmapIs Not Configured Properly

This case describes how to troubleshoot the fault wherein a message, indicating no dial tone, isdisplayed during the authentication of a POS machine connected to the UA5000 because thedigitmap is not configured properly.


Service exception

KeywordPOS machine

Fault DescriptionNetworking: UA5000 (HABA+HABF) -> switch -> BRAS

Fault description: A POS machine connected to the UA5000 in an office fails to connect to theserver of the bank completely. A card cannot be used and a message, indicating no dial tone, isdisplayed during authentication.



l The POS terminal is faulty.l The quality of the subscriber line is poor.



320

l The data configuration of the UA5000 is incorrect.l The data configuration of the softswitch is incorrect.

Procedure

Step 1 A phone is connected to the relevant port of the POS machine for performing a test. It is foundthat outgoing calls and incoming calls can be made successfully.

Step 2 Alarms are viewed on the UA5000 after login. No QoS alarm is found.

Step 3 The softswitch is pinged on the UA5000. It is found that no packet loss occurs. This indicatesthat the fault is not caused by a bearer network fault.

Step 4 Other POS machines connected to the same UA5000 work normally. This indicates that the faultis not caused by a server fault of the bank.

Step 5 The POS machine at the faulty service site is used at the normal service site. It is found that thePOS machine works normally. POS machines at the normal service site are used at the faultyservice site. It is found that the POS machines fail to work normally. These indicate that the faultis not caused by a POS machine fault.

Step 6 Two authentication servers of the bank are located in the capital of a province and they are966000 server and 0771******* server respectively. The office does not subscribe to the tollservice. After the office subscribes to the toll service temporarily, the POS machine can beauthenticated by the 0771******* server successfully. Other POS machines connected to theUA5000 are checked on site. It is found that the POS machines can register with the 966000server successfully.

Step 7 The signaling is traced. It is found that the time taken by the POS machine at the faulty servicesite to send the authentication message (to the server of the bank) out of the city CO is 5-6 ms,which is very long.

Step 8 The softswitch is checked. It is found that the digitmap of the 966000 server is missing. Thedigitmap of the 966000 server is added. Then, the time for sending the authentication messageout of the city CO is shortened to 2-3 ms. The POS machine at the faulty service site isauthenticated. It is found that the POS machine can be authenticated successfully and cards canbe used on the POS machine normally.

----End


The service flow of the POS machine covers two phases:l sign-in phase: In the sign-in phase, a user enters the access code on the POS machine, which

sends an authentication request to the server of the bank. The POS machine receives thekey from the server of the bank within a certain period of time (generally, 20–30 ms or 60ms to the maximum). If the POS machine fails to receive a response from the server of thebank, the POS machine sends the authentication request five times.

l card using phase: In the card using phase, after the sign-in is successful, the POS machinesends information to the bank platform in the dialup mode through the telephone line. Thebank platform identifies relevant information and sends the fee deduction information tothe issuing bank. After confirming the fee deduction information, the issuing bank respondsto the bank platform with a message. After confirming the message, the bank platform sendsprocessed information to the POS machine. After confirming the received information, the



321

POS machine prints the bill. After the card using is successful, a user can always use a cardfor payment if no power failure occurs.

TC-A0130 The Household Alarm System Fails to Work Normally Because thePacking Duration Is Very Long

This case describes how to troubleshoot the fault wherein the household alarm system fails towork normally because the packet packing duration is very long.

Fault Type

Narrowband service

Service exception

Keyword

Packet packing duration

Voice channel delay

Fault Description

After a user in country Y transfers services from operator B to operator C, the user reports thatthe household alarm system fails to work normally.

Alarm Information

None

Cause Analysis


l The household alarm system automatically calls the alarm center through the householdtelephone line, and sends relevant instructions to the alarm center through DTMF signals.In this manner, the automatic alarm function is implemented. The household alarm systemfails to work normally after the telephone operator is changed. In this case, the phase(dialing phase, connection phase, or conversation phase) where the fault occurs needs tobe confirmed first. Then, the step where the fault occurs can be confirmed.

l According to the relevant standard document NICC1704 of country Y, the household alarmsystem sends messages through DTMF signals over the Fast Format Protocol, which raisesa high requirement for the voice channel delay. Operator C, however, is a new operatorwho provides the VoIP-based service. The voice channel delay from end users of operatorC to the server on the traditional PSTN network may be long and the voice channel delaymay be set inappropriately.

Procedure

Step 1 After the fault recurs on site, the voice on the line is recorded through a voice recording pen.The recorded voice is analyzed. After the recorded voice is played, it can be rapidly determinedthat the fault occurs in the conversation phase.



322

Step 2 The waveform of the recorded voice is viewed through Cooledit, and then is compared with thestandard waveform. It is found that a long delay occurs on the confirmation message (1.4 kHzsingle audio) sent by the alarm system. As a result, the server fails to receive the confirmationmessage in time, and thus the alarm fails.

Step 3 Parameters that may affect the delay and can be adjusted include only the jitter buffer and packetpacking duration on the MSAN. In current versions, the jitter buffer is dynamically adjustedaccording to the network quality. If the value of the jitter buffer is changed, the delay is affectedslightly. The packet packing duration is set by the softswitch. Currently, the packet packingduration is set to 20 ms rather than 10 ms as proposed in the NICC1704.

Step 4 The value of the jitter buffer is changed to 20 ms. It is found that the fault persists. Then, thevalue of the jitter buffer is changed back to the default value. The packet packing duration ischanged from 20 ms to 10 ms. It is found that the alarm system works normally. The waveformof DTMF signals complies with the protocol.

Step 5 After multiple tests are performed repeatedly, it is determined that the packet packing durationis the key factor that affects the alarm system. After the packet packing duration is changed from20 ms to 10 ms, the fault is rectified completely.

----End


TC-A0132 Medicare Cards Fail to Be Used on a Medicare POS Machine Connectedto the UA5000 Because the Access Code Attribute of the Softswitch Is SetIncorrectly

This case describes how to troubleshoot the fault wherein medicare cards fail to be used on amedicare POS machine connected to the UA5000 because the access code attribute of thesoftswitch is set incorrectly.


Service exception

KeywordAccess code

Card using

Fault DescriptionNetworking: POS machine -> UA5000 -> EPON access device of Huawei -> S7806 -> softswitchof another company

Fault description: An office reports that medicare cards fail to be used on a POS machineconnected to one UA5000 in a medical institution. Users can normally use medicare cards withthe original C&C08.



323



l The POS machine is faulty.l The data configuration of the UA5000 is incorrect.l The subscriber line of the port on the UA5000 is faulty. For example, interference exists

on the subscriber line or the line quality is poor.l The data configuration of the softswitch is incorrect.

Procedure

Step 1 The POS machine is checked. The POS machine is connected to the traditional PSTN networkand a test is performed. It is found that no fault occurs on the POS machine during the test. Thisindicates that the POS machine is normal.

Step 2 The data configurations of the UA5000 and modem are checked. It is found that the dataconfigurations are correct.

Step 3 The subscriber line is checked. No interference is found. The length of the subscriber line isabout 100 m. This indicates that the line quality is good.

Step 4 Bidirectional packets are captured in the mirroring mode on the uplink port. The analysis resultis as follows: GUP exists in the /ANS signal sent from the TG. As a result, the POS machinemistakenly detects the /ANS signal as the /ANSam signal. Therefore, the POS machine uses theV.8 flow and sends the CM signal, which results in the negotiation failure. The access codeattribute is set to Internet access code on the softswitch. Then, the fault is rectified.

----End

Suggestions and SummaryWhen rectifying a fault about the interconnection to the softswitch of other manufacturers, youmust exclude simple causes such as data, subscriber line, or POS machine, and then capture andanalyze packets.

TC-A0171 High CPU Usage on a UA5000 Due to a Subscriber Line FaultThis case describes the troubleshooting of a UA5000 on which the CPU usage was high due toa subscriber line fault.


Service exception

KeywordsExcessive signaling



324

Idle number reported

Fault Description

Network topology: UA5000 -> bearer network -> softswitch

Fault symptom: The CPU usage of the UA5000 was over 80%. When the subscriber line wasdisconnected from the UA5000, the CPU usage returned to normal.

Alarm Information

Alarm "CPU Occupancy Exceeds the Threshold" was displayed on the HyperTerminal.

Cause Analysis

According to the signaling interaction information captured on site, it was found that thesoftswitch was sending more than 100 digitmaps on a single UA5000 port per second, and thatthe UA5000 reported an idle number immediately after receiving each digitmap. As the UA5000needs to parse and process each received digitmap, and it also operates voice services, thesignaling processed on a single port was excessive, and therefore the CPU usage became veryhigh.

Procedure

Step 1 Signaling interaction information was captured on site. It was found that the softswitch wassending more than 100 digitmaps per second.

The message issued by the softswitch was as follows:

!/2 [10.37.1.102]:2944 T=1149637022{C=366{MF=AG109601002331{DM=DM57644375{(EF)},E=1149366538{dd/ce{DM=DM57644375},al/on,al/fl,ctyp/dtone}}}}

The message reported by the UA5000 was as follows:

!/2 [10.37.24.4]:2944 T=151624012{C=366{N=AG109601002331{OE=1149366538{20090316T16055844:dd/ce{ds="",meth=PM}}}}}

Step 2 When a port on the UA5000 that is onhook receives a dd/ce event detection message, the UA5000directly responds to the softswitch with an error message indicating that the port cannot detectthe dialup event. Based on this fact and the further analysis of the signaling information, it wasconfirmed that the port was offhook when the fault occurred. When the alarm records werechecked, a large number of port lock and unlock alarms were found. This fault occurredfrequently when a port was running abnormally.

Step 3 The subscriber line was disconnected from the UA5000, returning the port to the idle state. Asa result, the softswitch stopped issuing digitmaps to the UA5000 whenever it received an onhookevent.

Step 4 The fault was rectified by replacing the subscriber line on the affected port.

----End


None



325

TC-A0170 Occasional Failure of Call Service on a UA5000 (Calling Party HeardBusy Tone, Called Party Heard No Ringing Tone) Due to Softswitch SendingMobile Codec

This case describes the troubleshooting of the occasional call service failure (the calling partyheard busy tone and the called party heard no ringing tone) that occurred on a UA5000 due tothe sending by the softswitch of a mobile codec.


Service abnormality

KeywordER=500

Fault DescriptionWhen the UA5000 interconnected with the softswitch, the call service occasionally failed.Specifically, the calling party received a busy tone whereas the phone of the called party did notring. Through signal tracing, it was found that, at the time of the service failure, the UA5000was responding to the softswitch with an ER=500 message ("Internal software failure in theMG").



l The signaling sent by the softswitch was incorrect.l Certain functions supported by the softswitch were not supported by the UA5000.

Procedure

Step 1 Signaling tracing was used to capture packets. The captured information was as follows:!/1 [10.9.39.43] T=742097942{C=${A=line1178{M{O{MO=SR,tdmc/ec=on}}},A=${M{O{MO=SO},L{v=0c=IN IP4 $m=audio $ RTP/AVP 0 8 97 98 99 100 18 4 101 102 96a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:97 G726-40/8000a=rtpmap:98 G726-32/8000a=rtpmap:99 G726-24/8000a=rtpmap:100 G726-16/8000a=rtpmap:18 G729/8000a=rtpmap:4 G723/8000a=rtpmap:101 AMR/8000a=rtpmap:102 AMR/8000a=rtpmap:96 telephone-event/8000},R{v=0c=IN IP4 10.9.33.181m=audio 35072 RTP/AVP 0 8 97 98 99 100 18 4 101 102 96a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:97 G726-40/8000



326

a=rtpmap:98 G726-32/8000a=rtpmap:99 G726-24/8000a=rtpmap:100 G726-16/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:4 G723/8000a=fmtp:4 annexa=noa=rtpmap:101 AMR/8000a=rtpmap:102 AMR/8000a=rtpmap:96 telephone-event/8000a=sendrecv}}}}}K{742097941}!/1 [10.40.36.6]:2944 P=742097942{ER=500{"Internal software failure in the MG"}}

Step 2 Analysis of the captured information revealed that the signaling sent by the softswitch when theuser under the UA5000 was called a second time was different from the signaling sent when theuser was called the first time. The signaling sent the second time carried not only 2833negotiation information, but also parameter a (a=rtpmap:101 AMR/8000), which was used forquerying whether a mobile codec was supported. It was confirmed that the singling was correctand that the AMR mobile codec was supported by the H.248 protocol. However, the UA5000did not support negotiation based on a mobile codec, because the users connected to the UA5000were not mobile terminal users. Therefore, a mobile codec was of no significance for theUA5000.

Step 3 After the softswitch maintenance engineer was advised to delete the mobile codec, the fault wasrectified.

----End


TC-A0172 Frequent Offline of Broadband Users on One UA5000 Due to MalwareAttack

This case describes the troubleshooting of the frequent offline of broadband users on a UA5000due to malware attack.

Fault TypeEthernet service

Service exception

KeywordsMalware attack

PPPoE dialup

Fault DescriptionNetwork topology: UA5000 -> MA5680T -> BRAS

Fault symptom: A large number of broadband users connected to the UA5000 went offlinefrequently. When the users performed PPPoE dialup again after offline, error 676 was displayed.



327

Alarm InformationAlarms "Line-caused ADSL Port Auto Deactivation" and "ADSL Port Link Loss" weredisplayed on the HyperTerminal.


l The subscriber line was faulty.l Interference caused by malware attack existed between users.

Procedure

Step 1 The offline records on the BRAS were checked. It was found that the users went offline at thesame time. According to the generated alarms, it was hypothesized that the PPPoE dialup offlinewas caused by interference on subscriber lines. Given that a new GSM base station wasestablished about 50 m away from the UA5000, the radio signal interference was a preliminarilysuspect of causing the fault.

Step 2 A local PPPoE dialup test was performed in the equipment room that housed the UA5000. Itwas found that the PC went offline in five minutes after connecting to the Internet. When thePPPoE dialup was performed again, error 676 was displayed.

Step 3 The Ethereal software was used on the test PC to trace the PPPoE packets. It was found that theBRAS responded with a PPP-LC-Termination packet, rather than a PADS packet, to the userafter receiving a PADR packet. As a result, broadband users failed to access the Internet. Basedon the preceding analysis, it was confirmed that the offline of broadband users was not causedby subscriber line problems.

Step 4 All the ADSL ports on the UA5000, except for the ADSL port connected to the PC used in thelocal test, were deactivated. Then, the PPPoE dialup was performed on the activated ADSL port.It was found that offline did not occur on the port in one hour. Packets were tracked in the processof disconnecting the PPPoE connection and then re-dialing up on the port many times. Thetracked PPPoE packets revealed no fault. The preceding analysis showed that the PPPoE packetinteraction between a single user and the BRAS was normal, and that the fault might occur onone user port on the UA5000, affecting Internet access of other users.

Step 5 The ADSL ports were activated one by one to test on which port the fault had occurred. Whenan ADSL port was activated, it was found that all the online ADSL users went offline, indicatingthat the fault occurred on this ADSL port.

Step 6 The ADSL user was advised to disconnect the PPPoE connection and then dial up again. It wasfound that upstream data traffic of the user was three times the downstream data traffic, wheneverno Internet page was open or download software was used. The traffic information about theADSL port on the UA5000 was checked. A large number of abnormal upstream data wasdetected.huawei(config)#display traffic 0/11/2{ <cr>|channel<K> }: Command: display traffic 0/11/2 Querying, please wait... -------------------------------------------------------------- Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps) -------------------------------------------------------------- 0/11/2 183.2 61.0 --------------------------------------------------------------



328

Step 7 After the ADSL port was deactivated, other users accessed the Internet normally through dialup.After observation for four hours, no offline fault was found. In conclusion, after the PPPoEdialup was successful, the faulty ADSL port learned the MAC address of the BAS, and itpretended to be a BRAS when other users performed PPPoE dialup. Therefore, when registeringwith this forged BRAS, the users failed to complete the normal packet interaction in the PPPoEdiscovery phase. Consequently, error 676 was prompted for these users.

----End

Suggestions and Summaryl Analyzing the PPPoE packet interaction is a major method of troubleshooting the PPPoE

service. You can also locate the fault by mirrored packet capture. When an offline occurs,dial up again immediately and trace the PPPoE packets, which is of great help fortroubleshooting.

l It is necessary to consider all the possible causes comprehensively when locating a fault,and do not locate fault based on only one suspect cause. For instance, in this case, thepreliminary suspect of the cause was the radio signal interference from the new GSM basestation, but finally the analysis showed that the fault was irrelevant to any subscriber lineproblem.

TC-A0175 Failure of Fax Service on a UA5000 Due to Quality Problems of theOptical Splitter

This case describes the troubleshooting of the fax service on a UA5000, which failed due toquality problems of the optical splitter.


Service exception

KeywordsD500

Fax service failure

Fault Descriptionl Network topology: UA5000 (F01D500) -> optical splitter -> MA5680T -> switch (S7806)

-> router (NE40) -> softswitchl Fault symptom: Users connected to certain ports on a UA5000 that uses the F01D500

cabinet failed to send and receive faxes normally, but the voice services of the users werenormal. The detailed fault symptoms were as follows:– Seven to eight fax machines connected to the F01D500 could send/receive fax to/from

each other normally.– The fax machines connected to the F01D500 failed to send/receive fax to/from the fax

machines that were not connected to the F01D500.




329


l The fax machine was faulty.l The subscriber line was faulty.l The data configuration of the UA5000 was incorrect.l Packet loss occurred on the optical path.

ProcedureStep 1 An affected fax machine was replaced. A test showed that the fault persisted.

Step 2 The fax machine was directly connected to the circuit line instead of the subscriber line. A testshowed that the fault persisted.

Step 3 The data configuration of the UA5000 was checked on site and found to be correct.

Step 4 The optical path was checked. It was found that a 1.3‰ packet loss occurred between theUA5000 and the softswitch.

Step 5 Packet pinging test between two devices was performed segment by segment on the network. Itwas found that no ping packet was discarded between the S7806 and the softswitch, and betweenthe S7806 and the MA5680T. The ping packet loss occurred between the S7806 and the UA5000,and between the MA5680T and the UA5000. Therefore, it was determined that the fault occurredbetween the MA5680T and the UA5000.

Step 6 The upstream PON board of the UA5000 was replaced. It was found that the fault persisted.

Step 7 The PON access service board for the MA5680T was replaced. It was found that the faultpersisted.

Step 8 The optical splitter between the MA5680T and the UA5000 was replaced. It was found that thefault did not occur and the fax service ran normally.

----End

Suggestions and Summaryl The data services, such as the fax and modem services, are sensitive to the delay caused by

packet loss. Therefore, when such services fail, it is recommended to first check whethera packet loss occurs on the network.

l If the optical splitter used by the customer is not provided by Huawei, it is recommendedto check the optical splitter when troubleshooting the FTTX problems.

TC-A0176 Absence of Caller Identification for UA5000 Users Due to IncorrectRinging Mode Settings on the Switch

This case describes the troubleshooting of a UA5000 on which the caller identification was notdisplayed due to incorrect ringing mode settings on the switch.


Service exception



330

Keywords

Long ringing

VRSP mode

Fault Description

Network topology: VRSP -> C&C08 switch

Fault symptom: The caller identification was not displayed for certain users connected to theUA5000.

Alarm Information

None

Cause Analysis


l The phone or subscriber line was faulty.

l The grounding resistance or the interference was great, or the transmission quality waspoor.

l The power board or the service board was faulty.

l The data configuration of the switch was incorrect.

Procedure

Step 1 Different new phones were connected directly to the device in the telecommunications room,rather than connected through the subscriber line. The subsequent tests showed that the calleridentification was not displayed on all the phones.

Step 2 The grounding of the UA5000 was checked. It was found that the device was grounded properly.Then, a test meter, such as a multimeter, was used to test the current on the device. No abnormalcurrent was detected on the device.

Step 3 The power board of the device was checked. It was found that the board was in the normal state.In addition, given that only one 2M link was configured on the device and there was no noisein normal calls on the device, it was determined that the transmission device was normal.

Step 4 A further analysis of the fault symptoms showed that the ringing modes of all the users whoencountered the fault were long-ringing mode (that is, the ringing was played withoutinterruption). Then, after the configuration of the ringing modes of these users was corrected onthe switch, the fault was rectified.

----End


None



331

TC-A0178 Static on the Lines Connected to Certain Boards of the UA5000 Due toInconsistency of Shelf Types

This case describes the troubleshooting of the static on the lines connected to certain boards ofa UA5000 due to inconsistency of the shelf types.


Service exception

KeywordsConsistency of shelf types

Static on the line

Outdoor cabinet

Fault DescriptionUsers connected to slots 20, 21, 22, 30, and 31 in the second shelf of an outdoor cabinet ofUA5000 could hardly complete a conversation with other uses by phone, because there wasstatic on the lines.



l The network quality was poor.l The service board was faulty.l The device was not grounded properly or the subtending cables were not connected

properly.l The slot on the backplane of the shelf was faulty.l The data configuration was different from the actual hardware configuration.

Procedure

Step 1 The UA5000 was logged in and the ping command was executed to ping the gateway. Thegateway could be pinged, indicating that the network quality was good.

Step 2 The board in an affected slot was replaced with a board in a normal slot. It was found that thefault persisted, indicating that the fault was not caused by a service board problem.

Step 3 Given that the fault occurred on only certain boards rather than all the boards on the device, itcould be preliminarily determined that the fault was not caused by the grounding problem of thedevice.

Step 4 The display frame info command was executed to query the information about the shelf.



332

huawei(config)#display frame info{ <cr>|frameid<0,97> }: Command: display frame info ---------------------------------------------------------------------------- FrameID FrameType FrameState ---------------------------------------------------------------------------- 0 MAIN_HABM_30(HABA) Normal ----------------------------------------------------------------------------

It was found that the shelf added in software was an HABA shelf, which, however, should notbe configured on an outdoor cabinet.

Step 5 A check on site showed that the UA5000 uses the F01D500 cabinet and HABD+HABF shelves.When the HABA shelf was deleted by executing the frame delete command and then the correctshelf was added by executing the frame add command, it was found that the static on the linedisappeared and that the users could have conversations by phone normally. The command foradding the correct shelf is as follows:huawei(config)#frame add 0 FrameType: 0 : MAIN_HABM_30(HABA) 1 : MAIN_HAFM_30(HABD) 2 : MAIN_HAFM_6(HABL) 3 : MAIN_H602HABD(HABD) 4 : MAIN_H601HABC(HABC) 5 : MAIN_H601HABO(HABO) 6 : MAIN_H601HABM(HABM) 7 : SLAVE_HAFS_32(HABE) 8 : SLAVE_HABS_32(HABB) 9 : SLAVE_HABS_30(HABA) 10 : SLAVE_HAFS_30(HABD) 11 : SLAVE_H602HABD(HABD) 12 : SLAVE_H602HABE(HABE) 13 : RSU_HAFS_30(HABD) 14 : RSU_HABS_30(HABA) 15 : RSU_HAFS_12(HABC) 16 : RSU_HAFS_6(HABL) 17 : RSUG_ONU60A(HUBO) 18 : RSUG_ONU04A 19 : RSUG_ONU08A 20 : RSP_19(HCB) 21 : RSP_15(HDB) 22 : RSP_14(HIB) 23 : RSP_12(HFB) 24 : RSP_10(HGB) 25 : RSP_6A(HMB) 26 : RSP_6B(HLB) 27 : UAM_R (HUBM) 28 : UAS_R (HUBS) 29 : UAFM_R(HUBE) 30 : UAFS_R(HUBF) 31 : UAMB_R(HUBB) 32 : ONU60A_R(HUBO) 33 : ONUF01D100_R(HUBL) 34 : VRSP_12(HABA) 35 : VRSP_18(HABA) 36 : HWTA(HIB_1) 37 : HWTA(HIB_2) 38 : HWTA(HIB_3) Please select frame type (0 ~ 38):3 Frame add successfully

----End


In this case, as the device could run normally when it was configured with the HABA shelfduring deployment, this fault did not occur before. However, the device processes datadifferently when it is configured with different types of shelves in software. If the softwareconfiguration of the device is incorrect, a fault may occur one day. Therefore, during devicedeployment, you must configure the device correctly according to the actual hardwareconfiguration of the device.

TC-A0179 Error 678 Displayed During Internet Access Through Dialup Due toIncorrect Setting of Service Port Status

This case describes the troubleshooting of error 678 that was displayed during dialup Internetaccess through a UA5000 due to incorrect setting of the service port status on the UA5000.



333


Service exception

Keywordact/up

deact/dn

Fault DescriptionAfter a UA5000 was configured with a new ADSL user in the capacity expansion, the on-sitedialup test showed that the Internet access of the new user failed. In addition, error 678 wasdisplayed when the fault occurred.



l The upstream link on the control board was inaccessible.l The configuration of the service VLAN was incorrect.l The subscriber line was faulty.l The port configuration of the UA5000 was incorrect.

Procedure

Step 1 Given that the services on the preceding boards in the same shelf operated normally, indicatingthat the ADSL service expansion on the UA5000 did not affect the original service, it wasdetermined that the upstream link on the control board of the device was normal.

Step 2 Given that the services on other ADSL ports in the same shelf as the affected port were normal,it was determined that the service VLAN configuration for the user was correct, because thedata plan requires that the ADSL services carried on the same shelf use the same service VLAN.

Step 3 The ADSL port information was queried after a modem was connected to the port. It was foundthat the port could be activated normally, indicating that the subscriber line was normal. Thequery result was as follows:huawei(config)#display board 0/7 ------------------------------ Board nane : H603ADRB Board status : Normal Online status : - ----------------------------------------------------------------------------- Port Port Type Port Status Line Profile Alarm Profile Extended Profile



334

----------------------------------------------------------------------------- 0 ADSL Being activated 1 1 -- 1 ADSL Being activated 1 1 -- 2 ADSL Activated 1 1 -- 3 ADSL Being activated 1 1 --

NOTE

Port 0/7/2 is the affected user port.

Step 4 The display service-port command was executed to query the service stream configuration onthe port. It was found that the port was configured with a service. The query result was as follows:huawei(config)#display service-port board 0/7 { <cr>|groupindex<K> }: Command: display service-port board 0/7 ---------------------------------------------------------------------------- VLAN VLAN attribute port shelf/slot/port VPI VCI service type parameter RX TX status flag ---------------------------------------------------------------------------- 207 common adl 0/ 7/ 0 0 35 - - 6 6 deact/dn - 207 common adl 0/ 7/ 1 0 35 - - 6 6 deact/dn - 207 common adl 0/ 7/ 2 0 35 - - 6 6 deact/dn -

NOTE


The command output showed that the service management status of the affected port was deact/dn, whereas the service management status of a normal port should be act/up. Therefore, it washypothesized that the service port was configured to deactivated state, resulting in the dialupconnection failure.

Step 5 After the activate service-port all was executed to activate all the service ports, it was foundthat the Internet access by the user through dialup was normal.

----End


TC-A0187 Error 676 on UA5000 Users During Dialup Due to Restriction on theNumber of Permitted BRAS Connections

This case describes the troubleshooting of error 676 that occurred on users of a UA5000 duringdialup due to restriction on the number of permitted BRAS connections.


Service interruption



335

KeywordsPADS

Number of users

Fault DescriptionNetwork topology: PC -> UA5000 -> router (6506R) -> BRAS

Fault symptom: Error 676 message frequently occurred on users of a newly-deployed UA5000during dialup.



l A loop occurred on user ports.l A loop occurred on a port on the upper-layer device.l The upstream optical-to-electrical (O/E) converter was faulty.l The number of permitted BRAS users was limited.

ProcedureStep 1 Given that error 676 during dialup was mostly caused by a loop on the user port or upper-layer

device, the ring check enable command was executed to enable the loop detection function ofthe UA5000. Then, the security mac-filter 0030-8810-2889 command (0030-8810-2889 wasthe MAC address of the BRAS) was executed to filter the MAC address, because the ring checkenable command could be used for preventing only single-port loop but could not be used forpreventing multi-port loop. It was found that the fault persisted.

Step 2 The upper-layer router (6506R) was checked. No loop was detected on the router, indicatingthat the fault was not caused by a loop on the UA5000 or upper-layer device.

Step 3 Packets were captured on the user port. The analysis found that the user PC did not receive theresponse packet PADS from the BRAS after sending four PADR packets to the BRAS, indicatingthat the upper-layer device may have discarded packets. Therefore, traffic statistics werecollected for analysis. The configuration scripts were as follows: <acl-link>acl number 4000 rule 5 permit type 0x8863 source 0022-1579-9c8b 0000-0000-0000 destination 0030-8810-2889 0000-0000-0000acl number 4001 rule 5 permit type 0x8863 source 0030-8810-2889 0000-0000-0000 destination 0022-1579-9c8b 0000-0000-0000# traffic-statistic inbound link-group 4001 rule 5 port 0/2/0 traffic-statistic outbound link-group 4000 rule 5 port 0/2/0

The display qos-info traffic-statistic port 0/2/0 command was executed to query the portstatistics.

huawei#display qos-info traffic-statistic port 0/2/0



336

traffic-statistic:port 0/2/0: Inbound: Matches: Acl 4001 rule 5 running 2 packets Outbound: Matches: Acl 4000 rule 5 running 1 packets Total number of traffic-statistic inbound : 1 Total number of traffic-statistic outbound : 1 Total number of traffic-statistic all : 2

When the dialup was normal, ACL4001 rule could match two packets, namely PADO and PADS,and ACL4000 rule matched only one packet, namely PADR. When the dialup was abnormal,the matching information was as follows:


Specifically, ACL4001 rule matched only one packet, namely PADO, whereas ACL4000 rulematched four packets because the user PC sent four PADR packets. Therefore, it was determinedthat the error 676 fault was caused because the upper-layer device did not respond to the userwith the PADS packet. After the same method was used on router 6506R to collect trafficstatistics, the same problem was found.

Step 4 The number of permitted BRAS connections was checked on the BRAS. It was found that theBRAS permitted the connection of only four users. After the number of permitted BRASconnections were increased to the maximum value, the fault was rectified.

----End


Error 676 during dialup is seldom caused by the restriction on the number of permitted BRASconnections, which therefore is often ignored during the handling of error 676. This case can beused as a reference for troubleshooting similar faults.

TC-A0190 Low Rate of Internet Access Through the UA5000 Due to a Large Numberof Junk Packets Transmitted from the Upper-layer Device

This case describes the troubleshooting of the low rate of Internet access through a UA5000because the upper-layer device transmitted a large number of junk packets.

Fault Type

Ethernet service

Service exception



337

KeywordsTraffic

ADSL

Fault DescriptionNetwork topology: UA5000 (IPMB) -> switch (S3500)

Faulty symptom: At about 10:30 AM every day, the Internet access rates of users connected toa UA5000 that used the IPMB+PVMB integrated upstream transmission mode were very low.The users used the MUX VLAN service.



l A fault, such as loop or virus attack, occurred on the user.l The IPMB control board processed the forwarded ADSL service data incorrectly.l The upstream bandwidth on the uplink port on the IPMB control board was insufficient so

that the traffic was limited.

Procedure

Step 1 The UA5000 was checked. It was found that the device was enabled with the loop detectionfunction, indicating that the fault was not caused by user port loop.

Step 2 Given that the users used the MUX VLAN service and that the low Internet access rate occurredon a large number of users in the same period, the possible cause of virus attack was eliminatedbecause there was little probability that all the users were affected by virus at the same time.

Step 3 The display traffic F/S/P command was executed to check the traffic on the activated user ports.It was found that the traffic on these ports was light, indicating that the fault was not caused byuser port.

Step 4 The other ETH port on the IPMB control board was added to the user VLAN. It was found thatthe Internet access rate was still very low, indicating that the fault was not caused by thecommunication failure between the ADSL service board and the IPMB control board.

Step 5 The UA5000 was logged in through the inband network management channel. It was found thatthe UA5000 responded to the received messages slowly, indicating that the fault may occurredon the IPMB control board.

Step 6 The IPMB control board was checked. It was found that only port 0 (for transmitting dataupstream) and port 7 (for subtending to the PVM board) on the IPMB board were online. Then,the traffic on associated ports on the IPMB board was checked after the activate command wasexecuted to activate all the ADSL ports.huawei(config-if-ipm-0/2)#display port traffic 0 The received traffic of this port(packets/s) =16606 The received traffic of this port(octets/s) =11173451 The transmitted traffic of this port(packets/s) =40



338

The transmitted traffic of this port(octets/s) =8498huawei(config-if-ipm-0/2)#display port traffic 7 The received traffic of this port(packets/s) =37 The received traffic of this port(octets/s) =8306 The transmitted traffic of this port(packets/s) =41 The transmitted traffic of this port(octets/s) =8406Port 7 forwards the voice service, and its Tx traffic and Rx traffic

The displayed traffic information showed that port 7 transmitted the voice service, with almostthe same receiving and transmitting traffic of about 8 kbyte/s. The transmitting traffic on port 0was almost the same as the transmitting traffic on port 7, but the receiving traffic on port 0 was11.17 Mbyte/s, which was excessively greater than the transmitting traffic and almost fullyoccupied the traffic on the 100 Mbit/s uplink port (100 Mbit/s = 12.5 Mbyte/s). Therefore, it waspreliminarily determined that the receiving traffic on port 0 caused the fault.

Step 7 The upper-layer switch S3500 was checked. It was found that the switch sent a large number ofjunk packets to the UA5000 in a certain period every day. After the junk packet filtering functionwas enabled on the switch through configuration change, the receiving traffic on the UA5000was normal and the Internet access rates of the users returned to the normal state.

----End

Suggestions and SummaryChecking the traffic on ports helps identify the causes of low Internet access rate.

TC-A0191 Fault on a Newly-Added SPC Due to the Local Loopback on the E1 PortThis case describes the troubleshooting of a newly added SPC that was faulty due to the localloopback on the E1 port.


Service abnormality

KeywordsSPC

Port loopback

Fault DescriptionThe control board of the UA5000 was PVMB and the service board was SDL. After running thecommand for adding an SPC, the system displayed the message "SPC fault".





339

l The service boards were faulty.l The timeslot configuration was configured incorrectly.l Local loopback occurred on the E1 ports.

Procedure

Step 1 The display board 0 command was executed to query the board status. It was found that theboard was normal.huawei(config)#display board 0 ------------------------------------------------------------------------- SlotID BoardName Status Sub0 Sub1 Online/Offline ------------------------------------------------------------------------- 0 PWX2 Normal 1 PWX2 Normal 2 3 4 H601PVMBF Active_normal H602ETCA 5 6 A32 Normal 7 A32 Normal 8 A32 Normal 9 A32 Normal 10 A32 Normal 11 A32 Normal 12 SDL Normal 13 SDL Normal 14 SDL Normal 15 SDL Normal

Step 2 The display_timeslot command was executed to check the timeslot occupancy status on theport on the SDL board. It was found that all the timeslots on the port were in the idle state.Therefore, it was determined that the SPC was faulty.huawei(config-if-sdl-0/13)#display timeslot ---------------------------------------------------------- | 0--7 | 8--15 | 16--23 | 24--31 | ---------------------------------------------------------- First HW | 00000000 | 00000000 | 00000000 | 00000000 | Second HW | 00000000 | 00000000 | 00000000 | 00000000 | First FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Second FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Third FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Fourth FE1 | 00000000 | 00000000 | 00000000 | 00000000 | First SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Second SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Third SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Fourth SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | ---------------------------------------------------------- '0'-Not used; '1'-Used ----------------------------------------------------------

Step 3 The spc delete command was executed to delete the faulty SPC and then the spc add commandwas executed to add a new SPC. However, the system still displayed "SPC fault".

Step 4 In the SDL mode, the display port state command was executed to query the ports status. Itwas found that a local loopback was performed on the E1 port.huawei(config-if-sdl-0/13)#display port state ------------------------------------------------------------------------- Port Type Frame Loop ALARM( LOS LFA RRA LMFA AIS CRC4 ) ------------------------------------------------------------------------- 0 FE1 PCM31 Local loopback N N N N N N 1 FE1 PCM31 No loopback Y Y N N N N 2 FE1 PCM31 No loopback Y Y N N N N 3 FE1 PCM31 No loopback Y Y N N N N -----------------------------------------------------



340

Port Type Rate Loop State ----------------------------------------------------- 4 SHDSL(V35) 32x64K No loopback Deactive 5 SHDSL(FE1) 32x64K No loopback Deactive 6 SHDSL(FE1) 32x64K No loopback Deactive 7 SHDSL(FE1) 32x64K No loopback Deactive -----------------------------------------------------

Step 5 The undo port_loopback command was executed to cancel the local loopback. It was foundthat the SPC returned to the normal state.

----End


If the bound E1 port is configured with loopback before the SPC is added, it is necessary tocancel the loopback on the E1 port and then add the SPC. If the loopback on the E1 port isrequired, it is recommended to cancel the loopback immediately after the test because theloopback may affect services.

TC-A0192 Fax Receiving Failure on a Fax Machine That Can Normally Transmit aFax Due to Incorrect Packets Issued by the Softswitch

This case describes the troubleshooting of a fax machine that could transmit a fax but could notreceive a fax due to incorrect packets issued by the softswitch.

Fault Type

Narrowband service

Service abnormality

Keywords

ER=500

Fax receiving failure

Fault Description

Network topology: UA5000 (EP1A) -> MA5680T -> bearer network -> softswitch

Fault symptom: The user under the UA5000 could transmit but could not receive the fax.

Alarm Information

None

Cause Analysis


l The fax machine was faulty.l Signaling flow for interconnecting with the softswitch was improper.



341

Procedure

Step 1 The working status of the fax machine was checked. It was found that the fax machine workedin a normal state, indicating that the fault was not caused by the fax or configuration.

Step 2 Pinging the softswitch from the UA5000 was performed. It was found that the softswitch couldbe pinged and no alarms were generated on the device.

Step 3 Softswitch signaling was traced and analyzed as follows:!/1 [10.67.5.53]:2944 T=1442084142{C=7{MF=A15{M{O{MO=SR,tdmc/ec=Off}},E=1442056393{ctyp/dtone,al/on,al/fl}},MF=A100000006{M{ST=1{O{MO=SR,RV=OFF,RG=OFF,nt/jit=40,tdmc/ec=Off},R{v=0 o=ZTE 207 30600 IN IP4 10.67.5.54 s=phone-call c=IN IP4 10.67.4.37 t=0 0 m=audio 15498 RTP/AVP 0 a=ptime:10 a=Modem }},TS{BF=OFF,ctyp/calltyp=DATA}}}}}!/1 [10.67.49.225]:2944 P=1442084142{C=7{MF=A15,MF=A100000006{ER=500{"Internal software failure in the MG"}}}}

The packet "a=Modem" that the softswitch issued could not be identified by the UA5000, andtherefore the UA5000 responded to the softswitch with the "Internal software failure in the MG"message.

Step 4 A softswitch fax profile parameter was modified, that is, the parameter "a=Modem" is deleted.After the modification, the fault was rectified.

----End


None

TC-A0193 Abnormal Ringing on Phones Connected to a UA5000 Due to theInterference on the Subscriber Line

This case describes the troubleshooting of the abnormal ringing on phones connected to aUA5000 due to the interference on the subscriber line.

Fault Type

Narrowband service

Service abnormality

Keywords

False ringing

DTMF

Fault Description

Fault symptom: The UA5000 worked in the normal state after providing the voice call service.After a period of time, users on the UA5000 reported that their phones often rang without beingcalled, and that the caller identification was also displayed. When the users took the phones offthe hook, however, no tone was played or the busy tone was played. The caller party did not callthe called party after the caller ID was dialed for acknowledgment.



342



l Prank call existedl The phone may be faulty.l The quality of the outside line and the insulation between line A and line B was poor.l Certain ports on the service board were faulty.

Procedure

Step 1 The caller party did not call the called party according to the caller ID short number.

Step 2 The phone was normal before the cutover of the UA5000 and most of the phones encounteredthe same fault at the same time. Therefore, the fault of the phone was excluded.

Step 3 The displayed caller ID was 4 short number of intro-group when the phone rings. According tothe feature of the line and the dialing mode, it was concluded that line A and line B touched witheach other, which caused the quality of the outside line was poor. As in the case that the calledparty was called through the pulse dialing.

Step 4 The pstnport attribute set command was executed to modify the configurations and shield thedigit collecting mode. The phone did not ring after observation for several days. The fault wasremoved. The specific configurations were as follows:huawei(config-esl-user)#pstnport attribute set 0/6/0 dial-mode DTMF-only

By default, the UA5000 supports both the impulse and DTMF modes. The two modes werechanged to the DTMF mode to shield the impulse signal.

----End

Suggestions and SummaryThe way of pulse dialing is similar to a sender sending numbers. The dialup is emulated if theoutside line is contacted with each other continually due to the poor quality of the outside line.However, for the voice call, the number is dialed in a fixed frequency, so the interference fromthe outside line does not affect the voice call.

TC-A0194 Failure of PPPoE Dialup Through the Subtending Shelf of a UA5000 Dueto the MAC Address Spoofing Function Configured on the UA5000

This case describes the troubleshooting of the PPPoE dialup failure that occurred on subtendingshelf of a UA5000 due to the MAC address spoofing function configured on the device.

Fault TypeEthernet Service

Service abnormality



343

Keyword

PITP

System security

Fault Description

Network topology: The UA5000 had two subtending shelves, the broadband control board wasthe IPMB, and the service board was the CSMB. The two shelves used the same service VLANduring service deployment.

The PPPoE dialup failure occurred on users of a UA5000 randomly, whereas the voice servicewas normal. Dialup failures from time to time and the distribution of the users' ports had noobvious rules. The voice service was normal.

Alarm Information

None

Cause Analysis


l The user failed to send the PPPoE dialup request.l The board driver was faulty.l The subtending shelf control board was faulty.l Attack ports existed on the device.

Procedure

Step 1 A dialup test was performed on the PC connected to the xDSL port, and the mirroring packetcapturing was performed on uplink port 0, with the filtering criterion on the packet capture toolEthereal set to the MAC address of the PC. It was found that the PADI packets did not reach theuplink port.

Step 2 The PPPoE dialup test was performed on the PC, connected to FE port 2 on the UA5000. Themirroring and packet capturing was performed on the uplink port. The PADI packet was detected.After the mirroring and packet capturing was performed on other uplink ports, no PADI packetwas detected. It indicated that the dialup packets was sent out but did not reach the uplink port0.

Step 3 The MAC address learned on the subtending shelf of the UA5000. It was found that only morethan 30 MAC addresses were learned by the UA5000. In normal conditions, the number of MACaddresses learned exceeds 100. Only if the LSW and the logic learned the MAC address at thesame time, can the MAC address be queried by running the display Mac-address command.Therefore, it was hypothesized that the packets was lost in the logic and the LSW.

Step 4 After the board was replaced, the fault persisted. It was found that the number of MAC addressesof the subtended shelves reached more than 180, but the number of the MAC addresses of thesubtending shelves was only about 30. Given that the PADI packets already reached the logicbut it was not found on the LSW upstream port, it was hypothesized that the PADI packets maybe discarded by the logic or LSW.



344

Step 5 The MAC address learned at the f/s shelf/slot can be queried by running the display mac-addressall command. If eight static MAC addresses were learned at the slot, it indicated that this portwas the attack source. All the attacked ports on the device were checked in this way, thus it wasdetermined that the attacked ports existed on the device.

NOTE

From the attack ports queried by deactivating, you can check whether other faulty ports on the UA5000can restore the PPPoE dialup. Therefore, the attacked ports acknowledged can be checked.

Step 6 After the attacked port was recorded and the fault information about the device was collected,the service on the attack ports was suspended. It was found that the PPPoE dialup on the faultyports was successful, indicating that the fault was rectified.

Step 7 As for the attack port, the bind command was executed to bind the MAC address. Thereforeonly the MAC address configured could be used by the user port for packets sending. The mac-address max-mac-count command was executed to configure the maximum number of theMAC addresses that learned by the port. The PPoE dialup service recovered after the previousconfiguration and the fault was removed.

----End

Suggestions and SummaryThe anti-MAC spoofing principles are analyzed as follows:

l Assuming that MAC1 is the MAC address of user A and MAC2 is the MAC address ofuser B, MAC2 is bounded with user A when user A dials through MAC2 in the case thatthe anti-MAC spoofing function is enabled. The PPPoE packets of user B is considered asthe unauthorized packets and is discarded because MAC2 has been bounded with user Awhen user B dials. As a result, the dialup of user B fails.

l When the anti-MAC spoofing function is enabled, the normal MAC address (not the staticconfiguration) is learned by the LSW chip in a static mode and the packets with this MACaddress are sent to the LSW all the time. At the same time, the learning of packets of normalusers fails.

As for problems of the PPPoE dialup failures, first check the security configurations of thedevice, such as the configuration of PITP and the anti-MAC address spoofing function, andcheck whether the user port attack is related to the configuration.

TC-A0195 Occasional Low Transmission Rate on the Modem Due to IncorrectSoftswitch Configuration

This case describes the troubleshooting of the occasional low transmission rate on the modemconnected to a UA5000 due to incorrect configuration on the softswitch.


Service abnormality

KeywordsAccess code

Low transmission rate



345

Fault DescriptionFigure 16-1 shows network on which the subtending PPPoE users fail to access the Internet.

Figure 16-1 Network on which the subtending PPPoE users fail to access the Internet

CC08

A8010

Modem CModem B

Modem A

UA5000

UMG

Fault symptom:l Modem A and modem C connected to the UA5000 could normally communicate with each

other. It was found that the transmission rate was 2 kbit/s after many on-site tests, whichtook 33% of the total number tested. The normal rate was 40 kbit/s in other time period. Adialup test was directly performed on the MDF of the UA5000, it was found that the faultpersisted.

l When a Modem B was connected to the UMG, Modem B could communicate with ModemC normally. The rate was maintained at 40 kbit/s.

l A connection was set up between Modem A and Modem B and the communication wasnormal. The rate was maintained at 40 kbit/s.



The rate negotiation between devices was faulty.

Procedure

Step 1 The packet was captured on the uplink port of the UA5000. It was found that the UMG serversent two high speed negotiation signals to the UA5000, but Modem A stopped to respondingand the high speed signal was changed to a low speed signal. This indicated that the negotiationfailed.

Step 2 The UMG server considered the low-speed modem existed under the UA5000 before theUA5000 responded to the UMG server. Therefore the rate was directly switched to the low speedrate and the rate allowable in the low speed transmission mode was 2 kbit/s. The negotiation



346

mode was modified on the softswitch and the internet access code was configured. When modemA worked normally, the UMG server immediately negotiate with the modem about the modeminformation, ensuring that the UA5000 responded with the negotiation signal in time. Thus theratio of successful negotiation was improved and the problem was solved.

----End


TC-A0196 Absence of the Dial Tone on Certain User Phones Due to Hardware Faultin the A32 Board

This case describes the troubleshooting of absence of the dial tone on certain user phones dueto hardware fault in the A32 board.


Service abnormality

KeywordsAbnormal dialup

Board failure

Fault DescriptionFault symptom: The UA5000 was configured with the standalone transmission mode function.All the ports under the same UA5000 could normally communicate with each other, but thestatus of certain port of A32 board was in the idle status. No dial tone was played on the phoneconnected to this port.



l Slot faults.l The board was faulty.l Port faults

Procedure

Step 1 The A32 board in slot 0/29 was interchanged with the A32 board in slot 0/25. In this case, the0/29/13 port was normal, but no dial tone was played on the phone connected to the 0/25/13port. Therefore, it was confirmed that the slot was normal.



347

Step 2 Given that other ports on the faulty A32 board could dial up normally, it was determined thatthe whole board was normal.

Step 3 A circuit line test and subscriber line test were performed separately. The result showed thatboth the circuit line of A32 board in slot 0/25 and the circuit line of A32 board in slot 0/29 werenormal. However, it was found that the subscriber lines on the two boards were faulty and thesame fault existed. It was determined that the hardware of 14 port on slot 0/29 of the A32 boardwas faulty. The circuit test result was as follows:huawei(config-test)#pots circuit-test{ v5id<K>|mgid<K>|frameid/slotid/portid<S><1,15>|telno<K> }:mgid 0 terminalid 8397{ <cr>|busy<K> }:Command: pots circuit-test mgid 0 terminalid 8397 Frame 0 slot 29 port 13 ( telno 4608397 mgid 0 terminalid A8397 ) under testing, Please wait......UA5000(config-test)# Testing port: 0/29/13 Telno : 4608397 MGid : 0 Terminalid : A8397 ---------------------------------------------------------- Test item Result ---------------------------------------------------------- Off-hook Failure: testing timeout Dial tone Normal Receiving pulse Failure: testing timeout Receiving DTMF Normal Ring back tone Normal Busy tone Normal Feeder Normal Polarity reversal Not supported On-hook Failure: testing timeout Ringing Normal Stop ringing Normal Ringing current voltage(V) Normal (76.520) Feeder voltage (V) Abnormal (17.414) Loop current (mA) Abnormal (3.833) ----------------------------------------------------------

Step 4 After the hardware of 14 port on A32 board was repaired or the A32 board was replaced with anormal board, the dialing service at the 14 port returned to the normal state, and the fault wasrectified.

----End


None

TC-A0199 Blocking of the V5 Link After the Active/Standby Switchover on aUA5000 Due to a Protocol Interoperability Problem

This case describes the troubleshooting of a V5 link that was blocked after the active/standbyswitchover on a UA5000 due to a protocol interoperability problem.

Fault Type

Narrowband service

Service abnormality



348

KeywordsThe V5 protocol

Software parameters

Fault DescriptionNetwork topology: UA5000 ->switch

The UA5000 was interconnected with the softswitch of another vendor. The active and standbyPVM boards were interconnected with the softswitch through two E1 cables. During the test onthe active/standby switchover function on site, it was found that the V5 links were in the blockedstate.



l After the active/standby switchover, the quality of the 2M link was faulty.l The clock settings were incorrect. As a result, the clock source could not be traced after

active/standby switchoverl The protocol interpretability between the softswitch and UA5000 was abnormal.

Procedure

Step 1 The display port state command was executed to query the 2M link status after the active/standby switchover was performed on the control boards of the UA5000. It was found that the2M status is normal, and the CRC4 check was enabled, which were consistent with the settingsof the softswitch.

Step 2 The display clock source command was executed to query the configuration status of the clocksource. The clock sources were configured on the first E1 link of the active and standby boards,the priorities of the clock sources are 0 and 1 respectively, and the clock output is enabled. Itindicated that the clock configuration was correct and the clock source was in the normal state.

Step 3 The display v5-software parameters command was executed to query the software parametersof the V5 interface. It was found that V5 software parameter 8 was set to 0 by default, whichindicated that auto-unblocking was not supported.

NOTE

The definition of automatic unblocking function: The block/unblock of the subscriber port and link adoptthe principle of "The blocker is also the unblocker". That is, if the softswitch blocks the subscriber port or2 M link, only the softswitch can unblock it. If an access device sends the unblocking request, the softswitchwill reject the request. This process, however, may vary with different softswitches. The access networkdevice supports flexible processing. To allow the softswitches of other vendors not to stick to this process,V5 software parameter 8 must be set to 1.

Step 4 The v5-software parameters modify 8 1 command was executed to modify V5 softwareparameter. After that, the problem was solved.

----End



349

Suggestions and SummaryWhen the access device is interconnected with the softswitches of other vendors through the V5interface, note that the settings of the V5 interface software must correct.

TC-A0202 Call Failure in R2 Tests Due to the Failure of the UA5000 to Identify theMFD

This case describes the troubleshooting of a call failure in R2 tests because the UA5000 did notidentify the MFD.


Service abnormality

KeywordsPBX

Not Implemented

Fault DescriptionFigure 16-2

shows the network on which the call fails in R2 tests because the UA5000 does not identify theMFD.

Figure 16-2 Network on which the call fails in R2 tests because the UA5000 does not identifythe MFD

Phone A

UA5000

MGC

PBX

Phone B

Phone C

Fault symptom: In the preceding network topology, the PBX was provided by Siemens and theUA5000 and the MGC were provided by Huawei. After the configuration, call tests wereperformed. It was found that phone C connected to the UA5000 could call phone A and phoneB, whereas phone A and phone B failed to call phone C.



350



l The PBX was not configured correctly.l The MGC was not configured correctly.l The UA5000 was not configured correctly.l The line is faulty.

ProcedureStep 1 Phone A failed to call under the PBX. So, the packet capture tool was used to capture the dialing

packets. when the PBX called the UA5000, the softswitch sent the following information:

¡¡ã[10.3.131.20]:2944 T=406326979{C=-{MF=A62{E=402660939{mfd/*,bcas/cf,bcas/casf,r2/r2f}}}}!/1¡¡À then MSAN (10.3.131.100) sends:¡¡ã[10.3.131.100]:2944 P=406326979{C=-{MF=A62{ER=501{"Not Implemented"}}}}!/1

During packets checking, it was found that the UA5000 failed to parse "MFD/*"sent by theMGC. As a result, the UA5000 returned to the “Not Implemented" message.

Step 2 It was confirmed by the softswitch maintenance personnel that the MFD/*" cannot be deleted.

Step 3 The fault may be removed by modifying the UA5000 configurations. The UA5000 supportedthe R2 function. The following commands were used to modify the configuration of the UA5000so that the "MFD/*" was ignored and a call could be made.huawei(config)#diagnosehuawei(diagnose)%%profile modify 1 item-index item-index12 1huawei(config)#interface h248 0huawei(config-if-h248-0)#if-h248 attribute profile-index 1huawei(config-if-h248-0)#reset coldstartAre you sure to reset MG interface?(y/n)[n]:y

Step 4 After the configuration of the UA5000 was modified, the phones could call each other. That is,the fault was rectified.

----End


TC-A0203 Fax Abnormality of a User Connected to the UA5000 Due to a SignalingProblem of the Softswitch

The case describes the troubleshooting of fax abnormality of a user connected to the UA5000due to a signaling problem of the softswitch.




351

Service abnormality

Keywords

FoIP test in T.38 mode

T.38 m line description

Fault Description

Network topology: UA5000 -> softswitch

Fault symptom: The fax to the UA5000 was abnormal due to improper signaling of thesoftswitch.

Alarm Information

None

Cause Analysis


l The quality of the bearer network was poor.

l The signaling was not properly processed.

Procedure

Step 1 The UA5000 was logged in and the alarm history was checked. It was found that no QoS alarmwas generated, and the delay of pinging the signaling IP address was short. Therefore, the qualityof the bearer network was good.

Step 2 Certain signaling abnormality was found during the signaling tracing.T=442689773{C=39{MF=A26{M{TS{BF=OFF,fax/faxstate=Negotiating},O{MO=SR,tdmc/ec=Off}},E=442921055{fax/faxconnchange,al/on,al/fl}},MF=A100000842{M{ST=1{O{MO=SR,RV=OFF,RG=OFF,nt/jit=40,tdmc/ec=On},R{v=0o=HuaweiSoftX3000 21167519 21167520 IN IP4 10.26.100.13s=Sip Callc=IN IP4 10.26.100.69t=0 0m=image 5496 udptl t38 //The first description.a=T38MaxBitRate:14400a=T38FaxRateManagement:transferredTCFa=T38FaxUdpEC:t38UDPRedundancym=audio 0 RTP/AVP 8 0 //The second description. One session contains only one "m=" line.a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=ptime:20a=silenceSupp:off - - - -a=ecan:fb on -a=faxa=inactive}},TS{BF=OFF,ctyp/calltyp=Fax,ipfax/faxstate=Negotiating}}}}}

!/2 [10.27.214.5]:2944 ER=400{"Syntax error in message"} //The UA5000 returns a syntax error and the fax is terminated.



352

In the signaling, "m=image 5496 udptl t38 " indicated that the T.38 fax mode was adopted. The"m=audio 0 RTP/AVP 8 0" description was unnecessary. As a result, the UA5000 failed to parsethe message and thus returned "m=audio 0 RTP/AVP 8 0" message.

Step 3 After the signaling "m=audio 0 RTP/AVP 8 0" was deleted from the softswitch, the problemwas solved.

----End

Suggestions and SummaryAs defined in the H.248 Protocol, the stream descriptor is a single bi-directional media stream.Therefore, the description of a session contains only one media description, that is, only one"m=" line. A stream descriptor, however, can contain multiple session descriptions for variouschoices. Each media stream on a termination must be described in an independent streamdescriptor. Multiple session descriptions contained in a descriptor should be separated by the"v=" line. Otherwise, the "v=" line serves as an option.

TC-A0210 Severe Voice Packet Loss Under Two UA5000s Due to the ForwardingDefects in EPON Device

This case describes the troubleshooting of a severe voice packet loss on a UA5000 that wasconnected to an EPON device. The fault occurred due to the forwarding defects in the EPONdevice.


Service abnormality

KeywordsVoice fault

Services forwarding

Fault DescriptionNetwork topology: UA5000 (PVM)-> the EPON (F820)-> OLT-> switch (S7806)-> router(NE40)

Packets loss occurred when the gateway was pinged from the two UA5000 in a certain office.The packet loss rate reached 60%, resulting in poor voice quality. The voice service of otheroffices under the OLT was normal. The independent upstream mode was adopted on the UA5000and the network cable was connected to the FE port of the F820.





353

l The running environment (temperature, humidity) of the UA5000 was adverse.

l The negotiation mode of the UA5000 and F820 port were inconsistent.

l The upstream of the UA5000 was configured insufficiently.

l The network cable connected to the F820 was faulty.

l The EPON was configured incorrectly.

Procedure

Step 1 The site environment was checked. It was found that the environment, temperature, humidity,and power were abnormal. Therefore, the problem of the environment was excluded.

Step 2 The upward bandwidth of the UA5000 was configured correctly.

Step 3 The port configuration mode of the UA5000 was consistent with that of the F820, but the faultpersisted.

Step 4 After the network checking and the Ping packets changing, the loss of packets was still serious.

Step 5 After the on-site packets capturing and voice signaling analysis, it was found that the callerservice on the UA5000 was normal. It indicated that no packet loss occurred when the UA5000processed the data packets.

Step 6 Therefore the fault was caused by the EPON forwarding. The service returned to normal afterthe EPON data was reconfigured.

----End


Services on the devices connected to EPON devices are often unstable. During thetroubleshooting of such unstable services, the efficiency is sometimes very low with normaltroubleshooting methods. If it is confirmed that the devices are free from problems, performoperations on the EPON devices, including reconfiguring the service data and changing theservice VLAN and IP address.

TC-A0211 Services Abnormality After Power Restoration Due to the Mismatch ofthe PVMB Version and the VRSP Version

This case describes the troubleshooting of the service abnormality after a power restoration dueto the mismatch of the PVMB version and the VRSP version.

Fault Type

Narrowband service

Service abnormality

Keywords

Power failure

Restart



354

Fault Description

Certain offices were remote. The services were usually normal, but sometimes power-off lastedtwo or three days. As a result, the storage battery on the UA5000 was exhausted and device waspowered off. After the equipment room was powered on, the UA5000 failed to start normallyand the services were interrupted. However, the broadband MA5300 in the same room startednormally and the services were normal.

Alarm Information

None

Cause Analysis


l The service board was faulty.

l The version of the board was faulty.

l The communication between the PVM VRSP and the switch or the OLT failed, causingthe system reset.

Procedure

Step 1 After login to the device through the serial port, it was found that the device automaticallyrestarted after running for several minutes. After restart, the display version command wasexecuted to query the version documents, the system displayed the following information:huawei(config)#display version --------------------------------------- Pcb Version: VER.C Base Bios Version: 336 Extend Bios Version: 336 Software Version: PVMVRSP6140 CPLD Version: 198 Logic Version: 300 NOD Version: 100 Encrypt Nios Version: 100

Step 2 The version description documents were queried. It was found that the documents after upgradewas:huawei(config)#display version --------------------------------------- Pcb Version: VER.C Base Bios Version: 336 Extend Bios Version: 336 Software Version: PVMVRSP6140 CPLD Version: 198 Logic Version: 304 NOD Version: 10a Encrypt Nios Version: 101

Step 3 After comparing with the version description documents, it was found that the Logic document,NOD document and Encrypt Nios were normally loaded. The cause may be that only the programdocument was loaded during deployment. The communication was normal after the loading wascompleted, but the Logic document and Encrypt Nios were not loaded according to the versionconfiguration table. As a result, the device failed to reset after power failure due to versionmismatch.



355

Step 4 The document was re-loaded according to the version configuration table. After a power-off test,it was found that the device could restart normally. The fault was removed.

----End


The version configuration table must be strictly observed to re-load the software in thedeployment.

TC-A0212 Voice Service Disconnection on a UA5000 Due to L2 Isolation on theEPON Device

This case describes the troubleshooting of the voice service disconnection on a UA5000 due toL2 isolation on the EPON device.

Fault Type

Narrowband service

Service abnormality

Keywords

MA5680T

Gateway delivery

Fault Description

Network topology: The voice service was disconnected due to EPON L2 isolation, as shown inFigure 16-3.

Figure 16-3 Network topology: the voice service disconnection due to EPON L2 isolation

UA5000 A

MA5680T

Soft3000

UA5000 B

Fault symptom: The UA5000 could normally call the other numbers except the numbersconnected to the MA5680T, but phone call between two UA5000s failed.



356

Alarm Information

None

Cause Analysis


l The MA5680T was configured incorrectly.

l The ARP learning under the UA5000 was disabled.

Procedure

Step 1 The H248 signaling was analyzed, and it was found that the media stream was single. TheUA5000 at two ends failed to ping through each other.

Step 2 On the MA5680T, the L2 forwarding status was checked.MA5680T(config)#display epon vlan-isolate

It was found that the EPON L2 isolation was disabled.

Step 3 After L2 isolation function was enabled on the MA5680T, the two UA5000s can ping each other.Run the following command to query the above information:MA5680T(config)#epon vlan-isolate enable

----End


None

TC-A0214 Modem Deactivation During a Call

This case describes the troubleshooting of a modem that was deactivated during a call.

Fault Type

xDSL service

Service abnormality

Keyword

Internet access failure

Fault Description

The modem was deactivated when a user was on the phone or pressed the hookflash.

Alarm Information

None



357

Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The modem was faulty.l The line was faulty.

Procedure

Step 1 The modem was replaced. The fault, however, persisted. This indicated that the modem wasnormal.

Step 2 The same situation was emulated on the main distribution frame (MDF) on the user side. It wasfound that the modem was not deactivated. This indicated that the line from the device to theMDF was normal.

Step 3 It was determined that the cabling at the home of the user was faulty. The leading-in box at thehome of the user was checked. It was found that the white wire of the phone line was notconnected properly. That is, the grounding cable was not grounded properly. As a result, theADSL line was deactivated frequently.

Step 4 The phone line was connected properly. That is, the fault was rectified.

----End

Suggestions and SummaryIn this case, the modem was deactivated frequently when a phone was ringing or a user pressedthe hookflash. Therefore, it was determined that the cabling on the user side was not proper. Inthis case, check whether the cabling on the user side met the requirements.

TC-A0215 Low Internet Access Rate Due to a Virus-Infected PCThis case describes the troubleshooting of a low Internet access rate due to a virus-infectedpersonal computer (PC).


Service abnormality

KeywordLow Internet access rate

Fault DescriptionNetwork topology: PC -> modem -> UA5000 -> switch -> BRAS

The user accessed the Internet in ADSL mode but the Internet access rate was too low.




358

Cause Analysis

According to the fault symptom, the possible causes were as follows:

l The upper layer device was faulty.

l The subscriber line was faulty.

l The user PC was infected with viruses.

Procedure

Step 1 The user PC was used to download data. The download rate was only 4 kbit/s. A test PC wasconnected to the port on the upper layer switch, which was originally used to connect theUA5000, to download data. The download rate reached 8 Mbit/s.

Step 2 The test PC was connected to the Ethernet port on the UA5000 to download data. The downloadrate was close to 8 Mbit/s.

Step 3 The traffic of the faulty ADSL port on the UA5000 was checked. It was found that the upstreamand downstream traffic of the port was consistent with the upstream and downstream traffic ofthe upper layer network. This indicated that the communication between the UA5000 and theupper layer device was normal.

Step 4 The subscriber line and the modem were checked. It was found that they were normal.

Step 5 The user PC was checked. It was found that the PC was of high configuration and the networkinterface card was configured correctly. The antivirus software was used to check the user PC.More than 250 viruses were detected.

Step 6 The viruses were killed and the download rate reached 400 kbit/s. That is, the fault was rectified.

----End


In this case, after the PC was infected with viruses, the performance of the PC and its networkinterface card was reduced and a large amount of data failed to be processed. As a result, theInternet access rate was too low.

TC-A0216 Low Internet Access Rate Due to Inconsistent Hardware and SoftwareSettings of the Network Interface Card on a PC

This case describes the troubleshooting of a low Internet access rate due to inconsistent hardwareand software settings of the network interface card on a PC.

Fault Type

xDSL service

Service abnormality

Keyword

Low Internet access rate



359

Fault Description

The Internet access rate of an ADSL user was low. That is, the download rate was only about 1kbit/s. After the PC was reset multiple times, the fault, however, persisted.

Alarm Information

None

Cause Analysis



l The user PC was faulty, including the following problems:

– The PC was of low configuration.

– The operating system (OS) of the PC was faulty.

– The hardware and software settings of the network interface card were inconsistent.

Procedure

Step 1 The user PC was replaced for tests. It was found that the Internet access service was normal, thedownload rate was about 150 kbit/s, and the video on demand (VOD) service was smooth. Thisindicated that the upper layer device was normal.

Step 2 The user PC was checked.

1. The configuration of the PC was checked. It was found that the configuration met therequirements. This indicated that the configuration of the PC was normal.

2. The OS of the PC was checked. It was found that the OS was just reinstalled. This indicatedthat the OS of the PC was normal.

3. The hardware and software settings of the network interface card were checked. It wasfound that the network interface card was a new network interface card installed after theOS was reinstalled. The network interface card drive was not reinstalled because the modelof the new network interface card was the same as the model of the original networkinterface card.

NOTEThe rate of the new network interface card was set to 10/100 Mbit/s auto adaptation, whereas the rate ofthe network interface card configured in the OS of the PC was 10 Mbit/s. That is, the rate setting of thenetwork interface card in the OS was inconsistent with the rate of the network interface card.

4. The rate of the network interface card in the OS was changed to 10/100 Mbit/s and the PCwas reset. The Internet access and VOD services were normal.

----End


After replacing the hardware of a PC, update the drive or reconfigure the data in time. This canprevent the inconsistency between the settings of the new hardware and the settings of thesoftware.



360

TC-A0217 Static on the Line Due to a High-Frequency Interference Source

This case describes the troubleshooting of the static on the line due to a high-frequencyinterference source.

Fault Type

xDSL service

Service abnormality

Keyword

Poor voice quality

Fault Description

The Internet access service of an ADSL user was normal but serious static occurred on the linewhen the user was in a conversation.

Alarm Information

None

Cause Analysis


l The splitter was faulty.

l The phone was faulty.

l A high-frequency interference source existed around the line.

Procedure

Step 1 The splitter was replaced. The fault, however, persisted.

Step 2 The phone was replaced. The fault, however, persisted.

Step 3 A phone was connected to the main distribution frame (MDF) of the device. The static stillexisted. This indicated that the line from the MDF to the home of the user was normal.

Step 4 The ambient environment of the UA5000 was checked. It was found that a power supply cabinetexisted near the UA5000. It was hypothesized that the strong interference caused the static onthe line.

Step 5 A phone was directly connected to the board of the UA5000. It was found that the staticdisappeared. Therefore, it was determined that the interference of the power supply cabinetcaused the static on the line.

Step 6 The subscriber cables were moved to a position far from the power supply cabinet. Then, thestatic disappeared.

----End



361


Interference causes unstable line signals or signal distortion. Therefore, make sure that signalcables are separate from power supply cables in cable routing, thus preventing the interference.

TC-B4028 Static on the ADSL Line Due to Incorrect Wire Bonding of the MDF

This case describes the troubleshooting of the static on the ADSL line due to incorrect wirebonding of the main distribution frame (MDF).

Fault Type

xDSL service

Service abnormality

Keyword

Poor voice quality

Fault Description

The static occurred when a user was in a conversation. That is, when the user was not surfingon the Internet, the voice service was normal. When the user was in a conversation while surfingon the Internet, the static occurred on the line.

Alarm Information

None

Cause Analysis

According to the fault symptom, the possible causes were as follows:l The splitter was faulty.l The phone was faulty.l The line was faulty.

Procedure

Step 1 The splitter was replaced. The fault, however, persisted. This indicated that the splitter wasnormal.


Step 3 The connection of the drop cable was checked. It was found that the cable was connectedproperly.

Step 4 A wiring bonding test was performed on the vertical MDF. The fault, however, persisted.

Step 5 A wiring bonding test was performed on the ADSL horizontal terminal board. It was found thatthe Internet can be accessed but no call can be made. This indicated that low-frequency voicesignals were not transmitted. Then, it was determined that the wiring bonding was faulty.



362

Step 6 The wiring of the ADSL horizontal terminal board was checked. It was found that the jumperbetween the vertical MDF and the horizontal MDF of the original switch was not removed.

Step 7 The wires were connected properly. That is, the fault was rectified.

----End

Suggestions and SummaryIf the static exists on the line, interference signals must exist in voice signals. In this case,eliminate the interference signals.

TC-A0219 Frequent Service Interruptions Due to Improper Setting of the InterleaveDelay

This case describes the troubleshooting of frequent service interruptions due to improper settingof the interleave delay.


Service abnormality

KeywordFrequent interruptions

Fault DescriptionThe ADSL users of the UA5000 accessed the Internet through Point-to-Point Protocol overEthernet (PPPoE) or Point-to-Point Protocol over ATM (PPPoA). Services were frequentlyinterrupted. After a service interruption, the users dialed up again and could access the Internetquickly.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The modem was faulty.l The configurations of the upper layer broadband remote access server (BRAS) and the

UA5000 were incorrect.

Procedure

Step 1 The modem was checked. It was found that the modem was not deactivated after the faultoccurred. The modem was replaced. The fault, however, persisted.

Step 2 The CPU usage of the upper layer BRAS was checked. It was found that the CPU usage wasonly 19%, indicating that the fault was not caused by a high CPU usage of the BRAS.



363

Step 3 The data configuration of the UA5000 was checked. It was found that the port worked ininterleave mode and the interleave delay was 64 ms.

NOTE

During the monitoring process on the user side, it was found that regular jitter occurred on ping packets. Thatis, a ping packet was transmitted with a great delay after seven to eight ping packets were transmitted stably.

In PPPoE or PPPoA access mode, the BRAS sent a PPP ECHO packet to the client software periodically tocheck whether a PPP user existed. If there was no response after the PPP ECHO packet was retransmitted certaintimes, the BRAS stopped the service of the user.

According to the preceding analysis, the PPP ECHO packet sent by the BRAS to the client software was lostbecause the interleave delay was great. As a result, the BRAS stopped the service of the user.

Step 4 The interleave delay of the port was changed to 16 ms. Through monitoring, it was found thatthe service was not interrupted frequently.

Step 5 The interleave delay of the port was changed to 8 ms. Through long-time monitoring, it wasfound that the fault was rectified.

----End


The greater the interleave delay is, the more stable the ADSL2+ line is, but the longer thetransmission delay is. Therefore, change the interleave delay according to the actual condition.

TC-A0220 Internet Access Interruption Due to an IP Address Conflict of theGateway

This case describes the troubleshooting of an Internet access interruption due to an IP addressconflict of the gateway.

Fault Type

Ethernet service

Service abnormality

Keyword


Fault Description

Network topology: User -> UA5000 -> LAN switch -> router -> Internet

The UA5000 provided the Internet access service. A user accessed the Internet with a fixed IPaddress. When the Internet access service was interrupted, the user could ping the IP address ofthe gateway but failed to ping the IP address of the DNS server.

Alarm Information

None



364

Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l A port on the LAN switch was faulty.l The data configuration of the UA5000 was incorrect.l The upper layer device was faulty.

ProcedureStep 1 A PC was directly connected to a port on the LAN switch. It was found that the Internet access

was successful. This indicated that the port on the LAN switch was normal.

Step 2 The data configuration of the UA5000 was checked. It was found that the data configurationwas correct. Pinging the IP address of the gateway from the UA5000 was performed. It wasfound that packet loss occurred seriously.

Step 3 A router maintenance engineer was coordinated to check the data configuration of the router. Itwas found that the MAC address bound with the IP address of the gateway was incorrect.Therefore, it was determined that the fault was caused by the address conflict of the gateway.

Step 4 The network cable connecting the UA5000 and the LAN switch was removed on the UA5000side. Pinging the IP address of the gateway from the UA5000 was performed. It was found thatthe ping operation was still successful. The ADSL ports on the UA5000 were disabled one byone until pinging the IP address of the gateway from the UA5000 failed. It was found that theIP address of a PC is the same as the IP address of the gateway.

Step 5 The PC whose IP address was the same as the IP address gateway was isolated. The MAC addressbound with the gateway on the router was changed. Then, the user could access the Internet.

Step 6 The ADSL ports disabled in Step 4 were enabled. That is, the fault was rectified.

----End

Suggestions and SummaryPrevent IP address conflicts in data planning.

TC-A0221 Low Internet Access Rate Due to Too Many Network ProtocolsThis case describes the troubleshooting of a low Internet access rate due to too many networkprotocols configured for a user.


Service abnormality

KeywordInternet access failure

Fault DescriptionThe UA5000 provided the Internet access service. When the same traffic control policy wasused, the Internet access rate of a user connected to the Ethernet service board was low. That is,



365

the maximum Internet access rate of the user ranged from 5 Mbit/s to 6 Mbit/s. The maximumdownstream rate defined in the traffic profile was 10 Mbit/s.

Alarm Information

None

Cause Analysis


l The data configuration of the UA5000 was incorrect.

l The Ethernet service board was faulty.

l The user PC was faulty.

Procedure

Step 1 The data configuration of the UA5000 was checked and found to be correct. This indicated thatthe fault was not caused by the data configuration of the UA5000.

Step 2 The Internet access rates of other users connected to the same Ethernet service board werechecked and found to be normal. This indicated that the Ethernet service board was normal.

Step 3 A test PC was used and the Internet access rate of the user was checked and found to be normal.This indicated that the user PC was faulty.

Step 4 The user PC was checked. It was found that a large number of network protocols were configuredon the user PC. After unnecessary network protocols were deleted, the Internet access ratebecame normal.

----End


If too many network protocols are configured on a terminal, the Internet access rate becomeslow. Therefore, it is recommended that you configure only necessary network protocols whenconfiguring the terminal.

TC-A0222 Internet Access Failure Due to a VLAN Interconnection Problem

This case describes the troubleshooting of the Internet access failure due to a VLANinterconnection problem.

Fault Type

Ethernet service

Service abnormality

Keyword




366

Fault DescriptionNetwork topology: UA5000 -> LAN switch -> router -> Internet

After UA5000s were upgraded, the system configurations were modified. All the usersconnected to an UA5000 could not access the Internet.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The uplink port was faulty.l The interconnection was faulty.

ProcedureStep 1 The uplink port parameters of the UA5000 were checked. It was found that the uplink port

worked in auto negotiation mode and was activated. There were two VLANs. One was VLAN100 and the other, namely, the default VLAN, was VLAN 1.

Step 2 The configuration of the port on the LAN switch connected to the uplink port on the UA5000was checked. It was found that the VLAN list of the port did not include VLAN 100.

Step 3 According to the preceding check result, it was determined that the fault was caused by theVLAN interconnection between the UA5000 and the LAN switch. That is, after the Ethernetport on the UA5000 sent an Ethernet packet that carried the VLAN 100 tag to the LAN switch,the LAN switch discarded the packet.

Step 4 The UA5000 was logged in and the native VLAN ID of the uplink port was changed to 100 sothat the uplink data did not carry the VLAN tag. That is, the fault was rectified.

----End

Suggestions and SummaryIf all the users connected to an UA5000 cannot access the Internet, the interconnection of theuplink port may be faulty.

TC-A0226 Dialup Failure of a PPP User Due to Inconsistent Encapsulation ModesThis case describes the troubleshooting of the dialup failure of a Point-to-Point Protocol (PPP)user due to inconsistent encapsulation modes.


Service abnormality




367

Fault Description

A user connected to the UA5000 failed to access the Internet through Point-to-Point Protocolover ATM (PPPoA) dialup.

Alarm Information

None

Cause Analysis


l The communication between the UA5000 and the broadband remote access server (BRAS)was faulty.


l The modem was faulty.

Procedure

Step 1 The connection between the UA5000 and the BRAS was checked. It was found that theconnection was normal.

Step 2 The configuration of the UA5000 was checked. It was found that the PPPoA was enabled,VLANs and service ports were configured correctly, no static MAC address was configured, themaximum number of learnt MAC addresses was 255 (the default value), a MAC address poolwas configured and the capacity of the MAC address pool was sufficient, and the encapsulationmode was LLC_BRIDGE. This indicated that the data configuration was correct.

Step 3 The modem configuration was checked. It was found that the encapsulation mode was LLC_PPP,which was different from the encapsulation mode on the UA5000.

Step 4 The encapsulation mode on the UA5000 was changed to LLC_PPP, which was the same as theencapsulation mode on the modem. The user dialed up again. Then, the dialup was successful.

----End


This fault was caused by the inconsistency between the encapsulation mode on the modem andthe encapsulation mode on the UA5000.

TC-A0227 Dialup Failure of a PPP User Due to a Static MAC Address

This case describes the troubleshooting of the dialup failure of a Point-to-Point Protocol (PPP)user due to a static MAC address.

Fault Type

Ethernet service

Service abnormality



368

Keyword


Fault Description

A user connected to the UA5000 failed to access the Internet through PPP dialup. When thedialup failed, packets were captured on the user side. It was found that the user sent PPPoEActive Discovery Initiation (PADI) packets but did not receive PPPoE Active Discovery Offer(PADO) packets.

Alarm Information

None

Cause Analysis


l The communication between the UA5000 and the broadband remote access server (BRAS)was faulty.


Procedure


Step 2 The configuration of the UA5000 was checked. It was found that the user was connected to port0/7/2 but the MAC address bound to the user was not the MAC address of port 0/7/2. The MACaddress bound to the user was the static MAC address configured on port 0/11/5.

NOTEAfter receiving PADO packets sent from the BRAS, the UA5000 sent the PADO packets to port 0/11/5, ratherthan port 0/7/2, because the destination MAC address of the PADO packets was the static MAC addressconfigured on port 0/11/5. As a result, port 0/7/2 did not receive the PADO packets. Accordingly, the dialup ofthe user failed.

Step 3 The static MAC address configured on port 0/11/5 was deleted and the user dialed up again.Then, the dialup was successful.

----End


When configuring a static MAC address, make sure that the configured port is the same as theport used in dialup.

TC-A0247 One-Way Audio on Pay Phone Due to A32 Board Port Not SupportingPolarity Reversal

This case describes how to troubleshoot the one-way audio on the pay phone because the A32board port does not support polarity reversal.



369

Fault Type

Narrowband service

Service abnormality

Keywords

CC-HASL

Fault Description

l During the interconnection test for the UA5000 and Iskratel SI2000, it is found that one-way audio occurs when a pay phone is connected to the A32 board of the UA5000. In thiscase, the pay phone user can hear the voice of the peer party but the peer party cannot hearthe voice of the pay phone user. In addition, the call charge on the pay phone is not deducted.

l The services operate normally when common phones are connected to these A32 boardports. In addition, if the A32 board is connected to the C&C08 switch, the pay phoneconnected to the board will not encounter this fault.

l The type of the A32 board is CC-HASL (03039717).

l The type of the pay phone is TMS-1517K4.

Alarm Information

No alarm is generated in this case.

Cause Analysis


l The pay phone is faulty.

l Certain ports on the A32 board do not support polarity reversal.

Procedure

Step 1 Replace the pay phone to test the service. It is found that the fault persists. In addition, giventhat the service is normal when the pay phone is connected to the C&C08 switch, it can bedetermined that the fault is not caused by pay phone problems.

Step 2 Further analyze the pay phone connection conditions. It is found that the pay phonecommunicating with the service board of C&C08 switch is connected to port 15; whereas thetested port on the UA5000 is always port 8. Connect the pay phone to port 15, given that onlyports 15 and 16 on the A32 board support polarity reversal.

Step 3 Run the pstnport attribute batset and pstnport reversepole_pulse batset commands toconfigure the polarity reversal function on the port. Then, perform the test again. It is found thatthe pay phone works normally. The specific configuration commands are as follows:huawei(config)#pstnport attribute batset 0/20/15 0/20/16 polarity-reverse Supporthuawei(config)#pstnport reversepole_pulse batset 0/20/15 0/20/16 300 enable

----End



370

Suggestions and SummaryCertain pay phone can work normally only when being connected to a port that supports polarityreversal. When a fault occurs in the pay phone service, check whether the connected A32 boardport supports polarity reversal.

TC-A0248 IUA Link Activation Failure Due to Incorrect Configuration of IUA LinkWork Mode

This case describes how to troubleshoot the failure to activate the IUA link because the IUAlink work mode is configured incorrectly.


Service abnormality

KeywordsLoad sharing

ISDN

Fault DescriptionA UA5000 uses the H.248 protocol. After the IUA link set and associated IUA link data isconfigured, the IUA link cannot be activated and the ISDN service cannot be provided.


Cause AnalysisThe possible causes are as follows:l The network between the UA5000 and the softswitch is faulty and therefore the two parties

cannot send messages to each other.l The basic IUA interconnection parameters set on the UA5000 and the softswitch are

inconsistent.l The settings of the IUA running parameters on the UA5000 are incorrect.

Procedure

Step 1 Ping the UA5000 and softswitch from each other. It is found that the two devices cancommunicate with each other normally without packet loss, and that the common voice serviceoperates normally. This indicates that the network between the two devices is normal.

Step 2 Check for the softswitch IP address, local IP address, softswitch IUA port ID, and local port IDmultiple times. It is found that the settings of interconnection parameters are correct.

Step 3 Run the display iua-linkset attribute command in sigtran mode to query the basic informationabout the IUA link. It is found that the IUA link set works in the override (active/standby) mode.



371

Comparably, the IUA links on a normal UA5000 (V100R013) connected to the same softswitchwork in the load sharing mode.

Step 4 Run the iua-linkset add command to change the work mode of the IUA link set to load sharing.It is found that the IUA link can be activated successfully.

----End


The default work mode of the IUA link set on the UA5000 PVM V100R013 is load sharing;whereas the default mode on the UA5000 PVM V100R017 is override. In practice, the workmode of the IUA link set needs to be correctly set according to the application requirements.

TC-A0249 Error 676 in Modem Dialup Service Through UA5000 Due to Non-Standard Signaling Sent by Softswitch

This case describes how to troubleshoot error 676 that is displayed in the narrowband modemdialup service provided through the UA5000. The fault is caused by non-standard signaling sentby the softswitch.

Fault Type

Narrowband service

Service abnormality

Keywords

Internet access through dialup

Fault Description

Network topology: UA5000 (PVMV100R013C03B032) -> softswitch -> BRAS

Fault symptom: In the narrowband modem dialup service through an UA5000, error 676 isdisplayed during dialup.

Alarm Information


Cause Analysis


l The user terminal is faulty.

l The number of IP addresses in the IP address pool of the BRAS is insufficient.

l The UA5000 interconnects with the softswitch incorrectly.



372

Procedure

Step 1 Perform the dialup test on other access devices connected to the same softswitch. It is found thatall the tests are successfully, indicating that the fault is not caused by user terminal problems.

Step 2 Given that only one account is used for test, it can be determined that the fault is not caused bythe insufficiency of the IP addresses in the IP address pool of the BRAS.

Step 3 Capture mirrored packets. The captured signaling is as follows:IER=.#@#!/2 [10.35.64.3]:2944 T=2441211895{C=${A=USER134,A=${M{ST=1{O{MO=RC,nt/jit=0,diffserv/dscp=1},L{.v=0.c=IN IP4 $.m=audio $ RTP/AVP 8.a=ptime:10.a=X-ChannelAttr:1.}}},E=2441764301{nt/netfail,nt/qualert{th=80}}}}}

Step 4 It is found that the softswitch issues two non-standard identifiers, namely diffserv/dscp=1 anda=X-ChannelAttr:1, and that the UA5000 responds to the softswitch with a "Unsupported orunknown Package" message. Remove the two identifiers from the softswitch. It is found thatthe dialup for Internet access through the UA5000 is successful.

----End

Suggestions and SummaryWhen such a fault occurs, capturing signaling is a good way to improve the fault locationefficiency.

TC-A0250 Subscriber Line Test Failures on Subtending Subrack Ports Due toIncorrect Configuration

This case describes how to troubleshoot subscriber line test failures on user ports in aUA5000′s subtending subrack due to an incorrect system configuration.


Other

KeywordTSS board

Fault DescriptionThe UA5000 is equipped with a master subrack and a subtending subrack. A TSS board isconfigured in the master subrack but is not configured in the subtending subrack. When asubscriber line test is performed on the user ports in the subtending subrack, the system displaysa message indicating that the test board cannot be found.


Cause Analysisl The data configuration of the TSS board is incorrect.



373

l The test group configuration of the system is incorrect.

Procedure

Step 1 Perform a subscriber line test on a user port in the master subrack. The test is successful,indicating that the data configuration of the TSS board is correct.

Step 2 Run the display testgroup command in test mode to query the test group configured for themaster subrack, and run the display frame info command in global config mode to query thetest group configured for the subtending subrack. It is found that the master subrack andsubtending subrack are configured in two different test groups.

Step 3 Run the frame set command to add the subtending subrack into the master subrack′s test group,and then perform a subscriber line test on a user port in the subtending subrack. It is found thatthe fault is rectified.

----End

Suggestion and SummaryWhen the UA5000 is equipped with a subtending subrack, the master subrack and the subtendingsubrack use the same test bus and, therefore, the same TSS board. It is not necessary to configureanother TSS board for the subtending subrack, but the two subracks must be configured in thesame test group.

TC-A0252 VLAN Stacking Service Failure Due to Unmatched Protocol TypesThis case describes how to troubleshoot a virtual local area network (VLAN) stacking servicefailure on the UA5000, which is caused by the unmatched Ethernet protocol types of the inner-layer VLANs configured on the UA5000 and on the optical line terminal (OLT), the UA5000'supper layer device.


Ethernet service

KeywordsVLAN stacking

VLAN tag

Fault DescriptionNetwork topology: UA5000 -> OLT -> switch -> router

Fault symptom: The single-VLAN services on the UA5000 on a site operate properly, but theVLAN stacking service, a double-VLAN service, fails.




374

Cause Analysisl The upstream link is faulty.l The upper layer device is faulty.l The data configuration on the UA5000 used to connect to the OLT is incorrect.

Procedure

Step 1 Check whether the affected UA5000 can be managed by the network management system(NMS). It is found that the UA5000 is in the managed device list on the NMS, indicating thatthe upstream link of the UA5000 is normal.

Step 2 Check the UA5000, OLT, and switch for the MAC addresses of subscribers connected to theUA5000. It is found that these devices can learn subscribers' MAC addresses successfully.

Step 3 Check for the MAC address of the broadband remote access server (BRAS) on the OLT and theswitch. It is found that the OLT and the switch can learn the BRAS' MAC address successfully.

Step 4 Check the external VLAN tags on other UA5000s connected to the same OLT. It is found thatthey are the same as the external VLAN tag on the affected UA5000, indicating that the fault isnot on the OLT but on the affected UA5000.

Step 5 Change the external VLAN tag on the affected UA5000 to another value, and then performanother test. It is found that the fault persists.

Step 6 Change the VLAN configuration on the affected UA5000 to single-VLAN configuration, andthen perform another test. It is found that the services on the UA5000 return to normal.

Step 7 Check the Ethernet protocol type of the inner-layer VLAN configured on the OLT. It is foundthat the type is 0x8100, whereas the type configured on the affected UA5000 is 0x7a.

Step 8 Run the stacking inner-ethertype command to change the Ethernet protocol type of the inner-layer VLAN configured on the UA5000 to 0x8100, and then perform another test. It is foundthat the fault is rectified.

----End

Suggestion and SummaryThe inner- and outer-layer Ethernet protocol types configured on the UA5000 only take effecton double-VLAN services and do not affect single-VLAN services. Note that the Ethernetprotocol types of the inner- and outer-layer VLANs configured on the UA5000 must be the sameas those configured on the upper layer device.

TC-A0254 H.248 Interface Failure Due to Conflict Between Outband NetworkManagement and Signaling IP Addresses

This case describes how to troubleshoot a failure of the H.248 interface on a UA5000, which iscaused by a conflict between the UA5000's outband management and signaling IP addresses.


Narrowband service



375

Keywords

Maintenance network port

MG interface IP address

Fault Description


The affected UA5000 is configured with two H601PVMD control boards (active and standby)and communicates with the network management system (NMS) in outband mode. Whennetwork cables are connected to the uplink network ports and outband network ports on boththe PVMD control boards, the H.248 interface on the UA5000 fails.

When a user disconnects the network cables from the four ports on the two PVMD control boardsand inserts a network cable into the uplink network port on one PVMD control board, the H.248interface recovers. Then, the user inserts the remaining three network cables into thecorresponding ports. It is found that the outband network ports and uplink network ports on thetwo control boards are working properly. If the user resets the UA5000, however, the H.248interface fails again. After performing the preceding operations again, the H.248 interfacerecovers.

Alarm Information


Cause Analysisl The upstream link is faulty.l The hardware of the control boards is faulty.l The data configuration on the UA5000 is incorrect.

Procedure

Step 1 Run the display uplink tps state command to query the operating status of the service networkports on the two control boards. It is found that the service network ports on both the active andstandby control boards are enabled to transmit data upstream.

Step 2 Replace the network cables connected to the service network ports. It is found that the faultpersists.

Step 3 Run the system switch-over command to perform an active/standby switchover. It is found thatthe fault persists.

Step 4 Analyze the data configuration on the UA5000. The UA5000 uses two service network portsand two outband network management ports for data transmission and NMS communication.The IP addresses of the outband network management ports are in the same network segmentas the signaling IP address of the H.248 interface. Because of this, the H.248 messages are sentto the outband network management ports instead of being sent to the service network ports. Asa result, the H.248 interface cannot negotiate parameters with the media gateway (MG) interface.

Step 5 Run the undo ip address command to delete the IP addresses of the outband networkmanagement ports, run the sysman mode inband command to change the network management



376

mode of the UA5000 to inband mode, and then run the ip address command to configure an IPaddress for the inband network management port. It is found that the fault is rectified.

----End


When a UA5000 uses two service network ports and two outband network management portsfor data transmission and NMS communication, the parameter negotiation between the H.248interface and the MG interface will fail if the IP address of the UA5000's outband network portsare in the same network segment as the signaling IP address of the H.248 interface. To preventthis problem, configure the preceding IP addresses in different network segments or use theinband network management mode.

TC-A0256 Frequent Internet Access Failures Due to Too Many Broadcast Packetson the Network

This case describes how to troubleshoot frequent Internet access failures due to too manybroadcast packets on the network.

Fault Type

Service abnormality

Ethernet service

Keywords

Jitter

Fault Description

Network topology: PC -> UA5000 -> OLT -> switch -> BRAS -> Internet

Broadband subscribers connected to a UA5000 are often forced offline when browsing Webpages. It is found that the delay is long, jitter is serious, and packets are lost when subscribersping certain Web sites.

Alarm Information


Cause Analysisl The Web sites themselves are the source of the problem.

l The upper layer network of the optical line terminal (OLT) has some problems.

l The UA5000 forwards packets incorrectly.

l There are too many broadcast packets on the network.



377

Procedure

Step 1 Given that the leased line service subscribers can access these Web sites successfully and browseWeb pages without any Internet failures, the Web sites are operating properly.

Step 2 Check the services on other broadband access devices connected to the same OLT as theUA5000. It is found that the services are operating properly, indicating that the upper layernetwork of the OLT is operating properly.

Step 3 Create VLAN a, which contains subscribers connected to the UA5000, on the OLT, andconfigure for the new VLAN an IP address that is in the same network segment as the IPaddresses of UA5000 subscribers. Then, run the interface vlanif command on the UA5000 tocreate a Layer 3 interface, and then ping the IP address of the OLT. It is found that there aredelays and jitters.

Step 4 Perform a loopback test on a user port on the UA5000, and then run the atm-ping command. Itis found that there are delays and jitters, indicating that the fault may be on the UA5000.

Step 5 Run the display traffic F/S/P command to query the real-time traffic on a user port on theUA5000. It is found that the traffic on the port occasionally increases suddenly to reach or exceedthe activation rate.

Step 6 Capture packets on a user port on the UA5000. A large number of broadcast packets are foundin the captured packets, indicating that the fault may be caused by the broadcast packets.

Step 7 Run the traffic-suppress all broadcast value 13 command to enable the broadcast packetsuppression function on the uplink port on the UA5000. It is found that the Internet access failuresstop.

Step 8 Check the VLAN configurations on the UA5000. It is found that many subscribers are configuredin the same VLAN, causing a large number of broadcast packets, which have occupied thebandwidth on the subscriber side. As a result, the interaction packets between the subscriber andthe BRAS are discarded, causing the subscriber offline.

Step 9 Modify the data configurations on the VLAN and assign one subscriber to each VLAN. It isfound that the fault is rectified.

----End

Suggestion and SummaryWhen the broadcast traffic suppression function is enabled on a device, the device will notforward broadcast packets on the network. This function, however, cannot be enabled when adevice is only operating broadcast interaction services, such as the Dynamic Host ConfigurationProtocol (DHCP) service.

TC-A0259 Busy Tones Occasionally Heard After Dialing Due to Incorrect RTPValue Range

This case describes how to troubleshoot the busy tones heard by the calling parties connectedto a UA5000 after dialing numbers. The fault is caused by the incorrect range of Real-TimeTransport Protocol (RTP) values set on the UA5000.




378

Narrowband service

KeywordsBusy tone after offhook

Temporary terminal

RTP terminal

Fault DescriptionThe UA5000, which functions as an access gateway (AG), is connected to a softswitch on a site.The subscribers connected to the AG occasionally hear busy tones after dialing numbers, andtherefore the called parties cannot be connected to.


Cause AnalysisThe RTP resources allocated by the AG to the softswitch are not configured on the softswitch.In such a case, the softswitch sends a busy tone signal to the AG after the AG allocates the RTPresources to the softswitch.

Procedure

Step 1 Trace signals transmitted between the AG and the softswitch. It is found that when an exceptionoccurs in the call process, the softswitch has sent an Add command to the AG requiring the AGto add a context and a temporary terminal. Then, the AG adds an RTP terminal (temporaryterminal) ID A100000100. Given that the RTP terminal IDs configured on the softswitch rangefrom A10000000 to A100000099, the softswitch sends a busy tone to the AG in this case becauseit cannot identify RTP terminal ID A100000100.

Step 2 Run the display tid-format command to check the terminal prefixes and terminal ID (TID)profiles currently used by each type of terminals connected to the media gateway (MG) interface.It is found that the RTP terminal is using the TID profile whose index is 1.

Step 3 Run the display tid-template command to query the information about TID profile 1. It is foundthat the temporary terminal resource that can be allocated by the AG is R+100000001. Therefore,the temporary terminals that can be allocated by the AG range from A100000001 toA100000100, because the maximum RTP terminal ID configured in the system is 99. This meansthat the AG may allocate temporary terminal ID A100000100, which is, however, not supportedby the softswitch. That is, when the AG allocates temporary terminal ID A100000100, a servicefailure occurs.

Step 4 Run the tid-template add 32 command to add TID profile with index 32, and set RTP terminalresource to R+100000000.

Step 5 Shut down the MG interface, and then run the tid-format rtp template 32 command to configureTID profile 32 for RTP terminals so that the RTP terminal IDs on the AG range fromA100000000 to A100000099. It is found that the fault is rectified after the MG interface is reset.

----End



379


There are two types of terminals in an H.248 call process.

l Physical terminals, which are identified by terminal IDs in signal interaction. Each voiceservice port on a UA5000 is configured with a fixed terminal ID.

l Temporary terminals, namely RTP terminals, which are identified by RTP terminal IDsconfigured on the UA5000. When establishing a call, the system randomly selects an IDfrom the configured ID range and allocates it to an RTP terminal. After the call is complete,the system releases this terminal ID for subsequent calls.

TC-A0260 Ringing Tone Absence Due to Incorrect Connection of SubscriberCables to the Backplane

This case describes how to troubleshoot the ringing tone absence due to incorrect connection ofsubscriber cables to the backplane connecting to an A32 board.

Fault Type

Service abnormality

Narrowband service

Keywords

A32 board

Header

Pin row

Fault Description

Network topology: UA5000 -> LAN switch -> SoftX3000

Fault symptom: New UA5000 subscribers can communicate as both the calling party and thecalled party, but no ringing tone is played for the called party.

Alarm Information


Cause Analysisl The data configuration on the UA5000 is incorrect.

l The A32 board is faulty.

l The power board is faulty.

l The subscriber line is short-circuited.

l Some cables seated in the main distribution frame (MDF) are crossed.

l The connection of subscriber cables to the backplane is incorrect.



380

Procedure

Step 1 Check whether the data configuration on the UA5000 is correct. It is found that the calling partyand the called party can communicate with each other and only several subscribers encounterthis fault. This indicates that the data configuration on the UA5000 is correct.

Step 2 Cut over the subscribers to the last 16 ports on the A32 board. It is found that the fault persists.Cut over the subscribers to another A32 board. It is found that the fault disappears.

Step 3 Replace the A32 board and then perform a test. It is found that the fault persists, indicating thatthe A32 board is normal.

Step 4 Check the power board. It is found that the power board is normal.

Step 5 Disconnect the subscriber line, connect the phone to the faulty port on the A32 board, and thenperform a test. It is found that the fault persists, indicating that the fault is not caused by thesubscriber line.

Step 6 Check whether cables are seated in the MDF correctly, for example, no cable is crossed. Thecables are seated correctly.

Step 7 Check the subscriber cables connected to the backplane connecting to the A32 board. It is foundthat the subscriber cables are incorrectly connected to the backplane. That is, the first 16-channelPOTS signals are not distributed on the first 16 rows (from row 1 to row 16) of pins on theheader. Connect the subscriber cables correctly and perform a test. It is found that the fault isrectified.

----End

Suggestions and Summaryl The first 16-channel POTS signals from the A32 board are distributed on the first 16 rows

of pins on the header.

l The last 16-channel POTS signals from the A32 board are distributed on the last 16 rows(from row 17 to row 32) of pins on the header.

TC-A0261 Multicast Service Failure Due to Insufficient Bandwidth Allocated toUsers

This case describes how to troubleshoot the multicast service failure due to insufficientbandwidth allocated to users.

Fault Type

Service abnormality

Multicast service

Keywords

Order

Program bandwidth



381

Fault DescriptionAfter the multicast service in Internet Group Management Protocol (IGMP) proxy mode isconfigured on the UA5000, the video on demand (VoD) service is normal whereas the multicastservice fails.


Cause Analysisl The data configuration on the UA5000 is incorrect.l The bandwidth allocated to the user is insufficient.l The set top box (STB) or the terminal is faulty.

ProcedureStep 1 Check the multicast service configuration. It is found that the configuration is correct. The

bandwidth in the line profile bound to the user is 4 Mbit/s and the traffic is not restricted.

Step 2 The affected user terminal is connected to another device. It is found that the multicast serviceis normal indicating that the user terminal is normal.

Step 3 Run the debugging igmp, terminal monitor, and terminal debugging commands to debug themulticast service. It is found that the system reports the "Warning: the user fails to pass bandwidthCAC" message, indicating that the fault is caused by CAC bandwidth restriction.

Step 4 Run the igmp bandwidthCAC disable command to disable the call admission control (CAC)bandwidth management function. It is found that the multicast programs can be played, butblurry images are displayed. It is suspected that the bandwidth allocated to the user is insufficient.

Step 5 Modify the line profile bound to the user by increasing the bandwidth for the user, and run theigmp bandwidthCAC enable command to enable the CAC bandwidth management function.It is found that the fault is rectified.

----End

Suggestions and SummaryThe bandwidth management principles for the uplink port and user port are the same. That is,the total bandwidth for programs (the total bandwidth for programs indicates the configuredprogram bandwidth instead of the bandwidth obtained based on actual program traffic) isrestricted based on the proportion of bandwidth allocated to multicast programs on the uplinkport, total bandwidth for the port, and calculated bandwidth allocated to the multicast service.

l If the bandwidth allocated to the multicast service is greater than the total in-use bandwidth,the current programs are not affected. When a program is added, the system compares theprogram's bandwidth with the remaining bandwidth for the port. If the program's bandwidthis greater than the remaining bandwidth for the port, the program cannot be added.Otherwise, the program can be added.

l If the allocated bandwidth for the multicast service is smaller than the total in-usebandwidth, the system automatically accumulates the bandwidth configured for eachmulticast program based on program indexes in ascending order to preferentially ensurethe bandwidth for the program with smaller index and forces the program with greater index



382

to go offline until the in-use bandwidth for the multicast service on the uplink port or userport is equal to or greater than its allocated bandwidth.

TC-A0262 Abnormal Dial Tone Due to Incorrect E1 Cable Connection Between theRSU and the PVM and EDTB Boards

This case describes how to troubleshoot the abnormal dial tone due to incorrect E1 cableconnection between the RSU and the PVM and EDTB boards.


Narrowband service

KeywordsIncorrect cable seating

Ring back tone absence

Fault Descriptionl The master subrack on the UA5000 is cascaded with seven RSU slave subracks. The PVMB

and EDTB boards on the UA5000 are connected to RSUs through E1 cables.l Some users cannot hear the dial tone after cutover.


Cause Analysisl The service board is faulty.l The power board is faulty.l E1 cables are incorrectly connected.

Procedure

Step 1 The fault occurs on an RSU subrack and the affected numbers are dispersed. Therefore, there isa low probability that a large number of boards are faulty at the same time. Replace serviceboards in the faulty RSU subrack and perform a test. It is found that the fault persists.

Step 2 Check the power board. It is found that the power board works properly and no power alarm isgenerated. Replace the power board and perform a test. It is found that the fault persists.

Step 3 Delete the E1 cable configuration on the faulty subrack and keep the cable configuration on onlyE1 port 0 on the control board in the RSU subrack. Then, perform a dialup test multiple times.It is found that the fault disappears.

Step 4 Configure E1 cables one by one for the RSU subrack and perform a dialup test. After an E1cable is tested normal, delete its configuration and then configure another E1 cable and performa dialup test. The test result shows that the fault is caused by the lines crossed due to incorrectE1 cable seating.



383

Step 5 Use a blocker to block the cables connected to the digital distribution frame (DDF) one by oneto locate the fault and then seat the cables based on the test result. The fault is rectified.

----End

Suggestions and Summaryl Seat cables according to the data plan during deployment.

l The engineer is recommended to use the blocker to check the line before the cutover toensure that the E1 cable connection is consistent with the data configuration.

l Do not block E1 port 0 on the control board in the RSU subrack when checking the deviceson the live network. Otherwise, the services on the entire subrack are interrupted.

TC-A0263 Ringing Tone Absence for the Called Party Due to Some Port Faults onthe CSRB Board

This case describes how to troubleshoot ringing tone absence for the called party due to someport faults on the CSRB board.

Fault Type

Service abnormality

Narrowband service

Keywords

Ringing tone absence for the called party

Fault Descriptionl The master subrack on the UA5000 is cascaded with seven RSU slave subracks and is

configured with CSRB and A32 boards. The PVMB and EDTB boards on the UA5000 areconnected to RSUs through E1 cables.

l When the numbers of some phones under the same CSRB board are dialed, no ringing toneis played, but the called parties can communicate with the calling party after taking thephone off the hook.

Alarm Information


Cause Analysisl The E1 cable connection between the RSU and the PVMB and EDTB boards is incorrect.


l The CSRB board is faulty.



384

Procedure

Step 1 Check the E1 cable connection between the RSU and the PVMB and EDTB boards. It is foundthat the connection is consistent with the data configuration, indicating that the connection iscorrect.

Step 2 Check the power board. It is found that the power board works properly and no power alarm isgenerated.

Step 3 Replace the power board and perform a test. It is found that the fault persists.

Step 4 Perform a circuit line test a port on the CSRB board. When the circuit line test is performed onthe faulty port, Ringing is Abnormal, indicating that the port is faulty. Replace the CSRB boardand dial the phone numbers. It is found that the ringing tone is played and the fault is rectified.

----End

Suggestions and SummaryPerform a circuit test to detect board hardware faults. In the case of no dial tone or abnormaldial tone on the port, perform a circuit or subscriber line test to accurately and rapidly locatefaults.

TC-A0265 Failure in Concurrent Ringing of Fixed-Line and PHS Phones Due to anUnsupported Parameter Issued by the Softswitch

This case describes how to troubleshoot the failures in concurrently playing ringing tones for afixed-line phone and a personal handyphone system (PHS) phone due to an unsupportedparameter issued by the softswitch.


Narrowband service

KeywordsConcurrent ringing of a fixed-line phone and PHS phone with the same number

No ringing tone

Fault DescriptionNetwork topology: fixed-line phone -> UA5000 -> softswitch

The UA5000 provides subscribers with a fixed-line and PHS phone concurrent ringing service.That is, the fixed-line phone and the PHS phone use the same number, and they ring at the sametime when this number is called. The subscribers complain that the fixed-line phone occasionallydoes not ring while the PHS phone rings sometimes.




385

Cause Analysisl The fixed-line phone or the PHS phone is faulty.l The service board is faulty.l The PWX board is faulty.l The softswitch is faulty.

Procedure

Step 1 Perform dialing tests on multiple in-service fixed-line phones and PHS phones. It is found thatthe fault persists.

Step 2 Move the affected user port to the service board in another slot. It is found that the fault persists,indicating that the original service board is normal.

Step 3 Check the fault reporting record. It is found that this fault did not occur on the subscribers usingother common call services, indicating that the PWX board is normal.

Step 4 Trace the H.248 signaling. It is found that the fault occurs because the access gateway (AG)responds to the softswitch with the "internal software failure in the MG" message after thesoftswitch issues a modify command.

Step 5 Analyze the H.248 signaling. It is found that the modify command issued by the softswitchcontains the "a=rtpmap:101 AMR/8000" code that is not supported by the AG. Then, thesoftswitch configuration is modified to ensure that it does not issue this code, and dialing testsare performed on the affected port multiple times. It is found that the fault is rectified.

NOTE

AMR/8000 is mobile codec.

----End


No suggestion or summary for this case.

TC-A0266 Unknown Multicast Service Failure Due to Enabled Unknown MulticastSuppression Function

This case describes how to troubleshoot the unknown multicast service failure due to enabledunknown multicast suppression function.

Fault Type

Service abnormality

Multicast service

Keywords

Traffic suppression

STB



386

Fault DescriptionThe UA5000 on a site provides ADSL users with an unknown multicast service. The service isnot configured with any Group Management Protocol (IGMP) parameters so that the UA5000transparently transmits the multicast packets. It is found that the ADSL users fail to watchprograms using set top boxes (STBs).


Cause Analysisl The link between the UA5000 and the video on demand (VoD) server is disconnected.l The STB is faulty.l The multicast service configuration on the UA5000 is incorrect.

Procedure

Step 1 Ping the VoD server from the UA5000. It is found that this operation is successful, indicatingthat the link between the UA5000 and the VoD server is normal.

Step 2 Replace the STB with the variable-length coding (VLC) player on the PC to order programs. itis found that the fault persists.

Step 3 Start the packet capturing tool on the PC. It is found that the STB has already sent an IGMPpacket for joining the multicast group, but this packet not found in the packets captured on theuplink port on the UA5000. Run the display traffic-suppress command to query the trafficsuppression configuration on the UA5000. It is found that the unknown multicast trafficsuppression function is enabled.

Step 4 Run the undo traffic-suppress multicast command to disable the unknown multicast trafficsuppression function. Programs can be ordered using the STB successfully, indicating that thefault is rectified.

----End

Suggestions and SummaryThe unknown multicast traffic suppression function is enabled to prevent unknown multicastpacket storms on the Ethernet port on a UA5000, by setting the ratio of permitted unknownmulticast traffic on the Ethernet port to the total traffic on the Ethernet port.

TC-A0267 A Low Probability That the Called Party Is Connected Due to theInteroperation Problems Between the LE of Company B and the UA5000

This case describes how to troubleshoot a low probability that the called party is connected dueto the interoperation problems between the local exchange (LE) of company B and the UA5000.


Narrowband service



387

KeywordsPulse notification

The called party fails to be connected

Fault DescriptionThe LE and the UA5000 are configured with V5 interfaces, The UA5000 users can make callsnormally as calling parties. When they are called parties:

l The call can be connected if the calling parties are fixed-line phone users.l The call connections frequently fail if the calling parties are mobile phone users.


Cause Analysisl The data configuration on the UA5000 is incorrect.l The data configuration on the LE is incorrect.l The interoperation between the UA5000 and the LE is abnormal.

Procedure

Step 1 Check the data configuration on the UA5000; for example, check whether the data configurationis consistent with that on the LE and whether access user data configuration is correct. It is foundthat the preceding configurations are correct.

Step 2 Perform a test on the UA5000 users and use the Tool box to trace data. As called parties, theUA5000 users fail to be connected after being connected once.

Step 3 Compare the signaling when the called parties are connected and the signaling when the calledparties fail to be connected.l When the called parties are connected, the LE issues intermittent ringing signals four seconds

after the LE sends the initial ringing signal to the called parties and the UA5000 does notreport pulse notification.

l When the called parties fail to be connected, the LE releases the voice service channels if theUA5000 reports pulse notification after the LE sends the initial ringing signal to the calledparties.

Step 4 It is suspected that the LE releases the voice service channels because it fails to identity the pulsenotification signal reported by the UA5000. Run the oversea parameters command to setoverseas parameter 5 to 0 (indicates that no pulse notification signal is sent). Then, perform atest on the UA5000 users. It is found that the called parties can be connected successfully,indicating that the fault is rectified.

----End

Suggestions and SummaryNo suggestion or summary for this case.



388

TC-A0257 Service Failure Due to Incorrectly Configured IPMD Board'sCommunication Ports on the Backplane

This case describes how to troubleshoot service failures caused when the UA5000 transmits dataupstream through a gigabit passive optical network (GPON) port and the communication portsof the IPMD board on the backplane are not configured properly.

Fault Type

Service abnormality

Other

Keywords

GP1A

GPON

GE optical port

Fault Description

Network topology: UA5000 -> optical line terminal (OLT)

Fault symptom: A UA5000 is configured to transmit data upstream through a GPON port. Onceconfigured, however, the UA5000 services fail.

Alarm Information


Cause Analysisl The status of the GP1A board on the UA5000 is abnormal.l The data configured on the OLT to add optical network units (ONUs) is incorrect.l The working modes of the IPMD board's communication ports on the backplane are set

incorrectly.

Procedure

Step 1 Run the display board 0 command to check the status of the GP1A board. It is found that theboard is in the normal state.

Step 2 Run the display ont info command on the OLT to check the status of the UA5000. It is foundthat the UA5000 has successfully registered with the OLT, with Control Flag set to active andRun State set to online. This indicates that the data configured on the OLT to add ONUs iscorrect.

Step 3 Create management VLAN 100 on the OLT and the UA5000, and configure IP addresses thatare in the same network segment for the created VLAN. Then, ping the OLT from the UA5000to check whether the Layer 3 interface between the IPMD board and the OLT is operational. Itis found that the interface is not operational.



389

Step 4 Given that the communication ports of the IPMD board on the backplane must be in the GE-Optical working mode to communicate with the GP1A board, run the display port statecommand to check the working modes of the IPMD board's communication ports on thebackplane. It is found that the working modes are not GE-Optical.

Step 5 Run the mode 0 GE-Optical command to change the working modes of the IPMD board'scommunication ports on the backplane to GE-Optical. It is found that the fault is rectified.

----End

Suggestion and Summaryl The IPMD board, a control board of the UA5000, communicates with the GP1A board, a

GPON interface board, through two communication ports on the backplane, and theworking modes of the ports must be set to GE-Optical.

l To communicate with the EP1A interface board, the IPMD board's communication portson the backplane must also be set to the GE-Optical working mode.

16.1.5 Service InterruptionThis topic provides the analysis of the cases related to service interruption.

TC-A0002 Certain Boards of a UA5000 Are Faulty Because the LAP-RSA Link inthe CPC Board of the Switch Is Abnormal

This topic describes how to troubleshoot the fault when certain boards of a UA5000 are faultybecause the LAP-RSA link in the CPC board of the switch is abnormal.

Fault TypeOther


Phenomenon Descriptionl A new UA5000 that is configured with one HABD shelf is added to an office. The UA5000

is connected to the 8008P011J024 switch in VRSP mode and it functions as the RSP shelf.After the data configuration, it is found that the ASL board in slot 2, the RSU board in slot9, and the TSS board in slot 15 cannot work in the normal state and LEDs RUN fast blink.Other ASL boards and the RSU board in slot 8 work in the normal state.

l On the device panel of the switch, it can be found that these boards are sometimes normaland sometimes faulty.



l The shelf data on the switch is configured incorrectly (such as the subnode is configuredincorrectly).



390

l The problem exists in the 2M link between the switch and the access network (AN) device.l The hardware of the board of the UA5000 is faulty.l The backplane of the UA5000 is faulty.l The DIP switch of the RSU board is set incorrectly.

Procedure

Step 1 Delete the shelf data from the switch, and then reconfigure the data. The HABD shelf is emulatedas the RSP-19D on site. Configure a 2M link on the left and right virtual RSP boards. Thesubnodes of the left and right RSP boards are 10 and 21, which belong to HW group 1. Theboards in the shelf are numbered from 260. After the shelf is added successfully and the boardsare activated, the fault persists.

Step 2 Change the RSU, ASL, and TSS boards and test again. If the fault persists, it indicates that thefault is not caused by the boards. Then, re-upgrade the RSU board software and check the cableconnection and the DIP switch of the RSU board. If the cable connection and the DIP switchare in the normal state, and bits 1, 2, and 3 are set to ON and bit 4 is set to OFF, it indicates thatthe fault is not caused by the software.

Step 3 Remove all the boards and examine the pins on the backplane. If no pin is bent or damaged, itindicates that the fault is not caused by the backplane.

Step 4 Configure the 2M link on the switch to another port. The fault persists.

Step 5 Modify the shelf data. When the shelf is configured with one RSU board, the fault is rectified.In this case, observe the link status of the CPC board. It is found that two links are in the workingstate. In the case of one RSU board, however, only one LAP-RSA link should be configured.After the shelf is deleted, the corresponding link is deleted and the second link is still in theworking state. After the query of the alarm through the client, an alarm indicating that the secondlink is abnormal is displayed. In this case, it is considered that the second link is abnormal.

Step 6 On the switch, only one CPC board is configured to LAP-RSA. Add an idle master/slave RSPshelf to occupy the faulty link, and then add an actual shelf to occupy another link that is in thenormal state (avoid the faulty link). After the configuration, the fault is rectified.

----End

Suggestion and SummaryThe UA5000 that is connected to the switch in VRSP mode is closely relevant to the linkprocessing board (the CPC board) of the switch. In the case of the fault of this type, it isrecommended that you check whether the CPC link is in the normal state.

TC-A0035 Services of Certain ASL Boards in the ONU1000 Cabinet Are Interruptedat Random Because the H302ESC Board Is Faulty

This topic describes how to troubleshoot the fault when services of certain ASL boards in theONU1000 cabinet are interrupted at random because the H302ESC board is faulty.

Fault TypeOther




391

KeywordH302ESC

At random

Not fixed

ONU1000

Phenomenon Descriptionl Networking: optical line terminal (OLT) -> built-in transmission device -> built-in

transmission device in remote equipment room -> optical network unit (ONU)l Each RSP-19 shelf is fully configured with ASL boards and an RSP board. Certain boards

in the three RSP-19 shelves are faulty at random and the frequency is every one to twohours. Services of the faulty ASL boards are abnormal and recover after approximately oneminute.

l On the BMS, certain ASL boards in the three RSP-19 shelves are faulty at random, that is,the ASL boards that are faulty on the BMS are not fixed each time.



l The RSP board is faulty.l The ASL boards are faulty.l The data configuration is incorrect.l The power supply of the -48 V voltage is unstable.l Loops or short circuits exist in the loop line.l The TSS board is faulty.l The grounding resistance of the cabinet is very large.l The backplane of the shelf is faulty.l The transmission device or E1 cable is faulty.l The H302ESC board is faulty.

Procedure

Step 1 Replace the RSP and ASL boards. The fault, however, persists.

Step 2 Check the data. No exception is found. In addition, no data is set in recent months.

Step 3 Check the transmission BMS. No alarms on the ONU1000 and E1 exception are generated.

Step 4 Check the voltage of the power supply. The voltage is 53.5 V, which indicates that the powersupply is normal.

Step 5 Replace the TSS board. The fault, however, persists. Check the data on the OMC and checkwhether the data of the host and the BAM is consistent. It is found that the data is correct and



392

the data of the host and the BAM is consistent. Check the operation log. It is found that onlymultiple records about adding the data of A32 boards exist in the log. Delete the added data ofthe A32 boards.

Step 6 Measure the grounding resistance of the cabinet. It is found that the result is normal.

Step 7 Test whether loops and short circuits exist in the loop line. No exception is found.

Step 8 Check the components of the H302ESC board. It is found that certain components on the boardare damaged. After the components are replaced, the fault is rectified.

NOTE

The H302ESC board uses the -48 V voltage of the cabinet, and then directly monitors the voltage andcurrent of the cabinet. If the H302ESC board is faulty, the power supply system of the shelf may be affectedand the power supply for the shelf is unstable. In this case, services are affected.

----End


To save the time for locating the fault when multiple boards are faulty at random, it isrecommended that you first check whether the components of the board are damaged.

TC-A0059 The Services of Users Connected to the AG Are Frequently InterruptedTemporarily Because the Router Updates the MAC Address Table Periodically

This case describes how to troubleshoot the fault wherein the services of users connected to theAG are frequently interrupted temporarily because the router updates the MAC address tableperiodically.

Fault Type

VoIP service


Keyword

Interconnection

ARP binding

Fault Descriptionl Networking: User terminal -> UA5000 -> Ethernet switch (S6506R) -> router (C7609) ->

softswitch

l Fault description: A temporary communication interruption for several seconds frequentlyoccurs on users connected to the UA5000 of an operator. This symptom does not occur ineach communication.

Alarm Information

None



393


l The quality of the subscriber line is poor, which results in the loss of certain voice signals.l The UA5000 is faulty.l The Ethernet switch is faulty, which results in the packet loss.l Network congestion occurs on the router, which results in the packet loss.

Procedure

Step 1 The line maintenance personnel working with the operator confirm that the subscriber line isalready replaced, but the fault persists. This indicates that the subscriber line is normal.

Step 2 The data of the uplink port is mirrored and the packets are captured through the Wireshark tool.The software analysis of the captured packets shows that the packet loss occurs at a certain time.Therefore, it can be determined that the fault is caused by the packet loss.

Step 3 The analysis of the time difference of the packet loss shows that the packet loss occurs regularly.The alarms and user data configuration on the UA5000 are checked. If the check result showsthat the alarms and data configuration are normal, it indicates that the UA5000 is normal.

Step 4 The associated alarms and data configuration on the Ethernet switch are checked. It is found thatthe alarms and data configuration are normal. This indicates that the switch is normal.

Step 5 The maintenance personnel are contacted to check the router. It is found that the router is enabledwith a function of periodically updating the MAC address table, and that the updating period isbasically consistent with the packet loss interval displayed in the package capture result.

Step 6 The static ARP binding function is configured on the corresponding port on the router. Then,the voice communication of the users is tested multiple times. The test result shows that thecommunication is normal. Thus, the fault is rectified.

----End

Suggestions and SummaryThe causes of such temporary communication interruption problems can be quickly locatedthrough the packet capture analysis.

TC-A0166 Occasional Interruption of Service on a UA5000 Due to an Optical PathProblem

This case describes the troubleshooting of the occasional service interruption on a UA5000 dueto an optical path problem.

Fault TypeOther


KeywordAttenuation



394

Temperature

Fault DescriptionNetwork topology: UA5000 -> switch A -> BRAS

Fault symptom: The service on a UA5000 in an office was periodically interrupted and thenrestored. To be more specific, the layer-3 interface up and down alarms were frequentlygenerated on the uplink port on the UA5000. It was found that the service was regularlyinterrupted at 4 PM and was restored at 9 AM. The ambient temperature of the device neverexceeded -10°C.

Alarm InformationThe "L3 Interface Link Down" and "L3 Interface Link Up" alarms were displayed on theHyperTerminal.


l The port on the upper-layer switch of the UA5000 was faulty.l The control board of the UA5000 was faulty.l The optical path between the UA5000 and the upstream switch was faulty.

Procedure

Step 1 The Tx and Rx optical power of the optical port was checked on switch A. It was found that theTx and Rx optical power was normal. Then, the optical port on switch A was replaced to checkwhether the service could be restored. It was found that the fault persisted, indicating that thefault was not caused by a port problem on switch A.

Step 2 Pinging upper-layer gateway address from the UA5000 was performed. It was found that thegateway could not be pinged from the UA5000 but that the tested Tx and Rx optical power ofthe optical port was normal. Given that the ambient temperature of the UA5000 never exceeded-10°C, it was hypothesized that the board might be faulty as a result of running in a low-temperature environment for a long time. Then, the IPMB control board and optical daughterboard of the UA5000 were replaced with new boards. It was found that the UA5000 still failedto ping the upper-layer gateway.

Step 3 The interface corresponding to switch A was configured with a new layer-3 address, and thenthis address was pinged from the UA5000. It was found that the address could not be pinged.

Step 4 The optical fiber connected to the UA5000 was removed and then the optical status of switch Awas checked. It was found that the port was not displayed in "down" status on switch A,indicating that the UA5000 was not directly connected to switch A. A further check confirmedthat a second switch was connected between the UA5000 and switch A, and that the actualnetwork topology was UA5000 -> switch B -> switch A -> BRAS.

Step 5 The Rx and Rx optical power of the optical port connected to the UA5000 was checked on switchB. It was found that the Tx optical power was normal but the Rx optical power was abnormal.A test showed that the light intensity transmitted from the UA5000 was very weak and unstable.

Step 6 Further analysis showed that the performance of the optical fiber between the UA5000 andswitch B was reduced and had become unstable in the cold temperature, and that the signal was



395

very weak and fluctuating. As a result, signal transmission on the port on switch B occasionallyfailed, leading to the interruption of service on the UA5000. When the optical transmission pathbetween the devices was replaced, the service interruptions on the UA5000 no longer occurred.

----End


The access devices used in cold northern areas often operate in temperatures between -10°C and-30°C. On the existing network, there have been cases where the access devices were frozen andfailed to work normally, but the probability is small and the fault can be rectified after thetransmission optical path is replaced.

To improve efficiency in troubleshooting, it is necessary to obtain accurate information abouthow the devices are networked.

TC-A0167 PPPoE Dialup Failure During Thunder Download Due to IncorrectConfiguration on the BRAS

This case describes the troubleshooting of a PPPoE dialup failure that occurred when Thundersoftware was used for download. The dialup failure occurred because the broadband remoteaccess server (BRAS) was not configured properly.

Fault Type

Ethernet service


Keywords


Retransmission counts

Fault Description

Network topology: UA5000 -> S6506R -> BRAS

Fault symptom: Numerous users reported that Internet access through PPPoE dialup failed whencertain applications, such as the download software Thunder, the video player PPLive, and themusic player Kuwo, were used during Internet surfing.

Alarm Information

None

Cause Analysis


l The bandwidth was insufficient or the optical attenuation was high.l The data configuration on the BRAS was incorrect.



396

Procedure

Step 1 The PPPoE dialup failure that occurs when applications such as Thunder, PPLive, and Kuwoare used is generally caused by network congestion. Therefore, the first step was to check theport traffic and optical power on the UA5000 and the S6506R. The check showed that the porttraffic and optical power on the two devices were normal, indicating that the fault was not causedby bandwidth insufficiency or optical attenuation.

Step 2 The PPP layer-2 detection interval and timeout detection count configurations on the BRASwere checked. It was found that the PPP layer-2 detection interval was short and that the timeoutdetection count was small, both of which might cause PPPoE dialup failure. After the PPP layer-2detection interval and timeout detection count were adjusted using the ppp keepalive command,the fault was rectified.

----End

Suggestions and SummaryIf the PPPoE connection fails during a normal PPPoE session, there are two possible causes:l The PPPoE user has made a request to go offline. This is a normal offline, and when the

user dials up again, the PPPoE connection is re-established immediately.l The PPP layer-2 detection interval is short or the timeout detection count is small. In such

cases, when the network is congested, the BRAS terminates the PPPoE session. Thunder,PPLive, and Kuwo are applications that tend to produce network congestion. Therefore,when the PPP layer-2 detection interval and timeout detection count, which are configuredthrough the ppp keepalive command under the virtual profile of the BRAS, do not meetthe current requirements, PPPoE users connected to the BRAS may find that theirconnection is frequently terminated.

The default PPP layer-2 detection interval of Huawei BRAS MA5200G is 20 seconds and thedefault timeout detection count is three. When the two values do not meet actual requirements,run the ppp keepalive command to reconfigure the values.





KeywordsPADS

Number of users




397





Procedure

Step 1 Given that error 676 during dialup was mostly caused by a loop on the user port or upper-layerdevice, the ring check enable command was executed to enable the loop detection function ofthe UA5000. Then, the security mac-filter 0030-8810-2889 command (0030-8810-2889 wasthe MAC address of the BRAS) was executed to filter the MAC address, because the ring checkenable command could be used for preventing only single-port loop but could not be used forpreventing multi-port loop. It was found that the fault persisted.





traffic-statistic:port 0/2/0: Inbound: Matches: Acl 4001 rule 5 running 2 packets Outbound: Matches: Acl 4000 rule 5 running 1 packets Total number of traffic-statistic inbound : 1 Total number of traffic-statistic outbound : 1



398

Total number of traffic-statistic all : 2





----End


Error 676 during dialup is seldom caused by the restriction on the number of permitted BRASconnections, which therefore is often ignored during the handling of error 676. This case can beused as a reference for troubleshooting similar faults.

TC-A0208 114 Call Disconnection on Voice Users of a UA5000 Due to a Third-PartyVoice Switch Problem

This case describes the troubleshooting of the disconnection of the 114 call, a phone numberquery hotline service provided in China, on voice users of a UA5000 due to a third-party voiceswitch problem.

Fault Type

Narrowband service


Keyword

Communication interruption

114



399

Fault Description

Network topology: Shenou switch -> UA5000 -> SX3000

NOTEThe UA5000 was interconnected with Shenou voice switch in the upstream direction, and was connected to theShenou voice switch in the downstream. The end users were connected by the third-party voice switch.

Fault symptom: As reported by the telecom maintenance personnel, when the voice subscriberof the UA5000 called 114, the call was connected normally. During the conversation (for lessthan 4s each time) after the call was connected, however, the call was interrupted automatically.

Alarm Information

None

Cause Analysis


l The data configuration of the softswitch was incorrect.

l The phone set was faulty.

l Other causes.

Procedure

Step 1 The conversation was interrupted abnormally when the subscriber dialed 114. The analysis ofsignaling tracing showed that the UA5000 reported the onhook message to the softswitch. Thisindicated that the fault was caused by the UA5000 and the softswitch was normal.

Step 2 Actually, the telephone did not hang up when the UA5000 reported the onhook message to thesoftswitch. It was suspected that the communication interruption was caused by the telephoneabnormality. The telephone was replaced at the faulty port, but the fault persisted. Therefore,the telephone was normal.

Step 3 It was found that the fault occurred after the third-party voice switch was added to the UA5000.Therefore, the line that connected to the third-party switch was disconnected on the MDF sideand the line was directly connected to the user phone. A dialup test was performed and it wasfound that the service was normal. Therefore, it was concluded that the fault was caused by thethird-party voice switch. After the switch was changed, the services were restored.

----End


None

TC-A0209 Internet Access Failure on VPDN Users Due to the Anti-MAC SpoofingFunction Enabled on the UA5000

This case describes the troubleshooting of the Internet access failure on VPDN users of a UA5000Due to the anti-MAC spoofing function enabled on the UA5000.



400



KeywordsAnti-MAC spoofing

Address drift

Fault DescriptionNetwork topology: PC -> UA5000 -> Switch (S3528) -> BRAS (MA5200G)

The subscriber was in a hospital, and the VPDN service was connected to the hospital intra-network after dialing up. The intra-network was connected to the next server through the medicalinsurance system software. The subscriber dialed the numbers in the VPDN mode successfully.Dialing up to access the network was successful, however the PC that uses this software failedto connect to the server. The system prompted that the connection was delayed.



l The network was disconnected due to the routing failure between the subscriber's computerand the server.

l The computer setting was faulty.l The MTU was set too large, and therefore the data failed to get through the upper-layer

device.l The parameter configuration of the UA5000 was incorrect.

Procedure

Step 1 The operation of pinging the service from the PC was performed. It was found that theconnection/communication was normal.

Step 2 The test was performed on another MA51000 under S3528, and it was found that the softwarewas normal. Therefore, it could be determined that the fault was caused by the UA5000 and thePC.

Step 3 The computer that was tested as normal on the MA5100 was connected to the UA5000 for atest, but the software runs abnormally.

Step 4 After the MTU value was decreased, the fault persisted.

Step 5 The packets were captured and analyzed on the PC, and it was confirmed that a virtual MACaddress was used by the software. However, the anti-MAC spoofing function was enabled onthe UA5000.



401

NOTE

After the anti-MAC spoofing function was enabled, the system will bind the MAC address with the servicestream. The packets were discarded because the virtual MAC address was used in the software.

Step 6 The security anti-macspoofing disable command was executed to disable the function. Afterthe test, the PC was connected to the medical server through the software normally.

----End


In routine maintenance, the fault wherein the subscribers can access the Internet but certainservices are abnormal. The fault may be caused by incorrect MTU settings. If the fault cannotbe rectified after the MTU value is decreased, perform packet capture and analysis.

Disable the anti-MAC spoofing function on the UA5000 and run the security mac-filtercommand to configure filtering function of a specified MAC address, thus preventing MACaddress change.

TC-A0223 Service Interruption Due to Repeated Resets of the MG Interface

This case describes the troubleshooting of a service interruption due to the repeated resets of themedia gateway (MG) interface.

Fault Type

VoIP service


Keyword

MG interface fault

Fault Description

When the H.248 protocol was used and the MG interface was configured, the MG interface wasreset repeatedly.

Alarm Information

None

Cause Analysis


l The data configuration of the MG interface was incorrect.

l The interconnection between the MG interface and the media gateway controller (MGC)was faulty.



402

Procedure

Step 1 The signaling message of the MG interface was analyzed. It was found that each time a heartbeatmessage was retransmitted, the interface was reset.

Step 2 The status of the transaction reliability switch of the protocol stack parameter was checked. Itwas found that the switch was turned off.

Step 3 The heartbeat parameter configured in the system was checked. It was found that the heartbeatparameter was set to 5 seconds, which was the minimum value in the heartbeat detection.

Step 4 The transaction retransmission mode was checked. It was found that the transactionretransmission mode was T-MAX and the retransmission time was 10 seconds. The T-MAXretransmission time is to the duration for retransmitting a transaction when the transmission ofthe transaction fails.

NOTEThe transaction retransmission time was 10 seconds whereas the heartbeat message was sent every 5 seconds.When there was a network jitter and the heartbeat message was lost, the remaining time was insufficient forretransmitting the transaction. Therefore, the MG interface was reset immediately after the message wasretransmitted once.

Step 5 The retransmission time was set to 25 seconds (default value), which was twice longer than theheartbeat detection time. That is, the fault was rectified.

----End

Suggestions and SummaryIt is recommended that you use the default settings when configuring the MG interface. Changethe default settings only when required.

TC-A0225 Faulty V5 Interface on the Switch Due to a Loopback on the 2M LinkThis case describes the troubleshooting of a faulty V5 interface on the switch due to a loopbackon the 2M link.



KeywordV5 service abnormality

Fault DescriptionThe UA5000 (PVM) was connected to a transmission device and then was connected to a switchthrough the V5 interface. The V5 interface on the UA5000 was displayed as normal but the V5interface on the switch was displayed as faulty.




403

Cause Analysis


l The data configuration of the switch or the UA5000 was incorrect.

l The transmission device was faulty.

Procedure

Step 1 The V5 interface on the UA5000 was checked. It was found that the V5 interface worked in thenormal state. This indicated that the 2M link was reachable. Therefore, it was concluded thatthe data configuration of the V5 interface on the UA5000 was correct.

Step 2 The data of the switch and the access network was checked. It was found that the negotiationdata on the switch was consistent with the negotiation data on the access network. Thenegotiation data includes V5ID, LINK ID, V5 version, logical C channel, and CRC. Thisindicated that the data configuration of the switch was correct.

Step 3 The transmission device was checked. It was found that a 2M loopback was configured for theUA5000. The loopback was canceled, the V5 interface on the switch became normal.

----End


None

TC-A0268 UA5000 Service Failure Due to Saving Data Failure After the ONU ofCompany B Is Power Cycled

This case describes how to troubleshoot the UA5000 service failure due to the failure in correctlysaving data after the optical network unit (ONU) of another company (company B as an example)is power cycled.

Fault Type


Others

Keywords

Connection

Mains off

Fault Description

Network topology: UA5000 -> ONU of company B -> OLT of company B

The UA5000 on a site is configured to transmit data in an integrated mode. The UA5000 andthe ONU of company B are powered off because the mains supply in the equipment room is cutoff. The UA5000 services are interrupted after the UA5000 and the ONU are powered on again.



404


Cause Analysisl The hardware of the control boards on the UA5000 is faulty.l The UA5000 data is lost.l The connection between the UA5000 and the ONU is abnormal.l The connection between the ONU and the OLT is abnormal.

Procedure

Step 1 Check the indicators on the control board panels of the UA5000 and run the display boardcommand to query the status of the control boards. It is found that the control boards are runningproperly.

Step 2 Check the UA5000 software. It is found that the software version is normal and no data is lost.

Step 3 Check the ONU on the OLT. It is found that the ONU is normal, indicating that the connectionbetween the OLT and the ONU is normal.

Step 4 Check on the ONU whether the ONU has learned three MAC addresses of the UA5000, namely,the MAC address of the uplink port on the IPMB board, the MAC address of the outband networkport on the PVMB board, and the MAC address of the network port.

Step 5 Connect the UA5000 to another port on the ONU. It is found that the fault persists.

Step 6 Check the transmission mode of the port on the ONU. The mode is transparent. The mode ofthe port connected to the UA5000 is changed to non-transparent and then transparent. It is foundthat the UA5000 services are restored, indicating that the fault is rectified.

----End

Suggestions and SummaryThe ONU of company B cannot correctly save data after being power cycled, so that the datadoes not take effect though the system displays that the data has been saved. The data can takeeffect after being modified.

16.1.6 Other FaultsThis topic provides the analysis of the cases related to other features.

TC-A0018 Data Loss Occurs After the Power-Off of the UA5000 Because theduplicate Command Is Executed Improperly During the Deployment

This topic describes how to troubleshoot the fault when data loss occurs after the power-off ofthe UA5000 because the duplicate command is executed improperly during the deployment.

Fault TypeOther



405

KeywordDuplicate

Phenomenon DescriptionIn an office, the UA5000 is powered off during the power adjustment. After the UA5000 ispowered on, it is found that the service data, such as the MG interface, is lost.



l The data is not saved after the configuration.l Saving the database fails because the flash chip of the control board is damaged.l The control board is not reset after the database is loaded or duplicated.

Procedure

Step 1 Check the operation logs. It is found that the field engineer performs the save operation beforethe UA5000 is powered off.

Step 2 Check the alarms. No alarm indicating that the hardware is faulty is found. Run the savecommand. If the command can be executed successfully and the system can be started normally,it indicates that the flash memory of the control board is in the normal state.

Step 3 Continue to analyze the alarms and operation logs of the UA5000.1. After the system is started on May 23, slot 5 is for the active control board and slot 4 is for

the standby control board. The field engineer begins to configure data. After a shelf is added,the field engineer saves the corresponding data.

2. Active/standby switchover occurs at 10:27:04 a.m. on 2008-05-23. Then, slot 4 is for theactive control board, and slot 5 is for the standby control board. Then, the field engineeradds the board data and saves the configurations to the flash memory at 10:31:09 on2008-05-23.

3. After performing the save operation, the field engineer configures such service data as theMG interface. During the process, the field engineer does not perform the save operation.At 11:19:17 on 2008-05-23, the field engineer runs the duplicate command, that is,duplicate the flash memory data on the active control board in slot 4 to the standby controlboard in slot 5. At 11:20:07 on 2008-05-23, the field engineer performs the save operation.

After running the duplicate command, the field engineer must reset the standby control board.The field engineer, however, does not reset the standby control board. As a result, only the dataon the active control board can be stored to the flash memory but the data on the standby boardcannot be stored to the flash memory when the save command is executed. Before the systemis powered off and restarted on June 21st, the flash memory data on the PVMB control board inslot 4 is inconsistent with the flash memory data on the PVMB control board in slot 5.

After the system is powered on and restarted, data loss occurs if the previous standby controlboard becomes the active control board. In other words, the data configured during the period



406

from 10:31:09 of 2008-05-23 to 11:19:17 of 2008-05-23 cannot be stored to the standby controlboard in slot 5. After the system was powered off and restarted on June 21st, the PVMB controlboard in slot 5 becomes the active control board. Before the restart, the data of slot 4 isinconsistent with the data of slot 5. Therefore, only the earlier shelf data and board data can berecovered from the flash memory after the PVMB control board in slot 5 becomes the activecontrol board. Other data is lost because such data is not stored to the flash memory before.

To sum up, the cause of this fault is that the standby control board is not reset and thus the flashmemory data on the active control board is inconsistent with the flash memory data on thestandby control board after the duplicate command is executed. After the system is restarted,the original standby control board becomes the active control board, thus data loss occurs.

----End

Suggestion and SummaryAfter you run the save command, the data of the active and standby control board is stored tothe flash memory. Therefore, it is recommended that you do not run the duplicate command toduplicate data from the active board to the standby board. After running the duplicate commandto duplicate the database or running the load data command to load the database, you mustrestart the corresponding control board. Otherwise, the save command cannot be executednormally.

TC-A0086 The 2M Links on the Switch and the UA5000 Are Seemingly NormalBecause the Transmission Device Is Not Grounded Properly

This case describes how to troubleshoot the fault wherein the 2M links on the switch and theUA5000 are seemingly normal because the transmission device is not grounded properly.

Fault TypeOther

Service exception

KeywordPVMB 2M pseudomorph

Fault DescriptionIn an office, the UA5000 is equipped with one HABA shelf, one PVMB control board, sevenA32 analog service boards (inserted in slots 0/6 to 0/12), and one DSL board (inserted in slot0/16). By the first 2M line on the left PVMB board, the UA5000 is connected to the switchthrough the PDH transmission device. The UA5000 in this office is deployed with the VRSPconfiguration and it originally uses only one 2M line. Now the number of 2M lines on UA5000needs to be increased to four, and in addition, the standby PVMB board is installed on theUA5000. In this manner, the UA5000 is connected to the switch through four 2M lines on theactive and standby PVMB boards (each PVMB board provides two 2M lines). After the standbyPVMB board is configured, it is found that the port on the A32 board in slot 0/12 and the attendantposition user connected to the DSL board in slot 0/16 cannot operate normally. The voice porton the A32 board cannot process services normally. That is, the users connected to this port candial the number of the called party successfully but cannot hear the voice from the called party.The same symptom occurs on the attendant position user connected to the DSL board. In



407

addition, the right RSP board on the network management system (NMS) is in the faulty (red)state.

Alarm Information

None

Cause Analysis


l The data configuration is incorrect.

l The 2M link is faulty.

l The hardware of the device is faulty.

l The power supply is abnormal.

l The device is not grounded properly.

Procedure

Step 1 The detailed data configuration on the switch and UA5000 is checked. It is found that the dataconfiguration is correct. This indicates that the fault is not caused by data configuration. OneHABA shelf is emulated as two RSP shelves on the switch.

Step 2 The two 2M lines on the active PVMB board are connected to two 2M lines (No.1 and No.2)on the PDH transmission device, and the two 2M lines on the standby PVMB board are connectedto two 2M lines (No.3 and No.4) on the PDH transmission device. The four 2M lines aredisconnected one by one and tested. No crossed pair is found. In addition, the tests of self-loopand loopback to the peer end are normal. This indicates that the 2M lines are normal, though theright RSP board is displayed as in the faulty state in red.

Step 3 Based on the fact that the fault occurs on slots 0/12 and 0/16, which correspond to the right halfshelf of the RSP shelf on the switch, the service boards inserted in slots 0/12 to 0/16 are tested.It is found that the fault wherein the call can be set up successfully but the users cannot hear anyvoice occurs on all the service boards inserted in slots 0/12 to 0/16. The 2M resources allocationon the switch is as follows: The two 2M links provided by the active RSP board are used for thecommunication of the left half shelf (corresponding to the 2M lines on the physical active PVMBboard). The two 2M links provided by the standby RSP board are used for the communicationof the right half shelf (corresponding to the 2M lines on the physical standby PVMB board).Based on the preceding analysis, it is considered that the hardware of the device is faulty. Afterthe shelf of the UA5000 and the PDH transmission device are replaced, however, it is found thatthe fault still persists.

Step 4 The power and device grounding in the equipment room is checked. It is found that the groundcable of the PDH transmission device is connected to the screw for fixing the board on theUA5000. This screw, is in direct contact with the metal material of the UA5000, which, however,is painted with a layer of rust proof paint and is equipped with a plastic pad. Therefore, the PDHtransmission device is just seemingly grounded but is actually insulated. That is, the groundingof the PDH transmission device is invalid. Then, ground cable of the PDH transmission deviceis re-connected to the ground bar. The subsequent test shows that the fault is rectified.

----End



408


The fault in this case is actually caused by a minor problem, that is, the transmission device isnot grounded properly and therefore the two 2M links (No.3 and No.4) cannot be used normally.Generally, if the transmission device is not grounded, the quality of the 2M link communicationis affected and error codes are generated. In this case, the grounding failure of the transmissiondevice is originally not considered to cause the communication failure of the 2M link, becausethe 2M link is normal in the self-loop test. The normal result, actually proved a pseudomorph.Therefore, it is recommended that you pay more attention to the grounding factor in theengineering.

TC-A0090 All the Services Carried on the UA5000 Are Interrupted Because the DataConfiguration on the Softswitch Is Incorrect

This case describes how to troubleshoot the fault wherein all the services carried on the UA5000are interrupted because the data configuration on the softswitch is incorrect.

Fault Type

Other

Other

Keyword

Data configuration

error

Fault Description

Networking: Softswitch -> bearer network -> UA5000

Fault description: All the user services carried on the UA5000 are interrupted.

Alarm Information

None

Cause Analysis


l The communication on the bearer network is interrupted.l The data configuration on the UA5000 is incorrect.l The upper layer device is faulty.

Procedure

Step 1 The softswitch is pinged from the UA5000. It is found that the softswitch can be pingedsuccessfully and the MG interface is in the normal state. Therefore, it can be determined thatthe bear network is normal.



409

Step 2 The data configuration on the UA5000 is checked. It is found that the configuration is correct.

Step 3 Packets are captured and analyzed. It is found that the UA5000 cannot identify the signalingsent by the softswitch, namely, [07:55:49.450]msg from mgc([10.55.80.6]:2944) to mg([10.58.136.22]:2944): !/2 [10.55.80.6]:2944 T=1191256705 {C=206{MF=A1{M{TS{fsk/fsktype=1}},SG{al/ri,fsk/fsk{d="2008-09-21",t="07:54:08",r=Private}}}}} [07:55:49.450]msg from mg([10.58.136.22]:2944) to mgc([10.55.80.6]:2944): !/2 [10.58.136.22]:2944ER=400{" Syntax error in message"}.

Step 4 The CO maintenance personnel are contacted to check the data configuration on the softswitch.It is found that the configuration on the softswitch is incorrect. After the configuration on thesoftswitch is corrected, the fault is rectified.

----End


None

TC-A0092 The Port Link Fails to Be Set Up Because the Modes of the Ports on thePVMD Board and the Upper-Layer Device Are Inconsistent

This case describes how to troubleshoot the fault wherein the port link cannot be set up becausethe modes of the ports on the PVMD board and the upper-layer device are inconsistent.

Fault Type

Other

Other

Keyword

PVMD

Working mode

Fault Description

The UA5000 transmits services upstream to the MA5600 through the Gigabit optical port onthe PVMD board. The LINK indicator of the network port on the MA5600, when the opticalfiber is just inserted in to the port, is on. Subsequently, the LINK indicator is off. In this case, itis found that the port is down, and that the LINK and ACT indicators of the network port on theUA5000 are off. That is, the port link between the UA5000 and the MA5600 fails to be set up.

Alarm Information

None

Cause Analysis




410

l The optical fiber or transceiver may be faulty because the indicator for the physical link ofthe port is off.

l The data configuration of the uplink port on the PVMD board is incorrect.l The working modes of the ports on the devices on the two sides are inconsistent.

Procedure

Step 1 The optical fibers are replaced by a new pair of optical fibers. It is found that the fault persists.This indicates that the fault is not caused by the optical fiber. Considering that the two PVMDboards provide two Gigabit optical transceivers and the MA5600 also provides two Gigabitoptical transceivers, the two optical transceivers on each of the device are exchanged to connectto the peer device. It is found that the fault persists. Therefore, it indicates that the opticaltransceivers on the two devices are normal.

Step 2 The up-linkport set workmode is executed to check the type of the uplink port. It is found thatthe type is configured to GE-O, which is correct.

Step 3 The working modes of the two ports on both sides are checked. It is found that the working modeof the port is configured to auto-adaptation, whereas the working mode of the port on theMA5600 is configured to 1000 M full-duplex. Then, the working mode of the uplink port on theUA5000 is changed to 1000 M full-duplex. Later, it is found that the port link is set upsuccessfully and the MG registers with the system successfully. That is, the fault is rectified.

----End

Suggestions and SummaryThere is another simple method of determining whether the optical fiber and transceiver arenormal. That is, use the optical fiber to perform self-loop on each network port, and then checkwhether the LINK indicator of the network port is normal. In addition, run the associatedcommand to check whether the status of the network port is restored, and accordingly you candetermine whether the optical fiber and transceiver are normal.

TC-A0097 The Services on the Lower Half Shelf Fails Because the Shelf Type ofthe UA5000 Is Set Incorrectly

This case describes how to troubleshoot the case wherein the services on the lower half shelffails because the shelf type of the UA5000 is set incorrectly.

Fault TypeOther

Other

KeywordHABA

Fault DescriptionA newly-deployed UA5000 uses the HABA shelf and is configured with one PVM board. Theshelf is simulated as two virtual RSP (VRSP) shelves. The 2M lines are connected to the first



411

and second 2M ports on the PVM board in slot 4. The user of the UA5000 reports that the busytone is played after offhook. On the BMS, the lower half shelf is displayed in red.



l The 2M line connected for the simulated second shelf is faulty.l The port on the DTE board of the OLT is faulty.l The data configured on the BMS is incorrect.l The hardware of the UA5000 is faulty.

Procedure

Step 1 A self-loop test from the equipment room to the OLT is performed. It is found that thecommunication is normal.

Step 2 A self-loop test from the equipment room to the UA5000 is performed. It is found that the E1links are normal.

Step 3 The display version command is executed to query the version of the UA5000. It is found thatthe "VRSP Workmode" value of the device is HABD, whereas the actual shelf type of the deviceis HABA.

Step 4 The working mode of the shelf is changed to HABA. Then, it is found that the fault is rectified.

----End

Suggestions and SummaryIn the deployment of the device, check and ensure that the settings of the shelf are the same asthe actual running parameters of the shelf.

TC-A0098 No Tone Is Played After Certain Users Go Off Hook Because the LoadedShelf Type Is Incorrect

This case describes how to troubleshoot the fault wherein no tone is played after certain usersgo offhook because the loaded shelf type is incorrect.


Other

KeywordHLB




412

Fault Description

Networking: UA5000 -> LAN switch -> MA5200G (BRAS) -> CN2

Fault description: The service can be successfully provided for only the users connected to thefirst board of the UA5000, and cannot be provided for users connected to other boards (in thiscase, no dial tone is played after the user goes off hook).

Alarm Information

None

Cause Analysis


l The service board is faulty.

l The softswitch fails to provide the service normally because it is configured with the userdata of only the first A32 board of the UA5000.

l The backplane is faulty because only the first slot is normal and the other slots are faulty.

l The UA5000 is not configured with the TID correctly.

l The power module or other module is faulty, which affects the users connected to the entireshelf.

l The shelf type is incorrect.

Procedure

Step 1 To check whether the fault is caused by the board, the board in the first slot is interchanged witha board in another slot. It is found that still only the services on the board in the first slot arenormal.

Step 2 The data of the softswitch is checked. It is found that the switch is configured with data of usersconnected to other boards.

Step 3 To check whether the fault is caused by the slot, the TID of the first slot is configured on otherslots to be tested. It is found that the fault persists.

Step 4 The TID configured on the UA5000 is checked. It is found that the TID is configured strictlyaccording to the requirement of the carrier, that is, the TID is correct.

Step 5 To verify that the fault is not caused by the slot, the backplane is replaced. It is found that thefault persists.

Step 6 During the replacement of the backplane, it is found that the backplane is the HLB board, whereasthe shelf type is configured to HMB according to the mark (AMG5160A) on the device. Whenthe device type is regarded as AMG5160A, the default backplane is the HMB board.

Step 7 The shelf type is changed. Then, it is found that the fault is rectified.

----End



413


When adding shelves to an integrated access device, to avoid being confused by the device namemarked on the front panel of the device, you need to check the type of the backplane and configurethe correct shelf type. This helps to prevent such faults.

TC-A0106 The NMS and Services Fail Because VLAN IDs Are Different When theQinQ Network on the UA5000 Is Reconstructed

This case describes how to troubleshoot the fault wherein the NMS and services fail becauseVLAN IDs are different when the QinQ network on the UA5000 is reconstructed.

Fault Type

Other

Other

Keyword

QinQ

NMS

Fault Description

Networking: The UA5000 is connected to the upper-layer switch through the optical fiber.

Fault description: The users connected to the UA5000 cannot access the Internet. The networkmanagement center cannot manage devices, but the test shows that the line and the optical linkare normal.

Alarm Information

None

Cause Analysis


l The uplink port is disconnected.l The optical/electrical converter is faulty.l The configuration of the switch is incorrect.l The VLAN configuration is incorrect.l A loop is formed.

Procedure

Step 1 Data is checked on the UA5000 after login. It is found that the data is correct and the uplink portis normal, but the gateway cannot be pinged through. The ID of the network management VLANis 753.



414

Step 2 The optical-to-electrical (O/E) converter is replaced, but the gateway still cannot be pingedthrough.

Step 3 The VLAN is checked on the switch in the central office after login. It is found that the VLANID corresponding to the UA5000 is 2329.

Step 4 The alarm information of the NM center is checked and it is found that services of the UA5000are interrupted at 12:00 one night. It is verified that the QinQ network is reconstructed that nightand the network management VLAN ID is changed to 4000, whereas the outer VLAN ID is2329.

Step 5 Based on the preceding analysis, it is determined that the fault is caused by the configurationinconsistency between the outer VLAN of the UA5000, VLAN of the switch, and the networkmanagement VLAN. After the IDs of the network management VLAN and the service VLANof the UA5000 are changed to the same ID, the network management and services are restored.

----End


TC-A0107 The Temperature Inside the Cabinet Is Very High Because the HeatDissipation Hole on the F01D100 Cabinet Is Blocked

This case describes how to troubleshoot the fault wherein the temperature inside the cabinet isvery high because the heat dissipation hole on the F01D100 cabinet is blocked.

Fault TypeOther

Other

KeywordToo high temperature

Heat exchange system

Fault DescriptionFault description: The F01D100 device reports a high temperature alarm.

Alarm InformationThe temperature is too high.


l The environment monitoring module reports an alarm by mistake.l The heat exchanger is faulty.



415

l The heat dissipation hole is blocked.

Procedure

Step 1 After on-site check, it is found that the fan inside the cabinet can rotate but the temperature istoo high and the environment monitoring is normal.

Step 2 The heat exchanger is checked and it is found that the heat exchanger is normal. (Note: To seethe heat exchanger, you need to open the front door of the cabinet and then open the two boltson the left side of the front door.)

Step 3 The fan of the heat exchanger is checked and it is found that there is heavy dust on the air filter.The dust on the air filter is cleared on site. It is found that the temperature of the cabinet reducesto the normal range and the fault is rectified.

----End

Suggestions and SummaryThe heavy dust on the air filter in the heat exchanger of the outdoor cabinet needs to be clearedin time.

TC-A0112 The H.248 Interface on the AG Fails to Be Set Up Because of Softswitch'sRestriction on the Negotiation Start Version

This case describes how to troubleshoot the fault wherein the H.248 interface of the AG fails tobe set up because of softswitch's restriction on the negotiation start version.

Fault TypeOther

Other

KeywordNegotiation start version

Fault DescriptionFault description: In an office, a new UA5000 is connected to the SoftX3000 through the H.248interface. After the data configuration, it is found that the H.248 interface is always in the waitack state and cannot work normally.



The UA5000 PVM V100R13C05B051 negotiates the H.248 protocol from V3 by default. Thesoftswitch, however, does not support V3 and therefore the negotiation fails. At the same time,



416

the SVC_CHANGE message initiated by the softswitch does not contain the version descriptor.Therefore, the negotiation for the interface between the UA5000 and the SoftX3000 fails.

ProcedureStep 1 The display if-h248 attribute command is executed to check the attribute configuration of the

H.248 interface on the UA5000. It is found that the attribute configuration of the H.248 interfaceon the UA5000 is the same as that on the SoftX3000.

Step 2 The signaling interface address of the SoftX3000 is pinged from the UA5000. It is found thatthe ping operation is successful and no packet loss occurs.

Step 3 Packets are captured through Ethereal on the uplink port of the UA5000 for analysis. It is foundthat the UA5000 initiates the registration but the softswitch does not reply.

Step 4 The SoftX3000 is checked, and it is found that the SoftX3000 does not support the H.248 V3protocol.

Step 5 The negotiation start version of the H.248 attribute on the UA5000 is changed to V2. Then, theH.248 interface is set up successfully and the fault is rectified.

----End


TC-A0127 One of the Two NMS Channels of the UA5000 Fails Because theConvergence Switch Is Configured Inappropriately

This case describes how to troubleshoot the fault wherein one of the two NMS channels of theUA5000 fails because the convergence switch is configured inappropriately.

Fault TypeOther

Other

KeywordConvergence

Outband NMS

Fault DescriptionNetworking: ETH ports on the two control boards of the UA5000 are connected to the sameupstream convergence switch 3528 of Huawei through different links.l Link 1: UA5000 (outband network management port is on the board in slot 0/4) ->

transmission device -> convergence switch 3528 (port 0/15)l Link 2: UA5000 (outband network management port is on the board in slot 0/5) ->

transmission device -> convergence switch 3528 (ports 0/16)

Fault description: When the PVMD board in slot 0/4 serves as the active control board, theaddress of the gateway, to which the outband NMS belongs, can be pinged successfully. When



417

the PVMD board in slot 0/5 serves as the active control board, the address of the gateway, towhich the outband NMS belongs, fails to be pinged.

Alarm InformationThe communication between the PVMD board and the NMS server is interrupted after active/standby switchover.


l The PVMD control board in slot 0/5 is faulty. As a result, the outband NMS function fails.l The transport channel of link 2 is faulty.l The networking and data configuration are inappropriate.

Procedure

Step 1 The PVMD control board in slot 0/5 is inserted into slot 0/4. It is found that the NMS is normal.This indicates that the fault is not caused by a fault on the PVMD control board in slot 0/5.

Step 2 The port connection is adjusted. That is, the convergence switch 3528 (port 0/15) is connectedto the UA5000 (outband NMS port on the board in slot 0/4). It is found that the NMS is normal.This indicates that the fault is not caused by a transport channel fault of link 2.

Step 3 The data configuration of the convergence switch 3528 is checked. It is found that ports 0/15and 0/16 are added to convergence link group 1. The display arp interface Ethernet 0/15 anddisplay arp interface Ethernet 0/16 commands are executed. It is found that the MAC addressof the outband NMS port on the PVMD board is learnt by port 0/15 of the convergence switch3528 regardless of whether the PVMD control board in slot 0/4 or in slot 0/5 of the UA5000serves as the active control board. Therefore, it can be considered that the fault may be causedby the convergence feature of the convergence switch 3528.

Step 4 The accounting device is removed and the exchange side terminal block is directly connectedto the subscriber line through a jumper. The test shows that the port is in the normal state. Then,the subscriber line is removed and a phone set is directly connected to the accounting device.The test shows that the port is in the failed state. This indicates that the fault is caused by theaccounting device. A further test is performed. It is found that the leading-in cable and leading-out cable of the accounting device are connected conversely. After the cables are connectedcorrectly, the fault is rectified.

----End

Suggestions and Summaryl The interconnected devices on both side must support the convergence feature before the

convergence group function is enabled.l You need to analyze the networking for rectifying the fault.

TC-A0184 Current Restriction Failure on the Battery Due to a Power Shelf FaultThis case describes the troubleshooting of the current restriction failure on a battery due to thepower shelf fault.



418

Fault TypeOther

Other

KeywordsMonitoring

Float charging

Fault DescriptionIn an office, the UA5000 used the PSM-B9+4860 power and four sets of batteries (12 V and100 A) in serial connection. The customer reported that the MCB often tripped after the powersupply of the telecommunications room was cut off and resumed again. The current insuranceof the MCB was AC 15 A.



l The load of the device was too heavy, causing severe power consumption.l The charging parameters of the battery were not set properly, causing excessively high

charging current of the battery.l The PSM monitoring module was faulty, causing the failure to control the charging current

of the battery.l The battery was faulty, causing excessively high charging current of the battery.l The power shelf was faulty, causing the failure to control the charging current of the battery.

Procedure

Step 1 The shelf was checked on site. It was found that only a half shelf was configured with services,and that no other power-consuming device was connected to PSM-B9+4860, indicating that thefault was not caused by excessively heavy power load on the device.

Step 2 The charging current of the battery was checked on site. It was found that the charging currentreached 50 A, revealing an obvious suspect of the fault case, namely, the excessively highcharging current. After the PSM monitoring module was checked, it was found that themonitoring module was in the normal state.

Step 3 The UA5000 was logged in and the environment monitoring condition was checked. It was foundthat the charging coefficient was set to the correct value 0.1. If the charging coefficient is set to0.1, the charging current of the battery should not be greater than 10 A. The specific results areas follows:

When the capacity of the battery set is 100 AH and the charging coefficient is configured to 0.1,the charging current should not be greater than 10 A in theory.



419

huawei(config-if-power4845-0)#display power { system<K>|environment<K>|run<K>|alarm<K>|battery-test<K> }:system { parameter<K> }:parameter Command: display power system parameter EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Even-float charging conversion control status: auto control Even charging voltage : 56.500 V Float charging voltage: 53.500 V Charging current restriction point coefficient: 0.100 Timed even charging duration: 60 days Battery count: 1 Battery 0 capacity: 100 A Upper test temperature threshold of the battery: 60°C Lower test temperature threshold of the battery: -40°C Temperature compensation coefficient: 100 mV Load power-off permit state: permitted Load power-off permit voltage: 43.500 V Battery power-off permit state: permitted Battery power-off permit voltage: 43,000 V Current divider parameters: 100 A AC over-voltage alarm threshold: 280 V AC under-voltage alarm threshold: 180 V DC over-voltage alarm threshold: 58 V DC under-voltage alarm threshold: 45 V Number of power units: 3 Address of power unit 0: 1 Control state of the switch machine of power unit 0: open Address of power unit 1: 2 Control state of the switch machine of power unit 1: open Address of power unit 2: 3 Control state of the switch machine of power unit 2: open Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (ºC) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50 ----------------------------------------------------------------------------

When the charging current is abnormal, the displayed charging status is float charging, and thecurrent of battery set 0 is 54.841 A.

huawei(config-if-power4845-0)#display power run info EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Current restriction state: not restricted Even-float charging conversion control status: auto control Charging state: float charging Load power-off permit state: permitted Load power-off permit state: permitted Number of power units: 3 Address of power unit 0: 1 Type of power unit 0: 2 Address of power unit 1: 2 Type of power unit 1: 2 Address of power unit 2: 3 Type of power unit 2: 2 Total line bank voltage: 53.090 AC voltage (V): 199.116 Total current of the unit (A): 61.232 Current of battery 0 (A): 54.841 Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (°C) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50



420

Remaining capacity of the battery: 100 % ----------------------------------------------------------------------------

When the charging current is normal, the displayed charging status is float charging, and thecurrent of battery set 0 is 0.151 A.

CH_Sima_UA5000(config-if-power4845-0)#display power run info EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Current restriction state: not restricted Even-float charging conversion control status: auto control Charging state: float charging Load power-off permit state: permitted Load power-off permit state: permitted Number of power units: 3 Address of power unit 0: 1 Type of power unit 0: 2 Address of power unit 1: 2 Type of power unit 1: 2 Address of power unit 2: 3 Type of power unit 2: 2 Total line bank voltage: 53.763 AC voltage (V): 225.553 Total current of the unit (A): 6.432 Current of battery 0 (A): 0.151 Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (°C) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50 Remaining capacity of the battery: 100 % ----------------------------------------------------------------------------

Step 4 After the PSM monitoring module was replaced, the fault persisted.

Step 5 It was hypothesized that the battery was faulty so that current restriction failed on the PSMmodule. After the battery was replaced, however, it was found that the fault persisted.

Step 6 After the power shelf was replaced, the test showed that the charging current of the battery was8.9 A, indicating that the fault was rectified.

----End


The current restriction on the UA5000 is detected by the PSM monitoring module and the controlparameters are issued by this module. However, the working circuit that actually controls thecharging current is on the power shelf. Therefore, when the power shelf is faulty, the monitoringmodule may still fail to control the charging current even though the current restrictionparameters of the monitoring module are configured correctly, as the fault described in this case.

TC-A0213 Fault on a Newly Added Shelf Due to Incorrect HW Cable Type

This case describes the troubleshooting of the fault on a newly added shelf because the type ofthe in-use HW cable was incorrect.

Fault Type

Other

Other



421

KeywordsRSP fault

HW cabling

PV8

Fault DescriptionAll the boards on the newly added RSP shelf under the PV8 shelf were faulty.



l The data configuration was incorrect.l The HW cable was connected incorrectly.l The DIP switch of the RSP control board was configured incorrectly.l The service board was faulty.l The backplane was faulty.

Procedure

Step 1 The data configurations were correct.

Step 2 The HW cable was connected in a right place after checking on site. The HW cable was removedand then installed back. However, the fault persisted.

Step 3 The second bit of the RSP control board SG1 was on, and then the RSP board was reset. It wasfound that the fault persisted.

Step 4 The RSP was normal before the active and standby RSP boards were configured. Therefore, thefault was not caused by the control board and the backplane.

Step 5 It was confirmed by the field engineer that only the HW cable was newly configured. The HWcable was suspected to be faulty. After checking, it was found that the cable configuration typeof the H301PV8 control board was improper (BOM code: 04027873, used for H302PV8 board)

Step 6 After the HW cable (material code: 04024260, used for H301PV8 board) was replaced, the faultwas removed.

----End

Suggestions and SummaryPay attention to the selecting of cable types because the RSP shelf was connected to the controlboard H301PV8.l The HW cable used for H302PV8 board is 04027873 (BOM). BOM description: single

Cable of -02PV8 differential HW Cable.



422

l The HW cable used for H301PV8 board is 04024260 (BOM). BOM description: singleCable of -PV8-RSP booting differential cable.

TC-A0255 Failure to Add a Traffic Entry Due to a Rate Level Absence in the RateTable

This case describes how to troubleshoot a failure to add a traffic entry on the UA5000 becausethere is no rate level corresponding to the traffic entry in the rate table on the device.

Fault Type

Other

QoS

Keywords

Traffic management

Traffic level

QoS

Fault Description

A user creates a traffic entry whose priority value is 4 and rate is 3072 kbit/s on the UA5000.After data configuration, however, the rate of the traffic entry is changed to 6000 kbit/s.

Alarm Information


Cause Analysis

There is no rate level corresponding to the traffic entry in the rate table.

Procedure

Step 1 Run the display rate table row command to query the traffic levels in the rate table. It is foundthat there is no rate level corresponding to rate 3072 kbit/s in the rate table, and therefore therate is changed to 6000 kbit/s.

Step 2 Create a traffic entry with a priority value of 4 and a rate of 3072 kbit/s.1. Run the modify rate table row 128 3072 command to change rate level 128 kbit/s to 3072

kbit/s.2. Run the traffic table command to create a traffic entry with a priority value of 4 and a rate

of 3072 kbit/s.3. Run the display traffic table command to query the traffic entry. It is found that the actual

traffic entry data is the same as the created data, indicating that the fault is rectified.

----End



423

Suggestion and SummaryWhen adding a traffic entry on the UA5000, ensure that the corresponding rate level is availablein the rate table. Otherwise, the rate level will be changed to a value that is in the rate table.

16.2 By Feature

16.2.1 VoIP ServiceThis topic provides the analysis of the cases related to the VoIP service.

TC-A0010 The UA5000 Fax Service Fails Due to Low Port GainThis topic describes how to troubleshoot the fault when the UA5000 fax service fails due to lowport gain.


Service exception

Phenomenon Descriptionl Networking: UA5000 -> universal media gateway (UMG) -> IP network -> softswitchl The UA5000 and the UMG communicate with each other through the V5 interface. Services

go upstream to the IP network after conversion in the UMG. In this networking mode, whenthe fax mode is set to V2 or V3 transparent transmission, the service is successful. Whenthe fax mode is set to T.38, the fax service fails.



l The fax terminal is faulty. The fax finally fails because the negotiation between the twofax terminals fails.

l Due to network factors, the negotiation signal is damaged, and finally the fax service fails.

Procedure

Step 1 The fax service can be transparently transmitted normally. This indicates that the fault is notcaused by the fax terminal.

Step 2 According to analysis on the UMG side, the UMG receives a fax signal from the UA5000 butthe UMG considers the weak signal as an echo signal and filters it. As a result, the fax fails.

Step 3 After the fault cause is located, run the following commands:



424

huawei(config-esl-user)#display pstnport attribute 0/7/0 huawei(config-esl-user)#pstnport attribute set 0/7/0 voicegain 0

Adjust the port gain, that is, set the receive gain to 0 dB and the transmit gain to –3.5 dB. Then,the fault persists.

Step 4 Re-adjust the gain to 5. Set voicegain to 5, that is, set the receive gain to 3 dB and the transmitgain to –12 dB. Then, the fax service is in the normal state and the fault is rectified.

Step 5 Re-adjust the gain by running the following commands. Set voicegain to 5, that is, set the receivegain to 3 dB and the transmit gain to –12 dB. Then, the fax service is in the normal state and thefault is rectified.huawei(config-esl-user)#display pstnport attribute 0/7/0 huawei(config-esl-user)#pstnport attribute set 0/7/0 voicegain 5

----End

Suggestion and SummaryIf a problem relates to the interconnecting with the product of another vendor, it is necessary tolearn the requirement of the product on the UA5000. Then, make adjustments accordingly tosolve the problem quickly.



Fault TypeOther

Board fault

Board fault alarm


LED RUN

Fails to work

PVMB





425


l The hardware of the service board is faulty.l The NE software and board software do not match.l The ± 5 V power supply for the narrowband service board is abnormal.l The 48 V power supply is abnormal.l The control board or the backplane is faulty.

Procedure







----End

Suggestion and SummaryNone




Service exception

KeywordCLIP



426

Abnormal CLIP

Protective unit


About 20 commercial subscribers of the AG report that abnormal CLIP occurs frequently (6 to8 out of 10 times).

Alarm Information

None

Cause Analysis



l An error occurs when the softswitch is processing the CLIP.

l An error occurs when the bearer network transmits the phone number.

l Processing operations is faulty inside the AG.

l The link is faulty.

l The ODF and the protective unit are faulty.

Procedure







----End





427

TC-A0024 The UA5000s in Different VLANs Cannot Communicate with EachOther Due to Configuration Errors in Subnet Masks

This topic describes how to troubleshoot the fault when the UA5000s in different VLANs cannotcommunicate with each other due to configuration errors in subnet masks.


Service exception

KeywordPing

Subnet

Service failure

Phenomenon Descriptionl Networking: UA5000 -> MA5680T -> switch -> routerl Fault phenomenon: The gateway of the UA5000 is on the switch. The UA5000s of VLAN

301 cannot communicate with or ping the UA5000s of VLAN 302; however, all theUA5000s of these two VLANs can normally call other devices.


Cause AnalysisIn this networking mode, the possible causes are as follows:

l The data configuration of the switch interface is incorrect.l The data configuration of the softswitch is incorrect.l The IP address of the UA5000 is configured incorrectly.

Procedure

Step 1 Check the data configurations of the two VLANs on the switch. No abnormality is found. Thisindicates that the fault is not caused by the data configuration of the switch.

Step 2 All the UA5000s of the two VLANs cannot ping each other, and therefore the fault is locatedon the route or the data link layer. Check the data configuration of the softswitch, but noabnormality is found. This indicates that the fault is not caused by the data configuration of thesoftswitch.

Step 3 Check the data configurations of the UA5000s. It is found that the subnet mask of the UA5000sof VLAN 301 is 255.255.255.0 and the subnet mask of UA5000s of VLAN 302 is255.255.255.192. After confirmation with the customer, it is learned that the planned subnetmask is 255.255.255.192. In the earlier stage, attention is not paid to the subnet mask



428

configuration of the UA5000s of VLAN 301, which results in this fault. Change the subnet maskof VLAN 301 to 255.255.255.192. Then, the fault is rectified.

----End

Suggestion and SummaryWhen configuring UA5000s, pay attention to the customer′s data plan. Configure the data forsubnet planning in strict accordance with the data plan. Otherwise, unexpected problems mayoccur.

TC-A0030 Busy Tone Is Played in the Outgoing Callings of the Intelligent PayPhone Due to the Incorrect Parameter Settings of the MG Interface Software

This topic describes how to troubleshoot the fault when busy tone is played in the outgoingcallings of the intelligent pay phone due to the incorrect parameter settings of the MG interfacesoftware.


Service exception

KeywordIntelligent pay phone

Busy tone

Phenomenon Descriptionl Networking: UA5000 -> switch -> softswitchl Fault phenomenon: The incoming and outgoing calls of the common subscribers are normal

but the busy tone is played in the outgoing calls of the intelligent pay phone.


Cause AnalysisThe matching mode between the digitmap issued by the softswitch and the default digitmap ofthe UA5000 is incorrect.

Procedure

Step 1 Trace the message on the UA5000. It is found that after the subscriber dials a complete number,the UA5000 reports only four digits, that is "4445", and the digitmap matching mode is completematch. Therefore, the digitmap matching mode of the UA5000 may be incorrect.

Step 2 Run the display mg-software parameter command to query the maximum digitmap matchingflag parameter of the MG interface. It is found that the maximum digitmap matching flagparameter value of the MG interface is 0, indicating "minimum match". Run the mg-software



429

parameter command to change the value of the parameter to 1, indicating "maximum match",and then the outgoing call of the intelligent pay phone is in the normal state.

----End

Suggestion and SummaryWhen a device in a new office is faulty, in the case of the board providing the service, checkwhether the basic configurations of the device are correct, and then check whether the matchingmode between the UA5000 and the softswitch is correct.

TC-A0031 The Calling Party of an IP Public Telephone Is Not Charged Because thePolarity Reversal Pulse Attributes for the PSTN Port Is Not Set

This topic describes how to troubleshoot the fault when the calling party of an IP public telephoneis not charged because the polarity reversal pulse attributes for the PSTN port is not set.


Service exception

KeywordIP public telephone

Polarity reversal pulse

Phenomenon DescriptionA UA5000 is deployed in an office. When the polarity reversal service is provided to thesubscriber, the called party of the IP public telephone is charged and the calling party is notcharged.


Cause AnalysisThe polarity reversal pulse attributes for the corresponding PSTN port on the UA5000 is not set.

Procedure

Step 1 Check the service board. It is found that the service board is CC0HASL, port 16 is enabled toprovide the polarity reversal service, and the port supports the polarity reversal feature.

Step 2 Replace the accounting terminal, and the fault persists.

Step 3 Check the configuration data of the UA5000. It is found that only the polarity reversal accountingfunction of the PSTN port for the subscriber is enabled. After the pstnport reversepole_pulseset command is executed to set the polarity reversal pulse attributes for the PSTN port, the faultis rectified.



430

NOTE

By default, the width of the high-level pulse of the PSTN port is 300 ms.

----End

Suggestion and SummaryWhen a device in a new office is faulty, first check whether the basic configurations of the deviceare correct in the case of the board providing the service.

TC-A0035 Services of Certain ASL Boards in the ONU1000 Cabinet Are Interruptedat Random Because the H302ESC Board Is Faulty

This topic describes how to troubleshoot the fault when services of certain ASL boards in theONU1000 cabinet are interrupted at random because the H302ESC board is faulty.

Fault TypeOther


KeywordH302ESC

At random

Not fixed

ONU1000

Phenomenon Descriptionl Networking: optical line terminal (OLT) -> built-in transmission device -> built-in

transmission device in remote equipment room -> optical network unit (ONU)l Each RSP-19 shelf is fully configured with ASL boards and an RSP board. Certain boards

in the three RSP-19 shelves are faulty at random and the frequency is every one to twohours. Services of the faulty ASL boards are abnormal and recover after approximately oneminute.

l On the BMS, certain ASL boards in the three RSP-19 shelves are faulty at random, that is,the ASL boards that are faulty on the BMS are not fixed each time.



l The RSP board is faulty.l The ASL boards are faulty.



431

l The data configuration is incorrect.l The power supply of the -48 V voltage is unstable.l Loops or short circuits exist in the loop line.l The TSS board is faulty.l The grounding resistance of the cabinet is very large.l The backplane of the shelf is faulty.l The transmission device or E1 cable is faulty.l The H302ESC board is faulty.

Procedure

Step 1 Replace the RSP and ASL boards. The fault, however, persists.

Step 2 Check the data. No exception is found. In addition, no data is set in recent months.

Step 3 Check the transmission BMS. No alarms on the ONU1000 and E1 exception are generated.

Step 4 Check the voltage of the power supply. The voltage is 53.5 V, which indicates that the powersupply is normal.

Step 5 Replace the TSS board. The fault, however, persists. Check the data on the OMC and checkwhether the data of the host and the BAM is consistent. It is found that the data is correct andthe data of the host and the BAM is consistent. Check the operation log. It is found that onlymultiple records about adding the data of A32 boards exist in the log. Delete the added data ofthe A32 boards.

Step 6 Measure the grounding resistance of the cabinet. It is found that the result is normal.

Step 7 Test whether loops and short circuits exist in the loop line. No exception is found.

Step 8 Check the components of the H302ESC board. It is found that certain components on the boardare damaged. After the components are replaced, the fault is rectified.

NOTE

The H302ESC board uses the -48 V voltage of the cabinet, and then directly monitors the voltage andcurrent of the cabinet. If the H302ESC board is faulty, the power supply system of the shelf may be affectedand the power supply for the shelf is unstable. In this case, services are affected.

----End

Suggestion and SummaryTo save the time for locating the fault when multiple boards are faulty at random, it isrecommended that you first check whether the components of the board are damaged.

TC-A0078 A Large Number of UA5000 Users Go Offline Because the Upper-LayerSoftswitch Processes the H.248 Messages Incorrectly

This case describes how to troubleshoot the fault wherein a large number of UA5000 users gooffline because the upper-layer softswitch processes the H.248 messages incorrectly.

Fault TypeOther



432

Service exception

KeywordDatabase

Configuration file

Fault Descriptionl Networking: UA5000 -> switch -> softswitchl Fault description: On a newly-deployed site, all the users are connected normally, but a

large number of users go offline during calls. The symptom is relieved after the active andstandby PVM boards of the UA5000 are switched over. The fault, however, recurs one daylater.



l The quality of the bearer network is poor.l The softswitch is faulty.

Procedure

Step 1 The display h248statics command is executed to check the send-and-receive information aboutthe H.248 messages. It is found that the numbers of re-sent and re-received H.248 messages areincreasing.

Step 2 The packets are pinged to check the quality of the bearer network. It is found that the networktransmission condition is good, no packet is lost, and no packet with long delay is transmitted.

Step 3 The H.248 messages are traced. It is found that the UA5000 sends a large number of user on-hook messages.

Step 4 The on-hook messages are further analyzed. It is found that the transaction IDs (TIDs) in theon-hook messages are different from the TIDs of the current calls. In addition, it is found that alarge number of on-hook messages are constantly sent with the TIDs corresponding to the portsthat do not carry any calls. After the analysis of the messages for the current calls, it is foundthat the UA5000 fails to receive the acknowledge messages from the softswitch after sendingthe on-hook messages. Therefore, it is determined that the UA5000 constantly retransmits theon-hook messages because the upper-layer device processes the messages incorrectly.

Step 5 The softswitch is upgraded by the maintenance personnel through a patch. Then, it is found thatthe fault is rectified.

----End




433

TC-A0054 The Fault Wherein No Tone Is Played After Offhook Frequently Occurson the UA5000 Users Because the HSCI Board of the Softswitch Is Faulty

This case describes how to troubleshoot the fault wherein no tone is played after offhookfrequently occurs on the UA5000 users because the HSCI board of the softswitch is faulty.


Service exception

KeywordPacket loss

HSCI board

Fault Descriptionl Networking: Phone of the user -> UA5000 -> softswitchl Fault description: The fault wherein no tone is played after offhook frequently occurs on a

great number of users.



l The network quality is poor.l The softswitch fails to send the dial tone event correctly.l An error occurs during the interconnection of the H.248 protocol between the softswitch

and the UA5000.l The board of the softswitch is faulty.

Procedure

Step 1 The ping command is executed on the UA5000 to send 1000 ping packets to the softswitch. Ifit is found that no packet is lost and the delay is normal, it indicates that fault is not caused bythe network quality problem.

Step 2 The packets are captured on the softswitch and the UA5000 and then the packet capture resultsare compared.1. The analysis of the packets captured on the UA5000 is as follows: After the UA5000 sends

the offhook signal, the softswitch issues a dial tone event signal cg/dtu, rather than cg/dt.The UA5000, however, cannot identify the cg/dtu signal because cg/dtu is not a descriptordefined in the H.248 protocol. Therefore, the UA5000 fails to issue the dial tone. In addition,the softswitch sends five MODIFY packets consecutively to continue issuing the dial tone,because it fails to receive the response from the UA5000.



434

2. The analysis of the packets captured on the softswitch is as follows: After the UA5000 usertakes the phone off the hook, the softswitch sends five MODIFY packets consecutively toissue the dial tone to the user, and the dial tone event is cg/dt. Then, the re-transmissionmechanism is triggered because the UA5000 fails to reply. After sending five MODIFYpackets consecutively, the softswitch stops issuing the dial tone. The debug information iscaptured to analyze the fault causes. It is found that a packet is issued incorrectly duringthe packet distribution process because the HSCI board is faulty.

Step 3 After the HSCI board is replaced, the fault is rectified.

----End

FAQQuestion: Why the signaling traced by the softswitch is different from the signaling traced bythe UA5000? (The network packets captured on the AG, namely the UA5000, through theETHEREAL tool indicates that the received dial tone signal is cg/dtu, whereas the signal tracedby the softswitch through the network management software is cg/dt.)

Answer: The signaling traced by the UA5000 is analyzed based on the packets that are capturedthrough the universal packet capture tool, rather than based on the internal signaling of theUA5000. Therefore, the credibility of the analysis on the basis of the captured packets is high.The softswitch uses the module-based design so that different modules perform differentfunctions. The signaling traced by the softswitch is the signaling sent by the protocol processingmodule. However, when this signaling is normal, it does not mean that the signaling sent by thesoftswitch is certainly normal.

TC-A0058 The Intelligent Public Telephone Service Fails Because the SoftswitchIssues an Improper Digitmap

This case describes how to troubleshoot the fault wherein the intelligent public telephone (IPT)service fails because the softswitch issues an improper digitmap.


Service exception

KeywordCharging

Fault Descriptionl Networking: UA5000 -> EPON access device -> bearer network -> softswitchl Fault description: After the normal IPT service of an office is cut over to the UA5000,

outgoing calls cannot be made. After the offhook, a voice message is played prompting theuser to query the call charge first. Then, the busy tone is played, which indicates that thecall is disconnected automatically.




435


l The polarity reversal settings of the UA5000 are incorrect.l The number collection function of the UA5000 is abnormal.l The IPT phone is faulty.l The UA5000 fails to cooperate with the IPT phone normally.

Procedure

Step 1 The display pstnport attribute command is executed to check whether the UA5000 isconfigured with the polarity-reversing pulse attribute. It is found that the polarity reversalsettings of the device are correct.

NOTE

Polarity-Reverse indicates whether the polarity-reversing pulse is supported. The values are as follows:

l Not supported: Polarity-reversing pulse is not supported.

l Supported: Polarity-reversing pulse is supported.The default value is "Not supported".

Step 2 As indicated by the voice message, the user cannot dial the number because the call detail record(CDR) of the previous call is not downloaded after the communication is complete. After theCDR is cleared, the test shows that the call can be made successfully but the call charge is notdisplayed after the communication is complete. Therefore, the fault is considered to be causedby the failure to query the call charge.

Step 3 Packets are captured through a packet capture tool, the captured data is restored to a voice filethrough the audio processing software CAPSEN, and then the whole process of dialing,communication, and onhook over the IPT phone is analyzed through the COOLEDIT audioprocessing tool. It is found that the whole process is normal. After the communication iscomplete, however, it is found that the IPT phone reports 45549 and 11#, at an interval less than4s.

NOTE

The digitmap {([2-8]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|F|x.F|[0-9].L)} issued by thesoftswitch is analyzed. From the digitmap, it is found that the UA5000 sends 4554911 as a single unit(sends the numbers consecutively) to the softswitch because a digitmap for accurately matching 45549 isnot available. The softswitch considers 4554911 as a phone number and thus sets up a call. As a result, thequery of the call charge by the IPT phone fails. Furthermore, in each subsequent call initiated by the IPTphone, the intelligent platform plays a voice message prompting the user to query the call charge first, andhence the outgoing calls cannot be made.

Step 4 In this case, the cause of the fault is that the timer for starting the match between the digitmapissued by the softswitch and the number 45549 dialed on the IPT phone is set too long. To rectifythis problem, you can re-plan the digitmap on the softswitch to shorten the duration of matchingthe phone number 45549. You can also run the h248stack command on the UA5000 to changethe previously-mentioned timer to 3s, because the digitmap on the softswitch takes effectglobally.

----End

Suggestions and SummaryThe general procedure of the IPT service is as follows:



436

l Before the user dials the number after picking the phone off the hook, the IPT phoneautomatically reports access code 45549 and connects to the intelligent platform.

l The user dials the number and makes a call.l After the communication is complete, the user places the phone on the hook and the IPT

phone automatically reports 45549 and 11# to the upper-layer device. 45549 is theintelligent access code, and 11# is sent to the intelligent platform for querying the callcharge.

TC-A0059 The Services of Users Connected to the AG Are Frequently InterruptedTemporarily Because the Router Updates the MAC Address Table Periodically

This case describes how to troubleshoot the fault wherein the services of users connected to theAG are frequently interrupted temporarily because the router updates the MAC address tableperiodically.



KeywordInterconnection

ARP binding

Fault Descriptionl Networking: User terminal -> UA5000 -> Ethernet switch (S6506R) -> router (C7609) ->

softswitchl Fault description: A temporary communication interruption for several seconds frequently

occurs on users connected to the UA5000 of an operator. This symptom does not occur ineach communication.



l The quality of the subscriber line is poor, which results in the loss of certain voice signals.l The UA5000 is faulty.l The Ethernet switch is faulty, which results in the packet loss.l Network congestion occurs on the router, which results in the packet loss.

Procedure

Step 1 The line maintenance personnel working with the operator confirm that the subscriber line isalready replaced, but the fault persists. This indicates that the subscriber line is normal.



437

Step 2 The data of the uplink port is mirrored and the packets are captured through the Wireshark tool.The software analysis of the captured packets shows that the packet loss occurs at a certain time.Therefore, it can be determined that the fault is caused by the packet loss.

Step 3 The analysis of the time difference of the packet loss shows that the packet loss occurs regularly.The alarms and user data configuration on the UA5000 are checked. If the check result showsthat the alarms and data configuration are normal, it indicates that the UA5000 is normal.

Step 4 The associated alarms and data configuration on the Ethernet switch are checked. It is found thatthe alarms and data configuration are normal. This indicates that the switch is normal.

Step 5 The maintenance personnel are contacted to check the router. It is found that the router is enabledwith a function of periodically updating the MAC address table, and that the updating period isbasically consistent with the packet loss interval displayed in the package capture result.

Step 6 The static ARP binding function is configured on the corresponding port on the router. Then,the voice communication of the users is tested multiple times. The test result shows that thecommunication is normal. Thus, the fault is rectified.

----End

Suggestions and SummaryThe causes of such temporary communication interruption problems can be quickly locatedthrough the packet capture analysis.

TC-A0168 Occasional Absence of Dial Tone After Offhook Due to Packet LossThis case describes the troubleshooting of the occasional absence of dial tone after offhook,which occurred on the user of a UA5000. The fault occurred due to the packet loss on the network.


Packet loss

KeywordPacket loss on the network

Fault DescriptionNetwork topology: UA5000 -> OLT (MA5680T) -> router -> softswitch

Fault symptom: After the user of the UA5000 took the phone off the hook, there wouldoccasionally be no dial tone, even though the power feed was normal. The service would bespontaneously restored after a certain period of time.

Alarm InformationAn alarm "QOS Exceeds Threshold Alarm" was displayed on the HyperTerminal.




438

l Packets loss occurred on the network.

l The DSP daughter board was faulty.

Procedure

Step 1 The alarm history on the device was checked. No DSP chip fault alarm was found, indicatingthat the DSP resource allocation was normal.

Step 2 The softswitch was pinged from the UA5000. Occasional packet loss was found.huawei(config)#ping 101.144.82.114 PING 101.144.82.114: 56 data bytes, press CTRL_C to break Reply from 101.144.82.114: bytes=56 Sequence=999 ttl=28 time=2 ms

--- 101.144.82.114 ping statistics --- 100 packet(s) transmitted 999 packet(s) received 0.10% packet loss round-trip min/avg/max = 2/2/5 ms

Step 3 Packets were captured on the UA5000. The analysis showed that the user was not released bythe softswitch but was still in the previous context when the fault occurred. The result was thatthe softswitch failed to send a dial tone when the user took the phone off the hook. The suspectedcause of the fault was that the port status on the softswitch and the port status on the AG wereinconsistent because of the loss of the detection event sent after the user hung up at the end ofthe previous call. The detection event loss was caused by the packet loss in the last call.

Step 4 The fault was rectified by executing the if-h248 attribute command on the UA5000 to changethe transmission protocol to UDP, and the h248stack command to change the transmission modeto fixed retransmission mode. The commands for the two operations are as follows:huawei(config-if-h248-0)#if-h248 attribute transfer alf/udphuawei(config-if-h248-0)#h248stack tr retransmode fixed 1000

----End


When a packet loss alarm is generated on the network, the first consideration is to troubleshootnetwork problems, which is a fundamental measure to resolve the problem. If packet loss onlyoccurs occasionally, and the loss is not critical, the fault can also be rectified by setting theredundancy transmission mode on the UA5000.

TC-A0170 Occasional Failure of Call Service on a UA5000 (Calling Party HeardBusy Tone, Called Party Heard No Ringing Tone) Due to Softswitch SendingMobile Codec

This case describes the troubleshooting of the occasional call service failure (the calling partyheard busy tone and the called party heard no ringing tone) that occurred on a UA5000 due tothe sending by the softswitch of a mobile codec.

Fault Type

Narrowband service

Service abnormality



439

KeywordER=500

Fault DescriptionWhen the UA5000 interconnected with the softswitch, the call service occasionally failed.Specifically, the calling party received a busy tone whereas the phone of the called party did notring. Through signal tracing, it was found that, at the time of the service failure, the UA5000was responding to the softswitch with an ER=500 message ("Internal software failure in theMG").



l The signaling sent by the softswitch was incorrect.l Certain functions supported by the softswitch were not supported by the UA5000.

Procedure

Step 1 Signaling tracing was used to capture packets. The captured information was as follows:!/1 [10.9.39.43] T=742097942{C=${A=line1178{M{O{MO=SR,tdmc/ec=on}}},A=${M{O{MO=SO},L{v=0c=IN IP4 $m=audio $ RTP/AVP 0 8 97 98 99 100 18 4 101 102 96a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:97 G726-40/8000a=rtpmap:98 G726-32/8000a=rtpmap:99 G726-24/8000a=rtpmap:100 G726-16/8000a=rtpmap:18 G729/8000a=rtpmap:4 G723/8000a=rtpmap:101 AMR/8000a=rtpmap:102 AMR/8000a=rtpmap:96 telephone-event/8000},R{v=0c=IN IP4 10.9.33.181m=audio 35072 RTP/AVP 0 8 97 98 99 100 18 4 101 102 96a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:97 G726-40/8000a=rtpmap:98 G726-32/8000a=rtpmap:99 G726-24/8000a=rtpmap:100 G726-16/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:4 G723/8000a=fmtp:4 annexa=noa=rtpmap:101 AMR/8000a=rtpmap:102 AMR/8000a=rtpmap:96 telephone-event/8000a=sendrecv}}}}}K{742097941}!/1 [10.40.36.6]:2944 P=742097942{ER=500{"Internal software failure in the MG"}}

Step 2 Analysis of the captured information revealed that the signaling sent by the softswitch when theuser under the UA5000 was called a second time was different from the signaling sent when theuser was called the first time. The signaling sent the second time carried not only 2833



440

negotiation information, but also parameter a (a=rtpmap:101 AMR/8000), which was used forquerying whether a mobile codec was supported. It was confirmed that the singling was correctand that the AMR mobile codec was supported by the H.248 protocol. However, the UA5000did not support negotiation based on a mobile codec, because the users connected to the UA5000were not mobile terminal users. Therefore, a mobile codec was of no significance for theUA5000.

Step 3 After the softswitch maintenance engineer was advised to delete the mobile codec, the fault wasrectified.

----End


None

TC-A0223 Service Interruption Due to Repeated Resets of the MG Interface

This case describes the troubleshooting of a service interruption due to the repeated resets of themedia gateway (MG) interface.

Fault Type

VoIP service


Keyword

MG interface fault

Fault Description

When the H.248 protocol was used and the MG interface was configured, the MG interface wasreset repeatedly.

Alarm Information

None

Cause Analysis

According to the fault symptom, the possible causes were as follows:l The data configuration of the MG interface was incorrect.l The interconnection between the MG interface and the media gateway controller (MGC)

was faulty.

Procedure

Step 1 The signaling message of the MG interface was analyzed. It was found that each time a heartbeatmessage was retransmitted, the interface was reset.



441

Step 2 The status of the transaction reliability switch of the protocol stack parameter was checked. Itwas found that the switch was turned off.

Step 3 The heartbeat parameter configured in the system was checked. It was found that the heartbeatparameter was set to 5 seconds, which was the minimum value in the heartbeat detection.

Step 4 The transaction retransmission mode was checked. It was found that the transactionretransmission mode was T-MAX and the retransmission time was 10 seconds. The T-MAXretransmission time is to the duration for retransmitting a transaction when the transmission ofthe transaction fails.

NOTEThe transaction retransmission time was 10 seconds whereas the heartbeat message was sent every 5 seconds.When there was a network jitter and the heartbeat message was lost, the remaining time was insufficient forretransmitting the transaction. Therefore, the MG interface was reset immediately after the message wasretransmitted once.

Step 5 The retransmission time was set to 25 seconds (default value), which was twice longer than theheartbeat detection time. That is, the fault was rectified.

----End


It is recommended that you use the default settings when configuring the MG interface. Changethe default settings only when required.

16.2.2 xDSL ServiceThis topic provides the analysis of the cases related to the xDSL service.

TC-A0179 Error 678 Displayed During Internet Access Through Dialup Due toIncorrect Setting of Service Port Status

This case describes the troubleshooting of error 678 that was displayed during dialup Internetaccess through a UA5000 due to incorrect setting of the service port status on the UA5000.

Fault Type

xDSL service

Service exception

Keyword

act/up

deact/dn

Fault Description

After a UA5000 was configured with a new ADSL user in the capacity expansion, the on-sitedialup test showed that the Internet access of the new user failed. In addition, error 678 wasdisplayed when the fault occurred.



442



l The upstream link on the control board was inaccessible.l The configuration of the service VLAN was incorrect.l The subscriber line was faulty.l The port configuration of the UA5000 was incorrect.

Procedure

Step 1 Given that the services on the preceding boards in the same shelf operated normally, indicatingthat the ADSL service expansion on the UA5000 did not affect the original service, it wasdetermined that the upstream link on the control board of the device was normal.

Step 2 Given that the services on other ADSL ports in the same shelf as the affected port were normal,it was determined that the service VLAN configuration for the user was correct, because thedata plan requires that the ADSL services carried on the same shelf use the same service VLAN.

Step 3 The ADSL port information was queried after a modem was connected to the port. It was foundthat the port could be activated normally, indicating that the subscriber line was normal. Thequery result was as follows:huawei(config)#display board 0/7 ------------------------------ Board nane : H603ADRB Board status : Normal Online status : - ----------------------------------------------------------------------------- Port Port Type Port Status Line Profile Alarm Profile Extended Profile ----------------------------------------------------------------------------- 0 ADSL Being activated 1 1 -- 1 ADSL Being activated 1 1 -- 2 ADSL Activated 1 1 -- 3 ADSL Being activated 1 1 --

NOTE


Step 4 The display service-port command was executed to query the service stream configuration onthe port. It was found that the port was configured with a service. The query result was as follows:huawei(config)#display service-port board 0/7 { <cr>|groupindex<K> }: Command: display service-port board 0/7



443

---------------------------------------------------------------------------- VLAN VLAN attribute port shelf/slot/port VPI VCI service type parameter RX TX status flag ---------------------------------------------------------------------------- 207 common adl 0/ 7/ 0 0 35 - - 6 6 deact/dn - 207 common adl 0/ 7/ 1 0 35 - - 6 6 deact/dn - 207 common adl 0/ 7/ 2 0 35 - - 6 6 deact/dn -

NOTE


The command output showed that the service management status of the affected port was deact/dn, whereas the service management status of a normal port should be act/up. Therefore, it washypothesized that the service port was configured to deactivated state, resulting in the dialupconnection failure.

Step 5 After the activate service-port all was executed to activate all the service ports, it was foundthat the Internet access by the user through dialup was normal.

----End


None

16.2.3 Ethernet ServiceThis topic provides the analysis of the case related to the Ethernet service.

TC-A0079 The Webpage Cannot Be Opened Because the Data Configuration of theIPMB Board Is Incorrect

This case describes how to troubleshoot the fault wherein the webpage cannot be opened becausethe data configuration of the IPMB board is incorrect.

Fault Type

xDSL service

Service exception

Keyword

Internet access

Fault Descriptionl Networking: UA5000 (IPMB) -> layer-2 switch -> access server (5200F)

l Fault description: A new private line service is provided for the UA5000 users. After theservice provisioning, the users can dial up successfully but cannot open the webpages. TheInternet access service of the ordinary PPPoE users, however, is normal.



444



l The configuration of the traffic profile of the IPMB board is incorrect.l The ports on the service board are faulty.l The traffic restriction configuration on the upper-layer device is incorrect.

Procedure

Step 1 The data configuration on the IPMB board of the UA5000 is checked. It is found that the trafficrestriction parameters are not configured in the traffic profile. Then, the traffic profile is changedto 2M, 4M, and 10M profiles, and each profile is re-activated. It is found that the fault persists.

Step 2 The VLAN configuration of the private line service is checked. It is found that the VLANconfiguration is correct and the upper-layer device can transmit the VLAN packets transparentlywithout traffic restriction. A PC is directly connected to the layer-2 switch to test the Internetaccess service. It is found that the service is normal. This indicates that the PC and the upper-layer device are normal.

Step 3 An attempt to log in to QQ, a type of instant messaging software, is made. It is found that thelogin is successful. Therefore, it is considered that the IPMB board may filter the Internet accessTCP packets in the private line service.

Step 4 The access control list (ACL) configured on the device is checked. It is found that the list containssuch a rule, namely, rule 1 deny tcp (0 times matched). The application of this rule filters theTCP packets. After this rule is deleted, the test shows that the Internet access service is normal.

----End


TC-A0080 The Network Port Cannot Work Normally Because the Working Modeof the Uplink Port on the H601PVMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the network port cannot work normallybecause the working mode of the uplink port on the H601PVMD board is incorrect.


Service exception

Keywordup-linkport



445

Fault Descriptionl Networking: UA5000 -> transmission device -> router (NE40E) -> switch (S3528) ->

softswitchl Fault description: A UA5000 uses the ETH1 port on the H601PVMD control board to

transmit services. After the network cable is inserted into the ETH1 port on the controlboard, the indicator of the ETH1 port is off.


Cause AnalysisThe possible cause is as follows:

l The network cable is faulty.l The network port is down because it does not match the working mode of the uplink port.

As a result, the service fails.

ProcedureStep 1 The network cable connected to the ETH1 port is removed and inserted into the network interface

card (NIC) of a portable PC. It is found that the indicator of the NIC is on. This indicates thatthe fault is not caused by the network cable.

Step 2 The UA5000 is logged in and the display fe active eth1 command is executed to check the statusof the ETH1 port. The command output is as follows:huawei(config)#display fe active eth1 link state:down config mode:100M Full duplex

Step 3 The display working mode command is executed to check the working mode of the board. Thecommand output is as follows:huawei(config)#display working mode working mode:alone outband port:ETH port service port:GE optic port

Step 4 It is found that the network port on the service board is a GE optical port. Then, the up-linkportset workmode command is executed to change the working mode of the uplink port. After thechange, it is found that the network port works normally and the service is restored.huawei(config)#up-linkport set workmode eth1

----End

Suggestions and SummaryWhen the H601PVMD board is used in the deployment of the UA5000, you must change theworking mode of the uplink port according to the actual conditions.

TC-A0091 Apple PC Fails to Access the Internet Through Dialup After the UA5000Is Enabled with the PITP (V Mode) Function

This case describes how to troubleshoot the fault wherein Apple PC fails to access the Internetthrough dialup after the UA5000 is enabled with the PITP (V mode) function.



446

Fault Type

xDSL service

Service exception

Keyword

PITP

Dialup failure

Fault Description

The broadband users of a UA5000 find that if they use the Apple MAC OS or Apple airportbroadband router, the access to the Internet fails.

Alarm Information

None

Cause Analysis


l The layer 2 link, namely, the link between the user PC and the broadband remote accessserver (BRAS), is faulty.

l The BRAS authentication fails.

Procedure

Step 1 A dialup test is performed on the user side. It is found that the Internet access through all thePCs installed with the Microsoft Windows XP OS can be successful. This indicates that the layer2 link is normal.

Step 2 The Apple PC is used to dial up and at the same time the packets are captured. It is found thatthe PPPoE dialup is terminated by the PADT packet sent by the PC during the dialup. Theanalysis of the captured packets shows that the "LC configuration request" packet is receivedby the Apple PC before the PADS packet. In this case, the Apple OS considers that the proceduredoes not comply with the protocol and therefore sends the PADT packet to terminate the dialupconnection.

Step 3 After receiving the PADR packet, the BRAS sends the "LC configuration request" packet at thesame time of responding the PC with the PADS packet. The PADS packet, however, needs tobe processed by the CPU of the UA5000 because the UA5000 is enabled with the PITP (V mode)function. As a result, the "LC configuration request" packet arrives at the PC before the PADSpacket.

Step 4 After the PITP function is disabled on the UA5000 or the "LC configuration request" packet issent by the BRAS with a delay, the fault is rectified.

----End



447

Suggestions and SummaryTo delay the time of sending the "LC configuration request" packet by the BRAS, you canconfigure the "ppp delay-lcp-negotiation" function on the BRAS in VT mode.

TC-A0115 The 678 Error Is Displayed During the Dialup of Broadband UsersConnected to the UA5000 Because the Wire Sequence of the Upstream Straight-Through Cable Is Incorrect

This case describes how to troubleshoot the fault wherein the 678 error is displayed during thedialup of broadband users connected to the UA5000 because the wire sequence of the upstreamstraight-through cable is incorrect.


Service exception

KeywordWire sequence of the straight-through network cable

678 error

Fault DescriptionNetworking: UA5000 (IPMB) -> SDH -> OSN3500 -> 6650 -> MA5200G

Fault description: The UA5000 supports FE in the upstream direction. A site has been runningservices for half a year. The 678 error is displayed for all users when they dial up every month.The IPMB control board is restarted and it is found that the fault persists. The dialup is sometimesnormal and sometimes abnormal after the entire shelf is powered off.



l Sometimes the dialup is normal and the IPMB uplink port is normal after the entire shelfis powered off. It is considered that the IPMB control board or the O2FN daughter boardmay be faulty.

l The upper-layer device needs to be configured with selected QinQ. Therefore, the data onthe upper-layer device may be faulty.

Procedure

Step 1 Sometimes the dialup is normal and the IPMB uplink port is normal after the entire shelf ispowered off. It is considered that the IPMB control board or the O2FN daughter board may befaulty. The IPMB control board and the O2FN daughter board are replaced. It is found that the



448

fault does not occur for several minutes. When the IPMB control board is powered off, it is foundthat the 678 error is displayed again. This indicates that the fault is not caused by the UA5000.

Step 2 It is considered that the data on the upper-layer device may be faulty. A switch is brought to thesite for test. It is found that each dialup is normal. This indicates that the upper-layer device isnormal.

Step 3 The networkings of the IPMB and the switch are compared and it is found that only one networkcable is different. Then, the upstream network cables are checked and it is found that the wiresequence is incorrect. A straight-through cable is replaced and the service is normal. The serviceis normal even when the IPMB control board is powered off.

----End


The wire sequence of the straight-through cable is "white, orange, orange, white, green, green,white, blue, blue, white, brown, and brown", which does not comply with the standard of thestraight-through cable (white, orange, orange, white, green, blue, white, blue, green, white,brown, and brown). This type of fault is related to many upper-layer devices. Therefore, you areadvised to locate the fault segment by segment.

TC-A0167 PPPoE Dialup Failure During Thunder Download Due to IncorrectConfiguration on the BRAS

This case describes the troubleshooting of a PPPoE dialup failure that occurred when Thundersoftware was used for download. The dialup failure occurred because the broadband remoteaccess server (BRAS) was not configured properly.

Fault Type

Ethernet service


Keywords


Retransmission counts

Fault Description

Network topology: UA5000 -> S6506R -> BRAS

Fault symptom: Numerous users reported that Internet access through PPPoE dialup failed whencertain applications, such as the download software Thunder, the video player PPLive, and themusic player Kuwo, were used during Internet surfing.

Alarm Information

None



449

Cause Analysis


l The bandwidth was insufficient or the optical attenuation was high.

l The data configuration on the BRAS was incorrect.

Procedure

Step 1 The PPPoE dialup failure that occurs when applications such as Thunder, PPLive, and Kuwoare used is generally caused by network congestion. Therefore, the first step was to check theport traffic and optical power on the UA5000 and the S6506R. The check showed that the porttraffic and optical power on the two devices were normal, indicating that the fault was not causedby bandwidth insufficiency or optical attenuation.

Step 2 The PPP layer-2 detection interval and timeout detection count configurations on the BRASwere checked. It was found that the PPP layer-2 detection interval was short and that the timeoutdetection count was small, both of which might cause PPPoE dialup failure. After the PPP layer-2detection interval and timeout detection count were adjusted using the ppp keepalive command,the fault was rectified.

----End


If the PPPoE connection fails during a normal PPPoE session, there are two possible causes:

l The PPPoE user has made a request to go offline. This is a normal offline, and when theuser dials up again, the PPPoE connection is re-established immediately.

l The PPP layer-2 detection interval is short or the timeout detection count is small. In suchcases, when the network is congested, the BRAS terminates the PPPoE session. Thunder,PPLive, and Kuwo are applications that tend to produce network congestion. Therefore,when the PPP layer-2 detection interval and timeout detection count, which are configuredthrough the ppp keepalive command under the virtual profile of the BRAS, do not meetthe current requirements, PPPoE users connected to the BRAS may find that theirconnection is frequently terminated.

The default PPP layer-2 detection interval of Huawei BRAS MA5200G is 20 seconds and thedefault timeout detection count is three. When the two values do not meet actual requirements,run the ppp keepalive command to reconfigure the values.



Fault Type

Ethernet service

Service exception



450

Keywords

Malware attack

PPPoE dialup

Fault Description

Network topology: UA5000 -> MA5680T -> BRAS


Alarm Information

Alarms "Line-caused ADSL Port Auto Deactivation" and "ADSL Port Link Loss" weredisplayed on the HyperTerminal.

Cause Analysis



Procedure








451

Step 6 The ADSL user was advised to disconnect the PPPoE connection and then dial up again. It wasfound that upstream data traffic of the user was three times the downstream data traffic, wheneverno Internet page was open or download software was used. The traffic information about theADSL port on the UA5000 was checked. A large number of abnormal upstream data wasdetected.huawei(config)#display traffic 0/11/2{ <cr>|channel<K> }: Command: display traffic 0/11/2 Querying, please wait... -------------------------------------------------------------- Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps) -------------------------------------------------------------- 0/11/2 183.2 61.0 --------------------------------------------------------------


----End






Fault Type

Ethernet service


Keywords

PADS

Number of users



452






Procedure






traffic-statistic:port 0/2/0: Inbound: Matches: Acl 4001 rule 5 running 2 packets Outbound:



453

Matches: Acl 4000 rule 5 running 1 packets Total number of traffic-statistic inbound : 1 Total number of traffic-statistic outbound : 1 Total number of traffic-statistic all : 2





----End

Suggestions and SummaryError 676 during dialup is seldom caused by the restriction on the number of permitted BRASconnections, which therefore is often ignored during the handling of error 676. This case can beused as a reference for troubleshooting similar faults.

TC-A0190 Low Rate of Internet Access Through the UA5000 Due to a Large Numberof Junk Packets Transmitted from the Upper-layer Device

This case describes the troubleshooting of the low rate of Internet access through a UA5000because the upper-layer device transmitted a large number of junk packets.


Service exception

KeywordsTraffic

ADSL



454

Fault DescriptionNetwork topology: UA5000 (IPMB) -> switch (S3500)

Faulty symptom: At about 10:30 AM every day, the Internet access rates of users connected toa UA5000 that used the IPMB+PVMB integrated upstream transmission mode were very low.The users used the MUX VLAN service.



l A fault, such as loop or virus attack, occurred on the user.l The IPMB control board processed the forwarded ADSL service data incorrectly.l The upstream bandwidth on the uplink port on the IPMB control board was insufficient so

that the traffic was limited.

Procedure

Step 1 The UA5000 was checked. It was found that the device was enabled with the loop detectionfunction, indicating that the fault was not caused by user port loop.

Step 2 Given that the users used the MUX VLAN service and that the low Internet access rate occurredon a large number of users in the same period, the possible cause of virus attack was eliminatedbecause there was little probability that all the users were affected by virus at the same time.

Step 3 The display traffic F/S/P command was executed to check the traffic on the activated user ports.It was found that the traffic on these ports was light, indicating that the fault was not caused byuser port.

Step 4 The other ETH port on the IPMB control board was added to the user VLAN. It was found thatthe Internet access rate was still very low, indicating that the fault was not caused by thecommunication failure between the ADSL service board and the IPMB control board.

Step 5 The UA5000 was logged in through the inband network management channel. It was found thatthe UA5000 responded to the received messages slowly, indicating that the fault may occurredon the IPMB control board.

Step 6 The IPMB control board was checked. It was found that only port 0 (for transmitting dataupstream) and port 7 (for subtending to the PVM board) on the IPMB board were online. Then,the traffic on associated ports on the IPMB board was checked after the activate command wasexecuted to activate all the ADSL ports.huawei(config-if-ipm-0/2)#display port traffic 0 The received traffic of this port(packets/s) =16606 The received traffic of this port(octets/s) =11173451 The transmitted traffic of this port(packets/s) =40 The transmitted traffic of this port(octets/s) =8498huawei(config-if-ipm-0/2)#display port traffic 7 The received traffic of this port(packets/s) =37 The received traffic of this port(octets/s) =8306 The transmitted traffic of this port(packets/s) =41 The transmitted traffic of this port(octets/s) =8406Port 7 forwards the voice service, and its Tx traffic and Rx traffic



455

The displayed traffic information showed that port 7 transmitted the voice service, with almostthe same receiving and transmitting traffic of about 8 kbyte/s. The transmitting traffic on port 0was almost the same as the transmitting traffic on port 7, but the receiving traffic on port 0 was11.17 Mbyte/s, which was excessively greater than the transmitting traffic and almost fullyoccupied the traffic on the 100 Mbit/s uplink port (100 Mbit/s = 12.5 Mbyte/s). Therefore, it waspreliminarily determined that the receiving traffic on port 0 caused the fault.

Step 7 The upper-layer switch S3500 was checked. It was found that the switch sent a large number ofjunk packets to the UA5000 in a certain period every day. After the junk packet filtering functionwas enabled on the switch through configuration change, the receiving traffic on the UA5000was normal and the Internet access rates of the users returned to the normal state.

----End


Checking the traffic on ports helps identify the causes of low Internet access rate.

TC-A0194 Failure of PPPoE Dialup Through the Subtending Shelf of a UA5000 Dueto the MAC Address Spoofing Function Configured on the UA5000

This case describes the troubleshooting of the PPPoE dialup failure that occurred on subtendingshelf of a UA5000 due to the MAC address spoofing function configured on the device.

Fault Type

Ethernet Service

Service abnormality

Keyword

PITP

System security

Fault Description

Network topology: The UA5000 had two subtending shelves, the broadband control board wasthe IPMB, and the service board was the CSMB. The two shelves used the same service VLANduring service deployment.

The PPPoE dialup failure occurred on users of a UA5000 randomly, whereas the voice servicewas normal. Dialup failures from time to time and the distribution of the users' ports had noobvious rules. The voice service was normal.

Alarm Information

None

Cause Analysis




456

l The user failed to send the PPPoE dialup request.l The board driver was faulty.l The subtending shelf control board was faulty.l Attack ports existed on the device.

Procedure

Step 1 A dialup test was performed on the PC connected to the xDSL port, and the mirroring packetcapturing was performed on uplink port 0, with the filtering criterion on the packet capture toolEthereal set to the MAC address of the PC. It was found that the PADI packets did not reach theuplink port.

Step 2 The PPPoE dialup test was performed on the PC, connected to FE port 2 on the UA5000. Themirroring and packet capturing was performed on the uplink port. The PADI packet was detected.After the mirroring and packet capturing was performed on other uplink ports, no PADI packetwas detected. It indicated that the dialup packets was sent out but did not reach the uplink port0.

Step 3 The MAC address learned on the subtending shelf of the UA5000. It was found that only morethan 30 MAC addresses were learned by the UA5000. In normal conditions, the number of MACaddresses learned exceeds 100. Only if the LSW and the logic learned the MAC address at thesame time, can the MAC address be queried by running the display Mac-address command.Therefore, it was hypothesized that the packets was lost in the logic and the LSW.

Step 4 After the board was replaced, the fault persisted. It was found that the number of MAC addressesof the subtended shelves reached more than 180, but the number of the MAC addresses of thesubtending shelves was only about 30. Given that the PADI packets already reached the logicbut it was not found on the LSW upstream port, it was hypothesized that the PADI packets maybe discarded by the logic or LSW.

Step 5 The MAC address learned at the f/s shelf/slot can be queried by running the display mac-addressall command. If eight static MAC addresses were learned at the slot, it indicated that this portwas the attack source. All the attacked ports on the device were checked in this way, thus it wasdetermined that the attacked ports existed on the device.

NOTE

From the attack ports queried by deactivating, you can check whether other faulty ports on the UA5000can restore the PPPoE dialup. Therefore, the attacked ports acknowledged can be checked.

Step 6 After the attacked port was recorded and the fault information about the device was collected,the service on the attack ports was suspended. It was found that the PPPoE dialup on the faultyports was successful, indicating that the fault was rectified.

Step 7 As for the attack port, the bind command was executed to bind the MAC address. Thereforeonly the MAC address configured could be used by the user port for packets sending. The mac-address max-mac-count command was executed to configure the maximum number of theMAC addresses that learned by the port. The PPoE dialup service recovered after the previousconfiguration and the fault was removed.

----End


The anti-MAC spoofing principles are analyzed as follows:



457

l Assuming that MAC1 is the MAC address of user A and MAC2 is the MAC address ofuser B, MAC2 is bounded with user A when user A dials through MAC2 in the case thatthe anti-MAC spoofing function is enabled. The PPPoE packets of user B is considered asthe unauthorized packets and is discarded because MAC2 has been bounded with user Awhen user B dials. As a result, the dialup of user B fails.

l When the anti-MAC spoofing function is enabled, the normal MAC address (not the staticconfiguration) is learned by the LSW chip in a static mode and the packets with this MACaddress are sent to the LSW all the time. At the same time, the learning of packets of normalusers fails.

As for problems of the PPPoE dialup failures, first check the security configurations of thedevice, such as the configuration of PITP and the anti-MAC address spoofing function, andcheck whether the user port attack is related to the configuration.

TC-A0209 Internet Access Failure on VPDN Users Due to the Anti-MAC SpoofingFunction Enabled on the UA5000

This case describes the troubleshooting of the Internet access failure on VPDN users of a UA5000Due to the anti-MAC spoofing function enabled on the UA5000.



KeywordsAnti-MAC spoofing

Address drift

Fault DescriptionNetwork topology: PC -> UA5000 -> Switch (S3528) -> BRAS (MA5200G)

The subscriber was in a hospital, and the VPDN service was connected to the hospital intra-network after dialing up. The intra-network was connected to the next server through the medicalinsurance system software. The subscriber dialed the numbers in the VPDN mode successfully.Dialing up to access the network was successful, however the PC that uses this software failedto connect to the server. The system prompted that the connection was delayed.



l The network was disconnected due to the routing failure between the subscriber's computerand the server.

l The computer setting was faulty.



458

l The MTU was set too large, and therefore the data failed to get through the upper-layerdevice.

l The parameter configuration of the UA5000 was incorrect.

Procedure

Step 1 The operation of pinging the service from the PC was performed. It was found that theconnection/communication was normal.

Step 2 The test was performed on another MA51000 under S3528, and it was found that the softwarewas normal. Therefore, it could be determined that the fault was caused by the UA5000 and thePC.

Step 3 The computer that was tested as normal on the MA5100 was connected to the UA5000 for atest, but the software runs abnormally.

Step 4 After the MTU value was decreased, the fault persisted.

Step 5 The packets were captured and analyzed on the PC, and it was confirmed that a virtual MACaddress was used by the software. However, the anti-MAC spoofing function was enabled onthe UA5000.

NOTE

After the anti-MAC spoofing function was enabled, the system will bind the MAC address with the servicestream. The packets were discarded because the virtual MAC address was used in the software.

Step 6 The security anti-macspoofing disable command was executed to disable the function. Afterthe test, the PC was connected to the medical server through the software normally.

----End


In routine maintenance, the fault wherein the subscribers can access the Internet but certainservices are abnormal. The fault may be caused by incorrect MTU settings. If the fault cannotbe rectified after the MTU value is decreased, perform packet capture and analysis.

Disable the anti-MAC spoofing function on the UA5000 and run the security mac-filtercommand to configure filtering function of a specified MAC address, thus preventing MACaddress change.

TC-A0214 Modem Deactivation During a Call

This case describes the troubleshooting of a modem that was deactivated during a call.

Fault Type

xDSL service

Service abnormality

Keyword




459

Fault Description

The modem was deactivated when a user was on the phone or pressed the hookflash.

Alarm Information

None

Cause Analysis

According to the fault symptom, the possible causes were as follows:l The modem was faulty.l The line was faulty.

Procedure

Step 1 The modem was replaced. The fault, however, persisted. This indicated that the modem wasnormal.

Step 2 The same situation was emulated on the main distribution frame (MDF) on the user side. It wasfound that the modem was not deactivated. This indicated that the line from the device to theMDF was normal.

Step 3 It was determined that the cabling at the home of the user was faulty. The leading-in box at thehome of the user was checked. It was found that the white wire of the phone line was notconnected properly. That is, the grounding cable was not grounded properly. As a result, theADSL line was deactivated frequently.

Step 4 The phone line was connected properly. That is, the fault was rectified.

----End


In this case, the modem was deactivated frequently when a phone was ringing or a user pressedthe hookflash. Therefore, it was determined that the cabling on the user side was not proper. Inthis case, check whether the cabling on the user side met the requirements.

TC-A0215 Low Internet Access Rate Due to a Virus-Infected PC

This case describes the troubleshooting of a low Internet access rate due to a virus-infectedpersonal computer (PC).

Fault Type

xDSL service

Service abnormality

Keyword

Low Internet access rate



460

Fault Description

Network topology: PC -> modem -> UA5000 -> switch -> BRAS

The user accessed the Internet in ADSL mode but the Internet access rate was too low.

Alarm Information

None

Cause Analysis




l The user PC was infected with viruses.

Procedure

Step 1 The user PC was used to download data. The download rate was only 4 kbit/s. A test PC wasconnected to the port on the upper layer switch, which was originally used to connect theUA5000, to download data. The download rate reached 8 Mbit/s.

Step 2 The test PC was connected to the Ethernet port on the UA5000 to download data. The downloadrate was close to 8 Mbit/s.

Step 3 The traffic of the faulty ADSL port on the UA5000 was checked. It was found that the upstreamand downstream traffic of the port was consistent with the upstream and downstream traffic ofthe upper layer network. This indicated that the communication between the UA5000 and theupper layer device was normal.

Step 4 The subscriber line and the modem were checked. It was found that they were normal.

Step 5 The user PC was checked. It was found that the PC was of high configuration and the networkinterface card was configured correctly. The antivirus software was used to check the user PC.More than 250 viruses were detected.

Step 6 The viruses were killed and the download rate reached 400 kbit/s. That is, the fault was rectified.

----End


In this case, after the PC was infected with viruses, the performance of the PC and its networkinterface card was reduced and a large amount of data failed to be processed. As a result, theInternet access rate was too low.

TC-A0216 Low Internet Access Rate Due to Inconsistent Hardware and SoftwareSettings of the Network Interface Card on a PC

This case describes the troubleshooting of a low Internet access rate due to inconsistent hardwareand software settings of the network interface card on a PC.



461


Service abnormality

KeywordLow Internet access rate

Fault DescriptionThe Internet access rate of an ADSL user was low. That is, the download rate was only about 1kbit/s. After the PC was reset multiple times, the fault, however, persisted.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The upper layer device was faulty.l The user PC was faulty, including the following problems:

– The PC was of low configuration.– The operating system (OS) of the PC was faulty.– The hardware and software settings of the network interface card were inconsistent.

ProcedureStep 1 The user PC was replaced for tests. It was found that the Internet access service was normal, the

download rate was about 150 kbit/s, and the video on demand (VOD) service was smooth. Thisindicated that the upper layer device was normal.

Step 2 The user PC was checked.1. The configuration of the PC was checked. It was found that the configuration met the

requirements. This indicated that the configuration of the PC was normal.2. The OS of the PC was checked. It was found that the OS was just reinstalled. This indicated

that the OS of the PC was normal.3. The hardware and software settings of the network interface card were checked. It was

found that the network interface card was a new network interface card installed after theOS was reinstalled. The network interface card drive was not reinstalled because the modelof the new network interface card was the same as the model of the original networkinterface card.

NOTEThe rate of the new network interface card was set to 10/100 Mbit/s auto adaptation, whereas the rate ofthe network interface card configured in the OS of the PC was 10 Mbit/s. That is, the rate setting of thenetwork interface card in the OS was inconsistent with the rate of the network interface card.

4. The rate of the network interface card in the OS was changed to 10/100 Mbit/s and the PCwas reset. The Internet access and VOD services were normal.

----End



462


After replacing the hardware of a PC, update the drive or reconfigure the data in time. This canprevent the inconsistency between the settings of the new hardware and the settings of thesoftware.

TC-A0219 Frequent Service Interruptions Due to Improper Setting of the InterleaveDelay

This case describes the troubleshooting of frequent service interruptions due to improper settingof the interleave delay.

Fault Type

xDSL service

Service abnormality

Keyword

Frequent interruptions

Fault Description

The ADSL users of the UA5000 accessed the Internet through Point-to-Point Protocol overEthernet (PPPoE) or Point-to-Point Protocol over ATM (PPPoA). Services were frequentlyinterrupted. After a service interruption, the users dialed up again and could access the Internetquickly.

Alarm Information

None

Cause Analysis


l The modem was faulty.

l The configurations of the upper layer broadband remote access server (BRAS) and theUA5000 were incorrect.

Procedure

Step 1 The modem was checked. It was found that the modem was not deactivated after the faultoccurred. The modem was replaced. The fault, however, persisted.

Step 2 The CPU usage of the upper layer BRAS was checked. It was found that the CPU usage wasonly 19%, indicating that the fault was not caused by a high CPU usage of the BRAS.

Step 3 The data configuration of the UA5000 was checked. It was found that the port worked ininterleave mode and the interleave delay was 64 ms.



463

NOTE

During the monitoring process on the user side, it was found that regular jitter occurred on ping packets. Thatis, a ping packet was transmitted with a great delay after seven to eight ping packets were transmitted stably.

In PPPoE or PPPoA access mode, the BRAS sent a PPP ECHO packet to the client software periodically tocheck whether a PPP user existed. If there was no response after the PPP ECHO packet was retransmitted certaintimes, the BRAS stopped the service of the user.

According to the preceding analysis, the PPP ECHO packet sent by the BRAS to the client software was lostbecause the interleave delay was great. As a result, the BRAS stopped the service of the user.

Step 4 The interleave delay of the port was changed to 16 ms. Through monitoring, it was found thatthe service was not interrupted frequently.

Step 5 The interleave delay of the port was changed to 8 ms. Through long-time monitoring, it wasfound that the fault was rectified.

----End

Suggestions and SummaryThe greater the interleave delay is, the more stable the ADSL2+ line is, but the longer thetransmission delay is. Therefore, change the interleave delay according to the actual condition.

TC-A0220 Internet Access Interruption Due to an IP Address Conflict of theGateway

This case describes the troubleshooting of an Internet access interruption due to an IP addressconflict of the gateway.


Service abnormality


Fault DescriptionNetwork topology: User -> UA5000 -> LAN switch -> router -> Internet

The UA5000 provided the Internet access service. A user accessed the Internet with a fixed IPaddress. When the Internet access service was interrupted, the user could ping the IP address ofthe gateway but failed to ping the IP address of the DNS server.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:



464

l A port on the LAN switch was faulty.l The data configuration of the UA5000 was incorrect.l The upper layer device was faulty.

Procedure

Step 1 A PC was directly connected to a port on the LAN switch. It was found that the Internet accesswas successful. This indicated that the port on the LAN switch was normal.

Step 2 The data configuration of the UA5000 was checked. It was found that the data configurationwas correct. Pinging the IP address of the gateway from the UA5000 was performed. It wasfound that packet loss occurred seriously.

Step 3 A router maintenance engineer was coordinated to check the data configuration of the router. Itwas found that the MAC address bound with the IP address of the gateway was incorrect.Therefore, it was determined that the fault was caused by the address conflict of the gateway.

Step 4 The network cable connecting the UA5000 and the LAN switch was removed on the UA5000side. Pinging the IP address of the gateway from the UA5000 was performed. It was found thatthe ping operation was still successful. The ADSL ports on the UA5000 were disabled one byone until pinging the IP address of the gateway from the UA5000 failed. It was found that theIP address of a PC is the same as the IP address of the gateway.

Step 5 The PC whose IP address was the same as the IP address gateway was isolated. The MAC addressbound with the gateway on the router was changed. Then, the user could access the Internet.

Step 6 The ADSL ports disabled in Step 4 were enabled. That is, the fault was rectified.

----End

Suggestions and SummaryPrevent IP address conflicts in data planning.

TC-A0221 Low Internet Access Rate Due to Too Many Network ProtocolsThis case describes the troubleshooting of a low Internet access rate due to too many networkprotocols configured for a user.


Service abnormality


Fault DescriptionThe UA5000 provided the Internet access service. When the same traffic control policy wasused, the Internet access rate of a user connected to the Ethernet service board was low. That is,the maximum Internet access rate of the user ranged from 5 Mbit/s to 6 Mbit/s. The maximumdownstream rate defined in the traffic profile was 10 Mbit/s.



465


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The data configuration of the UA5000 was incorrect.l The Ethernet service board was faulty.l The user PC was faulty.

ProcedureStep 1 The data configuration of the UA5000 was checked and found to be correct. This indicated that

the fault was not caused by the data configuration of the UA5000.

Step 2 The Internet access rates of other users connected to the same Ethernet service board werechecked and found to be normal. This indicated that the Ethernet service board was normal.

Step 3 A test PC was used and the Internet access rate of the user was checked and found to be normal.This indicated that the user PC was faulty.

Step 4 The user PC was checked. It was found that a large number of network protocols were configuredon the user PC. After unnecessary network protocols were deleted, the Internet access ratebecame normal.

----End

Suggestions and SummaryIf too many network protocols are configured on a terminal, the Internet access rate becomeslow. Therefore, it is recommended that you configure only necessary network protocols whenconfiguring the terminal.

TC-A0222 Internet Access Failure Due to a VLAN Interconnection ProblemThis case describes the troubleshooting of the Internet access failure due to a VLANinterconnection problem.


Service abnormality


Fault DescriptionNetwork topology: UA5000 -> LAN switch -> router -> Internet

After UA5000s were upgraded, the system configurations were modified. All the usersconnected to an UA5000 could not access the Internet.



466


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The uplink port was faulty.l The interconnection was faulty.

Procedure

Step 1 The uplink port parameters of the UA5000 were checked. It was found that the uplink portworked in auto negotiation mode and was activated. There were two VLANs. One was VLAN100 and the other, namely, the default VLAN, was VLAN 1.

Step 2 The configuration of the port on the LAN switch connected to the uplink port on the UA5000was checked. It was found that the VLAN list of the port did not include VLAN 100.

Step 3 According to the preceding check result, it was determined that the fault was caused by theVLAN interconnection between the UA5000 and the LAN switch. That is, after the Ethernetport on the UA5000 sent an Ethernet packet that carried the VLAN 100 tag to the LAN switch,the LAN switch discarded the packet.

Step 4 The UA5000 was logged in and the native VLAN ID of the uplink port was changed to 100 sothat the uplink data did not carry the VLAN tag. That is, the fault was rectified.

----End

Suggestions and SummaryIf all the users connected to an UA5000 cannot access the Internet, the interconnection of theuplink port may be faulty.

TC-A0226 Dialup Failure of a PPP User Due to Inconsistent Encapsulation ModesThis case describes the troubleshooting of the dialup failure of a Point-to-Point Protocol (PPP)user due to inconsistent encapsulation modes.


Service abnormality


Fault DescriptionA user connected to the UA5000 failed to access the Internet through Point-to-Point Protocolover ATM (PPPoA) dialup.



467


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The communication between the UA5000 and the broadband remote access server (BRAS)

was faulty.l The data configuration of the UA5000 was incorrect.l The modem was faulty.

ProcedureStep 1 The connection between the UA5000 and the BRAS was checked. It was found that the

connection was normal.

Step 2 The configuration of the UA5000 was checked. It was found that the PPPoA was enabled,VLANs and service ports were configured correctly, no static MAC address was configured, themaximum number of learnt MAC addresses was 255 (the default value), a MAC address poolwas configured and the capacity of the MAC address pool was sufficient, and the encapsulationmode was LLC_BRIDGE. This indicated that the data configuration was correct.

Step 3 The modem configuration was checked. It was found that the encapsulation mode was LLC_PPP,which was different from the encapsulation mode on the UA5000.

Step 4 The encapsulation mode on the UA5000 was changed to LLC_PPP, which was the same as theencapsulation mode on the modem. The user dialed up again. Then, the dialup was successful.

----End

Suggestions and SummaryThis fault was caused by the inconsistency between the encapsulation mode on the modem andthe encapsulation mode on the UA5000.

TC-A0227 Dialup Failure of a PPP User Due to a Static MAC AddressThis case describes the troubleshooting of the dialup failure of a Point-to-Point Protocol (PPP)user due to a static MAC address.


Service abnormality


Fault DescriptionA user connected to the UA5000 failed to access the Internet through PPP dialup. When thedialup failed, packets were captured on the user side. It was found that the user sent PPPoE



468

Active Discovery Initiation (PADI) packets but did not receive PPPoE Active Discovery Offer(PADO) packets.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The communication between the UA5000 and the broadband remote access server (BRAS)

was faulty.l The data configuration of the UA5000 was incorrect.

Procedure


Step 2 The configuration of the UA5000 was checked. It was found that the user was connected to port0/7/2 but the MAC address bound to the user was not the MAC address of port 0/7/2. The MACaddress bound to the user was the static MAC address configured on port 0/11/5.

NOTEAfter receiving PADO packets sent from the BRAS, the UA5000 sent the PADO packets to port 0/11/5, ratherthan port 0/7/2, because the destination MAC address of the PADO packets was the static MAC addressconfigured on port 0/11/5. As a result, port 0/7/2 did not receive the PADO packets. Accordingly, the dialup ofthe user failed.

Step 3 The static MAC address configured on port 0/11/5 was deleted and the user dialed up again.Then, the dialup was successful.

----End

Suggestions and SummaryWhen configuring a static MAC address, make sure that the configured port is the same as theport used in dialup.

TC-A0252 VLAN Stacking Service Failure Due to Unmatched Protocol TypesThis case describes how to troubleshoot a virtual local area network (VLAN) stacking servicefailure on the UA5000, which is caused by the unmatched Ethernet protocol types of the inner-layer VLANs configured on the UA5000 and on the optical line terminal (OLT), the UA5000'supper layer device.


Ethernet service

KeywordsVLAN stacking



469

VLAN tag

Fault DescriptionNetwork topology: UA5000 -> OLT -> switch -> router

Fault symptom: The single-VLAN services on the UA5000 on a site operate properly, but theVLAN stacking service, a double-VLAN service, fails.


Cause Analysisl The upstream link is faulty.l The upper layer device is faulty.l The data configuration on the UA5000 used to connect to the OLT is incorrect.

Procedure

Step 1 Check whether the affected UA5000 can be managed by the network management system(NMS). It is found that the UA5000 is in the managed device list on the NMS, indicating thatthe upstream link of the UA5000 is normal.

Step 2 Check the UA5000, OLT, and switch for the MAC addresses of subscribers connected to theUA5000. It is found that these devices can learn subscribers' MAC addresses successfully.

Step 3 Check for the MAC address of the broadband remote access server (BRAS) on the OLT and theswitch. It is found that the OLT and the switch can learn the BRAS' MAC address successfully.

Step 4 Check the external VLAN tags on other UA5000s connected to the same OLT. It is found thatthey are the same as the external VLAN tag on the affected UA5000, indicating that the fault isnot on the OLT but on the affected UA5000.

Step 5 Change the external VLAN tag on the affected UA5000 to another value, and then performanother test. It is found that the fault persists.

Step 6 Change the VLAN configuration on the affected UA5000 to single-VLAN configuration, andthen perform another test. It is found that the services on the UA5000 return to normal.

Step 7 Check the Ethernet protocol type of the inner-layer VLAN configured on the OLT. It is foundthat the type is 0x8100, whereas the type configured on the affected UA5000 is 0x7a.

Step 8 Run the stacking inner-ethertype command to change the Ethernet protocol type of the inner-layer VLAN configured on the UA5000 to 0x8100, and then perform another test. It is foundthat the fault is rectified.

----End

Suggestion and SummaryThe inner- and outer-layer Ethernet protocol types configured on the UA5000 only take effecton double-VLAN services and do not affect single-VLAN services. Note that the Ethernetprotocol types of the inner- and outer-layer VLANs configured on the UA5000 must be the sameas those configured on the upper layer device.



470

TC-A0256 Frequent Internet Access Failures Due to Too Many Broadcast Packetson the Network

This case describes how to troubleshoot frequent Internet access failures due to too manybroadcast packets on the network.

Fault Type

Service abnormality

Ethernet service

Keywords

Jitter

Fault Description

Network topology: PC -> UA5000 -> OLT -> switch -> BRAS -> Internet

Broadband subscribers connected to a UA5000 are often forced offline when browsing Webpages. It is found that the delay is long, jitter is serious, and packets are lost when subscribersping certain Web sites.

Alarm Information


Cause Analysisl The Web sites themselves are the source of the problem.l The upper layer network of the optical line terminal (OLT) has some problems.l The UA5000 forwards packets incorrectly.l There are too many broadcast packets on the network.

Procedure

Step 1 Given that the leased line service subscribers can access these Web sites successfully and browseWeb pages without any Internet failures, the Web sites are operating properly.

Step 2 Check the services on other broadband access devices connected to the same OLT as theUA5000. It is found that the services are operating properly, indicating that the upper layernetwork of the OLT is operating properly.

Step 3 Create VLAN a, which contains subscribers connected to the UA5000, on the OLT, andconfigure for the new VLAN an IP address that is in the same network segment as the IPaddresses of UA5000 subscribers. Then, run the interface vlanif command on the UA5000 tocreate a Layer 3 interface, and then ping the IP address of the OLT. It is found that there aredelays and jitters.

Step 4 Perform a loopback test on a user port on the UA5000, and then run the atm-ping command. Itis found that there are delays and jitters, indicating that the fault may be on the UA5000.



471

Step 5 Run the display traffic F/S/P command to query the real-time traffic on a user port on theUA5000. It is found that the traffic on the port occasionally increases suddenly to reach or exceedthe activation rate.

Step 6 Capture packets on a user port on the UA5000. A large number of broadcast packets are foundin the captured packets, indicating that the fault may be caused by the broadcast packets.

Step 7 Run the traffic-suppress all broadcast value 13 command to enable the broadcast packetsuppression function on the uplink port on the UA5000. It is found that the Internet access failuresstop.

Step 8 Check the VLAN configurations on the UA5000. It is found that many subscribers are configuredin the same VLAN, causing a large number of broadcast packets, which have occupied thebandwidth on the subscriber side. As a result, the interaction packets between the subscriber andthe BRAS are discarded, causing the subscriber offline.

Step 9 Modify the data configurations on the VLAN and assign one subscriber to each VLAN. It isfound that the fault is rectified.

----End


When the broadcast traffic suppression function is enabled on a device, the device will notforward broadcast packets on the network. This function, however, cannot be enabled when adevice is only operating broadcast interaction services, such as the Dynamic Host ConfigurationProtocol (DHCP) service.

16.2.4 Narrowband ServiceThis topic provides the analysis of the cases related to the narrowband service.

TC-A0002 Certain Boards of a UA5000 Are Faulty Because the LAP-RSA Link inthe CPC Board of the Switch Is Abnormal

This topic describes how to troubleshoot the fault when certain boards of a UA5000 are faultybecause the LAP-RSA link in the CPC board of the switch is abnormal.

Fault Type

Other


Phenomenon Descriptionl A new UA5000 that is configured with one HABD shelf is added to an office. The UA5000

is connected to the 8008P011J024 switch in VRSP mode and it functions as the RSP shelf.After the data configuration, it is found that the ASL board in slot 2, the RSU board in slot9, and the TSS board in slot 15 cannot work in the normal state and LEDs RUN fast blink.Other ASL boards and the RSU board in slot 8 work in the normal state.

l On the device panel of the switch, it can be found that these boards are sometimes normaland sometimes faulty.



472

Alarm Information

None

Cause Analysis


l The shelf data on the switch is configured incorrectly (such as the subnode is configuredincorrectly).

l The problem exists in the 2M link between the switch and the access network (AN) device.

l The hardware of the board of the UA5000 is faulty.

l The backplane of the UA5000 is faulty.

l The DIP switch of the RSU board is set incorrectly.

Procedure

Step 1 Delete the shelf data from the switch, and then reconfigure the data. The HABD shelf is emulatedas the RSP-19D on site. Configure a 2M link on the left and right virtual RSP boards. Thesubnodes of the left and right RSP boards are 10 and 21, which belong to HW group 1. Theboards in the shelf are numbered from 260. After the shelf is added successfully and the boardsare activated, the fault persists.

Step 2 Change the RSU, ASL, and TSS boards and test again. If the fault persists, it indicates that thefault is not caused by the boards. Then, re-upgrade the RSU board software and check the cableconnection and the DIP switch of the RSU board. If the cable connection and the DIP switchare in the normal state, and bits 1, 2, and 3 are set to ON and bit 4 is set to OFF, it indicates thatthe fault is not caused by the software.

Step 3 Remove all the boards and examine the pins on the backplane. If no pin is bent or damaged, itindicates that the fault is not caused by the backplane.

Step 4 Configure the 2M link on the switch to another port. The fault persists.

Step 5 Modify the shelf data. When the shelf is configured with one RSU board, the fault is rectified.In this case, observe the link status of the CPC board. It is found that two links are in the workingstate. In the case of one RSU board, however, only one LAP-RSA link should be configured.After the shelf is deleted, the corresponding link is deleted and the second link is still in theworking state. After the query of the alarm through the client, an alarm indicating that the secondlink is abnormal is displayed. In this case, it is considered that the second link is abnormal.

Step 6 On the switch, only one CPC board is configured to LAP-RSA. Add an idle master/slave RSPshelf to occupy the faulty link, and then add an actual shelf to occupy another link that is in thenormal state (avoid the faulty link). After the configuration, the fault is rectified.

----End


The UA5000 that is connected to the switch in VRSP mode is closely relevant to the linkprocessing board (the CPC board) of the switch. In the case of the fault of this type, it isrecommended that you check whether the CPC link is in the normal state.



473




Board fault

Board fault alarm








Procedure





Step 5 Compare the delivery list of this time with the previous delivery list. It is found that the HABAshelf is not configured with an HWCB board, which is used to subtend the slave shelf. This



474

office, however, does not use the slave shelf. Therefore, the carrier did not purchase the HWCBboard. Use an HWCB board from another office and insert it into the shelf of this office. Then,the service boards in slots 18 to 35 are in the normal state and the fault is rectified.

----End


TC-A0008 Only One ISDN Telephone Is in the Normal State Under the NT1Because the Working Mode of the BRA Port Is Set Improperly

This topic describes how to troubleshoot the fault when only one ISDN telephone is in the normalstate under the network termination 1 (NT1) because the working mode of the basic rate access(BRA) port is set improperly in the case of the integrated services digital network (ISDN) voiceservice.


Service exception

Phenomenon Descriptionl Networking: ISDN telephone -> NT1 -> UA5000 -> softswitch

NOTE

The UA5000 is led out to the NT1 (of another vendor) from a port on the DSL board. The NT1provides two ISDN ports connected to two telephones.

l Fault phenomenon: Only one ISDN telephone can establish a conversation. Telephone Acan establish a normal conversation after the offhook but telephone B plays no dialing toneupon offhook; or after telephone B is hooked off, telephone A does not play the dialingtone upon offhook. No exception is found on the softswitch side.



l The service port is faulty or is not activated.l The NT1 is faulty.l The telephone is faulty.l The cooperation between the NT1 provided by different vendors and the UA5000 is in the

abnormal state.l The data configuration is incorrect.



475

Procedure

Step 1 According the fault phenomenon, one telephone is in the normal state. Therefore, the fault is notcaused by the service port.

Step 2 Check the NT1 status, and it is in the normal state.

Step 3 Replace the ISDN telephones, and the fault persists.

Step 4 In ESL user mode, run the display braport attribute command to query the attribute of theBRA port. It is found that the working mode of the BRA port is set to p2p.The meanings of the working mode of the BRA port are as follows:l p2p: Indicates the point to point mode. It is applicable to the scenario where the ISDN BRA

port communicates with one terminal user.l p2mp: Indicates the point to multi-point mode. It is applicable to the application scenario

where the ISDN BRA port simultaneously communicates with multiple terminal users.

Step 5 In this troubleshooting case, it is required that the ISDN BRA port communicate with twoterminal users simultaneously. Therefore, run the braport attribute set command to change theworking mode of the BAR port to p2mp. Then, the fault is rectified.

----End

Suggestion and SummaryIt is recommended that you see the related documentation before the configuration. Otherwise,service exceptions may occur.

TC-A0009 MoIP Dialup Fails Because the Remote Server Changes the CodecWithout Reason

This topic describes how to troubleshoot the fault when modem over IP (MoIP) dialup failsbecause the remote server changes the codec without reason.


Service exception

Phenomenon DescriptionA UA5000 is interconnected with the trunk gateway (TG). In an MoIP test, the MoIP is used todial up to the IP network and the dialup fails.



l The account and password are incorrect.



476

l Communicating with the remote server fails.

l The operation process on the modem is incorrect.

Procedure

Step 1 Change the dialup account and password. If the fault persists, it indicates that the fault is notcaused by the account.

Step 2 Dial the remote server from a telephone directly. If the negotiation tone of the modem is played,it indicates that communicating with the remote server is in the normal state.

Step 3 After eliminating the preceding causes, capture packets. It is found that in the negotiationprocess, the remote server changes the codec without reason but the softswitch does not notifythe UA5000 that the UA5000 needs to switch the codec. As a result, the codecs between the twosides are inconsistent and the negotiation fails.

Step 4 Through the analysis of the softswitch, perform certain configurations on the softswitch. Afterthe softswitch issues consistent codecs according to the actual conditions of the two sides, thefault is rectified.

----End


During the handling of a VoIP, Fax, or MoIP service fault, it helps a lot to be familiar with theH.248 , MGCP and SIP protocol and skilled in using the packet capture tool.

TC-A0011 Fax Interconnecting Fails Because Codecs Are Inconsistent

This topic describes how to troubleshoot the fault when fax interconnecting fails because theUA5000 interconnects with the access equipment of company A and their codecs areinconsistent.

Fault Type

Narrowband service

Service exception

Phenomenon Descriptionl Networking: fax -> UA5000 -> softswitch -> access equipment of company A -> fax

l Fault phenomenon: When the UA5000 interconnects with the access equipment ofcompany A to implement the fax service, the fax service fails.

Alarm Information

None

Cause Analysis




477

l The fax terminal is faulty. The fax terminal requires special negotiation signals, but anotherfax terminal does not support these special negotiation signals. As a result, the faxnegotiation fails.

l The cooperation between the softswitch and the UA5000 is abnormal. The fax negotiationfails because the cooperation between the softswitch and the access equipment is abnormal.

l The fax negotiation fails because codecs are inconsistent.

Procedure

Step 1 Replace the fax with a new fax. If the fax UA5000 still fails, it indicates that the fault is notcaused by the fax terminal.

Step 2 Use the two faxes under the same UA5000 to send faxes. It is found that the faxes are in thenormal state. This indicates that the cooperation between the softswitch and the access equipmentis in the normal state.

Step 3 Capture signaling along with the engineer of company A. It is found that the μ-law is firstnegotiated on both sides (the softswitch sends codecs to the UA5000 and G.711μ is the firstcodec). In this case, the service is in the normal state. The access equipment of company A,however, forcibly changes the codec to G.711A and does not notify the softswitch of the change.As a result, the codecs are inconsistent on the two sides and the negotiation fails.

Step 4 On the softswitch side, change the codec type to G.711A, and then the fault is rectified.

NOTE

Consult the engineer of company A and it is confirmed that the fax service of company A supports onlyA-law and does not support μ-law. Therefore, the negotiation fails because the access equipment ofcompany A forcibly changes the codec in the negotiation process.

----End

Suggestion and SummaryIt helps a lot in troubleshooting a fax service fault to understand the fax principle, to be familiarwith the H.248 protocol, and capture packets for analysis.

TC-A0012 One-Way Audio and Continuous Dialing Tone Occur in the Subscriberof the Slave Shelf Because the HW Transfer Board Is Faulty

This topic describes how to troubleshoot the fault when the subscriber of the slave shelf cannothear the dialing tone (that is, one-way audio) and the dialing tone cannot be stopped because theHW transfer board is faulty.


Service exception

Phenomenon Descriptionl When a call is initiated from the local to the peer in the pulse telephone mode, the peer end

is alerted, and the ringback tone is played to the local end. After the call is connected, thelocal end hears the peer end but the peer end does not hear the local end.



478

l When a call is initiated from the local to the peer in the voice dialing mode, the local endhears only a continuous dialing tone.

l When a call is initiated from the peer to the local and the local uses the pulse dialing mode,the local end is alerted and the ringback tone is played to the peer end but when the call isanswered, the peer end does not hear the local end.

l When a call is initiated from the peer to the local and the local uses the voice dialing mode,the local end is alerted and the ringback tone is played to the peer end but when the call isanswered, the peer end does not hear the local end.

l Services under the master shelf are in the normal state. Call originations and conversionsare all in the normal state.Shelf type:

0 MAIN_HABM_30(HABA) Normal 1 SLAVE_HABS_30(HABA) Normal



l The A32 board in the slave shelf is damaged.l The fault occurs in the slave shelf and the master shelf is in the normal state. The physical

link between the master and slave shelves must be faulty. Possibly, the cable between themis in loose connection, either or both of the HW transfer boards HWCB and HWTB betweenthe master and slave shelves are faulty, or the hardware of the control board is faulty.

NOTE

According to the fault phenomenon, it is found that voices are not transmitted but pulse signals aretransmitted successfully. Therefore, the physical link may be faulty.

ProcedureStep 1 Replace the A32 board of the slave shelf, and the fault persists.

Step 2 Replace the HW transfer board HWTB of the slave shelf, and the fault persists.

Step 3 Replace the HW transfer board HWCB of the master shelf and perform the test again. The one-way audio and continuous dialing tone fault is rectified.

----End

Suggestion and SummaryIf a fault occurs only in the slave shelf but not in the master shelf, check the cable connectionbetween the master shelf and the slave shelf and their transfer boards. Make a replacement whennecessary.

TC-A0014 The Last Digit of the Caller ID Is Not Displayed for the Reason of theTelephone Set

This topic describes how to troubleshoot the fault when the last digit of the caller ID is notdisplayed for the reason of the telephone set.



479

Fault Type

Narrowband service

Other

Keyword

Narrowband voice service

Non-local PLMN number


A UA5000 is deployed in an office. The UA5000 is attached to the softswitch. Subscriberscomplain that their phones do not display the last digit of the phone number of the call made bya non-local mobile subscriber.

Alarm Information

None

Cause Analysis


l The cooperation between the softswitch and the UA5000 is in the abnormal state. As aresult, the last digit of the caller ID is lost.


Procedure

Step 1 Trace the H.248 signaling on the softswitch side. It is found that the caller ID is completely sent.This indicates that the cooperation between the softswitch and the UA5000 is in the normal state.

Step 2 Perform the dialing test using the non-local mobile phone. It is found that the caller ID is9013XXXXXXX. It is confirmed that the calling party is a virtual network subscriber. Thedisplayed first digit 9 represents an outgoing number and the subsequent digits 013XXXXXXXare the PLMN number of the calling party, but the last digit of the PLMN is not displayed.

Step 3 Perform the dialing test using another telephone set. The caller ID is displayed normally and theproblem is solved. Observe the difference between the two telephone sets. It is found that theLCD of the telephone set that cannot completely display the caller ID can display only 12 digits,but a normal telephone set can display 14 digits.

----End


None



480

TC-A0016 The Narrowband Leased Line Service Fails Due to Incorrect ModemConfigurations

This topic describes how to troubleshoot the fault when the narrowband leased line service failsdue to incorrect modem configurations.

Fault TypeOther

Service exception

KeywordNarrowband data and leased line service

SHDSL leased line

Phenomenon Descriptionl Networking: The customer requires to implement the 3 x 64 kbit/s = 192 kbit/s leased line

service through the following networking: router -> TDM SHDSL modem -> SDL SHDSLport -> SDL E1 port -> switch

l When an E1 cable is connected to the upstream port on the UA5000 PVM, the HABA shelfis emulated as the RSP shelf. The working mode is HABA. Services are in the normal state.On the UA5000, configure an intra-board semi-permanent connection from the SDLSHDSL port to the SDL E1 port (the start timeslot of the SHDSL port is 0/15/4/0 and theend timeslot is 0/15/4/2; the start timeslot of the E1 port is 0/15/0/1 and the end timeslot is0/15/0/3), with a bandwidth of 3 x 64 kbit/s = 192 kbit/s.

l Fault phenomenon: After the configurations, it is found that the physical layer between thetwo routers is UP but the protocol layer is DOWN and that neither of the two routers canbe pinged from each other.



l The data configurations of the UA5000 are incorrect.l The upper-layer link is faulty.l The modem configurations are incorrect.

Procedure

Step 1 Check the device status. The service boards work in the normal state, SHDSL port 0/15/4 is inthe active state, and E1 port 0/15/0 receives RRA alarms from the remote end. This indicatesthat the data on the AN side cannot be transmitted successfully.

Step 2 Check the data configurations of the UA5000, focusing on the timeslot usage and the frameformat. The data configurations are all correct.



481

Step 3 Connect the E1 tester to the E1 cable routed out of the CX. The test result is in the normal range.Connect the E1 tester to the E1 port on the SDL board. The test results are all zeros and they arein the normal range. This indicates that the upper-layer link is in the normal state.

Step 4 Check the modem configurations. It is found that DIVCLOCK is set to 1. Set DIVCLOCK toNORMAL, save the data, and restart the modem. After that, the status of the router protocollayer is changed from DOWN to UP, and the two routers can be pinged from each other. Thefault is rectified.

----End

Suggestion and SummaryWhen one timeslot is required to provide a 64 kbit/s service, you need to set DIVCLOC to 1.When three or more timeslots are required, you need to set DIVCLOCK to NORMAL.

TC-A0020 ISDN Subscribers Cannot Hear the Dialing Tone After the Offhook Dueto the Inconsistency Between the IUA Interface ID of the UA5000 and the IUAInterface ID of the Softswitch

This topic describes how to troubleshoot the fault when ISDN subscribers cannot hear the dialingtone after the offhook due to the inconsistency between the IUA interface ID of the UA5000and the IUA interface ID of the softswitch.


Service exception

KeywordISDN

No dialing tone

Interfaceid

Phenomenon DescriptionISDN subscribers cannot hear the dialing tone after the offhook.



l The NT1 or telephone set is faulty.l The data configuration of the UA5000 is incorrect.l The data configuration of the softswitch is incorrect.



482

Procedure

Step 1 On the UA5000 side, check the status of the port. It is found that the port is activated. Thisindicates that the fault is not caused by the NT1 or telephone set.

Step 2 Check the data configurations of the UA5000 and the softswitch. It is found that the interfaceID of the UA5000 is configured to 0 and the interface ID of the softswitch is configured to 192.

Step 3 Change the interface ID of the UA5000 to 192. Then, the fault is rectified.huawei(config-esl-user)#mgbrauser modify 0/18/0 interfaceid 192

----End


Compare the data configuration of the UA5000 with the data configuration of the softswitch.The related parameters on two sides should be consistent with each other.

TC-A0021 The Number Unobtainable Tone Is Played in the Case of the UA5000Voice Service with High-Volume Traffic Due to Severe Packet Loss of the BearerNetwork

This topic describes how to troubleshoot the fault when the number unobtainable tone is playedin the case of the UA5000 voice service with high-volume traffic due to severe packet loss ofthe bearer network.

Fault Type

Narrowband service

Packet loss

Keyword

Number unobtainable tone


The frequency of the number unobtainable tone played after dialing is high and not all the callscan be made successfully.

Alarm Information

None

Cause Analysis


l The telephone set is faulty.l The digit collection mode is incorrect.l The bearer network is faulty.



483

Procedure

Step 1 Replace the telephone set with the telephone sets of various types, and the fault persists.

Step 2 Check the data on site. It is found that the data is correct. Trace the signaling of the softswitch.It is found that the digitmap matching is correct.

Step 3 In the transit exchange, trace signaling system number 7 (SS7). It is found that the receivednumber and the dialed number are different, and certain dialed digits are lost. Sending the pingpackets to the gateway proves severe packet loss, and the packet loss rate reaches 35%. Thebandwidth of the egress of the transit exchange is 100 Mbit/s. The broadband services, NGNservices, and data detection occupy 90 Mbit/s. After the bandwidth is expanded, the fault isrectified.

----End

Suggestion and SummaryPacket loss on the network causes information loss and in this case the received number and thedialed number are different, and thus the number unobtainable tone is played.

TC-A0023 Making Long Distance Calls Fails Because Commas Exist in theDigitmap Issued by the Softswitch

This topic describes how to troubleshoot the fault when making long distance calls fails becausecommas exist in the digitmap issued by the softswitch.


Service exception

KeywordDigitmap

Syntax error

Dialing tone

Phenomenon DescriptionWhen the interconnection between the UA5000 PVM and the softswitch is tested, making along-distance call fails, and the second dialing tone cannot be heard after digit 8 is dialed.


Cause AnalysisAccording to the error message "Syntax error in message", the possible causes are as follows:

l The UA5000 fails to identify the syntax error in the signaling.



484

l The format of the digitmap is incorrect, which contains the invalid parameters or symbolsthat do not comply with the protocol.

Procedure

Step 1 According to the signaling captured when the fault occurs, the previous signaling before theerror message is the digitmap issued by the softswitch and its contents are shown as follows:#@ 7210 #@20080828.15:51:26.960 #@MGC->MG #@!/2 [192.168.199.131]:2944 T=10497250{C=-{MF=A1{DM=DM469199180354 {(1[2,4,8,9]x|[3,4,7,8,9]xxxxxxxxx|10xxxxxxxxxxx.|1[2,4,8,9]x|[2,5][1-5]xxx.|10xxx.|2[6-9]xxx.|5[0,6-9]xxx.)},E=10543282{dd/ce{DM=DM469199180354 },al/on,al/fl},SG{cg/dt}}}}

At this time, the UA5000 returns a message "Syntax error in message":

#@ 7211 #@20080828.15:51:26.960 #@MG->MGC #@!/2 [192.168.201.40]:2944 ER=400{"Syntax error in message"}

Step 2 Analyze the digitmap issued by the softswitch. It is found that multiple commas exist in thedigitmap, such as [2,4,8,9]. Commas in the digitmap are not compliant with relevant protocols.

Step 3 Modify the digitmap and stop using the digitmap containing commas. Then, the fault is rectified.

----End


The dialup fault is often caused by the digitmap. To locate such a fault, it is recommended thatyou capture and analyze packets.

TC-A0025 No Ringing Current Is Generated on the Subscriber Lines of the F01D500Subtending Shelf Because the Ringing Current Cable of the F01D500 SubtendingShelf Is Burned

This topic describes how to troubleshoot the fault when no ringing current is generated on thesubscriber lines of the F01D500 subtending shelf because the ringing current cable of theF01D500 subtending shelf is burned.

Fault Type

Narrowband service

Service exception

Keyword

Ringing current

Subtending


No ringing current is generated on the subscriber lines of the F01D500 subtending shelf, andthe CLIP is in the normal state when the subscriber makes a call or answers a call.



485

Alarm Information

None

Cause Analysis

The ringing current passes through the power module, the backplane of the master shelf, PWX2,the ringing current cable of the subtending shelf, and the backplane of the subtending shelf, andthen finally arrives at the service board of the subtending shelf. The possible causes of the faultare as follows:


l The backplane of the master shelf is faulty.

l The ringing current cable of the subtending shelf is faulty.

Procedure

Step 1 After checking, LEDs PWX2 VA0 and Fail are off, and no ringing current is generated on thesubscriber lines of the subtending shelf. After the power board is replaced, the fault persists.

Step 2 It is suspected that the backplane of the master shelf is faulty. After the shelf is replaced, thefault persists.

Step 3 After checking again, it is found that the ringing current cable of the subtending shelf is burned.After the ringing current cable is replaced, the fault is rectified.

----End


In the case of this fault, you need to check whether the ringing current cable is damaged inadvance.

TC-A0027 IC Card Telephones Connected to the UA5000 Cannot Make Calls Dueto Configuration Errors on the Intelligent Network

This topic describes how to troubleshoot the fault when IC card telephones connected to theUA5000 cannot make calls due to configuration errors on the intelligent network (IN).

Fault Type

Narrowband service

Service exception

Keyword

Intelligent network

IC card

Phones that can answer calls but cannot make calls



486

Phenomenon Descriptionl Networking: IC card telephone -> UA5000 -> intelligent network

l In the case of two IC card telephones connected to a UA5000, calls can be answered andemergency calls can be made, but calls to other subscribers such as fixed line phonesubscribers, Little Smart subscribers, and mobile subscribers cannot be made.

Alarm Information

None

Cause Analysis


l The IC card has insufficient balance or has expired.

l The digitmap mapping is incorrect.


l The settings of the intelligent network do not match the settings of the IC card.

Procedure

Step 1 Use the IC card in other telephones. If the calls can be made normally, it indicates that the ICcard has available balance or does not expire.

Step 2 Check digitmaps using the Toolbox. It is found that the softswitch has issued the digitmap tothe subscribers connected to the UA5000 and the signaling procedure is correct.

Step 3 Check the digit collection mode of the IC card telephone. It is found that the mode is UM, whichis consistent with that of other IC card telephones connected to UA5000s on other sites.

Step 4 Check the upper-layer intelligent network. It is found that the customer individually configuresthe intelligent public telephone (IPT) service and IC card service. The call barring is configuredon the IPT users who can make only 200, 300, and emergency calls and cannot make commoncalls, but the IC card users can make common calls after installing the IC card in the IPT. Duringthe deployment, the IC card phones are mistakenly configured with the IPT services, whichresults in this fault. Reconfigure the IC card telephones with normal IC card services, and thenthe fault is rectified.

----End


To facilitate fault locating, you’d better know the service type before troubleshooting the faultthat the phones can answer calls but cannot make calls.

TC-A0062 The H.248 Protocol Packets Cannot Be Retransmitted Because theInterface Attributes Are Configured Incorrectly

This case describes how to troubleshoot the fault wherein the H.248 protocol packets cannot beretransmitted because the interface attributes are configured incorrectly.



487

Fault Type

Narrowband service

Service exception

Keyword

alf/udp

Fault Description

The analysis of the packets captured on site shows that the UA5000 fails to receive the replymessage from the softswitch when the packet loss occurs on the network. As a result, the UA5000does not retransmit the packets as allowed by the H.248 protocol.

Alarm Information

None

Cause Analysis


l The transaction reliability parameter of the H.248 protocol stack is configured incorrectly.

l The interface attributes are configured incorrectly.

Procedure

Step 1 The display h248stack command is executed to check whether the transaction reliabilityparameter of the H.248 protocol stack is configured correctly. It is found that the parameter isconfigured correctly.

Step 2 The display h248stack command is executed to check the configuration of MG interfaceattributes. It is found that the attributes of the MG interface of this version is different from theattributes of the MG interfaces of the previous versions.

NOTE

In the Transmode parameters that contain TCP and UDP, parameter alf/udp is added. In the UA5000V100R017C02B107, to enable the protocol retransmission mechanism, Transmode must be configured toalf/udp, whereas in other versions, Transmode is generally configured to UDP.

Step 3 The if-h248 attribute command is executed to change the interface attribute to alf/udp, and thenthe interface is reset. After that, it is found that the fault is rectified.

----End


None



488

TC-A0063 No Dial Tone Is Played After Offhook Because the Voice File Is NotLoaded to the System

This case describes how to troubleshoot the fault wherein no dial tone is played after offhookbecause the voice file is not loaded to the system.


Service exception

Keyworddisplay version

Fault DescriptionA newly-deployed UA5000 in an office needs to support the EPON upstream transmission inintegrated mode, and thus the device is upgraded from UA5000 V100R013 to UA5000V100R017. After the services are provided through the UA5000, the broadband service isnormal, the H.248 interface is normal, but no dial tone is played after the narrowband user picksup the phone off the hook. The phone, however, is normal.



l The configuration of the softswitch is incorrect.l The interconnection parameters are configured incorrectly.l The voice file is not loaded to the system successfully after the UA5000 is upgraded.

Procedure

Step 1 The signaling tracing is performed on the softswitch. The tracing result shows that theconfiguration of the softswitch is correct.

Step 2 The interconnection parameters are checked. The check result shows that the interconnectionparameters are configured correctly.

Step 3 The display version 0/3 command is executed to query the version information about the controlboard. It is found that version number 002 is not displayed after the "Voice" parameter. Instead,the version number following the "Voice" parameter is null. Therefore, the fault is consideredto be caused by the failure of the loading of the voice file.

Step 4 The load voice command is executed to load the voice file named voice_new.efs again. Then,the fault is rectified.

----End



489


After the upgrade of the device, you need to run the display language command to check whetherthe version is upgraded successfully. In addition, you also need to run the display version 0/3command to query the detailed version information about the control board to check whetherthe voice file is loaded successfully.

TC-A0064 Dialing of the Welfare Lottery User Fails Because the 16-Port ServiceBoard Is Abnormal

This case describes how to troubleshoot the fault wherein the dialing of the welfare lottery userfails because the 16-port service board is abnormal.

Fault Type

Narrowband service

Service exception

Keyword

Welfare lottery

Fault Description

A UA5000 is used to process the voice service (implemented through dialup) provided forwelfare lottery users. A welfare lottery user reports a fault wherein the call is frequentlydisconnected and the dialing fails.

Alarm Information

None

Cause Analysis


l The network quality is poor.l The lottery machine is faulty.l The quality of the subscriber line is poor.l The parameter configuration of the UA5000 is incorrect.l The board of the UA5000 cannot work with the lottery machine normally.

Procedure

Step 1 A test is performed on site, and no fault such as packet loss that affects the network quality isdetected on the network. This indicates that the fault is not caused by the network qualityproblems.

Step 2 A normal lottery machine is used to test whether the fault can be rectified. It is found that thefault persists. This indicates that the lottery machine is normal.



490

Step 3 The lottery machine is moved to the equipment room to be tested (the lottery machine isconnected to the UA5000 not through the subscriber line). It is found that the fault persists. Thisindicates that the fault is not caused by the quality problem of the subscriber line.

Step 4 The configuration of the user parameters and the oversea parameters is checked. It is found thatthe parameter configuration is correct.

Step 5 As the fault (call disconnection and dialing failure) occurs on only one welfare lottery user amongthe three welfare lottery users, the board of the on-site UA5000 is checked. It is found that theUA5000 uses an old A16 service board. The old A16 service board is replaced by an A32 boardand then the device is tested. It is found that the fault does not occur on the welfare lottery useragain, that is, the fault is rectified.

----End


This case shows that the old service board fails to work with the new device normally. In certainservices that have strict requirements on the dialing function, such as the welfare lottery service,you must use the matching service board on the device as the configuration information requires.

TC-A0066 The Call Forwarding Service of the UA5000 User Fails Because theSoftswitch Sends the Digitmap Incorrectly

This case describes how to troubleshoot the fault wherein the call forwarding service of theUA5000 user fails because the softswitch sends the digitmap incorrectly.

Fault Type

Narrowband service

Service exception

Keyword

Call forwarding

Fault Descriptionl Networking: UA5000 -> bearer network -> softswitch

l Fault description: After user A presses * and #, the special dial tone cannot be played andthe call forwarding function cannot be performed.

l The procedure of the call forwarding service is as follows:

– Users A and B are both Centrex group users, and user A has the right to use the callforwarding service.

– A non-Centrex group user C calls user A. After answering the call, user A presses * and# to play the two-stage dial tone, and then dials the short number 8771 of user B toforward the call to user B.

– User A places the phone on the hook, and user C continues the conversation with userB.



491

Alarm Information

None

Cause Analysis


l The softswitch does not provide the call forwarding service for the user.

l The phone is faulty.

l The softswitch processes the operations incorrectly.

Procedure

Step 1 The user data configured on the softswitch is checked. It is found that the call forwarding serviceis provided for user A on the softswitch.

Step 2 The user phone is replaced and a test is performed. It is found that the fault persists.

Step 3 The H.248 messages are traced. It is found that after user A presses * and # to trigger the callforwarding service procedure, the softswitch sends an incorrect Modify message, in which thedigitmap contains two right brackets. The UA5000 cannot collect numbers according to thisdigitmap, and therefore the call forwarding service fails.

!/2 [10.37.3.102]:2944 T=1610257119{C=39{MF=AG153501000704{DM=DM381029697179 {(FF|ExxEx.F|FxxF|ExxF|ExxEx.Ex.F|FxxExxF|ExxExxExxF|EExx|FxxEx.F|ExxExxxxExxxxExxxxF|E6[28]x.|[0-8]xxx|9[2-8][0-9]xxxxxx|920x|910xxx.|912[0-268]|911[0-9]Sx.|912[3-579]Sx.|91[79]xSx.|916xxSxxxx|918xSx|99xxxxSx.|913xxxxxxxxx|9013xxxxxxxxx|915xxxxxxxxx|9015xxxxxxxxx|9010xxxSxxxxx|902xxxxSxxxxx|90[3-9]xxxxxSxxxx|90311xxxSxxxxx|9037[13679]6xxSxxxxx|904[135]1xxxSxxxxx|9051[0-9]xxxSxxxxx|9052[37]xxxSxxxxx|9053[12]xxxxxxxx|9057[1345679]xxxSxxxxx|9059[15]xxxSxxxxx|9075[57]xxxSxxxxx|90769xxxSxxxxx|90898xxxSxxxxx|900xxSx.|9[48]00xxxxxxx|900852xxxxxxxx|9xxxxxxxxxx)|EF)},E=1609730116{dd/ce{DM=DM381029697179 },al/on,al/fl},SG{cg/dt}}}}For this digitmap, error code 400 is returned by the UA5000:msg from mg([10.37.86.4]:2944) to mgc([10.37.3.102]:2944): !/2 [10.37.86.4]:2944 ER=400{"Syntax error in message"}

Step 4 The processing procedure of the call forwarding service is modified on the softswitch. Afterthat, the softswitch sends the correct digitmaps, and the fault is rectified.

----End


In the supplementary services such as call forwarding and third-party services, the UA5000performs the corresponding operations just according to the instructions from the softswitch.When similar cases occur, you need to analyze the H.248 messages carefully to locate the faultcauses. In addition, you need to know the processing procedure of the associated service.

TC-A0069 The External Call Through the UA5000 Fails Because the IP Address ofthe Outband Network Port on the UA5000 Is Configured Incorrectly

This case describes how to troubleshoot the fault wherein the external call through the UA5000fails because the IP address of the outband network port on the UA5000 is configured incorrectly.



492

Fault Type

Narrowband service

Service exception

Keyword

External call

Fault Description

When the UA5000 user dials a cross-softswitch external telephone number, no tone can be heardby the peer end. The internal call (made and answered by users connected to the same softswitch)supported by the UA5000, however, is normal.

Alarm Information

None

Cause Analysis


l The signaling interaction between the softswitch and the UA5000 is incorrect.

l The subscriber line or the hardware is faulty.

l The grounding of the main distribution frame (MDF) is not proper.

l The peer device or the local phone is faulty.

Procedure

Step 1 The grounding and hardware connection of the MDF, and the local phone are checked. It isfound that the grounding, hardware connection, and local phone are normal.

Step 2 Based on the fact that the internal call supported by the UA5000 is normal, packets are capturedto check whether the interaction between the UA5000 and the remote softswitch is normal. Thecaptured packets show that when the remote softswitch sends a signal to request the UA5000 toset up a connection with the remote softswitch whose IP address is 172.17.43.11, the UA5000sends the voice information to 0.0.0.0 instead. This indicates that the UA5000 fails to set up aconnection with the remote softswitch. As a result, the UA5000 user cannot make calls with thepeer end user. The further check of the UA5000 finds that the IP address of the local outbandnetwork port is the same as the IP address of the peer device. Then, the ip address command isexecuted to change the IP address of the local network port on the UA5000. The subsequent testshows that the external call through the UA5000 is normal.

----End


In the data plan, the IP address of the outband network port cannot be configured to any IPaddress that is already used on the network.



493

TC-A0070 The Emergency Channel Service of the UA5000 Fails Because a SoftwareParameter of the MG Interface Is Configured Incorrectly

This case describes how to troubleshoot the fault wherein the emergency channel service of theUA5000 fails because a software parameter of the MG interface is configured incorrectly.


Service exception

KeywordEmergency channel

Fault DescriptionA new service of the UA5000, namely the emergency channel service, is provided for a privatenetwork. During the test, it is found that no dial tone is played after the user picks up the phoneoff the hook. As a result, the emergency channel service cannot be implemented normally.



l The working mode of the CDI port is not configured on the UA5000.l The heartbeat detection function is not enabled on the UA5000.l The digitmap for the emergency channel service is not configured on the UA5000.l The MG interface software parameter of the UA5000 is configured incorrectly.

Procedure

Step 1 The display port attribute command is executed to check the working mode of the CDI port.It is found that the working mode of the CDI port is configured to DDI (Direct Dialing In)correctly.

Step 2 The display mg-software parameter command is executed to check the MG software parameterconfiguration of the UA5000. It is found that the heartbeat detection function of the UA5000 isenabled, but the MG interface is interrupted during the test of the emergency channel service.

Step 3 The display digitmap command is executed to check the digitmap configuration of the UA5000.It is found that the digitmap for the emergency channel service is already configured on theUA5000.

Step 4 The display mg-software parameter command is executed to check the MG software parameterconfiguration of the UA5000. It is found that a parameter value corresponding to the MGinterface software parameter name index 11 is set to 0, which means that the MG interface doesnot support the emergency channel service. Then, the mg-software parameter 11 3 command



494

is executed to set value to 3. The subsequent test shows that the emergency channel servicereturns to the normal state.

----End


The emergency channel is used when the network of the calling party is down. In this case, thecalling party can be connected to an outgoing-call port through the CDI port that is configuredwith the emergency channel service. In this manner, the calling party can make external callswith this outgoing-call port as an agent. To implement the emergency channel service, you mustdefine the required software parameters of the MG interface correctly.

TC-A0074 The Phone Conversation of the User Is Discontinuous Because the MediaIP Address of the UA5000 Conflicts with the IP Address of Another Port on theUpper-Layer Switch

This case describes how to troubleshoot the fault wherein the phone conversation of the user isdiscontinuous because the media IP address of the UA5000 conflicts with the IP address ofanother port on the upper-layer switch.

Fault Type

Narrowband service

Service exception

Keyword

IP address conflict

Fault Descriptionl Networking: UA5000 -> O/E converter -> O/E converter -> switch -> softswitch

l Fault description: The communication quality of the UA5000 user is poor, that is, the phoneconversation is discontinuous frequently.

Alarm Information

None

Cause Analysis


l The UA5000 board is faulty.


l The IP address conflict occurs.



495

ProcedureStep 1 The UA5000 is logged in and the board status of the device is checked. It is found that all the

boards of the device are normal. This indicates that the fault is not caused by the board fault.

Step 2 The optical-to-electrical (O/E) converter is connected with one PC at each end, and the two PCsare pinged from each other. It is found that no packet is lost and the optical path is normal.

Step 3 The gateway of the media IP address is pinged from the UA5000. It is found that a large numberof packets are lost.

Step 4 The gateway of the signaling IP address is pinged from the UA5000. It is found that no packetis lost.

Step 5 The upper-layer device is checked. It is found that one terminal connected to the softswitch usesan IP address that is the same as the media IP address of the UA5000.

Step 6 The data about the conflicting device is deleted from the switch. Then, the gateway of the mediaIP address is pinged from the UA5000. The subsequent test shows that the phone conversationis normal.

----End


TC-A0083 Voice Users Fail to Call Mobile or Fixed-Line Phone Numbers ThatContain Digit 3 Because of the Subscriber Lines Are Crossed

This case describes how to troubleshoot the fault wherein the voice users fail to call mobile andfixed-line numbers with digit 3 because of the subscriber lines are crossed.


Service exception

KeywordCrossed line

Dialing failure

Fixed-line phone number


Fault description: Certain users of the UA5000 fail to call mobile phone or fixed-line phonenumbers that contain digit 3.




496


l The digitmap configuration on the SoftX3000 is incorrect or a fault occurs when theSoftX3000 sends the digitmap.

l The PVM control board is faulty.l The port on the service board is faulty.l The subscriber line is faulty.l The phone is faulty.

Procedure

Step 1 Based on the fact that only certain users fail to call numbers that contain digit 3, it can bedetermined that the SoftX3000 and the PVM control boards are normal.

Step 2 The H.248 signaling is traced on the SoftX3000 and UA5000. It is found that all the numbersreported in the NOTIFY messages do not contain digit 3, whereas the users confirm that theypress the key of digit 3. Based on the fact that calling other numbers that do not contain digit 3can be successful, the phone of a user who encounters the fault is exchanged with a normalphone. Then, it is found that the fault still persists. Therefore, it can be determined that the faultis not caused by the phone.

Step 3 The test performed on the main distribution frame in the central office shows that the service isnormal. Therefore, it can be determined that the subscriber line is faulty.

Step 4 After the fault location by the subscriber line maintenance personnel, the fault is determined tobe caused by the subscriber lines that are crossed. Then, the detected subscriber lines arereplaced. The subsequent tests at the users' homes show that the services return to normal.

----End

Suggestions and SummaryWhen locating the fault causes, it is recommended that you firstly locate the direction of thefault causes and then eliminate the possible causes one by one.

TC-A0084 Brushing Bankcard Fails Because the Switching Mode of the POSMachine Is Set Incorrectly

This case describes how to troubleshoot the fault wherein brushing the bankcard fails becausethe switching mode of the point of sale (POS) machine is set incorrectly.


Service exception

KeywordPOS

Brushing bankcard



497

Fault DescriptionThe POS machine service of a UA5000 user fails.



l The network quality is poor.l The settings of the modem are incorrect.l The switching mode of the POS machine is set incorrectly.

ProcedureStep 1 The time report mode of the modem is changed to buffer report. It is found that the fault persists.

Then, the time report mode is changed to direct report. It is found that the fault still persists.

Step 2 The POS machine is replaced with a normal POS machine, and the subsequent test shows thatthe service is normal. This indicates that the network quality is good but the original POSmachine is faulty.

Step 3 The switching mode of the POS machine is changed from "C" to "E". The subsequent test showsthat the fault is rectified.

----End


TC-A0088 Playing the Dial Tone After the UA5000 User Goes Off Hook Is DelayedBecause the ARP Entry on the Upper-Layer Switch Cannot Age Out

This case describes how to troubleshoot the fault wherein playing the dial tone after the UA5000user goes off hook is delayed because the ARP entry on the upper-layer switch cannot age out.


Service exception

KeywordARP aging

Delay

Fault DescriptionNetworking: UA5000 -> H813E -> MA5680T (OLT) -> S7806 -> softswitch



498

Fault description: The gateway of the UA5000 is the IP address of the S7806. It is found thatthe dial tone after the voice user of the UA5000 goes off hook is played with a delay of about3s.

Alarm Information

None

Cause Analysis


l The intermediate link connecting the UA5000 to the softswitch is faulty (the ONU, OLT,and upper-layer switch pass through the link).

l The data configuration on the UA5000 is incorrect.l The PVM control board or the voice daughter board of the UA5000 is faulty.l The ARP entry on the upper layer device is faulty.

Procedure

Step 1 The IP address of the softswitch is pinged from the UA5000. It is found that the delay is 150ms, which is relatively long, and that the packet loss ratio reaches 8% occasionally. This indicatesthat the link is faulty. The optical link between the H813E and the OLT is checked. It is foundthat the link is normal. Then, the H813E is replaced to be tested. It is found that the fault persists.

Step 2 The packets are captured on the UA5000. It is found that after the UA5000 sends the offhooksignaling, the softswitch sends the dial tone with a delay of about 3s. The PVM control boardand voice daughter board of the UA5000 are replaced to be tested. It is found that the faultpersists.

Step 3 The data configuration on the UA5000 is checked. It is found that the media and voice signalingIP addresses are the same. Then, the media IP address is changed to the voice signaling IP addressto be tested. It is found that the fault persists.

Step 4 The ARP entry on the S7806 is checked. It is found that the ARP entry of the S8706 learns onlythe media IP address of the UA5000 before the change whereas does not learn the media IPaddress after the change. The further check proves that the ARP entry aging mechanism of theS7806 has a bug of occasional failure. After the ARP entry is cleared and re-learned, the faultis rectified.

----End


When dealing with complicated network problems, make analysis on a basis of whole networkand accordingly look for a breakthrough to locate the fault.

TC-A0098 No Tone Is Played After Certain Users Go Off Hook Because the LoadedShelf Type Is Incorrect

This case describes how to troubleshoot the fault wherein no tone is played after certain usersgo offhook because the loaded shelf type is incorrect.



499


Other

KeywordHLB


Fault DescriptionNetworking: UA5000 -> LAN switch -> MA5200G (BRAS) -> CN2

Fault description: The service can be successfully provided for only the users connected to thefirst board of the UA5000, and cannot be provided for users connected to other boards (in thiscase, no dial tone is played after the user goes off hook).



l The service board is faulty.l The softswitch fails to provide the service normally because it is configured with the user

data of only the first A32 board of the UA5000.l The backplane is faulty because only the first slot is normal and the other slots are faulty.l The UA5000 is not configured with the TID correctly.l The power module or other module is faulty, which affects the users connected to the entire

shelf.l The shelf type is incorrect.

Procedure

Step 1 To check whether the fault is caused by the board, the board in the first slot is interchanged witha board in another slot. It is found that still only the services on the board in the first slot arenormal.

Step 2 The data of the softswitch is checked. It is found that the switch is configured with data of usersconnected to other boards.

Step 3 To check whether the fault is caused by the slot, the TID of the first slot is configured on otherslots to be tested. It is found that the fault persists.

Step 4 The TID configured on the UA5000 is checked. It is found that the TID is configured strictlyaccording to the requirement of the carrier, that is, the TID is correct.

Step 5 To verify that the fault is not caused by the slot, the backplane is replaced. It is found that thefault persists.



500

Step 6 During the replacement of the backplane, it is found that the backplane is the HLB board, whereasthe shelf type is configured to HMB according to the mark (AMG5160A) on the device. Whenthe device type is regarded as AMG5160A, the default backplane is the HMB board.

Step 7 The shelf type is changed. Then, it is found that the fault is rectified.

----End


When adding shelves to an integrated access device, to avoid being confused by the device namemarked on the front panel of the device, you need to check the type of the backplane and configurethe correct shelf type. This helps to prevent such faults.

TC-A0102 The Interface Cannot Register with the Softswitch After InterruptionBecause the Signaling IP Addresses of Two AGs Conflict

This case describes how to troubleshoot the fault wherein the interface cannot register with thesoftswitch after interruption because the signaling IP addresses of two AGs conflict.

Fault Type

Narrowband service:

Service exception

Keyword

Registration failure

Signaling IP address conflict

Fault Description

Fault description: In an office, the bearer network is upgraded. The MG interface of an AGcannot recover after upgrade. The fault persists even when the MG interface is reset after thelogin to the AG.

Alarm Information

None

Cause Analysis



l The AG cannot communicate with the softswitch normally.

l The H.248 signaling interaction channel is faulty. For example, there is IP address conflictor MAC address conflict on the channel.



501

Procedure

Step 1 The AG is pinged remotely and it is found that no packet loss occurs.

Step 2 The softswitch is pinged from the AG and it is found that no packet loss occurs.

Step 3 The signaling is traced on the AG. It is found that the AG sends the registration requestcontinuously. The softswitch, however, does not respond. The AG configuration is checked onthe softswitch side. When the softswitch queries nodes, two MGs that share the same IP addressare found. An IP address is modified, and then the registration is successful after the MG interfaceis reset.

----End


TC-A0105 Sometimes No Tone Is Played After Offhook Because the Software BIOSVersions of Two RSU Boards Are Different

This case describes how to troubleshoot the fault wherein sometimes no tone is played afteroffhook because the software BIOS versions of two RSU boards are different.


Service exception

KeywordRSU


Fault DescriptionNetworking: VRSP -> OLT -> C&C08

Fault description: The fault wherein no tone is played after offhook occurs on certain users, butthe users can make phone calls normally after a period of time.



l The DSP resources are insufficient.l The 2M link quality is poor.l The subscriber line is faulty.



502

l The MDF and the device are grounded inappropriately.

l The BIOS versions of two RSU boards are different.

Procedure

Step 1 The resources are checked. When the resources are sufficient, the user hears the busy tone afteroffhook.

Step 2 The 2M cable is replaced by another 2M cable. It is found the fault persists.

Step 3 A call test is performed directly on the cable distribution frame. It is found that the fault persists.This indicates that the fault is not caused by the subscriber line.

Step 4 The grounding is checked and the grounding resistance is tested. It is found that the groundingis proper and the grounding resistance complies with standards. This indicates that the fault isnot caused by the grounding.

Step 5 An RSU board is removed and only one RSU board is configured. It is found that the fault doesnot recur. It is considered that the versions of the two RSU boards may be inconsistent.

Step 6 The display version command is executed to check the software versions and BIOS versionsof the two RSU boards. It is found that the BIOS versions are different. The software versionsand BIOS versions of the two RSU boards are upgraded, and then it is found that the fault isrectified.

----End


In this troubleshooting case, the two RSU boards run normally, and hence it is hard to identifywhether they match each other. Therefore, to identify the causes of the fault, you need to usethe exclusion method or run the associated commands to obtain required information.

TC-A0114 The Connection of the Automatic Meter Reading Terminal Fails to BeSet Up Because Codecs Are Switched in the Negotiation Flow of the Softswich ofAnother Company

This case describes how to troubleshoot the fault wherein the connection of the automatic meterreading terminal fails to be set up because codecs are switched in the negotiation flow of thesoftswich of another company.

Fault Type

Narrowband service

Service exception

Keyword

Automatic meter reading

Dialing between modems



503

Fault Description

Networking: User terminal -> UA5000 -> S6506R -> C7609 -> softswitch

Fault description: The UA5000 of an operator is connected to the automatic meter readingterminal (modem of a certain model) of a water supply company. The remote meter reading(dialing between modems) service is normal on the PSTN network. The connection of theautomatic meter reading terminal fails to be set up when it is cut over to the UA5000 of Huawei.The services such as the plain old voice service are normal and the communication quality isgood.

Alarm Information

None

Cause Analysis


l The flow of issuing signaling by the softswitch is incorrect.

l The parameters of the deployed modem on the UA5000 of Huawei are incorrect.

l The modem used in the water supply company has special flows.

Procedure

Step 1 Packets are captured on site for analysis. The softswitch issues packets, requiring the peer endto support the 804 codec. In fact, it is the AG of Huawei that chooses to support the 804 codec.It is found that the parameter 8 comes first. Therefore, the AG respond to parameter 8preferentially. The AG of Huawei chooses the parameter 8, which indicates that the AG supportsthe G.711A codec.

Step 2 The softswitch issues the ANSAMbar signal and negotiates with the modem. Note that the AGof Huawei uses the G.711A codec for negotiation. The softswitch issues a command to changethe codec. It is found that the parameter 8 follows the parameter 0 this time. The AG of Huaweialso supports the parameter 0, so it responds to the parameter 0. In this way, codecs are switchedin the negotiation flow and the modem negotiation fails.

Step 3 The maintenance personnel of the softswitch company are contacted to modify the softswitchtemplate to use the G.711A codec. Then, it is found that the fault is rectified.

----End


For this fault, analyzing captured packets can be used to quickly locate the fault to prevent themisunderstanding of Huawei's devices by customers.

TC-A0116 Partial Calls Fail to Be Connected Because the DSP Daughter Board onthe UA5000 Is Faulty

This case describes how to troubleshoot the fault wherein partial calls fail to be connectedbecause the DSP daughter board on the UA5000 is faulty.



504

Fault Type

Narrowband service

Service exception

Keyword

Wrong number

Connection

Fault Description

Networking: UA5000 -> SoftX3000

Fault description: When the user makes phone calls, a message is occasionally prompted afterdialup indicating that the dialed number is incorrect.

Alarm Information

None

Cause Analysis


l The telephone is faulty.l The softswitch is faulty.l Packet loss, network jitter, and delay occur.l The port gain and impedance are incorrect.l The DSP daughter board is faulty.

Procedure

Step 1 The signaling of abnormal communication is captured on the AG. It is found that digits are notreported completely. This indicates that the fault is not caused by the network or softswitch.

Step 2 Other types of telephones are used for testing. It is found that the fault persists. This indicatesthat the fault is not caused by the telephone.

Step 3 The port gain and impedance are modified for testing. It is found that the fault persists. Thisindicates that the fault is not caused by the port configuration fault.

Step 4 It is considered that the DSP daughter board processing may be faulty. The DSP channelsoccupied in the normal communication and abnormal communication are observed. It is foundthat the fault occurs when the DSP channel is on the daughter board in slot 0/5/1. The DSPchannel on the daughter board in slot 0/5/1 is disabled. Then the test is performed again. It isfound that the communication is normal.

Step 5 The H602ETCA daughter board in slot 0/5/1 is replaced and the fault is rectified.

----End



505


None

TC-A0118 No Dial Tone Is Played After Users Connected to the UA5000 GoOffhook Because the Signaling Issued by the Softswitch Contains the abj Package

This case describes how to troubleshoot the fault wherein no dial tone is played after usersconnected to the UA5000 go offhook because the signaling issued by the softswitch containsthe abj package.

Fault Type

Narrowband service

Service exception

Keyword

abj package

dial tone

Fault Description

Fault description: When the interconnection between the UA5000 and the softswitch of a peervendor is tested, no dial tone is played after offhook after data on the softswitch and UA5000 isconfigured. The signaling is traced and the following information is found.

l ERROR Descriptor: ER=440{"Unsupported or unknown Package"}

l ERROR Descriptor: ER=411{"The transaction refers to an unknown ContextID"}

Alarm Information

None

Cause Analysis


l The 440 error is caused by the abj package that the UA5000 does not support.

l The 411 error is caused by the unknown context. The softswitch issues signaling {C=*{S=A0}} and then {C=99 {W-S=*}}. This error can be ignored.

l No dial tone is played because a fault occurs in ADD and the softswitch does not issue thedial tone.

Procedure

Step 1 According to the error prompt obtained in the signaling tracing, it is found that the fault is causedby the abj package contained in the signaling that the softswitch issues. The UA5000 currentlydoes not support the abj package.



506

Step 2 The parameter on the softswitch is changed so that the softswitch does not issue the abj package.The parameter Jitter buffer is changed from fixed to adaptive.

Step 3 A test is performed again and it is found that the dial tone is played. The fault is rectified. Inaddition, the captured packets after modification are checked. It is found that the signaling doesnot contain the abj package.

----End

Suggestions and SummaryFor this fault, you are advised to first check whether the physical connection is correct. If thephysical connection is correct, capture the signaling for analysis.

A simple method of checking whether the physical connection is correct is as follows: Hook offthe telephone and then log in to the UA5000 to check whether the corresponding port is in thebusy state after manual offhook. If the port is not in the busy state, it indicates that the physicalconnection is incorrect. Thus, no dial tone is played. If the physical connection is correct, checkthe configuration of the UA5000 and the softswitch.

Then, capture the signaling for analysis. Rectify the fault step by step to quickly locate the fault.

TC-A0119 No Ringing Tone Is Played for Users Connected to the A32 Service BoardBecause the Relay Is Faulty

This case describes how to troubleshoot the fault wherein no ringing tone is played for usersconnected to the A32 service board because the relay is faulty.


Service exception

KeywordA32

Ringing tone

Fault DescriptionFault description: When a user on the A32 service board is called by another user, no ringingtone is played.



The A32 service board is faulty. The fault is always caused by the relay of the correspondingport and the relay fault occurs because the carbon granules inside the relay cannot roll freely.



507

Procedure

Step 1 The pots circuit-test command is executed to perform a circuit test for the user. It is found thatthe test result Ringing is abnormal.

Step 2 The A32 service board is removed and the relay of the corresponding user port is found. Therelay is knocked ten times with a pen to shake the carbon granules inside the relay. Then, thecarbon granules can roll freely. The A32 service board is inserted again. After the board runsnormally, a dialing test is performed and it is found that the ringing is normal.

----End


During the maintenance, the fault that no ringing tone is played occurs frequently. Generally,the A32 service board is sent back to the HQ for maintenance. The freight, however, is expensive,which increases the cost. The method used in this case has been applied on site many times.Therefore, when similar fault occurs, it is recommend that you first use this method.

TC-A0120 The Voice Service Fails Because the H.248 Protocol Versions on the MGInterface and Softswitch Are Different

This case describes how to troubleshoot the fault wherein the voice service fails because the H.248 protocol versions on the MG interface and softswitch are different.

Fault Type

Narrowband service

Service exception

Keyword

Ringing interruption

Ringback tone interruption

Fault Description

Networking: UA5000 -> bearer network -> SoftX3000

Fault description: The calling party can hear the first ringback tone and then hears the busy tone.After that, the ringing is interrupted. The called party hears the first ringing tone and then theringing is interrupted. The calling party hears the busy tone. The UA5000 on the softswitch side,however, is normal.

Alarm Information

MG interface disconnection alarm

Cause Analysis




508

l The line quality of the upstream link is poor.l The parameters of the UA5000 do not match those of the softswitch.

ProcedureStep 1 The alarm record is checked. It is found except the MG interface interruption alarm, no other

important alarms exist in the alarm record. Therefore, the UA5000 can be remotely logged in.

Step 2 The display if-mgcp state command is executed to check the status of the MG interface and itis found that the MG interface is in the normal state.

Step 3 The signaling of a number is traced on the softswitch side. It is found that the latest H.248protocol version in the attributes of the MG interface is different from that on the softswitch.

Step 4 The H.248 protocol version on the UA5000 is changed to the same as that on the softswitch. Anew call test is performed, and it is found that the communication is normal. The fault is rectified.

----End

Suggestions and SummaryWhen a call problem occurs, check the alarm information and H.248 signaling first, which helpsyou locate the fault quickly.

TC-A0123 The IUA Link on the UA5000 Fails to Be Activated Because the Port onthe SoftSwitch Firewall Is Disabled

This case describes how to troubleshoot the fault wherein the IUA link on the UA5000 fails tobe activated because the port on the softSwitch firewall is disabled.


Service exception

KeywordIUA link

Activate

Fault DescriptionFault description: In an office, the UA5000 ISDN service is configured. After the IUA link setand IUA link are configured, the IUA link fails to be activated and the IAU link is in the downstate.





509

l The MG interface on the UA5000 is faulty.l The data on the UA5000 is inconsistent with the data on the softswitch.l The network device masks the port of the IUA link.

Procedure

Step 1 The MG interface on the UA5000 is checked and it is found that the MG interface is normal.

Step 2 The data on the UA5000 and softswitch is checked. It is found that the data is consistent and theport ID and the IP address correspond with each other.

Step 3 The SCTP signaling is checked. It is found that the softswitch does not send the link-establishsignaling. Therefore, it is considered that the softswitch may mask the port of the IUA link. Theconfigurations of the UA5000, softswitch, and the intermediate network device are checked. Itis found that the local port for the IUA link that the UA5000 uses is disabled on the softswitchfirewall. Then, the configuration of the firewall is modified and the fault is rectified.

----End

Suggestions and SummaryThe IUA link and MG interface use different ports to register with the softswitch. The bearernetwork and softswitch should enable the port of the IUA link.

TC-A0124 Digits Are Underreported Because the DSP Daughter Board of theUA5000 Is Faulty

This case describes how to troubleshoot the fault wherein digits are underreported because theDSP daughter board of the UA5000 is faulty.


Board fault

KeywordOffhook

Underreported digits


Fault description: At a new site, all users connected to the AG can act as the called party normally;however, when they make phone calls, certain digits are underreported. The message tracing onthe softswitch side also proves this symptom.




510


l The data configuration on the softswitch (such as the issued digitmap and prefix) isincorrect.

l The telephone is faulty, which fails to report the digits correctly.l The service board is faulty (for example, the impedance does not match or the gains of the

port are incorrect).l The quality of the network is poor (for example, packet loss occurs).l The DSP chip is faulty.

ProcedureStep 1 The fault message sent back from the on-site engineer is checked. It is found that 1 in the phone

number 13812345678 is not reported.

Step 2 Other AG users call the 13812345678 phone number again. It is found that the phone numbercan be called normally. This indicates that the digitmap and prefix issued by the softswitch arecorrect (this can be confirmed in the H.248 message). At the same time, certain digits fail to bereported on the AG side. This indicates that the fault is not caused by the packet loss on thenetwork.

Step 3 Another normal telephone is used and then the test is performed again. It is found that the faultpersists. A fault occurs once every two calls and the fault message is the same as that shown inthe preceding step.

Step 4 The impedance and gains of the port on the service board are modified. It is found that the faultpersists.

Step 5 The host software version is checked. It is found that the host software configuration is normal.

Step 6 The dialing test is performed on site. It is found that the fault occurs once every two calls.According to the queried information about the DSP port occupied by the MG users, it is foundthat the fault occurs when the port under the dialing test occupies the DSP daughter boardresources of the active PVM board. Therefore, the DSP daughter board of the active PVM boardmay be faulty.

Step 7 All DSP channels of the active PVM board are disabled and then a dialup test is perform. It isfound that the fault does not recur. This indicates that the fault is caused by the DSP daughterboard of the active PVM board.

Step 8 The DSP daughter board on the active PVM board is replaced. The fault is rectified.

----End

Suggestions and SummaryOn the UA5000, when the fault that digits are underreported after offhook occurs in the voiceservice transmitted upstream over the IP network, you need to check whether the chip of theDSP daughter board is faulty.

TC-A0125 Users Cannot Answer Calls Normally Because the DSL Board Is FaultyThis case describes how to troubleshoot the fault wherein the users cannot answer calls normallybecause the DSL board is faulty.



511

Fault Type

Narrowband service

Service exception

Keyword

DSL board

Press hookflash

Fault Description

Networking: A high-density UA5000 (with one HABA shelf) is connected to the OLT. At thesame time, the softswitch is configured with the Centrex group and a console is available.

Fault description: Users supported by the HABA shelf occasionally cannot hear any voice whenthey pick up the phone after the ringing tone. They have to press hookflash to start a normalconversation. Because the user port is not fixed, this fault recurs irregularly.

Alarm Information

None

Cause Analysis


l The telephone of the user is faulty or the quality of the subscriber line is poor.

l The hardware of the UA5000 is faulty.

l The upper-layer device is faulty.

Procedure

Step 1 The telephone is replaced and a test is performed on the MDF side. It is found that the faultrecurs. This indicates that the fault is not caused by the telephone or the subscriber line.

Step 2 One service board, the control board, and the backplane are replaced and other service boardsare removed. It is found that the fault persists. This indicates that the fault is not caused by thehardware fault.

Step 3 The DSL board is removed and then a test is performed. It is found that the fault does not recur.After disconnected from the console, the DSL board is inserted and then a test is performedagain. It is found that the fault recurs. This indicates that the fault is caused by the DSL boardfault.

Step 4 The DSL board is replaced and the fault is rectified. (The DSL board may be aged or theelectronic components interferes with the DSL board. Therefore, the reporting of the offhooksignals is abnormal and this fault occurs.)

----End



512

Suggestions and SummaryThe DSL board is normal at other ONU512 sites. Therefore, the DSL board is not consideredto be faulty at first. You are advised to pay attention to each detail during troubleshooting.

TC-A0128 A Card Fails to Be Used on a POS Machine Connected to the UA5000Because the Access Code Attribute of the Softswitch Is Set Incorrectly

This case describes how to troubleshoot the fault wherein a card fails to be used on a POSmachine connected to the UA5000 because the access code attribute of the softswitch is setincorrectly.


Service exception

KeywordPOS machine

Card using failure

Fault DescriptionNetworking: UA5000 -> softswitch -> trunk gateway (TG)

Fault description: The UA5000 is connected to the core network softswitch used on the fixednetwork of an operator. The UA5000 provides the VoIP service for users and communicateswith the softswitch over the H.248 protocol. A voice user fails to use cards on an early-versionPOS machine connected to the UA5000. The POS service flow is as follows: After the user dialsthe access code xxxxxxx, the media streams are sent to the peer POS machine through the TG.



l The POS machine is faulty.l The configuration of the AG is incorrect.l The H.248 protocol negotiation is incorrect.l The negotiation flow of the modem is incorrect.

Procedure

Step 1 The POS machine is connected to the old stored program control switch through subscriber lines.It is found that the card can be used successfully. This indicates that the fault is not caused by aPOS machine fault.



513

Step 2 H.248 packets in the call flow are captured through Ethereal, and the captured packets areanalyzed. It is found that the H.248 signaling is normal, the G.711 transparent transmission modeis used, VAD is disabled, EC is enabled, and CNG is disabled, which are displayed in thesignaling. After the card fails to be used on the POS machine, the card is reused on the POSmachine multiple times. The operation, however, still fails. H.248 packets are analyzed. Noproblem is found. This indicates that the fault is not caused by incorrect H.248 negotiation flow.

Step 3 The configuration of the AG is checked. It is found that the G.711 transparent transmission modeis configured on the AG modem, and the event reporting mode is immediate reporting, whichis correct. This indicates that the fault is not caused by incorrect AG configuration.

Step 4 UDP packets in the call flow are captured through Ethereal. The UDP voice packets are restoredto a voice file through the capsens software. The frequency of the voice file is analyzed throughcooledit.

1. According to the analysis of the voice file through cooledit, the 2100 Hz ANS signalresponded by the TG is divided into three parts.

2. When the POS machine connected to the UA5000 responds to the received ANS signal,the response signal is the 980 Hz and 1180 Hz frequency shift keying (FSK) signal, whichis a call menu (CM) signal. According to the V.8 protocol, the POS machine sends the CMsignal after detecting the ANSam signal. Actually, the modem sends the ANS signals. Thedifference between the ANSam and ANS signals is that the amplitude modulation of theANSam signal is 15 Hz wider than that of the ANS signal.

3. According to the modem flow defined in the ITU-T V.8 protocol, the ANSam message isa 2100 Hz audio signal and the audio signal is reversed once every 450 ms. Nevertheless,according to the modem flow defined in the ITU-T V.25 protocol, the ANS message is anuninterrupted 2100 audio signal.

4. After the access code is dialed on the POS machine, the TG sends the ANS signal and usesthe flow defined in the V.25 protocol. The ANS signal returned by the TG is cut off. As aresult, the POS machine detects the ANS signal as the ANSam signal mistakenly. Then,the POS machine starts the flow defined in the V.8 protocol and sends the CM signal to thepeer end, which results in the negotiation failure.

5. The NGN is switched from the voice channel to the data channel in the call flow and signalsare interrupted during the switchover. The possible causes of packet loss are as follows:

l The EC of the TG does not completely cancel the initial signal in the echo cancellation.

l After the VBD is enabled on the TG and the TG detects the ANS signal, the TG switchesto the data channel and disables the EC.

l The TG is switched from the voice channel to the data channel.

Step 5 The data service of the modem has very strict requirements for network carrying. Especially,certain modems of earlier versions are sensitive to the network delay and packet loss. Thegateway serves as the source end of the IP network, and thus the delay and packet loss need tobe reduced on the gateway. When the VoIP service is used on the NGN, the memory of the codecis initialized during the switchover from the voice channel to the data channel, which definitelyresults in the signal interruption and cannot be prevented. In conclusion, the cause of the faultis as follows: The signal sent by the TG is interrupted. As a result, the POS machine mistakenlydetects the ANS signal defined in the V.25 protocol as the ANSam signal defined in the V.8protocol. Then, the negotiation flow fails.

Step 6 The access code attribute of the POS machine is set to Internet access code on the softswitch.In this way, the softswitch instructs the TG to switch from the voice channel to the data channel



514

during number analysis. No packet loss occurs in the subsequent modem negotiation. After theaccess code attribute is modified, the card can be used normally.

----End


When a similar fault occurs in the same networking, you can check the access code attribute ofthe softswitch if the card fails to be used on the POS machine, no problem is found in the H.248protocol analysis, and the fault cannot be located.

TC-A0129 A Message, Indicating No Dial Tone, Is Displayed During theAuthentication of a POS Machine Connected to the UA5000 Because the DigitmapIs Not Configured Properly

This case describes how to troubleshoot the fault wherein a message, indicating no dial tone, isdisplayed during the authentication of a POS machine connected to the UA5000 because thedigitmap is not configured properly.

Fault Type

Narrowband service

Service exception

Keyword

POS machine

Fault Description

Networking: UA5000 (HABA+HABF) -> switch -> BRAS

Fault description: A POS machine connected to the UA5000 in an office fails to connect to theserver of the bank completely. A card cannot be used and a message, indicating no dial tone, isdisplayed during authentication.

Alarm Information

None

Cause Analysis


l The POS terminal is faulty.

l The quality of the subscriber line is poor.

l The data configuration of the UA5000 is incorrect.

l The data configuration of the softswitch is incorrect.



515

Procedure

Step 1 A phone is connected to the relevant port of the POS machine for performing a test. It is foundthat outgoing calls and incoming calls can be made successfully.

Step 2 Alarms are viewed on the UA5000 after login. No QoS alarm is found.

Step 3 The softswitch is pinged on the UA5000. It is found that no packet loss occurs. This indicatesthat the fault is not caused by a bearer network fault.

Step 4 Other POS machines connected to the same UA5000 work normally. This indicates that the faultis not caused by a server fault of the bank.

Step 5 The POS machine at the faulty service site is used at the normal service site. It is found that thePOS machine works normally. POS machines at the normal service site are used at the faultyservice site. It is found that the POS machines fail to work normally. These indicate that the faultis not caused by a POS machine fault.

Step 6 Two authentication servers of the bank are located in the capital of a province and they are966000 server and 0771******* server respectively. The office does not subscribe to the tollservice. After the office subscribes to the toll service temporarily, the POS machine can beauthenticated by the 0771******* server successfully. Other POS machines connected to theUA5000 are checked on site. It is found that the POS machines can register with the 966000server successfully.

Step 7 The signaling is traced. It is found that the time taken by the POS machine at the faulty servicesite to send the authentication message (to the server of the bank) out of the city CO is 5-6 ms,which is very long.

Step 8 The softswitch is checked. It is found that the digitmap of the 966000 server is missing. Thedigitmap of the 966000 server is added. Then, the time for sending the authentication messageout of the city CO is shortened to 2-3 ms. The POS machine at the faulty service site isauthenticated. It is found that the POS machine can be authenticated successfully and cards canbe used on the POS machine normally.

----End


The service flow of the POS machine covers two phases:

l sign-in phase: In the sign-in phase, a user enters the access code on the POS machine, whichsends an authentication request to the server of the bank. The POS machine receives thekey from the server of the bank within a certain period of time (generally, 20–30 ms or 60ms to the maximum). If the POS machine fails to receive a response from the server of thebank, the POS machine sends the authentication request five times.

l card using phase: In the card using phase, after the sign-in is successful, the POS machinesends information to the bank platform in the dialup mode through the telephone line. Thebank platform identifies relevant information and sends the fee deduction information tothe issuing bank. After confirming the fee deduction information, the issuing bank respondsto the bank platform with a message. After confirming the message, the bank platform sendsprocessed information to the POS machine. After confirming the received information, thePOS machine prints the bill. After the card using is successful, a user can always use a cardfor payment if no power failure occurs.



516

TC-A0130 The Household Alarm System Fails to Work Normally Because thePacking Duration Is Very Long

This case describes how to troubleshoot the fault wherein the household alarm system fails towork normally because the packet packing duration is very long.

Fault Type

Narrowband service

Service exception

Keyword

Packet packing duration

Voice channel delay

Fault Description

After a user in country Y transfers services from operator B to operator C, the user reports thatthe household alarm system fails to work normally.

Alarm Information

None

Cause Analysis


l The household alarm system automatically calls the alarm center through the householdtelephone line, and sends relevant instructions to the alarm center through DTMF signals.In this manner, the automatic alarm function is implemented. The household alarm systemfails to work normally after the telephone operator is changed. In this case, the phase(dialing phase, connection phase, or conversation phase) where the fault occurs needs tobe confirmed first. Then, the step where the fault occurs can be confirmed.

l According to the relevant standard document NICC1704 of country Y, the household alarmsystem sends messages through DTMF signals over the Fast Format Protocol, which raisesa high requirement for the voice channel delay. Operator C, however, is a new operatorwho provides the VoIP-based service. The voice channel delay from end users of operatorC to the server on the traditional PSTN network may be long and the voice channel delaymay be set inappropriately.

Procedure

Step 1 After the fault recurs on site, the voice on the line is recorded through a voice recording pen.The recorded voice is analyzed. After the recorded voice is played, it can be rapidly determinedthat the fault occurs in the conversation phase.

Step 2 The waveform of the recorded voice is viewed through Cooledit, and then is compared with thestandard waveform. It is found that a long delay occurs on the confirmation message (1.4 kHz



517

single audio) sent by the alarm system. As a result, the server fails to receive the confirmationmessage in time, and thus the alarm fails.

Step 3 Parameters that may affect the delay and can be adjusted include only the jitter buffer and packetpacking duration on the MSAN. In current versions, the jitter buffer is dynamically adjustedaccording to the network quality. If the value of the jitter buffer is changed, the delay is affectedslightly. The packet packing duration is set by the softswitch. Currently, the packet packingduration is set to 20 ms rather than 10 ms as proposed in the NICC1704.

Step 4 The value of the jitter buffer is changed to 20 ms. It is found that the fault persists. Then, thevalue of the jitter buffer is changed back to the default value. The packet packing duration ischanged from 20 ms to 10 ms. It is found that the alarm system works normally. The waveformof DTMF signals complies with the protocol.

Step 5 After multiple tests are performed repeatedly, it is determined that the packet packing durationis the key factor that affects the alarm system. After the packet packing duration is changed from20 ms to 10 ms, the fault is rectified completely.

----End


None

TC-A0132 Medicare Cards Fail to Be Used on a Medicare POS Machine Connectedto the UA5000 Because the Access Code Attribute of the Softswitch Is SetIncorrectly

This case describes how to troubleshoot the fault wherein medicare cards fail to be used on amedicare POS machine connected to the UA5000 because the access code attribute of thesoftswitch is set incorrectly.

Fault Type

Narrowband service

Service exception

Keyword

Access code

Card using

Fault Description

Networking: POS machine -> UA5000 -> EPON access device of Huawei -> S7806 -> softswitchof another company

Fault description: An office reports that medicare cards fail to be used on a POS machineconnected to one UA5000 in a medical institution. Users can normally use medicare cards withthe original C&C08.



518



l The POS machine is faulty.l The data configuration of the UA5000 is incorrect.l The subscriber line of the port on the UA5000 is faulty. For example, interference exists

on the subscriber line or the line quality is poor.l The data configuration of the softswitch is incorrect.

Procedure

Step 1 The POS machine is checked. The POS machine is connected to the traditional PSTN networkand a test is performed. It is found that no fault occurs on the POS machine during the test. Thisindicates that the POS machine is normal.

Step 2 The data configurations of the UA5000 and modem are checked. It is found that the dataconfigurations are correct.

Step 3 The subscriber line is checked. No interference is found. The length of the subscriber line isabout 100 m. This indicates that the line quality is good.

Step 4 Bidirectional packets are captured in the mirroring mode on the uplink port. The analysis resultis as follows: GUP exists in the /ANS signal sent from the TG. As a result, the POS machinemistakenly detects the /ANS signal as the /ANSam signal. Therefore, the POS machine uses theV.8 flow and sends the CM signal, which results in the negotiation failure. The access codeattribute is set to Internet access code on the softswitch. Then, the fault is rectified.

----End

Suggestions and SummaryWhen rectifying a fault about the interconnection to the softswitch of other manufacturers, youmust exclude simple causes such as data, subscriber line, or POS machine, and then capture andanalyze packets.

TC-A0171 High CPU Usage on a UA5000 Due to a Subscriber Line FaultThis case describes the troubleshooting of a UA5000 on which the CPU usage was high due toa subscriber line fault.


Service exception

KeywordsExcessive signaling



519


Fault Description



Alarm Information


Cause Analysis


Procedure









----End


None



520

TC-A0173 Inaccessibility of Network Management Channel of a UA5000 Due to aLoop on the Upper-Layer Switch

This case describes the troubleshooting of a UA5000 on which the network management channelwas inaccessible due to a loop on the upper-layer switch.



KeywordsNMS

Self-loop

Fault DescriptionNetwork topology: UA5000 -> S3900 -> S8512 -> NE40E

NOTEThe network management gateway was configured on the S3900 and the voice service gateway was configuredon the NE40E. The UA5000 transmitted services upstream in integrated mode, and the IPMB broadband controlboard and PVMB narrowband control board were configured in the same network segment.

Fault symptom: Pinging the network management IP address of the PVMB control board fromthe IPMB control board failed, and both the voice service channel and network managementchannel of the UA5000 were inaccessible.



l The data configuration on the UA5000 was incorrect.l The internal ports on the PVMB and IPMB control boards were faulty.l The MAC address of the PVMB control board was in a conflict with the MAC address of

another device.l A loop occurred on the upper-layer switch.

Procedure

Step 1 The data configurations of the IPMB and PVMB control boards were checked and found to becorrect.

Step 2 The status of the internal ports on the IPMB and PVMB control boards was checked by runningthe display port state command on the two boards. It was found that the internal ports wereboth online and in 100 Mbit/s full-duplex working mode, indicating that the internal ports onthe two boards were normal.



521

Step 3 The display arp x.x.x.x command (x.x.x.x represents the network management IP address ofthe PVMB control board) was executed on the IPMB control board to query the ARP mappinginformation. It was found that the network management IP address of the PVMB control boardwas learned on the uplink port rather than on the internal port of the IPMB control board.Therefore, it was suspected that a loop had occurred on the upper-layer switch or the MACaddress of the PVMB control board was in a conflict with the MAC address of another device.

Step 4 The MAC address of the PVMB control board was changed. A test showed that the faultpersisted.

Step 5 The upstream optical fiber connected to the IPMB control board was removed. It was found thatthe IPMB control board learned the ARP information about the PVMB control board from theinternal port, and that the IPMB control board communicated with the PVMB control boardnormally.

Step 6 The upper-layer switch was checked. It was found that the MAC address of the PVMB controlboard drifted between two ports. Then, after the two ports were shut down on the switch, thenetwork management channel of the UA5000 was accessible.

Step 7 The layer-2 switch connected to the S3900 was checked. It was found that a loop (optical fiberself-loop) occurred on the layer-2 switch. When the loop problem was resolved and the twoshutdown ports were opened, the fault on the UA5000 was rectified.

----End


In normal state, the IPMB control board can communicate with the PVMB control board. If thetwo boards fail to communicate with each other, check whether the IPMB control board canlearn the ARP information of the PVMB control board normally. If the IPMB control boardlearns the ARP information about the PVMB control board from the uplink port, it is mostpossible that a loop occurs on the upper-layer switch of the UA5000. In such a case, the MACaddress of the PVMB control board drifts on the switch.

TC-A0175 Failure of Fax Service on a UA5000 Due to Quality Problems of theOptical Splitter

This case describes the troubleshooting of the fax service on a UA5000, which failed due toquality problems of the optical splitter.

Fault Type

Narrowband service

Service exception

Keywords

D500

Fax service failure



522

Fault Descriptionl Network topology: UA5000 (F01D500) -> optical splitter -> MA5680T -> switch (S7806)

-> router (NE40) -> softswitch

l Fault symptom: Users connected to certain ports on a UA5000 that uses the F01D500cabinet failed to send and receive faxes normally, but the voice services of the users werenormal. The detailed fault symptoms were as follows:

– Seven to eight fax machines connected to the F01D500 could send/receive fax to/fromeach other normally.

– The fax machines connected to the F01D500 failed to send/receive fax to/from the faxmachines that were not connected to the F01D500.

Alarm Information

None

Cause Analysis


l The fax machine was faulty.



l Packet loss occurred on the optical path.

Procedure

Step 1 An affected fax machine was replaced. A test showed that the fault persisted.

Step 2 The fax machine was directly connected to the circuit line instead of the subscriber line. A testshowed that the fault persisted.

Step 3 The data configuration of the UA5000 was checked on site and found to be correct.

Step 4 The optical path was checked. It was found that a 1.3‰ packet loss occurred between theUA5000 and the softswitch.

Step 5 Packet pinging test between two devices was performed segment by segment on the network. Itwas found that no ping packet was discarded between the S7806 and the softswitch, and betweenthe S7806 and the MA5680T. The ping packet loss occurred between the S7806 and the UA5000,and between the MA5680T and the UA5000. Therefore, it was determined that the fault occurredbetween the MA5680T and the UA5000.

Step 6 The upstream PON board of the UA5000 was replaced. It was found that the fault persisted.

Step 7 The PON access service board for the MA5680T was replaced. It was found that the faultpersisted.

Step 8 The optical splitter between the MA5680T and the UA5000 was replaced. It was found that thefault did not occur and the fax service ran normally.

----End



523

Suggestions and Summaryl The data services, such as the fax and modem services, are sensitive to the delay caused by

packet loss. Therefore, when such services fail, it is recommended to first check whethera packet loss occurs on the network.

l If the optical splitter used by the customer is not provided by Huawei, it is recommendedto check the optical splitter when troubleshooting the FTTX problems.

TC-A0176 Absence of Caller Identification for UA5000 Users Due to IncorrectRinging Mode Settings on the Switch

This case describes the troubleshooting of a UA5000 on which the caller identification was notdisplayed due to incorrect ringing mode settings on the switch.


Service exception

KeywordsLong ringing

VRSP mode

Fault DescriptionNetwork topology: VRSP -> C&C08 switch

Fault symptom: The caller identification was not displayed for certain users connected to theUA5000.



l The phone or subscriber line was faulty.l The grounding resistance or the interference was great, or the transmission quality was

poor.l The power board or the service board was faulty.l The data configuration of the switch was incorrect.

Procedure

Step 1 Different new phones were connected directly to the device in the telecommunications room,rather than connected through the subscriber line. The subsequent tests showed that the calleridentification was not displayed on all the phones.



524

Step 2 The grounding of the UA5000 was checked. It was found that the device was grounded properly.Then, a test meter, such as a multimeter, was used to test the current on the device. No abnormalcurrent was detected on the device.

Step 3 The power board of the device was checked. It was found that the board was in the normal state.In addition, given that only one 2M link was configured on the device and there was no noisein normal calls on the device, it was determined that the transmission device was normal.

Step 4 A further analysis of the fault symptoms showed that the ringing modes of all the users whoencountered the fault were long-ringing mode (that is, the ringing was played withoutinterruption). Then, after the configuration of the ringing modes of these users was corrected onthe switch, the fault was rectified.

----End


TC-A0178 Static on the Lines Connected to Certain Boards of the UA5000 Due toInconsistency of Shelf Types

This case describes the troubleshooting of the static on the lines connected to certain boards ofa UA5000 due to inconsistency of the shelf types.


Service exception

KeywordsConsistency of shelf types

Static on the line

Outdoor cabinet

Fault DescriptionUsers connected to slots 20, 21, 22, 30, and 31 in the second shelf of an outdoor cabinet ofUA5000 could hardly complete a conversation with other uses by phone, because there wasstatic on the lines.



l The network quality was poor.



525


l The device was not grounded properly or the subtending cables were not connectedproperly.

l The slot on the backplane of the shelf was faulty.

l The data configuration was different from the actual hardware configuration.

Procedure

Step 1 The UA5000 was logged in and the ping command was executed to ping the gateway. Thegateway could be pinged, indicating that the network quality was good.

Step 2 The board in an affected slot was replaced with a board in a normal slot. It was found that thefault persisted, indicating that the fault was not caused by a service board problem.

Step 3 Given that the fault occurred on only certain boards rather than all the boards on the device, itcould be preliminarily determined that the fault was not caused by the grounding problem of thedevice.

Step 4 The display frame info command was executed to query the information about the shelf.huawei(config)#display frame info{ <cr>|frameid<0,97> }: Command: display frame info ---------------------------------------------------------------------------- FrameID FrameType FrameState ---------------------------------------------------------------------------- 0 MAIN_HABM_30(HABA) Normal ----------------------------------------------------------------------------

It was found that the shelf added in software was an HABA shelf, which, however, should notbe configured on an outdoor cabinet.

Step 5 A check on site showed that the UA5000 uses the F01D500 cabinet and HABD+HABF shelves.When the HABA shelf was deleted by executing the frame delete command and then the correctshelf was added by executing the frame add command, it was found that the static on the linedisappeared and that the users could have conversations by phone normally. The command foradding the correct shelf is as follows:huawei(config)#frame add 0 FrameType: 0 : MAIN_HABM_30(HABA) 1 : MAIN_HAFM_30(HABD) 2 : MAIN_HAFM_6(HABL) 3 : MAIN_H602HABD(HABD) 4 : MAIN_H601HABC(HABC) 5 : MAIN_H601HABO(HABO) 6 : MAIN_H601HABM(HABM) 7 : SLAVE_HAFS_32(HABE) 8 : SLAVE_HABS_32(HABB) 9 : SLAVE_HABS_30(HABA) 10 : SLAVE_HAFS_30(HABD) 11 : SLAVE_H602HABD(HABD) 12 : SLAVE_H602HABE(HABE) 13 : RSU_HAFS_30(HABD) 14 : RSU_HABS_30(HABA) 15 : RSU_HAFS_12(HABC) 16 : RSU_HAFS_6(HABL) 17 : RSUG_ONU60A(HUBO) 18 : RSUG_ONU04A 19 : RSUG_ONU08A 20 : RSP_19(HCB) 21 : RSP_15(HDB) 22 : RSP_14(HIB) 23 : RSP_12(HFB) 24 : RSP_10(HGB) 25 : RSP_6A(HMB) 26 : RSP_6B(HLB) 27 : UAM_R (HUBM) 28 : UAS_R (HUBS) 29 : UAFM_R(HUBE) 30 : UAFS_R(HUBF) 31 : UAMB_R(HUBB) 32 : ONU60A_R(HUBO) 33 : ONUF01D100_R(HUBL) 34 : VRSP_12(HABA) 35 : VRSP_18(HABA) 36 : HWTA(HIB_1) 37 : HWTA(HIB_2) 38 : HWTA(HIB_3)



526

Please select frame type (0 ~ 38):3 Frame add successfully

----End


In this case, as the device could run normally when it was configured with the HABA shelfduring deployment, this fault did not occur before. However, the device processes datadifferently when it is configured with different types of shelves in software. If the softwareconfiguration of the device is incorrect, a fault may occur one day. Therefore, during devicedeployment, you must configure the device correctly according to the actual hardwareconfiguration of the device.



Fault Type

Ethernet service


Keywords

PADS

Number of users

Fault Description

Network topology: PC -> UA5000 -> router (6506R) -> BRAS


Alarm Information

None

Cause Analysis


l A loop occurred on user ports.

l A loop occurred on a port on the upper-layer device.

l The upstream optical-to-electrical (O/E) converter was faulty.

l The number of permitted BRAS users was limited.



527

Procedure









Specifically, ACL4001 rule matched only one packet, namely PADO, whereas ACL4000 rulematched four packets because the user PC sent four PADR packets. Therefore, it was determined



528

that the error 676 fault was caused because the upper-layer device did not respond to the userwith the PADS packet. After the same method was used on router 6506R to collect trafficstatistics, the same problem was found.


----End

Suggestions and SummaryError 676 during dialup is seldom caused by the restriction on the number of permitted BRASconnections, which therefore is often ignored during the handling of error 676. This case can beused as a reference for troubleshooting similar faults.

TC-A0191 Fault on a Newly-Added SPC Due to the Local Loopback on the E1 PortThis case describes the troubleshooting of a newly added SPC that was faulty due to the localloopback on the E1 port.


Service abnormality

KeywordsSPC

Port loopback

Fault DescriptionThe control board of the UA5000 was PVMB and the service board was SDL. After running thecommand for adding an SPC, the system displayed the message "SPC fault".



l The service boards were faulty.l The timeslot configuration was configured incorrectly.l Local loopback occurred on the E1 ports.

ProcedureStep 1 The display board 0 command was executed to query the board status. It was found that the

board was normal.



529

huawei(config)#display board 0 ------------------------------------------------------------------------- SlotID BoardName Status Sub0 Sub1 Online/Offline ------------------------------------------------------------------------- 0 PWX2 Normal 1 PWX2 Normal 2 3 4 H601PVMBF Active_normal H602ETCA 5 6 A32 Normal 7 A32 Normal 8 A32 Normal 9 A32 Normal 10 A32 Normal 11 A32 Normal 12 SDL Normal 13 SDL Normal 14 SDL Normal 15 SDL Normal

Step 2 The display_timeslot command was executed to check the timeslot occupancy status on theport on the SDL board. It was found that all the timeslots on the port were in the idle state.Therefore, it was determined that the SPC was faulty.huawei(config-if-sdl-0/13)#display timeslot ---------------------------------------------------------- | 0--7 | 8--15 | 16--23 | 24--31 | ---------------------------------------------------------- First HW | 00000000 | 00000000 | 00000000 | 00000000 | Second HW | 00000000 | 00000000 | 00000000 | 00000000 | First FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Second FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Third FE1 | 00000000 | 00000000 | 00000000 | 00000000 | Fourth FE1 | 00000000 | 00000000 | 00000000 | 00000000 | First SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Second SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Third SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | Fourth SHDSL | 00000000 | 00000000 | 00000000 | 00000000 | ---------------------------------------------------------- '0'-Not used; '1'-Used ----------------------------------------------------------

Step 3 The spc delete command was executed to delete the faulty SPC and then the spc add commandwas executed to add a new SPC. However, the system still displayed "SPC fault".

Step 4 In the SDL mode, the display port state command was executed to query the ports status. Itwas found that a local loopback was performed on the E1 port.huawei(config-if-sdl-0/13)#display port state ------------------------------------------------------------------------- Port Type Frame Loop ALARM( LOS LFA RRA LMFA AIS CRC4 ) ------------------------------------------------------------------------- 0 FE1 PCM31 Local loopback N N N N N N 1 FE1 PCM31 No loopback Y Y N N N N 2 FE1 PCM31 No loopback Y Y N N N N 3 FE1 PCM31 No loopback Y Y N N N N ----------------------------------------------------- Port Type Rate Loop State ----------------------------------------------------- 4 SHDSL(V35) 32x64K No loopback Deactive 5 SHDSL(FE1) 32x64K No loopback Deactive 6 SHDSL(FE1) 32x64K No loopback Deactive 7 SHDSL(FE1) 32x64K No loopback Deactive -----------------------------------------------------

Step 5 The undo port_loopback command was executed to cancel the local loopback. It was foundthat the SPC returned to the normal state.

----End



530

Suggestions and SummaryIf the bound E1 port is configured with loopback before the SPC is added, it is necessary tocancel the loopback on the E1 port and then add the SPC. If the loopback on the E1 port isrequired, it is recommended to cancel the loopback immediately after the test because theloopback may affect services.

TC-A0192 Fax Receiving Failure on a Fax Machine That Can Normally Transmit aFax Due to Incorrect Packets Issued by the Softswitch

This case describes the troubleshooting of a fax machine that could transmit a fax but could notreceive a fax due to incorrect packets issued by the softswitch.


Service abnormality

KeywordsER=500

Fax receiving failure

Fault DescriptionNetwork topology: UA5000 (EP1A) -> MA5680T -> bearer network -> softswitch

Fault symptom: The user under the UA5000 could transmit but could not receive the fax.



l The fax machine was faulty.l Signaling flow for interconnecting with the softswitch was improper.

Procedure

Step 1 The working status of the fax machine was checked. It was found that the fax machine workedin a normal state, indicating that the fault was not caused by the fax or configuration.

Step 2 Pinging the softswitch from the UA5000 was performed. It was found that the softswitch couldbe pinged and no alarms were generated on the device.

Step 3 Softswitch signaling was traced and analyzed as follows:!/1 [10.67.5.53]:2944 T=1442084142{C=7{MF=A15{M{O{MO=SR,tdmc/ec=Off}},E=1442056393{ctyp/dtone,al/on,al/fl}},MF=A100000006{M{ST=1{O{MO=SR,RV=OFF,RG=OFF,nt/jit=40,tdmc/ec=Off},R{v=0 o=ZTE 207 30600 IN IP4 10.67.5.54 s=phone-call c=IN IP4 10.67.4.37 t=0 0 m=audio 15498 RTP/AVP 0 a=ptime:10 a=Modem }



531

},TS{BF=OFF,ctyp/calltyp=DATA}}}}}!/1 [10.67.49.225]:2944 P=1442084142{C=7{MF=A15,MF=A100000006{ER=500{"Internal software failure in the MG"}}}}

The packet "a=Modem" that the softswitch issued could not be identified by the UA5000, andtherefore the UA5000 responded to the softswitch with the "Internal software failure in the MG"message.

Step 4 A softswitch fax profile parameter was modified, that is, the parameter "a=Modem" is deleted.After the modification, the fault was rectified.

----End


TC-A0193 Abnormal Ringing on Phones Connected to a UA5000 Due to theInterference on the Subscriber Line

This case describes the troubleshooting of the abnormal ringing on phones connected to aUA5000 due to the interference on the subscriber line.


Service abnormality

KeywordsFalse ringing

DTMF

Fault DescriptionFault symptom: The UA5000 worked in the normal state after providing the voice call service.After a period of time, users on the UA5000 reported that their phones often rang without beingcalled, and that the caller identification was also displayed. When the users took the phones offthe hook, however, no tone was played or the busy tone was played. The caller party did not callthe called party after the caller ID was dialed for acknowledgment.



l Prank call existedl The phone may be faulty.l The quality of the outside line and the insulation between line A and line B was poor.



532

l Certain ports on the service board were faulty.

Procedure

Step 1 The caller party did not call the called party according to the caller ID short number.

Step 2 The phone was normal before the cutover of the UA5000 and most of the phones encounteredthe same fault at the same time. Therefore, the fault of the phone was excluded.

Step 3 The displayed caller ID was 4 short number of intro-group when the phone rings. According tothe feature of the line and the dialing mode, it was concluded that line A and line B touched witheach other, which caused the quality of the outside line was poor. As in the case that the calledparty was called through the pulse dialing.

Step 4 The pstnport attribute set command was executed to modify the configurations and shield thedigit collecting mode. The phone did not ring after observation for several days. The fault wasremoved. The specific configurations were as follows:huawei(config-esl-user)#pstnport attribute set 0/6/0 dial-mode DTMF-only

By default, the UA5000 supports both the impulse and DTMF modes. The two modes werechanged to the DTMF mode to shield the impulse signal.

----End


The way of pulse dialing is similar to a sender sending numbers. The dialup is emulated if theoutside line is contacted with each other continually due to the poor quality of the outside line.However, for the voice call, the number is dialed in a fixed frequency, so the interference fromthe outside line does not affect the voice call.

TC-A0195 Occasional Low Transmission Rate on the Modem Due to IncorrectSoftswitch Configuration

This case describes the troubleshooting of the occasional low transmission rate on the modemconnected to a UA5000 due to incorrect configuration on the softswitch.

Fault Type

Narrowband service

Service abnormality

Keywords

Access code

Low transmission rate

Fault Description

Figure 16-4 shows network on which the subtending PPPoE users fail to access the Internet.



533

Figure 16-4 Network on which the subtending PPPoE users fail to access the Internet

CC08

A8010

Modem CModem B

Modem A

UA5000

UMG

Fault symptom:

l Modem A and modem C connected to the UA5000 could normally communicate with eachother. It was found that the transmission rate was 2 kbit/s after many on-site tests, whichtook 33% of the total number tested. The normal rate was 40 kbit/s in other time period. Adialup test was directly performed on the MDF of the UA5000, it was found that the faultpersisted.

l When a Modem B was connected to the UMG, Modem B could communicate with ModemC normally. The rate was maintained at 40 kbit/s.

l A connection was set up between Modem A and Modem B and the communication wasnormal. The rate was maintained at 40 kbit/s.

Alarm Information

None

Cause Analysis


The rate negotiation between devices was faulty.

Procedure

Step 1 The packet was captured on the uplink port of the UA5000. It was found that the UMG serversent two high speed negotiation signals to the UA5000, but Modem A stopped to respondingand the high speed signal was changed to a low speed signal. This indicated that the negotiationfailed.

Step 2 The UMG server considered the low-speed modem existed under the UA5000 before theUA5000 responded to the UMG server. Therefore the rate was directly switched to the low speedrate and the rate allowable in the low speed transmission mode was 2 kbit/s. The negotiationmode was modified on the softswitch and the internet access code was configured. When modemA worked normally, the UMG server immediately negotiate with the modem about the modem



534

information, ensuring that the UA5000 responded with the negotiation signal in time. Thus theratio of successful negotiation was improved and the problem was solved.

----End


None

TC-A0196 Absence of the Dial Tone on Certain User Phones Due to Hardware Faultin the A32 Board

This case describes the troubleshooting of absence of the dial tone on certain user phones dueto hardware fault in the A32 board.

Fault Type

Narrowband service

Service abnormality

Keywords

Abnormal dialup

Board failure

Fault Description

Fault symptom: The UA5000 was configured with the standalone transmission mode function.All the ports under the same UA5000 could normally communicate with each other, but thestatus of certain port of A32 board was in the idle status. No dial tone was played on the phoneconnected to this port.

Alarm Information

None

Cause Analysis


l Slot faults.l The board was faulty.l Port faults

Procedure

Step 1 The A32 board in slot 0/29 was interchanged with the A32 board in slot 0/25. In this case, the0/29/13 port was normal, but no dial tone was played on the phone connected to the 0/25/13port. Therefore, it was confirmed that the slot was normal.



535

Step 2 Given that other ports on the faulty A32 board could dial up normally, it was determined thatthe whole board was normal.

Step 3 A circuit line test and subscriber line test were performed separately. The result showed thatboth the circuit line of A32 board in slot 0/25 and the circuit line of A32 board in slot 0/29 werenormal. However, it was found that the subscriber lines on the two boards were faulty and thesame fault existed. It was determined that the hardware of 14 port on slot 0/29 of the A32 boardwas faulty. The circuit test result was as follows:huawei(config-test)#pots circuit-test{ v5id<K>|mgid<K>|frameid/slotid/portid<S><1,15>|telno<K> }:mgid 0 terminalid 8397{ <cr>|busy<K> }:Command: pots circuit-test mgid 0 terminalid 8397 Frame 0 slot 29 port 13 ( telno 4608397 mgid 0 terminalid A8397 ) under testing, Please wait......UA5000(config-test)# Testing port: 0/29/13 Telno : 4608397 MGid : 0 Terminalid : A8397 ---------------------------------------------------------- Test item Result ---------------------------------------------------------- Off-hook Failure: testing timeout Dial tone Normal Receiving pulse Failure: testing timeout Receiving DTMF Normal Ring back tone Normal Busy tone Normal Feeder Normal Polarity reversal Not supported On-hook Failure: testing timeout Ringing Normal Stop ringing Normal Ringing current voltage(V) Normal (76.520) Feeder voltage (V) Abnormal (17.414) Loop current (mA) Abnormal (3.833) ----------------------------------------------------------

Step 4 After the hardware of 14 port on A32 board was repaired or the A32 board was replaced with anormal board, the dialing service at the 14 port returned to the normal state, and the fault wasrectified.

----End


None

TC-A0199 Blocking of the V5 Link After the Active/Standby Switchover on aUA5000 Due to a Protocol Interoperability Problem

This case describes the troubleshooting of a V5 link that was blocked after the active/standbyswitchover on a UA5000 due to a protocol interoperability problem.

Fault Type

Narrowband service

Service abnormality



536

KeywordsThe V5 protocol

Software parameters

Fault DescriptionNetwork topology: UA5000 ->switch

The UA5000 was interconnected with the softswitch of another vendor. The active and standbyPVM boards were interconnected with the softswitch through two E1 cables. During the test onthe active/standby switchover function on site, it was found that the V5 links were in the blockedstate.



l After the active/standby switchover, the quality of the 2M link was faulty.l The clock settings were incorrect. As a result, the clock source could not be traced after

active/standby switchoverl The protocol interpretability between the softswitch and UA5000 was abnormal.

Procedure

Step 1 The display port state command was executed to query the 2M link status after the active/standby switchover was performed on the control boards of the UA5000. It was found that the2M status is normal, and the CRC4 check was enabled, which were consistent with the settingsof the softswitch.

Step 2 The display clock source command was executed to query the configuration status of the clocksource. The clock sources were configured on the first E1 link of the active and standby boards,the priorities of the clock sources are 0 and 1 respectively, and the clock output is enabled. Itindicated that the clock configuration was correct and the clock source was in the normal state.

Step 3 The display v5-software parameters command was executed to query the software parametersof the V5 interface. It was found that V5 software parameter 8 was set to 0 by default, whichindicated that auto-unblocking was not supported.

NOTE

The definition of automatic unblocking function: The block/unblock of the subscriber port and link adoptthe principle of "The blocker is also the unblocker". That is, if the softswitch blocks the subscriber port or2 M link, only the softswitch can unblock it. If an access device sends the unblocking request, the softswitchwill reject the request. This process, however, may vary with different softswitches. The access networkdevice supports flexible processing. To allow the softswitches of other vendors not to stick to this process,V5 software parameter 8 must be set to 1.

Step 4 The v5-software parameters modify 8 1 command was executed to modify V5 softwareparameter. After that, the problem was solved.

----End



537

Suggestions and SummaryWhen the access device is interconnected with the softswitches of other vendors through the V5interface, note that the settings of the V5 interface software must correct.

TC-A0200 Communication Failure Between the UA5000 and the NMS Server Dueto the Lack of Network Management Route

This case describes the troubleshooting of the communication failure between the UA5000 andthe network management system (NMS) server because the network management route was notadded.

Fault TypeOther


KeywordRoute configuration

NMS management

Fault DescriptionNetwork topology: UA5000 (PVMD) -> router (S8505) –> NMS server

The PVMD board was connected to the NMS through the ETH port in the outband networkmanagement mode. The IP address of the NMS server and that of the PVMD were not in thesame subnet. After the outband network management IP address of the PVMD was configured,the PVMD failed to ping the NMS server.



l The route on the bearer network was unreachable.l The routing entry on the S8505 was incorrect.l The network management route was not configured on the PVMD board.

Procedure

Step 1 The PVMD board could normally ping its own gateway and the gateway could ping the NMSserver too. Therefore the gateway from the PVMB board to the gateway was normal. The linkfrom the NMS server to the gateway was normal. Therefore, the bearer network was normal.

Step 2 It was suspected that the gateway of PVMD and the routing entry of S8505 may not be updated.After the routing entry was updated, the fault persisted.



538

Step 3 It was found that the PVMD board was a newly manufactured board. Therefore, a route mustbe added for outband network management.huawei(diagnose)%%outband { route<K> }:route { add<K>|delete<K> }:add { ip_address<X.X.X.X> }:10.144.5.6 /* The IP address of the NMS server.*/ { submask<M><X.X.X.X> }:255.255.255.0

After the network management route was added, the communication between the PVMD boardand the NMS server was restored.

----End


None

TC-A0201 Failure of UA5000 to Register by Using the Domain Name Due to theLack of MIDType Configuration

This case describes the troubleshooting of a UA5000 that failed to register with the Softswitchby using the domain name because the MIDType was not configured.

Fault Type

Narrowband service


Keywords

Midtype

Domain name

Fault Description

The UA5000 failed to register with the softswitch by using the domain name.

Alarm Information

None

Cause Analysis


l The domain name was configured incorrectly.

l The UA5000 MG interface was not reset.

l The data configuration of the softswitch was incorrect.



539

ProcedureStep 1 The domain name of the UA5000 was checked. It was found that the domain name was

configured correctly and the MG interface had been reset. However, the fault persisted.

Step 2 The interconnection parameters on the softswitch and the UA5000 were checked. It was foundthat the interconnection parameters were consistent on both sides.

Step 3 The display if-h248 attribute command was executed to check parameter domain name of theUA5000. It was found that the value of the MIDType was IP4_ADDR.

NOTE

MIDType was an information identifier. It was displayed in the message header to identify the messagesender. The default parameter ip4Address was used to configure the MID type of H.248 messages of aspecified MG interface.

Step 4 The if-h248 attribute command was executed to change the message identifier (MID) type ofH.248 messages to domainName, and thus the UA5000 can register by using the domain name.The specific configurations were as follows:huawei(config-if-h248-1)#if-h248 attribute miDType{ MIDTypeVal<E><ip4Address,domainName,deviceName> }:domainName

Step 5 After the MID of H.248 messages was modified, the MG interface was reset. As a result, theUA5000 could register normally by using the domain name, and the problem was solved.

----End

Suggestions and SummaryAs for H.248 messages, the MID type is not mandatory under the H.248 protocol. By default,the UA5000 registers with MGC by using the IP address+port number. When registering theUA5000 by using a domain name, the interface attributes must be configured.

TC-A0202 Call Failure in R2 Tests Due to the Failure of the UA5000 to Identify theMFD

This case describes the troubleshooting of a call failure in R2 tests because the UA5000 did notidentify the MFD.


Service abnormality

KeywordsPBX

Not Implemented

Fault DescriptionFigure 16-5

shows the network on which the call fails in R2 tests because the UA5000 does not identify theMFD.



540

Figure 16-5 Network on which the call fails in R2 tests because the UA5000 does not identifythe MFD

Phone A

UA5000

MGC

PBX

Phone B

Phone C

Fault symptom: In the preceding network topology, the PBX was provided by Siemens and theUA5000 and the MGC were provided by Huawei. After the configuration, call tests wereperformed. It was found that phone C connected to the UA5000 could call phone A and phoneB, whereas phone A and phone B failed to call phone C.

Alarm Information

None

Cause Analysis


l The PBX was not configured correctly.l The MGC was not configured correctly.l The UA5000 was not configured correctly.l The line is faulty.

Procedure

Step 1 Phone A failed to call under the PBX. So, the packet capture tool was used to capture the dialingpackets. when the PBX called the UA5000, the softswitch sent the following information:

¡¡ã[10.3.131.20]:2944 T=406326979{C=-{MF=A62{E=402660939{mfd/*,bcas/cf,bcas/casf,r2/r2f}}}}!/1¡¡À then MSAN (10.3.131.100) sends:¡¡ã[10.3.131.100]:2944 P=406326979{C=-{MF=A62{ER=501{"Not Implemented"}}}}!/1

During packets checking, it was found that the UA5000 failed to parse "MFD/*"sent by theMGC. As a result, the UA5000 returned to the “Not Implemented" message.

Step 2 It was confirmed by the softswitch maintenance personnel that the MFD/*" cannot be deleted.



541

Step 3 The fault may be removed by modifying the UA5000 configurations. The UA5000 supportedthe R2 function. The following commands were used to modify the configuration of the UA5000so that the "MFD/*" was ignored and a call could be made.huawei(config)#diagnosehuawei(diagnose)%%profile modify 1 item-index item-index12 1huawei(config)#interface h248 0huawei(config-if-h248-0)#if-h248 attribute profile-index 1huawei(config-if-h248-0)#reset coldstartAre you sure to reset MG interface?(y/n)[n]:y

Step 4 After the configuration of the UA5000 was modified, the phones could call each other. That is,the fault was rectified.

----End


None

TC-A0203 Fax Abnormality of a User Connected to the UA5000 Due to a SignalingProblem of the Softswitch

The case describes the troubleshooting of fax abnormality of a user connected to the UA5000due to a signaling problem of the softswitch.

Fault Type

Narrowband service

Service abnormality

Keywords

FoIP test in T.38 mode

T.38 m line description

Fault Description

Network topology: UA5000 -> softswitch

Fault symptom: The fax to the UA5000 was abnormal due to improper signaling of thesoftswitch.

Alarm Information

None

Cause Analysis


l The quality of the bearer network was poor.l The signaling was not properly processed.



542

ProcedureStep 1 The UA5000 was logged in and the alarm history was checked. It was found that no QoS alarm

was generated, and the delay of pinging the signaling IP address was short. Therefore, the qualityof the bearer network was good.

Step 2 Certain signaling abnormality was found during the signaling tracing.T=442689773{C=39{MF=A26{M{TS{BF=OFF,fax/faxstate=Negotiating},O{MO=SR,tdmc/ec=Off}},E=442921055{fax/faxconnchange,al/on,al/fl}},MF=A100000842{M{ST=1{O{MO=SR,RV=OFF,RG=OFF,nt/jit=40,tdmc/ec=On},R{v=0o=HuaweiSoftX3000 21167519 21167520 IN IP4 10.26.100.13s=Sip Callc=IN IP4 10.26.100.69t=0 0m=image 5496 udptl t38 //The first description.a=T38MaxBitRate:14400a=T38FaxRateManagement:transferredTCFa=T38FaxUdpEC:t38UDPRedundancym=audio 0 RTP/AVP 8 0 //The second description. One session contains only one "m=" line.a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=ptime:20a=silenceSupp:off - - - -a=ecan:fb on -a=faxa=inactive}},TS{BF=OFF,ctyp/calltyp=Fax,ipfax/faxstate=Negotiating}}}}}

!/2 [10.27.214.5]:2944 ER=400{"Syntax error in message"} //The UA5000 returns a syntax error and the fax is terminated.

In the signaling, "m=image 5496 udptl t38 " indicated that the T.38 fax mode was adopted. The"m=audio 0 RTP/AVP 8 0" description was unnecessary. As a result, the UA5000 failed to parsethe message and thus returned "m=audio 0 RTP/AVP 8 0" message.

Step 3 After the signaling "m=audio 0 RTP/AVP 8 0" was deleted from the softswitch, the problemwas solved.

----End

Suggestions and SummaryAs defined in the H.248 Protocol, the stream descriptor is a single bi-directional media stream.Therefore, the description of a session contains only one media description, that is, only one"m=" line. A stream descriptor, however, can contain multiple session descriptions for variouschoices. Each media stream on a termination must be described in an independent streamdescriptor. Multiple session descriptions contained in a descriptor should be separated by the"v=" line. Otherwise, the "v=" line serves as an option.

TC-A0204 Absence of Dial Tone on Certain Users Due to Unsecured Connectionof the Board

This case describes the troubleshooting of the absence of the dial tone on certain users of aUA5000 because the board was not inserted properly.


Board failure



543

KeywordsBackplane

Secure insertion of the board

Fault DescriptionNo dialing tone was displayed on many ports on the distribution frame.



l The service boards were faulty.l The slots were faulty.l The backplane or the network cable was faulty.l The board was not inserted securely.

Procedure

Step 1 The query result showed that most of the ports on the board had no power. The board may befaulty. The boards were replaced. The fault, however, persisted and the ports that had no powerwere not the original ones.

Step 2 Each time after the board was replaced, it was found that certain ports were normal. However,the ports that were faulty changed without rules.

Step 3 The board was inserted in another slot and it was found that the board was normal.

Step 4 The backplane and cable were checked and found to be normal.

Step 5 It was found that the board in the faulty slot seems to be 2 mm longer than other boards. Thisboard was pushed into the slot securely. The faulty board was tested again. It was found that thefault recovered and the dialing tone was normal. The fault was rectified.

----End

Suggestions and SummarySome serious faults may be caused by mistakes in detail, and therefore, great care must be takenin troubleshooting.

TC-A0208 114 Call Disconnection on Voice Users of a UA5000 Due to a Third-PartyVoice Switch Problem

This case describes the troubleshooting of the disconnection of the 114 call, a phone numberquery hotline service provided in China, on voice users of a UA5000 due to a third-party voiceswitch problem.



544

Fault Type

Narrowband service


Keyword

Communication interruption

114

Fault Description

Network topology: Shenou switch -> UA5000 -> SX3000

NOTEThe UA5000 was interconnected with Shenou voice switch in the upstream direction, and was connected to theShenou voice switch in the downstream. The end users were connected by the third-party voice switch.

Fault symptom: As reported by the telecom maintenance personnel, when the voice subscriberof the UA5000 called 114, the call was connected normally. During the conversation (for lessthan 4s each time) after the call was connected, however, the call was interrupted automatically.

Alarm Information

None

Cause Analysis


l The data configuration of the softswitch was incorrect.l The phone set was faulty.l Other causes.

Procedure

Step 1 The conversation was interrupted abnormally when the subscriber dialed 114. The analysis ofsignaling tracing showed that the UA5000 reported the onhook message to the softswitch. Thisindicated that the fault was caused by the UA5000 and the softswitch was normal.

Step 2 Actually, the telephone did not hang up when the UA5000 reported the onhook message to thesoftswitch. It was suspected that the communication interruption was caused by the telephoneabnormality. The telephone was replaced at the faulty port, but the fault persisted. Therefore,the telephone was normal.

Step 3 It was found that the fault occurred after the third-party voice switch was added to the UA5000.Therefore, the line that connected to the third-party switch was disconnected on the MDF sideand the line was directly connected to the user phone. A dialup test was performed and it wasfound that the service was normal. Therefore, it was concluded that the fault was caused by thethird-party voice switch. After the switch was changed, the services were restored.

----End



545


TC-A0210 Severe Voice Packet Loss Under Two UA5000s Due to the ForwardingDefects in EPON Device

This case describes the troubleshooting of a severe voice packet loss on a UA5000 that wasconnected to an EPON device. The fault occurred due to the forwarding defects in the EPONdevice.


Service abnormality

KeywordsVoice fault

Services forwarding

Fault DescriptionNetwork topology: UA5000 (PVM)-> the EPON (F820)-> OLT-> switch (S7806)-> router(NE40)

Packets loss occurred when the gateway was pinged from the two UA5000 in a certain office.The packet loss rate reached 60%, resulting in poor voice quality. The voice service of otheroffices under the OLT was normal. The independent upstream mode was adopted on the UA5000and the network cable was connected to the FE port of the F820.



l The running environment (temperature, humidity) of the UA5000 was adverse.l The negotiation mode of the UA5000 and F820 port were inconsistent.l The upstream of the UA5000 was configured insufficiently.l The network cable connected to the F820 was faulty.l The EPON was configured incorrectly.

Procedure

Step 1 The site environment was checked. It was found that the environment, temperature, humidity,and power were abnormal. Therefore, the problem of the environment was excluded.

Step 2 The upward bandwidth of the UA5000 was configured correctly.



546

Step 3 The port configuration mode of the UA5000 was consistent with that of the F820, but the faultpersisted.

Step 4 After the network checking and the Ping packets changing, the loss of packets was still serious.

Step 5 After the on-site packets capturing and voice signaling analysis, it was found that the callerservice on the UA5000 was normal. It indicated that no packet loss occurred when the UA5000processed the data packets.

Step 6 Therefore the fault was caused by the EPON forwarding. The service returned to normal afterthe EPON data was reconfigured.

----End

Suggestions and SummaryServices on the devices connected to EPON devices are often unstable. During thetroubleshooting of such unstable services, the efficiency is sometimes very low with normaltroubleshooting methods. If it is confirmed that the devices are free from problems, performoperations on the EPON devices, including reconfiguring the service data and changing theservice VLAN and IP address.

TC-A0211 Services Abnormality After Power Restoration Due to the Mismatch ofthe PVMB Version and the VRSP Version

This case describes the troubleshooting of the service abnormality after a power restoration dueto the mismatch of the PVMB version and the VRSP version.


Service abnormality

KeywordsPower failure

Restart

Fault DescriptionCertain offices were remote. The services were usually normal, but sometimes power-off lastedtwo or three days. As a result, the storage battery on the UA5000 was exhausted and device waspowered off. After the equipment room was powered on, the UA5000 failed to start normallyand the services were interrupted. However, the broadband MA5300 in the same room startednormally and the services were normal.





547


l The version of the board was faulty.

l The communication between the PVM VRSP and the switch or the OLT failed, causingthe system reset.

Procedure

Step 1 After login to the device through the serial port, it was found that the device automaticallyrestarted after running for several minutes. After restart, the display version command wasexecuted to query the version documents, the system displayed the following information:huawei(config)#display version --------------------------------------- Pcb Version: VER.C Base Bios Version: 336 Extend Bios Version: 336 Software Version: PVMVRSP6140 CPLD Version: 198 Logic Version: 300 NOD Version: 100 Encrypt Nios Version: 100

Step 2 The version description documents were queried. It was found that the documents after upgradewas:huawei(config)#display version --------------------------------------- Pcb Version: VER.C Base Bios Version: 336 Extend Bios Version: 336 Software Version: PVMVRSP6140 CPLD Version: 198 Logic Version: 304 NOD Version: 10a Encrypt Nios Version: 101

Step 3 After comparing with the version description documents, it was found that the Logic document,NOD document and Encrypt Nios were normally loaded. The cause may be that only the programdocument was loaded during deployment. The communication was normal after the loading wascompleted, but the Logic document and Encrypt Nios were not loaded according to the versionconfiguration table. As a result, the device failed to reset after power failure due to versionmismatch.

Step 4 The document was re-loaded according to the version configuration table. After a power-off test,it was found that the device could restart normally. The fault was removed.

----End


The version configuration table must be strictly observed to re-load the software in thedeployment.

TC-A0212 Voice Service Disconnection on a UA5000 Due to L2 Isolation on theEPON Device

This case describes the troubleshooting of the voice service disconnection on a UA5000 due toL2 isolation on the EPON device.



548


Service abnormality

KeywordsMA5680T

Gateway delivery

Fault DescriptionNetwork topology: The voice service was disconnected due to EPON L2 isolation, as shown inFigure 16-6.

Figure 16-6 Network topology: the voice service disconnection due to EPON L2 isolation

UA5000 A

MA5680T

Soft3000

UA5000 B

Fault symptom: The UA5000 could normally call the other numbers except the numbersconnected to the MA5680T, but phone call between two UA5000s failed.



l The MA5680T was configured incorrectly.l The ARP learning under the UA5000 was disabled.

Procedure

Step 1 The H248 signaling was analyzed, and it was found that the media stream was single. TheUA5000 at two ends failed to ping through each other.

Step 2 On the MA5680T, the L2 forwarding status was checked.



549

MA5680T(config)#display epon vlan-isolate

It was found that the EPON L2 isolation was disabled.

Step 3 After L2 isolation function was enabled on the MA5680T, the two UA5000s can ping each other.Run the following command to query the above information:MA5680T(config)#epon vlan-isolate enable

----End


TC-A0213 Fault on a Newly Added Shelf Due to Incorrect HW Cable TypeThis case describes the troubleshooting of the fault on a newly added shelf because the type ofthe in-use HW cable was incorrect.

Fault TypeOther

Other

KeywordsRSP fault

HW cabling

PV8

Fault DescriptionAll the boards on the newly added RSP shelf under the PV8 shelf were faulty.



l The data configuration was incorrect.l The HW cable was connected incorrectly.l The DIP switch of the RSP control board was configured incorrectly.l The service board was faulty.l The backplane was faulty.

Procedure

Step 1 The data configurations were correct.



550

Step 2 The HW cable was connected in a right place after checking on site. The HW cable was removedand then installed back. However, the fault persisted.

Step 3 The second bit of the RSP control board SG1 was on, and then the RSP board was reset. It wasfound that the fault persisted.

Step 4 The RSP was normal before the active and standby RSP boards were configured. Therefore, thefault was not caused by the control board and the backplane.

Step 5 It was confirmed by the field engineer that only the HW cable was newly configured. The HWcable was suspected to be faulty. After checking, it was found that the cable configuration typeof the H301PV8 control board was improper (BOM code: 04027873, used for H302PV8 board)

Step 6 After the HW cable (material code: 04024260, used for H301PV8 board) was replaced, the faultwas removed.

----End

Suggestions and SummaryPay attention to the selecting of cable types because the RSP shelf was connected to the controlboard H301PV8.l The HW cable used for H302PV8 board is 04027873 (BOM). BOM description: single

Cable of -02PV8 differential HW Cable.l The HW cable used for H301PV8 board is 04024260 (BOM). BOM description: single

Cable of -PV8-RSP booting differential cable.

TC-A0217 Static on the Line Due to a High-Frequency Interference SourceThis case describes the troubleshooting of the static on the line due to a high-frequencyinterference source.


Service abnormality

KeywordPoor voice quality

Fault DescriptionThe Internet access service of an ADSL user was normal but serious static occurred on the linewhen the user was in a conversation.


Cause AnalysisAccording to the fault symptom, the possible causes were as follows:



551

l The splitter was faulty.l The phone was faulty.l A high-frequency interference source existed around the line.

Procedure

Step 1 The splitter was replaced. The fault, however, persisted.


Step 3 A phone was connected to the main distribution frame (MDF) of the device. The static stillexisted. This indicated that the line from the MDF to the home of the user was normal.

Step 4 The ambient environment of the UA5000 was checked. It was found that a power supply cabinetexisted near the UA5000. It was hypothesized that the strong interference caused the static onthe line.

Step 5 A phone was directly connected to the board of the UA5000. It was found that the staticdisappeared. Therefore, it was determined that the interference of the power supply cabinetcaused the static on the line.

Step 6 The subscriber cables were moved to a position far from the power supply cabinet. Then, thestatic disappeared.

----End

Suggestions and SummaryInterference causes unstable line signals or signal distortion. Therefore, make sure that signalcables are separate from power supply cables in cable routing, thus preventing the interference.

TC-B4028 Static on the ADSL Line Due to Incorrect Wire Bonding of the MDFThis case describes the troubleshooting of the static on the ADSL line due to incorrect wirebonding of the main distribution frame (MDF).


Service abnormality

KeywordPoor voice quality

Fault DescriptionThe static occurred when a user was in a conversation. That is, when the user was not surfingon the Internet, the voice service was normal. When the user was in a conversation while surfingon the Internet, the static occurred on the line.




552

Cause AnalysisAccording to the fault symptom, the possible causes were as follows:l The splitter was faulty.l The phone was faulty.l The line was faulty.

Procedure

Step 1 The splitter was replaced. The fault, however, persisted. This indicated that the splitter wasnormal.


Step 3 The connection of the drop cable was checked. It was found that the cable was connectedproperly.

Step 4 A wiring bonding test was performed on the vertical MDF. The fault, however, persisted.

Step 5 A wiring bonding test was performed on the ADSL horizontal terminal board. It was found thatthe Internet can be accessed but no call can be made. This indicated that low-frequency voicesignals were not transmitted. Then, it was determined that the wiring bonding was faulty.

Step 6 The wiring of the ADSL horizontal terminal board was checked. It was found that the jumperbetween the vertical MDF and the horizontal MDF of the original switch was not removed.

Step 7 The wires were connected properly. That is, the fault was rectified.

----End

Suggestions and SummaryIf the static exists on the line, interference signals must exist in voice signals. In this case,eliminate the interference signals.

TC-A0225 Faulty V5 Interface on the Switch Due to a Loopback on the 2M LinkThis case describes the troubleshooting of a faulty V5 interface on the switch due to a loopbackon the 2M link.



KeywordV5 service abnormality

Fault DescriptionThe UA5000 (PVM) was connected to a transmission device and then was connected to a switchthrough the V5 interface. The V5 interface on the UA5000 was displayed as normal but the V5interface on the switch was displayed as faulty.



553

Alarm Information

None

Cause Analysis

According to the fault symptom, the possible causes were as follows:l The data configuration of the switch or the UA5000 was incorrect.l The transmission device was faulty.

Procedure

Step 1 The V5 interface on the UA5000 was checked. It was found that the V5 interface worked in thenormal state. This indicated that the 2M link was reachable. Therefore, it was concluded thatthe data configuration of the V5 interface on the UA5000 was correct.

Step 2 The data of the switch and the access network was checked. It was found that the negotiationdata on the switch was consistent with the negotiation data on the access network. Thenegotiation data includes V5ID, LINK ID, V5 version, logical C channel, and CRC. Thisindicated that the data configuration of the switch was correct.

Step 3 The transmission device was checked. It was found that a 2M loopback was configured for theUA5000. The loopback was canceled, the V5 interface on the switch became normal.

----End


None

TC-A0247 One-Way Audio on Pay Phone Due to A32 Board Port Not SupportingPolarity Reversal

This case describes how to troubleshoot the one-way audio on the pay phone because the A32board port does not support polarity reversal.

Fault Type

Narrowband service

Service abnormality

Keywords

CC-HASL

Fault Description

l During the interconnection test for the UA5000 and Iskratel SI2000, it is found that one-way audio occurs when a pay phone is connected to the A32 board of the UA5000. In thiscase, the pay phone user can hear the voice of the peer party but the peer party cannot hearthe voice of the pay phone user. In addition, the call charge on the pay phone is not deducted.



554

l The services operate normally when common phones are connected to these A32 boardports. In addition, if the A32 board is connected to the C&C08 switch, the pay phoneconnected to the board will not encounter this fault.

l The type of the A32 board is CC-HASL (03039717).l The type of the pay phone is TMS-1517K4.


Cause AnalysisThe possible causes are as follows:l The pay phone is faulty.l Certain ports on the A32 board do not support polarity reversal.

Procedure

Step 1 Replace the pay phone to test the service. It is found that the fault persists. In addition, giventhat the service is normal when the pay phone is connected to the C&C08 switch, it can bedetermined that the fault is not caused by pay phone problems.

Step 2 Further analyze the pay phone connection conditions. It is found that the pay phonecommunicating with the service board of C&C08 switch is connected to port 15; whereas thetested port on the UA5000 is always port 8. Connect the pay phone to port 15, given that onlyports 15 and 16 on the A32 board support polarity reversal.

Step 3 Run the pstnport attribute batset and pstnport reversepole_pulse batset commands toconfigure the polarity reversal function on the port. Then, perform the test again. It is found thatthe pay phone works normally. The specific configuration commands are as follows:huawei(config)#pstnport attribute batset 0/20/15 0/20/16 polarity-reverse Supporthuawei(config)#pstnport reversepole_pulse batset 0/20/15 0/20/16 300 enable

----End

Suggestions and SummaryCertain pay phone can work normally only when being connected to a port that supports polarityreversal. When a fault occurs in the pay phone service, check whether the connected A32 boardport supports polarity reversal.

TC-A0248 IUA Link Activation Failure Due to Incorrect Configuration of IUA LinkWork Mode

This case describes how to troubleshoot the failure to activate the IUA link because the IUAlink work mode is configured incorrectly.


Service abnormality



555

Keywords

Load sharing

ISDN

Fault Description

A UA5000 uses the H.248 protocol. After the IUA link set and associated IUA link data isconfigured, the IUA link cannot be activated and the ISDN service cannot be provided.

Alarm Information


Cause Analysis


l The network between the UA5000 and the softswitch is faulty and therefore the two partiescannot send messages to each other.

l The basic IUA interconnection parameters set on the UA5000 and the softswitch areinconsistent.

l The settings of the IUA running parameters on the UA5000 are incorrect.

Procedure

Step 1 Ping the UA5000 and softswitch from each other. It is found that the two devices cancommunicate with each other normally without packet loss, and that the common voice serviceoperates normally. This indicates that the network between the two devices is normal.

Step 2 Check for the softswitch IP address, local IP address, softswitch IUA port ID, and local port IDmultiple times. It is found that the settings of interconnection parameters are correct.

Step 3 Run the display iua-linkset attribute command in sigtran mode to query the basic informationabout the IUA link. It is found that the IUA link set works in the override (active/standby) mode.Comparably, the IUA links on a normal UA5000 (V100R013) connected to the same softswitchwork in the load sharing mode.

Step 4 Run the iua-linkset add command to change the work mode of the IUA link set to load sharing.It is found that the IUA link can be activated successfully.

----End


The default work mode of the IUA link set on the UA5000 PVM V100R013 is load sharing;whereas the default mode on the UA5000 PVM V100R017 is override. In practice, the workmode of the IUA link set needs to be correctly set according to the application requirements.



556

TC-A0249 Error 676 in Modem Dialup Service Through UA5000 Due to Non-Standard Signaling Sent by Softswitch

This case describes how to troubleshoot error 676 that is displayed in the narrowband modemdialup service provided through the UA5000. The fault is caused by non-standard signaling sentby the softswitch.


Service abnormality

KeywordsInternet access through dialup

Fault DescriptionNetwork topology: UA5000 (PVMV100R013C03B032) -> softswitch -> BRAS

Fault symptom: In the narrowband modem dialup service through an UA5000, error 676 isdisplayed during dialup.


Cause AnalysisThe possible causes are as follows:l The user terminal is faulty.l The number of IP addresses in the IP address pool of the BRAS is insufficient.l The UA5000 interconnects with the softswitch incorrectly.

Procedure

Step 1 Perform the dialup test on other access devices connected to the same softswitch. It is found thatall the tests are successfully, indicating that the fault is not caused by user terminal problems.

Step 2 Given that only one account is used for test, it can be determined that the fault is not caused bythe insufficiency of the IP addresses in the IP address pool of the BRAS.

Step 3 Capture mirrored packets. The captured signaling is as follows:IER=.#@#!/2 [10.35.64.3]:2944 T=2441211895{C=${A=USER134,A=${M{ST=1{O{MO=RC,nt/jit=0,diffserv/dscp=1},L{.v=0.c=IN IP4 $.m=audio $ RTP/AVP 8.a=ptime:10.a=X-ChannelAttr:1.}}},E=2441764301{nt/netfail,nt/qualert{th=80}}}}}

Step 4 It is found that the softswitch issues two non-standard identifiers, namely diffserv/dscp=1 anda=X-ChannelAttr:1, and that the UA5000 responds to the softswitch with a "Unsupported orunknown Package" message. Remove the two identifiers from the softswitch. It is found thatthe dialup for Internet access through the UA5000 is successful.

----End



557

Suggestions and SummaryWhen such a fault occurs, capturing signaling is a good way to improve the fault locationefficiency.

TC-A0251 No Ringing Tone for Some Subscribers Due to Faulty A32 BoardThis case describes how to troubleshoot the absence of ringing tones for some subscribers dueto a faulty A32 service board in the UA5000 to which these subscribers are connected.


Narrowband service


Fault DescriptionNetwork topology: UA5000 -> router -> SoftX3000

Fault symptom: Some subscribers connected to the UA5000 can make calls successfully buttheir phones do not ring when they are being called. If these phones are called, however, andthe subscribers answer the phone, they can communicate with the calling parties withoutproblems.


Cause Analysisl The PWX board is faulty.l The ringing current relay on the backplane is faulty.l One of the A32 boards is faulty.

Procedure

Step 1 Check the PWX board and system alarms. It is found that the status indicators on the board arerunning properly and that no PWX board alarm is generated in the system, indicating that thePWX board is functional.

Step 2 Replace the subrack and the backplane. It is found that the fault persists, indicating that the faultis not caused by the ringing current relay on the original backplane.

Step 3 Use the minimum configuration method to identify the fault cause. That is, remove the A32boards in the subrack one by one and perform circuit and subscriber line tests on the remainingA32 boards each time. It is found that the ringing voltage is normal after the A32 board in slot8 is removed. Replace the A32 board in slot 8. It is found that the fault is rectified.

----End



558

Suggestion and SummaryWhen a service failure occurs on the UA5000, you can use the device's circuit and subscriberline test functions and the minimum configuration method to locate the fault quickly. Theminimum configuration method may affect the services on the live network and should only beused when network traffic is light.

NOTE

The minimum configuration method involves removing the service boards one by one, performing testson the remaining boards each time, and then re-inserting the board into the slot to determine which boardcauses the fault.

TC-A0254 H.248 Interface Failure Due to Conflict Between Outband NetworkManagement and Signaling IP Addresses

This case describes how to troubleshoot a failure of the H.248 interface on a UA5000, which iscaused by a conflict between the UA5000's outband management and signaling IP addresses.


Narrowband service

KeywordsMaintenance network port

MG interface IP address

Fault DescriptionNetwork topology: UA5000 -> bearer network -> softswitch

The affected UA5000 is configured with two H601PVMD control boards (active and standby)and communicates with the network management system (NMS) in outband mode. Whennetwork cables are connected to the uplink network ports and outband network ports on boththe PVMD control boards, the H.248 interface on the UA5000 fails.

When a user disconnects the network cables from the four ports on the two PVMD control boardsand inserts a network cable into the uplink network port on one PVMD control board, the H.248interface recovers. Then, the user inserts the remaining three network cables into thecorresponding ports. It is found that the outband network ports and uplink network ports on thetwo control boards are working properly. If the user resets the UA5000, however, the H.248interface fails again. After performing the preceding operations again, the H.248 interfacerecovers.


Cause Analysisl The upstream link is faulty.



559

l The hardware of the control boards is faulty.l The data configuration on the UA5000 is incorrect.

Procedure

Step 1 Run the display uplink tps state command to query the operating status of the service networkports on the two control boards. It is found that the service network ports on both the active andstandby control boards are enabled to transmit data upstream.

Step 2 Replace the network cables connected to the service network ports. It is found that the faultpersists.

Step 3 Run the system switch-over command to perform an active/standby switchover. It is found thatthe fault persists.

Step 4 Analyze the data configuration on the UA5000. The UA5000 uses two service network portsand two outband network management ports for data transmission and NMS communication.The IP addresses of the outband network management ports are in the same network segmentas the signaling IP address of the H.248 interface. Because of this, the H.248 messages are sentto the outband network management ports instead of being sent to the service network ports. Asa result, the H.248 interface cannot negotiate parameters with the media gateway (MG) interface.

Step 5 Run the undo ip address command to delete the IP addresses of the outband networkmanagement ports, run the sysman mode inband command to change the network managementmode of the UA5000 to inband mode, and then run the ip address command to configure an IPaddress for the inband network management port. It is found that the fault is rectified.

----End

Suggestion and SummaryWhen a UA5000 uses two service network ports and two outband network management portsfor data transmission and NMS communication, the parameter negotiation between the H.248interface and the MG interface will fail if the IP address of the UA5000's outband network portsare in the same network segment as the signaling IP address of the H.248 interface. To preventthis problem, configure the preceding IP addresses in different network segments or use theinband network management mode.

TC-A0259 Busy Tones Occasionally Heard After Dialing Due to Incorrect RTPValue Range

This case describes how to troubleshoot the busy tones heard by the calling parties connectedto a UA5000 after dialing numbers. The fault is caused by the incorrect range of Real-TimeTransport Protocol (RTP) values set on the UA5000.


Narrowband service

KeywordsBusy tone after offhook



560

Temporary terminal

RTP terminal

Fault Description

The UA5000, which functions as an access gateway (AG), is connected to a softswitch on a site.The subscribers connected to the AG occasionally hear busy tones after dialing numbers, andtherefore the called parties cannot be connected to.

Alarm Information


Cause Analysis

The RTP resources allocated by the AG to the softswitch are not configured on the softswitch.In such a case, the softswitch sends a busy tone signal to the AG after the AG allocates the RTPresources to the softswitch.

Procedure

Step 1 Trace signals transmitted between the AG and the softswitch. It is found that when an exceptionoccurs in the call process, the softswitch has sent an Add command to the AG requiring the AGto add a context and a temporary terminal. Then, the AG adds an RTP terminal (temporaryterminal) ID A100000100. Given that the RTP terminal IDs configured on the softswitch rangefrom A10000000 to A100000099, the softswitch sends a busy tone to the AG in this case becauseit cannot identify RTP terminal ID A100000100.

Step 2 Run the display tid-format command to check the terminal prefixes and terminal ID (TID)profiles currently used by each type of terminals connected to the media gateway (MG) interface.It is found that the RTP terminal is using the TID profile whose index is 1.

Step 3 Run the display tid-template command to query the information about TID profile 1. It is foundthat the temporary terminal resource that can be allocated by the AG is R+100000001. Therefore,the temporary terminals that can be allocated by the AG range from A100000001 toA100000100, because the maximum RTP terminal ID configured in the system is 99. This meansthat the AG may allocate temporary terminal ID A100000100, which is, however, not supportedby the softswitch. That is, when the AG allocates temporary terminal ID A100000100, a servicefailure occurs.

Step 4 Run the tid-template add 32 command to add TID profile with index 32, and set RTP terminalresource to R+100000000.

Step 5 Shut down the MG interface, and then run the tid-format rtp template 32 command to configureTID profile 32 for RTP terminals so that the RTP terminal IDs on the AG range fromA100000000 to A100000099. It is found that the fault is rectified after the MG interface is reset.

----End


There are two types of terminals in an H.248 call process.



561

l Physical terminals, which are identified by terminal IDs in signal interaction. Each voiceservice port on a UA5000 is configured with a fixed terminal ID.

l Temporary terminals, namely RTP terminals, which are identified by RTP terminal IDsconfigured on the UA5000. When establishing a call, the system randomly selects an IDfrom the configured ID range and allocates it to an RTP terminal. After the call is complete,the system releases this terminal ID for subsequent calls.

TC-A0260 Ringing Tone Absence Due to Incorrect Connection of SubscriberCables to the Backplane

This case describes how to troubleshoot the ringing tone absence due to incorrect connection ofsubscriber cables to the backplane connecting to an A32 board.


Narrowband service

KeywordsA32 board

Header

Pin row

Fault DescriptionNetwork topology: UA5000 -> LAN switch -> SoftX3000

Fault symptom: New UA5000 subscribers can communicate as both the calling party and thecalled party, but no ringing tone is played for the called party.


Cause Analysisl The data configuration on the UA5000 is incorrect.l The A32 board is faulty.l The power board is faulty.l The subscriber line is short-circuited.l Some cables seated in the main distribution frame (MDF) are crossed.l The connection of subscriber cables to the backplane is incorrect.

Procedure

Step 1 Check whether the data configuration on the UA5000 is correct. It is found that the calling partyand the called party can communicate with each other and only several subscribers encounterthis fault. This indicates that the data configuration on the UA5000 is correct.



562

Step 2 Cut over the subscribers to the last 16 ports on the A32 board. It is found that the fault persists.Cut over the subscribers to another A32 board. It is found that the fault disappears.

Step 3 Replace the A32 board and then perform a test. It is found that the fault persists, indicating thatthe A32 board is normal.

Step 4 Check the power board. It is found that the power board is normal.

Step 5 Disconnect the subscriber line, connect the phone to the faulty port on the A32 board, and thenperform a test. It is found that the fault persists, indicating that the fault is not caused by thesubscriber line.

Step 6 Check whether cables are seated in the MDF correctly, for example, no cable is crossed. Thecables are seated correctly.

Step 7 Check the subscriber cables connected to the backplane connecting to the A32 board. It is foundthat the subscriber cables are incorrectly connected to the backplane. That is, the first 16-channelPOTS signals are not distributed on the first 16 rows (from row 1 to row 16) of pins on theheader. Connect the subscriber cables correctly and perform a test. It is found that the fault isrectified.

----End

Suggestions and Summaryl The first 16-channel POTS signals from the A32 board are distributed on the first 16 rows

of pins on the header.

l The last 16-channel POTS signals from the A32 board are distributed on the last 16 rows(from row 17 to row 32) of pins on the header.

TC-A0262 Abnormal Dial Tone Due to Incorrect E1 Cable Connection Between theRSU and the PVM and EDTB Boards

This case describes how to troubleshoot the abnormal dial tone due to incorrect E1 cableconnection between the RSU and the PVM and EDTB boards.

Fault Type

Service abnormality

Narrowband service

Keywords

Incorrect cable seating

Ring back tone absence

Fault Descriptionl The master subrack on the UA5000 is cascaded with seven RSU slave subracks. The PVMB

and EDTB boards on the UA5000 are connected to RSUs through E1 cables.

l Some users cannot hear the dial tone after cutover.



563

Alarm Information


Cause Analysisl The service board is faulty.


l E1 cables are incorrectly connected.

Procedure

Step 1 The fault occurs on an RSU subrack and the affected numbers are dispersed. Therefore, there isa low probability that a large number of boards are faulty at the same time. Replace serviceboards in the faulty RSU subrack and perform a test. It is found that the fault persists.

Step 2 Check the power board. It is found that the power board works properly and no power alarm isgenerated. Replace the power board and perform a test. It is found that the fault persists.

Step 3 Delete the E1 cable configuration on the faulty subrack and keep the cable configuration on onlyE1 port 0 on the control board in the RSU subrack. Then, perform a dialup test multiple times.It is found that the fault disappears.

Step 4 Configure E1 cables one by one for the RSU subrack and perform a dialup test. After an E1cable is tested normal, delete its configuration and then configure another E1 cable and performa dialup test. The test result shows that the fault is caused by the lines crossed due to incorrectE1 cable seating.

Step 5 Use a blocker to block the cables connected to the digital distribution frame (DDF) one by oneto locate the fault and then seat the cables based on the test result. The fault is rectified.

----End

Suggestions and Summaryl Seat cables according to the data plan during deployment.

l The engineer is recommended to use the blocker to check the line before the cutover toensure that the E1 cable connection is consistent with the data configuration.

l Do not block E1 port 0 on the control board in the RSU subrack when checking the deviceson the live network. Otherwise, the services on the entire subrack are interrupted.

TC-A0263 Ringing Tone Absence for the Called Party Due to Some Port Faults onthe CSRB Board

This case describes how to troubleshoot ringing tone absence for the called party due to someport faults on the CSRB board.

Fault Type

Service abnormality

Narrowband service



564

Keywords

Ringing tone absence for the called party

Fault Descriptionl The master subrack on the UA5000 is cascaded with seven RSU slave subracks and is

configured with CSRB and A32 boards. The PVMB and EDTB boards on the UA5000 areconnected to RSUs through E1 cables.

l When the numbers of some phones under the same CSRB board are dialed, no ringing toneis played, but the called parties can communicate with the calling party after taking thephone off the hook.

Alarm Information


Cause Analysisl The E1 cable connection between the RSU and the PVMB and EDTB boards is incorrect.l The power board is faulty.l The CSRB board is faulty.

Procedure

Step 1 Check the E1 cable connection between the RSU and the PVMB and EDTB boards. It is foundthat the connection is consistent with the data configuration, indicating that the connection iscorrect.

Step 2 Check the power board. It is found that the power board works properly and no power alarm isgenerated.

Step 3 Replace the power board and perform a test. It is found that the fault persists.

Step 4 Perform a circuit line test a port on the CSRB board. When the circuit line test is performed onthe faulty port, Ringing is Abnormal, indicating that the port is faulty. Replace the CSRB boardand dial the phone numbers. It is found that the ringing tone is played and the fault is rectified.

----End


Perform a circuit test to detect board hardware faults. In the case of no dial tone or abnormaldial tone on the port, perform a circuit or subscriber line test to accurately and rapidly locatefaults.

TC-A0265 Failure in Concurrent Ringing of Fixed-Line and PHS Phones Due to anUnsupported Parameter Issued by the Softswitch

This case describes how to troubleshoot the failures in concurrently playing ringing tones for afixed-line phone and a personal handyphone system (PHS) phone due to an unsupportedparameter issued by the softswitch.



565


Narrowband service

KeywordsConcurrent ringing of a fixed-line phone and PHS phone with the same number

No ringing tone

Fault DescriptionNetwork topology: fixed-line phone -> UA5000 -> softswitch

The UA5000 provides subscribers with a fixed-line and PHS phone concurrent ringing service.That is, the fixed-line phone and the PHS phone use the same number, and they ring at the sametime when this number is called. The subscribers complain that the fixed-line phone occasionallydoes not ring while the PHS phone rings sometimes.


Cause Analysisl The fixed-line phone or the PHS phone is faulty.l The service board is faulty.l The PWX board is faulty.l The softswitch is faulty.

Procedure

Step 1 Perform dialing tests on multiple in-service fixed-line phones and PHS phones. It is found thatthe fault persists.

Step 2 Move the affected user port to the service board in another slot. It is found that the fault persists,indicating that the original service board is normal.

Step 3 Check the fault reporting record. It is found that this fault did not occur on the subscribers usingother common call services, indicating that the PWX board is normal.

Step 4 Trace the H.248 signaling. It is found that the fault occurs because the access gateway (AG)responds to the softswitch with the "internal software failure in the MG" message after thesoftswitch issues a modify command.

Step 5 Analyze the H.248 signaling. It is found that the modify command issued by the softswitchcontains the "a=rtpmap:101 AMR/8000" code that is not supported by the AG. Then, thesoftswitch configuration is modified to ensure that it does not issue this code, and dialing testsare performed on the affected port multiple times. It is found that the fault is rectified.

NOTE

AMR/8000 is mobile codec.

----End



566


No suggestion or summary for this case.

TC-A0267 A Low Probability That the Called Party Is Connected Due to theInteroperation Problems Between the LE of Company B and the UA5000

This case describes how to troubleshoot a low probability that the called party is connected dueto the interoperation problems between the local exchange (LE) of company B and the UA5000.

Fault Type

Service abnormality

Narrowband service

Keywords

Pulse notification

The called party fails to be connected

Fault Description

The LE and the UA5000 are configured with V5 interfaces, The UA5000 users can make callsnormally as calling parties. When they are called parties:

l The call can be connected if the calling parties are fixed-line phone users.

l The call connections frequently fail if the calling parties are mobile phone users.

Alarm Information


Cause Analysisl The data configuration on the UA5000 is incorrect.

l The data configuration on the LE is incorrect.

l The interoperation between the UA5000 and the LE is abnormal.

Procedure

Step 1 Check the data configuration on the UA5000; for example, check whether the data configurationis consistent with that on the LE and whether access user data configuration is correct. It is foundthat the preceding configurations are correct.

Step 2 Perform a test on the UA5000 users and use the Tool box to trace data. As called parties, theUA5000 users fail to be connected after being connected once.

Step 3 Compare the signaling when the called parties are connected and the signaling when the calledparties fail to be connected.



567

l When the called parties are connected, the LE issues intermittent ringing signals four secondsafter the LE sends the initial ringing signal to the called parties and the UA5000 does notreport pulse notification.

l When the called parties fail to be connected, the LE releases the voice service channels if theUA5000 reports pulse notification after the LE sends the initial ringing signal to the calledparties.

Step 4 It is suspected that the LE releases the voice service channels because it fails to identity the pulsenotification signal reported by the UA5000. Run the oversea parameters command to setoverseas parameter 5 to 0 (indicates that no pulse notification signal is sent). Then, perform atest on the UA5000 users. It is found that the called parties can be connected successfully,indicating that the fault is rectified.

----End

Suggestions and SummaryNo suggestion or summary for this case.

16.2.5 Multicast ServiceThis topic provides the analysis of the case related to the multicast service.




Service exception

KeywordCLIP

Abnormal CLIP

Protective unit

Phenomenon DescriptionAbout 20 commercial subscribers of the AG report that abnormal CLIP occurs frequently (6 to8 out of 10 times).





568

l The telephone set is faulty.l An error occurs when the softswitch is processing the CLIP.l An error occurs when the bearer network transmits the phone number.l Processing operations is faulty inside the AG.l The link is faulty.l The ODF and the protective unit are faulty.

Procedure







----End



TC-A0261 Multicast Service Failure Due to Insufficient Bandwidth Allocated toUsers

This case describes how to troubleshoot the multicast service failure due to insufficientbandwidth allocated to users.

Fault Type

Service abnormality

Multicast service

Keywords

Order

Program bandwidth



569

Fault DescriptionAfter the multicast service in Internet Group Management Protocol (IGMP) proxy mode isconfigured on the UA5000, the video on demand (VoD) service is normal whereas the multicastservice fails.


Cause Analysisl The data configuration on the UA5000 is incorrect.l The bandwidth allocated to the user is insufficient.l The set top box (STB) or the terminal is faulty.

ProcedureStep 1 Check the multicast service configuration. It is found that the configuration is correct. The

bandwidth in the line profile bound to the user is 4 Mbit/s and the traffic is not restricted.

Step 2 The affected user terminal is connected to another device. It is found that the multicast serviceis normal indicating that the user terminal is normal.

Step 3 Run the debugging igmp, terminal monitor, and terminal debugging commands to debug themulticast service. It is found that the system reports the "Warning: the user fails to pass bandwidthCAC" message, indicating that the fault is caused by CAC bandwidth restriction.

Step 4 Run the igmp bandwidthCAC disable command to disable the call admission control (CAC)bandwidth management function. It is found that the multicast programs can be played, butblurry images are displayed. It is suspected that the bandwidth allocated to the user is insufficient.

Step 5 Modify the line profile bound to the user by increasing the bandwidth for the user, and run theigmp bandwidthCAC enable command to enable the CAC bandwidth management function.It is found that the fault is rectified.

----End

Suggestions and SummaryThe bandwidth management principles for the uplink port and user port are the same. That is,the total bandwidth for programs (the total bandwidth for programs indicates the configuredprogram bandwidth instead of the bandwidth obtained based on actual program traffic) isrestricted based on the proportion of bandwidth allocated to multicast programs on the uplinkport, total bandwidth for the port, and calculated bandwidth allocated to the multicast service.

l If the bandwidth allocated to the multicast service is greater than the total in-use bandwidth,the current programs are not affected. When a program is added, the system compares theprogram's bandwidth with the remaining bandwidth for the port. If the program's bandwidthis greater than the remaining bandwidth for the port, the program cannot be added.Otherwise, the program can be added.

l If the allocated bandwidth for the multicast service is smaller than the total in-usebandwidth, the system automatically accumulates the bandwidth configured for eachmulticast program based on program indexes in ascending order to preferentially ensurethe bandwidth for the program with smaller index and forces the program with greater index



570

to go offline until the in-use bandwidth for the multicast service on the uplink port or userport is equal to or greater than its allocated bandwidth.

TC-A0266 Unknown Multicast Service Failure Due to Enabled Unknown MulticastSuppression Function

This case describes how to troubleshoot the unknown multicast service failure due to enabledunknown multicast suppression function.

Fault Type

Service abnormality

Multicast service

Keywords

Traffic suppression

STB

Fault Description

The UA5000 on a site provides ADSL users with an unknown multicast service. The service isnot configured with any Group Management Protocol (IGMP) parameters so that the UA5000transparently transmits the multicast packets. It is found that the ADSL users fail to watchprograms using set top boxes (STBs).

Alarm Information


Cause Analysisl The link between the UA5000 and the video on demand (VoD) server is disconnected.

l The STB is faulty.

l The multicast service configuration on the UA5000 is incorrect.

Procedure

Step 1 Ping the VoD server from the UA5000. It is found that this operation is successful, indicatingthat the link between the UA5000 and the VoD server is normal.

Step 2 Replace the STB with the variable-length coding (VLC) player on the PC to order programs. itis found that the fault persists.

Step 3 Start the packet capturing tool on the PC. It is found that the STB has already sent an IGMPpacket for joining the multicast group, but this packet not found in the packets captured on theuplink port on the UA5000. Run the display traffic-suppress command to query the trafficsuppression configuration on the UA5000. It is found that the unknown multicast trafficsuppression function is enabled.



571

Step 4 Run the undo traffic-suppress multicast command to disable the unknown multicast trafficsuppression function. Programs can be ordered using the STB successfully, indicating that thefault is rectified.

----End


The unknown multicast traffic suppression function is enabled to prevent unknown multicastpacket storms on the Ethernet port on a UA5000, by setting the ratio of permitted unknownmulticast traffic on the Ethernet port to the total traffic on the Ethernet port.

16.2.6 QoSThis topic provides the analysis of the case related to the quality of service (QoS).

TC-A0255 Failure to Add a Traffic Entry Due to a Rate Level Absence in the RateTable

This case describes how to troubleshoot a failure to add a traffic entry on the UA5000 becausethere is no rate level corresponding to the traffic entry in the rate table on the device.

Fault Type

Other

QoS

Keywords

Traffic management

Traffic level

QoS

Fault Description

A user creates a traffic entry whose priority value is 4 and rate is 3072 kbit/s on the UA5000.After data configuration, however, the rate of the traffic entry is changed to 6000 kbit/s.

Alarm Information


Cause Analysis

There is no rate level corresponding to the traffic entry in the rate table.



572

Procedure

Step 1 Run the display rate table row command to query the traffic levels in the rate table. It is foundthat there is no rate level corresponding to rate 3072 kbit/s in the rate table, and therefore therate is changed to 6000 kbit/s.

Step 2 Create a traffic entry with a priority value of 4 and a rate of 3072 kbit/s.1. Run the modify rate table row 128 3072 command to change rate level 128 kbit/s to 3072

kbit/s.2. Run the traffic table command to create a traffic entry with a priority value of 4 and a rate

of 3072 kbit/s.3. Run the display traffic table command to query the traffic entry. It is found that the actual

traffic entry data is the same as the created data, indicating that the fault is rectified.

----End


When adding a traffic entry on the UA5000, ensure that the corresponding rate level is availablein the rate table. Otherwise, the rate level will be changed to a value that is in the rate table.

16.2.7 Other FaultsThis topic provides the analysis of the cases related to other features.

TC-A0018 Data Loss Occurs After the Power-Off of the UA5000 Because theduplicate Command Is Executed Improperly During the Deployment

This topic describes how to troubleshoot the fault when data loss occurs after the power-off ofthe UA5000 because the duplicate command is executed improperly during the deployment.

Fault Type

Other

Keyword

Duplicate


In an office, the UA5000 is powered off during the power adjustment. After the UA5000 ispowered on, it is found that the service data, such as the MG interface, is lost.

Alarm Information

None

Cause Analysis




573

l The data is not saved after the configuration.l Saving the database fails because the flash chip of the control board is damaged.l The control board is not reset after the database is loaded or duplicated.

ProcedureStep 1 Check the operation logs. It is found that the field engineer performs the save operation before

the UA5000 is powered off.

Step 2 Check the alarms. No alarm indicating that the hardware is faulty is found. Run the savecommand. If the command can be executed successfully and the system can be started normally,it indicates that the flash memory of the control board is in the normal state.

Step 3 Continue to analyze the alarms and operation logs of the UA5000.1. After the system is started on May 23, slot 5 is for the active control board and slot 4 is for

the standby control board. The field engineer begins to configure data. After a shelf is added,the field engineer saves the corresponding data.

2. Active/standby switchover occurs at 10:27:04 a.m. on 2008-05-23. Then, slot 4 is for theactive control board, and slot 5 is for the standby control board. Then, the field engineeradds the board data and saves the configurations to the flash memory at 10:31:09 on2008-05-23.

3. After performing the save operation, the field engineer configures such service data as theMG interface. During the process, the field engineer does not perform the save operation.At 11:19:17 on 2008-05-23, the field engineer runs the duplicate command, that is,duplicate the flash memory data on the active control board in slot 4 to the standby controlboard in slot 5. At 11:20:07 on 2008-05-23, the field engineer performs the save operation.

After running the duplicate command, the field engineer must reset the standby control board.The field engineer, however, does not reset the standby control board. As a result, only the dataon the active control board can be stored to the flash memory but the data on the standby boardcannot be stored to the flash memory when the save command is executed. Before the systemis powered off and restarted on June 21st, the flash memory data on the PVMB control board inslot 4 is inconsistent with the flash memory data on the PVMB control board in slot 5.

After the system is powered on and restarted, data loss occurs if the previous standby controlboard becomes the active control board. In other words, the data configured during the periodfrom 10:31:09 of 2008-05-23 to 11:19:17 of 2008-05-23 cannot be stored to the standby controlboard in slot 5. After the system was powered off and restarted on June 21st, the PVMB controlboard in slot 5 becomes the active control board. Before the restart, the data of slot 4 isinconsistent with the data of slot 5. Therefore, only the earlier shelf data and board data can berecovered from the flash memory after the PVMB control board in slot 5 becomes the activecontrol board. Other data is lost because such data is not stored to the flash memory before.

To sum up, the cause of this fault is that the standby control board is not reset and thus the flashmemory data on the active control board is inconsistent with the flash memory data on thestandby control board after the duplicate command is executed. After the system is restarted,the original standby control board becomes the active control board, thus data loss occurs.

----End

Suggestion and SummaryAfter you run the save command, the data of the active and standby control board is stored tothe flash memory. Therefore, it is recommended that you do not run the duplicate command to



574

duplicate data from the active board to the standby board. After running the duplicate commandto duplicate the database or running the load data command to load the database, you mustrestart the corresponding control board. Otherwise, the save command cannot be executednormally.

TC-A0048 The ID of the Slot Where the Board in the Slave Shelf Is Inserted IsDisplayed Incorrectly Because the Shelf Type Is Selected Incorrectly

This topic describes how to troubleshoot the fault when the ID of the slot where the board in theslave shelf is inserted is displayed incorrectly because the shelf type is selected incorrectly.

Fault Type

Other

Service exception

Keyword

Shelf type is incorrect

Board

Slot


During the deployment, one MD5500 is connected to the C&C08 upstream through the V5interface. After the MD5500 is configured with shelves and boards, enable the V5 interface. Itis found that the V5 interface works in the normal state and the subscribers on the master shelfcan make calls in the normal state. The IDs of the slave-shelf slots, however, are displayedincorrectly. Slot 8 is displayed as slot 6. The IDs of the slots behind slot 8 are increased by tworespectively. Therefore, the boards in slots 6 and 7 cannot be displayed.

Alarm Information

None

Cause Analysis


l The HW line or the transfer board that is connected to the salve shelf is faulty.l The control board is faulty.l The backplane is faulty.l The data is configured incorrectly.

Procedure

Step 1 Replace the HW line of the MD5500. It is found that the fault persists. This indicates that thefault is not caused by the HW line.



575

Step 2 Switch over the active and standby control boards. It is found that the fault persists. This indicatesthat the fault is not caused by the control board.

Step 3 The backplane cannot be replaced because no spare part is available for the backplane. Thedevice is newly delivered. Therefore, the backplane is rarely faulty. This indicates that the faultis not caused by the backplane.

Step 4 Check the data configuration. It is found that the shelf type is incorrect. In the deployment, themaster shelf of the MD5500 is the HABA shelf and the slave shelf of the MD5500 is the HABBshelf. Shelf type 5:SLAVE_HABS_30(HABA) is selected. Actually, shelf type4:SLAVE_HABS_32(HABB) should be selected. The HABA shelf provides 30 slots and theHABB shelf provides 32 slots. In this case, slot 6 and slot 7 cannot be displayed because theHABA shelf is two slots less than the HABB shelf. Change the shelf type. Then, the boards aredisplayed correctly and the fault is rectified.

----End

Suggestion and SummaryThe MD5500 is composed of the master shelf, slave shelf, and extended shelf. The three shelvesuse different backplanes. Therefore, make sure that the shelf types are selected correctly whenadding shelves. Otherwise, the fault occurs.

TC-A0055 Upstream Service Transmission Fails Because the Uplink Port Mode ofthe PVMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the upstream service transmission failsbecause the uplink port mode of the PVMD board is selected incorrectly.

Fault TypeOther


KeywordUplink port mode

ETH1

Fault DescriptionThe PVMD board of the UA5000 works in the independent mode for the upstream transmission,and the services are transmitted upstream through the ETH1 electrical port. After the networkcable is connected to the ETH1 port, however, the indicator of the port is off and the board cannotping the gateway successfully.





576


l The configuration of the PVMD board is incorrect.

Procedure

Step 1 A normal network cable is used to connect to the uplink port. If it is found that the fault stillexists, it indicates that the fault is not caused by the network cable fault.

Step 2 The display working mode command is executed to check the working mode of the PVMDboard. It is found that the uplink mode of the board is the independent mode and that the uplinkport is an FE optical port. The uplink port, however, is required to be an ETH1 electrical port.huawei#display working mode working mode:alone outband port:ETH port service port:FE optic port

Step 3 The up-linkport set workmode command is executed to change the uplink port mode to ETH1port. Then, it is found that the indicator of the ETH1 port is on and that the PVMD board canping the upper-layer device successfully. This indicates that the fault is rectified.huawei(config)#up-linkport set workmode { workmode<E><ETH1,FE-O,GE-O> }:ETH1 Command: up-linkport set workmode ETH1

----End


Compared with the PVMB board, the PVMD board supports the upstream transmission throughthe optical port. Therefore, when the PVMD board is used as the control board of the UA5000,you must configure the mode of the uplink port to optical port or electrical port mode accordingto the actual attributes of the physical port.



Fault Type

Other

Board fault

Keyword

Database configuration file




577

Fault DescriptionDuring the deployment of an office, an IPMB board that was originally installed on the HABAshelf is inserted into the HABC shelf and the service is provided when the originally configureddata is not erased. Then, the service runs in the normal state but the system frequently generatesthe alarm indicating that the control board does not match the shelf.

Alarm InformationAn alarm, "Failure: Failed to resume configuration data of device", indicating that issuing theconfiguration data fails is displayed on the HyperTerminal.


Cause AnalysisThe information about the type of the mother board is saved in the database of the IPMB controlboard of the UA5000, and different data files are created for different types of mother boards.When the new shelf is used, if you directly configure data for the shelf without running the eraseflash data command to erase the data about the original database, the system generates the alarmindicating that the control board does not match the shelf.

Procedure






----End







578

TC-A0057 The Boards in Slots 29-35 in the Slave Shelf of the UA5000 Fail to RegisterNormally Because the E1 Lines of the Master and Slave Shelves Are ConnectedInversely

This case describes how to troubleshoot the fault wherein the boards in slots 29-35 in the slaveshelf of the UA5000 fail to register normally because the E1 lines of the master and slave shelvesare connected inversely.

Fault TypeOther

Board fault

KeywordC&C08

RSU

Fault DescriptionIn an office, the C&C08 switch is connected to a UA5000 that is configured with two shelves(each shelf is configured with one RSU board that functions as the VRSP board). During thecapacity expansion for the slave shelf on site, the network management system (NMS) displaysthat seven service boards (in slots 29-35) fail after being inserted into the corresponding slots.



l The data configuration of the C&C08 switch is incorrect.l The DIP switches of the RSU board are set incorrectly.l The service board is faulty.l The HWCB board is faulty.l The E1 (2M) line is connected to the RSU board in an incorrect sequence.

Procedure

Step 1 The data configuration of the C&C08 switch is checked, and it is found that the configurationis correct. Then, the E1 line connection of the faulty shelf is exchanged with the connection ofa normal shelf at another site on the digital distribution frame (DDF) of the switch. It is foundthat the fault of the UA5000 shelf persists. This indicates that the data configuration of theC&C08 switch is correct.

Step 2 The version of the RSU board is checked. It is found that the version is 5125. The DIP switchsettings of the RSU board of this version determine that the shelf type is HABA. Therefore, itindicates that the settings of the DIP switches of the RSU board are correct.



579

Step 3 The A32 service boards in slots 29-35 are replaced. It is found that the fault persists. Thisindicates that the service boards are normal.

Step 4 The HWCB transfer board is replaced, and it is found that the fault persists.

Step 5 The slave shelf is removed and inserted again, and it is found that the service board can registernormally. When this service board is removed from the shelf, however, the NMS of the C&C08generates an alarm for shelf 0 instead of generating an alarm for shelf 1 normally. This indicatesthat the connections of the master and slave shelves may be incorrect. The subsequent checkshows that the E1 lines of the master and slave shelves are connected inversely. After the E1lines of the two shelves are connected again properly, it is found that the boards in slots 29-35can register normally. Thus, the fault is rectified.

NOTE

The master shelf of the UA5000 provides 18 slots. Slots 0 and 1 are designed to house secondary powerboards, slots 2 and 3 to house broadband control boards, slots 4 and 5 to house narrowband control boards,and slot 17 is already configured with the TSSB test board. The remaining 11 slots support a maximum of11 service boards. After the E1 lines of the master and slave shelves are connected inversely, the mastershelf data of the switch corresponds to the slave shelf hardware of the UA5000. As a result, the serviceboards in seven slots fail to register normally.

----End


During the project deployment, you must check the installation of the cabinet, cable connections,and data configuration of the device carefully, to avoid resource wastage due to incorrect basicconfigurations. After a fault occurs, you are suggested to check the upper and lower-layer devicesto locate the fault, based on the entire network rather than on a single device.

TC-A0060 The Service Board Is Faulty Because the Hardware Configuration of theHW Transfer Board Is Incorrect

This case describes how to troubleshoot the fault wherein the service board is faulty because thehardware configuration of the HW transfer board is incorrect.

Fault Type

Other

Board fault

Keyword

HWTF

HWCF

Fault Description

During a new deployment of the UA5000, the A32 service board is in the faulty state after beingadded in the HABD shelf and confirmed. The HABD shelf is also configured with the broadbandcontrol board and broadband service board. The display board 0 command is executed to checkthe status of other boards. The check result shows that other boards are in the normal state.



580



l The –48 V power supply is abnormal.l The service board is faulty.l The PVM narrowband control board is faulty.l The PWX power board is faulty.l The mother board of the HABD shelf is faulty.l The HW transfer board is faulty.

Procedure

Step 1 The broadband control board and broadband service board are in the normal state. This indicatesthat the –48 V power supply used by the shelf is normal.

Step 2 The A32 service board is replaced. It is found that the fault persists. This indicates that the faultis not caused by the faults on certain service boards.

Step 3 The PVM narrowband control board is replaced, and it is found that the fault persists.

Step 4 The PWX board is replaced, and it is found that the fault persists.

Step 5 The HABD shelf is replaced, and it is found that the fault persists.

Step 6 The configuration of the shelf is checked. It is found that the shelf is configured with the HWTFtransfer board, which actually should be used in the master shelf. After the HWTF transfer boardis replaced by the HWCF board, the status of the service board becomes normal and the fault isrectified.

----End

Suggestions and SummaryThere are multiple types of transfer boards for the UA5000. The knowledge about the functionsof each type of transfer board and the type and characteristics of the corresponding board (towhich the service is to be transferred) helps locate the hardware configuration problems quickly.For the associated information, see the corresponding Product Description manual.

TC-A0065 The Power Module of the E400 Is Damaged Because the Voltage Betweenthe N-Line of the Power Network and the Ground Is Excessively High

This case describes how to troubleshoot the fault wherein the power module of the E400 isdamaged because the voltage between the N-line of the power network and the ground isexcessively high.

Fault TypeOther



581

Power fault

Keyword

F01E400

N-line to ground voltage

Fault Description

The power module of an outdoor integrated access device F01E400 is damaged, and the devicecannot use the AC power. As a result, all the services are interrupted.

Alarm Information

The alarm LED on the PSM monitoring module is on.

Cause Analysis


l The output of the AC voltage is abnormal.l The mains supply is cut.l The power module system is faulty.

Procedure

Step 1 The AC voltage of the L-N output terminal on the site is tested. The tested voltage is 225 V,which is in the normal range.

Step 2 The AC MCB of the 4845 power is measured. If the voltage is 225 V, it indicates that the 4845power is normal.

Step 3 The MCB of the battery is measured. It is found that the input voltage after the 4845 powerconversion is 0 V, and the voltage of the binding post on the battery is 42 V.

Step 4 The 4845 power module is replaced. Then, it is found that the device can be powered on andcan work normally. The alarm LED on the PSM monitoring module is on, which indicates thatthe 4845 power module is faulty.

Step 5 The L-line to ground voltage and N-line to ground voltage are measured again. It is found thatthe L-line to ground voltage reaches 395 V and the N-line to ground voltage reaches 160 V,which both exceed the normal mains power standard. The power supplier is requested to adjustthe voltage, and then the fault is rectified.

----End


When installing the outdoor devices, you must measure the AC N-line to ground voltage due tothe uncertainty of the external environment and power. If the voltage exceeds the standard (<20 V), you must contact the power supplier to adjust the voltage before powering on the devicefor long-term operation.



582

TC-A0067 All the Service Boards in the Slave Shelf of the UA5000 Fail to Registerwith the System Because One DSL Board in the Shelf Is Faulty

This case describes how to troubleshoot the fault wherein all the service boards in the slave shelfof the UA5000 fail to register with the system because one DSL board in the shelf is faulty.

Fault TypeOther

Board fault

KeywordSlave shelf

HWTB

Fault Descriptionl Networking: UA5000 -> bearer network -> softswitchl Fault description: The slave shelf of a UA5000 is installed with the ASL and DSL boards,

but all the boards in the shelf fail to register with the system.

Alarm Informationl The display board 1 command is executed to query the board status. The query result

shows that all the boards in the slave shelf are faulty.l The shelf panels are checked. It is found that all the indicators on one DSL board are on.l The alarm records are checked. It is found that the board error alarms have been generated,

and the earliest board alarm is an alarm for the DSL board.


l The transfer board connected to the HW line or the HW connection line is faulty.l The DSL board is faulty.

ProcedureStep 1 The HWTB board of the slave shelf is replaced. It is found that the fault still persists.

Step 2 The board add and board delete operations can be performed on the slave shelf before and afterthe HWTB board is replaced. Therefore, this indicates that the fault is not caused by the HWTBboard and the HW connection line.

Step 3 The faulty DSL board is removed from the slave shelf and the board status of the slave shelf ischecked again. It is found that the status of each board returns to normal and the service recovers.

----End




583

TC-A0072 The UA5000 Fails to Register with the Softswitch Server Because thedual-homing function of the UA5000 is disabled

This case describes how to troubleshoot the fault wherein the UA5000 fails to register with thesoftswitch server because the dual-homing function of the UA5000 is disabled.

Fault TypeOther


KeywordDual-homing

Fault DescriptionDuring a new deployment, the UA5000 is connected to the softswitch. The IP addresses of thegateway and the softswitch can be pinged through from the UA5000, but the UA5000 fails toregister with the softswitch after the MG interface is reset on the UA5000.



l The optical fiber jumpers are abnormal.l The negotiation data configured on the softswitch is inconsistent with the corresponding

data on the UA5000.l The address of the UA5000 for the registration with the softswitch is incorrect.

Procedure

Step 1 The LINK indicator for the optical fiber is checked. It is found that the indicator is on. In addition,considering the fact that the IP addresses of the network management system (NMS) and otherdevices can be pinged through from the UA5000, it can be determined that the fault is not causedby the optical fiber.

Step 2 The operator is contacted to check the data configured on the softswitch. It is found that the dataconfigured on the softswitch is consistent with the data on the UA5000.

Step 3 The messages are traced. It is found that the registration message reported by the UA5000 isinconsistent with the message returned by the softswitch. The message traced on the softswitch,however, shows that the softswitch fails to receive the message sent by the UA5000. TheUA5000 may fail to register with the correct softswitch.

Step 4 The display mg-software parameter 2 command is executed to check the dual-homing functionof the UA5000. It is found that the dual-homing function of the UA5000 for registering with thesoftswitch is disabled. As a result, after the UA5000 fails to register with one softswitch, it cannotregister with another softswitch. After this cause is identified, the mg-software parameter 2



584

2 command is executed to enable the dual-homing function of the UA5000. Then, the fault isrectified.

----End


None

TC-A0075 The VRSP Board of a Newly-Deployed E200 Is Faulty Because One 2MLine on the Backplane of the OLT Is Faulty

This case describes how to troubleshoot the fault wherein the VRSP board of a newly-deployedE200 is faulty because one 2M line on the backplane of the OLT is faulty.

Fault Type

Other

Board fault

Keyword

Board hardware

Connection lines

Fault Descriptionl Networking: E200 (VRSP) -> OLT (DTE)

l Fault description: On a newly-deployed E200, the RSU4 board is used as the virtual RSP(VRSP) board. After the data is configured through the NMS, the NMS displays that theRSP board is faulty.

Alarm Information

None

Cause Analysis


l The data configuration of the RSU4 board is incorrect.

l The version of the RSU4 board is incorrect or the DIP switches are set incorrectly.

l The RSU4 board is faulty or the PWX board is faulty.

l The 2M transfer port and the 2M line on the E200 are faulty.

l The third-party transmission device is faulty.

l The data configuration on the OLT is incorrect.



585

Procedure

Step 1 The data configuration of the RSU4 board is checked. It is found that the configuration is correct.The RSU4 board is added again. It is found that the fault persists.

Step 2 The version of the RSU4 board is checked. It is found that the version of the RSU4 board matchesthe E200. Then, the settings of the DIP switches of the RSU4 board are checked. It is found thatthe DIP switch settings are correct.RSUA>show versionBoard type: H601RSU8Board Soft Ver: 5128PCB Ver: FBasic bios Ver: 100Ext bios Ver: 105CPLD Ver: 102Logic Ver: 109Node Ver: 3103 Compiling Time: Jul 25 2007 14:28:18

Step 3 The RSU4 board is replaced with a normal RSU4 board. The subsequent test shows that the faultpersists. Then, the PWX board is replaced with a normal PWX board. The subsequent test showsthat the fault still persists.

Step 4 A loopback from the digital distribution frame (DDF) in the branch office to the E200 isperformed on the DDF, and then the show runstate command is executed to check the statusof the 2M line. It is found that the 2M line is in the normal state. This indicates that the fault isnot caused by the 2M transfer on the E200.

Step 5 A loopback from the DDF in the general equipment room to the remote E200 is performed onthe DDF, and then the status of the 2M line on the RSU4 board is checked again. It is found thatthe 2M line is in the normal state. The 2M line on the DDF is disconnected. It is found that thestatus of the 2M line on the corresponding RSU4 board changes to "Fail". This indicates thatthe transmission is normal.

Step 6 The distance of the 2M line from the backplane of the OLT to the DDF in the general equipmentis only 10 meters. A loopback from the DDF to the DTE board is performed on the DDF, andthen the indicator on the DTE board is checked. It is found that the corresponding indicator isoff. Then, the 2M connector on the DDF is disconnected, and the corresponding indicator onthe DTE board is checked again. It is found that the indicator is still off. 30s later, the indicatorturns on. Therefore, it can be determined that this 2M line is faulty. After the 2M line is removedfrom the DTE backplane and a new 2M line is connected to the backplane, the RSP indicatorturns green. The subsequent test shows that the service is restored.

----End


When functioning as the VRSP board, the RSU4/PVM board has similar functions with the RSPboard. When an RSP board fault occurs, you need to check whether the 2M transmission line isnormal.

TC-A0076 The Network Port Cannot Be Activated Because the Mode of the UplinkPort on the IPMD Board Is Incorrect

This case describes how to troubleshoot the fault wherein the network port cannot be activatedbecause the mode of the uplink port on the IPMD board is incorrect.



586

Fault Type

Other


Keyword

Electrical port

Fault Descriptionl Networking: UA5000 (IPMD) -> Ethernet switchl Fault description: A newly-deployed UA5000 is connected to the switch through the ETH0

port on the IPMD control board. After the two devices are connected, the network portcannot be activated.

Alarm Information

None

Cause Analysis


l The network cable is faulty.l The Ethernet port on the peer device is configured incorrectly.l The configuration of the ETH0 port on the IPMD board is incorrect, or the control board

of the UA5000 is faulty.

Procedure

Step 1 The in-use network cable is replaced by another normal straight through network cable. Thesubsequent test shows that the fault persists.

Step 2 The peer device is directly connected to a PC through the network cable. It is found that thenetwork port can be activated. This indicates that the peer device is normal. After the PC isdirectly connected to the IPMD board, it is found that the port cannot be activated. This indicatesthat the fault occurs on the IPMD control board.

Step 3 The fault may be caused by incorrect port configuration, because the IPMD board supports twomodes for upstream transmission, namely, electrical port mode and optical port mode. Therefore,the display port state 0 command is executed to query the status of the ETH0 port. The queryresult is as follows:huawei(config-if-ipm-0/2)#display port state 0 ----------------------------------------------------------------------------- Port Port Native MDI Speed Duplex Flow- Active Link Type VLAN (Mbps) Control State ----------------------------------------------------------------------------- 0 GE-Optic 3 - 1000 full off active offline

The command output shows that port ETH0 is configured to an optical port. Then, the mode 0GE-Electrical command is executed to forcibly change the mode of the ETH0 port to a Gigabitelectrical port. The port, however, still cannot be activated.



587

Step 4 The further confirmation verifies that the port on the peer device is a Megabit electrical port.Therefore, the speed 0 100 command is executed in IPM mode to change the mode of ETH0port to a Megabit electrical port. Then, the test shows that the network port can be activatednormally.

----End


The IPMD control board uses the Gigabit optical port mode for upstream transmission by default.In the actual application, if a Gigabit optical port or electrical port is required for upstreamtransmission, the port mode must be changed accordingly. In addition, the data configuration ofthe port on the peer device must be consistent with the data configuration of the port on theUA5000.

TC-A0077 The Packets Cannot Be Transmitted Upstream to the EP1A BoardThrough the Backplane Because the Port Type of the Daughter Board of the IPMBBoard Does Not Match the Backplane

This case describes how to troubleshoot the fault wherein the packets cannot be transmittedupstream to the EP1A board through the backplane because the port type of the daughter boardof the IPMB board does not match the backplane.

Fault Type

Other

Service exception

Keyword

Database

Configuration file

Fault Descriptionl Networking: UA5000 (IPMB) -> MA5680Tl Fault description: The UA5000 IPMB board transmits data upstream to the MA5680T

through the EP1A board. The uplink port on the IPMB board, however, is always in theoffline state.

Alarm Information

None

Cause Analysis


l The data configuration of the port is incorrect.l The hardware connection is incorrect.



588

Procedure

Step 1 Based on the fact that the IPMB board transmits data to the EP1A board through auto-negotiation(no manual configuration is required), a network cable is used to directly connect the uplink porton the IPMB board to the network port on the EP1A board. It is found that the statuses of thetwo ports on the IPMB and EP1A boards are normal.

Step 2 The daughter board of the IPMB board is removed during the on-site deployment, and then theerase flash data command is executed to clear the database. It is found that the fault is rectifiedafter the board registers with the system again.

----End

Suggestions and Summaryl If the IPMB board is configured with an electrical daughter board, the packets of the device

can be transmitted upstream only through the Ethernet port by default, and the packetscannot be transmitted upstream through the backplane.

l The packets can be automatically transmitted upstream to the EP1A board through thebackplane only when the uplink port on the IPMB board is an optical port, or the IPMBboard is not configured with a daughter board.

TC-A0081 There Is No Power Feed After Users of a Half Shelf Go Off Hook Becausethe -48 V Power for the Lower Half HABA Shelf Is Faulty

This case describes how to troubleshoot the fault wherein there is no power feed after users ofthe half shelf go off hook because the -48 V power for the lower half HABA shelf is faulty.

Fault TypeOther

Power fault

KeywordMutual aid

Fault Descriptionl Networking: UA5000 (HABA shelf) -> layer-2 switch -> softswitchl Fault description: All the ASL boards of the UA5000 are displayed in the normal state, but

there is no power feed after the users connected to the lower half shelf of the HABA shelfgo off hook.



l The user cable is faulty.



589

l The service board is faulty.l The power board or the power is faulty.

Procedure

Step 1 The status of the service board is checked after the login to the device. It is found that the serviceboard is normal and the RUN indicator on the board is also normal (on for 1s and off for 1s).The power is measured on the main distribution frame that the subscriber line is not connectedto the board. It is found that the fault on the board still persists. Then, the power of the user portis directly measured on the pins of the backplane. It is found that the voltage is only -0.5 V. Thisindicates that the fault is not caused by the subscriber line.

Step 2 The service board on which the fault occurs is exchanged with a normal board and only oneservice board is used in the shelf to test. It is found that the fault persists.

Step 3 The power board is checked and replaced. It is found that the fault persists.

Step 4 The further check finds that one -48 V DC port is provided for each of the upper half HABAshelf and lower half HABA shelf. The voltage of the power line connected to the -48 V DC portfor the lower half shelf, however, is zero, after being measured through a multimeter. Then, anormal -48 V power line is used, and it is found that the fault is rectified. Thus, it can bedetermined that the fault is caused by the -48 V power input.

----End

Suggestions and SummaryThe -48 V power for the upper and lower half shelves of the HABA shelf provide power foronly the corresponding half shelf (cannot provide power for each other), but the upper and lowerhalf shelves that use +/-5 V working voltage can provide mutual aid for each other, that is, whenthe power for one half shelf fails, the power for the other half shelf can be used to provide powerfor the entire shelf.

TC-A0086 The 2M Links on the Switch and the UA5000 Are Seemingly NormalBecause the Transmission Device Is Not Grounded Properly

This case describes how to troubleshoot the fault wherein the 2M links on the switch and theUA5000 are seemingly normal because the transmission device is not grounded properly.

Fault TypeOther

Service exception

KeywordPVMB 2M pseudomorph

Fault DescriptionIn an office, the UA5000 is equipped with one HABA shelf, one PVMB control board, sevenA32 analog service boards (inserted in slots 0/6 to 0/12), and one DSL board (inserted in slot0/16). By the first 2M line on the left PVMB board, the UA5000 is connected to the switch



590

through the PDH transmission device. The UA5000 in this office is deployed with the VRSPconfiguration and it originally uses only one 2M line. Now the number of 2M lines on UA5000needs to be increased to four, and in addition, the standby PVMB board is installed on theUA5000. In this manner, the UA5000 is connected to the switch through four 2M lines on theactive and standby PVMB boards (each PVMB board provides two 2M lines). After the standbyPVMB board is configured, it is found that the port on the A32 board in slot 0/12 and the attendantposition user connected to the DSL board in slot 0/16 cannot operate normally. The voice porton the A32 board cannot process services normally. That is, the users connected to this port candial the number of the called party successfully but cannot hear the voice from the called party.The same symptom occurs on the attendant position user connected to the DSL board. Inaddition, the right RSP board on the network management system (NMS) is in the faulty (red)state.



l The data configuration is incorrect.l The 2M link is faulty.l The hardware of the device is faulty.l The power supply is abnormal.l The device is not grounded properly.

ProcedureStep 1 The detailed data configuration on the switch and UA5000 is checked. It is found that the data

configuration is correct. This indicates that the fault is not caused by data configuration. OneHABA shelf is emulated as two RSP shelves on the switch.

Step 2 The two 2M lines on the active PVMB board are connected to two 2M lines (No.1 and No.2)on the PDH transmission device, and the two 2M lines on the standby PVMB board are connectedto two 2M lines (No.3 and No.4) on the PDH transmission device. The four 2M lines aredisconnected one by one and tested. No crossed pair is found. In addition, the tests of self-loopand loopback to the peer end are normal. This indicates that the 2M lines are normal, though theright RSP board is displayed as in the faulty state in red.

Step 3 Based on the fact that the fault occurs on slots 0/12 and 0/16, which correspond to the right halfshelf of the RSP shelf on the switch, the service boards inserted in slots 0/12 to 0/16 are tested.It is found that the fault wherein the call can be set up successfully but the users cannot hear anyvoice occurs on all the service boards inserted in slots 0/12 to 0/16. The 2M resources allocationon the switch is as follows: The two 2M links provided by the active RSP board are used for thecommunication of the left half shelf (corresponding to the 2M lines on the physical active PVMBboard). The two 2M links provided by the standby RSP board are used for the communicationof the right half shelf (corresponding to the 2M lines on the physical standby PVMB board).Based on the preceding analysis, it is considered that the hardware of the device is faulty. Afterthe shelf of the UA5000 and the PDH transmission device are replaced, however, it is found thatthe fault still persists.

Step 4 The power and device grounding in the equipment room is checked. It is found that the groundcable of the PDH transmission device is connected to the screw for fixing the board on the



591

UA5000. This screw, is in direct contact with the metal material of the UA5000, which, however,is painted with a layer of rust proof paint and is equipped with a plastic pad. Therefore, the PDHtransmission device is just seemingly grounded but is actually insulated. That is, the groundingof the PDH transmission device is invalid. Then, ground cable of the PDH transmission deviceis re-connected to the ground bar. The subsequent test shows that the fault is rectified.

----End

Suggestions and SummaryThe fault in this case is actually caused by a minor problem, that is, the transmission device isnot grounded properly and therefore the two 2M links (No.3 and No.4) cannot be used normally.Generally, if the transmission device is not grounded, the quality of the 2M link communicationis affected and error codes are generated. In this case, the grounding failure of the transmissiondevice is originally not considered to cause the communication failure of the 2M link, becausethe 2M link is normal in the self-loop test. The normal result, actually proved a pseudomorph.Therefore, it is recommended that you pay more attention to the grounding factor in theengineering.

TC-A0090 All the Services Carried on the UA5000 Are Interrupted Because the DataConfiguration on the Softswitch Is Incorrect

This case describes how to troubleshoot the fault wherein all the services carried on the UA5000are interrupted because the data configuration on the softswitch is incorrect.

Fault TypeOther

Other

KeywordData configuration

error

Fault DescriptionNetworking: Softswitch -> bearer network -> UA5000

Fault description: All the user services carried on the UA5000 are interrupted.



l The communication on the bearer network is interrupted.l The data configuration on the UA5000 is incorrect.



592

l The upper layer device is faulty.

Procedure

Step 1 The softswitch is pinged from the UA5000. It is found that the softswitch can be pingedsuccessfully and the MG interface is in the normal state. Therefore, it can be determined thatthe bear network is normal.

Step 2 The data configuration on the UA5000 is checked. It is found that the configuration is correct.

Step 3 Packets are captured and analyzed. It is found that the UA5000 cannot identify the signalingsent by the softswitch, namely, [07:55:49.450]msg from mgc([10.55.80.6]:2944) to mg([10.58.136.22]:2944): !/2 [10.55.80.6]:2944 T=1191256705 {C=206{MF=A1{M{TS{fsk/fsktype=1}},SG{al/ri,fsk/fsk{d="2008-09-21",t="07:54:08",r=Private}}}}} [07:55:49.450]msg from mg([10.58.136.22]:2944) to mgc([10.55.80.6]:2944): !/2 [10.58.136.22]:2944ER=400{" Syntax error in message"}.

Step 4 The CO maintenance personnel are contacted to check the data configuration on the softswitch.It is found that the configuration on the softswitch is incorrect. After the configuration on thesoftswitch is corrected, the fault is rectified.

----End


None

TC-A0092 The Port Link Fails to Be Set Up Because the Modes of the Ports on thePVMD Board and the Upper-Layer Device Are Inconsistent

This case describes how to troubleshoot the fault wherein the port link cannot be set up becausethe modes of the ports on the PVMD board and the upper-layer device are inconsistent.

Fault Type

Other

Other

Keyword

PVMD

Working mode

Fault Description

The UA5000 transmits services upstream to the MA5600 through the Gigabit optical port onthe PVMD board. The LINK indicator of the network port on the MA5600, when the opticalfiber is just inserted in to the port, is on. Subsequently, the LINK indicator is off. In this case, itis found that the port is down, and that the LINK and ACT indicators of the network port on theUA5000 are off. That is, the port link between the UA5000 and the MA5600 fails to be set up.



593



l The optical fiber or transceiver may be faulty because the indicator for the physical link ofthe port is off.

l The data configuration of the uplink port on the PVMD board is incorrect.l The working modes of the ports on the devices on the two sides are inconsistent.

Procedure

Step 1 The optical fibers are replaced by a new pair of optical fibers. It is found that the fault persists.This indicates that the fault is not caused by the optical fiber. Considering that the two PVMDboards provide two Gigabit optical transceivers and the MA5600 also provides two Gigabitoptical transceivers, the two optical transceivers on each of the device are exchanged to connectto the peer device. It is found that the fault persists. Therefore, it indicates that the opticaltransceivers on the two devices are normal.

Step 2 The up-linkport set workmode is executed to check the type of the uplink port. It is found thatthe type is configured to GE-O, which is correct.

Step 3 The working modes of the two ports on both sides are checked. It is found that the working modeof the port is configured to auto-adaptation, whereas the working mode of the port on theMA5600 is configured to 1000 M full-duplex. Then, the working mode of the uplink port on theUA5000 is changed to 1000 M full-duplex. Later, it is found that the port link is set upsuccessfully and the MG registers with the system successfully. That is, the fault is rectified.

----End

Suggestions and SummaryThere is another simple method of determining whether the optical fiber and transceiver arenormal. That is, use the optical fiber to perform self-loop on each network port, and then checkwhether the LINK indicator of the network port is normal. In addition, run the associatedcommand to check whether the status of the network port is restored, and accordingly you candetermine whether the optical fiber and transceiver are normal.

TC-A0094 Power Module of the E400 Is Damaged by Surge Current That IsGenerated When the AC L Line and N Line Are Connected Inversely

This case describes how to troubleshoot the fault wherein the power module of the E400 isdamaged by surge current that is generated when the AC L line and N line are connectedinversely.

Fault TypeOther

Power fault



594

KeywordL line and N line

Power module

Fault DescriptionThe power module of the F01E400, an outdoor integrated access device, is damaged when theelectrical network is unstable or surge current (such as lightning strike) is generated. As a result,the device cannot use the AC power and all the services are interrupted when the battery poweris used up.

Alarm InformationThe alarm indicator on the PSM monitoring module is on.


l The mains supply is cut.l The power module system is faulty.l The AC power is faulty.

ProcedureStep 1 The AC voltage of the input circuit breaker on the device is measured. The voltage measures

226 V, which is in the normal range.

Step 2 The voltage of the AC circuit breaker on the 4845 power module is measured. The voltagemeasures 0 V, which indicates that there is no AC voltage.

Step 3 Based on the fact that the alarm indicator of the PSM monitoring module is on, it can bedetermined that the 4845 power module has no AC power supply.

Step 4 The 4845 power module is replaced, and then it is found that the device can be powered on andwork normally.

Step 5 The rectifier module of the 4845 power is disassembled. It is found that the electrical componenton the N line side is burnt but the fuse on the L line side is normal. This indicates that the ACL line and N line are connected inversely.

Step 6 The AC power input is checked. It is found that the L line and N line are indeed connectedinversely. After the two lines are connected properly, the fault is rectified.

----End

Suggestions and SummaryRectifier HRS850-9000C of the 4845 power of the E400 cabinet is designed with a protectionmeasure for L line, that is, a fuse is installed on the input side, which can well protect the linein the case of voltage fluctuation. The N line, however, is not provided with any protectionmeasure. Therefore, when installing the AC power, you must be very cautious of the portsmarked on the circuit breaker of the device for connecting to the L line and N line. The two linesmust not be connected inversely.



595

TC-A0095 Initializing the FPGA and Forwarding Logic Components Fails Becausethe Extended BIOS Is Not Loaded During the Upgrade of the PVMB Board

This case describes how to troubleshoot the fault wherein initializing the FPGA and forwardinglogic component fails because the extended BIOS is not loaded during the upgrade of the PVMBboard.

Fault Type

Other

Upgrade loading failure

Keyword

Failure to initialize the FPGA and forwarding logic components

Fault Description

Networking: A high-density UA5000 (HABA) is connected to the CC08 (that is configured withthe 128 module) and communicates with the SMII interface. The UA5000 is configured withonly one HABA shelf and it provides four 2M lines. The HABA shelf is simulated as two RSPshelves.

Fault description: After the PVMB board is removed, an alarm indicating that initializing theFPGA and forwarding logic components fails is generated a period after the maintenanceengineer logs in to the device through the serial port. The maintenance terminal of the switchshows that the RSP shelves and the A32 board are faulty. In addition, the corresponding 2Mports are displayed in the faulty state. The version of the switch is V610R105M8008P013 andthe version of the PVMB board is PVMVRSP6160.

Alarm Information

An alarm indicating that initializing the FPGA and forwarding logic components fails isgenerated.

Cause Analysis


If the extended BIOS is not loaded or loaded incorrectly during the upgrade, initializing theFPGA and forwarding logic components fails even if the version information queried after theupgrade is incorrect.

Procedure

Step 1 The maintenance terminal is connected to the PVMB board through the serial port, and then theversion information is queried. After the comparison of the queried information with theconfiguration information, it is found that the version information is correct.

Step 2 The fault may occur during the version loading process. Therefore, the following steps areperformed and then the device is tested after the board is removed. It is found that the fault isrectified.



596

1. Upgrade the extended BIOS.2. Load the package file.3. Load the program and data files.

----End

Suggestions and SummaryIt is known from the personnel who upgrade the PVMBVSP6130 to VRSP6160 that the packagefile, program, and data are directly loaded during the upgrade, but the extended BIOS is notloaded. At another site where the PVMBVRSP6130 is used, the incorrect loading procedure,that is, the package file, program, and data are loaded without loading the extended BIOS, isperformed. After the PVMB board is removed, the same alarm indicating that initializing theFPGA and forwarding logic components fails is generated. Thus, the fault is determined to becaused by the failure to upload the extended BIOS. The further analysis shows that the versioninformation queried after the upgrade is correct because the package file also contains the loadingitems for the BIOS. The upgrade of the package file, however, cannot upgrade the extendedBIOS correctly.

You must perform the correct procedure during the upgrade, and after the upgrade, you mustperform various tests to check whether the upgrade is successful.

TC-A0097 The Services on the Lower Half Shelf Fails Because the Shelf Type ofthe UA5000 Is Set Incorrectly

This case describes how to troubleshoot the case wherein the services on the lower half shelffails because the shelf type of the UA5000 is set incorrectly.

Fault TypeOther

Other

KeywordHABA

Fault DescriptionA newly-deployed UA5000 uses the HABA shelf and is configured with one PVM board. Theshelf is simulated as two virtual RSP (VRSP) shelves. The 2M lines are connected to the firstand second 2M ports on the PVM board in slot 4. The user of the UA5000 reports that the busytone is played after offhook. On the BMS, the lower half shelf is displayed in red.





597

l The 2M line connected for the simulated second shelf is faulty.l The port on the DTE board of the OLT is faulty.l The data configured on the BMS is incorrect.l The hardware of the UA5000 is faulty.

Procedure

Step 1 A self-loop test from the equipment room to the OLT is performed. It is found that thecommunication is normal.

Step 2 A self-loop test from the equipment room to the UA5000 is performed. It is found that the E1links are normal.

Step 3 The display version command is executed to query the version of the UA5000. It is found thatthe "VRSP Workmode" value of the device is HABD, whereas the actual shelf type of the deviceis HABA.

Step 4 The working mode of the shelf is changed to HABA. Then, it is found that the fault is rectified.

----End

Suggestions and SummaryIn the deployment of the device, check and ensure that the settings of the shelf are the same asthe actual running parameters of the shelf.

TC-A0099 A Large Number of IP Address Conflict Alarms Are Generated on theUA5000 Because the BRAS Fails to Process the ARP Proxy Packets Properly

This case describes how to troubleshoot the fault wherein a large number of IP address conflictalarms are generated on the UA5000 because the BRAS fails to process the ARP proxy packetsproperly.

Fault TypeOther

Service exception


ARP proxy

Fault DescriptionNetworking: UA5000 (EPON upstream) -> MA5680T -> convergence switch -> third-partyBRAS

Fault description: All the new UA5000s connected to the third-party BRAS continuously reportIP address conflict alarms. The MAC addresses in the generated alarms are the MAC addressof the same BRAS, and the alarms are generated at an average frequency of one alarm in oneminute.



598

Alarm Information

IP address conflict alarm

Cause Analysis


According to the TCP/IP protocol stack, the host checks whether its IP address is occupied byusing the free ARP request mechanism in the following two modes:

l Proactive mode: In this mode, the host sends the free ARP request to detect whether therequest is responded. The source IP address and the requested IP address are the IP addressof the host, which means that the host requests the IP address of itself to be resolved. If thehost receives an ARP response to the IP address of itself, it indicates that a host on thenetwork uses the same IP address.

l Passive mode: In this mode, if the host receives a free ARP request sent by another host,and the requested IP address is the IP address of the host that sends the request packet, itindicates that a host on the network uses the same IP address.

According to the preceding principle, to solve the IP address conflict problem, you can checkwhether the data plan and data configuration use identical IP addresses. If the problem still cannotbe solved, you can capture packets, and then analyze and locate the fault based on the ARPprinciples.

Procedure

Step 1 The data plan and the configurations of the BRAS, convergence switch, MA5680T, and UA5000are checked. It is found that these devices do not use the identical IP address.

Step 2 It is considered that the IP address may be incorrect. Then, the IP address of the UA5000 ischanged to another IP address. It is found that the fault still persists. The UA5000 is disconnectedand then the original IP address that reports conflict is pinged. It is found that the IP addresscannot be pinged through. This indicates that this IP address is not configured by another deviceon the network.

Step 3 According to the analysis of the TCP/IP protocol stack, it is determined that if an IP addressconflict alarm is generated on the UA5000, the UA5000 must receive a free ARP request orresponse targeting the IP address of itself. The analysis of the captured packets shows that theUA5000 sends one free ARP request in each minute, whereas each time after the UA5000 sendsthe ARP request, the third-party BRAS responds to the UA5000 with the MAC address of itself.This indicates that the processing on the UA5000 is normal and the fault is associated with theprocessing on the BRAS.

Step 4 After the query, it is known that the third-party BRAS is enabled with an L3 interface for thevoice service VLAN of the UA5000, and that the BRAS is enabled with the ARP proxy function.When the third-party BRAS is enabled with the ARP proxy function, the BRAS responds to allthe ARP requests (including the free ARP requests) with its MAC address.

Step 5 It is determined that the ARP proxy mechanism of the third-party BRAS is faulty. The deviceof Huawei does not respond to free ARP requests after being enabled with the ARP proxyfunction. Then, the ARP proxy function of the BRAS is disabled, and the MA5680T is configuredwith an L3 interface and is enabled with the ARP proxy function. The subsequent tests find that



599

no IP address conflict alarm is generated, and the voice and data services carried on the UA5000are normal. Thus, the fault is rectified.

----End


To solve the IP address conflict problem, you can check whether the data plan and dataconfiguration use identical IP addresses. If the problem still cannot be solved, you can capturepackets, and then analyze and locate the fault based on the ARP principles.

TC-A0101 The ADRB Board Is Not in the Working State Because the -48 V Inputfor the Lower Half Shelf of the HABA Shelf Is Abnormal

This case describes how to troubleshoot the fault wherein the ADRB board is not in the workingstate because the -48 V input for the lower half shelf of the HABA shelf is abnormal.

Fault Type

Other

Board fault

Keyword

-48 V input

Fault Description

Fault description: An ADRB board is inserted into slot 0/35 of the rear access HABA shelf onthe UA5000. After the HABA shelf is powered on, the ADRB board is not in the working state,and the RUN LED is off. When the board information is queried after the IPMB system is loggedin, and the system prompts "Unmanageable". The model of the IPMB board is H602IPMB andthe model of the ADRB board is H603ADRB.

Alarm Information

None

Cause Analysis


l The ADRB board is faulty.l The slot 0/35 of the HABA shelf is faulty.l The power system of the shelf is faulty.

Procedure

Step 1 The ADRB board is inserted into slot 0/16 of the upper half shelf. It is found that the ADRBboard can start. This indicates that the fault is not caused by the ADRB board fault.



600

Step 2 The ADRB board is inserted into other slots of the lower half shelf. It is found that the ADRBboard cannot start.

Step 3 It is considered that the slot of the HABA shelf may be faulty. The backplane of the shelf isreplaced. It is found that the fault persists.

Step 4 The input voltage of the lower half shelf is tested. It is found that the voltage is 0 V, which meansthat there is no voltage input. Then, the output port of the 4845 power module is checked. It isfound that there is no voltage output. The power output port is replaced with a normal port. It isfound that the ADRB board in slot 0/35 can start normally and the ADRB board can also startnormally in other slots. The fault is rectified.

----End


The upper half HABA shelf and the lower half HABA shelf provide one -48 V DC port each tosupply the -48 V DC power input to the upper half HABA shelf and lower half HABA shelfrespectively.

The broadband service board requires -48 V DC input. The boards related to the narrowbandservice can be started normally only when the secondary power board is powered on normally.These boards include the boards for providing narrowband services of the broadband andnarrowband combo device, narrowband service boards, and narrowband control boards.

TC-A0104 The Echo Is Loud During the Call of Users Connected to the UA5000Because the Service Board Is Faulty

This case describes how to troubleshoot the fault wherein the echo is loud during the call ofusers connected to the UA5000 because the service board is faulty.

Fault Type

Other

Board fault

Keyword

FAR

ASL

Echo

Echo

Fault Description

Networking: UA5000 -> switch -> SoftX3000

During the call of certain users connected to the UA5000, the peer user hears the loud echo inthe communication.



601



l The DSP gain is incorrect.l The port gain is incorrect.l The service board is faulty.

Procedure

Step 1 The DSP input gain and output gain are adjusted to the minimal values. It is found that the echostill exists.

Step 2 The port gain is adjusted to the minimal value. It is found that the echo still exists though it isnot as loud as before.

Step 3 The service boards in slot 8 and slot 13 are interchanged. It is found that the fault is relevant tothe boards. This indicates that the fault is caused by a service board.

Step 4 The further check shows that the fault occurs on the FAR board, which is a long-distance boardused when the feeder distance is longer than 5 kilometers. The users connected to the device,however, are in the neighboring buildings and the distance is within 200 meters. Therefore, theFAR board is replaced with the ASL board. Then, the fault is rectified.

----End

Suggestions and SummaryYou must use the corresponding board as required.

TC-A0106 The NMS and Services Fail Because VLAN IDs Are Different When theQinQ Network on the UA5000 Is Reconstructed

This case describes how to troubleshoot the fault wherein the NMS and services fail becauseVLAN IDs are different when the QinQ network on the UA5000 is reconstructed.

Fault TypeOther

Other

KeywordQinQ

NMS

Fault DescriptionNetworking: The UA5000 is connected to the upper-layer switch through the optical fiber.



602

Fault description: The users connected to the UA5000 cannot access the Internet. The networkmanagement center cannot manage devices, but the test shows that the line and the optical linkare normal.

Alarm Information

None

Cause Analysis


l The uplink port is disconnected.

l The optical/electrical converter is faulty.

l The configuration of the switch is incorrect.

l The VLAN configuration is incorrect.

l A loop is formed.

Procedure

Step 1 Data is checked on the UA5000 after login. It is found that the data is correct and the uplink portis normal, but the gateway cannot be pinged through. The ID of the network management VLANis 753.

Step 2 The optical-to-electrical (O/E) converter is replaced, but the gateway still cannot be pingedthrough.

Step 3 The VLAN is checked on the switch in the central office after login. It is found that the VLANID corresponding to the UA5000 is 2329.

Step 4 The alarm information of the NM center is checked and it is found that services of the UA5000are interrupted at 12:00 one night. It is verified that the QinQ network is reconstructed that nightand the network management VLAN ID is changed to 4000, whereas the outer VLAN ID is2329.

Step 5 Based on the preceding analysis, it is determined that the fault is caused by the configurationinconsistency between the outer VLAN of the UA5000, VLAN of the switch, and the networkmanagement VLAN. After the IDs of the network management VLAN and the service VLANof the UA5000 are changed to the same ID, the network management and services are restored.

----End


None

TC-A0107 The Temperature Inside the Cabinet Is Very High Because the HeatDissipation Hole on the F01D100 Cabinet Is Blocked

This case describes how to troubleshoot the fault wherein the temperature inside the cabinet isvery high because the heat dissipation hole on the F01D100 cabinet is blocked.



603

Fault TypeOther

Other

KeywordToo high temperature

Heat exchange system

Fault DescriptionFault description: The F01D100 device reports a high temperature alarm.

Alarm InformationThe temperature is too high.


l The environment monitoring module reports an alarm by mistake.l The heat exchanger is faulty.l The heat dissipation hole is blocked.

Procedure

Step 1 After on-site check, it is found that the fan inside the cabinet can rotate but the temperature istoo high and the environment monitoring is normal.

Step 2 The heat exchanger is checked and it is found that the heat exchanger is normal. (Note: To seethe heat exchanger, you need to open the front door of the cabinet and then open the two boltson the left side of the front door.)

Step 3 The fan of the heat exchanger is checked and it is found that there is heavy dust on the air filter.The dust on the air filter is cleared on site. It is found that the temperature of the cabinet reducesto the normal range and the fault is rectified.

----End

Suggestions and SummaryThe heavy dust on the air filter in the heat exchanger of the outdoor cabinet needs to be clearedin time.

TC-A0108 The Service Router and Softswitch Are Down Because Loop OccursBetween the UA5000 and T64G

This case describes how to troubleshoot the fault wherein the service router and the softswitchare down because loop occurs between the UA5000 and T64G.



604

Fault TypeOther

Service exception

KeywordLoop

Fault DescriptionNetworking: The UA5000 is connected through its optical port to the upstream T64G of anothercompany, and the optical port on the T64G is connected to the upstream service router (T64E).

Fault description: After the UA5000 is connected to the T64G, the T64E is down and all theports on the softswitch are blocked . Signaling is captured on the softswitch. It is found that theUA5000 sends about 3000 packets to the softswitch in a second.



l The UA5000 software is faulty.l The data configuration on the UA5000 is incorrect.l The UA5000 hardware is faulty.l Loop occurs on the UA5000 or T64G.

Procedure

Step 1 On site, the S3552F is connected between the UA5000 and T64G. It is found that loop alarm isgenerated when you log in to the S3552F. Furthermore, the loop alarm still exists when theUA5000 is disconnected.

Step 2 The UA5000 is disconnected. On the T64G, the UA5000 uplink port is mirrored to an Ethernetport for capturing packets. It is found that 450 thousand packets are captured in ten seconds.

Step 3 The provider of the softswitch is contacted to handle the problem. It is found that the loop occurson VLAN 1. The T64G data is checked. It is found that the data of native VLAN 1 is configuredon the port connected to the UA5000. The data is changed and then the port is connected to theUA5000 again. No fault is found in the observation in the following two days. This indicatesthat the fault is rectified.

----End

Suggestions and SummaryFor the network from the UA5000 to the T64G, pay attention to the data of native VLAN 1 onthe T64G.



605

TC-A0121 The UA5000 Cannot Go Online Because the GAUA Board Is Faulty

This case describes how to troubleshoot the fault wherein the UA5000 cannot go online becausethe GAUA board is faulty.

Fault Type

Other

Board fault

Keyword

GAUA

Optical fiber

Fault Description

Networking: The IPMB control boards in slots 2 and 3 on the CMSAN are connected to theGAUA boards in slots 6 and 7 on the AMSAN respectively through the optical fibers. Theservices are converged on the AMSAN and then sent upstream to the upper-layer network. TheN2000 BMS manages devices on the entire network.

Fault description: When the IPMB control board in slot 2 functions as the active control board,the CMSAN is found online from the N2000 BMS client. When the optical fiber of the GAUAboard in slot 6 on the AMSAN is removed, the active/standby switchover is performed on theIPMB control boards of the CMSAN. The IPMB control board in slot 3 functions as the activecontrol board and the CMSAN is found offline from the N2000 BMS client.

Alarm Information

The N2000 BMS client reports the CMSAN offline alarm.

Cause Analysis


l The versions of the active and standby IPMB control boards on the CMSAN are different.l The optical fiber between the control board in slot 3 on the CMSAN and the GAUA board

in slot 7 on the AMSAN is faulty.l The optical transceiver is faulty.l The IPMB control board in slot 3 on the CMSAN is faulty.l The GAUA board in slot 7 on the AMSAN is faulty.

Procedure

Step 1 The versions of the active and standby IPMB control boards on the CMSAN are checked and itis found that they are the same.

Step 2 The optical fiber between the control board in slot 3 on the CMSAN and the GAUA board inslot 7 on the AMSAN is replaced. It is found that the fault persists.



606

Step 3 The optical transceiver is replaced and it is found that the fault persists.

Step 4 The IPMB control board in slot 3 on the CMSAN is replaced and it is found that the fault persists.

Step 5 The GAUA board in slot 7 on the AMSAN is replaced and the fault is rectified.

Step 6 The optical fibers in slot 6 and 7 on the AMSAN are removed and inserted repeatedly. Theactive/standby switchover is performed on the IPMB control boards on the CMSAN and no NEis found offline from the N2000 BMS client. The fault is rectified.

----End


None

TC-A0122 The Broadband N2000BMS on the UA5000 Always Loses Control overDevices Because the Number of Learnable MAC Addresses of the ONU Is Small

This case describes how to troubleshoot the fault wherein the broadband N2000BMS on theUA5000 always loses control over devices because the number of learnable MAC addresses ofthe ONU is small.

Fault Type

Other

N2000 BMS losing control over the device

Keyword

Lose control

Fault Description

Fault description: The UA5000 adopts the integrated upstream mode, and the IPMB board isconnected upstream to the ONU. The N2000 BMS controls the PVMB board normally but losescontrol over the IPMB board.

Alarm Information

The N2000 BMS reports the "NE communication interruption" alarm.

Cause Analysis


l The quality of the upper-layer network is poor.

l The IPMB board is faulty.

l The ONU is faulty.



607

ProcedureStep 1 When the N2000 BMS loses control over the IPMB board, the management IP address of the

IPMB board cannot be pinged from the N2000 BMS. The management IP address (the signalingVLAN is the same as the N2000 BMS VLAN) of the PVMB board, however, can be pinged.Therefore, the fault is not caused by the upper-layer network.

Step 2 The IPMB board is replaced. It is found that the fault persists. This indicates that the fault is notcaused by the IPMB board fault.

Step 3 The MAC address learning information is checked on the ONU. It is found that the number oflearnable MAC addresses on the ONU reaches 64. The MAC addresses of the signaling VLANof the PVMB board are included, but the MAC addresses of the management VLAN of the IPMBboard are not included. It is considered that the number of learnable MAC addresses on the ONUmay reach the limit. As a result, the N2000 BMS always loses control over the IPMB boardbecause of the overflow of MAC addresses. The ONU is replaced with an ONU with a largernumber of learnable MAC addresses. The fault that the N2000 BMS loses control over the IPMBboard is rectified.

----End


TC-A0126 Ports on the A32 Service Board of the UA5000 Are Faulty Because theCables of the Accounting Device Are Connected Incorrectly

This case describes how to troubleshoot the fault wherein ports on the A32 service board of theUA5000 are faulty because the cables of the accounting device are connected incorrectly.

Fault TypeOther

Board fault

KeywordAccounting device

Hookflash

Fault DescriptionThe VoIP service is provided for a hotel user through the UA5000, After offhook, the busy toneis played for certain phones. Phone calls can be made normally after onhook and offhook. Thefault, however, recurs after a certain period of time. When phones that are not connected to theUA5000 call the faulty phones, a voice message, indicating that the faulty phones cannot be putthrough, is played. When phones that are connected to the UA5000 call the faulty phones, avoice message, indicating that the subscriber line is faulty, is played.




608

Cause Analysis


l The A32 board is faulty.

l The PVMB control board is faulty.

l The subscriber line or accounting device is faulty.

l The backplane is faulty.

Procedure

Step 1 The A32 board is replaced and the status of ports on the A32 board is checked. It is found thatthe ports are in the normal state after replacement but are in the failed state after a certain periodof time. This indicates that the fault is not caused by an A32 board fault.

Step 2 The PVMB control board is replaced. It is found that the ports on the A32 board are in thenormal state after replacement but are in the failed state after a certain period of time. Thisindicates that the fault is not caused by a PVMB control board fault.

Step 3 The subscriber line and accounting device are disconnected from the MDF. It is found that theports on the A32 board are still in the failed state. The A32 board is removed and then inserted.It is found that the ports on the A32 board are always in the normal state and the communicationis normal. This indicates that the fault is caused by a subscriber line fault or an accounting devicefault.

Step 4 The accounting device is removed and the exchange side terminal block is connected to thesubscriber line through a jumper. It is found that the ports on the A32 board are in the normalstate.

Step 5 The subscriber line is removed and a phone set is directly connected to the accounting device.It is found that the ports on the A32 board are in the failed state. This indicates that the fault iscaused by an accounting device fault. A further test is performed. It is found that the leading-incable and leading-out cable of the accounting device are connected conversely. After the cablesare connected correctly, the fault is rectified.

----End


None

TC-A0127 One of the Two NMS Channels of the UA5000 Fails Because theConvergence Switch Is Configured Inappropriately

This case describes how to troubleshoot the fault wherein one of the two NMS channels of theUA5000 fails because the convergence switch is configured inappropriately.

Fault Type

Other

Other



609

KeywordConvergence

Outband NMS

Fault DescriptionNetworking: ETH ports on the two control boards of the UA5000 are connected to the sameupstream convergence switch 3528 of Huawei through different links.l Link 1: UA5000 (outband network management port is on the board in slot 0/4) ->

transmission device -> convergence switch 3528 (port 0/15)l Link 2: UA5000 (outband network management port is on the board in slot 0/5) ->

transmission device -> convergence switch 3528 (ports 0/16)

Fault description: When the PVMD board in slot 0/4 serves as the active control board, theaddress of the gateway, to which the outband NMS belongs, can be pinged successfully. Whenthe PVMD board in slot 0/5 serves as the active control board, the address of the gateway, towhich the outband NMS belongs, fails to be pinged.

Alarm InformationThe communication between the PVMD board and the NMS server is interrupted after active/standby switchover.


l The PVMD control board in slot 0/5 is faulty. As a result, the outband NMS function fails.l The transport channel of link 2 is faulty.l The networking and data configuration are inappropriate.

Procedure

Step 1 The PVMD control board in slot 0/5 is inserted into slot 0/4. It is found that the NMS is normal.This indicates that the fault is not caused by a fault on the PVMD control board in slot 0/5.

Step 2 The port connection is adjusted. That is, the convergence switch 3528 (port 0/15) is connectedto the UA5000 (outband NMS port on the board in slot 0/4). It is found that the NMS is normal.This indicates that the fault is not caused by a transport channel fault of link 2.

Step 3 The data configuration of the convergence switch 3528 is checked. It is found that ports 0/15and 0/16 are added to convergence link group 1. The display arp interface Ethernet 0/15 anddisplay arp interface Ethernet 0/16 commands are executed. It is found that the MAC addressof the outband NMS port on the PVMD board is learnt by port 0/15 of the convergence switch3528 regardless of whether the PVMD control board in slot 0/4 or in slot 0/5 of the UA5000serves as the active control board. Therefore, it can be considered that the fault may be causedby the convergence feature of the convergence switch 3528.

Step 4 The accounting device is removed and the exchange side terminal block is directly connectedto the subscriber line through a jumper. The test shows that the port is in the normal state. Then,the subscriber line is removed and a phone set is directly connected to the accounting device.The test shows that the port is in the failed state. This indicates that the fault is caused by the



610

accounting device. A further test is performed. It is found that the leading-in cable and leading-out cable of the accounting device are connected conversely. After the cables are connectedcorrectly, the fault is rectified.

----End

Suggestions and Summaryl The interconnected devices on both side must support the convergence feature before the

convergence group function is enabled.l You need to analyze the networking for rectifying the fault.

TC-A0131 The Standby PV4 Control Board Fails to Work Normally BecauseTransport Settings Are Inappropriate

This case describes how to troubleshoot the fault wherein the standby PV4 control board failsto work normally because transport settings are inappropriate.

Fault TypeOther

Board fault

KeywordFault on the standby PV4 control board

Fault DescriptionThe PV4 service shelves of the low-density UA5000 are connected to the MD5500. Sites areconnected through optical transport devices to form a loop or link. The transport device at thecentral site is OptiX 2500+ and the transport device at other sites is Metro 1000 or Metro 155C.Two PV4 boards are configured in the control shelf at the outdoor ONU site CCC1004. Theactive PV4 control board works normally whereas the standby PV4 control board is faulty.Services of the entire site are normal. Nevertheless, a strange symptom exists. Only two E1 ports(19/5/0 and 19/5/1) are configured on the PV4 board in slot 5. The first two E1 ports of the PV4board in slot 5 are in the normal state but the third E1 port is also in the normal state. In normalcases, the third E1 port is in the failed state because the third E1 is not configured. E1 port 0 ofthe standby PV4 control board is in the failed state.



l The standby PV4 control board is faulty.l The backplane hardware is faulty.l The hardware cable is faulty.



611

l The MD5500 is connected to PV4 shelves through optical transport devices. The fault maybe caused by inappropriate transport settings.

ProcedureStep 1 The standby PV4 control board is replaced. It is found that the fault persists.

Step 2 It is difficult to replace the backplane. Therefore, replacing the backplane is the last solution tobe used.

Step 3 The cable from the 155C to the PV4 board hardware is replaced. It is found that the fault persists.

Step 4 The status of the E1 port is a physical state that is directly displayed. Three E1 ports of the activePV4 control board are normal. The E1 cable that should be connected from the transport deviceto the standby PV4 control board may be mistakenly connected to the active PV4 control board.

Step 5 Transport device engineers are contacted to analyze the fault. It is found that the transport settingsare incorrect. Then, the E1 cable connected to the third E1 port of the active PV4 control boardis connected to the first port of the standby PV4 control board.

Step 6 After the cable is connected correctly, the standby PV4 control board is still faulty.

Step 7 An E1 cable is used to connect to the 155C and the physical loopback is performed on the E1cable. Note that the inner copper conductor and the outer shielded cable of the E1 cable must beshort-circuited in the physical loopback of the E1 cable. It is found that the port of the MD5500is normal. This indicates that the fault is rectified after the transport settings are modified.

Step 8 The PV4 boards are replaced or the active and standby PV4 control boards are interchanged. Itis found that the fault is rectified. This indicates that the contact between the PV4 boards andthe backplane is inappropriate.

----End

Suggestions and SummaryNo data is configured on the PV4 board and the PV4 board contains only the hardware and boardsoftware. It is the same as a service board to a certain extent. For faults occurring on the PV4board, the location means are insufficient and only the hardware loopback and hardwarereplacement can be used to locate faults. You must be patient when rectifying such faults.

TC-A0166 Occasional Interruption of Service on a UA5000 Due to an Optical PathProblem

This case describes the troubleshooting of the occasional service interruption on a UA5000 dueto an optical path problem.

Fault TypeOther


KeywordAttenuation

Temperature



612

Fault Description

Network topology: UA5000 -> switch A -> BRAS

Fault symptom: The service on a UA5000 in an office was periodically interrupted and thenrestored. To be more specific, the layer-3 interface up and down alarms were frequentlygenerated on the uplink port on the UA5000. It was found that the service was regularlyinterrupted at 4 PM and was restored at 9 AM. The ambient temperature of the device neverexceeded -10°C.

Alarm Information

The "L3 Interface Link Down" and "L3 Interface Link Up" alarms were displayed on theHyperTerminal.

Cause Analysis


l The port on the upper-layer switch of the UA5000 was faulty.l The control board of the UA5000 was faulty.l The optical path between the UA5000 and the upstream switch was faulty.

Procedure

Step 1 The Tx and Rx optical power of the optical port was checked on switch A. It was found that theTx and Rx optical power was normal. Then, the optical port on switch A was replaced to checkwhether the service could be restored. It was found that the fault persisted, indicating that thefault was not caused by a port problem on switch A.

Step 2 Pinging upper-layer gateway address from the UA5000 was performed. It was found that thegateway could not be pinged from the UA5000 but that the tested Tx and Rx optical power ofthe optical port was normal. Given that the ambient temperature of the UA5000 never exceeded-10°C, it was hypothesized that the board might be faulty as a result of running in a low-temperature environment for a long time. Then, the IPMB control board and optical daughterboard of the UA5000 were replaced with new boards. It was found that the UA5000 still failedto ping the upper-layer gateway.

Step 3 The interface corresponding to switch A was configured with a new layer-3 address, and thenthis address was pinged from the UA5000. It was found that the address could not be pinged.

Step 4 The optical fiber connected to the UA5000 was removed and then the optical status of switch Awas checked. It was found that the port was not displayed in "down" status on switch A,indicating that the UA5000 was not directly connected to switch A. A further check confirmedthat a second switch was connected between the UA5000 and switch A, and that the actualnetwork topology was UA5000 -> switch B -> switch A -> BRAS.

Step 5 The Rx and Rx optical power of the optical port connected to the UA5000 was checked on switchB. It was found that the Tx optical power was normal but the Rx optical power was abnormal.A test showed that the light intensity transmitted from the UA5000 was very weak and unstable.

Step 6 Further analysis showed that the performance of the optical fiber between the UA5000 andswitch B was reduced and had become unstable in the cold temperature, and that the signal wasvery weak and fluctuating. As a result, signal transmission on the port on switch B occasionally



613

failed, leading to the interruption of service on the UA5000. When the optical transmission pathbetween the devices was replaced, the service interruptions on the UA5000 no longer occurred.

----End

Suggestions and SummaryThe access devices used in cold northern areas often operate in temperatures between -10°C and-30°C. On the existing network, there have been cases where the access devices were frozen andfailed to work normally, but the probability is small and the fault can be rectified after thetransmission optical path is replaced.

To improve efficiency in troubleshooting, it is necessary to obtain accurate information abouthow the devices are networked.

TC-A0177 Battery Power Supply Failure After Mains Power Cutoff, Due to the Faulton the EPMU in a Newly Deployed E200 Cabinet

This case describes the troubleshooting of the battery power supply failure after mains powercutoff. The fault occurred because the power monitoring module EPMU of the newly deployedE200 cabinet was faulty.

Fault TypeOther


Key WordEPS30-4815AF

Fault DescriptionProblem symptom:l The new deployed E200 cabinet used EPS30-4815AF for AC-DC power conversion. The

control board was RSU4 and the virtual control board was VRSP. In addition, themonitoring module was EPMU and the rectifier module was GERM4815T.

l When the external mains power was cut off, it was found that the E200 cabinet could notswitch to the battery power supply mode.

Alarm InformationThe following alarms were displayed in the alarm system of the BAM:

2009-10-30 11:35:29 Battery power-off Alarm ID 0830 Alarm source ESC2009-10-30 11:35:29 Battery circuit 1 is disconnected Alarm ID 0831 Alarm source ESC2009-10-30 11:35:29 High temperature battery power-off alarm Alarm ID 0855 Alarm source ESC




614

l The voltage of the battery set was very low, resulting in the failure of power supply by thebattery.

l The connection between the battery set and the E200 was incorrect.l The data confirmation of the device for power monitoring was incorrect.l The power monitoring module of the device was faulty.

Procedure

Step 1 The total voltage of the battery set was tested. It was found that the total voltage was –52 V.Then, the voltage of a single battery was tested. It was found that the voltage of each batterywas about -13 V, indicating that the battery set was normal.

Step 2 The internal circuit connection of the E200 was checked by using a multimeter according to theinternal circuit diagram of the device. It was found that the circuit conductivity was normal.

Step 3 The power configuration window of the H303ESC board was opened in the BAM monitoringsystem. In the configuration window, serial port 1 was configured to no power supply, and thenthe ESC board on the NE was deleted after the configuration was submitted. After the ESC boardwas deleted successfully, the H303ESC board was re-added and serial port 1 was configured toPS4845 power. Then, the configuration was submitted again and a test was performed againafter the mains power was cut off. It was found that the fault persisted.

Step 4 The real-time parameters of the battery were checked in the BAM monitoring system. It wasfound that the battery power supply state was power-off, the circuit was in the disconnectedstatus, and the battery temperature was 80°C. In addition, the battery power-off due to hightemperature alarm was reported in the alarm system. Therefore, it was hypothesized that thetemperature of the battery was excessively high and thus the monitoring module automaticallypowered off the battery as a protection mechanism, resulting in the failure of the system to switchto the battery power supply mode when the mains power was cut off.

Step 5 The surface of the battery was touched to check whether the temperature was high. It was foundthat the temperature was not high. However, the battery set was replaced with a new battery set.It was found that the fault persisted.

Step 6 The monitoring module was removed on site. The subsequent test showed that the batterysupplies power normally. After the monitoring module was replaced with a new monitoringmodule, it was found that the fault was rectified.

----End

Suggestions and SummaryThe fault of the monitoring module may result in incorrect measurement of the batterytemperature. Therefore, it is necessary to pay attention to the monitoring module problems whenlocating a fault wherein the battery works abnormally.

TC-A0183 POWER4845 EMU Fault Due to the HWCF BoardThis case describes the troubleshooting of the POWER4845 environment monitoring unit(EMU) that was faulty due to an HWCF board fault.

Fault TypeOther



615


KeywordEMU

Fault DescriptionA UA5000 that used POWER4845 EMU reported an EMU fault.

Alarm InformationThe "EMU Fault Alarm" was displayed on the HyperTerminal.



Procedure





----End


TC-A0184 Current Restriction Failure on the Battery Due to a Power Shelf FaultThis case describes the troubleshooting of the current restriction failure on a battery due to thepower shelf fault.



616

Fault TypeOther

Other

KeywordsMonitoring

Float charging

Fault DescriptionIn an office, the UA5000 used the PSM-B9+4860 power and four sets of batteries (12 V and100 A) in serial connection. The customer reported that the MCB often tripped after the powersupply of the telecommunications room was cut off and resumed again. The current insuranceof the MCB was AC 15 A.



l The load of the device was too heavy, causing severe power consumption.l The charging parameters of the battery were not set properly, causing excessively high

charging current of the battery.l The PSM monitoring module was faulty, causing the failure to control the charging current

of the battery.l The battery was faulty, causing excessively high charging current of the battery.l The power shelf was faulty, causing the failure to control the charging current of the battery.

Procedure

Step 1 The shelf was checked on site. It was found that only a half shelf was configured with services,and that no other power-consuming device was connected to PSM-B9+4860, indicating that thefault was not caused by excessively heavy power load on the device.

Step 2 The charging current of the battery was checked on site. It was found that the charging currentreached 50 A, revealing an obvious suspect of the fault case, namely, the excessively highcharging current. After the PSM monitoring module was checked, it was found that themonitoring module was in the normal state.

Step 3 The UA5000 was logged in and the environment monitoring condition was checked. It was foundthat the charging coefficient was set to the correct value 0.1. If the charging coefficient is set to0.1, the charging current of the battery should not be greater than 10 A. The specific results areas follows:

When the capacity of the battery set is 100 AH and the charging coefficient is configured to 0.1,the charging current should not be greater than 10 A in theory.



617

huawei(config-if-power4845-0)#display power { system<K>|environment<K>|run<K>|alarm<K>|battery-test<K> }:system { parameter<K> }:parameter Command: display power system parameter EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Even-float charging conversion control status: auto control Even charging voltage : 56.500 V Float charging voltage: 53.500 V Charging current restriction point coefficient: 0.100 Timed even charging duration: 60 days Battery count: 1 Battery 0 capacity: 100 A Upper test temperature threshold of the battery: 60°C Lower test temperature threshold of the battery: -40°C Temperature compensation coefficient: 100 mV Load power-off permit state: permitted Load power-off permit voltage: 43.500 V Battery power-off permit state: permitted Battery power-off permit voltage: 43,000 V Current divider parameters: 100 A AC over-voltage alarm threshold: 280 V AC under-voltage alarm threshold: 180 V DC over-voltage alarm threshold: 58 V DC under-voltage alarm threshold: 45 V Number of power units: 3 Address of power unit 0: 1 Control state of the switch machine of power unit 0: open Address of power unit 1: 2 Control state of the switch machine of power unit 1: open Address of power unit 2: 3 Control state of the switch machine of power unit 2: open Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (ºC) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50 ----------------------------------------------------------------------------

When the charging current is abnormal, the displayed charging status is float charging, and thecurrent of battery set 0 is 54.841 A.

huawei(config-if-power4845-0)#display power run info EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Current restriction state: not restricted Even-float charging conversion control status: auto control Charging state: float charging Load power-off permit state: permitted Load power-off permit state: permitted Number of power units: 3 Address of power unit 0: 1 Type of power unit 0: 2 Address of power unit 1: 2 Type of power unit 1: 2 Address of power unit 2: 3 Type of power unit 2: 2 Total line bank voltage: 53.090 AC voltage (V): 199.116 Total current of the unit (A): 61.232 Current of battery 0 (A): 54.841 Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (°C) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50



618

Remaining capacity of the battery: 100 % ----------------------------------------------------------------------------

When the charging current is normal, the displayed charging status is float charging, and thecurrent of battery set 0 is 0.151 A.

CH_Sima_UA5000(config-if-power4845-0)#display power run info EMU ID: 0 Power system configuration information ---------------------------------------------------------------------------- Current restriction state: not restricted Even-float charging conversion control status: auto control Charging state: float charging Load power-off permit state: permitted Load power-off permit state: permitted Number of power units: 3 Address of power unit 0: 1 Type of power unit 0: 2 Address of power unit 1: 2 Type of power unit 1: 2 Address of power unit 2: 3 Type of power unit 2: 2 Total line bank voltage: 53.763 AC voltage (V): 225.553 Total current of the unit (A): 6.432 Current of battery 0 (A): 0.151 Load high-temperature power-off permit state: permitted Load high-temperature power-off temperature (°C) : 65 Battery high-temperature power-off permit state: permitted Battery high-temperature power-off temperature (°C) : 50 Remaining capacity of the battery: 100 % ----------------------------------------------------------------------------

Step 4 After the PSM monitoring module was replaced, the fault persisted.

Step 5 It was hypothesized that the battery was faulty so that current restriction failed on the PSMmodule. After the battery was replaced, however, it was found that the fault persisted.

Step 6 After the power shelf was replaced, the test showed that the charging current of the battery was8.9 A, indicating that the fault was rectified.

----End

Suggestions and SummaryThe current restriction on the UA5000 is detected by the PSM monitoring module and the controlparameters are issued by this module. However, the working circuit that actually controls thecharging current is on the power shelf. Therefore, when the power shelf is faulty, the monitoringmodule may still fail to control the charging current even though the current restrictionparameters of the monitoring module are configured correctly, as the fault described in this case.



Fault TypeOther




619


Battery loop broken

Integrated device





Procedure

Step 1 Given that the "Battery off Alarm" was generated before the "Battery Loop Broken Alarm", thefirst step was to check whether the power-off was caused by low battery voltage. After the mainspower supply was cut off, it was found that the mains power cutoff alarm was reported normally.In this case, however, the fact was that no mains power cutoff alarm was reported before the"Battery off Alarm", indicating that the mains power supply was not cut off. Therefore, it wasdetermined that the battery set did not discharge, indicating that the fault was not caused by lowbattery voltage.

Step 2 The display power run info command was executed to check the battery configuration of thedevice. It was found that the "battery power-off permit state" parameter was set to "permitted".After the alarm logs are checked, it was found that all the alarms were generated at about 11:00AM or 12:00 AM, and that the alarms were cleared at night or before daybreak. Given that ahigh-temperature alarm was generated before the battery power-off, it was hypothesized that thefault was caused by high temperature. The result of executing the display power run infocommand was as follows:huawei(config-if-power4845-0)#display power run infoEMU ID: 0Running information about the power system----------------------------------------------------------------------------Current restriction state: not restrictedEven-float charging conversion control status: auto control Charging state: float chargingLoad power-off permit state: permittedBattery power-off permit state: permittedNumber of power units: 2Address of power unit 0: 1Type of the power unit 0: 2Address of power unit 1: 2Type of the power unit 1: 2Address of power unit 2: not configuredType of power unit 2: not configured



620

Total line bank voltage: 53.174AC voltage (V): 232.812Total current of the power unit (A): 13.074Current of battery group 0 (A): 0.373Load high-temperature power-off permit state: permittedLoad high-temperature power-off temperature(¡æ): 65Battery high-temperature power-off permit state: permittedBattery high-temperature power-off temperature(¡æ): 50Remaining capacity of the battery: 100 %---------------------------------------------------------------------------huawei(config-if-power4845-0)#display power environment info EMU ID: 0Analog Parameter Information---------------------------------Battery group temperature: 29.413¡æAmbient temperature: 25.817¡æAmbient humidity: 24.444%R.H(If you do not connect the EMU with any of the previous three sensors, the previous values are the default and the upper/lower alarm thresholds are invalid.)Analog parameter ID Name Current value Unit 2 Current on the current restriction point 20.500 A 3 Output voltage of monitoring control module 53.140 V ----------------------------------------------------------------------------



Step 5 The heat exchanger was powered off and the cover on the external circulation fan of the heatexchanger was removed. It was found that a lot of dust blocked the areas below the cooling fins,affecting the external circulation to a great extent. After the dust was cleaned, the devicetemperature returned to a normal value and no battery power-off alarm was generated on thedevice any more.

----End


It is necessary to maintain and clean the heat exchanger regularly, to prevent the battery power-off because of the high temperature inside of the cabinet.

TC-A0189 Absence of Ringing Tone Due to Burn-Out of the Connector on thePower Interface Board in HABD Shelf in F01D500 Cabinet

This case describes the troubleshooting of the absence of ringing tone for uses of a UA5000 dueto the burn-out of the connector on the power interface board in the HABD shelf in F01D500cabinet.

Fault Type

Other




621

Keywords

Subtending

Power board

Fault Description

l The ringing tone was not played for all the users connected to the HABD shelf of theUA5000, but the users could make or answer phone calls normally.

l The indicators on the secondary power board were abnormal, that was, the VIN (RUN)indicator was on, the VA0 indicator was off, the VB0 indicator was on, the VC0 indicatorwas on, and the FAIL indicator blinked.

Alarm Information

None

Cause Analysis


From the symptom that the absence of ringing tone occurred on all the users connected to theHABD shelf whereas the conversation by phone could still be successful, it could be determinedthat the ringing current provided by the power board was abnormal. In addition, the symptomthat the VAO indicator on the power board also showed that the ringing current on the powerboard was abnormal.

Procedure

Step 1 After the secondary power board was replaced, it was found that the fault persisted and that theindicators on the power board were still abnormal.

Step 2 During the process of replacing the secondary power board, a sign of circuit burn-out was foundon the power interface board in the most left part of the shelf. The power interface board providesthe following connectors:

l PWRIO-48V, which connects to the output port of the -48 V DC power.

l PWRIO+5V, which connects to the +5V power port on the HABF shelf of the UA5000 byusing an inter-shelf +5 V power cable.

l PWRIO-5V/RNG, which connects to the -5V/ringing current power port on the HABF shelfof the UA5000 by using an inter-shelf -5V/ringing current power cable.

Step 3 The shelf was powered off and the cable connected to the PWRIO-5V/RNG port wasdisconnected on the rear side of the power interface board. Then, the device was powered onagain. It was found that the indicators on the secondary power board returned to normal stateand that the ringing tones could be played normally for users.

NOTE

The disconnection of the subtending cable to the PWRIO-5V/RNG port did not affect the service becausethe extended shelf of the UA5000 was not configured with the service.

----End



622


Similar power problems often occur on outdoor cabinets of the UA5000 in a thunderstormweather. To troubleshoot such problems, it is necessary to master the skills of cabling andconnecting of the power cable.

TC-A0197 Service Interruption After Upgrade of the UA5000 Under MA5680 Dueto the Mismatch Between the EP1A and IPMD Versions

This case describes the troubleshooting of the service interruption after the upgrade of a UA5000under MA5680 due to the mismatch between the EP1A and IPMD versions.

Fault Type

Other


Keywords

Cutover

Re-load

Fault Description

Network topology: UA5000 -> OLT (MA5680T), the software version of MA5680T wasMA5680T V800R105C33B050.

A UA5000 version upgrade plan required that the UA5000IPM V100R017C02B091 beupgraded to UA5000IPM V100R017C02B111 and the UA5000PVM V100R017C02B091 beupgraded to UA5000PVM V100R017C02B109. After the upgrade of H601IPMD, it was foundthat the status of the ONT (UA5000) displayed on the MA5680T was normal, but the serviceson the UA5000 failed.

Alarm Informationl No alarm existed on the MA5680T.

l The system prompted that port 0 on the IPMD board was offline on the UA5000.

Cause Analysis


l The IPMD boards were faulty.

l The IPMD version did not match the EP1A version or the negotiation between the IPMDand EP1A failed.

l The backplane communication buses of the IPMD and EP1A boards were faulty.



623

Procedure

Step 1 The indicators on each board of the UA5000 were checked. It was found that the indicators werenormal, indicating that the board hardware was normal. In addition, the version information anddata configuration of the UA5000 were checked and found to be correct.

Step 2 The IPMD and EP1A boards were checked. It was found that EP1A board was connected to theMA5680T properly.

Step 3 The status of EP1A board was checked. It was found that the EP1A worked in the normal state.huawei(config)#display board 0/6--------------------------------------------------------Board Name: H601EP1ABoard State: NormalOnline State:-OnlineBoard has ports: 20 port type:-EPON_PORT1 port type:GE_PORT

Step 4 After the negotiation status of the IPMD port was changed from the compulsory 100 M modeto the negotiation mode, the fault was rectified. By default, the negotiation mode of EP1A in theV100R017C02B091 version was compulsory 100 M. The service failed when the EP1A boardwas reset to restore the default parameters. The status of the board was checked as follows:huawei(config)#display version 0/6Send message for inquiring board version successfully, board executing...BoardName:H601EP1ABIOSVersion:100SoftwareVersion:103LogicVersion:102

The V100R017C02B109 package file was checked. It was found that the software version ofthe EP1A board in V100R017C02B109 package file was 109.

Step 5 The software of the EP1A board was re-loaded through the MA5680T and the problem wassolved.

----End

Suggestions and SummaryThe IPM control board and the EP1A board must match each other. Note that you must firstupgrade the IPM control board and then upgrade the EP1A board.

TC-A0207 Rotation Stop on the External Circulation Fans of the Heat Exchanger ona D500 Due to -48 V Power Supply Input Failure

This case describes the troubleshooting of the rotation stop on the external circulation fans ofthe heat exchanger on the d500 due to -48 v power supply input failure.

Fault TypeOther


KeywordsFan fault



624

Heat exchanger

Fault Descriptionl The temperature inside the D500 outdoor cabinet on a site was very high. Fans inside the

cabinet (inner cycle system) rotated normally, however, the lower fans (external cyclesystem) did not rotate.

l The indicators (including the power indicator and the alarm indicator) on the front panelof the heat exchanger were on.

NOTE

The heat exchanger consists of internal cycle fan, external cycle fan, heat exchange plates, and monitoringbox. The working voltage of the fan was 220 V AC and the working voltage of the monitoring board was-48 V DC.



l The AC power supply was abnormal.l The monitoring board was faulty or worked abnormally.l A fan was faulty.

Procedure

Step 1 The AC voltage in the site was measured. It was found that the voltage was normal (230 V).

Step 2 The DC power supply system of the heat exchanger was checked. It was found that the miniaturecircuit breaker (MCB) was disconnected. Then, the MCB was connected. The alarm LED wasoff and the lower fans did not rotate.

Step 3 Several minutes later, the lower fans began to rotate and then worked normally.NOTE

The fan system was controlled by the temperature by default, and the fans began to rotate for several minutesafter the MCB was connected.

----End

Suggestions and Summaryl Whether the lower fans work normally is not only related to the 220 VAC power system

but also related to the normal running of the monitoring board.l You can query the power alarm "Load fuse 0" status (connect, disconnect) of Power4845

on site to determine whether the heat exchanger works in the normal state. See the followingexample:huawei(config-if-power4845-0)#display power alarm EMU ID: 0 Power alarm information ---------------------------------------------------------------------------- Mains supply yes : Yes Mains supply lack : Normal Total Vol lack : Normal Load fuse 0 : Connect Second fuse : Connect



625

Load off : On Battery off : On Battery 0 loop : Connect Environment Temperature : Normal Environment Humidity : Normal Door alarm : Normal Water alarm : Normal Fog alarm : Normal Wiring alarm : Normal Module 0 : Normal Module 1 : Normal Module 2 : Normal Battery temperature off state : Normal Load temperature off state : Normal ---------------------------------------------------------------------------- Name State |Name State Spare Dig0 Alarm |Spare Dig1 Alarm Spare Dig2 Alarm |Spare Dig3 Alarm Spare Dig4 Normal|Spare Dig5 Alarm Spare Dig6(rejiaohuanqi) Normal --------------------------------------------------------------------------

TC-A0245 ETH Port Failure Due to H601PVMD Board Not Configured withOutband Network Management IP Address

This case describes how to troubleshoot the ETH port that cannot work normally because theH601PVMD board is not configured with the outband network management IP address.

Fault Type

Other

Board fault

Keywords

Outband maintenance

ETH outband

Fault Description

The UA5000 on a site uses the H601PVMD board for upstream transmission in integrated mode.When the PVMD version is upgraded on site, it is found that the LINK indicator of the ETHport is off after the ETH port is connected to the PC through a network cable. As a result, filescannot be transmitted in TFTP mode.

Alarm Information


Cause Analysis



l The PC is connected to an incorrect port.

l The software configuration is incorrect.

l The port hardware is faulty.



626

Procedure

Step 1 Replace the network cable. It is found that the LINK indicator of the ETH port is off regardlessof using the crossover or straight-through network cable.

Step 2 Run the display working mode command to check for the data configuration. It is found thatthe data configuration is correct and that the ETH port is used for outband maintenance.huawei#display working mode working mode:integrated outband port:ETH port service port:Inner port

Step 3 Run the display ip address command to check whether the ETH port is configured with anoutband network management IP address. It is found that the ETH port is not configured withsuch an IP address.huawei(interface-outband)#display ip address Failure: This IP record does not exist

Step 4 Run the #GUIDA5AF2EAF-284B-4C7F-8852-816DC7A1C893_3 command to configure anoutband network management IP address for the ETH port. It is found that the ETH port worksnormally and the LINK indicator of the port is on. This indicates that the fault is rectified.

----End

Suggestions and SummaryWhen the outband network management mode is used to manage the UA5000 (PVM), the devicemust be configured with an outband network management IP address, and then the outbandnetwork port can be activated successfully (the LINK indicator turns on after the port isconnected to a PC through a network cable).

TC-A0246 Repeated System Reset After UA5000 PVM Is Upgraded from V1R13 toV1R17 Due to Incorrect Loaded File

This case describes how to troubleshoot the system that is reset repeatedly after the UA5000PVM is upgraded from V1R13 to V1R17. The fault is caused by the loading of incorrect files.

Fault TypeOther


KeywordsEFS file

File size

Fault DescriptionOriginal version: PVM V100R013B02D098 Target version: PVMV100R017C02B109

Fault symptom: After the system is upgraded and then reset, the command line interface cannotbe accessed, and the system is reset repeatedly. During the reset, the system displays thefollowing error information:



627

"Load 2nd Image to Calisto(0) in 55 TICKS OK! Load 2nd Image to Calisto(1) Error : 0xd108 Announcement: Line[2469] Frag[8] Len = 1415865856 Err! Announcement: Line[2469] Frag[9] Len = 1985242214 Err! Announcement: Line[2 System start ... "


Cause AnalysisThe possible causes are as follows:l The BIOS, CPLD, and FPGA files are loaded incorrectly.l The EFS file is loaded incorrectly.

ProcedureStep 1 Run the display io-packetfile information command to check whether the target BIOS, CPLD,

and FPGA files for the loading are correct. Then, reload these files. It is found that the faultpersists.

Step 2 Run the display io-packetfile information command to check for the size of the host programapplication file rom_pvm.efs. It is found that the size is different from the size of the sourcefile, indicating that the loaded rom_pvm.efs file may be incorrect. Then, load the correctrom_pvm.efs file. It is found that the fault is rectified.

----End

Suggestions and SummaryDuring the upgrade, check and ensure that the TFTP server communicates with the UA5000normally and that the file loading is not interrupted, so that the information in the transmittedfile is not lost.

TC-A0250 Subscriber Line Test Failures on Subtending Subrack Ports Due toIncorrect Configuration

This case describes how to troubleshoot subscriber line test failures on user ports in aUA5000′s subtending subrack due to an incorrect system configuration.


Other

KeywordTSS board

Fault DescriptionThe UA5000 is equipped with a master subrack and a subtending subrack. A TSS board isconfigured in the master subrack but is not configured in the subtending subrack. When a



628

subscriber line test is performed on the user ports in the subtending subrack, the system displaysa message indicating that the test board cannot be found.


Cause Analysisl The data configuration of the TSS board is incorrect.l The test group configuration of the system is incorrect.

Procedure

Step 1 Perform a subscriber line test on a user port in the master subrack. The test is successful,indicating that the data configuration of the TSS board is correct.

Step 2 Run the display testgroup command in test mode to query the test group configured for themaster subrack, and run the display frame info command in global config mode to query thetest group configured for the subtending subrack. It is found that the master subrack andsubtending subrack are configured in two different test groups.

Step 3 Run the frame set command to add the subtending subrack into the master subrack′s test group,and then perform a subscriber line test on a user port in the subtending subrack. It is found thatthe fault is rectified.

----End

Suggestion and SummaryWhen the UA5000 is equipped with a subtending subrack, the master subrack and the subtendingsubrack use the same test bus and, therefore, the same TSS board. It is not necessary to configureanother TSS board for the subtending subrack, but the two subracks must be configured in thesame test group.

TC-A0253 Abnormal Output Voltage of the Rectifier Module Caused by IncorrectPower Protocol File

This case describes how to troubleshoot the abnormal output voltage of a UA5000 rectifiermodule caused by an incorrect power protocol file loaded on the UA5000.

Fault TypeEnvironment monitoring fault

Other

KeywordsEMU


Power



629

Monitoring module

Fault DescriptionThe output voltage of the power rectifier module on a UA5000 is 62144955547648.000 V.


Cause Analysisl The power monitoring module is faulty.l The system processes data incorrectly.l The power protocol file loaded on the device is incorrect.

Procedure

Step 1 Replace the power monitoring module on the device with another one. It is found that the faultpersists, indicating that the power monitoring module is functional.

Step 2 Given that the fault did not occur on the UA5000s loaded with the same system software onother sites, perform an active/standby switchover on the affected UA5000. It is found that thefault persists, indicating that the fault is not caused by a data processing problem on the UA5000.

Step 3 Run the display esc power run info command to check the power protocol file loaded on theUA5000. It is found that the loaded file is incorrect.

Step 4 Run the load universal-power-protocol command to load the correct power protocol file onthe UA5000, and then perform another test. It is found that the fault is rectified.

----End

Suggestion and SummaryWhen the output voltage of the power rectifier module is abnormal, check whether the powerprotocol file loaded on the device is correct.

TC-A0257 Service Failure Due to Incorrectly Configured IPMD Board'sCommunication Ports on the Backplane

This case describes how to troubleshoot service failures caused when the UA5000 transmits dataupstream through a gigabit passive optical network (GPON) port and the communication portsof the IPMD board on the backplane are not configured properly.


Other

KeywordsGP1A



630

GPON

GE optical port

Fault DescriptionNetwork topology: UA5000 -> optical line terminal (OLT)

Fault symptom: A UA5000 is configured to transmit data upstream through a GPON port. Onceconfigured, however, the UA5000 services fail.


Cause Analysisl The status of the GP1A board on the UA5000 is abnormal.l The data configured on the OLT to add optical network units (ONUs) is incorrect.l The working modes of the IPMD board's communication ports on the backplane are set

incorrectly.

Procedure

Step 1 Run the display board 0 command to check the status of the GP1A board. It is found that theboard is in the normal state.

Step 2 Run the display ont info command on the OLT to check the status of the UA5000. It is foundthat the UA5000 has successfully registered with the OLT, with Control Flag set to active andRun State set to online. This indicates that the data configured on the OLT to add ONUs iscorrect.

Step 3 Create management VLAN 100 on the OLT and the UA5000, and configure IP addresses thatare in the same network segment for the created VLAN. Then, ping the OLT from the UA5000to check whether the Layer 3 interface between the IPMD board and the OLT is operational. Itis found that the interface is not operational.

Step 4 Given that the communication ports of the IPMD board on the backplane must be in the GE-Optical working mode to communicate with the GP1A board, run the display port statecommand to check the working modes of the IPMD board's communication ports on thebackplane. It is found that the working modes are not GE-Optical.

Step 5 Run the mode 0 GE-Optical command to change the working modes of the IPMD board'scommunication ports on the backplane to GE-Optical. It is found that the fault is rectified.

----End

Suggestion and Summaryl The IPMD board, a control board of the UA5000, communicates with the GP1A board, a

GPON interface board, through two communication ports on the backplane, and theworking modes of the ports must be set to GE-Optical.

l To communicate with the EP1A interface board, the IPMD board's communication portson the backplane must also be set to the GE-Optical working mode.



631

TC-A0258 Failures of A32 Board and GE Port on IPMD Board Due to PSTF BoardFaults

This case describes how to troubleshoot the failures of the A32 board and GE port on the IPMDboard of a UA5000, which are caused by faults in the PSTF board.


Other

KeywordsLINK indicator off

RUN indicator on

Fault DescriptionThe UA5000 on a site is configured to transmit data in integrated mode. After the data isconfigured, the LINK indicator of the GE optical port on the IPMD board is off after an opticalfiber is connected to the port. In addition, the RUN indicator on the A32 board is continuouslyon, representing an A32 board fault.


Cause Analysisl The working modes of the IPMD board's communication ports on the backplane are set

incorrectly.l The optical module is faulty.l The working modes of the interconnection ports set on the UA5000 and the peer device

are different.l The transmit and receive fibers are connected out of sequence.l The PSTF board is not in proper contact with the backplane.l The PSTF board is faulty.

Procedure

Step 1 Run the display port state command to check the working modes of the IPMD board'scommunication ports on the backplane. It is found that both the ports are in the correct workingmode, GE-Optical.

Step 2 Run the display port opticstate command to check the optical module for about the IPMDboard. The system displays the "Optics/electric module status is normal" message, indicatingthat the optical module is normal.

Step 3 Check the working modes of the interconnection ports on the UA5000 and the peer device. It isfound that the working modes are the same.



632

Step 4 Check the connection sequence of the transmit and receive fibers. It is found that the transmitand receive fibers are connected correctly, indicating that the fault is not associated with theoptical fiber connection.

Step 5 Given that the running indicators on the IPMD and PVMD boards are green and they are on forone second and off for one second, the subrack housing the two boards is receiving power. TheRUN indicator on the A32 board, however, is continuously on, indicating that the -48 V powersource of the device may be disconnected. Remove the PSTF board and re-insert it. It is foundthat the fault persists.

Step 6 Replace the PSTF board with another. It is found that the RUN indicator on the A32 board runsproperly and that the LINK indicator of the GE optical port on the IPMD board is continuouslyon, indicating that the fault is rectified.

----End

Suggestion and Summaryl The PSTF board is a front-access power transfer board used to provide -48 V power for the

system. When the -48 V power supply for a subrack cannot be detected, replacing the PSTFboard may address the problem.

l Failures of the -48 V power supply may cause faults on some modules in the system. Whenthe IPMD board of a UA5000 is not working properly, replacing the PSTF board mayaddress the problem.

l The A32 board uses -48 V power for operation. If the RUN indicator on the A32 board iscontinuously on, replacing the PSTF board may address the problem.

TC-A0264 Circuit and Subscriber Line Test Failures on the CSRB Board Due toHWCB Board Faults

This case describes how to troubleshoot the circuit and subscriber line test failures on the CSRBboard due to HWCB board faults.

Fault Type

Service abnormality

Narrowband service

Keywords

No ringing tone for the called party

Fault Description

The UA5000 is configured with HABA rear-access subracks, PVMB control boards, and CSRBand A32 service boards. A circuit or subscriber line test performed on a CSRB board failswhereas the test on an A32 board is successful.

Alarm Information




633

Cause Analysisl No RATB board is configured.l The CSRB board is faulty.l The RATB board is faulty.l The HWCB board is faulty.

Procedure

Step 1 Check board configurations. It is found that the RATB board has been configured correctly.

Step 2 Perform a circuit or subscriber line test on the CSRB boards in other slots in the HABA subrack.The test fails. This temporarily indicates that the CSRB boards are normal. The RATB boardsin an entire subrack generally are not faulty at the same time. Therefore, the RATB boards aretemporarily considered normal.

Step 3 Replace the HWCB board and perform a test. It is found that the fault is rectified.

----End

Suggestions and Summaryl If the circuit and subscriber line tests on the A32 boards in the same subrack are successful,

the TSSB board, test bus, and test group are normal.l When the circuit or subscriber line test on the A32 boards in the same subrack is successful

whereas the test on the CSRB boards fails, replace the transfer board to check whether thefault can be rectified.

l A32 boards support the line capturing function whereas CSRB boards do not support sucha function. Therefore, an RATB transfer board, is powered by a HWCB transfer board, isrequired to support the function.

TC-A0268 UA5000 Service Failure Due to Saving Data Failure After the ONU ofCompany B Is Power Cycled

This case describes how to troubleshoot the UA5000 service failure due to the failure in correctlysaving data after the optical network unit (ONU) of another company (company B as an example)is power cycled.

Fault TypeService interruption

Others

KeywordsConnection

Mains off

Fault DescriptionNetwork topology: UA5000 -> ONU of company B -> OLT of company B



634

The UA5000 on a site is configured to transmit data in an integrated mode. The UA5000 andthe ONU of company B are powered off because the mains supply in the equipment room is cutoff. The UA5000 services are interrupted after the UA5000 and the ONU are powered on again.

Alarm Information


Cause Analysisl The hardware of the control boards on the UA5000 is faulty.

l The UA5000 data is lost.

l The connection between the UA5000 and the ONU is abnormal.

l The connection between the ONU and the OLT is abnormal.

Procedure

Step 1 Check the indicators on the control board panels of the UA5000 and run the display boardcommand to query the status of the control boards. It is found that the control boards are runningproperly.

Step 2 Check the UA5000 software. It is found that the software version is normal and no data is lost.

Step 3 Check the ONU on the OLT. It is found that the ONU is normal, indicating that the connectionbetween the OLT and the ONU is normal.

Step 4 Check on the ONU whether the ONU has learned three MAC addresses of the UA5000, namely,the MAC address of the uplink port on the IPMB board, the MAC address of the outband networkport on the PVMB board, and the MAC address of the network port.

Step 5 Connect the UA5000 to another port on the ONU. It is found that the fault persists.

Step 6 Check the transmission mode of the port on the ONU. The mode is transparent. The mode ofthe port connected to the UA5000 is changed to non-transparent and then transparent. It is foundthat the UA5000 services are restored, indicating that the fault is rectified.

----End


The ONU of company B cannot correctly save data after being power cycled, so that the datadoes not take effect though the system displays that the data has been saved. The data can takeeffect after being modified.

16.3 By Alarm

16.3.1 ALM-0x02310000 Board Fault AlarmThis topic provides the analysis of the cases related to the board fault alarm.



635




Board fault

Board fault alarm








Procedure





Step 5 Compare the delivery list of this time with the previous delivery list. It is found that the HABAshelf is not configured with an HWCB board, which is used to subtend the slave shelf. This



636

office, however, does not use the slave shelf. Therefore, the carrier did not purchase the HWCBboard. Use an HWCB board from another office and insert it into the shelf of this office. Then,the service boards in slots 18 to 35 are in the normal state and the fault is rectified.

----End




Fault TypeOther

Board fault

Board fault alarm


LED RUN

Fails to work

PVMB




l The hardware of the service board is faulty.l The NE software and board software do not match.l The ± 5 V power supply for the narrowband service board is abnormal.l The 48 V power supply is abnormal.



637

l The control board or the backplane is faulty.

Procedure







----End


None

16.3.2 ALM-0x0a300013 Line-caused ADSL Port Auto DeactivationThis topic provides the analysis of the case related to the Line-caused ADSL Port AutoDeactivation alarm.



Fault Type

Ethernet service

Service exception

Keywords

Malware attack

PPPoE dialup



638

Fault DescriptionNetwork topology: UA5000 -> MA5680T -> BRAS





ProcedureStep 1 The offline records on the BRAS were checked. It was found that the users went offline at the

same time. According to the generated alarms, it was hypothesized that the PPPoE dialup offlinewas caused by interference on subscriber lines. Given that a new GSM base station wasestablished about 50 m away from the UA5000, the radio signal interference was a preliminarilysuspect of causing the fault.





Step 6 The ADSL user was advised to disconnect the PPPoE connection and then dial up again. It wasfound that upstream data traffic of the user was three times the downstream data traffic, wheneverno Internet page was open or download software was used. The traffic information about theADSL port on the UA5000 was checked. A large number of abnormal upstream data wasdetected.huawei(config)#display traffic 0/11/2{ <cr>|channel<K> }:



639

Command: display traffic 0/11/2 Querying, please wait... -------------------------------------------------------------- Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps) -------------------------------------------------------------- 0/11/2 183.2 61.0 --------------------------------------------------------------


----End




16.3.3 ALM-0x0a300052 ADSL Port Link LossThis topic provides the analysis of the case related to the ADSL Port Link Loss alarm.



Fault Type

Ethernet service

Service exception

Keywords

Malware attack

PPPoE dialup

Fault Description

Network topology: UA5000 -> MA5680T -> BRAS



640





Procedure






Step 6 The ADSL user was advised to disconnect the PPPoE connection and then dial up again. It wasfound that upstream data traffic of the user was three times the downstream data traffic, wheneverno Internet page was open or download software was used. The traffic information about theADSL port on the UA5000 was checked. A large number of abnormal upstream data wasdetected.huawei(config)#display traffic 0/11/2{ <cr>|channel<K> }: Command: display traffic 0/11/2 Querying, please wait... --------------------------------------------------------------



641

Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps) -------------------------------------------------------------- 0/11/2 183.2 61.0 --------------------------------------------------------------


----End




16.3.4 ALM-0x0e210000 CPU Occupancy Exceeds the ThresholdThis topic provides the analysis of the case related to the CPU Occupancy Exceeds the Thresholdalarm.

TC-A0171 High CPU Usage on a UA5000 Due to a Subscriber Line Fault

This case describes the troubleshooting of a UA5000 on which the CPU usage was high due toa subscriber line fault.

Fault Type

Narrowband service

Service exception

Keywords

Excessive signaling


Fault Description





642

Alarm Information


Cause Analysis


Procedure









----End


None

16.3.5 ALM-0x12100001 DSP Resources Insufficient AlarmThis topic provides the analysis of the case related to the DSP resources insufficient alarm.

16.3.6 ALM-0x15411000 EMU Fault AlarmThis topic provides the analysis of the case related to the EMU Fault alarm.



643

TC-A0183 POWER4845 EMU Fault Due to the HWCF Board

This case describes the troubleshooting of the POWER4845 environment monitoring unit(EMU) that was faulty due to an HWCF board fault.

Fault Type

Other


Keyword

EMU

Fault Description

A UA5000 that used POWER4845 EMU reported an EMU fault.

Alarm Information

The "EMU Fault Alarm" was displayed on the HyperTerminal.

Cause Analysis



Procedure





----End



644


16.3.7 ALM-0x15411010 Battery Off AlarmThis topic provides the analysis of the case related to the Battery Off alarm.



Fault TypeOther



Battery loop broken

Integrated device





Procedure

Step 1 Given that the "Battery off Alarm" was generated before the "Battery Loop Broken Alarm", thefirst step was to check whether the power-off was caused by low battery voltage. After the mainspower supply was cut off, it was found that the mains power cutoff alarm was reported normally.In this case, however, the fact was that no mains power cutoff alarm was reported before the"Battery off Alarm", indicating that the mains power supply was not cut off. Therefore, it was



645

determined that the battery set did not discharge, indicating that the fault was not caused by lowbattery voltage.

Step 2 The display power run info command was executed to check the battery configuration of thedevice. It was found that the "battery power-off permit state" parameter was set to "permitted".After the alarm logs are checked, it was found that all the alarms were generated at about 11:00AM or 12:00 AM, and that the alarms were cleared at night or before daybreak. Given that ahigh-temperature alarm was generated before the battery power-off, it was hypothesized that thefault was caused by high temperature. The result of executing the display power run infocommand was as follows:huawei(config-if-power4845-0)#display power run infoEMU ID: 0Running information about the power system----------------------------------------------------------------------------Current restriction state: not restrictedEven-float charging conversion control status: auto control Charging state: float chargingLoad power-off permit state: permittedBattery power-off permit state: permittedNumber of power units: 2Address of power unit 0: 1Type of the power unit 0: 2Address of power unit 1: 2Type of the power unit 1: 2Address of power unit 2: not configuredType of power unit 2: not configuredTotal line bank voltage: 53.174AC voltage (V): 232.812Total current of the power unit (A): 13.074Current of battery group 0 (A): 0.373Load high-temperature power-off permit state: permittedLoad high-temperature power-off temperature(¡æ): 65Battery high-temperature power-off permit state: permittedBattery high-temperature power-off temperature(¡æ): 50Remaining capacity of the battery: 100 %---------------------------------------------------------------------------huawei(config-if-power4845-0)#display power environment info EMU ID: 0Analog Parameter Information---------------------------------Battery group temperature: 29.413¡æAmbient temperature: 25.817¡æAmbient humidity: 24.444%R.H(If you do not connect the EMU with any of the previous three sensors, the previous values are the default and the upper/lower alarm thresholds are invalid.)Analog parameter ID Name Current value Unit 2 Current on the current restriction point 20.500 A 3 Output voltage of monitoring control module 53.140 V ----------------------------------------------------------------------------



Step 5 The heat exchanger was powered off and the cover on the external circulation fan of the heatexchanger was removed. It was found that a lot of dust blocked the areas below the cooling fins,affecting the external circulation to a great extent. After the dust was cleaned, the device



646

temperature returned to a normal value and no battery power-off alarm was generated on thedevice any more.

----End

Suggestions and SummaryIt is necessary to maintain and clean the heat exchanger regularly, to prevent the battery power-off because of the high temperature inside of the cabinet.

16.3.8 ALM-0x0230001c Failed to Resume Configuration Data ofDevice Alarm

This topic provides the failure to Resume Configuration Data of Device alarm.



Fault TypeOther

Board fault

KeywordDatabase configuration file


Fault DescriptionDuring the deployment of an office, an IPMB board that was originally installed on the HABAshelf is inserted into the HABC shelf and the service is provided when the originally configureddata is not erased. Then, the service runs in the normal state but the system frequently generatesthe alarm indicating that the control board does not match the shelf.

Alarm InformationAn alarm, "Failure: Failed to resume configuration data of device", indicating that issuing theconfiguration data fails is displayed on the HyperTerminal.


Cause AnalysisThe information about the type of the mother board is saved in the database of the IPMB controlboard of the UA5000, and different data files are created for different types of mother boards.



647

When the new shelf is used, if you directly configure data for the shelf without running the eraseflash data command to erase the data about the original database, the system generates the alarmindicating that the control board does not match the shelf.

Procedure






----End





16.3.9 ALM-0x09200000 Different patch files in Active Board andStandby Board Alarm

This topic provides the different patch files in active board and standby board alarm.



648

A Acronyms and Abbreviations

A

AAL5 ATM adaptation layer type 5

ACL access control list

AG access gateway

ARP Address Resolution Protocol

ATM asynchronous transfer mode

ATU-R ADSL transceiver unit at the remote end

B

BITS building integrated timing supply system

BRAS broadband remote access server

C

CAR committed access rate

CATV cable TV

CPE customer premises equipment

CPU central processing unit

CRC cyclic redundancy check

D

DNS domain name server

DSL digital subscriber line

DSLAM digital subscriber line access multiplexer

UA5000 Universal Access UnitTroubleshooting A Acronyms and Abbreviations


649

DSP digital signal processor

DTE digital terminal equipment

E

EMS element management system

EMU environment monitor unit

ESC environment supervision circuit

ESD electrostatic discharge

F

FE fast Ethernet

FLP fast link pulse

FoIP fax over IP

FTP File Transfer Protocol

G

GE gigabit Ethernet

H

HW highway

I

IAD integrated access device

IMA inverse multiplexing over ATM

IGMP Internet Group Management Protocol

IP Internet Protocols

IPoA Internet Protocols Over ATM

ISDN integrated service digital network

ISO International Standard Organization

ISP Internet service provider

ITU-T International Telecommunication Union - TelecommunicationStandardization Sector



650

L

LAN local area network

LOF loss of frame

LOS loss of signal

M

MAC media access control

MDI medium dependent interface

MGC media gateway controller

N

NE network element

NGN next generation network

NSR non-status reporting

P

PDN public data network

PDU protocol data unit

POTS plain old telephone service

PSTN public switched telephone network

R

RADIUS remote authentication dial in user service

RFC requirement for comment

RFM routing forward module

RSA revest-shamir-adleman algorithm

RTU remote terminal unit

Rx receive

S

SDH synchronous digital hierarchy

SN service number



651

SNI subscriber network interface

SNR signal-to-noise ratio

STB set top box

T

TCP/IP Transmission Control Protocol/Internet Protocol

TDM time division multiplexing

TFTP Trivial File Transfer Protocol

TTL time to live

Tx transmit

V

VCI virtual channel identifier

VLAN virtual LAN

VOD video on demand

VoIP voice over IP

VPI virtual path identifier

VPDN virtual private dial network

VPN virtual private network



652

Documents

UA5000 Troubleshooting(V100R019C02 01)