6. What is
RMON (Remote MONitoring) is an SNMP-based standard that allows management of network
If you'll recall, SNMP is the standard way of remotely managing devices. In a
typical network, you have routers, hubs, switches, backup power supplies, servers, mail
gateways, and so forth. In a modern network, all these devices can be remotely managed
with a centralized console. The console sends SNMP commands to monitor their status, to
reconfigure them, and receive alerts from them.
Of course, each of these devices accepts different commands and support different
parameters that can be monitored. For a router, you might be concerned with the rate that
packets are being forwarded. For a hub, you might want to monitor for any cabling faults
on the ports. For backup power supply, you will want to monitor the voltage of the power
being supplied. The collection of monitorable/changeable parameters are stored in a
virtual database called a MIB (Management Information Base).
RMON is just another SNMP MIB. The item that this MIB manages is the traffic on the
wire. In other words, we aren't talking about managing a real thing, but a virtual device.
6.1 What does "9-group RMON" refer to?
The original RMON standard specified 9 groups or sub-MIBs. A device could claim to
support RMON if it supported only one of those groups. Many products have come out that
support only the least resource intensive RMON groups. In order to differentiate
themselves, full RMON products have taken to calling themselves "full 9-group
The 9 groups defined by the original RMON specification are:
- This contains your basic Ethernet statistics. For the most part, these statistics are
only relevant for promiscuous sniffing devices. In the old days when RMON was developed,
most Ethernet consisted of a single coax wire. This group was essentially a MIB for the
wire itself: it monitored the load on the wire (bytes/second, frames/second), health of
the wire (CRC-errors/cable-faults), and simple traffic profiling.
- The golden rule of the SNMP standard is that no MIB should contain any complexity that
could otherwise be accomplished by a management console. The idea was that an SNMP should
be a small addition to any device. This means that other SNMP MIBs do not contain
history/trending/logging mechanisms because they can take up lots of memory in order to
store all that data. Such activity can be better done by the console simply by polling the
MIB on a regular basis, then storing the results on the console. RMON broke the mold
because it was the only MIB designed for itself. In all other cases, SNMP MIBs were added
to existing equipment. In the case of RMON, equipment was built expressly to host the RMON
MIB. For this reason, RMON added resource intensive items to its MIB.
"History" group is simply the "Statistics" group, but with the ability
to keep track of the variables over time. One typical thing you might do is tell the RMON
box to copy the Statistics group every hour and store the samples away.
- These three groups are better discussed together. They all refer to the MAC addresses
seen on the wire. Every Ethernet frame starts with a destination and source MAC address
identifying to whom the frame was sent, and who sent it.
The Host group monitors the
traffic that each MAC address sends/receives on the wire (bytes sent/received, frames
sent/received). The HostTopN group serves as a sort of History mechanism to the Host MIB.
Keeping a history of all the data would take too much memory, so instead it would allow
you to do historical summaries of only the most active hosts. For example, every day you
might store only the 10 most active hosts.
The Matrix MIB keeps a table of all the source/destination pairs. You can think of this
in a number of ways. For any host, you can identify who that host is talking to. Likewise,
you can identify who is talking to that host. This MIB is extremely resource intensive.
Note that in this discussion, the word "host" means essentially "MAC
address". In a normal routed TCP/IP environment, this means that you will generally
see that everyone is talking to the router. Later versions of RMON extended the host
concept to the IP address layer; described below.
- These two groups provide the capabilities necessary to remotely sniff traffic from the
The Filter group allows you to specify filters. The most common use for this is
when you want to sniff a single host's traffic, or if you are sniffing for a certain
protocol. The Capture group is where the sniffed traffic is placed. The management console
tells the capture group to create a buffer, then turns on sniffing, then downloads the
frames to the console for decoding.
- An Alarm could be triggered according to other values in the MIB. For example, you could
tell it to alarm whenever traffic exceeded a certain threshold. Once an alarm triggered,
either a Trap could be sent to the console, or the alarm could be logged in the Event
group for later retrieval.
Alarming within RMON was extraordinarily sophisticated. For
example, you could set a Filter to scan for a certain pattern within network traffic and
trigger an Alarm.
6.2 What kinds of products support RMON?
Originally, RMON was conceived as a remote sniffer. The idea was to create a stand-alone
box (called a "probe") that you would attach to an Ethernet segment. While you
can still purchase such probes, you are more likely to experience RMON as an add-on
product to hubs, switches, and routers.
6.3 What is RMONv2?
Version 2 of RMON extended the traffic-management capabilities up the protocol stack.
For example, the Host/HostTopN/Matrix groups were extended to the OSI Network Layer (i.e.
IP) and the OSI Application Layer. This required the ability to track the Network and
Application Layer protocols as well.
6.4 What is the difference between RMON and SNMP?
This question comes up rather often. The difference should be rather obvious - RMON is
just one of the 100 standard MIBs defined by the IETF, and management consoles use SNMP to
talk to the MIB.
However, the source of this confusion is that RMON wasn't your average
MIB. It broke the mold of how people viewed SNMP. Before RMON, SNMP was designed to be a
simple/lightweight protocol. The idea was that you would add this tiny little SNMP agent
to all your networking equipment, and that this agent would have minimal impact on the
equipment. RMON introduced new ways of thinking where the agent could be much more
resource intensive. This came from the fact that RMON wasn't added to existing equipment,
but instead existing equipment was designed to run RMON.
Over time, people found many of the RMON concepts useful. They extended into later MIBs
and versions of SNMP. At the same time, people imbedded RMON into existing equipment like
hobs, switches, and routers. In fact, the original coax Ethernet that RMON was designed
for doesn't exist today; yet RMON is still a thriving/evolving standard.
6.5 Does RMON function as a remote sniffer?
In a pinch, RMON can be used to remotely sniff traffic. The problem is that it isn't
very good at it. For example, with today's sniffing products, you can easily do a packet
capture of all traffic and save it real time to gigabyte disk drives. If you try to do
that with RMON, you'll find difficulties in trying to transfer all that data back to your
management console. One way to reduce this data is to set packet capture filters. However,
filtering is extremely weak in RMON. If you want to do sniffing, don't rely upon RMON to
do it for you.
On the flip side, there is a big security concern that RMON is so
pervasive on equipment throughout the Internet that you can often find open RMON probes
that will allow remote sniffing. Again, it won't provide very good sniffing capabilities,
but it will be good enough.
6.6 What are the limitations of RMON?
First of all, RMON suffers from the basic problems of SNMP. SNMP has always been a
"checkbox" item that customers always want in their products, but which vendors
don't spend a lot of time on. Thus, basic activities work within SNMP, but it never quite
reaches the hype. Likewise, while there are a ton of products out there that support RMON,
they don't always work correctly. Indeed, since RMON is so resource intensive, you will
often find that heavy use of RMON crashes the remote device.
Second of all, RMON is
extremely resource intensive. In RMONv2, the network-layer matrix table can quickly fill
up after a few moments attached to the network.
A. More info
Here are some useful references:
- Douglas E. Comer's NETBOOK
- A good introduction to protocols, a book that is available on the web. http://www.netbook.cs.purdue.edu/index.htm
- Laura Chappell's Introduction to Network Analysis
- Mark Miller's publications
- Especially the "LAN Protocol Handbook". http://www.diginet.com/publications.html
Berkeley Packet Filter
BPF (Berkeley Packet Filter)
A generic system, originally for BSD-based UNIX, that provides
network packet capture capabilities. See also DLPI,
Data Link Provider
DLPI (Data Link Provider Interface)
A built-in subsystem within Solaris (and other System V UNIX
systems) for packet capture. See also See also BPF,
Network Interface Tap
NIT (Network Interface Tap)
The system for SunOS 4 that allows monitoring of packets on
the wire. Replaced by DLPI on Solaris/SuOS