RMON

Remote Monitoring (RMON) enhances the capabilities provided by SNMP by enabling a management station to view more information about the node and its interaction with other nodes.

Overview of RMON

Like SNMP, RMON functionality is used in conjunction with a management station, or a RMON console and the managed agent. RMON data is stored in tables on the router and is sent, when requested or when an event is triggered to send a trap, to the RMON console. It reduces network traffic by minimizing the amount of data needing to be polled in regular SNMP packets. The RMON engine on a router polls the SNMP MIB variables locally. There are two thresholds: a rising threshold and a falling threshold. When the value of the MIB variable crosses a threshold, RMON creates a log entry and sends an SNMP trap. No more events are generated for that threshold until the opposite threshold is crossed. If the variable value rises and crosses the rising threshold, an event is triggered. No more events are triggered until the value falls below the falling threshold.

Routers ordered without the RMON option have alarm and event capability. The RMON option, available only on 2500 and AS5200 series routers, adds the other groups ”statistics, history, hosts , hostTopN, matrix, filter, and capture.

Packet capture is available only on the Ethernet interfaces of 2500 series and AS5200 series routers, and only headers are captured. Packets can be captured in one of two ways:

• Natively ” Packets destined to the Ethernet interface of the router

• Promiscuously ” All packets on the Ethernet segment

The packet-capture mechanism can be very data- and processor- intensive . If enabled, the router performance and network traffic should be closely monitored .

Alarms and events, combined with existing MIB variables, enable you to define areas of proactive monitoring. You can set an alarm on any MIB object that resolves to a value of type integer, counter, gauge, or timetick.

NOTE

RFC 2819 fully defines all the groups of RMON and how they interact.

Router Configuration for RMON

The command to define an alarm table entry and the variable for which the alarm is being set is as follows :

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

The number uniquely identifies the entry in the alarm table. The variable is a MIB OID. The interval is the time between subsequent monitors of the MIB object. The delta or absolute keywords specify whether the alarm will test the change in MIB values over the specified interval or the actual MIB value. The rising-threshold value is the threshold at which an event is generated. If the sampled value is equal to or greater than this value, and the last sampled value was lower than this value, an event is generated. If an event-number is specified, this is the number of the event to trigger when the sampled value exceeds the rising threshold value. Another event is not generated until the sampled value falls below the falling-threshold value. The falling-threshold value is also a threshold at which an event is generated. If the sampled value is less than or equal to the falling-threshold value, and the previous sampled value was greater than this value, an event is generated. Another event is not generated until the sampled value rises above the rising-threshold value.

The command to add or remove an event in the RMON event table is as follows:

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

An event defined with this command is triggered when the alarm specifies an event-number and the rising or falling-threshold value is met or exceeded. A log entry or an SNMP trap (or both) may be generated when the event occurs. The snmp-server community and snmp-server host commands must be configured for the community specified in the rmon event command before an SNMP trap is sent.

Example 9-10 shows a configuration example enabling events and alarms for a high number of output errors on an interface and high CPU on the router. The MIB OID can be entered in full, such as 1.3.6.1.2.1.2.2.1.20.4, which represents the MIBII value for ifOutErrors on index 4, or 1.3.6.1.4.1.9.2.1.58.0, which represents the Cisco CPU MIB value for the 5-minute moving average of the CPU busy percentage. The router automatically converts the OID to that shown in Example 9-10.

Example 9-10 Enabling Events and Alarms for a High Number of Output Errors on an Interface and High CPU on the Router

  snmp-server community eventtrap RO   snmp-server enable traps   snmp-server host 172.16.1.2 eventtrap   snmp-server trap-source loopback 1    rmon event 1 log trap eventtrap description "High ifOutErrors"     rmon event 2 log trap eventtrap description "High 5-minute CPU" owner jsmith     rmon alarm 10 ifEntry.20.4 20 delta rising-threshold 15 1 falling-threshold 0    owner jsmith    rmon alarm 11 lsystem.58.0 20 absolute rising-threshold 50 2 falling-threshold 25    owner jsmith  

RMON event 1 logs an event with the description "High ifOutErrors" associated with owner jsmith. The event also triggers an SNMP trap for community eventtrap. The event is created when an associated alarm occurs. RMON alarm number 10 is configured for the MIB variable ifEntry.20.4, which represents output errors on interface number 4. Interface number 4 in this case is serial interface 1. The alarm monitors the MIB variable every 20 seconds. If the value between polls rises by 15 or more, the alarm is triggered, triggering event number 1. If subsequent samples of the MIB OID indicate that there have been no output errors on the interface, the alarm is reset and can be triggered again.

Event 2 logs an event described as "High 5-minute CPU". The associated alarm, alarm 11, generates an event when the value sampled with the MIB OID lsystem.58.0 (AvgBusy5) is equal to or greater than 50. When the 5-minute average CPU busy percentage falls below 25, the alarm is reset and can be triggered again.

Example 9-11 shows an SNMP trap generated by event 1.

Example 9-11 SNMP Trap Generated by Event 1 Defined in Example 9-10

 SNMP: Queuing packet to 172.16.1.2 SNMP: V1 Trap, ent rmon, addr 172.16.2.25  alarmEntry.1.10 = 10  alarmEntry.3.10 = ifEntry.20.4  alarmEntry.4.10 = 2  alarmEntry.5.10 = 20  alarmEntry.7.10 = 15 

RFC 2819 defines alarm entries.[4] Alarm entry 1 represents the alarm index. As indicated in Example 9-11, alarm index 10 generated this SNMP trap. Alarm entry 3 defines the object identifier being sampled. In this SNMP trap, the OID is ifEntry.20.4, the number of output errors on interface serial 1. Alarm entry 4 is the sample type. A value of 1 means the sample type is absolute. A value of 2 indicates that the sample type is delta. Alarm entry 5 is the alarm value during the last sampling period. Alarm entry 7 is the defined rising threshold. In the SNMP trap in Example 9-11, the alarm value of 20 exceeds the rising threshold of 15, and therefore the event occurred.

RMON alarms and events are viewed using the show rmon alarms and show rmon events commands.

Example 9-12 displays the output from these two commands.

Example 9-12 Displaying RMON Alarm and Event Tables with the show rmon alarms and show rmon events Commands

 Bowler#  show rmon event alarms  Event 1 is active, owned by jsmith  Description is High ifOutErrors  Event firing causes log and trap to community eventtrap, last fired 1d00h  Current log entries:       index       time   description  1      1d00h   High ifOutErrors   2      1d00h   High ifOutErrors  Event 2 is active, owned by jsmith  Description is High 5-minute CPU  Event firing causes log and trap to community eventtrap, last fired 1d00h  Current log entries:       index       time   description  1      1d00h   High 5-minute CPU  Alarm 10 is active, owned by jsmith  Monitors ifEntry.20.4 every 20 second(s)  Taking delta samples, last value was 20  Rising threshold is 15, assigned to event 1  Falling threshold is 0, assigned to event 0  On startup enable rising or falling alarm Alarm 11 is active, owned by jsmith  Monitors lsystem.58.0 every 20 second(s)  Taking absolute samples, last value was 60  Rising threshold is 50, assigned to event 2  Falling threshold is 25, assigned to event 0  On startup enable rising or falling alarm 

The time shown in the event and alarm table is the value of sysUpTime when the event was generated. sysUpTime is the amount of time since the router was last reset. The output in Example 9-12 shows a value of 1 day and 0 hours.