Access Network Product Training Technical Cases

Access Network Product

Training Technical Cases

2013
 Access Network Product Training Technical Cases

Table of Contents

Table of Contents .............................................................................................................................. 2

PON Access MA5600T Troubleshooting Cases ............................................................................... 4
1. The AC power off alarm occured on MA5600T because the power distribution frame
faulty ......................................................................................................................................... 4
2. VOD service is not normal after some while because of being unknow unicast .............. 5
3. Multicast packet with TTL 1 causing the multicast user can not watch program ............. 6
4. High CPU occupancy cause ONT cannot be autofind ...................................................... 6
5. IGMP mode snooping cause CPU utilization high lead to IPTV freezing ........................ 7
6. PW down in MA5600T but up on the remote peer side due to Router didn't enable LDP8
7. Impossible to add MA5600T equipment due to MAC address conflict............................ 9
8. Mismatched overhead between MA5600T and OSN3500 caused mistiming of STM-1
stream ...................................................................................................................................... 11
9. STB cannot get IP address due to service port not enable DHCP option 82 ................... 15
10. MA5612 is intermittent down due to the fiber connector is not clear............................. 16
11. Services are interrupted for 5 minutes after an active/standby switchover because the
MAC address aging time is too long ....................................................................................... 17
12. GPON access network, illegal rogue ONT, it means that this ONT is broken................ 18
13. Why when we reboot ONT, the BIP error increase (FAQ) ............................................. 21
14. Data failed to be backed up after packets are forcibly sent from a VLAN interface ...... 22
PON Terminal Troubleshooting Cases ............................................................................................ 23
15. Improper value of priority-queue lead to ONT config state failed ................................. 23
16. User failed to get IPTV services due to non-standard FE cable between STB and ONT24
17. Wrong digital map configuration leads to call fail .......................................................... 26
18. Error Digitmap Match mode causes HG8245 VOIP fail ................................................ 26
MSAN UA5000 Troubleshooting cases .......................................................................................... 27
19. Troubleshooting of Reverse Polarity .............................................................................. 27
20. POS Transaction failed due to Missing Configuration in Softswitch and Terminal leads
Malfunction of UA5000 Line.................................................................................................. 29
21. UA5000 ISDN data service fails due to incorrect ptime on E company UMG .............. 31
22. VOIP call Fail due to interconnection problem between master and extended UA5000
fram 33
23. Synchronization failure on SDLE boards due to misconfiguration of the SHDSL modem
34
24. EPMU raised an ACinput Air Switch Alarm due to Wrong Logical Information Sent by
Power4875L to UA5000 ......................................................................................................... 36
DSLAM SmartAX MA5600 Troubleshooting Cases ...................................................................... 40
25. MA5600 failed to be provisioned by OSS due to inconsistency in Software Version of
Active & Standby SCUB Boards ............................................................................................ 40
26. Some PPPoE users cannot access the internet due to problem in the negotiation type... 42
HUAWEI Confidential
 Access Network Product Training Technical Cases

27. Abnormal ADSL Service due to traffic replication between PORTS in MA5600 .......... 43
28. How to collect lastword in BIOS mode in order to troubleshoot MA5600 SCU keeps
rebooting in BIOS mode issues（FAQ） ............................................................................... 45
29. PPPoE users go offline after going online for 2-5 minutes due to old modem firmware47
30. VOIP doesn't work because of wrong configuration of DHCP mode ............................. 47
31. Subscriber line connection problem affect quality of internet and IPTV service ........... 48
32. Interruption of Broadband Services (HSI & IPTV) due to ADSL sync instability
between CPE & DSLAM ........................................................................................................ 49
MSAN SmartAX MA5600T Troubleshooting Cases ...................................................................... 50
33. Poor Internet ADSL service due to unknown unicast packets storm from uplink port ... 50
34. The MA5600T not detected any multicast flow of IGMP program because uplink port
not configured IGMP .............................................................................................................. 52
iManager NMS Troubleshooting Cases .......................................................................................... 53
35. Unable to telnet sites via n2000 client ............................................................................ 53
36. OSS failed to get alarms from N2000 BMS server due to No more free space for the
Data and log of the IPMS database ......................................................................................... 54
37. ATU-R terminal managment menu is not displayed on BMS GUI due to it is hidden ... 56
38. Fail to synchronize ADSL port ALIAS in U2000 with description in MA5600T due to
default value off in Sybase DB ............................................................................................... 57
39. U2000 script importing ceased due to inadequate SDH instances .................................. 59
40. The problem of the arithmetic of the node and link sequence leads the SDH Node
Insection Failed Issue .............................................................................................................. 59
41. Failure to Modify Trails for Metro 500 and Metro 1000 due to not supporting Time
Division Mode ........................................................................................................................ 61
42. Alarm overflow dump function set as a high value caused U2000 system hard disk
usage to high ........................................................................................................................... 62
43. SNMP-NBI Connectivity towards 3rd Party Server or Terminal.................................... 64
44. On remote scenario, you can use U2000 ping, but cannot use command lines to ping .. 66

HUAWEI Confidential
 Access Network Product Training Technical Cases

PON Access MA5600T Troubleshooting Cases

1. The AC power off alarm occured on MA5600T because the power distribution

frame faulty

【Symptom】
Power system model: EPS75-4815AF
Customer reported the AC power off Alarm occured on MA5600T system
【Alarm Information】
ALARM 912 FAULT MAJOR 0x15411012 ENVIRONMENTAL 2012-02-29 10:39:04+08:00
ALARM NAME : The AC power is off
PARAMETERS : FrameID: 0 EMU ID: 1 Power ID: 0 EMU Type:
Pwr4875L Power Type: Power 4875L
DESCRIPTION : The AC power is off, causing battery supply or device
power-off(digital parameter monitor)
CAUSE : No Mains
ADVICE : Check if the Mains is OK
--- END
【Cause Analysis】
1) Incorrect configuration on system for power system
2) Incorrect DIP switch setting on EMU
3) No incoming power from the site
4) Power distibution frame fautly
【Handling Process】
1) Checked on the system configuration is correct.
KRT_V1058(config)#display emu 1
EMU ID: 1
----------------------------------------------------------------------------
EMU name : KRT_V1058
EMU type : Pwr4875L
Used or not : Used
EMU state : Fault / config
Frame ID :0
Subnode :0
2) Check in the system found the rectifier faulty.
KRT_V1058(config-if-power4875l-1)#display power alarm
EMU ID: 1 Power alarm information
----------------------------------------------------------------------------
Module 0 : Fault
Module 1 : Fault Rectifier module configuration can’t read

HUAWEI Confidential
 Access Network Product Training Technical Cases

Module 2 : Fault
Door alarm : Alarm Water alarm : Normal
Fog alarm : Normal Wiring alarm : Normal
Environment Temperature : Normal Environment Humidity : Normal
Battery temperature off state : Normal Load temperature off state : Normal

3) Checked on the rectifier LED is OFF. After replaced the rectifier modules, the problem still the same.
4) Checked for DIP switch setting on EMU is correct. The DIP switch setting no.7 should be ON
5) Checked on the incoming power is normal (230 VAC) by using power meter.
6) After changed on the power distribution frame, the problem resolved
【Suggestions and Summary】
Null.

2. VOD service is not normal after some while because of being unknow unicast

【Symptom】
All the VOD services in all OLTs become freeze sometimes, but other services like IPTV, internet, VOIP are
normal. The network topology is:
TV -> STB -> HG8245 -> MA5600T -> Juniper EX4200 -> Core IP Network -> VOD Server.
【Alarm Information】
Null.
【Cause Analysis】
Because all the services are normal except VOD and all the OLTs have the same problem, we think below
reasons may cause this problem:
1. There is some problem in the VOD server.
2. There have been some problems in the core network or Juniper EX4200 router like packet burst.
3. OLT discards the VOD packet.
4. ONT discards the VOD packet.
5. STB discards the VOD packet.
【Handling Process】
1. Capture the packet in OLT uplink port and ON eth port in the same time through mirror the uplink port of OLT
to other ethenet port and the eth port of HG8245 connecting to the STB to other eth port.
2. Analyze the packet in the OLT uplink port and no any packet discard and no packet burst.It means that the
VOD server and the core network and Juniper EX4200 router are all normal.
3. Analyze the packet in the eth port of HG8245 and some packets loss are found. The packet traffic during
packet loss is about 64Kbps and it's nearlly the same with the unknow unicast limited rate in HG8245.So we
think the problem is that the VOD packet becomes unknow unicast.
4. But why VOD packet becomes unknow unicast and why the problem do not always happen? We check the
captured packet when the problem is restored, HG8245 receive a packet from STB. So we think the
reason why the VOD packet becomes unknow unicast is that MAC forwarding table in HG8245 is aged. In
default the MAC address timer is 300s, in fact the valid time is between 260s to 340s.Confirmed with customer,
the response timer from STB to VOD servcer is 300s. So if the valid MAC address timer is below 300s, it will
cause the VOD problem happen.
HUAWEI Confidential
 Access Network Product Training Technical Cases

5. The Mac-address timer of HG8245 is controlled by OLT. We use below command in OLT to set the mac
address timer to 600s:MA5600T(config)#mac-address timer 600. Customer tests the solution and VOD
service is normal.
【Suggestions and Summary】
Null.

3. Multicast packet with TTL 1 causing the multicast user can not watch program

【Symptom】
Multicast user can order any program, there is no picture after ording any program
Network topology: Multicast server----------Switch--------MA5600T-------ONT8245
【Alarm Information】
Null.
【Cause Analysis】
TTL in multicast packet is wrong.
【Handling Process】
1. using the following commands to debug Igmp in OLT,the igmp user is online already
MA5600T#terminal debugging
MA5600T#terminal monitor
MA5600T#debugging igmp service-port 559
MA5600T#
*0.1201113490 MA5600T BTV/8/ALL:
The BTV user joins the program successfully
2. Check the port statistics in MA5600T uplink-port, there are lots of multicast packet,check the service-port
statistics ,there is few packet .
display port statistics
display statistics service-port index
3. Then we doubt the packet is drop in OLTcapture packet in MA5600T uplink-port,and get the TTL=1.if igmp
mode is proxy, MA5600T will drop this packet with TTL 1 .modify the TTL in Multicast server solved this issue
【Suggestions and Summary】
Use debugging commands to check the igmp packet is useful
analyze the packet is necessary when troubleshooting broadband service

4. High CPU occupancy cause ONT cannot be autofind

【Symptom】
Customer report that new ONTs are plugged to ports for specific OLT, they cannot be auto discovered.
【Alarm Information】
9401 2012-05-16 08:43:03+03:00 DST The system resources usage exceeds
the threshold
Resource Name: CPU, Current
Percent: 80
9400 2012-05-16 08:39:03+03:00 DST The system resources usage recovers
from the overload state to the normal state
Resource Name: CPU, Current
HUAWEI Confidential
 Access Network Product Training Technical Cases

Percent: 79
【Cause Analysis】
Possible reasons include below points:
1. OLT port ont autofind function is not enable
2. ONTs issue, including hardware and software issue
3. GPON board issue
4. OLT software issue
5. Other reasons
【Handling Process】
1. First we check the ONTs autofind switch using command " display ont autofind", find the switch is "enable".
2. Customer try to test sereval ONTs including HG8010 and HG863 and problem persist, also these ONTs can
be autofind in other OLT, which can clarify these ONTs have no problem.
3. Customer said this GPBD board is working well in another site, after he bring to this site, he meets this
problem, he can confirm this board is OK.
4. Customer has many sites with OLT version V800R008C01SPC100, only this site has problem, which can
clarify the host software is OK.
5. From the alarm history, we find the CPU occupany is higher than 80%, it would affect on ONTs'
autofind. Because customer is urgent to release service, we suggest him to switch over the system. And after
that, issue is solved, ONTs can be autofind.
【Suggestions and Summary】
High CPU occupancy will affect the ONTs register function. If CPU occupancy is very high, the software will
prohibit the register of ONTs. After swtich over the system, CPU occupany decrease to about 14%, and ONTs
can register normally.

5. IGMP mode snooping cause CPU utilization high lead to IPTV freezing

【Symptom】
IGMP mode snooping cause CPU utilization high lead to IPTV freezing
【Alarm Information】
#display cpu
CPU occupancy: 71%

# display igmp statistic global

The data of global IGMP statistic:
--------------------------------------------------------
Receive V1 general query number :0
Receive V2 general query number : 164447
Receive V3 general query number :0
Receive V2 specific query number : 29439994
Receive V3 specific query number :0
Receive V1 total report packets number :0
Receive V2 total report packets number : 2229039417 // num of report packets are very high
Receive V3 total report packets number : 18677
Receive V2 leave packets number : 21296235
HUAWEI Confidential
 Access Network Product Training Technical Cases

