Designing and Managing Behavior Models - Behavior Models and Their Components - NerveCenter Objects - Nodes -
NerveCenter Objects      Constructing Behavior Models

Nodes

In NerveCenter terminology, a node is either a workstation or a network device such as a router. NerveCenter monitors and manages a set of nodes, and each behavior model manages a subset of those nodes.

A node object has the data set shown in Definitions of Node Attributes. The table explains what information these data members contain and, where appropriate, how NerveCenter uses that information.

---

   The names of the data members shown in Definitions of Node Attributes match the labels used in NerveCenter's Node Definition window, where you create and modify node objects.

---

Definitions of Node Attributes

Property Groups and Properties

Another attribute of a node -- one that requires a little explanation -- is the node's property group. A property group is a list of properties, which are strings that generally name either an object in the management information base (MIB) used to manage a node, or the role the node plays in the network (such as "router"). These property strings can be:

• The name of a MIB base object
• A user-defined string

  Property Groups and Properties

  

Property groups are assigned to nodes and control which nodes will be contacted by a particular poll and which nodes can be monitored using a particular alarm. Both types of properties -- MIB base objects and user-defined strings -- play a part in making these determinations.

For example, NerveCenter ships with a predefined property group called Router. This property group contains the following properties.

atEntry	ip	snmp
egp	ipAddrEntry	system
egpNeighEntry	ipNetToMediaEntry	tcp
icmp	ipRouteEntry	tcpConnEntry
ifEntry	nl-ping	udp
interfaces	router	udpEntry

In this case, all the properties are MIB objects except "router," which describes the type of the device.

For the person who programs NerveCenter to monitor particular devices for specific error conditions, the properties associated with each node are important. These properties allow the programmer to define which devices NerveCenter should poll for MIB data and which error conditions NerveCenter should look for on each device, among other things.

You can filter the nodes that you are monitoring based on their properties. For example, you might choose to monitor only nodes that have been assigned the Router property group, that is, all routers.

Polls

A NerveCenter poll periodically sends an SNMP message to a set of nodes, requesting information from the agents running on those nodes. When the poll receives this information from a node, it uses the information in the evaluation of a poll condition, which may cause a trigger to be fired. For example, a poll may fire a trigger if the number of discarded packets on an interface is too high. The poll condition must be able to fire at least one trigger, and may be capable of firing several. These triggers can cause alarms to be instantiated, to change states, or perform actions -- under the right circumstances.

The key attributes of a poll are listed in Definitions of Poll Attributes This table explains what information these data members contain and, where appropriate, how NerveCenter uses that information.

---

   The names of the data members shown in Definitions of Poll Attributes match the labels used in NerveCenter's Poll Definition window, where you create and modify poll objects.

Definitions of Poll Attributes

Data Member	Definition
Name	A unique name that you assign to the poll.
Property	The Property attribute is a string. This string determines (in part) whether a poll will request MIB data from a particular node. Only if the node's property group contains the poll's property can polling possibly occur. However, before a poll will request information from a node's SNMP agent, other conditions must be satisfied as well. For further information, see the explanation below for Poll Condition.
Port	Optional. If you specify a port number here, NerveCenter will send the poll to this port on the nodes that are configured to receive the poll. Otherwise, NerveCenter will send the poll to the port specified in each node's definition.
Poll Rate	The number of seconds, minutes, or hours between polls.
Enabled	A poll's enabled status (Off or On) is similar to a node's Managed status. That is, if a poll is disabled, it will never send a request to an SNMP agent.
Poll Condition	The Poll Condition is a Perl script that can fire one or more triggers. Which trigger is fired (if any) depends of what data the poll retrieves from an SNMP agent. Generally, this data is used in evaluating an if statement. This poll condition must be expressed in terms of one MIB base object. For example, a valid condition would be: if (delta( snmp.snmpInBadCommunityNames ) >= 1 or delta( snmp.snmpInBadCommunityUses ) >= 1) { FireTrigger("AuthFail"); } In this case, the base object is snmp. The name of this base object must be one of the properties in a node's property group before the node can receive a request from a poll with this poll condition.
Suppressible	A poll's Suppressible attribute works in conjunction with a node's Suppressed attribute. If a node is suppressed and a related poll is suppressible, that poll will not query that node. If a poll is not suppressible, then it will poll even a suppressed node. Generally, the only polls that are insuppressible are those designed to determine when an unresponsive node becomes responsive again. When a node becomes responsive, the behavior model of which the poll is a part can change the status of the node from suppressed to unsuppressed. (You set an attribute of a node using the Set Attribute alarm action.)

