What is RMON?

The acronym RMON stands for Remote Network Monitoring. The RMON MIB documents are SNMP standards documents specifying information that an RMON agent can collect for eventual retrieval by RMON network management software. The probe setup and actual data collection uses SNMP. The RMON agent may be embedded in other network hardware (hub, switch, router), or it may be embedded in dedicated hardware (a probe), or it may run on host computers on network segments.

The major RMON vendors were NetMetrix, Frontier, Armon, and Axon. The latter two were purchased by 3Com and Bay Networks. Both seem to be putting the software into their switches and routers. 3Com has also announced a strategy to run the agent in software on workstations as well. I hope the network card (NIC) does most of the work!

NetMetrix is the HP software and probe line of products.

Frontier Software is partnered with Cisco, Cabletron, and Network General. Network General (“Sniffer (TM)”) recently dropped their RMON probe line, which apparently had small market share, and is now OEM-ing the Frontier hardware and software.

I expect Java and Web Browser-based development tools to be used to produce future versions of the graphical interface RMON software. Reduced time-to-market may make this fertile ground for innovation.

The Standards

The current standard, RMON version 1, is documented in RFC1757 (RFC1271 is almost identical). These documents focus on Ethernet, but RFC1513 addresses Token Ring Extensions to RMON. There is no WAN RMON. And RMON for ATM is the subject of current contention.

The RMON2 (RMON version 2) standards process is close to a final draft standard, with upcoming discussion of switch and Fast Ethernet extensions, and some minor changes. Vendors have had enough time so they should be close to RMON2 functionality.

If RMON2 really takes considerably more CPU power to gather its data, that may affect whether we’ll see it in routers and switches soon or not. Perhaps dedicated probes will be required. (Watch Bay Networks and 3Com, which made a big deal about RMON support across the product line, backpedal fast on RMON2 support? Stay tuned!)

The Nine Groups

There are nine groups of SNMP variables in RMON. All except the statistics group have control tables and data tables. The control tables control what information is collected and how often. The data tables store the collected data. Using an RMON probe involves basic SNMP setup (IP address and SNMP community string), telling it what to collect (via the control tables), then looking at the collected data (via the data tables).

The 9 RMON groups are:

  • ethernet statistics: statistics measured by the probe for each monitored Ethernet interface
  • history: periodic statistical samples from the ethernet network
  • alarm: periodic statistical samples are compared to configured thresholds, and an event is generated when a threshold is crossed (see below)
  • host: statistics for each host discovered (by means of source and destination MAC addresses)
  • hostTopN: the top N hosts, as ordered by one of their statistics
  • matrix: conversations between pairs of hosts, and statistics about those conversations (for example, traffic volume)
  • filter: packet pattern to match against traffic, either for packet capture or event generation
  • packet capture: the actual packets captured per the filter table
  • event: define events, especially what happens when an event occurs

What this boils down to is:

  • an RMON probe can collect data and periodically report it to a more central management station, which potentially reduces traffic on WAN links and polling overhead on the management station
  • it can report on what hosts are attached to the LAN, how much they talk, and to whom
  • it can “see” all LAN traffic, full LAN utilization, and not just the traffic to or through the router
  • it can filter and capture packets (so you don’t have to visit a remote LAN and attach a LAN Analyzer)
  • it can automatically collect data, compare to thresholds, and send traps to your management station — which offloads much of the work that might bog down the management station

RMON2 extends this to a higher level, so the probe can capture information at all seven layers of the OSI model. That is, not just who’s talking, but how much they’re talking, breaking it out by application. That’s the information you need for serious network design and modeling (dare I say “Netsys” in yet another article?)

The Cisco Netflow architecture / 75xx software is apparently going to indirectly support RMON2. That is, the statistics collected and SNMP-accessible Netflow tables are not RMON2, but a Frontier probe can apparently act as proxy and make this information look like RMON2 to our network management software. Perhaps this offloads some of the CPU load on the router?

Configuring RMON

All Cisco IOS images without full RMON support the alarm and event groups only. The packet capture support only captures headers, for security.

To turn on RMON on Ethernet interface zero, configure:

Promiscuous mode examines every packet on the LAN, whereas native examines only packets destined for the router (MAC address of router or broadcast/multicast).

You can also configure the packet analysis queue size from its default 64 packets:

There are currently commands to set RMON alarms and events (so you don’t have to do this from your RMON software after a router reboot). I imagine future IOS releases may extend this to allow configuration of other RMON control data as well, to allow you to permanently “manage” your edge routers by RMON.

To set up an alarm and event, I’d start with the event, then the alarm. The official syntax:

Here’s what that might look like in practice:

 

The first line specifies what event 1 is. The description is informational text, owner is who did it (who put it there). The word “log” says that when the event is generated, record it in the RMON log table. The “trap public” says to send an SNMP trap with community string “public” (per any “snmp-server host” commands you’ve configured).

The alarm line specifies what variable to watch, and where: ifOutErrors on interface 1 (a MIB-II standard ifIndex). The “30” is the seconds between checking this variable. “Delta” means to monitor the change in the variable. The rising threshold of 15 means that if the variable increases by more than 15 (over the 30 second interval), event 1 (which follows the 15) is to be generated. The falling-threshold occurs when two successive measurements of ifOutErrors return the same value (no change). Until the falling-threshold occurs the event does not occur again. No event is specified for the falling threshold. The owner is pjw.

