How does the NSP manage alarms?

NSP fault management

The NSP provides alarm monitoring, correlation, and troubleshooting for the most unhealthy NEs in the network. You can use the NSP to filter alarm lists, identify root causes, and determine alarm impacts.

The NSP receives alarms from managed equipment through a variety of possible means, depending on your network. The NSP collects those alarms and then applies root cause analysis and any configured alarm policies. The resulting alarm information is displayed in the Network Health dashboard in several views and lists, through which you can interact with and manage the alarms.

What alarm severity levels are supported?

The NSP supports the following alarm severity levels:

• Cleared

• Indeterminate

• Info

• Condition

• Warning

• Minor

• Major

• Critical

Alarm severity levels are color-coded. An administrator can change the colors assigned to each severity level; see the NSP System Administrator Guide for information about modifying alarm severity colors. You can manually change the severity of an alarm, or configure the NSP to change the severity of an alarm when it is received; see How do I automate alarm management using a policy?.

How does user access control affect what alarms are displayed?

Alarm-related navigation actions require write or execute access to the object affected by the alarm. Opening an NE Session requires execute access to the corresponding NE.

User access control is not supported on the historical and merged alarms lists, or on historical alarm REST and RESTCONF requests, which may show alarms outside of a user’s assigned role. User access control for optical trail alarms is only supported in deployments that include the NRC-X.

What happens when I reload alarms from MDM and WS-NOC sources?

When alarm messages from MDM and WS-NOC sources are modified or deleted in NSP, the change is recorded in the NSP database, but not at the alarm source. If alarms are bulk-reloaded from an MDM or WS-NOC source to the NSP, previously modified or deleted alarms from that source are handled in the following manner:

• For alarms with modified fields, any data already in the NSP database is not overwritten by the reloaded alarm.

• Alarms in the NSP database that are tagged as Transient (i.e., not standing alarms) are not deleted by the reload, even if they are no longer present on the source system.