---

---

If a poll fires a trigger, that trigger has the attributes shown in Definitions of Trigger Attributes.

Definitions of Trigger Attributes

A trigger's Name, Node name/IP address, Subobject, and Property are all important when it comes to determining what effect, if any, a trigger has on an alarm. You'll find more on this subject in the section Constructing Behavior Models.

Trap Masks

A trap mask filters SNMP traps that NerveCenter receives. Based on criteria that you specify, the trap mask either filters out each trap or fires a trigger in response to it. A trigger fired by a mask is exactly the same as a trigger fired by a poll except that a trap trigger contains the trap's variable binding list instead of the values of MIB attributes. (For further information about the trigger object, see the section Polls.)

The principal attributes of a trap mask are shown in Definitions of Trap Mask Attributes. The table explains what information these data members contain and, where appropriate, how NerveCenter uses that information.

---

   The names of the data members shown above match the labels used in NerveCenter's Mask Definition window, where you create and modify trap masks.

Definitions of Trap Mask Attributes

Attribute	Definition
Name	The name of the trap mask.
Generic	The generic trap type is an enumeration constant indicating the nature of the event being reported: 0 -- coldStart 1 -- warmStart 2 -- linkDown 3 -- linkUp 4 -- authenticationFailure 5 -- egpNeighborLoss 6 -- enterpriseSpecific You supply a Specific trap number (see below) only if the generic trap type is 6.
From	Indicates that the object identifier (OID) contained in the trap's Enterprise field must represent a branch in the MIB tree that is the same as, or subordinate to, the branch represented by the contents of the trap mask's Enterprise field.
From Only	Indicates that the OID contained in the trap's Enterprise field must match the trap mask's Enterprise attribute exactly.
Enterprise	An OID (or name) representing the object referenced by the trap.
Specific	A trap number supplied by the vendor of the product whose agent generated the trap. The significance of the trap number is defined in an ASN.1 file provided by the vendor.
Trigger Type	Trigger Type can be set to either Simple Trigger or Trigger Function. See the next two table entries for definitions of these trigger types.
Simple Trigger	A simple trigger is one that will be fired whenever the trap mask sees a trap that meets the criteria specified in the fields discussed above. The value of this attribute affects how this object interacts with other objects in a behavior model.
Trigger Function	A trigger function is a Perl script that is called whenever the trap mask sees a trap that meets the criteria specified in the fields discussed above. This function typically looks at information in the trap's variable bindings and fires a trigger if a condition is fulfilled. The trigger function fires this trigger using NerveCenter's FireTrigger() function. The value of this attribute affects how this object interacts with other objects in a behavior model.
Enabled	As with a poll, a trap that is disabled (Enabled is set to Off) is nonfunctional.

---

---

Alarms

As mentioned in the section Behavior Models on page 15, a NerveCenter alarm consists primarily of a state diagram, which defines the alarm's states, the transitions between states, and the alarm actions to be performed when each transition takes place. This alarm definition is analogous to a class in object-oriented programming. That is, the alarm itself does not monitor a network condition; rather, an alarm instance (comparable to an object) is created to track such a condition.

For example, the section Behavior Models on page 15 showed the definition of an alarm designed to monitor traffic on an interface.

Definition of the alarm IfLoad

If NerveCenter detects a medium or high level of traffic on an interface it is managing, it creates an instance of this alarm to track the condition. If NerveCenter detects medium or high traffic on five interfaces, it creates five instances of the alarm. Each instance of the alarm maintains such information as:

• The instance's current state
• The severity of that state
• The node the instance is monitoring

In addition, each alarm instance causes the appropriate alarm actions to take place when a state transition occurs.

If five instances of IfLoad are created, how do you distinguish them? Depending on the scope of the alarm, you might need to look at the instance's node attribute or at both its node and subobject attributes.