Receive V2 global leave packets number :0

Receive invalid igmp packets : 348631
Send V2 general query number : 112138246
Send V3 general query number : 57
Send V2 specific query number : 1882711028
Send V3 specific query number :0
Send V2 report packets number :0
Send V3 report packets number :0
Send V2 leave packets number :0
Send V2 global leave packets number : 28
--------------------------------------------------------
#display statistics service-port x
Number of upstream bytes : 2527408761
Number of upstream packets : 11351959
Number of upstream discard packets :0
Number of downstream bytes : 60496477527
Number of downstream packets : 914313565
Number of downstream discard packets : 170
【Cause Analysis】
Null
【Handling Process】
After checking the CPU utilization by #display cpu shows % of utilization
Use this command to check total report packets number
#display igmp statistic global
Check the IGMP global configuration # display igmp config vlan all
The configured IGMP mode is snooping.
IGMP mode should be proxy.
Step to change IGMP mode from snooping to proxy
huawei(config-mvlan600)#igmp mode
{ off<K>|proxy<K>|snooping<K> }:proxy

Command:
igmp mode proxy
Are you sure to change IGMP mode?(y/n)[n]:y
【Suggestions and Summary】
IGMP snooping mode will create a lot of report packets that lead to high CPU usage and make some packet
drop happen (created problem like IPTV freeze or jerking).The advantage of using proxy mode is it can make
the GPBD board sharing in the load.

6. PW down in MA5600T but up on the remote peer side due to Router didn't enable

LDP

【Symptom】

HUAWEI Confidential
 Access Network Product Training Technical Cases

[network structure] MA5600T ---------- (IP nerwork)----------Router(ALU)

[issue description]
Customer reported the pw status was down in MA5600T but was up in the Router so he thought it was
MA5600T problem and ask Huawei engineer to check .
【Alarm Information】
Null
【Cause Analysis】
Firstly, confirmed the issues , run this command "display pw pwid ", the display shows the local status code is
0X00000001 which means faulty , the remote status code is 0X00000000 which means good .See the print
screen in attachment .
Secondly, analysis the possilbe reasons.
Follow the MPLS principle; there are several reasons that could cause pw down:
1. routing is faulty; MA5600T can not reach the destination IP.
2. LDP is faulty; nodes do not distribute lable correctly.
3. PW configurtaion is wrong or inconsistence.
【Handling Process】
1. Check MA5600T configuraiton, nothing wrong had found.
2. PING remote ip, it was ok, so it was not routing problem.
3. Check LDP session. The status is operational which means ok .See the print screen in attachment.
4. Check LSP, found out there is only in label but no out label. As you can see in the following CLI, the in label
is 10505, but the out label is NULL.
display mpls lsp
-------------------------------------------------------------------------------
LSP Information: LDP LSP
-------------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
10.110.54.233/32 10505/NULL -/-

According to LDP principle , the out label of MA5600T should be distribute by the Router , so it is
Router problem.

5. Customer checked the Router and found out Router didn't enable LDP , after enable the LDP , the PW was
up.
【Suggestions and Summary】
All the nodes in the LSP should eable LDP, otherwise nodes will not distribute label for its neighbors.

7. Impossible to add MA5600T equipment due to MAC address conflict

【Symptom】
When trying to add a new MA5600T NE through BMS, customer receives an error indicating that a conflict
exists between outband management MAC addresses of the NE that they are trying to add and an existing NE.
【Alarm Information】
The alarm information is attached:

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Cause Analysis】
After analyzing the management mode of MA5600T devices we conclude that the only possible cause is the
same MAC address used by the active control cards of the 2 devices that conflict.
【Handling Process】
We check the mac addresses used by active control cards:

(GPON_SZTLORINCE-H1=84.1.20.38, GPON_KECSE-H4=84.1.35.154):
GPON_SZTLORINCE-H1(diagnose)%%display sysman mac-address
Current MAC address of active control board: 0025-9eac-0749
Modified MAC address of active control board: 0000-0000-0000
Default MAC address of active control board: 0025-9eac-0749

GPON_KECSE-H4(diagnose)%%display sysman mac-address

Current MAC address of active control board: 0025-9eac-0749
Modified MAC address of active control board: 0000-0000-0000
Default MAC address of active control board: 0025-9eab-f57c

We can see that GPON_KECSE-H4 uses a different MAC address then default one as current MAC address.
The root cause is that the active control card of GPON_KECSE-H4 was used as standby control card along the
active control card of GPON_SZTLORINCE-H1, though replicating the MAC address.

HUAWEI Confidential
 Access Network Product Training Technical Cases

After changing the MAC address to default one the adding of NE is possible:
GPON_KECSE-H4(diagnose)%%sysman mac-address current 0025-9eab-f57c
【Suggestions and Summary】
Null

8. Mismatched overhead between MA5600T and OSN3500 caused mistiming of

STM-1 stream

【Symptom】
Interconnection scenario: MA5600T with OSN3500 via STM-1 channel.
MA5600T is connected using TOPA board with 02CE subbboard. Software version is V800R007C00SPC300
Topology is the following: OSN3500 <---> MA5600T
Physical link is normal but STM-1 stream can not be synchronized correctly.
【Alarm Information】
The following error appeared:
FAULT MAJOR 2011-05-23 10:23:12+08:00 ALARM NAME: The remote defect indication signal of the line is
abnormal PARAMETERS :FrameID: 0, SlotID: 1, PortID: 0 ! RECOVERY CLEARED 2011-05-23
10:23:12+08:00 ALARM NAME: The remote defect indication signal of the line recovers from the abnormal
state PARAMETERS: FrameID: 0, SlotID: 1, PortID: 0
【Cause Analysis】

1. Physical connection was checked and found no fault.

2. Checked STM port state. Port status is active

MA5600T(config-if-top-stm1-0/1)#display port state all
---------------------------------------------------------------------------
Port Port Port Optic Line Port Loop VC12 Rate B2-SD alarm
Type Status Status Signal Clock Type Mode (Mbps) threshold
---------------------------------------------------------------------------
0 STM-1 active normal yes system no loop huawei 155 1.0e-5
1 STM-1 active normal yes system no loop huawei 155 1.0e-5
---------------------------------------------------------------------------

3. Checked port state details and found J0MM and HPTIM errors:

MA5600T(config-if-top-stm1-0/1)#display port state 0

{ |detail }:

Command:
display port state 0
-----------------------------------------------------------
Status of the optical transceiver : normal
Port admin status : active
Current port status : online
HUAWEI Confidential
 Access Network Product Training Technical Cases

Port rate : 155Mbps

Port Tx clock : system
Port vc12 numbering mode : huawei
Port B2-SD alarm threshold is : 1.0e-5
Port alarm status : J0MM HPTIM
Port IP address : -
Port MAC address : -
-----------------------------------------------------------

J0MM error corresponds to the J0 byte mismatch

HPTIM corresponds to J1 byte mismatch
Overhead values for J0 and J1 between MA5600T and OSN3500 are not consistent.

4. Checked overhead value and found that there is no response from OSN3500 to MA5600T

MA5600T(config-if-top-stm1-0/1)#display overhead 0
{ |VC12 }:

Command:
display overhead 0
-------------------------------------------
Type of J0 send :Long
J0 send :HUAWEI MA5600T
Type of J0 received :Long
J0 received :
Type of J0 required :Long
J0 required :HUAWEI MA5600T
Type of J1 send :Short
J1 send :HUAWEI MA5600T
Type of J1 received :Short
J1 received :
Type of J1 required :Short
J1 required :HUAWEI MA5600T
C2 send :2
C2 recevied :2
-------------------------------------------

【Handling Process】
1. Set J0 and J1 values to 0 and type of byte to "Long" for test. Let`s see the result:
MA5600T(config-if-top-stm1-0/1)#display overhead 0
{ |VC12 }:

HUAWEI Confidential
 Access Network Product Training Technical Cases

Command:
display overhead 0
-------------------------------------------
Type of J0 send :Long
J0 send :0
Type of J0 received :Long
J0 received :¬
Type of J0 required :Long
J0 required :0
Type of J1 send :Long
J1 send :0
Type of J1 received :Long
J1 received :¬
Type of J1 required :Long
J1 required :0
C2 send :2
C2 recevied :2
-------------------------------------------
2. J0 and J1 values received are incorrect and looks strange.

3. Set J0 and J1 values to 111111111111111 on both devices.

MA5600T(config-if-top-stm1-0/1)#display overhead 0
{ |VC12 }:

Command:
display overhead 0
-------------------------------------------
Type of J0 send :Long
J0 send :111111111111111
Type of J0 received :Long
J0 received :
Type of J0 required :Long
J0 required :111111111111111
Type of J1 send :Long
J1 send :111111111111111
Type of J1 received :Long
J1 received :
Type of J1 required :Long
J1 required :111111111111111
C2 send :2
C2 recevied :2
-------------------------------------------

HUAWEI Confidential
 Access Network Product Training Technical Cases

4. Found that MA5600T sends J0 and J1 frames not 111.. but 313131....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 0D 31 31 31 31 31 31 31 31 00
00 00 00 00 0D 31 31 31 31 31 31 31 00 00
31 31 00 00 0D 31 31 31 31 31 31 31 31 31

5. 31:31:31... is the 111... but in HEX value.

Different character`s format caused inconsistence of J0 and J1 bytes received.

6. MA5600T can send frames only in ASCII format. Correspondend data format need to be choosed on
OSN3500.

7. Checked again the received values:

MA5600T(config-if-top-stm1-0/1)#display overhead 0
{ |VC12 }:

Command:
display overhead 0
-------------------------------------------
Type of J0 send :Long
J0 send :111111111111111
Type of J0 received :Long
J0 received :111111111111111
Type of J0 required :Long
J0 required :111111111111111
Type of J1 send :Long
J1 send :111111111111111
Type of J1 received :Long
J1 received :111111111111111
Type of J1 required :Long
J1 required :111111111111111
C2 send :2
C2 recevied :2
-------------------------------------------

8. Checked the port state and found that errors were rectified
MA5600T(config-if-top-stm1-0/1)#display port state 0
{ |detail }:

Command:
display port state 0
-----------------------------------------------------------

HUAWEI Confidential
 Access Network Product Training Technical Cases

Status of the optical transceiver : normal

Port admin status : active
Current port status : online
Port rate : 155Mbps
Port Tx clock : system
Port vc12 numbering mode : huawei
Port B2-SD alarm threshold is : 1.0e-5
Port alarm status : no alarm
Port IP address : -
Port MAC address : -
-----------------------------------------------------------

【Suggestions and Summary】

For STM-1 interconnection between MA5600T and SDH/STM -transmission equipment always check overhead
values and set up correct data format on both devices to ASCII

9. STB cannot get IP address due to service port not enable DHCP option 82

【Symptom】
Network connection: OLT--> ONU -->RG --> STB-->TV
Customer complaint IPTV service is failed. After engineer troubleshoot, found the STB cannot get the IP
address.
【Alarm Information】
Error code: 102004; Network Unreachable
【Cause Analysis】
1 ) The STB is faulty.
2) The RG is faulty.
3) The ONU is faulty
4) The network cable is fautly or port is connected wronly.
5) The GPBD service port is faulty.
6) The fiber from OLT to ONU is faulty
7) Upper network and DHCP server is failure
8) The service port is not configured.
9) The service port not configured the DHCP option 82
【Handling Process】
1) The engineer changed withe the new STB, the problem still persists.
2) The engineer changed wiht the new RG, the problem still persists.
3) The engineer cahnged with the new ONU, the problem still persists.\
4) The engineer changed with the new LAN cable for RG and STB, the problem still persists.
5) The engineer changed with the new GPBD board, the service is still failed also.
6) The engineer checked from the optical power reading by command "display ont optical info x x'", the Tx and
Rx optical power is normal.
7) Customer informed one of user is service at this OLT affected only, so we can eliminate the root cause from

HUAWEI Confidential
 Access Network Product Training Technical Cases

upper layer side or DHCP server.

8) The engineer checked the configuration of the service port for this user is normal.
9) After checked the DHCP configuration for this service port by command" display dhcp option 82 service-port
xx", found the option 82 function is disabled. After configured this service port with option 82, the problem
solved. The user can watch the IPTV now.
【Suggestions and Summary】
Null

10. MA5612 is intermittent down due to the fiber connector is not clear

【Symptom】
Info
Device: SmartAX MA5612
Version:V800R308C00SPC500

MxU was intermittance and sometimes devices communication failed. After checking and get info from ANOC
team, MxU connected to slot 0/3 ont id 3.

MA5600T(config)#display statistics ont-line-quality 0/3 0 3

