RMON Statistics Collection on Cisco Catalyst Switch

Most network engineers who are familiar with RMON know to use the “alarms” and “events” to monitor things like the CPU loading hitting a certain threshold or looking for the number of incoming packets on an  interface. Cisco Catalyst switches support some RMON features that allow you to collect more information about packets that arrive on your interfaces. If you want to enable this then you have two options:

• Native Mode (Analyze packets that are destined for your interface).
• Promiscuous Mode (Analyze all packets that you encounter on the segment).

You can enable this for switchports (layer 2) or routed ports (layer 3) but it’s impossible to enable it on SVI (switch virtual interface) interfaces. Here’s an example how you can enable it on your Catalyst switch:

Switch(config)#interface fastEthernet 0/1
Switch(config-if)#rmon ?
  collection   Configure Remote Monitoring Collection on an interface
  native       Monitor the interface in native mode
  promiscuous  Monitor the interface in promiscuous mode

First you need to decide whether you want to use the native or promiscuous mode. I’ll select promiscuous:

Switch(config-if)#rmon promiscuous

Second step is to configure how often and how much statistics we want to collect:

Switch(config-if)#rmon collection history 1 ?
  buckets   Requested buckets of intervals. Default is 50 buckets
  interval  Interval to sample data for each bucket. Default is 1800 seconds
  owner     Set the owner of this RMON collection
  <cr>

The “1” is the RMON collection control index, you can pick any value you like. By default RMON will sample data each 1800 seconds..this is a little too long for my example so I’ll reduce it to 5 seconds:

Switch(config-if)#rmon collection history 1 interval 5

Now let’s see if my switch has collected anything:

Switch#show rmon statistics 
Collection 10006 on FastEthernet0/1 is active, and owned by config,
 Monitors ifIndex.10006 which has
 Received 34577 octets, 441 packets,
 39 broadcast and 395 multicast packets,
 0 undersized and 0 oversized packets,
 0 fragments and 0 jabbers,
 0 CRC alignment errors and 0 collisions.
 # of dropped packet events (due to lack of resources): 0
 # of packets received of length (in octets):
  64: 65, 65-127: 368, 128-255: 5,
  256-511: 1, 512-1023: 2, 1024-1518:0

Above you see that it has captured 441 packets and it also shows the different packet sizes. You can also take a look at the samples that RMON has taken so far:

Switch#show rmon history 
Entry 1 is active, and owned by 
 Monitors ifIndex.10001 every 5 second(s)
 Requested # of time intervals, ie buckets, is 50,
  Sample # 1 began measuring at 04:03:20
   Received 5002 octets, 58 packets,
   4 broadcast and 54 multicast packets,
   0 undersized and 0 oversized packets,
   0 fragments and 0 jabbers,
   0 CRC alignment errors and 0 collisions.
   # of dropped packet events is 0
   Network utilization is estimated at 0
  Sample # 2 began measuring at 04:03:25
   Received 4732 octets, 64 packets,
   3 broadcast and 59 multicast packets,
   0 undersized and 0 oversized packets,
   0 fragments and 0 jabbers,
   0 CRC alignment errors and 0 collisions.
   # of dropped packet events is 0
   Network utilization is estimated at 0

Above you can see the samples that are taken each 5 seconds. You can see that it’s working since sample 1 has captured 58 packets and sample 2 captured 64 packets 5 seconds later.

That’s all I wanted to show you, hopefully this tutorial has been helpful to you! If you have any questions, feel free to leave a comment.

RMON Configuration Example

In this lesson we’ll take a look at a simple RMON configuration where we want to receive a SNMP trap when we receive more than 200 unicast packets and also when we receive less than 10 unicast packets. When this occurs we will send a SNMP trap to a SNMP server. I will be using the following topology for this:

Just two routers…I will configure R1 to use RMON and we’ll use R2 to generate traffic so that we can test things.

Configuration

First i’ll configure a SNMP server that should receive the SNMP trap, there is none in this example but it doesn’t matter:

R1(config)#snmp-server host 192.168.12.254 MYTRAPS

I’ll use a community called “MYTRAPS”. We can use the “ifInUcastPkts” MIB to track the number of unicast packets but we need to check the interface number:

