Problem Description

Some versions of OSN 3500, in any of the following scenarios, cause the master to restart repeatedly (typically reset once every 12 minutes or so):

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

Scenario 2, the physical and logical single boards above the OSN 3500 network element master subrack are not the same, and the single board has set or is enabling the alarm reversal function.

Alarm information

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

Processing

Judgment method:

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

1, if you find the following records in the errlog, you can basically judge that the problem is caused by:

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" indicates the presence of

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

Emergency 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 download 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 reset, perform the following operation to restore.

:dbms-get-autobackup //(1)

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

:dbms-get-cyclebackup // (2)

:dbms-set-cyclebackup:disable; // Set to disable only if the result of query (2) is 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) results 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

Root Cause

The issue is a platform version defect and the platform versions involved are:

OSPV100R007C02T18D02 and earlier versions

OSPV100R007C03T13D02 and prior versions

OSPV100R008B01C and prior versions

OSPV100R009B01C and prior 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.

Suggestion and Summary

For this issue, it is recommended that you do not set the alarm reversal function on top of the extension subrack if it is on the above version;

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