Monthly Archives: November 2016

When End-to-End GE Services Cannot Be Created on the OptiX OSN 6800?

Issue Description

In the case of a newly deployed OptiX OSN 6800 V100R003, the WSD9 and the RMU9 form an ROADM network, in which the L4G boards are used. After optical fiber connections are established, OTS and OMS trails are found. Enable the end-to-end trail function to create GE services on the T2000 V200R006C01. After the OCh service layer trail is created by using the WDM end-to-end trail function to create, the system automatically completes the optical cross-connection configuration, but it fails to create the end-to-end GE services.

Alarm Information

Null

Handling Process

After the OCh trails are created, use the WDM trail search function to search the electrical layer service trails of the ODU5G and the OTU5G. Then, use the WDM trail function to create client GE services. The system automatically completes the electrical cross-connection configuration.

Root Cause

After creating the OCh trails in the ROADM network formed by the WSD9 and the RMU9, check the trails. Only optical layer OCh trails are created. The electrical layer service trails of the ODU5G and the OTU5G, however, are not created. The ODU5G and the OTU5G can be discovered only through the search function. Client GE services must be created above the service trails of the OCh optical layer and the OTU5G/ODU5G electrical layer. The following figure shows the relations between trails of different layers.

OSN 6800

Suggestions

End-to-end grooming is an important function in WDM service management. The T2000 supports creating end-to-end services at the network layer. After you specify the service source and the service sink, the T2000 can search the service trails and then generate corresponding client trails. The WDM trail creation process effectively simplifies the service configuration and improves operation correctness. It can also perform flexible service grooming and deployment during deployment commissioning or capacity expansion. When you configure the end-to-end service on the T2000, remember to search the created OCh trails before configuring client services.

 

TwitterLinkedInGoogle+FacebookPinterestTumblrStumbleUponRedditShare

How to Use the Multimeter to Check Whether the A32 Board Is Faulty?

Issue Description

Q:
The A32 board is a universal subscriber board of the UA5000. When I use the multimeter to check whether the A32 board is faulty, what should I do?
Alarm Information

Null

Handling Process

A:
1. First, check the board fuses. The A32 board has two fuses, which can be easily found on the board. Use the multimeter to check both ends of the fuse. If the test result is 0 ohms, it indicates that the fuse is normal. If the test result is not 0 ohms, it indicates that the fuse has blown. Check both fuses.

 fuses


fuses

2. If both fuses are normal, check the resistance between the network and the GND on the board. If the test result is larger than 19 kilohms, it indicates that the board is normal. If the test result is smaller than 19 kilohms, it indicates that the board is faulty.

 fuses


fuses

Root Cause

Null

Suggestions

Null

 

Due to disabling TDC-ADJUSTENABLE function high Bit errors on NS3 card

TDC-ADJUSTENABLE function high Bit errors on NS3 card

Issue Description

8 OSN 6800 are configured for making 40G DWMD ring
NE version is 5.51.05.35 NMS version is U2000V100R001C00SPC003

Alarm Information

BEFFEC-EXC

 

Handling Process

Cheked the Tx and Rx power on far end and local side,but both are fine
check the powers of all pass throughs on MCA there was no such variation on pass through channels
Check the board performance ,all performances were fine
When check the dispersion parameters the TDC-ADJUSTENABLE function was disable ,when enable this function all errors were cleared

Root Cause

1. Optical power value issue: need check whether it is low or high onwhole span including all pass throughs on MCA
2. OSNR issue:  need check the link power
3. Dispersion issue: if all wavelength have the same poor FEC-BEF-BER, consider dispersion issue
4. hardware issue ,need to replace

Suggestions

Always suggested to enable TDC-ADJUSTENABLE function ,otherwise due to this the 40 G card will generate errors

 

When compatible stp mode in S5700 Huawei switch with pvst in cisco switches?

Issue Description

