RMON

icon RMON

Introduction

Last month we discussed Performance Management. In the course of that article, I briefly mentioned RMON. Covering RMON in more detail seems like a natural topic for this month.

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.

Cisco has announced full RMON support in the 25xx line of routers. Obtain a software image containing RMON support (a separate "feature"), upgrade and boot off the new image, and you can do RMON. You'll probably want IOS version 11.1(6) or 11.2 if you're going to try this out. (The usual caveats about new Cisco IOS releases apply). The other Cisco router models support two of the RMON groups. We'll talk about what this means below.

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

This is CiscoWorld magazine, so I'd better get back to routers!

As noted above, if you've got a 25xx model with enough flash and RAM (and CPU to spare), and if you've installed an IOS version supporting RMON, you can try out RMON on a Cisco router. Without RMON monitoring software, it isn't going to get you very far (but see below).

I've tried this with IOS 11.1(3) and 11.1(6) -- the latter seemed to be happier doing RMON. The documentation I've seen is 11.2, off www.cisco.com.

Full RMON is available only on Ethernet interfaces of 25xx routers. You need to configure SNMP first. Cisco warns

"RMON can be very data and processor intensive. Users should measure usage effects to ensure that router performance is not degraded and to minimize excessive management traffic overhead. Native mode is less intensive than promiscuous mode."
That's presumably why RMON is fully implemented in the 25xx series: at the edge of the network, the number of hosts and packets is small enough for the CPU load to perhaps be tolerable. If you can identify data flows at the edges, there's no need to track them inside the network, where it is more costly to do so.

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:

interface ethernet 0

rmon promiscuous

(alternative: "rmon native")

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:

rmon queuesize number

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:

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

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

Here's what that might look like in practice:

rmon event 1 log trap public description "High ifOutErrors" owner pjw

rmon alarm 5 ifOutErrors.1 30 delta rising-threshold 15 1 falling-threshold 0 owner pjw

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:

london2#show rmon stat

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


london2#show rmon task

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.


london2#show rmon hosts

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


Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This email address is being protected from spambots. You need JavaScript enabled to view it. .

10/1996
Copyright (C)  1996,  Peter J. Welcher