Monthly Archives: February 2016

How to change the MA5600T Boards

Digest: The H805ADPD, H805VDMF, H805VDRD, and H80ASHLM boards of MA5600T

product need to be upgraded because their DDR1 memories are changed. Such a change is for

customers using these boards.

Sub-product line: Access network             Product: MA5600T

Problem Description

1.Product Engineering Code Change

MA5600T

MA5600T

2.Change Strategy

1) Change Scope: The sites with H805ADPD,H805VDMF,H805VDRD,H80ASHLM boards

2) Change relation : The new boards are produced with new DDR1 memories, all the function

and performance are the same ,the BOM is the same too. The boards current used in sites

won’t be effected.

3) Change finish date :

H805ADPD:2010-12-31.Huawei will use old DDR1 memories to product board to deliver before

2010-12-31, and please push the related office to upgrade the corresponding IO board package files

and software patches as soon as possible .We will deliver the new board after 2010-12-31, and

won’t be permitted to deliver the boards if the office didn’t upgrade the corresponding patches.

H805VDMF, H805VDRD, H80ASHLM:2010-9-30, please push the related office to upgrade

the corresponding IO board package files and software patches as soon as possible.

3. Spare part Strategy

The new board as spare part

Impact and Risk

Functions and performances of the upgraded boards are not affected if the corresponding IO

board package files and software patches were not upgraded

H805ADPD:Proved by test ,the abnormal rate arrived about 30% if the board without

corresponding IO board package files, exceed normal .

H805VDMF,H805VDRD,H80ASHLM:Proved by test, the abnormal rate didn’t increase,

but it also exist the same risk as H805ADPD board.

Measures and Solutions

Solution:

The related office which used these kinds new boards or will switch to theses kinds new

boards ,please upgrade to the corresponding IO board package files and software patches ,

as listed in the following table.

MA5600T_1

Attachment

NUll

TwitterLinkedInGoogle+FacebookPinterestTumblrStumbleUponRedditShare

How to precaution the using problem of Huawei MA5603T product?

Sub-product line: Access Network Line   Product: MA5603T

[Problem Description]

In the 6 U MA5603T, when the H801BIUA board with the software of 117 or earlier versions works with

the SCUN, SCUL, and SCUF control boards, the H801BIUA board fails to register and is in the faulty

state all the time, and the board in slot 0 resets repeatedly.

[Cause Analysis]

The software version of the H801BIUA board is too early. In the 6 U MA5603T, the H801BIUA board

is installed in slot 12, and in other products which use the H801BIUA board with the software of 117

or earlier versions, the H801BIUA board can only be installed in slot 0. If the H801BIUA board with

the software of 117 or earlier versions is installed in slot 12 of the MA5603T, the master-slave

communications of the boards in slots 12 and 0 conflict with each other, the board in slot 0 resets

repeatedly and the H801BIUA board is in the faulty state all the time.

[Impact and Risk]

1. In the 6 U MA5603T(Huawei OLT), the H801BIUA board can not start up in the normal state.

2. In the 6 U MA5603T, the board in slot 0 resets repeatedly.

[Measures and Solutions]

Avoidance Measures:

Do not use the H801BIUA board with the software of 117 or earlier versions in the MA5603T.

Solution:

When the problem occurs, re-load the software of the H801BIUA board to the version that matches

the host version through the serial port cable (the BOM of the serial port cable is 04028285) of the

H801BIUA board. Upgrade the software of the H801BIUA board through the commissioning

subboard and then load the BIOS software online through the host.

[Supplementary Information]

The methods of checking the software version of the H801BIUA board are as follows:

(1) If the board is in use, run the display version command through CLI on the host.

For example:

MA5603T(config)#display version 0/12

Main Board: H801BIUA

—————————————

Pcb            Version: H801BIUA VER B

Mab           Version: 0001

Logic          Version: (U21)102

Main CPU:

APP           Version: 118(2009-1-17)

BIOS          Version: 118

SubClockBoard:

PCB        Version: H802CKMA VER B

Software    Version: 103

Bios        Version: 103

—————————————

The number after “APP Version” is the APP version of the board. The number after “BIOS Version” is the BIOS version of the board. (2) Use the related board commands to query the software version through the serial port on the board.

BIUA>1

SFT ver:118

BIO ver:118