Problem: What’s the compatible stp mode in Huawei switches with pvst in Cisco switches

Product name: S5700

Software version: Quidway S5700 V200R003C00SPC300

Network topology:

SWITCH

SWITCH

Configuration: Configure spanning tree protocol mode in S5700 Huawei switch to be

compatible with pvst mode in Cisco switch

Solution

Description:

As the default stp(Spanning tree protocol) mode in Cisco switches is pvst and the stp mode

in Huawei switches is stp, when we connect Cisco switches with Huawei switches there’s a

miscompatiblity happened and looping will occured in the network so that to avoid this loop

we need to configure Huawei switches to work in vbst mode, this mode for Huawei switches

is compatible with pvst mode in Cisco

Configuration:

<Huawei> system-view

[Huawei] stp mode vbst

 

When OSN 1500 R1PCXLN board fails to query optical power due to software BUG?

Issue Description

OSN 1500 R1PCXLN board fails to query optical power, the optical power can not

be reported normally , the SCC version is 5.36.30.15.

Alarm Information

NULL

Handling Process

Warm reset the R1PCXLN board

Root Cause

1、The problem can be recured in the lab, once the line board type is changed, the optical

power can not be reported.

2、When R1PCXLN board type is changed, the line board can be used by multi-board ID .

This operation could disable  optical power report module due to the software BUG, lead

to the optical power can not be reported normally.

Suggestions

1、This handling method is a temporary way to avoid this problem, if you change the

R1PCXLN board type, the optical power will not be reported normally. The root method

is upgrade patch, the patch have not come forth now.  Once the patch can be acquired,

I will update this case.

2、The related product version is V1R9C03 and V2R11C00.

When the NMS Fail to Synchronize ONUs.

Keywords:

ONU version information,  OLT, MA5600T&MA5603T

Summary:

When an NMS synchronizes with ONUs from an OLT through the FTP, the character string length of the version information (such as the equipment ID, ONT model, ONU hardware version, ONU primary software version, ONU secondary software version) reported by some ONUs exceeds the maximum length defined in the protocol, and the reported character string does not contain any string tokenizer. As a result, the NMS fails to synchronize with the ONUs, and customers cannot manage the newly-deployed ONUs or deploy new services.

[Problem Description]

Trigger condition:

1. The U2000 is earlier than V100R006C02CP3207 and the OLT is the MA5600T V800R011 earlier than V800R011C00SPC107 or MA5600T V800R012 earlier than V800R012C00SPC103.

2. The NMS synchronizes with ONUs through the FTP.

3. The character string length of the version information reported by some ONUs exceeds the maximum length defined in the protocol, and the reported character string does not contain any string tokenizer. (As defined in the protocol, the maximum length of the equipment ID or ONT model is 20 bytes and that of ONU hardware version, primary software version, and secondary software version is 16 bytes.)

When the above conditions are met, the NMS fails to synchronize with the ONUs.

Symptom:

The following describes the possible symptoms:

1. The ONUs cannot be displayed on the NMS network topology.

2. ONU information, such as the ONU SN (GPON), LOID (EPON), and equipment ID, cannot be displayed on the NMS interface.

3. ONU information cannot be found on the OLT.

Identification method:

If the above symptoms occur, use the following methods to determine whether they are caused by the problem in this precaution.

If both the NMS and the OLT are in the version ranges mentioned above, proceed to the next step.

1. On the NMS:

Synchronize with the ONUs on the NMS, and reproduce the synchronization failure. View the NMS synchronization log, U2000\server\var\logs\Develop\BmsAccess_9961\BmsAccess_*_*.log or U2000\server\var\logs\Develop\BmsAccess_1\BmsAccess_*_*.log (* indicates the date and time), and check whether the following error message is displayed:

Call Function return Error:DoUpdate(pTableDesc, pSrcTable, pOutPutTable)

If not, the problem described in this precaution does not occur. The synchronization failure is caused by other causes.