RMON Show Commands

Basic RMON show commands:

  • show rmon
  • show rmon task

Sample output from these commands:


Interface 1 is active, and owned by config

Monitors ifEntry.1.1 which has

Received 724910886 octets, 2182270 packets,

6258 broadcast and 8912 multicast packets,

0 undersized and 0 oversized packets,

0 fragments and 9 jabbers,

5 CRC alignment errors and 36 collisions.

# of dropped packet events (due to lack of resources): 107

# of packets received of length (in octets):

64: 687369, 65-127: 608246, 128-255: 364934,

256-511: 68811, 512-1023: 153746, 1024-1518:299150


RMON task statistics:

2184829 packets input (2169425 promiscuous), 107 drops

2184697 packets processed, 26 on queue, queue utilization 64/64


There’s an amazing correspondence between the show commands and the nine RMON groups we discussed earlier: show rmon alarms, show rmon capture, show rmon event, show rmon filter, show rmon history, show rmon hosts, show rmon matrix, show rmon statistics, show rmon topn.

So you can look at any RMON tables the router has. But you currently need RMON software to easily set up the control tables in order to collect the data (except for the statistics group).

Controlling RMON

I thought it might be interesting to work with more RMON, but RMON software isn’t yet prevalent. HP OpenView for Windows doesn’t quite do it, since it doesn’t handle row creation. So I used the Carnegie-Mellon (CMU) snmptest program. Our copy has the RMON MIB loaded.

After typing $S within snmptest to get into SET mode, I entered the following. Setting hostControlStatus.1 to 2 says to create row number 1. Pressing RETURN on a blank “Variable:” prompt causes snmptest to send the SET request to the router.


Variable: rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1

Type [i|s|x|d|n|o|t|a]: i

Value: 2

Variable:

Received Get Response from 192.101.187.157

requestid 0x7FAB29A7 errstat 0x0 errindex 0x0

rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1 = createRequest (2)


It turns out that once the row is created, HP OpenView for Windows can take it from there. I stuck with CMU snmptest for consistency.

We next specify which interface is to collect data. You add additional rows for additional interfaces. At the same time, we also specify owner (a string, my initials), and set the control status to 3 (under creation), indicating to the probe that we’re fiddling with the row, using SET to stuff information into the few read-write variables.


Variable: rmon.hosts.hostControlTable.hostControlEntry.hostControlDataSource.1

Type [i|s|x|d|n|o|t|a]: o

Value: interfaces.ifTable.ifEntry.ifIndex.1

Variable:

Received Get Response from 192.101.187.157

requestid 0x7FAB29A8 errstat 0x0 errindex 0x0

rmon.hosts.hostControlTable.hostControlEntry.hostControlDataSource.1 = OID: interfaces.ifTable.ifEntry.ifIndex.1

Variable: rmon.hosts.hostControlTable.hostControlEntry.hostControlOwner.1

Type [i|s|x|d|n|o|t|a]: s

Value: pjw

Variable:

Received Get Response from 192.101.187.157

requestid 0x7FAB29A9 errstat 0x0 errindex 0x0

rmon.hosts.hostControlTable.hostControlEntry.hostControlOwner.1 = "pjw" Hex: 70 6A 77

Variable: rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1

Type [i|s|x|d|n|o|t|a]: i

Value: 3

Variable:

Received Get Response from 192.101.187.157

requestid 0x7FAB29AA errstat 0x0 errindex 0x0

rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1 = underCreation (3)


We finish by setting the control status for the row to 1 (valid). To abort instead, set status to 4 (invalid).


Variable: rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1

Type [i|s|x|d|n|o|t|a]: i

Value: 1

Variable:

Received Get Response from 192.101.187.157

requestid 0x7FAB29AB errstat 0x0 errindex 0x0

rmon.hosts.hostControlTable.hostControlEntry.hostControlStatus.1 = valid(1)

Variable:


I then used HP OpenView to look at the hosts table in tabular form. You can also use the appropriate router show command to look at the table. Note that for each MAC address it has seen, the router lists interesting statistics it has gathered. (I’ve cut down the output to fit).

A similar approach should work with the other RMON groups, if you want to experiment with them.

Of course good RMON software should make all this a lot easier. But this low-level approach also does show that the underlying mechanism isn’t all that complex.


Host Control Entry 1 is active, and owned by pjw

Monitors host ifEntry.1.1

Table size is 31, last time an entry was deleted was 00:00:00

Creation Order number is 1

Physical address is 0000.3b80.3b38

Packets: rcvd 23121, transmitted 19308

Octets: rcvd 3209797, transmitted 3568145

# of packets transmitted: broadcast 1, multicast 0

# of bad packets transmitted is 0

Creation Order number is 2

Physical address is 0800.2009.a107

Packets: rcvd 88, transmitted 101

Octets: rcvd 18419, transmitted 19548

# of packets transmitted: broadcast 0, multicast 0

# of bad packets transmitted is 0