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
Offers low-level utilization and error statistics
History group
Provides trend analysis data based on the data from the statistics group
Alarm group
Provides for the user to configure alarms
Event group
Logs and generates traps for user-defined rising thresholds, falling thresholds, and matched packets
Host group
Collects statistics based on MAC addresses
Top N Hosts group
Collects host statistics for the busiest hosts
Packet Capture group
Controls packet capture
Traffic Matrix group
Collects and returns errors and utilization data based on pairs of addresses
Filter group
Collects information based on definable filters
Token-ring group
Collects low-level token-ring statistics

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.