RFC 3635
Definitions of Managed Objects for the Ethernet-like Interface Types
Network Working Group J. Flick Request for Comments: 3635 Hewlett-Packard Company Obsoletes: 2665 September 2003 Category: Standards Track Definitions of Managed Objects for the Ethernet-like Interface Types Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Relation to MIB-2. . . . . . . . . . . . . . . . . . . . 4 3.2. Relation to the Interfaces MIB . . . . . . . . . . . . . 4 3.2.1. Layering Model . . . . . . . . . . . . . . . . . 4 3.2.2. Virtual Circuits . . . . . . . . . . . . . . . . 4 3.2.3. ifRcvAddressTable. . . . . . . . . . . . . . . . 5 3.2.4. ifType . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. ifXxxOctets. . . . . . . . . . . . . . . . . . . 5 3.2.6. ifXxxXcastPkts . . . . . . . . . . . . . . . . . 6 3.2.7. ifMtu. . . . . . . . . . . . . . . . . . . . . . 8 3.2.8. ifSpeed and ifHighSpeed. . . . . . . . . . . . . 8 3.2.9. ifPhysAddress. . . . . . . . . . . . . . . . . . 9 3.2.10. Specific Interface MIB Objects. . . . . . . . . 10 3.3. Relation to the 802.3 MAU MIB. . . . . . . . . . . . . . 13
3.4. dot3StatsEtherChipSet. . . . . . . . . . . . . . . . . . 13
3.5. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 14
4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Intellectual Property Statement. . . . . . . . . . . . . . . . 55
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
7. Normative References . . . . . . . . . . . . . . . . . . . . . 57
8. Informative References . . . . . . . . . . . . . . . . . . . . 58
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 59
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 60
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.1. Changes since RFC 2665 . . . . . . . . . . . . . . . . . 61
A.2. Changes between RFC 2358 and RFC 2665 . . . . . . . . . 62
A.3. Changes between RFC 1650 and RFC 2358. . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .64
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Ethernet-like
interfaces.
This memo also includes a MIB module. This MIB module updates the
list of managed objects specified in the earlier version of this MIB,
module, RFC 2665 [RFC2665].
Ethernet technology, as defined by the 802.3 Working Group of the
IEEE, continues to evolve, with scalable increases in speed, new
types of cabling and interfaces, and new features. This evolution
may require changes in the managed objects in order to reflect this
new functionality. This document, as with other documents issued by
this working group, reflects a certain stage in the evolution of
Ethernet technology. In the future, this document might be revised,
or new documents might be issued by the Ethernet Interfaces and Hub
MIB Working Group, in order to reflect the evolution of Ethernet
technology.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].3. Overview
Instances of these object types represent attributes of an interface to an ethernet-like communications medium. At present, ethernet-like media are identified by the value ethernetCsmacd(6) of the ifType object in the Interfaces MIB [RFC2863]. Some older implementations may return the values iso88023Csmacd(7) or starLan(11) for ifType for ethernet-like media. The definitions presented here are based on Section 30, "10 Mb/s, 100 Mb/s 1000 Mb/s and 10 Gb/s Management", and Annex 30A, "GDMO Specification for 802.3 managed object classes" of IEEE Std. 802.3, 2002 Edition [IEEE802.3], amended by IEEE Std. 802.3ae-2002 [IEEE802.3ae], as originally interpreted by Frank Kastenholz, then of Interlan in [KASTEN]. Implementors of these MIB objects should note that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here. To the extent that some of the attributes defined in [IEEE802.3] are represented by previously defined objects in MIB-2 [RFC1213] or in the Interfaces MIB [RFC2863], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the number of frames transmitted or received on a particular interface, the promiscuous status of an interface, the MAC address of an interface, and multicast information associated with an interface.
3.1. Relation to MIB-2
This section applies only when this MIB is used in conjunction with the "old" [RFC1213] interface group. The relationship between an ethernet-like interface and an interface in the context of MIB-2 is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. For agents which implement the (now deprecated) ifSpecific object, an instance of that object that is associated with an ethernet-like interface has the OBJECT IDENTIFIER value: dot3 OBJECT IDENTIFIER ::= { transmission 7 }3.2. Relation to the Interfaces MIB
The Interface MIB [RFC2863] requires that any MIB which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over constraining the MIB, thereby precluding management of certain media-types. Section 4 of [RFC2863] enumerates several areas which a media-specific MIB must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to [RFC2863] in order to understand the general intent of these areas.3.2.1. Layering Model
Ordinarily, there are no sublayers for an ethernet-like interface. However there may be implementation-specific requirements which require the use of sublayers. One example is the use of 802.3 link aggregation. In this case, Annex 30C of [IEEE802.3] describes the layering model and the use of the ifStackTable for representing aggregated links. Another example is the use of the 802.3 WAN Interface Sublayer. In this case, The 802.3 WIS MIB [RFC3637] describes the layering model and the use of the ifStackTable for representing the WAN sublayer.3.2.2. Virtual Circuits
This medium does not support virtual circuits and this area is not applicable to this MIB.
3.2.3. ifRcvAddressTable
This table contains all IEEE 802.3 addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for local consumption. The format of the address, contained in ifRcvAddressAddress, is the same as for ifPhysAddress. In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism.3.2.4. ifType
This MIB applies to interfaces which have the ifType value ethernetCsmacd(6). It is REQUIRED that all ethernet-like interfaces use an ifType of ethernetCsmacd(6) regardless of the speed that the interface is running or the link-layer encapsulation in use. Use of the ifType values iso88023Csmacd(7) and starLan(11) are deprecated, however some older implementations may return these values. Management applications should be prepared to receive these deprecated ifType values from older implementations. There are three other interface types defined in the IANAifType-MIB for Ethernet. They are fastEther(62), fastEtherFX(69), and gigabitEthernet(117). These interface types were registered by individual vendors, not by any IETF working group. A requirement for compliance with this document is that all ethernet-like interfaces MUST return ethernetCsmacd(6) for ifType, and MUST NOT return fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as there are fielded implementations that do return these obsolete ifType values, management applications SHOULD be prepared to receive them from older implementations. Information on the particular flavor of Ethernet that an interface is running is available from ifSpeed in the Interfaces MIB, and ifMauType in the 802.3 MAU MIB [RFC3636]. Note that implementation of the 802.3 MAU MIB [RFC3636] is REQUIRED for all ethernet-like interfaces.3.2.5. ifXxxOctets
The Interface MIB octet counters, ifInOctets, ifOutOctets, ifHCInOctets and ifHCOutOctets, MUST include all octets in valid frames sent or received on the interface, including the MAC header and FCS, but not the preamble, start of frame delimiter, or extension octets. This corresponds to the definition of frameSize/8 in section
4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than octets, and is defined as 2 x addressSize + lengthOrTypeSize + dataSize + crcSize). They do not include the number of octets in collided or failed transmit attempts, since the MAC layer driver typically does not have visibility to count these octets. They also do not include octets in received invalid frames, since this information is normally not passed to the MAC layer, and since non-promiscuous MAC implementations cannot reliably determine whether an invalid frame was actually addressed to this station. Note that these counters do include octets in valid MAC control frames sent or received on the interface, as well as octets in otherwise valid received MAC frames that are discarded by the MAC layer for some reason (insufficient buffer space, unknown protocol, etc.). Note that the octet counters in IF-MIB do not exactly match the definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK and aOctetsReceivedOK count only the octets in the clientData and Pad fields, whereas ifInOctets and ifOutOctets include the entire MAC frame, including MAC header and FCS. However, the IF-MIB counters can be derived from the IEEE 802.3 counters as follows: ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK) ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK) Another difference to keep in mind between the IF-MIB counters and IEEE 802.3 counters is that in the IEEE 802.3 document, the frame counters and octet counters are always incremented together. aOctetsTransmittedOK counts the number of octets in frames that were counted by aFramesTransmittedOK. aOctetsReceivedOK counts the number of octets in frames that were counted by aFramesReceivedOK. This is not the case with the IF-MIB counters. The IF-MIB octet counters count the number of octets sent to or received from the layer below this interface, whereas the packet counters count the number of packets sent to or received from the layer above. Therefore, received MAC Control frames, ifInDiscards, and ifInUnknownProtos are counted by ifInOctets, but not ifInXcastPkts. Transmitted MAC Control frames are counted by ifOutOctets, but not ifOutXcastPkts. ifOutDiscards and ifOutErrors are counted by ifOutXcastPkts, but not ifOutOctets.3.2.6. ifXxxXcastPkts
The packet counters in the IF-MIB do not exactly match the definition of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the number of frames successfully transmitted on the interface, whereas ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the
number of transmit requests made from a higher layer, whether or not
the transmit attempt was successful. This means that packets counted
by ifOutErrors or ifOutDiscards are also counted by ifOutXcastPkts,
but are not counted by aFramesTransmittedOK. This also means that,
since MAC Control frames are generated by a sublayer internal to the
interface layer rather than by a higher layer, they are not counted
by ifOutXcastPkts, but are counted by aFramesTransmittedOK. Roughly:
aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts +
ifOutBroadcastPkts + dot3OutPauseFrames -
(ifOutErrors + ifOutDiscards)
Similarly, aFramesReceivedOK counts the number of frames received
successfully by the interface, whether or not they are passed to a
higher layer, whereas ifInUcastPkts, ifInMulticastPkts and
ifInBroadcastPkts count only the number of packets passed to a higher
layer. This means that packets counted by ifInDiscards or
ifInUnknownProtos are also counted by aFramesReceivedOK, but are not
counted by ifInXcastPkts. This also means that, since MAC Control
frames are consumed by a sublayer internal to the interface layer and
not passed to a higher layer, they are not counted by ifInXcastPkts,
but are counted by aFramesReceivedOK. Roughly:
aFramesReceivedOK = ifInUcastPkts + ifInMulticastPkts +
ifInBroadcastPkts + dot3InPauseFrames +
ifInDiscards + ifInUnknownProtos
This specification chooses to treat MAC control frames as being
originated and consumed within the interface and not counted by the
IF-MIB packet counters. MAC control frames are normally sent as
multicast packets. In many network environments, MAC control frames
can greatly outnumber multicast frames carrying actual data. If MAC
control frames were included in the ifInMulticastPkts and
ifOutMulticastPkts, the count of data-carrying multicast packets
would tend to be drowned out by the count of MAC control frames,
rendering those counters considerably less useful.
To better understand the issues surrounding the mapping of the IF-MIB
packet and octet counters to an Ethernet interface, it is useful to
refer to a Case Diagram [CASE] for the IF-MIB counters, with
modifications to show the proper interpretation for the Ethernet
interface layer.
layer above
--------------------------------------------------------------------
ifInUcastPkts+ ^ | ifOutUcastPkts+
ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+
ifInMulticastPkts | | ifOutMulticastPkts
| |
dot3InPauseFrames <---| |<--- dot3OutPauseFrames
| |
ifInDiscards <---| |
| |
ifInUnknownProtos <---| |---> ifOutDiscards
| |
ifInOctets ----|---- ----|---- ifOutOctets
| |
ifInErrors <---| |---> ifOutErrors
| V
--------------------------------------------------------------------
layer below
3.2.7. ifMtu
The defined standard MTU for ethernet-like interfaces is 1500 octets.
However, many implementations today support larger packet sizes than
the IEEE 802.3 standard. The value of this object MUST reflect the
actual MTU in use on the interface, whether it matches the standard
MTU or not.
This value should reflect the value seen by the MAC client interface.
When a higher layer protocol, like IP, is running over Ethernet
framing, this is the MTU that will be seen by that higher layer
protocol. However, most ethernet-like interfaces today run multiple
protocols that use a mix of different framing types. For example, an
IEEE 802.2 LLC type 1 client protocol will see an MTU of 1497 octets
on an interface using the IEEE standard maximum packet size, and a
protocol running over SNAP will see an MTU of 1492 octets on an
interface using the IEEE standard maximum packet size. However,
since specification mandates using the MTU as seen at the MAC client
interface, the value of ifMtu would be reported as 1500 octets in
these cases.
3.2.8. ifSpeed and ifHighSpeed
For ethernet-like interfaces operating at 1000 Megabits per second
(Mb/s) or less, ifSpeed will represent the current operational speed
of the interface in bits per second. For current interface types,
this will be equal to 1,000,000 (1 million), 10,000,000 (10 million),
100,000,000 (100 million), or 1,000,000,000 (1 billion). ifHighSpeed
will represent the current operational speed in millions of bits per
second. For current ethernet-like interfaces, this will be equal to 1, 10, 100, or 1,000. If the interface implements auto-negotiation, auto-negotiation is enabled for this interface, and the interface has not yet negotiated to an operational speed, these objects SHOULD reflect the maximum speed supported by the interface. For ethernet-like interfaces operating at greater than 1000 Mb/s, ifHighSpeed will represent the current operational speed of the interface in millions of bits per second. Note that for WAN implementations, this will be the payload data rate over the WAN interface sublayer. For current implementations, this will be equal to 10,000 for LAN implementations of 10 Gb/s, and 9,294 for WAN implementations of the 10 Gb/s MAC over an OC-192 PHY. For these speeds, ifSpeed should report a maximum unsigned 32-bit value of 4,294,967,295 as specified in [RFC2863]. Note that these object MUST NOT indicate a doubled value when operating in full-duplex mode. It MUST indicate the correct line speed regardless of the current duplex mode. The duplex mode of the interface may be determined by examining either the dot3StatsDuplexStatus object in this MIB module, or the ifMauType object in the 802.3 MAU MIB [RFC3636].3.2.9. ifPhysAddress
This object contains the IEEE 802.3 address which is placed in the source-address field of any Ethernet, Starlan, or IEEE 802.3 frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software. In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems). If the designer truly can not chose, use of the factory-provided ROM address is suggested. If the address can not be determined, an octet string of zero length should be returned. The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set.
3.2.10. Specific Interface MIB Objects
The following table provides specific implementation guidelines for applying the interface group objects to ethernet-like media. Object Guidelines ifIndex Each ethernet-like interface is represented by an ifEntry. The dot3StatsTable in this MIB module is indexed by dot3StatsIndex. The interface identified by a particular value of dot3StatsIndex is the same interface as identified by the same value of ifIndex. ifDescr Refer to [RFC2863]. ifType Refer to section 3.2.4. ifMtu Refer to section 3.2.7. ifSpeed Refer to section 3.2.8. ifPhysAddress Refer to section 3.2.9. ifAdminStatus Write access is not required. Support for 'testing' is not required. ifOperStatus The operational state of the interface. Support for 'testing' is not required. The value 'dormant' has no meaning for an ethernet-like interface. ifLastChange Refer to [RFC2863]. ifInOctets The number of octets in valid MAC frames received on this interface, including the MAC header and FCS. This does include the number of octets in valid MAC Control frames received on this interface. See section 3.2.5. ifInUcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are consumed by the interface layer and are not passed to any higher layer protocol. See section 3.2.6.
ifInDiscards Refer to [RFC2863].
ifInErrors The sum for this interface of
dot3StatsAlignmentErrors,
dot3StatsFCSErrors,
dot3StatsFrameTooLongs,
and dot3StatsInternalMacReceiveErrors.
ifInUnknownProtos Refer to [RFC2863].
ifOutOctets The number of octets transmitted in
valid MAC frames on this interface,
including the MAC header and FCS. This
does include the number of octets in
valid MAC Control frames transmitted on
this interface. See section 3.2.5.
ifOutUcastPkts Refer to [RFC2863]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by the
interface layer, and are not passed from
any higher layer protocol. See section
3.2.6.
ifOutDiscards Refer to [RFC2863].
ifOutErrors The sum for this interface of:
dot3StatsSQETestErrors,
dot3StatsLateCollisions,
dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors and
dot3StatsCarrierSenseErrors.
ifName Locally-significant textual name for the
interface (e.g. lan0).
ifInMulticastPkts Refer to [RFC2863]. Note that this does
not include MAC Control frames, since
MAC Control frames are consumed by the
interface layer and are not passed to
any higher layer protocol. See section
3.2.6.
ifInBroadcastPkts Refer to [RFC2863]. Note that this does
not include MAC Control frames, since
MAC Control frames are consumed by the
interface layer, and are not passed to
any higher layer protocol. See section
3.2.6.
ifOutMulticastPkts Refer to [RFC2863]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by the
interface layer, and are not passed from
any higher layer protocol. See section
3.2.6.
ifOutBroadcastPkts Refer to [RFC2863]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by the
interface layer, and are not passed from
any higher layer protocol. See section
3.2.6.
ifHCInOctets 64-bit versions of counters. Required
ifHCOutOctets for ethernet-like interfaces that are
capable of operating at 20 Mb/s or
faster, even if the interface is
currently operating at less than
20 Mb/s.
ifHCInUcastPkts 64-bit versions of packet counters.
ifHCInMulticastPkts Required for ethernet-like interfaces
ifHCInBroadcastPkts that are capable of operating at
ifHCOutUcastPkts 640 Mb/s or faster, even if the
ifHCOutMulticastPkts interface is currently operating at
ifHCOutBroadcastPkts less than 640 Mb/s.
ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is
'enabled'
ifHighSpeed Refer to section 3.2.8.
ifPromiscuousMode Refer to [RFC2863].
ifConnectorPresent This will normally be 'true'. It will
be 'false' in the case where this
interface uses the WAN Interface
Sublayer. See [RFC3637] for details.
ifAlias Refer to [RFC2863].
ifCounterDiscontinuityTime Refer to [RFC2863]. Note that a
discontinuity in the Interface MIB
counters may also indicate a
discontinuity in some or all of the
counters in this MIB that are associated
with that interface.
ifStackHigherLayer Refer to section 3.2.1.
ifStackLowerLayer
ifStackStatus
ifRcvAddressAddress Refer to section 3.2.3.
ifRcvAddressStatus
ifRcvAddressType
3.3. Relation to the 802.3 MAU MIB
Support for the mauModIfCompl3 compliance statement of the MAU-MIB
[RFC3636] is REQUIRED for Ethernet-like interfaces. This MIB is
needed in order to allow applications to determine the current MAU
type in use by the interface, and to control autonegotiation and
duplex mode for the interface. Implementing this MIB module without
implementing the MAU-MIB would leave applications with no standard
way to determine the media type in use, and no standard way to
control the duplex mode of the interface.
3.4. dot3StatsEtherChipSet
This document defines an object called dot3StatsEtherChipSet, which
is used to identify the MAC hardware used to communicate on an
interface. Previous versions of this document contained a number of
OID assignments for some existing Ethernet chipsets. Maintaining
that list as part of this document has proven to be problematic, so
the OID assignments contained in previous versions of this document
have now been moved to a separate document [RFC2666].
The dot3StatsEtherChipSet object has now been deprecated.
Implementation feedback indicates that this object is much more
useful in theory than in practice. The object's utility in debugging
network problems in the field appears to be limited. In those cases
where it may be useful, it is not sufficient, since it identifies
only the MAC chip, and not the PHY, PMD, or driver. The
administrative overhead involved in maintaining a central registry of
chipset OIDs cannot be justified for an object whose usefulness is
questionable at best.
Implementations which continue to support this object for the purpose of backwards compatibility may continue to use the values defined in [RFC2666]. For chipsets not listed in [RFC2666], implementors that wish to support this object and return a valid OBJECT IDENTIFIER value may assign OBJECT IDENTIFIERS within that part of the registration tree delegated to individual enterprises.3.5. Mapping of IEEE 802.3 Managed Objects
IEEE 802.3 Managed Object Corresponding SNMP Object oMacEntity .aMACID dot3StatsIndex or IF-MIB - ifIndex .aFramesTransmittedOK IF-MIB - ifOutUCastPkts + ifOutMulticastPkts + ifOutBroadcastPkts* .aSingleCollisionFrames dot3StatsSingleCollisionFrames .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames .aFramesReceivedOK IF-MIB - ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts* .aFrameCheckSequenceErrors dot3StatsFCSErrors .aAlignmentErrors dot3StatsAlignmentErrors .aOctetsTransmittedOK IF-MIB - ifOutOctets* .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions .aLateCollisions dot3StatsLateCollisions .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors .aCarrierSenseErrors dot3StatsCarrierSenseErrors .aOctetsReceivedOK IF-MIB - ifInOctets* .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors .aPromiscuousStatus IF-MIB - ifPromiscuousMode .aReadMulticastAddressList IF-MIB - ifRcvAddressTable .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts* .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts* .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts* .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts* .aFrameTooLongErrors dot3StatsFrameTooLongs .aReadWriteMACAddress IF-MIB - ifPhysAddress .aCollisionFrames dot3CollFrequencies .aDuplexStatus dot3StatsDuplexStatus .aRateControlAbility dot3StatsRateControlAbility .aRateControlStatus dot3StatsRateControlStatus .acAddGroupAddress IF-MIB - ifRcvAddressTable .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelfTest dot3TestLoopBack
oPHYEntity
.aPHYID dot3StatsIndex or
IF-MIB - ifIndex
.aSQETestErrors dot3StatsSQETestErrors
.aSymbolErrorDuringCarrier dot3StatsSymbolErrors
oMACControlEntity
.aMACControlID dot3StatsIndex or
IF-MIB - ifIndex
.aMACControlFunctionsSupported dot3ControlFunctionsSupported and
dot3ControlFunctionsEnabled
.aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes
oPAUSEEntity
.aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames
.aPAUSEMACCtrlFramesReceived dot3InPauseFrames
* Note that the octet counters in IF-MIB do not exactly match the
definition of the octet counters in IEEE 802.3. See section 3.2.5
for details.
Also note that the packet counters in the IF-MIB do not exactly match
the definition of the frame counters in IEEE 802.3. See section
3.2.6 for details.
The following IEEE 802.3 managed objects have been removed from this
MIB module as a result of implementation feedback:
oMacEntity
.aFramesWithExcessiveDeferral
.aInRangeLengthErrors
.aOutOfRangeLengthField
.aMACEnableStatus
.aTransmitEnableStatus
.aMulticastReceiveStatus
.acInitializeMAC
Please see [RFC1369] for the detailed reasoning on why these objects
were removed.
In addition, the following IEEE 802.3 managed objects have not been
included in this MIB for the following reasons.
IEEE 802.3 Managed Object Disposition
oMACEntity
.aMACCapabilities Can be derived from
MAU-MIB - ifMauTypeListBits
.aStretchRatio Implementation constant.
oPHYEntity
.aPhyType Can be derived from
MAU-MIB - ifMauType
.aPhyTypeList Can be derived from
MAU-MIB - ifMauTypeListBits
.aMIIDetect Not considered useful.
.aPhyAdminState Can already obtain interface
state from IF-MIB - ifAdminStatus
and MAU state from MAU-MIB -
ifMauStatus. Providing an
additional state for the PHY
was not considered useful.
.acPhyAdminControl Can already control interface
state from IF-MIB - ifAdminStatus
and MAU state from MAU-MIB -
ifMauStatus. Providing separate
admin control of the PHY was not
considered useful.
oMACControlEntity
.aMACControlFramesTransmitted Can be determined by summing the
OutFrames counters for the
individual control functions
.aMACControlFramesReceived Can be determined by summing the
InFrames counters for the
individual control functions
oPAUSEEntity
.aPAUSELinkDelayAllowance Not considered useful.