------------------------------------------------------------------
Line quality statistic ONTID :3
LOFI alarm number : 81
Upstream frame scape error number : 6374
Upstream frame BIP error number : 798
Downstream frame BIP error number :0
Upstream frame FEC correct blocks :0
Upstream frame FEC uncorrected blocks : 0
Upstream frame HEC error : 25
------------------------------------------------------------------
【Alarm Information】
Alarm communication loses

【Cause Analysis】
Check on the document regarding Upstream frame scape error number =6374, Upstream frame BIP
error number = 798. this error should be "0" in order to avoid packet loss.
Upstream frame scape error number = This index is a statistics value. It helps to measure the number of the
frames with upstream delimiting failures (during four successive frames, no valid delimiting frames are received)
on an ONT.
【Handling Process】
1) Collect some log infomation :
MA5600T (config)#clear statistics ont-line-quality 0 // clear the current statistic
MA5600T (config)#display statistics ont-line-quality 0 // check on either this issue still persists or not.
2) Check on the temperature of the site, memory and cpu. All in good condition.
HUAWEI Confidential
 Access Network Product Training Technical Cases

3) Check on optical received power from mxu to OLT. This one is important to ensure the optical power recieved
during the range. The result is good but the problem still persists.
4) Clean the fiber connectivity for port 0/0/0 at MxU and output from spillter. Change the SFP.
5) Problem solved and keep monitoring for one week.
6) Result monitoring for 1 week and ask fse to check on ont-line profile.
MA5600T(config-if-gpon-0/3)#display statistics ont-line-quality 0 3
------------------------------------------------------------------
Line quality statistic ONTID :3
LOFI alarm number :0
Upstream frame scape error number :0
Upstream frame BIP error number :0
Downstream frame BIP error number :0
Upstream frame FEC correct blocks :0
Upstream frame FEC uncorrected blocks : 0
Upstream frame HEC error :0
------------------------------------------------------------------
7) Issue was solved and explain to customer regarding due to some dirty on fiber and SFP heating will occur
laser fiber connection.
【Suggestions and Summary】
1) First need to analyze and simplify the problem happen. FROM OLT----> spiltter----> MxU 1, MxU 2, MxU 3,
MxU 4---->mobile backhaul
2) Only found happen on MxU and check on two places of MxU and the spiltter. Luckily the spilltter and MxU
are at the same place.
3) Suspect on fiber quality due to explaination this alarm on internet.

11. Services are interrupted for 5 minutes after an active/standby switchover because

the MAC address aging time is too long

【Symptom】
Network topology: MxU -> OLT -> S8512. The gateway of the MxU is installed on S8512. The OLT connects to
the MxU through the control boards in the upstream direction. The active and standby control boards are
configured with a Poststate protection group.
Version: OLT V800R008C00SPC307
Five minutes after the active/standby switchover on the OLT, S8512 fails to ping the management IP address of
the MxU
【Alarm Information】
Null.
【Cause Analysis】
1. The ASPB board should be no issue since it could work in another MA5603T.
2. There might be bent pins on the backplane of MA5603T frame.
3. Software of the MA5603T might not support the ASPB board.
4. No CKMC sub-board is installed on the main controller board.
5. No voice file has been loaded.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Handling Process】
1. If S8512 fails to ping the management IP address of the MxU after the active/standby switchover, run the
display mac-address all command to query the MAC address. It is found that the OLT learns an incorrect
MAC address entry from the network side.
2. If S8512 pings the management IP address of the MxU after the active/standby switchover, run the display
mac-address all command to query the MAC address. It is found that the OLT learns a correct MAC address
entry from the user side.
3. After the analysis, it is found that the physical link between the standby control board and S8512 is in the up
state when the active control board is working. Although the standby control board is not working, it learns the
MAC address entry of the MxU from the network side because the MxU sends broadcast packets. After the
active/standby switchover, because the MAC address does not age and the MAC address learning priority on
the user side is lower than that on the network side, the OLT does not learn the correct MAC address entry from
the user side until the MAC address ages.
4. Run the display mac-address timer command to query the MAC address aging time 300s (default value) of
the OLT.
5. Run the mac-address timer command to change the default MAC address aging time of the OLT to 60s.
The fault is rectified.
【Suggestions and Summary】
On one hand, if the aging time is too short, dynamic MAC addresses will be deleted too early. As a result, when
receiving a data packet carrying an unknown destination address, the device broadcasts the packet to all the
ports in the VLAN. On the other hand, if the aging time is too long, the device fails to update the MAC address
entry based on network changes. As a result, the packet is broadcast because the destination address is not
found. Such unnecessary broadcast affects the operation performance of the device. Generally, it is
recommended that you use the default value.
If a similar fault occurs, you can change the aging time to meet special service requirements

12. GPON access network, illegal rogue ONT, it means that this ONT is broken

【Symptom】
The customer reports that it is presenting management and failure loss of services in one GPON OLT MA5603T,
software version (MA5600V800R009C00, patch SPC100). Customer has moved personal to test ONT
changing fault but the result is the same. The ONT HG8010 has the version V1R002C06S002.
In U2000 doesn't apear the alarm. U2000 V100R005C00SPC400
The scenario is like this:

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Alarm Information】
With the following command you can see if a specific port has or not a Rogue ONT:

MA5603T(config)#interface gpon 0/0

MA5603T(config-if-gpon-0/0)#display port state 6
----------------------------------------------------------------------------
Illegal rogue ONT Existent
----------------------------------------------------------------------------

HAC-BOG.CHICOANT-CP1(config)#display alarm history

{ alarmclass<K>|alarmid<K>|alarmlevel<K>|alarmparameter<K>|alarmsn<K>|alarmtime<K>|alarmtype<K>|all<
K> }:all
{ <cr>|detail<K>|list<K>||<K> }:
Command:
display alarm history all
ALARM 464982 FAULT MAJOR 0x2e314021 EQUIPMENT 2012-07-05 23:44:07+08:00
ALARM NAME: There are illegal incursionary rogue ONTs under the port
SRVEFF: SA
PARAMETERS: FrameID: 0, SlotID: 0, PortID: 6
DESCRIPTION: There are illegal incursionary rogue ONTs under the port, it
will interrupt service of other ONT(s)
CAUSE: There is illegal incursionary rogue ONT under the port
ADVICE: Detect rogue ont manually, and then replace it
--- END
【Cause Analysis】
The complicated part of GPON system is the upstream direction, it adopts TDMA, every ONU must send
messages according to the strict plan from OLT, and if one ONU cannot control its optical module laser we will
say that the ONU is rogue-ont.
The ONT sends light randomly without control and this will affect other ONTs so; we called this ONT--- rogue
ONT.
Rogue ONT means that this ONT is broken. We cannot avoid it but we can detect this fault to do not affect other
ONTs.
It can’t be avoided but we can check out which ONT is rogue ONT.
There are two ways to check it out:
The first way is auto detect, when auto detect switch is open, the OLT will check all ONTs
every 15 min. and another way is manual detect, the process will be executed immediately.
The principle is the same with two ways OLT checks the SD and RSSI signal, if the signal exceed the threshold
OLT will close the power of optical module of ONT.
【Handling Process】
To detect continuous rogue ONU there are two policies: auto-detect and manual-detect.
In this case, we used Auto-detect, running the command “anti-rogueont autodetect” to enable this fuction;
When this function is enabled, the OLT will automatically detect, locate, and isolate continuous-mode rogue
ONTs. When this function is disabled, the OLT only detects continuous-mode rogue ONTs but will not locate or

HUAWEI Confidential
 Access Network Product Training Technical Cases

isolate them. During the locating process, all services of ONTs under a PON port will be interrupted.

MA5603T(config)#anti-rogueont autodetect
{ switch<E><on,off> }:on

Command:
anti-rogueont autodetect on
This command may make the ONU with good line quality go offline
Are you sure to continue? (y/n)[n]: y

Or you can use the next command:

MA5603T(config-if-gpon-0/0)#anti-rogueont manual-detect 6
It show the next alarm:
0x2e324021 The illegal incursionary rogue ONTs under the port have been cleared.

Another way to detect the Rogue ONT is to deactivate all ONT, one at time on the port with the Illegal Rogue
ONT, in this case port 0/0/6, and see if the Illegal rogue ONT Existent becomes Inexistent.

About U2000:
We can detect the rogue ONT by U2000 with the version U2000 V100R006C00SPC200

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Suggestions and Summary】

The steps of Anti-Rogue ONT:
1. Detection:
-Check upstream signal exist or not based on Signal Detect (SD) of OLT optical module in the empty time slot
which allocated by OLT.
-Yes, there is rogue ONT.
-No, check next period
2. Identification:
-Inform all ONTs to shutdown TX power, and check whether Rogue ONT still exist. Yes, illegal rogue ONT exist.
-Find out the suspect Rogue ONT through inform the ONT to turn on Tx power one by one
3. Isolation:
-Inform the suspect ONT shutdown its TX power.

Root cause:
The SD of some OLT optical modules is too sensitive with the ODN quality.
When the ODN quality is not so good, for example high reflection of the ODN, SD will be set in the empty time
slot even all ONT is ok. So the OLT will make mistakes in detection, identification and isolation. The normal
ONT will be isolated.

Temporary solution:
-Turn off the function of identification and isolation has no any impact to any traffic.
-System still can detect the real Rogue ONT and send out the alarm.
-When the “Rogue ONT” is found, users decide to turn on the function of identification and isolation or not
according to the actual traffic. If the traffic is normal, no need to turn on the function.

13. Why when we reboot ONT, the BIP error increase (FAQ)

【Symptom】
Q: why when reboot ONT, the BIP error increase?
Customer is asking the resaon of the increased BIP errors when they reboot the ONT and when they
disconnect and connect the fiber, the BIP error will also increase.
【Alarm Information】
Null
【Cause Analysis】
Null
【Handling Process】
A:
Introduction of BIP:
Downstream BIP: The BIP field is an 8-bit field that contains the bit-interleaved parity of all bytes transmitted
since the last BIP, excluding FEC parity (if present). The receiver shall compute the bit interleaved parity on all
bytes received since the last BIP, excluding the FEC parity (if present) and after FEC correction has been
applied (if supported), and compare its result to the BIP transmitted in order to measure the number of errors on
the link.
Upstream BIP: The BIP field is an 8-bit field that contains the bit interleaved parity (exclusive OR) of all bytes
HUAWEI Confidential
 Access Network Product Training Technical Cases

transmitted since the last BIP (not including the last BIP) from this ONU, excluding the preamble and delimiter
bytes, and FEC parity bytes (if present). The OLT receiver shall compute the bit interleaved parity for each ONU
burst excluding the FEC parity bytes (if present) and after FEC correction has been applied (if supported), and
compare its result to the received BIP field in order to measure the number of errors on the link
Usually when there is an optical line problem, the bip error increase. But when we reboot ONT or diconnect the
fiber, bip error increase due to the following:
When we reboot ONT, the ONT power (Voltage) will go down slowly, so ONT will send frame that OLT receive
not well, But OLT receive the sync frame that make ONT online. SO that maybe causes 1 or 2 bip error.
And when disconnecting and connecting the fiber, this cause by manual, this is also slow decrease of power
voltage, that will send error frame to OLT in manual plug and pull out the fiber to our OLT system(the OLT detect
per 125us), so that also maybe cause BIP error too.
So this maybe cause BIP error, So when we detect line quality, we should focus the increase of the line quality,
also should focus the history line quality.
That will make our line quality well.
【Suggestions and Summary】
NULL.

14. Data failed to be backed up after packets are forcibly sent from a VLAN interface

【Symptom】
Version: V800R008C05SPC312
When users back up files of an MA5600T by FTP through the U2000 or CLI, the system displays a message
indicating that file transfer fails. However, files of other OLTs can be backed up successfully.
【Alarm Information】
Backup failure
【Cause Analysis】
Possible causes are as follow:
1. A network connection error occurs.
2. The FTP password is incorrect.
3. The control board is faulty.
4. The FTP data configuration is incorrect.
【Handling Process】
1. Ping the FTP server from the OLT. It is found that the FTP server is pingable. This indicates that the network
connection is normal.
2. Back up data of other OLT. It is found that the data backup is successful. This indicates that the FTP server
password is correct.
3. Back up data of the OLT by TFTP. It is found that the data backup is successful. This indicates that the
control board is works normally.
4. Check the FTP data configuration. The check result shows that the packets are configured to be forcibly sent
through VLAN interface 10.

huawei(config)#display sysman source all

trap source interface: vlanif31
syslog source interface: auto
HUAWEI Confidential
 Access Network Product Training Technical Cases

tftp source interface: auto

ftp source interface: vlanif10 --------Indicates that the packets are configured to be forcibly sent through
VLAN interface 10.
sftp source interface: auto
telnet source interface: auto
ping source interface: auto
tracert source interface: auto
license source interface: auto

