RMON (Network Troubleshooting Tools)

8.5. RMON

As we saw in the last chapter, SNMP can be used to collect network traffic at an interface. Unfortunately, SNMP is not a very efficient mechanism in some circumstances. Frequent collection of data over an overused, low-bandwidth WAN link can create the very problems you are using SNMP to avoid. Even after you have the data, a significant amount of processing may still be needed before the data is in a useful form.

A better approach is to do some of the processing and data reduction remotely and retrieve data selectively. This is one of the ideas behind the remote monitoring (RMON) extensions to SNMP. RMON is basically a mechanism to collect and process data at the point of collection. RMON provides both continuous and offline data collection. Some implementation can even provide remote packet capture. The RMON mechanism may be implemented in software on an existing device, in dedicated hardware such as an add-on card for a device, or even as a separate device. Hardware implementations are usually called RMON probes.

Data is organized and retrieved in the same manner as SNMP data. Data organization is described in an RMON MIB, identified by OIDs, and retrieved with SNMP commands. To the users, RMON will seem to be little more than an expanded or super MIB. To implementers, there are significant differences between RMON and traditional SNMP objects, resulting from the need for continuous monitoring and remote data processing.

Originally, RMON data was organized in nine groups (RFCs 1271 and 1757) and later expanded to include a tenth group (RFC 1513) for token rings:

Statistics group

RMON implementations are often limited to a subset of these groups. This isn't unrealistic, but you should be aware of what you are getting when paying the premium prices often required for RMON support.

Provided you have the RMON MIB loaded, you can use snmptranslate to explore the structure of these groups. For example, here is the structure of the statistics group:

bsd2# snmptranslate -Tp rmon.statistics
+--statistics(1)
   |
   +--etherStatsTable(1)
      |
      +--etherStatsEntry(1)
         |
         +-- -R-- Integer   etherStatsIndex(1)
         |        Range: 1..65535
         +-- -RW- ObjID     etherStatsDataSource(2)
         +-- -R-- Counter   etherStatsDropEvents(3)
         +-- -R-- Counter   etherStatsOctets(4)
         +-- -R-- Counter   etherStatsPkts(5)
         +-- -R-- Counter   etherStatsBroadcastPkts(6)
         +-- -R-- Counter   etherStatsMulticastPkts(7)
         +-- -R-- Counter   etherStatsCRCAlignErrors(8)
         +-- -R-- Counter   etherStatsUndersizePkts(9)
         +-- -R-- Counter   etherStatsOversizePkts(10)
         +-- -R-- Counter   etherStatsFragments(11)
         +-- -R-- Counter   etherStatsJabbers(12)
         +-- -R-- Counter   etherStatsCollisions(13)
         +-- -R-- Counter   etherStatsPkts64Octets(14)
         +-- -R-- Counter   etherStatsPkts65to127Octets(15)
         +-- -R-- Counter   etherStatsPkts128to255Octets(16)
         +-- -R-- Counter   etherStatsPkts256to511Octets(17)
         +-- -R-- Counter   etherStatsPkts512to1023Octets(18)
         +-- -R-- Counter   etherStatsPkts1024to1518Octets(19)
         +-- -RW- String    etherStatsOwner(20)
         |        Textual Convention: OwnerString
         +-- -RW- EnumVal   etherStatsStatus(21)
                  Textual Convention: EntryStatus
                  Values: valid(1), createRequest(2), underCreation(3), invalid(
4)

You retrieve the number of Ethernet packets on each interface exactly as you might guess:

bsd2# snmpwalk 172.16.1.9 public rmon.1.1.1.5
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.1 = 36214
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.2 = 0
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.3 = 3994
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.4 = 242
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.5 = 284
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.6 = 292
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.7 = 314548
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.8 = 48074
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.9 = 36861
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.10 = 631831
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.11 = 104
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.12 = 457157
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.25 = 0
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.26 = 0
rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts.27 = 0

(This is data from a recently installed 12 port switch. The last three interfaces are currently unused uplink ports.)

The primary problem with RMON, as described, is that it is limited to link-level traffic. This issue is being addressed with RMON2 (RFC 2021), which adds another 10 groups. In order to collect network-level information, however, it is necessary to delve into packets. This is processing intensive, so it is unlikely that RMON2 will become common in the near future. For most purposes, the first few RMON groups should be adequate.

One final word of warning. While RMON may lessen network traffic, RMON can be CPU intensive. Make sure you aren't overloading your system when collecting RMON data. It is ironic that tools designed to analyze traffic to avoid poor performance can actually cause that performance. To make truly effective use of an RMON probe, you should consider using a commercial tool designed specifically for your equipment and goals.