Previous section   Next section

Recipe 17.20 Using RMON to Send Traps

17.20.1 Problem

You want the router to send a trap when the CPU rises above a threshold, or when other important events occur.

17.20.2 Solution

You can configure a router to monitor its own CPU utilization and trigger an SNMP trap when the value exceeds a defined threshold with the following set of configuration commands:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#rmon event 1 log trap ORATRAP description "CPU on Router has exceeded
threshold" owner ijbrown
Router(config)#rmon event 2 log description "CPU on Router has normalized" owner
ijbrown         
Router(config)#rmon alarm 1 lsystem.57.0 60 absolute rising-threshold 70 1 falling-
threshold 40 2 owner ijbrown
Router(config)#end
Router#

The following commands will configure the router to monitor its own buffer failures and send an SNMP trap when the number of failures exceeds a threshold:

Router#configure terminal  
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#rmon event 3 log trap ORATRAP description "Excessive buffer failures 
on Router" owner  ijbrown 
Router(config)#rmon alarm 2 lsystem.46.0 300 delta rising-threshold 5 3 falling-
threshold -1 3 owner  ijbrown 
Router(config)#end 
Router#

To configure a router to monitor its own memory utilization and trigger an SNMP trap when it exceeds its threshold, use the following set of configuration commands:

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#rmon event 4 log trap ORATRAP description "Low memory condition on 
Router" owner ijbrown    
Router(config)#rmon event 5 log trap ORATRAP description "Low Memory condition 
cleared on Router" owner ijbrown
Router(config)#rmon alarm 3 lsystem.8.0 60 absolute rising-threshold 1500000 5 
falling-threshold 1000000 4 owner ijbrown
Router(config)#end
Router#

In this example, the router is configured to monitor the link utilization of a single interface and trigger an SNMP trap when that interface exceeds its threshold:

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#rmon event 6 log trap ORATRAP description "Bandwidth utilization has 
exceeded threshold on Router interface Serial 0/0" owner ijbrown
Router(config)#rmon event 7 log trap ORATRAP description "Bandwidth utilization has 
normalized on Router interface Serial 0/0" owner ijbrown
Router(config)#! Configure inbound alarm on Serial0/0 (ifNumber 3)
Router(config)#rmon alarm 4 lifEntry.6.3 300 absolute rising-threshold 1000000 6 
falling-threshold 800000 7 owner ijbrown
Router(config)#! Configure outbound alarm on Serial0/0 (ifNumber 3)
Router(config)#rmon alarm 5 lifEntry.8.3 300 absolute rising-threshold 1000000 6 
falling-threshold800000 7 owner ijbrown
Router(config)#end
Router#

To configure a router to monitor the number of interface errors on a particular interface, use the following set of commands:

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#rmon event 7 log trap ORATRAP description "ifErrors have exceeded 
threshold" owner ijbrown 
Router(config)#rmon alarm 6 ifEntry.14.3 300 delta rising-threshold 5 7 falling-
threshold  -1 7  owner ijbrown 
Router(config)#rmon alarm 7 ifEntry.20.3 300 delta rising-threshold 5 7 falling-
threshold  -1 7  owner ijbrown 
Router(config)#end 
Router#

If you choose to monitor interface-specific MIBS, such as utilization or errors, then we strongly suggest that you implement Cisco's interface persist command, which we discuss in Recipe 17.12.

17.20.3 Discussion

IOS includes some extremely helpful but seldom used remote monitoring (RMON) functionality. The main advantages to configuring the router to monitor its own performance are resource savings and flexibility.

The more conventional alternative is to have a centralized performance server that uses SNMP to periodically poll routers for health statistics. On a large network, this can consume a lot of bandwidth. However, if you move the polling functionality into the router itself, you can get the same benefits without the same bandwidth requirements.

The second major advantage of having the router monitor its own health is flexibility. You can configure each router to monitor itself using the thresholds and parameters that are most meaningful to that router. Since most performance monitoring packages on the market today limit the amount of flexibility in assigning thresholds, this built-in monitoring technique can often give more reliable results.

Of course, the biggest advantage of using RMON is that it is readily available in Cisco's IOS and requires no extra software. If your management software is capable of accepting SNMP traps, no further tools are required. For the budget-conscious administrator, RMON provides detailed performance threshold management without the added cost of performance software.

Cisco's RMON module comes standard in Cisco IOS and is included in the base IP Only feature set. The purpose of RMON is to monitor a certain MIB object on the router and notify the system administrator if the object's value leaves a defined range. It does this by polling itself internally for the values of these MIB objects. You can configure the internal polling interval.

To prevent unnecessary trouble notifications, Cisco RMON alarms use a concept of rising and falling thresholds. An RMON event fires when a value of an SNMP object exceeds the value assigned to the rising threshold. However, subsequent polls that exceed the rising threshold will not trigger an event firing until a polled value drops below the falling threshold value. This concept of rising and falling thresholds prevents the agent from flooding the server with redundant events.

