Optix OSN3500 reasonably sets the performance monitoring parameters of the network element and starts the performance monitoring of the network element, which can obtain the detailed performance records of the network element in the course of operation, so as to make it convenient for the maintenance personnel to monitor and analyze the operation status of the network element. When the SDH performance statistics value reaches a certain limit (SDH performance event threshold), the network element reports a performance event. When the BER reaches a certain limit (BER alarm threshold), the network element reports an alarm event. For services with high service quality requirements, when a specific event affecting service quality (such as B3_EXC) is monitored on a certain channel, AIS can be inserted into the corresponding port of the network element, triggering the relevant protection mechanism, and reversing the service to a better-quality protected channel, so as to ensure the service quality of these services.

Problem Description

Some versions of OSN3500, in any of the following scenarios, cause the master to restart repeatedly (usually reset once in about 12 minutes):

Scenario 1, the single board above the OSN 3500 expansion subrack was or is enabled for alarm reversal;

Scenario 2, the physical and logical boards above the OSN 3500 network element master subrack are inconsistent, and the board has been or is enabled with the alarm reversal function.

Alarm information

The master repeatedly reboots (usually resets once every 12 minutes or so), which can be queried by the errlog command.

Processing

Judgment method:

The problem can be determined by errlog and dbms-query: "alminv.dbf",drdb two commands

1, if the errlog found in the following records, basically can be judged to be caused by the problem:

fatal task errorcode=1, Line 2069 in alm_char.cpp:TA

2, and then use :dbms-query: "alminv.dbf",drdb command to query, in the following feedback results, "4d" and "57" means that there are

In the following results, "4d" and "57" indicate the presence of the above scenario 1, and "ff" indicates the presence of the above scenario 2.

:dbms-query: "alminv.dbf",drdb

ALMINV.DBF

record num BID OPPORT PATH ALLOW

1 ff 01 0001 01

2 05 02 0001 01

3 05 03 0001 01

4 05 04 0001 01

5 05 05 0001 01

6 4d 06 0001 01

7 57 07 0001 01

Urgent solution:

Method 1, if the alarm reversal function is still enabled on the existing network, you can turn off the alarm reversal function and then replace a brand new master board (if the existing network is dual master, you need to unplug all the dual masters), and then use T2000 to upload the configuration data;

Method 2, in the normal operation of the network element, check that the alarm reversal database has the BID of the extended subrack slot, you need to delete the alarm reversal database to avoid repeated reset of the network element after the reset, perform the following operation to restore.

:dbms-get-autobackup //(1)

:dbms-set-autobackup:disable; // Set to disable only if the result of query (1) is enable.

:dbms-get-cyclebackup // (2)

:dbms-set-cyclebackup:disable; // Set to disable only if query (2) results in enable.

:dbms-delete: "alminv.dbf",drdb

:dbms-copy-all:drdb,fdb0

:dbms-copy-all:drdb,fdb1

:dbms-query: "alminv.dbf",fdb0

:reset

:dbms-query: "alminv.dbf",drdb

:dbms-set-autobackup:enable; // query (1) results in enable, need to restore to original state

:dbms-set-cyclebackup:enable; // Query (2) resulted in enable, need to restore to original state

Method 3: Upgrade to the following version that solves the problem:

V version T version

OSPV100R007C03 T15 and later versions

OSPV100R008 B01D and later versions

OSPV100R009 B01D and later versions

Cause of Failure

The issue is a platform version defect and involves the platform version:

OSPV100R007C02T18D02 and prior versions

OSPV100R007C03T13D02 and prior versions

OSPV100R008B01C and previous versions

OSPV100R009B01C and previous versions

The platform version can be queried via the command line: sys-get-ptsoftver;

Note: This problem does not only affect OSN 3500 products, but also other optical networking products that use the above platforms.

Recommendations and Summary

For this issue, it is recommended not to set the alarm reversal function on the expansion subrack if it is in the above version;

This issue affects all optical network devices that use the above platform versions.

The related technical information in this chapter and the SDH equipment troubleshooting process are collected and organized by Shenzhen Optical Transmission Network Technology Co.(www.opticaltrans.com), please retain! Our company specializes in Huawei SDH optical transmission equipment, SDH transmission equipment sales.