5. Check whether data packets can be transferred from VLAN interface 10 to the FTP server. The check result
shows that the data packets cannot be transferred to the FTP server. Run the undo sysman source command
to delete the configuration of forcing FTP packets to be sent through VLAN interface 10. After the deletion, the
data backup of the OLT becomes normal.
【Suggestions and Summary】
Null

PON Terminal Troubleshooting Cases

15. Improper value of priority-queue lead to ONT config state failed

【Symptom】
Config state of ONT is failed when query ont info.
【Alarm Information】
orbe-olt1(config-if-gpon-0/0)#display ont info 0 all
-----------------------------------------------------------------------------
ONT-ID SN Control Run Config Match Protect
flag state state state side
-----------------------------------------------------------------------------
0 485754437688EA11 active online failed match no
-----------------------------------------------------------------------------
Description : ONT8247-1-Bridge
-----------------------------------------------------------------------------
1 4857544325E1A70C active online failed match no
-----------------------------------------------------------------------------
Description : ONT8247-2-Routed
-----------------------------------------------------------------------------
3 4857544325E12F0C active offline initial initial no
-----------------------------------------------------------------------------
Description : ORBE-Local
-----------------------------------------------------------------------------
In port 0, the total of ONTs are: 3
【Cause Analysis】
HUAWEI Confidential
 Access Network Product Training Technical Cases

Becasue HG8247 just support 4 queues, It means that priority-queue of gemport can be configured from 0 to 3,
So config state will be failed when this value was configured over 3 .

ont-lineprofile gpon profile-id 5 profile-name "line-profile_5"

tcont 1 dba-profile-id 12
gem add 0 eth tcont 1
gem add 1 eth tcont 1 priority-queue 6
gem add 2 eth tcont 1
gem mapping 0 0 vlan 100
gem mapping 1 1 vlan 200
gem mapping 2 2 vlan 300
commit
quit
【Handling Process】
Change the value of priority-queue to 3. The config state becomes normal.
【Suggestions and Summary】
The value of Priority-queue is limited from 0 to 3 on HG8247.

16. User failed to get IPTV services due to non-standard FE cable between STB and

ONT

【Symptom】
It is escalated by customer that on one ONT IPTV service is not working while other services HSI and VOIP is
normal.
【Alarm Information】
Null.
【Cause Analysis】
1-Wrong service port and BTV configuration at OLT.
2- STB or ONT faulty.
3-Cable or RJ-45 Connectors faulty between ONT and STB.
【Handling Process】
1- We check the service port configuration for IPTV services for problematic user and it is found ok, and with
same service port configuration other connections are normal.
2- Change the STB with other working STB, fault persists. Change ONT with working ONT but still the problem
persists so we can exclude the fault at ONT and STB.
3- Finally we check the cable between ONT and STB. From OLT we check the ont port state of all Ethernet
ports, result was as follow,
Cantt_MA5600T(config-if-gpon-0/13)#display ont port state 7 7 eth-port all
Command:
display ont port state 7 7 eth-port all
-----------------------------------------------------------------------------
ONT-ID ONT port-ID ONT Port-type Speed(Mbps) Duplex LinkState
-----------------------------------------------------------------------------

HUAWEI Confidential
 Access Network Product Training Technical Cases

7 1 GE 100 full up
7 2 GE - - down
7 3 GE - - down
7 4 GE 10 full up
--------------------------------------------------------------------------
The port 4 which connected with STB is up at 10 Mbps speed in auto negotiation mode. The FE cable and
RJ-45 connectors are suspected of this problem because it was manually made by field staff and length was
about 20 meters between STB and ONT. Field staff did not follow the color scheme while making connectors.
We change the cable and make the RJ-45 connectors according to standard color pattern. After this port is up
at 100Mbps and user can successfully watch the program.

Cantt_MA5600T (config-if-gpon-0/13)#display ont port state 7 7 eth-port all

Command: display ont port state 7 7 eth-port all
-----------------------------------------------------------------------------
ONT-ID ONT port-ID ONT Port-type Speed(Mbps) Duplex LinkState
-----------------------------------------------------------------------------
7 1 GE 100 full up
7 2 GE - - down
7 3 GE - - down
7 4 GE 100 full up
--------------------------------------------------------------------------
【Suggestions and Summary】
CAT-5 and CAT-5e has 100 ohm impedance and electrical characteristics supporting transmissions up to 100
MHz. Using wrong color scheme may affect all aspects of performance: capacitance, frequency, resistance,
attenuation. So follow the standard color scheme while making connectors as mentioned bellow.

HUAWEI Confidential
 Access Network Product Training Technical Cases

17. Wrong digital map configuration leads to call fail

【Symptom】
When we make call with 3 digit , we heart busy tone.but with 2 digit , the call is establish.
Phone=>ONT HG8245 => Splitter=>OLT => Softswitch (Ericsson)
【Alarm Information】
Null
【Cause Analysis】
We have taken one trace from customer belong to Ericsson.
We reviewed the trace I found the good trace report the number”*934#23”.
But huawei trace only report “*934”.
【Handling Process】
So it must be the digit map config problem. See trace as following:
We should add EXXXFXX in the digit map in the ONT HG8245.
The call is ok. See trace in file "trace ok with 3 digit" attached.
【Suggestions and Summary】
Null

18. Error Digitmap Match mode causes HG8245 VOIP fail

【Symptom】
Customer reports that they have some problem with VOIP on ONT. When customer dials #54#, SoftSwitch do
esn’t receive first digit after #, in this case SoftSwitch only receives #4#, digit 5 is missed.
HUAWEI Confidential
 Access Network Product Training Technical Cases

【Alarm Information】
Null
【Cause Analysis】
1. ONTs fault
2. Line abnormal
3. Configuration error
【Handling Process】
After checking the captured packets on problematic ONT, we find ONT does detect number 5, but does not rep
ort to SoftSwitch. Reason is that the Digitamp Match mode is set to Max. Max Digitmap match mode means af
ter customer dial first digit, ONT use this digit to match digitmap, if there're more than one digitmap can match,
ONT will not report this digit to SoftSwitch, it will wait for next digit. But Min Digitmap match mode will not wait
for next digit if first digit can match, it will directly report to SoftSwitch.
【Suggestions and Summary】
In this case, when ONT detects first #, find there're more than one digitmap can match, it waits next digit.
After customer dial digit 5, ONT find cannot match #5, it report # to SoftSwitch, missing digit 5, because digit 5
is not match in the Digtimap. After we modify Digitamap Match mode from Max to Min, problem solved.

MSAN UA5000 Troubleshooting cases

19. Troubleshooting of Reverse Polarity

【Symptom】
After a migration of many sites of V5 to IP of the Integrate Access Equipment (UA5000), there was no
response of reverse polarity in a lot of ports of HASL service boards. The customer and other huawei
engineers had done many tests before being in charge of this case in order to fix the problem, but without
success. The service board had been change for a new one, and the sitee was compared with other equipment
which reverse polarity worked very well.
【Cause Analysis】
We proceeded to use the following commands on the site to check the cause of the problem:

LA_JOSEFINA_PVMD(config)#display language
Local:
Description: CHINESE SIMPLIFIED (DEFAULT LANGUAGE)
Version: UA5000V100R019C00
Encoding: GBK

LA_JOSEFINA_PVMD(config)#display system parameters

-----------------------------------------------------------------------------
Parameter name index: 3 Parameter value: 0
Mean: Stop initial ringing flag, 0:not send, 1:send

HUAWEI Confidential
 Access Network Product Training Technical Cases

-----------------------------------------------------------------------------
Parameter name index: 6 Parameter value: 0
Mean: call-waiting tone flag, 0:softswitch, 1:mg
-----------------------------------------------------------------------------
LA_JOSEFINA_PVMD(config)#display log all (To check the log list of events)

LA_JOSEFINA_PVMD(config)#display alarm history all detail (To check all the alarms)

LA_JOSEFINA_PVMD(config)#display current-configuration (The equipment was configured as usual)

LA_JOSEFINA_PVMD(config-esl-user)#display pstnport attribute 0/13/15

Frame/Slot/Port : 0/13/15
Gain(db) : High gain
Dial-Mode : DTMF-Pulse-Both
Polarity-Reverse : Not supported
User-Type : DEL
Dsp-Para-Template :-
Support port line lock : Support
Support-Bell-ANS : Disable
Support-detect-ANS-single-tone : Disable

LA_JOSEFINA_PVMD(config-esl-user)#display pstnport reversepole_pulse 0/13/15

------------------------------------------
Frame/Slot/Port Level(ms) Reverse-pole-pulse
------------------------------------------
0 / 13 / 15 300 Disabled
------------------------------------------

In fact, I took some information with DBWIN:

LA_JOSEFINA_PVMD(su)%%dbwin enable

1) It's possible that some oudated UA5000 version don't support reverse polarity, so it is important upgrade the
version or use any patch with the characteristics because UA5000V100R019C00 shows us there is not a
patch.
2) Moreover, the reverse polarity was not supported and enables either on the UA5000 ports.

【Handling Process】
Then proceed to do the following process:

1) Load the newest patch V100R019C00SPC108

3) Reboot the equipment: reboot system

HUAWEI Confidential
 Access Network Product Training Technical Cases

4) Configure the ports that need reverse polarity as follows:

LA_JOSEFINA_PVMD(config-esl-user)#pstnport attribute batset 0/14/15 0/14/16 polarity-reverse support
LA_JOSEFINA_PVMD(config-esl-user)#pstnport clip batset 0/14/15 0/14/16 reverse-polarity enable

5) Save the changes

LA_JOSEFINA_PVMD(config)#save

6) Then test it again with the customer, and the problem was solved.

【Suggestions and Summary】

After doing the procedure, the reverse polarity was stable. Do not forget this parameter (reverse polarity) is
optional because not all the telephone services need this in particular, and for this reason by default it is
not-supported.

20. POS Transaction failed due to Missing Configuration in Softswitch and Terminal

leads Malfunction of UA5000 Line

【Symptom】
After migrating existing UA5000 (V5.2 R11 version) to UA5000PVMV100R019, users serving POS (Point of
Sales) started to have failures with the payment transactions inside one mall. New version after migration to IP
is:

Version: UA5000V100R019C00

PVMD_SAN_LUIS(config)#display version 0/4

---------------------------------------
Pcb Version: H601PVMD VER.B
Base Bios Version: 804
Extend Bios Version: 823
Software Version: UA5000V100R019C00
CPLD Version: 111
FPGA Version: 109
NOD Version: 110
Voice Version: 003
---------------------------------------
SubBoard[0] :
Miro Version: v7_17_3_8
---------------------------------------
SubBoard[1] :-

Escenario as follows:

HUAWEI Confidential
 Access Network Product Training Technical Cases

Cases:
1. When using Terminal 1 calling PBX 1, there is no problem but when calling PBX 2 transaction cannot be
completed most of time.
2. When using Terminal 2 and Terminal 3 calling PBX 1 transaction fails every 10 times, with PBX 2 transaction
cannot be completed most of time.

【Alarm Information】
There are no alarms present while the transactions failed with both PBX and Terminals. All DSP resources and
Board runs normal.
【Cause Analysis】
1. Fault didn't appeared while UA5000 had PVU control board and conneted with V5.2 interface, because TDM
transactions where not related to NGN network LE worked normally.

2. Once migrated site to IP network connection, in UA5000 we made some debug for the PSTN ports, DTMF
and digitmap had no problem. Also any other type of service and users had correct service, verified with the
QoS Tests and traces with dBwin.

3. Based on correct funcition on UA, supported to find the problem outside it. None of the transaction can be
sucessfully completed calling PBX 2, it was found that this pilot number was new PBX number outside current
operator network. But PBX 1 number belong to same operator PSTN number used before with other IP
UA5000 with no problems reported for POS transactions.

4. Found three models for POS Terminals, Terminal 1 completed the transaction every time but Terminal 2 and
3 had problems to complete transaction randomly every 10 or 20 transactions.

5. Provided that same UA5000 version worked corretly handling POS transactions in same scenario in other
locations and the diagnose for control and service boards did not presented any failure. Problem should be
related to negotiation parameters either between NGN to PSTN or for POS terminal itself.
【Handling Process】
HUAWEI Confidential
 Access Network Product Training Technical Cases

1. With support from Core Engineer, While analyzing parameters for PBX 1 number found that it has different
Service category registered in Huawei Softx for this number

2. When we changed Service Category of PBX 2 to "LOW SPEED", the Terminal 1 completed all the
transactions succesfully to PBX 2. But the random problem persisted for Terminal 2 and 3 for both PBX.

3. Provided that the problem was related with speed of the transaction, we could be able to raise the response
time in Terminal 3 from 50 seconds to 60 seconds, then all transactions could be completed. It also helped
modify the digitmap-timer timer in UA5000, long timer need to be decreased to 5s.

