No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Board software dismatch lead to opposite equipment reporting HP_SLM alarm

Publication Date:  2012-07-24 Views:  67 Downloads:  0
Issue Description
One network is composed of OSN1500 equipments, it’s host software is 5.36.11.13, 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.
Alarm Information
Opposite transmission equipment report HP_SLM alarm, and the PQ1 board report LP_RDI alarm in our OSN1500.
Handling Process
1. Use the command to check the C2 value to be transmitted, and find it is really the TUG.
:cfg-get-stc2:11,4,1;
                                       STC2                                       
                            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.
  :cfg-get-rc2:11,4,1
                                        RC2                                       
                            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 5.36.13.47, and uniform the other boards, then all the abnormal alarm disappear.
Root Cause
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.
Suggestions
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.

END