Using RMON to Send Traps

Problem

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

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 (Example 1):

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 exceeded a threshold (Example 2):

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 exceeded its threshold, use the following set of configuration commands (Example 3):

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 it exceeds its threshold (Example 4):

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-threshold 800000 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 (Example 5):

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.13.

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 periodically polls routers for SNMP-based 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 statistic is flexibility. You can configure each router to monitor itself by using the thresholds and parameters that are most meaningful to that router. Because most performance monitoring packages on the market today limit the amount of flexibility in assigning thresholds, this built-in monitoring technique can 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, then no further tools are required. For the money, 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 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. Because the router's RMON capabilities rely on the polling of SNMP MIB objects, you can configure it to monitor any variable that has a 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.

The optional trap keyword is accompanied by a community string. 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. But 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 40 2 owner ijbrown

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 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.

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 is most useful for determining when a variable's rate of change is too fast or too slow.

You set a rising-threshold value by 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 percent, meaning that the router will trigger an event when the CPU utilization rises through 70 percent. 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, then RMON event 1 will be triggered.

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

And, finally, you can specify an owner for an alarm, just the same as for an event using the owner keyword.

So the example configures RMON alarm 1 to poll the MIB entry for CPU utilization, every minute. If the utilization exceeds 70 percent, the router will send a trap and create a log message. And when the utilization dips back below 40 percent, it will just create a lot 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>

Currently Cisco's RMON functionality only supports traps, and not SNMP informs.

 

See Also

Recipe 17.14