4. Finally Terminal 2 (SAGEM) had no any option to change the response time and increase it, so the advice
this time was to change this model to Terminal 1 or 3.
【Suggestions and Summary】
Service Category configured in the SX for the PBX numbers can affect this type of transactions, provided that
UA5000 supports normally FAX and MODEM transactions it also needed to be checked the parameters for
POS terminals, thus concluding that one specific type has no robust performance and configuration support.

21. UA5000 ISDN data service fails due to incorrect ptime on E company UMG

【Symptom】
Network topology:
branch office A ( PSTN )----E// UMG----SIP-I---Huawei UMG---- Huawei Softx3000----Huawei UA5000 branch
office B
Phenomenon description:
Customer complain that data service between two bank branch office can not work. ISDN data connection can
not be established. After troubleshooting from NGN side we notice that data connection use clearmode codec
and if in clearmode payload is 97, problem occurs. While if in clearmode payload use 100 we don't have
problem.
【Alarm Information】
No.
【Cause Analysis】
Possible causes can be as following:
1. UA5000 configuration has problem.
2. UA5000 DSP miro has problem in processing.
HUAWEI Confidential
 Access Network Product Training Technical Cases

3. H248/Q931 signaling has problem.

4. Softx3000 has problem in processing packets.
5. E// UMG or Huawei UMG has problem in processing packets.
【Handling Process】
Handling steps are as following:
1. Check configuration setting of UA5000, there is no problem. In default the clearmode payload is 100.
2. DSP miro version is a little old, but customer did not agree to upgrade DSP version first as it will interrupt
service, so can not upgrade miro version first to see whether problem can be solved.
3. Collect dbwin trace while recur the problem to check and make comparison analysis between trace of
payload 97 and trace of payload of 100, call flow of signaling messages are same, no abnormity can be found.
So signaling has no problem.
4. Customer changed call route in PSTN, topology is as following, and test results shows data service is always
fine regardless of payload 97 or 100 in clearmode. The difference between two topologies is problematic
scenario path contains E// UMG.
branch office A ( PSTN)----Huawei UMG----Huawei Softx3000---Huawei UA5000---branch office B
5. Restore the route in PSTN to return to problematic network topology, capture wireshark trace on uplink port
of PVM by mirror function while testing payload 97 and 100 scenarios, we found following:
Based on the packets when the problem occurred (payload 97 scenario), UA5000 can send out the packets
normally.
In normal situation (payload 100 situation): Softx3000 sent to MSAN the ptime (packeting time) of opposite side
as 20ms, and the packets interval for both UA5000 receiving and sending are all 20ms, which is correct.
In problematic situation (payload 97 situation): Softx3000 sent the ptime 20ms to both opposite side and MSAN
side, in this case, opposite side should send packets with interval of 20ms, and MSAN should send out packets
with interval of 20ms too; but we can see the real situation is, the packets interval UA5000 receives is 10ms
(receive each packet with interval of 10ms), and UA5000 send out packets with 20ms interval(this is abnormal).
So there is problem regarding the packets sending interval sent from opposite side.
After E// softswitch changed ptime on E//UMG from 10ms to 20ms, problem was finally solved.

【Suggestions and Summary】

No.

HUAWEI Confidential
 Access Network Product Training Technical Cases

22. VOIP call Fail due to interconnection problem between master and extended

UA5000 fram

【Symptom】
MSAN connected to Metro ethernet to soft switch
phone--- MSAN---Metro Ethernet ------IP Network----- Soft switch
MSAN working in the integrated mode IPMB and PVM and have A32 card for voice service.
During MSAN acceptance the voice call is not working , in the same time the H.248 protocol is normal.
【Alarm Information】
HW-Pots-Deguche(config)#display board 0
-------------------------------------------------------------------------
SlotID BoardName Status Sub0 Sub1 Online/Offline
-------------------------------------------------------------------------
0 H602PWX Normal
1 H602PWX Normal
2
3
4 H601PVMD Active_normal H602ETCM
5 H601PVMD Standby_normal
6
7
8
9
10
11
12
13
14
15
16
17 TSS Normal
18 A32 Normal
19 A32 Normal
20 A32 Normal
21 A32 Normal
22 A32 Normal
23 A32 Normal
24 A32 Normal
25 A32 Normal
26 A32 Normal
27 A32 Normal
28 A32 Normal
29 A32 Normal
HUAWEI Confidential
 Access Network Product Training Technical Cases

30 A32 Normal
31 A32 Normal
32 A32 Normal
33 A32 Normal
34
35
-------------------------------------------------------------------------

HW-Pots-Deguche(config)#
【Cause Analysis】
The cause of this problem is divided into two side troubleshooting
1- Network Side:
- may be the connection between MSAN and Metro ethernet problem so we can not reach the MGC
- May be the coonection between MSAN and softswith is not working so H.248 is not working
2-MSAN local problem
- May be fram problem
- May be A32 card prblem
- May be software version problem
【Handling Process】
1- first we check the fram is added and working successfully
2- check the A32 board is normal
3- ping the MGC to confirm we can reach it
4-check the H.248 is noraml
5- make test call , there is no Voice signal
6- trace H.248 signal there is no signal interaction between MG and MGC
7- A32 card was installed in Extended fram , so we move the card from extended to fram master frame and
make test call it is working normal
8-so we start troubleshooting the High way cables between master and extended fram is not well connected
9-so after we unplug and plug in the cables again and fix it very well , we move the A32 card back to extended
fram and service working normal
【Suggestions and Summary】
We must keep in mind the high way cables connection between master and extended fram is very well
connected.

23. Synchronization failure on SDLE boards due to misconfiguration of the SHDSL

modem

【Symptom】
customer have synchronization problem between SDLE board and <<Patton>>modems.
“PATTON” modem generates the following message when synchronization is lost:

HUAWEI Confidential
 Access Network Product Training Technical Cases

and when it recovers this message appears:

attached is the configuration of the modem

【Alarm Information】
Null.
【Cause Analysis】
troubleshooting steps :
1- This problem could be from phyical line so we check directly from the MDF same problem occurs
2- we confirm that it is not board problem as we test new board and both is normal .
3- check the UA5000 configuration it is ok and no problem found .
4- check modem configuration :
We found , if we change timeslot in Modem as 0—31, the synchronization is stable, and after we modify back
to time slot 1—31, problem re-occur .
【Handling Process】
After troubleshooting problem on site we find that timeslots configuration was not consistent between SDLE
board and PATTON modem:
Two solutions are possible:
1) Let t1/e1 timeslot mapon the modem: 1-31 and change the rate on the SDLE board to 31x64K.
2) change t1/e1 timeslot map on the modem to 0-31 and set the rate on the SDLE board to 32x64K.
【Suggestions and Summary】

SDLE board:

HUAWEI Confidential
 Access Network Product Training Technical Cases

24. EPMU raised an ACinput Air Switch Alarm due to Wrong Logical Information Sent

by Power4875L to UA5000

【Symptom】
1. MSAN UA5000PVMV100R017C02B062 with SPH121 patched.
2. MSAN used H601PVMD as the NB control board and H603CSRB as the service board.
3. The MSAN typical network topology:

4. The MSAN power diagram:

HUAWEI Confidential
 Access Network Product Training Technical Cases

5. MSAN used Power4875L and EPMU02

EMU ID: 0
----------------------------------------------------------------------------
software version : 0109
PCB version :B
Board name : EPMU02
System name : EPS75-4815AF
----------------------------------------------------------------------------

6. The EPMU02 raised an alarm, red alarm of the EPMU was on

7. When displaying the alarm state --> ACinput air switch: alarm.
8. But actually, the AC input breaker was ON, and the AC current was exist passed through the rectifier system
and could generate DC current and powered ON the UA5000 shelf.
9. All related to the electricity was normal
【Alarm Information】
MSAN02-D3-CJ-1MRB(config-if-power4875L-0)#display power alarm
EMU ID: 0 Power alarm information
----------------------------------------------------------------------------
mains supply yes : yes mains supply lack : normal
total vol lack : normal
load fuse : connect
load off : on battery off : on

HUAWEI Confidential
 Access Network Product Training Technical Cases

battery 0 loop : connect

Environment Temperature : Normal Environment Humidity : Normal
Door alarm : Normal Water alarm : Normal
Fog alarm : Normal Battery Temperature alarm : Normal
Wiring alarm : Normal Acinput air switch : Alarm
Battery 1 Temp-Sensor : Normal Environment 1 Temp-Sensor : Normal
Environment Humidity-Sensor : Normal
【Cause Analysis】
- If there was a problem with the alarm information, but actually the device related to the alarm worked normally,
so I supposed that there must be a wrong logical signal information generated in the system.
- Based on the dbwin information collection, the problem came from the Power4875L that reported the alarm.
So, this issue was not related with the UA5000.
- Something has caused the Power4875L to send a wrong information to UA5000.
【Handling Process】
1. Based on the L2 further analysis about the dbwin information, the Power4875L really reported the alarm
status to the UA5000, so the problem was not related with the UA5000, but to the power system & monitoring
module.
2. Based on point 1, there are only 2 things caused this : the EPMU module or the AC input breaker have
broken.
3. Plug out and plug in the EPMU module. There was no effect.
4. Replacing the EPMU module with the new one. Unfortunately, the result is still not OK. The alarm still
existed.
5. The last, there must be a broken logical circuit of the AC input breaker of the PDU system.
6. Because this is internal circuit and the device was still under warranty, so we could not repair by our self. We
had to replace the entire power frame (PDU) system.
This is the explanation:

HUAWEI Confidential
 Access Network Product Training Technical Cases

On the back side of the AC INPUT breaker, there are two headers NO and C. Normally when AC Input
BREAKER is at ON status, the NO and C should be touched with each other, and when AC input breaker is at
OFF status, the NO and C are separated. In this way by NO and C we can detect whether AC input breaker is
actually ON or OFF, so NO and C can report digital signal to EMU (if NO and C is closed, report high level to
EMU; if NO and C isolated, report low level).
For this issue, it is probably the NO and C have some problems when AC breaker is actually ON, they are
isolated with each other, so reported low level for alarm status.

7. After replacing the entire power frame (PDU) system, the alarm was normalized. The state was became
normal, and the red alarm indicator of EPMU module was OFF. The problem has been resolved.
【Suggestions and Summary】
1. The ACinput Air Switch alarm was caused by the broken logical circuit of the device. It sent wrong logical
signal to the UA5000.
2. This circuit is placed on the back side of the AC input breaker.
3. Because this is internal circuit and the device was still under warranty, so we could not repair by our self. We
had to replace the entire power frame (PDU) system.
4. The dbwin information could give information whether the problem came from MSAN or the third party
device.

HUAWEI Confidential
 Access Network Product Training Technical Cases

DSLAM SmartAX MA5600 Troubleshooting Cases

25. MA5600 failed to be provisioned by OSS due to inconsistency in Software Version

of Active & Standby SCUB Boards

【Symptom】
It is reported by customer that one of their MA5600 DSLAM failed to be provisioned by OSS.
All other MA5600 DSLAMs were successfully provisioned by OSS.

Version of DSLAM: MA5600V300R002

OSS: Other Vendor`s OSS is being used in Customer`s Network.
【Alarm Information】
Null.
【Cause Analysis】
1- It was verified that MA5600 DSLAM was already visible on BMS N2000 then its mean no problem with the
configuration of SNMP parameters.
2- NBI & CORBA related process were already found running on N2000 as other MA5600 DSLAMs were
successfully be provisioned through OSS.
3- Status of SCUB board was normal but it may behave abnormality therefore we decided to switchover the
Services from Active SCUB slot-8 to Standby SCUB slot-7. Before Switching over, command "Display Data
Sync State" was executed in order to check the Data & Configuration syncronization between Active & Standby
SCUB.
It was observed by executing the command "display data sync state" that Active & Standby boards were failed
to syncronised with each other.Following is the Output After Execution of command.

MA5600config)#display data sync state

Data synchronization cancelled. The reason is: Software versions of active and standby boards are
not consistent
User Configuration data CRC check values of active and standby boards are inconsistent

4- When we checked the Version of SCUB boards then we found that both Version of LOGIC of both SCUB
boards was not same. As shown below:

HUAWEI Confidential
 Access Network Product Training Technical Cases

5- The version of mismatch of Logic may preventing DSLAM to be provisioned by OSS.

【Handling Process】
1- Execute the command "Duplicate Program" in oder to be have same Version of LOGIC on both SCUB
boards.
After the completion of Duplicate Progress, Checked the Version of LOGIC of Both Active & Standby boards &
both found to be same. as shown below.

2- Also the Data & Configuration between Active & Standby SCUB boards found to be syncronised with each
other, as shown below. At the same time the MA5600 found to be provisioned through OSS.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Suggestions and Summary】

