Monitoring Your Network - Monitoring Alarms - Interpreting Alarm-Instance Information -
Using the NerveCenter Client      Viewing an Alarm Instance's History

Interpreting Alarm-Instance Information

The alarm-instance information that you can view using the NerveCenter Web Client and the NerveCenter Client is meant to stand on its own, that is, to provide you with all the information you need concerning a network condition. However, until you become familiar with all of the behavior models being used at your site, you might need some supplementary information. For example, suppose you see the summary information shown in Summary Alarm Information:

Summary Alarm Information

It's clear what node is being reported on. However, if you're not familiar with the Authentication alarm, it may not be clear what it means for an instance of this alarm to be in the state Alert3. (As it turns out, this state indicates that a node has received three authentication-failure traps within a ten-minute period.) To find out what this state means, you can use the NerveCenter Client to look at the documentation for, and definition of, this alarm. For information on this subject, see the section Getting Information about an Alarm.

Also, it may not always be clear what condition caused the Source to generate the trigger that led to the most recent alarm transition. In the figure above, a mask called AuthFail generated the trigger authFail. You can probably guess that a trap mask responded to an authentication-failure trap. But what if you were monitoring an instance of the alarm ifErrorStatus (which monitors the percentage of error packets on an interface) and the poll MediumErrorRate fired the trigger mediumErrorRate. You could infer that NerveCenter had seen a moderate number of error packets on an interface, but what constitutes a medium error rate? You can find out by using the NerveCenter Client to read the documentation for, or definition of, the MediumErrorRate poll. For further information on interpreting the meaning of a trigger, see the section Getting Information about a Trigger.

Getting Information about an Alarm

If you're monitoring alarm instances and have a question about a particular alarm or alarm state, you can easily obtain information about the purpose of the alarm and what states are defined.

 
  To get this information:

1. From the NerveCenter Client's Admin menu, choose Alarm Definition List.

   The Alarm Definition List window is displayed.

   

2. Select the alarm you're interested in.

   The Notes button is enabled.

3. Select the Notes button.

   The Alarm Notes and Associations dialog displays.

   

   These notes should include the following information:

   • A list of states and their severities
   • A list of transitions and the objects that can trigger those transitions
   • A list of the actions associated with each transition
   • A brief description of the purpose of the alarm
   • A description of each state in the alarm
   • Information about other alarms that are part of the same behavior model

     ---

        If you need further information about an alarm, you can look at its definition. To view this definition, select the alarm in the Alarm Definition List window and then select the Open button.

     ---

Getting Information about a Trigger

If you're monitoring alarm instances and want further information about the cause of an alarm transition, you can obtain that information using the NerveCenter Client. The specific procedure you should follow depends on the type of the trigger that caused the transition. Finding Information about the Source of a Trigger directs you to the appropriate subsection.

Finding Information about the Source of a Trigger

A Trigger Generated by a Poll

If you're monitoring alarm instances and see that an alarm transition took place when the poll CsCpuBusy fired the csCpuBusy trigger, how can you determine what condition caused the poll to fire this trigger? To get this information, follow the procedure below.

 
  To determine why a poll fired a trigger:

1. From the NerveCenter Client's Admin menu, choose Poll List.

   The Poll List window is displayed.

   

2. Select the poll you're interested in.

   The Notes button is enabled.

3. Select the Notes button.

   The Poll Notes dialog displays.

   

   For each poll, the note should include the following information:

   • A list of the triggers the poll can fire
   • A list of the alarms in which the poll can cause a transition
   • A list of other objects that can fire any one of the triggers fired by this poll
   • A brief description of the poll and its poll condition

     ---

        If you need additional information about a poll, you can look at its definition. To view this definition, select the poll in the Poll List window and then select the Open button.

     ---

A Trigger Generated by a Mask