If yes, the character string length exceeds the maximum length when the NMS parses the POD file. Therefore, the information cannot be written into the NMS database. The problem can be solved by using the suggested solutions in this precaution (see “Measures and Solutions”).

2. On the OLT:

Query all ONT version information on the faulty OLT. The command output of the GPON or EPON ONT version information is as follows:

 

In the command output, if the type name, software version, or hardware version of a certain ONU exceeds the maximum length listed in the following table, the character string reported by the ONU does not contain any string tokenizer, which results in the problem described in this precaution. The problem can be solved by using the suggested solutions in this precaution (see “Measures and Solutions”).

GPON ONU EPON ONU
Information Maximum Length Information Maximum Length
Equipment-ID 20 bytes ONT model 20 bytes
ONT Version 16 bytes ONT hardware version 16 bytes
Main Software Version 16 bytes ONT software version 16 bytes
Standby Software Version 16 bytes - -

Use the following method to confirm the character string: Copy the ONT model or software version information to the UltraEdit, and choose View > Display Ruler from the main menu.

Display Ruler

Display Ruler

 

 

[Root Cause]

The version information reported by the ONU does not contain a string tokenizer.

The following uses the ONU software version as an example.

Different ONUs use different methods to report the ONU software version. Generally, an ONU adds a string tokenizer \0 at the end of the reported character string. In this way, the upper-layer device detects how many bytes the software version reported by the ONU contains.

If an ONU reports a 16-byte character string to the OLT but does not add a string tokenizer at the end of the character string, the OLT cannot determine how many bytes this character string contains. Therefore, the character string length of the ONU software version reported by the OLT to the NMS is uncertain, and may exceed the maximum length supported by the NMS. In addition, the NMS does not support this abnormal behavior and considers that the character string length of the ONU software version exceeds the maximum length. The NMS fails to parse the ONU software version. Consequently, the NMS fails to synchronize with the ONU.

[Impact and Risk]

If the character string length of the reported ONU software version exceeds the maximum length defined in the protocol and reported ONU software version does not contain a string tokenizer, the NMS fails to synchronize with the ONU through the FTP. As a result, customers cannot manage the newly-deployed ONUs or deploy new services.

[Measures and Solutions]

Preventive measure:

The NMS synchronizes with ONUs through the SNMP instead of the FTP, but the synchronization efficiency will be reduced by about 80%.

If you need to use this solution, contact Huawei R&D engineers for confirmation in advance to prevent NMS performance from being affected. The specific methods for synchronizing with ONUs through the SNMP are as follows:

1. Back up the U2000\server\nemgr\nemgr_access\dcp\platform\v100\feature\gdm\mxu_conf_dev_feature.xml file.

2. Copy the backup file and edit it. Find <feature name=”PollOptimize” support=”1″> in the file as follows:

 

1. The <dev type> structure in the file indicates an NE type and its version range information, among which the dev type field uniquely identifies the NE type. Delete the corresponding <dev type> structure based on the faulty equipment type on the live network.

Use the MA5600T and MA5680T as examples. In the dev type=”41″ and dev type=”45″ fields, 41 indicates the MA5600T, and 45 indicates the MA5680T. Delete the corresponding structures (the following two lines in the given XML file) for the NMS to synchronize with these two types of NEs through SNMP:

<dev type=”41″ area=”[MA5600V800R006C03B000,MA5600V800R006C03BZ);[MA5600V800R006C32B010,MA5600V800R006C33BZ);[MA5600V800R006C72B010,MA5600V800R006C72BZ);[MA5600V800R007C00,MA5600V800RZ)”/>

<dev type=”45″ area=”[MA5600V800R006C32B010,MA5600V800R006C32BZ);[MA5600V800R006C72B010,MA5600V800R006C72BZ);[MA5600V800R007C00,MA5600V800R007CZ);[MA5680V800R007,MA5680V800R099CZ);[MA5683V800R007,MA5683V800R099CZ)”/>

