Description of the problem

A customer newly expanded two OSN3500s with the same configuration (9-158 and 9-132), and the newly expanded devices communicate with the opposite end OSN3500 through the same configuration of WDM network (NG-WDM1 and NG-WDM2 with the same configuration). When the fiber was connected, it was found that 9-158 could not communicate with 9-157, while 9-131 and 9-132 could communicate normally, see annex 1;

Network element version: 5.21.18.50P01

Processing

(1) 9-131 and 9-132 can communicate normally, indicating that NG-WDM can transmit ECC normally, and the 2 NG-WDM network configurations are the same, ruling out NG-WDM network problems;

(2) Check the corresponding optical boards of 9-158 and 9-157 network elements with the command :alm-get-curdata, and find that there are no abnormal alarms such as RLOS.

3) check the performance of 9-158 and 9-157 with :per-get-curdata:bid,0,0,0,perall,15m and find no error codes;

4) Checked 9-158 and 9-157 with :cm-get-eccroute, :cm-get-coreroute, found no routes between them

(5) Use cm-get-bdinfo to check whether the optical ports have been assigned ECC channels, and find that the docked optical ports are normally assigned ECC channels.

6) Check whether the channel types of the two network elements are the same (:cm-get-fiberport:bid,port), and found that the channel types are the same.

7）Check the corresponding channels for error codes with cm-get-chaninfo and cm-get-chanerror, and find that there are no error codes.

8) Check CRC checksum with :cm-get-ecccrc command: both sides are found to be closed.

(9) The optical ports of 9-158 and 9-157 docking single boards are looped back respectively, and the display is normal after the loopback (meanwhile, the WDM network will be looped back segment by segment, and the ECC is found to be normal, so the WDM network failure is ruled out).

(10) soft reset 9-158 and 9-157 main control board, the problem still exists!

11) Use the command line to check the protocol stack of the docking single board:cm-get-ohpchan:bid,portid;

Found that the two sides use different protocols: (9-157: hwecc, 9-158: osi)

Modify 9-158-12SL16 protocol stack to hwecc, problem solved;

:cm-set-ohpchan:bid,portid,chantype, hwecc.

Root cause

Due to the different protocol stacks of the docking veneer, the two network elements cannot communicate.

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 the sale of Huawei SDH optical transmission equipment, SDH transmission equipment.