Definitions of Managed Objects for the Ethernet-like Interface Types
obsoletes
- rfc-2665 — Definitions of Managed Objects for the Ethernet-like Interface Types
Extracted elements (24)
dot3StatsDuplexStatus is intentionally redundant with ifMauType. Although redundant objects are generally discouraged, this object allows a management application to determine duplex status without knowing every possible ifMauType value, which was considered sufficiently valuable to justify the redundancy.
dot3StatsEtherChipSet has been deprecated because implementation feedback showed it is of limited use for debugging network problems in the field (identifies only the MAC chip, not PHY/PMD/driver), and the administrative overhead of maintaining a central chipset OID registry is not justified for an object of questionable utility.
MAC control frames (e.g., PAUSE frames) are treated as originated and consumed within the interface layer and excluded from IF-MIB ifInXcastPkts/ifOutXcastPkts counters. In many network environments MAC control frames can greatly outnumber data-carrying multicast frames, and including them would render the multicast packet counters considerably less useful.
The etherStatsBaseGroup was deprecated and split into etherStatsBaseGroup2 and etherStatsHalfDuplexGroup so that interfaces which can only operate in full-duplex mode (e.g., 10 Gb/s) are not required to implement half-duplex-only statistics such as collision counters.
IF-MIB octet counters differ from IEEE 802.3 aOctetsTransmittedOK/aOctetsReceivedOK by 18 bytes per frame (MAC header and FCS). The relationship is: ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK) and ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK).
IF-MIB packet counters (ifOutXcastPkts) count transmit requests from higher layers including failures, whereas IEEE 802.3 aFramesTransmittedOK counts only successful transmissions. Roughly: aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts + dot3OutPauseFrames - (ifOutErrors + ifOutDiscards).
ifInErrors is defined as the sum of dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsFrameTooLongs, and dot3StatsInternalMacReceiveErrors; ifOutErrors is the sum of dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, and dot3StatsCarrierSenseErrors.
64-bit HC octet counters (ifHCInOctets, ifHCOutOctets) are required for ethernet-like interfaces capable of operating at 20 Mb/s or faster, even if currently operating below that speed.
64-bit HC packet counters (ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts) are required for ethernet-like interfaces capable of operating at 640 Mb/s or faster.
All ethernet-like interfaces MUST return ethernetCsmacd(6) for ifType regardless of speed or link-layer encapsulation, and MUST NOT return fastEther(62), fastEtherFX(69), or gigabitEthernet(117).
ifSpeed and ifHighSpeed MUST NOT indicate a doubled value when operating in full-duplex mode; they MUST indicate the correct line speed regardless of the current duplex mode.
Implementation of the MAU-MIB (mauModIfCompl3 compliance statement of RFC 3636) is REQUIRED for all Ethernet-like interfaces, to allow applications to determine MAU type and control autonegotiation and duplex mode.
Management applications SHOULD be prepared to receive deprecated ifType values (fastEther(62), fastEtherFX(69), gigabitEthernet(117)) from older implementations that do not conform to the current requirement.
The IF-MIB octet counters ifInOctets, ifOutOctets, ifHCInOctets, and ifHCOutOctets MUST include all octets in valid frames including MAC header and FCS, but not the preamble, start of frame delimiter, or extension octets.
The value of ifMtu MUST reflect the actual MTU in use on the interface, whether it matches the standard 1500-octet MTU or not.
dot3CollTable is a collision histogram table indexed by ifIndex and dot3CollCount (1..16), where dot3CollFrequencies counts MAC frames that experienced exactly N collisions before transmission; does not increment in full-duplex mode.
dot3ControlTable describes the MAC Control sublayer per interface, providing dot3ControlFunctionsSupported (BITS indicating supported functions, currently only 'pause'), dot3ControlInUnknownOpcodes (Counter32), and dot3HCControlInUnknownOpcodes (Counter64 for 10 Gb/s interfaces).
dot3HCStatsTable provides 64-bit versions of high-rollover counters: dot3HCStatsAlignmentErrors, dot3HCStatsFCSErrors, dot3HCStatsInternalMacTransmitErrors, dot3HCStatsInternalMacReceiveErrors, dot3HCStatsFrameTooLongs, and dot3HCStatsSymbolErrors, intended for 10 Gb/s interfaces where 32-bit counters can roll over in under 5 minutes.
dot3PauseTable manages the MAC Control PAUSE function per interface with dot3PauseAdminMode (read-write: disabled/enabledXmit/enabledRcv/enabledXmitAndRcv), dot3PauseOperMode (read-only current state), and 32-bit/64-bit in/out PAUSE frame counters.
dot3StatsDuplexStatus reports the current MAC entity operating mode as unknown(1), halfDuplex(2), or fullDuplex(3); management control of duplex is accomplished through the MAU MIB via ifMauDefaultType or ifMauAutoNegAdvertisedBits.
dot3StatsRateControlAbility (TruthValue) and dot3StatsRateControlStatus (rateControlOff/rateControlOn/unknown) were added for management of the Rate Control function in 10 Gb/s WAN applications operating over OC-192 PHY.
dot3StatsTable provides per-interface Ethernet statistics including alignment errors, FCS errors, single/multiple collision frames, SQE test errors, deferred transmissions, late/excessive collisions, internal MAC errors, carrier sense errors, frame-too-longs, symbol errors, duplex status, and rate control ability/status.
The EtherLike-MIB module is registered under { mib-2 35 } (OID 1.3.6.1.2.1.35), with dot3 under { transmission 7 }. This document also defines compliance statements dot3Compliance2 (replacing deprecated dot3Compliance) and new object groups for 10 Gb/s support.
The only writable object in this MIB is dot3PauseAdminMode. Unauthorized write access to this object could disrupt network flow control. Implementations should use SNMPv3 with authentication and privacy to protect against unauthorized modification. Read-only objects expose interface statistics that could be sensitive in some environments.