Configuring user-defined alarms for GNEs

Standard alarms

The NFM-P monitors SNMP reachability and interface status, and raises a standard alarm for each of the following events:

• coldStart—The GNE restarts.

• linkDown—An interface goes out of service.

• linkUp—An interface returns to service.

GNE alarm catalogs

You can map GNE SNMP traps to user-defined NFM-P alarms in an alarm catalog, and associate the catalog with a GNE profile. A GNE profile can have one alarm catalog that contains up to 150 trap-to-alarm mappings.

A mapping is one of the following types:

• static—A specific SNMP trap is associated with a specific alarm.

• dynamic—The mapping includes one or more transform functions that define alarm properties based on values in SNMP trap PDUs.

Each mapping in a catalog defines an alarm that the NFM-P raises or clears when it receives a specific SNMP trap. When the NFM-P receives a high trap volume and must discard traps that it cannot process, it does not distinguish between standard and user-defined traps. To conserve system resources, Nokia recommends that you configure a GNE to send only the required traps to the NFM-P.

Traps that map to user-defined alarms require extra processing by the NFM-P and are managed in a separate, resource-limited queue. When this queue fills, the NFM-P discards some of the traps and raises an alarm. You can monitor the queue length using the NFM-P Resource Manager. When a mapping is administratively disabled, the NFM-P raises no alarm in response to an associated trap from a GNE.

GNE trap sequencing and throttling support are configurable in a GNE profile. After the NFM-P finishes throttling traps from a GNE or encounters a trap sequence error, it resynchronizes the discovered device MIBs.

A mapping includes standard elements such as the trap OID, alarm type, probable cause, and severity, but can include the following optional elements:

• trap name

• self-clearing designation—specifies that the alarm clears when a specific clearing trap is received, and has the following requirements:

  • If the severity of the raising alarm is a static value, the clearing trap must have a static mapping in the same catalog as the raising trap, and can be linked to only one raising trap.

  • If the severity of the raising alarm is defined using a transform function, the transform function must include a raising value pair and a clearing value pair.

• FDN extension, which is an alarm-name extension that can include the following:

  • static text

  • scripting functions—expressions that specify the trap PDU values to include; these allow the same alarm type to be raised in response to different traps while uniquely identifying the trap origin in the alarm name.

• additional text—used to provide information of value related to the trap event, for example, troubleshooting actions; the additional text consists of the trap OID by default, but can include the following:

  • static text

  • scripting functions—expressions that specify the trap PDU values to include; these are used to generate a more precise description of the alarm condition

• System Address and/or Interface Index varbind positions for a GNE on which to raise an alarm

Note: The FDN extension of a GNE alarm is not appended to the Alarm Name field in the NFM-P GUI, but is included in the Additional Text field. To create a filter for GNE alarms that have FDN extensions, you must filter on the Additional Text field.

You cannot filter on the Additional Text column on the dynamic alarm list, Faults tab, and Correlated Alarms tab.

When the NFM-P drops or fails to receive an SNMP trap from a GNE, the trap is lost. The NFM-P is unable to request that a GNE resend an SNMP trap.

If reliable communication via SNMP protocol is required, use “inform event” messaging instead of trap notifications.

A change to an alarm catalog or to a mapping in a catalog takes effect immediately after you commit the change.

You can use an NFM-P GUI or OSS client to configure GNE alarm catalogs and alarm mappings. The GUI supports the following methods:

• configuration forms—for object creation, modification, viewing, and deletion

• XML API script—for object creation and modification only

  A script template for alarm catalog configuration is available at the following location:

  /opt/nsp/nfmp/server/nms/sample/xmlapi/AlarmCatalogue-Template.txt

An OSS client can also retrieve a catalog or a subset of the alarm mappings in a catalog using the standard methods.

Transform functions

A transform function is an optional catalog component that associates one or more values in an SNMP trap PDU with an alarm property such as the alarm name, probable cause, or severity. For example, you can create a transform function that assigns an alarm severity of Critical when the value in a specific varbind is 1, Major when the value is 2, and Minor when the value is 3.

When an alarm mapping includes one or more transform functions, the NFM-P can raise multiple alarms in response to the same SNMP trap. A trap value and the associated alarm property value are specified as a value pair in a transform function. You can also specify a default alarm property value that the NFM-P assigns to an alarm when a received value is not defined in a value pair.

A transform function defines the input value type, such as integer, and the output alarm property type, such as severity. You can modify these parameters only when the transform function does not contain a value pair and is not used by a mapping.

A transform function returns an empty string when a received value is not defined in a value pair and no default alarm property value is assigned. When the transform function defines the alarm name, probable cause, or severity, the NFM-P logs an error in response and does not raise an alarm.