RMON

The Remote Network MONitoring (RMON) MIB was developed by the IETF to support monitoring and protocol analysis of LANs. The original version (sometimes referred to as RMON1) focused on OSI Layer 1 and Layer 2 information in Ethernet and Token Ring networks. It has been extended by RMON2 which adds support for Network- and Application-layer monitoring and by SMON which adds support for switched networks. It is an industry standard specification that provides much of the functionality offered by proprietary network analyzers. RMON agents are built into many high-end switches and routers.

Overview

Remote Monitoring (RMON) is a standard monitoring specification that enables various network monitors and console systems to exchange network-monitoring data. RMON provides network administrators with more freedom in selecting network-monitoring probes and consoles with features that meet their particular networking needs. An RMON implementation typically operates in a client/server model. Monitoring devices (commonly called "probes" in this context) contain RMON software agents that collect information and analyze packets. These probes act as servers and the Network Management applications that communicate with them act as clients. While both agent configuration and data collection use SNMP, RMON is designed to operate differently than other SNMP-based systems:

  • Probes have more responsibility for data collection and processing, which reduces SNMP traffic and the processing load of the clients.
  • Information is only transmitted to the management application when required, instead of continuous polling and monitoring

In short, RMON is designed for "flow-based" monitoring, while SNMP is often used for "device-based" management. RMON is similar to other flow-based monitoring technologies such as NetFlow and SFlow because the data collected deals mainly with traffic patterns rather than the status of individual devices. One disadvantage of this system is that remote devices shoulder more of the management burden, and require more resources to do so. Some devices balance this trade-off by implementing only a subset of the RMON MIB groups (see below). A minimal RMON agent implementation could support only statistics, history, alarm, and event.

The RMON1 MIB consists of ten groups:

  1. Statistics: real-time LAN statistics e.g. utilization, collisions, CRC errors
  2. History: history of selected statistics
  3. Alarm: definitions for RMON SNMP traps to be sent when statistics exceed defined thresholds
  4. Hosts: host specific LAN statistics e.g. bytes sent/received, frames sent/received
  5. Hosts top N: record of N most active connections over a given time period
  6. Matrix: the sent-received traffic matrix between systems
  7. Filter: defines packet data patterns of interest e.g. MAC address or TCP port
  8. Capture: collect and forward packets matching the Filter
  9. Event: send alerts (SNMP traps) for the Alarm group
  10. Token Ring: extensions specific to Token Ring

The RMON2 MIB adds ten more groups:

  1. Protocol Directory: list of protocols the probe can monitor
  2. Protocol Distribution: traffic statistics for each protocol
  3. Address Map: maps network-layer (IP) to MAC-layer addresses
  4. Network-Layer Host: layer 3 traffic statistics, per each host
  5. Network-Layer Matrix: layer 3 traffic statistics, per source/destination pairs of hosts
  6. Application-Layer Host: traffic statistics by application protocol, per host
  7. Application-Layer Matrix: traffic statistics by application protocol, per source/destination pairs of hosts
  8. User History: periodic samples of user-specified variables
  9. Probe Configuration: remote configure of probes
  10. RMON Conformance: requirements for RMON2 MIB conformance

Important RFCs
  • RMON1: RFC 2819 - Remote Network Monitoring Management Information Base
  • RMON2: RFC 4502 - Remote Network Monitoring Management Information Base Version 2 using SMIv2
  • HCRMON: RFC 3273 - Remote Network Monitoring Management Information Base for High Capacity Networks
  • SMON: RFC 2613 - Remote Network Monitoring MIB Extensions for Switched Networks
  • Overview: RFC 3577 - Introduction to the RMON Family of MIB Modules
gollark: We will laser-etch backup copies of important government data into picturesque parts of mountains.
gollark: To ensure our ancestors' traditions are respected, we will randomly dig them up and drag them to voting booths.
gollark: - If a foreign country's relations with our own are poor, it should be removed from all maps and not acknowledged by government policy.
gollark: - I think markets are a reasonably good resource allocation system, and to ensure liquidity would support requiring any property someone owns whatsoever to be put up for auction if someone requests it.
gollark: - I believe our country should construct its own god to reduce reliance on foreign imports, and maintain a stock of reality anchors to remove other gods if necessary.

See also
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.