In NerveCenter, alarms can have one of four scopes: enterprise, instance, node, or subobject. Only one instance of an enterprise-scope alarm can be created. This instance monitors a condition across all managed nodes. For example, one alarm instance could cause an action to take place if three or more routers in an enterprise are down at the same time.

A node-scope alarm monitors a single managed device for a condition. For instance, the alarm SnmpStatus (shipped with NerveCenter) determines whether a device is in a normal state, unreachable, down, or up but unable to respond to SNMP requests. An instance of this type of alarm can be identified by its alarm name and the name of the node it is monitoring. This node name is an attribute of the alarm instance.

A subobject-scope alarm most often monitors an interface on a device. For example, an instance of the alarm IfLoad monitors each interface that is experiencing a medium to high level of traffic. This type of instance can be identified by its alarm name, the name of the node it is monitoring, and the name of the subobject being monitored. This subobject name is usually composed of the name of a MIB table followed by an instance number. That is, if an instance of the IfLoad alarm is monitoring port 2 on a device, its subobject attribute has the value ifEntry.2.

Instance scope alarms track instances for every interface or port that fits the polled condition regardless of the base object. Instance scope is similar to Subobject scope but has the following difference: Instance scope lets you monitor any instance for different base objects. This allows you to track a variety of events for any managed subobject in a single alarm instance.

Alarm Scope

All NerveCenter alarms have a property called scope. This property can have one of four values:

• Subobject
• Instance
• Node
• Enterprise

If an alarm has Subobject scope, an instance of that alarm tracks activity on a component that can be described using a nonzero MIB object instance, for example, an interface on a router.

Instance scope alarms track instances for every interface or port that fits the polled condition regardless of the base object. Instance scope is similar to Subobject scope but has the following difference: Instance scope lets you monitor any instance for different base objects. This allows you to track a variety of events for any managed subobject in a single alarm instance.

If an alarm has Node scope, an instance of that alarm tracks activity on a single device. If an alarm has Enterprise scope, an instance of that alarm tracks activity on all managed nodes.

---

   It might be useful to think of an alarm instance as a copy of the alarm's state diagram whose current state is something other than Ground.

---

Why is NerveCenter architected this way? Well, think about the following network management problem: You want to be notified whenever four interfaces on a device experience high traffic.

Your first step in solving this problem might be to create a poll that detects high traffic on an interface and fires the trigger highTraffic. You might then create an alarm with node scope and five states, as shown in Possible Alarm Diagram for Looking for High Traffic on Four Interfaces.

Possible Alarm Diagram for Looking for High Traffic on Four Interfaces

Most likely, this alarm won't detect the condition you're looking for because all four transitions can be effected if the poll repeatedly detects high traffic on a single port.

To solve your problem, the trigger highTraffic must cause one or more transitions in a subobject scope alarm, and this alarm must fire a busyPort trigger (using the Fire Trigger alarm action) during its final transition. Such an alarm is shown in A Subobject Scope Alarm.

A Subobject Scope Alarm

When the high-traffic poll detects high traffic on an interface, a subobject scope alarm will be instantiated, and the transition highTraffic will occur. During this transition, the alarm will fire a trigger called busyPort. Note that once a subobject alarm instance transitions to the BusyPort state, additional high-traffic triggers for the interface concerned have no effect. However, if the high-traffic poll detects high traffic on other interfaces, new alarms will be instantiated and fire the trigger busyPort. Each instance fires its own busyPort trigger.

Now a node scope alarm similar to the one shown in Node Scope Alarm Detecting High Traffic from Four Alarm Instances can be configured to receive up to four busyPort triggers, each one from its own instance of the high traffic alarm. Each busyPort trigger signals high traffic on a different interface.

Node Scope Alarm Detecting High Traffic from Four Alarm Instances

An instance scope alarm behaves in a similar manner as the subobject scope alarm. The main difference between subobject and instance scope is that, with instance scope, you could add another transition to the alarm to monitor a different base object than the one for high traffic. Then, the alarm could be instantiated by the high-traffic poll and then transition again when an entirely different condition (MIB object) is detected.