The values of Dev type and the specific NE types are mapped as follows.

Dev type Equipment Type
41 MA5600T
45 MA5680T
75 MA5603T
2331 MA5608T

 

2. Restart the following processes: profile, BmsAccess, BmsCommon, TL1NbiDm, inTL1NbiDm, BmsTimingTask, BmsTest, BmsAtur, and BmsHGMPDm. For processes that cannot be found, ignore them.

Solution:

A patch for the NMS is released to resolve this issue. Patch version: U2000 V100R006C02SPC303 (to be released on September 30, 2013)

A patch for the OLT is released to resolve this issue. Patch version: MA5600T V800R011C00SPC109 (to be released on September 15, 2013)

Patch version: MA5600T V800R012C00SPC103 (to be released on August 20, 3013)

The problem can be resolved by loading the NMS patch or the OLT patch.

When Prewarning on Service Unavailability of H806GPBH & H806GPBD Boards of MA5600T

Keywords: H806GPBH, H806GPBD, DDR3 cache, slow Internet access, board reset

Abstract:

When a large number of users are connected to the H806GPBH/H806GPBD boards, the DDR3 read

operation occasionally becomes abnormal and the external DDR3 cache returns incorrect data, causing

wrong service packets. As a result, slow Internet access, dialup failure, and board reset may occur.

 

[Problem Description]

Trigger conditions

1. A large number of users are connected to the H806GPBH/H806GPBD boards (this problem is more

likely to be triggered when the number of users exceeds 300, and more users mean a higher probability

for this problem to occur), traffic is heavy, or traffic burst occurs.

2. Devices use the patches of versions earlier than V800R008SPC321, V800R010SPC111, V800R011SPC109,

V800R012SPC106, and V800R013C00SPC205.

 

The preceding conditions are mandatory conditions for the issue to occur. However, if these conditions are met,

the problem does not necessarily occur (for details, see the root cause analysis).

Symptom:

Users connected to the H806GPBH/H806GPBD boards encounter slow Internet access or dialup failures.

Even board reset may occur.

Location method 1 (manual):

When an H806GPBH or H806GPBD board encounters any fault mentioned above, check the DDR cache through

the transparent channel. Then, determine the problem based on the read/write result.

Step 1 Check whether the OLT and board versions are earlier than V800R008SPC321, V800R010SPC111,

V800R011SPC109, V800R012SPC106, or V800R013C00SPC205.

MA5600T(config)#display patch all

Software Version:MA5600V800R011C00

SPC100

SPH103

HP1102

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

Current Patch State:

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

Patch Name        Patch State     Delivery     Attribute     Dependency

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

SPC100            running         common       cold patch    NO

SPH103            running         common       hot patch     NO

HP1102            running         common       hot patch     NO

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

Total:3

Patches in the system cannot be rolled back

Step 2 Enter the transparent channel of the board.

MA5680T(config)#diagnose

MA5680T(diagnose)%%su

Challenge:E8BUH36K

Please input password:                — password (can be obtained using a password generation tool)

MA5680T(su)%%transparent on 0/slotid                      —slotid indicates the slot ID of the board.

Serial redirect function is enabled now!

Step 3 Run the following three groups of commissioning commands consecutively. If all the three return values

of a command group are incorrect, the DDR3 partition related to this group is faulty. As long as the execution

results of one or more group of commands indicate a fault, the problem may occur (note that, to ensure accuracy,

the interval for executing the three groups of commands must be short).

MA5680T(su)%%tm set indirect-reg 0×48000040 0×55555555

Write register 0×48000040 0×55555555 successfully!

MA5680T(su)%%tm dis indirect-reg 0×48000040 0×1

0×40000040: 55555555

MA5680T(su)%%tm set indirect-reg 0×48000040 0xaaaaaaaa

Write register 0×48000040 0xaaaaaaaa successfully!