If Active/Standby SCUB boards have different Versions then synchronization of data between active & standby
boards will not be consistent & different problems can be faced such as DSLAM failed to be provisioned by
OSS in case of abnornal sync state of Active & Stanby SCUB boards.

26. Some PPPoE users cannot access the internet due to problem in the negotiation

type

【Symptom】
The customer uses converter (FE to 100 Base-FX) to connect the DSLAM to the uplink device.
The connections are as following:
MA5600 ---> converter (FE to 100 Base-FX) ---> fiber cable ---> converter (100 Base-FX to FE) ---> S5238
switch.
After connecting the devices in the mentioned order , the customer informed us that some of the PPPoE users
cannot access the internet , and some of them can access the internet but the access speed is slow .
【Alarm Information】
Null
【Cause Analysis】
1- Wrong ADSL modem configuration.
2 - Fiber cable problem.
3 - Connectivity problem between Huawei devices (MA5600, S5328) and the converter.
【Handling Process】
1- We check the ADSL modem configuration for some of the users who cannot access the internet , and the
configuration was correct (VPI , VCI , user name , password) , and the used modem is compatible with Huawei
DSLAM .

2 - For the fiber cable we asked the customer to test the fiber cable , and the test result was good , so there was
no problem in the fiber cable .

3 - We checked the interface configuration on the S5328 with is connected to the converter , the interface auto
negotiation was disabled , and the speed was configured as 100 , and the duplex is full , then we used the
command "display interface GigabitEthernet 0/0/3" to check the interface information , we found that there is a
lot of errors (thousands) , we reset the interface counters by using the command "reset counters interface
GigabitEthernet 0/0/3 " , and we checked the interface again but the errors kept increasing .
Finally after enabling the auto negotiation on the interface and reset the counters the errors disappears , and
the problem was solved .
【Suggestions and Summary】

HUAWEI Confidential
 Access Network Product Training Technical Cases

Always check the interface negotiation when connecting Huawei devices to non-Huawei devices .
To check the interface mode in the MA5600 use the command "

MA5600(config)#display board 0/7

---------------------------------------
Board Name : H561SCUB
Board Status : Active normal
---------------------------------------

Subboard[0]: H531O2GS Status: Normal

Subboard[1]: H561E4GFA Status: Normal
-----------------------------------------------------------------------------
Port Port Optic Native MDI Speed Duplex Flow- Active Link
Type Status VLAN (Mbps) Ctrl State
-----------------------------------------------------------------------------
0 GE normal 1 - 1000 full off active online
1 GE normal 1 - 1000 full off active online
2 GE - 1 auto auto_1000 auto_full off active online
3 GE - 1 auto auto auto off active offline
4 GE - 1 auto auto auto off active offline
5 GE - 1 auto auto auto off active offline
-----------------------------------------------------------------------------

or you can use the command "display port state all" from the interface view :
MA5600(config-if-scu-0/7)#display port state all
-----------------------------------------------------------------------------
Port Port Optic Native MDI Speed Duplex Flow- Active Link
Type Status VLAN (Mbps) Ctrl State
-----------------------------------------------------------------------------
0 GE normal 1 - 1000 full off active online
1 GE normal 1 - 1000 full off active online
2 GE - 1 auto auto_1000 auto_full off active online
3 GE - 1 auto auto auto off active offline
4 GE - 1 auto auto auto off active offline
5 GE - 1 auto auto auto off active offline
-----------------------------------------------------------------------------

27. Abnormal ADSL Service due to traffic replication between PORTS in MA5600

【Symptom】
Customer reported abnormal HSI service in ADSL ports on MA5600 (V300R003C03B029), phenomena

HUAWEI Confidential
 Access Network Product Training Technical Cases

described as poor service and intermitent connection in PPPoE users in SITE A. ADSL lines checked and were
correctly synchronized and cooper lines were tested and normal.
【Alarm Information】
There is not any abnormal event or alarm related to the DSLAM or ports.
【Cause Analysis】
1. Check physical connections and normal state for ADSL port and modem synchronization to discar any
pysical problem. Without PPPoE session line is correct and no problem detected on cooper line.

2. Check general alarms and port related alarms, there was no any abnormal alarm related to the device, also
the CPU occupancy was normal while monitoring the test port.

2. Dial PPPoE session and check the traffic reaching the ADSL susbcriber on test port 0/9/0, even though port
was not saturated the session randomly disconnects and expected browsing speed is lower. Thus, checked the
line activation profile and the traffic table associated to the port. It was found that with lower traffic profiles the
problem is more evident.

3. Capture the traffic exchanged by testp port 0/9/0 to analyze the PPPoE session disconnection, previous
problem confirmed that not applying unknown-unicast traffic suppression leads to similar fault, but applying the
traffic-suppress function didn't helped to improve the service

4. Locate the MAC address of the traffic that is incorrect in service port 0/9/0, Its is found that received traffic
belong to different MAC address also connected in the same DSLAM equipment

HUAWEI Confidential
 Access Network Product Training Technical Cases

For some reason the traffic that belongs to port 0/14/14 is replicated to port 0/9/0 thus causing low rate and
bad performance for the ports.
【Handling Process】
1. Debug packet and internal port state, it found MAC address 0021-63e0-496a, appears and dissapear from
control board randomly, also internal registries are abnormal. Conclusion with R&D shows that there is some
interference (crosstalk) due to internal registry change in the ports.

2. So it's needed to apply patch solution replacing version IO packet file with C03B029IOSP01.bin

After applying the patch the traffic from other MAC didn't replicated in the test port. So the issue was solved.
【Suggestions and Summary】
Null.

28. How to collect lastword in BIOS mode in order to troubleshoot MA5600 SCU

keeps rebooting in BIOS mode issues（FAQ）

【Symptom】
How to collect lastword in BIOS mode in order to troubleshoot MA5600 SCU control board keeps rebooting in
BIOS mode issues?
Sometimes during SCU version upgrade, we find some SCU board keeps rebooting in BIOS mode after
upgrade; sometimes in commerical site suddenly SCU is keeping rebooting in BIOS mode. For these cases, we
should collect lastword in BIOS mode in order to send to HQ experts for further analysis.
【Alarm Information】
NULL.
【Cause Analysis】
NULL.
【Handling Process】
The method to collect lastword in PVM BIOS mode is as following:
Press <D> key to stop auto-boot 7 <- press D
Save extended BIOS enable start flag...OK!
Main Menu

HUAWEI Confidential
 Access Network Product Training Technical Cases

==============================================
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 : ^ [ <--press ESC key

Please input password: <--input password：debugmode

=============In Debug Mode====================

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 : s <--input s key

Please input password: <--input password：lastword

Set sucessfully.

=============In Debug Mode====================

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 : 0 <-- press 0 to reboot normally

Now system will boot from flash memory.

Testing Flash memory... <-- then will output lastword

【Suggestions and Summary】
NULL.

HUAWEI Confidential
 Access Network Product Training Technical Cases

29. PPPoE users go offline after going online for 2-5 minutes due to old modem

firmware

【Symptom】
The customer informed us that the some of the ADSL users in one site have problem in internet access .
The problem descripiton was that some of the ADSL users in the site cannot go online for more than 2-5
minutes and after that the modem loses the syncronization with the ADSL port and cannot sync again .
Networking:
MA5600 ---> S5328 ---> ME60E(BRAS) ---> internet .
【Alarm Information】
Null
【Cause Analysis】
1 - Physical interconnection problem in MDF room.
2 - Copper line problem from the MDF to the user’s houses.
3 - Service board problem.
【Handling Process】
1 - We checked the physical connections from MDF to the MA5600 , and tested all the ports that have the
problem , and we didn't find any problem .
2 - We asked the customer to test the copper line from the MDF to users house , to check if there is any
problems , and the customer replied that there is no problems in the copper lines .
3 - The ports which have the problem are not in the same service board , even though we changed one of the
boards and the problem was not solved .
4 - After checking with the customer and conntacting the users , we found that all the users uses the same type
of ADSL modem (Linksys WAG 160N) the also the same firmware version , so we tried other ADSL modem
(Huawei ADSL modem) and there was no problem , after that we upgraded the firware for one of the users
ADSL modems to the last version from the support website of linksys , and the problem was solved .
【Suggestions and Summary】
Always check the compatiblity between the used ADSL modem and Huawei devices.

30. VOIP doesn't work because of wrong configuration of DHCP mode

【Symptom】
The customer complain about the voip problem on one ip dslam (ma5600v300r003c05)
The topology is as follow:
phone ==> Modem==>DSLAM==>Switch==>ME60 ==>IP backbone==>Soft Switch
【Alarm Information】
Null
【Cause Analysis】
After checking the DSLAM we found all configurations (services ports and profiles) are normals and the
other services (internet and iptv) are running normally but when we test the voip we cannot initiate
the call.
The solution chosen by our customer is:

HUAWEI Confidential
 Access Network Product Training Technical Cases

1.pppoe for internet service

2.pppoe for iptv
3.dhcp for voip
After that we have checked the dhcp configuration mode:
normally there are 2 modes:
The l2 forwarding mode of dhcp relay, packets is transparently transmitted.
The l3 forwarding mode of dhcp relay has three forwarding modes:
The dhcp option60 mode in which a dhcp server is selected based on option60 domain.
The mac address segment mode of a dhcp server is selected based on the mac address segment to
which the source mac address of the dhcp packet belongs.
The standard dhcp mode of a dhcp server is selected based on the ip address of the vlan l3 interface
that forwards dhcp packets.
Using this command we have checked the dhcp mode used by this dslam :
command:
ma5600(config)#display dhcp config
dhcp relay mode: layer-3

【Handling Process】
the dslam in this solution is a l2 forwarding equipment, and the dhcp mode was setting wrongly , after
changing the dhcp config mode from l3 to l2 the problem has been solved
command:
dhcp mode { layer-2 | layer-3 { option60 | mac-range | standard } }
【Suggestions and Summary】
Check first the dhcp configuration.

31. Subscriber line connection problem affect quality of internet and IPTV service

【Symptom】
On one MA5600 site, customer feedback there is some internet problem on one VIP subscriber,the
phenomenon is:when the subscriber acces to internet , sometimes the service appear "micro-cut".
ma5600 version is v300r003c05，service board is adge，provide iptv service and internet service。
network topology is: iptv platform+internet outlet---mpls backbone---bras---switch---ma5600---modem---stb +
pc。
modem provide internet interface （used for internet service） and video interface（used for iptv service）
。
【Alarm Information】
Query the crc warning information on Sagem modem, we found the quantity of crc error increased, and
increased very fast.
【Cause Analysis】
Internet service appear "micro-cut", it should be the packet lost revising end-to-end, so we should locate where
these packets lost happen were.
【Handling Process】
1. Connect PC to internet interface on modem, ping dns of internet service, packet lost seriously.
2. Connect STB to video interface on modem, watch TV, we found mosaic is seriously.
3. Check the traffic on uplink port of ma5600, the occupation is 400M; there is no bottleneck about bandwidth.
HUAWEI Confidential
 Access Network Product Training Technical Cases

4. Telnet to ma5600, ping the gateway of management ip, the gateway is on bras, there is no packet lost, it
means there is no congestion between ma5600 and bras.
From the analysis we can see, this problem only affect this subscriber, we should check this adsl port, adsl line
problem.
5. Login to mode, query the crc warning information on sagem modem, we found the quantity of crc error
increased, and increased very fast.
The crc error on modem is caused by quality of line, check the connection on MDF side, we found the
connection of cable from ADGE bord to MDF is not very strong, we correct the connection, make it strong and
stable, then test service again.
PC access internet is normal, there is no ''micro-cut" and there is no packet lost about ping dns, also the TV
quality if normal , there is no mosaic .
【Suggestions and Summary】
In engineering period, the haraware installation team should enhance the quality consciousness to avoid such
kind problem.

32. Interruption of Broadband Services (HSI & IPTV) due to ADSL sync instability

between CPE & DSLAM

【Symptom】
We received one complaint about that adsl modems of all subscribers belong to ma5600 lost their adsl
synchronization after five minutes.
the faulty phenomena is that when modem starts to sync with dslam & successfully synced & will sync lost
after 5 to 10 minutes, and it never turn to sync unless manually resetting the modem.
【Alarm Information】
Null
【Cause Analysis】
1- with the help of command line, i checked the status scub (control board) & all adee (line boards), control
board & line boards found normal.
2- Its atm-ping from DSLAM to modem also found ok during syncronization (5 to 10 minutes).
3- Different parameters of adsl line profiles was verified, all parameters found configured.
4- Maximum Downstream Interleaved Delay' is one of parameter of ADSL line & it was already configured with
6 (ms). Its normal range is (0~255 ms) but optimized value can be selected according to ADSL line conditions.
5-The larger the interleave delay, the higher the ADSL connection stability i.e modem sync but longer the
transmission delay, so low value (6ms) of Interleaved delay is the possible cause of sync instability of modems.
But it need to select optmized value of interleaved delay by which adsl stability can be achieved.
【Handling Process】
I modified the adsl line profile that was assigned to all adsl ports & configured the 'maximum downstream
interleaved delay' with 16(ms).
Issue wasresolved after modified the maximum downstream interleaved delay' with 16(ms).
【Suggestions and Summary】
As interleaved delay was configured with 6(ms) which is very low thats why
the larger the 'maximum downstream interleaved delay, the higher the adsl2+ connection stability, but the
longer the transmission delay.

HUAWEI Confidential
 Access Network Product Training Technical Cases

As interleaved delay was configured with 6(ms) which was very low and causing the adsl sync instability.
ADSL sync achieved the stability after increasing interleaved delay from 6(ms) to 16(ms).

MSAN SmartAX MA5600T Troubleshooting Cases

33. Poor Internet ADSL service due to unknown unicast packets storm from uplink

port

【Symptom】
There's a DSLAM MA5600T (V800R007C01SPC100) connected to a switch Huawei Quidway S5328C-EI-24S
(V100R005C01) according to the Network Topology Diagram:

The ADSL subscribers are configured with traffic tables for downstream speed around 1 to 4 megas. It's almost
impossible for a subscriber to authenticate with PPPoE. When authentication rarely succeeded, the navigation
is so poor that no webpage opens normally. Ping to google reflects 80% of lost packets.
【Alarm Information】
In order to troubleshoot the problem, I connected 2 modems at ports 0/1/2 and 0/1/3. Only with ADSL link on,
no PPPoE authentication the traffic of the ports are:
IHUAW2_CIUDADELA_CHOFERES(config)#display traffic 0/1/2

HUAWEI Confidential
 Access Network Product Training Technical Cases

{ <cr>|channel<K> }:
Command:
display traffic 0/1/2
Querying, please wait...
-----------------------------------------------------------------
Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps)
-----------------------------------------------------------------
0/ 1/ 2 0.0 5739.6
-----------------------------------------------------------------
IHUAW2_CIUDADELA_CHOFERES(config)#display traffic 0/1/3
{ <cr>|channel<K> }:
Command:
display traffic 0/1/3
Querying, please wait...
-----------------------------------------------------------------
Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps)
-----------------------------------------------------------------
0/ 1/ 3 0.0 6471.6
-----------------------------------------------------------------
【Cause Analysis】
The switch is receiving a lot of unicast packets with an unknown MAC destination address. According to normal
operation, the unknown MAC-address packets are flooded to every port of the switch in order to find out the
correct destination. The DSLAM receives the flooding of unknown unicast packets and just like the switch, the
MA5600T forwards the traffic to every ADSL port causing an unwanted traffic of around 5 to 7 megas in each
port. Due to this, a suscriber that's configured with 3 megas of internet neither go online nor surf the web
because of the unwanted traffic totally occupies the channel.
【Handling Process】
In order to solve the issue, a discard unknow unicast packets policy was enabled on the massive internet
service vlan (vlan 201) with the following commands:
IHUAW2_CIUDADELA_CHOFERES(config)# vlan packet-policy 201 unicast discard
After enabling this filter the unwanted traffic in every port reduced dramatically:
HUAW2_CIUDADELA_CHOFERES(config)# display traffic 0/1/2
{ <cr>|channel<K> }:
Command:
display traffic 0/1/2
Querying, please wait...
-----------------------------------------------------------------
Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps)
-----------------------------------------------------------------
0/ 1/ 2 0.0 110.2
-----------------------------------------------------------------
The internet navigation experience improved accordingly and PPPoE session remains stable.
【Suggestions and Summary】
HUAWEI Confidential
 Access Network Product Training Technical Cases

