Learning How to Create Behavior Models - How to Use Behavior Models - How to Create Useful Behavior Models -
What is a Behavior Model?      Review and Summary

How to Create Useful Behavior Models

Over the course of the previous chapters you have created several behavior models. One behavior model detects high traffic. Another detects authorization failures. You also created other behavior models that were variations of these.

In this next scenario you don't want to be notified every time there is a problem. Instead, you want to know only when there is a persistent problem. Also, you want to know which nodes are not responding to NerveCenter's monitoring activities.

This scenario includes five activities:

1. Using a Counter to Detect Persistence
2. Notifying of a Persistent Condition
3. Using a Timer to Detect Persistence
4. Detecting Unresponsive Nodes
5. Testing for an Unresponsive Node

Using a Counter to Detect Persistence

In a previous chapter you developed a behavior model for detecting high-traffic conditions on the CriticalDevices nodes.

This first activity will step you through the first stage of using a counter to check for the persistence of high traffic.

 
  To use a counter to detect persistence:

1. Create a new alarm with the following characteristics:
   • Name: 1PersistentTraffic
   • Property: myNodes
   • Scope: SubObject
2. In the state diagram, add a state naming it Busy.

   

   The state should have a traffic severity of Medium.

3. In the state diagram, add a transition to move from the Ground state to the Busy state when the trigger portTraffic is fired.

   

4. Add another transition to be triggered by portTraffic. This transition should be circular, transitioning from the Busy state to the Busy state.
5. In the Transition Definition window for the circular transition, select New Action. From the list of alarm actions, select Alarm Counter.

   NerveCenter displays the Alarm Counter Action window.

   

6. In the Name field, type BusyCount.
7. In the Operation area, select Increment.
8. In the FireTrigger field, type tooBusy.
9. In the when counter equals field, type 3.
10. In the Alarm Counter Action window, select OK. In the Transition Definition window, select OK.

    The state diagram now includes a circular transition called portTraffic. Resize and position the icons to make the state diagram easier to read.

11. Add another transition to move from the Busy state to the Ground state when the notBusy trigger is fired.

    ---

       The notBusy trigger was created in the Chapter Review Exercises on page 33. You must complete that exercise before you can create this second transition.

    ---

12. In the Transition Definition window, select New Action. From the list of alarm actions, select Alarm Counter.

    The Alarm Counter Action window is displayed.

13. In the Counter Name field, select BusyCount.
14. Check the Set Counter checkbox, leaving the new counter value at 0.

    If the 1HighTraffic poll fires the notBusy trigger before the alarm counter BusyCount reaches three, the alarm will return to the Ground State. It will also return the count for BusyCount to zero. This way, the counter starts over any time the alarm receives a notBusy trigger.

15. In the Alarm Counter Action window, select OK. In the Transition Definition window, select OK.

    You may need to resize and position the icons to be able to make the state diagram easier to read.

16. In the Alarm Definition Window, select Save.

    ---

       It is important to save at this point so that NerveCenter has a chance to put the tooBusy trigger into its database. Otherwise you will not be able to use it in the next activity.

    ---

You have completed the first stage of creating a behavior model to detect persistent high traffic conditions. The next activity will step you through the process of creating an action to inform your network management platform of a high-traffic event.

Notifying of a Persistent Condition

In the last activity you began creating a behavior model with a counter that would test for the persistence of high-traffic conditions. Should traffic decrease on the interface before the counter reached three, the alarm would be returned to normal, and you would not be bothered.

This next activity steps you through the process of completing the behavior model. Should the high-traffic conditions persist, the alarm will move to a new state. It will also notify your network management platform using the alarm action inform.

---

   The portion of this activity from step 3 to step 6 assumes you are using NerveCenter to notify a network management platform, such as OpenView. If you are using NerveCenter by itself, you may substitute for the Inform action the alarm action of your choice.

---

 
  To use inform:

1. From the toolbar of 1PersistentTraffic's state diagram, select Add State.

   

   Name the state TooBusy and assign it a traffic severity of Very High.

   Resize and position the icon as necessary.

2. Add a transition, which moves from the Busy state to the TooBusy state when the tooBusy trigger is fired.

   

   If the tooBusy trigger is not available, make sure you saved at the end of the activity Using a Counter to Detect Persistence.

3. In the Transition Definition window, select New Action. From the alarm action list, select Inform.

   The Inform Action window appears.

   

   The Inform action sends a trap-like message to either a network management platform like HP OpenView or another NerveCenter. The only argument is a specific trap number.

   NerveCenter users are permitted to use any number in the range 100000 to 199999. Numbers below 100000 are used in predefined behavior models.

4. In the Specific Number text field, type the number 111111 or any other number in the appropriate range.

   If you do not enter a number in the Specific Number field, NerveCenter will assign a default number that will send a message that is not particularly informative.

5. In the Inform Action window, select OK. In the Transition Definition window, select OK.
6. In your network management platform, configure an event to display the message "Persistent high traffic detected" in the event browser.

   The new event should be configured for the specific trap number 111111 or the number you entered in step 4. See your network management platform's documentation for further instructions.

7. In the Alarm Definition window, select Save.
8. Turn the 1CheckTraffic poll and the 1PersistentTraffic alarm to on.

The Process that Occurs when 1PersistentTraffic is Enabled

You have just completed creating a behavior model which will only notify you when a persistent problem occurs. The next activity will step you through the process of using another NerveCenter feature to detect persistence, the timer.

Using a Timer to Detect Persistence

In a previous chapter, you created a behavior model to detect unauthorized communication attempts. However, you don't want to be bothered every time a glitch in the network causes a generic 4 trap to be sent out. You want your behavior model to notify you only of repeated attempts to breach security.

Earlier in this chapter you used a counter to detect a persistent condition. In this activity you will use a timer.

 
  To use a timer to detect persistence:

1. Create a new alarm called 1PersistentAuthFail.

   Set the Property field to myNodes and the Scope field to Node.

2. In the alarm's state diagram, add a state.

   

   Name it Trap4Received and assign it a fault severity of Minor.

3. In the state diagram, add a transition that moves from the Ground state to the Trap4Received state when the trigger authFailTrig is fired.

   

4. In the Transition Definition window, select New Action. From the alarm action list, select Fire Trigger.

   The Fire Trigger Action window appears.

   

   Similar to polls and masks, alarms can fire triggers. This trigger will carry the name you give it, the name of the object instance, the node for the alarm instance, and the property associated with the alarm.

5. In the Trigger Name field, type authTimeout. In the Delay area, type 2 and select Minutes.

   When the behavior model receives its first authentication failure trap, it starts a two-minute timer. After two minutes, the alarm will fire the authTimeout trigger.

6. In the Fire Trigger Action window, select OK. In the Transition Definition window, select OK. In the Alarm Definition window, select Save.

   It is important to save at this point, so that you will be able to use the authTimeout trigger in other parts of the alarm.

7. Add a transition that moves from the Trap4Received state to the Ground state when the trigger authTimeout is fired.

   This transition moves the alarm back to ground two minutes after the first authentication failure.

   Resize and position the icons to make the state diagram easier to read.

8. Add another transition that moves from Trap4Received to itself, caused by the authFailTrig trigger. Add to this transition the Inform action, using an appropriate trap number.
9. In the Transition Definition window, select New Action. From the alarm action list, select Clear Trigger.

   The Clear Trigger Action window appears.

   

10. From the Trigger Name list, select authTimeout.

    Should another authentication failure occur for this node within two minutes of the first, this action will delete the authTimeout trigger. The alarm will not be able to return to the Ground state. The Inform action will occur for every authentication failure after the first.

