rfc-2819

Remote Network Monitoring Management Information Base

S. Waldbusser
date2000-05 streamIETF areaops wgrmonmib statusINTERNET STANDARD pages98 canonicalhttps://www.rfc-editor.org/rfc/rfc2819 doi10.17487/RFC2819 errataview
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

obsoletes

also

Extracted elements (26)

design-rationale §5

History probes are encouraged to start the first sample such that a new sample begins exactly at each hour boundary. This produces more user-friendly reports and enables meaningful comparison across probes that have accurate time-of-day tracking.

snmp, measurement

design-rationale §3.1

OwnerString affords cooperative resource negotiation (identifying who owns what, enabling negotiation or reclamation) but deliberately provides no access control, because SNMP access control is articulated entirely in terms of MIB view contents and never object values.

snmp, security

design-rationale §3.2

Parameter validation should occur when each individual parameter object is set rather than only when EntryStatus is set to valid(1). This provides more specific feedback: if validation is deferred to the status transition, the management station cannot determine which of several parameters triggered a badValue error.

snmp

design-rationale §5

The alarm group uses a hysteresis mechanism: after a rising event fires, no further rising events occur until the value drops below the rising threshold and crosses the falling threshold, and vice versa. This prevents event storms from values oscillating near a threshold.

snmp, measurement

design-rationale §5

The hostTimeTable is indexed by creation order (1 to table size) rather than MAC address, enabling two optimizations: predictable indexes allow efficient PDU packing for fast bulk downloads, and new hosts are always appended at the end, allowing a management station to detect additions without re-scanning the table.

snmp

design-rationale §5

The packetMatch trap was removed in RFC 1757 because it could not be throttled, risking disruption of normal network traffic under high match rates. Management stations requiring notification should instead configure a risingAlarm on the channelMatches instance; log-based capture of packetMatch events remains supported.

snmp

interoperability-note §5

Collision counts vary by probe placement. On 10BASE-5/10BASE-2, repeater-port probes detect more collisions than station-connected probes. On 10BASE-T, placement has less impact since a station detects collisions only while transmitting; probes on stations and repeaters should report similar counts.

snmp, measurement

interoperability-note §5

RMON's jabber definition (packets >1518 octets with bad FCS) differs from IEEE 802.3 sections 8.2.1.5 and 10.3.1.4, which define jabber as any packet exceeding 20 ms duration (detection range 20–150 ms). Implementations must be aware of this definitional discrepancy.

snmp

interoperability-note §5

The etherStatsFragments counter increments for packets <64 octets with bad FCS. This is entirely normal because it counts both collision runts (normal Ethernet occurrences) and noise hits; a non-zero value does not indicate a problem.

snmp, measurement

normative-requirement §2.3 MUST

If a remote monitoring device implements a group, it MUST implement all objects in that group. All ten groups are optional. Implementations MUST also implement the system group of MIB-II and the IF-MIB.

snmp

normative-requirement §5 MUST

If at any time the variable name of an established alarmEntry is no longer available in the selected MIB view, the probe MUST change the status of that alarmEntry to invalid(4).

snmp

normative-requirement §5 MUST

Immediately after completing a createRequest operation, the agent MUST set the EntryStatus object to underCreation(3). An entry in underCreation state may exist in an incomplete or inconsistent state until the manager sets it to valid(1) or invalid(4).

snmp

normative-requirement §5 MUST

Management stations MUST be prepared to receive tabular information corresponding to entries not currently in use, since it is implementation-specific whether an agent removes invalidated entries from the table.

snmp

normative-requirement §5 MUST

The probe MUST NOT lower historyControlBucketsGranted except as a result of a modification to the associated historyControlBucketsRequested object. When BucketsGranted decreases, the oldest associated media-specific entries SHALL be deleted.

snmp

normative-requirement §5 MUST

The probe MUST only grant write access to alarmVariable in MIB views that have read access to all objects on the probe. During a set, if the variable is not available in the selected view, a badValue error MUST be returned.

snmp, security

normative-requirement §3.2 MUST

When multiple managers simultaneously attempt to create the same conceptual row, only the first succeeds; all others MUST receive an error. Row-index collision is arbitrated by the EntryStatus creation mechanism defined in RFC 1905.

snmp

protocol-element §5

OwnerString is a textual convention (OCTET STRING, SIZE 0..127) identifying the administrative owner of a resource. Agent-owned entries use strings starting with 'monitor'. It enables cooperative resource negotiation among managers but provides no enforcement against uncooperative parties.

snmp

protocol-element §5

The alarmTable provides threshold monitoring with fields for alarmInterval (seconds), alarmVariable (OID to any INTEGER-typed object), alarmSampleType (absoluteValue or deltaValue), alarmRisingThreshold, alarmFallingThreshold, alarmStartupAlarm (risingAlarm, fallingAlarm, or risingOrFallingAlarm), and event index references for notifications.

snmp, measurement

protocol-element §5

The EntryStatus textual convention defines four states for RMON conceptual rows: valid(1), createRequest(2), underCreation(3), and invalid(4). It governs the full lifecycle of control table entries and is used across all RMON functional groups.

snmp

protocol-element §5

The etherHistoryUtilization object encodes mean physical-layer utilization during a sampling interval in hundredths of a percent (Integer32, 0..10000). The recommended formula is: Utilization = [Pkts*(9.6+6.4) + Octets*0.8] / (Interval*10000).

snmp, measurement

protocol-element §5

The etherStatsTable (statistics 1) collects free-running per-interface counters including octets, total packets, broadcast/multicast packets, CRC/align errors, undersizePkts (<64 octets), oversizePkts (>1518 octets), fragments, jabbers, collisions, and seven packet-size distribution buckets (64; 65-127; 128-255; 256-511; 512-1023; 1024-1518 octets).

snmp, measurement

protocol-element §5

The historyControlTable configures periodic statistical sampling via historyControlBucketsRequested (default 50), historyControlBucketsGranted (read-only, set by agent), and historyControlInterval (1–3600 seconds, default 1800). The probe maintains a circular buffer of the granted number of sample buckets.

snmp, measurement

protocol-element §5

The RMON MIB is rooted at rmon (mib-2 16) with ten sub-trees: statistics(1), history(2), alarm(3), hosts(4), hostTopN(5), matrix(6), filter(7), capture(8), event(9), and rmonConformance(20).

snmp, registry

security-consideration §6

RMON probes collect comprehensive traffic statistics that reveal network topology, host activity, and traffic patterns for an entire segment. Access to RMON MIB objects should be controlled to prevent unauthorized network reconnaissance.

snmp, security

security-consideration §5

The alarmVariable object is a security exposure: because SNMP access control cannot restrict which OIDs may be named as alarm targets, a management station with write access to alarmVariable could potentially poll any object on the probe. Mitigation requires granting alarmVariable write access only in views with read access to all probe objects.

snmp, security

state-machine §5

EntryStatus transitions: nonExistent may only move to createRequest(2); valid and underCreation may move to valid(1), underCreation(3), or invalid(4); invalid may only remain invalid(4). createRequest is transient — the agent immediately sets it to underCreation(3) upon creation. Managers never observe createRequest state.

snmp