PCB ver:B CPD ver:(U21)102

Cmp tim: Jan 14 2009 14:47:25

H802CKMA SFT ver:103

BIO ver:103

PCB ver:B

BIUA>

(3) Manually upgrade the BIOS and APP. 1) Install the H801BIUA board in the shelf and then connect the PC serial to the H801BIUA

board through the commissioning subboard H561SEDB. Log in to the H801BIUA board through

the serial port of the PC. For how to log in to the H801BIUA board through the serial port,

see the following figure:

MA5603T

MA5603T

2) Upgrade the APP. When the following information is displayed during the startup, press d

to begin the loading. starting…

ma5600 BIUA Bios

BIOS Ver 118,

PCB Ver B,

Manu Ver 1,

Cpld Ver 102

Build time: Jan 14 2009 12:09:10

Please Press <D> key download app program with XModem … 2

Press CTRL+C key to abort! Waiting …CCCC   3) On the GT3000, choose File > Transfer > XMODEM > Send, and then choose the APP file

to be loaded. Please Select Program File . XMODEM downloading …CCCC 4) The APP loading

is completed. 5) Upgrade the BIOS: install the board into the shelf and then run the following

command in the CLI of the host after the board is in the normal state.

MA5603T(config)#load program

{ emu<K>|ftp<K>|sftp<K>|tftp<K>|xmodem<K> }:xmodem

{ frameid/slotid/subid<S><Length 1-15>|frameid/slotid<S><Length 

3-15>|frameid<U> <0,32> }:0/12

Command:

load program xmodem 0/12

Current baud rate is 9600bps, and it can be modified by ‘baudrate’ command

Are you sure to use this baud rate? (y/n)[n]:y

Whether to load other boards of same type ? (y/n)[n]:

Board name[H801BIUA]:

Whether to start loading? (y/n)[n]:y

You can also load the program in the tftp mode. 6) After the BIOS and the APP are loaded successfully, used methods (1) and

(2) in the preceding section to check whether the loaded versions are correct.

MA5616 Resource Overload Due to the Registration Using an H.248 Service Domain Name-20131010-A

Summary: In MA5616 V800R310C00SPC100 through V800R310C00SPH109, if the MA5616 uses an H.248

interface registered using a domain name, the MA5616 resource overload occurs after the MA5616 runs for a

long period of time.

Product Line: Access network           Product Family: MxU

Product Model: MA5616               Keywords: MA5616 resource overload

Problem Description

Trigger Conditions

This issue occurs if the following conditions are met:

The H.248 service has been configured on the MA5616.

A softswitch domain name has been configured on an H.248 interface. The softswitch domain name is only used

for checking an H.248 message head. The following figure shows an example.

 

The Issue that the MA5600T H802GPBD Board Resets Repeatedly

The Issue that the MA5600T H802GPBD Board Resets Repeatedly Summary: In MA5600T V8R6 and V8R7, during the management message (OMCI and PLOAM messages) interaction when the H802GPBD board is connected ONUs, there is a possible that the CPLD logic bug is triggered. As a result, the board resets. Product Model: MA5600T             Product Family: Optical access

[Issue Description]

Trigger conditions:

ONUs are in the auto-discovery stage and the management message interaction increases. ONUs repeatedly go online and offline, and the management message interaction increases. ONUs are repeatedly powered on and powered off, and the management message interaction increases. The possibility of board reset increases with the normal management message interaction.

Fault symptom:

The H802GPBD board resets at random when it is connected to ONTs.

Identification method:

