Evolution of the Interfaces Group of MIB-II
obsoleted by
- rfc-2233 — The Interfaces Group MIB using SMIv2
obsoletes
- rfc-1229 — Extensions to the generic-interface MIB
Extracted elements (28)
64-bit counters were adopted instead of scaling (e.g., counting in 1024-byte blocks) because scaling causes apparent burstiness at low traffic rates and leads to incorrect performance conclusions. 64-bit counters are only required at speeds above 20 Mbps to minimize implementation burden.
Each interface sub-layer gets its own conceptual row in the ifTable rather than combining all sub-layers into one row. This avoids requiring enumerated ifType values for every sub-layer combination, supports both upward and downward multiplexing via the ifStackTable, and allows layer-specific media MIBs to apply cleanly.
ifHighSpeed reports speed in 1,000,000 bits/second units rather than as a 64-bit gauge because SNMPv2 SMI does not support 64-bit gauges, and a split high-32/low-32 approach was deemed overly complex. At 4.2 Gbps the 1 Mbps granularity yields only 0.02% error, which is acceptable.
ifSpecific was deprecated because the only unambiguous definition — pointing to the most general MIB OID for the media-specific MIB — is redundant with ifType and provides no additional information. Ambiguous prior usage (MIB OID vs. table OID vs. row OID) caused interoperability problems.
The ifTable was not split into separate tables for packet-oriented vs. other interfaces. Instead, multiple SNMPv2 compliance statements with distinct object groups (ifGeneralGroup, ifPacketGroup, ifFixedLengthGroup) allow each sub-layer type to declare applicable objects without requiring agent rewrites.
The requirement that ifIndex values be less than ifNumber was removed, allowing 'holes' in the ifTable and supporting dynamically added/removed interfaces. The original combined restriction was problematic for devices supporting dynamic SLIP/PPP configuration over character ports.
Traps are generated on transitions into/out of the down state rather than the up state because: (1) transitions to down indicate errors of management interest; (2) on-demand interfaces frequently cycle between up and dormant, which would generate excessive linkUp/linkDown pairs if the up state were instrumented.
Connection-oriented sub-layers (e.g., Frame Relay, X.25) are strongly recommended not to have a separate ifTable row per virtual circuit, to avoid proliferation of rows with redundant information. An exception is when a virtual circuit itself acts as a sub-layer (e.g., PPP over an X.25 VC).
The BER ('on the wire') encodings and OBJECT IDENTIFIER values for existing MIB-II ifTable objects are unchanged in this re-specification. Agents conforming to MIB-II and the ifExtensions MIB (RFC 1229) generally require no rewrite.
A media-specific MIB MUST completely specify the sub-layering model used, providing the assumptions, reasoning, and rationale. It MUST NOT change the semantics, DESCRIPTION, or applicability of objects where this interface MIB is explicit.
After an interface is dynamically removed, its ifIndex value MUST NOT be re-used by a different dynamically added interface until after the next re-initialization of the network management system, to prevent counter discontinuity confusion in manager stations.
By default, ifLinkUpDownTrapEnable should be enabled(1) only for interfaces that do not operate on top of any other interface (i.e., the lowest sub-layer), limiting trap generation to one per interface per linkUp/Down event.
For interfaces operating at 20,000,000 bits/second or less, 32-bit byte and packet counters MUST be used. For interfaces faster than 20 Mbps but slower than 650 Mbps, 32-bit packet counters MUST be used and 64-bit octet counters MUST be used. For interfaces at 650,000,000 bits/second or faster, both 64-bit packet counters AND 64-bit octet counters MUST be used.
LinkUp traps are generated just after ifOperStatus leaves the down state; linkDown traps are generated just before ifOperStatus enters the down state. This allows a node with a single interface to transmit the linkDown trap before the interface goes down.
The media-specific MIB designer MUST completely and unambiguously specify the layering model, whether virtual circuits are assigned entries in the ifTable, and the applicability of both ifTestTable and ifRcvAddressTable.
When 64-bit counters are in use, the corresponding 32-bit counters MUST still be available and will report the low 32-bits of the associated 64-bit count (e.g., ifInOctets reports the least significant 32 bits of ifHCInOctets).
High-capacity 64-bit counter objects (ifHCInOctets, ifHCOutOctets, ifHCInUcastPkts, ifHCOutUcastPkts, and multicast/broadcast variants) are defined in ifXTable as Counter64 and have identical semantics to their 32-bit counterparts.
ifHighSpeed (ifXEntry 15) is a Gauge32 reporting interface bandwidth in units of 1,000,000 bits/second with ±500,000 bits/second precision. It is mandatory when ifSpeed would saturate at its maximum value of 4,294,967,295 bits/second.
ifName (ifXEntry 1) is a DisplayString containing the device's local name for the interface (e.g., 'le0' or '1'). When multiple ifTable entries represent a single named interface, all share the same ifName value.
The ifRcvAddressTable defines the media-level addresses an interface will receive. It is a generic table whose applicability must be specified by each media-specific MIB designer.
The ifStackTable identifies the superior and subordinate sub-layers among ifTable entries using INTEGER pointers to ifIndex values, enabling representation of both upward and downward multiplexing (e.g., MLP over serial, PPP over X.25 VCs).
The ifTable (from MIB-II) contains one conceptual row per interface sub-layer. Each sub-layer beneath the internetwork layer is represented as a separate entry indexed by ifIndex, supporting multiple sub-layers per physical interface.
The ifTestTable provides a generic mechanism for performing tests on interfaces. Media-specific MIBs must define its applicability. It replaces the RFC 1229 test table, substituting ifTestId, ifTestStatus, and ifTestOwner for the former community/context and requestId objects.
The ifXTable augments the ifTable with new objects added during the interface evolution effort, including ifName, separate multicast/broadcast counters, 64-bit high-capacity counters, ifLinkUpDownTrapEnable, ifHighSpeed, ifPromiscuousMode, and ifConnectorPresent.
The IANAifType textual convention is defined as a separate MIB module (OID mib-2 30) managed by IANA. It defines the enumerated integer values for ifType (54 initial values, other(1) through propMultiplexor(54)) and will be periodically re-issued by IANA to add new interface type values.
The InterfaceIndex textual convention is defined (Integer32 syntax) to encapsulate all semantics of the ifIndex object, allowing other MIB modules to import consistent ifIndex semantics without duplicating the definition.
Several objects in this MIB have read-write access: ifAdminStatus controls whether an interface passes traffic, ifLinkUpDownTrapEnable controls trap generation, and ifPromiscuousMode enables promiscuous reception. Unauthorized SET operations on these objects could disrupt network operations or enable traffic interception, requiring appropriate SNMP access controls.
ifOperStatus has five states: up(1), down(2), testing(3), unknown(4), dormant(5). When ifAdminStatus transitions to up, ifOperStatus moves to up if ready, dormant if waiting for external events, or remains down on fault. The dormant state is new in this revision for on-demand interfaces.