If you're monitoring alarm instances and see that an alarm transition took place when the SynBoardPowerFail trap mask fired the synBoardPsTrap trigger, how can you determine what condition caused the mask to fire this trigger? To get this information, follow the procedure below.

 
  To determine why a mask fired a trigger:

1. From the NerveCenter Client's Admin menu, choose Mask List.

   The Mask List window is displayed.

   

2. Select the mask you're interested in.

   The Notes button is enabled.

3. Select the Notes button.

   The Mask Notes dialog displays.

   

   For each mask, the note should include the following information:

   • A list of the triggers that this mask can fire
   • A list of the alarms in which this mask can cause a transition
   • A list of other objects that fire any one of the triggers fired by this mask
   • A brief description of the trap detected by this mask

     ---

        If you need additional information about a mask, you can look at its definition. To view this definition, select the mask in the Mask List window and then select the Open button.

     ---

A Trigger Generated by an Alarm

If you're monitoring alarm instances and see that a transition in one alarm took place when another alarm fired a trigger, how can you determine what condition caused the Source alarm to fire this trigger? To get this information, you can look at the notes (documentation) for the Source alarm. Just follow the procedure mapped out in the section Getting Information about an Alarm.

A List of Built-In Triggers

If you're monitoring alarm instances and an instance changes states because of a built-in trigger, you can consult the table below to determine why NerveCenter generated the built-in trigger. Built-In Triggers lists all the built-in triggers that NerveCenter can fire.

---

   NerveCenter uses all uppercase letters to designate built-in trigger names.

Built-In Triggers