Before finding the solution, another method was tryed that apparently provided the solution however caused a
side-effect issue. The first option tryed was applying traffic-suppress filter to every vlan in the upstream port:
HUAW2_CIUDADELA_CHOFERES(config)#interface giu 0/20
HUAW2_CIUDADELA_CHOFERES(config-if-giu-0/20)#traffic-suppress all unicast value 1
HUAW2_CIUDADELA_CHOFERES(config-if-giu-0/20)#quit
After applying the traffic-suppress filter, the unwanted traffic improved:
HUAW2_CIUDADELA_CHOFERES(config)#display traffic 0/1/2
{ <cr>|channel<K> }:
Command:
display traffic 0/1/2
Querying, please wait...
-----------------------------------------------------------------
Frame/Slot/Port Rx Traffic(Kbps) Tx Traffic(Kbps)
-----------------------------------------------------------------
0/ 1/ 2 0.0 115.8
-----------------------------------------------------------------
However a side-effect appeared, this filter is applied to every packet of every vlan in the upstream link. Because
of this some vlan of corporate users that utilize routing protocols may be affected because of the packets
discarding. This solution is not suggested for being inaccurate.
The best solution is to apply the filter only to massive internet vlan (in this case is vlan 201). The corporative
services remain unchanged and therefore those services are not affected.

34. The MA5600T not detected any multicast flow of IGMP program because uplink

port not configured IGMP

【Symptom】
Customer informed the IPTV service failed. All the user failed to watch the IPTV program. During
troubleshooting at site found the MA5600T not detected multicast flow for IGMP program.
【Alarm Information】
BNR_V1024(config)#display multicast flow-statistic vlan 600 ip 239.192.100.1
Command is being executed, please wait...
Multicast flow statistic result: 0(kbps)
【Cause Analysis】
The GICD board is faulty
- The SFP of uplink port is faulty.
- The uplink is not configured the VLAN for IGMP program
- IGMP program is not configured into system
- The source IP address of IGMP program configured wrongly.
- Upper layer network side is faulty
- The uplink port not configure the IGMP
【Handling Process】
The GICD board is running as normal
- The SFP module is normal since the link is normal

HUAWEI Confidential
 Access Network Product Training Technical Cases

- The uplink port already configured VLAN 600 for IPTV

- All the IGMP program and source IP address is configured correctly
- The upper layer network side already recieved Multicast flow for IPTV
- After chekced the uplink port status, the port 2 is online instead of port 0 for GICD (active) board at slot 19.
- Checked from MA5600T, only port 0 configured the IGMP.
- After configured IGMP for the port 0/19/2 as below:
BNR_V1024 (config-mvlan600)# igmp uplink-port 0/19/2, the problem solved.The MA5600T now can detect the
multicast flow for IGMP program.
【Suggestions and Summary】
If engineer or customer changed the uplink port for the MA5600T, please remember to configure IGMP for the
new uplink port.

iManager NMS Troubleshooting Cases

35. Unable to telnet sites via n2000 client

【Symptom】
For customer use their intranet to connect N2000 server and clients.
They applied an ipfilter to the server. Since, they want to limit the access to the server. After that client users
can’t telnet sites via server.
【Alarm Information】
There is no alarm indication in NMS, but Client users can use the client without any issue. But they cannot
telnet site by using the telnet function in device main menu. Except that all other services are ok.
【Cause Analysis】
So we try to directly telnet the site also. It was successful. Then try to telnet from server. That was successful
too. So I check the IP filter of the server create by the customer in Solaris system. As per we know our NMS use
the port 9803 for communicate between server and client. Normally we can see this port when we try login the
NMS client interface. So customer has permit only that port for communicate between server and client. They
have blocked other ports. So don’t any doubt at that time. Since 9803 is for client server communicate. So we
got packet capture from the client side PC while telnet. Then we saw that there is some traffic from port 9811
sends out.
【Handling Process】
So we checked the /etc/ipf/ipf.conf file in server we saw only 9803 is allowed by the system. So we changed
the configuration to allow the 9811 as below.
block in from 10.64.66.82 to 10.64.80.10
block out from 10.64.80.10 to 10.64.66.82
pass in quick from 10.64.66.82 to 10.64.80.10 port = 9803
pass out quick from 10.64.80.10 port = 9803 to 10.64.66.82
pass in quick from 10.64.66.82 to 10.64.80.10 port = 9811
pass out quick from 10.64.80.10 port = 9811 to 10.64.66.82
【Suggestions and Summary】
If we want to block client to access server, allow necessary actions for n2000 server. We have to change the
HUAWEI Confidential
 Access Network Product Training Technical Cases

/etc/ipf/ipf.conf file in Solaris system. If you don’t want to allow client users to telnet devices via client we need
to block the 9811 port.

36. OSS failed to get alarms from N2000 BMS server due to No more free space for

the Data and log of the IPMS database

【Symptom】
The issue reported that NOC system is not getting alarms from N2000 server.
【Alarm Information】
Null
【Cause Analysis】
The CORBA interface is not properly configured.
2. The NOC server is pingable from N2000 Server.
3. Disk space of N2000 server is also enough.
4. After Log in to System Monitor client, checked the free space of different Databases, only 0 MB Data Free
Space found for IPMS DataBase.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Handling Process】
Checked the Dump DB Dump settings & no any parcentage configured for dumping.
Configured the Dump Settings , set the 1% of Database to be dumped as according to below figure.
NOC/OSS system is starting to get alarms after dumping the Database of IPMS.

Checked the Dump DB Dump settings & no any parcentage configured for dumping.
Configured the Dump Settings , set the 1% of Database to be dumped as according to below figure.
NOC/OSS system is starting to get alarms after dumping the Database of IPMS.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Suggestions and Summary】

The dumping operation automatically deletes the corresponding data in the database, which releases the
database space. We can set whether to perform the periodic dumping, and set the dumping period.

37. ATU-R terminal managment menu is not displayed on BMS GUI due to it is hidden

【Symptom】
BMS added ATU-R terminal managment to performance ADSL terminal queries, configuration, ping tests, FTP
tests, PPPoE emulation tests and terminal upgrades but menu is not on GUI.
【Alarm Information】
ATU-R terminal managment menu is not found.
【Cause Analysis】
Menu is hidden on BMS GUI.
【Handling Process】
As the menu is hided it is necessary to enable it with following procedure:
For example: to enable the menu for MA5100V1's ATU,
1. Identify following file in the Client PC.
\client\style\defaultstyle\conf\bms\ma5100v1\adsl\adslMenu.xml

2. Identify following line in that file and then add --> at the end of the line
<!--************************Atur manager pupup**************
Identify following line in that file and then add <!-- at the begining of that line
************************Atur manager pupup**************-->
3. After that restart the Client to test it.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Suggestions and Summary】

NOTE:
1. For other devices related files are followings:

\client\style\defaultstyle\conf\bms\ma5100v1\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5100v2r1\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5105\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5300v1\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5600tv8\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5600v3\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ma5605\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ofa5920v3\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ua5000\adsl\adslMenu.xml
\client\style\defaultstyle\conf\bms\ua5000g\adsl\adslMenu.xml

2. For IPMB and MA5600V3 which version is older than MA5600V300R003C03B230 performance the
same modification on file named client\style\defaultstyle\conf\bms\bmscommon\adsl\adslMenu.xml

3. For MA5600V3 which version is newer than MA5600V300R003C03B230 performance the

same modification on file named
client\style\defaultstyle\conf\bms\lightweight\adsl\ma5600v3\**_popupmenu.xml

38. Fail to synchronize ADSL port ALIAS in U2000 with description in MA5600T due to

default value off in Sybase DB

【Symptom】
Customer reported that the ADSL port description configured through CLI in MA5600T does not synchronize
with the GUI interface in the U2000 client.

Even though customer synchronize the GUI interface, the configured description in MA5600T does not appear
in the U2000 client.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Alarm Information】
Log events in U2000 system does not represent any problem about syncrhonization or related to the operation
described.
【Cause Analysis】
1. Review processes for collecting information from NEs in the System monitor, all important process are up
and started so there is no reason to affect this operation.
2. Confirmed normal synchronization of other functions from the NE, the ADSL port can be configured normally
and all the alarms and cofig normally synchronize, so the trap exchange is normal.
3. Review the related option in the Sybase configuration, it's found that by default the related flag value is OFF,
so the port description will not appear in the U2000 GUI unless it is changed.
【Handling Process】
Need to perform the follow command to enable the switch.

Step1. Login the sysbase:

# cd /opt/sybase/OCS*/bin
# ./isql -SDBSVR -Usa –P<sa password>

Step2:
update BMSDB..bms_cfg_tab
set CfgValue='1'
where CfgName like '%BMS_USERLABEL_CONSISTENCY_TYPE%'
go
update BMSDB..bms_cfg_tab
set CfgValue='0'
where CfgName like '%USERLABEL_FROM_DEV_FLG%'
go

Step3:login U2000 System Monitor to restart the bmsXdsl process

