Hello, everyone!
This post will tell you one issue for HSC_UNAVAIL alarms on standby GXCSA due to fault in SXCSB board of OSN 3500 node in the Main Ring.
Problem description
Equipment Type: OSN 3500
Equipment Version: 5.21.18.53
Problem is reported by the customer that HSC_UNAVAIL alarms are being on Standby GXCSA in OSN 3500 node which is not in the main Ring. This is a SPUR node & connected to another OSN 3500 NE which is in Main Ring.
OSN 3500 (HSC_UNAVAIL) ------> OSN 3500 (SXCSB)(Main NE in Ring)
Handling procedure
The following steps were performed to resolve the issue:
1. First the parameters of the HSC_UNAVAIL alarms were checked. The parameters were 0x02 0x01 0x0a 0xff 0xff
2. According to the parameters, first we checked that all logical boards match with physical boards in OSN 3500
3. Next we cold reset the Standby GXCSA in OSN 3500 but still issue is not resolved.
4. Next we check the clock configuration of OSN 3500 & found that the clock is extracted from the line boards was not normal, so we switch the NE to use an internal clock.
5. After switching to the internal clock we found that the HSC_UNAVAIL alarm gets cleared. We then revert back to using the clock from line boards.
6. Now we check the main node of the Ring from where this current NE was getting its clock.
7.We see that the clock on the Main NE was normal.
8. Now we check that the slot-10 SXCSB in Main NE was active & slot 9 was on standby.
9. We use the following command to check the da value of slot 10 SXCSA
10. We find that the value is constantly fluctuating indicating some fault in the clock generator of the SXCSB board.
11. We then perform that active-standby switching on the Main OSN 3500 NE.
12. After switchover, the HSC_UNAVAIL alarms from Spur OSN 3500 having GXCSA are cleared.
13. This indicates that the slot-10 SXCSB of Main OSN 3500 was generating the problem
14. We then replace the SXCSB with a new board & make an active-standby switchover on the Main NE. Now there are no alarms on the SPUR OSN 3500 GXCSA
#9-2023:huawei02 [ATK-2023
:cfg-get-synstateda:10,0
SYN-STATE-DA
PLLTYPE STATE DA
0 1 2833
Total records :1
#9-2023:huawei02 [ATK-2023
:cfg-get-synstateda:10,0
SYN-STATE-DA
PLLTYPE STATE DA
0 1 4122
Total records :1
#9-2023:huawei02 [ATK-2023
:cfg-get-synstateda:10,0
SYN-STATE-DA
PLLTYPE STATE DA
0 1 13610.
Root cause
The root cause, in this case, was the fault in the clock generator of the SXCSB board of the OSN 3500 Main NE. If such a scenario is faced in which the issue is due to problematic clock generation, we should not only check the NE which is reporting the fault but other NEs from which we are extracting the clock.
Solution
1. We perform that active-standby switching on the Main OSN 3500 NE.
2. After switchover, the HSC_UNAVAIL alarms from Spur OSN 3500 having GXCSA are cleared.
3. This indicates that the slot-10 SXCSB of Main OSN 3500 was generating the problem
4. We then replace the SXCSB with a new board & make an active-standby switchover on the Main NE. Now there are no alarms on the SPUR OSN 3500 GXCSA.
That's all, I welcome everyone to leave a message and exchange in the comment area!
Thank you！
