Extensions to the generic-interface MIB
obsoleted by
- rfc-1573 — Evolution of the Interfaces Group of MIB-II
updated by
- rfc-1239 — Reassignment of experimental MIBs to standard MIBs
Extracted elements (24)
ifExtnsTestCommunity and ifExtnsTestRequestId are recorded so that, in the rare concurrent-manager scenario, the originating manager can verify that test results it reads are actually from its own request and not a superseding test invocation.
Rather than defining generic-but-reusable objects redundantly inside each interface-type-specific MIB, this document consolidates them as extensions to the generic interface group (MIB-II). This avoids duplication across media-specific MIB efforts (e.g., IEEE 802.5 Token Ring).
In the event two network managers invoke tests concurrently, the first test's results may be overwritten by the second test's results. A manager can detect this race by retrieving ifExtnsTestCommunity and ifExtnsTestRequestId simultaneously with the test results and verifying they match the original request.
Setting ifExtnsPromiscuous to true(1) is only legal on certain media types. Where legal, the change may require the interface to be reset before becoming effective, which implementations must accommodate.
A management station must not retransmit a request to invoke a test for which it receives no response; instead it must inspect the agent's MIB to determine if the invocation succeeded, retransmitting only if the invocation was unsuccessful.
Management stations must be prepared to receive tabular information corresponding to entries not currently in use (i.e., with status invalid(2)). Proper interpretation requires examining the ifExtnsRcvAddrStatus object instance.
Only one test may be in progress on each interface at any one time. If a second test is invoked while one is running, the second test must be rejected. Some agents may also reject a new test if any prior test is active on another interface.
When a test causes a reboot, the ifIndex value assigned to the interface must remain unchanged after the reboot. An agent must reject any test for which it cannot make at least the minimum result information available upon completion.
When an interface operates in promiscuous mode, the ifExtnsRcvAddrTable need only contain entries for addresses the interface would receive were it not in promiscuous mode — not every address seen on the medium.
Four Counter objects track multicast and broadcast traffic separately: ifExtnsMulticastsTransmittedOks, ifExtnsBroadcastsTransmittedOks, ifExtnsMulticastsReceivedOks, and ifExtnsBroadcastsReceivedOks. For MAC-layer protocols, multicast counts include both Group and Functional addresses.
ifExtnsChipSet (OID ifExtnsEntry.2) identifies the hardware chip set in use via an OBJECT IDENTIFIER assigned by IANA; if unknown, the value unknownChipSet { 0 0 } is returned.
ifExtnsPromiscuous (OID ifExtnsEntry.8) is an INTEGER {true(1), false(2)} indicating whether the interface accepts all frames on the medium. Setting it to true(1) may require an interface reset and is only legal on certain media types.
ifExtnsRcvAddrStatus (read-write INTEGER) controls the lifecycle of receive address entries: nonVolatile(4) persists across restarts, volatile(3) exists only until next restart, other(1) persistence is unclassified, invalid(2) marks the entry for deletion. Default value is volatile(3).
ifExtnsRcvAddrTable is mandatory for all interfaces capable of receiving frames at more than one address; it lists all unicast, multicast, and broadcast addresses the interface will accept, indexed by (ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress: PhysAddress).
ifExtnsRevWare (OID ifExtnsEntry.3) is a DisplayString (SIZE 0..255) containing the firmware version of the interface; it must contain only ASCII printable characters and is intended to be human-readable.
ifExtnsTable is the Generic Interface Extension Table, mandatory for all types of subnetwork interface, indexed by ifExtnsIfIndex and containing additional subnetwork-layer management objects. The number of entries matches ifNumber from MIB-II.
ifExtnsTestCode (read-only OBJECT IDENTIFIER) provides additional test-specific or interface-specific result information after a test. The value testCodeUnknown { 0 0 } is used when no additional code is available.
ifExtnsTestCommunity and ifExtnsTestRequestId record the SNMP authentication community name and request-id from the SNMP PDU that invoked the current or most recent test; these persist until the next test is invoked to allow managers to correlate results with requests.
ifExtnsTestTable provides objects for invoking and tracking operator-initiated interface tests. The table is optional; if implemented, all six objects (ifExtnsTestIfIndex, ifExtnsTestCommunity, ifExtnsTestRequestId, ifExtnsTestType, ifExtnsTestResult, ifExtnsTestCode) must be implemented.
ifExtnsTestType (read-write OBJECT IDENTIFIER) controls test invocation. Writing noTest { 0 0 } aborts an in-progress test; writing any other value starts the indicated test. On read, it returns the most recently written value, or noTest if never set since last initialization.
IANA manages the assignment of OBJECT IDENTIFIERs to hardware chip set types for the ifExtnsChipSet object. The reserved value unknownChipSet { 0 0 } is used when the chip set cannot be identified.
This document defines the wellKnownTests OID arc { ifExtensions 4 } and assigns testFullDuplexLoopBack { wellKnownTests 1 } as a well-known interface test identifier. Most test OIDs are defined in interface-type-specific documents.
The RFC explicitly states that security issues are not discussed in this memo. No access controls, authentication requirements, or threat model for the extended MIB objects are specified.
ifExtnsTestResult encodes test lifecycle with states: none(1) — no test yet requested, inProgress(3) — test running, success(2), failed(7), aborted(6), notSupported(4), unAbleToRun(5) — system state prevents execution. Transitions are driven by writing ifExtnsTestType.