CS669 - HW#2
MIB Analysis Etherlike-MIB

Jan Schaumann

Introduction

This article will give an overview, a short analyzation of the Etherlike-MIB, a MIB module to describe generic objects for Ethernet-like network interfaces. As part of this analyzation, this article will explain some of the details of the Etherlike-MIB as defined in the appropriate RFC's.

Overview

As part of the Management Information Base (MIB) for use with network management protocols in the Internet Community, the Etherlike-MIB defines objects for managing Ethernet-like objects. The Internet-standard currently defines the following three values of the ifType object:

• ethernetCsmacd(6)
• iso88023Csmacd(7)
• starLan(11)

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 ifSpecific object¹.

In relation to the Interfaces MIB[5] a few things need to be pointed out, as these have intentionally been left vague:

1. The Etherlike-MIB has no sublayers and thus doe not provide for layering.
2. Ethernet-like interfaces do not support virtual circuits
3. The Etherlike-MIB provides two optional tests for the ifTestTable²
4. The Etherlike-MIB provides all IEEE 802.3 addresses for which this interface will receive or forward packets in the ifRcvAddressTable
5. The Etherlike-MIB provides the IEEE 802.3 address of any frame that originates at this interface in the ifPhysAddress Table entry
6. The Etherlike-MIB applies to all interfaces with the above mentioned ifType values

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 [7].

Use of the Etherlike-MIB

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 interest³:

Object	Brief Description
ifIndex	Each ethernet-like interface is represented by an ifEntry.
ifSpeed	The current operational speed of the interface in bits per second.
ifPhysAddress	as described above (section 2, item 5)
ifOperStatus	The operational state of the interface.
ifInOctets	The number of octets in valid MAC frames received on this interface.
ifOutOctets	The number of octets in valid MAC frames transmitted from this interface.
ifInErrors	The sum of errors for this interface related to incoming traffic
ifOutErrors	The sum of errors for this interface related to outgoing traffic
ifCounterDiscontinuityTime	The value of sysUpTime on the most recent occasion at which any one or more of this interfaces counters suffered a discontinuity.

By monitoring these values, it is possible to maintain an up-to-date status of the (ethernet-like) interfaces of the monitored host.

Usage Details

As explained above, through the use of the Ethernet-Like MIB, the network manager will be able to maintain an overview of the system status, to monitor in- and outbound traffic. By writing a simple Perl-script⁴ the network manager is able to gather all valuable information in an easy fashion. The data collected can without much effort be organized for further processing in a large variety of formats.

Frequency of Polling

When polling the snmp-agent for the ifInErrors and 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.''[5]

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.

$$1Tb/s \equiv 1024^4 \, bits/sec = 1099511627776 \, bits/sec \equiv 137438953472 \, octets/sec$$

$$64 \textrm{ bit counter } \Rightarrow 18446744078004584735 \textrm{ octets }$$

Time elapsed until counter wraps:

$$\frac{18446744078004584735}{137438953472} \approx 134217728.03125 \textrm{ seconds}$$

$$\Rightarrow \frac{134217728.03125}{(60} \approx 2236962.13385 \textrm{ minutes }$$

$$\Rightarrow \frac{2236962.13385}{60} \approx 37282.70223 \textrm { hours }$$

$$\Rightarrow \frac{37282.70223}{24} \approx 1553.44593 \textrm{ days }$$

$$\Rightarrow \frac{1553.44593}{365} \approx 4.25602 \textrm{ years }$$

Dependencies in Data Gathering

Some of the table entries in the Etherlike-MIB depend on others, or need further explanation, as they might lead to unexpected results. The following entries should be treated with care:

• the ifSpeed entry can only report speeds up to approximately 2.2Gbs - if one were to investigate an interface with a higher speed, the ifHighSpeed object should be polled. Also, the duplex mode of the interface may be determined by examining either the dot3StatsDuplexStatus object in this MIBmodule, or the ifMauType object in the 802.3 MAU MIB - this object must not indicate a doubled value!
• the ifInErrors (and 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
  etherStatsLowSpeedGroup and 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.
• the Dot3StatsEntry group: some of the entries in this group are counted twice: once in their respective entry, and one in a related entry (Example: if dot3StatsSingleCollisionFrames is incremented,
  ifOutUcastPkts might 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 ifCounterDiscontinuityTime.

Summary

As we can see, through the use of the Etherlike-MIB it is possible gain complete control over the ethernet like interfaces on the server. Since the Etherlike-MIB is an adjunct of the Interfaces-MIB, as mentioned above, the network administrator can make use of the table-entries as specified in [5], gaining more detailed information through the use of the various objects and fields as explained in great detail in [7].

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 great functionality.

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.

Bibliography

1

Frank Kastenholz, MIB MODULE EtherLike-MIB, http://www.telecomm.uh.edu/stats/rfc/EtherLike-MIB.html

2

Frank Kastenholz, Definitions of Managed Objects for the Ethernet-like Interface Types, http://www.ietf.org/rfc/rfc1623.txt

3

Frank Kastenholz, Definitions of Managed Objects for the Ethernet-like Interface Types, http://www.ietf.org/rfc/rfc1643.txt

4

Frank Kastenholz, Definitions of Managed Objects for the Ethernet-like Interface Types http://www.ietf.org/rfc/rfc1650.txt

5

McCloghrie, K., and F. Kastenholz, The Interfaces Group MIB using SMIv2, http://www.ietf.org/rfc/rfc2233.txt

6

J. Flick & J. Johnson, Definitions of Managed Objects for the Ethernet-like Interface Types, http://www.ietf.org/rfc/rfc2358.txt

7

F. Flick & J. Johnson Definitions of Managed Objects for the Ethernet-like Interface Types, http://www.ietf.org/rfc/rfc2665.txt

8

Unknown, /usr/share/snmp/mibs/EtherLike-MIB.txt

Footnotes

... object¹

RFC2358[6] and all its predecessors have been obsolete in August 1999 by RFC2665[7]

... ifTestTable²

even though this table is deprecated, these tests are expected to be compatible with future implementations

... interest³

enumerating each field and its description would certainly be out of the scope of this document; again, please refer to [7] and [8]

... Perl-script⁴

using the Net::SNMP module