11. In the Clear Trigger Action window, select OK. In the Transition Definition window, select OK. In the Alarm Definition window, select Save.
12. Turn the mask 1CheckAuth and the alarm 1PersistentAuthFail on.
13. Use trapgen to simulate two generic 4 traps from the same node within two minutes of each other.

    The Alarm Summary window will display the progress of the 1PersistentAuthFail alarm.

    

You have now created two behavior models that inform your network management platform only when there is a persistent problem.

The next activity will explain how to create a behavior model that detects unresponsive nodes.

Detecting Unresponsive Nodes

In previous activities you have created behavior models that monitor nodes within the CriticalDevices group. But what if one of the nodes in the group is not responding?

This activity steps you through the process of creating a behavior model to place unresponsive nodes into another property group.

 
  To handle unresponsive nodes:

1. Create a new alarm, naming it 1DeadNode. Set the Property field to myNodes and the Scope field to Node.
2. In the alarm's state diagram, add a state. Name it NoResponse and assign it a fault severity of Warning.

   

   Resize and position the icon to make the state diagram easier to read.

3. In the state diagram, add a transition that will move from the Ground state to the NoResponse state.

   

4. In the trigger field, select ERROR.

   The ERROR trigger is one of the predefined triggers provided by NerveCenter. Like all the built-in triggers, ERROR is in capital letters so that you can distinguish it from user-defined triggers. The ERROR trigger automatically fires whenever NerveCenter doesn't get a response from an SNMP get request when polling a device. This condition is usually interpreted to mean the device is down.

5. In the Transition Definition window, select New Action. From the alarm action list, select Set Attribute.

   The Set Attribute Action window appears.

   

   The Set Attribute action allows you to change certain attributes of a poll, mask, alarm, or node. In this case you want to assign a new property group to the unresponsive node.

6. In the Set Attribute Action window, set the Object Type field to Node and leave the Name field at the default $NODE. From the Attribute list, select Property Group.

   This tells NerveCenter to change the property group of the unresponsive node that instantiated the alarm.

7. From the Value list, select the Troublemakers property group.

   ---

      The Troublemakers property group was created in the Review Exercises on page 21. You must complete that exercise before you can define this action.

   ---

8. In the Set Attribute Action window, select OK. In the Transition Definition window, select OK.
9. In the Alarm Definition window, select On and Save.

You have just finished creating a behavior model that will assign a different property group to an unresponsive node. The next activity will explain how to test such a behavior model.

Testing for an Unresponsive Node

In the last activity you created a behavior model to detect an unresponsive node.

This activity will step you through the process of testing that behavior model.

 
  To test for an unresponsive node:

1. From the Admin menu, choose Node List.

   

   NerveCenter displays the Node List window.

2. In the Node List, highlight one of the devices in the CriticalDevices group. Select Open.

   The Node Definition window appears.

   

3. In the Node Definition window, select the SNMP tab.

   NerveCenter displays the SNMP page.

   

4. In the Read Community field, delete the current value and type in garbage. Select Save.

   A bad community string causes an SNMP timeout error, which your new alarm 1DeadNode will interpret as your device being down.

   ---

      Remember to write down the correct name of the Read Community. You will need it later to restore the node to its original setting.

   ---

5. Enable the 1CheckTraffic poll and the 1HighTraffic alarm.

   The ERROR trigger will not be fired unless an unresponsive node is polled. This is why you must first turn on 1CheckTraffic. Because of smart polling, the 1CheckTraffic poll will not work unless an associated alarm, such as 1HighTraffic, is enabled.

6. In a few moments, examine the Node List. The device with the bad community string should now be in the Troublemakers property group.
7. Follow the instructions from step 1 through step 4, to return the proper value to the node's Read Community field.
8. From the Group list, select CriticalDevices.

You have just created several useful behavior models designed to detect persistent conditions or unresponsive nodes. Each of these models involved a single level of alarms.

Chapter 7, How to Use Alarm Scope in Behavior Models will explain how to create multi-alarm behavior models so that you will have an even more refined approach to monitoring your network.