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.

How do I use advanced filters from previous NSP versions?

Advanced filters that were created in NSP Release 23.8 and earlier are not compatible with NSP Release 23.11 or later. Automated filter migration is not supported in the base 24.8 release; however, support is planned to be introduced in a service pack. The Service Pack notes will announce the availability of the feature when supported.

Filters that require your attention because the migration failed to produce a usable filter have * before the filter name and are displayed in red; unusable filters appear in the filter list but cannot be added to functions such as watched filters and e-mail policies. Filters with duplicate names (for example, when a filter from 23.8 is migrated but a new filter already exists with the same name) have “(migrated)” appended to the filter name.

Filters that were used with an e-mail policy are removed from the policy, and the policy becomes disabled. Associate the filter with the e-mail policy and re-enable it to restore the policy.

Note: Check all migrated filters before use to ensure the automatic migration produced a filter that provides the results you need. The automatic migration is a tool to assist you in migrating filters, but the results are not guaranteed to filter exactly the same as the original filter.

If you have a filter you need to manually upgrade, perform the following modifications to the filter strings:

• ensure there are double quotation marks around keys and values

• ensure that all operators (and, or, not) are lower-case

• ensure timestamp comparisons are valid; timestamps can only be compared up to the second, not millisecond

• separate all ‘between’ operators into two conditions, one <= and one >=

• remove the following unsupported operators:

  • is null

  • In the Past

  • equals (match case)

  • not equal (match case)

• update operators to React format as described in the following table:

Previous format (Smartclient)	Current format (React)	Notes
equals	=	This operator is case-sensitive
notEqual	<>	This operator is case-sensitive
less than	<
greater than	>
less than or equal to	<=
greater than or	>=
contains	contains
does not contain	not contains
between (inclusive)	between	This operator is internally translated to >= and <= operators
is null	= ‘null’
wildcard	like, not like, starts with, ends with
AND	and
OR	or
NOT	not
In the Past	>	SmartClient uses this as a relative offset, but a similar function does not exist in React. The React operator only compares time in absolute reference time.