R1#show snmp mib ifmib ifindex
FastEthernet0/0: Ifindex = 1
Null0: Ifindex = 4
VoIP-Null0: Ifindex = 3
FastEthernet0/1: Ifindex = 2

I want to monitor the FastEthernet0/0 interface as its connected to R2. Now we can create an alarm:

R1(config)#rmon alarm 1 ifInUcastPkts.1 10 delta rising-threshold 200 1 falling-threshold 10 2

The command above requires some explanation:

• First we create an alarm called “alarm 1”.
• Secondly I’m refering to MIB object ifInUcastPkts.1 where the .1 is the FastEthernet0/0 interface.
• The “10” means that the sampling interval is 10 seconds.
• Delta means we use “delta” sampling instead of “absolute” sampling. If you don’t know the difference take a look at my delta vs absolute lesson.
• The rising-threshold is set to 200 packets and when this occurs, it will launch “event 1”.
• The falling-threshold is set to 10 packets and when this occurs, it will launch “event 2”.

With the alarm in place we can configure the events that should occur when the thresholds are met:

R1(config)#rmon event 1 trap MYTRAP description "Above 200"
R1(config)#rmon event 2 trap MYTRAP description "Below 10"

The first event will generate a SNMP trap with description “Above 200” and the second event will generate a SNMP trap that says “Below 10”.

Verification

Let’s see if our configuration is working…

R2#ping 192.168.12.1 repeat 10000 timeout 0

Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 192.168.12.1, timeout is 0 seconds:
......................................................................

I’ll send some quick pings from R2 towards R1. This is what you will see on R1:

R1#
%RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInUcastPkts.1 exceeded the rising-threshold value 200

As you can see it’s sending a trap because it’s receiving more than 200 packets. Once the pings stop and we don’t receive any more traffic you will see another message on R1:

R1#
 %RMON-5-FALLINGTRAP: Falling trap is generated because the value of ifInUcastPkts.1 has fallen below the falling-threshold value 10

Show commands

There’s also a number of show commands you can use to check your configuration:

R1#show snmp host 
Notification host: 192.168.12.254 udp-port: 162 type: trap
user: MYTRAPS security model: v1

Use show snmp host to check your SNMP configuration, this reveals the IP address, community-string and SNMP version.

R1#show rmon alarms 
Alarm 1 is active, owned by config
 Monitors ifInUcastPkts.1 every 10 second(s)
 Taking delta samples, last value was 0
 Rising threshold is 200, assigned to event 1
 Falling threshold is 10, assigned to event 2
 On startup enable rising or falling alarm

Above you can see the RMON alarm that we configured.

R1#show rmon events 
Event 1 is active, owned by config
 Description is Above 200
 Event firing causes trap to community MYTRAP,
 last event fired at  0y0w0d,00:33:40,
 Current uptime       0y0w0d,00:44:19
Event 2 is active, owned by config
 Description is Below 10
 Event firing causes trap to community MYTRAP,
 last event fired at  0y0w0d,00:33:50,
 Current uptime       0y0w0d,00:44:19

And an overview with the events that we are using. I hope this simple example helps you to understand RMON, if you have any questions feel free to ask.

RMON Absolute VS Delta

RMON can be used to monitor certain SNMP MIBs and generate an event for a certain threshold. One of the things you have to do when configuring RMON is choosing between absolute or delta sampling. In short, this is the difference between the two:

• Delta: values that always constantly increase OR constantly decrease.
• Absolute: values that can increase or decrease.

Delta should be used for values that will always increase or decrease (one of the two), for example interface counters like the number of input errors, CRC errors, output packets, interface resets etc. These are values that will always increase unless you reset the interface counters. I can’t think of any counters on a Cisco router or switch that always decrease.

Absolute should be used for values that increase or decrease over a certain amount of time, a good example is CPU usage. You probably want to receive a notification each time when your CPU load hits a certain threshold (like 85%) and receive a notification when it goes below another threshold (10% or so), this is absolute sampling.

Another example of absolute sampling could be the input or output rate of an interface as this can increase or decrease over the span of time. At one moment it might be 10.000 bits/sec, 10 minutes later it could be 5.000 bits/sec and 45 minutes later it might be 20.000 bits/sec.

I hope this helps to understand the difference between the two. If you need some more examples just leave a comment.