a. Query the CPLD version of the H802GPBD board. MA5600T(config)#display version 0/12 Send message for inquiring board version successfully, board executing… Main Board: H802GPBD ————————————— Pcb   Version: H802GPBD VER B Mab   Version: 0000 Logic Version: (U50)000(U25)008(U26)008(U49)018  –U49 is the CPLD logic and 018 is the logic version. Versions earlier than  018 has the issue of misinforming interruptions. Main CPU : CPU   Version: (U48)MPC8349 APP   Version: 672(2011-7-19) BIOS  Version: (U57)651 a. Enter the transparent transmission channel of the board to query the GMAC statistics. Commands for querying the GMAC information are as follows: MA5600T(config)#diagnose MA5600T(diagnose)%%su MA5600T(su)%%transparent on <frameid>/<slotid> MA5600T(su)%%user MA5600T(su)%%gmac show st 0 MA5600T(su)%%transparent off   MA5600T(su)%%gmac show stat 0 ——payload———————————————————- DownGemCnt:              13830616       UpGemCnt:               16303424 Down NVld Gem:           0              Up Misync Cnt:                 0 UGemReceivedIdle:        833932 ——DARB & RSM & PED——————————————————     DarbSendEthCnt:          13828216  RsmSendEthCnt:           12579847 DarbSendOmciCnt:         2400       RsmSendOmciCnt:          2400 DarbSendTdmCnt:          0           RsmSendTdmCnt:           0 DarbInsertIdleCnt:       9687041   RsmInsertInvalidCnt:     0 DarbInsertInvalidPortID: 0         RsmDropInvalidPortID:    0 PedCrcErrEth:            2 PedPLIErrDropOmci:       0 PedPLIErrDropTdm:        0 PedSendEthCnt:           12579847 PedSendTdmCnt:           0 PedSendOmciCnt:          2400 PedRecOverSizeEthCnt:    0 PedRecUnderSizeEthCnt:   0 ——OMCI——————————————————————     DomciInsertCnt:          2400           UomciSendCnt:            2400 UomciCrcErrSendCnt:      0 ——PLOAM—————————————————————– DownPloamCnt:            9297    UpPloamCnt:              23783 UploamDropForCrcCnt:     0 UploamDropForFullCnt:    0 UploamNoMsgCnt:          16058 ——SPI4.2—————————————————————-     SPI4DnReceiveCnt:        13828216       SPI4UpSendPktCnt:        12579847 SPI4DnDropCnt:           0 SPI4DnFifofullDrop:      0 SPI4DnPLIErrCnt:         0 SPI4DnTDMErrCnt:         0 SPI4DnETHErrCnt:         0 —————————————————————————- GMAC_ENTER_SERVICE:         10636691   —–The number of interruptions here is larger than 10 million, but the total number of interruptions on the following related PON ports is only larger than 20,000. Therefore, the issue is caused by excessively frequent interruptions. GMAC_ENTER_GMAC0_SERVICE:   8276 GMAC_ENTER_GMAC1_SERVICE:   8539 GMAC_ENTER_GMAC2_SERVICE:   3556 GMAC_ENTER_GMAC3_SERVICE:   1829 GMAC_ENTER_GMAC4_SERVICE:   2 GMAC_ENTER_GMAC5_SERVICE:   2 GMAC_ENTER_GMAC6_SERVICE:   2 GMAC_ENTER_GMAC7_SERVICE:   2 GMAC_INT_PLOAM:             18271 GMAC_INT_OMCI:              3661 GMAC_INT_ALARM:             344 GMAC_INT_LACKBAND:          0

[Root Cause]

When the board is connected ONTs, the ONTs respond to the management messages or PLOAM messages sent by the OLT. By reporting interruptions, the board GMAC instructs the CPU to process these messages. The CPLD codes of the GPBD board have a bug. As a result, useless interruptions will be reported to the CPU and the CPU always responds to these interruptions. When the system TICK interruption is generated (once 10 ms), the interruption that cannot be processed in time will be buffered in the system workQ queue. This process repeats. After the queue overflows (the depth of the workQ queue is 64), the operating system automatically resets the board.

[Impact and Risk]

The possibility of board reset increases with the number of ONTs connected to the board or the number of automatically discovered ONTs.

[Measures and Solutions]

Workarounds:

Reduce the management message interaction between OLT and ONU. Clear the automatically discovered ONTs of the board. Enable these ONTs to go online or remove them to reduce the management message interaction. Query the optical path status to check whether the management message interaction increases because ONTs repeatedly go online and offline due to optical path error codes.

Solution:

Upgrade the IO board package file for MA5600T V800R006C00SPC127 and later versions. Upgrade the IO board package file for MA5600T V800R007C00SPC317 and later versions. Upgrade the IO board package file for MA5600T V800R008C01SPC307 and later versions.

[Rectification Scope and Time Requirements]

None

[Pre-Warning Expiration]

The version is upgraded to V800R006C00SPC127 or V800R007C00SPC317 or V800R008C01SPC307, and the corresponding IO board package file is also upgraded. Query the CPLD logic version of the H802GPBD board. If the version is 018 or later, this issue is resolved.