Trigger Name	Meaning
CANNOT_SEND	A local error occurred while NerveCenter was trying to send an SNMP message.
ERROR	An SNMP or ICMP request did not result in a valid response. After firing the ERROR trigger, NerveCenter fires a second trigger that indicates the specific nature of the error.
ICMP_ERROR	Indicates an ICMP error. The ICMP_ERROR trigger contains the ICMP/IP fields from the error message.
ICMP_TIMEOUT	NerveCenter sent an ICMP ping to a node and did not receive a response. This trigger generally indicates that the node in question is down. NerveCenter uses the number of retries and retry interval specified on the SNMP tab in the Administrator. Refer to the Managing NerveCenter guide for details.
ICMP_UNKNOWN_ERROR	NerveCenter sent an ICMP ping to a node and received an invalid response. This trigger is no longer used except for the purpose of backward compatibility with version 3.5. We recommend you use it sparingly in the current version.
INFORM_CONNECTION_DOWN	A NerveCenter Inform host connection with OVPA is down.
INFORM_CONNECTION_UP	A NerveCenter Inform host connection with OVPA was down but is now back up.
INFORMS_LOST	The number of NerveCenter Informs that were unacknowledged and lost, usually while the inform host connection with OVPA was down.
NET_UNREACHABLE	Indicates that the IP routing layer could not find a route to the network containing the polled node, usually because at least one router was down. This trigger indicates nothing about the status of the node. This trigger can be issued only if you have a router between the workstation running NerveCenter and the polled node.
NODE_UNREACHABLE	Indicates that the IP routing layer could not find a route to the destination node. This trigger indicates nothing about the status of the node. This trigger can be issued only if you have a router between the workstation running NerveCenter and the polled node.
PORT_UNREACHABLE	NerveCenter sent a message to a node, and there was no response from the port to which the message was sent.
RESPONSE	NerveCenter sent an SNMP message and received a valid response from the agent on the destination node.
SNMP_AUTHORIZATIONERR	An SNMP v3 authorization error caused because there is a mismatch between one or all of the rows of vacmAccessTable and the packet. Reasons include: context name mismatch (vacmAccessContextPrefix); security model is not used (vacmAccessSecurityModel); incorrect security level (vacmAccessSecurityLevel); unauthorized to read the MIB view for the SNMP context (vacmAccessReadViewName); unauthorized to write to the MIB view for the SNMP context (vacmAccessWriteViewName); unauthorized to notify the MIB view for the SNMP context (vacmAccessNotifyViewName)
SNMP_BADVALUE	NerveCenter tried to set the value of an attribute in a MIB, but the value it supplied was inappropriate for the attribute. The value may have been of the wrong type, of the wrong length, or invalid for some other reason.
SNMP_DECRYPTION_ERROR	The SNMP v3 engine dropped packets because they could not be decrypted. The 32-bit counter, usmStatsDecryptionErrors, is greater than zero.
SNMP_ENDOFTABLE	NerveCenter fires SNMP_ENDOFTABLE when it finds no more rows while performing an SNMP walk of a MIB table. For example, you could walk IfTable to determine the number of DSO interfaces a node contains.
SNMP_GENERR	A GetRequest, GetNextRequest, or SetRequest failed for some unknown reason (general error).
SNMP_NOSUCHNAME	NerveCenter sent to an SNMP agent a GetRequest, a GetNextRequest, or a SetRequest, and the agent that was contacted was unable to perform the requested operation because: The name of the attribute to be read did not match exactly the name of an attribute available for get operations in the relevant MIB view The name of the attribute to be read did not lexicographically precede the name of an attribute available for get operations in the relevant MIB view The attribute to be set was not available for set operations in the relevant MIB view
SNMP_NOT_IN_TIME_WINDOW	The SNMP v3 engine dropped packets because the boots and timeticks sent in the PDU appeared outside of the authoritative SNMP agent's time window. The 32-bit counter, usmStatsNotInTimeWindows, is greater than zero.
SNMP_READONLY	The error readOnly is not defined in RFC 1157. However, some vendors' agents do use this error-status code. As the name implies, the error usually indicates that an agent has received a SetRequest (from NerveCenter, in this case) for an attribute whose access type is read only.
SNMP_TIMEOUT	NerveCenter sent an SNMP message to an agent and did not receive a response. This trigger indicates either that a node's SNMP agent is down or that the node itself is down. NerveCenter uses the number of retries and retry interval specified on the SNMP tab in the Administrator. Refer to the Managing NerveCenter guide for details.
SNMP_TOOBIG	An SNMP agent did not respond normally to a GetRequest, GetNextRequest, or SetRequest from NerveCenter because the size of the required GetResponse would have exceeded a local limitation.
SNMP_UNAVAILABLE_CONTEXT	The SNMP v3 engine dropped packets because the context contained in the message was unavailable. The 32-bit counter, snmpUnavailableContexts, is greater than zero.
SNMP_UNKNOWN_CONTEXT	The SNMP v3 engine dropped packets because the context contained in the message was unknown. The 32-bit counter, snmpUnknownContexts, is greater than zero.
SNMP_UNKNOWN_ENGINEID	The SNMP v3 engine dropped packets because they referenced an snmpEngineID that was not known to the SNMP v3 engine. The 32-bit counter, usmStatsUnknownEngineIDs, is greater than zero.
SNMP_UNKNOWN_USERNAME	The SNMP v3 engine dropped packets because they referenced a user that was not known to the SNMP v3 engine. The 32-bit counter, usmStatsUnknownUserNames, is greater than zero.
SNMP_UNSUPPORTED_SEC_LEVEL	The SNMP v3 engine dropped packets because the requested security level is unknown or unavailable. The 32-bit counter, usmStatsUnsupportedSecLevels, is greater than zero.
SNMP_WRONG_DIGEST	The SNMP v3 engine dropped packets because they didn't contain the expected digest value. The 32-bit counter, usmStatsWrongDigests, is greater than zero.
UNKNOWN_ERROR	Some other error occurred.

---

---

One additional trigger, USER_RESET, is not available from the list of built-in triggers in NerveCenter. NerveCenter fires USER_RESET to trigger another state for an existing alarm instance when you reset the alarm instance using the right-click pop-up menu in the Alarm Summary or Aggregate Alarm Summary windows.