Method used to determine a fault point based on a PS alarm


PS alarms vary according to protection schemes. Determine the fault point and handle the fault based on the related alarm handling procedure.

Other related questions:
Method used to handle the PS alarm reported by an unused protection group of a DCP board
Question: The first protection group on a DCP board of a WDM network is used. The second protection group is not used, but the PS switching alarm is reported. What are the methods of monitoring the impact and handling the issue? Once the alarm is masked, the PS alarm of the first protection group is masked. Analysis: 1. BWS 1600G NEs support DCP boards of various versions. The PS alarms of the DCP boards are reported when the optical switches are in the standby state. Because the alarm distinguishes the protection groups according to alarm parameters, PS alarms of the entire board will be not monitored if the alarms are masked. Therefore, the alarms cannot be handled by masking them. 2. Based on the DCP board alarm mechanism, you can clear the PS alarm by setting the second optical switch to active. 3. Because there is no command for directly changing the optical switch status, use the second protection group that is logically configured and lock out the optical switch to the active state. Then the issue is rectified. Answer: 1. Configure two logical OTU boards on the NMS, and configure the second protection group to a wavelength protection group. 2. Issue a lockout command to this new protection group on the NMS. The alarm is cleared. 3. Delete the new logical protection group and OTU board.

Clearing of PS switching alarms reported by the protection groups not used by DCP
1. Configure two logical OTU boards on the NMS and configure a wavelength protection group together with the second protection group of the corresponding DCP board. 2. Issue a locking command to the new protection group on the NMS. The alarm is cleared. 3. Delete the newly configured logical protection group and OTU boards.

Server buzzer alarm sound
Currently server buzzer alarm sounds only make sense for the RH2488 V2: Power supply alarm: one long beep. A long beep usually means that a PSU fault occurs, or that two PSUs are present but only one has AC power input. Please check the power supply status and whether the power cable is connected properly. Backplane alarm: one long beep. If this sound is made, check the power supply and signal. RAID controller card alarm: beep once per second. This alarm usually means a RAID controller card or hard disk exception, for example, hard disk fault, RAID disk offline, RAID degrade, or RAID rebuild.

Base of the OSNR = 10 × log (Ps/Pa) formula
The base of the OSNR = 10 x log (Ps/Pa) formula is 10. Strictly speaking, lg should be used instead of log. However, the default base is recognized in the industry and related standards. Therefore, "log" is still used in the formula.

Method used to determine primary/secondary controllers
1. Method used to determine primary/secondary controllers: In the storage background: Determine primary/secondary controllers: Log in to the storage's MML mode and enter sys status. master indicates a primary controller. slave indicates a secondary controller. Determine primary/secondary controllers: Log in to the storage's CLI mode and enter showmaster. primary indicates a primary controller and secondary indicates a secondary controller. 2. Primary/Secondary switchover Note: Primary/Secondary switchover must be performed during off-peak hours. a. On the OSM GUI, choose System > System Information > Primary/Secondary Switchover. b. Log in to the storage's CLI mode, enter swapsys, and enter y when y or n is prompted.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top