Probes gather remote data in RMON. A probe has
the same function as a SNMP agent. A probe has RMON capabilities; an
agent does not. When working with RMON, as with SNMP, a central management console is the
point of data
collection. An RMON probe is located on each segment of the network
monitored. These probes can be dedicated hosts, resident
on a server, or included in a standard networking device such as a
router or switch. These probes gather the specified data from each
segment and relay it to the management console.
 Redundant management consoles provide a
valuable feature for the network. Redundant management consoles
provide two major benefits to network management processes. First is
the ability to have more than one network administrator in different
physical locations monitor and manage the same network; for example
one in New York and one in San Jose. Second is the all-important
concept of redundancy. Having two or more management consoles means
that if one of the consoles fails, the other console still can be used
to monitor and control the network until the first console is
repaired. 
The RMON extension to the SNMP protocol
creates new categories of data. These categories add more branches to
the MIB database. Each of the major categories will be explained in
the following list. 
1. The Ethernet Statistics Group
Contains statistics gathered for
each monitored subnetwork. These statistics include counters
(incremental that start from zero) for bytes, packets, errors, and
frame size. The other type of data reference is an index
table. The table identifies each monitored Ethernet device,
allowing counters to be kept for each individual Ethernet
device. The Ethernet Statistics Group provides a view of the
overall load and health of a subnetwork by measuring different
types of errors including CRC, collisions, over and under-sized
packets.
2. The History Control Group
Contains a data table that will
record samples of the counters in the Ethernet Statistics Group
over a specified period of time. The default time set up for
sampling is every thirty minutes (1800 seconds) and the default
table size is fifty entries giving a total of twenty-five hours
of continuous monitoring. As the history is created for the
specified counter, a new entry is created in the table at each
sample interval until the limit of fifty is reached. Then as
each new entry is created the oldest entry in the table is
deleted. These samples provide a baseline of the network and can
be used to compare against the original baseline to resolve
problems or to update the baseline as the network changes.
3. The Alarm Group
Uses user specified limits that
are called thresholds. If the data counters being monitored
cross the thresholds, a message or alarm will be sent to the
specified people. This process, known as an error trap, can
automate many functions of network monitoring. Instead
of having a person constantly and directly monitoring the network
or waiting for a user to identify a problem with the network,
the network process itself can send messages to the network
personnel because of a failure or, more importantly, an impending
failure. This is an important component of preemptive
troubleshooting.
4. The Host Group
Contains counters maintained
about each host discovered on the subnetwork segment. Some of
the counter categories maintained are Packets, Octets, Errors,
and Broadcasts. Types of counters associated with each of the
previously mentioned items could be, for example, Total packets,
Packets received, Packets sent, along with many counters
specific to the type of item.
5. The Host TOPN Group
Is used to prepare reports about
a group of hosts that top a statistical list based on a measured
parameter. The best way to describe this group is by example. A
report could be generated for the top ten hosts generating
broadcasts for a day. Another report might be generated for the most
packets transmitted during the day. This category provides an
easy way to determine who and what type of data traffic
most occupies the selected subnetwork.
6. The Matrix Group
Records the data communication
between two hosts on a subnetwork. This data is stored in the
form of a matrix (a multi-dimensional table). One of the reports
that can be generated from this category is which host utilizes a server.
Reorganizing the matrix order can create other reports. For example, one
report might show all users of a
particular server, while another report shows all the servers
used by a particular host.
7. The Filter Group
Provides a way that a management
console can instruct an RMON probe to gather selected packets
from a specific interface on a particular subnetwork. This
selection is based on the use of two filters, the DATA and the
STATUS filter. The data filter is designed to match or not match
particular data patterns allowing for the selection of that
particular data. The status filter is based on the type of
packet looked at. This means, for example, a CRC packet or a Valid
packet. These filters can be combined using logical
"and" and "or" to create very complicated
conditions. The filter group allows the network administrator to
selectively look at different types of packets to provide better
network analysis and troubleshooting.
8. The Packet Capture Group
Allows the administrator to
specify a method to use to capture packets that have been
selected by the Filter Group. By capturing specified packets the
network administrator can look at the exact detail for packets
that meet the basic filter. The packet group also specifies the
quantity of the individual packet captured and the total number
of packets captured.
9. The Event Group
Contains events generated by
other groups in the MIB database. An example could be that a
counter exceeding the threshold for that counter specified in
the Alarm Group. This action would generate an event in the
Event Group. Based upon this event an action could be generated,
such as issuing a warning message to all the people listed in
the Alarm Groups parameters or creating a logged entry in the
event table. An event is generated for all comparison operations
in the RMON MIB extensions.
10. The Token-Ring Group
Contains counters specific to
token-ring networks. While most of the counters in the RMON
extensions are not specific to any type of data-link protocol,
the Statistics and History groups are. They are particularly
attuned to the Ethernet protocol. The Token-ring Group creates
counters necessary to monitor and manage token-ring networks
using RMON.
It is important to remember that RMON
is an extension to the SNMP protocol. Specifically, this means that
while RMON enhances the operation and monitoring capabilities of SNMP,
SNMP is still required for RMON to operate on a network. As a last
point, it is important to mention that there are later revisions of
both SNMP and RMON. They are labeled as SNMPv2 and RMON2. This
curriculum does not cover all the new capabilities of these versions.
|