OptiX OSN1500B is generally used in the access layer of metro transmission network. Under TDM network, it can be mixed with OptiX OSN 9560, OptiX OSN 9500, OptiX OSN 7500 II, OptiX OSN 7500, OptiX OSN 3500 II, OptiX OSN 2500, OptiX OSN 3500, OptiX OSN 500, OptiX OSN 550 and other optical transmission equipments to realize a full range of solutions from backbone layer, aggregation layer to access layer. 3500, OptiX OSN 500, OptiX OSN 550 and other optical transmission equipment mixed network, optimize the operator's investment, and can realize a full range of solutions from the backbone layer, aggregation layer to the access layer. With the support of packet switching technology, it is able to work with OptiX OSN 7500, OptiX OSN 7500 II, OptiX OSN 3500, OptiX OSN 500, OptiX OSN 550, OptiX PTN 910, OptiX PTN 950, OptiX PTN 1900, and OptiX PTN 3900, OptiX RTN 900 and other equipment together to form a packet data transport network, to meet the network IP service bearer requirements.

Problem Description

After the OSN1500 equipment replaces the PCXL board in slot 83, the NESOFT_MM alarm is reported. Check the version of the main control board in the network management, and they are all 5.36.30.15P01.

Querying with :hbu-get-backup-info returns Backup-Info : 0x00000002 , Master-Backup synchronization failed.

NESOFT_MM parameters are: 0x02, 0x03, 0x00, 0x08, 0xFF

Processing

Cause 1: The software versions currently running on the master and backup boards are inconsistent.

Cause 2: The software versions in the master and backup areas (OFS1 and OFS2) of the master board are inconsistent.

Cause 3: There is no file with the same name in the corresponding directory of the pair of boards on the master and backup boards.

Solution

Query the meaning of NESOFT_MM alarm.

According to the OSN1500 alarm information, we found that the alarm meaning of this device is inconsistent with the NeSoft and Platform of the main and backup master control boards.

2, use the command line to query the version of the two masters:

:sftm-get-testver:82

VERSION-INFORMATION(INCLUDING-PATCH-INFORMATION)

nesoftname ver date state test-versus-info

nfs 5.36.30.15p01 20100220 running t02

nsf1 5.36.30.15p01 20100220 active t02

nsf2 5.36.30.15p01 20100220 inactive t02

INI1 5.36.30.15P01 20091218 active T02

INI2 5.36.30.15P01 20091218 inactive T02

BIOS 08.09.04 20100716 inactive T01

ExtBIOS 09.09.04 20091218 active T01

Logic (U1028)120

LogicE01 (U1033)300

DRV V1.02 20090515 active T04

Total records :10

:sftm-get-testver:83

VERSION-INFORMATION(INCLUDING-PATCH-INFORMATION)

nesoftname ver date state test-versus-info

nfs 5.36.30.15p01 20100220 running t02

nsf1 5.36.30.15p01 20100220 active t02

nsf2 5.36.30.15p01 20100220 inactive t02

INI1 5.36.30.15P01 20091218 active T02

INI2 5.36.30.15P01 20091218 inactive T02

BIOS 08.09.03 20091218 inactive T01

ExtBIOS 09.09.04 20091218 active T01

Logic (U1028)120

LogicE01 (U1033)300

DRV V1.02 20090515 active T04

Total records :10

I found that the software versions queried by the master and backup master are the same, but the base BIOS is not the same. Check the version matching table, the basic BIOS should be 08.09.03.

3, using Navigator to view the two sets of host software

:sftm-show-dir:82,"/ofs1/hwx"

:sftm-show-dir:82,"/ofs2/hwx"

:sftm-show-dir:83,"/ofs1/hwx"

:sftm-show-dir:83,"/ofs2/hwx"

:sftm-show-dir:82,"/ofs1/fpga"

:sftm-show-dir:82,"/ofs2/fpga"

:sftm-show-dir:83,"/ofs1/fpga"

:sftm-show-dir:83,"/ofs2/fpga"

The commands query the hwx and fpga folders in the OSF1 and OSF2 directories of the master and backup masters respectively, and the comparison shows that there is one less sccpkg.ini file in the /ofs2/hwx directory of the 82-slot master than the corresponding directory of the 83-slot backup master. Checking the version matching table and other normal network elements, I found that this file should exist.

Problem localization:

OSN1500B 82-slot master osf2/hwx The files within osf2/hwx are inconsistent with 83-slot. 82-slot base BIOS is not the version required by the matching table.

Processing method:

Use Toolkit to reload the PCXL package for slot 82 at the board level, and then downgrade the base BIOS to 08.09.03. Observe for a period of time, and the alarm is no longer reported. Problem Solved.

Suggestions and Summary

1, NESOFT_MM alarm is not reported only when the version of the master and backup master control is not the same, but also when the file inspection found that the files in the directory are not the same, you need to carefully analyze the alarm parameters.

2、The company's spare parts may be inconsistent with the version running on the network, so you need to pay attention to the replacement of spare parts.

This chapter of related technical information and SDH equipment troubleshooting process by the Shenzhen Optical Transmission Network Technology Limited collection (www.opticaltrans.com), reproduced please retain! Our company specializes in Huawei SDH optical transmission equipment, SDH transmission equipment sales.