AFTER THIS OPERATION IS PERFORMED, THEN THE DESCRIPTION AND ALIAS ARE NORMALLY
SYNCHRONIZED.
【Suggestions and Summary】
Null

HUAWEI Confidential
 Access Network Product Training Technical Cases

39. U2000 script importing ceased due to inadequate SDH instances

【Symptom】
Some telecommunication carrier in Saudi Arabia wanted to change a server for U2000. When importing the
U2000 script of a huge network which consisted of over 5898 SDH NEs, an alarm was prompted and the
importing process was ceased.

【Alarm Information】
GNE_NUM_LIMIT_OVER, Location information: The number of Gateways of NE Manager nemgr_sdh_5354
exceeds.
【Cause Analysis】
By inquiring the old U2000 server, we found 10 SDH instances were deployed for the huge network. So we tried
to deploy more SDH instances. By default, there was only one instance for the SDH NE MANAGER. And the
maximum NEs one SDH NE explore can manage is 500. When the number of NEs is beyond the management
capability of an SDH explorer, GNE_NUM_LIMIT_OVER would be prompted.
【Handling Process】
Log in to the MSuite, and click the Deployment Package tab. Right-click the SDH NE MANAGER and add 9
more instances. And finally we succeeded in importing the U2000 script into the new server.
【Suggestions and Summary】
Null

40. The problem of the arithmetic of the node and link sequence leads the SDH Node

Insection Failed Issue

【Symptom】
During Node insection operation in SDH Network Expansion Wizard, the error happen with the message.
【Alarm Information】

HUAWEI Confidential
 Access Network Product Training Technical Cases

The Protection subnet modification fails in the expansion. Error code:1091633195

【Cause Analysis】
1.Confirm that the version between equipment and NM are matched;
2.Check and confirmed that the current application are not in the list of restrictions for "Node Addition on Fibers";
3.By analysis with NML_SDH logs & database from real-network, it’s found that the core arithmetic of the
node/link sequence got some limitation during some special condition.
The root cause is:
The nodes and links in protection subnet should be sequential, such as clockwise or anti-clockwise.
When a new node to be inserted into a MSP Ring, the new one and all other exist nodes’ sequence should be
re-calculated.
The arithmetic of the node/link sequence describe here:
All the nodes and links id will be taken out to handled, if the first link’s source NE ID is different with the minimal
Physical NE ID, the code will be lead to a death-circulation, when the counting of this evoked procedures up to
the upper limit, this error will be occurred
For example, The diagram shows here:

The link id was: {1,2,3,4,5,6,7,8}

Firstly, coding program to handle the linkID = 1, the source NE of this link is GoiSan_COT,
but the minimal Physical NE is CheongJu_COT（6-4）;
the circulation will be running to death-end until error happen, then arithmetic quit.

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Handling Process】
Work around:
1. Configure the logic system on the node which will be added in the ring first, then when finish the Expansion
Wizard, user can directlly searched out the protected subnet, it will save the time on added node during
configuration process;
2. Then delete the protection subnet from the NM, remind here don't select "Delete these trails, which pass the
protection subnet (from the network layer of the NM)";
3. Implement the expansion wizard to adding the nodes;
4. Manual search the protection subnet.
5. Stop the MSP protocal first then start the MSP protocal.
Finished. the nodes can be added successfully.

【Suggestions and Summary】

if we meet the problem of expansion wizard, the important things are check the restrictions for different
application scenario; then because normally for this scenario issue, we can not reoccur the issue every time, so
if we want get the rootcause, field engineer shall immediatelly collect the Nemgr_sdh and nml_sdh log as soon
as possible together with the error snapshot.

41. Failure to Modify Trails for Metro 500 and Metro 1000 due to not supporting Time

Division Mode

【Symptom】
After creating a VC12 trail, a user attempted to modify its timeslot from 2 to 13. However, the modification
failed, and the U2000 displayed the error message:"Cross connection source conflicts, Error Code:38746".
【Alarm Information】
"Cross connection source conflicts, Error Code:38746"
【Cause Analysis】
Both the T2000 V200R007C03 and the U2000 V100R002C01 support timeslot modification for created t
rails. On the T2000 V200R007C03, a user needs to delete a trail with its configured services before m
odifying its timeslots. Then, the user needs to recreate services, using original source and sink but mo
difying the timeslots that the services occupy. This mechanism may cause a short-term service interrup
tion before the timeslot has been modified successfully.
The mechanism for modifying trails has been improved on the U2000 V100R002C01. That is, new ti
meslots are added before the original ones are deleted. In this manner, the service interruption period
is minimized.
1. In T2000, The modification policy is “Deleting service first ,then create new service” In U2000,
The modification policy is “adding service first ,then deleting new service”.This is a optimization and the
object for optimizing is reduce the service interrupt time length.
This optimizing can reduce service interrupt time very much, and the problem is the Metro500 does
not support: “the same resource are exist at same time”.

2. For example: Bellow trail in red color will be changed to the trail in red color:
2.1 The old policy in T2000 is: Deleting cross-connect:1,2,3--->Then create cross-connect:4,5,6.

HUAWEI Confidential
 Access Network Product Training Technical Cases

The interrupt time length is same with the methods--->Directly inactive the trail then recreate th
e service;
2.2 The new policy in U2000 is: Create cross-connect first:4,5--->Then modify crocess-connect “3” T
o “6”
--->Last delete create cross-connect:1,2--->The interrupt time length can be reduced very much.

【Handling Process】
Analysis on the logs shows that the user failed to activate a cross-connection . The cause is that the devices do
not support cross-connections with the same source. Therefore, a cross-connection source conflict occurred
between the new trails and the original trails, and the trail modification failed.

Confirm with equipment part , that the OptiX Metro 500 which version is earlier thatn 1000 V300R005
(5.37.05.12) and all OptiX Metro 1000 do not support cross-connections with the same source, which causes a
failure to modify trails.

The only workaround for this scenatio is deactivate the original trails, modify their timeslots, and activate the
trails again. then the trail service time slots can be modified.

Solution:
Replace the OptiX Metro 500 with the OptiX OSN 500.
【Suggestions and Summary】
1. When front line meet this scenario issue, frontline engineer must understand first that the error code with 5
digit like "3xxxx", "4xxxx" is the error code reported by NE host , so for this type error code, we shall analysis
the NE log first instad of NM part.
2. This is a optimization of U2000, The optimization reduce the service interrupt time during modify service.

42. Alarm overflow dump function set as a high value caused U2000 system hard disk

usage to high

【Symptom】
harddisk usage is too high, especially /opt/Sybase/data is high to 97%, and there is a alarmdb_dev.dat file
under /opt/Sybase/data folder too big about 19Gb

HUAWEI Confidential
 Access Network Product Training Technical Cases

【Alarm Information】
When loging in, U2000 client will give the prompt "harddisk usage is too high".
【Cause Analysis】
1.useless file as log (automatic script).
2.alarm overflow dump function doesn't work or the threshold is too high.
3.Volume of lv_nms_data is not enough.
【Handling Process】
1.delete useless log (automatic script) :

# cd /opt/HWENGR/engineering/tool/hdcleaner
# ./start_solaris.sh

And check after : # df -hk /opt

2.check the relational process of U2000 is start or not

HUAWEI Confidential
 Access Network Product Training Technical Cases

set the alarm overlow dump threshold as a smaller value (we changed it form 1,000,000 to 300,000)

click adminstration-->task management-->overflow dump, choose the alarm or event object and find the
“Maximum capacity” is set to a smaller value

3.extend the volume of lv_nms_data

Check the free space in datadg group :
vxdg -g datadg free
and after try to extend the volume lv_nms_data +10giga for eg
vxresize –g datadg lv_nms_data +10g
【Suggestions and Summary】

After extending the volume operation finished, the problem solved.

The root reason should be alarmdb database is too big, but actually it is used only 2%.
the overflow dump should be set as a standard value. Because everyday the alarm database size is increasing,
if U2000 don't dump the alarm when it reach to a threshold, system will extend the database automatically. and
this database cannot be decreased or deleted, so it will become bigger and bigger.

43. SNMP-NBI Connectivity towards 3rd Party Server or Terminal

【Symptom】
In TATA account iManager U2000 has been deployed for monitoring and managing their IP/MPLS network
which includes the links which carry their own traffic and the links which have been leased to Enterprise
Customers.
The customer wanted to integrate a 3rd party server {Netcool in this case} with HUAWEI iManager U2000 using
SNMP-NBI. Purpose behind the integration was to fetch the alarm data on the Netcool device and use it to
generate a code for extended monitoring of the leased Enterprise links and the connectivty laid down for
internal communication.
【Alarm Information】
Problem Faced:
A concern was raised by the customer mentioing that the alarm traps received by them on their Netcool device
contain only a single OID value, neither the severity of the alarm nor the complete alarm code is being
reflected.
On the first note it found that there was an issue with the reachability of the Netcool device but even after the
device was made reachable the problem persisted.
On analysing various aspects and testing using different scenarios it was concluded that there was a limitation
with the SNMP-NBI license availability. The available license allowed only two NBI's to be configured and the
HUAWEI Confidential
 Access Network Product Training Technical Cases

new configuration which was being done was the third one. The same was communicated to the field team &
customer.

【Cause Analysis】
After the above findings again a test session was organized but the result was still the same only single OID
traps were received at the Netcool device. On analysing the problem it was found that due to some dummy
configurations for NBI-SNMP wrong traps were being received on Netcool.

【Handling Process】
When the dummy configurations for NMS3 to NMS6 were removed and testing was initiated the traps received

HUAWEI Confidential
 Access Network Product Training Technical Cases

at the Netcool device contained sixteen OID values {major requirement of customer} , alarm severity and
complete alarm code were received in the traps.
【Suggestions and Summary】
Whenever any such issue is faced the following points should be checked:
1. The reachability to the device.
2. The license availability & capacity.
3. Configuration should be cross-verified.

44. On remote scenario, you can use U2000 ping, but cannot use command lines to

ping

【Symptom】
Networking diagram
For oversea customers operate the remote equipments, I developed an E-Lab scenario in the Shenzhen
Huawei training center. The following figure shows the diagram for E-Lab networking. In the network, it consists
of E-lab native Ethernet services configuration which includes NMS information, physical information and
connection.

Networking description
As shown in the figure, there is a ring topology; NE 96, NE 97 and NE 99 connected to each other by
microwave links. NE 96 and NE 97 adopt OptiX RTN 950; NE 99 adopts OptiX RTN 980. NE 96, NE 97 and NE
99 connect to network management system (NMS) by LAN switch. You can use your own computer to login the
U2000 client in Shenzhen Huawei by E-lab, and then you can manage the NEs. On the other side, in order to
verify the Ethernet service configuration, some PCs connect Ethernet ports of the devices, respectively; PC 1
connects NE97 EM6T-port1, PC 2 connects NE97 EM6T-port2, PC 3 connects NE99 EM6T-port1, PC 4

HUAWEI Confidential
 Access Network Product Training Technical Cases

connects NE99 EM6T-port2. The IP addresses of PC 1-4 are fixed, respectively, PC 1: 10.77.242.201, PC
2:10.77.242.202, PC 3:10.77.242.203, PC 4:10.77.242.204. NE99 EM6T-port1 and EM6T-port2 connect to the
LAN switch respectively.
【Alarm Information】
I had created an E-line service between NE 96 and NE 97 by E-Lab client PC. On the E-Lab U2000, select an
NE 96, right-click, and then choose Tool > Ping from the shortcut menu. The NE 96 can be pinged NE 97 and a
message indicating operation succeed is displayed. If I use command lines to ping the NE on the E-Lab client
PC, the NE cannot be pinged.
【Cause Analysis】

The E-line service between NE 96 and NE 97 configured faultily;

The microwave link is abnormal;

Because Ping function need to start eam_agent process. If you cannot start this process, ping the NE
will be failed;

【Handling Process】

1. On the real lab, NE 96 connected PC, this PC can use command lines to ping PC 1. So, make sure
these configurations accurately and the microwave normally.
2. Log in to the U2000 system monitor; check eam_agent process enabled from process monitor.
3. Confirm the problem section from U2000 server to E-Lab client

PC.

4. The IP address of E-Lab client PC isn’t the same segment with IP address of U2000 server. The IP
address of E-Lab client PC is 192.168.1.131; the IP address of U2000 server is 10.77.242.100.
U2000 ping function start to U2000 server. So, the U2000 ping function and using PC command lines
to ping are different. On the E-Lab scenario, only select the U2000 ping function to verify the E-line
service.

【Suggestions and Summary】

U2000 ping function (Tool > Ping) is sending ping packets to a remote host to check whether it is reachable. To
check the network connectivity or the line quality, you can also perform the ping test.
The U2000 ping function and using PC command lines to ping are different. The U2000 ping function starts
from the NE, but not starts from the board.

HUAWEI Confidential