For these interfaces, the value of the
ifSpecific variable in the
MIB-II has the
OBJECT IDENTIFIER value
transmission 7. However,
this only applies to agents who implement the
In relation to the Interfaces MIB a few things need to be pointed out, as these have intentionally been left vague:
For a more detailed discussions of the relation to the Interface MIB and the specific Interface MIB Objects implemented in the Etherlike-MIB, as well as the Mapping of IEEE 802.3 Managed Objects, please refer to .
If your snmp-agent implements the Etherlike-MIB, you can gain valuable information about each of the interfaces on that host which are ethernet compatible. As an adjunct of the Interfaces MIB, the Etherlike-MIB provides all the necessary data that was intentionally left vague in the IF-MIB. When polling the snmp-agent for information regarding the ethernet compatible interfaces on that host, the following information might be of particular interest3:
||Each ethernet-like interface is represented by an ifEntry.|
||The current operational speed of the interface in bits per second.|
||as described above (section 2, item 5)|
||The operational state of the interface.|
||The number of octets in valid MAC frames received on this interface.|
||The number of octets in valid MAC frames transmitted from this interface.|
||The sum of errors for this interface related to incoming traffic|
||The sum of errors for this interface related to outgoing traffic|
||The value of
ifOutErrors(or the individual table-entries if more detailed information is desired) or for the total number of frames/packets received or transmitted, it is important to keep in mind that with other interfaces 32bit counters are commonly used to keep track of these numbers:
''As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, a 10Mbs stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, the minimum is 34 seconds.''Obviously, it is important, yet difficult to determine the proper polling interval so as not to interpret the results falsely. SNMPv2 introduced 64bit counters, which are limited to the highspeed interfaces such as Token Ring and Ethernet interfaces. Using a 64bit counter, the minimum time in which the counter will wrap is virtually unlimited: a 1-terabit/second (1,024 Gbs) link will cause a 64 bit octet counter to wrap in just under 5 years.
ifSpeedentry can only report speeds up to approximately 2.2Gbs - if one were to investigate an interface with a higher speed, the
ifHighSpeedobject should be polled. Also, the duplex mode of the interface may be determined by examining either the
dot3StatsDuplexStatusobject in this MIBmodule, or the
ifMauTypeobject in the 802.3 MAU MIB - this object must not indicate a doubled value!
ifOutErrors) entry is, as mentioned above, a sum of the various inbound- (or outbound-) traffic errors. When polling the snmp-agent for
dot3StatsSymbolErrors, for example, care must be taken not to add this number to the total numbers of errors again.
dot3Compliance: it is important to notice that this module differentiates between ''highspeed'' and ''lowspeed'' interfaces, using the
etherStatsHighSpeedGroup, respectively. These groups are mandatory for all ethernet-like network interfaces which are 10 Mb/s or slower, and which are 100 Mb/s or faster.
Dot3StatsEntrygroup: some of the entries in this group are counted twice: once in their respective entry, and one in a related entry (Example: if
ifOutUcastPktsmight be incremented as well). In addition, some of these entries are not incremented when the interface is operating in full duplex-mode. Further dependencies exist between some of this groups objects and the speed of the interface.
Furthermore it is important to know that discontinuities in the value of some
counter can occur at re-initialization of the management system, and at other
times as indicated by the value of
The simple structure of the MIB makes it easy for programmers and
system-administrators to work with this module while at the same time giving
Since it's first introduction, the Etherlike-MIB has changed, it has evolved
to fit and reflect the current status of ethernet like interfaces - future
revisions of the current implementation are foreseeable and need to be
monitored when implementing an snmp-agent using the Etherlike-MIB.