One network is composed of OSN1500 equipments, it’s host software is 220.127.116.11, other board's software match it, and in the near future, expand a N1SLQ1 board, which board version is 2.15, FPGA is 210, and basic and extended BIOS is 213 and 222. The first port connect with another OSN1500, the 4th port connect with another Vendor’s transmission equipment. However, after connecting the fiber, another
Vendor’s equipment report HP_SLM alarm, the traffic is not up.
Opposite transmission equipment report HP_SLM alarm, and the PQ1 board report LP_RDI alarm in our OSN1500.
1. Use the command to check the C2 value to be transmitted, and find it is really the TUG.
Bid Pid AU4ID C2VALUE
11 4 1 tugs
2. Make a self loop to 4th port with pigtail, and check the C2 value received, and find it is not TUG structure, but a random value, e.g. 0x6d, that is to say, the C2 value transmitted of 4th port is not TUG.
Bid Pid AU4ID C2VALUE
11 4 1 0x6d
3. See about related documentation, and find the reason is that N1SLQ1 board software doesn’t match the host software. About traffic type of going out direction, the R1 version’s rule is that 0 represent VC4, 1
represent VC3 and 2 represent VC12, however R2 version’s rule is different, 0 represent VC4 and 1 represent low order cross-connection traffic. When the software doesn’t match, e.g. in this case, the host
software is R1, and N1SLQ1 version expanded is R2, when configuring the VC12 service, the service type parameter host configured is 2, then the N1SLQ1 will throw off this value for illegal, and use the default value 0 (VC4), so all the HPOH (High Path Overhead) will be transmitted transparent, the J1 and C2 value transmitted is the value received form Cross-connection Module, so it is a random value.
4. Upgrade the host software version to 18.104.22.168, and uniform the other boards, then all the abnormal alarm disappear.
Opposite report HP_SLM alarm, which means the received C2 bytes doesn’t match the value to be received, and the possible reason is that the value N1SLQ1 board transmitted is not TUG structure, or the C2 value to be received is not TUG structure.
1. It isn’t permitted the boards version don’t match each other in OSN equipment for the different rules in different version.
2. Up to now, we can query the J1 and C2 value to be transmitted, to be received and received by command except transmitted, but after make a self loop to optical port with pigtail, we can get it by querying the value received.