Problem Description
Some versions of OSN3500, under any of the following scenarios, will cause the master to reboot repeatedly (usually reset once every 12 minutes or so):
Scenario 1, the single board above the OSN3500 expansion subrack has been or is currently enabled with the alarm inversion function;
Scenario 2, the physical board above the main subrack of the OSN3500 network element is not the same as the logical board, and the single board has been set up or is being enabled with the alarmReverse function
Scenario 1, the single board above the OSN3500 expansion subrack has been or is currently enabled with the alarm inversion function;
Scenario 2, the physical board above the main subrack of the OSN3500 network element is not the same as the logical board, and the single board has been set up or is being enabled with the alarmReverse function
The master is repeatedly rebooted (generally reset once every 12 minutes or so), which can be queried by the errlog command
Judgment method:
The problem can be judged by errlog and dbms-query: "alminv.dbf",drdb two commands
1, if the errlog found in the following records, basically can be judged as the problem caused by:
fatal task errorcode = 1, Line 2069 in alm_char. cpp:TA
2, then use :dbms-query: "alminv.dbf",drdb command to query, in the following feedback results, "4d" and "57" means that there is
Scenario 1 above, and "ff" means that there is Scenario 2 above
: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 inversion function is still enabled on the existing network, you can disable the alarm inversion function. If the alarm reversal function is still enabled on the existing network, you can turn off the alarm reversal function and replace it with a brand-new main control board (if the existing network has dual masters, you need to unplug all of the dual masters), and then use the T2000 to upload the configuration data.
Method 2: When the network element is running normally, and you check that there is a BID of the extended subrack slot in the alarm reversal database, you need to delete the alarm reversal database to avoid repeated resets of the network element after reset, perform the following operation to restore it. If the alarm reversal database is deleted, the network element will be reset repeatedly after the reset, perform the following operation to recover.
:dbms-get-autobackup //(1)
:dbms-set-autobackup:disable; // The result of query (1) is enable before setting it to disable
: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 back to original state
:dbms-set-cyclebackup. enable; // Query (2) results in enable, need to revert back to original state
Method 3: Upgrade to the following version that solves the problem:
V version T version
OSPV100R007C03 T15 and later
OSPV100R008 B01D and later
OSPV100R009 B01D and later
The problem can be judged by errlog and dbms-query: "alminv.dbf",drdb two commands
1, if the errlog found in the following records, basically can be judged as the problem caused by:
fatal task errorcode = 1, Line 2069 in alm_char. cpp:TA
2, then use :dbms-query: "alminv.dbf",drdb command to query, in the following feedback results, "4d" and "57" means that there is
Scenario 1 above, and "ff" means that there is Scenario 2 above
: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 inversion function is still enabled on the existing network, you can disable the alarm inversion function. If the alarm reversal function is still enabled on the existing network, you can turn off the alarm reversal function and replace it with a brand-new main control board (if the existing network has dual masters, you need to unplug all of the dual masters), and then use the T2000 to upload the configuration data.
Method 2: When the network element is running normally, and you check that there is a BID of the extended subrack slot in the alarm reversal database, you need to delete the alarm reversal database to avoid repeated resets of the network element after reset, perform the following operation to restore it. If the alarm reversal database is deleted, the network element will be reset repeatedly after the reset, perform the following operation to recover.
:dbms-get-autobackup //(1)
:dbms-set-autobackup:disable; // The result of query (1) is enable before setting it to disable
: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 back to original state
:dbms-set-cyclebackup. enable; // Query (2) results in enable, need to revert back to original state
Method 3: Upgrade to the following version that solves the problem:
V version T version
OSPV100R007C03 T15 and later
OSPV100R008 B01D and later
OSPV100R009 B01D and later
The issue is a platform version defect, and the platform versions involved are:
OSPV100R007C02T18D02 and later
OSPV100R007C03T13D02 and later
OSPV100R008B01C and later
OSPV100R009B01C and later
The platform version can be queried by the command line: sys-get-ptsoftver to query;
Note: This problem does not only affect OSN3500 products, other optical networking products that use the above platforms are at risk of this problem
OSPV100R007C02T18D02 and later
OSPV100R007C03T13D02 and later
OSPV100R008B01C and later
OSPV100R009B01C and later
The platform version can be queried by the command line: sys-get-ptsoftver to query;
Note: This problem does not only affect OSN3500 products, other optical networking products that use the above platforms are at risk of this problem
For this problem, if in the above version, it is recommended not to set the alarm reversal function on top of the extension subrack;
This problem affects all optical network devices that use the above platform version.
This problem affects all optical network devices that use the above platform version.
END
Sale of Huawei OSN3500 _Product Quotation _ Sales Manufacturer_Product Features_Product Description_Huawei SDH Transmission Equipment Sales
Supply Huawei OSN3500_Troubleshooting_Installation and Testing_Technical Indicators_Technical Parameters_Huawei SDH Transmission Equipment Sales


Chinese
English





