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. Filter alarm lists, identify root causes, and determine alarm impacts.

The alarm lists display all alarms against NEs in your network. The lists can be filtered and sorted in a variety of ways to reduce the number of visible alarm messages to a manageable number. Open an alarm list from a specific NE to view alarms only for that NE. There are three categories of alarm lists, available from the drop-down list:

• The current alarm list displays all active alarms in the network, or for specific NEs. The global current alarm list is kept updated in real-time. Current alarm lists accessed from the Top Unhealthy NEs or Top Problems views are updated on demand.

• The merged alarm list displays all active and previously-active alarms in the network (or for specific NEs) over a specified time period.

• The historical alarm list displays all previously-active alarms in the network (or for specific NEs) over a specified time period.

Alarm severity levels

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?.

Role-based access control for alarms

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.

Role-based access 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. Role-based access for optical trail alarms is only supported in deployments that include the NRC-X.

Alarm reload behavior

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 23.11 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.