Description of the problem

BUS_ERR and HSC_UNAVAIL alarms are reported on the UXCSB board at board position 10 of the Huawei OSN3500 device, which also comes with an expansion subrack and host version 5.21.12.42.

Processing

Huawei OSN3500 reports BUS_ERR alarm, there are two possibilities, one is false alarm, the other is real. After confirming, there is no possibility that the user's host version and network management version could have misreported BUS_ERR. Therefore, the reported BUS_ERR and HSC_UNAVAIL should be real. Also ruled out is an expansion subrack connection error resulting in a BUS_ERR. Checking the returned alarms, we found that the parameter of BUS_ERR is "0x12 0x02 0x04 0x02 0xff", while the parameter of HSC_UNAVAIL is "0x04 0x01 0x0a 0xff 0xff". Two conclusions were drawn after carefully analyzing these alarm parameters:

(1) HSC_UNAVAIL is caused by BUS_ERR;

(1) HSC_UNAVAIL is caused by BUS_ERR; (2) BUS_ERR is caused by B1 error;

In addition, both alarms are characterized by automatic ending and then automatic generation, and the service is not affected.

After further analysis, it is found that if there is a problem with the DB header cable of the upper port of the UXCSB board No. 10 connected to the expansion subrack, it will lead to a B1 error code, but why there is no DB header switching to eliminate this alarm needs to check the register data of the No. 10 cross board.

After collecting the register data of board 10 with OPTP command, it is found that the second bus of UXCSB board 10 has B1 error code, while the first bus is fine. Further analyzing the user's service on the expansion subrack, it is found that only board 52 has service, and board 52 corresponds only to the 1st bus of the cable. Now what is detected is that the 2nd bus has a B1 error code, but the 2nd bus is not configured for service, so the software, in order to ensure that the service is not flashed (switching the DB header will generate an error code), only reports the BUS_ERR alarm without DB header switching. At this point, it can be determined that the DB header cable of the upper port of the 10th cross board is bad.

Another question that needs to be addressed is why do these two alarms come and go? This is because cross board #10 is currently a standby board and our equipment will not detect bus alarms when there is clock asynchrony. Specifically, when the clock asynchrony lasts for 30s, bus alarms such as BUS_ERR will disappear, and detection will resume again after the clock is synchronized. The spare board will experience occasional clock asynchrony, so alarms such as BUS_ERR will be sporadic.

Root cause

Damage to the cable connecting the expansion subrack

Solution

After replacing the DB header cable on the upper port of the 10th crossover board, the alarm is eliminated.

Recommendations and Summary

Huawei OSN3500 BUS_ERR is a relatively common alarm, and to analyze its reported cause, you need to start from its alarm parameters instead of simply resorting to the alarm cause prompts on the network management.

The related technical information in this chapter and the SDH equipment troubleshooting process are collected and organized by Shenzhen Optical Transmission Network Technology Company Limited ( www.opticaltrans.com), please retain! Our company specializes in the sale of Huawei SDH optical transmission equipment, SDH transmission equipment.