Our examples show how to configure RMON to monitor CPU utilization, low memory situations, buffer failures, link utilization, and interface error counts. This is far from an exhaustive list of the RMON capabilities. Since the router's RMON capabilities rely on the polling of SNMP MIB objects, you can configure it to monitor anything that has an MIB variable. The potential number of statistics you can configure the router to watch is enormous.

The first step in configuring RMON on a router is to define the RMON event(s) that you wish to monitor. In our first RMON example, we configured the router to monitor CPU utilization. The follow two commands tell the router what to do when the CPU load rises above the threshold, and what to do when it falls back into the normal range:

Router(config)#rmon event 1 log trap ORATRAP description "CPU on Router has exceeded 
threshold" owner ijbrown
Router(config)#rmon event 2 log description "CPU on Router has normalized" owner 
ijbrown

The following IOS command defines an RMON event:

rmon event number [log] [trap community] [description string] [owner string]

This number keyword assigns a unique identification number for the RMON event. RMON event numbers range between 1 and 65,535. The optional log keyword tells the agent to create a log entry, as well as an SNMP trap, when event is triggered.

A community string accompanies the optional trap keyword. This configures the agent to send an SNMP trap when the event is fired, and assigns the SNMP community string for the trap.

You can specify an optional description for an RMON event using the description keyword. The text that follows this keyword is sent with the trap.

This owner keyword specifies the owner of an event. In our examples the owner is ijbrown. If you do not have AAA usernames configured on your router, you should use the default admin user ID.

In this example, RMON Event 1 creates a log entry and an SNMP trap when the CPU utilization on the router exceeds a certain threshold. RMON Event 2 creates a log entry, but doesn't send a trap when the CPU utilization returns to normal.

To view the configured RMON events, use the following command:

Router>show rmon events
Event 1 is active, owned by ijbrown
 Description is CPU on Router has exceeded threshold
 Event firing causes log and trap to community ORATRAP, last fired 00:00:00
Event 2 is active, owned by ijbrown
 Description is CPU on Router has normalized
 Event firing causes log, last fired 2w2d
 Current log entries:
      index       time   description
          1       2w2d   CPU on Router has normalized
Router>

To make the RMON events meaningful, you also must create a corresponding RMON alarm that defines the conditions for each of the event conditions that we just discussed:

Router(config)#rmon alarm 1 lsystem.57.0 60 absolute rising-threshold 70 1 falling-
threshold 402 ownerijbrown

The syntax of this command is as follows:

rmon alarm number variable interval {absolute | delta}
rising-threshold value [event-number]
falling-threshold value [event-number] [owner string]

The number in this command is simply a value between 1 and 65,535 that uniquely identifies this alarm.

You can specify a particular MIB object that you want the router to monitor with the variable field. In this example, we are polling the Cisco CPU utilization MIB entry, lsystem.57.0.

The next value, interval, tells the router how often you want it to poll the MIB object. The value can be between 1 and 4,294,967,295 seconds. This example tells the router to poll on a 60-second cycle. Bear in mind that polling too frequently will affect your router's CPU utilization, while polling too slowly might cause you to miss important events.

Once the data has been polled, you have the option of treating the value as an absolute or delta. In this example, we are interested in the actual value of the MIB variable, so we specified the absolute keyword. The keyword delta tells the router to take the numerical difference between the current sample and the previous one. This feature allows you to determine when a variable's rate of change is too fast or too slow.

You can set a rising threshold value using the rising-threshold keyword, which takes an argument between -2,147,483,648 and 2,147,483,647. In this example, the rising threshold is 70%, meaning that the router will trigger an event when the CPU utilization rises through 70%. When this happens, you want the router to trigger a particular event. This association with a particular event is made with the event-number argument. In this example, if the rising threshold is exceeded, RMON Event 1 will be triggered.

You configure a falling threshold similarly using the falling-threshold keyword. In this example, the falling threshold is 40%, meaning that if the CPU utilization dips below 40%, an event is triggered. As with rising thresholds, you can associate this alarm with a particular event number. In this example, the falling threshold triggers Event 2.

Finally, you can specify an owner for an alarm by using the owner keyword.

The example configures RMON Alarm 1 to poll the MIB entry for CPU utilization every minute. If the utilization exceeds 70%, the router will send a trap and create a log message. When the utilization dips back below 40%, it will create a log message.

To view the configured RMON alarms, use the following command:

Router>show rmon alarms
Alarm 1 is active, owned by ijbrown
 Monitors lsystem.57.0 every 60 second(s)
 Taking absolute samples, last value was 0
 Rising threshold is 70, assigned to event 1
 Falling threshold is 40, assigned to event 2
 On startup enable rising or falling alarm
Router>

Cisco's RMON functionality currently supports SNMP traps, but not SNMP informs.

17.20.4 See Also

Recipe 17.13


  Previous section   Next section
Top