DHCP Login Failure on a Base Station of a Vendor

Summary: An ATN device function as a DHCP relay agent, and base stations of two vendors

are connected to different DHCP servers. A server or firewall discards packets sent by a base

station of a specific vendor. As a result, users attached to the base station fail to get online.

[Problem Description]

Usage scenario:

The login failure occurs only on a Layer 3 HVPN, not on a Layer 2+ Layer 3 L3VPN.

Base stations of two or more vendors connected to the ATN device attempt to get online

through different DHCP servers.

Firewall rules are specified for private IP addresses on a wireless network management

system (NMS) to drop packets with IP addresses that are not in the specified wireless

network segment.

Trigger conditions:

The problem occurs if the following conditions are met:

An HVPN is configured on an ATN device.

Base stations of two or more vendors are connected to the ATN device.

The base stations obtain IP addresses assigned by different DHCP servers.

Firewall rules are specified for private IP addresses on at least one wireless NMS to

drop packets with IP addresses that are not in the specified wireless network segment.

Symptom:

Users attached to a base station of a specific vendor can get online, and users attached

to a base station of another vendor fail to get online.

Identification method:

Query the device version.

Run the display version command in the user view.

ATN950_5

Check that DHCP relay is configured on an L3VPN interface.

 

Run the display interface GigabitEthernet 0/3/1.200 command in the user view.

 

In the preceding command, 0 indicates the slot number, 3 indicates the subcard number,

1 indicates the interface number, and 200 indicates the sub-interface number. Specify these

figures based on real-world situations.

ATN950_2

Check that multiple L3VPN interfaces are configured on the ATN device. In addition,

DHCP relay is enabled and different DHCP server IP addresses are specified on the

interfaces.

 

Run the display interface GigabitEthernet 0/3/2.200 command in the user view.

In the preceding command, 0 indicates the slot number, 3 indicates the subcard

number, 2 indicates the interface number. and 200 indicates the sub-interface

number. Specify these figures based on real-world situations.

ATN950_3

A DHCP login failure occurs

Note that when users attached to a base station fail to get online using DHCP through

an ATN device, the ATN device needs to be notified of the event from the wireless side.

[Root Cause]

No RFC defines which source IP address is added to a DHCP Request message to be

forwarded by a DHCP relay agent. The ATN device automatically users the IP address

of an outbound interface as the source IP address and adds it to a DHCP Request

message in a VRF or native IP scenario.

In an L3VPN scenario, an ATN device functioning as a DHCP relay agent sets the

source IP address to the first valid private IP address in a VRF for all DHCP Request

messages. The base station of each vendor is connected to a specific NMS that

functions a DHCP server for the ATN device. NMS server hardware or firewall rules

are specified for private IP addresses to drop packets with IP addresses that are not

in the specified network segment. As a result, the DHCP Request message in which

the source IP address should have been set to the second valid private IP address in

a VRF carries the first valid private IP address in a VRF and therefore is dropped.

[Impact and Risk]

Users on a base station attached to the ATN device fail to get online using DHCP.

[Measures and Solutions]

Recovery measures:

Run the ip relay source-ip-address 24.1.1.2 command on the faulty DHCP

relay-enabled interface of the ATN device. 24.1.1.2 is the source IP address to be

carried in DHCP Request messages.

Note that 24.1.1.2 is the IP address of an interface connected to a base station.

ATN950_4

 

Workarounds:

Run the ip relay source-ip-address 24.1.1.2 command on the faulty DHCP

relay-enabled interface of the ATN device. 24.1.1.2 is the source IP address

to be carried in DHCP Request messages.

ATN950_5

Solutions:

Install one of the following patches to a specific type of ATN device running a

specific version. After the patch is installed, the ip relay source-ip-address

command is automatically added.

On ATN 910 and ATN 950 devices running versions earlier than V200R001C02SPC200,

upgrade them to V200R001C02SPC200 and install the patch V200R001SPH009 or later.

On ATN 910 and ATN 910I devices running V200R002C00, install the patch

V200R002SPH005 or later.

On ATN 950B devices running versions earlier than V200R001C02, upgrade

them to V200R001C02 and install the patch V200R001SPH008 or later.

On ATN 950B devices running V200R002C00, install the patch V200R002SPH002

or later.