MA5680T(su)%%tm dis indirect-reg 0×48000040 0×1

0×40000040: aaaaaaaa

MA5680T(su)%%tm set indirect-reg 0×48000040 0xffffffff

Write register 0×48000040 0xffffffff successfully!

MA5680T(su)%%tm dis indirect-reg 0×48000040 0×1

0×40000040: ffffffff

MA5680T(su)%%tm set indirect-reg 0×58000040 0×55555555

Write register 0×58000040 0×55555555 successfully!

MA5680T(su)%%tm dis indirect-reg 0×58000040 0×1

0×50000040: 55555555

MA5680T(su)%%tm set indirect-reg 0×58000040 0xaaaaaaaa

Write register 0×58000040 0xaaaaaaaa successfully!

MA5680T(su)%%tm dis indirect-reg 0×58000040 0×1

0×50000040: aaaaaaaa

MA5680T(su)%%tm set indirect-reg 0×58000040 0xffffffff

Write register 0×58000040 0xffffffff successfully!

MA5680T(su)%%tm dis indirect-reg 0×58000040 0×1

0×50000040: ffffffff

MA5680T(su)%%tm set indirect-reg 0×68000040 0×55555555

Write register 0×68000040 0×55555555 successfully!

MA5680T(su)%%tm dis indirect-reg 0×68000040 0×1

0×60000040: 55555555

MA5680T(su)%%tm set indirect-reg 0×68000040 0xaaaaaaaa

Write register 0×68000040 0xaaaaaaaa successfully!

MA5680T(su)%%tm dis indirect-reg 0×68000040 0×1

0×60000040: aaaaaaaa

MA5680T(su)%%tm set indirect-reg 0×68000040 0xffffffff

Write register 0×68000040 0xffffffff successfully!

MA5680T(su)%%tm dis indirect-reg 0×68000040 0×1

0×60000040: ffffffff

 

If “Read register fail errorcode” is displayed in the test, the problem can be identified.

MA5680T(su)%%tm display indirect-reg 0×68000040 1

0×68000040:

Read register fail errorcode=1082982587!   —This problem can be identified as long as this output is displayed.

—-End

Location method 2 (PMI tool)

If a board involves the problem symptom, upgrade the preventive maintenance inspection (PMI) tool using the

package attached in this document and then perform PMI to identify the problem. Install the required patch

if the following PMI result is displayed: “Detected DDR error. Solution: Update to SPC321 if is R8; update to

R11SPC109 if is R11. Should you have any question, please contact R&D, Zhouhao 00140882.”

 

MA5600T

MA5600T

For the PMI tool upgrade package, see the link:

http://support.huawei.com/support/pages/editionctrl/catalog/ShowSoftDetail.do?actionFlag=displaySoftInfo&node_id=000001539334&web_doc_id=SW0000627564&colID=ROOTENWEB|CO0000000174

 

MA5600T

MA5600T

 

[Root Cause]

When packet traffic is heavy, there is a small probability that the interval at which the FPGA reads and writes

the DDR3 is too short and cannot meet the DDR3 requirement. As a result, DDR3 becomes abnormal and

packets are incorrect, causing slow Internet access, dialup failure, or even board reset.

 

[Impact and Risk]

This problem occurs with a low probability and may cause slow Internet access, dialup failure, and

occasional board reset, which will affect live-network services.

 

[Measures and Solutions]

Recovery measures:

This problem is triggered occasionally and can be rectified by resetting the board affected.

Because this problem occurs occasionally and may trigger another DDR3 exception and relevant

problems, install the required patches for the faulty board.

Preventive measures:

None

Solutions:

Upgrade patches V800R008SPC321, V800R010SPC111, V800R011SPC109, V800R012SPC106,

and V800R013C00SPC105 accordingly to resolve the problem.

 

[Warning Expiration]

This warning automatically expires after the trigger conditions are not met.