Remote Network Monitoring Management Information Base for High Capacity Networks
updated by
- rfc-4502 — Remote Network Monitoring Management Information Base Version 2
Extracted elements (22)
A MIB conforming to SMIv1 can be produced from this SMIv2 MIB by translation, but Counter64 objects cannot be translated and must be omitted. The RFC explicitly states this loss of machine-readable information does not change the semantics of the MIB.
For each high-capacity counter, the MIB provides three objects: a base Counter32 (value modulo 2^32), an overflow Counter32 (X DIV 2^32), and a combined Counter64/CounterBasedGauge64. This triple representation lets SNMPv1 managers reconstruct the 64-bit value from the two 32-bit objects while SNMPv2c/v3 managers can read the Counter64 directly.
The etherStatsHighCapacity table is explicitly noted as not appropriate for full-duplex Ethernet monitoring; for full-duplex links the mediaIndependentTable should be used instead, with utilization computed as the maximum of inbound and outbound path utilizations.
In hostTopNRateBase, if the value is less than or equal to 7, report entries are created in the legacy hostTopNTable; if the value is greater than or equal to 8 (the new HC-specific values), entries are created in the hostTopNHighCapacityTable. The rateBase field thus serves as both a sort key and a table selector.
Similarly, nlMatrixTopNControlRateBase values 1-2 direct results to the standard nlMatrixTopNTable, while values 3-4 (HighCapacity variants) direct results to nlMatrixTopNHighCapacityTable. alMatrixTopNControlRateBase uses the same pattern with values 1-4 for standard and 5-8 for high capacity.
For half-duplex links or full-duplex-capable links operating in half-duplex mode, the mediaIndependentIn* objects shall be used and the mediaIndependentOut* objects shall not increment. For full-duplex links, the mediaIndependentOut* objects shall be present and shall increment.
If a remote monitoring device implements a group, it must implement all objects in that group. For example, an agent implementing the network layer matrix group must implement both the nlMatrixSDHighCapacityTable and the nlMatrixDSHighCapacityTable.
Implementations of this MIB must also implement the system and interfaces group of MIB-II (RFC 1213 and RFC 2233). MIB-II may also mandate implementation of additional groups.
mediaIndependentDataSource and other read-create configuration objects in the mediaIndependentTable may not be modified if the associated mediaIndependentStatus object is equal to active(1). This row-creation pattern is used consistently across all configurable tables in the MIB.
captureBufferHighCapacityTable (OID { capture 3 }) adds captureBufferPacketHighCapacityTime (Integer32 0..999999, units nanoseconds) to the RMON-1 captureBuffer, providing sub-millisecond precision for inter-packet arrival time when combined with the existing captureBufferPacketTime (milliseconds) object.
etherHistoryHighCapacityTable (OID { history 6 }) augments the RMON-1 etherHistoryTable with CounterBasedGauge64 objects for per-interval packet and octet counts, indexed by etherHistoryIndex and etherHistorySampleIndex.
etherStatsHighCapacityTable (OID { statistics 7 }) augments the RMON-1 etherStatsTable with 64-bit packet and octet counters as well as per-size-bucket 64-bit counters covering 64, 65-127, 128-255, 256-511, 512-1023, and 1024-1518 octet ranges, each paired with an overflow Counter32.
hostHighCapacityTable and hostTimeHighCapacityTable (OIDs { hosts 5 } and { hosts 6 }) augment RMON-1 host tables with Counter64 InPkts, OutPkts, InOctets, OutOctets, and paired overflow Counter32 objects per host address.
hostTopNHighCapacityTable (OID { hostTopN 3 }) provides a high-capacity TopN report with hostTopNHighCapacityAddress (OCTET STRING), plus a three-part rate representation: hostTopNHighCapacityBaseRate (Gauge32, modulo 2^32), hostTopNHighCapacityOverflowRate (Gauge32, X DIV 2^32), and hostTopNHighCapacityRate (CounterBasedGauge64).
matrixSDHighCapacityTable and matrixDSHighCapacityTable (OIDs { matrix 5 } and { matrix 6 }) augment RMON-1 matrix tables with Counter64 packet and octet counters for source-to-destination and destination-to-source traffic flows, each paired with overflow Counter32s.
mediaIndependentDuplexMode (INTEGER halfduplex(1)/fullduplex(2)), mediaIndependentDuplexChanges (Counter32), and mediaIndependentDuplexLastChange (TimeStamp) track the current duplex state, number of mode transitions, and sysUpTime of the last change for each monitored interface.
mediaIndependentTable (OID { rmon 21 }) provides media-independent statistics for promiscuous monitoring of any interface type, including both half-duplex and full-duplex links, with separate In/Out counters for packets, octets, and non-unicast packets at both 32-bit and 64-bit granularity.
nlMatrixTopNHighCapacityTable (OID { nlMatrix 8 }) provides a high-capacity network-layer matrix TopN report, including source/destination addresses as length-prefixed OCTET STRINGs, bidirectional packet and octet rates (forward and reverse), each expressed as the BaseRate (mod 2^32), OverflowRate (DIV 2^32), and a CounterBasedGauge64.
protocolDistStatsHighCapacityTable (OID { protocolDist 3 }) augments the RMON-2 protocolDistStatsTable with ZeroBasedCounter64 packet and octet counts per protocol, noting that fragmented network-layer packets increment the counter once per link-layer frame.
The HC-RMON-MIB module (OID hcRMON ::= { rmonConformance 5 }) defines high-capacity extensions to RMON-MIB (RFC 2819) and RMON2-MIB (RFC 2021), adding Counter64-based objects for monitoring high-speed networks where 32-bit counters overflow too quickly.
The HC-RMON-MIB exposes detailed traffic statistics, host tables, and packet capture data. Since RMON probes operate in promiscuous mode, unauthorized SNMP read access to this MIB can reveal sensitive network topology and traffic patterns; SNMPv3 with authentication and privacy is recommended to protect access.
Network-layer addresses in nlMatrixTopNHighCapacity entries are encoded as OCTET STRINGs with a leading length octet followed by the address bytes in network byte order; for IPv4 this is a 1-byte length of 4 followed by the 4-byte IP address.