Definitions of Managed Objects for the Ethernet-like Interface Types
obsoleted by
- rfc-2665 — Definitions of Managed Objects for the Ethernet-like Interface Types
obsoletes
- rfc-1650 — Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2
Extracted elements (22)
ifPhysAddress stores the MAC address in 'canonical' bit order (Group Bit as low-order bit of first octet), so a multicast address has bit 0x01 set in the first byte. When multiple addresses exist, the address placed in ARP responses (for IP systems) is recommended; ROM factory address is the fallback.
Several IEEE 802.3 managed objects were deliberately removed from the MIB (including aFramesWithExcessiveDeferral, aInRangeLengthErrors, aMACEnableStatus, acInitializeMAC) based on implementation feedback documented in RFC 1369. The rationale was that these objects proved impractical or redundant in deployed implementations.
The document takes the position that 'an Ethernet is an Ethernet': all speeds (10/100 Mbit) should share ifType ethernetCsmacd(6), with speed differentiation delegated to ifSpeed/ifHighSpeed and duplex mode to ifMauType in the MAU MIB. This avoids proliferating new ifType values for each Ethernet variant.
ifInErrors for an Ethernet-like interface is defined as the sum of dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors, and dot3StatsSymbolErrors. ifOutErrors is the sum of dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, and dot3StatsCarrierSenseErrors.
The ifRcvAddressTable contains all IEEE 802.3 addresses (unicast, multicast, broadcast) for which the interface will receive and forward frames up to higher layers. For MAC bridge ports, it does not include unicast addresses accepted only for forwarding and is not intended as a bridge address filtering mechanism.
This MIB applies to ifType values ethernetCsmacd(6), iso88023Csmacd(7), and starLan(11). iso88023Csmacd(7) and starLan(11) are supported only for backwards compatibility; new implementations should use ethernetCsmacd(6).
An interface capable of operating at 100 Mbit/sec MUST implement the ether100MbsCompliance compliance statement, even if currently operating at a lower speed. Counters specific to 100 Mbit operation simply will not increment when running at lower speeds.
If auto-negotiation is enabled but an operational speed has not yet been negotiated, ifSpeed and ifHighSpeed SHOULD reflect the maximum speed supported by the interface.
ifHCInOctets and ifHCOutOctets (64-bit octet counters) are required for ethernet-like interfaces capable of operating at 20 Mbit/sec or faster, even if currently operating below that speed.
ifSpeed and ifHighSpeed MUST NOT indicate a doubled value when operating in full-duplex mode; they MUST indicate the correct line speed regardless of duplex mode. Duplex mode is indicated by ifMauType in the MAU MIB.
It is RECOMMENDED that all Ethernet-like interfaces use ifType ethernetCsmacd(6) regardless of speed or link-layer encapsulation. An Ethernet-like interface SHOULD NOT use fastEther(62) or fastEtherFX(69) ifTypes.
Support for the mauModIfCompl compliance statement of the MAU-MIB (RFC 2239) is REQUIRED for Ethernet-like interfaces, to allow applications to determine the current MAU type and duplex mode. Without it, there is no standard way to determine duplex mode.
TDR test results MUST be provided in vendor-specific MIB objects; the standard MIB does not include objects for returning TDR test results.
dot3ErrorInitError and dot3ErrorLoopbackError are OBJECT-IDENTITY values under dot3Errors, used as test result codes to indicate MAC chip initialization failure or unexpected loopback data, respectively.
dot3StatsEtherChipSet contains an OBJECT IDENTIFIER identifying the MAC chipset used by the interface. Implementors should identify the MAC chip, or if not clearly identifiable, the chip that gathers transmit/receive statistics.
dot3StatsSymbolErrors counts the number of times an invalid data symbol was detected when a valid carrier was present, incremented at most once per carrier event even if multiple symbol errors occur. This object is new in RFC 2358 (absent from RFC 1650) and is required for 100 Mbit compliance.
dot3TestTdr and dot3TestLoopBack are defined as OBJECT-IDENTITY values under dot3Tests for use with the ifTestTable. TDR is specific to 10Base5/10Base2; loopback tests memory, data paths, and MAC chip logic while the interface is offline.
The dot3CollTable provides an optional collision histogram indexed by ifIndex and dot3CollCount (1..16), where dot3CollFrequencies counts MAC frames that required exactly N collisions before transmission completed or failed.
The dot3StatsTable provides per-interface statistics for ethernet-like interfaces, indexed by dot3StatsIndex (which maps 1:1 to ifIndex). It contains 15 Counter32 objects covering alignment errors, FCS errors, collision types, carrier sense errors, frame-too-long errors, and symbol errors.
The dot3ChipSets subtree (dot3 8) registers OBJECT IDENTIFIERs for Ethernet MAC chipsets from AMD, Intel, SEEQ, National Semiconductor, Fujitsu, Digital Semiconductor, Texas Instruments, Toshiba, Lucent, Galileo, Jato, and XaQTI. For chipsets not listed, assignment is required in vendor enterprise trees; future management may be delegated to IANA.
All MIB objects are read-only (no read-write or read-create), so there is no risk of an intruder altering objects via SNMP SET. However, dot3StatsEtherChipSet may reveal vendor equipment identity; SNMPv3 with USM (RFC 2274) and VACM (RFC 2275) is recommended to control read access and optionally encrypt values in transit.
SNMPv1 is inherently insecure: even on a network secured with IPsec, there is no access control over who may GET objects in this MIB. Implementors are recommended to use SNMPv3 with the User-based Security Model and View-based Access Control Model.