Troubleshooting (V800R010C00 01)

SmartAX MA5600T/MA5603T Multi-service Access
Module
V800R010C00
Troubleshooting
Issue 01
Date 2011-10-24
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2011-10-24) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Module
Troubleshooting About This Document
About This Document
Intended Audience
This document describes how to troubleshoot common faults and deal with emergencies in
services and functions provided by the MA5600T/MA5603T. In addition, this document
provides typical cases and common operations for troubleshooting the faults.
Reading through this document helps you learn how to troubleshoot common faults and deal
with 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, report
the fault information to Huawei technical support engineers for further diagnosis and analysis
according to the methods provided in this document.
The intended audience of this document is:
l System maintenance engineers
l Field maintenance engineers
l Network monitoring engineers
Symbol Conventions
The 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 not

avoided, 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 not

avoided, could cause equipment damage, data loss, and
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save

your time.
Provides additional information to emphasize or

supplement important points of the main text.
Issue 01 (2011-10-24) Huawei Proprietary and Confidential ii

Module
Command Conventions
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in square brackets [ ] are

optional.
{ x | y | ... } Alternative items are grouped in braces and separated by

vertical bars. One is selected.
[ x | y | ... ] Optional alternative items are grouped in square brackets

and separated by vertical bars. One or none is selected.
{ x | y | ... } * Alternative items are grouped in braces and separated by

vertical bars. A minimum of one or a maximum of all can
be selected.
GUI Conventions
Convention Description
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

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

sign. For example, choose File > Create > Folder.
Update History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Updates in Issue 01 (2011-10-24)

This is the first release of V800R010C00. Compared with issue 01 (2011-07-15) of
V800R009C00, this issue has the following changes:
The following information is added:
l 2.3.4.8 Unexpected Communication Interruptions

l 6.2 Locating and Troubleshooting ONT Faults
The following information is modified:
l 2.2.1.3 Low Internet Access Rate
Issue 01 (2011-10-24) Huawei Proprietary and Confidential iii

Module
l 2.2.3.6 Failure to Dial Certain Phone Numbers

l 2.3.4.2 No Tone After Offhook
l 2.3.4.3 Busy Tone After Offhook
l 6.2.3 Detecting a Rouge ONT
Issue 01 (2011-10-24) Huawei Proprietary and Confidential iv

Module
Troubleshooting Contents
Contents
About This Document.....................................................................................................................ii

1 Maintenance Engineers' Must-Read..........................................................................................1
1.1 Skill Requirements.............................................................................................................................................2
1.2 Troubleshooting Precautions..............................................................................................................................2
1.3 Troubleshooting Procedure.................................................................................................................................3
1.4 Contacting Huawei for Assistance.....................................................................................................................5
1.5 Frequently Used Methods for Troubleshooting..................................................................................................5
1.5.1 Configuration Data Analysis.....................................................................................................................5
1.5.2 Alarm Analysis..........................................................................................................................................5
1.5.3 Comparison Analysis.................................................................................................................................6
1.5.4 Interchange Analysis.................................................................................................................................6
1.5.5 Exclusive Method......................................................................................................................................6
1.5.6 Protocol Analysis.......................................................................................................................................7
1.5.7 Meter Test..................................................................................................................................................7
1.5.8 Performance Analysis................................................................................................................................7
2 Troubleshooting the FTTx GPON Service...............................................................................9

2.1 GPON ONU Abnormal State...........................................................................................................................10
2.1.1 GPON ONU Registration Failure............................................................................................................10
2.1.1.1 Failure to Go Online of a GPON ONU..........................................................................................10
2.1.1.2 Failure to Recover GPON ONU Configurations............................................................................19
2.1.1.3 GPON ONU Profile Match state is Mismatch................................................................................24
2.1.2 Failure to Auto Discover a GPON ONU.................................................................................................26
2.1.3 GPON ONU Frequently Goes Online and Offline..................................................................................33
2.2 Troubleshooting the FTTH Service (OLT + HG Series ONT)........................................................................38
2.2.1 Troubleshooting the Internet Access Service..........................................................................................38
2.2.1.1 Internet Access Failure...................................................................................................................39
2.2.1.2 Internet Access Service Interruption..............................................................................................41
2.2.1.3 Low Internet Access Rate...............................................................................................................46
2.2.1.4 PPPoE Dialup Failure.....................................................................................................................50
2.2.1.5 Failure to Obtain an IP Address in the DHCP Mode.....................................................................57
2.2.2 IPTV Service Failure...............................................................................................................................64
2.2.2.1 Multicast User Fails to Go Online..................................................................................................64
Issue 01 (2011-10-24) Huawei Proprietary and Confidential v

Module
2.2.2.2 Blank Screen After a Program Is Ordered......................................................................................74

2.2.2.3 Pixelation in a Multicast Program..................................................................................................89
2.2.2.4 Abnormal Interruption of a Multicast Program..............................................................................94
2.2.2.5 Long Program Switching Time......................................................................................................99
2.2.3 Troubleshooting Voice Service Faults..................................................................................................101
2.2.3.1 No Tone After Offhook................................................................................................................102
2.2.3.2 Busy Tone After Offhook.............................................................................................................104
2.2.3.3 One-Way Audio in a Voice Call...................................................................................................107
2.2.3.4 Noise in a Voice Call....................................................................................................................108
2.2.3.5 Voice Interruptions in a Voice Call..............................................................................................111
2.2.3.6 Failure to Dial Certain Phone Numbers.......................................................................................113
2.3 Troubleshooting the FTTB and FTTC Service (OLT + MDU)......................................................................114
2.3.1 Troubleshooting the Internet Access Service (When the MDU Provides xDSL Access).....................114
2.3.1.1 Troubleshooting the Failure to Access the Internet......................................................................115
2.3.1.2 Troubleshooting Frequent Interruptions in Internet Service........................................................117
2.3.1.3 Troubleshooting Low Internet Access Rate.................................................................................120
2.3.1.4 Troubleshooting the Failure to Obtain an IP Address by PPPoE Dialup.....................................125
2.3.1.5 Troubleshooting the Failure to Obtain an IP Address in DHCP Mode........................................132
2.3.2 Troubleshooting the Internet Service Fault (MDU Service Access in LAN Mode).............................137
2.3.2.1 Troubleshooting the Failure to Access the Internet......................................................................138
2.3.2.2 Troubleshooting Frequent Interruptions in Internet Service........................................................140
2.3.2.3 Troubleshooting Low Internet Access Rate.................................................................................143
2.3.2.4 Troubleshooting the Failure to Obtain an IP Address by PPPoE Dialup.....................................147
2.3.2.5 Troubleshooting the Failure to Obtain an IP Address in DHCP Mode........................................155
2.3.3 IPTV Service Failure.............................................................................................................................161
2.3.3.1 Failure to Go Online of a Multicast User.....................................................................................161
2.3.3.2 Blank Screen After Ordering a Program......................................................................................171
2.3.3.3 Pixelation in a Multicast Program................................................................................................190
2.3.3.4 Abnormal Interruption of a Multicast Program............................................................................198
2.3.3.5 Long Time in Switching Programs...............................................................................................203
2.3.4 Troubleshooting the Voice Service.......................................................................................................204
2.3.4.1 No Power Feed After Offhook.....................................................................................................205
2.3.4.2 No Tone After Offhook................................................................................................................207
2.3.4.3 Busy Tone After Offhook.............................................................................................................210
2.3.4.4 One-Way Audio in Communication.............................................................................................214
2.3.4.5 Noise in Communication..............................................................................................................216
2.3.4.6 Poor Voice Service in Communication........................................................................................219
2.3.4.7 Failure to Dial Certain Phone Numbers.......................................................................................220
2.3.4.8 Unexpected Communication Interruptions...................................................................................221
2.3.5 FoIP Service Failures.............................................................................................................................223
2.3.6 MoIP Service Failures...........................................................................................................................225
3 Troubleshooting the xDSL Services......................................................................................228
Issue 01 (2011-10-24) Huawei Proprietary and Confidential vi

Module
3.1 Troubleshooting the Internet Access Service.................................................................................................229

3.1.1 Failure to Access the Internet After Successfully Obtaining an IP Address.........................................229
3.1.2 Low Internet Access Rate......................................................................................................................233
3.1.3 Frequent Offline in the Internet Access Service....................................................................................238
3.1.4 Failure to Obtain an IP Address in PPPoE Dialup................................................................................243
3.1.5 Failure to Obtain an IP Address in the DHCP Mode............................................................................247
3.1.6 Failure to Obtain the IP Address in PPPoA Dialup...............................................................................252
3.1.7 Failure to Obtain the IP Address in IPoA Dialup..................................................................................255
3.2 Troubleshooting the Multicast Service...........................................................................................................260
3.2.1 Failure to Go Online for a Multicast User.............................................................................................260
3.2.2 Dark Screen After Ordering a Program.................................................................................................263
3.2.3 Erratic Display (Mosaic) in a Multicast Program..................................................................................266
3.2.4 Abnormal Program Interruption in Watching a Multicast Program......................................................268
3.2.5 Long Time in Switching Programs........................................................................................................270
4 Troubleshooting the System...................................................................................................273

4.1 NMS Fails to Manage a Device......................................................................................................................274
4.2 Service Board Is in the Failed State................................................................................................................276
4.3 Service Board Resets Repeatedly...................................................................................................................277
4.4 Control Board Resets Caused by Abnormalities............................................................................................279
5 Emergency Handling................................................................................................................281
5.1 Precautions for Emergency Handling.............................................................................................................282
5.2 Troubleshooting Common Emergencies........................................................................................................282
5.2.1 Service Interruption Encountered by All the Users of a Single Device................................................282
5.2.2 Service Interruption Encountered by All the Users of Multiple Devices Under the Upper-Layer BRAS or
Router.............................................................................................................................................................284
5.2.3 Service Interruption Encountered by All the Users of All Devices Under the Upper-Layer BRAS or Router
........................................................................................................................................................................284
6 Commonly Used Methods of Fault Locating and Troubleshooting................................286

6.1 Methods of Locating and Troubleshooting Common ODN Faults................................................................288
6.1.1 Common ODN Faults............................................................................................................................288
6.1.2 ODN-Related Alarms............................................................................................................................296
6.1.3 Checking the Optical Power..................................................................................................................297
6.1.3.1 Analyzing the Optical Power........................................................................................................297
6.1.3.2 Querying the Optical Power Using the CLI.................................................................................300
6.1.3.3 Measuring the Upstream Optical Power Using the Optical Power Meter....................................300
6.1.3.4 Measuring the Downstream Optical Power Using the Optical Power Meter...............................302
6.1.4 Using the OTDR to Locate Abnormal Attenuation Points on the Optical Line....................................304
6.1.5 Checking Whether the Optical Fiber Is Damaged Using the Red Pointer............................................311
6.1.6 Cleaning the Connector of an Optical Fiber..........................................................................................312
6.2 Locating and Troubleshooting ONT Faults....................................................................................................315
6.2.1 ONT-Related Alarms.............................................................................................................................315
6.2.2 Locating and Troubleshooting an ONT Fault Remotely.......................................................................317
Issue 01 (2011-10-24) Huawei Proprietary and Confidential vii

Module
6.2.2.1 Querying ONT Information..........................................................................................................317

6.2.2.2 Simulating a PPPoE Dialup..........................................................................................................318
6.2.2.3 Performing a Voice Loop Line Test.............................................................................................318
6.2.2.4 Simulating a Voice Call................................................................................................................320
6.2.2.5 Restoring Factory Defaults...........................................................................................................321
6.2.2.6 Resetting an ONT.........................................................................................................................321
6.2.3 Detecting a Rouge ONT........................................................................................................................322
6.2.4 Replacing an ONT.................................................................................................................................325
6.3 Common Methods of Locating Voice Service Faults....................................................................................326
6.3.1 Capturing Packets by Using Port Mirroring..........................................................................................326
6.3.2 Ethereal..................................................................................................................................................327
6.3.3 CoolEdit.................................................................................................................................................331
6.4 Optical Fiber Loopback..................................................................................................................................333
6.5 ADSL2+ Port Loopback.................................................................................................................................335
6.6 SHDSL Port Loopback...................................................................................................................................337
6.7 VDSL2 Port Loopback...................................................................................................................................338
6.8 Changing the Line Profile (Template) of an xDSL Port................................................................................340
6.9 Changing the Traffic Profile of an xDSL Port...............................................................................................341
6.10 E1 Port Loopback.........................................................................................................................................342
6.11 E1 Line Loopback........................................................................................................................................344
6.12 Performing PPPoE Dialup Simulation.........................................................................................................346
7 Troubleshooting Cases.............................................................................................................348
7.1 Troubleshooting Cases of ONU Status Abnormality.....................................................................................349
7.1.1 Failure to Go Online of an ONU...........................................................................................................349
7.1.1.1 TC-C6211 ONU Failure to Go Online Because of Too Large Fiber Length Distance................349
7.1.1.2 TC-C6212 ONU Failure to Go Online Because of Incorrect Fiber Connection..........................350
7.1.1.3 TC-C6213 ONU Failure to Go Online Because of Not Clean Fiber Connector..........................351
7.1.1.4 TC-C6216 ONU Failure to Go Online Because of a Too Large Receive Optical Power Difference
Between ONUs.........................................................................................................................................352
7.1.2 Failure to Recover ONU Configurations...............................................................................................354
7.1.2.1 TC-C6166 Failed ONU Configuration State Because of Incorrect Queue Scheduling Priority
..................................................................................................................................................................354
7.1.3 ONU Profile Mismatch..........................................................................................................................355
7.1.3.1 TC-C6000 The Match State Is mismatch Because of the Inconsistency Between the Number of
GEM Ports in the Capability Set Profile and the Number of GEM Ports Supported by an ONU...........355
7.1.4 Failure to Automatically Discover an ONU..........................................................................................356
7.1.4.1 TC-C6004 Certain ONUs Fail to Be Auto Discovered on the OLT Because of Very Short Maximum
Registration Distance................................................................................................................................356
7.1.4.2 TC-C6015 An ONU Fails to Be Auto Discovered on an OLT Because the Actual Distance Between
the ONU and OLT Is Longer Than the Preset Maximum Distance.........................................................357
7.1.4.3 TC-C6308 The ONU Cannot Be Automatically Detected Because the Optical Attenuation Is
Excessively High......................................................................................................................................358
7.1.4.4 TC-C6210 ONU Auto Discovery Failure Because of Too Long Fibers......................................359
7.1.4.5 TC-C6215 ONU Auto Discovery Failure Because of Failure of Optical Splitter........................361
Issue 01 (2011-10-24) Huawei Proprietary and Confidential viii

Module
7.1.5 ONU Frequently Goes Online and Offline............................................................................................361

7.1.5.1 TC-C6007 An ONU Goes Online and Offline Repeatedly Because of Unstable Voltage...........362
7.1.5.2 TC-C6311 An ONT Frequently Goes Online and Offline Because of Unmatched Optical Fiber
Connectors................................................................................................................................................363
7.1.5.3 TC-C6207 ONU Frequent Going Online and Offline Because of Mismatching Fiber Connector
..................................................................................................................................................................364
7.1.5.4 TC-C6208 ONU Frequent Going Online and Offline Because of a Too Small Fiber Bend Radius
..................................................................................................................................................................365
7.1.5.5 TC-C6214 ONU Frequent Going Online and Offline Because of a Too Large Split Ratio.........367
7.1.5.6 TC-C6217 ONU Frequent Going Online and Offline Caused by a Rogue ONU........................368
7.1.6 Other ONU Faults..................................................................................................................................370
7.1.6.1 TC-C6008 Alarms About the Loss of GEM Cells Are Generated on an OLT Because of Very Large
Receive Optical Power of an ONT...........................................................................................................370
7.1.6.2 TC-C6052 Login to the ONU Through the Maintenance Network Port for Deployment Upgrade
Fails Due to the Mismatch of the ARP Mapping.....................................................................................371
7.1.6.3 TC-C6054 Data Cannot Be Saved on the ONU Because the H.248 Interface Is Not Registered
..................................................................................................................................................................372
7.1.6.4 TC-C6120 Many Users Under the Same PON Port Have Dialing Error 678 Because Optical Power
Is Too Strong............................................................................................................................................373
7.1.6.5 TC-C6307 A Large Number of Alarms Are Generated on the OLT Because the Optical Power for
the Transmission Between the OLT and the ONT Is Excessively High..................................................374
7.1.6.6 TC-C6209 Too Many Bit Errors on an ONU Because of Poor Fiber Splicing............................375
7.1.6.7 TC-C6226 ONT Can Be Successfully Pinged but the Web Page Cannot Be Logged in After the
ONT Is Upgraded.....................................................................................................................................377
7.2 Troubleshooting Cases of Internet Access Service Faults..............................................................................378
7.2.1 Failure to Access the Internet................................................................................................................378
7.2.1.1 TC-C6371 Failure to Access the Internet for the Leased Line User Caused by Improper ACL
Configuration............................................................................................................................................378
7.2.1.2 TC-C6372 Traffic-Limit Failure Caused by Incorrect Sequence of QoS Actions.......................380
7.2.2 Going Offline Frequently......................................................................................................................381
7.2.2.1 TC-C6186 MA5626G PPPoE Users Go Offline Abnormally After the Anti-MAC Spoofing Is
Enabled on the MA5626G........................................................................................................................381
7.2.3 Low Internet Access Rate......................................................................................................................383
7.2.3.1 TC-C6031 Failure to Open Web Pages Due to Configuration Inconsistency of the Link Aggregation
..................................................................................................................................................................383
7.2.3.2 TC-C6118 Internet Cafe User of an ONT Encounters Great Delay Because the QoS Policy of the
Upper-Layer Switch Is Incorrect..............................................................................................................384
7.2.3.3 TC-C6386 Low Downloading Speed Cause by Disabled MAC Address Aging Function..........386
7.2.3.4 TC-C6187 Some Users of the MA5600T Fail to Access the Internet or Have Low Internet Access
Rate Because of Conflicted MAC Addresses...........................................................................................387
7.2.4 Failure to Obtain an IP Address in the PPPoE Dialing Mode...............................................................389
7.2.4.1 TC-C6242 PPPoE Dialing Failure Caused by Abnormal ARP Packets of the Set-Top Box.......389
7.2.5 Failure to Obtain an IP Address in the DHCP Mode............................................................................391
7.2.5.1 TC-C6145 PC Fails to Obtain the DHCP-Allocated IP Address Because Excessive Broadcast
Domains Are Configured on the ONU.....................................................................................................391
Issue 01 (2011-10-24) Huawei Proprietary and Confidential ix

Module
7.2.5.2 TC-C6385 Failure to Access the Internet Because of Incorrect Configurations of the DHCP Server
..................................................................................................................................................................392
7.3 Troubleshooting Cases of IPTV Service Faults.............................................................................................393
7.3.1 Dark Screen After Program Ordering....................................................................................................393
7.3.1.1 TC-C6050 Multicast Service Is Unavailable Due to Inconsistency Between the User VLAN and the
Multicast VLAN on the ONU..................................................................................................................393
7.3.1.2 TC-C6146 New Programs Cannot Be played Because the Multicast Bandwidth on a PON Port of
the OLT Is Limited...................................................................................................................................394
7.3.1.3 TC-C6327 Failure to Watch Programs Caused by the Improper TTL of the Multicast Stream
..................................................................................................................................................................396
7.3.1.4 TC-C6330 Failure to order programs Caused by No Configuration of the Host IP Address.......397
7.3.2 Mosaic Display in Multicast Programs.................................................................................................398
7.3.3 Abnormal Program Interruption in Watching a Multicast Program......................................................398
7.3.3.1 TC-C6068 Program Is Suspended After a Multicast User Watches the Program for Three Minutes
Because of Incompatibility of Features Implemented on Different Devices...........................................399
7.3.3.2 TC-C6329 Program Suspension After a User Orders the Program Successfully and Watches the
Program for a Short Period of Time Because of Incorrect Multicast Mode.............................................401
7.3.3.3 TC-C6218 Program of an STB Interrupted Owing to Program Switching on Another STB Managed
by the Same ONT.....................................................................................................................................402
7.3.4 Suspended in Multicast Programs ........................................................................................................403
7.3.4.1 TC-C6023 Multicast Program Is Not Displayed Smoothly Due to the Optical Module Problem on
the Upstream Device................................................................................................................................403
7.3.4.2 TC-C6134 A Multicast Program Is Suspended Because Different Multicast IP Addresses Map the
Same Multicast MAC Address.................................................................................................................404
7.3.4.3 TC-C6246 IPTV Service of the MA5616 Is Not Smooth Because the MAC Aging Time of the OLT
Is Too Short..............................................................................................................................................405
7.3.5 Other Multicast Service Faults..............................................................................................................407
7.4 Troubleshooting Cases of VoIP Service Faults..............................................................................................407
7.4.1 No Tone After Offhook.........................................................................................................................407
7.4.1.1 TC-C6005 No Dial Tone Is Played After Offhook Because of Damaged Cables........................407
7.4.1.2 TC-C6033 The Phone Has Neither Feed Nor Dial Tone After Offhook Due to Poor Contact of the
MDF..........................................................................................................................................................408
7.4.1.3 TC-C6077 MG Interface of the ONU Resets Every 20 Minutes Because Registered Domain Name
Conflict Exists..........................................................................................................................................409
7.4.1.4 TC-C6080 Phone User of the Virtual Network Hears No Tone After Offhook Caused by Abnormal
Digitmap Issued by the Softswitch...........................................................................................................411
7.4.1.5 TC-C6081 User Hears No Tone After Offhook Because Softswitch Does Not Recognize Parameters
Reported by the ONU...............................................................................................................................413
7.4.1.6 TC-C6125 Users of the MA5616 Cannot Hear a Tone at Irregular Intervals After Picking Up the
Telephone Because Configurations of the H.248 Profile Are Incorrect...................................................414
7.4.2 Busy Tone After Offhook......................................................................................................................415
7.4.2.1 TC-C6034 Ports on the Voice Service Board Are Displayed as Remote Block Because User Data
Is Not Configured on the Softswitch........................................................................................................415
7.4.2.2 TC-C6041 The Caller Hears the Busy Tone After Offhook Due to Inconsistent RTP Formats
Between the ONU and the Softswitch .....................................................................................................416
7.4.2.3 TC-C6083 ONU User Hears the Busy Tone After Offhook BecauseSoftswitch Does Not Recognize
the Offhook Signaling Reported by the ONU..........................................................................................418
Issue 01 (2011-10-24) Huawei Proprietary and Confidential x

Module
7.4.2.4 TC-C6192 Route Is Lost After an ONU Is Reset Because the Route of the MG Media Address of
the ONU Is Set to the Default Route........................................................................................................419
7.4.3 No Ring Back Tone After Dialing.........................................................................................................421
7.4.3.1 TC-C6116 VoIP Service Failure Occurs on an ONU Because the Softswitch Issues an Incorrect
Parameter of the Detection Message........................................................................................................421
7.4.3.2 TC-C6121 SIP VoIP Service Fails Because an ONT Port ID Is Not Bound to a Telephone Number
..................................................................................................................................................................422
7.4.3.3 TC-C6243 Voice Users Served by the MA5616 Sometimes Cannot Hear the Ringback Tone After
Dialing Numbers Owing to the Fault of the E1 Trunk of the MCA Platform on the Core Network.......424
7.4.4 Busy Tone After Dialing.......................................................................................................................425
7.4.4.1 TC-C6035 Subscribers Hear the Busy Tone After Dialing the Number Due to the Incorrect Settings
of Software Parameters of the MG Interface ...........................................................................................425
7.4.4.2 TC-C6078 ONU Users Hear the Busy Tone After Offhook and Dialing Due to Incorrect Settings
of the RTP Ephemeral Termination Range on the Softswitch.................................................................426
7.4.5 One-Way Audio in a Voice Call............................................................................................................428
7.4.5.1 TC-C6001 One-Way Audio Because of Improper Configuration of the Voice IP Routing .......428
7.4.5.2 TC-C6013 One-Way Audio Because of the ACL Configured on the Bearer Network...............429
7.4.5.3 TC-C6037 IPT Service of the Caller Fails Because of Inconsistent ONU Dialing Mode...........430
7.4.5.4 TC-C6051 One-Way Audio of the Voice Service on the ONU Occurs Because the Port ID Used by
the Media Stream Is Masked on the Bearer Network...............................................................................431
7.4.5.5 TC-C6229 One-Way Audio Between the HG850a and the IAD in the Same Network Segment
Because the ARP Proxy on the Upper-Layer Gateway Is Disabled.........................................................432
7.4.6 Noise in a Voice Call.............................................................................................................................435
7.4.6.1 TC-C6003 Broadcast Is Played After Offhook Because of the Interference on the Loop Line
..................................................................................................................................................................435
7.4.6.2 TC-C6082 Noise Occurs in the VoIP Service of the ONU Because the OLT Suffers Network Attacks
..................................................................................................................................................................436
7.4.6.3 TC-C6129 Voice Subscriber Hears Much Noise After Offhook Because the ASDA Daughter Board
Is Faulty....................................................................................................................................................437
7.4.7 Voice Interruptions in a Voice Call.......................................................................................................438
7.4.7.1 TC-C6014 Interrupted Conversation Because of Improper QoS Configuration of the VoIP Service
..................................................................................................................................................................438
7.4.8 Fail to Dial Certain Phone Numbers......................................................................................................439
7.4.8.1 TC-C6043 Put-Through Rate of the Long-Distance Calls Is Low Due to Packet Loss Caused by
Loose Optical Fiber Connection on the PON Port of the ONU...............................................................440
7.4.8.2 TC-C6045 International Call Fails Due to the Digitmap Matching Problem When the ONU Is
Interconnected with the Softswitch of Another Vendor...........................................................................441
7.4.8.3 TC-C6059 Subscribers Cannot Dial 10060 or 10000 Due to a Lack of the Digitmap.................443
7.4.8.4 TC-C6142 Certain Phones Fail to Be Connected Because the Dialing Rule in the Default Digitmap
Is Excessively Short..................................................................................................................................444
7.4.8.5 TC-C6181 Dialing Failure Because Phones of the MA5616 Are Connected to IP Dialers.........446
7.4.8.6 TC-C6190 There Is a Possibility That Number Loss Occurs When a User Connected to the MA5616
Makes Long-Distance Calls......................................................................................................................447
7.4.8.7 TC-C6195 MA5620 Users Fail to Call Local Fixed Phones Because of IMS Calling Prefix Conflict
..................................................................................................................................................................448
7.4.9 Abnormal Fax Service...........................................................................................................................449
7.4.9.1 TC-C6074 Fax Cannot Be Received or Transmitted Due to Incorrect Fax-Modem Setting.......449
Issue 01 (2011-10-24) Huawei Proprietary and Confidential xi

Module
7.4.9.2 TC-C6076 Faxing a Document to Certain Numbers Is Successful While Faxing the Document to
Others Fails...............................................................................................................................................450
7.4.9.3 TC-C6084 Fax Service Fails on the ONU Because the RFC2198 Function Is Not Enabled on the
Softswitch.................................................................................................................................................451
7.4.9.4 TC-C6115 MA5620G Fails to Receive and Transmit Extranet Faxes Because of Incorrect Fax
Configurations of the Softswitch..............................................................................................................453
7.4.9.5 TC-C6122 Fax Service Failure Occurs on the ONT Because the IMS Does Not Support T.38
..................................................................................................................................................................454
7.4.9.6 TC-C6194 MA5620 Users Fail to Receive Faxes Because Parameters Are Incorrectly Configured
on the SIP Profile......................................................................................................................................455
7.4.9.7 TC-C6236 Fax Service Is Intermittently Interrupted Owing to the Fault of the Upper-Layer Optical
Line of the OLT........................................................................................................................................456
7.4.10 Abnormal Voice Interruption..............................................................................................................457
7.4.10.1 TC-C6060 The Voice Service Is Interrupted Intermittently Due to the Redundant Configuration
of the POTS Ports.....................................................................................................................................457
7.4.10.2 TC-C6063 Voice Service of the ONU Connected to an OLT Is Abnormal Caused by Incorrect
Configurations of Link Aggregation........................................................................................................459
7.4.10.3 TC-C6093 H.248 Interface of the MA5616 Is Intermittently Disconnected Because the Softswitch
Does Not Respond to Request 904 Sent by Certain TIDs........................................................................460
7.4.10.4 TC-C6130 MG Interface Is Interrupted Because the Management VLAN of the ONU Is Incorrectly
Changed ...................................................................................................................................................461
7.4.10.5 TC-C6162 H.248 Interface Is Disconnected Repeatedly Because the Primary/Secondary MAC
Addresses of the ONU Are Reversely Configured...................................................................................462
7.4.10.6 TC-C6182 Call Services of an MA5616 Connected to an SBC Are Abnormal Because Packets Are
Lost Between the SBC and the MG..........................................................................................................464
7.4.11 Abnormal CLIP...................................................................................................................................465
7.4.11.1 TC-C6112 CLIP Service Is Abnormal Because Configurations of the SIP Profile Are Incorrect
..................................................................................................................................................................465
7.4.11.2 TC-C6119 CLIP Service Failure Occurs on an ONU User Because the IMS Configurations Are
Incorrect....................................................................................................................................................467
7.4.12 Abnormal Call Holding, Call Waiting, and Call Forwarding..............................................................468
7.4.12.1 TC-C6161 Call Hold and Call Waiting Services Are Abnormal Because of Incorrect Parameters
of an MA561x SIP Profile........................................................................................................................468
7.4.12.2 TC-C6165 Call Waiting Service Fails Because of Incorrect Hookflash Upper/Lower Limits of the
HG850a.....................................................................................................................................................470
7.4.13 Abnormal POS Machine Service.........................................................................................................471
7.4.13.1 TC-C6048 POS Machine Fails to Be Registered Due to Incorrect Registration Code of the POS
Machine Connected to the ONU..............................................................................................................471
7.4.13.2 TC-C6117 Payment Service with Bankcard on the POS Machine Connected to the MA5606T Fails
Because of Polarity Reversal Settings......................................................................................................473
7.4.13.3 TC-C6235 POSs Cannot Register with the Server Because Echo Cancellation Is Not Disabled
..................................................................................................................................................................475
7.4.14 Echo in a Voice Call............................................................................................................................476
7.4.14.1 TC-C6047 The Peer Subscribers of the ONU Hear Their Own Echoes Because the Echo
Cancellation (EC) Function Is Disabled on the Softswitch......................................................................476
7.4.15 Voice User Fails to Be Registered.......................................................................................................477
7.4.15.1 TC-C6009 The MG Interface Fails to Pass the MGC Authentication Because of Incorrect Data
Configuration of the MGC.......................................................................................................................477
Issue 01 (2011-10-24) Huawei Proprietary and Confidential xii

Module
7.4.15.2 TC-C6010 The MG Fails to Register with the Softswitch Because of Inconsistent Protocol Versions
..................................................................................................................................................................479
7.4.15.3 TC-C6011 The MG Fails to Register with the MGC Because of the Faulty Upper-Layer Link
..................................................................................................................................................................480
7.4.15.4 TC-C6012 The MG Interface Fails to Register with the Softswitch Because of Disabled H.248
Protocol Proxy on the SBC.......................................................................................................................481
7.4.15.5 TC-C6053 Switchover Occurs Repeatedly Because the ONU Fails to Register with the Active
MGC.........................................................................................................................................................482
7.4.15.6 TC-C6055 The ONU Fails to Be Registered Due to the Incorrect Setting of the Domain Name
..................................................................................................................................................................483
7.4.15.7 TC-C6061 The ONT Fails to Register with the Softswitch Due to the Incorrect Setting of the User
Name.........................................................................................................................................................485
7.4.15.8 TC-C6231 Failed to Register the H.248 Interface of an HG850a Owing to the Incorrect
Configuration of MgcDomainName on the HG850a...............................................................................485
7.4.15.9 TC-C6239 H.248 Interface Cannot Be Registered Owing to Restriction on the Length of the MGC
Domain Name...........................................................................................................................................487
7.4.16 Other Voice Service Faults..................................................................................................................488
7.4.16.1 TC-C6029 OLT Subscribers Connected to the AGs in the Same Network Segment Cannot
Communicate with Each Other Due to the ARP Proxy Problem.............................................................488
7.4.16.2 TC-C6193 Caller and Callee Fail to Be Connected When Two ONUs Connected to a PON Port
Make Calls with Each Other.....................................................................................................................489
7.4.16.3 TC-C6173 Voice Service Failure Because the Subnet Mask of the Static IP Address of the HG850e
Voice Service Is Incorrect........................................................................................................................491
7.4.16.4 TC-C6303 Failure to Make a Phone Call but Success in Accessing the Internet.......................492
7.5 Troubleshooting Cases of Other Services Faults............................................................................................493
7.5.1 Network Failure.....................................................................................................................................493
7.5.1.1 TC-C6168 Failure to Telnet a Cascaded Switch Because TLS Streams Are Configured on the
MA5620G.................................................................................................................................................493
7.5.1.2 TC-C6180 Failure to Ping the MA5620 Because the MA5600T Is Enabled with Anti-IP Attack
..................................................................................................................................................................494
7.5.1.3 TC-C6382 Failure to Log In to the Device Caused by Malicious Attacks...................................495
7.5.1.4 TC-C6384 Failure to Ping the Layer 3 Interface Caused by a Ring Network..............................497
7.5.2 NEs Fail to Be Managed by the NMS...................................................................................................498
7.5.2.1 TC-C6370 Failure of the BMS to Manage NEs Caused by Inconsistent Versions......................498
7.5.2.2 TC-C6189 N2000 BMS Frequently Fails to Manage the MA5616 Because of Bridge MAC Address
Conflict.....................................................................................................................................................499
7.5.2.3 TC-C6245 Network Management Service of All ONUs Connected to the Same PON Port Is
Frequently and Intermittently Interrupted Owing to the Incorrect Configuration of the DBA................500
7.5.3 Service Board Resets Repeatedly..........................................................................................................501
7.5.3.1 TC-C6141 ASPB Board of an ONU Resets Repeatedly Because the DC Power Is Poorly Grounded
..................................................................................................................................................................502
7.5.4 Other Service Faults..............................................................................................................................503
7.5.4.1 TC-C6016 Interconnection Between the OLT and the Switch Fails Due to Incorrect LACP
Configuration on the Switch.....................................................................................................................503
7.5.4.2 TC-C6024 Failure to Support the Long-Distance E1 Cable Due to the Jumper Setting Problem on
the TOPA Board.......................................................................................................................................505
Issue 01 (2011-10-24) Huawei Proprietary and Confidential xiii

Module
7.5.4.3 TC-C6154 BMS Frequently Prints the Error Message Because the MA5652G Does Not Support
1588 Clock................................................................................................................................................506
7.5.4.4 TC-C6155 Anti MAC Spoofing of the MA5652G Fails Because Anti MAC Spoofing Is Not Enabled
in the VLAN Service Profile....................................................................................................................507
7.5.4.5 TC-C6309 The Downloading Rates of 40 Mbit/s and 60 Mbit/s Downloading Bandwidths Cannot
Reach Expected Values Because of Incorrect Setting of the Buffer Size on the FTP Server..................509
7.5.4.6 TC-C6369 Failure to Load the Configuration File Backed Up in the Unix Operating System
..................................................................................................................................................................510
7.5.4.7 TC-C6377 Failure to Synchronize a Correctly Configured NTP Client with the NTP Server in Time
..................................................................................................................................................................511
7.5.4.8 TC-C6170 Failure to Back Up the Database File Because the Patch Is Not Activated...............512
7.5.5 Upgrade Failure.....................................................................................................................................513
7.5.5.1 TC-C6237 MDU Cannot Be Upgraded Normally Owing to the Unstable Transmission Link
..................................................................................................................................................................513
7.5.6 Control Board Abnormal Reset.............................................................................................................514
7.5.6.1 TC-C6364 Failure to Start the Upgraded Standby Control Board Caused by Mismatching of the
Extended BIOS.........................................................................................................................................514
7.5.7 High CPU Usage Means........................................................................................................................516
7.5.7.1 TC-C6366 Slow Command Response and Execution Caused by Concurrent Operations on the
Active/Standby Control Boards Through the Serial Ports........................................................................516
7.5.8 EMU Fault.............................................................................................................................................517
7.5.8.1 TC-C6133 Configurations of Fans of the MA5600T Fail to Be Issued Because the New Fans Support
the Automatic Loading Function..............................................................................................................517
8 FAQ..............................................................................................................................................519
8.1 Operation-Related FAQ..................................................................................................................................520
8.1.1 What Commands Does an OLT Have for Querying the Version..........................................................520
8.1.2 How to Do If the Root Password of a Device Is Lost...........................................................................520
8.1.3 How Does the MA5616 Automatically Cut Off the Power Supplied to the Broadband Service Board When
the Batteries Are Used as Power Supply........................................................................................................521
8.1.4 How to Configure Port Mirroring on the MA561x to Capture Voice Packets......................................522
8.1.5 How to Query and Change the ARP Aging Time.................................................................................522
8.1.6 What Are Precautions for the ETHB When It Functions as the Upstream Board of the MA5600T/
MA5603T.......................................................................................................................................................523
8.1.7 How to Set the Port of the SCUB/SCUN as the Upstream Port............................................................523
8.1.8 How to Query Traffic of a Port on the MA5616...................................................................................524
8.1.9 Can a Service Port of the MA5616 Be Activated or Deactivated.........................................................524
8.1.10 Whether Does the MA5616 Support Packet Capturing on the Upstream Port Locally......................525
8.1.11 How to Troubleshoot the Fault That When an MDU Is Powered Off Its System Time Regresses to Year
2000................................................................................................................................................................525
8.1.12 How to Collect Traffic and Rate Statistics an ONT on the MA5600T/MA5603T.............................526
8.1.13 In What Conditions Can Multicast Packets Be Carried in the PPPoE Mode on the MA5600T/MA5603T
........................................................................................................................................................................527
8.1.14 How to Train the ADSL/VDSL Modem Connected to the MA5652G to Be a VDSL Modem..........528
8.1.15 How to Configure DBA When GPBD and the OT928G Are Used Together.....................................528
8.1.16 Why Is a Prompt Indicating That the Modified GEM Port Mapping Index Is the Same as the Index of
Another Mapping Displayed..........................................................................................................................529
Issue 01 (2011-10-24) Huawei Proprietary and Confidential xiv

Module
8.1.17 How to Load the Version of the Standby Control Board of the MA5600T........................................529
8.1.18 How to Troubleshoot the Fault That the NMS Displays that the EMAC Chip of the MA5600T Board Is
Faulty..............................................................................................................................................................530
8.1.19 How to Disable the Check Performed by the HG8245 on the Port Used by the SIP Proxy Server to Send
SIP Packets.....................................................................................................................................................530
8.1.20 How to Use Storage Batteries to Ensure Normal Use of the Broadband Service After Interruption of the
Mains..............................................................................................................................................................531
8.2 Principle-Related FAQ...................................................................................................................................531
8.2.1 Why P2P Download Leads to Low ADSL Rate....................................................................................531
8.2.2 How Is the VoIP Service Implemented on the MA5600T by Setting the electronic Switch................532
8.2.3 Which Cabinets Are Used for the 21-inch ETSI Subrack and the 19-inch IEC Subrack......................533
8.2.4 What Are the Functions of the HiGig Interface on the ETHB Board...................................................533
8.2.5 What Are the Relations Between the Delay Caused by DBA Rate Limitation and the Size of User Packets
........................................................................................................................................................................533
8.2.6 Whether the DC Power Board PDIA of the MA5616/MA5610 Supports Reporting an Alarm In Case of
Power-off........................................................................................................................................................534
8.2.7 How Long Will the MA5600T/MA5603T Report the LOS Alarm After Its PON Port Does Not Receive
Any Optical Signals........................................................................................................................................534
8.2.8 Whether Certain Boards Can Be Used on Both the MA5616 and the MA5610...................................535
8.2.9 How Long Will the SIP Interface of the MA5616 Be Registered Again After the SIP Interface Is
Disconnected..................................................................................................................................................535
8.2.10 What Are the Limitations for Configuring Link Aggregation and Protection on the ETHA, ETHB, and
GIU Boards.....................................................................................................................................................536
8.2.11 Why Does the H831VESC EMU of MA562x V800R307 Fail to Be Deleted....................................536
8.2.12 What Are the Differences Between Options always-on and once-on in the Password Authentication of
an ONU...........................................................................................................................................................537
8.2.13 Can Multicast Duplication Be Concurrently Achieved on the OLT and BRAS.................................537
8.2.14 Why Does the Multicast Packet Sent by the Port (with Native VLAN) of the HG866 Carry the VLAN
........................................................................................................................................................................538
8.2.15 What Is the Relationship Between the LOF and LOS Alarms............................................................538
8.2.16 What Is the Difference Between the loghost add and file-server Commands...................................539
8.2.17 Can a Switch Be Cascaded to an OPFA Board...................................................................................539
8.2.18 How to Forward Voice Media Streams of an MDU............................................................................539
8.2.19 How to Capture SIP and H.248 Signaling of the HG824x..................................................................540
8.2.20 Why Is a Message Prompting You to Change Time Displayed When You Log In to an MDU.........540
8.2.21 How to Limit POTS Calls If the Maximum Power of the MA5616 Exceeds 200 W.........................541
8.2.22 Can -48 V Power Supply Be Used When the MA5616 Uses the PAIB Power Board........................541
8.2.23 What Is the MDU's Forwarding Mechanism for the Voice Media Stream?.......................................541
8.2.24 Routes Supported by the HG824x Series ONT...................................................................................543
8.2.25 How to Implement Interworking Between Four FE Ports of the HG824x..........................................543
8.2.26 Whether the GE Optical Ports of the Main Control Boards on the MA562x Series Support Link
Convergence...................................................................................................................................................544
8.2.27 Default IGMP Packet Processing Mode of the MDU.........................................................................544
Issue 01 (2011-10-24) Huawei Proprietary and Confidential xv

Module
Troubleshooting 1 Maintenance Engineers' Must-Read
1 Maintenance Engineers' Must-Read
About This Chapter
Maintenance engineers for troubleshooting are required to have more than one year's experience
in engineering or equipment maintenance. After reading the must-read, maintenance engineers
can know about the skills, procedures, and methods required to troubleshoot faults in the
MA5600T/MA5603T.
1.1 Skill Requirements

Maintenance engineers need to possess troubleshooting skills so that they can troubleshoot faults
successfully.
1.2 Troubleshooting Precautions
Before locating and troubleshooting faults, carefully read and strictly abide by the following
precautions.
1.3 Troubleshooting Procedure
This topic describes the universal procedure for troubleshooting the common faults.
1.4 Contacting Huawei for Assistance
If the fault persists even after the troubleshooting measures described in this document have
been taken, contact Huawei for assistance (Huawei engineers will provide guidance remotely
or on site on troubleshooting).
1.5 Frequently Used Methods for Troubleshooting
There are various of methods for fault location. In actual fault location, different methods are
used together. Therefore, mastering and using these methods are very important for improving
the efficiency of troubleshooting.
Issue 01 (2011-10-24) Huawei Proprietary and Confidential 1

Module
1.1 Skill Requirements

Maintenance engineers need to possess troubleshooting skills so that they can troubleshoot faults
successfully.
Maintenance engineers need to master the following:
1. Basics of communications technologies

l Computer network technologies, such as Ethernet and TCP/IP
l X digital subscriber line (xDSL) access technology
l Principles of the multicast service
2. Networking, services, and functions of the MA5600T/MA5603T
l Actual networking conditions
l Hardware structure and performance specifications of the MA5600T/MA5603T
l Functions of boards and slots for boards on the MA5600T/MA5603T
l Working principles of services and functions of the MA5600T/MA5603T
l Service configurations of the MA5600T/MA5603T
l Connections between the MA5600T/MA5603T and the other devices over the network
l Protocols used between the MA5600T/MA5603T and the other devices over the
network
3. Common operations for locating faults in the MA5600T/MA5603T, in addition to:
l Which operations may completely or partially interrupt the service
l Which operations may result in customer complaints
l Which emergency or backup measures are available
l Which operations may damage the equipment
4. Use of common test tools and instruments, including:
l Multimeter
l Line tester
l Optical power meter
l Optical attenuator
5. Methods of determining and handling emergencies in the devices (these methods can be
mastered through practice and before practice the relevant standards and requirements of
carriers need to be known about)
6. How to seek help in case of a fault, including but not limited to referring to the
troubleshooting documents or contacting Huawei for assistance
1.2 Troubleshooting Precautions

Before locating and troubleshooting faults, carefully read and strictly abide by the following
precautions.
For maintenance engineers, they should:

Module
l Bear in mind precautions for handling emergencies. For details, see 5.1 Precautions for
Emergency Handling.
l In case of a fault, check first whether or not the fault is an emergency. For details, see
Determining Whether a Fault Is an Emergency. If the fault is an emergency, use the pre-
defined emergency handling method to return the faulty module to the normal state quickly
and then recover services.
l Strictly follow the regulations on operations and industry safety to prevent personal injury
and equipment damage.
l When replacing and maintaining parts of equipment, take antistatic measures (for example,
wear the ESD wrist strap).
l When any problem occurs during the troubleshooting, record the original information in
detail.
l Make a record when performing significant operations (for example, restarting the device
or erasing the database). Before such significant operations are performed by qualified
engineers, check whether these operations are feasible and at the same time carry out the
backup and work out contingency and security measures.
l To improve troubleshooting efficiency, make the following preparations before a fault
occurs on the device:
– Get ready the information about physical connections of the on-site devices.
– Make a table containing information (including VLAN, IP address, interconnected port
ID, firewall configurations, and user name and password) about the communications,
interconnection, and rights of parts and devices.
– Make on-site part/device archives where the software and hardware configurations, the
software and hardware versions, and the change information are recorded.
– Periodically maintain the backup device to ensure that its hardware configuration,
software version, and parameters are the same as the working device running over the
existing network. In this way, when the working device is faulty in an emergency, the
faulty device can be replaced with the backup device quickly.
– Periodically check the remote access device and the fault diagnosis tools (including the
testing tools and the packet capture tools) to ensure their normal use.
– Update the fault-related documents (including the Troubleshooting, Alarm Reference,
and Routine Maintenance) in time and place them in an easily accessible place (the latest
documents can be obtained at http://support.huawei.com).
1.3 Troubleshooting Procedure

This topic describes the universal procedure for troubleshooting the common faults.
Figure 1-1 shows the flowchart for troubleshooting the common faults.

Module
Figure 1-1 Flowchart for troubleshooting the common faults
Start
Collect and record fault

information
Can the fault No

scope or type be
identified?
Yes
Determine the fault scope

and type
Yes
Emergency maintenance Is the fault emergent?
No
Locate the fault cause
Shield/Isolate the fault
Rectify the fault
Query troubleshooting
results
No Contact Huawei
Is the fault rectified?
Customer Center
Yes
Record the troubleshooting

process
End

Module
1.4 Contacting Huawei for Assistance

If the fault persists even after the troubleshooting measures described in this document have
been taken, contact Huawei for assistance (Huawei engineers will provide guidance remotely
or on site on troubleshooting).
Call local Huawei branches or representative offices or contact Huawei Customer Service
Center.
Contact Huawei Customer Service Center: support@huawei.com
NOTE
Before contacting Huawei for technical support, fill in the form for reporting a fault and deliver this form
to Huawei by fax or email. This can help us rectify the fault quickly for you. The more detailed and accurate
the fault information you provide, the more helpful for subsequent fault locating.
1.5 Frequently Used Methods for Troubleshooting

There are various of methods for fault location. In actual fault location, different methods are
used together. Therefore, mastering and using these methods are very important for improving
the efficiency of troubleshooting.
1.5.1 Configuration Data Analysis

Incorrect re-configurations and expansion configurations, and outstanding problems of existing
configurations are possible causes of a fault. Therefore, when locating and troubleshooting a
fault, you need to analyze the configuration data.
For example, none of the users configured on the MA5600T/MA5603T can watch multicast
programs. Check the configuration data. It is found that the time to live (TTL) value preset in
the multicast source is very small. In this case, multicast streams are discarded when they are
forwarded on the MA5600T/MA5603T because TTL is 0. This leads to the fault.
There is plenty of configuration data. Therefore, as described in 1.1 Skill Requirements, you
must master configuration methods and implementation principles of different services and
functions, especially the configuration data needs to be checked for different faults, to improve
the efficiency of troubleshooting. This document provides different methods of checking the
configuration data for locating common faults. For details, see the following topics.
1.5.2 Alarm Analysis

By analyzing alarms, causes of certain faults can be found, or a fault can be located by using
alarm analysis together with other methods.
An alarm is an important prompt when a fault or an event occurs. When a fault occurs on the
MA5600T/MA5603T, an alarm may be generated. Through the alarm management system, such
as the NMS or the CLI, you can query alarms.
The alarm information includes the detailed description and the possible cause of a fault or an
abnormality, and the troubleshooting advice. The alarm information involves aspects such as
the hardware, link, service, and CPU usage. The information volume of the alarm information
is large and complete, which is the important basis for fault analysis and location.

Module
When a fault occurs in the system, check whether an alarm is generated in the system. If an alarm
is generated, analyze the alarm associated with the fault, and then clear the alarm to rectify the
fault by referring to Alarm and Event Reference.
For example, run the display alarm history command and display event history command to
query the critical alarms. A "system resource is exhausted" alarm is in these alarms, and a
suggestion of "decrease system load" is displayed.
1.5.3 Comparison Analysis

Comparison analysis is to compare the faulty components or symptoms with the normal
components or symptoms, and then find out differences, to locate the fault. For example,
compare line parameters of faulty services with line parameters of normal services, or compare
devices at the same network layer.
Comparison analysis is applicable to faults that are caused by a single factor.
For example, if an ADSL user is frequently offline, replace a modem or compare whether other
ADSL users around have the same fault to locate the fault.
1.5.4 Interchange Analysis

When a fault cannot be located after the faulty parts are replaced, you can locate and troubleshoot
the fault by using the interchange analysis.
Interchange is to interchange the parts that may be faulty with normal parts (such as boards and
cables), and then compare the running conditions to locate the faults. This method is applicable
to the following scenarios:
l After a part is replaced, the scope or the location of the fault cannot be found.
l The fault occurs by multiple causes.
CAUTION
The interchange operation is risky to certain extent. For example, install the short-circuited board
in the normal running subrack. This may lead to subrack fault. Therefore, to prevent another
fault from occurring, exercise caution when using the interchange analysis.
1.5.5 Exclusive Method

When a fault is complicated and may involve multiple stages, you can locate the fault by using
the exclusive method that is used to exclude the normal stages.
To use the exclusive method, you must know stages in which the fault may occur, and then use
the applicable methods (such as loopback operations and configuration data analysis) to locate
the fault. Therefore, you must be familiar with the following point:
l System structure and working principles of the MA5600T/MA5603T

l Stages where the fault may occur
l Fault diagnosis operations such as loopback and configuration data analysis
l Usage of testers

Module
For example, a multicast program ordered by a user is always interrupted. After the user orders
the program again, the program becomes normal. According to principles of implementing the
multicast service, the possible causes of the fault are as follows:
l The multicast server is faulty.
l The configuration of the multicast router is incorrect.
l The set top box (STB) is faulty.
Then, check the STB, upper-layer multicast server, and multicast router accordingly to locate
the fault. This is the process of the exclusive method.
NOTE
The exclusive method involves all the stages in the entire network. It is recommended that you exclude
normal stages in the following sequence: remote end first and then local end, major cause first and then
the minor cause, simpleness first and then complication. This reduces troubleshooting cost and improves
troubleshooting efficiency.
1.5.6 Protocol Analysis

Protocol analysis is used to locate and troubleshoot a fault when the MA5600T/MA5603T is
improperly interconnected with the upper-layer device. This method is mainly used to
troubleshoot faults of PPPoE dialup, multicast services, and voice services.
Protocol analysis indicates the method for analyzing a fault by tracing the signaling and capturing
the packets.
To use the protocol analysis method, you must be familiar with the related protocols and the
exchange process for packets. In this case, the fault can be located from the obtained packets.
For example, a user fails to order multicast programs. After the packets are captured and
analyzed, it is found that the BRAS discards the IGMP packets sent from the user.
1.5.7 Meter Test

Meter test indicates that you can locate and troubleshoot a fault by comparing the actual values
of performance parameters tested by various instruments and meters with the correct values.
Instruments and meters directly indicate the running status of the device through visual and
quantitative data. They are important factors in troubleshooting.
The following instruments and meters are frequently used for troubleshooting:
l Multimeter
l Line tester
l Optical power meter
For example, an optical power meter is used to test the mean launched power of an optical port.
By testing the mean launched power, you can check whether the optical module for transmitting
signals works in the normal state. You can also use the multimeter to test the voltage, resistance,
and current during the power commissioning.
1.5.8 Performance Analysis

Performance analysis is to use the performance statistics provided by the MA5600T/
MA5603T to analyze the performance indexes of the faulty service to locate the fault.

Module
You need to query different performance statistics to locate different faults. In this case, you
must be familiar with the following point:
l System structure and operation mechanism
l Types of statistics provided by the system
l Method of querying and analyzing the statistics
For example, run the display port statistics command in the Ethernet port mode to query the
statistics on Ethernet ports. Based on the statistics, you can check whether the system is running
in the normal state.
l If the number of CRC error frames increases quickly, it indicates that links between devices
may be abnormal, the port negotiation mode is incorrect, or the physical fault occurs on
the port.
l If a large number of frames are discarded, it indicates that the traffic transmitted from the
interconnected device exceeds the receive capability of the local port.

Module
Troubleshooting 2 Troubleshooting the FTTx GPON Service
2 Troubleshooting the FTTx GPON Service
About This Chapter
This topic describes how to troubleshoot common faults in Internet access, multicast (IPTV),
and voice (VoIP) services in the GPON access mode in FTTx scenarios.
2.1 GPON ONU Abnormal State
This topic describes how to troubleshoot common faults in ONU abnormal state, including fail
to register an ONU, fail to auto discover an ONU and ONU frequently get offline. ONU includes
ONT and MDU.
2.2 Troubleshooting the FTTH Service (OLT + HG Series ONT)
This chapter describes how to troubleshoot common faults in Internet access, multicast (IPTV),
and voice (VoIP) services in the GPON access mode in FTTH scenarios. Home gateway (HG)
series ONT includes the HG810a.
2.3 Troubleshooting the FTTB and FTTC Service (OLT + MDU)
and voice (VoIP) services in the GPON access mode in FTTB and FTTC scenarios. MDU refers
to MA561x, MA562x, MA5612 and MA5606T. Command lines executed by MDU are examples
of MA5616.

Module
2.1 GPON ONU Abnormal State

This topic describes how to troubleshoot common faults in ONU abnormal state, including fail
to register an ONU, fail to auto discover an ONU and ONU frequently get offline. ONU includes
ONT and MDU.
2.1.1 GPON ONU Registration Failure

The ONU registration failure is a fault in which the values of Run state, Config state, and
Match state of an ONU are abnormal as queried by running the display ont info command on
the OLT.
l The ONU running status refers to the current running status of the ONU. It indicates whether
the ONU is online and whether the ONU can carry service. The ONU status is classified
into three types: ONU Run state, ONU Config state, and ONU Match state.
– If the ONU running status is offline, the OLT cannot issue any command to the ONU.
– If the ONU running status is online. In this case, whether the service can be forwarded
is determined by the ONU configuration status.
l The ONU configuration status indicates whether the configuration restoration is enabled
and whether the configuration restoration is complete. The ONU configuration status has
the following states: initial, normal, configuring (config), and configuration failure (failed).
When an ONU goes online, the ONU is in the configuration restoration stage.
– The first status is initial. Soon the initial is complete and the ONU enters the config
state.
– In the config state, the ONU capability and configuration data are restored. The duration
of the config state is determined by the amount of the data configured on the ONU.
– If the configuration restoration is successful, the ONU transitions from the config state
to the normal state.
– If the configuration restoration fails, the ONU transits from the config state to the failed
state and the service cannot be carried forward.
l The ONU matching status indicates whether the actual ONU capability is the same as the
service profile bound to the ONU. The status includes: initial, mismatch, and match. To
some extent, the matching status is determined by the ONU running status and configuration
status.
– The matching status of the ONU can be queried only when the ONU running status is
online and the configuration status is normal. The matching status is match when the
hardware capability is the same as the ONU service profile bound with the ONU.
Otherwise, the status is mismatch.
– In other configuration states, the matching status is initial.
– The ONU matching status does not affect the normal forwarding of the service flow,
and only indicates whether the actual ONU capability is the same as the service profile
bound to the ONU.
2.1.1.1 Failure to Go Online of a GPON ONU

An ONU connected to a GPON port of an OLT fails to go online normally, but the queried Run
state of the ONU is displayed as offline by running the display ont info command on the OLT.

Module
Location Method
NOTE
Going online refers to a process that after being powered on, an ONU registers with an OLT and sets up a
management channel with the OLT. An ONU can be managed by the OLT and be configured with services
only after going online.
When an ONU fails to go online, locate the fault based on the following fault symptoms and
possible causes.
Fault Symptom Possible Cause

Scope
OLT A single ONU or some l The SN or password configured on the OLT is

ONUs connected to an different from the actual SN or password of the
OLT fail to go online. ONU; hence, the ONU fails to pass
authentication and go online.
l The actual distance between the ONU and OLT
exceeds the ranging compensation distance
configured on the OLT.
l The OLT deactivates the ONU.
All the ONUs connected to l The laser on the PON port is disabled.
a PON port of an OLT fail l The pluggable optical module of the PON is
to go online. faulty.
l The PON port is faulty.
All the ONUs connected to l The board or the slot is faulty.

a board of an OLT fail to go
online.
ODN A single ONU or some l The branch fiber is bent excessively.

NOTE ONUs connected to an l The branch fiber connector is not clean.
ODN OLT fail to go online.
failures l The quality of branch fiber splicing is poor. For
are example, the splicing point has air bubbles.
generally l Different types of branch fiber connectors are
caused by
large
interconnected.
reflection l The multi-mode optical fiber is used as the
and branch fiber.
attenuatio
n caused l The ODN is not properly planned. For
by example, the split ratio, network coverage and
improper attenuation difference are not planned within
optical the proper ranges.
compone
nts, l The optical attenuation of the optical path is
design, or excessively small.
constructi
on.
l A branch fiber break occurs.
l The optical splitter is faulty or the connectors
on the optical splitter are not clean.

Module

Scope
All the ONUs connected to l The backbone fiber is bent excessively.

a PON port of an OLT fail l The backbone fiber connector is not clean.
to go online.
l The quality of branch fiber splicing is poor. For
example, the splicing point has air bubbles.
l Different types of backbone fiber connectors
are interconnected.
l The multi-mode optical fiber is used as the
backbone fiber.
l A backbone fiber break occurs.
ONU A single ONU or some l The ONU is not powered on.

ONUs connected to an l The information (including SN and password)
OLT fail to go online. for ONU authentication conflicts; hence, the
later power-on ONU fails to go online.
l A rogue ONU (such as a continuous-mode
ONU) exists on the network and affects other
ONUs.
l The ONU hardware is faulty.
l The optical module of the ONU is faulty.
l The Patch cord of the ONU is broken or bent
excessively.
CAUTION
To facilitate fault report, save the results of the following steps.
The parameters of the optical module in this topic comply with Class B+. Note that such
parameters are slightly different from the parameters in Class C.
Procedure
Step 1 When the queried Run state of the ONU is displayed as offline, check whether the OLT
generates the following alarms. If such alarms are generated, clear them and check whether the
fault is rectified. If the fault persists, proceed to Step 2.
The following alarms may be generated:
l 0x2e305015 The authentication information about the ONT is invalid
l 0x2e314021 There are illegal incursionary rogue ONTs under the port
l 0x2e314022 The ONT is rogue ONT
l 0x2e11a00b The dying-gasp of GPON ONTi (DGi) is generated

Module
l 0x2e11a001 The feed fiber is broken or OLT can not receive any expected optical signals
(LOS)
l 0x2e112007 The distribute fiber is broken or the OLT cannot receive expected optical
signals from the GPON ONT(LOSi)
l 0x2e11a00a The loss of acknowledgement PLOAM message with ONTi (LOAi) occurs
Step 2 Check for the possible causes on the OLT and troubleshoot the faults accordingly. If the ONU
still fails to go online after that, proceed to Step 3.
Possible Cause Judgment Criterion Troubleshooting Method
The SN configured on Run the display ont info Run the ont add command to
the OLT is different from command to query the ONU re-add an ONU and specify the
the actual SN of the information. It is found that the correct ONU SN and password.
ONU; hence, the ONU SN in the result is different NOTE
fails to pass from the actual ONU SN. The ONU with a different SN is
authentication and to go regarded as a new one and is
online. founded by the OLT.
The actual distance Run the display port info Run the port range command
between the ONU and command to query the to adjust the minimum logical
OLT exceeds the ranging minimum logical reach (Min reach and maximum logical
compensation distance distance) and maximum reach so that the actual distance
configured on the OLT. logical reach (Max distance) between the ONU and OLT is
configured for the GPON port. within the ranging
It is found that the actual compensation distance.
distance between the ONU and NOTE
OLT exceeds the ranging l By default, the ranging
compensation distance. compensation distance of a
For example, the actual length GPON port is from 0 km to 20
km.
of the optical fiber between the
ONU and OLT is about 25 km, l According to Class B+, the
which exceeds the ranging maximum logical reach of a
GPON port must not exceed
compensation distance of 0-20 60 km, and the difference
km. between the minimum logical
reach and maximum logical
reach must not exceed 20 km.
The OLT deactivates the Run the display ont info Run the ont activate command
ONU. command to query the ONU to activate an ONU.
information. It is found that NOTE
Control flag is displayed as When an ONU is activated, its
deactivated. optical module only receives
optical signals but does not
transmit optical signals.
The laser on the PON Run the display port info Run the port laser-switch
port is disabled. command to query the command to enable the laser on
information about the PON the PON port.
port. It is found that Laser NOTE
switch is in the Off state. By default, the laser on a GPON
port is enabled.

Module
The PON port is faulty. If either of the following two Replace the optical module of
situations occurs, the PON pot the PON port or replace the
is faulty. board.
l Run the display port state
command to query the
status of the PON port. It is
found that abnormal items
exist in the query result. For
example, the laser status
(Laser state) is abnormal
and the transmit optical
power (TX power) exceeds
the normal range (1.5-5.0
dBm).
l Migrate the service to
another port. It is found that
the ONU goes online
normally.
The board or the slot is All the ONUs connected to the Change the board to another
faulty. board fail to go online. slot. If the fault persist, replace
the board.
Step 3 Check for the possible causes on the ODN and troubleshoot the faults accordingly. If the ONU
The optical fiber 1. Test the backbone fiber and Clean the optical fiber
connector is not clean. branch fiber by using the connector. For details about
NOTE OTDR. It is found that the how to clean the connector, see
An unclean optical fiber reflection and return loss 6.1.6 Cleaning the Connector
connector will cause are abnormal. of an Optical Fiber.
excessive attenuation and
abnormal reflection. 2. Check the optical fiber
connector on site by using
the optical fiber endface
detector. It is found that the
optical fiber connector is
not clean.
The optical fiber is bent 1. Test the backbone fiber and Route and bundle the optical
excessively. branch fiber by using the fiber in a proper manner.
NOTE OTDR. It is found that
Optical signals attenuate abnormal return loss points
seriously on an optical exist on the optical fiber.
fiber with an excessively
small bending radius. 2. Check the optical fiber on
site. It is found that the
optical fiber is bent
excessively.

Module
The quality of optical 1. Test the backbone fiber and Splice the optical fiber again.
fiber splicing is poor. For branch fiber by using the
example, the splicing OTDR. It is found that
point has air bubbles. abnormal return loss points
NOTE exist on the optical fiber.
Poor optical fiber splicing 2. Check the optical fiber
leads to unstable
splicing points by using the
transmission of optical
signals. As a result, packet magnifying glass on site. It
loss occurs. is found that the splicing
points have quality
problems, for example, air
bubbles exist.
The optical fiber is not 1. Test the backbone fiber and l If the optical fiber is not
firmly connected or branch fiber by using the firmly connected, reconnect
different types of optical OTDR. It is found that the optical fiber firmly.
fiber connectors are abnormal return loss points l If different types of optical
interconnected. exist on the optical fiber. fiber connectors are
NOTE 2. Check the optical fiber interconnected, replace the
If the optical fiber is not connectors on site. It is incompatible connector
firmly connected or
found that the optical fiber with a compatible one or
different types of optical
fiber connectors are is not firmly connected or replace relevant devices,
interconnected, the PC connector (blue) and such as the optical splitter.
attenuation and reflection APC connector (green) are NOTE
will be excessively large. interconnected. In the scenario of the CATV
service, it is recommended that
you use APC connectors (green)
only.
The multi-mode optical 1. Check the backbone fiber Replace the multi-mode optical
fiber is used as the and branch fiber by using fiber with the single-mode
backbone or branch the OTDR. It is found that optical fiber.
optical fiber. optical signals attenuate
NOTE seriously.
If the multi-mode optical 2. Check the optical path on
fiber is used as the
backbone or branch optical
fiber, the optical signal multi-mode optical fiber is
attenuates quickly and the used. The multi-mode
return loss increases. optical fiber can be
recognized by its physical
features such as its color.

Module
The optical attenuation If either of the following two Add an optical attenuator on the
of the optical path is situations occurs, the optical optical path between the OLT
excessively small. attenuation of the optical path and ONU.
NOTE is excessively small.
l If the optical l Measure the receive optical
attenuation of the power of the ONU by using
optical path is the optical power meter. It
excessively small, the is found that the actual
optical power received
receive optical power of the
by the ONU will
exceed the overload ONU is greater than -8
optical power of the dBm.
ONU. l Check the optical path
l Such a situation occurs between the OLT and ONU.
usually in labs, where It is found that the optical
the OLT and ONU
attenuation of the optical
may be directly
connected to each path is excessively small.
other through a short The normal attenuation
optical fiber. range is 10-25 dB.
The ODN is not properly The ODN does not meet the Optimize the ODN to meet
planned. requirements of the ODN link Huawei's ODN planning
NOTE plan or GPON Class B+. requirements and protocol
l The split ratio of the l Three-level splitting exists requirements.
ODN link is not in the ODN.
determined by the
number of ONTs l The network coverage of
connected but by the the ODN exceeds 20 km by
split ratio of optical far.
splitters. When an
optical splitter is
l The split ratio exceeds the
connected to the ODN, maximum split ratio that the
attenuation occurs and board allows. Assuming
the split ratio of the that the maximum split ratio
optical splitter needs to of a board is 1:64. If the
be calculated. first-level split ratio is 1:8
l Protocols specify that and the second-level split
the receive optical ratio is 1:16, the actual split
power of the OLT
ratio is 1:128, which
should not exceed 15
dB. In addition, the exceeds the maximum split
difference between the ratio of the board.
maximum optical l The optical attenuation
power and the
minimum optical
difference of two optical
power should not paths exceeds 15 dB.
exceed 15 dB.

Module
The optical splitter is Measure the input and output Replace the faulty optical
faulty or the connectors optical power of the optical splitter or clean the connectors
on the optical splitter are splitter by using the optical on the optical splitter.
not clean. power meter. It is found that the
actual attenuation exceeds the
theoretical attenuation.
NOTE
The faults in the optical splitter
cannot be located by the OTDR
because the OTDR cannot
penetrate the optical splitter.
A backbone fiber break 1. Check the backbone fiber Reconnect the branch optical
occurs. by using the OTDR. It is fiber.
found that a backbone fiber
break occurs.
2. Check the optical fiber on
optical fiber is broken or not
connected.
A branch fiber break 1. Check the branch fiber by Reconnect the branch optical
occurs. using the OTDR. It is found fiber.
that a branch fiber break
occurs.
connected.
Step 4 Check for the possible causes on the ONU and troubleshoot the faults accordingly. If the ONU
The ONU is not powered If either of the following two Restore the power supply of the
on. situations occurs, the ONU is ONU.
not powered on.
l The 0x2e11a00b The
dying-gasp of GPON ONTi
(DGi) is generated alarm is
generated on the OLT, but
the corresponding recovery
alarm is not generated.
l Check the power supply of
the ONU. It is found that the
power supply of the ONU
fails or is turned off.

Module
A rogue ONU (such as a If either of the following two Replace the rogue ONU with a
continuous-mode ONU) situations occurs, a rogue ONU normal one.
exists on the network and exists.
affects other ONUs. l The 0x2e314021 There are
NOTE illegal incursionary rogue
If a rogue ONU exists, the ONTs under the port alarm
ONU that fails to go online
is generated on the OLT.
may be a normal one and
the ONU that can go online l The 0x2e314022 The ONT
may be a rogue one. is rogue ONT alarm is
generated on the OLT.
l Connect the optical fiber of
the OLT port to the optical
power meter for
measurement. If a value can
be read from the optical
power meter, a continuous-
mode ONU or irregular-
mode ONU exists.
The information (SN) for The 0x2e305015 The Replace the ONU with
ONU authentication authentication information conflicted SN.
conflicts; hence, the about the ONT is invalid alarm
power-on ONU fails to is generated on the OLT.
go online.
The ONU hardware is If either of the following two Replace the faulty ONU or the
faulty. situations occurs, the ONU optical module of the ONU.
hardware is faulty.
l The LEDs of the ONU are
off when the ONU is
powered on.
l After the ONU is replaced
with another ONU, the new
ONU is auto discovered by
the OLT.

Module
The optical module of the Replace the faulty ONU with a Replace the faulty ONU or the
ONU is abnormal. For normal one. It is found that the optical module of the ONU.
example, the transmit new ONU is auto discovered by
optical power of the the OLT.
optical module is An alternative is to locate the
excessively small or its fault as follows:
receiver sensitivity is
low. l Set the optical module of
the ONU to the continuous
mode, and measure the
transmit optical power by
using the optical power
meter. It is found that the
actual transmit optical
power is beyond the normal
range (1.5 dBm to 5.0
dBm).
l Measure the receive optical
power of the ONU by using
the optical power meter. It
is found that the actual
receive optical power is
within the normal range
(-27 dBm to -8 dBm).
The Patch cord of the Check the Patch cord of the Replace the Patch cord of the
ONU is broken or bent ONU. It is found that the Patch ONU.
excessively. cord is broken or bent
excessively.
Step 5 Record the results of the preceding steps in the form for reporting a fault, fill in the form
completely, and then submit the form to Huawei for technical support.
Step 6 The fault is rectified.
----End
Related Topics
7.1.1 Failure to Go Online of an ONU
2.1.1.2 Failure to Recover GPON ONU Configurations

An ONU connected to a GPON port of an OLT can go online successfully, but the queried
Config state of the ONU is displayed as failed by running the display ont info command on
the OLT.

Module
Location Method
NOTE
Configuration recovery refers to a process in which, after an ONU goes online, the OLT issues
configurations to the ONU and then the ONU adjusts its operating parameters based on the issued
configurations.
Fault Judgment Criterion Possible Cause

Scope
OLT ONUs of the same type fail l The configurations issued by the OLT
to recover their mismatch the actual ONU capabilities.
configurations.
ODN A single ONU fails to The optical attenuation is over large or small and
NOTE recover its configurations. the ONU can normally go online but fails to
ODN recover its configurations. The possible causes are
failures as follows:
are
generally l The branch fiber is bent excessively.
caused by l The branch fiber connector is not clean.
large
reflection l Different types of branch fiber connectors are
and interconnected.
attenuatio
n caused
by branch fiber.
improper l The optical splitter is faulty or the connectors
optical on the optical splitter are not clean.
compone
nts, Multiple ONUs connected The optical attenuation is over large or small and
design, or
constructi
to the same PON port of an the ONU can normally go online but fails to
on. OLT fail to recover their recover its configurations. The possible causes are
configurations. as follows:
l The ODN is not properly planned. For
example, the split ratio, network coverage and
attenuation difference are not planned within
the proper ranges.
l The backbone fiber is bent excessively.
l The backbone fiber connector is not clean.
l Different types of backbone fiber connectors
are interconnected.
backbone fiber.
ONU A single ONU fails to l The ONU functions improperly or is faulty.

recover its configurations. l The ONU has been configured at local and the
configurations conflict with configurations
issued by the OLT.

Module
CAUTION
Procedure
Step 1 When Config state of the ONU is displayed as failed, check whether the OLT generates the
following alarm. If such an alarm is generated, clear it and check whether the fault is rectified.
If the fault persists, proceed to Step 2.
l 0x2e21a102 The GPON ONT configuration recovery fails
fails to recover its configurations, go to Step 3.
The configurations Check configurations issued to Modify OLT configurations

issued by the OLT the ONU by the OLT. It is based on actual ONU
mismatch the actual found that some configurations capabilities.
ONU capabilities. are not supported by the ONU.
For example, the number of
GEM ports exceeds the number
supported by the ONU.
still fails to recover its configurations after that, go to Step 4.
not clean.
The optical fiber is bent 1. The return loss points of the Route and bundle the optical
excessively. backbone fiber and branch fiber in a proper manner.
NOTE fiber are abnormal tested by
Optical signals attenuate using the OTDR.
seriously on an optical
2. The optical fiber is bent
small bending radius. excessively onsite.

Module
The optical fiber is not 1. The return loss points of the l If the optical fiber is not
firmly connected or backbone fiber and branch firmly connected, reconnect
different types of optical fiber are abnormal tested by the optical fiber firmly.
fiber connectors are using the OTDR. l If different types of optical
interconnected. 2. Check the optical fiber fiber connectors are
NOTE connectors on site. It is interconnected, replace the
If the optical fiber is not found that the optical fiber incompatible connector
firmly connected or
is not firmly connected or with a compatible one or
fiber connectors are PC connector (blue) and replace relevant devices,
interconnected, the APC connector (green) are such as the optical splitter.
attenuation and reflection interconnected. NOTE
will be excessively large. In the scenario of the CATV
only.
The multi-mode optical 1. Optical signals of the Replace the multi-mode optical
fiber is used. backbone fiber and branch fiber with the single-mode
NOTE fiber attenuate seriously by optical fiber.
If the multi-mode optical using the OTDR.
2. The multi-mode optical
fiber, the optical signal fiber is used onsite. The
attenuates quickly and the multi-mode optical fiber
return loss increases. can be recognized by its
physical features such as its
color.

Module
NOTE plan or GPON. requirements and protocol
determined by the
number of ONUs l The network coverage of
splitters. When an
optical splitter is
connected to the ODN, specification. For example,
attenuation occurs and a board supports a
the split ratio of the maximum of 1:64 split
optical splitter needs to ratio. If the first-level split
be calculated. ratio is 1:8, the second-level
l Protocols specify that is 1:16, the actual split ratio
the receive optical is 1:128. This exceeds the
power of the OLT
specification (1:64).
dB. In addition, the l The optical attenuation
difference between the difference of two optical
maximum optical lines exceeds 15 dB.
power and the
minimum optical
power should not
exceed 15 dB.
NOTE
still fails to recover its configurations after that, go to Step 5.
The ONU has been The management-related ONU Delete the web page
configured at local and configurations such as IP configurations and issue
the configurations address and management mode configurations to the ONU by
conflict with are configured on the web page. the OLT.
configurations issued by
the OLT.

Module
The ONU functions Run the ont reset command to Replace the faulty ONU with a
improperly or is faulty. reset the ONU. It is found that functional one.
the ONU fails to recover its
configurations.
----End
Related Topics
7.1.2 Failure to Recover ONU Configurations
2.1.1.3 GPON ONU Profile Match state is Mismatch

An ONU connected to a GPON port of an OLT can go online successfully, but the queried
Match state of the ONU is displayed as mismatch by running the display ont info command
on the OLT.
Location Method
NOTE
Match state indicates the consistency between the actual ONU capabilities and the capability set (including
the port type and port quantity) configured in the ONU profiles. If an inconsistency exists, Match state is
displayed as mismatch.
In practice, ONUs in the offline state are bulk pre-configured on the OLT to facilitate service provisioning.
An ONU service profile and an ONU line profile are specified during such configurations. The ONU
profiles together can be regarded as a virtual ONU. Subsequent services are configured based on this virtual
ONU. Inconsistency between the capability set configured in the ONU profiles and the actual ONU
capabilities involves the following two situations:
l The configured capability set outmatches the actual ONU capabilities. If the ONU is bound to such
ONU profiles, ONU configurations will fail to be recovered when the ONU goes online.
l The configured capability set undermatches the actual ONU capabilities. In this case, the ONU
capabilities that are not covered by the ONU profiles will fail to be configured or applied.
When the queried Match state of the ONU is displayed as mismatch, locate the fault according
to the following procedure:
1. Check whether the capability set configured in the ONU service profile and line profile
matches the actual ONU capabilities.
CAUTION

Module
Procedure
Step 1 Run the display ont capability command to query the actual ONU capabilities. According to
the data plan, modify the current ONU profiles, or bind matching ONU profiles to the ONU.
l If this problem occurs on all the ONUs of the same type, the configurations of the ONU
profiles may be incorrect.
– If the OLT works in the distributed mode, the profiles that are bound to the ONU cannot
be modified or deleted. In this case, bind matching ONU profiles to the ONU.
– If the OLT works in the profile mode:
1. Run the display ont-srvprofile command to query the information about the ONU
service profile and run the display ont-lineprofile command to query the
information about the ONU line profile.
2. Modify the ONU profiles by referring to Configuring a GPON ONT Profile in the
Commissioning and Configuration Guide.
l If this problem occurs on only one ONU, it is suggested to bind matching ONU profiles to
the ONU.
– If the OLT works in the distributed mode:
1. Run the display ont-profile command to query the current ONU profiles that are
2. If the OLT does not have matching ONU profiles, run the ont-profile add command
to add matching ONU profiles.
3. Run the ont modify command to bind the ONU profiles to the ONU.
– If the OLT works in the profile mode:
1. Run the display ont-srvprofile command to query the information about the ONU
service profile and run the display ont-lineprofile command to query the
information about the ONU line profile.
2. If the OLT does not have matching ONU profiles, add matching ONU profiles by
referring to Configuring a GPON ONT Profile in the Commissioning and
Configuration Guide.
3. In the GPON mode of the OLT, run the ont modify command to bind the ONU
profiles to the ONU.
Step 2 Check whether Match state of the ONU is displayed as match.

l If Match state of the ONU is displayed as match, go to Step 4.
l If Match state of the ONU is displayed as mismatch, proceed to Step 3.
----End
Related Topics
7.1.3 ONU Profile Mismatch

Module
2.1.2 Failure to Auto Discover a GPON ONU

The ONU auto discovery failure is a fault in which an OLT fails to auto discover an ONU after
the ONU is powered on.
Location Method
NOTE
The ONU auto discovery is a feature in which a pre-configured ONU automatically registers with an OLT
after the ONU is powered on; if the OLT does not pre-configure the ONU, the ONU enters the auto
discovery state and waits to be configured by the OLT.
When an OLT fails to auto discover an ONU, locate the fault based on the following fault
symptoms and possible causes.

Scope
OLT A single ONU or some The actual distance between the ONU and OLT
ONUs connected to an exceeds the ranging compensation distance
OLT fail to be auto configured on the OLT.
discovered by the OLT.
All the ONUs connected l The ONU auto discovery function is disabled
to a PON port on an OLT on the PON port.
fail to be auto discovered l The laser on the PON port is disabled.
by the OLT.
l The PON port is faulty.
All the ONUs connected The board or the slot is faulty.

to a board on an OLT fail
to be auto discovered by
the OLT.

ONUs connected to an l The branch fiber connector is not clean.
OLT fail to be auto
discovered by the OLT. l Different types of branch fiber connectors are
interconnected.
branch fiber.
l The ODN is not properly planned. For
example, the split ratio, network coverage and
the proper ranges.
l The optical attenuation of the optical path is
excessively small.
l A branch fiber break occurs.

Module

Scope
All the ONUs connected l The backbone fiber is bent excessively.

to a PON port on an OLT l The backbone fiber connector is not clean.
fail to be auto discovered
by the OLT. l Different types of backbone fiber connectors
are interconnected.
backbone fiber.
l A backbone fiber break occurs.
ONU A single ONU or some l The ONU is not powered on.

ONUs connected to an l A rogue ONU (such as a continuous-mode
OLT fail to be auto ONU) exists on the network and affects other
discovered by the OLT. ONUs.
l The ONU hardware is faulty.
l The optical module of the ONU is faulty.
l The Patch cord of the ONU is broken or bent
excessively.
CAUTION
Procedure
still fails to be auto discovered by the OLT after that, proceed to Step 2.
The ONU auto discovery Run the display port info Run the port ont-auto-find
function is disabled on command to query the command to enable the auto
the PON port. information about the PON discovery function of the PON
port. It is found that Autofind port.
is in the Disable state. NOTE
By default, the ONU auto
discovery function is disabled on
a PON port.

Module
The actual distance Run the display port info Run the port range command
between the ONU and command to query the to adjust the minimum logical
OLT exceeds the ranging minimum logical reach (Min reach and maximum logical
compensation distance distance) and maximum reach so that the actual distance
configured on the OLT. logical reach (Max distance) between the ONU and OLT is
configured for the PON port. It within the ranging
is found that the actual distance compensation distance.
between the ONU and OLT NOTE
exceeds the ranging l By default, the ranging
compensation distance. compensation distance of a
For example, the actual length GPON port is from 0 km to 20
km.
of the optical fiber between the
ONU and OLT is about 25 km, l According to Class B+, the
which exceeds the ranging maximum logical reach of a
GPON port must not exceed
compensation distance of 0-20 60 km, and the difference
km. between the minimum logical
reach and maximum logical
reach must not exceed 20 km.
The laser on the PON Run the display port info Run the port laser-switch
port is disabled. command to query the command to enable the laser on
information about the PON the PON port.
port. It is found that Laser NOTE
switch is in the Off state. By default, the laser on a GPON
port is enabled.
situations occurs, the PON port the PON port or replace the
is faulty. board.
dBm).
the ONU is auto discovered
by the OLT.

Module
The board or the slot is Run the display board Run the board reset command
faulty. command to query the status of to reset the board or change the
the board. It is found that the board to another slot. If the fault
board status is not Normal. persist, replace the board.
NOTE
For details about how to
troubleshoot the faults, see 4.2
Service Board Is in the Failed
State
not clean.
excessively.

Module
firmly connected or
only.
NOTE seriously.
The optical attenuation If either of the following two Add an optical attenuator on the
of the optical path is situations occurs, the optical optical path between the OLT
excessively small. attenuation of the optical path and ONU.
NOTE is excessively small.
l If the optical l Measure the receive optical
attenuation of the power of the ONU by using
optical path is the optical power meter. It
excessively small, the is found that the actual
receive optical power of the
by the ONU will
exceed the overload ONU is greater than -8
optical power of the dBm.
ONU. l Check the optical path
l Such a situation occurs between the OLT and ONU.
usually in labs, where It is found that the optical
the OLT and ONU
attenuation of the optical
may be directly
connected to each path is excessively small.
other through a short The normal attenuation
optical fiber. range is 10-25 dB.

Module
determined by the
splitters. When an
optical splitter is
power of the OLT
power and the
minimum optical
exceed 15 dB.
NOTE
A backbone fiber break 1. Check the backbone fiber Reconnect the backbone
occurs. by using the OTDR. It is optical fiber.
found that a backbone fiber
break occurs.
connected.

Module
A branch fiber break 1. Check the branch fiber by Reconnect the branch optical
occurs. using the OTDR. It is found fiber.
that a branch fiber break
occurs.
connected.
The ONU is not powered Check the power supply of the Restore the power supply of the
on. ONU. It is found that the power ONU.
supply of the ONU fails or is
turned off.
The ONU hardware is If either of the following two Replace the faulty ONU or the
faulty. situations occurs, the ONU optical module of the ONU.
hardware is faulty.
l The LEDs of the ONU are
off when the ONU is
powered on.
l After the ONU is replaced
with another ONU, the new
ONU is auto discovered by
the OLT.

Module
The optical module of the Replace the faulty ONU with a Replace the faulty ONU or the
ONU is abnormal. For normal one. It is found that the optical module of the ONU.
example, the transmit new ONU is auto discovered by
optical power of the the OLT.
optical module is An alternative is to locate the
excessively small or its fault as follows:
receiver sensitivity is
low. l Set the optical module of
the ONU to the continuous
mode, and measure the
transmit optical power by
using the optical power
meter. It is found that the
actual transmit optical
power is beyond the normal
range (-1.5 dBm to +5
dBm).
l Measure the receive optical
power of the ONU by using
the optical power meter. It
is found that the actual
receive optical power is
within the normal range
(-27 dBm to -8 dBm).
The Patch cord of the Check the Patch cord of the Replace the Patch cord of the
ONU is broken or bent ONU. It is found that the Patch ONU.
excessively. cord is broken or bent
excessively.
----End
Related Topics
7.1.4 Failure to Automatically Discover an ONU
2.1.3 GPON ONU Frequently Goes Online and Offline

ONUs connected to a GPON port frequently go online and offline and thus the OLT reports a
large number of ONU LOS alarms and relevant recovery alarms.
Location Method
NOTE
An ONU frequently goes online and offline because the OLT receives weak ONU signals. As a result,
packets exchanged between the OLT and the ONU are lost.

Module
When an ONU frequently goes online and offline, locate the fault based on the following fault
symptoms and possible causes.

Scope
OLT All the ONUs connected to The PON port is faulty.

a PON port on an OLT
frequently go online and
offline.
All the ONUs connected to The board or the slot is faulty.

a board frequently go
online and offline.

NOTE ONUs connected to an l The branch fiber connector is not clean.
ODN OLT frequently go online
failures and offline. l Different types of branch fiber connectors are
are interconnected.
generally
caused by
large branch fiber.
reflection l The ODN is not properly planned. For
and example, the split ratio, network coverage and
attenuatio
n caused
by the proper ranges.
improper l The optical splitter is faulty or the connectors
optical on the optical splitter are not clean.
compone
nts, All the ONUs connected to l The backbone fiber is bent excessively.
design, or
constructi
a PON port on an OLT l The backbone fiber connector is not clean.
on. frequently go online and
offline. l Different types of backbone fiber connectors
are interconnected.
backbone fiber.
ONU A single ONU or some l A rogue ONU (such as a continuous-mode

ONUs connected to an ONU) exists on the network and affects other
OLT frequently go online ONUs.
and offline. l The ONU is restarted repeatedly.
CAUTION

Module
Procedure
Step 1 When the "ONU frequently goes online and offline" alarm is generated, check whether the OLT
generates the following alarms. If such alarms are generated, clear them and check whether the
fault is rectified. If the fault persists, proceed to Step 2.
The following alarms may be generated:
l 0x2e11a001 The feed fiber is broken or OLT can not receive any expected optical signals
(LOS)
l 0x2e112007 The distribute fiber is broken or the OLT cannot receive expected optical
l 0x2e314021 There are illegal incursionary rogue ONTs under the port
l 0x2e314022 The ONT is rogue ONT
l 0x2e112002 The loss of GEM channel delineation (LCDGi) occurs
l 0x2e112003 The signal degrade of ONTi (SDi) occurs
l 0x2e112004 The signal fail of ONTi (SFi) occurs
l 0x2e112006 The loss of frame of ONTi (LOFi) occurs
still fails to function properly after that, proceed to Step 3.
situations occurs, the PON port the PON port or replace the
is faulty. board.
dBm).
the ONU functions
properly.
The board or the slot is All the ONUs connected to a Change the board to another
faulty. board frequently go online and slot. If the fault persist, replace
offline. the board.

Module
not clean.
excessively.
firmly connected or
only.
NOTE seriously.

Module
NOTE
determined by the
splitters. When an
optical splitter is
power of the OLT
power and the
minimum optical
exceed 15 dB.

Module
A rogue ONU (such as a If either of the following two Replace the rogue ONU with a
continuous-mode ONU) situations occurs, a rogue ONU normal one.
exists on the network and exists.
affects other ONUs. l The 0x2e314021 There are
NOTE illegal incursionary rogue
If a rogue ONU exists, the ONTs under the port alarm
ONU that fails to go online
is generated on the OLT.
may be a normal one and
the ONU that can go online l The 0x2e314022 The ONT
may be a rogue one. is rogue ONT alarm is
generated on the OLT.
l Connect the optical fiber of
the OLT port to the optical
power meter for
measurement. If a value can
be read from the optical
power meter, a continuous-
mode ONU or irregular-
mode ONU exists.
The ONU is restarted Check whether the ONU is Replace the ONU or ensure that
repeatedly. faulty or whether the power the power supply of the ONU is
voltage is unstable. normal.
----End
Related Topics
7.1.5 ONU Frequently Goes Online and Offline
2.2 Troubleshooting the FTTH Service (OLT + HG Series

ONT)
and voice (VoIP) services in the GPON access mode in FTTH scenarios. Home gateway (HG)
series ONT includes the HG810a.
2.2.1 Troubleshooting the Internet Access Service

This topic describes how to troubleshoot common faults in the Internet access service, including
the following faults: PPPoE dialup failure, DHCP dialup failure, failure to access the Internet
after successful dialup, Internet access service interruption, and low Internet access rate. The
following uses the bridging ONT as an example to describe how to troubleshoot a fault.

Module
Prerequisites
The ONU and the OLT must communicate with each other normally. If a fault occurs in
communication between the ONU and the OLT, all the services of the ONU are interrupted.
NOTE
The following lists common faults in communication between the ONU and the OLT.
l 2.1.1 GPON ONU Registration Failure
l 2.1.2 Failure to Auto Discover a GPON ONU
l 2.1.3 GPON ONU Frequently Goes Online and Offline
2.2.1.1 Internet Access Failure

A user provisioned with the Internet access service obtains the IP address but fails to obtain
resources in a network (for example, the user fails to open a web page or fails to download a
file).
Context
NOTE
ONTs can be classified into two types: bridging ONT and gateway ONT. The following uses the bridging ONT
as an example. The bridging ONT and gateway ONT have the following difference in the Internet access service:
l Gateway ONT: The ONT serves as a DHCP client for proxy to obtain the public IP addresses of user PCs
and serves as a DHCP server to assign private IP addresses for user PCs.
l Bridging ONT: The ONT transparently transmits all user packets but does not process them.
The following uses the bridging ONT as an example to describe how to troubleshoot a fault.
Figure 2-1 shows an example network of the FTTH Internet access service.
NOTE
If a user fails to obtain the IP address, see 2.2.1.4 PPPoE Dialup Failure or 2.2.1.5 Failure to Obtain an
IP Address in the DHCP Mode to troubleshoot the fault of failing to obtain the IP address.
Figure 2-1 Example network of the FTTH Internet access service
PC (Wi-Fi access)
BRAS
ONT Optical splitter OLT
PC
Residential router
PC
Scope: customer
Scope: ONT Scope: OLT OLT: upper-layer network device
premises equipment

Module
Location Method
When Internet access failure occurs in an FTTH network, locate the fault according to the fault
scope and possible causes, as described in the following table.
Table 2-1 Possible causes of the fault in different scopes

Scope
User-side A single user fails to access l The user fails to obtain the IP address.
device the Internet but other users l The PC is infected by viruses.
connected to the same
ONT access the Internet l The Internet Explorer (IE) of the PC fails.
successfully. l The PC is in slow response because of its long-
term operating.
l The network interface card (NIC) of the PC
malfunctions or fails.
OLT/ None NOTE

ONT Generally, this fault is not caused by the OLT or the
ONT if the IP address is obtained.
Upper- Users connected to l The web page server is faulty.

layer multiple OLTs fail to l The DNS server is faulty.
device access the Internet.
(such as
the web
page
server and
DNS
server)
CAUTION
Procedure
Step 1 Run the display alarm history command to check whether the system generates a line-related
alarm. If an alarm is generated, clear the alarm by referring to the relevant instruction documents.
l If the fault persists even after the alarm is cleared, go to Step 2.
l If the fault is rectified after the alarm is cleared, go to Step 5.
Step 2 Troubleshoot the fault of the user-side device according to the following table. If the Internet
access failure persists, go to Step 3.

Module
The PC is infected by Viruses are found by using the Use the anti-virus software to
viruses. anti-virus software. remove viruses.
The IE of the PC fails. The fault is rectified by Restart the IE or re-install the
restarting the IE or re-installing IE.
the IE.
The PC is in slow The fault is rectified after the Restart the PC.
response because of its PC is restarted.
long-term operating.
The NIC of the PC The fault persists after all the Update the driver of the NIC. If
malfunctions or fails. above-mentioned operations the fault persists, replace the
are performed. NIC.
Step 3 Troubleshoot the fault of the upper-layer device according to the following table. If the Internet
access failure persists, go to Step 4.
The web page server is Another web page can be Check the web page server. If
faulty. visited. the web page server is faulty,
troubleshoot the fault.
The DNS server is faulty. A known web page can be The DNS server fails to resolve
visited by entering its IP the domain name. In this case,
address (such as http:// check the DNS server and
192.168.0.2) to the IE address troubleshoot the fault.
bar.
----End
Related Topics
7.2.1 Failure to Access the Internet
2.2.1.2 Internet Access Service Interruption

This topic describes how to troubleshoot the fault when the Internet access service is interrupted.
Context
NOTE
Internet access service interruption may occur by various causes, for example, the ONT goes offline
frequently and the IP address fails to be obtained.

Module
PC (Wi-Fi access)
BRAS
PC
Residential router
PC
Scope: customer
premises equipment
Location Method
When the Internet access service is interrupted, locate the fault according to the fault scope and
possible causes, as described in the following table.

Scope
User-side The Internet access service l The PC is infected by viruses.

device of a single user is l A network device such as the residential router
interrupted but the Internet between the ONT and the PC is faulty.
access service of other
users connected to the l The driver of the network interface card (NIC)
same ONT is normal. on the PC is damaged or the hardware of the
NIC is faulty.
ONT The Internet access service l Lines of an ONT fail, for example, the ONT
of multiple users fails to be registered with the OLT, the ONT
connected to the same fails to be automatically discovered by the
ONT is interrupted. OLT, and the ONT goes offline frequently.
l The wireless signals received by the PC using
Wi-Fi access are of poor quality.
l The hardware of the ONT malfunctions or is
faulty.

Module

Scope
OLT The Internet access service l Packet loss occurs because of incorrect
of users on multiple ONTs configurations, such as link aggregation and
connected to the same OLT port negotiation between the OLT and the port
is interrupted. of the upper-layer device.
l Packet loss occurs because of a large volume
of traffic on the upstream port.
l MAC address transfer occurs because a
network encounters a loop or a device
improperly forwards packets.
l The hardware, such as the optical module,
service board, and control board of the OLT
malfunctions or is faulty.
Upper- The Internet access service l Packet loss occurs on the upper-layer device.
layer of users connected to
device multiple OLTs is
(including interrupted.
the
convergen
ce switch,
router, and
BRAS)
CAUTION
Procedure
Step 2 Troubleshoot the fault of the user-side device according to the following table. If the Internet
access service interruption persists, go to Step 3.

Module
A network device such as The fault is rectified after the Replace the device between the
the residential router PC is directly connected to an ONT and the PC.
between the ONT and the ONT.
PC is faulty.
The driver of the NIC on The fault persists after all the Update the driver of the NIC. If
the PC is damaged or the above-mentioned operations the fault persists, replace the
hardware of the NIC is are performed. NIC.
faulty.
Step 3 Troubleshoot the fault of the ONT according to the following table. If the Internet access service
interruption persists, go to Step 4.
Lines of an ONT fail, for The Run state and Config For details about how to
example, the ONT fails state of the ONT are abnormal troubleshoot the fault, see
to be registered with the in the display ont info "ONU Abnormal State."
OLT, the ONT fails to be command output.
automatically discovered
by the OLT, and the ONT
goes offline frequently.
The wireless signals The quality of signals checked Adjust the position of the PC
received by the PC using on the PC is poor. and ensure that the quality of
Wi-Fi access are of poor signals exchanged between the
quality. PC and the ONT meets the
requirement.
The hardware of the The fault is rectified after the Restart the ONT. If the fault
ONT malfunctions or is ONT is restarted or replaced. persists, replace the ONT.
faulty.
Step 4 Troubleshoot the fault of the OLT according to the following table. If the Internet access service
interruption persists, go to Step 5.
Packet loss occurs The link aggregation, port Modify the configurations of
because of incorrect protection pair, and port the OLT or the upper-layer
configurations, such as negotiation configurations of interconnected device to
link aggregation and port the OLT are different from ensure that configurations of
negotiation between the those of the upper-layer the OLT are the same as those
OLT and the port of the interconnected device. of the upper-layer
upper-layer device. interconnected device.
NOTE
Packets will be forwarded to
a non-destination port or
discarded because of
incorrect configurations of
the OLT's upstream port.

Module
Packet loss occurs If Number of discarded In this case, share traffic with
because of a large volume frames increases in the output other ports or increase the rate
of traffic on the upstream of the display port statistics of the port.
port. command that is executed
multiple times, packet loss
occurs on the upstream port
due to the large traffic.
MAC address transfer MAC address transfer occurs 1. Run the ring check
occurs because a network on the upstream port or other enable command to check
encounters a loop or a service ports in the output of whether a ring network is
device improperly the display location command generated.
forwards packets. that is executed multiple times 2. Capture packets to locate
for querying the MAC address the device that improperly
of the user encounters the fault. forwards packets.
NOTE
Enable the anti-MAC spoofing
function to prevent MAC address
transfer on service ports.
The hardware, such as the The fault is rectified by Exclude hardware faults by
optical module, service resetting the service board, resetting the service board,
board, and control board replacing the optical module, replacing the optical module,
of the OLT malfunctions or restarting the system. or restarting the system.
or is faulty. NOTE NOTE
If the fault recurs after a period of If multiple devices have the same
time, the software fails. In this hardware fault, contact Huawei
case, contact Huawei technical technical support engineers for
support engineers for help. help.
Step 5 Troubleshoot the fault of the upper-layer device according to the following table. If the Internet
access service interruption persists, go to Step 6.
Packet loss occurs on the Packet loss is found in the Capture packets along the
upper-layer device. output of the ping command service route section by section
for testing the quality of the to locate the device that
link between the OLT and the discards packets or improperly
network server. forwards packets.
----End
Related Topics
7.2.2 Going Offline Frequently

Module
2.2.1.3 Low Internet Access Rate

This topic describes how to troubleshoot the fault when the actual Internet access rate of a user
is far lower than the applied rate.
Context
PC (Wi-Fi access)
BRAS
PC
Residential router
PC
Scope: customer
premises equipment
Location Method
When the Internet access rate is low, locate the fault according to the fault scope and possible
causes, as described in the following table.

Scope
User-side The Internet access rate of l The PC is infected by viruses.

device a single user is low but the l The Internet Explorer (IE) of the PC fails.
Internet access rate of other
users connected to the l The network interface card (NIC) of the PC is
same ONT is normal. faulty or the PC runs for a long time.
l The Internet connection of the PC is abnormal
or is prohibited.
l A network device such as the residential router
between the ONT and the PC is faulty.
ONT The Internet access rate of l The wireless signals received by the PC using
multiple users connected to Wi-Fi access are of poor quality.
the same ONT is low. l The hardware of the ONT malfunctions or is
faulty.

Module

Scope
OLT The Internet access rate of l The limited rate of the OLT is lower than the
users on multiple ONTs provisioned rate.
connected to the same OLT l Packet loss occurs because of a large volume
is low. of traffic on the upstream port.
l The OLT has unknown traffic, occupying user
bandwidth.
l The hardware, such as the optical module,
service board, and control board of the OLT
malfunctions or is faulty.
Upper- The Internet access rate of l The limited rate of the BRAS is lower than the
layer users of multiple OLTs is provisioned rate.
device low. l Packet loss occurs on the upper-layer device or
(including the delay is excessive long.
the
convergen
ce switch,
router, and
BRAS)
CAUTION
Procedure
Step 2 Troubleshoot the fault of the user-side device according to the following table. If the low Internet
access rate persists, go to Step 3.
The Internet Explorer The fault is rectified by Restart the IE or re-install the
(IE) of the PC fails. restarting the IE or re-installing IE.
the IE.

Module
The PC is in slow The fault is rectified after the Restart the PC.
response because of its PC is restarted.
long-term operating.
The NIC of the PC The fault persists after all the Update the driver of the NIC. If
malfunctions or fails. above-mentioned operations the fault persists, replace the
are performed. NIC.
A network device such as The fault is rectified after the Replace the device between the
the residential router PC is directly connected to an ONT and the PC.
between the ONT and the ONT.
PC is faulty.
Step 3 Troubleshoot the fault of the ONT according to the following table. If the low Internet access
rate persists, go to Step 4.
The wireless signals The quality of signals checked Adjust the position of the PC
received by the PC using on the PC is poor. and ensure that the quality of
Wi-Fi access are of poor signals exchanged between the
quality. PC and the ONT meets the
requirement.
The hardware of the The fault is rectified after the Restart the ONT. If the fault
ONT malfunctions or is ONT is restarted or replaced. persists, replace the ONT.
faulty.
Step 4 Troubleshoot the fault of the OLT according to the following table. If the low Internet access
rate persists, go to Step 5.
The limited rate of the The available rate is lower than Modify the configurations to
OLT is lower than the the applied rate by checking ensure that the available rate
provisioned rate. the rate limit configurations of reaches the applied rate. For
NOTE the OLT. details, see Configuring GPON
The rate limit scheme is NOTE Rate Limitation.
formulated in service Keywords of main rate limit
planning. Rates of multiple nodes are displayed as follows:
nodes will be limited if the
l Service port: service-port
rate limit scheme is not
clear. In this case, the l ONT port: port eth
available rate is the lowest l ONT T-CONT: tcont
limited rate.
l PON port: car-port
l Upstream port: line-rate

Module
Packet loss occurs If Number of discarded In this case, share traffic with
because of a large volume frames increases in the output other ports or increase the rate
of traffic on the upstream of the display port statistics of the port.
port. command that is executed
multiple times, packet loss
occurs on the upstream port
due to the large traffic.
The OLT has unknown The unknown traffic exists Capture packets to analyze the
traffic, occupying user because there is a large volume source of the unknown traffic
bandwidth. of traffic when no service is to troubleshoot the fault.
configured by running the NOTE
display port traffic command More than 200 users in a VLAN
to query the data traffic of the may lead to an oversize broadcast
upstream port or the service domain. Then, a broadcast storm
will occur in peak hours. As a
port.
result, the Internet access rate of
users in the VLAN is low.
The hardware, such as the The fault is rectified by Exclude hardware faults by
optical module, service resetting the service board, resetting the service board,
board, and control board replacing the optical module, replacing the optical module,
of the OLT malfunctions or restarting the system. or restarting the system.
or is faulty. NOTE NOTE
If the fault recurs after a period of If multiple devices have the same
time, the software fails. In this hardware fault, contact Huawei
case, contact Huawei technical technical support engineers for
support engineers for help. help.
Step 5 Troubleshoot the fault of the upper-layer device according to the following table. If the low
Internet access rate persists, go to Step 6.
The limited rate of the The rate limited on the BRAS Modify the limited rate to
BRAS is lower than the is lower than the applied rate. ensure that the rate meets the
provisioned rate. applied rate.
Packet loss occurs on the Packet loss or excessive long Capture packets along the
upper-layer device or the delay is found in the output of service route section by section
delay is excessive long. the ping command for testing to locate the device that
the quality of the link between discards packets or has
the OLT and the network excessive long delay.
server.
----End

Module
Related Topics
7.2.3 Low Internet Access Rate
2.2.1.4 PPPoE Dialup Failure

This topic describes how to troubleshoot the fault when a user encounters errors (such as error
678) during PPPoE dialup to access the Internet and consequently the IP address cannot be
obtained.
Context
NOTE
PPPoE dialup can be initiated by the user PC, residential router, or ONT. This section uses the PPPoE
dialup initiated by the user PC as an example to describe how to troubleshoot common faults.
PC (Wi-Fi access)
BRAS
PC
Residential router
PC
Scope: customer
premises equipment
Location Method
NOTE
l If the OLT supports the PPPoE dialup emulation, you can run the PPPoE dialup emulation command
on the OLT for the OLT to emulate a user to initiate PPPoE dialup. If the emulation dialup succeeds,
you can preliminarily judge that the OLT and the upper-layer device are normal.
l If the ONT supports the PPPoE dialup emulation, you can run the PPPoE dialup emulation command
on the OLT for the ONT to emulate a user to initiate PPPoE dialup. If the emulation dialup succeeds,
you can preliminarily judge that the ONT, OLT, and the upper-layer device are normal.
When "PPPoE Dialup Failure" occurs, locate the fault based on the following fault symptoms
and possible causes.

Module
Table 2-4 Possible causes of PPPoE dialup failure

Scope
User-side Dialup of a single user PC l The PPPoE dialup software is not installed
device fails but other user PCs of correctly or does not run properly.
the same ONT are normal. l The network connection of the user PC is
abnormal or disabled.
l The PPPoE user name or password is incorrect.
l The network device (such as residential router)
between the ONT and the user PC has
problems.
l Configurations for the authentication mode or
encryption mode on the PC (Wi-Fi access) are
different from the configurations on the ONT.
l The driver of the user PC NIC (network
interface card) is damaged or the NIC hardware
is faulty.
ONT Dialup of multiple user l The ONT encounters line faults such as
PCs of the same ONT fails. registration failure, failure to be automatically
discovered, and frequent offline.
l The WLAN function of the ONT is disabled.
l The SSID broadcast function of the ONT is
disabled and the Wi-Fi terminal cannot search
for the SSID.
l The ONT hardware is abnormal or faulty.

Module

Scope
OLT Dialup of multiple ONTs l Configuration problems of the VLAN

of the same OLT fails. translation in the OLT and ONT traffic
streams:
– VLAN tag translation on the ONT
– VLAN tag translation on the OLT
– Configuration for the native VLAN of the
OLT upstream port and the ONT user port
– Configuration for the mappings between
user VLAN, ONT port, ONT ID, GEM
port, service VLAN, and upstream port
l The PITP protocol configuration is different on
the OLT and the BRAS.
l The number of MAC addresses in the service
port access reaches the maximum number of
learned MAC addresses.
l When PPPoE VMAC is set to be in the single-
mac mode, the number of PPPoE sessions
reaches the configured maximum number of
PPPoE sessions for the port.
l The OLT discards the interaction packets
between the user PC and the BRAS.
l The OLT hardware (optical module, service
board, or control board) is abnormal or faulty.
Upper- Dialup of users of multiple l The user name or account is not configured
layer OLTs fails. properly on the BRAS.
device l The BRAS restricts the number of connection
(BRAS, users.
convergen
ce switch, l In the link between the OLT and the BRAS,
or router) some device discards the interaction packets
between the user PC and the BRAS.
CAUTION
Procedure
Step 1 When "PPPoE Dialup Failure" occurs, run the display alarm history command to check whether
the line-related alarm is generated in the system. If the related alarm is generated, clear the alarm
by referring to the corresponding alarm guidance.

Module

Step 2 Handle the user-side device problems based on the following table. If dialup still fails after these
problems are solved, go to Step 3.
The PPPoE dialup "Error 602", "error 605", "error Uninstall and then reinstall the
software is not installed 606", "error 608", "error 609", PPPoE dialup software.
correctly or does not run "error 611", "error 617", or NOTE
properly. "error 633" is returned during In the Windows operating system
dialup. After the PPPoE dialup (OS), set up a network connection
software is uninstalled and then again to reinstall the PPPoE dialup
software.
reinstalled, the dialup
succeeds.
The network connection "Error 606" or "error 617" is Rectify the network connection
of the user PC is returned during dialup. Check of the user PC to ensure that the
abnormal or disabled. the network connection of the connection is in the normal
user PC and find that the state.
connection is in the disabled NOTE
state or in another abnormal In the Windows OS, after the user
state. PC is connected to the ONT, no
configuration is required and the
network will automatically enter
the normal state.
The PPPoE user name or "Error 691" is returned during Use the correct user name and
password is incorrect. dialup. password.
The network device Connect the user PC directly to Replace the network device
(such as residential the ONT and dialup can between the ONT and the user
router) between the ONT succeed. PC.
and the user PC has
problems.
Configurations for the Connect the PC to the ONT in Modify the configurations for
authentication mode or the wireless mode and check the authentication mode and
encryption mode on the the configurations of the ONT encryption mode on the PC
PC (Wi-Fi access) are and PC (Wi-Fi access). (Wi-Fi access) to be the same as
different from the Configurations for the the configurations on the ONT.
configurations on the authentication mode or NOTE
ONT. encryption mode on the PC are If the OS is Windows 2003 and the
different from the patch version is Service Pack 2,
configurations on the ONT. only the Tkip encryption mode is
supported. The patch version must
be upgraded to Service Pack 3 to
support the Tkip, Tkip&Aes, and
Aes encryption modes.
The driver of the user PC After all the preceding possible Reinstall the NIC driver. If the
NIC (network interface causes are excluded, dialup still fault persists, replace the NIC.
card) is damaged or the fails.
NIC hardware is faulty.

Module
Step 3 Handle the ONT problems based on the following table. If dialup still fails after these problems
are solved, go to Step 4.
The ONT encounters line On the OLT, run the display Handle the problem by
faults such as registration ont info command to query the referring to the section "ONU
failure, failure to be ONT information. The running Status Abnormality".
automatically status (Run state) and
discovered, and frequent configuration status (Config
offline. state) are abnormal.
The WLAN function of The WLAN indicator of the Press and hold the WLAN
the ONT is disabled. ONT is not in the always on button or set the WLAN
state. function on the ONT web page
to enable the WLAN function.
The SSID broadcast The PC cannot search for the Log in to the web page of the
function of the ONT is SSID of the wireless network. ONT and enable the SSID
disabled and the Wi-Fi broadcast function.
terminal cannot search NOTE
for the SSID. l By default, the SSID
broadcast function is enabled.
l To ensure that the wireless
network is not embezzled, you
must manually input on the PC
the same SSID that is set on
the ONT if the SSID broadcast
function of the ONT is
disabled.
The ONT hardware is Restart or replace the ONT, and Restart the ONT. If the fault
abnormal or faulty. dialup can succeed. persists, replace the ONT.
Step 4 Handle the OLT problems based on the following table. If dialup still fails after these problems
are solved, go to Step 5.

Module
Configuration problems l If the user once succeeded Configure the data correctly
of the traffic stream: in dialup, run the display based on the data plan.
l VLAN tag translation log command to check the
on the ONT system log and find that the
problem occurs because
l VLAN tag translation the data configuration is
on the OLT modified.
l Configuration for the l If the user never succeeded
native VLAN of the in dialup, check the data
OLT upstream port configuration based on the
and the ONT user port data plan and find that the
l Configuration for the data configuration is
mappings between different from the plan.
user VLAN, ONT
port, ONT ID, GEM
port, service VLAN,
and upstream port
The PITP protocol l Run the display pitp See the section "Configuring
configuration is different config command to query Anti-Theft and Roaming of
on the OLT and the whether global PITP is User Account Through PITP"
BRAS. enabled. The query result is and configure PITP based on
NOTE different from the data the data plan.
After the PITP function is plan.
enabled, the user device
information is carried in a
l When PITP is enabled, run
PPPoE packet and the the display pitp permit-
PPPoE packet is then forwarding service-port
authenticated on the BRAS. command to check whether
The dialup succeeds only the OLT allows the user-
when the device side PPPoE packet to carry
information (added by OLT
or by a user-side device) is
the device information.
the same as that configured The query result is different
on the BRAS. from the data plan.
The number of users in the Run the display mac-address Run the mac-address max-
service port access service-port command to mac-count command to
reaches the maximum query the number of MAC reconfigure the maximum
number of learned MAC addresses already learned by number of learned MAC
addresses. the service port, run the addresses for this traffic
display mac-address max- stream, and increase the
mac-count service-port number of access users on this
command to query the service port.
maximum number of learned NOTE
dynamic MAC addresses, and By default, the maximum number
find that the number of already of learned MAC addresses is not
learned MAC addresses restricted.
reaches the maximum number
of learned MAC addresses.

Module
When PPPoE VMAC is Run the display pppoe mac- Run the pppoe max-session-
set to be in the single-mac mode command to query the count command to set the
mode, the number of current MAC address maximum number of PPPoE
PPPoE sessions reaches allocation mode for the PPPoE sessions for a service port to 8
the configured maximum user and find that the mode is (the largest value).
number of PPPoE single-mac. NOTE
sessions for the port. When the MAC address
NOTE allocation mode of VMAC is
If the number of online single-mac, a service port allows
PPPoE sessions is larger a maximum of eight PPPoE
than the preset maximum sessions. Therefore, make a
number for the port, the proper plan before network
system does not allow a new deployment to prevent that the
PPPoE session to be set up. number of online PPPoE sessions
exceeds eight.
The OLT discards the Capture packets for analysis Based on the packet capture
interaction packets on the OLT user port and result and the device
between the user PC and upstream port, and find that configuration, analyze the
the BRAS. packets are lost. cause for packet loss and take
measures to rectify the fault.
NOTE
Possible causes of OLT packet
loss are as follows:
l Packets are filtered due to the
ACL configuration problem.
l Packets are discarded due to
the problems such as
broadcast storm, extremely
large traffic, and port rate
limitation on the OLT.
The OLT hardware Perform operations such as Perform operations such as

(optical module, service resetting the service board, resetting the service board,
board, or control board) is replacing the optical module, replacing the optical module,
abnormal or faulty. and restarting the system, and and restarting the system to
the fault is rectified. rectify the hardware problems.
NOTE NOTE
If the fault occurs again after a If multiple devices have the same
period of time, the software has hardware problem, contact
problems and you need to contact Huawei engineers to analyze the
Huawei engineers to carry out hardware fault and fundamentally
further analysis. rectify the hardware fault.
Step 5 Handle the upper-layer device problems based on the following table. If dialup still fails after
these problems are solved, go to Step 6.

Module
The number of users Check the maximum number Expand the capacity of the
reaches that maximum of connections allowed by the BRAS.
number of connected BRAS and the number of
users supported by the already connected users, and
BRAS. find that the number of already
connected users reaches the
maximum number of
connections.
The user name or account Check the data configuration Configure the user name and
is not configured properly of the BRAS and find that the password correctly on the
on the BRAS. user name and password of the BRAS.
user with problems are not
configured or are configured
incorrectly.
In the link between the Run the ping command to test Capture packets section by
OLT and the BRAS, some the quality of the link between section, locate the device
device discards the the OLT and the network where packets are discarded or
packets sent by the user server, and find packet loss. forwarded incorrectly, and
PC. rectify the problem.
----End
2.2.1.5 Failure to Obtain an IP Address in the DHCP Mode

This topic describes how to troubleshoot the fault when a user uses the DHCP mode to access
the Internet but fails to obtain an IP address.
Context
NOTE
The DHCP client can be the user PC, IPTV set top box, IP phone, residential router, or ONT. This section
uses the user PC that functions as the DHCP client as an example to describe how to troubleshoot common
faults.

Module
PC (Wi-Fi access)
DHCP server
IP phone ONT Optical splitter OLT
Set top box

TV
Residential router
PC
Scope: customer
premises equipment
Location Method
When "Failure to Obtain an IP Address in the DHCP Mode" occurs, locate the fault based on
the following fault symptoms and possible causes.
Table 2-5 Possible causes of failure to obtain an IP address in the DHCP mode

Scope
User-side A single user PC fails to l The IP obtaining mode of the PC is not set to
device obtain an IP address but "Obtain an IP address automatically."
other user PCs of the same l The network connection of the user PC is
ONT are normal. abnormal or disabled.
l The network device (such as residential router)
between the ONT and the user PC has
problems.
l Configurations for the authentication mode or
encryption mode on the PC (Wi-Fi access) are
different from the configurations on the ONT.
l The driver of the user PC NIC (network
interface card) is damaged or the NIC hardware
is faulty.
ONT Multiple user PCs of the l The ONT encounters line faults such as
same ONT fail to obtain IP registration failure, failure to be automatically
addresses. discovered, and frequent offline.
l The WAN port of an ONT is not created.
l The SSID broadcast function of the ONT is
disabled and the Wi-Fi terminal cannot search
for the SSID.
l The ONT hardware is abnormal or faulty.

Module

Scope
OLT Multiple ONTs of the same l Configuration problems of the VLAN

OLT fail to obtain IP translation in the OLT and ONT traffic
addresses. streams:
– VLAN tag translation on the ONT
– VLAN tag translation on the OLT
– Configuration for the native VLAN of the
OLT upstream port and the ONT user port
– Configuration for the mappings between
user VLAN, ONT port, ONT ID, service
VLAN, and upstream port
l Configurations for the DHCP option 82
function on the OLT are different from the
configurations on the DHCP server.
l The number of MAC addresses in the service
port access reaches the maximum number of
learned MAC addresses.
l The OLT enables a special function (such as
anti-MAC spoofing) and modifies the RAIO
information in the DHCP option 82 packet.
l The OLT hardware (optical module, service
board, or control board) is abnormal or faulty.
Upper- Users of multiple OLTs fail l The IP address pool resources of the DHCP
layer to obtain IP addresses. server are exhausted.
device l In the link between the OLT and the DHCP
(DHCP server, some device discards the packets sent
server, by the user PC.
convergen
ce switch, l The OLT enables a special function (such as
or router) anti-MAC spoofing) and modifies the RAIO
l The upper-layer device modifies the
CAUTION
Procedure
Step 1 When "Failure to Obtain an IP Address in the DHCP Mode" occurs, run the display alarm
history command to check whether the line-related alarm is generated in the system. If the related
alarm is generated, clear the alarm by referring to the corresponding alarm guidance.

Module

Step 2 Handle the user-side device problems based on the following table. If the IP address still cannot
be obtained after these problems are solved, go to Step 3.
The IP obtaining mode of Check the properties of the Set the property of the network
the PC is not set to network connection and find connection to "Obtain an IP
"Obtain an IP address that the IP obtaining mode is address automatically."
automatically." static IP address. NOTE
In the Windows operating system
(OS), the default property of the
network connection is "Obtain an
IP address automatically."
The network connection Check the network connection Rectify the network connection
of the user PC is of the user PC and find that the of the user PC to ensure that the
abnormal or disabled. connection is in the disabled connection is in the normal
state or in another abnormal state.
state. NOTE
In the Windows OS, after the user
PC is connected to the ONT, no
configuration is required and the
network will automatically enter
the normal state.
The network device Connect the user PC directly to Replace the network device
(such as residential the ONT and an IP address can between the ONT and the user
router) between the ONT be obtained. PC.
and the user PC has
problems.
Configurations for the Connect the PC to the ONT in Modify the configurations for
authentication mode or the wireless mode and check the authentication mode and
encryption mode on the the configurations of the ONT encryption mode on the PC
PC (Wi-Fi access) are and PC (Wi-Fi access). (Wi-Fi access) to be the same as
different from the Configurations for the the configurations on the ONT.
configurations on the authentication mode or NOTE
ONT. encryption mode on the PC are If the OS is Windows 2003 and the
different from the patch version is Service Pack 2,
configurations on the ONT. only the Tkip encryption mode is
supported. The patch version must
be upgraded to Service Pack 3 to
support the Tkip, Tkip&Aes, and
Aes encryption modes.
The driver of the user PC After all the preceding possible Reinstall the NIC driver. If the
NIC (network interface causes are excluded, dialup still fault persists, replace the NIC.
card) is damaged or the fails.
NIC hardware is faulty.
Step 3 Handle the ONT problems based on the following table. If the IP address still cannot be obtained
after these problems are solved, go to Step 4.

Module
The ONT encounters line On the OLT, run the display Handle the problem by
faults such as registration ont info command to query the referring to the section "ONU
failure, failure to be ONT information. The running Status Abnormality".
automatically status (Run state) and
discovered, and frequent configuration status (Config
offline. state) are abnormal.
The WLAN function of The WLAN indicator of the Press and hold the WLAN
the ONT is disabled. ONT is not in the always on button or set the WLAN
state. function on the ONT web page
to enable the WLAN function.
The SSID broadcast The PC cannot search for the Log in to the web page of the
function of the ONT is SSID of the wireless network. ONT and enable the SSID
disabled and the Wi-Fi broadcast function.
terminal cannot search NOTE
for the SSID. l By default, the SSID
broadcast function is enabled.
l To ensure that the wireless
network is not embezzled, you
must manually input on the PC
the same SSID that is set on
the ONT if the SSID broadcast
function of the ONT is
disabled.
The ONT hardware is Restart or replace the ONT, and Restart the ONT. If the fault
abnormal or faulty. an IP address can be obtained. persists, replace the ONT.
Step 4 Handle the OLT problems based on the following table. If the IP address still cannot be obtained
after these problems are solved, go to Step 5.
Configuration problems l If the user once obtained an Configure the data correctly
of the traffic stream: IP address successfully, based on the data plan.
l VLAN tag translation run the display log
on the ONT command to check the
system log and find that the
l VLAN tag translation problem occurs because
on the OLT the data configuration is
l Configuration for the modified.
native VLAN of the l If the user never obtained
OLT upstream port an IP address successfully,
and the ONT user port check the data
l Configuration for the configuration based on the
mappings between data plan and find that the
user VLAN, ONT data configuration is
port, ONT ID, service different from the plan.
VLAN, and upstream
port

Module
Configurations for the l Run the display dhcp Refer to "Configuring Anti-
DHCP option 82 function option82 config command Theft or Roaming of User
on the OLT are different to query whether DHCP Accounts Through DHCP" and
from the configurations option 82 is enabled configure parameters based on
on the DHCP server. globally. The query result the data plan.
NOTE is different from the data NOTE
l After the DHCP option
plan. Pay attention to the following
data plan:
82 function is enabled, l When DHCP option 82 is
the device information enabled and you run the l Whether the DHCP server
is carried in a DHCP requires the DHCP packet to
display dhcp-option82
packet and the DHCP carry the option 82
packet is then permit-forwarding information.
authenticated on the service-port command to
l Whether the option 82
DHCP server. The check whether the OLT information is added by the
authentication succeeds allows the user-side DHCP user device or the OLT.
only when the device packet to carry the device
information (added by l The option 82 information
information, the query cannot be added repeatedly.
OLT or by a user-side
device) is the same as result is different from the
that configured on the data plan.
DHCP server. TIP
l If the DHCP server Run the display dhcp l2
authenticates the user statistics command to query the
based on the added statistics of the Layer 2 DHCP
information of the user packets. In the statistics,
device, run the dhcp- "Number of received packets
option82 permit- with untrusted option82"
forwarding service- indicates that the OLT receives
port 100 enable the DHCP packet with the
command on the OLT information added by the user
for the device to allow device.
the DHCP packet with
the information added
by the user device to
pass (assume that the
traffic stream ID of the
user is 100).
The number of users in the Run the display mac-address Run the mac-address max-
service port access service-port command to mac-count command to
reaches the maximum query the number of MAC reconfigure the maximum
number of learned MAC addresses already learned by number of learned MAC
addresses. the service port, run the addresses for this traffic
display mac-address max- stream, and increase the
mac-count service-port number of access users on this
command to query the service port.
maximum number of learned NOTE
dynamic MAC addresses, and By default, the maximum number
find that the number of already of learned MAC addresses is not
learned MAC addresses restricted.
reaches the maximum number
of learned MAC addresses.

Module
The OLT enables a special Capture the DHCP option 82 Analyze the captured packets,
function (such as anti- packets that enter the OLT and find out the cause for the
MAC spoofing) and that are forwarded out of the packet modification, and
modifies the RAIO OLT. Analyze the packets and adjust the configuration
information in the DHCP find that the packet contents accordingly.
option 82 packet. are modified. NOTE
NOTE After enabling anti-MAC
If the DHCP server verifies spoofing, the OLT will add the
the RAIO information in the 802.1q information flag to the
DHCP option 82 packet and low 16 bits of the XID in the
the RAIO information is DHCP DISCOVER packets sent
modified by the OLT or by users. If the DHCP server does
other devices, the RAIO not allow the information to be
information cannot pass the added to the XID parameter, anti-
verification and an IP MAC spoofing must be disabled.
address fails to be obtained.
The OLT hardware Perform operations such as Perform operations such as

(optical module, service resetting the service board, resetting the service board,
board, or control board) is replacing the optical module, replacing the optical module,
abnormal or faulty. and restarting the system, and and restarting the system to
the fault is rectified. rectify the hardware problems.
NOTE NOTE
If the fault occurs again after a If multiple devices have the same
period of time, the software has hardware problem, contact
problems and you need to contact Huawei engineers to analyze the
Huawei engineers to carry out hardware fault and fundamentally
further analysis. rectify the hardware fault.
Step 5 Handle the upper-layer device problems based on the following table. If the IP address still
cannot be obtained after these problems are solved, go to Step 6.
The IP address pool Check the number of Expand the capacity of the
resources of the DHCP remaining IP addresses on the DHCP server.
server are exhausted. DHCP server and find that the
number is 0.
In the channel between the Run the ping command to test Capture packets section by
OLT and the DHCP the quality of the link between section, locate the device
server, some device the OLT and the network where packets are discarded or
discards the packets sent server, and find packet loss. forwarded incorrectly, and
by the user PC. rectify the problem.
The upper-layer device Capture the DHCP option 82 Analyze the captured packets,
modifies the information packets that enter the device find out the cause for the
in the DHCP option 82 and that are forwarded out of packet modification, and
packet. the device. Analyze the adjust the configuration
packets and find that the accordingly.
packet contents are modified.

Module
----End
Related Topics
7.2.5 Failure to Obtain an IP Address in the DHCP Mode
2.2.2 IPTV Service Failure

This topic describes how to troubleshoot IPTV service faults in a GPON FTTH network.
Common IPTV service faults include multicast users failing to go online, blank screen after
program ordering, pixelation in a multicast program, abnormal interruption of a multicast
program, and long program switching time.
Prerequisites
l The ONT and OLT communicate with each other properly. If a communication fault occurs
between the ONT and OLT, all the services on the ONT are interrupted. In this case,
troubleshoot the fault first by referring to the methods described in other topics according
to the specific fault symptom.
NOTE
The following lists common communication faults between the ONT and the OLT.
l ONT Registration Failure
l Failure to Automatically Discover an ONT
l ONU Frequently Goes Online and Offline
l The multicast mode of an ONT is the dynamic controllable mode. That is, multicast-
mode of an ONT is set to olt-control on the OLT. The OLT configures and manages the
users and programs of an ONT. That is, the ONT does not manage its multicast users and
programs.
Precautions
The described methods for troubleshooting multicast service faults are applicable only to
dynamic-controllable-mode ONTs.
2.2.2.1 Multicast User Fails to Go Online

This topic describes how to troubleshoot the fault when a multicast user fails to order any
program because the multicast user fails to go online (the queried user status is offline or
block on the OLT). When such a fault occurs in an FTTH network, locate and troubleshoot the
fault by using the following location methods and troubleshooting procedure.
Location Method
When a multicast user in an FTTH network is blocked, run the undo igmp user block command
to unblock the user.
When a multicast user in an FTTH network is offline, enable the OLT debugging function and
check whether the OLT receives a report packet from the multicast user for ordering the specified
program.

Module
l If the OLT receives the report packet, the multicast link is normal but the OLT fails to
create a corresponding multicast entry. This is generally caused by incorrect multicast
configurations on the OLT.
l If the OLT does not receive the report packet, the multicast link fails. This is mainly caused
by incorrect software configurations of the OLT and hardware faults of user terminals.
Table 2-6 provides more details about using the location methods.
Table 2-6 Location methods

Scope
OLT The OLT receives the l The program ordered by the multicast user is
report packet. not included in the MVLAN to which the
multicast user belongs.
l No upstream port is configured in the MVLAN
to which the multicast user belongs.
l The multicast user does not have the
permission to watch the program.
l The maximum multicast bandwidth of the user
is lower than the bandwidth required by the
ordered program.
permission to order certain types of programs
(such as HDTV).
The OLT is faulty if both l The IGMP function is disabled in the MVLAN
the following situations to which the OLT belongs. In this case, all users
occur: in the MVLAN fail to go online.
l The OLT does not l Multicast configurations of the ONT ETH port
receive the report are incorrect. For example, the native VLAN
packet. is not configured on the ONT.
l The user fails to go
online from the
beginning or fails to go
online after
configuration
modification.
ONT and The ONT and user terminal l The set top box (STB) is faulty.
user are faulty if both the l The ONT is faulty.
terminal following situations occur:
l The physical line between the STB and ONT
l The OLT does not is faulty.
receive the report
packet.
l The user can go online
at first but fails to go
online later.

Module
NOTE
Faults can be located according to specified scenarios because the deployment scenario and the routine
OM scenario involve different fault scopes.
l If the fault occurs during deployment, check the hardware and initial software configurations.
l If the fault occurs during OM, check only the hardware because the software configurations of a user
are generally not modified in this scenario. Hence, if the status of a user changes from normal to
abnormal, it is generally caused by hardware failures. If the fault occurs after a new user is added or
an existing user is modified, check the software configurations of the user.
CAUTION
Procedure
Step 1 Run the display igmp user service-port command to query the multicast user status (check the
State parameter).
l If State is block, the multicast user is blocked. In this case, run the undo igmp user block
command to unblock the user. Then, go to Step 2.
l If State is offline, go to Step 3.
NOTE
If you need to block a multicast user from watching programs temporarily without deleting the user (for
example, when the user has charges overdue), run the igmp user block command to block the user. When
the user is blocked, the OLT forces the user to go offline from the current program. In addition, the OLT
rejects the user's requests for ordering programs until the user is unblocked.
Step 2 Order a program to check whether the user can go online.

l If the user can go online, go to Step 9.
l If the user fails to go online, go to Step 3.
Step 3 Enable the OLT debugging function and collect information as follows:
1. Enable the function of multicast user monitoring.
huawei(config)#terminal monitor
huawei(config)#terminal debugging
huawei(config)#debugging igmp service-port
2. Order a program again and go to Step 4.

NOTE
After the preceding steps are performed, run the following commands to disable the debugging function.
huawei(config)#undo debugging igmp
huawei(config)#undo terminal debugging
huawei(config)#undo terminal monitor
Step 4 Locate the fault according to the reception result (received or not) of the report packet and the
fault scope.
l If the OLT displays a prompt message for the program, the OLT receives the report packet
successfully. In this case, go to Step 5.1.
l If the OLT does not display a prompt message for the program, the OLT fails to receive the
report packet. In this case, locate the fault according to the fault scope.

Module
– If the user fails to go online from the beginning or fails to go online after configuration
modification, go to Step 5.2.
– If the user can go online at first but fails to go online later, go to Step 6.
Step 5 Check multicast configurations of the OLT.
1. If the OLT receives the report packet successfully, find the possible cause according to the
judgment criteria described in Table 2-7 and troubleshoot the fault. Then, go to Step 5.4
to verify whether the fault is rectified.
Table 2-7 Incorrect multicast configurations of the OLT and troubleshooting methods
Possibl Judgment Criterion Troubleshooting Method
e
Cause
The The maximum multicast bandwidth of Choose one of the following

maximu the user is lower than the bandwidth troubleshooting methods according
m required by the ordered program if one to the purchased service type:
multica of the following situations occurs: l Inform the user that the program
st l The OLT receives the report packet cannot be watched because of
bandwi and displays "the user fails to pass insufficient bandwidth, and ask
dth of bandwidth CAC". the user to order a program with
the user a lower bandwidth than the
is lower l User MaxBandWidth in the
display igmp user service-port maximum bandwidth of the
than the user.
bandwi command output is lower than
dth Bandwidth in the display igmp l Increase the user bandwidth and
required program name command output. ask the user to order the
by the NOTE program again.
ordered If User MaxBandWidth is no-limit, the NOTE
multicast bandwidth of the user is not Run the igmp user modify service-
progra
limited. port 100 max-bandwidth command
m.
to modify the maximum bandwidth of
the user to ensure that it is higher than
the program bandwidth (this example
assumes that the service port index of
the multicast user is 100).

Module

e
Cause
The The multicast user does not have the Choose one of the following
multica permission to order certain types of troubleshooting methods according
st user programs if one of the following to the purchased service type:
does not situations occurs: l Inform the user that the program
have the l The OLT receives the report packet cannot be watched because the
permiss and displays "the number of the user does not have the
ion to grade program that the user is permission to watch the
order allowed to watch has reached program, and ask the user to
certain maximum". order a program that has not
types of reached the maximum watch
progra l The maximum number of programs
at a level that the user can watch limit at its level.
ms
(such as (watch limit) is 0 in the display l Add the permission for ordering
HDTV) igmp user extended-attributes the programs at this level for the
. service-port command output. user so that the user can order
NOTE the program.
l If watch limit is 0, the user cannot NOTE
order any programs at this level. That You can run the igmp user watch-
is, the user's permission to the limit service-port command to set the
programs of the corresponding type is number of programs at each level that
limited. For example, if HDTV watch a user can watch.
limit is 0, the user cannot watch HDTV
programs.
l If watch limit is no-limit, the
maximum number of programs at this
level that a user can watch is not
limited, but the total number of
programs that can be concurrently
watched is limited.

Module

e
Cause
multica permission to watch the program if one troubleshooting methods according
st user of the following situations occurs: to the purchased service type:
does not l The OLT receives the report packet l If the user can watch all
have the and displays "the user has no right". programs without
permiss authentication, perform the
ion to l Run the display igmp user service-
port 100 command to query the following operations:
watch
the right profile bound to the multicast a. In BTV mode, run the igmp
user (this example assumes that the user modify service-port
service port index of the multicast 100 no-auth command to
user is 100). modify the authentication
– If Bind profiles is 0, the user is mode of the user to "no
not bound to a right profile so the authentication" (this
user cannot order any programs. example assumes that the
service port index of the
– If Bind profiles is equal to or multicast user is 100).
larger than 1, the user can watch
only the program to which the b. Order the program again.
user has the watch permission. l If the user can watch only
In this case, perform operations certain programs with
for further check. In the query authentication, inform the user
result, find the index (this that the user has no permission
example assumes that the index to watch the program and ask
is 1) and name of the right the user to order a program with
profile bound to the user and run the watch or preview
the display igmp profile permission.
profile-index 1 command to
query the user permission for
ordering the program.
– If the permission of a
program is forbidden or
idle, the user does not have
the permission to order the
program.
program is watch or
preview, the user can order
the program. If so, the user's
permission to the program is
not the cause of this fault.

Module

e
Cause
progra NOTE NOTE

m. A multicast user can be bound to multiple To set permissions of the user for
right profiles. If these right profiles are ordering some programs, run the igmp
configured with different permissions to user bind-profile service-port 100
the same program, the permission with the profile-index-list 1 command to bind
highest priority prevails. By default, the a correct right profile to the multicast
priorities of the program permissions are user (this example assumes that the
forbidden > preview > watch > idle. You service port index of the multicast user
can run the igmp right-priority command is 100 and the right profile index is 1).
to set the priorities.

Module

e
Cause
The The program ordered is not included in Choose one of the following
progra the MVLAN to which the multicast troubleshooting methods according
m user belongs if both the following to the purchased service type:
ordered situations occur: l Inform the user that the program
by the l The OLT receives the report packet cannot be watched because the
multica and displays "match program fail". user has no permission to watch
st user is the program, and ask the user to
not l In the display igmp program
vlan command output, the program order a program that is included
include in the MVLAN to which the
d in the multicast user belongs.
MVLA
N to l Perform the following steps to
which add the program to the user's
the MVLAN and ask the user to
multica order the program again.
st user a. Run the display igmp
config vlan command to
query Program match
mode of the MVLAN.
– If Program match
mode is enable, the
program is a static
program, which is
manually added.
mode is disable, the
program is a dynamic
program, which is
automatically generated
upon ordering.
b. Add programs to the
MVLAN.
– To add a static program
to an MVLAN, run the
igmp program add
command.
– To add dynamic
programs to an MVLAN,
run the igmp match
group command to set
the IP address range of
program groups that can
be generated
dynamically in the
MVLAN, and include

Module

e
Cause
belongs ordered is not in the program list of the IP address of the

. the MVLAN. ordered program in the
IP address range.
No No upstream port is configured in the Add an upstream port to the

upstrea MVLAN to which the multicast user MVLAN and ask the user to order
m port belongs if both the following situations the program again.
is occur: NOTE
configu l The OLT receives the report packet In MVLAN mode, run the igmp
red in and displays "match program fail". uplink-port command to set the
the upstream port as the upstream port of
MVLA l No upstream port maps the user's the MVLAN. This allows the upstream
MVLAN in the display igmp port to forward the multicast packets of
N to this MVLAN.
which uplink-port all command output.
the
multica
st user
belongs
.
2. In MVLAN mode, run the display igmp config vlan command to query IGMP mode of
the MVLAN.
l If IGMP mode is off, the IGMP function is disabled in the MVLAN. In this case, run
the igmp mode command in MVLAN mode to set IGMP mode to proxy. Then, order
the program again and go to Step 5.4.
l If IGMP mode is proxy or snooping, the IGMP function is enabled in the MVLAN
and this is not the cause of the fault. Then, go to Step 5.3.
NOTE
If the terminal (ONT or STB) used by the user does not support multicast management, enable the
IGMP function on the OLT. Otherwise, the multicast service cannot be provisioned to the user.
3. Run the display current-configuration ont command to query the configurations of the
ONT ETH port. Specially, query the port VLAN and native VLAN of the ETH port carrying
the multicast service. Compare the queried data with the data of a normal multicast user to
verify whether the configurations are correct.
l If the configurations are correct, go to Step 6.
l If the configurations are incorrect, modify configurations by referring to the
configurations of a common user. Then, order the program again and go to Step 5.4.
NOTE
The configurations of the ONT ETH port carrying the multicast service depend on the network
topology and data plan and therefore the configurations are flexible. The typical configurations are:
Port VLAN is CVLAN and Native VLAN is not configured. If the default native VLAN is different
from the port VLAN, the untagged multicast packets sent from the user side will be dropped by the
ONT ETH port. As a result, the user fails to go online.
4. Check whether the user can go online.

Module
Step 6 If the OLT does not receive the report packet and the other users in the MVLAN can go online,
find the possible cause according to the judgment criteria described in Table 2-8 and
troubleshoot the fault. Then, go to Step 7 to verify whether the fault is rectified.
Table 2-8 Line and terminal faults and troubleshooting methods

e Cause
The STB The user can go online after resetting the Reset the STB or replace the STB
is faulty. STB or replacing the STB with a with a functional one.
functional one and ordering the program.
The The user can go online after resetting the Reset the ONT or replace the ONT
ONT is ONT or replacing the ONT with a with a functional one.
faulty. functional one and ordering the program. NOTE
Some ONTs can be reset remotely by
running commands on the OLT. For
details, see 6.2.2.6 Resetting an ONT.
The Check the LAN indicator on the ONT (the Connect the network cable again or
physical HG8245 is used as an example) to replace the network cable with a
line determine the status of the physical line functional one.
between between the STB and ONT.
the STB l If the LAN indicator is off, the line is
and faulty.
ONT is
faulty. l If the LAN indicator is steady on or
For blinks, the line is in the normal state.
example
, the
network
cable is
not
securely
connecte
d, is
damage
d, or is
incorrect
ly
connecte
d.
Step 7 Order a program and check whether the user can go online.

Module
----End
2.2.2.2 Blank Screen After a Program Is Ordered

When such a fault occurs, a user cannot watch the program after the user goes online and orders
a program. When such a fault occurs in an FTTH network, locate and troubleshoot the fault by
using the following location methods and troubleshooting procedure.
Location Method
When blank screen occurs after a user orders a program in an FTTH network, the fault scope
can be determined by the location where program traffic interruption occurs, as shown in Figure
2-6.
Figure 2-6 Locating the fault

Detection point 2:
Upstream port of the ONT
Detection point 1: Detection point 3:
ONT ETH port Upstream port of the OLT
OLT Multicast server
ONT Optical splitter
STB Multicast router Multicast router

TV
STB
TV
Scope: user terminal Scope: ONT Scope: OLT Scope: upper-layer network and devices of
Symptom: Multicast Symptom: Multicast streams Symptom: Multicast streams the OLT
streams reach the reach the upstream port of reach the upstream port of the Symptom: Multicast streams do not reach the
ONT ETH port. the ONT but do not reach OLT but do not reach the upstream port of the OLT.
the ONT ETH port. upstream port of the ONT.
Table 2-9 describes possible causes of the fault in different scopes.

Fault Scope Possible Cause
User terminal l The TV cable connecting the TV set to the set top box (STB) is not
properly connected or is damaged.
l The STB is faulty.
ONT The ONT is faulty.

Module
OLT On the OLT, check whether the multicast user is online and then
troubleshoot the fault according to the following symptoms:
l If the multicast user is offline or blocked, troubleshoot the fault by
referring to related description in 2.2.2.1 Multicast User Fails to
Go Online.
l If the multicast user goes online but the multicast program still has
a blank screen, the fault is generally caused by incorrect multicast
configurations on the OLT. In this case, enable the OLT debugging
function and locate the fault according to the debugging
information displayed on the OLT CLI. Possible causes are as
follows:
– The remaining multicast bandwidth of the user is lower than
the bandwidth required by the ordered program.
– The number of programs that the user watches reaches the
upper limit so that the user cannot order a new program.
– The multicast user does not have the permission to watch the
program.
– The program ordered is not in the MVLAN to which the
– The multicast user does not have the permission to order certain
types of programs (such as HDTV).
– The number of programs at a level that the user can watch
reaches the upper limit so that the user cannot order a new
program at this level.
– The rate configured in the traffic profile that is bound to the
service port is far lower than the bandwidth of the multicast
program.
– There are too many prejoin static programs, occupying too
much bandwidth.
– The maximum multicast bandwidth assigned to the PON port
is very low.
Upper-layer l The program is not configured on the multicast server.

network and devices l The time to live (TTL) value set on the multicast server for the
(including the multicast stream is very small.
multicast router and
multicast server) of l Network communication fails between the OLT and multicast
the OLT router, or between the multicast router and multicast server.
CAUTION

Module
Procedure
Step 1 Order a program again and perform the following steps to determine the location where program
traffic interruption occurs.
1. Run the display multicast flow-statistic vlan 3 ip 224.1.1.1 command to query the traffic
statistics of the ordered program on the OLT upstream port (this example assumes that the
MVLAN ID is 3 and the IP address of the multicast program is 224.1.1.1). If the queried
program traffic is not 0, the program traffic has reached the OLT upstream port.
2. On the OLT, run the display statistics service-port command two or three times to query
the traffic statistics of the service port of the multicast user. If the value of Number of
downstream packets changes obviously every time, the program traffic has reached the
upstream port of the ONT.
NOTE
The following prerequisites must be met before you run the display statistics service-port command
to query the traffic statistics so as to prevent the query results from being affected by other services.
l The multicast user is not watching other programs.
l The service port is not carrying other heavy-traffic services, such as file download from the
Internet.
3. On the OLT, run the display ont traffic portid ontid ontportid command to query the
downstream traffic (Down traffic) of the ONT ETH port connected to the STB. If the
queried program traffic is not 0, the program traffic has reached the ONT ETH port.
4. According to the preceding query results, determine the fault scope by referring to Table
2-10 and perform operations accordingly.
NOTE
When multiple NEs need to be checked, generally locate the fault from lower-layer devices to upper-
layer devices, that is, in the sequence of user terminal -> ONT -> OLT -> multicast router -> multicast
server, section by section along the service route.
Table 2-10 Fault scope and troubleshooting methods

Fault Scope Judgment Criterion Troubleshooting Method
User terminal Multicast streams reach the user Check the user terminal
port of the ONT. following Step 2.
ONT Multicast streams reach the a. Check the user terminal

upstream port of the ONT but do following Step 2.
not reach the user port of the b. Check the ONT following
ONT. Step 3.
User terminal, Multicast streams reach the a. Check the user terminal
ONT, and OLT upstream port of the OLT but do following Step 2.
not reach the upstream port of b. Check the ONT following
the ONT. Step 3.
c. Check the OLT following
Step 4.

Module
User terminal, Multicast streams do not reach a. Check the user terminal
ONT, OLT, and the upstream port of the OLT. following Step 2.
upper-layer b. Check the ONT following
network and Step 3.
devices of the
OLT c. Check the OLT following
Step 4.
d. Check the upper-layer
network and devices of the
OLT following Step 5.
Step 2 Check the user terminal.

1. Verify that the TV cable is properly connected to the STB.
2. Check the indicator status of the STB. If the indicator of the STB ETH port connected to
the ONT blinks quickly, the STB decoding may be incorrect. Reset the STB or replace the
STB with a functional one.
3. Order a program to check whether the user can watch the program successfully.
l If the user can watch the program successfully, go to Step 7.
l If the user fails to watch the program, go to Step 2.4.
4. Check whether all NEs have been checked according to Table 2-10.
l If all NEs have been checked, go to Step 6.
l If some NEs have not been checked, check these NEs according to Table 2-10.
Step 3 Check the ONT.

1. Reset the ONT by referring to Resetting an ONT. Order the program to check whether the
user can watch the program.
2. Replace the ONT with a functional one by referring to Replacing an ONT. Order the
program to check whether the user can watch the program.
Step 4 Check the OLT.

1. Run the display igmp user service-port command to query the multicast user status (check
the State parameter).
l If State is online, go to Step 4.2.
l If State is offline or block, perform operations by referring to 2.2.2.1 Multicast User
Fails to Go Online. Then, go to Step 7.
2. Enable the OLT debugging function and collect information as follows:

Module
a. Enable the function of multicast user monitoring.

huawei(config)#debugging igmp service-port
b. Order a program again and go to Step 4.3.

NOTE
After the preceding steps are performed, run the following commands to disable the debugging
function.
3. Find the possible cause according to the judgment criteria described in Table 2-11 and
troubleshoot the fault. Then, go to Step 4.4 to verify whether the fault is rectified.

Module
Table 2-11 Incorrect multicast configurations of the OLT and troubleshooting methods
e
Cause
The The maximum multicast bandwidth of Choose one of the following

maximu the user is lower than the bandwidth troubleshooting methods
m required by the ordered program if one according to the purchased service
multica of the following situations occurs: type:
st l The OLT receives the report packet l Inform the user that no more
bandwi and displays "the user fails to pass programs can be ordered
dth of bandwidth CAC". because the user's remaining
the user bandwidth is insufficient, and
is lower l Run the display igmp user service-
port command to query the ask the user to close some
than the programs first and then order
bandwi maximum bandwidth (User
MaxBandWidth) and used the program again.
dth
required bandwidth (Used bandwidth) of l Increase the user bandwidth
by the the user and run the display igmp and ask the user to order the
ordered program name command to query program again.
progra the bandwidth (Bandwidth) of the NOTE
m. ordered program. As shown by the l You can run the igmp user
command output, the user's modify service-port index max-
remaining bandwidth (maximum bandwidth command to modify
bandwidth minus used bandwidth) the maximum bandwidth of the
is lower than the bandwidth of the user.
ordered program. l When multicast bandwidth
NOTE management (multicast CAC) is
If User MaxBandWidth is no-limit, the disabled, the system does not
multicast bandwidth of the user is not guarantee the bandwidth of the
limited. program requested by the user.
l Because the downstream rate of a
line is limited, multicast packets
will be lost if the bandwidth of the
downstream multicast streams is
higher than the maximum rate of
the line. In this case, the user can
watch the program but pixelation
or delay occurs. If a large number
of multicast packets are lost, blank
screen occurs.

Module

e
Cause
The The maximum number of programs that Choose one of the following
maximu the user can concurrently watch reaches troubleshooting methods
m the preset maximum value if one of the according to the purchased service
number following situations occurs: type:
of l The OLT receives the report packet l Inform the user that no more
progra and displays "the number of programs can be ordered
ms that program that the user is allowed to because the available programs
the user watch has reached maximum". reach the preset maximum
can value, and ask the user to close
concurr l The number of programs that the
user is watching is equal to the some programs and order the
ently program again.
watch available programs (Available
reaches programs) in the display igmp l Increase the available programs
the user service-port command output. for the user and ask the user to
preset NOTE order the program again.
maximu If Available programs is no-limit, the user NOTE
can watch 32 programs concurrently. You can run the igmp user modify
m value.
service-port index max-program
command to modify the number of
available programs.

Module

e
Cause
multica permission to watch the program if one troubleshooting methods
st user of the following situations occurs: according to the purchased service
does not l The OLT receives the report packet type:
have the and displays "the user has no right". l If the user can watch all
permiss programs without
ion to l Run the display igmp user service-
port 100 command to query the authentication, perform the
watch following two operations:
the right profile bound to the multicast
user (this example assumes that the a. In BTV mode, run the igmp
service port index of the multicast user modify service-port
user is 100). 100 no-auth command to
– If Bind profiles is 0, the user is modify the authentication
not bound to a right profile so the mode of the user to "no
user cannot order any programs. authentication" (this
example assumes that the
– If Bind profiles is equal to or service port index of the
larger than 1, the user can watch multicast user is 100).
only the program to which the
user has the watch permission. In b. Order the program again.
this case, perform operations for l If the user can watch only
further check. In the query certain programs with
result, find the index (this authentication, inform the user
example assumes that the index that the user has no permission
is 1) and name of the right profile to watch the program and ask
bound to the user and run the the user to order a program with
display igmp profile profile- the watch or preview
index 1 command to query the permission.
user permission for ordering the
program.
program.
program is watch or
the program. If so, the user's
permission to the program is
not the cause of this fault.

Module

e
Cause
progra NOTE NOTE

configured with different permissions to the user bind-profile service-port 100
same program, the permission with the profile-index-list 1 command to bind
highest priority prevails. By default, the a correct right profile to the multicast
priorities of the program permissions are user (this example assumes that the
forbidden > preview > watch > idle. You service port index of the multicast user
can run the igmp right-priority command is 100 and the right profile index is 1).
on the OLT to set the priorities.

Module

e
Cause
The The program ordered is not included in Choose one of the following
progra the MVLAN to which the multicast troubleshooting methods
m user belongs if both the following according to the purchased service
ordered situations occur: type:
is not l The OLT receives the report packet l Inform the user that the user has
include and displays "match program fail". no permission to watch the
d in the program, and ask the user to
MVLA l In the display igmp program vlan
command output, the program order a program that is included
N to in the MVLAN to which the
which multicast user belongs.
the
multica l Perform the following steps to
st user add the program to the user's
MVLAN and ask the user to
order the program again.
a. Run the display igmp
query Program match
mode of the MVLAN.
mode is enable, the
program is a static
program, which is
manually added.
program, which is
upon ordering.
MVLAN.
igmp program add
command.
– To add dynamic
programs to an
MVLAN, run the igmp
match group command
to set the IP address
range of program groups
that can be generated
dynamically in the
MVLAN, and include

Module

e
Cause
belongs ordered is not in the program list of the IP address of the

. the MVLAN. ordered program in the
IP address range.
multica permission to order certain types of troubleshooting methods
st user programs if one of the following according to the purchased service
does not situations occurs: type:
have the l The OLT receives the report packet l Inform the user that the
permiss and displays "the number of the program cannot be watched
ion to grade program that the user is because the user does not have
order allowed to watch has reached the permission to watch the
certain maximum". program, and ask the user to
types of order a program that has not
progra l The maximum number of programs
at a level that the user can watch reached the maximum watch
ms limit at its level.
(such as (watch limit) is 0 in the display
HDTV) igmp user extended-attributes l Add the permission for
. service-port command output. ordering the programs at this
NOTE level for the user so that the user
If the maximum number of the programs at can order the program.
a certain level is 0, the user cannot order any NOTE
programs at this level. That is, the user's You can run the igmp user watch-
permission to the programs of the limit service-port command to set the
corresponding type is limited. For example, number of programs at each level that
if HDTV watch limit is 0, the user cannot a user can watch.
watch HDTV programs.
The Such is the case if one of the following Choose one of the following
number situations occurs: troubleshooting methods
of l The OLT receives the report packet according to the purchased service
progra and displays "the number of the type:
ms at a grade program that the user is l Inform the user that the ordered
level allowed to watch has reached program has not been
that the maximum". purchased by the user and ask
user can the user to order other
watch l The number of programs that the
user is watching is equal to the programs.
reaches
the maximum number (watch limit) of l Increase the maximum number
upper programs at a level that the user can of programs at this level and ask
limit so watch in the display igmp user the user to order the program
that the extended-attributes service-port again.
user command output. NOTE
cannot NOTE You can run the igmp user watch-
If watch limit is no-limit, the maximum limit service-port command to set the
order a
number of programs at this level that a user number of programs at each level that
new a user can watch.
can watch is not limited, but the total
progra number of programs that can be
m at this concurrently watched is limited.
level.

Module

e
Cause
The rate Such is the case if the following Bind a traffic profile to the service
configu situation occurs: port and order the program again.
red in Run the display service-port l If a suitable traffic profile exists
the command to query the index of the Rx in the system, run the service-
traffic traffic and then run the display traffic port 100 outbound traffic-
profile table ip command to query the PIR of table index 6 command to bind
that is the traffic profile. As shown by the the traffic profile to the service
bound command output, the PIR is far smaller port (this example assumes that
to the than the bandwidth of the ordered the service port index is 100 and
service program. the traffic profile index is 6).
port is
NOTE l If the system does not have a
far If the PIR is smaller than the bandwidth of
lower suitable traffic profile, run the
the ordered program, there will be multicast
than the traffic table ip command to
packet loss and pixelation will occur. If the
bandwi PIR is very small, the blank screen may add a new profile that meets the
dth of occur because a large number of multicast requirement and then bind the
the packets are lost. profile to the service port.
multica If the service port carrying the multicast
st streams also carries streams of other
services, ensure that the total traffic of all
progra services is smaller than or equal to the PIR.
m. Otherwise, the other services may occupy
the majority of traffic streams, which leads
to multicast bandwidth insufficiency. As a
result, pixelation will occur.
Common programs and high definition
(HD) programs require different
bandwidths, which are determined by the
program sources provided by the program
provider.
l Generally, the rate of a common
program is lower than 5 Mbit/s. In this
case, the default IP traffic profile 6 of
the system can be used.
l An HD program requires much traffic.
For example, the rate of an HD program
is higher than 12 Mbit/s. In this case, a
new traffic profile for limiting the rate
is required, or the default IP traffic
profile 6 can be used.

Module

e
Cause
There The prejoin static programs occupy too Run the igmp program modify
are too much bandwidth, which is close to the command to modify Prejoin to
many maximum downstream bandwidth of disable and then order the program
prejoin multicast programs provided by the again.
static PON port.
progra l You can obtain the bandwidth of
ms, prejoin static programs following
occupyi the steps below:
ng too
much a. Run the display igmp program
all command to query the
prejoin attribute (Prejoin) of the
program.
b. Calculate the bandwidth of
prejoin static programs
(Prejoin is enable) according to
the data plan. For example, if
100 programs are enabled with
the prejoin function and the
bandwidth of each program is 5
Mbit/s, the total bandwidth of
the prejoin static programs is
500 Mbit/s.
l You can obtain the maximum
downstream bandwidth of multicast
programs provided by the PON port
following the steps below:
a. Run the display igmp config
global command to query the
bandwidth management
function (Bandwidth
management switch).
b. Run the display igmp
bandwidth port command to
query the bandwidth (Max
bandwidth) assigned to the
PON port.
– If Bandwidth management
switch is disable, the OLT does
not perform multicast bandwidth
management. The maximum
bandwidth in this case is the
maximum downstream
transmission rate supported by
the PON line.
switch is enable and Max

Module

e
Cause
bandwi bandwidth is no-limit, the OLT NOTE

dth. performs multicast bandwidth You can modify the attributes of all
multicast programs in any MVLAN.
management but the OLT PON
When a program is being watched or
port does not limit the multicast previewed by a user, however, its
program bandwidth. The attributes cannot be modified.
maximum bandwidth in this case
is the maximum downstream
the PON line.
bandwidth has a specific value,
the OLT PON port limits the
multicast program bandwidth.
The maximum bandwidth in this
case is the bandwidth (Max
bandwidth) assigned to the
PON port.
The The maximum multicast bandwidth Run the igmp bandwidth port
maximu assigned to the PON port is very low if command to modify the maximum
m both the following situations occur: bandwidth provided by the PON
multica l In the display igmp config global port for multicast programs to meet
st command output, the bandwidth the total bandwidth requirement of
bandwi management function (Bandwidth the OLT multicast user. Then order
dth management switch) is enable. the program again.
assigne
d to the l Run the display igmp bandwidth
PON port command to query the
port is bandwidth (Max bandwidth)
very assigned to the PON port and the
low. used bandwidth (Used bandwidth).
As shown by the command output,
the remaining bandwidth (the
assigned bandwidth minus the used
bandwidth) is lower than the
bandwidth of the ordered program.
l The bandwidth assigned to the PON
port is very small, which does not
meet the total bandwidth
requirement of OLT multicast users.
4. Check whether the user can watch the program successfully.


Module
Step 5 Check the upper-layer network and devices of the OLT.
troubleshoot the fault. Then, go to Step 5.2 to check whether the fault is rectified.
Table 2-12 Faulty upper-layer network and devices of the OLT and troubleshooting
methods
e
Cause
The The multicast server does not have the Add the program to the multicast
progra program. server.
m is not TIP
configu If the user can watch the program, it
red on indicates that the multicast server has the
the program.
multica
st
server.
The All users of the OLT fail to watch all Increase the TTL value of multicast
TTL programs configured on the multicast packets on the multicast server.
value server.
set on NOTE
the If the TTL value of multicast packets on the
multica upstream port of the OLT is smaller than 2,
st server the OLT drops the multicast packets.
for the
multica
st
stream
is very
small.
The Ping the multicast router and the Troubleshoot the fault in the
upper- multicast server from the OLT network between the OLT and the
layer separately. It is found that the OLT fails multicast router or between the
network to ping the multicast router or the OLT and the multicast server.
commu multicast server.
nication TIP
of the If other users of the OLT can watch the
OLT program, the network between the OLT and
fails. the multicast server is functional.
2. Order a program again and check whether the user can watch the program.

Module
----End
Related Topics
7.3.1 Dark Screen After Program Ordering
2.2.2.3 Pixelation in a Multicast Program

Pixelation in a multicast program is a fault that a user goes online successfully and orders a
program but the quality of the program is poor. For example, the program has pixelation. When
pixelation occurs in a program in an FTTH network, locate and troubleshoot the fault by using
the following location methods and troubleshooting procedure.
Location Method
When pixelation occurs, the fault scope can be determined by the location where packet loss
occurs, as shown in Figure 2-7.
Figure 2-7 Locating the pixelation fault

Detection point 1: Detection point 2:
ONT ETH port Upstream port of the OLT
Optical splitter
ONT
STB Multicast router Multicast router

TV
STB
TV
Scope: user terminal Scope: ONT to the OLT Scope: upper-layer network and devices
Symptom: Packet loss Symptom: Packet loss does not occur of the OLT
does not occur on the on the upstream port of the OLT but Symptom: Multicast streams do no reach
ONT ETH port. occurs on the ONT ETH port. the upstream port of the OLT.
Table 2-13 describes possible causes of the fault in different scopes. When the fault scope cannot
be determined, generally locate the fault from upper-layer devices to low-layer devices, that is,
in the sequence of multicast server -> multicast router -> OLT -> ODN -> ONT -> user terminal,
section by section along the service route.

User terminal l The STB is faulty.

l The TV set is faulty.

Module
ONT The ONT is faulty.
ODN Packet loss occurs over the physical line between the OLT and the
ONT.
OLT l The rate configured in the traffic profile that is bound to the service
port is lower than the bandwidth of the multicast program.
l The QoS rate limit on the port is excessively low.
Upper-layer l The multicast source is abnormal.

network and devices l Network communication fails on the physical line between the
of the OLT OLT and multicast router, or between the multicast router and
multicast server.
CAUTION
Procedure
Step 1 Order a program again and perform the following steps to determine the location where multicast
packets are lost.
1. Run the display multicast flow-statistic vlan 3 ip 224.1.1.1 command to query the traffic
statistics of the ordered program on the OLT upstream port (this example assumes that the
MVLAN ID is 3 and the IP address of the multicast program is 224.1.1.1).
l If the query result is close to the rate of the program traffic, the program traffic has
reached the OLT upstream port. Then, go to Step 1.2.
l If the query result is far lower than the rate of the program traffic, the program traffic
encounters packet loss before reaching the OLT upstream port. This indicates that the
upper-layer network and devices of the OLT are faulty. Then, go to Step 2.
2. Run the display ont traffic portid ontid ontportid command to query the downstream traffic
(Down traffic) of the ONT ETH port connected to the STB.
l If the query result is close to the rate of the program traffic, the program traffic has
reached the ONT ETH port. This indicates that the user terminal is faulty. Then, go to
Step 4.
l If the query result is far lower than the rate of the program traffic, the program traffic
encounters packet loss before reaching the ONT ETH port. This indicates that the fault
occurs on the physical line between the ONT and the OLT. Then, go to Step 3.

Module
methods
e
Cause
The Pixelation occurs when a user watches Replace the multicast source.
multica a program on the multicast server.
st TIP
source If other users can watch the program
is properly, the multicast source is functional.
abnorm
al.
layer separately. It is found that packet loss multicast router or between the
network occurs. OLT and the multicast server.
of the TIP
OLT is If other users of the OLT can watch the
of poor program, the network between the OLT and
quality. the multicast server is functional.
2. Order the program and check whether the user can watch the program.
3. Check whether packet loss occurs on the upstream port of the OLT.
l If packet loss occurs on the upstream port of the OLT, go to Step 6.
l If no packet is lost on the upstream port of the OLT, the fault on the physical line between
the OLT and the multicast server is cleared. Then, locate the fault in other fault scopes
according to the location where packet loss occurs and go to Step 1.
1. Run the display alarm history all command to query historical alarms and check whether
the OLT generates an ODN-related alarm.
l If an ODN-related alarm is generated, the ODN is faulty. In this case, clear the alarm
by referring to relevant instruction documents. Then, go to Step 3.3.
l If no ODN-related alarm is generated, go to Step 3.2.

Module
Table 2-15 Incorrect configurations of the OLT and troubleshooting methods

e
Cause
The rate Run the display service-port Bind a new traffic profile to the
configu command to query the index of the Rx service port.
red in traffic profile that is bound to the l If a suitable traffic profile exists
the multicast stream and then run the in the system, run the service-
traffic display traffic table ip command to port 100 outbound traffic-
profile query the PIR of the traffic profile. As table index 6 command to bind
that is shown by the command output, the PIR the traffic profile to the service
bound is smaller than the bandwidth of the port (this example assumes that
to the ordered program. the service port index is 100 and
service NOTE the traffic profile index is 6).
port is If the PIR is smaller than the bandwidth of
lower the ordered program, there will be multicast l If the system does not have a
than the packet loss and pixelation will occur. If the suitable traffic profile, run the
bandwi PIR is very small, the blank screen may traffic table ip command to
occur because a large number of multicast add a new profile that meets the
dth of packets are lost.
the requirement and then bind the
If the service port carrying the multicast profile to the service port.
multica streams also carries streams of other
st services, ensure that the total traffic of all
progra services is smaller than or equal to the PIR.
m. Otherwise, the other services may occupy
the majority of traffic streams, which leads
to multicast bandwidth insufficiency. As a
result, pixelation will occur.
Common programs and high definition
provider.
case, the default IP traffic profile 6 can
be used.
l An HD program requires much traffic.
For example, the rate of an HD program
is higher than 12 Mbit/s. In this case, a
profile 6 can be used.

Module

e
Cause
The Run the display qos-info traffic-limit Run the traffic-limit command to
QoS port command to query the target rate change the target rate to an
rate (Target rate) of the port and then appropriate value or run the undo
limit on compare the target rate with the traffic-limit command to cancel
the port bandwidth of the ordered program. As the traffic limitation on the port.
is shown by the command output, the
excessi target rate is smaller than the bandwidth
vely of the ordered program.
low. NOTE
If the user port carries other services (such
as the Internet access service), the traffic of
all services must be lower than or equal to
the target rate. Otherwise, the other services
may occupy the majority of traffic streams,
which leads to multicast bandwidth
insufficiency. As a result, pixelation will
occur.
3. Order the program and check whether the user can watch the program.
4. Check whether packet loss occurs on the ONT ETH port.
l If packets are lost on the ONT ETH port, go to Step 4.
l If no packet is lost on the ONT ETH port, the fault on the physical line between the
ONT and OLT is cleared. Then, go to Step 5.
Step 4 Check the ONT.

1. Reset the ONT by referring to Resetting an ONT. Order a program again and check
whether the user can watch the program.
2. Replace the ONT with a functional one by referring to Replacing an ONT. Order a program
again and check whether the user can watch the program.
3. Check whether packet loss occurs on the ONT ETH port.
l If packets are lost on the ONT ETH port, go to Step 6.
l If no packet is lost on the ONT ETH port, the fault on the physical line between the
ONT and OLT is cleared. Then, go to Step 5.

1. Reset the STB. Order a program again and check whether the user can watch the program.

Module
2. Replace the STB. Order a program again and check whether the user can watch the program.
3. Check whether the TV set is faulty. If the TV set is faulty, troubleshoot the fault. Then,
order a program again and check whether the user can watch the program.
l If the user fails to watch the program, go to Step 6.
NOTE
You can connect the TV cable to another video input device such as a DVD player or VCR player
to check whether the TV set is faulty. If pixelation persists, the TV set is faulty.
----End
Related Topics
7.3.2 Mosaic Display in Multicast Programs
2.2.2.4 Abnormal Interruption of a Multicast Program

Abnormal interruption of a multicast program is a fault that a program is abnormally interrupted
when a multicast user is watching the program. When abnormal program interruption occurs in
an FTTH network, locate and troubleshoot the fault by using the following location methods
and troubleshooting procedure.
Location Method
When abnormal multicast program interruption occurs in an FTTH network, generally locate
the fault from upper-layer devices to lower-layer devices, that is, in the sequence of multicast
server -> multicast router -> OLT -> ODN -> ONT -> user terminal, section by section along
the service route. Table 2-16 describes possible causes of the fault in different scopes.

Scope
Upper- All users encounter the fault. The multicast source is abnormal.
layer
network All users of the OLT encounter the Network communication fails on the
and fault. physical line between the OLT and
devices of multicast router, or between the
the OLT multicast router and multicast server.

Module

Scope
OLT The OLT is faulty if both the The viewing duration of the user reaches
following symptoms occur: the preview duration.
l A single user encounters the fault.
l Other programs can still be
watched when a program is
interrupted.
The OLT is faulty if both the The quick leave mode of the user is
following symptoms occur: immediate.
l The ONT is connected to multiple
STBs.
l Programs of an STB are
frequently interrupted when a
program is switched on another
STB.
ODN The ODN is faulty if the OLT The backbone fiber or branch fiber is
generates the following alarms: faulty.
l 0x2e11a001 The feed fiber is
broken or OLT can not receive
any expected optical signals
(LOS)
l 0x2e112007 The distribute fiber
is broken or the OLT cannot
receive expected optical signals
from the GPON ONT(LOSi)
ONT and The ONT and user terminal are faulty l The ONT is faulty.
user if both the following symptoms l The STB is faulty.
terminal occur:
l A single user encounters the fault.
l Other programs cannot be
interrupted.
CAUTION
Procedure

Module
methods
e
Cause
The Program interruption occurs when a Replace the multicast source.

multica user is watching a program ordered
st from the multicast server.
source TIP
is If other users can watch the program
abnorm properly, the multicast source is functional.
al.
layer separately. It is found that the OLT fails multicast router or between the
network to ping the multicast router or the OLT and the multicast server.
commu multicast server.
nication TIP
fails. the multicast server is functional.
2. Order the program to check whether the user can watch the program.
1. Run the display alarm history all command to query historical alarms and check whether
the OLT generates the following alarms:
l 0x2e11a001 The feed fiber is broken or OLT can not receive any expected optical
signals(LOS)
l 0x2e112007 The distribute fiber is broken or the OLT cannot receive expected
optical signals from the GPON ONT(LOSi)
l If the preceding alarms are generated, the fiber is faulty. In this case, clear the alarms
by referring to relevant instruction documents. Then, go to Step 2.3.
l If the preceding alarms are not generated, go to Step 2.2.

Module
Table 2-18 Incorrect configurations of the OLT and troubleshooting methods

e
Cause
The The viewing duration of the user Choose one of the following
viewing reaches the preview duration if both the troubleshooting methods
duration following symptoms occur: according to the purchased service
of the l A single user encounters the fault. type:
user l Inform the user that the user has
reaches l Other programs can still be watched
when a program is interrupted. no permission to watch the
the program and ask the user to
preview NOTE
A program is suspended when its viewing
order a program with the
duration watch permission.
duration reaches the preset preview
.
duration. l Add the permission for
watching the program for the
user.
NOTE
To set permissions of the user for
ordering some programs, run the igmp
user bind-profile service-port 100
profile-index-list 1 command to bind
a correct right profile to the multicast
user (this example assumes that the
service port index of the multicast user
is 100 and the right profile index is 1).

Module

e
Cause
The The quick leave mode of the user is In BTV mode, run the igmp user
quick immediate if the ONT is connected to modify service-port 100
leave multiple STBs and one of the following quickleave mac-based command
mode of symptoms occurs: to modify quick leave to mac-
the user l Programs of an STB are frequently based (this example assumes that
is interrupted when a program is the service port index is 100).
immedi switched on another STB. Order the program again and
ate. switch a program on another STB.
l As shown by the display igmp user
service-port command output, the
quick leave mode of the user is
immediate.
NOTE
l If an ONT without the IGMP proxy
function is connected to multiple STBs,
quick leave can only be disable or
mac-based.
l If immediate is selected, the OLT stops
forwarding the program traffic to the
user after receiving the leave packet
sent from the user. All services of an
ONT are carried through a service port
and all STBs connected to the ONT
share the service port. As a result, if a
program that is provided by an STB but
being watched by other STBs is
switched to another program, the
program being watched by other STBs
is interrupted.
l For details about principles and data
processing of the fast leave attribute,
see Feature Description > Multicast >
Advanced Multicast Technologies >
User-Side Interoperating
Technologies.
3. Check whether the user can watch the program.

Step 3 Check the ONT and user terminal.
1. Check the indicator status of the STB. If the indicator of the STB ETH port connected to
the ONT blinks quickly, the STB decoding may be incorrect. Reset the STB or replace the
STB with a functional one. Order a program again and check whether the user can watch
the program.
2. Reset the ONT by referring to Resetting an ONT. Order a program again and check
whether the user can watch the program.

Module

3. Replace the ONT with a functional one by referring to Replacing an ONT. Order a program
again and check whether the user can watch the program.
----End
Related Topics
7.3.3 Abnormal Program Interruption in Watching a Multicast Program
2.2.2.5 Long Program Switching Time

Long program switching time is a fault that a very long time is required in switching the current
program to a new one; however, the programs can be switched and the new program can be
watched. When such a fault occurs in an FTTH network, locate and troubleshoot the fault by
using the following location methods and troubleshooting procedure.
Location Method
When the fault occurs in an FTTH network, check whether the fast leave attribute is correctly
CAUTION
Procedure
Step 1 Run the display igmp user service-port command to query the fast leave attribute (quick
leave) of the user who encounters the fault, and check whether the fast leave attribute is correctly
configured. The fast leave attribute can be configured by referring to Table 2-19 according to
user network's configurations.
l If the fast leave attribute is correctly configured, go to Step 3.
l If the fast leave attribute is incorrectly configured, run the igmp user modify service-port
quickleave command to modify the fast leave attribute of the user. Then, go to Step 2.

Module
Table 2-19 Configuring the fast leave attribute of a multicast user
ONT IGMP Number Reserve Fast Immedia MAC-Based Fast

Settings of STBs d Leave te Fast Leave
Bandwi Disable Leave
dth d
IGMP One Insufficie √ √

disabled nt
Sufficient √ √ √
More than Insufficie √ (fewer than or equal

one nt to eight STBs)
Sufficient √ √ (fewer than or equal

to eight STBs)

snooping nt


to eight STBs)
IGMP proxy One Insufficie √ √

nt
More than Insufficie √ √ (Not limited)

one nt
Sufficient √ √ √ (Not limited)
NOTE
l In Table 2-19, √ indicates that the corresponding fast leave attribute can be selected.
l For details about principles and data processing of the fast leave attribute, see Feature Description >
Multicast > Advanced Multicast Technologies > User-Side Interoperating Technologies.
Step 2 Order the program again to check whether the time of switching a program is of a proper length.
l If the time of switching a program is of a proper length, go to Step 4.
l If the time of switching a program is still too long, go to Step 3.
----End

Module
2.2.3 Troubleshooting Voice Service Faults

This topic describes how to troubleshoot voice service faults in a fiber to the home (FTTH)
network. Common voice service faults include: no tone after offhook, busy tone after offhook,
one-way audio in a voice call, noise in a voice call, voice interruptions in a voice call, and failure
to dial certain phone numbers.
Prerequisites
l The ONT and OLT communicate with each other normally. If a fault occurs in a voice call
between the ONT and OLT, all the services on the ONT are interrupted. In this case, base
on fault symptom and rectify the fault by referring to troubleshooting methods described
in other topics.
NOTE
Common faults in a voice call between the ONT and OLT include:
l ONT registration failure
l Failure to auto discover an ONT
l ONT frequently goes online and offline
l For different types of ONTs, methods for troubleshooting voice service faults are different.
This topic uses HG8240, HG8245 and HG8247 series as examples.
Context
In an FTTH network, voice subscribers access the network by using ONTs, and the ONTs work
together with an upper-layer softswitch or IMS network to achieve the VoIP service. After
encapsulated by ONTs that serve as MG or SIP interfaces, voice packets are forwarded to the
next generation network (NGN) through the OLT. The following figure shows an FTTH network
for voice service.

Module
NMS
SoftX 3000
OLT
Encapsulate voice
subscriber packets
ONT ONT
Phone A Phone B
2.2.3.1 No Tone After Offhook

No tone after offhook indicates that a subscriber hears no tone or only a weak current noise after
offhook. When such a fault occurs in an FTTH network, locate the fault according to the
following procedure.
Cause Analysis
When an FTTH subscriber hears no tone after offhook, possible causes are as follows:
l The phone is faulty.
l The line between the phone and the POTS (POTS refers to plain old telephone service) port
is faulty.
l The line between the phone and the POTS port is not properly connected.
l The POTS port is faulty.
CAUTION

Module
Procedure
Step 1 Perform the voice loop line test on the ONT. If a fault occurs, rectify it according to the test
conclusion. For details, see 6.2.2.3 Performing a Voice Loop Line Test. If the subscriber hears
no tone after offhook after the rectification, go to Step 2.
Test Result Possible Cause Troubleshooting

Method
l Normal - No process is needed

l Phone disconnected because the loop line and
phone are normal.
l AC current abnormal The line between the Replace the line between
l DC current abnormal phone and the POTS port the phone and the POTS
is faulty. port.
l Loop current abnormal
l Loop resistance abnormal
l Insulating resistance abnormal
l Capacitance abnormal
l Impedance abnormal
l Insulating not good
l Broken lines
l Line mixing
l Connected to ground
l AB Line reversal
l Line leaking
Broken lines l The phone is faulty. l Replace the phone.

l The line between the l Replace the line
phone and the POTS between the phone
port is faulty. and the POTS port.
l The line between the l Re-connect the line
port is not properly and the POTS port
connected. properly.
Step 2 Check whether domain name conflict occurs on ONTs connected to the same softswitch.
l If domain name conflict occurs, change the name to ensure that there is no identical domain
name. Then, go to Step 4.
l If no domain name conflict, go to Step 3.
Step 3 Connect the phone that encounters the fault to another POTS port.
l If the fault is rectified, the original ONT POTS port is faulty. In this case, replace the ONT
by referring to Replacing an ONT. Then, go to Step 6.
l Then, go to Step 5.
Step 4 Make a call again to check whether the fault is rectified.

Module
l If the fault is rectified, go to Step 6.

l If the fault persists, go to Step 5.
----End
Related Topics
7.4.1 No Tone After Offhook
2.2.3.2 Busy Tone After Offhook

Busy tone after offhook indicates that a subscriber hears only a busy tone after offhook. When
such a fault occurs in an FTTH network, locate the fault according to the following procedure.
Cause Analysis
When an FTTH subscriber hears a busy tone after offhook, possible causes are as follows:
l The link between the OLT and the MGC/IMS is faulty.
l No voice subscriber is configured on the MGC/IMS.
l No Layer 2 traffic stream for voice service is configured or correctly configured on the
OLT.
l Voice parameters are not configured correctly on the ONT.
NOTE
The root cause for the fault of busy tone after offhook is that the voice subscriber is not registered with the MGC/
IMS. In this case, check the voice service configurations and physical link status to locate the fault.
To check the registration status of the voice subscriber, run the display ont mg status command on the OLT.
If MG Status is Registered, the voice subscriber is registered successfully.
CAUTION
Procedure
Step 1 Check whether the link between the OLT and the MGC/IMS is faulty.
NOTE
In the VLANIF/MEth mode on the OLT, run the ip address command to configure a Layer 3 interface, and run
the ping command to ping the IP address of the MGC/IMS to check the link connectivity between the OLT and
the MGC/IMS.
l If the link is faulty, proceed to Step 2.
l If the link is normal, go to Step 3.
Step 2 Rectify the fault in the link between the OLT and the MGC/IMS, and check whether the voice
subscriber is registered with the MGC/IMS successfully.

Module
l If the voice subscriber is registered, go to Step 10.

l If the voice subscriber fails to be registered, proceed to Step 3.
Step 3 Check whether a voice subscriber is configured on the MGC/IMS.
l If a voice subscriber is configured, go to Step 5.
l If no voice subscriber is configured, proceed to Step 4.
Step 4 Configure a voice subscriber on the MGC/IMS, and check whether the voice subscriber is
registered with the MGC/IMS successfully.
Step 5 On the OLT, run the display service-port command to check whether a Layer 2 traffic stream
for voice service is configured, and check whether State is up.
l If Layer 2 traffic stream is configured and State is up, go to Step 7.
l If Layer 2 traffic stream is not configured or State is not up, proceed to Step 6.
Step 6 On the OLT, run the service-port command to configure a Layer 2 traffic stream for voice
service, and check whether the voice subscriber is registered with the MGC/IMS successfully.
Step 7 Check whether voice parameters are configured correctly on the ONT. The voice parameters
concerned include signaling WAN interface parameters, voice interface parameters and voice
subscriber parameters, as described in the following table. If the subscriber hears a busy tone
after offhook when voice parameters are correct, proceed to Step 8.
Parameter Item Configuration Principle
Signaling l Service list (service type) l The service list must contain VoIP
WAN port l VLAN ID service. Otherwise the voice
parameters service fails.
l The ONT-side VLAN ID on the
ONT must be the same as the user-
side VLAN ID of the Layer 2
traffic stream created by the OLT
for voice service.

Module
Parameter Item Configuration Principle
Voice interface H.248: The voice interface parameters on the

parameters l MGC address and port ID ONT must be the same as the
parameters configured on the MGC/
l MID format, MG domain name IMS.
and device name
NOTE
l Prefix and digital length of the You can trace H.248 signaling on the
RTP TID MGC and check for error 502 to judge
whether the RTP TID format of the MG is
SIP: the same as that of the MGC.
l IP address and port ID of the According to protocols, message 502 is
SIP server defined as invalid termination (including
RTP termination and physical
l Home domain name termination). On the MGC, if the traced
H.248 signaling contains error 502, the
RTP TID format of the MG is different
from that of the MGC. For example, the
RTP TID of the MGC is in an ascending
order of RTP1000, RTP1001 and
RTP1002; however, the RTP TID of the
MG is in an ascending order of RTP500,
RTP501 and RTP502.
Voice H.248: Voice subscriber parameters on the

subscriber l Terminal name (terminal ID) ONT must be the same as parameters
parameters configured on the MGC/IMS.
l Associated physical port
(associated POTS port)
SIP:
l Registered user name
(subscriber phone number)
l Authentication user name and
password
l Associated physical port
(associated POTS port)
Step 8 Check whether the voice subscriber is registered with the MGC/IMS successfully.
----End
Related Topics
7.4.2 Busy Tone After Offhook

Module
2.2.3.3 One-Way Audio in a Voice Call

One-way audio indicates that a subscriber can dial a phone number and hear the ring tone, but
only the tone of one party can be heard in a voice call. When such a fault occurs in an FTTH
network, locate the fault according to the following procedure.
Cause Analysis
When one-way audio occurs in an FTTH network, possible causes are as follows:
ACL (ACL refers to access control list) rules on the bearer network, OLT or ONT are not
configured correctly.
NOTE
l A subscriber can dial the phone number and hear the ring tone. Hence the signaling streams are normal.
l If a fault occurs on the bearer network, locate the fault by making phone calls between subscribers of the
same OLT. In this case, media streams are forwarded inside the device instead of the bearer network. If the
subscribers can call each other normally, the link between the device and the bearer network is faulty.
CAUTION
Procedure
Step 1 Check whether subscribers of the same OLT can call each other normally.
l If the subscribers can call each other normally, the link between the device and the bearer
network is faulty. In this case, proceed to Step 2.
l If the subscribers fail to call each other normally, go to Step 3.
Step 2 Check whether ACL rules are correctly configured on the router of the IP bearer network.
l If ACL rules are correctly configured, go to Step 7.
l If ACL rules are not correctly configured, modify or cancel ACL rules of the IP bearer
network. Then, go to Step 6.
Step 3 Check whether subscribers of the same ONT can call each other normally.
l If the subscribers can call each other normally, configurations on the OLT are incorrect. In
this case, proceed to Step 4.
l If the subscribers fail to call each other normally, configurations on the ONT are incorrect.
In this case, go to Step 5.
Step 4 On the OLT, run the display acl all command to check whether ACL rules are used to filter
upstream or downstream voice media streams.
l If ACL rules are used, run the undo acl command on the OLT to cancel the ACL rules,
and go to Step 6.
l If ACL rules are not used, proceed to Step 5.
NOTE
The ACL that has been delivered to a port cannot be deleted. To delete such an ACL, cancel the ACL
delivery before deleting by running the undo packet-filter command on the OLT.

Module
Step 5 On the ONT, check whether IP filtering and MAC address filtering functions are configured to
filter upstream or downstream voice media streams.
l If IP filtering and MAC address filtering functions are configured, disable them and proceed
to Step 6.
l If IP filtering and MAC address filtering functions are not configured, go to Step 7.

l If the fault persists, proceed to Step 7.
----End
Related Topics
7.4.5 One-Way Audio in a Voice Call
2.2.3.4 Noise in a Voice Call

Noise in a voice call indicates that a subscriber hears a strong current noise and broadcast noise
in a voice call, excluding the environment noise of both parties. When such a fault occurs in an
FTTH network, locate the fault according to the following procedure.
Cause Analysis
When noise in a voice call occurs in an FTTH network, locate the fault according to the fault
scope, as described in the following table.
Subscribers of the same OLT l Packet loss occurs in the bearer network.
l Electromagnetic interference exists in the environment of
the OLT.
Subscribers of two POTS l Electromagnetic interference exists in the environment of

ports on an ONT the ONT and the line between the ONT and the phones.
l The ONT or power adapter is faulty.
Subscriber of a POTS port on l The POTS port is faulty.

an ONT l The line between the phone and the POTS port is faulty.
l The line between the phone and the POTS port is not
properly connected.
l The subscriber line is not correctly connected. For
example, an extra xDSL (DSL refers to digital subscriber
line) distribution box is connected.

Module
Subscribers calling certain The phone number configured on the ONT is different from
numbers that configured on the softswitch.
CAUTION
Procedure
Step 1 Check the fault scope.
l If all subscribers of the same OLT hear the noise, proceed to Step 2.
l If the subscribers of two POTS ports on an ONT hear the noise, go to Step 3.
l If the subscriber of a POTS port on an ONT hears the noise, go to Step 5.
l If the subscribers calling certain numbers hear the noise, go to Step 7.
Step 2 Rectify packet loss failure in the bearer network and eliminate electromagnetic interference (such
as interference brought by the broadcast tower and high voltage wire) in the environment of the
OLT. Then, make a call again to check whether the fault is rectified.
Step 3 Eliminate electromagnetic interference (such as interference brought by a radio or stereo) in the
environment of the ONT and the line between the ONT and the phones. Then, make a call again
to check whether the fault is rectified.
Step 4 Replace the ONT or power adapter. Then, make a call again to check whether the fault is
rectified.
Step 5 Run the ont pots-test command to perform a loop line test for the ONT, and rectify the fault
according to the test result. If the noise persists in a voice call after the rectification, proceed to
Step 6.

Method

phone are normal.

Module

Method
is faulty. port.
l Broken lines
l Line mixing
l AB Line reversal
l Line leaking

Step 6 Re-connect the subscriber line properly. Then, make a call again to check whether the fault is
rectified.
Step 7 Check the phone numbers configured on the softswitch and ONT, and modify the phone number
configured on the phone that encounters the fault to be the same as the phone number configured
on a normal phone. Then, make a call again to check whether the fault is rectified.
----End
Related Topics
7.4.6 Noise in a Voice Call

Module
2.2.3.5 Voice Interruptions in a Voice Call

Voice interruptions in a voice call indicate that the voice heard by a subscriber in a voice call is
interrupted at times. When such a fault occurs in an FTTH network, locate the fault according
to the following procedure.
Cause Analysis
When voice interruptions in a voice call occur in an FTTH network, possible causes are as
follows:
l The 802.1p priority of the voice service is too low on the ONT.
l The POTS port is faulty.
l The line between the POTS port and the phone is faulty.
l The line between the phone and the POTS port is not properly connected.
l The network connection is abnormal.
CAUTION
Procedure
Step 1 Run the ont pots-test command to perform a loop line test for the ONT, and rectify the fault
according to the test result. If voice interruptions persist after the rectification, proceed to Step
2.
Method

phone are normal.

Module

Method
is faulty. port.
l Broken lines
l Line mixing
l AB Line reversal
l Line leaking

Step 2 Rectify the network fault (for example, improper optical fiber connection). Then, make a call
again to check whether the fault is rectified.
Step 3 Connect the phone that encounters the fault to another POTS port, Then, make a call again to
check whether the fault is rectified.
l If the fault is rectified, the POTS port on the original ONT is faulty. In this case, replace
the ONT and go to Step 8.
Step 4 Check whether the 802.1p priority of the voice service is too low on the ONT.
NOTE
l When packet loss occurs in case of network congestion, packets with a lower QoS (QoS refers to quality
of service) priority are discarded first. Priorities of QoS packets are from 0 to 7 in an ascending order.
l The voice service requires a high network quality. Hence, it is recommended that you set the priority
of the voice service on the ONT to 6.
l If the 802.1p priority of the voice service is too low on the ONT, set it to a high priority,
and proceed to Step 5.

Module
l If the 802.1p priority of the voice service is high on the ONT, go to Step 6.

Step 6 Replace the ONT. Then, make a call again to check whether the fault is rectified.
----End
Related Topics
7.4.7 Voice Interruptions in a Voice Call
2.2.3.6 Failure to Dial Certain Phone Numbers

Failure to dial certain phone numbers indicates that when dialing certain phone numbers, the
subscriber hears "the number you dialed does not exist". When such a fault occurs in an FTTH
Cause Analysis
When a subscriber fails to dial certain phone numbers, possible causes are as follows:
1. Packet loss occurs in the network between the OLT and the MGC/IMS.
2. Digitmaps associated with the phone numbers are not configured on the MGC or ONT.
CAUTION
Procedure
Step 1 Check whether packet loss occurs in the network between the OLT and the MGC/IMS.
NOTE
In the VLANIF/MEth mode on the OLT, run the ip address command to configure a Layer 3 interface, and run
the ping command to ping the IP address of the MGC/IMS repeatedly to check whether packet loss occurs in
the network between the OLT and the MGC/IMS.
l If packet loss occurs in the network, rectify the fault (for example, improper optical fiber
connection) in the link between the OLT and the MGC/IMS, and proceed to Step 2.
l If no packet loss occurs in the network, go to Step 3.

Module

Step 3 Check whether digitmaps associated with the phone numbers are configured on the MGC or
ONT.
l If the digitmaps are configured, go to Step 5.
l If the digitmaps are not configured, configure them, and proceed to Step 4.

----End
Related Topics
7.4.8 Fail to Dial Certain Phone Numbers
2.3 Troubleshooting the FTTB and FTTC Service (OLT +

MDU)
and voice (VoIP) services in the GPON access mode in FTTB and FTTC scenarios. MDU refers
to MA561x, MA562x, MA5612 and MA5606T. Command lines executed by MDU are examples
of MA5616.
2.3.1 Troubleshooting the Internet Access Service (When the MDU

Provides xDSL Access)
This chapter describes how to troubleshoot common faults users encounter when accessing the
Internet using MDU in xDSL mode on FTTB and FTTC network. Common faults include
Internet access failure, frequent service disconnection, low access rate, and failure to obtain an
IP address by Point-to-Point Protocol over Ethernet (PPPoE) dialup or Dynamic Host
Configuration Protocol (DHCP) mode.
Prerequisites
NOTE

Module
2.3.1.1 Troubleshooting the Failure to Access the Internet

This section describes how to troubleshoot failures when users access the Internet on fiber to
the building (FTTB) and fiber to the curb (FTTC) networks in xDSL mode, for example, users
fail to open Web pages.
Fault Location
Use the following guidelines to locate the fault.
Fault Location Location Analysis Possible Causes
User terminal A user fails to obtain the IP For the details about how to troubleshoot
address (excludes users this fault, see the following sections:
with a static IP address). l 2.3.1.4 Troubleshooting the Failure
to Obtain an IP Address by PPPoE
Dialup
l 2.3.1.5 Troubleshooting the Failure
to Obtain an IP Address in DHCP
Mode
The user obtains the IP l The user's PC is infected with viruses.

address successfully l Internet Explorer (IE) on the user's
(excludes users with a PC is faulty.
static IP address). The user
can access the Internet l The network interface card (NIC) in
after replacing the PC. the user's PC is faulty, or the PC is
slow to respond after running for a
long period.
Web site Certain Web sites fail to The Web site sever is faulty.
open.
No Web site can be The domain name server (DNS) fails to

opened. resolve the IP address.
DNS A Web site can be opened l The DNS is faulty and fails to resolve
by entering its IP address. the domain name.
l The communication between the
user's PC and the DNS is abnormal.
CAUTION
Procedure
1. Check whether the user's PC can obtain an IP address.

Module
NOTE
To view the IP address of the PC, do as follows:

a. Choose Start > Run from the Windows main menu. In the Run dialog box displayed, enter cmd and
press Enter.
b. In the CLI window displayed, run the ipconfig command to view the IP address obtained by the PC.
l If the PC can obtain an IP address, go to Step 1.3.
l If the PC cannot obtain an IP address, do as follows:
– For PPPoE users, see 2.3.1.4 Troubleshooting the Failure to Obtain an IP
Address by PPPoE Dialup. Then, go to Step 1.2.
– For DHCP users, see 2.3.1.5 Troubleshooting the Failure to Obtain an IP
Address in DHCP Mode. Then, go to Step 1.2.
2. Check whether the user can access the Internet.
l If the user can access the Internet successfully, go to Step 5.
l If the user cannot access the Internet, go to Step 1.3.
3. Replace the user's PC with a test PC that can access the Internet in the same mode as the
user's PC. Then, check whether the user can access the Internet.
l If the user can access the Internet, the fault is on the user's PC. Check whether the user's
PC is infected with viruses, the NIC or IE of the user's PC is faulty, or the PC is slow
to respond after running for a long period. Then, go to Step 5.
l If the user cannot access the Internet, go to Step 2.
Step 2 Check whether the user can access the Internet by going to various Web sites through the Web
server.
l If the user can access certain Web sites, the fault is on the Web site itself. Go to Step 5.
l If the user cannot access any Web sites, go to Step 3.
Step 3 Check the DNS.

1. Enter the IP address of an existing Web site in the address bar of IE (format: http://
192.168.0.2) and check whether the Web site opens.
l If the Web site opens, the fault is on the DNS and the DNS cannot resolve the domain
name. Go to Step 3.2.
l If the Web site does not open, go to Step 4.
2. Check whether the PC can ping the IP address of the DNS.
NOTE
To view the DNS IP address of the PC, do as follows:

press Enter.
b. In the command line interface (CLI) window displayed, run the ipconfig/all command to view the
DNS IP addresses obtained by the PC, namely, the values of the DNS Servers parameter.
l If the PC can ping the IP address of the DNS, the link between the PC and the DNS is
normal and the DNS is faulty. Go to Step 3.3.
l If the PC cannot ping the IP address of the DNS, go to Step 4.
3. Rectify the fault on the DNS. Then, check whether the user can access the Internet.

Module
----End
Related Topics
2.3.1.2 Troubleshooting Frequent Interruptions in Internet Service

This section describes how to troubleshoot frequent interruptions in Internet service when x
digital subscriber line (xDSL) users on fiber to the building (FTTB) and fiber to the curb (FTTC)
networks are accessing the Internet.
Fault Location
User terminal The fault does not recur when the The user's PC is infected with
user's PC is replaced. viruses or the network interface card
(NIC) in the user's PC is faulty.
The fault does not recur when the The user's modem is faulty.
user's modem is replaced.
Link between Packet loss on the subscriber line l The quality of the subscriber line
user terminal and is severe. is deteriorated.
optical network l The subscriber line is old.
unit (ONU)
l The subscriber line is not
connected properly.
l The subscriber line connectors
are loose.
l There is a strong source of
interference around the user.
ONU The Internet service on a single l The user port is faulty.

port is frequently interrupted. l The quality of the subscriber line
is deteriorated and the packet
loss on the subscriber line is
severe.
Internet services on all ONU ports l The ONU is faulty.

are frequently interrupted. l There is a strong source of
interference around the ONU.
l A user's MAC address drift
occurred on the ONU.

Module
Upper layer Internet services of all users The BRAS's MAC address has
BRAS connected to the BRAS are drifted.
frequently interrupted.
CAUTION
Procedure
1. Replace the user's PC and then check whether Internet service is restored.
l If the service is restored, the fault is on the user's PC. Check whether the NIC in the
user's PC is faulty or whether the user's PC is infected with viruses. Then, go to Step
6.
l If the service is not restored, go to Step 1.2.
2. Check the indicator status on the modem to determine whether the modem is being activated
and deactivated frequently.
l If the modem is being activated and deactivated frequently, go to Step 1.3.
l If the modem is not being activated and deactivated frequently, go to Step 2.
3. Replace the modem and then check whether the modem would still be activated and
deactivated frequently.
l If the modem would still be activated and deactivated frequently, go to Step 2.
l If the modem would not be activated and deactivated frequently, go to Step 1.4.
4. Check whether the service recovers to normal.
l If the service is restored, go to Step 6.
l If the service is not restored, go to Step 2.
Step 2 Check the quality of the line between the ONU and the user terminal.
1. Check whether cyclic redundancy code (CRC) loss occurs on the subscriber line.
l If CRC loss occurs on the subscriber line, go to Step 2.2.
l If CRC loss does not occur on the subscriber line, go to Step 3.
NOTE
Query the performance statistics of the faulty port multiple times (recommended: 10 times) and then
compare the statistics to check whether packet loss occurs on the subscriber line. The query interval is
20s.
Run the display xdsl statistics performance frameid/slotid/portid line-showtime co ever-before
command on the ONU to query all the performance statistics of the subscriber line after the subscriber
line is initialized. Then, check whether the Count of errored seconds and Count of severely errored
seconds increase. If the two numbers increase, packet loss is occurring on the subscriber line.
2. Check the quality of the physical line between the ONU and the modem to determine
whether the line is not connected properly or the line is old. Reconnect the line properly or

Module
replace the old line as needed to ensure good line quality. Then, check whether the modem
can be activated.
l If the modem can be activated, go to Step 2.3.
l If the modem cannot be activated, go to Step 2.4.
4. Check whether there is a strong source of interference, such as a wireless base station or a
high-frequency switch power system, around the user.
l If there is a strong source of interference around the user, it may be the cause of the
fault. Contact the relevant department to handle it. Then, go to Step 6.
l If there is no strong source of interference around the user, go to Step 2.5.
5. Change a port for the user and configure the necessary data on the ONU. Then, check
whether service is restored.
l If the service is restored, the user port is faulty. Change a port for the user and reconfigure
the data. Then, go to Step 6.
Step 3 Check whether the user's MAC address has drifted from one ONU port to another.
1. In global config mode, run the display location mac-addr command to check multiple
times (more than three times is recommended) whether the user's MAC address has drifted
on the port that has learned the user's MAC address.
l If the MAC address drift occurred, go to Step 3.2.
l If no MAC address drift occurred, go to Step 4.
NOTE
l The mac-addr parameter in the command indicates the user's MAC address. For modem dialup,
the user's MAC address is the MAC address of the modem. For PC dialup, the user's MAC address
is the MAC address of the PC.
l The F/S/P parameter in the query result indicates the service port that learned the user's MAC
address. Generally, the port displayed in the query result should be the service port of the user.
If the displayed port is not the service port of the user, the user's MAC address has drifted.
2. Check whether a loop has formed or there are user attacks on the port that the user's MAC
address has drifted to. If a loop has formed, disconnect it. If the port that the MAC address
has drifted to is being attacked, deactivate the port initiating the attacks. Then, check
whether the service is restored.
Step 4 Check whether the BRAS's MAC address has drifted on the ONU.
1. Run the display location mac-addr command to check multiple times (more than three
times is recommended) whether the BRAS's MAC address has drifted on the port that has
learned the BRAS's MAC address.
l If the BRAS's MAC address has drifted, go to Step 4.2.
l If the BRAS's MAC address has not drifted, go to Step 5.

Module
NOTE
l The mac-addr parameter in the command indicates the BRAS's MAC address.
l The F/S/P parameter in the query result indicates the uplink port that learned the BRAS's MAC
address. Generally, the port displayed in the query result should be the uplink port on the ONU
connected to the BRAS. If the displayed port is not the uplink port, the BRAS's MAC address
has drifted.
2. Check whether a loop has formed or whether there are user attacks on the port where the
user's MAC address has drifted. If such a problem occurs, disconnect the loop or deactivate
the port where the user attacks are initiated. Then, perform another dialup check. Then,
check whether the service is restored.
----End
Related Topics
2.3.1.3 Troubleshooting Low Internet Access Rate

Low Internet access rate indicates that the attainable Internet access rates for users are lower
than the rates provided them. This section describes how to troubleshoot low access rates when
x digital subscriber line (xDSL) users on fiber to the building (FTTB) and fiber to the curb
(FTTC) networks access the Internet.
Fault Location
User terminal The fault does not recur when the l The network interface card
user's PC is replaced. (NIC) in the PC is faulty.
l The user's PC is infected with
viruses.
l The computer does not meet the
minimum configuration
requirements.
The fault does not recur when the The user terminal is faulty.
user terminal is replaced.

Module
ONU l The subscriber line is old.
are loose.
ONU The Internet access rate on a single l The rate restriction configuration
port is low. for the user is incorrect.
l Certain users's Internet access
rates are restricted on the BRAS.
The Internet access rates on all l A user's MAC address drift

ONU ports are low. occurred on the ONU.
l The upstream bandwidth on the
ONU is insufficient.
OLT The Internet access rates on all The DBA bandwidth that the OLT
ONU ports are low. allocates to the ONU is insufficient.
Upper layer Only certain users' Internet access Certain users's Internet access rates
BRAS rates are low; the services of other are restricted on the BRAS.
users on the BRAS are normal.
CAUTION
Procedure
Step 1 Determine the fault range when identifying the fault causes.
l If the Internet access rates of only certain users on the ONU are low whereas the rates of
other users are normal, go to Step 2.
l If the Internet access rates of all users on the ONU are low, go to Step 7.
Step 2 Replace the user's PC and test whether the Internet access rate is normal.
l If the Internet access rate is normal, the fault is on the PC. Check whether the NIC in the
user's PC is faulty, the PC is infected with viruses, the PC is slow to respond after running
for a long time, or the PC's configuration is low. Then, go to Step 11.
l If the Internet access rate is low, go to Step 3.
Step 3 Check whether the line between the ONU and the user terminal is normal.
1. In xDSL mode on the ONU, run the display line operation command to check whether
the actual line rate downstream (Kbps) in the query result meets the requirements of the
user's subscribed rate.

Module
l If the actual line rate downstream (Kbps) is much smaller than the user's subscribed
rate, go to Step 3.2.
l If the actual line rate downstream (Kbps) is almost the same as the user's subscribed
rate, go to Step 4.
2. In xDSL mode on the ONU, run the display port state command to query the line profile
bound to the user port and then run the display adsl line-profile profile-index command
to query whether the Maximum transmit rate downstream (kbps) in this line profile
meets the user's subscribed rate.
l If the Maximum transmit rate downstream (kbps) meets the user's subscribed rate,
go to Step 3.4.
l If the Maximum transmit rate downstream (kbps) does not meet the user's subscribed
rate, bind a qualified line profile to the user port. For how to configure a line profile for
a port, see Changing the Line Profile (Template) of an xDSL Port. Then, go to Step
3.3.
3. Check whether the Internet access is restored.
l If the Internet access rate is restored, go to Step 11.
l If the Internet access is not restored, go to Step 3.4.
l If no CRC loss occurs on the subscriber line, go to Step 4.
NOTE
Query the performance statistics of the faulty port multiple times (recommended: 10 times) and then
compare the statistics to check whether packet loss occurs on the subscriber line. The query interval is
20s.
Run the display xdsl statistics performance frameid/slotid/portid line-showtime co ever-before
command on the ONU to query all the performance statistics of the subscriber line after the subscriber
line is initialized. Then, check whether the Count of errored seconds and Count of severely errored
seconds increase. If the two numbers increase, packet loss is occurring on the subscriber line.
5. Check whether the physical line between the ONU and the user terminal is connected
properly or whether the line is old.
l If the line is not connected properly or is old, reconnect the line or replace a line as
needed. Then, Step 3.6.
l If the line is connected properly or is not old, go to Step 3.7.
6. Check whether the Internet access is restored.
l If the Internet access is restored, go to Step 11.
l If the Internet access is not restored, go to Step 3.7.
7. Replace the user's modem and then check whether the Internet access rate is normal.
l If the Internet access is not restored, go to Step 4.
Step 4 Check whether unknown traffic is occupying the bandwidth on the ONU.
1. Ensure that the user is not accessing the Internet. Run the display statistics service-port
index command to query the traffic information about the affected service port multiple
times (recommended: five times). The query interval is 20s.
l If the upstream or downstream traffic increases rapidly, unknown traffic is occupying
the bandwidth. Go to Step 4.2.

Module
l If the upstream or downstream traffic does not increase, go to Step 5.

NOTE
Normally, the query results should be similar when the user is not accessing the Internet.
l Number of upstream bytes: Indicates the current upstream traffic of the user.
l Number of downstream bytes: Indicates the current downstream traffic of the user.
2. Use packet-capturing software, such as Ethereal, to capture packets on the user's PC,
confirm the known traffic source, and then eliminate the unknown traffic source. You can
eliminate the unknown traffic source by checking whether the PC sending the unknown
traffic is infected with viruses. Check whether the Internet access is restored.
Step 5 Check on the ONU the maximum rate configured for the user.
1. Run the display service-port command to query the indexes of the traffic profiles
configured for the service port in the receive and transmit directions.
2. Run the display traffic table ip command to query the corresponding traffic profile. Then,
check whether the committed information rate (CIR) reaches the bandwidth that the user
applies for.
l If the CIR is less than the bandwidth that the user applied for, the traffic profile bound
to the user is incorrect. Go to Step 5.3.
l If the CIR is equal to the bandwidth that the user applies for, go to Step 6.
3. Run the undo service-port command to delete the service port of the user. Then, run the
service-port command to reconfigure a service port for the user and bind the user to a
proper traffic profile. Check whether the Internet access is restored.
NOTE
When modifying the traffic profile, note the following:

l The service ports bound to the traffic profile take effect at the same time after the traffic profile is
modified.
l If the current traffic profile is bound with multiple service ports, run the traffic table ip command to
create a required traffic profile.
l If the current traffic profile is bound with one service port, run the traffic table ip modify command
to modify the traffic profile.
1. In global config mode, run the display location command to check multiple times
(recommended: three times) whether the user's MAC address has drifted away from the
port that originally learned it.
l If the user's MAC address has drifted, go to Step 6.2.
l If the user's MAC address has not drifted, go to Step 7.

Module
NOTE
has drifted to is being attacked, deactivate the port initiating the attacks. Check whether the
Internet access is restored.
Step 7 Query the OLT for the DBA bandwidth that the OLT allocates to the ONU.
1. Run the display ont info portid ontid command to query the DBA bandwidth that the OLT
allocates to the ONU.
Query the value of the DBA Profile-ID parameter.

2. Run the display DBA-profile profile-id profile-id command to query the bandwidth
configured in the DBA profile.
3. Check whether the bandwidth occupied by the uplink port on the ONU reaches the allocated
DBA bandwidth.
l If the bandwidth occupied by the uplink port on the ONU almost reaches the permitted
maximum bandwidth, the bandwidth of the uplink port on the site is the cause of the
fault. Go to Step 7.4.
l If the bandwidth occupied by the uplink port on the ONU is lower than the maximum
attainable bandwidth, go to Step 8.
4. Change the DBA bandwidth that the OLT allocates to the ONU or reduce the number of
users on the device by cutting users over to another device. Then, check whether the service
is restored.
Step 8 Check whether the upper layer BRAS is restricting the user rate.
l If the rate of the affected user is restricted on the BRAS, modify the BRAS configuration.
Then, go to Step 9.
l If the rate of the affected user is not restricted on the BRAS, go to Step 10.
Step 9 Check whether the service recovers to normal.

----End

Module
Related Topics
2.3.1.4 Troubleshooting the Failure to Obtain an IP Address by PPPoE Dialup

This section describes how to troubleshoot a failure to obtain an IP address by point-to-point
over Ethernet (PPPoE) dialup mode. When a user accessing the Internet in xDSL mode on fiber
to the building (FTTB) and fiber to the curb (FTTC) network fails to obtain an IP address by
PPPoE dialup, refer to the following guidelines to address the issue.
Fault Location
Perform a PPPoE dialup emulation test to determine the fault scope first.
If the result of the PPPoE dialup emulation test is success, the link between the optical network
unit (ONU) and the upper layer broadband remote access server (BRAS) is normal. Therefore,
the fault must be located on the link between the ONU and the user terminal. Use the following
guidelines to locate the fault more accurately.
User terminal If the fault does not recur when the l The dialup software is not
user's PC is replaced, the fault is properly installed on the PC.
on the PC. l The network interface card
(NIC) in the PC is faulty.
If the fault does not recur when the The modem is faulty.
user's modem is replaced, the fault
is on the modem.
Link between The user's modem cannot be A fault has occurred on the
user terminal and activated. subscriber line.
ONU l The quality of the subscriber line
is deteriorated.
l The subscriber line is old.
are loose.
The user port is deactivated.
ONU The fault does not recur when the The user port is faulty.
line of the affected user is moved
to another user port.
The configured service port data is The configured service port data,
inconsistent with the data plan. such as the port ID, virtual path
identifier (VPI), and virtual channel
identifier (VCI), is incorrect.
If the result of the PPPoE dialup emulation test is not success, the fault must be located on the
link between the ONU and the upper layer BRAS. Use the following guidelines to address the
fault more accurately.

Module
ONU The configured service port data is The configured service port data,
inconsistent with the data plan. such as the VLAN ID, is incorrect.
The uplink port forwards no The uplink port on the ONU was not
service stream to the upper layer added to the upstream VLAN.
device.
The security configuration is l The Policy Information Transfer

incorrect. Protocol (PITP) configuration is
incorrect.
l The configured number of MAC
addresses that can be learned by
the service port is incorrect.
l The configuration of the anti-
MAC address spoofing function
is incorrect.
l An access control list (ACL) that
does not allow transmission of
PPPoE packets is configured.
A MAC address drift occurs. l A user or BRAS's MAC address

may drift because of attacks or a
loop on the network.
OLT The configured service port data is The configured service port data,
inconsistent with the data plan. such as the upstream VLAN, user
side VLAN, and port ID, is
incorrect.
The uplink port forwards no The uplink port on the OLT was not
device.
Upper-layer The configuration of the upper The maximum transmission unit

device layer router is incorrect. (MTU) or the quality of service
(QoS) value configured on the upper
layer router is not correct.
The BRAS configuration is The user's account is restricted on

incorrect. the BRAS.
CAUTION
Procedure
Step 1 Perform a PPPoE dialup emulation test on the ONU for the affected user.

Module
l If the result of the dialup emulation test is not success, go to Step 3.

NOTE
If the result of the dialup emulation test is timeout, parameter negotiation failure, user authentication
failure, offline requested by the peer end, or other errors, the fault is located on the upper layer device
of the ONU.
l If the result of the dialup emulation test is success, go to Step 2.

1. Replace the user's PC with another one and perform a dialup emulation test to check whether
the dialup can be successful.
l If the dialup is successful, the fault is related to a problem on the user's PC. Check
whether the PPPoE software is installed on the PC incorrectly and whether the PC's NIC
is faulty or disabled, and address the problem. Then, go to Step 14.
l If the dialup fails, go to Step 2.2.
2. Check the indicator status on the modem to determine whether the modem is activated.
l If the modem is activated, go to Step 3.
l If the modem is not activated, go to Step 2.3.
3. Replace the modem and then check whether the modem can be activated.
4. Perform a dialup check.
l If the dialup is successful, go to Step 14.
l If the dialup fails, go to Step 3.
replace the old line as needed to ensure good line quality. Then, activate the modem to
check whether the modem can be activated.
7. Run the display port state portid command on the ONU in xDSL mode to check whether
the user port is Deactivated.
l If the port is Deactivated, go to Step 2.8.
l If the port is not Deactivated, go to Step 2.9.
8. Run the activate portid command on the ONU in xDSL mode to activate the xDSL port
and then check whether the port is Activated.
l If the port is Activated, go to Step 2.10.
l If the port is not Activated, go to Step 2.9.
9. Move the user to another port and then check whether the new port is Activated.
l If the new port is Activated, the original user port is faulty. Change the user's port and
reconfigure the port data. Then, go to Step 2.10.
l If the port is not Activated, go to Step 13.

Module

Step 3 Check whether the data configuration on the ONU is correct.

1. Run the display service-port port frameid/slotid/portid command to check whether the
data configuration of the service port is correct.
l If the data configuration is correct, go to Step 3.3.
l If the data configuration is incorrect, refer to the following notes to change the
configuration data. Then, go to Step 3.2.
NOTE
l Run the undo service-port command to delete the original service port.
l Run the service-port command to configure a new service port.
3. Run the display port vlan frameid/slotid/portid command to check whether the uplink port
on the ONU was added to the upstream VLAN.
l If the uplink port was added to the upstream VLAN, go to Step 4.
l If the uplink port was not added to the upstream VLAN, run the port vlan command to
add the uplink port to the upstream VLAN, whose configuration must be the same as
the configuration on the upper layer device. Then, go to Step 3.4.
Step 4 Check the PITP configuration on the ONU.

1. Run the display pitp config command to check whether the current global PITP function
is enabled.
l If the function is enabled, go to Step 4.2.
l If the function is not enabled, go to Step 5.
2. Run the display pitp config command to check the current PITP mode.
l If the current PITP mode is pmode, go to Step 4.5.
l If the current PITP mode is vmode, go to Step 4.3.
3. Run the display pitp vmode ether-type command to query the currently configured
Ethernet protocol type in the VBRAS packet and check whether the protocol type is the
same as the protocol type configured on the upper layer device.
l If the protocol types are the same, go to Step 5.
l If the protocol types are different, go to Step 4.4.
4. Run the pitp vmode ether-type command to change the current protocol type so it is the
same as the protocol type configured on the upper layer device, and then perform another
dialup check.

Module
5. Run the display pitp permit-forwarding service-port service-portid command to check

whether the function that allows user-side PPPoE packets to carry vendor tags is enabled
on the service port of the affected user.
l If the function is enabled, go to Step 5.
l If the function is not enabled, run the pitp permit-forwarding service-port service-
portid enable command to enable it on the service port. Then, go to Step 4.6.
Step 5 Check the user port MAC address configuration on the ONU.
1. Run the display mac-address port frameid/slotid/portid command to query the current
number of MAC addresses learned by the service port of the user.
2. Run the display mac-address max-mac-count service-port index command to query the
maximum number of MAC addresses that can be learned by the service port.
3. Check whether the current number of MAC addresses learned by the service port reaches
the maximum number of MAC addresses that can be learned by the service port.
l If the current number has reached the maximum number, run the mac-address max-
mac-count service-port index command to increase the maximum number of MAC
addresses that can be learned by the service port. Then, go to Step 6.
l If the maximum number has not been reached, go to Step 7.
Step 6 Perform a dialup check.

Step 7 Check whether the user's MAC address has drifted on the ONU.
times (more than three times is recommended) whether the user's MAC address has drifted
on the port that has learned the user's MAC address.
NOTE
l The F/S/P parameter in the query result indicates the service port where the user's MAC address
has been learned. Generally, the port displayed in the query result should be the service port of
the user. If the displayed port is not the service port of the user, the user's MAC address has
drifted.
user's MAC address has drifted. If such a problem occurs, disconnect the loop or deactivate
the port where the user attacks are initiated. Then, perform another dialup check.
Step 8 Check whether a BRAS's MAC address has drifted on the ONU.

Module
times is recommended) whether the BRAS's MAC address has drifted on the port that has
learned the BRAS's MAC address.
l If the BRAS's MAC address has drifted, go to Step 8.2.
l If the BRAS's MAC address has not drifted, go to Step 9.
NOTE
l The mac-addr parameter indicates the BRAS's MAC address.

l The F/S/P parameter in the query result indicates the uplink port where the BRAS's MAC address
has been learned. Generally, the port displayed in the query result should be the uplink port on
the ONU connected to the BRAS. If the displayed port is not the uplink port, the BRAS's MAC
address has drifted.
2. Check whether a loop has formed or there are user attacks on the port where the BRAS's
MAC address has drifted. If such a problem occurs, disconnect the loop or deactivate the
port where the user attacks are initiated. Then, perform another dialup check.
Step 9 Check whether the security configuration on the ONU is correct.
1. Run the display security config command to check whether the anti-MAC address
spoofing function is enabled.
2. Run the display mac-address static command to check whether a static MAC address is
configured on the service port of the user.
NOTE
If a static MAC address and the anti-MAC address spoofing function are configured on a service port
at the same time, the service port user cannot access the Internet.
l If a static MAC address is configured on the service port, go to Step 9.3.
l If no static MAC address is configured on the service port, go to Step 10.
3. Run the security anti-macspoofing disable command to disable the anti-MAC address
spoofing function on the service port or run the undo mac-address static command to
delete the static MAC address configured on the port based on the service planning. Then,
perform another dialup check.
Step 10 Check whether an ACL restricting the transmission of PPPoE packets is configured on the ONU.
1. Run the display packet-filter port frameid/slotid/portid command to check whether an
ACL is configured on the user port.
l If an ACL is configured, go to Step 10.2.
l If no ACL is configured, go to Step 11.
2. Run the display acl command to check whether the ACL restricts the transmission of
PPPoE packets.
l If the ACL restricts the transmission of PPPoE packets, go to Step 10.3.
l If the ACL does not restrict the transmission of PPPoE packets, go to Step 11.
3. Change the ACL rule that restricts the transmission of PPPoE packets or delete the ACL
configuration on the port. Then, perform another dialup check.

Module

Step 11 Check whether the data configuration on the OLT is correct.

1. Run the display service-port command to check whether the service port configuration on
the OLT, such as the user VLAN, upstream VLAN, ONU ID, and port ID, is correct.
NOTE
was added to the upstream VLAN.
Step 12 Check the data configuration on the upper layer device.

1. Check whether the MTU and QoS configurations on the upper layer device, such as the
upper layer router, are correct.
l If the configurations are correct, go to Step 12.3.
l If the configurations are incorrect, change the settings and ensure that the required data
configurations are correct. Then, go to Step 12.2.
3. Check whether the user data configuration on the upper layer BRAS is correct. Check, for
example, whether the user's account is restricted on the BRAS.
l If the data configuration on the BRAS is incorrect or the user's account is restricted,
change the settings on the BRAS. Then, go to Step 12.4.
l If the data configuration on the BRAS is correct and the user's account is not restricted,
go to Step 13.

Module
----End
2.3.1.5 Troubleshooting the Failure to Obtain an IP Address in DHCP Mode

This section describes how to troubleshoot a failure to obtain an IP address in Dynamic Host
Configuration Protocol (DHCP) mode. When a user accessing the Internet in xDSL mode on
fiber to the building (FTTB) and fiber to the curb (FTTC) network fails to obtain an IP address
by DHCP mode, refer to the following guidelines to address the issue.
Fault Location
User terminal If the fault does not recur when the The network interface card (NIC) in
user's PC is replaced, the fault is the PC is faulty or disabled.
on the PC.
is on the modem.
optical network l The quality of the subscriber line
unit (ONU) is deteriorated.
are loose.
ONU The user port is not activated. The user port is deactivated.
The fault does not recur when the The user port is faulty.
inconsistent with the data plan. such as the VLAN ID and port ID, is
incorrect.
device.
A MAC address drift occurs. A user or BRAS MAC address may

drift because of attacks or a loop on
the network.

Module
The security configuration is l The static IP binding function is

incorrect. enabled on the ONU.
l The MAC address filtering table
is incorrectly configured on the
ONU because the affected user is
configured in the table.
Link between The ONU cannot ping the DHCP l The configuration of the router
ONU and DHCP server. between the ONU and the DHCP
server sever is incorrect.
l The DHCP configuration on the
ONU is inconsistent with that on
the DHCP server.
l The link between the ONU and
the DHCP server is faulty.
DHCP server The ONU can obtain an IP address l The IP address of the DHCP
when the DHCP server is server is exhaust.
replaced. l The DHCP server is faulty.
incorrect.
device.


CAUTION
Procedure
1. Replace the user's PC with another one and then perform a dialup test to check whether the
new PC can obtain an IP address.

Module
l If the new PC can obtain an IP address, the fault is on the user's PC. Check whether the
PC's NIC is faulty or disabled, and address the problem. Then, go to Step 9.
l If the new PC fails to obtain an IP address, go to Step 1.2.
2. Check the indicator status on the modem to determine whether the modem is activated.
l If the modem is activated, go to Step 2.
l If the modem is not activated, go to Step 1.3.
3. Replace the modem and then check whether the modem can be activated.
4. Check whether the PC can obtain an IP address.
l If the PC can obtain an IP address, go to Step 9.
l If the PC fails to obtain an IP address, go to Step 2.
replace the old line as needed to ensure good line quality. Then, check whether the modem
can be activated.
7. Run the display port state portid command in xDSL mode to check whether the user port
is Deactivated.
l If the user port is Deactivated, go to Step 1.8.
l If the user port is not Deactivated, go to Step 1.9.
8. Run the activate portid command in xDSL mode to activate the xDSL port and then check
whether the port is Activated.
l If the user port is Activated, go to Step 1.10.
l If the user port is not Activated, go to Step 1.9.
9. Move the user to another port and then check whether the new port is Activated.
l If the new port is Activated, the original user port is faulty. Change the user's port and
reconfigure the port data. Then, go to Step 1.10.
l If the port is not Activated, go to Step 8.

1. Run the display service-port port frameid/slotid/portid command to check whether such
data configurations of the user's service port as the VLAN ID and port ID are correct.

Module
NOTE
l If the PC fails to obtain an IP address, go to Step 2.3.
Step 3 Check whether a user's MAC address drift has occurred on the ONU.
times (more than three times is recommended) whether a MAC address drift occurred on
the port that has learned the user's MAC address.
l If the MAC address drift has occurred, go to Step 3.2.
l If no MAC address drift has occurred, go to Step 4.
NOTE
drifted.
user's MAC address drift has occurred. If such a problem occurs, disconnect the loop or
deactivate the port where the user attacks are initiated. Then, perform another dialup check
and check whether the PC can obtain an IP address.

1. Run the display bind service-port index command to check whether the user's service port
is bound with an IP address.
l If the service port is bound with an IP address, run the undo bind command to cancel
the static IP address binding on the service port. Then, go to Step 4.2.
l If the service port is not bound with an IP address, go to Step 4.3.

Module
3. Run the display security mac-filter command to check whether the user's MAC address
is contained in the filtering list.
l If the user's MAC address is contained in the filtering list, run the undo security mac-
filter command to delete the MAC address from the filtering list. Then, go to Step
4.4.
l If the user's MAC address is not contained in the filtering list, go to Step 5.
Step 5 Check the interoperability between the DHCP server and the ONU.
1. Run the Ping command on the ONU to ping the IP address of the DHCP server.
l If the IP address can be pinged, go to Step 5.5.
l If the IP address cannot be pinged, check the configuration of the route between the
ONU and the DHCP server, the link between the ONU and the DHCP server, and the
DHCP server. Ensure that the ONU can communicate with the DHCP server normally.
Then, go to Step 5.2.
3. Run the display dhcp option82 config command to check whether the DHCP Option82
configuration on the access device is consistent with that on the DHCP sever.
l If the configurations are consistent, go to Step 5.5.
l If the configurations are inconsistent, change the configuration on one side as needed
to ensure that they are consistent. Then, go to Step 5.4.
5. Check whether the DHCP server is faulty and the IP address of the DHCP server is exhaust.
Ensure the DHCP server work in the normal state. Check whether the PC can obtain an IP
address.
1. Run the display service-port command on the OLT to check whether such service port
configurations on the OLT as the user VLAN, upstream VLAN, ONU ID, and port ID are
correct.
l If the configurations are incorrect, refer to the following notes to change the
NOTE

Module

3. Check whether the user data configuration on the upper layer BRAS is correct and whether
the user's account is restricted on the BRAS.
go to Step 8.
----End
Related Topics
2.3.2 Troubleshooting the Internet Service Fault (MDU Service

Access in LAN Mode)
This chapter describes how to troubleshoot common faults that users encounter when accessing
the Internet using MDU in LAN mode on fiber to the building (FTTB) and fiber to the curb
(FTTC) network. Common faults include Internet access failure, frequent service disconnection,

Module
low access rate, and failure to obtain an IP address by Point-to-Point Protocol over Ethernet
(PPPoE) dialup or Dynamic Host Configuration Protocol (DHCP) mode.
Prerequisites
communication between the ONU and the OLT, all the services on the ONU are interrupted. In
this case, according to fault symptom, troubleshoot the fault by referring to the methods
described in other topics.
NOTE
The following section lists common faults in communication between the ONU and the OLT.
2.3.2.1 Troubleshooting the Failure to Access the Internet

This section describes how to troubleshoot failures associated with local area network (LAN)
users accessing the Internet on fiber to the building (FTTB) and fiber to the curb (FTTC)
networks, for example, users fail to open Web pages.
Fault Location
User terminal A user fails to obtain the IP For the details about how to troubleshoot
address (excludes users this fault, see the following sections:
with a static IP address). l 2.3.2.4 Troubleshooting the Failure
to Obtain an IP Address by PPPoE
Dialup
l 2.3.2.5 Troubleshooting the Failure
to Obtain an IP Address in DHCP
Mode
The user obtains the IP l The user's PC is infected with viruses.

address successfully l Internet Explorer (IE) on the user's
(excludes users with a PC is faulty.
static IP address). The user
can access the Internet l The network interface card (NIC) in
after replacing the PC. the user's PC is faulty, or the PC is
slow to respond after running for a
long period.
Web site Certain Web sites fail to The Web site sever is faulty.
open.
No Web site can be The domain name server (DNS) fails to

opened. resolve the IP address.

Module
DNS A Web site can be opened l The DNS is faulty and fails to resolve
by entering its IP address. the domain name.
l The communication between the
user's PC and the DNS is abnormal.
CAUTION
Procedure
Step 1 Check the user's PC.
1. Check whether the user's PC can obtain the IP address.
NOTE
To view the IP address of the PC, do as follows:

press Enter.
b. In the command line interface (CLI) window displayed, run the ipconfig command to view the IP
address obtained by the PC.
l If the PC can obtain the IP address, go to Step 1.3.
l If the PC cannot obtain the IP address, do as follows:
– For PPPoE users, see 2.3.2.4 Troubleshooting the Failure to Obtain an IP
Address by PPPoE Dialup. Then, go to Step 1.2
– For DHCP users, see 2.3.2.5 Troubleshooting the Failure to Obtain an IP
Address in DHCP Mode. Then, go to Step 1.2
2. Check whether the user can access the Internet.
l If the user cannot access the Internet, go to Step 1.3.
3. Replace the user's PC with a test PC that can access the Internet in the same mode as the
user's PC. Then, check whether the user can access the Internet.
l If the user can access the Internet, the fault is on the user's PC. Check whether the user's
PC is infected with viruses, the NIC or IE of the user's PC is faulty, or the PC is slow
to respond after running for a long period. Then, go to Step 5.
Step 2 Check whether the user can access the Internet by going to various Web sites through the Web
server.
l If the user can access certain Web sites, the fault is on the Web site itself. Go to Step 5.
l If the user cannot access any Web sites, go to Step 3.
Step 3 Check the DNS.

Module
1. Enter the IP address of an existing Web site in the address bar of IE (format: http://
192.168.0.2) and check whether the Web site opens.
l If the Web site opens, the fault is on the DNS and the DNS cannot resolve the domain
name. Go to Step 3.2.
l If the Web site does not open, go to Step 4.
2. Check whether the PC can ping the IP address of the DNS.
NOTE
To view the DNS IP address of the PC, do as follows:

press Enter.
b. In the CLI window displayed, run the ipconfig/all command to view the DNS IP address obtained by
the PC.
l If the PC can ping the IP address of the DNS, the link between the PC and the DNS is
normal and the DNS is faulty. Go to Step 3.3.
l If the PC cannot ping the IP address of the DNS, go to Step 4.
3. Rectify the fault on the DNS. Then, check whether the user can access the Internet.
l If the user can access the Internet, go to Step 5.
----End
Related Topics
2.3.2.2 Troubleshooting Frequent Interruptions in Internet Service

This section describes how to troubleshoot frequent interruptions in Internet service when local
area network (LAN) users on fiber to the building (FTTB) and fiber to the curb (FTTC) networks
are accessing the Internet.
Fault Location
User terminal The fault does not recur when the The user's PC is infected with
user's PC is replaced. viruses or the network interface card
(NIC) in the user's PC is faulty.

Module
optical network l The subscriber line is old.
unit (ONU)
are loose.
l There is a strong source of
interference around the user.
ONU The Internet service on a single l The user port is faulty.

port is frequently interrupted. l The quality of the subscriber line
is deteriorated and the packet
loss on the subscriber line is
severe.
Internet services on all ONU ports l The ONU is faulty.

are frequently interrupted. l There is a strong source of
interference around the ONU.
l The MAC address has drifted
between ONU ports.
Upper layer Internet services of all users The BRAS MAC address has drifted
broadband connected to the BRAS are between ONU ports
remote access frequently interrupted.
server (BRAS)
CAUTION
Procedure
1. Replace the user's PC and then check whether Internet service is restored.
l If service is restored, the fault is on the user's PC. Check whether the NIC in the user's
PC is faulty or whether the user's PC is infected with viruses. Then, go to Step 7.
l If service is not restored, go to Step 1.2.
2. Replace the user terminal, and then check whether the service is restored.

Module

NOTE
Query the statistics of the faulty port multiple times (recommended: 10 times) and then compare the
statistics to check whether packet loss occurs on the subscriber line. The query interval is 20s.
Run the display port statistics portid command on the ONU to query all the performance statistics of the
subscriber line after the subscriber line is initialized. Then, check whether the number of CRC error frames
increases. If it increases, packet loss is occurring on the subscriber line.
properly or whether the line is old. Reconnect the line properly or replace the line as needed.
Then, check whether the service is restored.
3. Check whether there is a strong source of interference, such as a wireless base station or a
high-frequency switch power system, around the user.
l If there is a strong source of interference around the user, it may be the cause of the
fault. Contact the relevant department to handle it. Then, go to Step 7.
l If there is no strong source of interference around the user, go to Step 3.
Step 3 Change the port for the user and configure the necessary data on the ONU. Then, check whether
the service is restored.
l If the service is restored, the user port is faulty. Change the user's ONU port and reconfigure
the data. Then, go to Step 7.
(recommended: three times) whether the user's MAC address on the port that learned it has
drifted.
NOTE
address. Normally, the port displayed in the query result is the service port of the user. If the
displayed port is not the service port of the user, the user's MAC address has drifted.
2. Check whether a loop has formed or whether there are user attacks on the port that the user's
MAC address has drifted to. If a loop has formed, disconnect it. If the port that the MAC
address has drifted to is being attacked, deactivate the port initiating the attacks. Then,
Step 5 Check whether a BRAS MAC address drift has occurred on the ONU.
1. Run the display location mac-addr command to check multiple times (recommended: three
times) whether a BRAS MAC address has drifted away from the port that originally learned
it.

Module
l If the BRAS MAC address has drifted, go to Step 5.2.

l If the BRAS MAC address has not drifted, go to Step 6.
NOTE
l The mac-addr parameter in the command indicates the BRAS's MAC address.
l The F/S/P parameter in the query result indicates the uplink port that learned the BRAS MAC
address. Normally, the port displayed in the query result is the uplink port on the ONU connected
to the BRAS. If the displayed port is not the uplink port, the BRAS MAC address has drifted.
2. Check whether a loop has formed or whether there are user attacks on the port that the user's
MAC address has drifted to. If a loop has formed, disconnect it. If the port that the MAC
address has drifted to is being attacked, deactivate the port initiating the attacks. Then,
----End
Related Topics
2.3.2.3 Troubleshooting Low Internet Access Rate

Low Internet access rate indicates that the attainable Internet access rates for users are lower
than the rates provided them. This section describes how to troubleshoot low access rates when
local area network (LAN) users on fiber to the building (FTTB) and fiber to the curb (FTTC)
networks access the Internet.
Fault Location
User terminal The fault does not recur when the l The PC's network interface card
user's PC is replaced. (NIC) is faulty.
l The user's PC is infected with
viruses.
l The computer does not meet the
minimum configuration
requirements.

Module
ONU l The subscriber line is old.
are loose.
ONU The Internet access rate on a single l The rate restriction configuration
port is low. for the user is incorrect.
l Certain users' Internet access
rates are restricted on the BRAS.
The Internet access rates on all l A user's MAC address has drifted
ONU ports are low. between ONU ports.
l The upstream bandwidth on the
ONU is insufficient.
OLT The Internet access rates on all The DBA bandwidth that the OLT
ONU ports are low. allocates to the ONU is insufficient.
Upper layer Only certain users' Internet access Certain users' Internet access rates
BRAS rates are low; the services of other are restricted on the BRAS.
users on the BRAS are normal.
CAUTION
Procedure
Step 1 Determine the fault range when identifying the fault causes.
l If the Internet access rates of only certain users on the ONU are low whereas the rates of
other users are normal, go to Step 2.
l If the Internet access rates of all users on the ONU are low, go to Step 7.

1. Replace the user's PC and test whether the Internet access rate is normal.
l If the Internet access rate is normal, the fault is on the PC. Check whether the NIC in
the user's PC is faulty, the PC is infected with viruses, the PC is slow to respond after
running for a long time, or the PC's configuration is low. Then, go to Step 11.
l If the Internet access rate is low, go to Step 2.2.
2. Replace the user terminal, and then check whether the Internet access rate is normal.
l If the Internet access rate is normal, go to Step 11.
l If the Internet access rate is low, go to Step 3.

Module
NOTE
Query the statistics of the faulty port multiple times (recommended: 10 times) and then compare the
statistics to check whether packet loss occurs on the subscriber line. The query interval is 20s.
Run the display port statistics portid command on the ONU to query all the performance statistics of the
subscriber line after the subscriber line is initialized. Then, check whether the number of CRC error frames
increases. If it increases, packet loss is occurring on the subscriber line.
properly or whether the line is old. Reconnect the line properly or replace the line as needed.
Then, check whether the Internet access is normal.
l If the Internet access is normal, go to Step 11.
l If the Internet access is low, go to Step 4.
Step 4 Check whether unknown traffic is occupying the bandwidth on the ONU.
1. Ensure that the user is not accessing the Internet. Run the display port statistics portid
command to query the statistics of the Ethernet port multiple times (recommended: five
times). The query interval is 20s.
l If the upstream or downstream traffic increases rapidly, unknown traffic is occupying
the bandwidth. Go to Step 4.2.
l If the upstream or downstream traffic does not increase, go to Step 5.
NOTE
Normally, the query results should be similar when the user is not accessing the Internet.
l Number of transmitted octets: Indicates the current downstream traffic of the user.
l Number of received octets: Indicates the current upstream traffic of the user.
2. Use packet-capturing software, such as Ethereal, to capture packets on the user's PC,
confirm the known traffic source, and then eliminate the unknown traffic source. You can
eliminate the unknown traffic source by checking whether the PC sending the unknown
traffic is infected with viruses. Then, check whether the Internet access rate is restored.
Step 5 Check the maximum rate configured for the user.

1. Run the display service-port command to query the indexes of the traffic profiles in the
receive and transmit directions configured for the service port.
2. Run the display traffic table ip command to query the corresponding traffic profile. Then,
check whether the committed information rate (CIR) reaches the bandwidth that the user
applied for.
l If the CIR is less than the bandwidth that the user applied for, the traffic profile bound
to the user is incorrect. Go to Step 5.3.
l If the CIR is equal to the bandwidth that the user applied for, go to Step 6.
3. Run the undo service-port command to delete the service port of the user. Then, run the
service-port command to reconfigure a service port for the user and bind the user to the
proper traffic profile. Check whether the Internet access rate is restored.

Module

l If the Internet access rate is not restored, go to Step 6.
NOTE
When modifying the traffic profile, note the following:

l The service ports bound to the traffic profile take effect at the same time when the traffic profile is
modified.
l If the current traffic profile is bound to multiple service ports, run the traffic table ip command to
create the required traffic profile.
l If the current traffic profile is bound to one service port, run the traffic table ip modify command to
modify the traffic profile.
(recommended: three times) whether the user's MAC address has drifted away from the
port that originally learned it.
NOTE
address. Normally, the port displayed in the query result is the service port of the user. If the
displayed port is not the service port of the user, the user's MAC address has drifted.
has drifted to is being attacked, deactivate the port initiating the attacks. Then, check
whether the Internet access rate is restored.
l If the Internet access rate is not restored, go to Step 7.
Step 7 Query the OLT for the DBA bandwidth that the OLT allocates to the ONU.
1. Run the display ont info portid ontid command to query the DBA bandwidth that the OLT
allocates to the ONU.
Query the value of the DBA Profile-ID parameter.

2. Run the display DBA-profile profile-id profile-id command to query the bandwidth
configured in the DBA profile.
3. Check whether the bandwidth occupied by the uplink port on the ONU reaches the allocated
DBA bandwidth.
l If the bandwidth occupied by the uplink port on the ONU almost reaches the permitted
maximum bandwidth, the bandwidth of the uplink port on the site is the cause of the
fault. Go to Step 7.4.
l If the bandwidth occupied by the uplink port on the ONU is lower than the maximum
attainable bandwidth, go to Step 8.
4. Change the DBA bandwidth that the OLT allocates to the ONU or reduce the number of
users on the device by cutting users over to another device. Then, check whether the service
is restored.

Module

Step 8 Check whether the upper layer BRAS is restricting the user rate.
l If the rate of the affected user is restricted on the BRAS, modify the BRAS configuration.
Then, go to Step 9.
l If the rate of the affected user is not restricted on the BRAS, go to Step 10.
l If service is normal, go to Step 11.
l If service is not normal, go to Step 10.
----End
Related Topics
2.3.2.4 Troubleshooting the Failure to Obtain an IP Address by PPPoE Dialup

This section describes how to troubleshoot a failure to obtain an IP address by point-to-point
over Ethernet (PPPoE) dialup mode. When a user accessing the Internet in LAN mode on fiber
to the building (FTTB) and fiber to the curb (FTTC) network fails to obtain an IP address by
PPPoE dialup, refer to the following guidelines to address the issue.
Fault Location
Perform a PPPoE dialup emulation test to determine the fault scope first.
If the result of the PPPoE dialup emulation test is "success," the link between the optical network
unit (ONU) and the upper layer broadband remote access server (BRAS) is normal. Therefore,
the fault must be located on the link between the ONU and the user terminal. Use the following
guidelines to locate the fault more accurately.
User terminal If the fault does not recur when the l The dialup software is not
user's PC is replaced, the fault is properly installed on the PC.
on the PC. l The network interface card
(NIC) in the PC is faulty.
is on the modem.

Module
is deteriorated.
are loose.
The user port is deactivated.
ONU The fault does not recur when the The user port is faulty.
line of the affected user is
connected to another user port.
inconsistent with the data plan. such as the port ID, is incorrect.
If the result of the PPPoE dialup emulation test is not "success," the fault must be located on the
link between the ONU and the upper layer BRAS. Use the following guidelines to address the
fault more accurately.
ONU The configured service port data is The configured service port data,
inconsistent with the data plan. such as the VLAN ID, is incorrect.
The uplink port forwards no The uplink port on the ONU is not
device.
The security configuration is l The Policy Information Transfer

incorrect. Protocol (PITP) configuration is
incorrect.
l The configured number of MAC
addresses that can be
dynamically learned by the
service port is incorrect.
l The configuration of the anti-
MAC address spoofing function
is incorrect.
l An access control list (ACL) that
does not allow transmission of
PPPoE packets is configured.
A MAC address drift occurs. l A user or BRAS MAC address

may drift because of attacks or a
loop on the network.

Module
incorrect.
The uplink port forwards no The uplink port on the OLT is not
device.


CAUTION
Procedure
Step 1 Perform a PPPoE dialup emulation test on the ONU for the affected user.
l If the result of the dialup emulation test is not "success," go to Step 4.
NOTE
If the result of the dialup emulation test is "timeout," "parameter negotiation failure," "user authentication
failure," "offline requested by the peer end," or other errors, the fault is located on the upper layer device
of the ONU.
l If the result of the dialup emulation test is "success," go to Step 2.
1. Replace the user's PC with another and perform a dialup emulation test to check whether
the dialup can be successful.
l If the dialup is successful, the fault is related to a problem on the user's PC. Check
whether the PPPoE software is installed on the PC incorrectly and whether the PC's NIC
is faulty or disabled, and address the problem. Then, go to Step 15.
2. Replace the modem and perform a dialup check. Then, check whether the dialup is
successful.
Step 3 Check the interoperability between the user terminal and the ONU.
1. In ETH mode, run the display port state portid command on the ONU to check whether
Active State of the Ethernet port is active.

Module
l If Active State of the Ethernet port is active, go to Step 3.3.

l If Active State of the Ethernet port is not active, go to Step 3.2.
2. Run the undo shutdown portid command to activate the Ethernet port. Then, check
whether it is in the active state.
l If it is in the active state, go to Step 3.3.
l If it is not in the active state, go to Step 3.9.
3. Run the display port state portid command to check whether Link of the Ethernet port is
online.
l If Link of the Ethernet port is online, go to Step 3.4.
l If Link of the Ethernet port is not online, go to Step 3.5.
5. Check the quality of the physical line between the ONU and the user terminal to determine
replace the old line as needed to ensure good line quality. Then, check whether Link of the
Ethernet port is online.
7. In ETH mode, run the display port state portid command to check whether the duplex
mode, rate, network cable adaptation mode of the Ethernet port are consistent with those
of the user terminal.
l If they are consistent, go to Step 3.9.
l If they are inconsistent, modify the parameter settings of the Ethernet port to ensure that
the parameter settings are consistent with those of the user terminal. Then, go to Step
3.8.
NOTE
In ETH mode, modify the parameter settings of the Ethernet port by using the following methods:
l Run the auto-neg command to enable or disable the auto-negotiation mode of the Ethernet port.
After the auto-negotiation mode of the Ethernet port is enabled, the Ethernet port automatically
negotiates the port rate and duplex mode with the interconnected port.
l Run the duplex command to configure the duplex mode of the Ethernet port to full duplex or half
duplex.
l Run the mdi command to configure the network cable adaptation mode of the Ethernet port.
l Run the speed command to configure the rate of the Ethernet port.
9. Replace the port and perform a dialup check. Then, check whether the dialup is successful.
l If the dialup is successful, the original user port is faulty. Change the user's port and
reconfigure the port data. Then, go to Step 15.

Module

1. Run the display service-port port frameid/slotid/portid command to check whether the
data configuration of the user's service port, such as the VLAN ID and port ID, is correct.
l If the data configuration of the user's service port is correct, go to Step 4.3.
l If the data configuration of the user's service port is incorrect, go to Step 4.2.
NOTE
the configuration on the upper layer device.Then, go to Step 4.4.
Step 5 Check the PITP configuration on the ONU.

1. Run the display pitp config command to check whether the current global PITP function
is enabled.
2. Run the display pitp config command to check the current PITP mode.
l If the current PITP mode is pmode, go to Step 5.5.
l If the current PITP mode is vmode, go to Step 5.3.
3. Run the display pitp vmode ether-type command to query the currently configured
Ethernet protocol type in the VBRAS packet and check whether the protocol type is the
same as the protocol type configured on the upper layer device.
l If the protocol types are the same, go to Step 6.
l If the protocol types are different, go to Step 5.4.
4. Run the pitp vmode ether-type command to change the current protocol type so it is the
same as the protocol type configured on the upper layer device, and then perform another
dialup check.
5. Run the display pitp permit-forwarding service-port service-portid command to check
whether the function that allows user-side PPPoE packets to carry vendor tags is enabled
on the service port of the affected user.

Module
l If the function is enabled, go to Step 6.

l If the function is not enabled, run the pitp permit-forwarding service-port service-
portid enable command to enable it on the service port. Then, go to Step 5.6.
Step 6 Check the user port MAC address configuration on the ONU.
1. Run the display mac-address port frameid/slotid/portid command to query the current
number of MAC addresses learned by the service port of the user.
2. Run the display mac-address max-mac-count service-port index command to query the
maximum number of MAC addresses that can be learned by the service port.
3. Check whether the current number of MAC addresses learned by the service port reaches
the maximum number of MAC addresses that can be learned by the service port.
l If the current number has reached the maximum number, run the mac-address max-
mac-count service-port index command to increase the maximum number of MAC
addresses that can be dynamically learned by the service port. Then, go to Step 7.
l If the maximum number has not been reached, go to Step 8.
Step 7 Perform a dialup check.

Step 8 Check whether a user's MAC address has drifted on the ONU.
NOTE
l The mac-addr parameter in the command indicates the user's MAC address. For user terminal
dialup, the user's MAC address is the MAC address of the user terminal. For PC dialup, the user's
MAC address is the MAC address of the PC.
drifted.
deactivate the port where the user attacks are initiated. Then, perform another dialup check.
Step 9 Check whether a BRAS MAC address drift has occurred on the ONU.
times is recommended) whether a MAC address drift occurred on the port that has learned
the BRAS MAC address.

Module

NOTE
l The mac-addr parameter indicates the MAC address of the BRAS.

l The F/S/P parameter in the query result indicates the uplink port where the BRAS MAC address
has been learned. Generally, the port displayed in the query result should be the uplink port on
the ONU connected to the BRAS. If the displayed port is not the uplink port, the BRAS MAC
address drift has occurred.
deactivate the port is initiating the attacks. Then, perform another dialup check.

1. Run the display security config command to check whether the anti-MAC address
spoofing function is enabled.
2. Run the display mac-address static command to check whether a static MAC address is
configured on the service port of the user.
NOTE
If a static MAC address and the anti-MAC address spoofing function are configured on a service port
at the same time, the service port user cannot access the Internet.
l If a static MAC address is configured on the service port, go to Step 10.3.
l If no static MAC address is configured on the service port, go to Step 11.
3. Run the security anti-macspoofing disable command to disable the anti-MAC address
spoofing function on the service port or run the undo mac-address static command to
delete the static MAC address configured on the port based on the service planning. Then,
perform another dialup check.
Step 11 Check whether an ACL restricting the transmission of PPPoE packets is configured on the ONU.
1. Run the display packet-filter port frameid/slotid/portid command to check whether an
ACL is configured on the user port.
l If an ACL is configured, go to Step 11.2.
l If no ACL is configured, go to Step 12.
2. Run the display acl command to check whether the ACL restricts the transmission of
PPPoE packets.
l If the ACL restricts the transmission of PPPoE packets, go to Step 11.3.
l If the ACL does not restrict the transmission of PPPoE packets, go to Step 12.
3. Change the ACL rule that restricts the transmission of PPPoE packets or delete the ACL
configuration on the port. Then, perform another dialup check.

Module

1. Run the display service-port command to check whether the service port configuration on
the OLT, such as the user VLAN, upstream VLAN, ONU ID, and port ID, is correct.
NOTE
go to Step 14.
----End

Module
2.3.2.5 Troubleshooting the Failure to Obtain an IP Address in DHCP Mode

This section describes how to troubleshoot a failure to obtain an IP address in Dynamic Host
Configuration Protocol (DHCP) mode. When a user accessing the Internet in LAN mode on
fiber to the building (FTTB) and fiber to the curb (FTTC) network fails to obtain an IP address
by DHCP mode, refer to the following guidelines to address the issue.
Fault Location
User terminal If the fault does not recur when the The network interface card (NIC) in
user's PC is replaced, the fault is the PC is faulty or disabled.
on the PC.
is on the modem.
is deteriorated.
are loose.
ONU The user port is not activated. The user port is deactivated.
The fault does not recur when the The user port is faulty.
inconsistent with the data plan. such as the VLAN ID and port ID, is
incorrect.
device.
A MAC address drift occurs. A user or BRAS MAC address may

drift because of attacks or a loop on
the network.
The security configuration is l The static IP binding function is

incorrect. enabled on the ONU.
l The MAC address filtering table
is incorrectly configured on the
ONU because the affected user is
configured in the table.

Module
Link between The ONU cannot ping the DHCP l The configuration of the router
ONU and DHCP server. between the ONU and the DHCP
server sever is incorrect.
l The DHCP configuration on the
ONU is inconsistent with that on
the DHCP server.
l The link between the ONU and
the DHCP server is faulty.
DHCP server The ONU can obtain an IP address l The IP address of the DHCP
when the DHCP server is server is exhaust.
replaced. l The DHCP server is faulty.
incorrect.
device.


CAUTION
Procedure
1. Replace the user's PC with another one and then perform a dialup test to check whether the
new PC can obtain an IP address.
l If the new PC can obtain an IP address, the fault is on the user's PC. Check whether the
PC's NIC is faulty or disabled, and address the problem. Then, go to Step 10.
l If the new PC fails to obtain an IP address, go to Step 1.2.
2. Replace the user terminal with another one and then check whether the new user terminal
can obtain an IP address.
l If the new user terminal can obtain an IP address, go to Step 10.

Module
l If the new user terminal fails to obtain an IP address, go to Step 2.
Step 2 Check the interoperability between the user terminal and the ONU.
1. In ETH mode, run the display port state portid command on the ONU to check whether
Active State of the Ethernet port is active.
l If Active State of the Ethernet port is active, go to Step 2.3.
l If Active State of the Ethernet port is not active, go to Step 2.2.
2. Run the undo shutdown portid command to activate the Ethernet port. Then, check
whether it is in the active state.
l If it is in the active state, go to Step 2.3.
l If it is not in the active state, go to Step 2.9.
3. Run the display port state portid command to check whether Link of the Ethernet port is
online.
5. Check the quality of the physical line between the ONU and the user terminal to determine
replace the old line as needed to ensure good line quality. Then, check whether Link of the
Ethernet port is online.
7. In ETH mode, run the display port state portid command to check whether the duplex
mode, rate, and network cable adaptation mode of the Ethernet port are consistent with
those of the user terminal.
l If they are consistent, go to Step 2.9.
l If they are inconsistent, modify the settings of the Ethernet port to ensure that the settings
are consistent with those of the user terminal. Then, go to Step 2.8.
NOTE
In ETH mode, modify the parameter settings of the Ethernet port by using the following methods:
l Run the auto-neg command to enable or disable the auto-negotiation mode of the Ethernet port.
After the auto-negotiation mode of the Ethernet port is enabled, the Ethernet port automatically
negotiates the port rate and duplex mode with the interconnected port.
l Run the duplex command to configure the duplex mode of the Ethernet port to full duplex or half
duplex.
l Run the mdi command to configure the network cable adaptation mode of the Ethernet port.
l Run the speed command to configure the rate of the Ethernet port.

Module

9. Replace the user port and then check whether the PC can obtain an IP address.
l If the PC can obtain an IP address, the original user port is faulty. Change the user's port
and reconfigure the port data. Then, go to Step 10.
1. Run the display service-port port frameid/slotid/portid command to check whether such
data configurations of the user's service port as the VLAN ID and port ID are correct.
NOTE
Step 4 Check whether a user's MAC address has drifted on the ONU.
l If a MAC address drift occurred on the port, go to Step 4.2.
l If a MAC address drift did not occur on the port, go to Step 5.
NOTE
deactive port is initiating the attacks. Then, perform another dialup check and check whether
the PC can obtain an IP address.

Module
Step 5 Check the security configuration on the ONU.

1. Run the display security mac-filter command to check whether the user's MAC address
is contained in the filtering list.
l If the user's MAC address is contained in the filtering list, run the undo security mac-
filter command to delete the user's MAC address from the filtering list. Then, go to
Step 5.2.
l If the user's MAC address is not contained in the filtering list, go to Step 6.
Step 6 Check the interoperability between the DHCP server and the ONU.
1. Run the Ping command on the ONU to ping the IP address of the DHCP server.
l If the IP address can be pinged, go to Step 6.5.
l If the IP address cannot be pinged, check the configuration of the route between the
ONU and the DHCP server and ensure that the ONU can communicate with the DHCP
server normally. Then, go to Step 6.2.
2. Check whether the IP address can be obtained.
l If the IP address can be pinged, go to Step 10.
l If the IP address cannot be pinged, go to Step 6.3.
3. Run the display dhcp option82 config command to check whether the DHCP Option82
configuration on the access device is consistent with that on the DHCP sever.
l If the configurations are consistent, go to Step 6.5.
l If the configurations are inconsistent, change the configuration on one side as needed
to ensure that they are consistent. Then, go to Step 6.4.
5. Check whether the DHCP server is faulty and the IP address of the DHCP server is exhaust.
Ensure the DHCP server work in the normal state. Check whether the PC can obtain an IP
address.

1. Run the display service-port command on the OLT to check whether such service port
configurations on the OLT as the user VLAN, upstream VLAN, ONU ID, and port ID are
correct.
l If the configurations are incorrect, refer to the following notes to change the

Module
NOTE

go to Step 9.
----End
Related Topics

Module
2.3.3 IPTV Service Failure

This topic describes how to troubleshoot an IPTV service fault in a GPON FTTB or FTTC
network. The common faults in the IPTV service include failure to go online of a multicast user,
blank screen after ordering programs, pixelation in a multicast program, abnormal interruption
of a multicast program, and long time in switching programs.
Prerequisites
l The MDU and OLT communicate with each other normally. If a fault occurs in
communication between the MDU and the OLT, all the services on the MDU are
interrupted. In this case, troubleshoot the fault first by referring to the methods described
in other topics according to the fault symptom.
NOTE
The following lists common faults in communication between the MDU and the OLT.
l MDU Registration Failure
l Failure to Automatically Find an MDU
l MDU Frequently Goes Online and Offline
l The OLT manages an MDU using a multicast cascading port. The OLT uses IGMP proxy
and the MDU uses the IGMP proxy in the multicast VLAN mode.
Precautions
l Different MDUs support different functions and commands. In troubleshooting the IPTV
service faults, the MA5616 is used as an example.
l Causes of the IPTV service failure are the same for a DSL-connected MDU or LAN-
connected MDU. Therefore, the troubleshooting methods and procedure are also applicable
to these two types of MDUs unless otherwise specified.
Related Topics
7.3 Troubleshooting Cases of IPTV Service Faults
2.3.3.1 Failure to Go Online of a Multicast User

This topic describes how to troubleshoot the fault when a multicast user fails to order any
programs because the multicast user fails to go online (the queried user status is offline or
block on the MDU). When such a fault occurs in an FTTB or FTTC network, locate the fault
according to the following procedure.
Location Method
When a multicast user in an FTTB or FTTC network is blocked, run the undo igmp user
block command to unblock the user.
When a multicast user in an FTTB or FTTC network is offline, enable the MDU debugging
function and locate the fault according to whether the MDU receives the report packet from the
multicast user.
l If the MDU receives the report packet, the multicast link is normal but the MDU fails to
create a corresponding multicast entry. This is generally caused by incorrect multicast
configurations on the MDU.

Module
l If the MDU does not receive the report packet, the multicast link fails. This is mainly caused
by incorrect MDU software configurations, faulty physical link between the MDU and the
modem, and hardware faults of terminals.
Table 2-20 describes fault symptoms and possible causes when a multicast user in an FTTB or
FTTC network is offline.
Table 2-20 Fault symptoms and possible causes when a multicast user in an FTTB or FTTC
network is offline
Scope
MDU The MDU receives the l The program ordered is not in the MVLAN to
report packet. which the multicast user belongs.
l No upstream port is configured in the MVLAN
to which the multicast user belongs.
permission to watch the program.
l The maximum multicast bandwidth of the user
is lower than the required bandwidth of the
ordered program.
permission to order certain types of programs
(such as HDTV).
The MDU does not receive The IGMP function of the MVLAN on the MDU
the report packet and all is disabled.
users in the MVLAN fail to
go online.
The MDU does not receive l The xDSL port on the MDU fails to be
the report packet and a activated due to incorrect line profile
single user or some users configurations. This cause is excluded when
fail to go online. the MDU is connected to the user using a LAN.
l The VPI/VCI on the MDU are different from
those on the modem. This cause is excluded
when the MDU is connected to the user using
a LAN.
MDU to The MDU does not receive l The hardware of the port on the MDU is faulty.
the the report packet and a l The physical line between the MDU and the
terminal single user fails to go modem is faulty. This cause is excluded when
online. the MDU is connected to the user using a LAN.
l The modem is faulty. This cause is excluded
when the MDU is connected to the user using
a LAN.
l The set-top box (STB) is faulty.

Module
NOTE
Faults can be located according to specific scenarios because fault scopes are different for deployment and
routine operation and maintenance.
l If the fault occurs during deployment, check initial configurations of the hardware and the software.
l If a multicast user fails to go online during O&M, check only the hardware because the software
configuration of a user is generally not modified in this scenario. Hence, if the status of a user changes
from normal to abnormal, it is generally caused by hardware failures. If a multicast link failure occurs
after a new user is added or an existing user is modified, check whether the configuration is correct.
CAUTION
Procedure
Step 1 On the MDU, run the display igmp user user-index command to query the multicast user status
(State).
l If State is block, the multicast user is blocked. In this case, run the undo igmp user block
command to unblock the user. Then, go to Step 2.
l If State is offline, go to Step 3.
NOTE
If you need to block a multicast user from watching programs temporarily without deleting the user (for
example, when the user owes charges), run the igmp user block command to block the user. When the
user is blocked, the MDU forces the user to go offline from the current program. In addition, the MDU
rejects the user from ordering programs until the user is unblocked.
Step 3 Enable the MDU debugging function and collect information as follows:
1. Enable the function of multicast user monitoring.
huawei(config)#debugging igmp
2. Order the program again. Then, go to Step 4.

NOTE
After the preceding steps are performed, run the following commands to disable the debugging function.
Step 4 Locate the fault according to the receiving condition of the report packet and the fault scope.
l If the MDU displays a prompt message of the program, the MDU receives the report packet.
In this case, go to Step 5.1.
l If the MDU does not display a prompt message of the program, the MDU does not receive
the report packet. In this case, locate the fault according to the fault scope.
– If all users in the MVLAN fail to go online, go to Step 5.2.

Module
– If a single user or some users in the MVLAN fail to go online, go to Step 6.

Step 5 Check multicast configurations of the MDU.
1. If the MDU receives the report packet, find the possible cause according to judgment criteria
described in Table 2-21 and then troubleshoot the fault. Then, go to Step 5.3 to check
whether the fault is rectified.
Table 2-21 Incorrect multicast configurations of the MDU

e
Cause
The If one of the following symptoms Choose one of the following

maximu occurs, the fault is because the troubleshooting methods
m maximum multicast bandwidth of the according to the purchased service
multica user is lower than the required type:
st bandwidth of the ordered program. l Notify the user of ordering
bandwi l The MDU receives the report packet another program (whose
dth of and displays "the user fails to pass bandwidth is lower than the
the user bandwidth CAC". maximum bandwidth of the
is lower user) because the bandwidth is
than the l The maximum bandwidth of the
user is lower than the bandwidth of insufficient and the program
required cannot be watched.
bandwi the ordered program by running the
dth of display igmp user user-index l Increase the user bandwidth
the command to query the maximum and notify the user of ordering
ordered bandwidth (User MaxBandWidth) the program again.
progra of the user and running the display NOTE
m. igmp program name command to Run the igmp user modify user-
query the bandwidth (Bandwidth) index max-bandwidth command to
of the ordered program. modify the maximum bandwidth of
the user to ensure that it is higher than
NOTE the program bandwidth.
If User MaxBandWidth is no-limit, the
multicast bandwidth of the user is not
limited.

Module

e
Cause

multica occurs, the fault is because the multicast troubleshooting methods
st user user does not have the permission to according to the purchased service
does not order certain types of programs. type:
have the l The MDU receives the report packet l Notify the user of ordering
permiss and displays "the number of the another program (the maximum
ion to grade program that the user is number of the programs at this
order allowed to watch has reached level must not be 0) because the
certain maximum". user does not have the
types of permission to watch the ordered
progra l The maximum number (watch
limit) of programs at a level that can program.
ms
(such as be watched by the user is 0 by l Set the permission for ordering
HDTV) running the display igmp user the programs at this level for the
. extended-attributes user-index user so that the user can order
command on the MDU. the program.
NOTE NOTE
l If the maximum number of the You can run the igmp user watch-
programs at a certain level is 0, the user limit command to set the number of
cannot order any programs at this level. programs at each level that a user can
That is, the user's permission to the watch.
programs of the corresponding type is
restricted. For example, if HDTV
watch limit is 0, the user cannot watch
HDTV programs.
l If watch limit is no-limit, the
maximum number of the programs at
this level that a user can watch is not
limited, but the total number of
programs that can be concurrently
watched is limited.

Module

e
Cause

does not watch the program. type:
have the l The MDU receives the report packet l If the user can watch all
permiss and displays "the user has no right". programs without
ion to authentication, perform the
watch l Run the display igmp user 100
command to query the right profile following two operations:
the
bound to the multicast user (assume a. In the BTV mode, run the
that the service port of the multicast igmp user modify 100 no-
user is 100). auth command to modify
– If Bind profiles is 0, the user is the authentication mode of
not bound to a right profile and the user to "no
the user cannot order any authentication" (assume
programs. that the multicast user index
is 100).
– If Bind profiles is equal to or
larger than 1, the user can watch b. Order the program again.
only the program to which the l If the user can watch certain
user has the watch permission. In programs with authentication,
this case, perform operations for notify the user of ordering
further check. In the queried another program because the
result, find the index (assume user has no permission to watch
that the index is 1) and name of the program. The permission to
the program right profile bound watch the program is watch or
to the user and run the display preview.
igmp profile profile-index 1
command to query the user
permission for ordering the
program.
program.
program is watch or
the program. Therefore, this
is not the cause for this fault.

Module

e
Cause
progra NOTE NOTE

configured with different permissions to a user bind-profile 100 profile-index-
same program, the permission with the list 1 command to bind a correct right
highest priority prevails. By default, the profile to the multicast user (assume
priority of the program permissions is that the multicast user index is 100 and
forbidden > preview > watch > idle. You the right profile index is 1).
can run the igmp right-priority command
to set the priority.

Module

e
Cause
The If the following symptoms occur, the Choose one of the following
progra fault is because the program ordered is troubleshooting methods
m not in the MVLAN to which the according to the purchased service
ordered multicast user belongs. type:
is not in l The MDU receives the report packet l Notify the user of ordering
the and displays "match program fail". another program because the
MVLA user has no permission to watch
N to l The program ordered is not in the
MVLAN to which the multicast the program (the program is
which included in the MVLAN to
the which the multicast user
multica belongs).
st user
l Perform the following steps to
add the program to the
MVLAN to which the multicast
user belongs and then order the
program again.
query Program match
mode of the program.
mode is enable, the
program is a static
program, which is
manually added.
program, which is
upon the ordering.
MVLAN.
igmp program add
command.
– To add a dynamic
program to an MVLAN,
run the igmp match
group command to set
the IP address range of
program groups that can
be generated

Module

e
Cause
belongs user belongs by running the display dynamically in the

. igmp program vlan command. MVLAN, and ensure
that the IP address range
includes the IP address
of the ordered program.
No If the following symptoms occur, the Add the upstream port to the
upstrea fault is because no upstream port is MVLAN to which the multicast
m port configured in the MVLAN to which the user belongs and notify the user of
is multicast user belongs. ordering the program again.
configu l The MDU receives the report packet NOTE
red in and displays "match program fail". In the MVLAN mode, run the igmp
the uplink-port command to set the
MVLA l No upstream port maps the upstream port as the upstream port of
N to MVLAN to which the multicast the MVLAN. This allows the
user belongs by running the display upstream port to forward the multicast
which packets of this MVLAN.
the igmp uplink-port all command to
multica query the multicast upstream port.
st user
belongs
.
2. If the MDU does not receive the report packet and all users in the MVLAN fail to go online,
the IGMP function may be disabled in the MVLAN. In this case, run the display igmp
config vlan command in the MVLAN mode to query IGMP mode of the MVLAN.
l If IGMP mode is off, the IGMP function is disabled in the MVLAN. In this case, run
the igmp mode command in the MVLAN mode to set IGMP mode to proxy or
snooping accordingly. Order a program and then, go to Step 5.3.
l If IGMP mode is proxy or snooping, the IGMP function is enabled in the MVLAN
and it is not the cause of the fault. Then, go to Step 6.
NOTE
If the terminal used by the user does not support multicast management, enable the IGMP function
on the MDU. Otherwise, the multicast service cannot be provisioned to the user.
3. Check whether the user can go online.
Step 6 If the MDU does not receive the report packet and the other users in the MVLAN can go online,
find the possible cause according to judgment criteria described in Table 2-22 and then
troubleshoot the fault. Then, go to Step 7 to check whether the fault is rectified.

Module
Table 2-22 Line and terminal faults

e Cause
The If the following symptoms occur, the fault Choose one of the following
xDSL is because the xDSL port on the MDU troubleshooting methods according
port on fails to be activated due to incorrect line to the specific symptom of the fault:
the profile configurations. l If the multicast user can go online
MDU l An MDU is connected to a user using first but then goes offline, the
fails to xDSL. software configurations are
be correct. In this case, check the
activate l The port to which the multicast user
belongs is in the Activating state or hardware, including the xDSL
d due to port, the modem, and the line
incorrect Deactivated state by running the
display board frameid/slotid between the MDU and the
line modem.
profile command to query the port status
configur (Status). l If the multicast user cannot go
ations. online and the port cannot be
activated, check the modem,
MDU configurations, and the line
between the MDU and the
modem. You can refer to
configurations of other normal
ports and bind an appropriate line
profile to the faulty port. For
details, see 6.8 Changing the
Line Profile (Template) of an
xDSL Port.
The If the following symptoms occur, the fault If VPI/VCI settings of the traffic
VPI/ is because the VPI/VCI on the MDU are stream are different from those
VCI on different from those on the modem. configured on the modem, modify
the l An MDU is connected to a user using VPI/VCI settings of the MDU to be
MDU xDSL. the same as those configured on the
are modem, or modify VPI/VCI settings
different l The VPI/VCI settings of the traffic of the modem to be the same as those
from stream are different from those configured on the MDU.
those on configured on the modem after query
NOTE
the by running the display service-port
To modify the VPI/VCI settings on the
modem. port frameid/slotid/portid command. MDU, run the undo service-port
command on the MDU to delete the
original service port, and then run the
service-port command to create a new
service port and set the VPI/VCI.
The The user can go online after migrating Migrate configurations of the faulty
hardwar configurations of the faulty port to a port to a functional one or replace the
e of the functional one and ordering the program. board to which the faulty port
port on belongs.
the
MDU is
faulty.

Module

e Cause
The The user can go online after using a Use a functional line.
physical functional line and ordering the program.
line
between
the
MDU
and the
modem
is faulty.
The The modem indicator is in the abnormal Resetting the modem or use a
modem state. The user can go online after functional modem.
is faulty. resetting the modem or using a functional
modem and ordering the program.
The STB The user can go online after resetting the Reset the STB or use a functional
is faulty. STB or using a functional STB and STB.
----End
2.3.3.2 Blank Screen After Ordering a Program

Blank screen after program ordering is a fault that a user cannot watch the program after the user
orders a program. When blank screen occurs after a user orders a program in an FTTB or FTTC
Location Method
When blank screen occurs after a user orders a program in an FTTB or FTTC network, the fault
scope can be determined by detecting the location where program traffic interruption occurs, as
shown in Figure 2-8.

Module
Figure 2-8 Locating the blank screen fault

Detection point 1: User
port of the MDU
Detection point 2:
Upstream port of the MDU
LAN access
MDU
TV STB
Detection point 3:
Upstream port of the OLT
Optical splitter
STB
TV
Multicast router Multicast router
DSL access
MDU
Modem
TV STB
STB
TV
Scope: MDU Scope: OLT

Scope: user terminal Scope: upper-layer network and devices
Symptom: Multicast streams reach Symptom: Multicast streams
Symptom: Multicast of the OLT
the upstream port of the MDU but reach the upstream port of the
streams reach the user Symptom: Multicast streams do not
do not reach the user port of the OLT but do not reach the
port of the MDU. reach the upstream port of the OLT.
MDU. upstream port of the MDU.
Table 2-23 shows possible causes of the fault in different scopes.

User terminal The modem, set-top box (STB), and TV cable are faulty.

Module
MDU On the MDU, check whether the multicast user is online and then
troubleshoot the fault according to the following symptoms:
l If the multicast user is offline or is blocked, troubleshoot the fault
by referring to 2.3.3.1 Failure to Go Online of a Multicast
User.
l If the multicast user goes online but blank screen occurs in the
multicast program, the fault is generally caused by incorrect
multicast configurations on the MDU. In this case, enable the MDU
debugging function and then locate the fault according to the
debugging information displayed on the MDU CLI. Possible
causes:
– The remaining multicast bandwidth of the user is lower than
the required bandwidth of the ordered program.
– The number of programs watched by the multicast user reaches
the upper limit so that the user cannot order a new program.
– The multicast user does not have the permission to watch the
program.
– The program ordered is not in the MVLAN to which the
– The multicast user does not have the permission to order certain
types of programs (such as HDTV).
– The number of programs at a level watched by the multicast
user reaches the upper limit so that the user cannot order a new
program at this level.
– The rate configured in the traffic profile bound to the traffic
stream is far lower than the bandwidth of the multicast program.
– There are too many prejoined static programs, occupying too
many bandwidths.
OLT l The program ordered is not in the MVLAN that is configured on

the OLT.
l The MDU multicast mode configured on the OLT mismatches the
actual multicast mode configured on the MDU.
l The maximum multicast bandwidth assigned to the PON port is
very low.
Upper-layer l The program is not configured on the multicast server.

network and devices l The time to live (TTL) value set for the multicast stream of the
(including the multicast server is very small.
multicast router and
multicast server) of l The network communication fails. The network communication
the OLT failure occurs on the line between the OLT and multicast router,
and between the multicast router and multicast server.

Module
CAUTION
Procedure
Step 1 Order a program again and perform the following steps to determine the location where program
traffic interruption occurs.
1. On the OLT, run the display multicast flow-statistic vlan 3 ip 224.1.1.1 command to
query the traffic statistics of the ordered program on the upstream port (assume that the
program traffic is not 0, the program traffic reaches the OLT upstream port.
2. On the MDU, run the display multicast flow-statistic vlan 3 ip 224.1.1.1 command to
program traffic is not 0, the program traffic reaches the MDU upstream port.
3. On the MDU, run the display statistics service-port command two or three times to query
the traffic statistics of the service port to which the multicast user belongs. If values of
Number of downstream packets different greatly, the program traffic reaches the MDU
user port.
NOTE
The following prerequisites must be met before you run the display statistics service-port command
to query the traffic statistics so as to prevent the queried results from being affected by other services.
l The multicast user is not watching other programs.
l The service port does no carry other heavy-traffic services. For example, the service of
downloading files from the Internet.
4. According to the preceding queried results, determine the fault scope by referring to Table
2-24 and perform operations accordingly.
NOTE
When multiple NEs need to be checked, generally locate the fault from lower-layer devices to upper-
layer devices, that is, in the sequence of user terminal -> MDU -> OLT -> multicast router -> multicast
server from segment to segment.
Table 2-24 Fault scope and troubleshooting method

User terminal If the following symptoms Check the user terminal

occur, the fault is because the following Step 2.
user terminal is faulty.
l Multicast streams reach the
user port of the MDU.
l Other users of the MDU can
watch the program.

Module
User terminal and Multicast streams reach the a. Check the user terminal
MDU upstream port of the MDU but following Step 2.
do not reach the user port of the b. Check the MDU following
MDU. Step 3.
User terminal, Multicast streams reach the a. Check the user terminal
MDU, and OLT upstream port of the OLT but do following Step 2.
not reach the upstream port of b. Check the MDU following
the MDU. Step 3.
c. Check the OLT following
Step 4.
User terminal, Multicast streams do not reach a. Check the user terminal
MDU, OLT, and the upstream port of the OLT. following Step 2.
upper-layer b. Check the MDU following
network and Step 3.
devices of the
OLT c. Check the OLT following
Step 4.
d. Check the upper-layer
network and devices of the
OLT following Step 5.

1. Verify that the TV cable is properly connected to the STB.
2. Check the indicator status of the STB. If the indicator of the STB Ethernet port connected
to the modem blinks quickly, the STB decoding may be incorrect. Reset the STB or use a
functional STB.
3. Check the indicator status of the modem. If the indicator of the modem Ethernet port
connected to the STB is abnormal, reset the STB or use a functional STB.
NOTE
For details about indicator status of the modem, see the related documents of the Modem.
l If the user cannot watch the program, go to Step 2.5.
5. Check whether all NEs are checked according to Table 2-24.
l If all NEs are checked, go to Step 6.
l If not all NEs are checked, check the remaining NEs according to Table 2-24.
Step 3 Check the MDU.

1. On the MDU, run the display igmp user user-index command to query the multicast user
status (State).
l If State is online, go to Step 3.2.
l If State is offline or block, perform operations by referring to 2.3.3.1 Failure to Go
Online of a Multicast User. Then, go to Step 7.

Module
2. Enable the MDU debugging function and collect information as follows:

a. Enable the function of multicast user monitoring on the MDU.
huawei(config)#debugging igmp
b. Order the program again. Then, go to Step 3.3.

NOTE
After the preceding steps are performed, run the following commands to disable the debugging
function.
3. Find the possible cause according to judgment criteria described in Table 2-25 and then

Module
Table 2-25 Incorrect multicast configurations of the MDU

e
Cause

maximu occurs, the fault is because the troubleshooting methods
m maximum multicast bandwidth of the according to the purchased service
multica user is lower than the required type:
st bandwidth of the ordered program. l Notify the user of ordering
bandwi l The MDU receives the report packet another program because the
dth of and displays "the user fails to pass remaining bandwidth is
the user bandwidth CAC". insufficient and the program
is lower cannot be ordered.
than the l On the MDU, run the display igmp
required user user-index command to query l Increase the user bandwidth
bandwi the maximum bandwidth (User and notify the user of ordering
dth of MaxBandWidth) and used the program again.
the bandwidth (Used bandwidth) of NOTE
ordered the user and run the display igmp l You can run the igmp user
progra program name command to query modify user-index max-
m. the bandwidth (Bandwidth) of the bandwidth command on the
ordered program. The remaining MDU to modify the maximum
bandwidth (the maximum bandwidth of the user.
bandwidth - the used bandwidth) is l When multicast bandwidth
lower than the bandwidth of the management is disabled
ordered program. (multicast CAC disabled), the
system does not guarantee the
NOTE bandwidth of the program ordered
If User MaxBandWidth is no-limit, the by the user.
multicast bandwidth of the user is not
limited. l The downstream rate of a line is
limited. Therefore, multicast
packets will be lost if the
bandwidth of the downstream
multicast streams is higher than
the maximum rate of the line.
Though multicast packets are lost,
the user can watch the program but
pixelation or delay occurs. Or
even blank screen occurs if a large
number of multicast packets are
lost.

Module

e
Cause

maximu occurs, the fault is because the available troubleshooting methods
m programs reach the preset maximum according to the purchased service
number value. type:
of l The MDU receives the report packet l Notify the user of closing some
progra and displays "the number of programs and then ordering the
ms program that the user is allowed to program again because the
(Availa watch has reached maximum". available programs reach the
ble preset maximum value and no
progra l The number of programs that users
are watching is equal to the more programs can be ordered.
ms) that
users available programs by running the l Increase the available programs
can display igmp user user-index and notify the user of ordering
watch at command on the MDU. the program again.
the NOTE NOTE
same If Available programs is no-limit, the user You can run the igmp user modify
can watch 32 programs concurrently. user-index max-program command
time
on the MDU to modify the available
reach programs.
the
preset
maximu
m value.

Module

e
Cause

does not watch the program. type:
have the l The MDU receives the report packet l If the user can watch all
permiss and displays "the user has no right". programs without
ion to authentication, perform the
watch l On the MDU, run the display igmp
user 100 command to query the following two operations:
the
right profile bound to the multicast a. On the MDU, run the igmp
user (assume that the service port of user modify 100 no-auth
the multicast user is 100). command in the BTV mode
– If Bind profiles is 0, the user is to modify the authentication
not bound to a right profile and mode of the user to "no
the user cannot order any authentication" (assume
programs. that the multicast user index
is 100).
– If Bind profiles is equal to or
larger than 1, the user can watch b. Order the program again.
only the program to which the l If the user can watch certain
user has the watch permission. In programs with authentication,
this case, perform operations for notify the user of ordering
further check. In the queried another program because the
result, find the index (assume user has no permission to watch
that the index is 1) and name of the program. The permission to
the program right profile bound watch the program is watch or
to the user and run the display preview.
igmp profile profile-index 1
command on the MDU to query
the user permission for ordering
the program.
program.
program is watch or
the program. Therefore, this
is not the cause for this fault.

Module

e
Cause
progra NOTE NOTE

configured with different permissions to a user bind-profile 100 profile-index-
same program, the permission with the list 1 command on the MDU to bind a
highest priority prevails. By default, the correct right profile to the multicast
priority of the program permissions is user (assume that the multicast user
forbidden > preview > watch > idle. You index is 100 and the right profile index
can run the igmp right-priority command is 1).
on the MDU to set the priority.

Module

e
Cause
progra fault is because the program ordered is troubleshooting methods
m not in the MVLAN to which the according to the purchased service
ordered multicast user belongs. type:
is not in l The MDU receives the report packet l Notify the user of ordering
the and displays "match program fail". another program because the
N to l The program ordered is not in the
MVLAN to which the multicast the program (the program is
which included in the MVLAN to
the user belongs by running the display
which the multicast user
multica belongs).
st user
program again.
config vlan command on
the MDU to query program
match mode of the
MVLAN to which the user
belongs.
mode is enable, the
program is a static
program, which is
manually added.
program, which is
upon the ordering.
MVLAN.
igmp program add
command on the MDU.
run the igmp match
group command on the
MDU to set the IP

Module

e
Cause
belongs igmp program vlan command on address range of

. the MDU. program groups that can
be generated
dynamically in the
MVLAN, and ensure

does not order certain types of programs. type:
have the l The MDU receives the report packet l Notify the user of ordering
permiss and displays "the number of the another program (the maximum
ion to grade program that the user is number of the programs at this
order allowed to watch has reached level must not be 0) because the
certain maximum". user does not have the
types of permission to watch the ordered
progra l The maximum number (watch
limit) of programs at a level that can program.
ms
(such as be watched by the user is 0 by l Set the permission for ordering
HDTV) running the display igmp user the programs at this level for the
. extended-attributes user-index user so that the user can order
command on the MDU. the program.
NOTE NOTE
If the maximum number of the programs at You can run the igmp user watch-
a certain level is 0, the user cannot order any limit command on the MDU to set the
programs at this level. That is, the user's number of programs at each level that
permission to the programs of the a user can watch.
corresponding type is restricted. For
example, if HDTV watch limit is 0, the
user cannot watch HDTV programs.

Module

e
Cause

number occurs, the fault is because the number troubleshooting methods
of of programs at a level watched by the according to the purchased service
progra multicast user reaches the upper limit. type:
ms at a l The MDU receives the report packet l Notify the user of ordering
level and displays "the number of the another program because the
watched grade program that the user is ordered program is not
by the allowed to watch has reached purchased.
multica maximum".
st user l Increase the maximum number
reaches l The number of programs that users of programs at a level watched
the are watching is equal to the by the multicast user and notify
upper maximum number (watch limit) of the user of ordering the
limit so programs at a level that can be program again.
that the watched by the user by running the NOTE
user display igmp user extended- You can run the igmp user watch-
cannot attributes user-index command on limit command on the MDU to set the
the MDU. number of programs at each level that
order a a user can watch.
new NOTE
progra If watch limit is no-limit, the maximum
number of the programs at this level that a
m at this
user can watch is not limited, but the total
level. number of programs that can be
concurrently watched is limited.

Module

e
Cause
The rate On the MDU, run the display service- Bind a traffic profile to multicast
configu port command to query the index of the streams and order the program
red in Rx traffic and then run the display again.
the traffic table ip command to query the l If a correct traffic profile is in
traffic PIR of the traffic profile. The PIR is far the system, run the service-
profile smaller than the bandwidth of the port 100 outbound traffic-
bound ordered program. table index 6 command on the
to the NOTE MDU to bind the traffic profile
traffic If the PIR is smaller than the bandwidth of (assume that the index of the
stream the ordered program, the multicast packets
multicast traffic streams is 100
is far are lost and pixelation occurs. If the PIR is
very small, the blank screen may occur and the index of the traffic
lower profile is 6) to the multicast
because a large number of multicast packets
than the are lost. streams again.
bandwi
If the service port carrying the multicast l If the currently configured
dth of streams carries streams of other services,
the traffic profile does not meet the
ensure that the total traffic of all services is
multica requirement, run the traffic
smaller than or equal to the PIR. Otherwise,
st other services may occupy the majority of table ip command on the MDU
progra traffic streams, which leads to insufficient to add a new profile that meets
m. multicast bandwidth. As a result, the the requirement and then bind
pixelation occurs. the profile to the traffic streams.
The common programs and high definition
provider.
be used.
l An HD program has heavy traffic. For
example, the rate of an HD program is
higher than 12 Mbit/s. In this case, a
profile can be used.

Module

e
Cause
There The prejoined static programs occupy On the MDU, run the igmp
are too too many bandwidths, which is close to program modify command to
many the maximum downstream bandwidth modify Prejoin to disable and then
prejoine of multicast programs provided by the order the program again.
d static PON port.
progra l You can obtain the bandwidth of
ms, prejoined static programs following
occupyi the steps below:
ng too
many a. On the MDU, run the display
igmp program all command to
query the prejoin attribute
(Prejoin) of the program.
b. Calculate the bandwidth of
prejoined static programs
(Prejoin is enable) according to
the data plan. For example, if
100 programs are enabled with
the prejoin function and the
bandwidth of each program is 5
Mbit/s, the total bandwidth of
the prejoined static programs is
500 Mbit/s.
l You can obtain the maximum
downstream bandwidth of multicast
programs provided by the PON port
following the steps below:
a. On the OLT, run the display
igmp config global command to
query the bandwidth
management function
(Bandwidth management
switch).
b. On the OLT, run the display
igmp bandwidth port
bandwidth (Max bandwidth)
assigned to the PON port.
switch is disable, the OLT does
not perform the multicast
bandwidth management. The
maximum bandwidth is the
maximum downstream
the PON line.

Module

e
Cause
bandwi – If Bandwidth management NOTE

dths. switch is enable and Max You can modify the attributes of all
multicast programs in any MVLAN.
bandwidth is no-limit, the OLT
When a program is being watched or
performs the multicast previewed by a user, however, its
bandwidth management but the attributes cannot be modified.
OLT PON port does not limit the
The maximum bandwidth is the
maximum downstream
the PON line.
bandwidth has a specific value,
the OLT PON port limits the
The maximum bandwidth is the
bandwidth (Max bandwidth)
assigned to the PON port.


Module
Table 2-26 Incorrect multicast configurations of the OLT

e
Cause
The On the OLT, run the display igmp Choose one of the following
progra program vlan command to check troubleshooting methods
m whether the program ordered by the according to the purchased service
ordered type:
is not in l Notify the user of ordering
the another program because the
N that is the program (the program is
configu included in the MVLAN to
red on which the multicast user
belongs).
program again.
config vlan command on
the OLT to query program
match mode of the
MVLAN to which the user
belongs.
mode is enable, the
program is a static
program, which is
manually added.
program, which is
upon the ordering.
MVLAN.
igmp program add
command on the OLT.
run the igmp match
group command on the

Module

e
Cause
the multicast user is included in the OLT to set the IP address

OLT. MVLAN. range of program groups
that can be generated
dynamically in the
MVLAN, and ensure
The If the following symptoms occur, the On the OLT, run the igmp
maximu fault is because the maximum multicast bandwidth port command to
m bandwidth assigned to the PON port is modify the maximum bandwidth
multica very low. provided by the PON port to
st l On the OLT, run the display igmp multicast programs to meet the
bandwi config global command to verify total bandwidth requirement of
dth that the bandwidth management MDU multicast users. Order the
assigne function (Bandwidth management program again.
d to the switch) is enable.
PON
port is l On the OLT, run the display igmp
very bandwidth port command to query
low. the bandwidth (Max bandwidth)
assigned to the PON port and the
used bandwidth (Used bandwidth).
The remaining bandwidth (the
maximum bandwidth - the used
bandwidth) is lower than the
bandwidth of the ordered program.
l The bandwidth assigned to the PON
port is very small, which does not
meet the total bandwidth
requirement of MDU multicast
users.

Module

e
Cause
The If the following two queried results are Modify the MDU multicast mode
MDU different, the fault is because the MDU configured on the OLT to match
multica multicast mode configured on the OLT the actual multicast mode
st mode mismatches the actual multicast mode configured on the MDU.
configu configured on the MDU. NOTE
red on l On the OLT, run the display ont In the GPON access mode, run the
the OLT info command to query the multicast mode command on the
mismat OLT to modify the MDU multicast
multicast mode of the ONT. That is, mode.
ches the the MDU multicast mode
actual configured on the OLT.
multica
st mode l On the MDU, run the display igmp
configu config vlan command to query the
red on actual IGMP mode of the MDU.
the
MDU.

Table 2-27 Faulty upper-layer network and devices of the OLT

e
Cause
The The program is not configured on the Add the program to the multicast
progra multicast server. server.
m is not TIP
configu If the user can watch the program, this is not
red on the cause.
the
multica
st
server.

Module

e
Cause
The All users of the OLT or the MDU fail Increase the TTL value of multicast
time to to watch all programs configured on to packets of the multicast server.
live the multicast server.
(TTL) NOTE
value If the TTL value of multicast packets on the
set for upstream port of the OLT is smaller than 2,
the the OLT drops multicast packets.
multica
st
stream
of the
multica
st server
is very
small.
The Ping the multicast router and multicast Troubleshoot the fault on the line
upper- server from the OLT separately. It is between the OLT and the multicast
layer found that the OLT fails to ping the router or the fault on the line
network multicast router and the multicast between the OLT and the multicast
commu server. server.
nication TIP
fails. the multicast server is normal.
2. Order a program again and then check whether the user can watch the program successfully.
----End
Related Topics
2.3.3.3 Pixelation in a Multicast Program

Pixelation in multicast programs is a fault that a user is online and orders a program but the
quality of the program is poor, such as pixelation. When pixelation occurs in an FTTB or FTTC

Module
Location Method
When pixelation occurs in an FTTB or FTTC network, the fault scope can be determined by
detecting the location where program traffic interruption occurs, as shown in Figure 2-9.
Figure 2-9 Locating the pixelation fault

LAN access
Detection point 1:
MDU Upstream port of the MDU
TV STB
Detection point 2:
Upstream port of the OLT
STB OLT Multicast server
Optical splitter
TV
DSL Multicast router Multicast router

access
MDU
Modem
TV STB
STB
TV
Scope: user terminal to the MDU Scope: MDU to the OLT Scope: upper-layer network and devices of the
Symptom: Packet loss does not occur Symptom: Packet loss does not OLT
on the upstream port of the MDU. occur on the upstream port of the Symptom: Packet loss occurs on the upstream
MDU but packet loss occurs on port of the OLT.
the upstream port of the MDU.
Table 2-28 shows possible causes of the fault in different scopes.

User terminal to the l The activation rate of the xDSL port is excessively low. This cause
MDU is excluded when the MDU is connected to the user using a LAN.
l The rate configured in the traffic profile bound to the traffic stream
is lower than the bandwidth of the multicast program.
l The QoS rate limitation on the port is excessively low.
l If pixelation occurs only in program switching, the maximum
bandwidth used by the user may be higher than the downstream
line rate and the fast leave function may not be enabled.
l The data processing capability of the modem is poor. This cause
is excluded when the MDU is connected to the user using a LAN.
l The TV set is faulty.
MDU to the OLT Packet loss occurs on the line between the MDU and the OLT.

Module
Upper-layer l The multicast source is abnormal.

network and devices l The network quality is poor. The network communication failure
of the OLT occurs on the line between the OLT and multicast router, and
between the multicast router and multicast server.
CAUTION
Procedure
Step 1 Order a program again and perform the following steps to determine the location at which
multicast packets are lost.
1. On the OLT, run the display multicast flow-statistic vlan 3 ip 224.1.1.1 command to
l If the queried result is close to the rate of the program traffic, the program traffic reaches
the OLT upstream port. Then, go to Step 1.2.
l If the queried result is far lower than the rate of the program traffic, the program traffic
loses packets before reaching the OLT upstream port. Then, go to Step 2.
2. On the MDU, run the display multicast flow-statistic ip 224.1.1.1 vlan 3 command to
l If the queried result is close to the rate of the program traffic, the program traffic reaches
the MDU upstream port. It is assumed that packets loss occurs on the MDU, user
terminal, or on the line between the MDU and the user terminal. Then, go to Step 4.
l If the queried result is far lower than the rate of the program traffic, the program traffic
loses packets before reaching the MDU upstream port. It is assumed that the program
traffic loses packets on the line between the OLT and the MDU. Then, go to Step 3.

Module

e
Cause
The Pixelation occurs when a user watches Replace the multicast source.
multica a program ordered from the multicast
st server.
source TIP
is If other users can watch the program
abnorm successfully, the multicast source is
al. normal.
layer found that packet loss occurs. router or the fault on the line
network TIP between the OLT and the multicast
quality If other users of the OLT can watch the server.
of the program, the network between the OLT and
OLT is the multicast server is normal.
poor.
2. Order the program to check whether the user can watch the program successfully.
3. Check whether packets are lost on the upstream port of the OLT.
l If the packets are lost on the upstream port of the OLT, go to Step 6.
l If no packet is lost on the upstream port of the OLT, the fault on the line between the
OLT and the multicast server is rectified. Then, troubleshoot the fault in other fault
scopes according to the location where packet loss occurs and go to Step 1.
Step 3 Check the line between the OLT and the MDU.
1. On the OLT, run the display alarm history all command to query historical alarms and
run the display event history all command to query historical events to check whether
alarms or events related to the PON line (line between the OLT and the MDU) are generated
on the OLT.
l If such alarms or events are generated, clear them by referring to the relevant instruction
documents. Then, go to Step 3.2.
l If no such alarms or events are generated, go to Step 4.
l If the user cannot watch the program, go to Step 4.

Module
Table 2-30 Incorrect configurations of the MDU

e
Cause
activati fault is because the activation rate of the troubleshooting methods
on rate xDSL port is excessively low. according to the specific symptom
of the l An MDU is connected to a user of the fault:
xDSL using xDSL. l If a multicast program is normal
port is but then has pixelation
excessi l The actual downstream line rate is
lower than the bandwidth of the occasionally, the line quality is
vely poor or interference sources
low. ordered program.
exist. Connect the modem to the
NOTE
CO equipment, to the MDF,
l If the xDSL port carries other services and to the MDU, and perform
(such as the Internet access service), the
tests accordingly to locate the
traffic of all services must be lower than
or equal to the actual downstream line fault (including the
rate. Otherwise, other services may electromagnetic interference
occupy the majority of traffic streams, that may exist on the line) on the
which leads to insufficient multicast line section by section.
bandwidth. As a result, the pixelation
occurs. l If a multicast program always
has pixelation, configurations
l For an ADSL2+ user, in the ADSL
mode, run the display line operation are incorrect. You must bind a
command on the MDU to query the new line profile to the port
actual downstream line rate (Actual according to Changing the
line rate downstream) of the modem. Line Profile (Template) of an
l For a VDSL2+ user, in the VDSL xDSL Port to improve the line
mode, run the display line operation rate.
command on the MDU to query the
actual downstream line rate (Actual
line rate downstream) of the modem.

Module

e
Cause
The rate On the MDU, run the display service- Bind a new traffic profile to
configu port command to query the index of the multicast streams.
red in Rx traffic and then run the display l If a correct traffic profile is in
the traffic table ip command to query the the system, run the service-
traffic PIR of the traffic profile. The PIR is port 100 outbound traffic-
profile smaller than the bandwidth of the table index 6 command on the
bound ordered program. MDU to bind the traffic profile
to the NOTE (assume that the index of the
traffic If the PIR is smaller than the bandwidth of multicast traffic streams is 100
stream the ordered program, the multicast packets
and the index of the traffic
is lower are lost and pixelation occurs. If the PIR is
very small, the blank screen may occur profile is 6) to the multicast
than the streams again.
because a large number of multicast packets
bandwi are lost.
dth of l If the currently configured
If the service port carrying the multicast traffic profile does not meet the
the streams carries streams of other services,
multica requirement, run the traffic
ensure that the total traffic of all services is
st table ip command on the MDU
smaller than or equal to the PIR. Otherwise,
progra other services may occupy the majority of to add a new profile that meets
m. traffic streams, which leads to insufficient the requirement and then bind
multicast bandwidth. As a result, the the profile to the traffic streams.
pixelation occurs.
The common programs and high definition
provider.
be used.
l An HD program has heavy traffic. For
example, the rate of an HD program is
higher than 12 Mbit/s. In this case, a
profile can be used.

Module

e
Cause
The On the MDU, run the display qos-info On the MDU, run the traffic-
QoS traffic-limit port command to query limit command to change the target
rate the target rate of the port and then rate to an appropriate value or run
limitati compare the target rate with the the undo traffic-limit command
on on bandwidth of the ordered program. The on the MDU to cancel the traffic
the port target rate is lower than the bandwidth limitation on the port.
is of the ordered program.
excessi NOTE
vely If the user port carries other services (such
low. as the Internet access service), the traffic of
all services must be lower than or equal to
the target rate. Otherwise, other services
may occupy the majority of traffic streams,
which leads to insufficient multicast
bandwidth. As a result, the pixelation
occurs.

Module

e
Cause
The If one of the following symptoms On the MDU, run the igmp user
maximu occurs, the fault is because the modify user-index max-
m maximum bandwidth of the user is bandwidth command to modify
bandwi higher than the downstream line rate the maximum bandwidth of the
dth of and the fast leave function is not user to be lower than the line rate.
the user enabled.
is l Pixelation occurs only when
higher programs are switched.
than the
downstr l Run the display igmp user user-
eam line index command to query the fast
rate and leave attribute (Quick leave) and
the fast the maximum bandwidth of the
leave program (User MaxBandWidth).
function The Quick leave is disable and the
is not maximum bandwidth is higher than
enabled the downstream line rate.
. NOTE
l When a user switches between channels
using a remote controller, two IGMP
packets are transmitted at the same
time, including one leave packet and
one join packet. Before the previous
program stops, traffic of two programs
exists over the subscriber line. If no
sufficient bandwidth is available for the
traffic of two programs over the line,
packet loss occurs due to traffic
overflow. As a result, pixelation occurs.
l When a user switches between channels
frequently, traffic of multiple multicast
groups exists over the line.
l After the maximum bandwidth of a user
is limited, the user cannot order a new
program if the bandwidth of the new
ordered program is larger than the value
(the maximum bandwidth - the used
bandwidth). This ensures that the
program that is being watched is not
affected.

Module
Table 2-31 Faulty user terminal

e
Cause
The If the following symptoms occur, the Replace the modem with another
data fault is because the data processing modem with higher processing
processi capability of the modem is poor. capability. In this way, the
ng l The available bandwidth is higher processing capability of the
capabili than the bandwidth of the order modem meets the requirements of
ty of the program. user service bandwidth.
modem
is poor. l Pixelation occurs on programs
(such as HD program) requiring
higher bandwidths but programs
requiring lower bandwidths are
normal.
NOTE
When there is a great volume of traffic, the
rate for forwarding packets is beyond the
processing capability of the modem, which
leads to packet loss.
The The fault is rectified after the STB is Reset or replace the STB.
STB is reset or replaced.
faulty.
The TV Pixelation persists after the TV cable is Contact the TV set maintenance
set is connected to another video input device engineer to troubleshoot the TV set
faulty. such as a DVD player or VCR player. fault.
----End
Related Topics
2.3.3.4 Abnormal Interruption of a Multicast Program

Abnormal interruption of a multicast program is a fault that a multicast user is watching a
program but the program is abnormally interrupted. When abnormal interruption of a multicast
program occurs in an FTTB or FTTC network, locate the fault according to the following
procedure.

Module
Location Method
When abnormal interruption of a multicast program occurs in an FTTB or FTTC network,
generally locate the fault from upper-layer devices to lower-layer devices, that is, in the sequence
of multicast server -> OLT -> MDU -> user terminal from segment to segment. Table 2-32
shows possible causes of the fault in different scopes.

Scope
Upper- All users on the network encounter The multicast source is abnormal.
layer the fault.
network
and All users of the OLT encounter the The network communication of the link
devices of fault. between the OLT and multicast router,
the OLT or between the multicast router and
multicast server fails
OLT If one of the following symptoms Configurations of the multicast

occurs, the OLT is faulty. cascading port on the OLT do not match
l Multiple users of the MDU configurations of the multicast mode on
encounter the fault at the same the MDU.
time.
l The program is interrupted
frequently but can be watched
after being ordered again.
MDU If all the following symptoms occur, The line between the MDU and the user
the MDU is faulty. terminal is faulty.
l Only one user encounters the
fault.
interrupted.
l The Internet access service and
voice service of the same user
terminal are abnormal.
If all the following symptoms occur, The watching duration of the user
the MDU is faulty. reaches the preview duration.
fault.
l Other programs can be watched
when a program is interrupted.

Module

Scope
User If all the following symptoms occur, The modem or set-top box (STB) is
terminal the user terminal is faulty. faulty.
fault.
interrupted.
CAUTION
Procedure

e
Cause
The A multicast program is abnormally Replace the multicast source.

multica interrupted when a user is watching a
st program ordered from the multicast
source server.
is TIP
abnorm If other users can watch the program
al. successfully, the multicast source is
normal.
layer found that the OLT fails to ping the router or the fault on the line
network multicast router and the multicast between the OLT and the multicast
commu server. server.
nication TIP
fails. the multicast server is normal.

Module

Step 2 Check whether configurations of the multicast cascading port on the OLT match configurations
of the multicast mode on the MDU.
1. On the OLT, run the display igmp cascade-port frameid/slotid/portid command to check
whether the fast leave function is enabled on the port to which the user terminal is connected.
l If quick leave is disable or the message "The cascade port does not exist" is displayed,
go to Step 3.
l If quick leave is enable, go to Step 2.2.
NOTE
l If the fast leave function of the cascading port is enabled, the program is disabled immediately
after the cascading port receives the leave packet.
l If the fast leave function of the cascading port is disabled, after the cascading port receives the
leave packet, the system sends a group-specific query and waits a certain period of time. If no
response is received from the user during the waiting period, the system drives the user offline.
This allows the fast leave function to help reduce the exchange of IGMP packets, therefore
reducing the usage of bandwidth resources.
l Note that if the lower-layer device does not support the proxy of the IGMP leave packet, all the
users watching the program may go offline when a user watching the same program goes offline.
Therefore, when the fast leave function is enabled on the multicast cascading port, it is
recommended that you enable IGMP proxy on the lower-layer device, or enable IGMP snooping
and the proxy function of the IGMP leave packet.
2. On the MDU, run the display igmp config vlan command to query the IGMP mode and
the leave proxy switch.
l If the IGMP mode is IGMP proxy, go to Step 3.
l If the IGMP mode is IGMP snooping and the leave proxy switch is enabled, go to Step
3.
l If the IGMP mode is IGMP snooping and the leave proxy switch is disabled, go to Step
2.3.
3. Modify the OLT or MDU configuration according to the network plan.
l On the OLT, run the igmp cascade-port modify frameid/slotid/portid quickleave
disable command to disable the fast leave function of the multicast cascading port.
Then, go to Step 2.4.
l On the MDU, run the igmp leave-proxy enable command in the MVLAN mode to
enable the proxy function of the IGMP leave packet or run the igmp mode proxy
command to change the MVLAN to work in the IGMP proxy mode. Then, go to Step
2.4.
1. On the MDU, run the display board frameid/slotid command to query the status of the
faulty port.
l If the port is in the activated state, go to Step 3.4.
l If the port is in the deactivated state, go to Step 3.2.
2. On the MDU, query the historical alarms, historical events, and operation logs of the system
and find out the cause of port deactivation.

Module
a. Run the display alarm history all command to query the historical alarms of the
system.
b. Run the display event history all command to query the historical events of the
system.
c. Run the display log command to query the operation logs.
l If you find any ring network alarm or event in the query, the ring network generated on
the user side leads to deactivation of the faulty user port. Eliminate the ring network,
and activate the user port. Then, go to Step 3.3.
l If you find any deactivation alarm and event, or the operation log of manually
deactivating the port in the query, find out the deactivation cause based on the prompt
of the alarm and event and ensure that the user port is in the activated state. Then, go to
Step 3.3.
4. On the MDU, run the display igmp user user-index command to query the right profile
bound to the multicast user. On the MDU, run the display igmp profile profile-index 1
command in the BTV mode to query the information about the right profile bound to the
user (assuming that the right profile is profile 1).
l If the right of the user is watch, the user has permission to watch the program. Then,
go to Step 4.
l If the right of the user is preview, the user has permission to preview the program. If
the preview duration of a user reaches the maximum preview duration, the system stops
the program and notifies the user of a normal interruption. Then, go to Step 6.
NOTE
There are four program permissions: forbidden, preview, watch and idle. When a user is bound to
multiple right profiles that are configured with different permissions to a same program, the
permission with the highest priority prevails. By default, the priority of the program permissions is
forbidden > preview > watch > idle. You can run the igmp right-priority command to set the priority.

1. Check the indicator status of the STB. If the indicator of the STB Ethernet port connected
to the modem blinks quickly, the STB decoding may be incorrect. Reset the STB or use a
functional STB.
2. Check the indicator status of the modem. If the indicator of the modem Ethernet port
connected to the STB is abnormal, reset the STB or use a functional STB.
NOTE
For details about indicator status of the modem, see the related documents of the Modem.
----End

Module
Related Topics
7.3.3 Abnormal Program Interruption in Watching a Multicast Program
2.3.3.5 Long Time in Switching Programs

Long program switching time is a fault that a very long time is required in switching the current
program to a new one; however, the programs can be switched and the new program can be
watched. When such a fault occurs in an FTTB or FTTC network, locate and troubleshoot the
fault by using the following location methods and troubleshooting procedure.
Location Method
When the fault occurs in an FTTB or FTTC network, check whether the fast leave attribute is
correctly configured on the MDU.
CAUTION
Procedure
Step 1 Run the display igmp user user-index command to query the fast leave attribute (quick
leave) of the user who encounters the fault, and check whether the fast leave attribute is correctly
configured. The fast leave attribute can be configured by referring to Table 2-34 according to
user network's configurations.
l If the fast leave attribute is correctly configured, go to Step 3.
l If the fast leave attribute is incorrectly configured, run the igmp user modify user-index
quickleave command to modify the fast leave attribute of the user. Then, go to Step 2.
NOTE
The following table lists the recommended configurations for different home users.
Table 2-34 Configuring the fast leave attribute of a multicast user
IGMP STB Reserve Normal Quick MAC-Based Quick

Configurati Quantity d Leave Leave Leave
on Used on Bandwi
the STB dth

disabled nt


to eight STBs)

Module
IGMP STB Reserve Normal Quick MAC-Based Quick

Configurati Quantity d Leave Leave Leave
on Used on Bandwi
the STB dth

snooping nt


to eight STBs)
IGMP proxy One Insufficie √ √

nt
More than Insufficie √ √ (Not limited)

one nt
Sufficient √ √ √ (Not limited)
NOTE
l In Table 2-34, √ indicates that the corresponding fast leave attribute can be selected.
l For details about principles and data processing of the fast leave attribute, see Feature Description >
Multicast > Advanced Multicast Technologies > User-Side Interoperating Technologies.
Step 2 Order the program again to check whether the time of switching a program is of a proper length.
l If the time of switching a program is of a proper length, go to Step 4.
l If the time of switching a program is still too long, go to Step 3.
----End
2.3.4 Troubleshooting the Voice Service

This topic describes how to troubleshoot common faults in the voice service, including the
following faults: no tone after offhook, busy tone after offhook, one-way audio in
communication, noise in communication, poor voice service in communication, and failure to
dial certain phone numbers.
Prerequisites
l The ONU and the OLT must communicate with each other normally. If a fault occurs in

Module
In this case, according to fault symptom, troubleshoot the fault by referring to the methods
described in other topics.
NOTE
l Different ONUs support different functions and commands. In troubleshooting the voice
service, consider the MA562x as an example.
Context
In an FTTx network, voice subscribers access the ONU, and the ONU works together with the
upper-layer softswitch or an IMS network to achieve the VoIP service. After being encapsulated
by the ONU, voice packets are forwarded to the NGN network through the OLT. The following
figure shows a network of the FTTx voice service.
2.3.4.1 No Power Feed After Offhook

This section describes how to troubleshoot the fault where there is no power feed when a phone
goes offhook. When this fault occurs, the phone does not respond after going offhook, and the
"phone in use" indicator is off, which means that the phone has no power feed.

Module
Fault Location
Start
Identify the fault

scope.
The fault occurs on some The fault occurs on all The fault occurs on all ports
ports. ports on some boards. on the MDU.
Check whether the phone is

functional.
Check whether the loop and

circuit lines are functional.
Check whether the Check whether the power

Check whether the user
service boards are board on the MDU is
ports are functional.
functional. functional
End
CAUTION
Procedure
Step 1 Identify the fault scope.
l If the fault occurs on some ports, go to Step 2.
l If the fault occurs on all ports on some boards, go to Step 7.
l If the fault occurs on all ports on the multi-dwelling unit (MDU), go to Step 8.
Step 2 Replace the phone with a functional one and check whether the fault is rectified.
Step 3 Run the pots circuit-test command on the MDU to perform a circuit line test on the affected
port. Check whether Feeder voltage is Normal.
l If Feeder voltage is Normal, go to Step 4.
l If Feeder voltage is not Normal, go to Step 6.

Module
Step 4 Run the pots loop-line-test command on the MDU to perform a loop line test on the affected
port. Check whether Conclusion is Normal.
l If Conclusion is Normal, go to Step 10.
l If Conclusion is not Normal, rectify the fault according to the displayed test conclusion.
Then, go to Step 5.
NOTE
For example, if Conclusion is Phone not connected, the phone is faulty or the line between the phone
and the MDU is not connected properly. In this case, replace the phone or ensure that the line is connected
properly.
Step 5 Check whether the fault is rectified.

Step 6 Connect the phone to another port on the same board, and check whether the fault is rectified.
l If the fault is rectified, the original user port is faulty. Go to Step 11.
Step 7 Replace the voice service board on the MDU and check whether the fault is rectified.
Step 8 Check whether the power board on the MDU is working properly.
l If the power board is working properly, go to Step 10.
l If the power board is faulty, go to Step 9.
Step 9 Replace the power board on the MDU and check whether the fault is rectified.
----End
2.3.4.2 No Tone After Offhook

This section describes how to troubleshoot the fault where there is no dial tone or only a weak
current sound when a phone goes offhook.
Fault Location

Module
Start
Identify the fault

scope.
The fault occurs on some The fault occurs on all The fault occurs on all ports
ports. ports on some boards. on the MDU.
Check whether the phone is

functional.
Check whether the loop and

circuit lines are functional.
Check whether the

Check whether the user Check whether the voice file
service boards are
ports are functional. is loaded to the MDU.
functional.
Check whether the DSP

daughter board are properly.
Check whether the MDU

configurations are correct.
Check whether the softswitch

End
CAUTION
Procedure
Step 1 Identify the fault scope.
l If the fault occurs on some ports, go to Step 2.
l If the fault occurs on all ports on some boards, go to Step 7.
l If the fault occurs on all ports on the multi-dwelling unit (MDU), go to Step 8.
Step 2 Replace the phone with a functional one and check whether the fault is rectified.

Module
Step 3 Run the pots loop-line-test command on the MDU to perform a loop line test on the affected
plain old telephone service (POTS) port. Check whether Conclusion is Normal.
l If Conclusion is Normal, go to Step 5.
l If Conclusion is not Normal, rectify the fault based on the displayed test conclusion. Then,
go to Step 4.
NOTE
For example, if Conclusion is Phone not connected, the phone is faulty or the line between the phone
and the MDU is not connected properly. In this case, replace the phone or ensure that the line is connected
properly.

Step 5 Run the pots circuit-test command on the MDU to perform a circuit line test on the affected
port.
l If the results of all test items are Normal, the user port is functional. Go to Step 8.
l If the results of only some test items are Normal, the user port is faulty. Go to Step 6.
Step 6 Connect the phone to another port on the same board, and check whether the fault is rectified.
l If the fault is rectified, the original user port is faulty. Go to Step 19.
Step 7 Replace the voice service board on the MDU and check whether the fault is rectified.
Step 8 Check whether a voice file is loaded to the MDU.

l If a voice file is loaded to the MDU, go to Step 10.
l If a voice file is not loaded to the MDU, run the load voip command on the MDU to load
a voice file to the device. Then, go to Step 9.
Step 9 Take the phone off the hook to check whether the fault is rectified.
Step 10 Run the display boardframeid/slotid command to check whether the state of the DSP daughter
board is Normal.
l If the state is Normal, go to Step 12
l If the state is not Normal, go to Step 11
Step 11 Ensure the DSP daughter board work in the normal state to check whether the dial tone is played.
l If the dial tone is played, go to Step 19.
l If the dial tone is not played, go to Step 12.
Step 12 Run the display pstn state command on the MDU to check whether CTPAdmState of the
affected POTS port is StartSvc.
l If CTPAdmState is StartSvc, go to Step 14.
l If CTPAdmState is not StartSvc, go to Step 13.

Module
Step 13 Run the undo endservice command on the MDU to reactivate the service on the port, and check
Step 14 Ensure that the media gateway (MG) interface is functional. Then, check whether the fault is
rectified.
NOTE
Check whether the following conditions are met:
l The MG interface configuration on the MDU is the same as that on the interconnected media gateway
controller (MGC).
l The MDU communicates with the MGC properly.
Step 15 Check whether the data configuration on the MDU conforms to the data plan.
l If the data configuration conforms to the data plan, go to Step 17.
l If the data configuration does not conform to the data plan, go to Step 16.
Step 16 Take the phone off the hook to check whether the fault is rectified.
Step 17 Have a softswitch engineer check whether the softswitch data configuration conforms to the data
plan. If any inconsistency is found, make necessary modifications to ensure data consistency.
Then, check whether the fault is rectified.
----End
Related Topics
2.3.4.3 Busy Tone After Offhook

Busy tone after offhook indicates that when a subscriber picks the phone off the hook, only a
busy tone is heard. When the fault of busy tone after offhook occurs in FTTB and FTTC network,
locate the fault according to the following procedure.
Location Method
When the fault of busy tone after offhook occurs in FTTB and FTTC network, locate the fault
according to the following procedure:

Module
Start
Confirm the voice protocol type
H.248 protocol SIP protocol
Check MG interface attributes Check SIP interface attributes
Check the data of MGC

subscribers
Check the RTP format of the MG
Check whether the subscriber

line is normal
End
CAUTION
Procedure
Step 1 On the ONU, run the display alarm history all command to query the historical alarms and
then run the display event history all command to query the historical events. Check whether
the alarms or events related to the fault are generated.
l If such alarms or events are generated, clear these alarms or events to rectify the fault
according to the relevant guide. Then, proceed to Step 2.
l If such alarms or events are not generated, go to Step 3.

Module
NOTE
The related alarms or events include the following:

l DSP resources insufficient
l Port remote blocking
l H.248 interface interruption
l Communication between the VAG and the SIP proxy server is interrupted
Step 2 Pick the phone off the hook again and check whether a dial tone is heard.
l If a dial tone is heard, go to Step 16.
l If no dial tone is heard, proceed to Step 3.
Step 3 On the ONU, run the display protocol support command to query the current used voice
protocol.
l If the H.248 protocol is used, proceed to Step 4.
l If the SIP protocol is used, go to Step 13.
Step 4 In the H.248 mode of the ONU, run the reset coldstart command to reset the MG interface and
make the subscriber register again. If registration is successful, run the display pstn state
command in the global config mode of the ONU to check whether the service management state
(CTPAdmState) of the POTS port is StartSvc.
CAUTION
In resetting the MG interface, subscriber services carried on this interface will be interrupted.
Therefore, before resetting the MG interface, ensure that no users under this interface are running
services.

l If CTPAdmState is not StartSvc, proceed to Step 5.
Step 5 In the H.248 mode of the ONU, run the display if-h248 attribute mgid command to check
whether MG interface attributes are the same as those configured on the MGC.
l If MG interface attributes are the same as those configured on the MGC, go to Step 7.
l If MG interface attributes are different from those configured on the MGC, run the if-h248
attribute command in the H.248 mode of the ONU to modify MG interface attributes to
be the same as those configured on the MGC. Run the reset coldstart command to reset
the MG interface. Then, proceed to Step 6.
Step 7 In test mode, run the pots loop-line-test command to perform the POTS subscriber loop line
test with the phone on the hook.
l If the test result (shown in Conclusion) is Normal, the subscriber line and the phone are
normal. Then, go to Step 9.
l If the test result (shown in Conclusion) is not Normal, rectify the fault based on the test
result. Then, go to Step 8.

Module
NOTE
If the test result shown in Conclusion is Phone not connected, the phone is faulty or the line between the
phone and the MDU is not properly connected. In this case, replace the phone or check whether the line
is connected properly.
Step 9 On the MGC, query subscriber data and check whether data of the subscriber who encounters
the fault is configured on the MGC.
l If data of the subscriber who encounters the fault is configured on the MGC, go to Step
11.
l If data of the subscriber who encounters the fault is not configured on the MGC, configure
such data on the MGC. Then, proceed to Step 10.
Step 11 On the MGC, trace H.248 signaling, and check whether error 502 is contained in H.248 signaling.
l If error 502 is contained in H.248 signaling, run the tid-template modify command on the
ONU to modify the terminal ID format of the MG to be the same as that of the MGC. In
the H.248 mode of the ONU, run the reset coldstart command to reset the MG interface
and make the subscriber register again. Then, go to Step 14.
l If error 502 is not contained in H.248 signaling, go to Step 15.
NOTE
In the protocol, error 502 is defined as invalid termination point, including RTP termination point and
physical termination point. On the MGC, if the traced H.248 signaling contains error 502, it indicates that
the terminal ID format of the MG is different from that of the MGC. For example, RTP configured on the
MGC is in a progressively increase format of RTP1000, RTP1001 and RTP1002; however, RTP configured
on the MG is in a progressively increase format of RTP500, RTP501 and RTP502.
Step 12 In the SIP mode of the ONU, run the reset command to reset the SIP interface and make the
subscriber register again. If registration is successful, run the display pstn state command in
the global config mode of the ONU to check whether the service management state
(CTPAdmState) of the POTS port is StartSvc.
CAUTION
In resetting the MG interface, subscriber services carried on this interface will be interrupted.
Therefore, before resetting the MG interface, ensure that no users under this interface are running
services.

l If CTPAdmState is not StartSvc, proceed to Step 13.
Step 13 In the SIP mode of the ONU, run the display if-sip attribute mgid command to check whether
SIP interface attributes are the same as those configured on the IMS.

Module
l If SIP interface attributes are the same as those configured on the IMS, go to Step 15.
l If SIP interface attributes are different from those configured on the IMS, run the if-sip
attribute basic command in the SIP mode of the ONU to modify SIP interface attributes
to be the same as those configured on the IMS. Run the reset command to reset the SIP
interface. Then, proceed to Step 14.
----End
Related Topics
2.3.4.4 One-Way Audio in Communication

One-way audio indicates that a subscriber can dial the phone number and hear the ringing tone,
but only the tone of one party can be heard in communication. When the fault of one-way audio
in communication occurs in FTTB and FTTC network, locate the fault according to the following
procedure.
Location Method
When the fault of one-way audio occurs in FTTB and FTTC network, locate the fault according
1. Check configurations of the MG route.

2. Check configurations of ACL rules of the ONU, OLT, and bearer network.
NOTE
l Dialing a phone number and hearing the ringing tone are normal on the device, and it can be determined
that the signaling streams are normal. In this case, one-way audio maybe because the route of the device is
incorrect or the route of the bearer network is incorrect.
l If a fault occurs on the bearer network, locate the fault by making phone calls within two parties of the same
OLT. If two parties can call each other, it indicates that media streams are forwarded inside the device instead
of the bearer network. In this case, you can determine that the fault occurs on the link between the device
and the bearer network.
CAUTION

Module
Procedure
Step 1 Check whether the ONU and the trunking gateway (TG) can ping each other.
l If the ONU cannot ping the IP address of the TG but the TG can ping the IP address of the
ONU, proceed to Step 2.
l If the ONU and the TG can ping each other, go to Step 4.
Step 2 On the ONU, run the display ip routing-table command to query configurations of IP routes.
Check whether the destination IP address of the ONU is in the IP subnet allocated by the TG.
l If the destination IP address of the ONU is in the IP subnet allocated by the TG, go to Step
4.
l If the destination IP address of the ONU is not in the IP subnet allocated by the TG, run
the ip route-static command on the ONU to increase the route from the ONU to the TG
to ensure that the ONU can ping the TG. Then, proceed to Step 3.
Step 3 Call each other again to check whether the fault is rectified.
Step 4 On the same OLT, check whether subscribers of the OLT can call each other.
l If subscribers of the OLT cannot call each other, proceed to Step 5.
l If subscribers of the OLT can call each other, it indicates that the fault occurs on the link
from the OLT to the bearer network. Then, go to Step 10.
Step 5 On the same ONU, check whether subscribers of the ONU can call each other.
l If subscribers of the ONU cannot call each other, it indicates that the ONU is faulty. Then,
proceed to Step 6.
l If subscribers of the OLT can call each other, it indicates that the fault occurs on the link
from the OLT to the ONU. Then, go to Step 8.
Step 6 On the ONU, run the display acl all command to check whether the ACL rules filter the upstream
or downstream voice streams.
l If the ACL rules filter the upstream or downstream voice media streams, run the undo
acl command on the ONU to cancel the filtering rule. Then, proceed to Step 7.
l If the ACL rules do not filter the upstream or downstream voice streams, go to Step 12.
NOTE
If an ACL is delivered to a port, the ACL cannot be deleted. When you need to delete such an ACL, run
the undo packet-filter command on the ONU to cancel the delivery of this ACL.
Step 8 On the OLT, run the display acl all command to check whether the ACL rules filter the upstream
or downstream voice streams.
l If the ACL rules filter the upstream or downstream voice media streams, run the undo
acl command on the OLT to cancel the filtering rule. Then, proceed to Step 9.
l If the ACL rules do not filter the upstream or downstream voice streams, go to Step 10.

Module
NOTE
If an ACL is delivered to a port, the ACL cannot be deleted. When you need to delete such an ACL, run
the undo packet-filter command on the OLT to cancel the delivery of this ACL.
Step 10 Check whether ACL rules are correctly configured on the router of the IP bearer network.
l If ACL rules are correctly configured on the router of the IP bearer network, go to Step
12.
l If ACL rules are not correctly configured on the router of the IP bearer network, modify or
cancel ACL rules of the IP bearer network. Then, proceed to Step 11.
----End
Related Topics
2.3.4.5 Noise in Communication

Noise in communication indicates that a subscriber hears a strong current noise and broadcast
noise in communication, but the noise does not include the environment noise of two parties.
When a subscriber in FTTB and FTTC network hears noise, locate the fault according to the
following procedure:
Location Method
When a subscriber in FTTB and FTTC network hears noise, locate the fault according to the
following fault scope:
All subscribers of an ONU l The grounding of the digital distribution frame (DDF) and
ONU is not standard.
l The electrical attributes configured on the PSTN port do
not comply with the local standard.
l The input and output gains of the DSP chip do not comply
with the local standard.

Module
Subscribers of certain ports l The subscriber line and phone are faulty.
on an ONU l The VoIP service board of the ONU is faulty.
l The environment of the OLT, ONU, and external line has
electromagnetic interference.
Subscribers using certain The configurations related to numbers of the softswitch and
numbers voice gateway are incorrect.
CAUTION
Procedure
Step 1 Confirm the fault scope.
l If the fault occurs on all subscribers of the ONU, proceed to Step 2.
l If the fault occurs on subscribers of certain ports on the ONU, go to Step 7.
l If the fault occurs on subscribers using certain numbers, go to Step 11.
Step 2 On the ONU, run the display pstnport electric command to query the electrical attributes of a
PSTN port. Check whether the impedance type, current type, transmit gain, and receive gain
configured on the faulty port are the same as those configured on a normal port of another ONU.
l If the impedance type, current type, transmit gain, and receive gain configured on the faulty
port are the same as those configured on a normal port of another ONU, proceed to Step
4.
l If the impedance type, current type, transmit gain, and receive gain configured on the faulty
port are different from those configured on a normal port of another ONU, run the pstnport
electric set command on the ONU to configure the electrical attributes of the PSTN port
again to make the electrical attributes to be the same as those configured on a normal port.
Then, proceed to Step 3.
NOTE
When you need to configure the electrical attributes of the PSTN port in batches, you can run the pstnport
electric batset command.
Different countries and regions have different requirements on the electrical attributes. Therefore, the
configured electrical attributes must comply with the local standard and the interconnection parties must
have the same configurations. For example, the requirements for transmit and receive gains are as follows:
l China: The transmit gain and receive gain of the local network are 0 dB and -3.5 dB respectively. The
transmit gain and receive gain of the toll network are 0 dB and -7 dB respectively.
l Other countries and regions: Generally, the transmit gain the receive gain of the local network and toll
network are 0 dB and -7 dB respectively.

Module
Step 4 On the ONU, run the display mgpstnuser attribute command to query the attributes of a PSTN
subscriber, and check whether the input and output gains of the DSP chip configured on the
faulty port are the same as those configured on a normal port of another ONU.
l If the input and output gains of the DSP chip configured on the faulty port are the same as
those configured on a normal port, go to Step 6.
l If the input and output gains of the DSP chip configured on the faulty port are different
from those configured on a normal port, run the mgpstnuser attribute setframeid/slotid/
portiddsp-input-gaindsp-input-gain-valuedsp-output-gaindsp-output-gain-value
command on the ONU to configure the attributes of the PSTN subscriber again and make
the attributes to be the same as those configured on a normal port. Then, proceed to Step
5.
Step 6 Check whether DDF and ONU grounding complies with the local standard. Call each other again
to check whether the fault is rectified.
Step 7 On the ONU, run the pots loop-line-test command to perform a loop-line test for the board
where a fault occurs.
l If the test result is normal, it indicates that the external line and the phone are faulty. Then,
go to Step 9.
l If the test result is that the ONU is not connected to a phone, it indicates that the phone is
faulty or the cable between the phone and the ONU is not properly connected. In this case,
replace the phone and make sure that the cable between the phone and the ONU is properly
connected. Then, proceed to Step 8.
l If the test result is others such as line B grounding, it indicates that external lines are faulty.
In this case, troubleshoot the fault according to the prompt message. For example, if the
test result is line B grounding, it indicates that line B may be damaged. In this case, replace
the line B, and then proceed to Step 8.
NOTE
The qualitative loop-line test conclusions include: normal, touch the power line, line A mixed with other lines,
line B mixed with other lines, lines A and B mixed with other lines, line A grounding, line B grounding, lines
A and B grounding, self-mixing (small resistance and self-touch wire), A-B insulation difference, line A leakage,
line B leakage, lines A and B leakage, phone set not connected, offhook, and unknown.
Step 9 Check the voice board for the subscriber who encounters the fault. Call each other again to check
Step 10 Check the environment for the ONU, OLT, and external lines to troubleshoot electrical
interference of the broadcast tower and high voltage cables. Call each other again to check

Module

Step 11 Check configurations related to numbers of the softswitch and voice gateway. Compare the
configurations of the faulty numbers with those of the normal numbers and modify the
configurations of the faulty numbers to be the same as those of the normal numbers. Call each
other again to check whether the fault is rectified.
----End
Related Topics
2.3.4.6 Poor Voice Service in Communication

Poor voice service in communication indicates that the voice heard by one party of the
communication is poor and is interrupted at times. When the voice heard by one party of the
communication is poor and is interrupted at times in FTTB and FTTC network, locate the fault
Location Method
When the voice heard by one party of the communication is poor and is interrupted at times in
FTTB and FTTC network, locate the fault according to the following procedure:
1. Check whether the QoS priority of the voice service is very low.
2. Check whether the phone is faulty.
CAUTION
Procedure
Step 1 On the ONU, run the display qos ip command and the display qos vlan command to check
whether the QoS priority of the voice service is very low.
l If the QoS priority of the voice service is very low, run the qos ip command to set a higher
QoS priority of the media IP address and signaling IP address, and run the qos vlan
command to set the VLAN priority of the media IP address and signaling IP address to 6.
l If the QoS priority of the voice service is not very low, go to Step 3.

Module
NOTE
l When packet loss occurs in case of congestion in the network, packets with a lower QoS priority are
discarded first. Priorities of QoS packets are from 0 to 7 in an ascending order.
l The voice service has a high requirement on network quality, and in this case, it is recommended that
you set the priority of the voice service to 6 on the ONU.
Step 3 Replace the phone. Then, call each other again to check whether the fault is rectified.
----End
Related Topics
2.3.4.7 Failure to Dial Certain Phone Numbers

Failure to dial certain phone numbers indicates that when dialing certain phone numbers, the
subscriber hears "the number you dialed does not exist". When a subscriber fails to dial certain
phone numbers in FTTB and FTTC network, locate the fault according to the following
procedure.
Location Method
When a subscriber fails to dial certain phone numbers in FTTB and FTTC network, locate the
fault according to the following procedure:
1. Check whether digitmaps associated with the phone numbers are configured on the MGC.
2. Check the network between the ONU and the softswitch.
CAUTION
Procedure
Step 1 Check whether digitmaps associated with the phone numbers are configured on the MGC.
l If digitmaps associated with the phone numbers are configured on the MGC, go to Step
3.

Module
l If digitmaps associated with the phone numbers are not configured on the MGC, configure
digitmaps on the MGC. Then, proceed to Step 2.
Step 3 On the ONU, run the ping command to ping the IP address of the software to check whether
packet loss occurs.
l If packet loss occurs, troubleshoot the fault (for example, optical fibers are not properly
connected). Then, proceed to Step 4.
l If packet loss does not occur, go to Step 5.
----End
Related Topics
2.3.4.8 Unexpected Communication Interruptions

When the communication between two users on a fiber to FTTB and FTTC network is interrupted
unexpectedly, locate the fault according to the following procedure.
Fault Location
Use the following guidelines to locate the fault:
1. Check whether the line quality is poor, the packet loss on the network is severe, or the
network communication is interrupted.
2. Check whether the softswitch is faulty.
3. Check whether the associated data configurations are correct.
CAUTION
Procedure
Step 1 Run the ping command on the optical network unit (ONU) to ping the IP address of the softswitch
to check whether a packet loss occurs on network.

Module
l If a packet loss occurs on the network, identify and rectify the network fault, for example,
the fiber is not properly connected to the device. Then, go to Step 2.
l If no packet loss occurs on the network, go to Step 3.
Step 2 Redial the number of the peer party to check whether the fault is rectified.
Step 3 Have a softswitch engineer check whether all users connected to the softswitch have encountered
this fault.
l If all users connected to the softswitch have encountered this fault, have the softswitch
engineer rectify the fault. Then, go to Step 10.
l If not all users connected to the softswitch have encountered this fault, go to Step 4.
Step 4 On the ONU, run the display protocol support command to query the current used voice
protocol.
l If the H.248 protocol is used, go to Step 5
l If the SIP protocol is used, go to Step 7
Step 5 Run the display if-h248 attribute command on the ONU to check whether the H.248 interface
data configurations are consistent with the data plan.
l If the data configurations are consistent with the data plan, go to Step 9.
l If the data configurations are inconsistent with the data plan, go to Step 6.
Step 6 Run the if-h248 attribute command on the ONU to modify the H.248 interface data
configurations as required, and run the reset coldstart command to reset the H.248 interface.
Then, check whether the fault is rectified.
Step 7 Run the display if-sip attribute command on the ONU to check whether the SIP interface data
configurations are consistent with the data plan.
l If the data configurations are consistent with the data plan, go to Step 9.
l If the data configurations are inconsistent with the data plan, go to Step 8.
Step 8 Run the if-sip attribute basic command on the ONU to modify the SIP interface data
configurations as required, and run the reset command to reset the SIP interface. Then, check
----End
Related Topics
7.4.10 Abnormal Voice Interruption

Module
2.3.5 FoIP Service Failures

This section describes how to troubleshoot fax over IP (FoIP) service failures.
Fault Location
Start
Check whether the fax

machine is functional.
Check whether the bearer

network quality is good.

Check whether the softswitch

End
CAUTION
Procedure
Step 1 Check whether the fax machine is working properly.
l If the fax machine is working properly, go to Step 3.
l If the fax machine is faulty, go to Step 2.

Module
NOTE
Common fax machine problems are as follows:

l There is no paper or the paper is not placed properly in the sending fax machine, causing a failure to send
faxes.
l The memory on the receiving fax machine is full, causing a failure to receive faxes.
l The sending fax machine is set to the pulse dialing mode, causing a failure to send faxes.
l A function that blocks incoming faxes is enabled on the receiving fax machine, causing a failure to receive
faxes.
l Automatic fax reception is not enabled on the receiving fax machine. Therefore, the fax machine will not
receive a fax if the user does not manually operate the machine to receive it.
Step 2 Replace the fax machine and check whether the fault is rectified.
Step 3 Ping the interconnected media gateway controller (MGC) from the multi-dwelling unit (MDU),
and check whether severe packet loss or a large delay occurs on the network.
l If the network has such a problem, Then, go to Step 4.
l If the network does not have such a problem, go to Step 5.
NOTE
To transmit fax services, the bearer network is required to meet the following requirements:
l In T.30 transparent transmission fax mode that uses G.711 codec, the packet loss ratio on the bearer network
must be smaller than or equal to 0.1%.
l In T.38 fax mode that uses T.38 codec, the packet loss ratio on the bearer network must be smaller than or
equal to 1%.
Step 4 Check the network and the transmission devices between the MDU and the MGC, and rectify
any fault. Ensure that the MDU can ping the MGC and that there is no severe packet loss on the
network, and check whether the FoIP service recovers.
l If the service recovers, go to Step 10.
Step 5 Run the display fax-modem parameters command on the MDU to check whether the Rfc2198-
start-mode settings on the MDU are the same as the settings on the softswitch.
l If the settings are the same, go to Step 7.
l If the settings are different, Then, go to Step 6.
NOTE
The RFC 2198 protocol is used to improve data transmission reliability and service quality using the
redundancy transmission mechanism. This function must be enabled on both the MDU and the softswitch
if the function is used. Otherwise, the fax service will fail.
Step 6 Run the fax-modem parameters rfc2198-start-mode command on the MDU to change the
redundancy transmission settings so that they are the same as the settings on the softswitch, and
check whether the FoIP service recovers.
Step 7 Check whether the V21 signal detection threshold is properly set on the softswitch.
l If the threshold is properly set, go to Step 9.

Module
l If the threshold is not properly set, change the value, and go to Step 8.
NOTE
The V21 signal detection threshold on the software is set based on the level value of a common fax machine.
The default level is -20 dB. If the V21 signal level sent by the public switched telephone network (PSTN)
port to the softswitch has not reached the detection threshold on the softswitch (for example, about -27
dB), the softswitch cannot detect fax signals. In this case, fax reception will fail. You can use either of the
following methods to prevent this problem:
l Method 1: Set the V21 signal detection threshold on the softswitch to slightly lower than the V21 signal
level sent by the PSTN port. If an interference source exists on the line, set the detection threshold on
the softswitch to about -20 dB.
l Method 2: Replace the fax machine to increase the V21 signal level sent by the PSTN port to a value
higher than -20 dB. This ensures that the signal level on the fax machine is about -15 dB (between -11
dB and -19 dB).
Step 8 Check whether the FoIP service recovers.

----End
Related Topics
7.4.9 Abnormal Fax Service
2.3.6 MoIP Service Failures

This section describes how to troubleshoot modem over IP (MoIP) service failures. MoIP service
failures include Internet access dial-up failures and frequent Internet access interruptions.
Fault Location

Module
Start
Check whether the modem

is functional.
Check whether the modem


Check whether the

softswitch configurations
are correct.
Check whether the bearer

network quality is good.
End
CAUTION
Procedure
Step 1 Check whether the modem is functional.
l If the modem is functional, go to Step 3.
l If the modem is faulty, go to Step 2.
Step 2 Replace the modem with a functional one and check whether the fault is rectified.
Step 3 Check whether the modem settings are correct, such as the modem clock settings and dial-in
and dial-out rights settings.
l If the settings are correct, go to Step 5.
l If the settings are incorrect, go to Step 4.
Step 4 Set the modem correctly and check whether the fault is rectified.

Module

Step 5 Run the display fax-modem parameters command on the local and peer multi-dwelling units
(MDUs) to check whether the modem configuration conforms to the data plan. In addition, have
the media gateway controller (MGC) engineer check whether the MGC configuration conforms
to the data plan.
l If the modem configuration and MGC configuration conform to the data plan, go to Step
7.
l If the configurations do not conform to the data plan, go to Step 6.
NOTE
Check whether the Rfc2198-start-mode settings on the local MDU are the same as the settings on the peer
MDU.
l The RFC 2198 protocol is used to improve data transmission reliability and service quality using the
redundancy transmission mechanism.
l This function must be enabled on both the MDUs if the function is used. Otherwise, the modem service will
fail.
Step 6 Run the fax-modem parameters command on the local and peer MDUs to modify the modem
service configuration and ensure that the configuration conforms to the data plan. In addition,
have the MGC engineer modify the MGC configuration to ensure that the configuration
conforms to the data plan. Then, check whether the fault is rectified.
Step 7 Ping the interconnected MGC from the MDU, and check whether severe packet loss or a large
delay occurs on the network.
l If the MGC cannot be pinged or the packet loss ratio is high, go to Step 8.
l If the MGC can be pinged and there is no packet loss, go to Step 9.
NOTE
The packet loss ratio on the bearer network is required to be smaller than 0.5% to carry modem services.
Step 8 Check the network and the transmission devices between the MDU and the MGC, and rectify
any fault. Ensure that the MDU can ping the MGC and that there is no severe packet loss on the
network. Then, check whether the modem services recover.
l If the services recover, go to Step 10.
----End
Related Topics
7.4.13 Abnormal POS Machine Service

Module
Troubleshooting 3 Troubleshooting the xDSL Services
3 Troubleshooting the xDSL Services
About This Chapter
This topic describes how to troubleshoot typical faults in the Internet access service and the
multicast service when the MA5600T/MA5603T functions as the DSLAM. When the xDSL
board is installed in the subrack of the MA5600T/MA5603T to directly provide the xDSL
services for users, the MA5600T/MA5603T can implement the DSLAM application scenario.
3.1 Troubleshooting the Internet Access Service
This topic describes how to troubleshoot the faults in the Internet access service when the
MA5600T/MA5603T functions as the DSLAM. The common faults in the Internet access
service include failure to access the Internet after successfully obtaining an IP address, low
Internet access rate, frequent offline in accessing the Internet, failure to obtain an IP address in
PPPoE dialup, failure to obtain an IP address in the DHCP mode, failure to obtain an IP address
in PPPoA dialup, and failure to obtain an IP address in IPoA dialup.
3.2 Troubleshooting the Multicast Service
This topic describes how to troubleshoot the faults in the multicast service when the MA5600T/
MA5603T functions as the DSLAM. The common faults in the multicast service include failure
to go online for a multicast user, dark screen after ordering a program, erratic display (mosaic)
in a multicast program, abnormal program interruption in watching a program, and long time in
switching programs.

Module
3.1 Troubleshooting the Internet Access Service

This topic describes how to troubleshoot the faults in the Internet access service when the
MA5600T/MA5603T functions as the DSLAM. The common faults in the Internet access
service include failure to access the Internet after successfully obtaining an IP address, low
Internet access rate, frequent offline in accessing the Internet, failure to obtain an IP address in
PPPoE dialup, failure to obtain an IP address in the DHCP mode, failure to obtain an IP address
in PPPoA dialup, and failure to obtain an IP address in IPoA dialup.
3.1.1 Failure to Access the Internet After Successfully Obtaining an

IP Address
This topic describes how to troubleshoot the fault when a user successfully obtains an IP address
but fails to view the Web pages. When the MA5600T/MA5603T functions as the DSLAM and
a user fails to access the Internet after successfully obtaining an IP address, locate the fault
Location Method
When a user of the DSLAM fails to access the Internet after obtaining an IP address, locate the
1. Check whether user bandwidth is occupied by unknown traffic.

2. Check whether the bandwidth of the upstream port is insufficient.
3. Check whether packets are lost on the xDSL line.
4. Check whether packets are lost on the upstream port.
5. Check whether the MAC address drift exists.
6. Check whether the MTU and MSS configurations of the BRAS are correct.
7. Check whether the user PC is faulty (such as having an Internet Explorer fault).
CAUTION
Procedure
Step 1 Stop the user PC from sending Internet access requests, and run the display traffic command
to query the real-time traffic on the faulty port.
NOTE
Rx Traffic(Kbps) indicates the current upstream traffic and Tx Traffic(Kbps) indicates the current
downstream traffic. Normally, when the user stops the Internet access, the upstream and downstream traffic
is very low (far lower than the user bandwidth) and is close to 0.
l If the upstream or downstream traffic is very heavy, it indicates that the unknown traffic
occupies the user bandwidth. In this case, proceed to Step 2.

Module
l If the upstream or downstream traffic is very light (far lower than the user bandwidth) and
is close to 0, go to Step 3.
Step 2 Capture packets by using the packet capture tool, such as Ethereal installed on the PC to check
the source of the unknown traffic and to further clear the unknown traffic. Then, check whether
the service recovers to normal.
l If the service recovers to normal, go to Step 22.
l If the service does not recover to normal, proceed to Step 3.
Step 3 Check whether the bandwidth of the upstream port is insufficient.

1. In the SCU mode or the GIU mode, run the display port state portid command to check
the maximum permitted bandwidth of the upstream port. Ethernet port rate is in the unit
of Mbit/s.
2. Make the user continue to access the Internet, and then run the display port traffic
command for multiple times (10 times are recommended) to query the real-time traffic of
the upstream port. The interval between two queries is 20s. Then, check whether the current
occupied bandwidth of the upstream port is close to the maximum permitted bandwidth.
NOTE
l The traffic may be burst traffic; therefore, it is recommended that you query the traffic for multiple
times.
l 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 calculation, if the current occupied bandwidth of the upstream port is close to the
maximum permitted bandwidth, it indicates that the bandwidth of the upstream port of the
site causes the fault. In this case, proceed to Step 4.
l If the current occupied bandwidth of the upstream port is far lower than the maximum
permitted bandwidth, go to Step 5.
Step 4 Increase the maximum permitted bandwidth of the upstream port (for example, replace the 100M
daughter board with the 1000M daughter board, or run the speed command to configure a higher
bandwidth of the upstream port), or use multiple upstream ports (upstream port aggregation) to
provide the user bandwidth, or decrease the number of users configured on the device (migrate
certain users to other devices). Then, check whether the service recovers to normal.
NOTE
The maximum permitted bandwidth of the upstream port is associated with the hardware capability (a
100M daughter board or a 1000M daughter board. You can run the display board frameid/slotid command
to query the type of the current daughter board used by the control board) and the configurations.
l If the negotiation function of the upstream port is enabled (run the auto-neg command to configure
the negotiation function), the maximum permitted bandwidth of the upstream port is determined by
the negotiation between the upstream port and the port on the interconnected device.
l If the negotiation function of the upstream port is disabled, the maximum permitted bandwidth of the
upstream port is the value configured by running the speed command.
Step 5 Check whether the CRC packets are lost on the line of the user port.
l If the CRC packets are lost on the line of the user port, check the line environment, that is,
check whether the interference source exists. Then, replace the modem, and go to Step 6.
l If the CRC packets are not lost on the line of the user port, go to Step 7.

Module
NOTE
You can check whether the CRC packets are lost on the line of the user port by querying the performance
statistics of the faulty port for many times (10 times are recommended). These queries are at an interval of
20s and need to be performed based on the type of a xDSL port.
l In the case of an ADSL port, in the ADSL mode, run the display statistics performance frameid/
slotid/portid current-15minutes command to query the performance statistics of the faulty ADSL port.
Then, observe the query result multiple times to check whether Count of errored seconds and Count
of severely errored seconds increase. If they increase, it indicates that the CRC packets are lost on
the ADSL line.
l In the case of a VDSL port, in the VDSL mode, run the display statistics performance portid line-
showtime cpe current-15minutes command to query the performance statistics when the VDSL line
is working. Then, observe the query result multiple times to check whether Count of errored
seconds and Count of severely errored seconds increase. If they increase, it indicates that the CRC
packets are lost on the VDSL line.
l In the case of an SHDSL port, in the SHDSL mode, run the display statistics performance portid
current command to query the current performance statistic of a faulty SHDSL port. Then, observe
the number of CRC anomalies (CRC anomaly count in 15 minutes) within 15 minutes. If the number
is not 0, it indicates that the CRC packets are lost on the SHDSL line.

Step 7 In the SCU mode or the GIU mode, run the display port statistics command for multiple times
(10 times are recommended) to query the performance statistics of the upstream port. The interval
between two queries is 20s. Then, check whether the number of CRC packets lost on the upstream
port increases.
l If Number of CRC error frames increases, it indicates that CRC packets are lost on the
upstream port. The packet loss may occur because the upstream link is abnormal, port
negotiation is incorrect, or the port is faulty. In this case, proceed to Step 8.
l If Number of CRC error frames does not increase, go to Step 9.
Step 8 Troubleshoot the upstream port fault and then check whether the service recovers to normal.
1. Troubleshoot the upstream port fault.
l If the optical port is used for upstream transmission, check whether the negotiation mode
of the local port is the same as the negotiation mode of the port on the interconnected
device. Run the display port state portid command to check the negotiation mode of
the local upstream port. At the same time, check whether optical fibers are loose and
whether the optical module is matched. Run the display port opticstate portid
command to query the information about the optical module, and mainly check whether
the type, wavelength, and transmission distance of the local and interconnected optical
modules are consistent. Make sure that the negotiation modes of ports are the same, and
optical fibers are firmly inserted. If necessary, replace an optical module.
l If the electrical port is used for upstream transmission, check whether the negotiation
mode of the local port is the same as the negotiation mode of the port on the
interconnected device. Run the display port state portid command to check the
negotiation mode of the local upstream port. At the same time, check whether network
cables are normal. Make sure that the negotiation modes of ports are the same. If
necessary, replace a network cable.

Module
Step 9 In the global config mode, run the display location command for multiple times (over three
times are recommended) to query the ports that learn the user MAC address. Then, check whether
user MAC address drift exists.
NOTE
l In query, the input mac-addr is the user MAC address. If a modem is used for dialup, the user MAC
address is the MAC address of the modem. If a PC is used for dialup, the user MAC address is the
MAC address of the PC.
l In results, F/S/P is the user port that learns the user MAC address. Normally, the queried port is the
port connected to the user. Otherwise, user MAC address drift exists.
l If user MAC address drift exists, check whether a ring network or user attack exists. If a
ring network or user attack exists, troubleshoot the fault (for example, disconnect the ring
network or deactivate the port where the user attack is from). Then, proceed to Step 10.
l If user MAC address drift does not exist, go to Step 11.

Step 11 Run the display location command for multiple times (over three times are recommended) to
query the ports that learn the BRAS MAC address. Then, check whether BRAS MAC address
drift exists.
NOTE
l In query, the input mac-addr is the BRAS MAC address.

l In results, F/S/P is the upstream port that learns the BRAS MAC address. Normally, the queried port
is the upstream port connected to the BRAS. Otherwise, BRAS MAC address drift exists.
l If BRAS MAC address drift exists, check whether a ring network or user attack exists. If
a ring network or user attack exists, troubleshoot the fault (for example, disconnect the ring
l If BRAS MAC address drift does not exist, go to Step 13.

Step 13 In DOS of the PC, type Ping -n 100 x.x.x.x. x.x.x.x indicates the IP address of the DNS, and
100 indicates that 100 packets are sent to the DNS for the ping test.
l If you can ping the IP address of the DNS, go to Step 15.
l If you cannot ping the IP address of the DNS, it indicates that the DNS is incorrectly
configured or the DNS is faulty. In this case, check the configuration of the DNS and the
running status of the DNS to rectify the fault. Then, proceed to Step 14.

Step 15 Check whether only certain Web sites cannot be opened.

l If only certain Web sites cannot be opened, proceed to Step 16.
l If all the Web sites cannot be opened, go to Step 18.

Module
Step 16 In DOS of the PC, type Ping -n 100 x.x.x.x -l y. x.x.x.x indicates the IP address of the Web site
(it can be the domain name of the Web site), and 100 indicates that 100 packets with the length
of y are sent to the Web site for the ping test.
NOTE
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 ping test is successful by
using the short packets but fails by using the long packets, it indicates that the MTU of the BRAS is very
small but the MSS of the BRAS is very great.
l If the MTU of the BRAS is very small but the MSS of the BRAS is very great, increase the
MTU of the BRAS and decrease the MSS of the BRAS. Then, proceed to Step 17.
l If the MTU and MSS of the BRAS are correct, go to Step 20.
l If the service does not recover to normal, go to Step 20.
Step 18 In DOS of the PC, type Ping -n 100 x.x.x.x -l y. x.x.x.x indicates the IP address of the BRAS,
and 100 indicates that 100 packets with the length of y are sent to the BRAS for the ping test.
NOTE
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 ping test is successful by
using the short packets but fails by using the long packets, it indicates that the MTU of the BRAS is very
small but the MSS of the BRAS is very great.
l If the MTU of the BRAS is very small but the MSS of the BRAS is very great, increase the
MTU of the BRAS and decrease the MSS of the BRAS. Then, proceed to Step 19.
l If the MTU and MSS of the BRAS are correct, go to Step 20.
Step 20 Check whether the PC is faulty (mainly check whether the Internet Explorer is faulty). After
troubleshooting the fault, check whether the service recovers to normal.
----End

When the MA5600T/MA5603T functions as the DSLAM and the Internet access rate of the user
is low, locate the fault according to the following procedure.
Location Method
When the Internet access rate is low for the DSLAM user, locate the fault according to the

Module
1. Check whether the line activation rate meets the user bandwidth requirement.
2. Check whether the limited rate configured in the traffic profile meets the user bandwidth
requirement.
3. Check whether user bandwidth is occupied by unknown traffic.
4. Check whether the bandwidth of the upstream port is insufficient.
5. Check whether packets are lost on the VDSL line.
8. Check whether packets are lost in transmission from the user to the BRAS or from the user
to the Web site.
CAUTION
Procedure
Step 1 Run the display line operation command to query the actual line rate of the modem. Check
whether the line activation rate of the faulty port meets the user bandwidth requirement.
l If the activation rate does not meet the user bandwidth requirement, modify the line
profile. Bind the port to a more proper line profile to improve the line rate. Then, proceed
to Step 2.
l If the activation rate meets the user bandwidth requirement, go to Step 3.

Step 3 Check whether the limited rate configured in the traffic profile meets the requirement on the
user bandwidth for the Internet access.
1. Run the display service-port port 0/3/1 command to query the index of the RX traffic
bound to the traffic stream of the Internet access service (assume that the physical port of
the user is 0/3/1).
2. Run the display traffic table ip from-index 0 command to query the PIR of the traffic
profile bound to the traffic stream of the Internet access service.
3. Compare the PIR with the user bandwidth for the Internet access service.
l If the PIR is off, higher than, or equal to the user bandwidth for the Internet access
service, it indicates that the rate of the bound traffic profile is sufficient and is not the
cause of the problem. Then, go to Step 5.
l If the PIR is lower than the user bandwidth for the Internet access service, it indicates
that the rate of the bound traffic profile is excessively low.
– If proper traffic profiles exist in the system, run the service-port 0 outbound traffic-
table index 6 command to bound the traffic stream of the Internet access service to
a more proper traffic profile (assume that the index for the traffic stream of the

Module
Internet access service is 0 and the index of the traffic profile to be bound is 6). Then,
proceed to Step 4.
– If no traffic profile in the current system meets the requirement, run the traffic table
ip command to add a proper traffic profile, and bind the traffic profile to the traffic
stream of the Internet access service. Then, proceed to Step 4.
Step 5 Stop the user from accessing the Internet, and run the display traffic command to query the
real-time traffic on the faulty port.
NOTE
Rx Traffic(Kbps) indicates the current upstream traffic and Tx Traffic(Kbps) indicates the current
downstream traffic. Normally, when the user stops the Internet access, the upstream and downstream traffic
is very low (far lower than the user bandwidth) and is close to 0.
l If the upstream or downstream traffic is very heavy, it indicates that the unknown traffic
occupies the user bandwidth. In this case, proceed to Step 6.
l If the upstream or downstream traffic is very light (far lower than the user bandwidth) and
is close to 0, go to Step 7.
Step 6 Capture packets by using the packet capture tool, such as Ethereal installed on the PC to check
the source of the unknown traffic and to further clear the unknown traffic. Then, check whether
the service recovers to normal.
Step 7 Check whether the bandwidth of the upstream port is insufficient.
1. In the SCU mode or the GIU mode, run the display port state portid command to check
the maximum permitted bandwidth of the upstream port. Ethernet port rate is in the unit
of Mbit/s.
2. Make the user continue to access the Internet, and then run the display port traffic
command for multiple times (10 times are recommended) to query the real-time traffic of
the upstream port. The interval between two queries is 20s. Then, check whether the current
occupied bandwidth of the upstream port is close to the maximum permitted bandwidth.
NOTE
l The traffic may be burst traffic; therefore, it is recommended that you query the traffic for multiple
times.
l 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 calculation, if the current occupied bandwidth of the upstream port is close to the
maximum permitted bandwidth, it indicates that the bandwidth of the upstream port of the
site causes the fault. In this case, proceed to Step 8.
l If the current occupied bandwidth of the upstream port is far lower than the maximum
permitted bandwidth, go to Step 9.
Step 8 Increase the maximum permitted bandwidth of the upstream port (for example, replace the 100M
daughter board with the 1000M daughter board, or run the speed command to configure a higher
bandwidth of the upstream port), or use multiple upstream ports (upstream port aggregation) to
share the user bandwidths, or decrease the number of users configured on the device (migrate
certain users to other devices). Then, check whether the service recovers to normal.

Module

NOTE
The maximum permitted bandwidth of the upstream port is associated with the hardware capability (a
100M daughter board or a 1000M daughter board. You can run the display board frameid/slotid command
to query the type of the current daughter board used by the control board) and the configurations.
l If the negotiation function of the upstream port is enabled (run the auto-neg command to configure
the negotiation function), the maximum permitted bandwidth of the upstream port is determined by
the negotiation between the upstream port and the port on the interconnected device.
l If the negotiation function of the upstream port is disabled, the maximum permitted bandwidth of the
upstream port is the value configured by running the speed command.
Step 9 When the VDSL line is working, run the display statistics performance portid line-showtime
cpe current-15minutes command 10 times at an interval of 20s to query the performance
statistics. Then, observe the query result multiple times to check whether Count of errored
seconds and Count of severely errored seconds increase. If they increase, it indicates that the
CRC packets are lost on the VDSL line.
l If the CRC packets are lost on the line of the user port, check the line environment, that is,
check whether the interference source exists. Then, replace the modem, and go to Step
10.
l If the CRC packets are not lost on the line of the user port, go to Step 11.

Step 11 In the SCU mode or the GIU mode, run the display port statistics command for multiple times
(10 times are recommended) to query the performance statistics of the upstream port. The interval
between two queries is 20s. Then, check whether the number of CRC packets lost on the upstream
port increases.

Module
NOTE

query the ports that learn the MAC address of the BRAS. Then, check whether BRAS MAC
address drift exists.
NOTE
l In query, the input mac-addr is the MAC address of the BRAS.

l In results, F/S/P is the upstream port that learns the MAC address of the BRAS. Normally, the queried
port is the upstream port connected to the BRAS. Otherwise, BRAS MAC address drift exists.

Step 17 Check whether this fault occurs only when certain Web sites are opened.
l If this fault occurs only when certain Web sites are opened, proceed to Step 18.
l If this fault occurs when opening all the Web sites, go to Step 20.
Step 18 In DOS of the PC, type Ping -n 100 x.x.x.x. x.x.x.x indicates the IP address of the Web site (it
can be the domain name of the Web site), and 100 indicates that 100 packets are sent to the Web
site for the ping test.

Module
Step 19 In DOS of the PC, type Ping -l 1200 -n 100 x.x.x.x. x.x.x.x indicates the IP address of the Web
site (it can be the domain name of the Web site), and 1200 indicates that 100 packets with the
length of 1200 octets are sent to the Web site for the ping test.
Step 20 In 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.
Step 21 In DOS of the PC, type Ping -l 1200 -n 100 x.x.x.x. x.x.x.x indicates the IP address of the BRAS,
and 1200 indicates that 100 packets with the length of 1200 octets are sent to the BRAS for the
ping test.
----End
3.1.3 Frequent Offline in the Internet Access Service

This topic describes how to troubleshoot the fault when the connection is frequently interrupted
in the Internet access service. When the MA5600T/MA5603T functions as the DSLAM and the
connection of a user is frequently interrupted in accessing the Internet, locate the fault according
Location Method
When the connection of a DSLAM user is frequently interrupted in the Internet access service,
locate the fault according to the following procedure:
1. Check whether the service board status is normal.
3. Check whether the user MAC address drift exists.
4. Check whether the BRAS MAC address drift exists.
5. Check line parameters of the faulty port.
6. Check the physical line.
7. Replace a modem for test.
CAUTION
Procedure
Step 1 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 4.3 Service Board Resets
Repeatedly to rectify the fault. Then, proceed to Step 2.
l If the board that houses the faulty port is not reset repeatedly, proceed to Step 3.

Module

Step 3 In the SCU mode, run the display port statistics command for multiple times (10 times are
recommended) to query the performance statistics of the upstream port. The interval between
two queries is 20s. Then, check whether the number of CRC packets lost on the upstream port
increases.
NOTE

Module
drift exists.
NOTE

Step 9 Check line parameters of the user port.
l In the case of an ADSL2+ port, in the ADSL mode, run the display line operation portid
command to check whether the following line parameters are correct (compared with the
empirical 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 the VDSL mode, run the display line operation portid
command to check whether the following line parameters are correct (compared with the
empirical values or compared with other normal ports).
– Line SNR margin downstream
– Line SNR margin upstream
– Actual line rate downstream
– Actual line rate upstream
– Line attenuation downstream
– Line attenuation upstream
l In the case of an SHDSL port, in the SHDSL mode, check whether the following line
parameters are 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 SNR
margin.
– Run the display statistics performance portid current command to query Current
LoopAttenuation.
l If the preceding parameters are correct, go to Step 11.
l If only certain preceding parameters are correct, proceed to Step 10.

Module
Step 10 Modify line parameters and then check whether the service recovers to normal.
1. Modify line parameters.
l In the case of an ADSL2+ port, in the ADSL mode, run the adsl line-profile modify
command to enlarge values of the following parameters:
– 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
l In the case of a VDSL2 port, in the VDSL mode, run the vdsl line-profile modify
command to enlarge values of the following parameters:
– Target SNR margin downstream
– Minimum SNR margin downstream
– Maximum SNR margin downstream
– Target SNR margin upstream
– Minimum SNR margin upstream
– Maximum SNR margin upstream
l In the case of an SHDSL port, in the SHDSL mode, run the shdsl line-profile modify
command to modify the following parameters:
– Increase Downstream current target SNR margin and Downstream worst case
target SNR margin.
– Increase Upstream current target SNR margin and Upstream worst case target
SNR margin.
– Set Target SNR margin bitmap to 0xF to make the preceding four SNR margins
take effect.
l If the service does not recover to normal, in the case that the service board has an internal
splitter, go to Step 13; in the case that the service board has an external splitter, proceed
to Step 11.
Step 11 Check whether cable connection on the splitter is correct.
l If cable connection on the splitter is correct, go to Step 13.
l If cable connection on the splitter is incorrect, connect cables again, and then proceed to
Step 12.
Step 13 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 15.
l If connectors of drop cables and phone lines are not connected properly, connect them again
to ensure that they are connected properly. Then, proceed to Step 14.

Module

Step 15 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 proceed to Step 16.
l If only the PC is connected to the modem, go to Step 17.
Step 17 Check whether strong interference sources exist around the subscriber end, such as the radio
BTS.
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, seek
help from the associated departments. Then, go to Step 21.
l If no strong interference sources exist around the subscriber end, proceed to Step 18.
Step 18 Collect the port statistics and then proceed to the next step.
l In the case of an ADSL2+ port, in the ADSL mode, run the following commands:
– display statistics performance portid current-15minutes (over three times are
recommended and the interval between two queries is 20s)
– display statistics performance portid current-24hours
l In the case of a VDSL2 port, in the VDSL mode, run the following commands:
– display statistics performance portid channel all co current-15minutes (over three
times are recommended and the interval between two queries is 20s)
– display statistics performance portid channel all co current-24hours
– display statistics performance portid channel all cpe current-15minutes (over three
– display statistics performance portid channel all cpe current-24hours
– display statistics performance portid line-initial current- 15minutes (over three times
are recommended and the interval between two queries is 20s)
– display statistics performance portid line-initial current- 24hours
– display statistics performance portid line-showtime co current-15minutes (over three
– display statistics performance portid line-showtime co current-24hours
– display statistics performance portid line-showtime cpe current-15minutes (over
three times are recommended and the interval between two queries is 20s)
– display statistics performance portid line-showtime cpe current-24hours
l In the case of an SHDSL port, in the SHDSL mode, run the display statistics performance
portid current command (over three times are recommended and the interval between two
queries is 20s)
Step 19 Replace a modem for test. Then, check whether the service recovers to normal.

Module
----End
3.1.4 Failure to Obtain an IP Address in PPPoE Dialup

This topic describes how to troubleshoot the fault when a user fails to access the Internet because
no IP address can be obtained in PPPoE dialup. When the MA5600T/MA5603T functions as
the DSLAM and no IP address can be obtained in PPPoE dialup, locate the fault according to
the following procedure.
Location Method
When no IP address can be obtained in PPPoE dialup for the DSLAM user, locate the fault
1. Check the connectivity between the device and the modem.

2. Check whether the upstream port exists in the upstream VLAN and whether the upstream
link is in the online state.
3. Check the PITP configuration.
4. Check the configuration of the PPPoE MAC address.
6. Check the security feature configuration.
7. Check whether the ACL rule that limits PPPoE packets is configured.
8. Check whether the user data of the upper-layer BRAS is correct and whether the account
of the user is limited.
CAUTION
Procedure
Step 1 In the xDSL mode, run the atm-ping portid vpi vci command to check whether the device can
ping the modem.
The xDSL mode can be ADSL, SHDSL, or VDSL.
l If the device can ping the modem, go to Step 6.

l If the device cannot ping the modem, proceed to Step 2.
Step 2 Run the display port state portid command to check whether the port to which the user belongs
is activated (Status is Activated).
l If the port is activated, go to Step 4.

Module
l If the port is not activated, run the activate portid command to activate the user port. Then,
proceed to Step 3.

Step 4 In the global config mode, run the display service-port port frameid/slotid/portid command to
check whether VPI and VCI of traffic streams are the same as VPI and VCI configured on the
modem.
l If VPI and VCI of traffic streams are the same as VPI and VCI configured on the modem,
go to Step 6.
l If VPI and VCI of traffic streams are not the same as VPI and VCI configured on the modem,
modify VPI and VCI of the MA5600T/MA5603T to be the same as those configured on
the modem, or modify VPI and VCI of the modem to be the same as those configured on
the MA5600T/MA5603T. If VPI and VCI of the MA5600T/MA5603T are modified, run
the undo service-port command to delete the original service port, and then run the service-
port command to configure the new VPI and VCI. Then, proceed to Step 5.

Step 6 Run the display port vlan frameid/slotid/portid command to check whether the upstream port
exists in the upstream VLAN. The query result contains the upstream VLAN ID.
l If the upstream port exists in the upstream VLAN, go to Step 8.
l If the upstream port is not added to the upstream VLAN, run the port vlan command to
add the upstream port to the upstream VLAN. This VLAN must be the same as the VLAN
configured for the upper-layer device. Then, proceed to Step 7.

Step 8 Run the display board frameid/slotid command to check whether the state of the link
corresponding to the upstream port is online.
l If the state of the link corresponding to the upstream port is online, go to Step 10.
l If the link corresponding to the upstream port is not online, connect the upstream physical
link to ensure that the upstream channel is normal. Then, proceed to Step 9.

Step 10 Run the display pitp port frameid/slotid/portid config command to query the PITP mode of the
user port, run the display raio-mode command to query the RAIO working mode, and then
check whether the RAIO mode is the same as that configured on 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 not the same as that configured on the BRAS, modify the RAIO mode
to be the same as that configured on the BRAS. Run the raio-mode command to modify

Module
the configuration of the MA5600T/MA5603T, or modify the configuration on the BRAS.


Step 12 Run the display pppoe mac-mode command to query the MAC address allocation mode for
the PPPoE user.
l If the multi-mac mode is used, go to Step 15.
l If the single-mac mode is used, proceed to Step 13.
Step 13 Run the display pppoe max-session-count command to query the maximum number of PPPoE
sessions on the user port. According to usage, determine whether the number of the connected
sessions exceeds the maximum number of sessions on the port.
NOTE
If the number of the online PPPoE sessions is greater than the preset maximum number of PPPoE sessions,
the system does not disconnect sessions by force to decrease the number of sessions, but limits setup of
new sessions. In this case, certain users cannot go online.
l If the number of the connected sessions exceeds the maximum number of sessions on the
port, run the pppoe max-session-count command to increase the maximum number of
PPPoE sessions on the port. Then, proceed to Step 14.
l If the number of the connected sessions does not exceed the maximum number of sessions
on the port, go to Step 15.

Step 15 Run the display mac-address port frameid/slotid/portid command to query the number of the
MAC addresses learned by the user port currently, run the display mac-address max-mac-
count command to query the permitted maximum number of MAC addresses dynamically
learned by the user port, and then check whether the number of the MAC addresses learned by
the user port currently is the same as the permitted 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 the
permitted maximum number of MAC addresses dynamically learned by the user port, run
the mac-address max-mac-count service-port index command to increase the permitted
maximum number of MAC addresses dynamically learned by the user port. Then, proceed
to Step 16.
l If the number of the MAC addresses learned by the user port currently is different from the
permitted maximum number of MAC addresses dynamically learned by the user port, go
to Step 21.


Module
NOTE

drift exists.
NOTE


Step 21 Run the display security config command to check whether the anti-MAC-spoofing function
is enabled.
l If the anti-MAC-spoofing function is enabled, proceed to Step 22.
l If the anti-MAC-spoofing function is disabled, go to Step 24.
Step 22 Run the display mac-address static command to check whether the user traffic stream is
configured with a static MAC address.
NOTE
If the static MAC address is configured and the anti-MAC-spoofing function is enabled as well, the user
fails to go online.
l If the user traffic stream is configured with a static MAC address, according to the service
planning, run the security anti-macspoofing disable command to disable the anti-MAC-
spoofing function or run the undo mac-address static command to delete the static MAC
address configured for the user traffic stream. Then, proceed to Step 23.
l If the user traffic stream is not configured with a static MAC address, go to Step 24.


Module
Step 24 Run the display packet-filter port frameid/slotid/portid command to check whether the user
port is configured with the ACL rule.
l If the user port is configured with the ACL rule, proceed to Step 25.
l If the user port is not configured with the ACL rule, go to Step 27.
Step 25 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, proceed to Step 26.
l If the ACL rule does not limit the PPPoE packets, go to Step 27.

l If the service is not covered to normal, proceed to Step 27.
Step 27 Check whether the user data of the upper-layer BRAS is correct or whether the account of the
user is limited.
l If the user data of the upper-layer BRAS is not correct or the account of the user is limited,
modify the BRAS configuration, and then proceed to Step 28.
l If the user data of the upper-layer BRAS is correct and the account of the user is not limited,
go to Step 29.

----End

no IP address can be obtained in the DHCP mode. When the MA5600T/MA5603T functions as
the DSLAM and no IP address can be obtained in the DHCP mode, locate the fault according
Location Method
When no IP address can be obtained in the DHCP mode for the DSLAM user, locate the fault
1. Check the connectivity between the device and the modem.

3. Check the security feature configuration.
4. Check whether the MA5600T/MA5603T can communicate with the DHCP server.

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

l If the device cannot ping the modem, proceed to Step 2.
Step 2 Run the display port state portid command to check whether the port to which the user belongs
is activated (Status is Activated).
l If the port is activated, proceed to Step 4.
proceed to Step 3.

modem.
l If VPI and VCI of traffic streams are the same as VPI and VCI configured on the modem,
go to Step 6.

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

Module

l If the state of the link corresponding to the upstream port is online, go to Step 10.

Step 10 Run the display dhcp option82 config command to check whether the configuration of the
DHCP option82 function is the same as that configured on the DHCP server.
l If the configuration of the DHCP option82 function is the same as that configured on the
DHCP server, go to Step 12.
l If the configuration of the DHCP option82 function is not the same as that configured on
the DHCP server, modify the configurations to be the same, and then proceed to Step 11.

Step 12 Run the display bind xdsl frameid/slotid/portid vpi vpi vci vci command to check whether the
service channel is bound with the static IP address.
l If the service channel is bound with the static IP address, run the undo bind command to
cancel the binding. Then, proceed 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 is
incorrectly 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, proceed to
Step 15.
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 the
user traffic stream is the same as the static MAC address of other traffic streams.

Module
l If the static MAC address of the user traffic stream is the same as the static MAC address
of other traffic streams, run the undo mac-address static command to delete the static
MAC address of other traffic streams. Then, proceed to Step 17.
l If the static MAC address of the user traffic stream is different from the static MAC address
of other traffic streams, go to Step 18.

Step 18 Run the display security bind mac frameid/slotid/portid command to query the number of MAC
addresses bound with the traffic streams, run the display security anti-macspoofing max-mac-
count frameid/slotid/portid vpi vpi vci vci command to query the maximum number of MAC
addresses that can be bound with the traffic streams, and then check whether the number of MAC
addresses bound with the traffic streams is the same as the maximum number of MAC addresses
that can be bound with the traffic streams.
l If the number of MAC addresses bound with the traffic streams is the same as the maximum
number of MAC addresses that can be bound with the traffic streams, run the security anti-
macspoofing max-mac-count frameid/slotid/portid vpi vpi vci vci command to increase
the maximum number of MAC addresses that can be bound with the traffic streams. Then,
proceed to Step 19.
l If the number of MAC addresses bound with the traffic streams is different from the
maximum number of MAC addresses that can be bound with the traffic streams, go to Step
20.

Step 20 Run the display security bind mac command (do not type any parameter) to query information
about all the dynamically bound MAC addresses. Then, check whether the user MAC address
is bound to other traffic streams.
l If the user MAC address is bound to other traffic streams, it indicates that MAC spoofing
exists. In this case, check the fault and then troubleshoot it. Then, proceed to Step 21.
l If the user MAC address is not bound to other traffic streams, go to Step 22.

Step 22 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 31.
l If DHCP relay mode is layer-3, proceed to Step 23.
Step 23 Run the display interface vlanif command to check whether the upstream VLAN Layer 3
interface is in the UP state.
l If the upstream VLAN Layer 3 interface is in the UP state, go to Step 25.
l If the upstream VLAN Layer 3 interface is not in the UP state, check the configurations of
the upstream port connection and the upstream VLAN, and make sure that the Layer 3
interface is in the UP state. Then, proceed to Step 24.

Module

Step 25 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 31.
l If you cannot ping the IP address of the DHCP server, check the configuration of the router
connecting the MA5600T/MA5603T to the DHCP server and make sure that the MA5600T/
MA5603T can communicate with the DHCP server. Then, proceed to Step 26.
NOTE
drift exists.
NOTE


Module
----End
3.1.6 Failure to Obtain the IP Address in PPPoA Dialup

no IP address can be obtained in PPPoA dialup. When the MA5600T/MA5603T functions as
the DSLAM and no IP address can be obtained in PPPoA dialup, locate the fault according to
the following procedure.
Location Method
When no IP address can be obtained in PPPoA dialup for the DSLAM user, locate the fault
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 ensure that the VLAN is not a QinQ VLAN.
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 the PPPoA mode and whether the encapsulation
mode is the same as that configured on the modem.
CAUTION
Procedure
Step 1 Run the display pppoa config command to check whether the PPPoA to PPPoE conversion
function 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, proceed to Step 2.

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

Module
NOTE
l If MAC addresses: is the same as Addresses in use:, it indicates that MAC addresses are exhausted.
l The system supports a maximum of 20 MAC address pools, and a maximum of 1024 MAC addresses
can be configured.
l If the MAC address pool is not configured or MAC addresses in the MAC address pool are
exhausted, run the mac-pool command to configure the MAC address pool. Then, proceed
to Step 4.
l If the MAC address pool is configured and MAC addresses in the MAC address pool are
not exhausted, 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, proceed to Step 6.
l If the upstream VLAN is not a QinQ VLAN, go to Step 7.


l If the link corresponding to the upstream port is online, go to Step 11.

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


Module
proceed to Step 12.
modem.
l If the VPI and the VCI of traffic streams are the same as VPI and VCI configured on the
modem, go to Step 15.
Step 15 Run the display encapsulation frameid/slotid/portid command to check whether the PVC is
encapsulated in the PPPoA mode.
NOTE
In query results, ENCAP indicates the PVC encapsulation mode. The encapsulation mode corresponding
to PPPoA is vc_ppp or llc_ppp.
l If the PVC is encapsulated in the PPPoA mode, go to Step 17.
l If the PVC is not encapsulated in the PPPoA mode, run the encapsulation frameid/slotid/
portid command to set the PVC encapsulation mode to PPPoA. Then, proceed to Step
16.
Step 17 Check whether the encapsulation mode configured on the modem is the same as the query result
on the MA5600T/MA5603T.
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 MA5600T/MA5603T. Then,
proceed to Step 18.

Module
NOTE

drift exists.
NOTE


----End
3.1.7 Failure to Obtain the IP Address in IPoA Dialup

no IP address can be obtained in IPoA dialup. When the MA5600T/MA5603T functions as the
DSLAM and no IP address can be obtained in IPoA dialup, locate the fault according to the
following procedure.
Location Method
When no IP address can be obtained in IPoA dialup for the DSLAM user, locate the fault
1. Check whether the IPoA to IPoE conversion function is enabled.

Module
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 ensure that the VLAN is not a QinQ VLAN.
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.
CAUTION
Procedure
Step 1 Run the display ipoa config command to check whether the IPoA status.
l If IPoA is enabled, go to Step 3.
l If IPoA is disabled, run the ipoa enable command to enable IPoA. Then, proceed to Step
2.
NOTE
When IPoA is enabled, MA5600T/MA5603T enables the IPoA to IPoE conversion function.

Step 3 Run the display mac-pool all command to check whether the MAC address pool is configured
and whether MAC addresses in the MAC address pool are exhausted.
NOTE
l If MAC addresses: is the same as Addresses in use:, it indicates that MAC addresses are exhausted.
l The system supports a maximum of 20 MAC address pools, and a maximum of 1024 MAC addresses
can be configured.
l If the MAC address pool is not configured or MAC addresses in the MAC address pool are
exhausted, run the mac-pool command to configure the MAC address pool. Then, proceed
to Step 4.
l If the MAC address pool is configured and MAC addresses in the MAC address pool are
not exhausted, go to Step 5.


Module
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, proceed to Step 6.
l If the upstream VLAN is not a QinQ VLAN, go to Step 7.
l If the link corresponding to the upstream port is online, go to Step 11.
Step 11 In the xDSL mode, run the display port state portid command to check whether the port to
which the user belongs is activated (Status is Activated).
NOTE

proceed to Step 12.
modem.

Module
Step 15 Run the display encapsulation frameid/slotid/portid command to query the PVC encapsulation
mode.
NOTE
In query results, ENCAP indicates the PVC encapsulation mode. The encapsulation mode corresponding
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 address
configured on the modem, go to Step 17.
l If ENCAP is llc_ip, SRCIP is configured and SRCIP is not the same as the IP address
configured on the modem, modify SRCIP of the MA5600T/MA5603T to be the same as
the IP address configured on the modem, or modify the IP address configured on the modem
to be the same as SRCIP of the MA5600T/MA5603T. If SRCIP of the MA5600T/
MA5603T is modified, run the encapsulation command to configure new SRCIP. Then,
proceed to Step 16.
l If ENCAP is llc_ip, SRCIP is not configured and the modem reports the source IP address
using the InAtmArp protocol, go to Step 17.
l If ENCAP is llc_ip, SRCIP is not configured and the modem does not report the source
IP address using the InAtmArp protocol, run the encapsulation frameid/slotid/portid
command to configure the source IP address for the traffic streams and this IP address is
the same as the IP address configured on the modem. Then, proceed to Step 16.
l If ENCAP is vc_ip, SRCIP is configured and SRCIP is the same as the IP address
configured on the modem, go to Step 17.
l If ENCAP is vc_ip, SRCIP is configured and SRCIP is not the same as the IP address
configured on the modem, modify SRCIP of the MA5600T/MA5603T to be the same as
the IP address configured on the modem, or modify the IP address configured on the modem
to be the same as SRCIP of the MA5600T/MA5603T. If SRCIP of the MA5600T/
MA5603T is modified, run the encapsulation command to configure new SRCIP. Then,
proceed 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 address
is the same as the IP address configured on the modem. Then, proceed to Step 16.
l If ENCAP is auto and the encapsulation mode configured on the modem is llc, go to Step
17.
l If ENCAP is auto and the encapsulation mode configured on the modem is vc-mux, modify
the encapsulation mode to llc. Then, proceed to Step 16.
Step 17 Run the display encapsulation frameid/slotid/portid command to query the PVC encapsulation
mode and check whether the destination IP address (DSTIP) is configured.

Module
l If the destination IP address is configured, proceed to Step 18.

l If the destination IP address is not configured, go to Step 20.
Step 18 Check whether the destination IP address is valid.

NOTE
l If the upper-layer device connected to the upstream port and the MA5600T/MA5603T are in the same
network segment, the destination IP address is the IP address of the upper-layer device.
l If the upper-layer device connected to the upstream port and the MA5600T/MA5603T are in different
network segments, the destination IP address is the IP address of the upstream VLAN Layer 3 interface.
The IP address of the upstream VLAN Layer 3 interface and the IP address of the upper-layer device
must be 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, proceed to
Step 19.

l If the service does not recover to normal, go to Step 26.
Step 20 Run the display ipoa config command to check whether the valid default gateway is configured.
NOTE
l If the destination IP address of IPoA is not configured, the system uses the default gateway of IPoA as
the destination IP address. Therefore, the default gateway is generally configured as the same as the
destination IP address.
l If the upper-layer device connected to the upstream port and the MA5600T/MA5603T are in the same
network segment, the default gateway is the IP address of the upper-layer device.
l If the upper-layer device connected to the upstream port and the MA5600T/MA5603T are in different
network segments, the default gateway is the IP address of the upstream VLAN Layer 3 interface. The
IP address of the upstream VLAN Layer 3 interface and the IP address of the upper-layer device must
be 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, proceed to Step 21.

NOTE

Module

drift exists.
NOTE


----End
3.2 Troubleshooting the Multicast Service

This topic describes how to troubleshoot the faults in the multicast service when the MA5600T/
MA5603T functions as the DSLAM. The common faults in the multicast service include failure
to go online for a multicast user, dark screen after ordering a program, erratic display (mosaic)
in a multicast program, abnormal program interruption in watching a program, and long time in
switching programs.
3.2.1 Failure to Go Online for a Multicast User

This topic describes how to troubleshoot the fault when a multicast user (queried on the
MA5600T/MA5603T) fails to order any program because of the failure to go online. When the
MA5600T/MA5603T functions as the DSLAM and a multicast user fails to go online, locate
the fault according to the following procedure.
Location Method
When a DSLAM multicast user fails to go online, locate the fault according to the following
procedure:
1. Check whether the user is in the block state.


Module
3. Check whether the program ordered by the user exists.

4. Check whether the user has rights to order the program.
5. Check the bandwidth CAC function.
CAUTION
Procedure
Step 1 Run the display igmp user command to query the multicast user status.
l If the user is in the block state, it indicates that the user is blocked. In this case, run the
undo igmp user block command to unblock the user. Then, proceed to Step 2.
l If the user is in the offline state, go to Step 3.
NOTE
If you need to block a multicast user from watching a program but not to delete the user (such as a user
that is out of service), run the igmp user block command to block the user. When the user is blocked, the
MA5600T/MA5603T forces the user to go offline from the watching program. In addition, the MA5600T/
MA5603T rejects the user from ordering a program until the user is blocked.
Step 2 Order a program again and check whether the user can go online.
l If the user fails to go online, proceed to Step 3.
Step 3 Run the display port state portid command to check whether the multicast port is activated.
l If the port is not activated, proceed to Step 4.
Step 4 Run the activate portid command to activate the user port. Then, check whether the multicast
port is activated.
l If the port is not activated, proceed to Step 5.
Step 5 Proceed according to the specific symptom of the fault.
l If the multicast user goes online first and then goes offline, you need to check the modem
and the physical line.
1. Check the status of the LED on the modem. If the LED indicates that the modem is
abnormal, replace the modem with a normal modem. If the LED indicates that the
modem is in the normal state, it indicates that the fault is not caused by the modem.
2. Connect the modem to the CO equipment, to the MDF, and to the MA5600T/
MA5603T, and perform tests accordingly to locate the fault on the line section by
section. Then, proceed to Step 6.
l If the multicast user fails to go online from the beginning and the corresponding port fails
to be activated, you need not only need to check the modem and the physical line to locate
the fault using the above-mentioned methods, but also need to check the MA5600T/
MA5603T data configuration. You can refer to the configuration of other normal ports and

Module
bind an appropriate line profile to the faulty port. For details, see 6.8 Changing the Line
Profile (Template) of an xDSL Port. Then, proceed to Step 6.
Step 6 Order a program again and check whether the user can go online.
l If the user fails to go online, proceed to Step 7.
Step 7 Run the display igmp program all command to query the multicast program list. Check whether
the MVLAN of the user contains the program ordered by the user.
l If the MVLAN contains the program, go to Step 9.
l If the MVLAN does not contain the program, proceed to Step 8.
Step 8 Order a program that exists in the MVLAN again and check whether the program can be watched.
l If the program can be watched, notify the user that this program needs to be bought. Then,
go to Step 14.
l If the program cannot be watched, proceed to Step 9.
Step 9 Check whether the user has rights to order the program.
1. Run the display igmp user service-port 100 command to query the right (authority) profile
bound to the user (assume that the ID of the service port for the multicast user is 100).
l When Bind profiles is -, it indicates that authentication is not required and the user can
order all programs in the MVLAN. Go to Step 11.
l When Bind profiles is 0, it indicates that the user is not bound to any right profile and
cannot order any program. Proceed to Step 9.2
l When Bind profiles is larger than or equal to 1, it indicates that the user can order only
the permitted multicast program. You can see the index and name of the program right
profile bound to the user at the end of the query result. Go to Step 9.3
2. Run the igmp user bind-profile service-port 100 profile-index-list 1 command to bind
a proper right profile to the user according to multicast service planning (assume that the
ID of the service port for the user is 100 and the index of the program right profile to be
bound is 1). Proceed to Step 9.3.
3. Run the display igmp profile profile-index 1 command to query the multicast right profile
bound to the user (assume that the index of the program right profile bound to the user is
1).
l When the right of the ordered program for the user is watch or preview, it indicates
that the user can order this program. Go to Step 11.
l When the right of the ordered program for the user is forbidden or idle, it indicates that
the user does not have the right to order this program. Proceed to Step 10.
NOTE
There are four types of program rights: forbidden, preview, watch, and idle. When a user is bound
to multiple profiles and the program rights in the profiles are different, the final program right of the
user is determined by the right with the highest priority. By default, the priority of the program rights
is forbidden > preview > watch > idle. You can run the igmp right-priority command to set the
priority.
Step 10 Order the program with the watch or preview right for the user and check whether the program
can be watched.
l If the program can be watched, notify the user that this program needs to be bought. Then,
go to Step 14.

Module
Step 11 Check the bandwidth CAC function.

1. Run the following commands to enable the monitoring function of the multicast user.
huawei(config)#debugging igmp all
2. Order a program again.

3. After commands are printed, run the following commands to disable the debugging
function.
4. Check the debugging information on the CLI.

l If "Warning: the user fails to pass bandwidth CAC" is displayed and the user can use
only the current bandwidth according to the service requirement, notify the user to order
the program with low traffic. Then, go to Step 14.
l If "Warning: the user fails to pass bandwidth CAC" is displayed and more bandwidth
can be allocated to the user according to the service requirement, run the igmp user
modify service-port 100 max-bandwidth 5000 command to increase the bandwidth
allocated to the user (assume that the ID of the service port for the multicast user is 100
and the maximum bandwidth is increased to 5000 kbit/s). Then, proceed to Step 12.
l If the preceding information is not displayed, go to Step 13.
Step 12 Order a program again and check whether the program can be watched.
l If the program can be watched, go to Step 14.
----End
3.2.2 Dark Screen After Ordering a Program

This topic describes how to troubleshoot the fault when a dark screen is displayed after the user
orders a program. When the MA5600T/MA5603T functions as the DSLAM and a dark screen
is displayed after the user orders a program, locate the fault according to the following procedure.
Location Method
When a dark screen is displayed after a DSLAM multicast user goes online and orders a program,
locate the fault according to the following procedure:
1. Check whether multicast streams are transmitted to the upstream port of 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 multicast upstream port is added to the MVLAN of the multicast user.
5. Check multicast program configurations.

Module
CAUTION
Procedure
Step 1 Run the display igmp user port frameid/slotid/portid command to check whether the faulty
user is online (whether State is online).
l If the user is online, proceed to Step 2.
l If the user is not online, see 3.2.1 Failure to Go Online for a Multicast User to rectify
the fault. Then, go to Step 14.
Step 2 Run the display multicast flow-statistic vlan 10 ip 224.1.1.2 command to query the statistics
for the traffic of the ordered program on the upstream port. Check whether the stream of the
ordered program is transmitted to the upstream port (assume that the MVLAN ID is 10 and the
IP address of the multicast program is 224.1.1.2).
l If the queried program traffic is correct, it indicates that the stream of the ordered program
reaches the upstream port. Then, proceed to Step 3.
l If the queried program traffic is incorrect, it indicates that a fault occurs before the program
stream is forwarded from the multicast server to the upstream port. Then, go to Step 8.
Step 3 Run the display traffic frameid/slotid/portid command to query the Tx traffic (Tx Traffic) of
the port to which the multicast user is connected.
NOTE
You can use this operation to check whether the multicast stream is forwarded normally from the upstream
port of the MA5600T/MA5603T to the DSL user port. In the normal state, the Tx traffic must be close to
the multicast traffic.
l If the Tx traffic is normal, proceed to Step 4.
l If the Tx traffic is abnormal, go to Step 5.
Step 4 Check the configurations of the modem and the terminal and rectify the fault. Order a program
again and check whether the program can be watched normally.
l If the program can be watched normally, go to Step 14.
l If the program cannot be watched normally, go to Step 13.
Step 5 Run the display board frameid/slotid command to query the status of the faulty user port.
l If the port is in the activated state, go to Step 13.
l The port is in the deactivated state, proceed to Step 6.
Step 6 Query the historical alarms, historical events, and operation logs of the system and find out the
cause for the port deactivation.
1. Run the display alarm history all command to query the historical alarms of the system.
2. Run the display event history all command to query the historical events of the system.
3. Run the display log command to query the operation logs.
l If you can find the ring network alarm or event in the query, it indicates that the ring network
generated on the user side leads to deactivation of the faulty user port. Eliminate the ring
network and activate the user port again. Then, proceed to Step 7.

Module
l If you can find the deactivation alarm and event, or the operation log of manually
deactivating the port in the query, find out the deactivation cause based on the prompt of
the alarm and event and ensure that the user port is in the activated state. Then, proceed to
Step 7.
Step 7 Order a program again and check whether the program can be watched normally.
l If the program cannot be watched normally, go to Step 13.
Step 8 Check the configuration of the multicast upstream port.

1. Run the display igmp uplink-port all command to query the upstream port corresponding
to the MVLAN of the ordered program.
2. Run the display port vlan frameid/slotid/portid command to check whether the VLANs
of the upstream port contain the MVLAN of the ordered program.
l If the VLANs of the upstream port contain the MVLAN, go to Step 10.
l If the VLANs of the upstream port do not contain the MVLAN, run the port vlan
command to add the upstream port to the MVLAN. Then, proceed to Step 9.
NOTE
The multicast packet that carries this MVLAN tag can be forwarded through the upstream port only
when the VLANs of the multicast upstream port contain the MVLAN. Otherwise, the packet is
discarded. Assume that the MVLAN ID is 10 and the ID of the multicast upstream port is 0/19/0, run
the following configuration commands:
l In the MVLAN mode, run the igmp uplink-port 0/19/0 command to set port 0/19/0 as the
upstream port of MVLAN 10.
l In the global config mode, run the port vlan 10 0/19 0 command to add MVLAN 10 to the
VLANs of port 0/19/0.
l If the program cannot be watched normally, proceed to Step 10.
Step 10 Run the display igmp program name command to check whether the multicast program is
configured as prejoin.
l If the multicast program is configured as prejoin, proceed to Step 11.
l If the multicast program is not configured as prejoin, go to Step 12.
Step 11 Run the igmp program modify name cctv1 prejoin disable command to disable the prejoin
function of the multicast program (taking program cctv1 as an example). Order a program again
and check whether the program can be watched normally.
NOTE
If the service recovers to normal, you can enable the prejoin function of the program.
Step 12 Find out the cause for the fault that the upper-layer device receives the IGMP packet but does
not issue the program stream, and rectify the fault. Order a program again and check whether
the program can be watched normally.

Module
----End
3.2.3 Erratic Display (Mosaic) in a Multicast Program

This topic describes how to troubleshoot the fault when a user is online and orders a program
but the quality of the program is poor, for example, erratic display (mosaic) occurs. When the
MA5600T/MA5603T functions as the DSLAM and erratic display occurs in the multicast
program, locate the fault according to the following procedure.
Location Method
When erratic display occurs in the multicast program for a DSLAM multicast user, locate the
1. Check whether the limited rate configured in the traffic profile meets the requirement on
the user bandwidth for ordering the program.
2. Check whether the line activation rate meets the requirement on the user bandwidth for
CAUTION
Procedure
Step 1 Check whether the limited rate configured in the traffic profile meets the requirement on the
user bandwidth for ordering the program.
1. Run the display service-port port command to query the index of the RX traffic bound to
the traffic stream of the multicast service.
2. Run the display traffic table ip from-index 0 command to query the PIR of the traffic
profile bound to the traffic stream of the multicast service.
3. Compare the PIR with the user bandwidth for ordering the program.
l If the PIR is off, higher than, or equal to the user bandwidth for ordering the program,
it indicates that the rate of the bound traffic profile is sufficient and is not the cause of
the problem. Then, go to Step 3.
l If the PIR is lower than the user bandwidth for ordering the program, it indicates that
the rate of the bound traffic profile is excessively low.
– If proper traffic profiles exist in the system, run the service-port 100 outbound
traffic-table index 6 command to bound the traffic stream of the multicast service
to a more proper traffic profile (assume that the index for the traffic stream of the
multicast service is 100 and the index of the traffic profile to be bound is 6). Then,
proceed to Step 2.

Module
– If no traffic profile in the current system meets the requirement, run the traffic table
ip command to add a proper traffic profile, and bind the traffic profile to the traffic
stream of the multicast service. Then, proceed to Step 2.
NOTE
The requirements on the port bandwidth of common programs and high-definition programs are different
and are determined by the programs of suppliers.
l Normally, the rate for common programs is lower than 5 Mbit/s. You can use IP traffic profile 6 (default
profile of the system) for common programs.
l Generally, the traffic for high-definition programs is high. For example, the rate of some high-definition
programs is higher than 12 Mbit/s. In this case, you need to add a new traffic profile according to actual
conditions to limit the rate, or use IP traffic profile 6 (default profile of the system).
Step 3 Check whether the actual downstream line rate of the xDSL port meets the requirement on the
user bandwidth for ordering the program.
1. Check the actual downstream line rate of the xDSL port.
NOTE
l In the case of ADSL2+ access users, in the ADSL mode, run the display line operation command
to query the actual downstream line rate (actual line rate downstream) of the modem.
l In the case of VDSL2 access users, in the VDSL mode, run the display line operation command
to check the actual downstream line rate (actual line rate downstream) of the modem.
2. Compare the actual downstream line rate with the user bandwidth for ordering the program.
l If the actual downstream line rate is higher than or equal to the user bandwidth for
ordering the program, it indicates that the line rate is sufficient and is not the cause of
the problem. Then, go to Step 5.
l If the actual downstream line rate is lower than the user bandwidth for ordering the
program, proceed to Step 3.3
3. Perform the corresponding operation according to the circumstances of erratic display for
multicast programs.
l If the multicast program is normal at the beginning and erratic display occasionally
occurs later on, it indicates the line quality is poor or certain interference sources exist.
Locate the fault section by section by connecting the modem to the CO end, to the MDF,
and to the subscriber line at the subscriber home and performing tests. You also need
to consider the interference that may exist on the line, such as the electric field and the
magnetic field. Then, proceed to Step 4.
l If the multicast program is abnormal at the beginning and erratic display occurs all the
time, it indicates that the data configuration is not proper. Change the line profile and
bind the port to a more proper line profile to improve the line rate. Then, proceed to
Step 4.

Module
----End
3.2.4 Abnormal Program Interruption in Watching a Multicast

Program
This topic describes how to troubleshoot the fault when a multicast user is watching a program
but the program is abnormally interrupted. When the fault of abnormal multicast program
interruption occurs in the case that the MA5600T/MA5603T functions as the DSLAM, locate
the fault according to the following procedure.
Location Method
When the abnormal multicast program interruption occurs on a DSLAM, generally locate the
fault from upper-layer devices to lower-layer devices, that is, in the sequence of multicast server
-> MA5600T/MA5603T -> user terminal from segment to segment. The following table lists
the NEs that may cause this fault and the possible causes.
Multicast server The multicast source is abnormal.

The network between the MA5600T/
MA5603T and the multicast server is faulty.
MA5600T/MA5603T The line from the MA5600T/MA5603T to the

user terminal is faulty.
The watching duration of the user reaches the
preview duration.
User terminal The modem or set-top box (STB) is faulty.
CAUTION
Procedure
Step 1 Check the multicast source of the multicast server and the network from the MA5600T/
MA5603T to the multicast server.
1. On the multicast server, check whether the multicast source is faulty.
l If the multicast source is faulty, replace the multicast source and proceed to Step 1.2.
l If the multicast source is normal, go to Step 1.3.
2. Order a program again and check whether the user can watch the program normally.
l If the user can watch the program normally, go to Step 6.
l If the user cannot watch the program normally, proceed to Step 1.3.

Module
3. Ping the IP address of the MA5600T/MA5603T upstream port from the multicast server
and check whether the ping operation is successful.
l If the ping operation is successful, go to Step 2.
l If the ping operation fails, it indicates that the fault is not caused by the network fault
between the MA5600T/MA5603T and the multicast server. Then, proceed to Step
1.4.
l If the user cannot watch the program normally, proceed to Step 2.
Step 2 check MA5600T/MA5603T.
1. Run the display board frameid/slotid command to query the status of the faulty port.
l If the port is in the activated state, go to Step 2.4.
l If the port is in the deactivated state, proceed to Step 2.2.
2. Query the historical alarms, historical events, and operation logs of the system and find out
the cause for port deactivation.
a. Run the display alarm history all command to query the historical alarms of the
system.
b. Run the display event history all command to query the historical events of the
system.
c. Run the display log command to query the operation logs.
l If you find any ring network alarm or event in the query, it indicates that the ring network
generated on the user side leads to deactivation of the faulty user port. Eliminate the
ring network, and activate the user port. Then, proceed to Step 2.3.
l If you find any deactivation alarm and event, or the operation log of manually
deactivating the port in the query, find out the deactivation cause based on the prompt
of the alarm and event and ensure that the user port is in the activated state. Then, proceed
to Step 2.3.
l If the user cannot watch the program normally, proceed to Step 2.4.
4. Run the display igmp user service-port 100 command to query the right profile bound to
the multicast user (assume that the service port of the multicast user is 100). In the BTV
mode of the ONU, run the display igmp profile profile-index 1 command to query the
information about the right profile bound to the user (assume that the index of the right
profile is 1).
l If the right of the user is watch, it indicates that the user has the right to watch the
program. Then, proceed to Step 3.
l If the right of the user is preview, it indicates that the user has the right to preview the
program. If the preview duration of a user reaches the maximum preview duration, the
system suspends the program and notifies the user of a normal interruption. Then, go
to Step 6.

Module
NOTE
There are four types of program rights: forbidden, preview, watch, and idle. When a user is bound
to multiple right profiles that are configured with different rights to a same program, the right with
the highest priority prevails. By default, the priority order of the program rights is forbidden > preview
> watch > idle. You can run the igmp right-priority command to set the priority.

1. Check the LED status of the STB. If the LED of the Ethernet port on the STB connected
to the modem blinks quickly, the STB decoding may be incorrect. In this case, reset or
replace the STB.
2. Check the LED of the Ethernet port on the modem connected to the STB. Then, reset or
replace the modem.
3. After the preceding operations, order a program again and check whether the user can watch
the program normally.
l If the user cannot watch the program normally, proceed to Step 4.
Step 4 Perform the following operations to collect the relevant information.

1. Enable the function of monitoring a multicast user.
2. Order a program again.

3. When the information is displayed on the CLI, run the following commands to disable the
debugging function.
4. Proceed to Step 5.
----End
3.2.5 Long Time in Switching Programs

This topic describes how to troubleshoot the fault of long time in switching programs. That is,
when a user switches the current program to another program, it takes a very long time; however,
the programs can be switched and the new program can be watched. When the MA5600T/
MA5603T functions as the DSLAM and the fault of long time in switching programs occurs,
locate the fault according to the following procedure.
Location Method
When the fault of long time in switching programs for a DSLAM multicast user occurs, locate
the fault according to the following procedure:
Check whether the quick leave attribute of the multicast user is correct.

Module
CAUTION
Procedure
Step 1 Run the display igmp user port command to query the quick leave configuration of the user.
In query results, Quick leave indicates the quick leave attribute of a multicast user. It has the
following three modes:
l disable: The quick leave attribute is disabled. When a multicast user is not configured with
this attribute, the system sends the group-specific query packet after receiving the leave
packet from the user. If the system does not receive the Report packet from the multicast
user within the preset aging time, it considers that the multicast user has left.
l immediate: When the user is configured with the quick leave attribute of the immediate
mode, 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 is
connected to multiple STBs, a temporary black screen may occur if a user is offline.
l mac-based: indicates the quick offline based on the MAC address. If a user terminal is
connected to multiple STBs, when the system receives the leave packet from the user, it
determines whether the packet is sent from the last STB. If the packet is sent from the last
STB, the system forces the user to go offline. Otherwise, the user is still online. This avoids
the weak points of immediate.
Check whether the quick leave attribute of the user is correct according to the preceding three
modes.
l If the quick leave attribute is correct, go to Step 3.

l If the quick leave attribute is incorrect, proceed to Step 2.
Step 2 Run the igmp user modify port frameid/slotid/portid quickleave command to change the quick
leave attribute of the user. Then, order a program again and check whether the time in switching
programs is normal.
l If the time in switching programs is normal, go to Step 5.
l If the time in switching programs is abnormal, proceed to Step 3.
Step 3 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 commands are printed, run the following commands to disable the debugging
function.
4. Proceed to Step 4.

Module
----End

Module
Troubleshooting 4 Troubleshooting the System
4 Troubleshooting the System
About This Chapter
This topic describes how to troubleshoot common faults in the MA5600T/MA5603T system,
including the following faults: NMS fails to manage a device, service board is in the failed state,
service board resets repeatedly, control board resets caused by abnormalities, and fan is in the
fault state.
4.1 NMS Fails to Manage a Device

This topic describes how to troubleshoot the fault when the NMS fails to manage the MA5600T/
MA5603T.
4.2 Service Board Is in the Failed State
This topic describes how to troubleshoot the fault through the CLI when the service board of
the MA5600T/MA5603T is in the failed state.
4.3 Service Board Resets Repeatedly
the MA5600T/MA5603T resets repeatedly.
4.4 Control Board Resets Caused by Abnormalities
This topic describes how to troubleshoot the fault through the CLI when the control board of

Module
4.1 NMS Fails to Manage a Device

This topic describes how to troubleshoot the fault when the NMS fails to manage the MA5600T/
MA5603T.
Location Method
When the NMS fails to manage the MA5600T/MA5603T, locate the fault according to the
1. Check the fault scope.
2. Check whether the MA5600T/MA5603T can ping the NMS.
3. Check whether configurations of the MA5600T/MA5603T and the NMS are correct.
4. Check whether the IP address of the MA5600T/MA5603T is the same as that configured
on the NMS.
CAUTION
Procedure
Step 1 Check whether the same NMS fails to manage other devices, that is, whether the fault occurs in
a large scale.
l If the same NMS fails to manage other devices, proceed 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 a matched NMS version. Then,
proceed to Step 3.
Step 4 Run the ping command to ping the NMS.
l If the device can ping the NMS, go to Step 8.
l If the device cannot ping the NMS, proceed to Step 5.
Step 5 Run the display ip routing-table command to check whether there is a route from the device
to the NMS server.
l If there is a route from the device to the NMS server, check the upstream link to ensure that
the device can communicate with the NMS. Then, go to Step 7.
l If there is not a route from the device to the NMS server, run the ip route-static command
to add a static route to the NMS server. Then, proceed to Step 6.

Module

l If there is not a route from the device to the NMS server, check the upstream link to ensure
that the device can communicate with the NMS. Then, proceed to Step 7.
Step 8 Check configurations of the MA5600T/MA5603T and the NMS. Make sure that configurations
are correct. Then, check whether the fault is rectified.
NOTE
The following configurations need to be checked.

l Run the display snmp-agent community read command to check whether the read community name
of the device is the same as that of the NMS. If they are inconsistent, run the snmp-agent community
read command to modify the read community name of the device to be the same as that of the NMS.
l Run the display snmp-agent community write command to check whether the write community name
of the device is the same as that of the NMS. If they are inconsistent, run the snmp-agent community
write command to modify the write community name of the device to be the same as that of the NMS.
l Run the display snmp-agent target-host command to check whether the IP address of the NMS server
is included in the target host list for traps. If the IP address of the NMS server is not included in the
target host list for traps, run the snmp-agent target-host command to add the NMS server to the target
host list for traps.
l Run the display snmp-agent trap enable command to check whether traps can be sent to the NMS
from the device. If it is disable, run the snmp-agent trap enable command to enable trap sending from
the device to the NMS.
Step 9 Run the display interface interface-type interface-number command to query the IP address of
the port communicating with the NMS. Then, check whether the IP address of the MA5600T/
MA5603T is the same as that configured on the NMS.
l If the MA5600T/MA5603T is the same as that configured on the NMS, go to Step 11.
l If the MA5600T/MA5603T is different from that configured on the NMS, in the VLAN
interface mode or the MEth mode, run the undo ip address command to delete the incorrect
IP address and then run the ip address command to re-configure the IP address to enable
the IP address of the MA5600T/MA5603T to be the same as that configured on the NMS.
l If the fault persists, process to Step 11.
----End

Module
4.2 Service Board Is in the Failed State

the MA5600T/MA5603T is in the failed state.
Location Method
When the service board of the MA5600T/MA5603T is in the failed state, locate the fault
1. Check whether the type of the actual used service board is the same as that configured on
the system.
2. Check whether the service board is firmly inserted.
3. Check whether the power supply of the cabinet is normal.
4. Replace the original service board with a new service board and then check whether the
new service board can start normally.
CAUTION
When you remove and insert a service board, antistatic measures must be taken.
Procedure
Step 1 Run the display board frameid/slotid command to query the name of the faulty board, check
the type of the actual board inserted in the subrack, and check whether their types are the same.
l If their types are the same, go to Step 4.
l If their types are different, proceed to Step 2.
Step 2 If it is confirmed that system configurations are correct, insert a board of the correct type into
the slot and then proceed to the next step. If it is confirmed that system configurations are
incorrect, run the board delete command to delete the original configurations, after the system
displays a message indicating that the board is auto discovered, run the board confirm command
to confirm the board and then proceed to the next step.
Step 3 Wait five minutes and then check whether the fault is rectified.
Step 4 Check whether the service board is firmly inserted.

l If the service board is firmly inserted, go to Step 6.
l If the service board is not firmly inserted, remove and insert the service board, and ensure
that the service board is firmly inserted. Then, proceed to Step 5.


Module
Step 6 Check whether the power supply of the cabinet is normal.

l If the power supply of the cabinet is normal, go to Step 8.
l If the power supply of the cabinet is abnormal, check the device supplying power and enable
this device to supply power in the normal state. Then, proceed to Step 7.

Step 8 Replace the original service board, and then check whether the new service board can start
normally.
l If the new service board can start normally, it indicates that service board is faulty. In this
case, replace the original service board with a new one. Then, go to Step 11.
l If the new service board cannot start normally, proceed to Step 9.
Step 9 In the diagnosis mode, run the display reset-record command.
----End
4.3 Service Board Resets Repeatedly

Location Method
When the service board of the MA5600T/MA5603T resets repeatedly, locate the fault according
1. Check major alarms and events.

2. Check whether the board packet file was omitted during the upgrade or patch installation
procedure.
3. Check whether the backplane of the subrack is normal.
CAUTION
Take ESD measures when you remove and insert a service board.

Module
Procedure
Step 1 Run the display alarm history all command to query the historical alarms and then run the
display event history all command to query the historical events. Check whether the alarms or
events related to the fault are generated.
l If such alarms or events are generated, clear these alarms or events to rectify the fault
according to the relevant guide. Then, proceed to Step 2
l If such alarms or events are not generated, go to Step 5
NOTE
The related alarms or events include the following:

l 0x02300082 The type of the board do not match
l 0x02310000 The communication between the board and the control board fails
l 0x02310018 The board hardware is abnormal
l 0x15411201 The temperature is out of the normal range by analog parameter monitor
l 0x1541a024 The fan is blocked and therefore stops rotation
l 0x0241a00d The ambient temperature for the board is too high
l Alarms related to voltage and current

Step 3 Run the display io-packetfile information command to query the version of the board software
packet file. Check whether the version of the board is the same as that describe in the board
version chapter of the Release Notes.
l If the version is the same, go to Step 5
l If the version is not the same, load the board packet file according to the Upgrade Guide
or Patch Installation Guide. Then, proceed to Step 4
Step 5 Insert the faulty service board to another normal slot and check whether the board can start
normally without reset.
l If the board can start normally without reset, proceed to Step 6.
l If the board can start normally but resets, it indicates that service board is faulty. In this
case, replace the original service board with a new one. Then, go to Step 9.
Step 6 Insert a normal service board in another slot to the slot that houses the faulty board, and check
whether the board can start normally without reset.
l If the board can start normally without reset, proceed to Step 7.
l If the board can start normally but resets, it indicates that the backplane of the subrack is
faulty. Use the board in other normal slots to recover the service. Then, proceed to Step
7.
Step 7 In the diagnose mode, run the display reset-record commands.

Module
----End
4.4 Control Board Resets Caused by Abnormalities

This topic describes how to troubleshoot the fault through the CLI when the control board of
Location Method
When the control board of the MA5600T/MA5603T resets repeatedly, locate the fault according
1. Check whether the control board recovers to the normal state after resetting.
2. Check whether the reset is caused by manual operations.
3. Check whether the temperature of the cabinet is very high.
4. Check whether the power supply of the cabinet is normal.
5. Check whether protection switchover occurs because optical fibers or network cables of
the upstream port are loose or are not connected.
6. Check whether the port connecting the upper-layer device to the MA5600T/MA5603T
works normally.
CAUTION
Abnormal reset of the control board adversely affects a lot. Therefore, when a fault occurs,
recover the service according to the pre-defined contingency method. Then, follow the guidance
described in this document for troubleshooting in the first place.
Procedure
Step 1 After the control board resets, check whether the RUN LED on the panel is 1s on and 1s off
repeatedly.
l If the panel is 1s on and 1s off repeatedly, proceed to Step 2.
l If the panel is not 1s on and 1s off repeatedly, go to Step 11.
Step 2 Run the display log all command to check whether the control board resets because of manually
delivered command.
l If the control board resets because of manually delivered command, go to Step 12.
l If the control board resets due to other causes, proceed to Step 3.
Step 3 Check whether fans are normal.
If fans are faulty, the temperature of the cabinet is very high. In this case, the control board resets
abnormally.
l If fans are normal, go to Step 5.

Module
l If fans are faulty, troubleshoot the fault. Then, proceed to Step 4.

Step 4 Check whether the control board resets by the abnormality.
l If the control board resets by the abnormality, proceed to Step 5.
l If the control board does not reset, go to Step 12.
Step 5 Check whether the power supply of the cabinet is normal.
l If the power supply of the cabinet is normal, go to Step 7.
l If the power supply of the cabinet is abnormal, check the device supplying power and enable
this device to supply power in the normal state. Then, proceed to Step 6.
Step 7 Check whether optical fibers or network cables of the upstream port are loose or are not
connected.
l If optical fibers or network cables of the upstream port are loose or are not connected,
connect fibers or cables again to ensure firm connection. Then, proceed to Step 8.
l If optical fibers or network cables of the upstream port are firmly connected, go to Step
9.
Step 9 Check whether the port connecting the upper-layer device to the MA5600T/MA5603T works
normally.
l If the port works normally, go to Step 11.
l If the port works abnormally, troubleshoot the port fault of the upper-layer device. Then
proceed to Step 10.
----End

Module
Troubleshooting 5 Emergency Handling
5 Emergency Handling
About This Chapter
If an emergency occurs, use the pre-defined emergency handling methods to recover services
quickly and then locate and rectify faults by referring to guidance provided in this document.
5.1 Precautions for Emergency Handling

When pre-defining emergency handling methods or carrying out emergency handling, abide by
the following precautions.
5.2 Troubleshooting Common Emergencies
Services are recovered after an emergency is handled according to the emergency handling
methods. After this, locate and rectify the faults. The following provides guidance on handling
several common emergencies as examples. These examples help you be familiar with the ideas
for handling emergencies.

Module
5.1 Precautions for Emergency Handling

When pre-defining emergency handling methods or carrying out emergency handling, abide by
the following precautions.
An emergency is hazardous and causes grave consequences. To improve emergency handling

efficiency and minimize costs incurred, you need to abide by the following when handling an
emergency:
l In case of emergency handling, the fast service recovery and the normal running of the
device are prioritized. Therefore, to improve emergency handling, see this document as
guidance and according to carriers' actual conditions, pre-define various emergency
handling methods (such as, restarting the system, performing the active/standby
switchover, backing up and restoring the database and configuration file, and cutting over
all services to the protection service network). In addition, periodically (once in a quarter
is recommended) organize to learn and practice emergency handling.
l Before reporting on duty, emergency handling personnel must have taken the required
training and have possessed skills in 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 the service level agreement (SLA) with Huawei, contact Huawei for
assistance by referring to 1.4 Contacting Huawei for Assistance at the earliest time in
case of an emergency.
l In case of an emergency, maintenance engineers must keep their composure and perform
operations according to the pre-defined emergency handling methods (that is, locate the
faulty parts or modules first and then recover services). Note: Do not restart the system
directly without any fault locating.
5.2 Troubleshooting Common Emergencies

Services are recovered after an emergency is handled according to the emergency handling
methods. After this, locate and rectify the faults. The following provides guidance on handling
several common emergencies as examples. These examples help you be familiar with the ideas
for handling emergencies.
5.2.1 Service Interruption Encountered by All the Users of a Single

Device
This topic describes how to troubleshoot the fault when all the users of a single MA5600T/
MA5603T encounter service interruption.
Procedure
Step 1 Check whether the power supply is normal.
If the LEDs of all the boards are off, it indicates that the power input or the power supply itself
has problems. Take relevant measures to handle these problems.

Module
If it is confirmed that the power supply is normal but the LEDs of all the boards are still off,
contact 1.4 Contacting Huawei for Assistance.
Step 2 Check whether the control board is normal.

Observe the running status LED on the front panel. If the LED is on for 1s and off for 1s
repeatedly, it indicates that the control board is normal; otherwise, the control board is faulty
and it needs to be replaced.
Step 3 Check whether the link status of the upstream port is online.
Step 4 Check the configuration of the upper-layer BRAS or router.
If multiple MA5600T/MA5603Ts (including the device where the fault occurs) are connected
to the upper-layer BRAS or router and other devices are in the normal state, check the
configuration of the BRAS or router and the configuration of the port of the faulty MA5600T/
MA5603T, such as the configuration of the VLAN transparent transmission and the route
configuration.
Step 5 Check the interfaces of the connected transmission device.
If an upper-layer transmission device is cascaded with multiple MA5600T/MA5603Ts

(including the device where the fault occurs) and other devices are in the normal state, check
the data configuration of the transmission device, and the data configuration of the interface of
the faulty device.
Step 6 Confirm the history operations.

1. Check the operations carried out on the MA5600T/MA5603T before and after the fault
occurs.
l Check whether any maintenance engineers have operated the MA5600T/MA5603T
before the fault occurs, and whether any alarms are generated on the maintenance
terminal during the operations.
l Whether maintenance engineers operate the device after the fault occurs. If maintenance
engineers operate the device after the fault occurs, obtain the impacts of such operations.
For the MA5600T/MA5603T, it is recommended that you run the display log all command
to collect all the log information.
NOTE
l In the MA5600T/MA5603T host system, the logs are stored in the static random access memory
(SRAM). Therefore, the logs still exist even if the system is reset or powered off.
l The maximum number of logs that can be stored is 512. If the number exceeds 512, the earliest
logs are overwritten. Therefore, record the logs immediately after a fault occurs on the system
to prevent loss of any useful information.
l It is recommended that you use an NMS or a log server to record logs because the number of
logs that can be recorded on the MA5600T/MA5603T is limited by the memory.
2. Check whether the maintenance personnel operate the upstream and downstream devices
before and after the fault.
3. Check whether any construction is carried out in the local or remote telecommunications
room. Focus on the routing of optical fibers and network cables during the construction.
Check whether the construction affects the original optical fibers and network cables.
Step 7 Check the service configuration.
For detailed operations, see the chapters therein for the troubleshooting of services and functions.

Module
Step 8 If the fault cannot be rectified by performing the preceding steps, fill in "Form for reporting a
fault" and then contact Huawei for technical support.
----End
5.2.2 Service Interruption Encountered by All the Users of Multiple

Devices Under the Upper-Layer BRAS or Router
This topic describes how to troubleshoot the fault when all the users of multiple MA5600T/
MA5603Ts under the upper-layer BRAS or router encounter service interruption.
Procedure
Step 1 Contact the BRAS/router maintenance engineers to check whether the interface between the
BRAS/router and the MA5600T/MA5603T is normal.
Step 2 Contact the BRAS/router maintenance engineers to check whether the data configurations of
the BRAS/router are correct.
Step 3 Contact the engineers in charge of maintaining the transmission devices to check whether the
transmission devices are interconnected correctly with the access network devices.
Step 4 Compare the faulty device and the normal device of the same level, and find differences to
determine whether the fault is caused by these differences.
Step 5 Check whether the service configurations of the MA5600T/MA5603T are correct.
For example, check the following for the multicast service:
l Whether the video service is configured correctly.

l Check whether the TTL value of a program is large enough. Ensure that the maximum value
is greater than the number of hops from the server to the user.
----End
5.2.3 Service Interruption Encountered by All the Users of All

Devices Under the Upper-Layer BRAS or Router
This topic describes how to troubleshoot the fault when all the users of all MA5600T/
MA5603Ts under the upper-layer BRAS or router encounter service interruption.
Procedure
Step 1 Contact the BRAS/router maintenance engineers to check whether the BRAS/router works in
the normal state.
Step 2 Contact the BRAS/router maintenance engineers to check whether the data configurations of
the BRAS/router are correct.
Step 3 Contact the engineers in charge of maintaining the transmission devices to check whether the
transmission devices are interconnected correctly.

Module
Step 4 Check whether the service configuration is correct.

For example, check the following for the multicast service:
l Whether the video service is configured correctly.
l Check whether the TTL value of a program is large enough. Ensure that the maximum value
is greater than the number of hops from the server to the user.
----End

Module 6 Commonly Used Methods of Fault Locating and
Troubleshooting Troubleshooting
6 Commonly Used Methods of Fault Locating

and Troubleshooting
About This Chapter
This topic describes commonly used methods of fault locating and troubleshooting for functional
modules, including OM methods of the equipment and methods of using common fault locating
tools.
6.1 Methods of Locating and Troubleshooting Common ODN Faults
This topic describes the location methods, related alarms, and common operations in locating
and troubleshooting common ODN faults.
6.2 Locating and Troubleshooting ONT Faults
This topic describes ONT-related alarms and how to locate and troubleshoot ONT faults.
6.3 Common Methods of Locating Voice Service Faults
This chapter describes common tools and methods for locating voice service faults.
6.4 Optical Fiber Loopback
When the service of an optical port is interrupted, or when an abnormality alarm is reported for
an optical port, the optical fiber loopback can be performed section by section from the local
end to the remote end to check whether the two-fiber bi-directional local optical port (such as
the upstream FE/GE optical port), the peer optical port, or the optical line is normal.
6.5 ADSL2+ Port Loopback
When the service of an ADSL2+ port is abnormal, loopback can be performed on the port to
check whether the communication between the service board of this port and the backplane is
normal. Through the loopback, the fault can be located. One thing that should be noted is that,
during the actual fault locating, the fault is usually located through a series of loopback performed
section by section.
6.6 SHDSL Port Loopback
When the service of an SHDSL port is abnormal, loopback can be performed on the port to check
whether the communication between the service board of this port and the backplane (local
loopback), or the communication between this service board and the user-side device (remote
loopback), is normal. Through the loopback, the fault can be located. One thing that should be
noted is that, during the actual fault locating, the fault is usually located through a series of
loopback performed section by section.

6.7 VDSL2 Port Loopback

When the service of a VDSL2 port is abnormal, loopback can be performed on the port to check
whether the communication between the service board of this port and the backplane is normal.
Through the loopback, the fault can be located. One thing that should be noted is that, during
the actual fault locating, the fault is usually located through a series of loopback performed
section by section.
6.8 Changing the Line Profile (Template) of an xDSL Port
This topic describes how to change the line profile (line template) bound to an xDSL port when
the line profile of the ADSL2+ or SHDSL port or the line template of the VDSL2 port cannot
meet the requirement for the service.
6.9 Changing the Traffic Profile of an xDSL Port
This topic describes how to change the traffic profile when the traffic profile bound to the xDSL
port cannot meet the requirements for the rate and the 802.1p priority.
6.10 E1 Port Loopback
The E1 port loopback refers to the software loopback of an E1 port, and it can be local loopback
or remote loopback. When the service of an E1 port is abnormal, perform local loopback to
normal, or perform remote loopback to check whether the communication between this service
board and the peer device is normal.
6.11 E1 Line Loopback
The E1 line loopback is also called the 2M link physical loopback. It is a type of hardware
loopback. When the service of an E1 port is abnormal, perform the E1 line loopback to check
whether the E1 port is normal and whether the communication of the line is normal.
6.12 Performing PPPoE Dialup Simulation
PPPoE dialup simulation is to simulate the OLT or ONU as a PPPoE client to initiate dialup
authentication to the BRAS. After obtaining the authentication results, check the connectivity
between the OLT or ONU and the BRAS.

6.1 Methods of Locating and Troubleshooting Common

ODN Faults
This topic describes the location methods, related alarms, and common operations in locating
and troubleshooting common ODN faults.
The ODN contains all lines and devices between the optical line terminal (OLT) and optical
network unit (ONU), such as backbone fibers, optical splitters, and branch fibers. The ODN
assigns power of optical signals and provides physical channels for transmitting optical signals
between the OLT and ONU, as shown in the following figure.
ONT 1
ONT 2
ONT 3
Optical splitter
OLT
ONT N ODN
6.1.1 Common ODN Faults

This topic describes how to locate and troubleshoot common ODN faults.
You can determine the fault point according to the judgment criteria and then troubleshoot the
fault.

Table 6-1 Locating and troubleshooting common ODN faults

The connector endface of The connector endface of an l Clean the connector endface
an optical fiber is optical fiber is unclean, if it is not clean. For details
unclean, scratched, or scratched, or indented if one of about how to clean the
indented. the following situations occurs: connector, see 6.1.6
NOTE l The attenuation (calculated Cleaning the Connector of
An unclean, scratched, or using the optical power on an Optical Fiber.
indented optical fiber
both sides of the optical l Replace the optical fiber if
connector will cause
excessive attenuation and fiber connector tested by its connector endface is
abnormal reflection. the optical power meter) of scratched or indented.
the optical fiber connector
is larger than the theoretical
attenuation. For details
about how to check the
optical power, see 6.1.3
Checking the Optical
Power.
l The reflection and return
loss of the backbone fiber
and branch fiber are
abnormal as tested by the
OTDR. For details about
how to use the OTDR, see
6.1.4 Using the OTDR to
Locate Abnormal
Attenuation Points on the
Optical Line.
l The optical fiber endface
check finds that the
connector endface of the
optical fiber is unclean,
scratched, or indented.

The optical fiber The connector of the optical Connect the optical fiber again
connector is too tight or fiber is too tight or loose if one to ensure that the optical fiber is
loose. of the following situations properly connected.
NOTE occurs: NOTE
An over tightly or loosely l The attenuation (calculated FC/PC connectors are generally
connected optical fiber difficult to fasten properly. SC/PC
using the optical power on
will cause excessively connectors are recommended.
large attenuation and both sides of the optical When an SC/PC connector is
reflection. fiber connector tested by properly connected, you will hear
the optical power meter) of a click.
Power.
l Points with abnormal return
loss exist on the backbone
fiber and branch fiber as
tested by the OTDR. For
details about how to use the
OTDR, see 6.1.4 Using the
OTDR to Locate
Abnormal Attenuation
Points on the Optical
Line.
l The optical fiber connector
checked onsite is too tight
or loose.

Optical fiber connectors Optical fiber connectors of Replace the incompatible

of different types are different types are connected if connector with a compatible
connected. one of the following situations one or replace relevant devices.
NOTE occurs: NOTE
If different types of optical l The attenuation (calculated In the CATV service scenario, it is
fiber connectors are recommended that you use APC
using the optical power on
connected, the attenuation connectors (green) only.
and reflection will be both sides of the optical
excessively large. fiber connector tested by
the optical power meter) of
Power.
l Points with abnormal return
fiber and branch fiber as
OTDR to Locate
Line.
l The PC connector (blue) is
connected to the APC
connector (green) onsite.

The optical fiber is The optical fiber is excessively Replace the optical fiber.
excessively bent. bent if one of the following
NOTE situations occurs:
Optical signals attenuate l Points with abnormal return
seriously on an optical
small bending radius. fiber and branch fiber as
OTDR to Locate
Line.
l The optical fiber has red
light leaking as tested by a
red pointer in a short
distance (within 1000 m).
For details about how to use
the red pointer, see 6.1.5
Checking Whether the
Optical Fiber Is Damaged
Using the Red Pointer.
l The optical fiber is
excessively bent onsite.
NOTE
The bending diameter of an
optical fiber must be longer
than 6 cm.

The optical fiber is The optical fiber is damage if l Replace the optical fiber if it
damaged. either of the following is damaged.
situations occurs: l Splice the optical fiber
l Points with abnormal return again if air bubbles exist at
loss exist on the backbone the splicing point.
fiber and branch fiber as CAUTION
tested by the OTDR. For Only specially trained and
details about how to use the qualified personnel are
OTDR, see 6.1.4 Using the allowed to splice optical
fibers.
OTDR to Locate
Line.
l The optical fiber has red
light leaking as tested by a
red pointer in a short
distance (within 1000 m).
For details about how to use
the red pointer, see 6.1.5
Checking Whether the
Optical Fiber Is Damaged
Using the Red Pointer.

The multi-mode optical The multi-mode optical fiber is Replace the multi-mode optical
fiber is used. used if one of the following fiber with a single-mode optical
NOTE situations occurs: fiber.
Only single-mode optical l The attenuation (calculated
fibers can be used on the
using the optical power of
ODN lines. If the multi-
mode optical fiber is used, the backbone fiber and
the optical signal branch fiber tested by the
attenuates quickly and the optical power meter) of the
return loss increases. backbone fiber and branch
fiber is larger than the
theoretical attenuation. For
details about how to check
the optical power, see 6.1.3
Power.
l Optical signals of the
backbone fiber and branch
fiber attenuate seriously as
OTDR to Locate
Line.
l The multi-mode optical
fiber is used onsite.
NOTE
The single-mode optical fiber
is yellow and the multi-mode
optical fiber is orange.

The optical splitter is The optical splitter is faulty or l Replace the optical splitter
faulty or the fiber adapter the fiber adapter for the optical if it is faulty.
for the optical splitter is splitter is not clean if either of l Clean the fiber adapter for
not clean. the following situations occurs: the optical splitter if it is not
l The attenuation (calculated clean. For details about how
using the optical power on to clean the fiber adapter,
both sides of the optical see 6.1.6 Cleaning the
splitter tested by the optical Connector of an Optical
power meter) of the optical Fiber.
splitter is larger than the
theoretical attenuation. For
details about how to check
the optical power, see 6.1.3
Power.
l The attenuation of the
optical splitter is
excessively large as tested
by the OTDR. For details
about how to use the
OTDR to Locate
Line.
NOTE
The common OTDR cannot
test attenuation of the optical
splitter in the penetration
manner. Therefore, the
attenuation of an optical
splitter can be tested only by
the OTDR that can penetrate
the optical splitter.

The optical attenuation The optical attenuation of the Add an optical attenuator on the
of the optical line is optical line is excessively small optical line between the OLT
excessively small. if either of the following and ONU.
NOTE situations occurs:
l If the optical l The actual receive optical
attenuation of the power of the ONU is larger
optical line is than -8 dBm as tested by the
excessively small, the
optical power meter.
by the ONU will l The optical attenuation of
exceed the overload the optical line between the
optical power of the OLT and ONU is
ONU.
excessively small. The
l Such a situation normal attenuation range is
usually occurs in labs,
15-25 dB.
where the OLT and
ONU may be directly
connected to each
other by using a short
optical fiber.
determined by the
connected but by the the ODN far exceeds 20 km.
split ratio of optical l The split ratio exceeds the
splitters. When an
optical splitter is
specification. For example,
connected to the ODN, a board supports a
attenuation occurs and maximum split ratio of
the split ratio of the 1:64. If the first-level split
optical splitter needs to ratio is 1:8, the second level
be calculated. is 1:16, the actual split ratio
l Protocols specify that is 1:128. This exceeds the
the receive optical specification (1:64).
power of the OLT
should not exceed 15 l The optical attenuation
dB. In addition, the difference of two optical
difference between the lines exceeds 15 dB.
maximum optical
power and the
minimum optical
power should not
exceed 15 dB.
6.1.2 ODN-Related Alarms

This topic describes ODN-related alarms.
Table 6-2 describes GPON ODN faults and corresponding alarms.

Table 6-2 GPON ODN alarms

Fault Related Alarms
l The split ratio is excessively 0x2e112002 The loss of GEM channel delineation
large. (LCDGi) occurs
l The optical fiber is excessively 0x2e112003 The signal degrade of ONTi (SDi) occurs
long. 0x2e112004 The signal fail of ONTi (SFi) occurs
l The branch fiber deteriorates or 0x2e112006 The loss of frame of ONTi (LOFi) occurs
is bent.
0x2e112007 The distribute fiber is broken or the OLT
l The branch fiber connector is cannot receive expected optical signals from the GPON
loose or contaminated. ONT(LOSi)
0x2e11a00a The loss of acknowledgement PLOAM
message with ONTi (LOAi) occurs
0x2e11a00c The loss of PLOAM of ONTi (LOAMi)
occurs
l The backbone fiber is broken or 0x2e11a001 The feed fiber is broken or OLT can not
disconnected. receive any expected optical signals(LOS)
l The optical module of the OLT
PON port is faulty or removed.
The optical module of the ONU 0x2e112007 The distribute fiber is broken or the OLT
PON port is faulty or removed. cannot receive expected optical signals from the GPON
ONT(LOSi)
6.1.3 Checking the Optical Power

Checking the optical power is a common method for ODN troubleshooting. By checking and
analyzing upstream and downstream optical power, you can determine whether the optical line
quality is good.
6.1.3.1 Analyzing the Optical Power

In optical power analysis, the actual optical attenuation is compared with the theoretical value
to determine the quality of the optical line and locate the abnormal attenuation point in the optical
line.
The optical power attenuates after being transmitted through the optical components or optical
fibers. Normally, the actual attenuation is close to the theoretical value. If the actual attenuation
is much larger than the theoretical value, abnormal attenuation point exists in the optical line.
Figure 6-1 shows the ODN optical line

Figure 6-1 ODN optical line
Upstream
ONU 0
OUT IN
ONU 1
ONU 2 Two-level optical splitter A OUT IN
ONU 29 One-level optical splitter

OUT IN
ONU 30 OLT
ONU 31 Two-level optical splitter B
Downstream
Actual optical attenuation = Upstream optical power on one side of the test point - Upstream
optical power on the other side of the test point. Alternatively, Actual optical attenuation =
Downstream optical power on one side of the test point - Downstream optical power on the other
side of the test point. These two calculated values are the same. For details about how to measure
the optical power, see 6.1.3.3 Measuring the Upstream Optical Power Using the Optical
Power Meter and 6.1.3.4 Measuring the Downstream Optical Power Using the Optical
Power Meter.
For example, to calculate the actual optical attenuation of two-level optical splitter A in Figure
6-1, do as follows:
l Method 1: Actual optical attenuation of two-level optical splitter A = Upstream optical
power of the IN port on two-level optical splitter A - Upstream optical power of the OUT
port on two-level optical splitter A
l Method 2: Actual optical attenuation of two-level optical splitter A = Downstream optical
power of the OUT port on two-level optical splitter A - Downstream optical power of the
IN port on two-level optical splitter A
NOTE
l If the upstream optical power is used for calculating the optical attenuation of an optical splitter, only
the ONU to be tested is powered on. That is, other ONUs connected to the same optical splitter are
powered off. This ensures accurate optical power.
In the preceding example, only ONU 0, ONU 1, or ONU 2 is powered on and the other two ONUs are
powered off.
l It is recommended that you use the downstream optical power for calculating the optical attenuation
because the downstream optical is easy to measure.
l You can run commands to query the optical power if it cannot be measured onsite. However, the optical
power of an optical splitter cannot be queried using the CLI. For details, see 6.1.3.2 Querying the
Optical Power Using the CLI. When the CLI is used for querying the optical power, the query result
is accurate and stable if a great volume of data is transmitted; the query result has a maximum difference
of 2 dB from the actual optical power if a small volume of data is transmitted. Therefore, it is not
recommended that you run commands to query the optical power.
Table 6-3 lists theoretical optical attenuation.

Table 6-3 Theoretical optical attenuation

Component Type Average Loss (dB)
Connection Mechanical splicing point, fusion 0.3

point splicing point, active connector, and
quick connector
Optical splitter 1:64 20.5
1:32 17.5
1:16 13.5
1:8 10.5
1:4 7.5
1:2 3.5
Optical fiber 1490 nm (1 km) 0.23
1310 nm (1 km) 0.35
Table 6-4 describes possible faults and causes if the actual optical attenuation is much larger
than the theoretical value.
Table 6-4 Possible faults and causes

Fault Possible Cause
Connection point (such as l Cores at the two ends of an optical fiber of the mechanical
mechanical splicing splicing point or the fusion splicing point are not aligned.
point, fusion splicing l The fusion splicing point has air bubbles.
point, active connector,
and quick connector) l The active connector or the quick connector is faulty or not
clean.
Optical splitter The optical splitter is faulty or the fiber adapter for the optical
splitter is not clean.
Optical fiber l The connector endface of an optical fiber is unclean,

scratched, or indented.
l The optical fiber connector is too tight or loose.
l Optical fiber connectors of different types are connected.
l The optical fiber is excessively bent.
l The optical fiber is damaged.
l The multi-mode optical fiber is used.

6.1.3.2 Querying the Optical Power Using the CLI

If the optical power cannot be measured onsite, you can log in to the OLT to query the Tx/Rx
optical power of the OLT or ONU using the CLI. It is not recommended that you use the CLI
to query the optical power because there is a difference between the query result and actual value.
Context
NOTE
l When the CLI is used for querying the optical power, the query result is accurate and stable if a great
volume of data is transmitted; the query result has a maximum difference of 2 dB from the actual optical
power if a small volume of data is transmitted. Therefore, it is recommended that you use the optical
power meter to measure the optical power onsite.
l If the MDU or ONU supports optical power query, you can use the MDU CLI or ONT web page to
query the Tx/Rx optical power.
Table 6-5 Commands for querying the optical power of a GPON ONU
Item Command
Rx optical power of the OLT display port state
Tx optical power of the OLT display port state
Rx optical power of the ONU display ont optical-info
Tx optical power of the ONU display ont optical-info
6.1.3.3 Measuring the Upstream Optical Power Using the Optical Power Meter
This topic describes how to measure the upstream optical power using the optical power meter.
Prerequisites
l The OLT and the ONU are powered on.
l The PON port is enabled.
Tools and Materials

l A new SC/PC single-mode patch cord not longer than 1 m is recommended.
l Burst optical power meter: Measures the upstream and downstream optical power without
disconnecting a working optical line. This power meter is usually used in external tests. It
generally measures the optical power at the ingress for optical signals and displays the result
on its screen. Optical signals attenuate from their entry into the optical power to their
departure from the optical power, which affects the measurement result. However, this
attenuation is not considered in actual external tests.
Impact on the System

Services carried on the optical line will be interrupted.

Precautions
CAUTION
Never look into the optical port or the connector of an optical fiber without eye protection. Never
put the optical port towards the flammables.
Clean the connector of an optical fiber after testing the optical power by referring to 6.1.6
Cleaning the Connector of an Optical Fiber. This is because if a contaminated optical fiber
is connected to a functional optical fiber connector, the connector will be contaminated, which
leads to abnormal attenuation and reflection and therefore affects the quality of the optical line.
Procedure
Step 1 Configure the measurement parameters of the burst optical power meter.
l Optical power unit: dBm
l Wavelength (nm): 1310
NOTE
A functional ONU does not proactively send optical signals. An ordinary optical power meter measures
only the upstream optical power or downstream optical power at one time and the optical line is
disconnected in measuring. Therefore, a bust optical power meter is required in measuring the upstream
optical power.
Step 2 Use the patch cord to connect the bust optical power meter to the measurement point in an ODN
link to measure the optical power.
Points for measuring the upstream optical power are connection points (such as mechanical
splicing points, fusion splicing points, active connector, and quick connector) in an ODN link,
IN and OUT ports of an optical splitter, OLT PON ports, and ONU PON ports.
The following figure shows measurement of the upstream optical power using an ONU PON
port as an example.
Upstream
ONU 0
OUT IN
ONU 1
ONU 2 Two-level optical splitter OUT IN
ONU 29
OUT IN One-level optical splitter
ONU 30
OLT
Two-level optical splitter
ONU 31
Burst optical
power meter
Step 3 View and record the optical power read from the burst optical power meter.

NOTE
l If the value on the optical power meter changes within a range of 0.2 dBm, take the average value.
l If the value on the optical power meter changes in a range wider than 0.2 dBm, there is a possibility that the
optical fiber is not properly connected, the optical fiber is excessively bent, or the optical fiber connector is
unclean.
l Do not bend the optical fiber. A bent optical fiber may affect the test result.
Step 4 Remove the burst optical power meter after measurement and reconnect the optical line.
Step 5 Analyze the quality of the optical line. For details, see 6.1.3.1 Analyzing the Optical Power.
----End
6.1.3.4 Measuring the Downstream Optical Power Using the Optical Power Meter
This topic describes how to measure the downstream optical power using the optical power
meter.
Prerequisites
l The OLT and the ONU are powered on.
l The PON port is enabled.
Tools and Materials

l A new SC/PC single-mode patch cord not longer than 1 m is recommended.
l Burst optical power meter or common optical power meter
– Burst optical power meter: Measures the upstream and downstream optical power
without disconnecting a working optical line. This power meter is usually used in
external tests. It generally measures the optical power at the optical signal ingress and
displays the result on its screen. Optical signals attenuate from their entry into the optical
power to their departure from the optical power, which affects the measurement result.
However, this attenuation is not considered in actual external tests.
– Ordinary optical power meter: Measures only the upstream or downstream optical
power at one time and the optical line is disconnected in measuring.
NOTE
When measuring the downstream optical power, disconnect the optical line and connect the optical
power meter to the measurement point. That is, you do not need to connect the optical power meter
to the optical line. The optical power meter can be the bust optical power meter or ordinary optical
power meter.

Precautions
CAUTION

Clean the connector of an optical fiber after testing the optical power by referring to 6.1.6
Cleaning the Connector of an Optical Fiber. This is because if a contaminated optical fiber
is connected to a functional optical fiber connector, the connector will be contaminated, which
leads to abnormal attenuation and reflection and therefore affects the quality of the optical line.
Procedure
Step 1 Configure the measuring parameters of the optical power meter.
Step 2 Connect the optical power meter to the measurement point.
Points for measuring the downstream optical power are connection points (such as mechanical
splicing points, fusion splicing points, active connector, and quick connector) in an ODN link,
IN and OUT ports of an optical splitter, OLT PON ports, and ONU PON ports.
l If the measurement point is the IN port of an optical component (such as the IN port of an
optical splitter or the ONU PON port), remove the optical fiber of the measurement point
and connect the optical fiber to the optical power meter.
l If the measurement point is the OUT port of an optical component (such as the OUT port of
an optical splitter or the OLT PON port), remove the optical fiber of the measurement point
and use the patch cord to connect the optical power meter to the measurement point.
The following figure shows measurement of the downstream optical power using an OLT PON
port as an example.
Downstream
ONU 0
OUT IN
ONU 1
ONU 2 Two-level optical splitter

OUT IN
ONU 29 One-level optical

OUT IN
splitter
ONU 30 OLT
ONU 31 Two-level optical splitter
Optical power meter
Step 3 View and record the optical power read from the optical power meter.
NOTE
l If the values on the optical power meter change within a range of 0.2 dBm, use the average value.
l If the values on the optical power meter change in a range wider than 0.2 dBm, there is a possibility that the
optical fiber is not properly connected, the optical fiber is excessively bent, or the optical fiber connector is
unclean.
l Do not bend the optical fiber. A bent optical fiber may affect the test result.
Step 4 Remove the optical power meter after measurement and reconnect the optical line.

Step 5 Analyze the quality of the optical line. For details, see 6.1.3.1 Analyzing the Optical Power.
----End
6.1.4 Using the OTDR to Locate Abnormal Attenuation Points on

the Optical Line
The optical time domain reflectometer (OTDR) is usually used for locating abnormal attenuation
points on the optical line.
Concept
The OTDR is used to test parameters such as the optical fiber curve, return loss, fusion splicing
loss, reflection ratio, and length/attenuation/break of the optical fiber on the cable line. The
OTDR issues a laser pulse signal to the tested optical fiber, and receives the reflected optical
signal on the optical port in certain intervals. Based on the optical power of the Rayleigh
scattering and Fresnel reflection, the OTDR shows the signal trail of the whole optical fiber. In
this way, the loss of different parts on the optical fiber and the fiber end position can be
determined based on the test result.
Figure 6-2 shows the procedure for testing the performance (such as the loss) of the fiber line
by using the OTDR.
Figure 6-2 OTDR test procedure

Test the
Connect the
Set parameters performance of Save the test data Analyze the data
tested line
the optical fiber
Disconnect light Test the fiber Be familiar with

Set the mode
source of fiber line curve the event type
Connect the tested Set the Analyze the

line wavelength Test the return loss event
Test the fusion

Set the pulse width
splicing loss
Set the Test the reflection

measurement ratio
range
Set the average Test the length/

time attenuation/break
of the optical fiber
Set the event
threshold
Rayleigh scattering
When the optical fiber is heated during manufacturing, thermal agitation causes uneven atom
compression, which leads to uneven material density, and further leads to uneven refraction
ratio. When the optical fiber is cooled, the unevenness is fixed and it arises optical scattering,
which is called Rayleigh scattering. The Rayleigh scattering is an inherent feature of the optical
fiber. Points that can generate Rayleigh scattering exist on the entire optical fiber and they are
continuous.
Fresnel reflection

The Fresnel reflection generally occurs on discrete interfaces such as the connector and adapter.
It is caused by air gap, misalignment or refraction mismatch. The Fresnel reflection is a discrete
reflection and it is generated on some discrete points of the fiber. The reflection points generally
include the fiber connector (at the gap between the glass and the air), smooth mirror cross section
that blocks the optical fiber, and the fiber end.
OTDR dynamic range
The OTDR dynamic range is a physical quantity used to test the maximum capacity of events
on the fiber line. It determines the longest fiber distance that the OTDR can measure. If the
OTDR dynamic range is small and the tested optical fiber is with high loss, the remote end may
be displayed as noise in the OTDR curve.
Deadzone
A deadzone is two events that are close to each other but still can be measured, namely, the
resolution of two events. The deadzone of the OTDR is a certain range within which the OTDR
curve cannot reflect the fiber line status due to the impact of Fresnel reflection. Attenuation
deadzone is the part of OTDR trail whose measured data is covered by a strong reflection. Event
deadzone is the minimum distance between two reflection events when they can still be
distinguished. In this case, the distance between two events can be measured, but the loss of
each of them cannot be measured.
Event
An event on the optical fiber is anything (apart from normal scattering of the optical material
itself) that causes loss or reflection. The event includes all kinds of connections and damages
(such as bends, cracks or breaks). An event can be reflective or non-reflective. A reflective event
occurs when some pulse energy is reflected (for example on a connector), and it generates a peak
signal on the trail. A non-reflective event occurs on the optical fiber at the part where some loss
is generated but no reflection occurs, and it generates an angle on the trail.
Optical attenuation
The attenuation of the optical fiber is the power loss occurred when optical signals travel along
the optical fiber. The unit of the attenuation (A) is dB, and the attenuation can be calculated
using the following formula: A = 10 x lgP1/P2. In the formula, A is the attenuation, P1 is the
optical power of the input end, and P2 is the optical power of the output end.

Precautions
l Select the OTDR whose test wavelength is the same as communication wavelength of the
tested system.
l Select test instruments that are of good performance.
l Select the OTDR with a relatively large memory.
l Select the OTDR with USB port or network cable to facilitate data reading.
l Select the OTDR that is with a relatively long power supply duration and then prepare for
power supplying.
l Do not replace the test instruments during the test to prevent great change of the test value.

l Record the parameter settings and test results of the instrument in detail during the test.
After the test, collect and save the record data for reference in subsequent maintenance.
l Before storing the instruments, fully charge their batteries to extend the life cycle of the
batteries. If the instruments are idle for a long time, charge and discharge the batteries at
least once every three months.
l Clean the connector of an optical fiber after testing the optical power by referring to 6.1.6
Cleaning the Connector of an Optical Fiber. This is because if a contaminated optical
fiber is connected to a functional optical fiber connector, the connector will be
contaminated, which leads to abnormal attenuation and reflection and therefore affects the
quality of the optical line.
CAUTION
Procedure
Step 1 Connect the tested line.
1. Disconnect the light source of the tested fiber line.
2. If the OTDR optical port does not match the connector of the tested optical fiber, prepare
a 300-2000 m transitional patch cord, with one end matching the OTDR optical port and
the other end matching the connector of the tested optical fiber.
TIP
If the OTDR optical port matches the connector of the tested optical fiber, an additional 300-2000
m optical fiber can be used to process the deadzone and to test the insertion loss of the terminal
connector. The additional optical fiber includes the following two types: the transmitting optical fiber
and receiving optical fiber. The transmitting optical fiber is connected between the OTDR optical
port and the connector of the tested optical fiber. It is used to cover the front deadzone so that the
front part of the tested optical fiber is in the linear stable zone of the OTDR curve, and to measure
the insertion loss of the front connector. The receiving optical fiber is connected to the end of the
tested optical fiber. It is used to prevent the Fresnel reflection peak from affecting the measurement
of the event that occurs close to the end of the tested optical fiber, and to measure the insertion loss
of the rear connector.
3. Clean the OTDR optical port and the fiber connector by using alcohol.
NOTE
Avoid other detergents or refractive index matching liquid that dissolve the adhesive in the fiber
connector.
4. Connect the tested line, as shown in Figure 6-3.
Figure 6-3 Connecting the tested line
2 3
Tested line
1. Transitional patch cord 2. Connector 3. Connection point

Step 2 Set parameters.

1. Set the mode.
The following modes can be used as required: automatic, manual and fault locating.
TIP
l The automatic mode is used in common tests.

l The manual mode is used in the following situations:
a. The event point is determined and located incorrectly in a short-distance (within tens of
meters) or ultra-long-distance test.
b. Test results of the same optical fiber are different in different tests.
l The fault locating mode is used to fast locate obvious fault positions.
2. Set the wavelength.
Generally, the test wavelength is the same as the communication wavelength of the tested
system. For example, if the system opens a wavelength of 1550 nm, the test wavelength
must also be 1550 nm.
3. Set the pulse width.
The pulse width varies with the distance of the tested optical fiber. The shorter the distance,
the smaller the pulse width. Figure 6-4 shows reference values for setting the pulse width.
Figure 6-4 Reference values for setting the pulse width
4. Set the measurement range.

The best measurement range is between 1.5 times and twice the length of the tested optical
fiber.
TIP
l In actual tests, perform the automatic test that is of the maximum measurement range first to
locate the faulty section, and then select a proper measurement range that is larger than and closest
to the tested distance. In this way, the accuracy of the OTDR is utilized sufficiently.
l Keep the measurement range twice the length of the tested optical fiber to prevent second
reflection at the fiber end.
l If the measurement range is shorter than twice the length of the tested optical fiber, second
reflection peak of the fiber end may occur on the even test curve, hence causing the ghost, which
leads to a feint that the optical fiber line is faulty.
5. Set the average time.

Generally, the average time is around 30s. The recommended average time is 20s or 30s.
6. Set fiber parameters.
The refraction ratio n and backscattering coefficient η can be set based on the ratio and
coefficient provided by the manufacturer. If the provided values cannot be obtained, use
the default values of the instrument.
TIP
l If different sections of optical fibers are of different refraction ratios, set the refraction ratio by
section to reduce test errors caused by inaccurate settings.
l If the refraction ratio error is 0.001, the measured distance error can be 0.7 m/km.
7. Set the event threshold.
The setting of the event threshold depends on your interested events. Table 6-6 lists
reference values for setting the event threshold.
Table 6-6 Reference values for setting the event threshold
Threshold Minimum Value Default Value Maximum Value

(Unit: dB) (Unit: dB) (Unit: dB)
Fusion splicing 0.01 All 1.99

point
Reflection -98.00 All -11.00
Fiber end 3.00 Automatic 20.00

detection
Step 3 Test the performance of the optical fiber.

l Test the fiber curve.
1. Select Start to perform the test.
2. The test result is the fiber curve.
l Test the return loss.
1. Enter the test interface after testing the fiber curve.
2. Select Return Loss. Then two marking lines A and B are displayed on the interface.
3. Move the marking lines A and B to delimit the area for testing the return loss.
4. Select Return Loss Test to obtain the return loss of area A-B.
l Test the fusion splicing loss.
2. Select 4-pt SPL. Then four marking lines a, A, B and b are displayed on the fiber
curve.
3. Move marking lines a and A to the start point and end point of the linear area before
the tested event respectively, and move marking lines B and b to the start point and
end point of the linear area after the tested event respectively, as shown in Figure
6-5.

Figure 6-5 Setting the marking lines for a fusion splice event
a AB b
1. Tested fusion splice event
4. Select Fusion Splicing Loss and perform the test. The test result is the loss value of
the fusion splice event.
l Test the reflection ratio.
2. Select 4-pt SPL. Then three marking lines a, A and B are displayed on the fiber curve.
3. Move marking lines a and A to the start point and end point of the linear area before
the tested event respectively, and move marking line B at the peek of the tested event,
as shown in Figure 6-6.
Figure 6-6 Setting the marking lines for a reflection event
a AB
4. Select Reflection Coefficient and perform the test. The test result is the reflection
ratio of the reflection event.
l Test the length/attenuation/break of the optical fiber.
1. Enter the interface of the event list after testing the fiber curve.
2. Check the length of the optical fiber displayed in the event list.
3. Check whether the fiber curve is consecutive. If the curve is consecutive, the optical
fiber is not broken. Otherwise, the optical fiber is broken.
4. Check the attenuation of the optical fiber between two points by reading the vertical
level difference between them directly from the fiber curve.
Step 4 Save the test data.

l Common saving mode of the test data includes the OTDR curve mode and figure mode.
l To save the test data using a USB disk, insert the USB disk directly into the USB port on the
OTDR and then export the files.
l To save the test data using a network cable, connect the computer to the OTDR by using the
network cable and then export the files.
Step 5 Analyze the data.
1. Check the trail whose vertical axis displays the optical power and horizontal axis displays
the distance. The test trail shows the optical power of the return signal relative to the
distance.
TIP
l Normally, the slopes of each section (such as single or multiple spools of optical cables) on the
entire curve are basically the same in an OTDR test.
l A greater slope in a section indicates a greater attenuation in it.
l If the entire curve is anomalous with large change of slopes or is bent or bracket-shaped, the
quality of the optical fiber degrades severely.
2. Analyze the event.
Figure 6-7 shows common events.
Figure 6-7 Common events
1 2 3 4 5
1. Mechanical splicing point 2. Connection point of the patch cord 3. Fusion splicing point
4. Connector 5. Fiber end
Figure 6-8 shows common curves of fiber faults.

Figure 6-8 Common curves of fiber faults
2 dB
(1) (2)
Abnormal
Normal
Abnormal Normal
(3) (4)
1. Macro-bend 2. Break
3. Extrusion 4. Incorrect connection or ghost
TIP
l Ghost: The position of the ghost is generally an integer multiple of the distance from a strong-
reflection event to the instrument, and no loss occurs at the position. The ghost can be cleared
by selecting a short pulse width or adding attenuation to the front part (such as the OTDR output
end) of the strong-reflection even. If the event causing ghost occurs at the fiber end, make a small
bending to increase the attenuation for the optical signal that reflects back to the start part.
l Positive gain: Some connectors are displayed as amplifiers, and the power level seems to be
increased by certain gain. Positive gain is caused by the situation that more backscattering optical
signals are reflected in the optical fiber after the fusion splicing point than the fiber before the
fusion splicing point. Actually, the fusion splicing loss occurs at the fusion splicing point of the
optical fiber. The actual loss can be obtained as follows: Perform multiple measurements from
the other end opposite to the end where amplifiers are displayed to obtain the measured loss
values of the fusion splicing point, and then calculate the average loss; the difference between
the gain and the average loss is the actual loss of the fusion splicing point.
l Fiber connection: Main factors that affect cable safety are mechanical damages. An excessively
large connection loss does not affect the connection intensity. Therefore, in the cases that some
connecting loss values are excessively large with about 1% of them exceeding the standard value,
and the values do not decrease after multiple re-connecting, the fiber connection can still be
determined as qualified.
----End
6.1.5 Checking Whether the Optical Fiber Is Damaged Using the

Red Pointer
The red pointer, also called visual fault locating meter or visual fault detector, sends red light to
check whether the optical fiber has red light leak to locate the damage point of an optical fiber.

Context
You can directly see the position with red light leak by using the red pointer. Though the red
pointer is easy to use, its measurement range is limited within 1000 m. Therefore, it can only be
used for locating the damage point of an optical fiber in a short distance.
An optical fiber is generally damaged on the bare fiber, coiled fiber or fusion splicing point.
Precautions
DANGER
Never look directly into the optical fiber connector or the laser transmit port on the optical port
board without eye protection. Never put the optical port towards the flammables.
Procedure
Step 1 Place the red pointer on the endface of an optical fiber and send red light.
Step 2 Check whether the optical fiber has red light leak. If the red light leaks, the fiber is damaged.
Step 3 Replace or re-splice the optical fiber that has red light leak.
l Replace the optical fiber if its bending is excessively large.
NOTE
The bending diameter of an optical fiber must be longer than 6 cm.
l Splice the optical fiber again if air bubbles exist at the splicing point.
----End
6.1.6 Cleaning the Connector of an Optical Fiber

This topic describes how to clean the connector of an optical fiber. Frequent insertion and
removal or not taking dustproof treatment for a long time causes the connector to be unclean
and deteriorated, which compromises the quality of the line. Therefore, you need to take

measures to prevent dust and periodically clean optical fiber connectors, including the connector
endface of an optical fiber, optical port of an optical module, and fiber adapter.
Prerequisites
Prepare the cleaning tools before cleaning, and follow the instructions in "Precautions".
Context
A large number of optical fiber connectors are used in optical transmission, which are easy to
be contaminated in OM. The dust particles that can be seen by a microscope affect the quality
of optical signals. As a result, the system performance deteriorates and network stability is
affected. For two connected optical components, dust particles may damage the surface of the
optical fiber. If the cladding or edge of an optical fiber has dust particles, the cores of two
connected optical fibers may not be exactly aligned. As a result, the quality of optical signals is
affected.
A 1 μm dust particle on a single-mode optical fiber blocks 1% optical signals and therefore leads
to 0.05 dB attenuation loss. A 9 μm dust particle is hard to be seen without a microscope but it
completely blocks the core of an optical fiber. Therefore, even an extremely small contaminant
that can only be found by an instrument such as a microscope may block the connector of an
optical fiber. Besides dust particles, the following contaminants need to be cleaned away:
l Grease (usually brought by hands)
l Condensation residues
l Powder (evaporation residues of water or solvent)
Such contaminants will also damage optical components and are more difficult to clean away
than dust particles. To clean optical components, you must follow the corresponding steps.
Tools and Materials

The following lists commonly used cleaning tools and materials:
l Optical power meter: used for testing whether the laser on the connector of an optical fiber
is disabled.
l Lint-free wipe: a piece of long silk cotton specially used for cleaning the connector endfaces
of an optical fiber.
l Lint-free swab: used for cleaning the optical port of an optical module, and a fiber adapter.
It has two specifications: ф2.5 mm and ф1.25 mm. You can select one according to the
port type (use the lint-free swab with ф2.5 mm for the ports of SC and FC types, and use
that with ф1.25 mm for the ports of LC and MTRJ types).
l Protective cap: used on the connector of an optical fiber, optical port of an optical module,
and fiber adapter.
l Cleaning tool box: used for placing lint-free wipes and protective caps. Place lint-free wipes
and protective caps separately from other tools.
l Cleaning reagent (alcohol): used for cleaning the connector of an optical fiber. It is
flammable and therefore must be safely stored and kept clean.
l Optical fiber endface magnifier: a microscope (400*) used for checking whether the
connector endface of an optical fiber is clean and smooth.


An optical module must be powered off before its port is cleaned. In this case, services carried
on the optical port will be interrupted.
Precautions
DANGER
l Never look into the optical port or the connector of an optical fiber without eye protection.
Never put an optical port towards the flammables.
l Never clean an optical fiber connector when the laser is on.
l ESD discharge damages the equipment. To remove or insert a pluggable optical module
before or after cleaning, wear an ESD wrist strap or ESD gloves.
l Put a protective cap into the cleaning tool box immediately after taking it off. Place unused
protective caps in the cleaning tool box, or in the ESD bag for sealed storage. Clean
protective caps quarterly (it is recommended to clean them by using an ultrasonic cleaner).
l Keep your hands clean and dry before cutting a lint-free wipe, and place unused lint-free
wipes in the clean ESD bag or the cleaning tool box for sealed storage.
l After the cleaning, cover the connector of the optical fiber, optical module, and fiber adapter
that will not be immediately used with protective caps.
Procedure
l Clean the connector endface of an optical fiber.
1. Power off the laser of the connector before cleaning. Disconnect the optical fiber (at
both ends) to be cleaned.
2. Use the optical power meter to test the optical power and ensure that no optical signals
are sent from the connector of the optical fiber.
3. Clip a piece of lint-free wipe into 32 small pieces of the same size.
4. Use a dry lint-free wipe (two-layer) to wipe the connector endface of the optical fiber
along one direction once. For a seriously contaminated connector, use a lint-free wipe
(two-layer) dipped with a little cleaning reagent to wipe the connector endface of the
optical fiber along one direction once, and then use a dry lint-free wipe (two-layer) to
wipe it along one direction once again for ensuring that the connector endface is dry
NOTE
l A lint-free wipe can be used only once. Use the portion of the lint-free wipe that is not
touched by your hands.
l You can use the optical fiber end magnifier to check the cleaning and abrasion condition
of an optical fiber connector.
5. After the cleaning, do not touch the connector. Connect the optical fiber (at both ends)
immediately. Cover the optical connectors that will not be immediately used with
protective caps.
6. Power on the laser.
l Clean the optical port of an optical module.

1. Power off the laser of the optical module before cleaning. Disconnect the optical fiber
(at both ends) from the optical module.
are sent from the port of the optical module.
3. Wear an ESD wrist strap or ESD gloves to remove a pluggable optical module.
4. Select lint-free swabs with a suitable diameter according to the type of the optical port.
Dip a swab with the cleaning reagent, insert the swab into the inside of the optical
port, and then clean it by rotating the swab 360 degrees in one direction along the
inner wall of the optical port.
NOTE
The lint-free swab with ф2.5 mm is used for the ports of SC and FC types and that with ф1.25 mm
is used for the ports of LC and MTRJ types.
5. Insert a dry swab of the same type into the inside of the optical port and clean it by
rotating the swab 360 degrees in one direction along the inner wall of the optical port.
6. After the cleaning, connect the optical fiber (at both ends). Cover the ports of the
optical modules that will not be immediately used with protective caps. Wear an ESD
wrist strap or ESD gloves to insert a pluggable optical module.
l Clean a fiber adapter.
1. Power off the laser of the optical port before cleaning. Disconnect the optical fiber (at
both ends) from the fiber adapter.
are sent from the connector of the fiber adapter.
3. Select lint-free swabs with a suitable diameter according to the type of the fiber
adapter. Dip a swab with the cleaning reagent, insert the swab into the socket inside
the fiber adapter, and then clean it by rotating the swab 360 degrees in one direction
along the inner wall of the fiber adapter.
NOTE
The lint-free swab with ф2.5 mm is used for the ports of SC and FC types and that with ф1.25 mm
is used for the ports of LC and MTRJ types.
4. Insert a dry swab of the same type into the socket inside the fiber adapter and clean it
by rotating the swab 360 degrees in one direction along the inner wall of the fiber
adapter.
NOTE
Use an ultrasonic cleaner to clean fiber adapters when there are a large quantity of them.
5. After the cleaning, connect the optical fiber (at both ends). Cover the fiber adapters
that will not be immediately used with protective caps.
----End
6.2 Locating and Troubleshooting ONT Faults

This topic describes ONT-related alarms and how to locate and troubleshoot ONT faults.
6.2.1 ONT-Related Alarms

This topic describes ONT-related alarms.

Table 6-7 describes GPON ONT faults and corresponding alarms.
Table 6-7 GPON ONT alarms

The ONT is powered off. 0x2e11a00b The dying-gasp of GPON ONTi

(DGi) is generated
0x2e11a001 The feed fiber is broken or OLT
can not receive any expected optical signals
(LOS)
0x2e112007 The distribute fiber is broken or
the OLT cannot receive expected optical
The ONT hardware is faulty. 0x2e112002 The loss of GEM channel

delineation (LCDGi) occurs
0x2e112003 The signal degrade of ONTi
(SDi) occurs
0x2e112004 The signal fail of ONTi (SFi)
occurs
0x2e11a00c The loss of PLOAM of ONTi
(LOAMi) occurs
0x2e11a00f The physical equipment error of
ONTi (PEEi) occurs
0x2e112007 The distribute fiber is broken or
the OLT cannot receive expected optical
0x2e11a107 The status of ONT's E1/T1 port
is abnormal
The ONT software is faulty. 0x2e21a102 The GPON ONT configuration

recovery fails
0x2e11a00c The loss of PLOAM of ONTi
(LOAMi) occurs
The ONT internal interface is faulty. 0x2e313015 The hardware of the ONT is
faulty
The ONT hardware self-check fails. 0x2e313015 The hardware of the ONT is
faulty
The device connected to the E1/T1 port is 0x2e11a107 The status of ONT's E1/T1 port
faulty or the line between the device and the is abnormal
E1/T1 port is not connected properly.
The line of the ONT E1/T1 port is not 0x2e11a107 The status of ONT's E1/T1 port
connected properly. is abnormal
The ONT software upgrade fails. 0x2e30a10e Fail to load the GPON ONT file

The mains supply of the ONT is unavailable. 0x2e313016 The ONT switches to the
standby battery
The backup battery of the ONT is lost or is 0x2e313017 The standby battery of the ONT
faulty. is lost
The backup battery of the ONT cannot be 0x2e313018 The standby battery of the ONT
charged. cannot be charged
The voltage of the backup battery of the ONT 0x2e313019 The voltage of the standby
is over low. battery of the ONT is too low
The ONT enclosure is open. 0x2e31301a The shell of the ONT is opened
There is a rogue ONT. 0x2e314021 There are illegal incursionary

rogue ONTs under the port
6.2.2 Locating and Troubleshooting an ONT Fault Remotely

This topic describes how to remotely locate and troubleshoot an ONT fault using the OLT CLI.
6.2.2.1 Querying ONT Information

You can query ONT information such as the ONT status and traffic by running commands on
the OLT, which helps locate an ONT fault remotely.
Table 6-8 Commands for querying information about a GPON ONT
Information Command
Version display ont version
Status and display ont info

configurations
Capability display ont capability
Optical module display ont optical-info
Real-time traffic of an display ont traffic

Ethernet port
Performance display statistics ont-eth

statistics of an
Ethernet port
POTS port status display ont potsport state
Registration status of display ont mg status

the ONT on the MG
interface

Information Command
Performance display statistics ont-iphost

statistics of an display statistics ont-iphost
IPHOST port on the
ONT
Information about the display ont ipconfig

IP address of the ONT display ont ipconfig
Information about the display ont wan-info

WAN port of the
ONT
6.2.2.2 Simulating a PPPoE Dialup

You can verify the PPPoE dialup function by simulating a PPPoE user dialing up from an ONT
for connecting to the BRAS. The simulation can be performed by running commands on the
OLT.
Prerequisites
l You have the operator authority or higher to the OLT.
l Related service data is configured.
l The ONT is in the online state.
Procedure
l In GPON access mode, perform PPPoE dialup simulation as follows:
1. Run the interface gpon command to enter the GPON mode.
2. Run the pppoe simulate start command to start PPPoE dialup simulation and query
the returned result.
If PPPoE dialup simulation is successful, Emulator result is Success.
3. (Optional) Run the pppoe simulate stop command to stop an unfinished PPPoE dialup
simulation.
----End
6.2.2.3 Performing a Voice Loop Line Test

You can check whether the loop current, loop voltage, and phone are in the normal state by
remotely performing a voice loop line test when the ONT POTS port fails to provide the voice
service. The test can be performed by running commands on the OLT and it helps quickly locate
a fault that occurs on the line between an ONT POTS port and a connected phone.
Prerequisites
l The voice service is configured.

Procedure
Step 1 Run the test command to enter the test mode.
Step 2 Run the ont pots-test-threshold set command to set the test threshold for the ONT POTS port.
NOTE
l You can run the ont pots-test-threshold restore command to restore the test threshold for the ONT POTS
port to the default value.
l Run the display ont pots-test-threshold command to query the test threshold for the ONT POTS port.
Step 3 Run the ont pots-test command to perform the voice loop line test and query the returned result,
including the test conclusion and values.
Conclusion l Normal
l AC current abnormal
l DC current abnormal
l Broken lines
l Line mixing
l AB Line reversal
l Line leaking
l Phone disconnect
l Time out
l Failed
Item l A->ground DC voltage

l B->ground DC voltage
l A->B DC voltage
l A->ground AC voltage
l B->ground AC voltage
l A->B AC voltage
l A->ground insulation resistance
l B->ground insulation resistance
l A->B insulation resistance
l A->ground capacitance
l B->ground capacitance
l A->B capacitance

----End
6.2.2.4 Simulating a Voice Call

Call simulation is a test in which the test module of an ONT is used as a phone to perform the
call test. You can check whether the call service runs properly by running commands on the
OLT to remotely perform voice call simulation when a POTS port fails to provide the voice
service.
Prerequisites
l The voice service is configured.
Context
The call simulation test serves two purposes: verifying basic call services during service
provisioning; used together with the POTS line test to locate a fault during service running.
There are two types of call simulation tests: caller simulation and callee simulation.
l Caller simulation: The test module of an ONT simulates a calling party and initiates a voice
call.
l Callee simulation: The test module of an ONT simulates a called party and answers a voice
call.
The call simulation test is irrelevant to protocols for upstream transmission and is applicable to
SIP and H.248.
Procedure
Step 1 Run the test command to enter the test mode.
Step 2 Run the ont emulational call command to start the voice call simulation.
l In caller simulation, the called party hears the ringing tone, picks up the phone, hears the
prompt tone, and performs operations according to the prompt tone. The CLI displays the
test result.
l In callee simulation, the calling party calls the called party. After hearing the ringing tone,
the called party automatically picks up the phone and plays the prompt tone. The CLI displays
the test result.
If call simulation is successful, Test Result is success.
Step 3 (Optional) Run the display ont emulational call command to query the status of the voice call
simulation test.
NOTE
The voice call simulation test is a special operation. After the test command is issued, the test result is returned
after a long period of time. In the test, you can run the query command to query the current test status.
Step 4 (Optional) Run the undo ont emulational call command to stop the voice call simulation test.
----End

6.2.2.5 Restoring Factory Defaults

You can run commands on the OLT to restore factory defaults for an ONT to rectify the ONT
service failure caused by unauthorized configurations.
Prerequisites
Context
Some ONTs support the following operations for restoring factory defaults:
l Holding down the reset button on the ONT panel.
l Logging in to the Web page of the ONT and restoring factory defaults on the Web page.

All services of the ONT are interrupted.
Precautions
CAUTION
Restoring factory defaults resets an ONT and all services of the ONT are interrupted. Therefore,
exercise caution when performing this operation.
Procedure
l In GPON access mode, run the following commands on the OLT to restore factory defaults
for an ONT:
2. Run the ont factory-setting-restore command to restore factory defaults for an ONT.
NOTE
When receiving the restoration command issued by the OLT, the ONT resets. In the restoration
process, the ONT running status is down. You can run the display ont info command to query the
ONT status.
----End
6.2.2.6 Resetting an ONT

You can remotely reset an ONT by running commands on the OLT to make ONT configurations
take effect or to resolve certain unexpected faults that occur on the ONT.
Prerequisites

Context
Some ONTs support the following local reset operations:
l Pressing the reset button on the ONT panel for a short while.
l Logging in to the Web page of the ONT and resetting the ONT on the Web page.

All services of the ONT are interrupted.
Precautions
CAUTION
Resetting an ONT directly interrupts all its services. Therefore, exercise caution when
performing this operation.
Procedure
l In GPON access mode, reset an ONT as follows:
2. Run the ont reset command to reset an ONT.
NOTE
When receiving the reset command issued by the OLT, the ONT resets. In the resetting process, the
ONT running status is offline. You can run the display ont info command to query the ONT status.
----End
6.2.3 Detecting a Rouge ONT

A rogue ONT affects communication of the other ONTs under the same OLT. This topic
describes how to locate and isolate a rogue ONT.
Context
PON uses time division multiplexing. Using this mechanism, an ONT sends packets to the
upstream direction according to the time stamp allocated by the OLT. If an ONT sends optical
signals when it is not allocated a time stamp, its optical signals conflict with optical signals sent
by other ONTs. Such an ONT is called a rogue ONT.
A rogue ONT has the following impacts on the system:
l If the rogue ONT is online, one or all of the other ONTs connected to the same PON port
on the OLT go offline or go online and offline frequently.
l If the rogue ONT is not configured, the other ONTs that are not configured will fail to be
automatically discovered.
A rogue ONT has two modes: continuous mode and irregular mode. Currently, the system
supports detection and isolation of only continuous-mode GPON ONTs. Irregular-mode GPON
ONTs can only be detected and isolated manually.
The continuous-mode GPON ONT detection includes automatic detection and manual detection.

l Automatic detection: Enabled by running the anti-rogueont autodetect command.
CAUTION
Due to the complexity of optical lines, the system may mistakenly detect and isolate a
functional ONT, which will affect user services. Therefore, it is recommended that you set
automatic detection to off. That is, disable automatic detection.
l Manual detection: Enabled by running the anti-rogueont manual-detect command.
The continuous-mode GPON ONT detection has the following limitations:

l By checking and analyzing the optical signals in the upstream direction, the OLT can
identify and isolate rogue ONTs for non-malicious users, but cannot identify ONTs that
are intentionally damaged or that are incompliant with standard requirements.
l The ONT does not need to support extended PLOAM messages for identifying a rogue
ONT on the PON line. The system, however, can only determine whether a rogue ONT
exists but cannot locate a rogue ONT.
l All ONTs connected to a PON port on the OLT must support Huawei-defined extended
PLOAM messages for rogue ONT identification. Furthermore, optical signal transmission
of the ONT optical modules must be controllable.
Procedure
l In GPON access, perform the following operations to check a rogue GPON ONT.
1. If an ONT goes online and the other ONTs connected to the same PON port go offline
or go online and offline frequently, a rogue ONT may exist in the system. In this case,
detect the ONT using the following method:
2. Run the anti-rogueont manual-detect command to detect the rogue ONT manually.
Then, check whether the 0x2e314022 The ONT is rogue ONT or 0x2e314021 There
are illegal incursionary rogue ONTs under the port alarm is generated.
– If an alarm is generated, a continuous-mode ONT may exist. In this case, go to
Step 3.
– If no alarm is generated, an irregular-mode ONT may exist. In this case, go to Step
5.
NOTE
You can use an optical power meter to measure the receive optical power on an OLT PON port
to determine whether a rogue ONT exists on the PON port. For details, see "Related
Information".
3. Clear the generated alarm.
– If the 0x2e314022 The ONT is rogue ONT alarm is generated, go to Step 4.
– If the 0x2e314021 There are illegal incursionary rogue ONTs under the port alarm
is generated, go to Step 5.
NOTE
l If the 0x2e314022 The ONT is rogue ONT alarm is generated, a continuous-mode ONT may
exist or a functional ONT is mistakenly detected as a rogue ONT because of the faulty ONT.
l If the 0x2e314021 There are illegal incursionary rogue ONTs under the port alarm is generated,
a continuous-mode ONT may exist and this ONT does not support Huawei-defined extended
PLOM messages or optical signal transmission of ONT optical modules cannot be controlled.

4. Check whether a faulty ONT goes online.

– If a faulty ONT goes online, this ONT is in continuous mode. In this case, locate
the ONT by its ID and subrack ID/slot ID/port ID according to parameters in the
generated alarm. Then, replace the ONT by referring to Replacing an ONT and
go to Step 8.
– If no faulty ONT goes online, an irregular-mode ONT may exist. In this case, go
to Step 5.
5. Run the ont deactivate command to deactivate the ONTs connected to the same PON
port one by one. Then, check whether a faulty ONT goes online.
– If a faulty ONT goes online, the ONT is a rogue one. In this case, replace the ONT
– If no faulty ONT goes online, the ONT optical module may be damaged so that
the rogue ONT cannot be isolated or deactivated by running the command. In this
case, go to Step 6.
6. Detect a rogue ONT manually. On the optical splitter, remove upstream optical fibers
of the ONTs one by one and check whether a faulty ONT can go online.
– If a faulty ONT goes online, the ONT is a rogue one. In this case, replace the ONT
– If no faulty ONT goes online, go to Step 7.
7. Record the results of the preceding steps in the form for reporting a fault, fill in the
form completely, and then submit the form to Huawei for technical support.
8. The fault is rectified.
----End
Related Information
The procedure of using an optical power meter to measure the receive optical power on an OLT
PON port is as follows:
1. Configure the measuring parameters of the optical power meter.
2. Remove the fiber from the OLT PON port and connect it to the optical power meter, as
Figure 6-9 Measuring the receive optical power on an OLT PON port
3. Wait 10s and then read the value. Check the value on the optical power meter in one minute.

4. Insert the optical fiber removed in step 2 to restore the connection between the ONT and
the OLT.
5. Check whether a rogue ONT exists according to the measured result.
l If no value can be read or the read value is smaller than -45 dBm on the optical power
meter, there is no continuous-mode ONT or irregular-mode ONT under the PON port.
l If a value can always be read and is larger than -28 dBm on the optical power meter,
there is a continuous-mode ONT under the PON port.
l If a value can only be read intermittently and, when it can be read, is larger than -28
dBm on the optical power meter, there is an irregular-mode ONT under the PON port.
6.2.4 Replacing an ONT

An ONT needs to be replaced if it is faulty or its hardware needs to be upgraded.
Prerequisites
The type of the ONT remains the same after the replacement.
Procedure
Step 1 Replace an ONT onsite.
1. Remove the optical fiber from the ONT and the cable from the port.
2. Replace the ONT. Then, connect the removed optical fiber and cable.
3. Log in to the ONT web page to configure the ONT information.
a. Modify the ONT authentication information.
l If the ONT is authenticated by password, password+SN, LOID, or LOID
+CHECKCODE, modify the password, LOID, or CHECKCODE of the ONT and
ensure that they are the same as those before the replacement.
l If the ONT is authenticated by SN, you do not need to modify its SN after the
replacement.
NOTE
Each ONU has unique SN, which is configured before factory delivery and cannot be changed.
b. (Optional) Configure the ONT service data.
If the ONT service data such as the Wi-Fi authentication information is configured on
the ONT web page, you need to configure such data again after the replacement.
NOTE
If the NMS is used in the live network, you do not need to configure the service data again because
the NMS will issue the original data.
Step 2 Log in to the OLT and modify the ONT authentication information.
Run the ont modify (gpon) command to change the SN so that the ONT authentication
information configured on the OLT is the same as that on the ONT.
NOTE
You can run the display ont autofind (gpon) command to query the automatically discovered SN and then
change the SN.
----End

6.3 Common Methods of Locating Voice Service Faults

This chapter describes common tools and methods for locating voice service faults.
6.3.1 Capturing Packets by Using Port Mirroring

Capturing packets on an Ethernet port allows you to monitor the traffic on a device, diagnose
network faults, and analyze the data. This requires a packet capture tool connected to the uplink
Ethernet port, which may interrupt the service on the uplink Ethernet port. Port mirroring
function allows you to mirror the packets on an Ethernet port to an idle Ethernet port and to
capture the packets to the destination port, preventing service interruption on the source port.
Context
Figure 6-10 shows the cable connection in port mirroring and packet capturing.
Figure 6-10 Cable connection in port mirroring and packet capturing
Uplink port
Packet
capture tool
Source port Destination port
Description: In the preceding figure, the source port is the uplink port of a device, namely, the
Ethernet port on which packets are to be captured. The packets transmitted through the source
port are mirrored to the destination port. A packet capture tool is connected to the destination
port for capturing the packets.
The packet capture tool (for example, the Ethereal) can be installed on a PC that is connected
to the destination port by using a network cable. (If the destination port is an optical port, an O/
E converter can be used for signal converting.)
Prerequisite
l The source port and destination port for mirroring must be Ethernet ports.
l The destination port cannot be an aggregated port.

l The devices must be connected according to Figure 6-10.
Procedure
Step 1 Verify that the current Ethernet ports can be used for port mirroring.
1. Run the display board frameid/slotid command to verify that the source port and
destination port are Ethernet ports.
If the source port and destination port are not Ethernet ports, it cannot be used for port
mirroring.
2. Run the display link-aggregation all command to verify that the destination port is not an
aggregated port.
If the destination port is an aggregated port, determine whether to cancel port aggregation
based on site requirements.
l If port aggregation can be canceled, run the undo link-aggregation command to cancel
port aggregation. After packet capture operation is complete, run the link-
aggregation command to restore port aggregation.
NOTE
Port aggregation implements port protection and load sharing among the ports in an aggregation group.
After port aggregation is canceled, load sharing cannot be implemented. As a result, packets may be
lost when the traffic is heavy. Therefore, exercise caution when canceling port aggregation.
l Port mirroring cannot be performed if port aggregation is configured.
Step 2 In ETH mode, run the mirror port command to configure port mirroring.
Step 3 Run the display mirror command to verify that port mirroring is configured successfully.
Step 4 Start the packet capture tool to capture packets.
Step 5 Run the undo mirror port command to disable the port mirroring.
Step 6 Run the display mirror command to verify that port mirroring is disabled successfully.
----End
Result
After the packets are captured, you can analyze the packets.
6.3.2 Ethereal
To locate a fault on the network, you only need to capture some packets or analyze some of the
packets captured among a large number of packets on the network. The Ethereal tool can be
used to filter specified packets based on the preset filtering rules, helping you focus only on
useful information to locate a fault.
Context
There are two methods of setting filtering rules on the Ethereal tool:
l Method 1: Configure filtering rules before capture to only capture specified packets.
l Method 2: Configure filtering rules after capture to only display specified packets among
the captured packets.

This section describes how to capture packets using method 2.
Prerequisites
The .cap file is generated after packet capture.
Procedure
Step 1 Run the Ethereal tool and open the generated .cap file.
Step 2 Configure packet filtering rules.

You can configure filtering rules manually or use the function of automatically generating
filtering rules based on a packet field. The following section describes how to perform the two
operations.
l Manually configure filtering rules to filter specified packets.
1. Enter a filtering criterion in the Filter box as shown in the following figure. For example,
filtering criterion "frame.pkt_len>100" indicates that a packet longer than 100 bytes
will be filtered out.

NOTE
See the user guide for the tool to learn about the rules for setting filtering criteria. If the filtering
criterion entered in the Filter box does not meet the setting rules, the background color of the Filter
box is red, indicating that the entered filtering criterion is invalid. If the filtering criterion entered in
the Filter box meets the setting rules, the background color of the Filter box is green, indicating that
the entered filtering criterion is valid.
2. Click Apply. The tool can filter the required packets, as shown in the following figure.

l Select a packet field to enable the tool to automatically generate filtering rules based on the
field.
1. Select the desired packet field, right-click, and choose Apply as Filter from the shortcut
menu. Then, choose a computing formula as required, as shown in the following figure.

NOTE
You can also choose multiple computing formulae in the preceding step.
2. Click Apply. The tool can filter the required packets, as shown in the following figure.
----End
Result
The Ethereal tool displays the required packets according to the preset filtering rules.
6.3.3 CoolEdit
When a voice service fault occurs, listening to the collected voice file may not be enough to
locate the fault. The CoolEdit tool can be used to evaluate the quality of a voice file and helps
you locate a fault.
Context
After obtaining the voice file for the affected voice service, you can use the CoolEdit tool to
analyze the quality parameters of the voice service and the possible fault causes to troubleshoot
the service as soon as possible.
Prerequisites
The voice file for the affected voice service is available.
Procedure
Step 1 Open the CoolEdit tool, as shown in the following figure.

Step 2 Click to open the voice file to be analyzed.

Step 3 Analyze the opened voice file. The following figure is an example. The figure shows that the
interval between the original voice and the echo is about 360 ms, which is far longer than the
duration (128 ms) that can be canceled using the echo cancellation algorithm. As a result, the
service users hear echoes of their own voice.
----End

Result
The CoolEdit tool analyzes the voice service file and provides associated information for you
to locate the fault.
6.4 Optical Fiber Loopback

When the service of an optical port is interrupted, or when an abnormality alarm is reported for
an optical port, the optical fiber loopback can be performed section by section from the local
end to the remote end to check whether the two-fiber bi-directional local optical port (such as
the upstream FE/GE optical port), the peer optical port, or the optical line is normal.
Prerequisites
A service stream exists on the port where the optical fiber loopback is performed and the port
has been running normally until the fault occurs.
Impact on System
After the optical fiber loopback is performed, the corresponding optical port cannot forward
packets correctly. As a result, all the services carried by this port are interrupted.
Tools, Meters, and Materials

l Optical fiber
Precautions
When performing the optical fiber loopback, to avoid impacting the service, pay attention to the
following points:
l If the optical port of the loopback works in the active/standby mode, switch the service of
this port to a normal port before the loopback.
l If the optical port of the loopback works in the load balancing mode, perform the loopback
when the optical fiber carries minimum traffic (such as at night or in the early morning),
thus to prevent congestion.
l During the optical fiber loopback, if the optical port of the loopback is not isolated from
other ports, a broadcast storm may occur. Therefore, after the loopback test, disable the
loopback.
Procedure
Step 1 Use an optical fiber to connect the Tx and Rx ends of an optical port on the device to form a
self-loop, as shown in Figure 6-11.

Figure 6-11 Optical fiber loopback
NOTE
To prevent the optical power overload from damaging the components, use an optical attenuator for the
loopback test. A small optical attenuation value should be set. If the optical attenuation value is too large,
the loopback test result may be inaccurate. It is suggested that the optical attenuation value be set to the
maximum value or about 20 dB, and be gradually downshifted during the optical fiber loopback until the
LINK LED of the optical port turns on.
Step 2 Run the display alarm history command and display event history command to query whether
a recovery alarm or event is generated by the corresponding optical port.
----End
Reference
Optical fiber loopback
The method of the optical fiber loopback is to manually connect the Tx and Rx ends of an optical
port directly by using optical fibers.
Figure 6-12 illustrates the optical fiber loopback.
Figure 6-12 Optical fiber loopback
Optical fiber loopback is performed on the side where the fault occurs section by section from
the local end to the remote end, as shown in Figure 6-12. If the optical port of the device recovers
(a recovery alarm or event is generated) after the loopback is performed on one section, it
indicates that the optical fiber and the components in this section are in the normal state.
Otherwise, it indicates that a fault occurs on the optical fiber or the components in this section.
To rectify the fault, check the optical fiber or replace the components.

6.5 ADSL2+ Port Loopback

When the service of an ADSL2+ port is abnormal, loopback can be performed on the port to
normal. Through the loopback, the fault can be located. One thing that should be noted is that,
during the actual fault locating, the fault is usually located through a series of loopback performed
section by section.
Prerequisites
l The board must be in the normal state.
l 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 the
service traffic.)
NOTE
l Only deactivated ports can be looped back.

l If a port is in the loopback state, the port cannot be activated.

l 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 in the ADSL mode to cancel the
loopback in time.
Precautions
l In the case of hybrid loopback, the subscriber line must be connected to a 100-ohm resistor
in series.
l The port loopback type of a specific board is related to the hardware structure of the board.
When loopback is enabled on a non-supporting board, the system gives a corresponding
error prompt.
Procedure
Step 1 In the ADSL mode, run the loopback command to start the port loopback (select a proper
loopback type, such as UTOPIA, AFE, or hybrid, as required).
For example, to perform the UTOPIA loopback on port 0/3/1, do as follows:
huawei(config-if-adsl-0/3)#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 corresponding
to the traffic stream of the port is 0/35), do as follows:
huawei(config-if-adsl-0/3)#atm-ping 0 0 35
----End

Reference
The ports on the ADSL2+ board support only the local loopback.
Local loopback
Local loopback, also named inloop, refers to the loopback from the port processing module of
the board to the backplane. In the local loopback, the signals that are transmitted from the
backplane to the port are directly sent to the backplane to check whether the board is in the
normal state. Figure 6-13 shows the local loopback.
Figure 6-13 Local loopback

interface module
Port processing
Backplane
module
Local
loopback
Board
ADSL2+ port local loopback
The ADSL2+ board supports three types of local loopback, namely, universal test & operations
PHY interface for ATM (UTOPIA), analog front end (AFE), and hybrid.
l UTOPIA loopback refers to the loopback of "backplane <-> UTOPIA port <-> backplane",
as shown in Figure 6-14 (1). This loopback type is used to check whether the path between
the backplane and the logic is normal.
l AFE loopback refers to the loopback of "backplane <-> AFE <-> backplane", as shown in
Figure 6-14 (2). This loopback type is used to check whether the path between the
backplane and the inner side of the chipset is normal.
l Hybrid loopback refers to the loopback of "backplane <-> hybrid <-> backplane", as shown
in Figure 6-14 (3). This loopback type is used to check whether the path between the
backplane and the edge of the chipset is normal.
Figure 6-14 ADSL2+ port local loopback
A
UTOPIA AFE Hyb
背 F Hybrid
UT rid
E
Backpane OPI
接
interface A (1)
1 (2)
2 (3)
module
模
块逻
Logic Chipset
辑
Board

6.6 SHDSL Port Loopback

When the service of an SHDSL port is abnormal, loopback can be performed on the port to check
whether the communication between the service board of this port and the backplane (local
loopback), or the communication between this service board and the user-side device (remote
loopback), is normal. Through the loopback, the fault can be located. One thing that should be
noted is that, during the actual fault locating, the fault is usually located through a series of
loopback performed section by section.
Prerequisites
l The board must be in the normal state.
l In local loopback, the following requirements must be met:
– The SHDSL ports must be in deactivated state.
– The switch chip and local SHDSL is tested, and no SHDSL link is needed.
l In remote loopback, the following requirements must be met:
– The SHDSL port must be in the activated state.
– The switch chip and remote SHDSL is tested, and SHDSL link is required. Ensure that
traffic streams are carried in the upstream direction from the user-side device to the
SHDSL service board.
Impact on System
l After a port is configured with loopback, the port cannot forward packets correctly. As a
result, all the services carried by this port are interrupted.
l After a port is configured with loopback, a broadcast storm may occur if the port is not
isolated from other ports. Therefore, after the loopback test, run the undo loopback
command to disable the loopback.
Precautions
The port loopback type of a specific board is related to the hardware structure of the board. When
loopback is enabled on a non-supporting board, the system gives a corresponding error prompt.
Procedure
Step 1 In the SHDSL mode, run the loopback command to enable the port loopback.
For example, to enable local loopback on port 0/3/1 for two minutes, do as follows:
huawei(config-if-shl-0/3)#loopback 0 remote time 2
Step 2 In the SHDSL board works in the ATM mode, in the SHDSL mode, run the atm-ping command
to check the connectivity of the channel. If the SHDSL board works in the PTM mode, a
peripheral device such as the Smartbits is required for transmitting packets to check the
connectivity of the channel.
For example, assuming that the SHDSL port works in the ATM mode and the VPI/VCI of the
traffic stream on the loopback port is 0/35, to check the connectivity of the channel for the
loopback enabled in the previous step, do as follows:
huawei(config-if-shl-0/3)#atm-ping 0 0 35
----End

References
The SHDSL board supports the local and remote loopbacks on the port.
Local Loopback
Local loopback, also called inloop, near-end loopback, or CO-end loopback, refers to the
loopback from the port processing module inside the board to the backplane. In local loopback,
the signals between the backplane and the port directly return to the backplane. The test aims to
check whether the downstream service between the control board and the board chip set is
through, and whether packet loss exists. When the service failure occurs, the fault is located on
the control board, board logic, and chip set. Figure 6-15 shows the local loopback.
Remote Loopback
Remote loopback, also called outloop, refers to the loopback from the port processing module
inside the board to the subscriber line. In remote loopback, the signals between the user-side
device (such as the modem) and the port signal receiving module directly return to the user-side
device through the port signal sending module over the subscriber line. The test aims to check
whether the upstream service between the customer premises equipment (CPE) and the board
is through, and whether packet loss exists. When the service failure occurs, the fault is located
on the CPE or the board chip set. Figure 6-16 shows the remote loopback.
Figure 6-16 Remote loopback
6.7 VDSL2 Port Loopback

When the service of a VDSL2 port is abnormal, loopback can be performed on the port to check
whether the communication between the service board of this port and the backplane is normal.
Through the loopback, the fault can be located. One thing that should be noted is that, during

the actual fault locating, the fault is usually located through a series of loopback performed
section by section.
Prerequisites
l The VDSL2 port is in the deactivated state.
l The VDSL2 service has been running normally until the fault occurs (make sure that a
service stream exists in the downstream direction between the control board and the VDSL2
service board).
NOTE
l Loopback can be performed only on a deactivated port.

l The port in the loopback state cannot be activated.
Impact on System
l After a port is configured with loopback, the port cannot forward packets correctly. As a
result, all the services carried by this port are interrupted.
l After a port is configured with loopback, a broadcast storm may occur if the port is not
isolated from other ports. Therefore, after the loopback test, run the undo loopback
command to disable the loopback.
Precautions
The port loopback type of a specific board is related to the hardware structure of the board. When
loopback is enabled on a non-supporting board, the system gives a corresponding error prompt.
Procedure
Step 1 In the VDSL mode, run the loopback command to enable the port loopback.
For example, to enable local loopback on port 0/3/1, do as follows:
huawei(config-if-vdsl-0/3)#loopback 0 local
Step 2 If the VDSL port works in the ATM mode, in the VDSL mode, run the atm-ping command to
check the connectivity of the channel. If the VDSL board works in the PTM mode, a peripheral
device such as the Smartbits is required for transmitting packets to check the connectivity of the
channel.
For example, assuming that the VDSL port works in the ATM mode and the VPI/VCI of the
traffic stream on the loopback port is 0/35, to check the connectivity of the channel for the
loopback enabled in the previous step, do as follows:
huawei(config-if-vdsl-0/3)#atm-ping 0 0 35
----End
Reference
The VDSL2 board supports only local loopback on the VDSL2 port.
Local loopback
the signals between the backplane and the port directly return to the backplane. Local loopback
is used to check whether the board is normal. Figure 6-17 illustrates local loopback.

6.8 Changing the Line Profile (Template) of an xDSL Port

This topic describes how to change the line profile (line template) bound to an xDSL port when
the line profile of the ADSL2+ or SHDSL port or the line template of the VDSL2 port cannot
meet the requirement for the service.
Prerequisites
None

The port needs to be deactivated. As a result, the service carried by the port is interrupted.
Precautions
None
Procedure
l 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-template command to query the line template configured
in the system, run the display adsl line-profle command to query the line profile
configured in the system, and run the display adsl channel-profile command to query
the channel profile configured in the system. Check whether the line profile and the
channel profile contained in the line template meet the requirements.
– If the line profile and the channel profile contained in the line template meet the
requirements, run the deactivate 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 line profile that meets the requirement.
– If the line profile and the channel profile contained in the line template do not meet
the requirements, run the adsl line-profile add, adsl channel-profile add, and
adsl line-template add commands to add new line profiles that meet the
requirements. Then, run the deactivate command to deactivate the port whose line
profile needs to be changed. Lastly, run the activate command to activate the port
and bind the port with the new profile.
l Change the line profile of the SHDSL port.

1. Run the interface shl command to enter the SHDSL mode.

2. Run the display shdsl line-profile command to check whether a line profile that meets
the requirement exists in the system.
– If a line profile that meets the requirement exists in the system, run the
deactivate 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 line
profile 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 be
changed. Lastly, run the activate command to activate the port and bind the port
with 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 query the line template configured
in the system, run the display vdsl line-profle command to query the line profile
configured in the system, and run the display vdsl channel-profile command to query
the channel profile configured in the system. Check whether the line profile and the
channel profile contained in the line template meet the requirements.
– If the line profile and the channel profile contained in the line template meet the
requirements, run the deactivate command to deactivate the port whose line
template needs to be changed. Then, run the activate command to activate the port
and bind the port with the line template that meets the requirement.
– If the line profile and the channel profile contained in the line template do not meet
the requirements, run the vdsl line-profile add, vdsl channel-profile add, and
vdsl line-template add commands to add new line profiles that meet the
requirement. Then, run the deactivate command to deactivate the port whose line
template needs to be changed. Lastly, run the activate command to activate the
port and bind the port with the new template.
----End
6.9 Changing the Traffic Profile of an xDSL Port

This topic describes how to change the traffic profile when the traffic profile bound to the xDSL
port cannot meet the requirements for the rate and the 802.1p priority.
Prerequisites
None

The service port (also called PVC) needs to be deleted before the profile change. As a result, the
service of the user corresponding to the service port is interrupted.
Precautions
None

Procedure
Step 1 Run the display traffic table ip command to check whether a traffic profile that meets the
requirement 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
ip 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.
CAUTION
The 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 with
a new traffic profile.
----End
6.10 E1 Port Loopback

The E1 port loopback refers to the software loopback of an E1 port, and it can be local loopback
or remote loopback. When the service of an E1 port is abnormal, perform local loopback to
normal, or perform remote loopback to check whether the communication between this service
board and the peer device is normal.
Prerequisites
The service carried by the E1 port has been running normally until the fault occurs. That means:
l To perform local loopback, make sure that a service flow exists between the backplane of
the device and the service board of the E1 port.
l To perform remote loopback, make sure that a service flow exists between the peer device
and the service board of the E1 port.

(Optional) A simulated terminal, such as an E10 meter, is required. For remote loopback
operations, when a tested link does not carry a service flow, use a simulated terminal to simulate
the peer device to send packets. Then determine the link status based on the indication on the
simulated terminal. For local loopback operations, determine the link status based on the
indication on the simulated terminal, without using the simulated terminal to simulate the peer
device to send packets.

Impact on System
After the E1 port loopback is enabled, the corresponding port cannot forward packets correctly.
As a result, all the services carried by this port are interrupted.
Precautions
l To avoid impacting the service and causing traffic congestion, perform the E1 port loopback
when the device carries minimum traffic.
l During the E1 port loopback, if the port is not isolated from other ports, a broadcast storm
may occur. Therefore, after the loopback test, run the undo loopback command to disable
the loopback.
l Loopback cannot be performed on an E1 port that is in idle or blocked state.
l The port loopback type of a specific board is related to the hardware structure of the board.
When loopback is enabled on a non-supporting board, the system gives a corresponding
error prompt.
Procedure
l Configure a remote 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 corresponding
ports on the emulation terminal, and ensure that they are in good contact.
2. Start the remote loopback on the E1 port.
For example, run the loopback command in TDM mode to start the remote loopback
on port 0/1/0.
huawei(config-if-tdm-0/1)#loopback 0 remote
3. Verify the loopback result.
By checking whether the peer device receives the signal sent by itself (for example,
if the remote loopback is started on a port, the user of the peer device should hear the
voice of himself/herself when making calls), you can determine whether the tested
link is accessible. If an emulation terminal such as the E10 meter is used, you can
determine the result according to the indication on the meter.
l Configure a 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 corresponding
ports on the emulation terminal, and ensure that they are in good contact.
2. Start the local loopback on the E1 port.
For example, run the loopback command in TDM mode to start the local loopback
on port 0/1/0.
huawei(config-if-tdm-0/1)#loopback 0 local
3. 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 the
peer device should hear the voice of himself/herself when making calls), you can
determine whether the tested link is accessible. If an emulation terminal such as the
E10 meter is used, you can determine the result according to the indication on the
meter.
----End

Reference
E1 port local loopback
the signals between the backplane and the port directly return to the backplane. Local loopback
is used to check whether the communication between the backplane and the service board of the
E1 port is normal. It is a loopback inside the system. Figure 6-18 illustrates the E1 port local
loopback.
Figure 6-18 E1 port local loopback
E1 port remote loopback
Remote loopback, also called outloop, refers to the loopback from the port processing module
inside the board to the line. In the remote loopback, the signals between the peer device (such
as the PBX or switch) and the port signal receiving module directly return to the peer device
through the port signal sending module over the subscriber line. Remote loopback is used to
check whether the communication between the service board of the E1 port and the peer device
is normal. Figure 6-19 illustrates the E1 port remote loopback.
Figure 6-19 E1 port remote loopback
6.11 E1 Line Loopback

The E1 line loopback is also called the 2M link physical loopback. It is a type of hardware
loopback. When the service of an E1 port is abnormal, perform the E1 line loopback to check
whether the E1 port is normal and whether the communication of the line is normal.

Prerequisites
A service stream exists on the E1 loop, and the service has been running normally until the fault
occurs.

l E1 self-loop line (used for performing the E1 line loopback when accurate signal quality
detection is not required)
l BER tester (used for performing the E1 line loopback when accurate signal quality detection
is required)
Impact on System
After the E1 line loopback is enabled, the corresponding port cannot forward packets correctly.
As a result, all the services carried by this port are interrupted.
Precautions
l To avoid impacting the service and causing traffic congestion, perform the E1 line loopback
when the device carries minimum traffic.
l During the E1 line loopback, if the port is not isolated from other ports, a broadcast storm
may occur. Therefore, after the loopback test, disable the loopback.
Procedure
Step 1 Connect the Rx and Tx ends of the E1 line to be tested to the E1 self-loop line or to the
corresponding ports on the BER tester, and make sure that the connectors are in proper contact.
Step 2 Determine the status of the E1 line according to the loopback result.
l When you use the E1 self-loop line to perform the loopback, run the display port state
command to query the status of the port involved in the loopback. If the port is in the normal
state, it indicates that the E1 port works in the normal state and the internal communication
of the system is also normal.
l When you use the bit error meter to perform the loopback, you can determine whether the
E1 port and the internal communication of the system are normal through the indication
(whether there is a signal stream or not) on the bit error meter. In addition, you can determine
the signal quality of the line according to the indication on the bit error meter.
----End
Reference
The E1 line loopback is a loopback test performed by manually creating a hardware loop. Figure
6-20 illustrates the E1 line loopback.

Figure 6-20 E1 line loopback
6.12 Performing PPPoE Dialup Simulation

PPPoE dialup simulation is to simulate the OLT or ONU as a PPPoE client to initiate dialup
authentication to the BRAS. After obtaining the authentication results, check the connectivity
between the OLT or ONU and the BRAS.
Prerequisites
Associated services must be configured on the ONU and OLT.
Application Scenarios
l In engineering, the PPPoE dialup simulation can be performed in batches on the BMS.
l Before service provisioning, you can perform PPPoE dialup simulation to simulate a traffic
stream, and in this way to simulate a call for checking whether the configurations of a
service are correct.
l In maintenance, PPPoE dialup simulation checks whether the ONU can communicate with
the OLT and the BRAS respectively. If the connectivity between the ONU and the OLT,
or between the ONU and the BRAS is abnormal, locate the fault. After checking remotely,
you can find that the fault is not caused by configuration errors, or by a link fault between
the ONU and the BRAS or between the ONU and the user terminal. In this case, the fault
is caused by the circuit line, subscriber line, modem, or PC.
l The loop-line test between the ONU and the user cannot be implemented currently, which
needs support of the test system of the office.
Procedure
Step 1 Start the PPPoE dialup simulation.
Assume that the user name is huawei1, user password is user123, ID of the traffic stream to
which the user belongs is 10, authentication mode is Chap, and simulation timeout time is 10s.
To start such a PPPoE dialup simulation, do as follows:
huawei(config)#pppoe simulate start
Service-port(index<0-279>):10

User Name(length<1,65>):huawei1
User Password(length<0,16>):*******
Authentication Mode: 1. Chap 2. Pap [default 1]:1
Overtime Time(5-60s)[default 5]: 10
Step 2 Query the results of the PPPoE dialup simulation.

huawei#display pppoe simulate info
PPPoE simulate information is:
-----------------------------------------------------------------
Service-port: 10
User name: huawei1
Current phase: - Result: Success
Start time: 2009-07-13,15:52:46
End time: 2009-07-13,15:52:46
Session ID: 591
User IP: 193.2.3.172
Gateway IP: 193.2.3.1
-----------------------------------------------------------------
----End

Module
Troubleshooting 7 Troubleshooting Cases
7 Troubleshooting Cases
About This Chapter
This topic describes how to troubleshoot faults that occur in the FTTx scenarios from aspects
of fault description, cause analysis, procedure, and suggestions and summary. All the
troubleshooting cases described in this topic are encountered during deployment and operation
and maintenance (OM), which provides guidance for users to troubleshoot the similar faults.
7.1 Troubleshooting Cases of ONU Status Abnormality
7.2 Troubleshooting Cases of Internet Access Service Faults
7.4 Troubleshooting Cases of VoIP Service Faults
7.5 Troubleshooting Cases of Other Services Faults

Module
7.1 Troubleshooting Cases of ONU Status Abnormality

7.1.1 Failure to Go Online of an ONU
The ONU going online failure is a fault in which an ONU fails to go online normally, and the
queried Run state of the ONU is displayed as offline by running the display ont info command
on the OLT.
7.1.1.1 TC-C6211 ONU Failure to Go Online Because of Too Large Fiber Length
Distance
This topic describes how to troubleshoot the fault of ONU failure to go online.
Fault Type
Abnormal ONU connection
Keyword
Fiber length distance
ONU failure to go online
Fault Description
Network topology: Optical split level: two levels; level-one split ratio: 1:2; level-two split ratio:
1:16; backbone fiber: 2.2 km long; branch fibers: 500 m to 24 km long
During deployment in an office, the receive optical power of all ONUs under two-level optical
splitters is normal but the ONUs fail to go online.
Alarm Information
None
Possible Cause
l The ONU receive optical power is larger than the overload optical power.
l The ONU receive optical power is smaller than the sensitivity.
l There is abnormal attenuation on ODN lines.
l The distance between the ODN Max. receive optical power and Min. optical power exceeds
the threshold.
Procedure
Step 1 Analyze the network. It is found that the distance between the farthest ONU and the OLT is over
20 km and the distance between the farthest and nearest ONUs is also over 20 km, as shown in
Figure 7-1.

Module
Figure 7-1 Too large length distance between branch fibers
Step 2 Plan the ODN again and connect the ONUs whose fibers are longer than 20 km to another PON
port. Then, ONUs normally go online.
Step 3 Such a fault does not recur in the next week.
----End
Suggestion and Conclusion

Make sure that the distance between the farthest ONU and the nearest ONU under a PON port
is smaller than 20 km.
7.1.1.2 TC-C6212 ONU Failure to Go Online Because of Incorrect Fiber Connection

This topic describes how to troubleshoot the fault of ONU registration failure.
Fault Type
Keyword
Fiber connection
ONU failure to register with the OLT
Fault Description
Network topology: Optical split level: one level; split ratio: 1:16; backbone fiber: 3.2 km long;
branch fiber: 600 m long
During deployment in an office, an ONU fails to register with the OLT. The ONU receive optical
power is 1.27 dBm and its transmit optical power is -15.9 dBm. The fault persists after system
restart or soft system reset.

Module
Alarm Information
None
Possible Cause
l The fiber is incorrectly connected.
Procedure
Step 1 Test the ONU receive optical power. The ONU receive optical power is -15.9 dBm, which is
within the normal range.
Step 2 Perform a remote query. It is found that the ONU should be connected to another PON port.
Then, it is determined that the optical fiber is incorrectly connected.
Step 3 Confirm the connection on site. It is found that the optical fiber is incorrectly connected, as
Figure 7-2 Fiber connection
Step 4 After the fault is rectified, services recover.

----End

Identify different ports using labels in engineering and manage the ports differently to prevent
incorrect connection.
7.1.1.3 TC-C6213 ONU Failure to Go Online Because of Not Clean Fiber Connector
Fault Type

Module
Keyword
Fiber connector
Fault Description
Network topology: Optical split level: one level; split ratio: 1:16; backbone fiber: 7 km long;
branch fiber: 1.2 km long
During deployment in an office, one ONU under the OLT fails to go online but other ONUs are
normal.
Alarm Information
None
Possible Cause
Procedure
Step 1 Test the ONU receive optical power. It is found that the power is -21 dBm. The ONU receive
optical power should be -14 dBm based on the network topology. Therefore, the ODN branch
fibers may cause the failure.
Step 2 Locate the fault by segment. It is found that the endface of a segment of fiber is not clean. Clean
the endface and test the ONU receive optical power again. -15 dBm attenuation is obtained.
Then, the ONU goes online successfully.
----End

Before connecting a fiber, clean the fiber endface to prevent unnecessary attenuation caused by
dust.
7.1.1.4 TC-C6216 ONU Failure to Go Online Because of a Too Large Receive Optical
Power Difference Between ONUs
Fault Type
Keyword
Optical power difference

Module
Fault Description
Network topology: Optical split level: two levels; level-one split ratio: 1:2; a 1:16 optical splitter
connected to one channel and an ONT connected to the other channel
During deployment in an office, only one ONU goes online normally and all other ONUs fail
to go online. The receive optical power of the failed ONUs is small but is still larger than the
sensitivity.
Alarm Information
None
Possible Cause
Procedure
Step 1 Test the ONU receive optical power. It is found that the receive optical power of the successful
online ONU is -7 dBm but that of other ONUs is -23 dBm.
Step 2 Calculate the range of the optical power of the entire ODN. The difference between the ONU
Max. receive optical power and the Min. receive optical power is (-7 dBm) - (-23 dBm) = 16
dBm, which is larger than 15 dBm. It is concluded that the large ONT optical power difference
causes the ONU with a low optical to fail to go online, as shown in Figure 7-3.
Figure 7-3 Too large optical power difference
Step 3 Add a 10 dBm attenuator before ONU 0. Other ONUs successfully go online.
----End

The difference between the ONU Max. receive optical power and the Min. receive optical power
should be smaller than 15 dBm, as specified in the protocol. That is, the attenuation difference
between any two ONUs connected to a PON port must not be larger than 15 dBm.

Module
7.1.2 Failure to Recover ONU Configurations

The ONU configuration recovery failure is a fault in which an ONU connected to a PON port
of an OLT can go online successfully, but the queried Config state of the ONU is displayed as
failed by running the display ont info command on the OLT.
7.1.2.1 TC-C6166 Failed ONU Configuration State Because of Incorrect Queue

Scheduling Priority
This topic describes how to troubleshoot the fault when the configuration state of an ONU is
failed.
Fault Type
Failed configuration state
Keyword
Configuration failure, registration
Fault Description
Network topology: ONU -> OLT
Version: MA5600T V800R006C02
After an ONU goes online, you can configure traffic streams for the ONU. There is no error
message during configuration, but traffic streams are unreachable after configuration. It is found
that the Config state of the ONU is failed by querying.
Alarm Information
None
Possible Cause
Parameters are incorrectly configured or functions that are not supported by the ONU are
configured.
Procedure
Step 1 Check the operation log. It is found that no error message or alarm is generated in configuration.
Step 2 In the diagnose mode, run the display ont failed-configuration 0/3/0 1 command to query the
cause of the ONU configuration failure. The queried result is as follows:
The type of failed config : Config GEM Port (21)
The index of failed config : 1792
The cause of failed config : OMCI/OAM returns error (2)
Step 3 Delete the new configurations one by one and query the ONU registration status. It is found that
the ONU Config state is normal after ont gemport bind 0 1 174 1 priority-queue 4 is deleted.
The ONU Config state is failed again when ont gemport bind 0 1 174 1 priority-queue 4 is
configured. This indicates that the configuration of ont gemport bind 0 1 174 1 priority-queue
4 is incorrect.

Module
Step 4 Modify the value of priority-queue to 3. It is found that the ONU is in the normal state.
Step 5 Perform tests. It is found that when priority-queue is set to 0, 1, 2, or 3, the ONU is in the normal
state; when priority-queue is set to 4, 5, 6, or 7, the ONU is in the failed state.
----End

The system supports priority-queue of 0-7, but only 0-3 are valid values. When priority-
queue is 4, 5, 6, or 7, the system does not prompt an error, but the ONU will be in the failed
state and services are unreachable.
The cause of this fault is that in versions earlier than V800R006C02, priority-queue indicates
the priority of a GEM port, which ranges from 0 to 7. The system uses the priority queue (PQ)
scheduling by default to map GEM ports (bound to the same T-CONT) with different priorities
to four queues for scheduling. From version V800R006C02, priority-queue indicates the
specific T-CONT queue to which the GEM port maps. An ONU supports four queues; therefore,
priority-queue ranges from 0 to 3.
7.1.3 ONU Profile Mismatch

The ONU profile mismatch failure is a fault in which an ONU connected to a PON port of an
OLT can go online successfully, but the queried Match state of the ONU is displayed as
mismatch by running the display ont info command on the OLT.
7.1.3.1 TC-C6000 The Match State Is mismatch Because of the Inconsistency

Between the Number of GEM Ports in the Capability Set Profile and the Number
of GEM Ports Supported by an ONU
This topic describes how to troubleshoot the fault when the Match State of an ONU is
mismatch because the number of GEM ports in the ONU capability set profile delivered by the
OLT is inconsistent with the number of GEM ports supported by the ONU.
Fault Type
GPON service
Keyword
Capability set profile
mismatch
GEM port
Fault Description
After an ONU is added to the OLT in a new office, an engineer runs the display ont info
command on the OLT to query the ONU. The Match State of the ONU is always mismatch.
Alarm Information
None

Module
Cause Analysis
After the ONU is added, if the ONU can go online normally, and the Run State and Match
State of the ONU are up and mismatch respectively, the possible cause is that the actual
capability of the ONU is inconsistent with the capability set profile bound to the ONU, or the
ONU is faulty.
Procedure
Step 1 Check the ports of the ONU on site. It is found that capability set profile configured on the OLT
is consistent with the actual capability of the ONU. Run the display ont capability command
to check the ports of the ONU and the parameters such as T-CONTs on the OLT. It is found that
the ports of the ONU and the parameters are consistent with the actual configurations.
Step 2 Consult ONU technical manuals. It is found that the ONU supports up to 128 GEM ports. Only
32 GEM ports, however, can be configured in the capability set profile by the OLT. Therefore,
the parameter about the number of GEM ports is set differently. As a result, the Match State of
the ONU is mismatch.
----End

Though this parameter does not affect services, the configurations cannot be delivered to the
ONU after the ONU is reset. You can run the ont resume resource command to configure the
recovery policy of the ONU. If the actual capability of the ONU is different from the capability
set profile bound to the ONU, the OLT excludes the management commands that are beyond
the actual hardware capability, and delivers only the management commands within the ONU
hardware capability according to the hardware capability parameters reported by the ONU.
7.1.4 Failure to Automatically Discover an ONU

The ONU auto discovery failure is a fault in which an OLT fails to automatically discover an
ONU after the ONU is powered on.
7.1.4.1 TC-C6004 Certain ONUs Fail to Be Auto Discovered on the OLT Because of
Very Short Maximum Registration Distance
This topic describes how to troubleshoot the fault when certain ONUs fail to be auto discovered
on the OLT because the maximum registration distance configured on the OLT is very short.
Fault Type
ONU auto discovery failure
Keyword
Registration failure
Fault Description
Certain ONUs connected to a PON port of an OLT in an office can be auto discovered on the
OLT successfully, but certain ONUs fail to be auto discovered on the OLT.

Module
Alarm Information
None
Cause Analysis
l The hardware of the ONUs is faulty.
l The ports of the PON board do not work normally.
l The data configuration of the system is incorrect, and the maximum distance for registering
the ONUs is short.
Procedure
Step 1 The fault occurs on multiple ONUs, and the fault persists after the ONUs are replaced. This
indicates that the hardware of the ONUs is normal.
Step 2 Certain ONUs connected to the PON port can register with the OLT normally, and the ONUs
work stably. This indicates that the PON board is normal.
Step 3 After check, it is found that the ONUs that fail to register with the OLT are far from the OLT,
and the physical distance ranges from 3 km to 5 km. The ONUs that are 1 km away from the
OLT do not encounter the fault.
Step 4 Run the display port info command to view the maximum registration distance of the PON
port. It is found that the maximum registration distance is 2 km.
Step 5 Run the port portid range max-distance command to change the maximum registration distance
of the PON port to 20 km. As a result, the fault is rectified.
----End

The maximum registration distance of the system is 20 km by default. Do not change the
registration distance at discretion. By default, the minimum and maximum registration distances
of the ONU are 0 km and 20 km respectively, and the configuration granularity is 1 km.
7.1.4.2 TC-C6015 An ONU Fails to Be Auto Discovered on an OLT Because the

Actual Distance Between the ONU and OLT Is Longer Than the Preset Maximum
Distance
This topic describes how to troubleshoot the fault when an ONU fails to register with an OLT
because the actual distance between the ONU and OLT is longer than the preset maximum
distance.
Fault Type
Keyword
Registration failure

Module
Fault Description
An ONU is connected to an OLT directly through an optical fiber. The ONU fails to be auto
discovered on the OLT.
Alarm Information
None
Cause Analysis
l The optical path attenuation is very large.
l The data configurations of the ONU or OLT may be incorrect.
Procedure
Step 1 Use an optical power meter to measure the optical power of the PON ports of the OLT and the
remote ONU. The optical attenuation is about -12 dB, which is within the normal range. This
indicates that the optical path is normal.
Step 2 Connect an ONU at the local end to the OLT. It is found that the ONU can be auto discovered
on the OLT, which indicates that the PON ports on both sides of the ONU and OLT are normal.
Step 3 The ONU at the local end can be auto discovered on the OLT whereas the ONU at the remote
end fails to be auto discovered on the OLT. Therefore, it is suspected that the distance between
the ONU and OLT is very long. The maximum distance supported by the OLT is 20 km by
default. Run the port portid range max-distance command to change the maximum distance
supported by the OLT to 30 km. As a result, the fault is rectified.
----End

It is not recommended that the distance between an OLT and ONU exceed 20 km. Otherwise,
if the distance is very long, the ONU that can be auto discovered on the OLT fails to be auto
discovered on the OLT due to deteriorated surroundings.
7.1.4.3 TC-C6308 The ONU Cannot Be Automatically Detected Because the Optical
Attenuation Is Excessively High
This topic describes how to troubleshoot the fault when the ONU cannot be auto discovered
because the optical attenuation is excessively high.
Fault Type
GPON service
Keyword
Optical Attenuation

Module
Fault Description
All LEDs of the ONU are normal. Enable the auto discovery function and it is found that the
OLT cannot auto discover the ONU.
Alarm Information
None
Cause Analysis
l The ONU is faulty.
l The configuration on the OLT is improper.
l The optical path is faulty.
Procedure
Step 1 All LEDs of the ONU are normal. Therefore, the problem is not caused by the faulty optical
path.
Step 2 Use an optical power meter to check segment by segment the optical power of each connection
point. It is found that optical attenuation for a segment of optical fiber between the ODF in the
telecommunications room and the optical splitter reaches –13 dB. As a result, the optical
attenuation after the optical splitter reaches –30 dB, which is lower than the minimum activation
optical attenuation (–27 dB) of the ONU. Therefore, the ONU cannot be auto discovered. After
the optical fiber is replaced, the fault is rectified.
----End

The optical attenuation of the optical path between the ONU and the OLT should be within the
range of 15–25 dB.
7.1.4.4 TC-C6210 ONU Auto Discovery Failure Because of Too Long Fibers
This topic describes how to troubleshoot the fault of ONU auto discovery failure.
Fault Type
Keyword
Too long fiber
Failure to report the SN
Failure to discover the ONU
Fault Description
Network topology: Optical split level: two levels; level-one split ratio: 1:2; level-two split ratio:
1:16; backbone fiber: 1 km long; branch fibers: 15 km to 24 km long

Module
During deployment in an office, the receive optical power of some ONUs is normal but the
ONUs fail to report their SNs or go online. Remove the ONUs and install them in the
telecommunications room. It is found that they work normally.
Alarm Information
None
Possible Cause
l ODN lines are too long and exceed the online distance preset in the system.
Procedure
Step 1 Analyze the network conditions. It is found that the distance of the nearest ONU is longer than
10 km and the distance of the farthest ONU is shorter than 30 km but longer than 20 km, which
is the Max. online distance (20 km) preset in the system. The network diagram is shown in
Figure 7-4.
Figure 7-4 Network Diagram
Step 2 The ONU goes online after the ONU Max. online distance and Min. online distance are changed
to 30 km and 10 km respectively by running the port range command on the OLT.
----End

The default ONU Max. online distance is 20 km. If the distance between the ONU and the OLT
exceeds 20 km, change the ONU Max. online distance.

Module
7.1.4.5 TC-C6215 ONU Auto Discovery Failure Because of Failure of Optical Splitter
This topic describes how to troubleshoot the fault of ONU auto discovery failure.
Fault Type
Keyword
Optical splitter
Fault Description
There are 26 ONUs in an office and one of them never reports its SN.
Alarm Information
None
Possible Cause
Procedure
Step 1 Test the transmit optical power on the optical splitter egress. It is found that the transmit optical
power of the optical fiber connected to the failed ONU is -28 dBm but that of other optical fibers
is about -15 dBm. Then, the egress of the optical splitter connected to the failed ONU may have
an abnormality.
Step 2 Clean the connector. The fault persists. The abnormality lies inside the optical splitter.
Step 3 Connect the ONU to the standby path. The ONU reports its SN and services recover.
----End

Connect the ONU to another port if the original one is faulty.
7.1.5 ONU Frequently Goes Online and Offline

The ONU frequently going online and offline failure is a fault in which an ONU connected to a
PON port of an OLT frequently goes online and offline and therefore the OLT reports a large
number of ONU LOS and ONU signal recovery alarms.

Module
7.1.5.1 TC-C6007 An ONU Goes Online and Offline Repeatedly Because of

Unstable Voltage
This topic describes how to troubleshoot the fault when an ONU goes online and offline
repeatedly and alarms that the ONU goes online and offline repeatedly are generated on the OLT
because of unstable voltage.
Fault Type
Service failure
Keyword
Going online and offline repeatedly
Repeated reset
Fault Description
An ONU connected to an OLT in an office goes online and offline repeatedly and irregularly.
Alarm Information
Alarms that the ONU goes online and offline repeatedly are generated on the OLT.
Cause Analysis
l The optical fiber attenuation is very large.
l The hardware of the ONU is faulty.
l The boards on the OLT are faulty.
Procedure
Step 1 Other ONUs connected to the PON port are normal, which indicates that the PON board of the
OLT is normal.
Step 2 Use an optical power meter to test the optical fiber attenuation on the ONU side. It is found that
the optical fiber attenuation is -20 dB, which is normal. This indicates that the line is normal.
Step 3 Replace the ONU with another ONU. The fault, however, persists, which indicates that the
hardware of the ONU is normal.
Step 4 The ONU on which the fault occurs is located in a remote mountain area. Therefore, it is
suspected that the fault is caused by the surroundings. Log in to the ONU in the telnet mode,
and then run the display alarm list all command to carefully view the alarms. It is found that
the ONU resets in peak hours from 7:00 a.m. to 8:00 p.m. in four consecutive days. Therefore,
it can be preliminarily determined that the fault is caused by the voltage.
Step 5 Use a multimeter to test the voltage on site. It is found that the ONU resets repeatedly due to
unstable voltage. Replace the ONU with another ONU with the DC module. As a result, the fault
is rectified.
----End

Module

The ONUs of Huawei support AC power supply and DC power supply. If an ONU uses the AC
power supply, the ONU resets repeatedly when the voltage is unstable. If the voltage is abnormal
and the normal voltage cannot be guaranteed, it is recommended that you use an ONU with the
DC module.
7.1.5.2 TC-C6311 An ONT Frequently Goes Online and Offline Because of

Unmatched Optical Fiber Connectors
This topic describes how to troubleshoot the fault when the deployed ONT frequently goes online
and offline because the optical fiber connectors do not match.
Fault Type
GPON service
Keyword
Fiber patch cord
Optical fiber connector
Fault Description
When an ONT is installed in the deployment, the optical path attenuation is -23 dBm, which is
within the normal attenuation range. After the optical fibers are connected, the LED of the PON
port blinks. In addition, the ONT fails to register with the OLT normally, and the ONT goes
online and offline frequently.
Alarm Information
The up and down alarms about the ONT (OT928) are generated on the OLT.
Cause Analysis
l The optical path attenuation is very large.
l The optical fiber connectors are not clean or not connected properly.
Procedure
Step 1 Use an optical power meter to measure the optical path attenuation. It is found that the optical
path attenuation is -23 dBm, which is within the normal range of the optical path attenuation.
Step 2 It is suspected that the poor quality of optical signals is caused by the dirty optical fiber
connectors of the ONT (OT928). Clean the optical fiber connectors, and remove and then insert
the optical fiber connectors again. The fault, however, persists.
Step 3 Replace the ONT with another ONT (OT928) to conduct a test. The fault, however, persists,
which indicates that the hardware of the ONT (OT928) is normal.
Step 4 Check the fiber patch cord of the ONT (OT928). It is found that the connector of the fiber patch
cord does not match the optical fiber connector of the ONT. Though the connector of the fiber
patch cord is square, the color is different. After verification, the optical fiber connectors used
in the ONT (OT928) are green, square, and SC/APC.

Module
NOTE
The BOM is 14130252, and the name is Patch Cord, SC/APC-FC/PC, Singlemode-G.652, 3mm, 3m.
Step 5 Replace the fiber patch cord with a correct fiber patch cord (SC/APC-FC/PC). As a result, the
LED of the PON port is stable, and the ONT can register with the OLT normally.
----End

Currently, the type of the fiber patch cord used in the ONT (OT928) is seldom used in China,
but is mostly used abroad. Therefore, note that you should use the correct fiber patch cord.
The greatest difference between green and blue fiber patch cords is as follows: The
interconnection section between the fiber patch cord with green connectors and the OT928 is
oblique. The interconnection section between the fiber patch cord with blue connectors and the
ONT is plane, which can result in 3-6 dBm optical attenuation.
7.1.5.3 TC-C6207 ONU Frequent Going Online and Offline Because of

Mismatching Fiber Connector
This topic describes how to troubleshoot the fault of ONU frequent going online and offline.
Fault Type
Keyword
Fiber connector
ONU frequent going offline
ONU frequent going online and offline
Fault Description
Network topology: Optical split level: one level; split ratio: 1:32; connector: SC/APC connector
In an office, an ONU frequently goes online and offline.
Alarm Information
LOSi alarm and LOFi alarm
Possible Cause

Module
Procedure
Step 1 Test the receive optical power on ONU optical ports. It is found that the receive optical power
is -27 dBm. This indicates that there is abnormal attenuation on ODN lines.
Step 2 Perform a test on the optical splitter. It is found that the connector of the optical splitter is an
SC/APC connector but that of the ONU fiber is an SC/PC connector. When an APC-endface
fiber is connected to a PC-endface fiber, at least 3 dB attenuation will be generated, as shown
in Figure 7-5.
Figure 7-5 Interconnection of PC and APC connectors
Step 3 Remove the SC/PC fiber (blue) and splice it to an SC/APC fiber (green). Test the ONU receive
optical power again. It is found that the receive optical power becomes -23.5 dBm, which is
within the normal range. This indicates that the mismatching fiber connector causes abnormal
attenuation on ODN lines and consequently causes the ONU to go online and offline frequently.
----End

It is recommended that you connect an SC/PC connector to an SC/PC connector (or an SC/APC
connector to an SC/APC connector). The biggest difference between an SC/PC connector and
an SC/APC connector lies in that the endface of an SC/PC connector is a plane but the endface
of an SC/APC connector is a slop. If an SC/PC connector is connected to an SC/APC connector,
at least 3 dB attenuation will be generated.
7.1.5.4 TC-C6208 ONU Frequent Going Online and Offline Because of a Too Small
Fiber Bend Radius
Fault Type

Module
Keyword
Bend radius
Fault Description
In an office, an ONU frequently goes online and offline.
Alarm Information
LOSi alarm and LOFi alarm
Possible Cause
Procedure
Step 1 Test the receive optical power on ONU optical ports. It is found that the receive optical power
is only -28 dBm. This indicates that there is abnormal attenuation on ODN lines.
Step 2 Check field conditions. It is found that fibers are placed disorderly, the fiber bend radius is too
small and the fiber is almost broken, as shown in Figure 7-6.
Figure 7-6 Too small fiber bend radius
Step 3 Replace the fiber and test the ONU receive optical power again. -18 dBm optical power is
obtained and services recover. This indicates that the too small fiber bend radius causes abnormal
attenuation on ODN lines and consequently causes the ONU to go online and offline frequently.
----End

Module

Make sure that the fiber bend diameter is larger than 8 cm when bending a fiber.
7.1.5.5 TC-C6214 ONU Frequent Going Online and Offline Because of a Too Large
Split Ratio
Fault Type
Keyword
Split ratio
Fault Description
Network topology: Originally, the system uses one-level optical split and the split ratio is 1:8.
Later, the customer connects a 1:16 optical splitter to the 1:8 optical splitter. The three ONUs
are connected to the 1:16 optical splitter.
During deployment in an office, three ONUs frequently go online and offline.
Alarm Information
None
Possible Cause
Procedure
Step 1 Test the ONU receive optical power. It is found that the receive optical power of the three ONUs
is approaching the sensitivity.
Step 2 Analyze the total split ratio of the three ONUs. It is found that the total split ratio is 1: (16 x 8)
= 1:128, which is too large and therefore causing too large attenuation, as shown in Figure
7-7.

Module
Figure 7-7 Too large split ratio
Step 3 Change the 1:16 optical splitter to a 1:4 one. Then, the fault is rectified.
----End

Bit errors will occur on an ONU if the ONU receive optical power is approaching the sensitivity
and even the ONU may go offline. Reserve a 3 dBm attenuation margin in ODN planning.
NOTE
The specifications of the optical path attenuation are as follows (the following are theoretical values and
the actual values vary with the environment):
l The optical attenuation on the ONU GPON port should be within the range of 15 dBm to 25 dBm.
l The attenuation on an optical fiber is about 0.3 dB per kilometer.
l The attenuation for an optical splitter is as follows:
l 1:2 optical splitter: 3 dBm
7.1.5.6 TC-C6217 ONU Frequent Going Online and Offline Caused by a Rogue
ONU
Fault Type
Keyword
Rogue ONU

Module
Fault Description
All ONUs connected to a port in an office frequently go online and offline after a flood.
Alarm Information
Rogue ONU alarm
Possible Cause
Procedure
Step 1 After communicating with the customer, we learn that there was once a flood in this office and
some ONUs are flooded.
Step 2 Analyze the condition. Only certain ONUs are flooded. This should not cause all ONUs to go
offline repeatedly. It is concluded that the optical modules of certain ONUs transmit signals
abnormally because of flood and the ONUs become rogue ONUs.
Step 3 Check optical lines one by one near the optical splitter. It is found that one ONU works in the
continuous mode, as shown in Figure 7-8.
Figure 7-8 Rogue ONU
Step 4 Replace the ONU. System services recover.

----End

In normal conditions, ONU signal transmit timeslots are controlled by the OLT. A rogue ONU
is an ONU that goes out of control of the OLT and works in the continuous mode or irregular

Module
mode. You can locate a rogue ONU manually or locate a rogue ONU by querying alarms
generated on the OLT. If a rogue ONU is detected, replace it in time.
7.1.6 Other ONU Faults

This topic describes how to troubleshoot other common ONU faults.
7.1.6.1 TC-C6008 Alarms About the Loss of GEM Cells Are Generated on an OLT
Because of Very Large Receive Optical Power of an ONT
This topic describes how to troubleshoot the fault when alarms about the loss of GEM cells are
generated on an OLT because the receive optical power of an ONT is very large.
Fault Type
ODN
Keyword
Optical power
Fault Description
An ONT in an office works normally and can register with an OLT normally. Alarms such as
the loss of GEM cells, however, are generated on the OLT.
Alarm Information
l Loss of GEM cells
l Recovery of GEM channels
l Deterioration of ONU signals
Cause Analysis
The ONT is connected to the OLT through optical fibers directly. As a result, the receive optical
power of the ONT is very large, which is beyond the normal range of optical modules. Therefore,
the cycle from the loss of optical signals, to the recovery of optical signals, and then to the
deterioration of optical signals repeats.
Procedure
Step 1 Check the optical fiber connection and it is found that the ONT is directly connected to the OLT
through an optical fiber. Therefore, the optical power for the transmission between the OLT and
the ONT may be excessively high.
Step 2 Add an optical splitter between the ONT and the OLT. After the ONT is registered, the alarm
disappears.
----End

Module

An ONT cannot be connected to an OLT directly. Optical attenuators or optical splitters must
be added between them to ensure that the optical path attenuation ranges from 15 dB to 25 dB.
NOTE
The specifications of the optical path attenuation are as follows:

l The optical attenuation on the GPON port on the ONT should range from 15 dB to 25 dB.
l The optical attenuation of an optical fiber is about 0.3 dB per kilometer.
l After optical signals travel through an optical splitter, the attenuation of the optical signals is as follows:
l 3dB if the splitter is a 1:2 optical splitter.
l 6 dB if the splitter is a 1:4 optical splitter.
7.1.6.2 TC-C6052 Login to the ONU Through the Maintenance Network Port for
Deployment Upgrade Fails Due to the Mismatch of the ARP Mapping
This topic describes how to troubleshoot the fault when login to the ONU through the
maintenance network port for deployment upgrade fails due to the mismatch of the ARP
mapping.
Fault Type
Host service
Keyword
ARP mapping
Maintenance network port
Fault Description
The ONU is connected to a PC with the IP address 10.11.104.1/24. Login to the ONU from the
PC through default maintenance network port 0/1/1 fails, and the IP address 10.11.104.2/24 of
the ONU cannot be pinged through from the PC. Through the serial port, however, login to the
ONU is successful.
Alarm Information
None
Cause Analysis
l The board of the ONU is faulty.
l The maintenance network port of the ONU is incorrectly configured.
l The network configuration of the PC is incorrect.

Module
Procedure
Step 1 Log in to the ONU through the serial port. It is found that the boards of the ONU are in the
normal state.
Step 2 Query the configuration of the maintenance network port of the ONU. It is found that the
configuration is correct.
Step 3 Query the status of the maintenance network port. It is found that the maintenance network port
is in the normal state.
Step 4 Query the ARP table on the PC. It is found that the MAC address corresponding to 10.11.104.2
is 00-18-82-77-1c-c0, which is different from the MAC address 0018-8277-1d02 of the ONU.
This is the cause of the fault. The MAC address corresponding to 10.11.104.2 is the MAC address
of the previous ONU rather than the current ONU.
C:\Documents and Settings\Administrator>arp -a
Interface: 10.11.104.1 --- 0x2
Internet Address Physical Address Type
10.11.104.2 00-18-82-77-1c-c0 dynamic
Step 5 Run the arp -d command to delete the previous ARP mapping. Login to the current ONU is
successful, and the fault is rectified.
----End
Suggestion and Summary

Generally, a mapping in the ARP table is automatically invalid five or ten minutes after the
mapping is not used. Before the previous mapping is invalid, login to the current ONU from the
PC fails.
7.1.6.3 TC-C6054 Data Cannot Be Saved on the ONU Because the H.248 Interface Is
Not Registered
This topic describes how to troubleshoot the fault when data cannot be saved on the ONU because
the H.248 interface is not registered.
Fault Type
VoIP service
Keyword
H.248 interface
Data saving
Fault Description
During the data saving on a new deployed ONU, it is found that the system prompts a saving
failure when the saving process reaches 90%.
Alarm Information
None

Module
Cause Analysis
l The CPU usage is high when the system executes certain tasks, which results in the saving
failure.
l The H.248 interface is abnormal.
Procedure
Step 1 Query the CPU usage before running the command for saving data. It is found that the CPU
usage is normal. Therefore, the fault is not caused by the high CPU usage.
Step 2 Through multiple tests, it is found that when data saving fails, the H.248 interface is in the down
state; when data saving is successful, the H.248 interface is in the up state.
Step 3 Query the configuration of the H.248 interface. It is found that the transmission mode of the H.
248 interface is alf/udp. After the transmission mode is modified to udp, data can be saved
regardless of whether the H.248 interface is in the up or down state.
NOTE
When the transmission mode of the H.248 interface is configured as alf/udp, the status of H.248 interface is
detected because alf/udp has the transaction reliability function. With this function, when the H.248 interface
is not registered, the system regards the H.248 interface as abnormal, and therefore does not allow the data
saving.
----End

During the deployment, when the ONU is configured, it is recommended that the MG interface
be configured with the udp transmission mode. After the ONU runs in the normal state, the alf/
udp transmission mode can be selected.
7.1.6.4 TC-C6120 Many Users Under the Same PON Port Have Dialing Error 678
Because Optical Power Is Too Strong
This topic describes how to troubleshoot the fault when many users under the same PON port
have dialing error 678.
Fault Type
ONU
Keyword
Too strong optical power
Dialing error 678
Fault Description
Network topology: PC -> ONU (MA5616) -> OLT (MA5600T) -> BRAS
Fault description: Four ONUs (MA5616s) are connected to a PON port. Since deployment, all
users under some ONUs or under all ONUs connected to the PON port have been reporting
dialing error 678. The ONUs with dialing error 678 cannot be logged in remotely. In addition,
the ONUs cannot be pinged from the OLT.

Module
Alarm Information
None
Cause Analysis
l The optical splitter is faulty.
l The PON port on the OLT is faulty.
Procedure
Step 1 Because all ONUs under the PON port have this fault intermittently. Therefore, it can be
determined that the fault is not caused by a single ONU.
Step 2 Replace the optical splitter with a new one. It is found that the fault persists. Therefore, it can
be determined that the fault is not caused by the optical splitter.
Step 3 Connect the ONU to the PON port on another board of the OLT. It is found that the fault persists.
Therefore, it can be determined that the fault is not caused by the PON port of the OLT.
Step 4 Check the optical path. The distance from an ONU to the OLT is about 1700 m. The measured
Rx optical power on the primary PON port of the optical splitter is about 2 dB; the measured Rx
optical power on each ONU port is about -6.3 dB. As indicated in documentation, the Rx optical
power of the PON port on the ONU should be from -8 dB to -24 dB. However, the Rx optical
power of any of these ONUs exceeds -8 dB. Therefore, the optical power may be too strong.
Step 5 Add a 5 dB optical attenuator on the primary PON port of the OLT. Then, the measured Rx
optical power of the ONU becomes about -12 dB. Observation for about a week shows that none
user under the PON port reports dialing error 678 again. That is, this fault is rectified.
----End

If the optical power is very strong, the ONU cannot receive optical signals normally.
7.1.6.5 TC-C6307 A Large Number of Alarms Are Generated on the OLT Because
the Optical Power for the Transmission Between the OLT and the ONT Is
Excessively High
This topic describes how to troubleshoot the fault when a large number of alarms are generated
on the OLT because the optical power for the transmission between the OLT and the ONT is
excessively high.
Fault Type
GPON service
Keyword
Optical Power Is Excessively High

Module
Fault Description
The ONT (HG850) can be registered but the alarms reported continuously on the OLT side.
Alarm Information
The alarms of GEM cell loss, GEM channel recovery, and ONU signal attenuation are reported
continuously on the OLT side.
Cause Analysis
l The ONT is faulty.
Procedure
Step 1 Check the optical fiber connection and it is found that the ONT is directly connected to the OLT
through an optical fiber. Therefore, the optical power for the transmission between the OLT and
the ONT may be excessively high.
Step 2 Add an optical splitter between the ONT and the OLT. After the ONT is registered, the alarm
disappears.
----End

An ONT cannot be connected to an OLT directly. Optical attenuators or optical splitters must
be added between them to ensure that the optical path attenuation ranges from 15 dB to 25 dB.
NOTE
The specifications of the optical path attenuation (the following are theoretical values and the actual values vary
with the environment) are as follows:
l The optical attenuation on the GPON port on the ONT should range from 15 dB to 25 dB.
l The optical attenuation of an optical fiber is about 0.3 dB per kilometer.
l After optical signals travel through an optical splitter, the attenuation of the optical signals is as follows:
l 3dB if the splitter is a 1:2 optical splitter.
7.1.6.6 TC-C6209 Too Many Bit Errors on an ONU Because of Poor Fiber Splicing
This topic describes how to troubleshoot the fault of too many bit errors on an ONU.
Fault Type
Keyword
Fiber splicing

Module
Bit error
Fault Description
branch fiber: 1 km long
In an office, too many bit errors are detected on an ONU.
NOTE
Run the display statistics ont-line-quality command to query quality statistics of ONU lines. If this
command is executed for multiple times, the ONU bit error statistics increase, indicating that the ONU has
bit errors.
Alarm Information
None
Possible Cause
Procedure
Step 1 Test the ONU receive optical power. It is found that the power is -27.3 dBm. Test the downstream
optical power of the optical splitter. It is found that the power is -17 dBm, indicating that there
is abnormal attenuation on ODN lines.
Step 2 Check the optical fiber between the optical splitter and the ONU (the optical fiber is only 1 km
long). No optical connector is found, indicating that the attenuation on the optical fiber may be
caused by fiber splicing.
Step 3 Perform a test using a red pointer. It is found that severe transient interruption of optical signals
occurs on the splicing points. Open the splice box. Visible beads are found on the splicing points,
as shown in Figure 7-9.
Figure 7-9 Poor fiber splicing

Module
Step 4 The system runs normally in the next week after re-splicing, and the ONU normally goes online.
----End

Check splicing quality after a fiber is spliced. Make sure that the splicing loss is smaller than
0.1 dB.
7.1.6.7 TC-C6226 ONT Can Be Successfully Pinged but the Web Page Cannot Be
Logged in After the ONT Is Upgraded
This topic describes how to troubleshoot the fault when the web page of the ONT cannot be
logged in.
Fault Type
Terminal management
Keyword
Web page, ONT login failure
Fault Description
After the HG813e is upgraded to V200R001C00SPC006, the ONT can be pinged locally, but
the web page of the ONT cannot be logged in.
Alarm Information
None
Possible Cause
The Internet Explorer prohibits the ActiveX controls required to log in to the web page.
Procedure
Step 1 Start the Internet Explorer.
Step 2 On the main menu, choose Tools > Internet Options. The Internet Options dialog box is
displayed.
Step 3 On the Security tab page, click Custom level. The Security Settings dialog box is displayed.
Step 4 Set Initialize and script ActiveX controls not marked as safe for scripting to Enable, as

Module
Figure 7-10 Enabling the ActiveX controls
Step 5 Log in to the web page of the HG813e again. The fault is rectified.
----End

None
7.2 Troubleshooting Cases of Internet Access Service Faults

The Internet access service failure is a fault in which users provided with the Internet access
service cannot obtain network resources. For example, they cannot open a Web site.
7.2.1.1 TC-C6371 Failure to Access the Internet for the Leased Line User Caused by
Improper ACL Configuration
This topic describes how to troubleshoot the fault when the leased line user cannot access the
Internet because of the incorrect ACL configuration.
Fault Type
ACL service

Module
Keyword
ACL
Fault Description
Networking: PC -> Modem -> ONU -> OLT -> BRAS.
A user can access the Internet successfully in the PPPoE dialup mode, but the new leased line
user (static user without dialup) fails to access the Internet.
Alarm Information
None
Cause Analysis
l The configuration on the BRAS is improper.
Procedure
Step 1 Check whether the BRAS data configuration is correct. Disconnect the OLT from the PC, and
configure the same VLAN on the Layer 3 switch and the OLT (replace the OLT with the Layer
3 switch for networking). Perform a test when the PC is configured with a static IP address. It
is found that the service provisioning is in the normal state. This indicates that the user data on
the BRAS is correct.
Step 2 Check whether the data configuration of the OLT is correct. Connect the OLT to the PC again,
and ping the gateway (BRAS) by using the static IP address. The operation fails. Trace the
packets on the BRAS. It is found that no data packets are reported. It can be determined that the
OLT is faulty.
Step 3 Check the configuration of the OLT. The following QoS and ACL configurations are displayed:
acl number 2000
rule 5 deny
rule 10 permit source 1.1.1.1 0
packet-filter inbound ip-group 2000 rule 5 port 0/19/0
The upstream port 0/19/0 allows only the IP packets with source IP addresses 1.1.1.1 and 2.2.2.2
to pass because of these QoS and ACL configurations, and discards other IP packets. In this
case, the Internet access packets of the static user are discarded.
The packets with the standard IPoE encapsulation mode can be processed, and the packets with
the PPPoE encapsulation mode cannot be processed because the basic ACLs (2000-2999) are
used for the IP packets. In this case, these ACLs do not take effect on the PPPoE dialup user.
Step 4 From the carrier, the troubleshooting engineers obtain the information that the OLT provides a
Layer 3 interface as the interface of the inband BMS and the telnet. To avoid illegal access to
the OLT, the preceding configurations are performed. Only multiple fixed IP addresses, such as
1.1.1.1 and 2.2.2.2 can access the OLT. Nevertheless, the packets of the legal Internet access
user are filtered because of the incorrect ACL configuration. Therefore, the solution is to modify
the ACL and to configure more accurate filtering criteria.

Module
To avoid illegal access to the OLT, make sure that the destination IP address of the packets to
be filtered is the IP address (3.3.3.3) of the Layer 3 interface on the OLT. Therefore, the
destination IP address, as a filtering criterion, can be added to the ACL rule. The advanced ACL
should be used because the basic ACL uses only the source IP address as the filtering criterion.
Modify the configuration as follows:
acl number 3000
rule 5 deny ip destination 3.3.3.3 0
rule 10 permit ip source 1.1.1.1 0 destination 3.3.3.3 0
rule 15 permit ip source 2.2.2.2 0 destination 3.3.3.3 0
Step 5 Add a leased line user to perform a test. It is found that the Internet access service is in the normal
state.
----End

When configuring the QoS and the ACL, analyze the features of multiple packets carefully and
configure the ACL rules accurately so that the leased line user does not fail to access the Internet
because of the incorrect ACL configuration.
7.2.1.2 TC-C6372 Traffic-Limit Failure Caused by Incorrect Sequence of QoS

Actions
This topic describes how to troubleshoot the fault when the traffic-limit fails because of incorrect
sequence of the QoS actions.
Fault Type
Other
Keyword
QoS
Traffic-limit
Fault Description
The configuration on the OLT:
acl number 2000
traffic-limit inbound ip-group 2000 rule 5 64 exceed drop port 0/19/0
traffic-limit inbound ip-group 2000 rule 10 128 exceed drop port 0/19/0
Then, the carrier sends packets from the user port located in slot 0/3. The traffic of the packets
whose source IP addresses are 1.1.1.1 and 1.1.1.2 is 512 kbit/s. Capture packets on upstream
port 0/19/0. It is found that the traffic of the captured packets exceeds 64 kbit/s and is equal to
the traffic of the sent traffic. This indicates that the traffic-limit does not take effect.

Module
Alarm Information
None
Cause Analysis
l The ACL configuration is improper.
Procedure
Step 1 It is suspected that the packets sent from the user may not match the ACL, which invalidates the
traffic-limit. The packets, however, captured by the carrier indicate that the packets are correct.
Step 2 Analyze the user configuration. It is found that the following QoS configurations exist besides
the traffic-limit:
acl number 2001
rule 5 deny
rule 10 permit source 1.1.1.0 0.0.0.255
Step 3 The configuration sequence obtained from the carrier indicates that the traffic-limit is configured
before the packet-filter is configured. In this case, the cause of the fault is that the traffic-limit
and the packet-filter conflict with each other. The action taken by the traffic-limit to the packets
that exceed the preset traffic value is "deny". If the packets match the "permit" action of the
packet-filter, the packets to be discarded are forwarded again.
Step 4 Delete the packet-filter configuration, or adjust the configuration sequence, that is, deliver the
packet-filter before the traffic-limit is delivered.
Step 5 Capture packets on the upstream port 0/19/0. It is found that the two methods are correct.
----End

If the traffic-limit is delivered before the packet-filter is delivered, the packets used in the test
match the two ACLs. In this case, the "deny" action of the traffic-limit is overwritten by the
"permit" action of the packet-filter according to the QoS matching sequence, that is, an action
delivered later has a higher priority. Then, the traffic-limit does not take effect.
If you need to configure multiple QoS actions, analyze whether the QoS actions conflict with
each other, and then determine the configuration sequence.

Going offline frequently is a fault that users go offline frequently in connecting to the Internet.
7.2.2.1 TC-C6186 MA5626G PPPoE Users Go Offline Abnormally After the Anti-
MAC Spoofing Is Enabled on the MA5626G
This topic describes how to troubleshoot the fault when the MA5626G PPPoE users go offline
abnormally.

Module
Fault Type
Authentication service
Keyword
MA5626G, anti-MAC spoofing
Fault Description
Network topology: MA5626G -> MA5600T -> ME60
PPPoE users connected to the MA5620G go offline abnormally.
Alarm Information
None
Cause Analysis
l The link is of poor quality and packets are lost.
l The ME60 authentication is faulty.
l The data configurations of the MA5600T and MA5626G are incorrect.
Procedure
Step 1 Ping the gateway from the user side. It is found that no packet is lost. This indicates that the
network is of good quality.
Step 2 Capture packets on the ME60. It is found that the ME60 issues PADT to forcedly enable the
PPPoE to go offline if it does not receive PPPoE replay packet for three consecutive times. This
indicates that the ME60 authentication is correct and the fault occurs between the user side and
ME60.
Step 3 Capture packets on the MA5626G. It is found that its service ports receive packets normally but
the upstream port drops the PPPoE reply packet returned by the user. This indicates that the
MA5626G encounters a fault.
Step 4 Run the display security config command to check configurations of the MA5626G. It is found
that parameter Anti-macspoofing function is set to enable, which indicates that the anti-MAC
spoofing function is enabled. Therefore, the upstream traffic is checked. If the traffic is not
changed, the user is forced to go offline. When the upstream traffic statistics exceed 4294967295,
traffic overturn occurs. As a result, the user is forced to go offline.
Step 5 Disable the anti-MAC spoofing function of all MA5626Gs. Then, the fault is rectified.
----End

The security anti-macspoofing is disabled by default. The fault occurs because security anti-
macspoofing is enabled at the initial stage of engineering.

Module

Low Internet access rate is a fault that the Internet access rate of a user is far lower than the
provided Internet access rate.
7.2.3.1 TC-C6031 Failure to Open Web Pages Due to Configuration Inconsistency

of the Link Aggregation
This topic describes how to troubleshoot the fault when subscribers connected to the ONU
sometimes fail to open the web pages due to the configuration inconsistency of the link
aggregation between the OLT and the peer device.
Fault Type
Internet service
Keyword
Link aggregation
Fault Description
Subscribers connected to the ONU fail to open the web pages sometimes. The voice services
and the NMS are normal.
Alarm Information
None
Cause Analysis
l The traffic configuration on the ONU is incorrect.
l The network connection is abnormal.
l The OLT configuration is incorrect.
Procedure
Step 1 Check the traffic profile index of the ONU, and query the configuration of the traffic profile. It
is found that the configuration is correct.
Step 2 Ping the domain name of a Web site. The ping operation sometimes fails. In detail, when the
ping operation is successful, no packet loss occurs if the ping operation lasts long. If the ping
operation is interrupted and then continued, the ping operation fails. After a while, the ping
operation is successful. This problem occurs irregularly.
Step 3 Query the OLT configuration. It is found that the aging time of the MAC address is set to 10s.
Therefore, the fault may be caused by the short aging time of the MAC address. Change the
aging time to 300s. The fault, however, persists.
Step 4 Ping the gateway address of the upper-layer device connected to the OLT from a PC. The ping
operation is always successful. It can be preliminarily determined that the upper-layer device
connected to the OLT is abnormal.

Module
Step 5 Check the OLT. It is found that two ports on the OLT are used for upstream transmission. One
port, however, is not configured with any data, and it is just online. Later, it is found that the
link aggregation is configured on the upper-layer device connected to the OLT. The link
aggregation, however, is not configured on the OLT. Remove the optical fiber connected to the
port with no data configured. The fault then is rectified.
----End

The fault is completely rectified when the link aggregation is configured on the OLT. At the
same time, the network reliability is improved.
The gateway address of the upper-layer device can be pinged successfully, but why the Web site
domain name cannot be pinged from time to time? It is related to the load sharing mechanism
of the upper-layer device.
l When the gateway address of the upper-layer device is pinged, the source MAC address
and the destination MAC address are fixed. Therefore, there are only two results, ping
success and ping failure.
l When the Web site domain name is pinged, the destination MAC address is not fixed
because a Web site can have multiple servers. As a result, the ICMP packet may be returned
through the link of the other port, and thus the ping operation fails on a probability basis.
7.2.3.2 TC-C6118 Internet Cafe User of an ONT Encounters Great Delay Because
the QoS Policy of the Upper-Layer Switch Is Incorrect
This topic describes how to troubleshoot the fault when the Internet cafe user of an ONT
encounters great delay.
Fault Type
Internet access service
Keyword
HG850E
Delay
QoS
Fault Description
Network topology: Internet cafe user -> ONT (HG850) -> OLT (MA5600T) -> LAN switch ->
BRAS
Version: MA5600T (V800R006C02SPC100+SPC106), HG850 (V100R001C05SPC062)
Data plan: The ONT uses the static IP address, the upstream/downstream rate limit of 8 Mbit/s
for users is set on the upper-layer switch, and the DBA profile uses the fixed bandwidth of 32
Mbit/s.
Fault description: Internet cafe users of ONTs in multiple offices of XX Telecom encounter the
great delay. By pinging the upper-layer gateway from the PC in the Internet cafe, it is found that
the delay is volatile 150 ms, or even greater.

Module
Alarm Information
None
Cause Analysis
l The ONT hardware is faulty.
l The hardware of the PON board of the OLT is faulty.
l The ONT performance is poor.
l Configurations of the upper-layer device are incorrect.
Procedure
Step 1 Replace the ONT. It is found that the fault persists. Thus, the fault is not caused by the ONT
hardware fault.
Step 2 Connect an ONU (MA5620) to the PON port of the ONT that is faulty. Enable the Layer 3
interface and ping BRAS from the MA5620 by sending 1000 packets. It is found that packets
are not lost and the delay is within 2-3 ms. This indicates that the fault is not caused by the
hardware fault of the PON board of the OLT.
Step 3 Perform testing in the laboratory. The network is Smartbits -> ONT -> OLT -> Smartbits. It is
found that the delay is about 0.5 ms. In another test of the network in which the ONT is connected
to the PC, transmit 2000 variable-length traffic streams of 80 Mbit/s from the Smartbits to the
ONT and ping the OLT from the PC. It is found that the delay is within 1-2 ms. This indicates
that the fault may be not caused by the poor ONT performance.
Step 4 Bring the Smartbits to the Internet cafe that encounters the fault. Connect one more ONT to the
same PON port of the ONT that is fault and configure the two ONTs to be the same. Transmit
traffic of 7 Mbit/s from the Smartbits and ping the BRAS. It is found that the delay is within 2-3
ms (within the normal range). This indicates that the fault is not caused by the poor ONT
performance.
Step 5 Coordinate the user to check configurations of the upper-layer device. It is found that the QoS
policy of the upper-layer switch is set to best-effort, which leads to great delay in the case of the
burst traffic. When the QoS policy of the upper-layer switch is set to discard, the fault is rectified.
NOTE
The QoS policy of the upper-layer switch can be set to discard and best-effort. These two policies are
different when used in the Internet cafe scenario.
l If the QoS policy of the upper-layer switch is set to discard, when the bust traffic exceeds the rate limit,
the over-limitation traffic is discarded. This leads to packet loss in the case of the burst traffic.
l If the QoS policy of the upper-layer switch is set to best-effort, when the bust traffic exceeds the rate
limit, the over-limitation traffic is saved into the buffer and then is forwarded. This leads to delay in
the case of the burst traffic.
The Internet cafe user is sensitive to the delay; therefore, it is recommended that you set the QoS policy of
the upper-layer switch to discard.
----End

The network in which an ONT is connected to the Internet cafe user is not recommended. It is
recommended that you replace the ONT of the HG series with the ONU.

Module
7.2.3.3 TC-C6386 Low Downloading Speed Cause by Disabled MAC Address

Aging Function
This topic describes how to troubleshoot the fault when the downloading speed for the ADSL
users is low because the MAC address aging function is disabled.
Fault Type
Other
Keyword
MAC Address Aging
Fault Description
Networking: OLT C -> OLT B -> OLT A -> Convergence switch -> BRAS
Every three of nine OLTs are cascaded as a group. Then, the three groups are connected to the
convergence switch. Two groups work in the normal state but the three OLTs in the third group
suffer a low network rate. Pinging the gateway from the three OLTs with a low network rate
shows that the delay is 2 ms, and loss of packets does not occur.
Alarm Information
None
Cause Analysis
l The configuration on the upper-layer device is improper.
Procedure
Step 1 Check whether the other six OLTs are in the normal state. If the other six OLTs are normal, it
indicates that the fault is not caused by the upper-layer devices of the convergence switch.
Step 2 Restart OLT A. It is found that the fault does not reoccur for a couple of days. It indicates that
OLT A is faulty.
Step 3 Log in to OLT A and check the port negotiation configuration and the statistics.
l Check the negotiation result on the upstream port of OLT A. It is found that the result of the
negotiation is full-duplex mode, which is proper.
l Check the statistics of the received and transmitted packets. It is found that the number of
discard frames increases dramatically, but the phenomenon does not occur on other normal
nodes. The discarding of frames may be caused by the low downloading speed.
Step 4 Check the MAC address table. It is found that the MAC address table is abnormal: The MAC
address aging time is set to No aging. xxxx-0198-7600, as the MAC address of the BRAS, is
learned by multiple service ports. Change the MAC address aging time to 300s (the default
value). Wait for 10 minutes and check the MAC address table again. It is found that the MAC
address table recovers. Only the upstream board learns the MAC address of the BRAS. The

Module
number of discard frames on the upstream port stops increasing. The downloading speed
recovers.
----End

The cause of the fault is that the MAC address aging time is set to No aging. In the case of the
configuration of the basic functions such as the MAC address, it is recommended that you use
the default values (except for special requirements), which should not be modified at discretion.
7.2.3.4 TC-C6187 Some Users of the MA5600T Fail to Access the Internet or Have
Low Internet Access Rate Because of Conflicted MAC Addresses
This topic describes how to troubleshoot the fault when some users fail to access the Internet or
have low Internet access rate.
Fault Type
Low Internet access rate
Keyword
Hash, low Internet access rate
Fault Description
Network topology: ONU -> OLT (MA5600T)
More than 1000 users are connected to a PON port of the MA5600T through ONUs. Some users
fail to access the Internet or have low Internet access rate.
Alarm Information
None
Possible Cause
Packet loss occurs on the network.
Procedure
Step 1 Check the LSW packet statistics. It is found that a large number of packets are lost.
BCM.0> show c xe15
RDBGC0.xe15 : 3,350 +3,350 1,610/s //There are 1610 packets are lost per
second.
Step 2 Disable downstream unknown unicast suppression. It is found that packets are not lost.
Step 3 Check the number of MAC addresses learned on the LSW. It is found that more than 8K MAC
addresses are learned.
huawei(config)#display mac-address number
It will take some time, please wait...
Number of static MAC configed : 0
Number of other MAC: 8479

Module
Step 4 It is determined that the fault occurs because some MAC addresses are not learned and
downstream packets are processed as unknown unicast packets. In this case, disable unknown
unicast suppression. It is found that the fault is rectified temporarily.
----End

The SCUL control board learns up to 16K MAC addresses and the LSW uses the hash algorithm
to learn MAC addresses. The hash algorithm has hash collision. Therefore, when 8K MAC
addresses are learned, there is a high probability of hash collision, leading to failure to learn
some MAC addresses. When the LSW fails to learn MAC addresses, the downstream unicast
packets are forwarded as unknown unicast packets and some packets are dropped because of
unknown unicast suppression. In this case, some users fail to access the Internet or have low
Internet access rate.
Disabling unknown unicast suppression troubleshoots the fault temporarily. To troubleshoot the
fault fundamentally, modify the network. For different live network scenarios, perform
corresponding operations.
l For live networks, use the SCUL control boards and perform the following operations:
1. Run the undo traffic-suppress command to cancel unknown unicast suppression of
the upstream port.
NOTE
In this way, the downstream packets of users whose MAC addresses are not learned by the
LSW will not be suppressed. However, this may cause the problem that the LSW broadcasts
unknown unicast packets downstream in the VLAN. If service boards A and B are in the same
VLAN, packets sent to service board A are copied to service board B and therefore occupy the
downstream bandwidth of service board B.
2. Divide SVLANs based on PON board for some services to prevent unknown unicast
packets from occupying downstream bandwidths of other service boards, as described
in Table 7-1.
NOTE
The logic of a PON board learns MAC addresses; therefore, unknown unicast packets are
forwarded as known unicast packets on service boards.

Module
Table 7-1 Type of services dividing SVLANs based on PON board
Service Type Optimization Proposal
Voice service Voice services of the entire subrack use a unified SVLAN.
That is, SVLAN division based on PON board is not required.
l Voice users do not go offline generally, so their MAC
addresses preferentially occupy L2 entries and are not
aged. In this case, there is a low probability of MAC
address learning failure.
l If a certain MAC address cannot be learned because of hash
collision, the downstream packets are broadcast on all
service boards. However, the light-traffic-volume
broadcast downstream packets slightly affect downstream
bandwidths of service boards.
l Few voice packets that are not of the ONU connecting to
GPBD are forwarded to the ONU and the ONU identifies
such packets and drops them.
Broadband service SVLANs need to be divided based on PON board.
IPTV multicast service SVLANs do not need to be divided based on PON board.
(multicast service This is because multicast streams are forwarded based on
channel) multicast VLAN and are not affected by MAC address
learning.
VoD multicast service SVLANs need to be divided based on PON board.

(unicast service
channel)
l For new sites, use the SCUN control boards (LSW 56820).
NOTE
Up to 32K MAC addresses can be can be learned and the LSW chip supports dual hash leaky buckets
and reordering in hash collision. According to the Broadcom (BRCM) test result, in dual hash leaky
buckets and single-level collision reordering, when the hash collision occurs for the first time, the
L2 table usage is 72%. That is, there is a high probability of hash collision only when more than 20K
MAC addresses are learned by SCUN.
7.2.4 Failure to Obtain an IP Address in the PPPoE Dialing Mode

The IP address obtainment failure is a fault in which an IP address cannot be obtained in the
PPPoE Dialing mode.
7.2.4.1 TC-C6242 PPPoE Dialing Failure Caused by Abnormal ARP Packets of the
Set-Top Box
This topic describes how to troubleshoot the fault when PPPoE dialing fails.
Fault Type
Multicast service

Module
Keyword
IPTV dialing failure
Fault Description
Version: MA5616V800R306C01SPC021
The MA5616 is connected to a set-top box of a certain type through an ADSL modem. PPPoE
dialing sometimes fails. The dialing success rate is very low. This affects the use of the IPTV
service. When dialing fails, the MA5616 cannot learn the MAC address of the set-top box. PPPoE
dialing initiated by ordinary Internet users, however, succeeds.
Alarm Information
None
Possible Cause
l An error occurs in the MAC address learning of the MA5616.
l The quality of the external line of the user is poor.
l The modem is faulty.
l The set-top box is faulty.
Procedure
Step 1 The latest patch has been installed on the MA5616. In addition, PPPoE dialing initiated by
ordinary Internet users succeeds and the MAC address learning is also normal. This indicates
that the MA5616 is not faulty.
Step 2 Connect the MA5616 to a modem and conduct a test. The fault persists. This indicates that the
external line is not faulty.
Step 3 Replace the original modem with a modem of another type. The fault persists. This indicates
that the modem is not faulty.
Step 4 Capture packets between the set-top box and the original modem when the fault occurs. Replace
the original modem with a modem of another type. When the dialing service becomes normal,
capture packets between the set-top box and the new modem. Compare the packets captured in
two times. It is found that the original set-top box sends an ARP packet to the modem every five
seconds. This is a heartbeat detection mechanism of the original set-top box.
Step 5 Disable the heartbeat detection mechanism of the original set-top box. The dialing service
becomes normal.
----End

For the PPPoE dialing-based IPTV service, when dialing fails, find the related MAC address
based on the method for handling the fault of ordinary dialing users. Locate the fault by replacing
the relevant device. When necessary, capture and compare packets to handle the fault.

Module

The IP address obtainment failure is a fault in which an IP address cannot be obtained in the
DHCP mode.
7.2.5.1 TC-C6145 PC Fails to Obtain the DHCP-Allocated IP Address Because

Excessive Broadcast Domains Are Configured on the ONU
This topic describes how to troubleshoot the fault when the PC fails to obtain the DHCP-allocated
IP address.
Fault Type
Internet access service
Keyword
DHCP, broadcast domain, IP address obtainment
Fault Description
Network topology: PC -> ONU -> OLT (MA5600T) -> DHCP server -> Aggregation switch
Fault description: The OLT configured with firewall is connected to multiple ONUs. After
enabling the DHCP server and being configured with NAT, the OLT is connected to the MAN
aggregation switch. The PC cascaded to the ONU cannot obtain the IP address; however, if the
PC is configured with a static IP address in the DHCP IP address pool, the PC can ping the
gateway and access the Internet.
Alarm Information
None
Cause Analysis
Each user port of the ONU is allocated with a VLAN to achieve port isolation. In addition, ONU
VLAN is switched on the OLT to save VLAN resources. In this case, the OLT has excessive
broadcast domains. As a result, DHCP offer packets are lost.
Procedure
Step 1 Enable the debugging dhcp server packet on the firewall and capture packets. It is found that
the firewall has transmitted DHCP offer packets but the PC does not receive these packets.
Step 2 Capture packets by mirroring on the upstream port of the OLT. It is found that DHCP offer
packets reach the OLT but are not transmitted to the PC.
Step 3 Configure the data again. That is, configure a smart VLAN on each ONU to reduce broadcast
domains of the OLT. Then, test again. It is found that all the PCs can obtain IP addresses.
----End

Module

Ports in a smart VLAN are isolated. Therefore, isolation of user ports of an ONU can be achieved
by configuring a smart VLAN on the ONU.
7.2.5.2 TC-C6385 Failure to Access the Internet Because of Incorrect Configurations

of the DHCP Server
This topic describes how to troubleshoot the fault when the failure to access the internet because
of incorrect configurations of the DHCP server.
Fault Type
Ethernet service
Keyword
DHCP
Fault Description
A user fails to obtain the IP address. In such a case, check the packet statistics. It is found that
only the DHCP discover packets from the user are received, but the DHCP offer packets from
the DHCP server are not received. In addition, no packet is received on the BRAS.
Alarm Information
None
Cause Analysis
The configuration on the OLT is improper.
Procedure
Step 1 Check the link between user and OLT. It is found that the link is in the normal state.
Step 2 Check the link between the OLT and the BRAS. It is found that the link is in the normal state.
Step 3 Check the system configuration. It is found that the user VLAN is not bound to the DHCP server.
Step 4 Bind the DHCP server. It is found that the user obtain the IP address and successful access the
Internet.
----End

In this case, the operator once performed an operation for deleting the Layer 3 interface. After
a new Layer 3 interface is created, it is not bound to the DHCP server, which results in the loss
of the configuration. In practice, the majority of the faults relating to DHCP occur on the OLT.
Therefore, when finding such a fault, check the configuration of the OLT first.

Module

Dark screen after program ordering is a fault that a user cannot watch the program after the user
goes online and orders a program.
7.3.1.1 TC-C6050 Multicast Service Is Unavailable Due to Inconsistency Between

the User VLAN and the Multicast VLAN on the ONU
This topic describes how to troubleshoot the fault when the multicast service is unavailable
because the user VLAN is different from the multicast VLAN on the ONU.
Fault Type
Multicast service
Keyword
Multicast unavailable
Fault Description
Network topology: PC (installed with the VLC software to simulate the multicast client) –>
ONU (OT928) –> OLT (MA5600T) -> PC (installed with the VLC software to simulate the
multicast server)
Perform the test on site. It is found that when the user VLAN is the same as the multicast VLAN,
the multicast service is normal; however, when the user VLAN is different from the multicast
VLAN, the multicast service is unavailable, but the multicast subscribers are online.
Alarm Information
None
Cause Analysis
l The data configuration is incorrect, because the unicast service is normal but the multicast
service is unavailable.
l The setting of the VLC software is incorrect.
l The join packet fails to reach the multicast server, or the server does not respond normally.
l Certain security functions are enabled. As a result, the packets are intercepted.
Procedure
Step 1 The multicast service is normal when the user VLAN is the same as the multicast VLAN.
Therefore, it can be determined that the device can implement the multicast service. In addition,
the multicast subscribers are online when the multicast service is normal. Therefore, the multicast
service of the device is normal.

Module
Step 2 Modify the user VLAN, and modify the multicast configuration data accordingly. It is found
that the multicast subscribers are online, but the multicast program is not available on the PC
that functions as the multicast client. Then, modify the user VLAN to be the same as the multicast
VLAN. The multicast service returns to the normal state. Therefore, it can be determined that
the setting of the VLC software is correct.
Step 3 Capture packets on the PC that functions as the multicast client. It is found that no multicast
packet is received. Then, capture packets on the PC that functions as the multicast server. It is
found that the multicast packets are transmitted from the server.
Step 4 Based on the preceding two situations, it can be determined that the multicast media packets are
discarded on the way from the OLT to the ONU. Then, mirror the PON port and capture packets.
It is found that the media packets are issued. Therefore, the media packets are discarded on the
ONU side.
Step 5 It is known that the protocol packets and the media packets are transmitted through different
channels, that is, through different GEM ports. For ONU that does not have the VLAN
conversion function, the media packets still carry the multicast VLAN tag when reaching the
user port, and therefore the user port discards the data packets whose VLAN is different from
the native VLAN of the user port on the ONU. Therefore, the PC (multicast client) cannot receive
the multicast media packets, which causes the failure of the multicast service.
Step 6 Run the ont multicast-forword tag translation command to modify the multicast forwarding
mode of the ONU to translation. The multicast service returns to the normal state.
----End

For ONU that does not have the VLAN conversion function, the multicast service is implemented
on the ONU in the following three ways:
l The user VLANs and the multicast VLAN are the same (not recommended when the
broadcast domain is large because of the large number of subscribers).
l All user VLANs are the same, but are different from the multicast VLAN. In this case, the
multicast service is implemented by setting the multicast forwarding mode.
l A switch is connected to the ONU to remove or convert the VLAN tag. With the capability
of the switch, the multicast service can be implemented for multiple subscribers and
multiple VLANs concurrently.
7.3.1.2 TC-C6146 New Programs Cannot Be played Because the Multicast

Bandwidth on a PON Port of the OLT Is Limited
This topic describes how to troubleshoot the fault when new programs cannot be played.
Fault Type
Multicast
Keyword
Black screen, play failure, prejoin, multicast, bandwidth

Module
Fault Description
Network topology: PC -> ONU (MA5616) -> OLT -> (MA5600T) -> Multicast router ->
Multicast server
Fault description: A PC installed with the VLC software can play only certain programs and
certain programs are played as black screen.
Alarm Information
None
Cause Analysis
l Configurations of the upper-layer multicast server and multicast routers are incorrect and
multicast stream transmission is abnormal.
l The ONU configurations are incorrect or the patch loading operations are incorrect.
l The bandwidth of the link from the PON port of the OLT to the ONU is insufficient. As a
result, multicast streams are not transmitted downstream to the ONU.
Procedure
Step 1 Replace the MA5616 with the MA5620 that is configured with the multicast service and retain
configurations of other devices over the network. It is found that programs that cannot be played
originally can be normally played. This indicates that the fault is not caused by the upper-layer
multicast server or the multicast router.
Step 2 On the MA5616, run the display patch all command to query the software version. It is found
that the software version is correct, patch SPH009 is running, but the control board patch file
matching patch SPH009 is not loaded. Then, load the matched control board patch file. It is
found that the fault persists.
Step 3 On the MA5616, enable the debugging function, capture the corresponding IGMP packets, and
play one of the multicast programs playing as black screen. It is found that in the played
information about the captured IGMP report packets, the IP address of the multicast program is
239.252.1.138 but this static multicast program is not configured on the MA5616. In this case,
run the igmp program add command on the MA5616 to configure this program. It is found
that the fault persists.
Step 4 On the MA5616, run the display igmp user all command to query the user status. It is found
that the user is online. On the MA5600T, run the display igmp program all command to query
the number of users that watch program 239.252.1.138. It is found that no user watches the
program. This indicates that multicast streams are not transmitted to the MA5616.
Step 5 On the MA5600T, run the display igmp bandwidth port command to query the multicast
bandwidth. It is found that the maximum multicast bandwidth is about 716.8 Mbit/s and
bandwidth 715 Mbit/s has been used.
Step 6 On the MA5600T, run the display igmp cascade-port command to query the number of online
programs on a cascading multicast port. It is found that 143 programs are online. In addition,
bandwidth of about 715 Mbit/s has been used. This indicates that each program occupies about
5 Mbit/s. The MA5616 is configured with the prejoin function when configuring the static
multicast program. That is, the multicast program pre-joins the upper-layer device. With the
prejoin function, when being added with a new multicast program, the MA5616 transmits the
report packet to the OLT. In this case, no matter whether a user orders the program, multicast

Module
streams are transmitted to the upstream port of the MA5616 in advance. Then, the MA5600T
assigns fixed bandwidth of 5 Mbit/s to each multicast program by default. Program prejoin
greatly occupies the multicast bandwidth between the MA5600T and the MA5616. As a result,
the remaining multicast bandwidth is less than 5 Mbit/s and the newly added programs cannot
be played.
Step 7 Configure all programs again and disable the prejoin function. It is found that all the programs
are played normally and the fault is rectified.
----End

The OLT limits the multicast bandwidth on a PON port. By default, the maximum multicast
bandwidth of a PON port is about 716.8 Mbit/s. When a large number of static multicast programs
are configured on an ONU, not all of the programs are enabled with the prejoin function so that
the bandwidth load can be prevented.
7.3.1.3 TC-C6327 Failure to Watch Programs Caused by the Improper TTL of the
Multicast Stream
This topic describes how to troubleshoot the fault when a user fails to watch programs because
of the improper TTL of the multicast stream.
Fault Type
Multicast service
Keyword
TTL
Fault Description
A user uses the VLC video software to watch programs, but fails to watch the programs. The
engineers capture data packets on the PC. It is found that the IGMP report packets are sent out,
but no multicast stream is received.
Alarm Information
None
Cause Analysis
Check the traffic statistics on the upstream port of the OLT. It is found that a large number of
multicast packets are received. The possible cause is that the TTL is set improperly in the
multicast source because the effect of the network on the TTL is not considered.
Procedure
Step 1 Capture data packets from the switch on the multicast server side. It is found that the multicast
stream is sent to the backbone network. Run the display port statistics command on the OLT
to query the traffic statistics of the upstream port. It is found that a large number of multicast

Module
packets are received on the upstream port. Run the display statistics command to query the
traffic statistics of the service port. It is found that only a few packets are received (possibly
IGMP request packets). It can be determined that the multicast packets are discarded after they
are sent to the OLT.
Step 2 Connect the OLT to the multicast server directly. It is found that ordering programs is successful,
which indicates that the packets are not discarded by the OLT.
Step 3 Capture data packets between the backbone network and the OLT, and compare the packets with
the multicast packets sent from the multicast server. It is found that the TTL of the multicast
packets sent to the upstream port of the OLT is zero. When the OLT forwards the multicast
packets to the user side, a hop is decreased. Therefore, it can be determined that the TTL is set
improperly in the multicast source.
Step 4 On the multicast server, increase the TTL of the multicast stream by 1. Order programs again.
It is found that the user can order programs through the OLT and the fault is rectified.
----End

None
7.3.1.4 TC-C6330 Failure to order programs Caused by No Configuration of the Host

IP Address
This topic describes how to troubleshoot the fault when a user fails to order programs because
the host IP address is not configured.
Fault Type
Multicast service
Keyword
Host IP address
Fault Description
Networking: PC -> Modem or ONT -> OLT -> BRAS ->Multicast router -> VoD server
The multicast user fails to order programs.
Alarm Information
None
Cause Analysis
l The multicast configuration on the OLT is incorrect.
l The OLT sends the multicast response packet, but the multicast response packet is discarded
by the BRAS. Therefore, the multicast router does not receive the packet.

Module
Procedure
Step 1 Check the upstream port. It is found that the upstream port is in the normal state.
Step 2 Check the multicast configuration of the OLT. It is found that the data configuration of the
upstream port and the VLAN configuration are correct.
Step 3 Check whether the multicast user is online. It is found that the multicast user is online.
Step 4 Capture packets on the BRAS and analyze the packets. It is found that the BRAS discards the
IGMP packets sent from the outband network port of the OLT.
NOTE
When the upstream port is configured for the multicast service of the OLT, if the host IP address is not configured,
the system sends the IGMP packets with the IP address of the Layer 3 interface of the multicast VLAN. If a
unicast route from the BRAS to the upstream port does not exist, the IGMP packets are discarded.
Step 5 Add the host IP address and ensure that the host IP address and the IP address of the BRAS are
in the same subnet. The OLT sends IGMP packets with the host IP address. As a result, the fault
is rectified.
----End

When the OLT is used to provide the multicast service, there are multiple cases for the source
IP address of the sent multicast packets:
l If the IP address of the Layer 3 interface is configured for the program VLAN, the IP address
is the source IP address. Moreover, ensure that this IP address and the IP addresses of the
BRAS and the upper-layer router are in the same subnet.
l If the IP address of the Layer 3 interface is not configured, the source IP address is the host
IP address of the multicast program.
l If the host IP address is not configured, the source IP address is 0.0.0.0 by default.
When the OLT is used to provide the multicast service, configure the multicast host IP address
as the source IP address contained in the sent multicast packets according to the actual condition.
In addition, ensure that the host IP address and the IP addresses of the BRAS and the upper-
layer router are in the same subnet.

Mosaic display in multicast programs is a fault that a user is online and orders a program but
the quality of the program is poor, such as mosaic display.
7.3.3 Abnormal Program Interruption in Watching a Multicast

Program
Abnormal program interruption in watching a multicast program is a fault that a multicast user
is watching a program but the program is abnormally interrupted.

Module
7.3.3.1 TC-C6068 Program Is Suspended After a Multicast User Watches the

Program for Three Minutes Because of Incompatibility of Features Implemented
on Different Devices
This topic describes how to troubleshoot the fault when a program is suspended after a multicast
user watches the program for three minutes.
Fault Type
Multicast service
Keyword
Multicast VLAN
Program suspension
Fault Description
Network topology: Multicast user –> MA5600T -> MA5600 -> Multicast server
Fault description: When a user of the MA5600T watches the IPTV program, the program is
suspended after being watched for about three minutes; when the user watches another program
for about three minutes, the fault recurs. The multicast users of the MA5600, however, do not
encounter this fault.
Alarm Information
None
Cause Analysis
l The program streams are faulty.
l The multicast configurations of the MA5600T are incorrect.
Procedure
Step 1 The multicast users of the MA5600T can go online in the normal state, which indicates that the
basic multicast cascading configurations and the configurations of multicast programs and
multicast users of the MA5600T are correct.
Step 2 A user of the MA5600T can watch a program only about three minutes. This fault may be caused
by the following:
1. The multicast user sends a leave packet, which makes the user go offline.
2. The multicast user is always online but the program streams are interrupted.
3. The multicast user goes offline abnormally.
Step 3 Run the debugging igmp command to enable the debugging function globally on the MA5600
and for a certain service port on the MA5600T respectively to check the exchange of IGMP
protocol packets. It is found that the MA5600 transmits the IGMP query packet, but does not
receive the IGMP report packet of the corresponding program. Therefore, the MA5600 considers
that the multicast user does not respond after time 2 x General query interval (s) + General query
response time (0.1s), and then deletes the corresponding multicast forwarding entry.

Module
Step 4 Confirm that the MA5600T does not upstream transmit the IGMP report packet. Then, run the
debugging igmp 0/19/1 command on The MA5600T to query the debugging IGMP information.
It is found that the multicast upstream port does not receive the IGMP query packet sent from
the upper-layer MA5600 for the multicast program.
Step 5 Capture packets on the upstream port of the MA5600T by mirroring. The analysis of captured
packets proves that the IGMP query packet is already transmitted from the MA5600 to the
MA5600T, and already reaches the upstream port of the MA5600T. Because this packet is an
untagged packet, the VLAN ID of PVID is added to it when it reaches the upstream port of the
MA5600T. In general, the VLAN ID of PVID is different from the multicast VLAN ID. As a
result, the IGMP query packet will not be transmitted to the multicast module of the
MA5600T for processing, and then cannot reach the multicast user. Consequently, the multicast
user will not respond with the IGMP report packet.
Step 6 Why the multicast users of the MA5600T can order programs successfully? This is because the
IGMP report packet upstream transmitted by the MA5600T carries the multicast VLAN ID, but
the MA5600 considers the IGMP packet according to whether the DMAC is the IGMP MAC
address, instead of whether the packet is a tagged or untagged packet. If the DMAC address is
the IGMP MAC address, the packet is transmitted to the multicast module of the MA5600 for
processing.
Step 7 Because the MA5600 does not support MVLAN (multicast VLAN), the IGMP packets
transmitted from the MA5600 do not carry a VLAN tag. The MA5600T, however, supports
MVLAN since V8R5. Therefore, the VLAN tag of the multicast packets that transmitted to the
MA5600T must match the MVLAN tag and then the packets can be processed in the specified
MVLAN.
Step 8 When the aging time of the IGMP user expires, the MA5600 considers that the user already goes
offline, and then deletes the corresponding entry to disconnect the multicast streams.
Step 9 Enable the unsolicited reporting capability of multicast programs on the MA5600T. In this way,
the IGMP packets will be exchanged frequently. Enable or disable this capability according to
actual network resources and device performance.
MA5600T(config-mvlan4)#igmp program modify ip 224.1.1.4 unsolicited enable
Step 10 Enable the static attribute of the multicast cascade users on the MA5600. In this way, after a
program is ordered by users, this program will be always online even if the leave packet is
received.
MA5600(config-btv)#igmp cascade-port modify 0/7/0 static enable
MA5600(config-btv)#igmp static-join cascade-port 0/7/0 ip 224.1.1.1
Step 11 When this cascading port is statically configured with a program, the report packet and leave
packet will be dropped. In this case, the quick leave attribute of the cascading port does not take
effect. In this way, the multicast streams of the program will be led to the multicast cascading
port, reducing the exchange of IGMP protocol packets. Then the user of the lower-layer cascaded
device can quickly order programs, but the bandwidth of the upper-layer device may be occupied
continuously. Enable or disable this attribute according to actual conditions.
----End

l This topic describes a special network topology, which is not recommended by Huawei. It
is recommended that you plan the network based on Huawei recommended FTTx network
topology.

Module
l The implementations of the multicast service on the MA5600 and the MA5600T are
different. When a fault is associated with device compatibility, note that the impact on
network resources and on device performance should be considered.
7.3.3.2 TC-C6329 Program Suspension After a User Orders the Program

Successfully and Watches the Program for a Short Period of Time Because of
Incorrect Multicast Mode
This topic describes how to troubleshoot the fault when the program stops after a user orders
the program successfully and watches the program for a short period of time.
Fault Type
Multicast service
Keyword
Program Suspension
Fault Description
A user orders a program successfully. The program, however, stops after a short period of time.
Alarm Information
None
Cause Analysis
l The user right configuration is incorrect.
l The configuration of the multicast mode is incorrect.
Procedure
Step 1 Check the authority of the multicast user. It is found that the authority of the user is not set and
the user can watch all the programs.
Step 2 Check the parameters. It is found that the IGMP mode is set to IGMP Snooping, the querier is
disabled, and the aging time is shorter than the preset time of the multicast source, which results
in the user being offline after the aging time.
Step 3 Modify the IGMP mode to Proxy. Check the program. It is found that the program is smooth
and the fault is rectified.
----End

None

Module
7.3.3.3 TC-C6218 Program of an STB Interrupted Owing to Program Switching on

Another STB Managed by the Same ONT
This topic describes how to troubleshoot the fault when the IPTV service is interrupted.
Fault Type
IPTV service
Keyword
Interruption of the IPTV service
Fault Description
Network topology: Set-top box (STB) -> Switch -> HG850e -> OLT -> IP network -> IPTV
platform
Version: HG850e V100R001C05B056
The HG850e is connected to a switch. The switch is connected to two IP STBs. The same
program is played on the TV sets connected to the two STBs. When the program is switched on
one of the TV sets, the program on the other TV set is interrupted.
Alarm Information
None
Possible Cause
quickleave of multicast users is set to immediate.
Procedure
Step 1 In BTV mode, run the display igmp user all command to query the setting of quickleave of
multicast users. Confirm that quickleave of multicast users is set to immediate.
Step 2 Run the igmp user modify service-port command to change the value of quickleave of
multicast users to mac-based.
Step 3 Test the IPTV service. It is found that the fault is rectified.
----End

If quickleave of multicast users is set to mac-based, the system checks whether the MAC
address in the leave packet sent by a user is the same as that in the report packet sent by this user
when the user goes online. If the two MAC addresses are the same, the user goes offline
immediately. If the two MAC addresses are different, the user does not go offline.
If quickleave of multicast users is set to immediate, the OLT cuts off the media stream routed
to the ONT when receiving the IGMP leave message.

Module
7.3.4 Suspended in Multicast Programs

Not Displayed Smoothly in multicast programs is a fault that a user is online and orders a program
but the program is Not Displayed Smoothly.
7.3.4.1 TC-C6023 Multicast Program Is Not Displayed Smoothly Due to the Optical
Module Problem on the Upstream Device
This topic describes how to troubleshoot the fault when the multicast program is not displayed
smoothly due to the optical module problem on the upstream device.
Fault Type
Multicast service
Keyword
Multicast
Unsmooth program
Fault Description
Network topology: TV -> Set-top box (STB) -> ONU -> OLT -> Switch -> BRAS -> Multicast
source
When a subscriber orders a multicast program, the program is not displayed smoothly.
Alarm Information
None
Cause Analysis
l The programs from the program source are abnormal.
l Packet loss or packet error occurs on the downstream port of the ONU.
l The bandwidth limited for the downstream multicast VLAN by the ONU is insufficient.
l The PON port of the OLT works abnormally.
l The upstream port of the OLT is faulty.
l Other upper-layer devices are faulty.
Procedure
Step 1 Confirm with the subscriber about the multicast source. It is found that the multicast source
works in the normal state.
Step 2 Replace the STB. The fault, however, persists. Therefore, the fault is not caused by the STB.
Step 3 Run the display port state all command to query the parameters and the status of all the ports
on each service board. It is found that they are all normal.

Module
Step 4 Run the display traffic table ip command to query the bandwidth limited for the downstream
VLAN on the ONU. It is found that profile 10 is referenced, and CIR is 3 Mbit/s.
Step 5 Run the display port statistic command to query the performance parameters of the PON port.
It is found that no packet loss or error packet occurs on the PON port.
Step 6 Configure a Layer 3 address of the user VLAN on the ONU. Then, ping the ONU from the PC,
and ping the PC from the ONU. It is found that no packet loss occurs.
Step 7 Run the display port statistic command to query the performance parameters of the upstream
port on the OLT. It is found that no packet loss or error packet occurs on the upstream port.
Configure a Layer 3 address of the user VLAN on the OLT.
Step 8 Ping the OLT from the PC, and ping the PC from the OLT. It is found that no packet loss occurs.
Step 9 The link between the OLT and the PC is normal after the preceding software and port checking;
therefore, the upper-layer device may be faulty.
Step 10 Ping the gateway address of the BRAS from the OLT. It is found that packet loss occurs.
Step 11 Replace the optical fiber connected to the upper-layer device. Packet loss still occurs.
Step 12 Replace the optical module of the upper-layer device. It is found that no packet loss occurs.
Therefore, it can be determined that the paused screen of the multicast service is caused by the
optical module problem of the upper-layer switch.
----End

Multiple factors may cause the unsmooth multicast program. Therefore, sum up the possible
causes, and check the devices one by one from the user end.
7.3.4.2 TC-C6134 A Multicast Program Is Suspended Because Different Multicast

IP Addresses Map the Same Multicast MAC Address
This topic describes how to troubleshoot the fault when a multicast program is suspended.
Fault Type
Multicast
Keyword
Multicast program suspension
Fault Description
Network topology: ONU (MA5620) -> OLT (MA5600T) -> Multicast source
Fault description: When a multicast user of the ONU watches multicast programs, program
239.0.0.1 is suspended but the other programs are normal.
Alarm Information
None

Module
Cause Analysis
In the networking, the OLT is the multicast duplication point. If a multicast program is suspended
but the others are normal, the multicast source may be faulty or the ONU fails to forward a
multicast group.
Procedure
Step 1 Check the OLT. It is found that configurations of the OLT are correct.
Step 2 Use another multicast source to play the multicast program that encounters the fault. It is found
that the fault persists. This indicates that the multicast source is normal.
Step 3 When the multicast user of the ONU watches multicast program 239.128.0.1, if other multicast
users of the ONU watch multicast program 239.0.0.1, program 239.0.0.1 is suspended.
Step 4 According to the mapping relation between the multicast IP address and the multicast MAC
address defined in the protocol, programs 239.0.0.1 and 239.128.0.1 map the same multicast
MAC address. The ONU forwards the multicast data based on the multicast MAC address. In
this way, in ONU forwarding, programs 239.0.0.1 and 239.128.0.1 share the same program.
When two users of the ONU watch programs 239.0.0.1 and 239.128.0.1 at the same time, the
ONU sends the data of these two programs to user ports. Thus, the STBs of users receive traffic
of two multicast programs. The STB of a user is used for determining whether the multicast
traffic is required based on the multicast IP address. The unrequired multicast traffic will be
discarded. The buffer size of an STB, however, is fixed. If the buffer size is small, certain traffic
of the two multicast programs will be discarded and thus the programs are suspended.
Step 5 Change the multicast IP address of either of the two programs. As a result, the fault is rectified.
----End

According to the mapping relation between the multicast IP address and the multicast MAC
address defined in the multicast protocol, five bits of the multicast IP address are not included
in mapping, and 32 multicast IP addresses map the same multicast MAC address. Usually, two
multicast IP addresses with a large span map the same multicast MAC address. This indicates
that MAC address collision hardly occurs. When such a collision occurs, an STB may receive
unrequired multicast traffic. Then, the STB discards the unrequired multicast traffic based on
the multicast IP address. If its buffer size is small, the required multicast traffic is also discarded.
This affects the multicast service. In this case, it is recommended that you plan one IP address
to map one MAC address uniquely in planning the multicast IP addresses.
7.3.4.3 TC-C6246 IPTV Service of the MA5616 Is Not Smooth Because the MAC
Aging Time of the OLT Is Too Short
This topic describes how to troubleshoot the fault when the IPTV service is not smooth.
Fault Type
Multicast service
Keyword
Unsmooth multicast programs, TV

Module
Fault Description
Network topology: MA5616 -> OLT -> Switch -> BRAS -> Multicast source
Version: MA5616V800R306C01
The MA5616 uses the IGMP mode to deploy the IPTV service. The multicast duplication point
is on the OLT. After the service is deployed, all IPTV services of the set-top boxes (STBs)
connected to the MA5616 are not smooth.
Alarm Information
None
Possible Cause
l The data configuration is incorrect.
l The downlink bandwidth of the MA5616 is insufficient.
l A network fault exists.
l A fault exists on the upper-layer switch.
l A fault exists on the MA5616.
l A fault exists on the OLT.
Procedure
Step 1 Connect the STB to another MA5616. The fault is not detected. This indicates that the STB is
not faulty.
Step 2 Connect a PC directly to the MA5616 and test the download speed. The download speed is 5
Mbit/s. This indicates that the fault is not caused by the bandwidth configuration.
Step 3 On the MA5616, ping the IP address of the BRAS. No packets are lost. This indicates that the
fault is not caused by the network.
Step 4 Test the IPTV service on the upper-layer switch. The service is normal. This indicates that the
fault is not caused by the upper-layer switch.
Step 5 Check the configuration data on the OLT. It is found that the MAC address aging time is changed
to 10s. The default MAC address aging time is 300s. It is possible that the number of unknown
unicast packets is too large and the IPTV service of the MA5616 is not smooth because the MAC
address aging time configured on the OLT is different from that configured on the MA5616.
Step 6 Change the MAC aging time on the OLT to 300s. After the modification is complete, the IPTV
service becomes normal.
----End

The default MAC aging time is 300s on either the OLT and the ONU. You are advised not to
modify the default value because the inconsistency in the MAC address aging time configured
on the OLT and the ONU may generate a lot of unknown unicast packets and affect the service.

Module
7.3.5 Other Multicast Service Faults

This topic describes how to troubleshoot other multicast service faults.
7.4 Troubleshooting Cases of VoIP Service Faults

No tone after offhook is a fault that a user hears no tone or only a weak current noise after
offhook.
7.4.1.1 TC-C6005 No Dial Tone Is Played After Offhook Because of Damaged

Cables
This topic describes how to troubleshoot the fault when no dial tone is played after offhook
because line B is damaged and grounded directly.
Fault Type
VoIP service
Service failure
Keyword
No tone after offhook
Line B grounding
Local block
Fault Description
Certain voice users connected to an ONU cannot hear the dial tone after offhook. After the users
are transferred to another port, the users can hear the dial tone. A few minutes later, however,
the fault recurs.
Alarm Information
None
Cause Analysis
l The voice file package is not loaded.
l The hardware of the port is faulty.
l The loop line is faulty.
Procedure
Step 1 Only certain voice users cannot hear the dial tone after offhook, which indicates that the voice
file package is loaded.

Module
Step 2 Transfer the users to a port to which users connected can hear the dial tone after offhook. The
fault recurs after a few minutes. This indicates that the port is normal.
Step 3 Check the status of the port when the fault occurs. It is found that the port is in the blocked at
local state. Generally, the blocked at local state is caused by the following: Port fault, loop line
fault, or the endservice command is executed to terminate services on the port. After
confirmation with the customer, it is found that terminating services is not performed. Therefore,
it is suspected that the fault is caused by the loop line.
Step 4 Conduct a loop line test on the port to which the users who encounter the fault are connected. It
is found that line B is grounded, which indicates that the insulation resistance of line B to the
ground is smaller than 20 ohms or line B is grounded directly. Check the loop line on the user
side. It is found that the cable is damaged, and part cores are bare and are grounded directly.
Replace the cable and conduct a test. The fault is rectified and the users can make phone calls
normally.
----End

When only certain voice users encounter a fault, you can conduct tests on the circuit or loop line
to locate the cause of the fault during troubleshooting. The specific commands are as follows:
huawei(config)#test
huawei(config-test)#pots ?
NOTE
There is a busyflag parameter in the circuit and loop line tests. You can select whether to conduct the test upon
busy. If you choose force, services are affected, and the conversations are interrupted.
7.4.1.2 TC-C6033 The Phone Has Neither Feed Nor Dial Tone After Offhook Due
to Poor Contact of the MDF
This topic describes how to troubleshoot the fault when the phone connected to the ONU has
neither feed nor dial tone after offhook due to the poor contact of the main distribution frame
(MDF).
Fault Type
Voice service
Keyword
MDF
No dial tone
Fault Description
The phone connected to the ONU has neither feed nor dial tone after offhook.
Alarm Information
None

Module
Cause Analysis
l The subscriber cable is faulty.
l The hardware of the port is faulty.
Procedure
Step 1 Run the display board command to query the user port. It is found that the port is in the normal
state. Perform the circuit test on the port, and the test result is normal. It is determined that the
physical port is normal.
Step 2 Perform the loop-line test on the port. The system prompts a message, indicating that no phone
is connected. Connect a phone on the MDF side. After offhook, the port is still in the idle state.
Therefore, the fault may be caused by the subscriber loop line.
Step 3 Remove the cable connected to the ONU on the MDF, and connect the cable directly to the
phone. After offhook, the phone has feed and dial tone.
Step 4 Connect the cables on the MDF again. The fault then is rectified.
----End

When the phone connected to the ONU has neither feed nor dial tone after offhook, the possible
causes are as follows:
l The port is not provisioned with services.
l The ONU is not loaded with the voice package.
l The loop line is faulty.
l The port is faulty.
When such a fault occurs, focus on the preceding four causes and analyze them one by one.
7.4.1.3 TC-C6077 MG Interface of the ONU Resets Every 20 Minutes Because

Registered Domain Name Conflict Exists
This topic describes how to troubleshoot the fault when the MG interface of the ONU resets
every 20 minutes because registered domain name conflict exists.
Fault Type
Voice service
Keyword
MG interface disconnection
Registered domain name conflict
Fault Description
Network topology: Softx3000 –> SBC –> OLT –> ONU

Module
In a residential community, users can make calls sometimes through its ONU (MA5620), but
sometimes they hear no tone after offhook. This problem often occurs. Domain names configured
on the ONU are registered with the Softx3000 through the SBC proxy.
Alarm Information
The MG interface resets every 20 minutes.
2009-02-20 03:27:12 MG interface interruption restoration
MG interface ID: 0, MGC ipaddr:
192.168.249.2, MGC port: 2944, Inner Call:
0, Rejected Call: 0
2009-02-20 03:27:12 MG interface interruption
192.168.249.2, MGC port: 2944, Online User:
0
0, Rejected Call: 0
2009-02-20 03:07:45 MG interface interruption
192.168.249.2, MGC port: 2944, Online User:
0
Cause Analysis
l Optical lines between the ONU and the OLT are faulty.
l Packets are lost over the link between the ONU and the SBC, and between the SBC and
the Softx3000.
l Data configurations of the SBC or the Softx3000 are incorrect.
l Domain names configured on the ONU conflict.
Procedure
Step 1 Check the alarm information on the ONU and the OLT. It is found that there is no optical-line-
related alarm. Then, test the receive optical power of the ONU in the field. It is found that the
receive optical power of the ONU is -14 dB, which is normal. This indicates that the fault is not
caused by the optical line.
Step 2 When the fault occurs, ping the SBC from the ONU and ping the Softx3000 from the SBC. It is
found that no packets are lost. In addition, the fault occurs on only this ONU. Therefore, the
fault is not caused by the packet loss.
Step 3 Check data configurations of the SBC and the Softx3000. It is found that data configurations
are the same as those of the ONU. This indicates that the fault is not caused by data
configurations.
Step 4 Trace the signaling on the ONU by using the DBwin. It is found that the ONU does not receive
the heartbeat packet sent from the Softx3000 in five minutes. Then, the ONU sends the heartbeat
packet to the Softx3000 every one minute for five times; however, the Softx3000 does not
respond. In this case, the MG interface of the ONU resets. This process repeats and thus the MG
interface of the ONU resets every 20 minutes.
Step 5 The ONU does not receive the heartbeat packet sent from the Softx3000, which leads to MG
interface reset. It is suspected that the Softx3000 does not send the heartbeat packet. In this case,

Module
trace the ONU information on the Softx3000. It is found that the Softx3000 sends the heartbeat
packet all the time.
Step 6 Analyze the information traced on the Softx3000. It is found that the Softx3000 does not stop
sending the heartbeat packet until it receives the reset message RE="900" sent from the ONU.
Step 7 It is suspected that the SBC drops the heartbeat packet sent from the Softx3000 to the ONU. In
this condition, trace the ONU information on the SBC. It is found that the SBC does not receive
the heartbeat packet sent from the Softx3000, which is the same as the information traced on the
ONU.
Step 8 Two different results are obtained by tracing the information about the same ONU on the
Softx3000 and the SBC. This indicates that certain problems occur. Check the signaling of the
Softx3000. It is found that the MGW address changes. That is, the MGW address changes from
10.34.18.41 to 10.34.18.52. This indicates that two ONUs communicate with the Softx3000 by
using the same domain name.
Step 9 Check the domain name on SBC 10.34.18.41 and SBC 10.34.18.52. The registered users can be
found. This indicates that two different ONUs are configured with the same domain name.
Step 10 ONU 1 and ONU 2 are configured with the same domain name, but only one ONU can exchange
the signaling with the Softx3000 at a time. Assume that ONU 2 is normal. If ONU 1 does not
receive the heartbeat packet sent from the Softx3000 in five minutes, the ONU sends the
heartbeat packet to the Softx3000 automatically. If ONU 1 does not receive the response from
the Softx3000 in five minutes, ONU 1 sends the signaling for resetting the MG interface to the
Softx3000. After receiving this signaling, the Softx3000 responds to this signaling. In this case,
ONU 1 is in service. But ONU 2 cannot receive the heartbeat packet sent from the Softx3000.
Then, the MG interface resets after 10 minutes. Therefore, the MG interface of each ONU resets
in 20 minutes.
Step 11 Modify ONU 1 and ONU 2 to be with different registered domain names. Then, two ONUs work
normally.
----End

Configure a unique registered domain name for one ONU.
7.4.1.4 TC-C6080 Phone User of the Virtual Network Hears No Tone After Offhook
Caused by Abnormal Digitmap Issued by the Softswitch
This topic describes how to troubleshoot the fault when the phone user of the virtual network
hears no tone after offhook caused by abnormal digitmap issued by the softswitch.
Fault Type
Voice service
Keyword
Digitmap

Module
Fault Description
The ONU (MA5620) is interconnected with the softswitch of another vendor. The phone user
of the virtual network hears no tone after offhook.
Alarm Information
None
Cause Analysis
l The voice file is not loaded.
l The MDF is not in proper contact.
l The digitmap issued by the softswitch contains invalid characters.
l The format of the digitmap is abnormal.
Procedure
Step 1 Remove the ONU from the virtual network. Then, tones can be heard after offhook and the call
is normal. It is determined that the fault is not caused by the absence of the voice file or poor
contact on the MDF, but the fault is caused by the digitmap.
Step 2 Trace the signaling. It is found that the digitmap contains one "|" at the beginning, for example,
{(|0xxx|, which should be {(0xxx|. In addition, the digitmap contains the space at two places,
for example, at | 3xxx, which contains a redundant space. The following shows the signaling:
[10:14:46.540]msg from mgc([10.61.4.6]:2944) to mg([10.61.54.209]:2944): !/1
[ 10.61.4.6]:2944 T=4
69824532{C=-{MF=A0/2/23{DM=DM463751207458 {(|0xxx|1xxx|2xxx| 3xxx|4xxx|5xxx|6xxx|
7xxx|8xxx|FF|9123xx|910
000|910001|911111|911[0-59]|912[01246-9]|9125x|9186x|916xS.|9179xxSx.|919xSx.|911
[6-8]xxx|913xxxxxxxxx|9
15xxxxxxxxx| 918xxxxxxxxx|920x|92[1-9]xxxxx|9[3-8]xxxxxx|94xxxxxxxxx|98xxxxxxxxx|
9800xSx.|99xxxxSx.|9013
xxxxxxxxx|9015xxxxxxxxx|9018xxxxxxxxx|90[1-2]xxxxSxxxxx|90[3-9]xxxxxSxxxxx|
90311xxxSxxxxx|904[15]1xxxSxx
xxx|90512xxxSxxxxx|9057[147]xxxSxxxxx|9075[57]xxxSxxxxx|90898xxxSxxxxx|
900xxxxSxxxxxxxxxxx|[EF][0-9][0-9
E].F|EExx|EFxxF)},E= 470281777{dd/ce{DM=DM463751207458 },mfd/ce
{DM=DM463751207458 },al/on,al/fl},SG{ cg/
dt}}}}
[10:14:46.540]msg from mg([10.61.54.209]:2944) to mgc([10.61.4.6]:2944): !/1
[10.61.54.209]:2944 ER=4
00{"Syntax error in message"}
Step 3 The above-mentioned two points do not conform to the digitmap rules, so the ONU returns a
syntax error. Rectify the digitmap on the softswitch of another vendor. After that, the service
becomes normal.
----End

None

Module
7.4.1.5 TC-C6081 User Hears No Tone After Offhook Because Softswitch Does Not
Recognize Parameters Reported by the ONU
This topic describes how to troubleshoot the fault when the user hears no tone after offhook
because the softswitch does not recognize parameters reported by the ONU.
Fault Type
Voice service
Keyword
Fault Description
A certain user picks up the phone but hears no tone. After the user hangs up the phone and picks
up the phone again, no tone is heard. The fault is rectified after the H.248 interface is reset.
Alarm Information
None
Cause Analysis
l The line is faulty.
l The port status of the device is abnormal.
l Data configurations on the softswitch are incorrect.
l Interconnection parameters are incorrect, which leads to abnormal packet exchange.
Procedure
Step 1 If the phone is normal after offhook, it indicates that the line is normal.
Step 2 Log in to the device and check the user port status. It is found that the user port is normal.
Step 3 Configure packet capture by mirroring on the upstream port and find out the regular of fault
recurrence is that after the user picks up the phone but not does not dial a number for several
minutes, if the user hangs up the phone and picks up the phone again, no tone is heard.
Step 4 Analyze the packets as follows: If the ONU VoIP user does not dial a number for a long time
after picking up the phone, message T=275545430{C=-{N=A3{OE=39321
{20090120T02012800:dd/ce{ds="T",meth=PM}}}}} is reported. In addition, the softswitch
does not respond to the message, which causes that the port resources cannot be released and no
tone is heard after the user picks up the phone.
Step 5 If the user of the ONU VoIP user picks up the phone but not does not dial a number, three
parameters "", " "", and "T" are reported upstream. Then, test the softswitch. It is found that the
softswitch responds to parameters "" and " " but does not respond to parameter "T". As a result,
no tone is heard after picking up the phone.
Step 6 Modify parameters to report "" or " " upstream to rectify the fault.
----End

Module

To rectify voice faults, you must find out the regular of fault recurrence.
7.4.1.6 TC-C6125 Users of the MA5616 Cannot Hear a Tone at Irregular Intervals
After Picking Up the Telephone Because Configurations of the H.248 Profile Are
Incorrect
This topic describes how to troubleshoot the fault when users of the MA5616 cannot hear a tone
at irregular intervals after picking up the telephone.
Fault Type
H.248 VoIP service
Keyword
Offhook pre-configuration
Fault Description
Network topology: Telephone -> ONU (MA5616) -> OLT (MA5600T) -> LAN switch ->
Softswitch
MA5616 version: V800R306C01
Fault description: When the user of the ONU in an office makes a call as the caller, the user
cannot hear a tone after picking up the telephone at irregular intervals. After the POTS board is
removed and inserted again, the H.248 VoIP service returns to normal. However, after a period
of time, the fault recurs. The fault cannot be rectified automatically.
Alarm Information
None
Cause Analysis
l The POTS board is faulty.
l The digitmap configuration of the softswitch is incorrect.
l The interconnection between the ONU and the softswitch is faulty.
Procedure
Step 1 Replace the POTS board. However, after a period of time, the fault recurs. This indicates that
the fault is not caused by the POTS board.
Step 2 Check users of other POS ports. It is found that users of other POS ports can hear a tone after
picking up the telephone. This indicates that the digitmap configuration of the softswitch is
correct.
Step 3 Enable the DBwin debugging function to trace the signaling. It is found that there is no H.248
signaling for reporting the offhook event when the user picks up the telephone. On the ONU,

Module
run the display pstn state command to confirm that the service state of the POS port is offhook.
That is, the system detects the offhook action but does not report the "al/of" offhook information
to the softswitch.
MA5616(config)#display pstn state 0/1
---------------------------------------------------------------------
F /S /P PTPSrvState PTPAdmState CTPSrvState CTPAdmState LineState
---------------------------------------------------------------------
0 /1 /0 Normal NoLoop,NoTest Idle StartSvc Normal
0 /1 /5 Normal NoLoop,NoTest Offhook StartSvc Normal //The
system detects the offhook action.
Step 4 Run the display current-configuration section h248 command to check the H.248 profile of
the system. It is found that parameter 40 in the H.248 profile is 0, which indicates that the offhook
pre-configuration flag is disabled.
MA5616(config)#display current-configuration section h248
[h248]
<h248-0>
interface h248 0
if-h248 attribute mgip 10.40.74.197 mgport 2944 transfer udp
if-h248 attribute primary-mgc-ip1 10.9.33.42 primary-mgc-port 2944
if-h248 attribute secondary-mgc-ip1 10.9.39.42 secondary-mgc-port 2944
if-h248 attribute mg-media-ip1 10.40.74.197
if-h248 attribute profile-index 0
tid-format pstn prefix line
mg-software parameter 13 1
h248profile modify para 40 0 //The function of actively reporting offhook
is disabled.
Step 5 Considering interconnection between the ONU and the softswitch from other vendors, run the
h248profile modify para 40 1 command to change parameter 40 to 1, that is, enable the offhook
pre-configuration flag. Then, observe the service for a couple of days. It is found that the H.248
VoIP service is normal.
MA5616(config)#interface h248 0
MA5616(config-if-h248-0)#h248profile modify para 40 1
----End

None

Busy tone after offhook is a fault that a user hears only a busy tone after offhook.
7.4.2.1 TC-C6034 Ports on the Voice Service Board Are Displayed as Remote Block
Because User Data Is Not Configured on the Softswitch
This topic describes how to troubleshoot the fault when ports on the voice service board are
displayed as remote blocked because no user data is configured on the softswitch.
Fault Type
Voice service

Module
Keyword
Softswitch
Remote block
Fault Description
The ONU is connected to voice subscribers. After offhook, certain subscribers hear the busy
tone.
Alarm Information
None
Cause Analysis
l The MG interface is faulty.
l Certain ports on the voice service board are faulty.
Procedure
Step 1 Log in to the device and query the status of the MG interface. It is found that MG interface is in
the normal state. In addition, voice services of subscribers connected to certain ports are normal.
Therefore, it can be determined that the MG interface is normal.
Step 2 Run the display board 0 command to query the status of the voice service board and run the
display board frameid/slotid command to query the status of the ports on the voice service
board. It is found that they are in the normal state. Run the display pstn state command to query
the ports. It is found that ports connected to subscribers that hear the busy tone after offhook are
displayed as "remote block". Migrate the user data on a normal port to a faulty port. The status
of the faulty port is changed to "StartSvc". Therefore, the fault is not caused by the port and the
ONU.
Step 3 Check the configuration of the softswitch of another vendor. It is found that no user data is
configured on the faulty ports. Add user data on the softswitch. Then, the ports are queried to
be "StartSvc", and the phone calls can be made successfully.
----End

When Huawei device works with the device of another vendor, Huawei needs to cooperate with
the vendor for fault location.
7.4.2.2 TC-C6041 The Caller Hears the Busy Tone After Offhook Due to Inconsistent
RTP Formats Between the ONU and the Softswitch
This topic describes how to troubleshoot the fault when the caller hears the busy tone after
offhook because the RTP format configured on the ONU is different from the RTP format
configured on thesoftswitch.
Fault Type
Voice service

Module
Keyword
RTP format
Busy tone after offhook
Fault Description
The 64 voice subscribers connected to the ONU hear the busy tone after offhook when they
function as the caller.
Alarm Information
None
Cause Analysis
l The digitmap issued by the softswitch is incorrect.
l The TID and the RTP configured on the ONU are different from those configured on the
softswitch.
Procedure
Step 1 Trace the H.248 signaling on the ONU. It is found that the softswitch issues the busy tone signal.
#@20081205.14:56:04.440
#@MG->MGC
#@!/1 <0018828F2D6A>:2944 P=2831172942{C=106{S=RTP591{SA{rtp/dur=50,rtp/os=0,
rtp/or=0,rtp/ps=0,rtp/pr=0,rtp/pl=0,rtp/jit=0,rtp/delay=0}}}}
#@20081205.14:56:04.440
#@MGC->MG
#@!/1 <0018828F2D6A-BGW>:2944 T=2831172943{C=106{MF=AG0{SG{cg/bt}}}}
Step 2 Trace the H.248 signaling on the softswitch. It is found that the RTP transmitted from the ONU
is different from that configured on the softswitch, and the 502 error occurs in the H.248 signaling
of the softswitch. The RTP on the softswitch should be configured as RTP 1000, RTP1001, ...,
which is increased by 1.
Step 3 Change the RTP format on the ONU to be the same as that on the softswitch, and then reset the
H.248 interface. The caller can make phone calls normally.
Before the change, the configuration on the ONU is as follows:
tid-template add 33 format %u parameter-list R+500 name ceshi1
After the change, the configuration on the ONU is as follows:

tid-template add 33 format %u parameter-list R+1000 name ceshi1
interface h248 0
tid-format rtp prefix RTP template 33 pstn prefix AG
----End

When Huawei devices are interconnected with the devices of other vendors to implement the
voice service, you need to check the consistency of the parameter configuration on both sides,
because different vendors have different configuration standards. In addition, you need to trace
the H.248 signaling, which helps solve the common interconnection problems.

Module
7.4.2.3 TC-C6083 ONU User Hears the Busy Tone After Offhook BecauseSoftswitch
Does Not Recognize the Offhook Signaling Reported by the ONU
This topic describes how to troubleshoot the fault when the ONU user hears the busy tone after
offhook because the softswitch does not recognize the offhook signaling reported by the ONU.
Fault Type
Voice service
Keyword
Busy tone
Fault Description
The MA561x V800R306C01B053SPH001 is interconnected with the softswitch through the H.
248 protocol. When the MA561x user makes an outgoing call, the user directly hears the busy
tone after offhook. After the same user receives an incoming call once, the user can make
outgoing calls normally.
Alarm Information
None
Cause Analysis
The interconnection between the softswitch and the ONU is faulty.
Procedure
Step 1 Trace the signaling. It is found that the softswitch returns error 410 after the MA561x reports
the offhook signaling to the softswitch. The signaling is as follows:
[02:59:20.280]msg from mg([172.21.8.20]:2944) to mgc([172.31.8.12]:2944): !/2
<001882B338D7>:2944 T=252084108{C=-{N=AG58910{OE=*{20090704T02592000:al/of}}}}
[02:59:20.320]msg from mgc([172.31.8.12]:2944) to mg([172.21.8.20]:2944): !/2
<001882B338D7-BGW>:2944 P
=252084108{C=-{ER=410{}}}
Step 2 By default, Huawei ONU reports OE=* in the offhook signaling, but the softswitch cannot
recognize the * sign and returns error 410. As a result, the MA561x plays the busy tone to the
phone of the user.
Step 3 When the MA561x is interconnected with the softswitch, the ZTE_AGW/1 profile must be
adopted, and the value of parameter 46 in the profile must be changed to 1 so that the MA561x
reports the offhook event in a format that can be recognized by the softswitch. The default value
of parameter 46 is 0, indicating the format OE=*. When the MA561x is interconnected with a
Huawei softswitch, the ZTE_AGW/1 profile need not be used. The following are the methods
of querying and modifying the profile and the parameter.
huawei(config-if-h248-1)#display h248profile list
---------------------------------------------
Profile-Index Profile-Name("Negotiation-Name")
---------------------------------------------
0 CustomizingProfileTemplet("")
1 NoProfile("")
2 BT_AGW/3("BT_AGW/3")

Module
3 FT_AGW/2("FT_AGW/2")
4 KPN_AGW/1("KPN_AGW/1")
5 PCCW_AGW/1("PCCW_AGW/1")
6 ZTE_AGW/1("ZTE_AGW/1")
---------------------------------------------
Step 4 Query the parameter values of the profile list.

huawei(config-if-h248-1)#display h248profile profile-index 6
Command:
display h248profile profile-index 6
---------------------------------------------
Profile-Name: ZTE_AGW/1
Profile-Negotiation-Name: ZTE_AGW/1
Profile-Index: 6
---------------------------------------------
Para2: 3
Para12: 1
Para45: 5
Para46: 1
Para48: 2
Para51: 1
Para52: 1
Para54: 1
Para83: 1
---------------------------------------------
Step 5 Modify the value of parameter 46.

huawei(config-if-h248-1)#h248profile modify para 46 1
----End

When the MA561x interoperates with the softswitch, make sure that the profile and the profile
parameters are configured correctly. Interoperation problems usually lead to VoIP service faults.
7.4.2.4 TC-C6192 Route Is Lost After an ONU Is Reset Because the Route of the MG
Media Address of the ONU Is Set to the Default Route
This topic describes how to troubleshoot the fault when route is lost after an ONU is reset.
Fault Type
Voice failure
Keyword
Route loss
Fault Description
After an ONU is powered off and reset, the NMS can manage the ONU normally but the voice
service of the ONU fails.
Alarm Information
None

Module
Possible Cause
l The configuration data is not saved and is lost.
l The board of the ONU is faulty.
l The H.248 interface is abnormal.
Procedure
Step 1 Query the board status. It is found that the board is normal, which indicates that the fault is not
caused by the board fault.
Step 2 Query the H.248 interface status. It is found that the H.248 interface is in the wait act state.
huawei(config)#display if-h248 all
--------------------------------------------------------------------------------
MGID Trans State MGPort MGIP MGCPort MGCIP/
DomainName
--------------------------------------------------------------------------------
0 UDP wait act 2944 10.10.229.130 2944 10.10.10.1
--------------------------------------------------------------------------------
Step 3 Reset the H.248 interface. It is found that the H.248 interface is still in the abnormal state.
Step 4 Check the configuration data relating to the H.248 interface. It is found that the configuration
data is correct but the route to the MGC is not configured.
Step 5 Configure a default route to the MGC and then check the H.248 interface status. It is found that
the H.248 interface is normal and the voice service recovers.
Step 6 Save the data.
Step 7 Rest the equipment and check whether the fault is rectified. It is found that the default route to
the MGC is lost again.
Step 8 Change the route to the MGC to be the specific route, reset the equipment and then check whether
the fault is rectified. It is found that the route is not lost.
huawei(config)#ip route-static 10.0.0.0 255.0.0.0 10.10.229.120
Step 9 Query the H.248 interface status. It is found that the H.248 interface and voice services are
normal.
huawei(config)#display if-h248 all
----------------------------------------------------------------------------
MGID Trans State MGPort MGIP MGCPort MGCIP/
DomainName
----------------------------------------------------------------------------
0 UDP Normal 2944 10.10.229.130 2944 10.10.10.1
----------------------------------------------------------------------------
----End

When an ONU is reset, the OLT automatically issues data to the ONU to generate a default
management route. If you delete such a default route or change the next hop of such a default
route to another IP address, the deleted route or the changed route will be restored after the ONU
is reset.
To troubleshoot such a fault, configure the MG media route to be the specific route if the MG
address is different from the management address.

Module
7.4.3 No Ring Back Tone After Dialing

No ring back tone after dialing is a fault that a user does not hear the ring back tone after dialing
a phone number and the voice service fails.
7.4.3.1 TC-C6116 VoIP Service Failure Occurs on an ONU Because the Softswitch
Issues an Incorrect Parameter of the Detection Message
This topic describes how to troubleshoot the fault when the calling party hears the busy tone
after dialing and the called party fails to be connected.
Fault Type
Voice service
Keyword
Error 446
th = 100
Fault Description
Network topology: Telephone -> ONU (MA5616) -> OLT (MA5600T) -> Softswitch
Version: MA5616V800R306C01SPH009
Fault description: After the ONU is connected to the softswitch, the calling party hears the busy
tone after dialing and the called party fails to be connected.
Alarm Information
None
Cause Analysis
l The profile-index parameter of the ONU is different from that of the softswitch.
l The formats of the ephemeral terminations of the softswitch and the ONU are different.
l Signaling exchange is abnormal.
Procedure
Step 1 Check the configuration and change profile-index referenced by the H.248 interface to be the
same as that specified in the profile of the softswitch vendor. It is found that the fault persists.
Step 2 Confirm that the formats of the ephemeral terminations of the softswitch and the ONU are the
same. It is found that the fault persists.
Step 3 Trace the signaling. When the softswitch issues the add message to add an association, the ONU
responds with error 446.
!/1 [10.122.98.148]:2944 T=315649154{C=${A=USER00100300009,A=${M{ST=1{O{MO=SR,nt/
jit=0},L{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:20 },R{v=0 c=IN IP4
10.122.98.76 m=audio 11186 RTP/AVP 0 a=ptime:20 }}},E=316093284{nt/netfail,nt/
qualert{th=100}}}}}
!/1 [10.122.251.7]:2944 P=315649154{C=56{A=USER00100300009,A=RTP00200000003{M{ST=1

Module
{O{MO=SR,nt/jit=0},L{v=0 c=IN IP4 10.122.251.7 m=audio 57620 RTP/AVP 0 a=ptime:

20 },R{v=0 c=IN IP4 10.122.98.76 m=audio 11186 RTP/AVP 0 a=ptime:20 }}},ER=446
{"Unsupported or Unknown Parameter"}}}}
Step 4 From the signaling, it can be seen that the ONU incorrectly responds to message E=316093284
{nt/netfail,nt/qualert{th=100} that is issued by the softswitch. The ONU supports the nt/netfail
and nt/qualert detection messages. The RTCPXR attribute of the DSP must be enabled. In this
case, set the RTCPXR attribute to enable. It is found that the fault persists.
Step 5 Check the H.248 protocol. According to the description of qualert in section E.11.2 of
rfc3525_H.248, the th parameter ranges from 0 to 99. The th parameter issued by the softswitch,
however, is 100, which is not compliant with the H.248 protocol. As a result, the ONU responds
with error 446. Change the parameter of the softswitch to a proper value. It is found that the fault
is rectified.
----End

l V800R305 does not concern about nt/netfail and nt/qualert detection messages or the th
parameter; therefore, the fault mentioned in this topic does not occur.
l V800R306 and V800R307 concern about nt/netfail and nt/qualert detection messages.
Thus, the RTCPXR attribute must be enabled and the th parameter must be compliant with
the H.248 protocol.
7.4.3.2 TC-C6121 SIP VoIP Service Fails Because an ONT Port ID Is Not Bound to
a Telephone Number
This topic describes how to troubleshoot the fault when the SIP VoIP service fails.
Fault Type
VoIP service
Keyword
SIP VoIP service
Error 404
Fault Description
Network topology: Telephone -> ONT (HG850a) -> OLT (MA5600T) -> IMS
Fault description: The ONT is provisioned with the SIP VoIP service. When the telephone
connected to the ONT functions as the calling party, the calling party cannot make a call but
hears the current noise; when the telephone connected to the ONT functions as the called party,
the calling party hears a voice message indicating that the number dialed does not exist. The
IMS, however, displays that the telephone number is registered successfully with the ONT. It is
also found in the traced signaling on the IMS that error 404 is displayed.
Alarm Information
None

Module
Cause Analysis
l Configurations of the ONT are incorrect.
l Configurations of the IMS are incorrect.
Procedure
Step 1 Check configurations of the ONT. It is found that its configurations are correct. The telephone
number is registered successfully with the ONT. The following figure shows the HG850a Web
page.
Step 2 Check parameters of the IMS. It is found that parameters are correct. In addition, the IMS is
connected downstream to some other ONTs and users of these ONTs can make calls normally.
Step 3 Make a call from the telephone and trace signaling on the IMS.
Step 4 When the telephone connected to the ONT functions as the calling party, the beep current noise
is heard and no INVITE message is displayed on the IMS. When the telephone connected to the
ONT functions as the called party, a voice message indicating that the number dialed does not
exist. Then, error 404 is sent from the IMS. This indicates that the fault is caused by the ONT.
SIP/2.0 404 The Number you have dialed is not in service
Step 5 Log in to the ONT and bind the port ID to the telephone number. It is found that a call can be
made normally. In this case, the fault is rectified.
NOTE
ONTs of different types may have different Web pages. For details, see the ONT Service Manual. In the
case of the HG850a, choose Advanced > VoIP from the navigation tree on the Web page. Then, on the
Port tab page, select the check box after Associated SIP ID, as shown in the following figure.
----End

Module

The check box indicates the physical status of the telephone. The dialed telephone number can
be reported only when the check box is selected.
In the case of the VoIP service failure of a type A terminal, the terminal is placed at the user
premise and thus it is hard to trace the signaling by means of packet capturing based on port
mirroring. Therefore, in deployment configuration, it is recommended that you perform
configurations without re-work by referring to the deployment guide.
7.4.3.3 TC-C6243 Voice Users Served by the MA5616 Sometimes Cannot Hear the
Ringback Tone After Dialing Numbers Owing to the Fault of the E1 Trunk of the
MCA Platform on the Core Network
This topic describes how to troubleshoot the fault when voice users sometimes cannot hear the
ringback tone.
Fault Type
Voice service
Keyword
No ringback tone
Fault Description
Network topology: MA5616 -> OLT -> NE40 -> SoftX3000
If the called user is in busy state after a voice user served by the MA5616 dials the number, the
calling user sometimes cannot hear the ringback tone or announcement. If the calling user does
not hook on, the calling user hears the busy tone about 10 seconds later.
Alarm Information
None
Possible Cause
l The phone set is faulty.
l The voice port on the MA5616 is faulty.
l The MA5616 does not play the signal tone.
l A fault exists on the bearer network.
l A fault exists on the media gateway controller (MGC).
l A fault exists on the missed call alert (MCA) platform.
Procedure
Step 1 The ringback tone cannot be heard only when the called user is busy. This indicates that the
phone set and the voice port on the MA5616 are not faulty.

Module
Step 2 Capture signaling on the MA5616 and analyze the packets. No exception is detected. This
indicates that the fault is not caused by the MA5616 and the bearer network.
Step 3 Trace signaling on the MGC. No exception is detected. When the called user is busy, the call is
routed to the MCA platform for further processing.
Step 4 Analyze information related to the called number. It is found that the missed call recording
function is enabled for the called number. The fault may be related to the MCA platform.
Step 5 Select a phone number for which the missed call recording function is disabled. Conduct a test
by using this number. The fault is not detected. The fault may be caused by the MCA platform.
Step 6 Test the trunk lines one by one between the MGC and the missed call server. It is found that the
fault occurs when the service occupies the first E1 trunk line.
Step 7 Disconnect this trunk line. The fault is rectified.
----End

None
7.4.4 Busy Tone After Dialing

Busy tone after Dialing is a fault that a user hears only a busy tone after Dialing.
7.4.4.1 TC-C6035 Subscribers Hear the Busy Tone After Dialing the Number Due
to the Incorrect Settings of Software Parameters of the MG Interface
This topic describes how to troubleshoot the fault when subscribers hear the busy tone after
dialing the number because the software parameters of the MG interface are incorrectly set on
the ONU.
Fault Type
Voice service
Keyword
Software parameters of the MG interface
Busy tone
Fault Description
The voice subscribers can hear the dial tone after offhook, but always hear the busy tone after
dialing the number.
Alarm Information
None

Module
Cause Analysis
l The digitmap is issued incorrectly.
l The number reported by the ONU does not match the digitmap issued by the softswitch.
l The data configuration on the ONU is incorrect.
Procedure
Step 1 The other AGs except this new ONU connected to the softswitch are normal. Therefore, it can
be determined that the digitmap issued by the softswitch is correct.
Step 2 After the numbers such as 10000 or 10086 are dialed, the busy tone is always heard. Therefore,
the problem is not caused by the mismatch between the number reported by the ONU and the
digitmap issued by the softswitch.
Step 3 Use the DBwin to capture the signaling exchange information on the ONU. It is found that the
softswitch issues the digitmap normally, the ONU reports the number normally, and then the
softswitch issues the request for creating a context. Then, after the ONU reports the "ER=432
{"Out of TerminationIDs or No TerminationID available"}" message, the softswitch issues the
busy tone.
NOTE
After the subscriber connected to the ONU dials the number, the 432 error code is reported. According to the
H.248 protocol, this error code indicates that no termination is available or the terminations are insufficient.
Check the data configuration on the ONU. It is found that "mg-software parameter 24 1" is configured for the
H.248 interface. Run the display mg-software parameter command to query the software parameters of the
MG interface. It is found that "24: Max. RTP terminal ID" indicates the maximum number of RTP terminals.
When "software parameter 24" is set to 1, it indicates that one ephemeral termination is allocated. Therefore,
when the softswitch issues a request to the MG for creating a context, the ONU reports the error code, indicating
that the terminations are insufficient.
Step 4 The ONU is configured with two ASRB boards, which can be connected to up to 64 users.
According to the actual requirement (except the special requirements), 64 RTP terminals are
enough. Configure "mg-software parameter 24 64" for the H.248 interface. The fault is rectified.
----End

l When configuring the software parameters of MG interface, you need to know the details
about each parameter, and you must not configure the parameters at random.
l Software parameter "24: Max. RTP terminal ID" of the MG interface is a new feature,
which requires your attention.
7.4.4.2 TC-C6078 ONU Users Hear the Busy Tone After Offhook and Dialing Due
to Incorrect Settings of the RTP Ephemeral Termination Range on the Softswitch
This topic describes how to troubleshoot the fault when ONU users hear the busy tone after
offhook and dialing due to incorrect settings of the RTP ephemeral termination ID range on the
softswitch.
Fault Type
Voice service

Module
Keyword
RTP ephemeral termination ID range
Busy tone after offhook
Fault Description
Network topology: Softswitch –> Bearer network –> OLT (MA5600T) –> ONU (MA5616)
The ONU (MA5616) users randomly hear the busy tone after picking up the phone and dialing
a number.
Alarm Information
None
Cause Analysis
l The Layer 2 network is faulty.
l The interconnection between the ONU and the softswitch is improper.
Procedure
Step 1 When the fault recurs, ping the softswitch from the ONU. It is found that no packet loss occurs
and the H.248 interface is normal.
Step 2 Trace signaling on the ONU. It is found that the softswitch directly responds with the busy tone
after the user picks up the phone and dials a number.
Step 3 Trace signaling on the softswitch.

msg to mgc: MEGACO/1 [10.67.5.53]:2944
P=161486837{C=4{A=A161,A=A100000064{M{ST=1{O{MO=RC,nt/jit=40},L{v=0 c=IN IP4
10.68.75.10 m=audio 28656 R
TP/AVP 8 a=ptime:20 }}}}}}
msg from mgc to mg: MEGACO /1 [10.67.41.126]:2944
T=161486838{ C=4{ MF=A161{ SG{ cg/bt}}}}
Step 4 In the ADD reply message reported by the ONU, the ID allocated to the RTP ephemeral
termination is A100000064. According to the normal flow, the softswitch should play the ringing
tone to the called party, and at the same time respond with the Modify command, containing the
ringing tone message (al/ri). The softswitch, however, responds with the busy tone message (cg/
bt). On the softswitch, the RTP ephemeral termination ID must be specified manually. Therefore,
it is suspected that the RTP ephemeral termination ID range is not correctly set. Check the RTP
ephemeral termination ID range set on the softswitch. It is found that the range is set to
A100000000-A100000032. When the ephemeral termination ID allocated by the ONU to the
user is A100000064, which exceeds the RTP ephemeral termination ID range set on the
softswitch, the softswitch fails to identify the termination ID and thus plays the busy tone.
Step 5 Set the number of the RTP terminations on the MG interface of the ONU to 32.
huawei(config-if-h248-1456)#mg-software parameter 24 32
Step 6 Reset the MG interface. Test the service. Now, the service is normal.
----End

Module

l By default, the RTP ephemeral termination ID range of the MA5616 V800R306C01B053
is A100000000-A100000064.
l When the ONU is interconnected with the softswitch, the RTP ephemeral termination ID
range on the softswitch must be the same as that on the ONU.
l The RTP ephemeral termination ID range of the ONU can be modified through software
parameter 24 of the MG interface. The modification takes effect after the MG interface is
reset.

One-way audio is a fault that a user can dial a phone number and hear the ring tone, but only the
tone of one party can be heard in a voice call.
7.4.5.1 TC-C6001 One-Way Audio Because of Improper Configuration of the Voice

IP Routing
This topic describes how to troubleshoot the fault when one-way audio occurs because the
configuration of the voice IP routing of an ONU is improper.
Fault Type
VoIP service
Keyword
One-way audio
Routing configuration
Fault Description
An OLT is connected to a router for upstream transmission to the bearer network. An ONU is
connected to the GPBD board on the OLT to provide the voice service. After the service is
provided, a user can make phone calls normally, and hear the ring tone normally. One-way audio,
however, occurs during conversations. In addition, when the user uses the phone to dial a hotline,
the digit keys fail to be dialed according to the voice prompt.
Alarm Information
None
Cause Analysis
l The network quality is poor.
l One-way audio occurs on the media gateway of the bearer network.
Procedure
Step 1 On the ONU, run the display if-h248 all command to check the status of the MG interface of
the ONU. It is found that the interface is in the normal state.

Module
Step 2 On the ONU, run the display if-h248 state and display if-h248 attribute commands to check
the configuration of the MG interface. It is found that the configuration of the MG interface is
normal.
Step 3 On the OLT, run the ping command to check the link between the OLT and the signaling gateway
of the softswitch. It is found that no packet loss occurs.
Step 4 Capture packets on the ONU and OLT sides during a conversation. It is found that the signaling
interaction is normal.
Step 5 Ask different users connected to the same OLT to dial each other. It is found that the
conversations are normal.
Step 6 The media streams on the network are converged to the softswitch through the TG. Trace
signaling on the softswitch during the dialing. The IP address allocated by the TG for the
conversation is obtained. Ping the IP address of the TG from the ONU. It is found that the ping
operation fails. Ping the IP address of the ONU from the TG. Nevertheless it is found that the
ping operation is successful.
Step 7 On the ONU, run the display ip routing-table command to check the IP routing configuration
of the ONU. It is found that the IP routing configuration is very precise, and the destination IP
addresses are not within the IP network segment allocated by the TG. Change the routing to the
default routing. As a result, the voice service becomes normal.
----End

The dialing and ringing of the ONU are normal, which indicates that the signaling stream is
normal. The possible cause of one-way audio is that the routing configuration of the ONU or
bearer network is incorrect.
If a similar fault occurs on the bearer network, you can ask multiple users connected to one OLT
to dial each other to locate the fault. If the multiple users can dial each other normally, it indicates
that the bearer network is normal. The media streams are forwarded inside the ONU. Therefore,
it can be determined that the channel from the ONU to the bearer network is faulty.
7.4.5.2 TC-C6013 One-Way Audio Because of the ACL Configured on the Bearer
Network
This topic describes how to troubleshoot the fault when one-way audio occurs during the
conversation of a voice user connected to an ONU because of the ACL configured on the bearer
network.
Fault Type
VoIP service
Keyword
One-way audio
ACL

Module
Fault Description
The ringing is normal after a POTS user connected to an ONU makes a phone call. One-way
audio, however, occurs sometimes when a call is set up.
Alarm Information
None
Cause Analysis
l The softswitch is faulty.
l The upper-layer bearer network is faulty.
Procedure
Step 1 The user can make phone calls normally, which indicates that the data configurations of the OLT
and ONU are correct, and the signaling interaction with the softswitch is normal. Therefore, it
can be determined that the fault is not caused by the ONU, OLT or softswitch.
Step 2 Capture packets and analyze the packets. It is found that the IP packet interaction of media
streams is faulty when one-way audio occurs. Check the configurations of the router on the IP
bearer network. It is found that the ACL based on UDP port numbers is configured and UDP
ports 50000-60000 are limited. Nevertheless, the UDP port number of media streams of the ONU
ranges from 49500 to 65500. Therefore, when the media streams occupy UDP ports
50000-60000, one-way audio occurs due to the ACL limit. Cancel the ACL settings on the IP
bearer network, and test the service. As a result, the service becomes normal.
----End

When the VoIP service is provided, pay attention to the range of UDP port numbers in the ACL
configured on the upper-layer bearer network.
7.4.5.3 TC-C6037 IPT Service of the Caller Fails Because of Inconsistent ONU
Dialing Mode
This topic describes how to troubleshoot the fault when the caller service of the intelligent public
telephone (IPT) service fails.
Fault Type
Voice service
Keyword
Dialing mode, mismatch, IPT service

Module
Fault Description
The ONU (MA5606T) is interconnected with the softswitch. The IPT service of the caller fails,
but the IPT service of the callee is normal.
Alarm Information
None
Cause Analysis
l The physical attributes of the PSTN port on the ONU are different from those configured
on the softswitch.
l The accounting phone is faulty.
Procedure
Step 1 Trace the H.248 message on the softswitch. It is found that the softswitch does not receive the
number information reported by the ONU. Therefore, it can be determined that the fault is caused
by the ONU or the accounting phone.
Step 2 In the pstnport mode of the ONU, run the display pstnport attribute command to query the
physical attributes of the PSTN port. It is found that the dialing mode is set to support only the
pulse dialing. The accounting phone adopts the dual-tone multifrequency (DTMF) dialing mode,
which causes the mismatch of the dialing number between the ONU and the accounting phone.
As a result, the accounting phone fails to collect digits, and the caller service fails.
Step 3 In the pstnport mode of the ONU, run the pstnport attribute set frameid/slotid/portid dial-
mode DTMF-pulse-both command to change the dialing mode to "DTMF-pulse-both", which
indicates that both the DTMF dialing mode and the pulse dialing mode are supported. Perform
the dialing test. The caller service is normal, and the fault is rectified.
----End

There are two dialing modes, DTMF dialing mode and pulse dialing mode. Currently, most of
the phones in China adopt the DTMF dialing mode, and only a few phones adopt the pulse dialing
mode. It is recommended that the dialing mode be configured as "DTMF-pulse-both", which
indicates that the two dialing modes are supported.
7.4.5.4 TC-C6051 One-Way Audio of the Voice Service on the ONU Occurs Because
the Port ID Used by the Media Stream Is Masked on the Bearer Network
This topic describes how to troubleshoot the fault when one-way audio of the voice service on
the ONU occurs because the port ID used by the media stream is masked on the bearer network.
Fault Type
Voice service
Keyword
One-way audio

Module
Port ID
Fault Description
Voice subscribers are connected to the ONU. When they make phone calls, they can hear the
voice of the callee. The callee, however, cannot hear the voice of the caller sometimes.
Alarm Information
None
Cause Analysis
l The route from the ONU to the peer media gateway is abnormal.
l The port ID is masked on the network.
Procedure
Step 1 When subscribers from other cities call the subscribers connected to the ONU, the subscribers
from other cities cannot hear the peer voice for multiple times, but the subscribers connected to
the ONU can hear the peer voice. This fault occurs from time to time. Therefore, the fault is not
caused by one-way audio.
Step 2 Perform the dialing test repeatedly, and capture the signaling of the callee during the normal and
the abnormal call services. It is found that the IP address of the UMG is x.x.241.x or x.x.242.x
when the service is normal, and x.x.240.x or x.x.243.x when the service is abnormal. x.x.240.x
and x.x.243.x, however, can be pinged successfully, which indicates that the routes from the
ONU to the two UMGs are reachable. Therefore, the ACL may be implemented on a certain
device between the ONU and the UMG with the IP address x.x.243.x. As a result, the port ID
used by the media stream is masked, which causes the one-way audio.
Step 3 One-way audio of the voice services on the ONU occurs. Regardless of whether the subscribers
connected to the ONU function as the caller or the callee, they can hear the peer voice. Therefore,
it can be determined that the voice stream from the peer end to the local end is normal (peer end-
>UMG->PE->SR->T64G->OLT->ONU->local end). The peer end cannot hear the local voice.
Therefore, it can be determined that the voice stream from the local end cannot reach the peer
end normally (peer end<-UMG<-PE<-SR<-T64G<-OLT<-ONU<-local end).
Step 4 Check the devices one by one on the route from the ONU to NE40E-2 (PE). It is found that the
port connecting SR-2 to PE-2 is configured with the outbound policy. The ACL rule in the
outbound policy allows the IP address segment of the ONU to pass only UDP port 2944. After
other UDP ports are unrestricted, the fault is rectified.
----End

None
7.4.5.5 TC-C6229 One-Way Audio Between the HG850a and the IAD in the Same
Network Segment Because the ARP Proxy on the Upper-Layer Gateway Is Disabled
This topic describes how to troubleshoot the fault when one-way audio occurs between the
HG850a and the IAD in the same network segment.

Module
Fault Type
Service function
Keyword
One-way audio
Fault Description
Figure 7-11 shows the network topology. The IP address of the HG850a is 10.3.6.7. The IP
address of the SoftX3000 is 10.10.210.10. The IP address of the IAD is 10.3.4.87.
Figure 7-11 Network topology

10.3.4.87
VLAN 3
IAD
10.3.254.254 10.3.6.7
10.10.210.10 VLAN 3
VLAN 3
SoftX3000 Cisco ASA Qtech3900 MA5600T HG850a

Layer 2
Version: HG850a V100R001C05
One-way audio occurs when a user served by the ONT calls a user served by the IAD. That is,
the user served by the ONT can hear the user served by the IAD, but the user served by the IAD
cannot hear the user served by the ONT.
Alarm Information
None
Possible Cause
l The phone set on the IAD side is faulty.
l The configuration data of the ONT or IAD is incorrect.
l Signaling interaction is abnormal.
l RTP packets are not properly forwarded from the ONT to the IAD.
Procedure
Step 1 Initiate calls respectively from users served by the IAD and ONT to mobile users. The service
is normal. This indicates that the phone sets are not faulty.

Module
Step 2 Analyze the signaling exchanged between the SoftX3000, ONT, and IAD. No fault is detected.
Step 3 Capture packets from the upper-layer switch of the IAD and MA5600T. It is found that RTP
packets sent from the ONT can be captured from the upper-layer switch of the MA5600T, but
not from the upper-layer switch of the IAD. RTP packets may be discarded on the network.
Step 4 Analyze the captured packets. It is found that the destination MAC address of each RTP packet
sent from the ONT is the MAC address of the gateway Cisco ASA, but not the MAC address of
the IAD, as shown in Figure 7-12. The destination MAC address of each RTP packet sent from
the IAD is the MAC address of the ONT, and the source MAC address of the RTP packet is the
MAC address of the IAD, as shown in Figure 7-13. It is confirmed that the destination MAC
addresses of packets are the MAC address of the gateway no matter whether the destination IP
addresses are in the same broadcast domain when the HG850a processes voice service packets
such as the RTP packets. Generally, to enable interworking between ONTs in the same network
segment, the ARP proxy (or a similar function) on the gateway must be enabled.
Figure 7-12 RTP packet sent from the ONT
Figure 7-13 RTP packet sent from the IAD
Step 5 Check the configuration of the Cisco ASA. It is found that configuration of the ARP proxy is
not available. Check the RTP packets sent from the IAD. It is found that the source MAC
addresses of these packets are the MAC address of the IAD. This proves that the ARP proxy (or
a similar function) is disabled on the gateway. In this case, after receiving RTP packets sent from

Module
the ONT, the Cisco ASA cannot forward the packets properly and therefore discards these
packets.
Step 6 Plan the IP addresses again. Move the gateway of the ONT to the MA5600T and enable the ARP
proxy on the gateway. The fault is rectified.
----End

None

Noise in a voice call is a fault that a user hears a strong current noise and broadcast noise in
communication, but the noise does not include the environment noise of two parties.
7.4.6.1 TC-C6003 Broadcast Is Played After Offhook Because of the Interference on

the Loop Line
This topic describes how to troubleshoot the fault when a user connected to an ONU hears the
broadcast after offhook because the loop line of the ONU is interfered by external broadcast
signals.
Fault Type
VoIP service
Service failure
Keyword
Loop line
Interference
Fault Description
A voice user is connected to an ONU in a telecommunications room. The user hears the broadcast
after offhook, and the conversation quality is affected.
Alarm Information
None
Cause Analysis
l The OLT delivers abnormal information.
l The ONU is interfered.

Module
Procedure
Step 1 Check the data configurations of the ONU and OLT. It is found that the data configurations are
correct.
Step 2 Replace the ONU with another ONU of the same type to conduct a test. The user still hears the
broadcast, which indicates that the hardware of the ONU is normal.
Step 3 Check the configuration of the softswitch. It is found that the configuration is correct. It is
suspected that abnormal data may exist. Capture packets on the OLT and ONU. No abnormal
data is found.
Step 4 Remove the voice line from the terminal block, and use a test phone to conduct a test in the
telecommunications room. It is found that no broadcast is heard. Connect the loop line to the
terminal block, and use the test phone to conduct a test. It is found that the broadcast is heard.
Therefore, it can be determined that the loop line is interfered.
Step 5 Check the loop line. It is found that the broadcast tower of a broadcast station is very close to
the loop line. The broadcast signals are transmitted to the voice network through the loop line.
Reconstruct the loop line. As a result, the fault is rectified.
----End

Electromagnetic devices interfere the communication greatly. Therefore, if noise exists in the
conversation, you need to consider whether electromagnetic interference exists on the network.
7.4.6.2 TC-C6082 Noise Occurs in the VoIP Service of the ONU Because the OLT
Suffers Network Attacks
This topic describes how to troubleshoot the fault when noise occurs in the VoIP service of the
ONU because the OLT suffers network attacks.
Fault Type
Voice service
Keyword
Noise
Network attacks
Fault Description
Network topology: VoIP user –> MA5606T (ONU) –> MA5600T (OLT) –> SS –> UMG –>
PSTN
Noise often occurs in the VoIP service of the ONU (MA5606T).
Alarm Information
None

Module
Cause Analysis
l The quality of the subscriber line deteriorates.
l Interference source exists in the telecommunications room.
l The DDF grounding is improper.
l The service boards are faulty.
l The upstream transmission is faulty.
Procedure
Step 1 Make calls for test on the DDF and the device separately. It is found that noise exists. This
indicates that the noise is not caused by the poor quality of the subscriber line.
Step 2 Check the environment of the telecommunications room. It is found that both cabling and the
power supply meet the specifications and there is no strong electromagnetic interference. This
indicates that the noise is not caused by the environment.
Step 3 Test the grounding resistance. It is found that the grounding resistance is 3.48 ohms, which is
in the normal range. This indicates that the noise is not caused by improper grounding of the
DDF in the telecommunications room.
Step 4 Test all the boards. It is found they are all faulty. This indicates that the noise is not caused by
service boards.
Step 5 Check the upper-layer device. It is found that an alarm is generated on the OLT indicating that
the CPU usage is high (90%). Ping the gateway from the ONU. It is found that packets with
small sizes are not lost but a long delay exists, and certain packets with large sizes are lost. It is
suspected that the noise occurs because of the high CPU usage of the OLT. After checking, it is
found that the OLT suffers the ARP attack, which leads to high CPU usage. Configure the
firewall for the OLT. It is found that the CPU usage recovers and the noise occurred in the VoIP
service of the ONU disappears.
----End

To rectify the noise fault, follow the method of checking from nearness to farness and from the
hardware to data. After an uncomplicated hardware component is replaced, if the fault persists,
compare data to find out certain differences. That is, do not replace a complicated hardware
component such as the backplane. This minimizes the effect on the current service.
7.4.6.3 TC-C6129 Voice Subscriber Hears Much Noise After Offhook Because the
ASDA Daughter Board Is Faulty
This topic describes how to troubleshoot the fault when the voice subscriber hears much noise
after offhook.
Fault Type
Voice service
Keyword
Noise

Module
Fault Description
MA5616 version: V800R306C01
Fault description: In an office, the voice subscriber of the MA5616 hears much noise after
offhook.
Alarm Information
There is no alarm information, but the alarm LEDs on the ASPB boards in slots 1 and 2 are on
continuously.
Cause Analysis
l The subscriber loop line is faulty.
l The ASPB board is faulty.
l The ASDA narrowband daughter board is faulty.
Procedure
Step 1 Connect a telephone to the MDF for test. It is found that the fault persists. This indicates that
the subscriber loop line is normal.
Step 2 Replace the ASPB board. It is found that the subscriber still hears the noise. This indicates that
the ASPB board is normal.
Step 3 Replace the ASDA narrowband daughter board. It is found that the fault is rectified and the
subscriber makes a call normally.
----End

Generally, if the subscriber hears the noise after offhook, locate the fault from the DSP first. The
DSP of the MA561x is integrated on the ASDA daughter board. Thus, when such a fault occurs,
replace the faulty board with a normal one to rectify the fault.

Voice interruptions in a voice call are a fault that the voice heard by a user in a voice call is
interrupted at times.
7.4.7.1 TC-C6014 Interrupted Conversation Because of Improper QoS

Configuration of the VoIP Service
This topic describes how to troubleshoot the fault when the conversation of an NGN user
connected to an ONU is interrupted because the VoIP QoS of the ONU is configured improperly.
Fault Type
VoIP service

Module
Keyword
QoS
Interrupted conversation
Fault Description
The conversation is interrupted intermittently when a user connected to an ONU makes a phone
call during the running of the ONU.
Alarm Information
None
Cause Analysis
l The data configurations of the softswitch, OLT, or ONU are incorrect.
l Congestion occurs on the link.
l The configuration of the QoS is improper.
Procedure
Step 1 Check the data configuration of the softswitch. It is found that the H.248 interface and signaling
tracing are normal.
Step 2 Check the data configuration of the OLT and the packet forwarding. It is found that the data
configuration is normal, and packets are forwarded normally.
Step 3 Capture packets on the ONU and softswitch sides. It is found that packet loss occurs from the
ONU to the softswitch.
Step 4 Check the data configuration of the ONU because network congestion occurs temporarily. It is
found that qos vlan media 192.168.100.12priority 0 exists in the data configuration, and the
QoS priority is set to 0, which indicates the best effort mode and lowest priority. Therefore, if
network congestion occurs, the VoIP packets may be discarded.
Step 5 Change the priority of voip media of the ONU to 6. As a result, the fault is rectified.
----End

The requirement of the voice service for the network quality is high. Therefore, it is
recommended that you set the priority of voip media of the ONU to 6.

Failure to dial certain phone numbers is a fault that when dialing certain phone numbers, the
user hears "the number you dialed does not exist".

Module
7.4.8.1 TC-C6043 Put-Through Rate of the Long-Distance Calls Is Low Due to Packet
Loss Caused by Loose Optical Fiber Connection on the PON Port of the ONU
This topic describes how to troubleshoot the fault when the put-through rate of the long-distance
calls is low due to packet loss caused by loose optical fiber connection on the PON port of the
ONU.
Fault Type
Voice service
Keyword
Put-through rate
Long-distance call
Fault Description
Network topology: POTS -> ONU (MA5620) -> OLT (MA5600T) -> SBC -> Softswitch
The put-through rate of the long-distance calls for subscribers connected to the ONU is low.
When the subscribers dial the local number to make a call, the system often prompts "the number
you dial does not exist". In addition, the phone lines are sometimes crossed, that is, subscriber
B answers the phone when subscriber A is called.
Alarm Information
None
Cause Analysis
l The ONU does not collect digits correctly.
l The softswitch does not collect digits correctly.
l Packet loss occurs on the network.
Procedure
Step 1 Check the actual network topology and the fault phenomenon. It is found that the faulty ONU
and the normal ONU are installed under the same optical splitter in the same telecommunications
room. Compare the two devices. It is found that all the data configuration is the same. Therefore,
the fault is not caused by incorrect data configuration.
Step 2 Based on the preceding analysis, it can be determined that the fault is an individual one.
Therefore, use the DBwin to capture signaling packets on the faulty ONU.
Step 3 Through the signaling packets, it is found that the digitmap for the local mobile phone issued
by the softswitch is improper.
The specific signaling is as follows:
[05:49:57.890]msg from mgc([61.136.204.190]:2944) to mg([192.168.172.77]:2944):
MEGACO/1 [61.136.204.190]:2944 T=372781572{C=-{MF=A0{E=377948164{dd/ce
{DigitMap=dmap1},
al/*},SG{cg/dt},DM=dmap1{([2-8]xxx|13|15|18|19|0xxx|9xxx|1[012467]x|20x|E|F|x.F|
[0-9].L)}}}}
[05:49:57.900]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):

Module
!/1 [192.168.172.77]:2944 P=372781572{C=-{MF=A0}}

[05:49:58.760]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):
!/1 [192.168.172.77]:2944 T=831{C=-{N=A0{OE=377948164{20000206T05495800:dd/ce
{ds="13",meth=FM}}}}}
After the two digits "13" are dialed, the digitmap is matched. Therefore, the two digits "13" are
reported to the softswitch, and the following nine digits dialed are reported to the softswitch one
by one. When the last digit is reported to the softswitch, the call connection should be performed
at once; however, the softswitch still issues the event for detecting the dialing tone.
[05:50:00.880]msg from mgc([61.136.204.190]:2944) to mg([192.168.172.77]:2944):
MEGACO/1 [61.136.204.190]:2944 T=372781852{C=-{MF=A0{E=377948172{tonedet/std
{tl=*},al/*},SG{}}}}
Analyze the following packet. It is found that the two digits "21" dialed are retransmitted twice.
[05:50:03.520]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):
!/1 [192.168.172.77]:2944 T=835{C=-{N=A0{OE=377948170{20000206T05495900:tonedet/
std{tid=d2}}}}}
[05:50:03.700]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):
!/1 [192.168.172.77]:2944 T=836{C=-{N=A0{OE=377948170{20000206T05495900:tonedet/
std{tid=d1}}}}}
[05:50:07.520]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):
!/1 [192.168.172.77]:2944 T=835{C=-{N=A0{OE=377948170{20000206T05495900:tonedet/
std{tid=d2}}}}}
[05:50:07.570]msg from mgc([61.136.204.190]:2944) to mg([192.168.172.77]:2944):
MEGACO/1 [61.136.204.190]:2944 P=835{C=-{N=A0}}
[05:50:07.700]msg from mg([192.168.172.77]:2944) to mgc([61.136.204.190]:2944):
!/1 [192.168.172.77]:2944 T=836{C=-{N=A0{OE=377948170{20000206T05495900:tonedet/
std{tid=d1}}}}}
Through the preceding analysis, it can be determined that signaling retransmission occurs only
when the network is of poor quality. Therefore, the signaling fails to be transmitted to the
softswitch due to packet loss on the network, which results in the call connection failure.
Step 4 Log in to the ONU, and ping the IP address of the softswitch from the ONU. It is found that the
packet loss rate reaches 20%. The other ONU under the same optical splitter has no packet loss.
Therefore, exchange the optical fibers connected to these two ONUs. It is found that the faulty
ONU returns to the normal state.
Step 5 During the exchange of the optical fiber, it is found that the optical fiber connected to the faulty
ONU is loose. Reconnect the optical fiber. It is found that no pass loss occurs. Then, perform
the dialing test. It is found that all the call connections are normal.
Step 6 The cause of the crossed phone line is as follows: Due to the network problem, during the one-
by-one digit collection, certain digits are retransmitted and certain digits are discarded. As a
result, the softswitch collects the wrong digits. The softswitch performs the connection operation
after receiving 11 digits, and therefore, the crossed phone line occurs. The root cause is the
packet loss on the network.
----End

The packet loss on the network causes many voice faults. No matter what fault occurs, capturing
the voice signaling packet is the base for analyzing and handling the fault.
7.4.8.2 TC-C6045 International Call Fails Due to the Digitmap Matching Problem
When the ONU Is Interconnected with the Softswitch of Another Vendor
This topic describes how to troubleshoot the fault when the international call fails due to the
digitmap matching problem when the ONU is interconnected with the softswitch of another
vendor.

Module
Fault Type
Voice service
Keyword
Digitmap matching
Fault Description
Network topology: ONU (MA5606T) -> OLT (MA5600T) -> Softswitch (from another vendor)
The ONU is interconnected with the softswitch of another vendor. No problem occurs when the
local phone calls and national long-distance calls are made. When the international calls are
made, however, the busy tone is heard after only five numbers are dialed.
Alarm Information
None
Cause Analysis
l No call-out right for the international calls is provided.
l The ONU collects incorrect digits, which results in the busy tone issued by the softswitch.
l The digitmap on the softswitch is incorrectly configured.
Procedure
Step 1 Check the softswitch. It is found that the call-out right for the international calls is provided.
Step 2 Capture the H.248 packets on the softswitch. The captured packets are displayed as follows:
!/2 <00188270C078-QZSS1>:2944 T=2387649548{C=-{MF=AG58900{DM=DM567760351958 {([EF]
[0-9][0-9E].F|EE
xx|FF|EFxxF|ExxExxxxF|100xx|101x.|102x.|108x.|110|114|119|111x.|118x.|120|122|
121xx|123xx|125x.|160|162|
163xx|1643|16500|166xSx.|168xxSxxx|17xxxS.|19xxxxS.|200|2010|20188|20198|20170|
20130|201x.|400xxxxxxx|80
0xxxxxxx|600x.|700x.|950x.|951x.|955xx|958x.|968xxx|96168xxxxx|9[0-5]xxxSx.|9[7-9]
xxxSx.|96[0-2]xxSx.|96
[4-9]xxSx.|963xx|96366xSx.|00xxSx.|01[358]xxxxxxxxx|010xxxSxxxxx|02xxxxSxxxxx|059
[2346789]xxxSxxxx|059[1
5]xxxSxxxxx|0[346789]xxxxxSxxxxx|05[012345678]xxxxxSxxxxx|0311xxxSxxxxx|037[179]
xxxSxxxxx|04[15]1xxxSxxx
xx|051[023]xxxSxxxxx|053[12]xxxSxxxxx|057[147]xxxSxxxxx|075[57]xxxSxxxxx|
0769xxxSxxxxx|089[18]xxxSxxxxx|
026023xxxSxxxxxSxxx|[2-8]xxxxxx|1[358]xxxxxxxxx)},E=2388331963{dd/ce
{DM=DM567760351958 },mfd/ce{DM=DM567
760351958 },al/on,al/fl},SG{cg/dt}}}}
2008-12-09 09:59:18.68
Receive
10.32.102.23:2944
10.32.100.6:2944
MOD_REPLY
Text
!/2 <00188270c078>:2944 P=2387649548{C=-{MF=AG58900}}
2008-12-09 09:59:18.68
Send
10.32.100.6:2944
10.32.102.23:2944

Module
RSPACK
Text
!/2 <00188270C078-QZSS1>:2944 K{2387649548}
2008-12-09 09:59:20.87
Receive
10.32.102.23:2944
10.32.100.6:2944
NTFY_REQ
Text
!/2 <00188270c078>:2944 T=2684{C=-{N=AG58900{OE=2388331963{20081209T10081700:dd/ce
{ds="00852",meth=FM}}}}}
2008-12-09 09:59:20.87
Send
10.32.100.6:2944
10.32.102.23:2944
NTFY_REPLY
Text
!/2 <00188270C078-QZSS1>:2944 P=2684{C=-{N=AG58900}}
2008-12-09 09:59:20.87
Send
10.32.100.6:2944
10.32.102.23:2944
MOD_REQ
Text
!/2 <00188270C078-QZSS1>:2944 T=2387649549{C=-{MF=AG58900{SG{cg/bt}}}}
Step 3 From "ds="00852",meth=FM", it can be determined that the ONU collects the digits and reports
"00852" to the softswitch. After receiving the number, the softswitch directly plays the busy
tone (SG{cg/bt). The reason why the softswitch plays the busy tone is that the softswitch does
not collect digits completely. On the access side, however, the digits are collected according to
the digitmap, and "FM" is matched. The digitmap of the international call configured on the
softswitch of this vendor is "00xxSx.". The ONU, however, implements the minimum matching
of the digitmap by default. Therefore, after five digits are matched, the ONU reports the number.
As a result, the digits are collected incompletely. Change the digitmap matching mode to
maximum matching on the ONU. The digit collection is normal, and the international calls can
be made. The fault then is rectified.
----End

When Huawei device is interconnected with the softswitch of another vendor, it is recommended
that you change the digitmap matching mode of Huawei device to maximum matching.
In the case of the ONU (MA5606T), the digitmap is set in the software parameters of the MG
interface. In terms of the MDU (MA562x), the digitmap matching mode is changed by loading
and setting the profile file.
7.4.8.3 TC-C6059 Subscribers Cannot Dial 10060 or 10000 Due to a Lack of the
Digitmap
This topic describes how to troubleshoot the fault when subscribers connected to the SIP terminal
fail to dial 10060 or 10000 due to a lack of the digitmap.
Fault Type
Voice service

Module
Keyword
Digitmap
Fault Description
POTS subscribers connected to the SIP terminal (HG850e) can dial any number except 10060
and 10000. When they dial 10060 or 10000, the system prompts a message, indicating that they
cannot dial the number.
Alarm Information
None
Cause Analysis
The digitmap is determined by the SIP terminal. The digitmap in the faulty office is as follows:
[2-8]XXXXXXX|013XXXXXXXXX|015XXXXXXXXX|13XXXXXXXXX|15XXXXXXXXX|010XXXXXXXX|
02XXXXXXXXX|0[3-9]
XXXXXXXXXX|9XXXX|201|1[01246-9]X|[*#]+X[0-9*]+#|[0-9][0-9]+#|X+T|**XX|[*#]9X
Apparently, the 100xx field is not included in the digitmap. Therefore, subscriber cannot dial
10060 or 10000.
Procedure
Step 1 Add the 100xx field to the digitmap of the SIP terminal. The new digitmap is as follows:
[2-8]XXXXXXX|013XXXXXXXXX|015XXXXXXXXX|13XXXXXXXXX|15XXXXXXXXX|010XXXXXXXX|
02XXXXXXXXX|100xx|0
[3-9]XXXXXXXXXX|9XXXX|201|1[01246-9]X|[*#]+X[0-9*]+#|[0-9][0-9]+#|X+T|**XX|[*#]9X
Step 2 Dial 10060 and 10000. The call service is normal.
----End

When such a fault occurs on the SIP terminal, modify the digitmap. For example, when the
189xxxxxxxx is provisioned by China Telecom, corresponding field needs to be added to the
digitmap.
7.4.8.4 TC-C6142 Certain Phones Fail to Be Connected Because the Dialing Rule in
the Default Digitmap Is Excessively Short
This topic describes how to troubleshoot the fault when a voice message is played indicating
that the dialed phone number does not exist.
Fault Type
Voice service
Keyword
Dialing rule, SIP, control point, call failure

Module
Fault Description
Network topology: Phone -> MSAN (MA5600T) -> IMS
Version: MA5600T V800R006C02
Fault description: The VoIP users are connected to the MA5600T through the ASPB voice board
to achieve the SIP VoIP service. After configuration, the registration of number (08038878502)
of the local phone and number (08038878501) of the peer phone on the IMS is successful. Each
time when the VoIP user dials the number of the peer phone from the local phone, a voice
message is played indicating that the dialed phone number does not exist.
Alarm Information
None
Cause Analysis
l The VoIP configurations are incorrect.
l The dialing rule is incorrect.
Procedure
Step 1 Capture packets on the upstream port of the MA5600T by mirroring. It is found that the
MA5600T reports phone number 0803887850 to the IMS, in which the last digit of the actual
number is lost. This indicates that the dialing rule of the MA5600T may be incorrect.
Step 2 Check the digitmap file in the files for upgrading the device to the current version. It is found
that the dialing rule defines numbers supported 1 digit shorter than the number series such as
08038878501.
[digitmap-definition-3]
DigitmapName=defaultNormalDigitmap
DigitmapType=0
DigitmapBody=([2-8]xxxxxxx|[2-8]xxSxxxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]
x|F|x.F|[0-9].S) ///0xxxxxxxxx are 10 digits and 08038878501 series are 11 digits.
Step 3 Modify control point 49 of the SIP service profile to 1. It is found that the fault is rectified. The
configuration commands are as follows:
huawei(config)#interface sip 0
huawei(config-if-sip-0)#sipprofile modify syspara 49 1
huawei(config-if-sip-0)#reset
NOTE
Control point 49 indicates that whether the digitmap is with the maximum match. 0 indicates the non-
maximum match and 1 indicates the maximum match. The MA5600T is configured with non-maximum
match by default.
The maximum match indicates that after a successful digitmap matches, the phone number is reported to
the IMS after a period of time (5s by default). In the 5s, the received phone numbers are also reported to
the IMS.
----End

Phone number rules vary with counties. If a phone number is very long, the device may report
an incomplete number to the IMS. When such a fault occurs, it is recommended that you modify
the dialing rule of the SIP service profile to maximum match.

Module
7.4.8.5 TC-C6181 Dialing Failure Because Phones of the MA5616 Are Connected to
IP Dialers
This topic describes how to troubleshoot the fault when the dialing failure occurs.
Fault Type
Voice service
Keyword
Dialing abnormal, MA5616, #, do
Fault Description
The MA5616 is subtended to the MA5600T. After dialing, phones connected to the MA5616
play the prompt "Sorry! The number you dialed does not exist" or does not play tones. After one
minute, break tones are played.
Network topology: Most of phones are connected to IP dialers.
Alarm Information
None
Cause Analysis
None
Procedure
Step 1 Replicate the fault onsite and capture signaling using the toolbox for analysis. It is found that
the last bit tid reported by all toll calls is do (tid = do). According to the H.248 protocol, tid =
do reported by the AG indicates that the user dials #.
Step 2 Disconnect IP dialers, dial again, and trace signaling. It is found that tid = do is not reported.
Step 3 Analyze signaling. It is found that IP dialers abnormally report #. That is, # is reported when
dialing is not complete. As a result, dialing fails.
Step 4 Disconnect IP dialers. It is found that the fault is rectified.
----End

To shorten the call connection time, IP dialers report # as dialing end event. Fault symptoms
vary with # locations. That is, the number dialed does not exist or no tone is played after dialing.
After one minute, break tones are played.
When such a fault occurs, learn about the network topology, including involved devices and
components.

Module
7.4.8.6 TC-C6190 There Is a Possibility That Number Loss Occurs When a User
Connected to the MA5616 Makes Long-Distance Calls
This topic describes how to troubleshoot the fault that number loss occurs when a user makes
long-distance calls.
Fault Type
Voice service
Keyword
Underreported digits, profile, long-distance call, number loss
Fault Description
Number loss occurs when a user connected to the MA5616 makes long-distance calls. For
example, when the user dials 17909 + Phone number, the number received on the softswitch is
1799 + Phone number. The softswitch is the Huawei SoftX3000.
This fault is not caused by the version or the network topology.
Alarm Information
None
Cause Analysis
The Huawei softswitch uses the digitmap in the default shortest match mode when reporting a
number.
When reporting a number in the normal situation, the MA5616 reports 179 first to the softswitch
according to digitmap 1[0124-9]x. After receiving 179, the softswitch detects that some digits
of the number are not received and issues the tonedet/std signaling to receive the number digit
by digit. Then the MA5616 continues to report the number digit by digit. Possible causes of the
fault are as follows:
l Packet loss occurs on the MA5616; as a result, digit 0 is lost when the MA5616 reports
digits of the number.
l The patch of the MA5616 is not loaded.
l The digit is discarded on the MA5616.
Procedure
Step 1 Transmit ping packets. It is found that the packets are not lost between the MA5616 and the
softswitch, but sometimes the delay is large.
Step 2 Load the latest patch on the MA5616. It is found that the fault persists after the patch is loaded.
Step 3 Trace the signaling on the MA5616 by using the DBwin. It is found that the msg from mg to
mgc: !/1 [10.75.25.132]:2944 T=370819782{C=-{N=A240{OE=655051268
{20100520T01070300:tonedet/std{tid=d0}}}}} signaling is not reported to the softswitch when
the fault occurs. This indicates that the signaling is discarded on the MA5616.It is also found
that sometimes the delay between the MA5616 and the softswitch increases abruptly. As a result,

Module
the MA5616 receives digit 0 reported by the user before the detect event issued by the softswitch.
In this case, digit 0 is discarded by the MA5616.
Step 4 Modify the profile so that the MA5616 buffers received digits and reports them after receiving
the tonedet/std signaling. The profile can be modified in the following ways:
1. Set the ID of the existing profile to 0.
MA5616(config-if-h248-0)#if-h248 attribute profile-index 0
2. Set control points 0 and 44 of the profile to 1.

Step 5 Perform a dialup test. It is found that the service is restored.
----End

When number loss occurs, you can locate and rectify the fault as follows:
l You can check whether packets are lost on the link. The Huawei softswitch receives the
number digit by digit. If packets are lost, number loss occurs.
l You can check whether the patch of the MA5616 is the latest one. Some number-loss-
related faults are rectified in the patch.
l You can set control points 0 and 44 of the profile on the MA5616 to 1 for buffering digits.
l You can also set the digitmap from the shortest match mode to the longest match mode.
But this setting will lead to slow addressing speed when the user makes calls.
7.4.8.7 TC-C6195 MA5620 Users Fail to Call Local Fixed Phones Because of IMS
Calling Prefix Conflict
This topic describes how to troubleshoot the fault when the MA5620 users fail to call local fixed
phones.
Fault Type
Voice service
Keyword
IMS, prefix, 484, SIP
Fault Description
Version: MA5620 V800R307C01SPC500
Network topology: ONU (MA5620) -> MA5600T -> IMS -> PSTN (voice gateway office)
Fault description: When MA5620 users serve as callers, they fail to call local fixed phones but
can dial mobile phones. When they serve as callees, they can answer both fixed phone and mobile
phones.
Alarm Information
None

Module
Cause Analysis
l The calling prefix of the softswitch is incorrect.
l The gateway connection is faulty.
Procedure
Step 1 Check that MA5620 users can call all phones except fixed phones. This indicates that the
MA5620 configurations are correct.
Step 2 Trace SIP signaling. It is found that after receiving the INVITE message, the IMS responds with
both message 100 and message 484. However, message 180 indicating ringing needs to be
reported. Message 484 indicates incomplete ringing.
Step 3 It is suspected that the IMS calling prefix is incorrect. Check the IMS configurations. It is found
that the prefix conflicts with the access code.
Step 4 Delete the conflicted access codes. It is found that fixed phones can be called and the fault is
rectified.
----End

None
7.4.9 Abnormal Fax Service

Abnormal fax service is a fault that a user fails to receive or send a fax.
7.4.9.1 TC-C6074 Fax Cannot Be Received or Transmitted Due to Incorrect Fax-

Modem Setting
This topic describes how to troubleshoot the failure to receive or transmit the fax service data
due to incorrect fax-mode setting.
Fault Type
Voice service
Keyword
Fax
fax-modem
Fault Description
On the newly deployed MA561x, the fax cannot be received or transmitted.
Alarm Information
None

Module
Cause Analysis
l Signaling exchange is abnormal.
l Settings of the softswitch are incorrect.
l The fax parameters are incorrect.
Procedure
Step 1 Trace signaling. It is found that signaling exchange is normal.
Step 2 Check settings of the softswitch. It is found that settings are correct.
Step 3 Run the following command to check the fax-modem parameter.

MA5612(config)#display fax-modem parameters
-----------------------------------------------------------------------------
Negomode : Negotiation
Packet-interval-10ms : Disable
Rfc2198-start-mode : enable Rfc2198SmartStartup
Vbd-codec : G.711A
Vbd-payload-type : Static
TransEvent : ControlledByMGC
-----------------------------------------------------------------------------
Step 4 It is found that the Rfc2198-start-mode parameter is enabled. Then, run the fax-modem
parameters rfc2198-start-mode disable Rfc2198SmartStartup command to disable this
parameter. It is found that the fax service recovers.
----End

Through RFC2198, the redundancy mode for transmitting the data service is automatically
enabled. If the redundancy mode is enabled on the local device, it must be enabled on the peer
end. The peer gateway is generally disabled; therefore, the Rfc2198-start-mode parameter must
be disabled on the MA561x.
7.4.9.2 TC-C6076 Faxing a Document to Certain Numbers Is Successful While

Faxing the Document to Others Fails
This topic describes how to troubleshoot the fault when faxing a document to certain numbers
is successful while faxing the document to others fails.
Fault Type
Voice service
Keyword
Fax
Level
Fault Description
Network topology: Fax machine –> ONU(MA5620) –> Bearer network –> UMG –> PSTN

Module
When a certain user of the ONU transmits faxes to PSTN users, faxing a document to certain
numbers is successful while faxing the document to others fails. The user's POTS service is
normal and can receive faxes normally. In addition, the users of a PON port can transmit faxes
normally to each other.
Alarm Information
None
Cause Analysis
l The fax machine is faulty, which leads to a negotiation failure.
l A fault occurs when the UMG switches the fax.
Procedure
Step 1 The most common method of handling fax problems is to capture packets on the network side,
record voice on the UMG side, and trace signaling on the SoftX3000. Trace signaling on the
SoftX3000, record voice on the UMG8900, and capture packets on the PON upstream port, and
then analyze the captured packets. It is found that the level of the V21 signal from PSTN is very
low (about -27 dB). This level is out of the UMG detection threshold (for a common fax machine,
this threshold is -20 dB by default).
Step 2 Then, change this threshold to -28 dB. The numbers that cannot be used for faxing before can
be used for faxing normally.
----End

l You can enlarge the range of the UMG signaling detection to avoid such a fault. Currently,
the detection level on the UMG8900 is lowered to -28 dB. Although the preceding problem
of the low level is solved after the level is lowered to -28 dB, the echo signals from PSTN
are also detected. In worse situations, the telephony and fax services are affected and the
echo problems, once happening, cannot be solved. In addition, when the level of the V21
signal from PSTN is lower than -27 dB, faxing the document to certain numbers also fails.
In short, this level threshold must not be set too low. In terms of the current value (-28 dB),
if no problems are found after a period of time, temporarily use this value; if certain
interference exists, change the level threshold back to -20 dB.
l To rectify this fault, you can increase the level of the V21 signal from PSTN to a value
greater than -20 dB. Ensure that the level is between -11 dB to -19 dB (about -15 dB is the
best). The commonly used method is to replace the fax machine on the PSTN side.
7.4.9.3 TC-C6084 Fax Service Fails on the ONU Because the RFC2198 Function Is
Not Enabled on the Softswitch
This topic describes how to troubleshoot the fault when the fax service fails on the ONU because
the RFC2198 function is not enabled on the softswitch.
Fault Type
Voice service

Module
Keyword
RFC2198
Fax
Fault Description
Huawei ONU (MA5616) is deployed in an office of a carrier. The carrier complains that faxes
cannot be received or transmitted normally.
Alarm Information
None
Cause Analysis
l The fax machine is faulty.
l The fax mode of the ONU is different from the fax mode of the softswitch.
l Certain parameters of the ONU mismatch those of the softswitch.
Procedure
Step 1 The user is migrated from the switch to the optical access device, so it can be determined that
the fault is not caused by the fax machine.
Step 2 Ping the signaling gateway. It is found that no packet loss occurs.
Step 3 Check the data configurations of the fax machine and the softswitch. It is found that the
parameters match each other, as shown in the following:
FAX transfers mode :Thoroughly
T38 Fax Port :RTP port
FAX flow :V3 Flow
Step 4 Run the display fax-modem parameters command to check the configurations of the fax
service. It is found that the ONU supports RFC2198. Then, it is suspected that RFC2198 is not
enabled on the peer device. Capture signaling. It is then found that all services are normal from
the start of fax flow to connection, but the fax service is interrupted during the negotiation of
fax parameters. Then, it is determined that parameters are consistent. Modify the RFC2198
parameter to Disable Rfc2198SmartStartup and then test the fax service again. It is found that
the fax service becomes normal. The fault is rectified.
----End

On Huawei ONU (MA5616), the RFC2198 function is enabled by default. RFC2198 improves
the reliability of data transmission through redundant transmission. When the network quality
is poor, redundant transmission can ensure the service quality.

Module
7.4.9.4 TC-C6115 MA5620G Fails to Receive and Transmit Extranet Faxes Because
of Incorrect Fax Configurations of the Softswitch
This topic describes how to troubleshoot the fault when the MA5620G fails to receive and
transmit extranet faxes.
Fault Type
Voice service
Keyword
Fax
Fault Description
Network topology: Fax machine -> ONU (MA5620G) -> OLT (MA5600T) -> Softswitch
(SoftX3000)
Fault description: ONUs connected to the same OLT can receive and transmit faxes normally
but ONUs connected to different OLTs fail to receive and transmit faxes.
Alarm Information
None
Cause Analysis
l The fax machine is faulty.
l The network is of poor quality.
l The RFC2198 function of the ONU is enabled.
l The softswitch configurations are incorrect. For example, the no fax and no modem options
are selected.
l The communication protocol that is used between the ONU and the softswitch is incorrect.
Procedure
Step 1 Transmit faxes between ONUs that are connected to the same OLT or different OLTs separately.
It is found that faxes fail to be transmitted and received between ONUs connected to different
OLTs. However, faxes can be transmitted and received between ONUs connected to the same
OLT. This indicates that the peer fax machines are normal.
Step 2 Ping the signaling gateway and media gateway of the softswitch from the ONU. It is found that
packet loss does not occur. This indicates that the network functions properly.
Step 3 Check fax configurations of the ONU. It is found that the RFC2198 function is disabled.
MA5620G#display fax
{ parameters<K> }:parameters
Command:
display fax parameters
-----------------------------------------------------------------------------
Fax transfers mode :V3 flow
T38 Fax Port :RTP port
Fix the package interval as 10ms :disable

Module
RFC2198 intelligent startup :disable

-----------------------------------------------------------------------------
Step 4 Check fax configurations of the softswitch. It is found that the no fax and no modem options are
deselected.
Step 5 Exchange packets between the ONU and the softswitch in the T.38 mode. Capture and analyze
the exchanged packets. It is found that SDP configurations of the local ONU does not contain
T.38 codes, which indicates that the softswitch does not issue the signaling for switching the T.
38 channel to the ONU. The correct signaling that needs to be issued to the ONU from the
softswitch is as follows:
L{v=0
c=IN IP4 172.27.96.86
m=image 49528 udptl t38
a=ptime:20
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38MaxBitRate:14400 },
Step 6 Cancel local SDP Address Present from configurations of the softswitch. It is found that
extranet faxes can be transmitted and received.
----End

local SDP Address Present indicates whether the media gateway can change the local IP address
during media stream creations and then submits the confirmed result to SDP connection
parameter c.
7.4.9.5 TC-C6122 Fax Service Failure Occurs on the ONT Because the IMS Does Not
Support T.38
This topic describes how to troubleshoot the fault when the fax service failure occurs on the
ONT.
Fault Type
SIP VoIP service
Keyword
T.38
Fault Description
Network topology: Fax machine -> ONT (HG850a) -> OLT (MA5600T) -> IMS
Fault description: The OLT is connected to two ONTs and the two ONTs are connected to two
fax machines respectively. A fax fails to be sent between the two fax machines; however, the
fax can be sent between either of these two fax machines and a fax machine in the network.
Alarm Information
None

Module
Cause Analysis
l The configuration of the ONT is incorrect.
l The configuration of the IMS is incorrect.
Procedure
Step 1 Capture packets on the IMS for analysis. When an ONT sends a fax, the INVITE message for
negotiating the fax capability carries the T.38 protocol. After receiving the INVITE message,
the IMS returns an OK message that also carries the T.38 protocol. Then, the IMS sends an
INVITE message that carries the G.711 protocol. When receiving such a message, the ONT
responds an OK message that carries the G.711 protocol.
Step 2 Check fax services configurations on the two ONTs. It is found that configurations are the same.
On the IMS, however, one ONT not configured to support T.38. Thus, G.711 is used in fax
negotiation.
----End

The ONT supports both G.711 and T.38 fax modes. Though the T.38 mode is enabled on the
ONT, if on the IMS the ONT is not configured to support T.38, G.711 is used for the fax service.
The SIP VoIP service is mainly controlled by the IMS. Thus, if other services are faulty when
a call is connected, check the ONT and IMS configurations.
7.4.9.6 TC-C6194 MA5620 Users Fail to Receive Faxes Because Parameters Are
Incorrectly Configured on the SIP Profile
This topic describes how to troubleshoot the fault when the MA5620 users fail to receive faxes.
Fault Type
Voice service
Keyword
SIP profile, fax, receive, IMS, 147
Fault Description
Network topology: Fax machine -> ONU (MA5620) -> MA5600T -> IMS -> PSTN -> Fax
machine
Version: V800R307C01SPC500
Fault description: The MA5620 is connected to the IMS using the SIP protocol. Users of an
MA5620 fail to receive faxes transmitted from users of another MA5620 but can transmit faxes
successfully. However, users of an MA5620 can transmit and receive faxes with each other.
Alarm Information
None

Module
Cause Analysis
l The ONU configuration is incorrect.
l The IMS is faulty.
Procedure
Step 1 Two POTS ports on the MA5620 are connected to two fax machines. After testing, it is found
that faxes can be transmitted and received. This indicates that faxes can be transmitted and
received by users of the same MA5620.
Step 2 Configure the fax numbers to another MA5620. It is found that faxes can be transmitted and
received.
Step 3 Collect data of the normal and faulty MA5620 separately and then compare the collected data.
It is found that parameter 147 configured on the SIP profile of the normal MA5620 is 0 but that
of the faulty MA5620 is 3.
Step 4 Run the sipprofile modify command to modify parameter 147 configured on the SIP profile of
the faulty MA5620 to 0.
Step 5 Reset the SIP interface and transmit and receive faxes for testing. It is found that faxes can be
transmitted and received and the fault is rectified.
----End

When the fax service is configured on the MA5620, parameter 147 configured on the SIP profile
must be set to 0 or 1. These two values are specially used for interconnecting to the IMS. Value
3 is used for interconnection outside China. Therefore, this value must be modified in
deployment inside China.
7.4.9.7 TC-C6236 Fax Service Is Intermittently Interrupted Owing to the Fault of the
Upper-Layer Optical Line of the OLT
This topic describes how to troubleshoot the fault when the fax service is intermittently
interrupted.
Fault Type
Voice service
Keyword
Fax machine, intermittent interruption
Fault Description
Network topology: Fax machine -> MA5610 -> OLT -> NE40E -> Upper-layer network
On the 10 machines connected to the MA5610, the fax service is intermittently interrupted.

Module
Alarm Information
None
Possible Cause
l The external line is faulty.
l The fax machines are faulty.
l Packets are lost on the link.
l A board of the MA5610 is faulty.
Procedure
Step 1 Test the fax service on site. The fax machines of some brands sometimes can send and receive
faxes and sometimes cannot send or receive faxes. The fax machines of other brands always
cannot send or receive faxes.
Step 2 Adjust the lines on the cable distribution frame on the user side in the equipment room. The fault
persists.
Step 3 Modify the configuration of the MA5610 V800R307C01SPH506 that uses the SIP protocol. Set
parameter 147 to 0, 1, and 2, respectively. Conduct a fax service test. The fault persists. After
the test, set parameter 147 to 0.
Step 4 Simulate the environment on site and capture packets. Analyze the RTP packets. It is found that
some packets are lost.
Step 5 On the MA5610, ping the upper-layer voice gateway (NE40E) and the upper-layer SBC interface
address. No packets are lost. On the MA5610, ping the large 1498-byte packets sent to the voice
gateway (NE40E). A lot of packets are lost.
Step 6 Check the line section by section. It is found that packets are lost on the line between the OLT
and the NE40E.
Step 7 Replace the optical fiber between the OLT and the NE40E.
Step 8 On the MA5610, ping the upper-layer voice gateway (NE40E) and the upper-layer SBC interface
address again. No packets are lost and the fax service becomes normal.
----End

When handling faults related to the fax service, adjust the SIP parameters. In addition, pay close
attention to subscriber lines.
7.4.10 Abnormal Voice Interruption

Abnormal voice interruption is a fault that the voice heard by a user in a voice call is interrupted
suddenly.
7.4.10.1 TC-C6060 The Voice Service Is Interrupted Intermittently Due to the

Redundant Configuration of the POTS Ports
This topic describes how to troubleshoot the fault when the voice service is interrupted
intermittently because the POTS ports are configured redundantly.

Module
Fault Type
Voice service
Keyword
Intermittent interruption of the voice service
Fault Description
The ONT (HG850e) is configured with the SIP-based voice service. After the configuration, it
is found that the voice service is interrupted every three minutes. This fault occurs repeatedly
after the number is dialed.
Alarm Information
None
Cause Analysis
l The configuration of the OLT is incorrect.
l The configuration of the upper-layer softswitch is incorrect.
l The ONT hardware is faulty.
l The configuration of the ONT is incorrect.
Procedure
Step 1 Check the configuration of the voice service on the OLT. It is found that the configuration is
correct, and no related alarm is generated.
Step 2 Replace the phone. The fault, however, persists.
Step 3 Through the investigation, it is known that the upper-layer softswitch is from another vendor.
The configuration may be incompatible. Therefore, contact the customer to check the softswitch.
It is found that the configuration of the softswitch is correct.
Step 4 Check the ONT. It is found that the ONT is online, and all the LEDs on the ONT are normal.
Then, replace the ONT. The fault, however, persists.
Step 5 Check the configuration of the ONT. It is found that two POTS ports are configured with the
number, user name, and password, but only one POTS port is connected to a phone. The SIP
registration interval is 180s. Therefore, the fault may be caused by the re-registration of the
POTS port connected to no phone. When the POTS port registers every 180s, the upper-layer
softswitch regards the signaling exchange as abnormal because this POTS port is not connected
to a phone, and therefore, the softswitch disconnects the call communication.
Step 6 Delete the configuration of the POTS port that is not used. The fault then is rectified.
----End

Module

The ONT (HG850e) has two POTS ports. If only one POTS port is used, make sure that the
POTS port that is not used is not configured with the information such as the number and the
user name.
7.4.10.2 TC-C6063 Voice Service of the ONU Connected to an OLT Is Abnormal

Caused by Incorrect Configurations of Link Aggregation
This topic describes how to troubleshoot the fault when voice service of the ONU connected to
an OLT is abnormal due to incorrect configurations of link aggregation.
Fault Type
Voice service
Keyword
MAC address drift
Link aggregation
Fault Description
The voice services of certain ONUs connected to an OLT (MA5600T) are abnormal, with
frequent conversation interruption. In addition, the MG interface disconnection alarm is
generated on the ONUs, and packet loss is severe when the gateway (NE40E) is pinged by using
the IP address of the MG. The PPPoE service and the NMS (Network Management Server),
however, are normal. The networking is as follows:
|-----MA5200G(PPPoE)
ONU--MA5600T--S8016
|-----NE40E (NGN voice)
Alarm Information
An MG interface disconnection alarm is generated on the ONU.
Cause Analysis
l The link is faulty.
l Configurations of the OLT and ONUs are incorrect.
Procedure
Step 1 Links between ONUs and the NE40E is faulty. This possible cause is ruled out because only the
voice service is abnormal and other services are normal.
Step 2 The MAC address learning of the OLT is abnormal. Check the MAC address entries on the
MA5600T. It is found that the MAC addresses of the ONUs with the abnormal voice service are
often learned by upstream port 0/19/0 (that is, the MAC address drift occurs).
Step 3 Check data configurations on the OLT. It is found that upstream ports have already been
configured with link aggregation, and upstream ports 0/19/0 and 0/19/1 transparently transmit
all service VLANs. Then, check data configurations on the S8016. It is found that link

Module
aggregation is not configured and that port 2/0/13 corresponding to port 0/19/1 transparently
transmits only VLAN 705. Therefore, the MAC address drift occurs only on VLAN 705 and
services of this VLAN are affected.
Step 4 Configure link aggregation on the S8016 to transparently transmit all service VLANs. Then, the
voice service recovers.
----End

None
7.4.10.3 TC-C6093 H.248 Interface of the MA5616 Is Intermittently Disconnected

Because the Softswitch Does Not Respond to Request 904 Sent by Certain TIDs
This topic describes how to troubleshoot the fault when the H.248 interface of the MA5616 is
intermittently disconnected because the softswitch does not respond to request 904 sent by
certain TIDs.
Fault Type
MG interface
Keyword
Intermittent disconnection of an H.248 interface
Interrupted session
Fault Description
Network topology: Telephone -> ONU (MA5616) -> OLT (MA5600T) -> Softswitch (Soft3000)
Fault description: In an office, the MA5616 is connected to the Soft3000, but the VoIP service
is interrupted at intervals of between 10 and 20s. Check the alarm generated on the MG interface,
which indicates that the H.248 interface is intermittently disconnected at intervals of between
10 and 20s.
Alarm Information
The H.248 interface disconnection alarm is frequently generated.
Cause Analysis
l Configurations of the MA5616 are incorrect.
l The link between the MA5616 and the softswitch is faulty.
l Signaling exchange between the MA5616 and the softswitch is abnormal.
l The software of the MA5616 is faulty.

Module
Procedure
Step 1 Check configurations of the MA5616. It is found that configurations are correct. Then, check
the profile referenced by the H.248 interface. It is found that the profile is the profile 1:NoProfile
("") of the Soft3000, which indicates that the profile is correct.
MA5616(config)#display if-h248 attribute 0
-------------------------------------------------
MGID
0
MG Description
-
MG DomainName
-
Protocol
H248
Start Negotiate Version
1
Profile Negotiation Parameter
enable
Profile index 1:NoProfile("")
...
-------------------------------------------------
Step 2 Check whether any packets transmitted from the MA5616 to the softswitch are lost. Ping the
softswitch from the MA5616 consecutively 5000 times. It is found that no packets are lost, which
indicates that the link between the MA5616 and the softswitch is normal.
Step 3 Check whether the software of the MA5616 is correct. Then, run the reboot system command
to the MA5616. It is found that the fault persists.
Step 4 Trace the signaling. It is found that when the interface is reset, TIDs (ranging from A0 to A191)
of all the ports of the MA5616 send request 904 to the MGC. But actually, the MA5616 supports
only 64 telephones and the softswitch is configured with only 64 TIDs (ranging from A0 to
A63). Therefore, TIDs ranging from A64 to A191 configured on the MA5616 are junk data. In
addition, the softswitch responds with correct message, such as P=388650384{C=-{SC=A13
{SV{V=1}}}}, to the request 904 sent by the TIDs ranging from A0 to A63; and responds with
error 430, such as P=372844506{C=-{MF=A64{ER=430{"A64"}}}}, to the request 904 sent
by the TIDs ranging from A64 to A191. The softswitch, however, does not respond to the request
904 sent by certain TIDs. As a result, the MA5616 sends message 900 to reset the interface.
Step 5 Delete TIDs ranging from A64 to A191 from the MA5616 so that these TIDs do not send request
904 to the MGC. It is found that the H.248 interface is not reset and the fault is rectified.
----End

None
7.4.10.4 TC-C6130 MG Interface Is Interrupted Because the Management VLAN of

the ONU Is Incorrectly Changed
This topic describes how to troubleshoot the fault when the MG interface is disconnected.
Fault Type
H.248 VoIP service

Module
Keyword
The MG interface is disconnected.
Fault Description
Fault description: The original management VLAN and the VoIP service VLAN of the ONU
are the same. After the management VLAN and management IP address are changed according
to customer requirement, the MG interface is disconnected.
Alarm Information
The MG interface is disconnected.
Cause Analysis
l The configurations of the H.248 interface on the ONU are lost.
l The configurations of the VLAN or configurations of the route of the ONU are incorrect,
which leads to MGC disconnection.
l The other network device is faulty, which leads to MGC disconnection.
Procedure
Step 1 When the MG interface is disconnected, ping the softswitch for test. Ping the softswitch from
the ONU, but the ping operation fails. Ping the IP address of the voice gateway from the ONU,
but the ping operation also fails.
Step 2 On the ONU, run the display vlan 100 command to check the configurations of the VoIP service
VLAN of the ONU. Assume that the ID of the VoIP service VLAN is 100. It is found that the
Standard port number is 0, which indicates that the configurations of the upstream port in the
VoIP service VLAN are lost.
Step 3 On the ONU, run the port vlan command to add an upstream port to the VLAN. Then, the ONU
can ping the softswitch and the MG interface is connected.
----End

On the OLT, when you run the ont ipconfig command to change the management VLAN of the
ONU, the configurations of the original management VLAN of the ONU are automatically
deleted. The original management VLAN is configured with the VoIP service; thus, the VLAN
cannot be deleted and only the upstream port in the VLAN is deleted. As a result, the route
between the ONU and the softswitch is unreachable and the VoIP service is interrupted.
7.4.10.5 TC-C6162 H.248 Interface Is Disconnected Repeatedly Because the Primary/

Secondary MAC Addresses of the ONU Are Reversely Configured
This topic describes how to troubleshoot the fault when the H.248 interface is disconnected
repeatedly.

Module
Fault Type
Voice
Keyword
H.248 interface disconnection, call interruption
Fault Description
The H.248 interface is disconnected repeatedly; therefore, the narrowband users do not hear dial
tones sometimes after picking up phones and communications are interrupted.
Alarm Information
H248 interface interruption
Cause Analysis
l The network is of poor quality. For example, network interruption or packet loss occurs.
l Data configurations are incorrect.
l The control board is faulty.
Procedure
Step 1 Log in to the ONU for checking. It is found that a large number of interface interruption alarms
are generated. Ping the MGC from the ONU. It is found that packets are not lost but the interface
interruption alarm is generated. This indicates that the fault is not caused by poor network quality.
Step 2 Check configurations of the H.248 interface. It is found that configurations are correct.
Step 3 Trace the signaling of the H.248 interface. It is found that the ONU proactively initiates the hot
startup request (RE="902") to the active MGC at a specified interval and the MGC responds
with an error (ER=402{"unknown MGW"}). Then, the H.248 interface is disconnected. After
that, the ONU initiates the register request to the standby MGC and the MGC responds to the
ONU normally. Then, the H.248 interface recovers. The H.248 interface is disconnected
repeatedly in such a process.
Step 4 Compare the data configurations of the ONU with those of the MGC. It is found that the primary/
secondary MAC addresses of the ONU are the secondary/primary MAC addresses of the MGC.
In addition, it is found that software parameter 2 of the MG interface on the ONU is set to 2. In
this case, the ONU supports dual homing and auto switching. When detecting that the primary
MAC address of the MGC is normally used for communication, the ONU performs auto
switching and initiates the register request to the active MGC. Therefore, the fault occurs.
Step 5 On the ONU, run the if-h248 attribute command to change the primary/secondary MAC
addresses of the ONU and then run the reset coldstart command to reset the H.248 interface.
In this case, the fault is rectified.
----End

This fault can be rectified by modifying software parameter 2 of the MG interface on the ONU
to 1 so that the ONU supports dual homing but does not support auto switching. However, this

Module
method is not recommended. This is because the primary/secondary MAC addresses of the MGC
and ONU will be different from the addresses planned, which affects maintenance.
7.4.10.6 TC-C6182 Call Services of an MA5616 Connected to an SBC Are Abnormal

Because Packets Are Lost Between the SBC and the MG
This topic describes how to troubleshoot the fault when call services of an MA5616 connected
to an (session border controller) SBC are abnormal.
Fault Type
Voice service
Keyword
MA5616, abnormal call service
Fault Description
Networking topology: MA5616 -> SBC -> MGC (SoftX3000)
When a user connected to an MA5616 makes calls, call services are abnormal. Sometimes the
peer end cannot hear the voice when picking up the phone after the phone rings, and sometimes
communications are interrupted.
Alarm Information
None
Cause Analysis
The VoIP fault is mainly caused by the following two factors:
l The signaling interaction is abnormal.
l The media stream channel is abnormal.
To accurately locate the fault, check the signaling interaction and media stream channel after
obtaining details about the fault.
Procedure
Step 1 Make intranet and extranet calls on the site where the fault occurs. It is found that in the
SoftX3000-intranet calls, call services are normal; but in extranet calls, sometimes the peer end
cannot hear the voice and sometimes communications are interrupted.
Step 2 Capture packets. It is found that the signaling is normal in intranet and extranet calls. Therefore,
it is preliminarily determined that the fault is caused by the SBC and media gateway (MG).
Step 3 Send ping packets from the SBC to the MG for a long time and log in to the SBC and MG to
check the MA5616 with the help of Huawei core network engineers. It is found that packets are
lost intermittently but the MA5616 functions properly.
Step 4 Check the bearer network with the help of the user. It is found that a port on a third-party bearer
device turns to the up or down state intermittently, which causes abnormal call services.

Module
Step 5 Rectify the network fault. Then the user connected to the MA5616 can make calls normally.
----End

A voice fault involves a large number of devices in the access, core and bearer networks, and
cooperation between multiple departments and between multiple engineers are required. The
key factor for locating the voice fault is to collect the fault information correctly and analyze
the fault symptom in detail. In this way, the cause can be determined to facilitate troubleshooting.
7.4.11 Abnormal CLIP

Abnormal calling line identification presentation (CLIP) is a fault that a user fails to receive the
caller number. For example, the caller number cannot be displayed or the display of the caller
number is incomplete.
7.4.11.1 TC-C6112 CLIP Service Is Abnormal Because Configurations of the SIP

Profile Are Incorrect
This topic describes how to troubleshoot the fault when the calling line identification
presentation (CLIP) service is abnormal because configurations of the SIP profile are incorrect.
Fault Type
Voice service
Keyword
SIP
CLIP service
Fault Description
Network topology: MA5620G -> IMS -> TG -> PSTN
Version: V800R307C01SPC200
Fault description: The caller ID is incompletely displayed for the VoIP user of the MA5620G
in an office, that is, the last digit is lost.
Alarm Information
None
Cause Analysis
l The IMS is faulty. For example, the IMS does not issue the signaling of the caller ID or the
issued caller ID is incorrect.
l The telecommunications room does not meet the requirements. For example, the ground
resistance is high.
l The subscriber loop line is faulty. For example, the subscriber loop line has interference.

Module
l The telephone is faulty. For example, the telephone does not support the CLIP service or
the telephone supports only the DTMF-format ID.
Procedure
Step 1 Replace the telephone, subscriber loop line, and MA5620G. It is found that the fault persists.
Step 2 Check grounding of the MA5620G and the MDF. It is found that the MA5620G and the MDF
are securely grounded.
Step 3 Trace the signaling.
[15:59:07.960]msg from mgc([218.207.219.17]:5060) to mg([218.207.143.45]:5060):
INVITEsip:+865946920128@218.207.143.45:5060;transport=udpSIP/2.0
[15:59:07.960]INVITEsip:+865946920128@218.207.143.45:5060;transport=udpSIP/2.0
[15:59:07.960]Via: SIP/2.0/UDP 218.207.219.17:5060;branch=z9hG4bK35c410ee23f808
44e5ae2a36d
[15:59:07.960]Call-ID: sbc29faa8856a78ca0fbbb7c2cf38fbc32d@19600.0.ATS.ats2.fj.
chinamobile.com.1
[15:59:07.960] From: <tel:13599017839;phone-context=+86>;tag=6ec3bcf2-CC-1
[15:59:07.960]To: <tel:+865946920128>
[15:59:07.960]CSeq: 1 INVITE
[15:59:07.960]Allow: INVITE,ACK,BYE,CANCEL,REGISTER,UPDATE,INFO,PRACK,NOTIFY,RE
FER,SUBSCRIBE,OPTIONS,MESSAGE
[15:59:07.960]Contact: <sip:218.207.219.17:5060;transport=udp>
[15:59:07.960]Max-Forwards: 68
[15:59:07.960]Supported: 100rel,timer
[15:59:07.960]Session-Expires: 1800
[15:59:07.960]Min-SE: 90
[15:59:07.960]Privacy: none
[15:59:07.960]P-Called-Party-ID: <tel:+865946920128>
[15:59:07.960] P-Asserted-Identity: <tel:+8613599017839>
Step 4 Run the display sipprofile command to check configurations of the SIP profile of the MA5620G.
It is found that control point 69 in the system parameter SysPara is 0, which indicates that the
caller ID is first obtained from the P-Asserted-Identity header field. According to the traced
signaling P-Asserted-Identity: <tel:+8613599017839>, you can confirm that the sent ID is
8613599017839, but the actually received ID is 861359901783. This indicates that the telephone
cannot receive a super-long ID.
Step 5 Run the sipprofile modify syspara 69 1 command to change control point 69 to 1 so that the
MA5620G can obtain the caller ID from the From header field and the ID is 13599017839. In
this case, the fault is rectified.
----End

In the system parameter of the SIP profile, control point 69 is used for setting the priority of the
header field from which the caller ID can be obtained, that is, setting whether the caller ID is
obtained from the P-Asserted-Identity header field or from the From header field.
l When control point 69 is set to 0, it indicates that the caller ID is obtained from the P-
Asserted-Identity header field.
l When control point 69 is set to 1, it indicates that the caller ID is obtained from the From
header field.

Module
7.4.11.2 TC-C6119 CLIP Service Failure Occurs on an ONU User Because the IMS
Configurations Are Incorrect
This topic describes how to troubleshoot the fault when the calling line identification
presentation (CLIP) service failure occurs on an ONU user.
Fault Type
Voice service
Keyword
SIP CLIP
INVITE message
Fault Description
Network topology: Telephone -> ONU (MA5610) -> OLT (MA5600T) -> IMS
Fault description: The SIP voice user of the MA5610 can make calls normally but its CLIP
service fails.
Alarm Information
None
Cause Analysis
l The signaling exchange between the IMS and the ONU is abnormal.
l The telephone and the subscriber loop line are faulty.
Procedure
Step 1 Trace the signaling to check whether the From header field in the INVITE message contains the
calling line identification when the telephone connected to the ONU functions as the called party.
If the identification in the From header field is Anonymous, it indicates that the From header
field in the INVITE message does not contain the calling line identification. This is because the
CLIP service is not configured on the IMS. The traced signaling is displayed as follows:
From: Anonymous <sip:Anonymous@Anonymous>;tag=8fb27ade-CC-146
Step 2 Check and find that the CLIP service is not configured on the IMS. Then, configure the CLIP
service on the IMS. It is found that the CLIP service on the ONU is normal and the fault is
rectified.
----End

The CLIP signaling of SIP is issued in the INVITE message, and the calling line identification
can be obtained from the P-Asserted-Identity header field or the From header field in the INVITE
message. You can modify the profile parameter on the MA5610 to decide from which header
you can obtain the calling line identification.

Module
The correct INVITE message containing the calling line identification is displayed in the
following. According to the From header field, the calling line identification is 07712345678.
From: <tel:07712345678;phone-context=+86> //From header field
P-Asserted-Identity: <tel:+867712345678> //P-Asserted-Identity header
field
7.4.12 Abnormal Call Holding, Call Waiting, and Call Forwarding

This topic describes how to locate and troubleshoot a call holding, call waiting, or call forwarding
fault.
7.4.12.1 TC-C6161 Call Hold and Call Waiting Services Are Abnormal Because of
Incorrect Parameters of an MA561x SIP Profile
This topic describes how to troubleshoot the fault when call hold and call waiting services are
abnormal.
Fault Type
Voice
Keyword
SIP, call hold, call waiting
Fault Description
Network topology: ONU (MA561x) -> OLT (MA5600T) -> IMS
Version: MA561x V800R307C01SPC400
Fault description: In testing the call hold service, the caller cannot hear the quick dial tone after
pressing the hookflash button. This fault persists after the hookflash upper/lower limits are
changed. In testing the call waiting (CW) service, the caller does not hear the CW prompt but
hears a prompt "Sorry! The subscriber you dialed is busy now, please redial later."
Alarm Information
None
Cause Analysis
l The IMS is not provisioned the call hold and CW services.
l The subscriber does not activate the CW service using the phone.
l Configurations of the call hold and CW services on the MA561x are incorrect.
Procedure
Step 1 Check the IMS. It is found that the call hold and CW services are enabled.
Step 2 Dial the service query codes using the phone. It is found that the CW service is activated. The
call hold service does not need to be activated, that is, it only needs to be provisioned on the
IMS.

Module
Step 3 Check whether configurations of the call hold and CW services are correct. It is found that the
SIP PSTN subscriber service rights can be subscribed from the IMS core. If subscription is not
supported, the SIP PSTN subscriber service rights can be configured on the MA561x.
Step 4 Check whether the SIP PSTN subscriber service rights obtained from the IMS core are correct.
MA5616(diagnose)%%display uaprofile 0/1
----------------------------------------------------------------------------
F /S /P : 0 /1 /63
Telno : 2024903
Telno-Index : 0
Register State : 2
Proxy Index : 0
Switch Reason : proxy-normal
call-waiting : disable //CW service
call-hold : disable //Call hold service
call-transfer : disable
conference : disable
three-party : disable
message-waiting : disable
MCID : disable
hotline : disable
TP : disable
CD : disable
UUS1 : disable
UUS2 : disable
UUS3 : disable
DC : disable
anonymous-call : disable
MWI mode : 0
hotline number : -
hotline time : -
dialing tone : standard-dail-tone
Step 5 The queried result shows that almost all the supplementary services are disabled, which is
different from the service status on the IMS. This indicates that the SIP PSTN subscriber service
rights are incorrect.
Step 6 Run the display sipprofile syspara command to query SIP profile parameters. If control point
4 (SP4) is set to 0, the SIP PSTN subscriber service rights are not subscribed. If SP4 is set to 1,
the SIP PSTN subscriber service rights are subscribed. However, the queried result shows that
SP4 is set to 0.
Step 7 Run the sipprofile modify syspara 4 1 command to modify the value of SP4 and reset the SIP
interface. Then, query subscription status. The queried result is as follows:
MA5616(diagnose)%%display uaprofile 0/1/63
{ <cr>|endframeid/slotid/portid<S><Length 1-15> }:
Command:
display uaprofile 0/1/63
----------------------------------------------------------------------------
F /S /P : 0 /1 /63
Telno : 2024903
Telno-Index : 0
Register State : 2
Proxy Index : 0
Switch Reason : proxy-normal
call-waiting : enable //The CW service is enabled.
call-hold : enable //The call hold service is enabled.
call-transfer : enable
conference : disable
three-party : enable
message-waiting : disable
MCID : disable
hotline : disable
TP : disable
CD : disable
UUS1 : disable

Module
UUS2 : disable
UUS3 : disable
DC : enable
anonymous-call : disable
MWI mode : 0
hotline number : -
hotline time : -
dialing tone : standard-dail-tone
----------------------------------------------------------------------------
Step 8 Test the call hold and CW services. It is found that they are normal. The fault is rectified.
----End

If subscription is not supported, run the sippstnuser rightflag set command to configure the
service right of a single SIP PSTN user.
7.4.12.2 TC-C6165 Call Waiting Service Fails Because of Incorrect Hookflash Upper/
Lower Limits of the HG850a
This topic describes how to troubleshoot the fault when the call waiting (CW) service fails.
Fault Type
Voice service
Keyword
CW, hookflash
Fault Description
Version: HG850a V100R001C07
When flash hooking is performed (by pressing the hookflash button or quick onhook and
offhook) in testing the CW service of the HG850a, communication between user A and user B
is interrupted immediately, but user A can communicate with user C successfully. The result of
such a test process is different from the normal CW scenario. The normal CW scenario is as
follows:
1. The CW service is configured for user A.
2. User C dials user A when user A is communicating with user B.
3. User A hears a prompt and then presses the hookflash button.
4. User B and user C are in the call hold state, and user A can perform one of the following
operations:
l If user A presses 2, user A communicates with user C and user B is in the call hold state.
l If user A presses 1, user A communicates with user C and user B is interrupted.
l If user A presses 0, user A communicates with user B and user C is interrupted.
Alarm Information
None

Module
Cause Analysis
Packets are captured when the fault occurs. It is found that the HG850a transmits a bye message.
This indicates that when flash hooking is performed, the HG850a considers that an onhook action
is required and therefore disconnects user B. When the HG850a re-connects a call, user C is
dialing; therefore, the HG850a connects user C, and user A can communicate with user C.
Procedure
Step 1 Export the .XML file used by the customer. It is found that the flash hooking parameter is
4294967295. Convert this parameter into the default configurations:
HookFlashUpTime="130" //HAookflash upper limit, in the unit
of ms.
HookFlashDownTime="50" //Hookflash lower limit, in the unit of
ms.
OnhookConfirmTime="250" //Onhook confirmation time, in the unit
of ms.
Step 2 The preceding configurations show that the hookflash upper/lower limits are short; therefore,
the flash hooking is easy to be considered as onhook. To rectify the fault, enlarge the hookflash
upper/lower limits. Change the hookflash upper/lower limits to the following values:
HookFlashUpTime="600"
HookFlashDownTime="100"
OnhookConfirmTime="700" //Considering jitter, it is
recommended that you set this parameter to a value that is 100 larger than the
hookflash upper limit.
Step 3 After the preceding values are set, the fault persists when pressing the hookflash button but the
fault is rectified by quick onhook and offhook. In this case, change the hookflash upper/lower
limits multiple times. When the hookflash upper/lower limits are set to the following values, the
flash hooking is achieved by pressing the hookflash button or quick onhook and offhook. The
fault is rectified.
HookFlashUpTime="900"
HookFlashDownTime="50"
OnhookConfirmTime="1000"
----End

The hookflash upper/lower limits are set according to the phone type.
7.4.13 Abnormal POS Machine Service

Abnormal POS machine service is a fault that a user fails to use a POS machine for the payment
service.
7.4.13.1 TC-C6048 POS Machine Fails to Be Registered Due to Incorrect Registration

Code of the POS Machine Connected to the ONU
This topic describes how to troubleshoot the fault when the POS machine fails to be registered
due to the incorrect registration code of the POS machine connected to the ONU.
Fault Type
VoIP service

Module
Keyword
POS machine
Incorrect registration code
Fault Description
Network topology: POS machine -> ONU (MA5620) -> OLT (MA5600T) -> Aggregation
switch -> IP MAN->Softswitch
When a POS machine is connected to the ONU, the registration fails. The POS machine,
however, can register successfully and work in the normal state when it is connected to the
traditional PSTN network.
Alarm Information
None
Cause Analysis
l The address of the POS machine is not configured on the softswitch.
l The registration code of the POS machine is set incorrectly.
l The softswitch is faulty.
Procedure
Step 1 The service of the POS machine is an MoIP service. The prerequisite for configuring the MoIP
service is that the voice service on the service port is normal. Therefore, connect a phone to the
subscriber line to perform a test. It is found that the voice service is normal, which indicates that
the voice service port connected to the POS machine is normal, and the VoIP services configured
on the ONU and the OLT are correct.
Step 2 Capture packets and restore the voice in the media stream of the captured packets. It is found
that when the POS machine is connected to the ONU and registers automatically through dialing,
the softswitch responds with the "The number you dial does not exists; please check it and dial
again." message.
Step 3 In the captured packets, analyze the registration code "04008855800" dialed by the POS
machine. There are two possible causes of this registration code, that is, two-stage dialing may
exist for the subscriber in the group, or the subscriber does not belong to the group. Connect a
phone to the subscriber line and perform the dialing test. Dial the outgoing prefix "0", and dial
the number "4008855800" after a while; however, the system still prompts "The number you
dial does not exists; please check it and dial again." Then, dial the number "4008855800" directly
without dialing the outgoing prefix, the fax tone is heard, and the POS machine is normal.
Therefore, it can be determined that the subscriber of the POS service does not belong to the
group, and an outgoing prefix "0" is added to the registration code, which causes the fault.
Step 4 Change the registration code setting on the POS machine or add the subscriber to the group.
Then, the registration is successful.
----End

Module

None
7.4.13.2 TC-C6117 Payment Service with Bankcard on the POS Machine Connected
to the MA5606T Fails Because of Polarity Reversal Settings
This topic describes how to troubleshoot the fault when brushing bankcard on the POS machine
connected to the MA5606T fails.
Fault Type
Voice service
Keyword
EC
POS machine
Fault Description
Network topology: POS machine -> ONU (MA5606T) -> OLT -> Softswitch -> TG -> Bank
server
Fault description: The POS machine under the MA5606T cannot be registered normally. In the
current network, the softswitch (SS) and the trunk gateway (TG) are from company Z. This POS
machine can be registered and provide the payment service with bankcard normally in the PSTN
and under the device from company Z.
Alarm Information
None
Cause Analysis
l Compatibility of the POS machine has problem.
l The parameter issued by the softswitch is incorrect.
l Other hardware and software parameters are incorrect.
Procedure
Step 1 This POS machine can be registered and provide the payment service with bankcard normally
in the PSTN and under the device from company Z. This POS machine can also be registered
and provide the payment service with bankcard normally under the Huawei softswitch.
Therefore, the fault is not caused by the POS machine.
Step 2 Connect the POS machine to other Huawei devices, including the MA5616 and MA5620. It is
found that the POS machine cannot be registered or fails to provide the payment service with
bankcard. Therefore, the fault is not caused by the MA5606T.
Step 3 Check the signaling issued by the softswitch. It is found that the signaling is normal and is
confirmed that the EC is already disabled. Compare the signaling issued by Huawei softswitch

Module
with the signaling issued by the softswitch from company Z and the only difference is that the
signaling issued by Huawei softswitch includes the extra polarity reversal signaling SG{xal/
las}.
Step 4 On the POS port, disable polarity reversal or change polarity reversal to soft polarity reversal.
It is found that the POS machine can provide the payment service with bankcard normally. This
indicates that the hard polarity reversal mode used on the MA5606T triggers gap consumption
in the media stream and causes the fault.
NOTE
Disable polarity reversal on the POS port by running the command on the ONU. For example, to disable
polarity reversal on port 0/4/1 of the MA5606, do as follows:
MA5606T(config-pstnport)#pstnport attribute set 0/4/1 reverse-pole-pulse
disable
----End

After the traditional PSTN is replaced with the NGN network gradually, the fault of payment
service with bankcard provided by the POS machine occurs more frequently. The payment
service with bankcard provided by the POS machine has strict requirement on delay, jitter, and
packet loss. When the POS machine fails to be registered or provide the payment service with
bankcard normally, locate the fault as follows:
1. Ensure that EC is disabled. It is recommended that you disable (supported by Huawei but
not supported by company Z) EC for the called number through the softswitch. If the
softswitch from other vendors does not support EC, disable this function on the port of the
ONU by running relevant commands.
l In the case of the MA5606T and the MA5620 of V800R305, run the following
commands to disable EC of the port.
MA5606T(config)#esl user
MA5606T(config-esl-user)#mgpstnuser attribute set 0/4/1 pos enable
l In the case of the MA5616, MA5610, MA5620, and MA5612 of V800R307, run the
following commands to disable EC of the port.
MA5616(config)#dsp-para-template add pos 1 1 0 2 1
MA5616(config)#esl user
MA5616(config)#service-num add 8001111111 pos //8001111111 is the
number for connecting the payment service with bankcard provided by the POS
machine.
NOTE
l Different banks support different numbers for connecting the payment service with bankcard
provided by the POS machine. In this case, the number needs to be found from the H,248
signaling.
l The number for connecting the payment service with bankcard provided by the POS machine
must be completely the same as the number preset in the digitmap. If they are not completely
the same, change the value of software parameter 13 of the H.248 interface to 1. To query
and change the software parameter of the H.248 interface, run the following commands.
MA5606T(config-if-h248-0)#display mg-software parameter 13
MA5606T(config-if-h248-0)#mg-software parameter 13 1
2. Ensure that the softswitch does not issue the polarity reversal signaling. If the intelligent
public telephone (IPT) billing function is not involved, you can disable polarity reversal of
the POS port; however, this action is not recommended. It is recommended that you disable
polarity reversal on the softswitch.

Module
3. Replace or upgrade the POS machine. POS machines of some banks are too old and can
be used only in the PSTN. The version of these POS machines needs to be upgraded to
solve the problem.
7.4.13.3 TC-C6235 POSs Cannot Register with the Server Because Echo Cancellation
Is Not Disabled
This topic describes how to troubleshoot the fault when the point of sales (POS) systems fail to
register with the server.
Fault Type
Voice service
Keyword
Registration failure, POS fault
Fault Description
Version: MA5616V800R306C01SPH108
A period of time after dialing is initiated on multiple POSs in a hotel, the POSs automatically
hook on and re-dial. After several times of re-dialing attempts, the POSs return to the main
interface and a registration failure message is displayed.
Alarm Information
None
Possible Cause
l The POSs are faulty.
l A network fault exists.
l Other faults
Procedure
Step 1 This fault occurs on multiple POSs in the hotel. In addition, the POSs work normally in the
PSTN network. Therefore, the POSs are not faulty.
Step 2 Ping the media gateway controller (MGC) on the MA5616 for a period of time. No packets are
lost. Therefore, the network is not faulty.
Step 3 Trace the signaling. After dialing is initiated on a POS, the server responds to the dialing request
successfully. Then, the POS is powered off and re-dials. This process repeats until the registration
fails. Check the signaling. It is found that the echo cancellation (EC) function is enabled. The
POS generally processes the high-speed service and the EC function must be disabled. Therefore,
it is predicted that the registration failure occurs because the EC function is not disabled.
[17:10:11.510]msg from mgc([10.45.11.5]:2944) to mg([10.45.92.7]:2944): !/1
[10.45.11.5]:2944 T=605162897{C=56{MF=A10{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON}},
E=604765448{al/*},SG{}}
Step 4 Configure the data on the MA5616 to disable the EC function.

Module
MA5616(config)#dsp-para-template { add<K>|del<K> }:add { name<S><Length

1-31> }:TXCPJ //Case-sensitive template name, which can be specified as required
{ ec-value<0,1> }:1 //The value 1 indicates that the EC function is disabled.
{ jb-value<0,1> }:1 { nlp-value<0,2> }:2 { workmode-value<0,2> }:0 { sc-
value<0,1> }:0 MA5616(config)#service-num add 82919199 TXCPJ //Disable the EC
function for the service number 82919199.
Step 5 Test the POSs. The POSs can register with the server normally.
----End

The POS generally processes the high-speed service. The EC function must be disabled.
7.4.14 Echo in a Voice Call

Echo in a voice call is a fault that the callees can hear their own echoes in a call.
7.4.14.1 TC-C6047 The Peer Subscribers of the ONU Hear Their Own Echoes
Because the Echo Cancellation (EC) Function Is Disabled on the Softswitch
This topic describes how to troubleshoot the fault when the peer subscribers of the ONU hear
their own echoes because the EC function is disabled on the softswitch.
Fault Type
Voice service
Keyword
Echo
EC
Fault Description
When subscribers connected to the ONU function as the caller to make phone calls, the callees
can hear their own echoes. The call service on the caller side, however, is normal. When
subscribers connected to the ONU call each other, the caller and the callee can hear their own
echoes.
Alarm Information
None
Cause Analysis
l Acoustic echo exists.
l The EC function for the electric echo is not enabled.
– If the AG subscribers hear echoes, it is because that the EC of the peer gateway is not
complete.
– If the subscribers of the peer gateway hear the echoes, it is because the EC of the AG
is not complete.

Module
Procedure
Step 1 Cover the phone transmitter at the peer end where echo occurs. The echo persists. Therefore,
the echo is not the acoustic echo. If it is the acoustic echo, the echo disappears when the phone
transmitter is covered. In addition, when the peer phone calls a phone connected to anther device,
no echo exists. Therefore, the echo is generated by the ONU.
Step 2 Capture the H.248 signaling and analyze the signaling issued by the softswitch. It is found that
the EC function is disabled. In the signaling, "tdmc/ec=off" indicates that the EC function is
disabled. That is, no EC is implemented on the ONU, and therefore the peer subscribers can hear
their own echoes.
[23:28:45.730]msg from mgc([211.140.160.166]:2944) to mg([221.131.203.6]:2944):
MEGACO/1 <SS>:2944 Transaction=773977921{Context=${Add=A3{Media{LocalControl
{Mode=SendReceive}}},Add=${Media{Local{v=0
c=IN IP4 $
m=audio $ RTP/AVP 8 0 18
a=ptime:20
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
},LocalControl{tdmc/ec=off,tdmc/gain=9,Mode=Inactive}}}}}
Step 3 Modify the data configuration on the softswitch, that is, enable the EC function. Then, perform
the test. It is found that the call is normal, and neither side can hear their own echoes.
----End

The EC function on the ONU is enabled by default. Controlled by the softswitch, the EC,
however, is not implemented on the ONU when the EC is OFF in the signaling of the softswitch.
In this case, you need to modify the configuration on the softswitch.
Echo principles: Generally echo can be categorized as the acoustic echo (which is prevented
only in the acoustic way) and the electric echo (which can be controlled through the electric
principles of the device).
7.4.15 Voice User Fails to Be Registered

Voice user fails to be registered is a fault that a voice user fails to be registered on a media
gateway controller (MGC) or an IP multimedia subsystem (IMS).
7.4.15.1 TC-C6009 The MG Interface Fails to Pass the MGC Authentication Because
of Incorrect Data Configuration of the MGC
This topic describes how to troubleshoot the fault when the POTS service of the ONU fails to
pass the authentication because of incorrect data configuration of the softswitch.
Fault Type
VoIP service
Keyword
MGC authentication

Module
MGC configuration
POTS service
Fault Description
The MG interface configured on the ONU fails to pass the authentication. Specially, the MG
interface is in the wait ack state. Mirror the data of the PON port on the ONU to the FE port,
and capture packets. It is found that the ONU sends the request packet, but does not receive the
response packet.
Alarm Information
None
Cause Analysis
l Data about the MG interface is not configured on the session border controller (SBC).
l Port 2944 is disabled in the devices on the MAN.
l The data configuration of the softswitch is incorrect.
Procedure
Step 1 Check the configuration of the SBC. It is found that data about the MG interface is configured
on the SBC.
Step 2 Consult the carrier about whether port 2944 on the MAN is enabled. It is found that port 2944
is enabled after consultation.
Step 3 Check the data configuration of the softswitch. It is found that the data of the softswitch for
supporting the POTS service of the ONU is configured and the authentication mode on the
softswitch side is ONU address + port 2944.
Step 4 Trace H.248 messages on the softswitch side. It is found that no request packet sent from the
ONU is received.
Step 5 Check the configurations of the softswitch again. It is found that the softswitch uses the
authentication mode based on static IP addresses. The SBC proxy, however, is used on the
existing network. That is, the ONU address is converted, and thus the ONU cannot pass the
authentication in this mode.
Step 6 Configure the authentication mode based on dynamic IP addresses for the softswitch. As a result,
the fault is rectified.
----End

Generally, the MG is connected to the MGC directly, and no SBC is used in the test environment.
The IP address of the MG is visible to the MGC. Generally, the authentication mode based on
static IP addresses is used.
On the existing network, however, the SBC proxy is configured between the MG and MGC to
ensure the security of the MGC. In this way, the IP address of the data that travels through the
SBC is converted into another IP address, which cannot be identified by the MGC. Therefore,

Module
when the SBC proxy is adopted, the authentication mode of the MGC needs to be configured as
dynamic.
NOTE
The SBC provides necessary channels for information streams or media streams that are sent to or from the
network. The SBC functions as the gateway of information transmission, and solves problems related to the
security of the IP network, service performance assurance, and NAT traversal.
7.4.15.2 TC-C6010 The MG Fails to Register with the Softswitch Because of

Inconsistent Protocol Versions
This topic describes how to troubleshoot the fault when the MG fails to register with the
softswitch in the interconnection of the OLT and ONT to the softswitch.
Fault Type
VoIP service
Keyword
The MG fails to register with the softswitch
Inconsistent protocol versions
Fault Description
An OLT (MA5600T) and ONU (MA5606T) are used to provide the VoIP service. The OLT is
connected to the softswitch. After the MG interface on the OLT is configured, the MG interface
is in the Wait ack state.
Alarm Information
None
Cause Analysis
l The data of the ONU does not match that of the softswitch.
l The link between the OLT and ONU is faulty.
l The link between the OLT and softswitch is faulty.
l The parameters of the MG interface are incorrect.
Procedure
Step 1 Check the interconnection data of both the MG and MGC. It is found that the IP address and
port number of the MG, and the IP address and port number of the MGC are set correctly.
Step 2 On the OLT, run the display ont info command to check the status of the ONU. It is found that
the matching status of the ONU is normal. Ping the OLT from the ONU and ping the IP address
of the gateway to which the MGC belongs. It is found that the ping operations are successful.
Step 3 Mirror the data of the upstream port on the OLT and then capture packets. The packet "{SV
{MT=RS, V=3, RE="901", 20080507T15302326}}" is captured but no signaling response
packet is received by the softswitch.

Module
Step 4 On the ONU, run the display if-h248 attribute command to check the parameters of the MG
interface. It is found that the Top H248 Version parameter is set to 3. It is suspected that the H.
248 protocols used for information exchange between the MG and MGC are inconsistent.
Step 5 On the ONU, run the if-h248 attribute command to change the version of starting the negotiation
to negotiation in an ascending order, and then reset the MG interface. As a result, the MG
interface can register with the softswitch normally.
----End

None
7.4.15.3 TC-C6011 The MG Fails to Register with the MGC Because of the Faulty
Upper-Layer Link
This topic describes how to troubleshoot the fault when the IAD connected to the ONT fails to
register with the MGC because of the faulty upper-layer link.
Fault Type
VoIP service
Keyword
IAD
MG registration
Fault Description
l No dial tone is played after offhook, and the number-unobtainable tone is played after a
phone number is dialed.
l The VoIP LED of the IAD is steadily on, but the IAD fails to register with the MGC.
l The common Internet access service through PPPoE dialup is normal.
Alarm Information
None
Cause Analysis
l Packets are not forwarded.
l The upper-layer device is faulty.
Procedure
Step 1 Check the data configuration of the MGC because the number-unobtainable tone is played after
a phone number is dialed. It is found that no data is configured. After data is added, the number-

Module
unobtainable tone is not played after a phone number is dialed, but the IAD still fails to register
with the MGC.
Step 2 Check the data configuration of the OLT. No problem is found.
Step 3 It is suspected that packets are not forwarded. Then, capture packets. It is found that the OLT
and ONT forward the registration request packet of the IAD to the upper-layer device, but do
not receive a response packet from the MGC.
Step 4 Log in to the NE40 connected to the OLT to check the configurations. It is found that data is
configured on ports 4 and 5. Nevertheless, port 4 is in the DOWN state, port 6 is in the UP state,
but no data is configured on port 6.
Step 5 Adjust the port configurations and line connections of the NE40, and adjust the data
configurations from ports 4 and 6 to ports 4 and 5. As a result, the fault is rectified.
----End

If the MG interface fails to register with the MGC, the troubleshooting tips are to check the
signaling if the MG and MGC interact with each other, or check whether packet loss occurs if
the MG and MGC do not interact with each other. The troubleshooting difficulty is to be familiar
with the network environment and various devices on the network.
7.4.15.4 TC-C6012 The MG Interface Fails to Register with the Softswitch Because
of Disabled H.248 Protocol Proxy on the SBC
This topic describes how to troubleshoot the fault when the MG interface of an ONU fails to
register with the softswitch because the H.248 protocol proxy is disabled on the SBC.
Fault Type
Device interconnection
Keyword
The MG interface fails to register with the softswitch
H.248 protocol proxy
Fault Description
An ONU fails to register with the OLT after the H.248 interface is enabled on the ONU.
Alarm Information
None
Cause Analysis
l The network between the MG and MGC fails.
l Port 2944 is disabled.

Module
Procedure
Step 1 Check the data configurations of the ONU and softswitch. It is found that the data configurations
of the ONU and softswitch are correct.
Step 2 Trace H.248 packets. It is found that the ONU sends the registration request of interface 901,
but does not receive a response packet from the softswitch.
Step 3 Trace H.248 packets on the softswitch side. It is found that the softswitch does not receive the
registration request, which indicates that the network between the ONU and softswitch is faulty.
Step 4 The ONU uses the SBC for signaling proxy. Therefore, check the configuration of the SBC. It
is found that the H.248 protocol proxy is disabled on the SBC. Enable the H.248 protocol proxy.
As a result, the MG interface can register with the softswitch normally and the fault is rectified.
----End

None
7.4.15.5 TC-C6053 Switchover Occurs Repeatedly Because the ONU Fails to

Register with the Active MGC
This topic describes how to troubleshoot the fault when switchover occurs repeatedly because
the ONU fails to register with the active MGC.
Fault Type
VoIP service
Keyword
MG registration failure
Switchover
Fault Description
When the DBwin is used to trace the signaling on the ONU, it is found that the ONU reports the
warm start signaling "902" repeatedly. The signaling is as follows:
[13:37:30.610]msg from mg([10.18.161.4]:2944) to mgc([10.14.132.5]:2944): !/1
[10.18.161.4]:2944 T=244209006{C=-{SC=ROOT{SV{MT=RS,V=2,RE="902",20081014T13373
061}}}}
Alarm Information
None
Cause Analysis
The dual-homing MGC is configured and the auto-switchover function is enabled on the ONU.
The current ONU registers with the standby MGC, and the active MGC does not respond due
to certain causes such as no data configuration. Therefore, the ONU reports the warm start
signaling "902" repeatedly.

Module
Procedure
Step 1 Query the running status and the basic attribute configuration of the H.248 interface. It is found
that the ONU is configured with dual-homing and registers with the standby MGC.
Step 2 Query the dual-homing attribute of the ONU. It is found that the auto-switchover is supported.
huawei#display mg-software parameter 2
-------------------------------------------------
Interface Id:0 para index:2 value:2
-------------------------------------------------
APPENDIX:
-------------------------------------------------
Interface software parameter name:
2: Whether MG support dual-home speciality
0: Do not support the dual-homing
1: Support the dual-homing, but do not support the auto switchover
2: Support the dual-homing and auto switchover
Step 3 Change the dual-homing of the ONU not to support the auto-switchover function. The warm
start signaling "902" disappears.
huawei#mg-software parameter 2 1
Step 4 Check the data. It is found that no related data is configured on the active MGC. Therefore, the
ONU fails to register with the active MGC.
----End

When configuring the dual-homing policy on the ONU, make sure that related data is configured
on the active MGC to avoid the repeated switchover of the ONU.
7.4.15.6 TC-C6055 The ONU Fails to Be Registered Due to the Incorrect Setting of
the Domain Name
This topic describes how to troubleshoot the fault when the ONU fails to be registered due to
the incorrect setting of the domain name.
Fault Type
Voice service
Keyword
Setting of the domain name
Fault Description
The ONU (MA5606T) works with the softswitch of another vendor to provide the NGN voice
service. During the test, it is found that the MG interface on the ONU is always in the waiting
status and cannot work in the normal state.
Alarm Information
None

Module
Cause Analysis
l The data configuration on the MG interface is incorrect.
l The data configuration on the MG is inconsistent with the data configuration on the MGC.
Procedure
Step 1 Check the data on the ONU. The domain name registration mode is adopted, and therefore focus
on whether the domain name of the MG interface is the same as the domain name on the
softswitch. It is found that the domain names are the same.
Step 2 After certain checks, it is found that the ONU does not directly register with the softswitch.
Instead, the ONU registers with the proxy server (B200) of this vendor. Certain ONUs
successfully register with the softswitch; therefore, check the faulty ONU by comparing it with
an ONU that registers successfully.
The data of the MG interface on the ONU that registers successfully is as follows:
huawei(config)#display if-h248 attribute 0
----------------------------------------------------------------------------
MGID 0
MG Description -
MG DomainName XXXXX5
Protocol H248
Start Negotiate Version 1
Profile Negotiation Parameter Disable
Profile index 5:ZTE_AGW/1("")
2833Encrypt -
Codetype Text
Transmode UDP
HeartBeatGenTimer(s) 60
HeartBeatRetransTimes 3
HeartBeatRetransTimer(s) 60
MG signalling IP 172.16.127.25
MG signalling Port 2944
MG media IP 172.16.127.25
MIDType DOMAIN_NAME
DeviceName -
Active MGC MGC Port :2944 MGC IP:61.157.97.2
Active MGC MGC Domain Name:XXXXX5-BGW
Standby MGC MGC Port :- MGC IP:-
Standby MGC MGC Domain Name:-
----------------------------------------------------------------------------
Step 3 The only difference is that "MGC Domain Name" of the ONU that registers successfully has "-
BGW" while "MGC Domain Name" of the ONU that fails to register does not have "-BGW".
Add "-BGW" to "MGC Domain Name" of the ONU that fails to register. Then, the ONU can
register successfully.
Step 4 After certain checks, it is found that the B200 requires the softswitch to add "-BGW", which is
used to determine whether the signaling is transmitted from the softswitch or from the ONU to
the B200.
----End

None

Module
7.4.15.7 TC-C6061 The ONT Fails to Register with the Softswitch Due to the
Incorrect Setting of the User Name
This topic describes how to troubleshoot the fault when the ONT fails to register with the
softswitch due to the incorrect setting of the user name.
Fault Type
Voice service
Keyword
MG registration failure
Fault Description
The ONT is provisioned with the SIP-based voice service. After the configuration is completed,
the ONT fails to register with the softswitch. The session border controller (SBC) and the
gateway address, however, can be pinged through from the ONT.
Alarm Information
None
Cause Analysis
l The configuration of the SIP server is incorrect.
l The configuration of the voice service on the ONT is incorrect.
Procedure
Step 1 Capture packets on the upstream port of the ONT. It is found that the "401" response message
is contained in the SIP packet, which indicates that the request message contains syntax errors
or that the SIP server fails to process the request message.
Step 2 The ONT registers with the SIP server successfully, and the configuration of the SIP server is
correct. Therefore, the configuration of the voice service on the ONT may be incorrect.
Step 3 Log in to the ONT through the web page, and check the configuration of the voice service.
Choose VoIP > Basic Configuration > User name, and change the user name to the user phone
number. Then, save the configuration, and reset the ONT. The ONT can register with the
softswitch successfully, and the VoIP LED is on.
----End

Generally, the user name on the SIP terminal is set to the number phone number. When such a
fault occurs, check the setting of the user name first.
7.4.15.8 TC-C6231 Failed to Register the H.248 Interface of an HG850a Owing to the
Incorrect Configuration of MgcDomainName on the HG850a
This topic describes how to troubleshoot the fault when the H.248 interface cannot be registered.

Module
Fault Type
Service function
Keyword
VoIP 402
Fault Description
During configuration of the H.248 VoIP service on the HG850a, the domain name-based
registration mode is used for interconnection between the HG850a and a media gateway
controller (MGC). On the MGC, the status of the H.248 interface is checked and the result
indicates that the H.248 interface is in normal status. After the normal number allocation, the
VoIP service is tested on site. It is found that the busy tone is heard when the phone set hooks
off.
Alarm Information
None
Possible Cause
l Data configuration on the HG850a is incorrect.
l Numbers are not properly allocated on the MGC.
l Other faults
Procedure
Step 1 Check the data configuration of the HG850a. The port TID, H.248 interface, and domain name
of the HG850a are correct. Therefore, the fault is not caused by incorrect data configuration of
the HG850a.
Step 2 Check the configuration of the MGC. No fault is detected, but the system prompts that
initialization of the user port fails.
Step 3 Capture packets on the HG850a and analyze the captured packet file. Analysis shows that the
MGC responds normally when the HG850a sends a ServiceChange message for registration.
When the MGC sends audit and digitmap request messages to the HG850a, the HG850a responds
with the Unauthorized error message (402). This indicates that the H.248 interface on the
HG850a side may be abnormal. The captured packet file is as follows:
//Mon Jun 28 17:16:10 2010:916284 MEGACO/1 <ECSBC1-ECMGC-COCO4>:2944 Transaction
=10758{ Context=-{ Modify=ROOT{ DigitMap=zhengzhou{([EF]xxF|E990x.|ExxExx.F|
ExxEx.Ex.Ex.F|ExxEx.Exx.F|EEx.F|FxxEx.F|013xxxxxxxxx|015xxxxxxxxx|13xxxxxxxxx |
15xxxxxxxxx|6xxxxxxx|600x.|00x.|01[01246-9]x.|0[2-9]x.|1[01246-9]x.|[2-5789]
x.)} } } } // Mon Jun 28 17:16:10 2010:925227 !/1 <zzbgy-dfxdclscs.hw>:2944 P=10758
{ER=402{"Unauthorized"}}
Step 4 Check the configuration of the HG850a and the registration message responded by the MGC. It
is found that MGC domain name (MgcDomainName) configured on the HG850a is different
from that in the message responded by the MGC.
Step 5 Modify the data configuration on the HG850a. The fault is rectified.
----End

Module

In domain name-based registration mode, the server uses the domain name to send a registration
request to the ONT. The MGC domain name configured on the ONT, however, is different from
that in the message responded by the MGC. Therefore, the ONT determines that the subsequent
messages are invalid requests. If the IP address-based registration mode is used, this fault does
not occur because the IP address of the MGC is configured on the ONT and the ONT determines
that the requests coming from this IP address are valid.
7.4.15.9 TC-C6239 H.248 Interface Cannot Be Registered Owing to Restriction on

the Length of the MGC Domain Name
This topic describes how to troubleshoot the fault when the H.248 interface cannot be registered.
Fault Type
Voice service
Keyword
402 error, registration failure
Fault Description
Version: MA5616V800R306C01B053SPC020
After the new MA5616 is installed, the voice service cannot be provided. The media gateway
controller (MGC) can be pinged. (The MGC is a SoftX3000.) Configuration of the parameters
that should be negotiated with the MGC is correct. The H.248 interface, however, always cannot
be registered normally. After the DBWIN debugging command is executed, it is found that the
MA5616 sends the registration request to the MGC, but the MGC returns the 402 error message,
that is, the Unauthorized message.
Alarm Information
None
Possible Cause
l The poor quality of the network between the MG and the MGC results in errors of the
signaling packets.
l Configuration of parameters (including the authentication mode and domain name) on the
MGC is different from that on the MA5616.
Procedure
Step 1 Ping packets between the MGC and the MA5616. No packets are lost and the delay is in normal
range. This indicates that the network is not faulty.
Step 2 Compare the configuration of parameters related to the H.248 interface registration on the MGC
with that on the MA5616. Both the MGC and the MA5616 use the domain name-based
authentication mode. In addition, the domain names configured on the MGC and the MA5616
are the same.

Module
Step 3 Configure the parameters related to the voice service on the MA5616 (device A) so that the
configuration of device A is the same as that of an MA5616 (device B) on which the fault does
not occur. The H.248 interface can be registered normally.
Step 4 Compare the configuration of device A with that of device B. It is found that the length of the
domain name is 20 bytes on device B and 21 bytes on device A. The fault may be related to the
length of the domain name.
Step 5 Change the length of the domain name to 20 bytes on both the MGC and the MA5616. The H.
248 interface can be registered normally.
----End

If the 402 error occurs during interconnection between the MGC and the MA5616, check whether
the parameter configuration is the same on two sides.
The MGC supports the domain name of up to 64 bytes. In practice, the valid domain name is
subject to a certain length restriction, which varies with the type of interfaces to be registered.
This fault occurs because a 21-byte domain name is configured on the MGC, but only the first
20 bytes of the domain name are valid. During configuration of parameters used for
interconnection, pay attention to the length restriction on the domain name. Otherwise, the 402
error may occur even if the configurations of H.248 parameters are the same on both sides.
7.4.16 Other Voice Service Faults

This topic describes how to troubleshoot other common voice service faults.
7.4.16.1 TC-C6029 OLT Subscribers Connected to the AGs in the Same Network
Segment Cannot Communicate with Each Other Due to the ARP Proxy Problem
This topic describes the fault when OLT subscribers connected to the AGs in the same network
segment cannot communicate with each other due to the ARP proxy problem.
Fault Type
Voice service
Keyword
ARP proxy
Fault Description
Network topology
AG_1----ONU----|
|----OLT(MA5600T)----Switch----BRAS (MA5200G)----Bearer network----
Softswitch
AG_2----ONU----|
The IP addresses of AG_1 and AG_2 are in the same network segment. AG_1 and AG_2 belong
to the same sub-port on the MA5620G, and use the same QinQ VLAN on the OLT.

Module
Subscribers report that the voice services of AG_1 and AG_2 cannot communicate with each
other.
Alarm Information
None
Cause Analysis
l The AG is faulty or fails to register with the softswitch.
l The configuration of the OLT or softswitch is incorrect.
Procedure
Step 1 AG_1 and AG_2 can ping the remote MGC, and can register with the MGC normally. In addition,
these two AGs can communicate with the AGs in other network segments normally. Therefore,
the fault is not caused by the registration problem with the MGC or by the configurations of the
OLT or ONU. Other services in these two AGs are normal, and the only problem is that they
cannot communicate with each other. Therefore, the fault is not caused by the configuration of
the MGC.
Step 2 Communications between subscribers in the same network segment is within a gateway. Layer
2 isolation, however, is implemented on the OLT. Therefore, if subscribers want to communicate
with each other, the ARP proxy must be enabled.
Step 3 QinQ is enabled on the OLT, and therefore the ARP proxy cannot be enabled at the same time.
Check the MG5200G. It is found that the ARP proxy is not enabled on the BRAS port. Enable
the ARP proxy, and the fault is rectified.
----End

l ARP proxy cannot be enabled on the OLT (MA5600T) when QinQ is enabled. Note this
during the network planning.
l In the BRAS mode, the ARP proxy on the MA5200G is disabled by default.
7.4.16.2 TC-C6193 Caller and Callee Fail to Be Connected When Two ONUs
Connected to a PON Port Make Calls with Each Other
This topic describes how to troubleshoot the fault when the caller and callee fail to be connected
when two ONUs connected to a PON port make calls with each other.
Fault Type
Voice service
Keyword
Internal forwarding, external forwarding
Fault Description
Network topology: Two MA5616s are connected to a PON port on the OLT (MA5600T).

Module
VoIP address of MA5616-1: 10.64.40.33/24

VoIP address of MA5616-2: 10.64.40.34/24
Voice VLAN: 1000
Fault description: When a user connected to MA5616-1 makes calls with a user connected to
MA5616-2, the caller and callee fail to be connected. When the user connected to MA5616-1
makes calls with other users, the calls can be set up.
Alarm Information
None
Cause Analysis
Cause analysis: The voice IP addresses of the two MA5616s is in the same network segment
and work in the internal forwarding mode. Therefore, the media stream does not match the
routing table; instead, it issues the ARP to search for the MAC address of the peer MA5616. But
the voice VLAN 3103 is the smart type on the OLT, hence the two MA5616s are isolated from
each other, which leads to call failure.
Procedure
Step 1 Query the system parameter 5 of the two MA5616s. It is found that the values of the two
parameters are 0, which indicates internal forwarding.
MA5616(config)#display system parameters 5
-----------------------------------------------------------------------------
Parameter index: 5 parameter value: 0
Step 2 To troubleshoot the fault, select one of the following three ways as required:
Method Defect
Enable the ARP proxy on the OLT. Occupies the carrier's IP address resources.
Select another VLAN (such as common Causes excessive VLAN broadcast domains.
VLAN) on the OLT to disable the Layer 2
isolation function.
Run the system parameters 5 1 command on None

the ONU to set the voice media stream to the
external forwarding mode.
----End

Two MA5616s can make calls with each other in the following four situations:
1. In the same network segment + Internal forwarding mode
2. In the same network segment + External forwarding mode
3. In different network segments + Internal forwarding mode
4. In different network segments + External forwarding mode

Module
When the IP addresses of the local and peer MA5616s are in the same network segment in the
internal forwarding mode, the MAC address corresponding to the IP address of the peer MA5616
is learned by using the ARP. In the other three situations, the MAC address corresponding to
the media gateway is learned. In these cases, all media streams are forwarded to the media
gateway to perform the next hop addressing and forwarding.
7.4.16.3 TC-C6173 Voice Service Failure Because the Subnet Mask of the Static IP
Address of the HG850e Voice Service Is Incorrect
This topic describes how to troubleshoot the fault when the voice service fails.
Fault Type
Voice service
Keyword
Subnet mask, incorrect configuration, voice service failure
Fault Description
The voice service fails after the HG850e is configured.
Alarm Information
None
Cause Analysis
1. The OLT configurations are incorrect.
2. The HG850e configurations are incorrect.
3. The softswitch configurations are incorrect.
4. The HG850e is faulty.
Procedure
Step 1 Log in to the OLT and check OLT configurations. It is found that OLT configurations are correct.
Step 2 Log in to the HG850e and check HG850e configurations. It is found that the subnet mask of the
static IP address of the voice service is incorrect. As a result, the static IP address and gateway
are in different network segments.
----End

If the IP address of the HG850e is in a different network segment from the gateway, the HG850e
does not prompt an error. Therefore, the HG850e configurations must be correct.

Module
7.4.16.4 TC-C6303 Failure to Make a Phone Call but Success in Accessing the
Internet
This topic describes how to troubleshoot the fault when a GPON user fails to make a phone call
but can access the Internet successfully.
Fault Type
Voice service
Keyword
Phone Call
VLAN
Fault Description
After the GPON access service is provided, certain users report that they cannot make phone
calls but can access the Internet.
Alarm Information
None
Cause Analysis
l The configuration on the user terminal is improper.
Procedure
Step 1 The Internet access service is available, which indicates that the OLT at the central office and
the ONT at the terminal are in the normal state. The possible cause is that the service
configuration at the terminal is incorrect.
Step 2 Check the configuration of the upstream port on the OLT. It is found that the upstream port is
added to the upstream VLAN for special voice service.
Step 3 Check the configuration of the service virtual port on the ONT. It is found that the service virtual
port is added to the upstream VLAN of the voice service.
Step 4 Check the configuration of the VLAN of the ONT port connected to the IAD. It is found that
the port is added to the VLAN on the user side of the voice service.
Step 5 Check the native VLAN of the ONT port connected to the IAD. It is found that the native VLAN
is the default configuration.
Step 6 Set the native VLAN of the IAD port to the VLAN on the user side of the voice service and keep
other configurations unchanged. Verify the service. It is found that the fault is rectified.
----End

Module

l When the services are differentiated by the user-side VLAN, correctly configure the native
VLAN of the Ethernet port at the terminal.
l When the data is transmitted upstream without VLAN tag, ensure that the native VLAN of
the upstream port is the same as the VLAN of the port.
7.5 Troubleshooting Cases of Other Services Faults

7.5.1 Network Failure
Network failure is a fault that the network between two devices is interrupted and devices cannot
communicate with each other.
7.5.1.1 TC-C6168 Failure to Telnet a Cascaded Switch Because TLS Streams Are
Configured on the MA5620G
This topic describes how to troubleshoot the fault when the cascaded switch fails to telnet.
Fault Type
LAN access service
Keyword
Priority
Fault Description
Network topology: Layer 2 switch -> MA5620G -> MA5600T (V800R006C02)
The GPON service of the MA5600T uses the solution of binding GEM ports to priorities. That
is, the priority bound to traffic streams of the MA5620G is 0 and the priority bound to traffic
streams of the management address of the MA5620G is 3. Users can remotely ping the
management IP address of the Layer 2 switch but cannot telnet it.
Alarm Information
None
Cause Analysis
l The Layer 2 switch filters out telnet packets by ACL rules configured.
l The MA5600T uses the solution of binding GEM ports to priorities. The priority of traffic
streams for managing the Layer 2 switch must be 0. Otherwise, the MA5600T drops
packets.
Procedure
Step 1 Check configurations of the Layer 2 switch. It is found that telnet for the port is not blocked.

Module
Step 2 Capture packets on the Layer 2 switch. It is found that the priority of the telnet response packet
of the Layer 2 switch is 6. The priority of the packets of the Layer 2 switch cannot be changed.
Step 3 Check the configurations of the MA5620G. It is found that the transparent LAN service (TLS)
streams are configured, but the attributes of such streams cannot be changed.
Step 4 Configure a traffic stream on the MA5620G using the management IP address of the Layer 2
switch and configure the stream with the following attributes using the traffic profile: the priority
of the stream is 0, the local attributes are used. Then, the Layer 2 switch can be telneted remotely.
Then, it is found that the fault is rectified.
----End

If the GPON service of the MA5600T uses the solution of binding GEM ports to priorities, the
priority of the traffic stream transmitted to the GPON device needs to be checked.
7.5.1.2 TC-C6180 Failure to Ping the MA5620 Because the MA5600T Is Enabled with
Anti-IP Attack
This topic describes how to troubleshoot the fault when the MA5620 fails to be pinged.
Fault Type
Device/NMS
Keyword
Anti-IP attack, management
Fault Description
An office deploys the MA5600T and the MA5620 but the management IP address of the
MA5620 fails to be pinged on the MA5600T.
Alarm Information
None
Cause Analysis
l The optical path is faulty or a rogue ONU exists.
l IP addresses conflict.
Procedure
Step 1 Check optical power. It is found that the optical power is normal. This indicates that the optical
path is normal.

Module
Step 2 Ping MA5620s connected to the optical splitter. It is found that all these MA5620s fail to be
pinged. Then, connect the MA5620s to the MA5600T separately. It is found that the fault
persists. This indicates that a rogue ONU does not exist.
Step 3 Check configurations of the management channel of the MA5600T. It is found that
configurations are correct. In addition, the MA5600T can issue data to the MA5620. This
indicates that the fault is not caused by configurations and the optical path.
Step 4 Check the management IP address. It is found that IP address conflict does not occur.
Step 5 Check other parameters. On the MA5600T, run the display security config command to confirm
that the anti-IP attack function is enable.
Step 6 It is suspected that the enabled anti-IP attack causes ping failure between the MA5600T and
MA5620. In this case, run the security anti-ipattack disable command to disable the anti-IP
attack function.
Step 7 After the anti-IP attack function is disabled, the MA5600T can ping all the MA5620s.
----End

After anti-IP attack is enabled, the MA5600T discards the user-side IP packet whose destination
address is the IP address of itself. As a result, the MA5600T cannot ping MA5620s and MA5620s
cannot be connected or managed by the MA5600T.
7.5.1.3 TC-C6382 Failure to Log In to the Device Caused by Malicious Attacks

This topic describes how to troubleshoot the fault when a user fails to log in to the device in the
telnet mode because of malicious attacks.
Fault Type
Other
Keyword
Malicious Attacks
Fault Description
When a user logs in to the OLT in the telnet mode, the system prompts "too many users" and
the login fails.
MA5600T version: V800R006C02SPC100
Alarm Information
None
Cause Analysis
l The number of times of the remote login to the OLT exceeds the system limitation.
l The system software is faulty.

Module
l The hardware, such as the control board, is faulty.

l Virus attacks.
l Other causes.
Procedure
Step 1 Run the display client command or the display terminal user online command to check the
user information. It is found that all online users log in to the system through serial ports.
Step 2 Collect information from the OLT. It is found that certain users with fixed IP addresses
repeatedly try to log in to the OLT through port 22 (port 22 is used for SSH, port 23 is used for
telnet, and port 22 and port 23 share the same connection channel). The IP addresses are not
owned by the carrier. Therefore, viruses may exist or there are malicious attacks on the OLT.
Meanwhile, multiple faulty sites do not have any security measures. The ACL/firewall is not
configured and even the default password of the root user is not changed.
Step 3 In case of such malicious attacks, the OLT fails to protect the abnormal TCP connection
sufficiently if the firewall is not configured. If user 2 starts the connection when user 1 closes
the connection (the fault recurs easily because of thousands of connections in a short time), user
2 and user 1 share the same connection channel and user 2 may fail to close the connection. If
the conflict accumulates, users fail to log in to the OLT.
Step 4 To troubleshoot the fault, configure a powerful firewall and ACL rules on the OLT as follows:
huawei(config)#firewall enable
huawei(config)#firewall default permit
huawei(config)#acl 3000 //Only the TCP connection within the
specified IP address range can connect to the IP address of the device.
huawei(config-acl-adv-3000)#rule
{ integer<0,4294967294>|permit<K>|deny<K> }:permit
{ <1-255>|ip<K>|gre<K>|ipinip<K>|icmp<K>|tcp<K>|udp<K> }:tcp
{ <cr>|source<K>|destination<K>|source-port<K>|destination-port<K>|time-range<K>
|established<K>|fragment<K>|dscp<K>|precedence<K>|tos<K> }:source
{ ip_addr<X.X.X.X>|any<K> }:218.3.253.0 //Source IP address range
{ ip_addr<X.X.X.X>|0<K> }:0.0.0.255 //Mask with 24 bits. Note that the
mask here is different from the common mask.
{ <cr>|destination<K>|source-port<K>|destination-port<K>|time-range<K>|establish
ed<K>|fragment<K>|dscp<K>|precedence<K>|tos<K> }:destination
{ ip_addr<X.X.X.X>|any<K> }:218.3.253.15 //Destination IP address
{ ip_addr<X.X.X.X>|0<K> }:0 //Complete match of masks
{ <cr>|source-port<K>|destination-port<K>|time-range<K>|established<K>|fragment<
K>|dscp<K>|precedence<K>|tos<K> }:
Command:
rule permit tcp source 218.3.253.0 0.0.0.255 destination 218.3.253.15 0
huawei(config-acl-adv-3000)#rule deny //It is forbidden to connect the
TCP packets of all other IP addresses to the IP address of the device.
{ <1-255>|ip<K>|gre<K>|ipinip<K>|icmp<K>|tcp<K>|udp<K> }:tcp
{ <cr>|source<K>|destination<K>|source-port<K>|destination-port<K>|time-range<K>
|established<K>|fragment<K>|dscp<K>|precedence<K>|tos<K> }:source
{ ip_addr<X.X.X.X>|any<K> }:any
{ <cr>|destination<K>|source-port<K>|destination-port<K>|time-range<K>|establish
ed<K>|fragment<K>|dscp<K>|precedence<K>|tos<K> }:destination
{ ip_addr<X.X.X.X>|any<K> }:218.3.253.15
{ ip_addr<X.X.X.X>|0<K> }:0
{ <cr>|source-port<K>|destination-port<K>|time-range<K>|established<K>|fragment<
K>|dscp<K>|precedence<K>|tos<K> }:
Command:
rule deny tcp source any destination 218.3.253.15 0
huawei(config-acl-adv-3000)#quit
huawei(config)#interface vlanif 4000
huawei(config-if-vlanif4000)#firewall
{ packet-filter<K> }:packet-filter
{ INTEGER<2000-2999>|INTEGER<3000-3999> }:3000 //Previously configured
ACL rules

Module
{ inbound<K>|outbound<K> }:inbound
Command:
firewall packet-filter 3000 inbound
ACL applied successfully
----End

l It is recommended that you check the ACL configuration on the OLT.
l If the OLT on the site runs in the normal state, perform the configuration shown in the
proceeding display. If the OLT on the site prompts "too many users" and users fail to log
in to the OLT, it is recommended that you restart the system, configure the ACL rules
shown in the preceding display and then save the configuration, or configure the ACL rules
shown in the preceding display, save the configuration, and then restart the system to
troubleshoot the fault.
7.5.1.4 TC-C6384 Failure to Ping the Layer 3 Interface Caused by a Ring Network
This topic describes how to troubleshoot the fault when pinging the Layer 3 interface fails
because of a ring network.
Fault Type
Other
Keyword
Layer 3 Interface
Ring Network
Fault Description
The user PC and the OLT can learn the MAC address of each other, but the user cannot ping the
corresponding Layer 3 interface of the OLT from the PC.
Alarm Information
None
Cause Analysis
Procedure
Step 1 Check the physical connection. It is found that the connection is proper.
Step 2 Check whether the anti-MAC spoofing or anti-IP/ICMP attack function is enabled. Check the
system configuration. It is found that the firewall is disabled, no security feature is configured
and no rules for filtering packets are set.

Module
Step 3 Check whether the ARP entry is correct. Check the MAC address learning. It is found that the
corresponding ARP entry exists. When you compare the port that provides the access service to
the user and the learned port, it is found that they are not the same.
Step 4 Disconnect the line to the port that learns the ARP entry. It is found that the user PC can ping
the Layer 3 interface of the device. Connect the line to the port that learns the ARP entry and
clear the ARP entry. It is found that the user PC cannot ping the Layer 3 interface of the device.
Step 5 Check the network. It is found that the peer device exists in a ring network. After the ring network
is removed, the fault is rectified.
----End

In this case, a ring network exists. Therefore, the ARP packets sent from one upstream port are
returned from another upstream port. This causes the failure to refresh the ARP entry. In addition,
the ping packet searches for the egress based on the ARP entry, and the service packets are sent
through an incorrect port; thus the failure to ping the Layer 3 interface occurs.
7.5.2 NEs Fail to Be Managed by the NMS

NEs fail to be managed by the NMS is a fault that the NMS fails to manage NEs.
7.5.2.1 TC-C6370 Failure of the BMS to Manage NEs Caused by Inconsistent

Versions
This topic describes how to troubleshoot the fault when the BMS fails to manage the NEs because
of inconsistent versions.
Fault Type
Other
Keyword
Failure of the BMS to Manage NEs
Fault Description
The telecommunications room of an office is powered off abnormally several times. After the
OLT starts up, the BMS fails to manage the OLT. After logging in to the OLT, the engineers
find that certain data is lost and the versions are inconsistent.
The communication failure alarms are generated on the BMS and the reset alarms are generated
on the OLT.
Alarm Information
None
Cause Analysis
l The OLT version is incorrect.

Module
l The configuration on the OLT is incorrect.
Procedure
Step 1 Check the version of the OLT. It is found that it is the version before upgrade.
Step 2 Check the data. It is found that it is the data before upgrade.
Step 3 Check the rollback state. It is found that the rollback is in the "enabled" state.
NOTE
l In OLT upgrade, the program and database can be loaded through either the BIOS or command lines.
l The flash memory of the OLT is divided into the active sector and the standby sector. When the program
and the database are loaded through the BIOS, the program and the database are written into the active sector
and the standby sector.
l When the program and the database are loaded through command lines, if the system is reset during the
loading, the program and the database are only written into the active sector. Check the status of the rollback
through command lines. It is found that the rollback is in the "enabled" state. This state, however, is available
only for two days (by default). After two days, the state changes to "disabled".
l If the rollback is in the "disabled" state, the OLT synchronizes the program and the database in the active
sector to the standby sector. If the rollback is in the "enabled" state, the OLT does not synchronize the
program and the database in the active sector to the standby sector.
Step 4 The OLT is newly installed (less than two days) and is upgraded through command lines. The
system resets after the program is loaded, whereas the database is not loaded. The rollback is in
the "enabled" state. The OLT fails to start up for several times due to abnormalities and rolls
back to the previous version. It can be determined that the OLT rolls back.
Step 5 Reload the version through the BIOS or command lines.
----End

None
7.5.2.2 TC-C6189 N2000 BMS Frequently Fails to Manage the MA5616 Because of
Bridge MAC Address Conflict
This topic describes how to troubleshoot the fault when the N2000 BMS frequently fails to
manage the MA5616.
Fault Type
Ethernet service
Keyword
MAC address, NMS management failure, 00e0-fc11-2233
Fault Description
Version: MA5616 V800R306C01B053
Two MA5616s managed by the N2000 BMS report NMS management failure alarms every
some minutes.

Module
Alarm Information
Device communication abnormality
Cause Analysis
Two MA5616s encounter this fault concurrently. The IP addresses or MAC addresses may
conflict with each other.
Procedure
Step 1 Check IP addresses of the two MA5616s. It is found that they are different.
Step 2 Check MAC addresses of the two MA5616s. It is found that they are the same, that is, 00e0-
fc11-2233. This indicates that the fault is caused by MAC address conflict.
Step 3 Change the MAC addresses of the two MA5616s. The fault is rectified.
----End

It is recommended that you check whether the MAC address of the MA5616 is 00e0-fc11-2233
in deployment. If the MAC address is 00e0-fc11-2233, change the MAC address.
7.5.2.3 TC-C6245 Network Management Service of All ONUs Connected to the

Same PON Port Is Frequently and Intermittently Interrupted Owing to the
Incorrect Configuration of the DBA
This topic describes how to troubleshoot the fault when the network management service of All
ONUs connected to the same PON port is frequently and intermittently interrupted.
Fault Type
Ethernet service
Keyword
Frequent and intermittent interruption of the network management service
Fault Description
The GPON access service is used on a site. The port (0/1/3) on the GPBC board of the OLT is
connected to 18 ONUs. The network management service of all these ONUs frequently and
intermittently interrupted for more than 400 times a day.
Alarm Information
LOF
Possible Cause
l The optical circuit is faulty.

Module
l The GPBC board is faulty.

l The optical splitter is faulty.
l One or more rogue ONUs exist.
l The software configuration is incorrect.
Procedure
Step 1 Measure the optical power of the branch optical circuit. The optical power is -17 dBm, which
falls in the normal range. This indicates that the fault is not caused by the optical circuit.
Step 2 Replace the optical splitter. The fault persists. This indicates that the fault is not caused by the
optical splitter.
Step 3 Replace the GPBC board. The fault persists. This indicates that the fault is not caused by the
GPBC board.
Step 4 Use the minimum configuration method to locate the fault. Deactivate all the ONUs connected
to the port (0/1/3), and then activate these ONUs one by one. It is found when ONU 9 is activated,
all the ONUs connected to the port (0/1/3) start to intermittently discard packets. ONU 9 may
be a rogue ONU.
Step 5 Replace ONU 9 with a new ONU. The fault persists. This indicates that the fault is not caused
by the rogue ONU.
Step 6 On the OLT, ping the management IP address of ONU 9 for a period of time. On the ONU, run
the display icmp statistics command to take statistics on packets. It is found that the number
of IGMP echo packets is the same as the number of the echo reply packets. This indicates that
intermittent packet lost does not occur on the ONU side.
Step 7 On the OLT, take statistics on packets. It is found that the number of IGMP echo packets is
different from the number of the echo reply packets and is less than the number of echo reply
packets counted on the ONU. This indicates that packet loss may occur on the OLT side.
Step 8 Further analyze the relevant data. It is found that the bandwidth allocation type of the DBA
template bound to ONU 9 is set to type4 and the maximum bandwidth is 1,024,000 kbit/s. It is
possible that the configured uplink bandwidth is too large, which causes congestion.
Step 9 Change the maximum bandwidth of the DBA template to 102,400 kbit/s. The fault is rectified.
----End

The uplink bandwidth of the GPON is 1.25 Gbit/s. When the configured bandwidth is 1 Gbit/s,
congestion may occur because the uplink traffic is too large.
In this case, ONU 9 is connected to 21 switches. Both the uplink and downlink traffic is large.
In particular, when the display statistics ont is executed, a lot of broadcast packets are detected.
The networking that the ONU is connected to multiple switches is not recommended.
7.5.3 Service Board Resets Repeatedly

Service board resets repeatedly is a fault that after the system resets, the service board resets
repeatedly and cannot work.

Module
7.5.3.1 TC-C6141 ASPB Board of an ONU Resets Repeatedly Because the DC Power
Is Poorly Grounded
This topic describes how to troubleshoot the fault that the ASPB board of an ONU (MA5616)
resets repeatedly.
Fault Type
System failure
Keyword
Board reset, DC power, ground
Fault Description
Network topology: ONU (MA5616) -> OLT (MA5600T)
Version: MA5616 V800R306C01SPH009
Fault description: The MA5616 adopts the DC power for power supply and the two ASPB boards
are normal and abnormal interchangeably. In addition, such a fault occurs repeatedly.
Alarm Information
Alarms "The communication between the service board and the control board fails" and "The
communication of the board with the control board recovers" are generated repeatedly.
Event "The board is powered off" is generated repeatedly.
Cause Analysis
l The MA5616 service board is faulty.
l There are a large number of VoIP users. As a result, the -48 V power of the MA5616
becomes low.
l The power supply of the MA5616 is abnormal.
Procedure
Step 1 On the MA516, run the display event history all command to query historical events. It is found
that the event "The board is powered off" exists. Then, test the power supply voltage of the PDIA
power board. It is found that the voltage is -53 V and the power supply is stable.
Step 2 It is suspected that excessive VoIP users are connected to the ASPB board, which lowers the
power voltage when the board starts. In this case, remove all the ASPB boards and then insert
only one ASPB board. It is found that the fault persists. In addition, this fault cannot be rectified
by loading patch SPC018.
Step 3 Replace the ASPB board and the subrack on site. It is found that the fault persists. In this case,
it is suspected that the power supply of the device is abnormal because of the generated event
"The board is powered off". Replace the DC-powered ASPB board with the AC-powered PAIA
power board in the subrack where the fault occurs. It is found that the PAIA power board works
normally and the power voltage is stable. This can be concluded that the fault is caused by DC
power.

Module
Step 4 Check device connections on site. It is found that device connections are as follows:
The MA5616 and the rectifier module from a vendor are installed on the same metal rack. When
receiving the 220 V AC, the rectifier module outputs five -48 V DC loads to other devices. In
these five -48 V DC loads, the rated current of load 1 and load 2 is 20 A, which is higher than
the output current of the other three loads. In addition, each load is controlled by a switch. In
the network diagram, a battery group is connected to the BATT interface on the rectifier module,
which is used for supplying power for loads after the AC power is powered off. The GND point
of the rectifier module is suspended.
Step 5 Disconnect the power cable from the PDIA power board. Then, test the voltage between the two
cables connecting load 2 to the PDIA power board. It is found that the voltage is -53 V, which
meets the requirement. Test the voltage between the ground cable (in black) of the MA5616 and
the GND point. It is found that there is a voltage of about 30 V. Then, use a ground cable to
connect the GND point on the MA5616 to the metal rack. It is found that the 30 V voltage does
not exist. In this case, connect the MA5616 to the metal rack and start the MA5616. It is found
that the ASPB board registers normally and the fault is rectified.
----End

When the DC power is adopted for supplying power for an ONU, the ONU and the rectifier
module must be grounded securely.
7.5.4 Other Service Faults

This topic describes how to troubleshoot other common service faults.
7.5.4.1 TC-C6016 Interconnection Between the OLT and the Switch Fails Due to
Incorrect LACP Configuration on the Switch
This topic describes how to troubleshoot the fault when Huawei OLT fails to interconnect with
the switch of another vendor due to incorrect Link Aggregation Control Protocol (LACP)
configuration on the switch.

Module
Fault Type
Other
Keyword
LACP configuration
Interconnection failure
Fault Description
The OLT is connected to a certain type of switch of another vendor in the lacp-static aggregation
mode in the upstream direction. After lacp-static is configured, an alarm is generated, and the
related service is unavailable.
Alarm Information
The alarm generated on the OLT is as follows:
huawei(config)#link-aggregation 0/17 0-1 egress-ingress workmode lacp-
static
huawei(config)#
! EVENT MAJOR 2008-07-15 13:42:03
ALARM NAME :Port is forbidden to transfer the service packets
PARAMETERS :FrameID: 0, SlotID: 17, PortID: 0
huawei(config)#
! EVENT MAJOR 2008-07-15 13:42:03
ALARM NAME :Port is forbidden to transfer the service packets
PARAMETERS :FrameID: 0, SlotID: 17, PortID: 1
Cause Analysis
l The upstream optical path of the OLT is faulty.
l The data configuration of the upstream port on the OLT is incorrect.
l The LACP configuration is incorrect.
l The configuration of the peer switch of this vendor is incorrect.
Procedure
Step 1 Check the configuration of the upstream board on the OLT and the configuration of the switch.
It is found that the interconnected optical ports on the OLT and the switch are configured as
forced 1000 Mbit/s and full duplex, and are in the up state. Therefore, it can be determined that
the fault is not caused by the optical path.
Step 2 Disable the aggregation function. It is found that the upstream service of a single link is normal.
Therefore, it can be determined that the data configuration of the upstream port on the OLT is
correct.
Step 3 Configure the aggregation manually, and do not run the LACP protocol. It is found that the
services are normal. Therefore, it can be determined that the fault is caused by the LACP
interconnection.
NOTE
The systems at both ends of the link of the static LACP aggregation group run the LACP protocol; however,
systems at both ends of the link of the manual aggregation group do not run the LACP protocol.

Module
Step 4 The switch of this vendor supports both the Port Aggregation Control Protocol (PAgP) and
LACP, and uses PAgP by default. It is preliminarily suspected that the default protocol PAgP
runs on the switch, which causes interconnection failure. After check, however, it is found that
LACP runs on the switch.
Step 5 Configure the switch to be in the active LACP mode. The fault then is rectified.
----End

The switch of this vendor supports the following two LACP modes:
l Passive LACP mode (default mode): In this mode, the port is in the passive state, and does
not initiate an LACP negotiation.
l Active LACP mode: In this mode, the port is in the active state, and initiates an LACP
negotiation.
In this case, the LACP mode is configured on the switch, but an active negotiation is not initiated,
which causes the failure to interconnect with Huawei OLT.
Suggestion: When Huawei OLT is connected to the switch of another vendor in the upstream
direction after link aggregation, the switch must to be configured with the LACP of active mode
(Huawei devices are in the active negotiation mode by default). In this case, the LACP
negotiation can be initiated.
7.5.4.2 TC-C6024 Failure to Support the Long-Distance E1 Cable Due to the Jumper
Setting Problem on the TOPA Board
This topic describes how to troubleshoot the fault when the TOPA board cannot support the
long-distance (20–30 m) E1 cable due to the jumper setting problem on the board.
Fault Type
Other
Keyword
TOPA board
E1 cable
Fault Description
On the TOPA board of the OLT, the line impedance of the E1 port is set to 120 ohms through
the software parameters. When connected to the 120-ohm terminal of the ODF through a 5–10
m cable, the TOPA board can carry the E1 service normally. After the cable is replaced with a
30 m cable, the E1 service is unavailable.
Alarm Information
None

Module
Cause Analysis
The transmission principles of 75-ohm cable are different from the transmission principles of
the 120-ohm cable. The conversion from 75-ohm to 120-ohm fails to be implemented by using
only settings of software parameters. To implement the conversion, the jumper and the DIP
switch must be used, in addition to the setting of software parameters.
NOTE
The differences between the transmission principles of a 75-ohm cable and the transmission principles of a 120-
ohm cable are as follows:
l 75-ohm E1 cable: unbalanced coaxial cable
l On the transmit end: One wire is grounded, and the other is used to transmit data.
l On the receive end: One wire is grounded, and the other is used to receive data.
l 120-ohm E1 cable: balanced twisted pair cable, used to transmit data in the dual-Tx and dual-Rx mode.
Procedure
Step 1 Connect a converter that converts 75-ohm to 120-ohm to the cable of the TOPA board, and
connect the cable to the 120-ohm terminal of the ODF. In this case, the TOPA board can carry
E1 services normally. Therefore, it can be determined that the setting of software parameters
cannot implement the interconnection.
Step 2 Remove the TOPA board, and it is found that the E1 jumpers are installed on the TOPA board,
which is covered by the daughter board. Then, remove the E1 jumpers of all the ports, and remove
the converter added in step 1. After that, reinstall the TOPA board. It is found that the TOPA
board can carry the E1 service normally.
----End

Currently, the TOPA board on the device has E1 jumpers. When the long-distance E1 cable
needs to be supported, use the E1 jumper. When no E1 jumper is available, use the converter,
because settings of software parameters cannot implement the conversion from 75-ohm to 120-
ohm.
7.5.4.3 TC-C6154 BMS Frequently Prints the Error Message Because the MA5652G
Does Not Support 1588 Clock
This topic describes how to troubleshoot the fault when the BMS frequently prints the error
message.
Fault Type
Others
Keyword
1588 clock, GPON Message_Error message
Fault Description
Network topology: ONU (MA5652G)-> OLT (MA5600T)

Module
Version: MA5600TV800R007C00, MA5652GV800R307C00SPC202
Fault description: The BMS frequently prints the GPON Message_Error message.
Alarm Information
Navigate to the BMS interface to check alarms and events. In the Events column, more than 10
GPON Message_Error messages are printed per second and these messages are generated by
MA5652Gs with different IP addresses.
Location Method
1. The alarms and events displayed on the BMS are reported by the device. Therefore, learn
about the events that can be generated by a device.
2. Check whether the event is generated on only one MA5652G or all the MA5652Gs.
3. Query the related information to find the cause of event generation.
4. Take further measures to solve or prevent reporting of the event.
Procedure
Step 1 Run the event output all command to enable the event print function of MA5652G. It is found
that the event ID is 0x0a300146.
Step 2 Query other MA5652Gs. It is found that such an event is also generated.
Step 3 Query the alarm and event manual of the corresponding version of the MA5652G. It is found
that such an event is generated because "The ONU receives from the OLT a message that the
ONU does not recognize".
Step 4 Confirm that such an event is frequently generated because the PLOAM message carries the
1588 clock information. The PLOAM message is sent from the OLT to the MA5652G. The 1588
clock feature is a new feature in MA5600TV800R007C00, which is not supported by
MA5652GV800R307C00. As a result, the MA5652G cannot identify the PLOAM message
carrying the 1588 clock information. The clock message is transmitted in a high frequency and
all the MA5652Gs report the same event to the BMS. As a result, the BMS frequently refreshes
the GPON Message_Error message.
Step 5 On the MA5652G, run the trap filter event condition id 0x0a300146 command to prevent such
a clock message from being sent to the BMS. Then, the fault is rectified.
----End

None
7.5.4.4 TC-C6155 Anti MAC Spoofing of the MA5652G Fails Because Anti MAC
Spoofing Is Not Enabled in the VLAN Service Profile
This topic describes how to troubleshoot the fault when anti MAC spoofing of the MA5652G
fails.

Module
Fault Type
Others
Keyword
Anti MAC spoofing, VLAN service profile
Fault Description
Version: MA5652G V800R307C00SPC208
Fault description: In the global config mode, anti MAC spoofing is enabled and two PCs with
different IP addresses but with the same MAC address can obtain their IP addresses through the
DHCP server.
Alarm Information
None
Cause Analysis
1. On the MA5652G, run the display security bind mac command to check whether the MAC
address is bound to the MA5652G.
2. If the MAC address is not bound to the MA5652G, it indicates that anti MAC spoofing is
not enabled. In this case, check the configurations.
3. If the MAC address is bound to the MA5652G, it indicates that the fault may be caused by
the device. In this case, submit the fault to Huawei technical support engineers to locate
the fault.
Procedure
Step 1 On the MA5652G, run the display security bind mac command to check whether the MAC
address is bound to the MA5652G. It is found that the MAC address is not bound to the
MA5652G.
Step 2 Enable anti MAC spoofing in the global config mode and the VLAN service profile and then
bind the MAC address. The related configurations are as follows:
In the global config mode:
[abs-config]
<abs-config>
security anti-macspoofing enable
In the VLAN service profile:

[vlan-srvprof]
<vlan-srvprof>
vlan service-profile profile-id 1 profile-name "srvprof-1"
security anti-macspoofing enable
commit
vlan bind service-profile 200 profile-id 1 //200 is the ID of the VLAN
that needs to be bound to the MAC address.
----End

Module

After anti MAC spoofing is enabled both in the global config mode and the VLAN service
profile, you can run the display security bind mac command to query the bound MAC address
if you fail to query the bound MAC address by running the display mac-address command.
7.5.4.5 TC-C6309 The Downloading Rates of 40 Mbit/s and 60 Mbit/s Downloading

Bandwidths Cannot Reach Expected Values Because of Incorrect Setting of the
Buffer Size on the FTP Server
This topic describes how to troubleshoot the fault when the downloading rates of 40 Mbit/s and
60 Mbit/s downloading bandwidths cannot reach expected values because the buffer size is
incorrectly set on the FTP server.
Fault Type
GPON service
Keyword
FTP Server
Buffer Size
Fault Description
Networking: PC –> ONT –> OLT –> MPLS/IP network –> Internet –> Remote FTP server
The GPON downloading rate is tested in an office. The downloading rates are tested when the
bandwidths are 100 Mbit/s, 80 Mbit/s, 60 Mbit/s, 40 Mbit/s, 20 Mbit/s, and 10 Mbit/s. When
the bandwidths are 40 Mbit/s and 60 Mbit/s, the downloading rates cannot reach the expected
values (bandwidth x 80%).
Alarm Information
None
Cause Analysis
l The flow control configuration is incorrect.
l The network transmission is faulty.
Procedure
Step 1 Check whether the fault is caused by the improper settings of the flow control. Check the settings
of the traffic-table, ont gemport bind, tcont bind-profile, and DBA-profile parameters of the
service stream. It is found that the flow control is set correctly.
Step 2 The FTP downloading is tested through the remote FTP server. Check whether a network
bottleneck exists on the MPLS/IP network or whether packet loss occurs on a node. Simulate a
local FTP server to conduct a test. It is found that the fault persists. This indicates that the fault
is not caused by the MPLS/IP network.

Module
Step 3 Analysis: FTP is based on the CS model and the application layer protocol of TCP. According
to the features of the protocol, the buffer size must be set differently for different downloading
bandwidths on the server and client so that expected downloading rates can be reached.
1. If the downloading bandwidth is 40 Mbit/s, change the buffer size of the FTP server from
10240 bytes to 4096 bytes.
2. If the downloading bandwidth is 60 Mbit/s, change the buffer size of the FTP server from
10240 bytes to 6144 bytes.
Step 4 Retest whether the downloading rates reach the expected values. As a result, the fault is rectified.
----End

The FTP downloading is an end-to-end process. The downloading rate involves every stage of
the entire end-to-end service process, including the following:
l Hardware performances of the FTP server and client
l Bandwidth and delay of the transmission line
l Algorithms of the FTP server (including the size of the transmit buffer)
l Algorithms of the client (including the size of the sliding window)
The fault that the downloading rate on the client cannot reach the expected value is mostly caused
by the incorrect setting of the transmit buffer size of the FTP server. Therefore, you can rectify
the fault by setting different buffer sizes for different downloading bandwidths on the FTP server.
7.5.4.6 TC-C6369 Failure to Load the Configuration File Backed Up in the Unix
Operating System
This topic describes how to troubleshoot the fault when the configuration file backed up in the
Unix operating system cannot be loaded successfully.
Fault Type
Other
Keyword
Backup File
Unix
Fault Description
The configuration file is backed up from the OLT to the Unix operating system on a site. When
the configuration file is reloaded to the OLT, the system prompts invalid configuration file, and
the loading fails.
Alarm Information
None

Module
Cause Analysis
The backup file is incorrect.
Procedure
Step 1 Analysis: Open the backup configuration file. It is found that illegible characters exist in the
configuration file. Therefore, when the configuration file is backed up in different operating
systems, illegible characters are generated due to different coding formats, which results in the
loading failure.
Step 2 Back up the configuration file again in the Windows operating system. It is found that the loading
is successful.
----End

The coding formats in the Unix and Windows operating systems are different. As a result,
illegible characters exist in the configuration file backed up in the Unix operating system.
Therefore, it is recommended that you back up files in the Windows operating system.
7.5.4.7 TC-C6377 Failure to Synchronize a Correctly Configured NTP Client with

the NTP Server in Time
This topic describes how to troubleshoot the fault when a correctly configured NTP client cannot
synchronize with the NTP server in time.
Fault Type
Other
Keyword
NTP Server
Time Synchronize
Fault Description
When the OLT, whose NTP feature is properly configured, is connected to the NTP server, the
OLT cannot synchronize with the NTP server in time. The NTP server, however, provides the
normal time synchronization service.
Alarm Information
None
Cause Analysis
l The configuration on the NTP server is improper.

Module
Procedure
Step 1 Check the network connection between the client and the server. It is found that the link is in
the normal state.
Step 2 Check the configuration of the OLT. It is found that the configuration is correct.
Step 3 Check the configuration of the NTP server. It is found that the NTP server is configured with
an ACL rule, which prevents the clients in a certain network segment from synchronizing the
NTP server in time.
Step 4 Change the ACL rule that is configured on the NTP server, and manually change the time of the
OLT to be the same as the time of the NTP server. Then, the time synchronization service is
recovered and the fault is rectified.
----End

When the OLT cannot normally synchronize the NTP server in time, you need to locate the fault.
Most faults are caused by an improper network environment or incorrect device configuration.
7.5.4.8 TC-C6170 Failure to Back Up the Database File Because the Patch Is Not
Activated
This topic describes how to troubleshoot the fault when the database file fails to be backed up.
Fault Type
Database service
Keyword
Backup, database, flash memory
Fault Description
The database file fails to be backed up using the CLI. A message is displayed on the device,
indicating that reading information from the flash memory has an error or the flash memory does
not contain the correct database file.
Alarm Information
None
Cause Analysis
The IO board package file is not activated.
Procedure
Step 1 Run the save command to save the data. It is found that the data is successfully saved. This
indicates that the flash memory of the control board is normal.

Module
Step 2 Back up the configuration file using TFTP. It is found that the configuration file is successfully
backed up. This indicates that TFTP configurations are correct.
Step 3 Run the display io-packetfile information command to query the IO board package file. It is
found that patch SPH109 is not activated. Run the patch activate command to activate the patch.
It is found that the database file can be backed up.
----End

After a patch is loaded to the device, if the IO board package file is not activated, the data can
be saved but the database file cannot be backed up. To troubleshoot such a fault, run the patch
activate command to activate the patch.
7.5.5 Upgrade Failure

Upgrade failure means that the device upgrade cannot be finished.
7.5.5.1 TC-C6237 MDU Cannot Be Upgraded Normally Owing to the Unstable

Transmission Link
This topic describes how to troubleshoot the fault when the MDU cannot be upgraded normally.
Fault Type
Upgrade and cutover
Keyword
Upgrade failure
Fault Description
Network topology: PC -> O/E converter -> Optical fiber -> O/E converter -> S9300 -> MAN -
> MA5600T -> MA5620, where the PC is connected to an O/E converter through a network
cable, and the S9300 is connected to an O/E converter through a network cable.
Version: MA5620 MxU_Series_V800R308C00SPC500
Start the TFTP service on the PC. Upgrade the MA5620 to
MxU_Series_V800R308C00SPC500_MA562X (SD5103-new_device). Twelve hours after the
version loading process reaches 99%, the version loading process is still 99% and upgrade fails.
The MA5620 cannot be reset. One day later, the version is loaded successfully. After the
MA5620 is reset, the version upgrade of the MA5620 succeeds. The same fault occurs on
multiple MA5620s running on the live network.
Alarm Information
None
Possible Cause
l The software package H822Epub_packetfile.bin is corrupted.

Module
l The hardware of the MA5620 is faulty.

l The transmission link is unstable. Therefore, it takes a long time to transfer the software.
Procedure
Step 1 Remove the original H822Epub_packetfile.bin. Obtain the new H822Epub_packetfile.bin
and load the version software again. The fault persists.
Step 2 Load the version software on multiple MA5620s. The same fault occurs. When these MA5620s
are upgraded on site, the fault does not occur. Therefore, the hardware of MA5620s is not faulty.
Step 3 On the PC, ping large packages sent to the MA5620. No packets are lost.
Step 4 Load the version software in FTP mode. The same fault occurs.
Step 5 Connect the FE port on the uplink board of the MA5600T to the PC. Ping large packets between
the FE port and the PC. It is found that the delay is great and some packets are lost. The
transmission link may be faulty.
Step 6 Check the line section by section. It is found that the quality of the network cable between the
S9300 and the O/E converter is not good. After this network cable is replaced, the fault does not
occur.
----End

None
7.5.6 Control Board Abnormal Reset

Control board abnormal reset means that the control board resets and restarts unexpectedly in
case of an abnormality.
7.5.6.1 TC-C6364 Failure to Start the Upgraded Standby Control Board Caused by
Mismatching of the Extended BIOS
This topic describes how to troubleshoot the fault when the upgraded standby control board fails
to start because the extended BIOS does not match.
Fault Type
Other
Keyword
Upgraded Standby Control Board
Extended BIOS
Fault Description
The OLT is configured with active and standby control boards. After the active and standby
control boards are upgraded through command lines, the active control board can start, but the

Module
standby control board is reset repeatedly. Run the display board 0 command to check the board
status. It is found that the standby control board is in the "Failed" state.
Alarm Information
None
Cause Analysis
l The version of the upgrade program does not match.
l The versions do not match.
Procedure
Step 1 Check the active control board. It is found that the active control board is in the normal state.
This ensures that the fault is not caused by the upgrading program.
Step 2 Check the standby control board. It is found that the standby control board is reset repeatedly.
Therefore, the fault may be caused by the versions. Check the version configuration table. It is
found that the extended BIOS version does not match the current host version.
Step 3 Connect the serial port on the maintenance terminal to the standby control board. When "Press
<D> key to stop auto-boot" is displayed during the starting of the standby control board, press
D to enter the startup option, or select 3 to erase the extended BIOS.
System is booting from extended BIOS...
The last update date of extended BIOS is : May 16 2005, 10:37:33
Extended BIOS version is 108
Press <D> key to stop auto-boot 5
Main Menu
=============================
0. Boot from flash
1. Boot from serial port by Xmodem
2. Boot from ethernet port by TFTP
3. Erase extended BIOS and reboot
Please enter a choice : 3
Step 4 Load the BIOS again through TFTP after the standby control board is reset.
Base BIOS version is 108
Check spare extended BIOS...OK!
Press <D> in three seconds to download extended BIOS, press
<C> to restore main extended BIOS from spare BIOS area...
Now system will load extended BIOS from Xmodem/TFTP.
Please select load mode:
0 -- Xmodem , 1 -- TFTP , Q -- QUIT[default: 1]: 1
Extended BIOS will be downloaded by TFTP.
Board IP address : [10.11.104.226] 10.11.104.2
Board Mask address : [255.255.252.0]
Host IP address : [10.11.104.1] 10.11.104.226
Download filename : [scuextbios.bin]
You will download file 'scuextbios.bin' from TFTP server 10.11.104.226
Are you sure?(y/n) : [y] y
Downloading file, please wait...download 258176 bytes OK!
Begin to save extended BIOS to spare area... 100%
Save spare extended BIOS to flash area successfully.
Begin to save extended BIOS to main area... 100%
Save main extended BIOS to flash area successfully.
Saving extended BIOS disable start flag...OK!
Check main extended BIOS...OK!
----End

Module

If the active control board is reset repeatedly, check whether the BIOS matches the software
version. If the BIOS does not match the software version, load the BIOS again.
7.5.7 High CPU Usage Means

High CPU usage means that the CPU usage queried by running the display cpu command is
higher than the normal value.
7.5.7.1 TC-C6366 Slow Command Response and Execution Caused by Concurrent

Operations on the Active/Standby Control Boards Through the Serial Ports
This topic describes how to troubleshoot the fault when the command response and execution
is slow because the active and standby control boards are operated concurrently through the
serial ports.
Fault Type
Other
Keyword
Slow Command Response and Execution
Fault Description
Log in to the system through a serial port, the command response and execution is slow. Run
the display current-configuration command and the system prompts "system busy".
Run the display cpu command to query the CPU usage of the board. It is found that the CPU
usage reaches 19% when no service is running.
NOTE
The system is not configured with any service, the CPU usage should be 13%. Currently, it reaches 19%, which
indicates that the system is processing certain tasks.
Alarm Information
None
Cause Analysis
l The CPU occupancy ratio of the device is high.
l Data synchronization between the active and standby control boards is being performed.
Procedure
Step 1 Check whether a large amount of service traffic is running on the system, which results in the
high CPU usage. It is found that no service is running.
Step 2 The system prompts "system busy". Generally, it indicates that the system is performing the
active/standby switchover when the active and standby control boards are configured.

Module
Step 3 Check whether the active and standby control boards are configured and whether the active/
standby switchover is being performed. It is found that the active/standby switchover is not
performed.
Step 4 Check the system environment. In the case that a system is configured with the active and standby
control boards, check the standby control board. It is found that the standby control board is
connected to a terminal, and an operator is operating the standby control board through the
terminal. Because the active and standby control boards are operated concurrently, the CPU
usage is high, and the command response and execution is slow.
----End

None
7.5.8 EMU Fault

EMU fault refers to a failure or malfunction of an EMU in the subrack.
7.5.8.1 TC-C6133 Configurations of Fans of the MA5600T Fail to Be Issued Because

the New Fans Support the Automatic Loading Function
This topic describes how to troubleshoot the fault when configurations of fans of the
MA5600T fail to be issued.
Fault Type
Environment monitoring
Keyword
Fan, automatic loading, configuration failure
Fault Description
Fault description: In deployment, when the basic configurations are issued to certain devices
through the third-party OSS system, a message is displayed, indicating that configurations of
fans already exist and issuing of fan configurations fails.
Version: The version of the MA5600T is V800R006C02SPC100 and the type of fans is
H801FCBB.
Alarm Information
None
Cause Analysis
According to the obtained information, the fault that configurations of fans fail to be issued
occurs because the device is configured with fans. But devices that encounter the fault are new
devices, which are not configured with fans. Therefore, the fault cause needs to be found by
field test.

Module
Procedure
Step 1 Log in to the device that encounters the fault and run the display emu command to confirm that
configurations of fans already exist.
Step 2 Run the emu del command to delete configurations of fans, and then remove and insert the fan
tray.
Step 3 Observe that the system automatically discovers and loads fans.
Step 4 Run the display emu command to confirm that configurations of fans already exist.
Step 5 Confirm that the fault occurs because certain fans support automatic loading and configurations
are generated automatically. The issued configurations of fans are invalid for faulty devices, but
the system can automatically configure fans. Thus, fans can work in the normal state.
----End

Service provisioning needs to be deployed according to fans of different types.

Module
Troubleshooting 8 FAQ
8 FAQ
About This Chapter
This topic provides principle-related and operation-related FAQs.

8.1 Operation-Related FAQ
This topic describes FAQs for operations such as query and configuration and provides detailed
answers.
8.2 Principle-Related FAQ
This topic provides FAQs for implementation principles and specifications of FTTx products to
help you know more about the products.

Module
8.1 Operation-Related FAQ

This topic describes FAQs for operations such as query and configuration and provides detailed
answers.
8.1.1 What Commands Does an OLT Have for Querying the Version
Question
What commands does an OLT have for querying the version?
Answer
1. When running the display patch all command, you can query the current version of the
system and the information about the running patch.
2. When running the display language command, you can query the version that is running
in the system, namely, the version of the active control board.
3. When running the display version frameid/slotid command, you can query the C-level
version and the board hardware version of the control boards.
8.1.2 How to Do If the Root Password of a Device Is Lost

Question
How to do if the root password of a device is lost?
Answer
After using the device, the user may change the default user name and password. If all the users
forget their password, resolve the problem by using the following method 1. If any other user
can log in to the device, resolve the problem by using the following method 2.
l Method 1: Load the empty database matched the device again. After restarting the device,
log in to the system by using the default root password admin(OLT) or mduadmin(MDU).
This method will lead to loss of data configurations and the user needs to configure the data
again.
l Method 2: If the device is managed by the NMS (Network Management Server), modify
the configuration file on the NMS as follows:
1. Back up the configuration file of the device on the NMS.
2. Open the configuration file and find out the record of changing the root password, as
shown in boldface in the following display.
[MA5600V800R005:
6833]
#
[global-
config]
<global-
config>
terminal user name buildrun_new lww231 *[)!AAYS*Y&aU86K;V-a@AUA!!* 1

Module
2009:06:04
:17:07:25 2009:06:04:17:07:25 root 2 6

-----
terminal user name buildrun_new bmsmpls *[4P]`OUIa%=[G]0U3=OWJY1!!* 0

2009:06:
08:15:01:02 2009:06:08:15:01:02 root 3 65535

-----
adsl mode switch-to

ADSL
vdsl mode switch-to normal
3. Delete the boldface part and then save the configuration file.
4. Load the modified configuration file to the system through the NMS and activate the
configuration file.
5. Log in to the device by using the default root password admin(OLT) or mduadmin
(MDU).
----End
8.1.3 How Does the MA5616 Automatically Cut Off the Power
Supplied to the Broadband Service Board When the Batteries Are
Used as Power Supply
Question
How does the MA5616 automatically cut off the power supplied to the broadband service board
when the batteries are used as power supply? How to use this function?
Answer
This function requires hardware support and the related commands need to be executed.
Hardware requirement: The PAIB board with the PMUA daughter board must be used.
The commands are executed as follows:
Step 1 Run the display emu command to query the environment monitoring unit (EMU) currently
configured on the MA561x.
Step 2 Run the emu add command to add the PMU as an EMU.
Step 3 Run the interface emu command to enter the PMU mode.
Step 4 Run the broad-service power-off shutdown command to enable the function of automatically
cutting off the power supply.
Step 5 Run the display power system parameter command to query and confirm that the function of
automatically cutting off the power supply is enabled. That is, Power-cut-close-Broad-
service is On.
Step 6 After the preceding commands are executed, if no mains supply is input, an external battery is
used for supplying power. In this case, the device automatically cuts off the power supplied to

Module
the broadband service board to enable the voice board works normally. This prolongs the backup
time of the battery.
----End
8.1.4 How to Configure Port Mirroring on the MA561x to Capture

Voice Packets
Question
How to configure port mirroring on the MA561x to capture voice packets?
Answer
Different versions may have different commands for capturing packets. Taking the
MA5616V800R307C01 as an example, the following configures port mirroring to capture
packets.
1. Configure the remote packet capture.

huawei(diagnose)%%remote-capture parameters record-switch enable server-ip
10.71.94.221 source-ip 192.168.1.168 start-record-num 1 stop-record-num 2 udp-
port 5000 vlan-tag 100
//10.71.94.221 is the IP address of the PC for packet capture and 192.168.1.168
is the media address of the ONU.
huawei(diagnose)%%
remote-capture trace frame/slot/port 0/3/1 auto-stop-time 400 0 base-trace
enable extend-trace enable
//frame/slot/port 0/3/1 is the corresponding PSTN port.
2. After packets are captured, run the following commands to disable the packet capture on
the board and the packet capture by port mirroring.
huawei(diagnose)%%undo remote-capture trace frame/slot/port 0/3/1
NOTE
Up to two ports can be configured for packet capture.
8.1.5 How to Query and Change the ARP Aging Time
Question
How to query and change the ARP aging time?
Answer
In the versions earlier than V800R006C02, the ARP aging time is fixed to 20 min and cannot
be queried or changed.
In V800R006C02 and the versions later than V800R006C02, the ARP aging time can be queried
and changed.
l Query the ARP aging time: display arp aging-time
l Change the ARP aging time: arp aging-time

Module
8.1.6 What Are Precautions for the ETHB When It Functions as the
Upstream Board of the MA5600T/MA5603T
Question
What are precautions for the ETHB when it functions as the upstream board of the MA5600T/
MA5603T?
Answer
The following operations are required when the ETHB functions as the upstream board:
Step 1 In the board mode, run the network-role uplink command to set the ETHB as the upstream
board. After this, isolation between the ETHB and other service boards is canceled.
Step 2 In the global config mode, run the undo isolate board command to cancel the port isolation of
the ETHB.
----End
8.1.7 How to Set the Port of the SCUB/SCUN as the Upstream Port
Question
Both SCUB and SCUN have four GE optical ports, which can function as upstream ports. How
to set the GE optical port of the control board (SCUB/SCUN) as upstream ports when upstream
transmission is not implemented by the GIU board?
Answer
Switching to the upstream port of the SCUB is controlled by the electronic switch. At a time,
only the upstream port of the GIU board or the port of the control board can be used for upstream
transmission.
CAUTION
In the case of the SCUB, make sure that the current configuration of the system is already saved
before running the electro-switch command. After this command is run, the system will be reset.
l To set the port of the control board as the upstream port, run the electro-switch 0
location-0 command.
l To set the port of the GIU board as the upstream port, run the electro-switch 0
location-1 command.
l The SCUN can work with the GIU upstream board. In this case, the SCUN equals an
upstream board in another GIU slot.

Module
8.1.8 How to Query Traffic of a Port on the MA5616
Question
How to query traffic of a port on the MA5616?
Answer
On current ONUs, you can query packet statistics of a port but cannot directly query traffic of
a port. To obtain traffic of a port, you can measure the number of frames received by the port in
a period of time as follows:
1. Query the number of frames received on a port at two different times by running the
following commands for different scenarios:
l On a GPON upstream port, run the interface gponnni command to enter the GPONNNI
mode, and then run the display gpon-port statistics command to query the number of
frames received on a port.
l On the other ports, run the display interface [ interface-type [ interface-number ] ]
command to query the number of frames received on a port.
2. Calculate the number of frames received by or transmitted from a port between the two
times: Number of frames measured the second time - Number of frames measured at the
first time.
3. Calculate traffic of a port: Number of frames x Bytes per frame.
For example, the number of frames are measured two times within 30s, and the number of frames
between these two times is: 85734 = 786687061 - 786601327. Assume that a frame is of about
1500 bytes. In this case, traffic of a port within 30s is about: 85734 x 1500 x 8= 1,028,808,000
bits. That is, 981 Mbits, 122.6 MB.
8.1.9 Can a Service Port of the MA5616 Be Activated or Deactivated
Question
Can a service port of the MA5616 be activated or deactivated?
Answer
In version V800R306, the service port cannot be activated or deactivated, but only the user port
can be activated and deactivated. For example, to deactivate ADSL port 0/1/0, do as follows:
MA5616(config-if-adsl-0/1)#deactivate
{ portid<0,63>|all<K> }:0
Command:
deactivate 0
In version V800R307, both the port and the service port can be deactivated. For example,
deactivate service port 31, do as follows:
MA5616(config)#service-port 31 adminstatus disable

Module
8.1.10 Whether Does the MA5616 Support Packet Capturing on the

Upstream Port Locally
Question
Whether does the MA5616 support packet capturing on the upstream port locally?
Answer
The MA5616 support capturing packets on the upstream port locally; however, only the packets
in one direction can be captured at a time. That is, the upstream and downstream packets cannot
be captured concurrently.
For example, the commands for capturing mirroring packets of the upstream port on the MA5616
(V800R306) are as follows:
MA5616(config)#acl 2000 //Create an ACL rule.
MA5616(config-acl-basic-2000)#rule permit //Permit all packets to pass the
port.
MA5616(config-acl-basic-2000)#quit
MA5616(config)#traffic-mirror
{ inbound<K>|outbound<K> }:outbound
{ ip-group<K>|link-group<K>|user-group<K> }:ip-group
{ integer<2000,3999> }:2000
{ link-group<K>|port<K>|rule<K> }:port 0/0/1 to port 0/0/0 //Mirror the
traffic transmitted from the upstream port to port 0/0/0.
8.1.11 How to Troubleshoot the Fault That When an MDU Is

Powered Off Its System Time Regresses to Year 2000
Question
When MDUs (MA5616 and MA562x series devices) from Huawei are powered off, their system
time regresses to year 2000. In this case, when a device generates an alarm, the time carried in
the alarm information is year 2000, which is inconvenient for troubleshooting. Then, how to
troubleshoot such a fault?
Answer
There are two methods:
l Method 1:
Upgrade the OLT version to V800R006 and upgrade the MDU version to V800R307 or
later versions. The MDU can synchronize the time of the OLT through the inband
management channel.
l Method 2:
Perform the following configurations for time synchronization by using NTP.
On the OLT, enable the NTP master clock.
OLT(config)#ntp-service refclock-master
On the MDU, synchronize the time of the OLT.

MDU(config)#ntp-service unicast-server 10.101.139.2

Module
8.1.12 How to Collect Traffic and Rate Statistics an ONT on the

MA5600T/MA5603T
Question
On the MA5600T/MA5603T of different commercial versions, how to collect traffic and rate
statistics of an ONT?
Answer
The following table lists the statistics collection modes and query commands supported by
different commercial versions of the MA5600T/MA5603T.
Statistics Query Command Version

Collection
Mode
Packets count of a display statistics vlan vlanid [ label inner- V800R005C33B

VLAN vlanid ] 118
V800R006C02S
PC100
V800R007C00
V800R007C01
V800R008C01
V800R008C02
V800R008C03
Volume of traffic display statistics service-port index V800R005C33B

streams 118
V800R006C02S
PC100
V800R007C00
V800R007C01
V800R008C01
V800R008C02
V800R008C03
ONT traffic display ont traffic portid ontid [ ontportid ] V800R006C02S

PC100
V800R007C00
V800R007C01
V800R008C01
V800R008C02
V800R008C03

Module
Statistics Query Command Version

Collection
Mode
Packets count of display statistics ont portid ontid V800R006C02S

an ONT PC100
V800R007C00
V800R007C01
Traffic and display statistics ont frameid/slotid portid ont-id V800R008C01

packets count of V800R008C02
an ONT
V800R008C03
Traffic of a PON display port traffic portid V800R007C00

port V800R007C01
V800R008C01
V800R008C02
V800R008C03
8.1.13 In What Conditions Can Multicast Packets Be Carried in the

PPPoE Mode on the MA5600T/MA5603T
Question
In what conditions can multicast packets be carried in the PPPoE mode on the MA5600T/
MA5603T?
Answer
The prerequisite is that the multicast server supports PPPoE-encapsulated multicast streams. In
addition, the MA5600T/MA5603T needs to be configured with parameters by performing the
following operations:
Step 1 Run the igmp mode snooping command to set the IGMP mode of the MA5600T/MA5603T to
snooping.
Step 2 Run the igmp report-proxy disable command to disable proxy of the IGMP report message of
the MA5600T/MA5603T.
Step 3 If the upper-layer device cannot identify the IGMP over PPPoE packet, run the igmp echo
enable command to enable the IGMP echo function. This is to duplicate the IGMP packet that
is encapsulated in the PPPoE mode to the standard Ethernet packet. Then multicast server sends
the Ethernet packet to the upper-layer device.
----End

Module
8.1.14 How to Train the ADSL/VDSL Modem Connected to the

MA5652G to Be a VDSL Modem
Question
If the ADSL/VDSL modem connected to the MA5652G needs to be trained to be a VDSL
modem, how to configure the VDSL service profile and channel profile?
Answer
The following methods describe how to train the ADSL/VDSL modem to be a VDSL modem.
l Method 1: Select the VDSL-related protocol G.993.2 (Annex A/B/C) for transmission
mode in the VDSL line profile.
l Method 2: Select the PTM mode for data path mode in the VDSL channel profile.
In the case of method 1, if the channel profile is set to both, the ADSL/VDSL modem may be
trained to be an ADSL mode when unstable factors such as line environment noise exist.
Therefore, if the ADSL/VDSL modem is connected to the MA5652G, method 2 is
recommended.
If the modem connected to the MA5652G is not an ADSL/VDSL modem, in configuring the
line profile and channel profile, set transmission mode to all and data path mode to both.
8.1.15 How to Configure DBA When GPBD and the OT928G Are
Used Together
Question
How to configure DBA when GPBD and the OT928G are used together? The version of the
OLT with GPBD is V800R007C00 and the version of the OG928G is V100R003C020.
Answer
When GPBD and the OT928G are used together, DBA configurations need to meet the following
requirements:
l The DBA bandwidth mode is minimum delay.

l The DBA bandwidth type is fixed, that is, type 1.
l The DBA minimum bandwidth is 37376 kbit/s.
l The bandwidth compensation is enabled.
In the maximum bandwidth mode, the OT928G has the following limitations:
l The E1 services are unavailable when there are more than six channels.
l The TDM service is unavailable.

Module
8.1.16 Why Is a Prompt Indicating That the Modified GEM Port

Mapping Index Is the Same as the Index of Another Mapping
Displayed
Question
In modifying gpon-lineprofile-300, the undo gem mapping 0 0 command is executed to delete
the mapping relation between the GEM port and ONT service and then the gem mapping 0 1
command is executed to set up mapping between the GEM port and ONT service; however, a
prompt indicating that the mapping index is the same as the index of another mapping is
displayed. Why does the preceding fault occur?
Answer
This is because parameter modification in the ONT line profile configuration mode takes effect
only after the commit command is executed. In the preceding question, after the undo gem
mapping 0 0 command is executed, the commit command is not executed; therefore, the delete
operation does not take effect. If the gem mapping 0 1 command is executed, a prompt indicating
that the mapping index is the same as the index of another mapping is displayed.
To rectify this fault, run the commit command after a configuration command is executed.
8.1.17 How to Load the Version of the Standby Control Board of the
MA5600T
Question
How to load the version of the standby control board of the MA5600T if the active control board
functions properly?
Answer
If one of the control boards of the MA5600T is faulty, the faulty control board needs to be
replaced. In replacement, the following scenarios may occur:
l For H801SCUN, there is no need to check the versions of control boards on the live network
or the version of the substitute control board. This is because the H801SCUN supports
duplicating of all information to the standby control board. No manual operation is required.
l For H801SCUB, H801SCUF, or H801SCUL,
– When the version of the original control board is earlier than V800R008C01, automatic
information duplication to the standby control board is supported if the version of the
substitute control board is V800R006C02 or later. No manual operation is required.
– When the version of the original control board is V800R008C01 or later, automatic
information duplication to the standby control board is supported if the version of the
substitute control board is V800R008C01 or later. No manual operation is required.
– When the version of the original control board is V800R008C01 or later, a patch is
required for the substitute control board to support automatic information duplication
to the standby control board if the version of the substitute control board is earlier than
V800R008C01. Related patches are as follows:

Module
– V800R006C02: SPC124 or a later patch

– When the version of the substitute control board is earlier than V800R006C02.
automatic information duplication to the standby control board is not supported.
Therefore, manually upgrade the substitute control board to the version of the control
board on the live network for information synchronization.
8.1.18 How to Troubleshoot the Fault That the NMS Displays that
the EMAC Chip of the MA5600T Board Is Faulty
Question
If the NMS displays that the EMAC chip of the MA5600T board is faulty, is the board hardware
or the chip faulty? How to troubleshoot such a fault?
Answer
If the MA5600T reports that the EMAC chip is faulty, it does not indicate that the board hardware
or chip is faulty.
Reset the board or remove and insert the board. If the fault is rectified, there is no need to replace
the board. If the fault persists, replace the board.
8.1.19 How to Disable the Check Performed by the HG8245 on the

Port Used by the SIP Proxy Server to Send SIP Packets
Question
By default, the HG8245 checks the port used by the SIP proxy server to send SIP packets. If the
port is different from that configured on the HG8245, the HG8245 discards packets. How can
this function be disabled?
Answer
Step 1 Export the XML configuration file from the HG8245.
Step 2 Change the value of parameter 212 to 0, as shown in Figure 8-1.
Figure 8-1 Modifying the configuration file

Module
Step 3 Import the modified XML configuration file to the HG8245.
----End
8.1.20 How to Use Storage Batteries to Ensure Normal Use of the

Broadband Service After Interruption of the Mains
Question
The MA5616 is powered by the H831PAIB board. After the mains is interrupted, the storage
batteries start to supply power. When the storage batteries supply power to the MA5616, the
broadband service is stopped by default and only the narrowband service is still provided. In
this way, the narrowband service can be used for a longer time. How can the broadband service
be normally used after the storage batteries supply the power to the MA5616?
Answer
Step 1 Query the EMU ID of the H831PMU that the H831PAIB is equipped with.
MA5616(config)#display emu { <cr>|
emuid<0,15> }:
Command: display emu EMU parameter

---------------------------------------------------------------------------- ID
Type State | ID Type State
---------------------------------------------------------------------------- 0
H831VESC Normal | 1 FAN Normal 2 H831PMU
Normal | 3 - -
Step 2 Disable the function that stops the broadband service so that the broadband service is not
interrupted when the MA5616 is powered by the storage batteries upon interruption of the mains.
MA5616(config)#interface emu 2 MA5616(config-if-h831pmu-2)#undo broad-service
power-off shutdown
NOTE
1. To run the preceding command successfully, the DSP subboard and the voice service board must exist.
2. Run the command and save the modified data before the mains is interrupted. In this way, configuration
of the function takes effect when the mains is interrupted. If the command is executed after the mains
is interrupted, the modification succeeds, but configuration of the function does not take effect.
----End
8.2 Principle-Related FAQ

This topic provides FAQs for implementation principles and specifications of FTTx products to
help you know more about the products.
8.2.1 Why P2P Download Leads to Low ADSL Rate
Question
In an Internet cafe using the ADSL service, if a user uses the P2P software for downloading or
uploading with the very light traffic, the Internet access rate of the entire Internet cafe will be

Module
slow. If the Internet cafe uses the FTTx+LAN mode for Internet access, the Internet access rate
is not that slow. Why do these two problems happen?
Answer
This is because the upstream ADSL rate and the downstream ADSL rate are asymmetric.
Generally, the ADSL upstream bandwidth is low. In addition, downloading and uploading are
performed simultaneously through the P2P software. In this case, the upstream bandwidth is
congested but the downstream bandwidth is sufficient. Therefore, the P2P communication
packets sent from the ADSL end cannot be exchanged successfully. This leads to low
downstream rate.
If the FTTx+LAN mode is used, the upstream and downstream bandwidths are the same; thus,
congestion does not occur in the upstream direction and the above-mentioned fault does not
occur.
8.2.2 How Is the VoIP Service Implemented on the MA5600T by

Setting the electronic Switch
Question
The MA5600T can be configured with the VoIP service board (such as the ASRB board) to
implement the VoIP service. How is the VoIP service implemented on the MA5600T by setting
the electronic switch?
Answer
The MA5600T supports the VoIP service only when the electronic switch is already switched
to the VoIP daughter board. By default, the MA5600T does not support the VoIP service.
Since V800R005, the VoIP service has been supported.
The MA5600T provides the following two electronic switches:

l Electronic switch 0: Used for determining whether the port on the control board or the port
on the upstream interface board of the MA5600T is used for upstream transmission.
– If the electronic switch is on location-0, it indicates that the control board is used for
upstream transmission.
– If the electronic switch is on location-1, it indicates that the upstream interface board is
used for upstream transmission.
– By default, electronic switch 0 is on location-0.
l Electronic switch 1: Used for determining whether the MA5600T supports the VoIP service
or supports upstream transmission through port 0/20/3.
– If the electronic switch is on location-0, it indicates that the electronic switch is switched
to the VoIP daughter board and thus supporting the VoIP service.
– If the electronic switch is on location-1, it indicates that the electronic switch is switched
to port 0/20/3. Then, port 0/20/3 serves as the upstream port.
– By default, electronic switch 1 is on location-1, indicating that the VoIP service is not
supported.

Module
NOTE
l The SCUL control board does not support the VoIP service and does not provide the upstream port; thus,
services are upstream transmitted by only the upstream interface board.
l The SCUL control board does not support the electronic switch
8.2.3 Which Cabinets Are Used for the 21-inch ETSI Subrack and
the 19-inch IEC Subrack
Question
Which cabinets are used for the 21-inch ETSI subrack and the 19-inch IEC subrack?
Answer
The 21-inch ETSI subrack and the 19-inch IEC subrack are of different dimensions and are
installed in the cabinets of different dimensions.
l The 21-inch ETSI subrack is installed in the ETSI cabinet (N63E).
l The 19-inch IEC subrack is installed in the 19-inch standard cabinet (N66).
8.2.4 What Are the Functions of the HiGig Interface on the ETHB
Board
Question
What are the functions of the HiGig interface on the ETHB board?
Answer
The HiGig interface provides a communication channel for two adjacent ETHB boards to
implement binding of two adjacent ETHB boards. Two adjacent ETHB boards can implement
load sharing and redundant protection only after they are bound together.
Because MABA, MABC.VER A, and MABH.VER B backplanes do not provide the HiGig
interface, the ETHB board provides such an interface on the front panel. The HiGig interfaces
of two ETHB boards are connected by using an external mini SAS high-speed cable. In this way,
the two ETHB boards can communicate with each other. To set two ETHB boards to be in a
protect group or to implement load sharing between two ETHB boards, connect their HiGig
interfaces.
The MABC.VER B and MABH.VER C backplanes provide the HiGig interface. Therefore, two
adjacent ETHB boards can communicate with each other through the backplane directly and
they can implement binding without external mini SAS high-speed cables.
8.2.5 What Are the Relations Between the Delay Caused by DBA
Rate Limitation and the Size of User Packets
Question
What are the relations between the delay for processing packets and the size of user packets in
an FTTH network where only DBA rate limitation is adopted?

Module
Answer
In general, if the size of user packets is fixed, the delay is the smaller when the DBA bandwidth
is higher; if the DBA bandwidth is fixed, the delay is the longer when the size of user packets
is larger. The following section uses an example to describe it:
l The highest DBA bandwidth is presumed to be 1024 kbit/s and the size of user packets
1024 bytes. Because the size of GPON frames is fixed to 125 us, the size of the GPON
frames that can be transmitted through a T-CONT is 16 bytes (1024 kbit/s x 0.000125s/8
bit = 16 bytes). As described in the GPON protocol, each GEM frame is 5 bytes long, so
the size of actually transmitted Ethernet packets is 11 bytes.
l The size of user packets is 1024 bytes, which will be transmitted for 94 times (1024/11=94)
with a delay 11750 us (94 x 125 us = 11750 us). DBA jitter usually exists in actual networks,
so the size of the packets that can be transmitted each time may be shorter than 11 bytes
and the transmission of all packets can be completed only after 95 times; the delay is 11875
us (11750 us + 125 us = 11875 us).
8.2.6 Whether the DC Power Board PDIA of the MA5616/MA5610

Supports Reporting an Alarm In Case of Power-off
Question
The AC power board PAIA of the MA5616/MA5610 supports reporting an alarm in case of
power-off, whether does the DC power board PADI support such a function?
Answer
The DC power board PADI of the MA5616/MA5610 supports reporting the dying-gasp alarm,
but does not report the alarm in case of power-off due to certain causes. After 220 V AC mains
supply is converted into -48 V DC power by the 4820, it is input into the PDIA power board to
supply power for the control board.
l If the input of 220 V mains supply is cut, it is less probable for the PDIA power board to
report an alarm in case of power-off.
l If the 4820 power supply is faulty, that is, if the input of -48 V DC power is cut, the PDIA
power board will report an alarm.
The power of the power system is large, but its load (the MA5616/MA5610) consumes little
power. After 220 V AC mains supply is cut, the waveform of the lower -48 V DC power is
slowly dropped drown. The MA5616/MA5610 reports the dying gasp alarm only after the
voltage drops to lower than -42V. At this moment, however, all the system power for reporting
the dying gasp alarm is almost consumed, causing a failure in reporting the dying gasp alarm.
8.2.7 How Long Will the MA5600T/MA5603T Report the LOS Alarm
After Its PON Port Does Not Receive Any Optical Signals
Question
How long will the MA5600T/MA5603T report the LOS alarm after its PON port does not receive
any optical signals?

Module
Answer
According to the protocol, the OLT regards itself having failed to receive optical signals after
it fails to detect any optical signals for consecutive four frames, and then the OLT sets the status
of the PON port to down. The upstream optical frequency of the ONU is 8000 frame/s, and 0.5
ms for four frames, so the MA5600T/MA5603T reports the LOS alarm 0.5 ms after its PON
port does not receive any optical signals.
As described in the protocol, LOS Loss of Signal The OLT did not receive any expected
transmissions in the upstream (complete PON failure) for 4 consecutive frames.
8.2.8 Whether Certain Boards Can Be Used on Both the MA5616 and
the MA5610
Question
Whether certain boards can be used on both the MA5616 and the MA5610?
Answer
Certain boards can be used on both the MA5616 and the MA5610. For details about such boards,
see the following:
l Control board: The MA5616 uses the CCUB board as its control board but the MA5610
uses the CCUA board. The CCUB and the CCUA, however, can use the same upstream
interface board, EP1A.
l Service board: Narrowband service boards ASRB and ASPB can be used on both the
MA5616 and the MA5610. 16-channel Ethernet access board EIUA can be used on only
the MA5610, and xDSL boards ADLE and VDGE can be used on only the MA5616.
l Power board: Power boards PDIA, PAIA, and PAIB can be used on both the MA5616 and
the MA5610.
l Fan board: The FCBA fan board can be used on both the MA5616 and the MA5610.
8.2.9 How Long Will the SIP Interface of the MA5616 Be Registered
Again After the SIP Interface Is Disconnected
Question
How long will the SIP interface of the MA5616 be registered again after the SIP interface is
disconnected?
Answer
If the SIP interface is normal, it sends the options message every 5s.
If the SIP interface is faulty, it sends the options message every 10s. If the SIP interface receives
message 200 (responded to the options message) sent by the IMS six times consecutively, the
SIP interface changes from the faulty state to the normal state. Then, the interface initiates the
register message.

Module
8.2.10 What Are the Limitations for Configuring Link Aggregation

and Protection on the ETHA, ETHB, and GIU Boards
Question
What are the limitations for configuring link aggregation and protection on the ETHA, ETHB,
and GIU boards?
Answer
The ETHA board supports only intra-board aggregation groups and protect groups, but does not
support inter-board aggregation groups or protect groups. In addition, the ETHA board can be
used for cascading but not for upstream transmission.
The ETHB and GIU boards support both intra-board aggregation groups and protect groups, and
inter-board aggregation groups and protect groups. Inter-board aggregation groups and protect
groups can be set up only between the ports on the boards of the same type. For example, a port
on the ETHB board and a port on the GIU board cannot form an inter-board aggregation group.
When setting up an aggregation group or protect group, pay attention to the following points:
l A port can be directly added to a protect group. Or, it can be added to an aggregation group
and then to a protect group. A port that has been added to a protect group, however, cannot
be added to an aggregation group.
l Switching is of low efficiency between the ports that are in a protect group only, but
switching is highly efficient between the ports that are both in an aggregation group and in
a protect group. In this case, it is recommended that you add ports to an aggregation group
and then to a protect group. This shortens service interruption.
l Ports that have been added to an LACP aggregation group cannot be added to a protect
group. If such ports need to be added to a protect group, they need to be added to an
aggregation group manually first.
8.2.11 Why Does the H831VESC EMU of MA562x V800R307 Fail to

Be Deleted
Question
When an operator tries to delete the H831VESC EMU from MA562x V800R307, a message is
displayed indicating that the delete operation fails. Why does the H831VESC EMU fail to be
deleted?
huawei(config)#display emu
{ <cr>|emuid<0,15> }:
Command:
display emu
EMU parameter
----------------------------------------------------------------------------
ID Type State | ID Type State
----------------------------------------------------------------------------
0 H831VESC Normal | 1 - -
2 - - | 3 - -
4 - - | 5 - -
6 - - | 7 - -
8 - - | 9 - -
10 - - | 11 - -

Module
12 - - | 13 - -
14 - - | 15 - -
----------------------------------------------------------------------------
huawei(config)#emu del
{ emuid<0,15> }:0
Command:
emu del 0
Failure: Virtual ESC does not support this operation
Answer
H831VESC provides a series of built-in environment monitoring functions (such as temperature
monitoring); therefore, it cannot be deleted.
8.2.12 What Are the Differences Between Options always-on and

once-on in the Password Authentication of an ONU
Question
What are the differences between options always-on and once-on in the password authentication
of an ONU?
Answer
always-on: If this option is selected, an ONU is authenticated in the password mode before it
goes online each time, and the MAC address/SN parameter is not required in ONU registration.
After the ONU is authenticated, you can modify its SN or MAC address.
once-on: If this option is selected, an ONU is authenticated in the password mode within a
specified period before it goes online for the first time. After successful authentication, the ONU
is bound to the MAC address/SN. Thus, the ONU is authenticated by MAC address/SN but not
by password next time it goes online. After the ONU is authenticated, you cannot modify its SN
or MAC address.
8.2.13 Can Multicast Duplication Be Concurrently Achieved on the

OLT and BRAS
Question
Can multicast duplication be concurrently achieved on the OLT and BRAS?
Answer
The multicast duplication can be concurrently achieved on the OLT and BRAS. On the OLT,
when the IGMP proxy is enabled, the session duplication function can be configured on the
BRAS. These two functions do not conflict with each other.

Module
8.2.14 Why Does the Multicast Packet Sent by the Port (with Native
VLAN) of the HG866 Carry the VLAN
Question
Why does the multicast packet sent by the port (with native VLAN) of the HG866 still carry the
VLAN?
Answer
The HG866 and other ONTs have different ways to implement the multicast service. Multicast
protocol packets and multicast streams are isolated, and the native VLAN of the HG866 port
takes effect only for the multicast protocol packets. By default, the ONT multicast forwarding
mode in the ONT service profile is multicast-forward unconcern. Therefore, multicast streams
are forwarded with tags.
You can remove tags in multicast streams by running the multicast-forward untag command
to modify the Srvprofile mode of the ONT service profile to untag.
8.2.15 What Is the Relationship Between the LOF and LOS Alarms
Question
How to detect LOF and LOS alarms and what is the relationship between these two alarms?
What alarm is generated if optical fibers are removed when the MA5606T or MA5652G serves
as an ONU?
Answer
LOF indicates loss of frame. When such an alarm is generated, the ONU can receive optical
signals. LOS indicates loss of signal. When such an alarm is generated, the ONU fails to receive
optical signals. The mechanisms of detecting LOFi and LOSi alarms are as follows:
l LOFi: If four consecutive frames of an OLT fail to locate an upstream frame of an ONU,
the LOFi alarm is generated and the ONU goes offline.
l LOSi: If four consecutive frames of an OLT fail to receive an upstream optical signal of
an ONU, the LOFi alarm is generated and the ONU goes offline.
The relationship between the LOF and LOS alarms is as follows:
l Use an optical attenuator to test the ATM 155/622 Mbit/s optical port and increase the
attenuation gradually. It is found that the alarm status changes as follows: normal -> SD -
> LOF -> LOS. This indicates that after LOF is generated, if the attenuation is increased
further, no optical signal is received and LOS is generated. If an optical fiber is removed,
LOF may be generated first and then LOS, which is related to the alarm detection
mechanism. The LOSi, LOFi, and LCDGi alarms are detected in the time window mode.
In the first several detections, if the time window detects the threshold for frame losing,
the LOFi alarm will be generated.
l If the PON line generates an LOF alarm, LOS will not be generated. This is because the
PON port uses the time division system. If an LOF alarm is generated, the ONT goes offline
and then the OLT does not assign the timeslot (bandwidth) to the ONU. Therefore, the OLT

Module
does not detect whether the ONT transmits upstream optical signals and an LOS alarm is
not generated.
l If LOS is generated, LOF/SD will be suppressed. This is because LOS is the alarm of the
highest severity.
When the MA5606T and MA5652G serve as an ONU and the optical patch is normal, LOS is
generated when an optical fiber is removed.
8.2.16 What Is the Difference Between the loghost add and file-
server Commands
Question
What is the difference between the loghost add and file-server commands that are used for
configuring the log server?
Answer
The loghost add command is implemented according to the standard protocol. It is used for
recording system operation logs and running information. Generally, it is used in the Linux
operating system (OS).
The file-server command is implemented according to the Huawei internal protocol. It is used
for configuring the information about the active/standby servers for automatically backing up
or loading files, and implementing backup of board software, logs, and configuration files.
Generally, it is used in the Windows OS and Solaris OS.
8.2.17 Can a Switch Be Cascaded to an OPFA Board

Question
What is the network topology for an OPFA board? Can a switch be cascaded to an OPFA board?
Answer
An OPFA board is a 16-port FE optical service board. It supports 16 optical ports for providing
the fiber to the home (FTTH) service for users. OPFA supports only P2P access, that is, a PC is
connected to an OPFA board using an optical modem.
An OPFA board can neither cascade an optical switch using an optical port nor cascade a device.
However, it can cascade a small-capacity switch using an optical modem and it supports
transparent transmission of eight VLANs.
8.2.18 How to Forward Voice Media Streams of an MDU

Question
How to forward voice media streams of an MDU?
Answer
The voice media streams of an MDU can be forwarded in the following two processes:

Module
l The process the same as the process of forwarding IP packets: Locate the routing table. For
a direct route, request the MAC address corresponding to the peer IP address and then
forward voice media streams using Layer 2 switching (requiring ARP proxy supported by
the OLT or gateway). For an indirect route, request the MAC address corresponding to the
next hop IP address using ARP and then forward voice media streams using Layer 3 routing.
l The process of external forwarding: Query the media gateway in the VoIP configurations,
request the MAC address corresponding to the IP address of the media gateway using ARP
and then use this MAC address as the destination MAC address for forwarding media
streams. Then, transmit voice media streams to the media gateway regardless of the type
(direct or indirect) of a route and then forward voice media streams using Layer 3 routing.
Currently, only the MA5635 uses the external forwarding process by default and the other MDUs
use the process the same as the process of forwarding IP packets.
8.2.19 How to Capture SIP and H.248 Signaling of the HG824x
Question
How to capture SIP and H.248 signaling of the HG824x?
Answer
Step 1 Telnet the ONT.
l IP address of the ONT: 192.168.100.1/24
l User name: root
l Password: admin
Step 2 Run the following command to check the status of the MG interface.
WAP>vspa display mg if state
Step 3 Run the following commands to check the status of the POTS users.
WAP>vspa display user status port 0
WAP>vspa display user status port 1
Step 4 Run the following commands to print the received and transmitted signaling.
WAP>set dbgoutput outputtype all swt 1
WAP>vspa debug module 201 cmd 2 subcmd 1
----End
8.2.20 Why Is a Message Prompting You to Change Time Displayed

When You Log In to an MDU
Question
Why is a message prompting you to change time displayed when you log in to an MDU? The
displayed message is as follows:
The current system time is: 2010-05-20 17:16:34
Are you sure to modify system time? (y/n)[n]:

Module
Answer
A message prompting you to change time is displayed only when the following conditions are
meet.
l The network time protocol (NTP) function is disabled.

l You log in to the equipment for the first time after the equipment is powered off and reset.
8.2.21 How to Limit POTS Calls If the Maximum Power of the

MA5616 Exceeds 200 W
Question
How to limit POTS calls if the maximum power of the MA5616 exceeds 200 W?
Answer
l If no user picks up the phone, a loop is not generated and ports do not generate power. In
addition, the power of voice boards is about 6 W when no user picks up the phone.
l If a user picks up the phone, a local loop is generated and 1.9 W power is generated.
l If 73 users pick up phones concurrently, about 139 W power is generated. With the power
of power boards, control boards, voice boards, and the fan tray, the power of the system
exceeds 200 W. In this case, if one more user picks up the phone, the system is overloaded.
If a user hangs up the phone, another user can picks up the phone. Then, there are still 73
users pick up phones concurrently. Therefore, the system is overloaded and POTS call are
limited.
8.2.22 Can -48 V Power Supply Be Used When the MA5616 Uses the
PAIB Power Board
Question
Can -48 V power supply be used when the MA5616 uses the PAIB power board?
Answer
The -48 V power supply cannot be used when the MA5616 uses the PAIB power board.
PAIB is an AC input power board and uses AC power supply by default. Its DC terminal is
connected to -48 V battery. PAIB is installed with a relay for protecting the battery and the relay
turns on the circuit to the -48 V battery for power supply only when the mains supply fails. In
this case, if PAIB of the MA5616 requires DC power supply, mains supply must be connected
and then powered off. If the mains cannot be connected, PAIB must be replaced with PDIA.
8.2.23 What Is the MDU's Forwarding Mechanism for the Voice

Media Stream?
Question
What is the MDU's (except the MA5606T) forwarding mechanism for the voice media stream?

Module
Answer
The MDU's voice media stream can be forwarded in the following two modes: internal
forwarding (default) and external forwarding. The current forwarding mode of a device can be
queried by running the following command.
huawei(config)#display system parameters 5
-----------------------------------------------------------------------------
Parameter index: 5 Value: 0
Indication: the media stream forwarding mode within the same device. 0: device
internal forwarding; 1: device external forwarding.
-----------------------------------------------------------------------------
An MDU forwards voice media streams as follows:

1. When a phone connected to the local MDU makes calls with a phone connected to the peer
MDU, the IP address and the port ID of the peer gateway can be obtained by signaling
interaction. The source IP address in the IP address header of the media packet is the media
IP address of the port on the local MDU (see the following media IP address configuration
command), the destination IP address is the IP address of the peer-end MGC, and the source
MAC address in the Ethernet header of the media packet is the bridge MAC address of the
local MDU.
<h248-0>
if-h248 attribute mg-media-ip1 10.144.79.20
2. The destination MAC address can be obtained in two ways: by using the destination IP
address, or by using the MGC. Only when the IP addresses of local MDU and peer media
gateway are in the same network segment in the internal forwarding mode, the destination
MAC address is learned by using the destination IP address. Otherwise, the destination
MAC address is learned by using the MGC.
3. The MAC address is searched in the ARP entries based on the index of the IP address.
l If the MAC address is found, it is returned directly.
l If the MAC address is not found, the routing table is searched based on the IP address.
– When a direct route (see the second entry in the following routing table) is found,
the ARP is triggered to request the MAC address corresponding to the IP address.
– When a network segment route (see the first entry in the routing table) is found, then
the next hop is found by using the routing table. If the ARP entries corresponding
to the next hop exist, the MAC address corresponding to the next hop is returned.
Otherwise, the ARP is triggered to learn the MAC address corresponding to the next
hop.
huawei(config)#display ip routing-table
Command:
display ip routing-table
Route FlMDUs: R - relay, D - download to fib, DC - DHCP Client
---------------------------------------------------------------------------
---
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost FlMDUs NextHop Interface
0.0.0.0/0 Static 60 0 RD 10.144.78.1 vlanif200
10.144.78.0/23 Direct 0 0 D 10.144.79.20 vlanif200
10.144.79.20/32 Direct 0 0 D 127.0.0.1 InLoopBack0

Module
8.2.24 Routes Supported by the HG824x Series ONT
Question
What type of routes are supported by the HG824x series ONT? How does each type of routes
work?
Answer
Currently, the HG824x series ONT supports the following types of routes:
l Policy route: The egress of packets is determined based on the ingress, source IP address,
and IPTOS of the packets. Currently, the ONT supports the ingress- and source IP address-
based policy routes. These routes can be configured by using the NMS or web page.
– The ingress-based policy route can be used for the Internet access service. The route
can be configured by binding the WAN port to the LAN port of the ONT. After the
Layer 3 LAN port is bound to a WAN port, all packets that are routed into the ONT
through this LAN port are routed out of the ONT through the WAN port that is bound
to the LAN port.
– The source IP address-based policy route is used for the voice service and TR-069
service by default. After the voice WAN port and TR-069 WAN port obtain the IP
address, the source IP address-based policy route is automatically configured on the
ONT. If the source IP address in a packet is the IP address of the voice WAN port, the
packet is forwarded to this WAN port. If the source IP address in a packet is the IP
address of the TR-069 WAN port, the packet is forwarded to this WAN port.
l Static route: The network administrator manually configures the routing information by
using the NMS or web page. The WAN port of the ONT on the route is specified based on
the source IP address of packets.
l Default route: After the ONT fails to find a policy route or static route after receiving
packets, the ONT forwards the packets through the WAN port specified by the default route.
The default route can be configured by using the NMS or web page.
The HG824x series ONT always selects a route with a higher preference. Among the three types
of routes, the preference of the policy route is the highest and the preference of the default route
is the lowest.
8.2.25 How to Implement Interworking Between Four FE Ports of

the HG824x
Question
How can the four FE ports of the HG824x interwork with each other?
Answer
l When the four FE ports work in Layer 2 mode, Layer 2 FE ports process packets based on
the VLANs configured on the LSW. Packets are broadcast in the same VLAN and
forwarded based on the MAC address.
l When the four FE ports work in Layer 3 mode, packets of the Layer 3 FE ports are processed
by the CPU. The four FE ports can interwork with each other when the IP addresses of the
four ports are in the same network segment.

Module
8.2.26 Whether the GE Optical Ports of the Main Control Boards on

the MA562x Series Support Link Convergence
Question
Do the GE optical ports of the main control boards on the MA562x series support link
convergence?
Answer
l The MA562x V800R307C00 supports two GE optical port subboards, but only one GE
optical port can be displayed. In addition, the MA562x V800R307C00 does not support
convergence of uplink port links on the main control board.
l The MA562x V800R307C01 or a later version supports two GE optical port subboards and
also convergence of uplink port links on the main control board.
l The MA562x series of all versions do not support link convergence on the ETH service
ports.
8.2.27 Default IGMP Packet Processing Mode of the MDU

Question
How does the MDU process IGMP packets by default?
Answer
l For the MDU V800R305, the IGMP packet processing mode is configured in BTV mode.
By default, the IGMP packet processing mode is set to snooping. That is, an IGMP packet
is captured to the CPU by default. If the corresponding port is not added to the MVLAN,
the system discards the IGMP packet.
In BTV mode, you can run the display igmp config global command to view the
configuration status of the IGMP packet processing mode.
l For the MDU V800R306 or a later version, the IGMP packet processing mode of the MDU
V800R305 is configured in MVLAN mode. By default, no MVLAN exists. That is, IGMP
packets are not captured to the CPU. When an MVLAN is created, the default IGMP packet
processing mode is off.
In MVLAN mode, you can run the display igmp config vlan command to view the
configuration status of the IGMP packet processing mode.

Troubleshooting (V800R010C00 01)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Troubleshooting (V800R010C00 01)

Hochgeladen von

Copyright:

Verfügbare Formate

SmartAX MA5600T/MA5603T Multi-service Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-24) Huawei Proprietary and Confidential i

About This Document

Indicates a hazard with a high level of risk which, if not

Indicates a hazard with a medium or low level of risk which,

Indicates a potentially hazardous situation that, if not

Indicates a tip that may help you solve a problem or save

Provides additional information to emphasize or

Issue 01 (2011-10-24) Huawei Proprietary and Confidential ii

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in square brackets [ ] are

{ x | y | ... } Alternative items are grouped in braces and separated by

[ x | y | ... ] Optional alternative items are grouped in square brackets

{ x | y | ... } * Alternative items are grouped in braces and separated by

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

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

Updates in Issue 01 (2011-10-24)

The following information is added:

l 2.3.4.8 Unexpected Communication Interruptions

The following information is modified:

l 2.2.1.3 Low Internet Access Rate

Issue 01 (2011-10-24) Huawei Proprietary and Confidential iii

l 2.2.3.6 Failure to Dial Certain Phone Numbers

Issue 01 (2011-10-24) Huawei Proprietary and Confidential iv

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

2 Troubleshooting the FTTx GPON Service...............................................................................9

Issue 01 (2011-10-24) Huawei Proprietary and Confidential v

2.2.2.2 Blank Screen After a Program Is Ordered......................................................................................74

3 Troubleshooting the xDSL Services......................................................................................228

Issue 01 (2011-10-24) Huawei Proprietary and Confidential vi

3.1 Troubleshooting the Internet Access Service.................................................................................................229

4 Troubleshooting the System...................................................................................................273

6 Commonly Used Methods of Fault Locating and Troubleshooting................................286

Issue 01 (2011-10-24) Huawei Proprietary and Confidential vii

6.2.2.1 Querying ONT Information..........................................................................................................317

Issue 01 (2011-10-24) Huawei Proprietary and Confidential viii

7.1.5 ONU Frequently Goes Online and Offline............................................................................................361

Issue 01 (2011-10-24) Huawei Proprietary and Confidential ix

Issue 01 (2011-10-24) Huawei Proprietary and Confidential x

Issue 01 (2011-10-24) Huawei Proprietary and Confidential xi

Issue 01 (2011-10-24) Huawei Proprietary and Confidential xii

Issue 01 (2011-10-24) Huawei Proprietary and Confidential xiii

Issue 01 (2011-10-24) Huawei Proprietary and Confidential xiv

Issue 01 (2011-10-24) Huawei Proprietary and Confidential xv

1 Maintenance Engineers' Must-Read

About This Chapter

1.1 Skill Requirements

Issue 01 (2011-10-24) Huawei Proprietary and Confidential 1

1.1 Skill Requirements

Maintenance engineers need to master the following:

1. Basics of communications technologies

1.2 Troubleshooting Precautions

For maintenance engineers, they should:

Issue 01 (2011-10-24) Huawei Proprietary and Confidential 2

1.3 Troubleshooting Procedure

Issue 01 (2011-10-24) Huawei Proprietary and Confidential 3

Figure 1-1 Flowchart for troubleshooting the common faults

Collect and record fault

Can the fault No