RFC 1573
Evolution of the Interfaces Group of MIB-II
RFC 1573: Evolution of the Interfaces Group of MIB-II ✨
Network Working Group, Request for Comments 1573 🎀
Authors: K. McCloghrie (Hughes LAN Systems) and F. Kastenholz (FTP Software) 💅
Category: Standards Track, dated January 1994 🦋
Obsoletes: 1229 🫶
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. 💖
Table of Contents 🌸
1. Introduction ............................................. 2
2. The SNMPv2 Network Management Framework .................. 2
2.1 Object Definitions ...................................... 3
3 Experience with the Interfaces Group ...................... 3
3.1 Areas of Clarification/Revision ......................... 3
3.1.1 Interface Numbering ................................... 4
3.1.2 Interface Sub-Layers .................................. 4
3.1.3 Virtual Circuits ...................................... 5
3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 5
3.1.5 Counter Size .......................................... 5
3.1.6 Interface Speed ....................................... 6
3.1.7 Multicast/Broadcast Counters .......................... 6
3.1.8 Addition of New ifType values ......................... 6
3.1.9 ifSpecific ............................................ 6
3.2 Clarifications/Revisions ................................ 7
3.2.1 Interface Numbering ................................... 7
3.2.2 Interface Sub-Layers .................................. 8
3.2.3 Guidance on Defining Sub-layers ....................... 11
3.2.4 Virtual Circuits ...................................... 12
3.2.5 Bit, Character, and Fixed-Length Interfaces ........... 12
3.2.6 Counter Size .......................................... 14
3.2.7 Interface Speed ....................................... 16
3.2.8 Multicast/Broadcast Counters .......................... 16
3.2.9 Trap Enable ........................................... 17
3.2.10 Addition of New ifType values ........................ 17
3.2.11 InterfaceIndex Textual Convention .................... 17
3.2.12 IfAdminStatus and IfOperStatus ....................... 18
3.2.13 Traps ................................................ 19
3.2.14 ifSpecific ........................................... 20
3.3 Media-Specific MIB Applicability ........................ 20
4. Overview ................................................. 21
5. IANAifType Definition .................................... 22
6. Interfaces Group Definitions ............................. 24
7. Acknowledgements ......................................... 53
8. References ............................................... 53
9. Security Considerations .................................. 55
10. Authors' Addresses....................................... 551. Introduction ✨
okay so this memo is all about a chunk of the Management Information Base (MIB) that network management protocols use to look after Network Interfaces 🔥
It's specifically about the 'interfaces' group of MIB-II 💜. It shares what we learned from defining loads of media-specific MIB modules that work alongside the 'interfaces' group to manage the different sub-layers sitting below the internetwork-layer. It also proposes some clarifications to, and extensions of, the architecture behind the 'interfaces' group 🧚
The memo also includes a MIB module, and it's giving double duty 💅. It adds new MIB definitions to support those architectural extensions, and it re-specifies the 'interfaces' group of MIB-II so it's compliant with the SNMPv2 SMI while staying semantically identical to the existing SNMPv1-based definitions. Iconic compatibility energy 👑
2. The SNMPv2 Network Management Framework 🦋
The SNMPv2 Network Management Framework is made of four major components, and they are:
- RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management.
- STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols.
- RFC 1445 which defines the administrative and other architectural aspects of the framework.
- RFC 1448 which defines the protocol used for network access to managed objects.
The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Experimental vibes only 🧪
2.1. Object Definitions 🌈
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. Each object type is named by an OBJECT IDENTIFIER, which is an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Names with main character energy 💖
3. Experience with the Interfaces Group 💅
One of the strengths of internetwork-layer protocols such as IP [6] is that they're designed to run over any network interface. To make that work, IP treats every protocol it runs over as one single "network interface" layer. Other internetwork-layer protocols take the same view. 🫶
MIB-II represents this idea with the 'interfaces' group. It defines a generic set of managed objects, so any network interface can be managed in an interface-independent way through them. The 'interfaces' group also gives room for extra managed objects that are specific to a particular type of network interface (for example, a specific medium such as Ethernet). Those extras get defined as extensions to the 'interfaces' group for media-specific management. Since MIB-II was standardized, loads of media-specific MIB modules have been defined 🌸
Experience with those media-specific MIB modules has shown that the MIB-II model is too simplistic and/or static for some kinds of media-specific management. Because of this, some of those modules have assumed an evolution or loosening of the model. This memo proposes to document and standardize that evolution, and to fill in the gaps it left behind 🔥
An earlier effort to extend the interfaces group got published as RFC 1229 [7]. As part of defining the evolution of the interfaces group, this memo applies that evolution to the RFC 1229 extensions and thereby incorporates them ✨
3.1. Areas of Clarification/Revision 🎀
There are several areas where experience shows that clarifying, revising, or extending the model would help. The next sections talk about these 🧚
3.1.1. Interface Numbering 🍓
MIB-II defines an object, ifNumber, whose value represents:
"The number of network interfaces (regardless of their
current state) present on this system."Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value like this:
"Its value ranges between 1 and the value of ifNumber. The
value for each interface must remain constant at least from
one re-initialization of the entity's network management
system to the next re-initialization."This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. But more and more devices let you dynamically add and remove network interfaces. One example is being able to dynamically configure the use of SLIP/PPP over a character-oriented port. For those dynamic additions and removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic 😭
3.1.2. Interface Sub-Layers 🦋
Experience defining media-specific management information has shown the need to tell apart the multiple sub-layers beneath the internetwork-layer. There's also a need to manage these sub-layers in devices (e.g., MAC-layer bridges) that don't know which internetwork protocols, if any, run over those sub-layers. So the idea of having one conceptual row in the interfaces table (MIB-II's ifTable) represent a whole interface underneath the internetwork-layer, with a single associated media-specific MIB module (referenced via the ifType object), is too simplistic. Another problem is the ifType object, whose enumerated values cover each type of interface 💀
Take an interface with PPP running over an HDLC link that uses an RS232-like connector. Each of those sub-layers has its own media-specific MIB module. If all of that is represented by one conceptual row in the ifTable, then the specific combination needs its own enumerated ifType value, one that maps to that exact combination of media-specific MIBs. On top of that, there's still no method for describing how all the sub-layers in the MIB stack relate to each other 🫠
There's a related problem with upward and downward multiplexing of the sub-layers. An example of upward multiplexing is MLP (Multi-Link-Procedure), which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer(s) above it. An example of downward multiplexing would be several instances of PPP, each framed within a separate X.25 virtual circuit, all running over one fractional T1 channel alongside other uses of the T1 link. The current MIB structure doesn't allow these kinds of relationships to be described 🌈
3.1.3. Virtual Circuits 💜
Several of the sub-layers that have media-specific MIB modules are connection oriented (e.g., Frame Relay, X.25). Experience shows that every effort to define a MIB module for these keeps asking the same question: do we need separate conceptual rows in the ifTable for each virtual circuit? Most of these efforts, if not all of them so far, have decided that all virtual circuits reference a single conceptual row in the ifTable 🙈
3.1.4. Bit, Character, and Fixed-Length Interfaces
okay so RS-232 is a character-oriented sub-layer 🧚, and you can send IP datagrams over it (e.g., through use of PPP) 💖. A lot of the objects in the ifTable are packet-based, so experience has shown it's not appropriate to give a character-oriented sub-layer its own (whole) conceptual row in the ifTable 🙈.
Experience has also shown it's sometimes desirable to have some management info for bit-oriented interfaces. Those are similarly hard to represent with a (whole) conceptual row in the ifTable 🫶. For example, you might want to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data ✨.
Then there's one more twist 🌀. Some subnetwork technologies send data in fixed length transmission units. Cell relay, and especially Asynchronous Transfer Mode (ATM), sends data in fixed-length cells 🦋. Representing that as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit (e.g., the size of a cell) 💀.
3.1.5. Counter Size
As network media speeds go up, the minimum time in which a 32 bit counter will wrap goes down 📉. On an Ethernet, a stream of back-to-back, full-size packets will make ifInOctets wrap in just over 57 minutes ⏰. For a T3 line, the minimum wrap-time is just over 12 minutes. For FDDI, it wraps in 5.7 minutes. For a 1-gigabit medium, the counter might wrap in as little as 34 seconds 😭. Requiring that interfaces be polled frequently enough not to miss a counter wrap is going to get more and more problematic 🥲.
3.1.6. Interface Speed
Network speeds are increasing 🚀. The range of ifSpeed is limited to reporting a maximum speed of (2**31)-1 bits/second, or approximately 2.2Gbs. SONET defines an OC-48 interface, which is defined as operating at 48 times 51 Mbs, a speed in excess of 2.4gbits. So ifSpeed is going to be of diminishing utility over the next several years 💅.
3.1.7. Multicast/Broadcast Counters
The counters in the ifTable for packets addressed to a multicast or the broadcast address are combined as counters of non-unicast packets 🎀. In contrast, the ifExtensions MIB [7] defines one set of counters for multicast and a separate set for broadcast packets 🌈. With the separate counters, the original combined counters become redundant 💜.
3.1.8. Addition of New ifType values
Over time, new ifType enumerated values have been needed for new interface types 🍓. Because the syntax of ifType is defined in a MIB, this means the new MIB has to be re-issued in order to define the new values 😤. In the past, re-issuing the MIB has only happened after several years ⏳.
3.1.9. ifSpecific
The original definition of the OBJECT IDENTIFIER value of ifSpecific wasn't clear enough 🙃, so different implementors used it differently and things got confusing 😵💫. Some implementations set the value of ifSpecific to the OBJECT IDENTIFIER that defines the media-specific MIB, i.e., the "foo" of:
foo OBJECT IDENTIFIER ::= { transmission xxx }Others set it to the OBJECT IDENTIFIER of the table or entry in the appropriate media-specific MIB (e.g. fooTable or fooEntry). Still others set it to the OBJECT IDENTIFIER of the index object of the table's row, including the instance identifier (e.g., fooIfIndex.ifIndex). A definition based on the latter would not be sufficient unless it also allowed for media-specific MIBs which include several tables, where each table has its own, different, indexing 🧩.
3.2. Clarifications/Revisions
The following clarifications and/or revisions are proposed 📝.
3.2.1. Interface Numbering
One solution to the interface numbering problem would be to redefine ifNumber to be the largest value of ifIndex. But the utility of that object is questionable, and such a re-definition would require ifNumber to be deprecated 🤔. So an improvement would be to deprecate ifNumber and not replace it. However, deprecating ifNumber would require a change to the part of ifIndex's definition that refers to ifNumber. Since the definition of ifIndex has to change anyway to solve the problem, changes to ifNumber don't actually help the solution 🙅♀️.
The solution adopted in this memo is to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to keep ifNumber with its current definition ✨. You could argue this is a change in the semantics of ifIndex. However, all existing implementations already conform to this new definition, and to avoid forcing changes on existing implementations and the many existing media-specific MIBs, it's proposed that this change does not require ifIndex to be deprecated 💖.
This solution also makes "holes" in the ifTable possible (i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous). But SNMP's GetNext (and SNMPv2's GetBulk) operation easily deals with holes 🕳️. The value of ifNumber still represents the number of conceptual rows, which goes up and down as new interfaces are dynamically added and removed 📈📉. The vital constancy requirement is met by requiring that, after an interface is dynamically removed, its ifIndex value is not re-used (by a different dynamically added interface) until after the following re-initialization of the network management system 🔒. This avoids the need to assign ifIndex values in advance for every possible interface that might be added dynamically 🙌.
The exact meaning of a "different" interface is hard to define, and there will be gray areas 🌫️. One important criterion is that a management station, which hasn't noticed that an interface has gone away and another has come into existence, should not get confused when it calculates the difference between the counter values retrieved on successive polls for a particular ifIndex value 🧐. However, any firm definition in this document would likely turn out to be inadequate. So instead, the following guidelines are offered to let implementors choose what "different" means in their particular situation 🎀.
A previously-unused value of ifIndex should be assigned to a dynamically added interface if:
- the assignment of a previously-used ifIndex value to the interface could result in a discontinuity in the values of ifTable counters for that value of ifIndex; or,
- an agent has no knowledge of whether the interface is the "same" or "different" from a previous interface incarnation.
Because the value of ifIndex was restricted to be less than ifNumber, interfaces got numbered with small integer values 🔢. That made it possible for humans to use the ifIndex values as (somewhat) user-friendly names for network interfaces (e.g., "interface number 3") 🥰. With that restriction relaxed, ifIndex values could now be assigned as very large numbers (e.g., memory addresses). Such numbers would be much less user-friendly 😬.
Therefore, this memo recommends that ifIndex values still be assigned as (relatively) small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous 🌱. (Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces 🧠.)
This proposed change brings a new problem of its own 😱. Previously, there usually was a simple, direct mapping of interfaces to the physical ports on systems, based on the ifIndex value. But by removing the previous restrictions on the values allowed for ifIndex, along with the interface sub-layer concept (see the following section), mapping interfaces to physical ports becomes increasingly problematic 🥺.
To address this, a new object, ifName, is added to the MIB 🎉. This object contains the device's name for the interface that the relevant entry in the ifTable is a component of. For example, if a router has an interface named wan1, which is made up of PPP running over an RS-232 port, the ifName objects for the corresponding PPP and RS-232 entries in the ifTable will both contain the string "wan1" 🦋.
3.2.2. Interface Sub-Layers ✨
okay so there's one option that's possible but not recommended 🙈 for representing multiple sub-layers. You keep ONE conceptual row for all the sub-layers of an interface, and each media-specific MIB module names its "superior" and "subordinate" sub-layers using OBJECT IDENTIFIER "pointers". The problems with this are:
- (1) the superior/subordinate pointers live inside the media-specific MIB modules, so a manager couldn't learn an interface's structure without inspecting multiple pointers across different MIB modules. That's overly complex, and it only works if the manager knows about all the relevant media-specific MIB modules 💀
- (2) every current MIB module would need to be retrofitted with these new "pointers" 😭
- (3) this scheme doesn't really handle upward and downward multiplexing 🌀
- (4) you'd need enumerated values of ifType for each combination of sub-layers 📚
Another option is also possible but not recommended 🫶. You keep one conceptual row for all the sub-layers of an interface, and you add a brand new separate MIB table that names the "superior" and "subordinate" sub-layers. That table has OBJECT IDENTIFIER "pointers" to the media-specific MIB module(s) for each sub-layer. So basically one conceptual row in the ifTable would stand for every combination of sub-layers between the internetwork-layer and the wire. This one has fewer drawbacks, BUT it doesn't support downward multiplexing, like PPP over MLP 🥺 MLP makes two (or more) serial lines look like a single physical interface to the layers above, so PPP over MLP should look like a single interface to the internetwork-layer. With this scheme, though, you'd end up with two (or more) conceptual rows in the ifTable, and the internetwork-layer would run over both of them. This scheme also needs enumerated values of ifType for each combination of sub-layers.
Now for the solution this memo actually adopts 👑 Each sub-layer gets its own individual conceptual row in the ifTable, and there's a new separate MIB table (the ifStackTable, see section 5 of this memo) that identifies the "superior" and "subordinate" sub-layers using INTEGER "pointers" to the right conceptual rows in the ifTable. This solution supports BOTH upward and downward multiplexing ✨ It also lets the IANAIfType to Media-Specific MIB mapping figure out which media-specific MIB module goes with each sub-layer. The new table (ifStackTable) only needs to be looked at when you want information about layering 🧚 And enumerated values for ifType are needed for each sub-layer only, NOT for combinations of them.
Of course there's a catch 🌸 Some objects in the ifTable (specifically ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts) need their descriptions generalized so they apply to ANY sub-layer, not just the one sitting directly beneath the network layer like they do today. Some objects (specifically ifSpeed) also need appropriate values identified for when a generalized definition doesn't fit a particular sub-layer.
Also, this adopted solution doesn't require a device to know whether an internetwork protocol runs on top of a sub-layer that's instrumented by a conceptual row of the ifTable 🦋 In fact, the counters of packets received on an interface count the number "delivered to a higher-layer protocol". The meaning of "higher-layer" here includes:
- (1) Delivery to a forwarding module that accepts packets/frames/octets and forwards them on at the same protocol layer. For example, for this definition, the forwarding module of a MAC-layer bridge counts as a "higher-layer" to the MAC-layer of each port on the bridge.
- (2) Delivery to a higher sub-layer within an interface stack. For example, for this definition, if a PPP module operated directly over a serial interface, the PPP module would count as the higher sub-layer to the serial interface.
- (3) Delivery to a higher protocol layer that does not do packet forwarding, for sub-layers that are "at the top of" the interface stack. For example, for this definition, the local IP module would count as the higher layer to a SLIP serial interface.
On the output side, the counters of packets transmitted out an interface count the number "that higher-level protocols requested to be transmitted". The meaning of "higher-layer" here includes:
- (1) A forwarding module, at the same protocol layer, that transmits packets/frames/octets which were received on a different interface. For example, for this definition, the forwarding module of a MAC-layer bridge counts as a "higher-layer" to the MAC-layer of each port on the bridge.
- (2) The next higher sub-layer within an interface stack. For example, for this definition, if a PPP module operated directly over a serial interface, the PPP module would be a "higher layer" to the serial interface.
- (3) For sub-layers that are "at the top of" the interface stack, a higher element in the network protocol stack. For example, for this definition, the local IP module would count as the higher layer to an Ethernet interface.
3.2.3. Guidance on Defining Sub-layers 🎀
okay so the designer of a media-specific MIB has to decide whether to split the interface into sub-layers, and if so, how to draw the lines 📐 The guidance below is here to help with those decisions.
In general, the number of entries in the ifTable should be kept to the minimum that network management needs 💅 Specifically, a group of related interfaces can be treated as a single interface with one entry in the ifTable, as long as:
- (1) none of the interfaces in the group does multiplexing for any other interface in the agent, AND
- (2) there's a meaningful and useful way for ALL of the ifTable's information (like the counters and the status variables) and ALL of its capabilities (like write access to ifAdminStatus) to apply to the group as a whole 🔥
When that's the case, there should be one entry in the ifTable for the group, and any internal structure that network management needs to see should be captured in a MIB module specific to that type of interface 🌈
Quick note: applying item (2) to the ifTable's ifType object means there has to be a meaningful media-specific MIB AND a meaningful ifType value that apply to the group as a whole 🧠 For example, it's NOT appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as a single ifTable entry when the media-specific MIBs and the ifType values for HDLC and RS-232 are separate (rather than combined).
Also, the sub-layers of an interface on one device will sometimes be different from the sub-layers of the interconnected interface on another device 🤝 A simple example is a frame-relay DTE interface connecting to a frameRelayService interface, where the DTE interface has a different ifType value and media-specific MIB than the DCE interface.
⚠️ A media-specific MIB may say that a particular ifTable counter doesn't apply and that its value must always be 0. That signals the event can't happen and doesn't happen for that interface type. For example, ifInMulticastPkts and ifOutMulticastPkts on an interface type with no multicast capability.
In other circumstances, an agent must NOT always return 0 for a counter just because its implementation can't detect occurrences of that event 😬 Instead, it must return a noSuchName/noSuchObject error/exception when queried for that counter, even if this means the implementation can't comply with the relevant MODULE-COMPLIANCE macro.
These guidelines are just that: guidelines 💖 The designer of a media-specific MIB is free to lay out the MIB in whatever SMI conformant manner they like. HOWEVER, the media-specific MIB MUST completely specify the sub-layering model it uses, and it must provide the assumptions, reasoning, and rationale used to develop that model 📜
3.2.4. Virtual Circuits 🦋
This memo strongly recommends that connection-oriented sub-layers do NOT get a conceptual row in the ifTable for each virtual circuit 🙅♀️ This stops the ifTable from exploding with rows, especially ones with a ton of redundant info. (Fun comparison: connection-less sub-layers don't get conceptual rows for each remote address either ✨) That said, there may be situations where it makes sense for a virtual circuit of a connection-oriented sub-layer to have its own conceptual row in the ifTable 🌸 An example would be PPP over an X.25 virtual circuit. The MIB in section 6 of this memo supports those situations.
If a media-specific MIB wants to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for that decision in the media-specific MIB's specification 📝
3.2.5. Bit, Character, and Fixed-Length Interfaces ✨
Okay so, about half the objects in the ifTable work for every type of interface: packet-oriented, character-oriented, and bit-oriented 🎀. Of the other half, two work for both character-oriented and packet-oriented interfaces, and the rest only work for packet-oriented ones 🧚. So yes, it would be super consistent to show every interface type in the ifTable, but it's just not possible to fully implement the whole ifTable for bit- and character-oriented sub-layers 😭.
One possible solution is to split the ifTable into two (or more) new MIB tables 🌸. One table would hold the objects that only matter to packet-oriented interfaces (like PPP), and the other could be used by all interfaces. This option is not recommended and highly undesirable, though, because every agent that implements the ifTable (so, like, just about every existing SNMP agent) would need changes 💀.
The solution this memo goes with builds on a detail that's different in SNMPv2 compared to SNMPv1 💅. In SNMPv2, compliance statements refer to object groups, and object groups are explicitly defined by listing the objects they contain. So you can write multiple compliance statements: one for all interfaces, plus extra ones for specific interface types 🦋. Each one can be based on its own object group, and the group for all interfaces only includes the ifTable objects that make sense for every type of interface. With this approach, every sub-layer gets its own conceptual row in the ifTable 🌈.
So, section 6 of this memo defines the objects from the existing 'interfaces' group of MIB-II 🫶. These definitions are SNMPv2-compliant and semantically equivalent to the original MIB-II definitions. The semantics match and the BER ("on the wire") encodings haven't changed, so these definitions keep the same OBJECT IDENTIFIER values MIB-II assigned ✨. Basically, existing agents that conform to MIB-II and the ifExtensions MIB generally don't need a rewrite 🙌.
This memo also defines several object groups that say which objects apply to which types of interface 🔥:
- the
ifGeneralGroup. This group has the objects that apply to all types of network interfaces, including bit-oriented ones 🍓. - the
ifPacketGroup. This group has the objects that apply to packet-oriented network interfaces 📦. - the
ifFixedLengthGroup. This group has the objects that apply not only to character-oriented interfaces, like RS-232, but also to subnetwork technologies that send data in fixed-length transmission units, like cell-relay/ATM 💜. Besides the octet counters, there are a few other counters (like the error counters) that are useful for this kind of interface but are currently defined as packet-oriented 🙈. To make them work here, their definitions have been generalized to apply to character-oriented interfaces and fixed-length-transmission interfaces 🧁.
Here's a detail to keep in mind 👀. The octet counters in the ifTable add up octet counts for unicast and non-unicast packets into one octet counter per direction (received/transmitted). So with the fixed-length-transmission definition above, if these interfaces support non-unicast packets, separate counts of unicast and multicast/broadcast transmissions can only be kept in a media-specific MIB module 🎯.
3.2.6. Counter Size 💖
Two approaches were looked at for the shrinking minimum counter-wrap time problem 🕰️. One was scaling the counters. For example, ifInOctets could count received octets in, say, 1024 byte blocks. The other was making the counter bigger.
Scaling was rejected 🚫. It works fine at high count rates, but at low rates it struggles. If there's barely any traffic on an interface, it could take a long time before enough counts build up to bump the counter. The traffic would look super bursty, and people could come to the wrong conclusions about how the network is performing 😬.
So the alternative, which this memo adopts, is giving the counters more room with expanded 64-bit counters 🚀. These are provided in new "high capacity" groups,
The old 32-bit counters haven't been deprecated 💅. The 64-bit counters should only be used when the 32-bit counters don't have enough capacity, meaning the 32-bit counters could wrap too fast 🏃♀️.
For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be used 📏. For interfaces that operate faster than 20,000,000 bits/second and slower than 650,000,000 bits/second, 32-bit packet counters MUST be used and 64-bit octet counters MUST be used 🌸. For interfaces that operate at 650,000,000 bits/second or faster, both 64-bit packet counters AND 64-bit octet counters MUST be used 👑.
These speed steps were picked as reasonable compromises, based on the following 🧠:
- Keeping 64-bit counters costs quite a bit, so it's better to have as few agents supporting them as possible 💸. Common interfaces, like Ethernet, shouldn't need them.
- 64-bit counters are a brand new feature, introduced in SNMPv2 🆕. It's reasonable to expect support for them to be spotty for a while, so the goal is to limit them to as few systems as possible 🫠. That basically means 64-bit counters should be limited to higher speed interfaces. Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are pretty widespread, so it seems fair to not require 64-bit counters for them 🌈.
- The 32-bit octet counters wrap in these times for these interfaces (when transmitting maximum-sized packets back-to-back) ⏱️:
- Ethernet: 57 minutes,
- 16 megabit Token Ring: 36 minutes,
- A US T3 line (45 megabits): 12 minutes,
- FDDI: 5.7 minutes
- The 32-bit packet counters wraps in about 57 minutes when 64-byte packets are transmitted back-to-back on a 650,000,000 bit/second link 🤯.
As an aside, a 1-terabit (1,000 gigabits) link will cause a 64 bit octet counter to wrap in just under 5 years 🥹. On the flip side, you'd need an 81,000,000 terabit/second link to make a 64-bit counter wrap in 30 minutes 😳. We believe that, even though technology is marching forward fast, that link speed won't be reached for at least several years 🔮. That leaves plenty of time to evaluate introducing 96 bit counters 💜.
When 64-bit counters are in use, the 32-bit counters MUST still be available 🫶. They report the low 32-bits of the associated 64-bit count. For example, ifInOctets reports the least significant 32 bits of ifHCInOctets. This keeps things working with existing implementations and costs agents very little ✨.
The new "high capacity" groups are 🎀:
- the
ifHCFixedLengthGroupfor character-oriented/fixed-length interfaces, and theifHCPacketGroupfor packet-based interfaces. Both of these groups include 64 bit counters for octets, and - the
ifVHCPacketGroupfor packet-based interfaces. This group includes 64 bit counters for octets and packets.
3.2.7. Interface Speed 🏎️
To keep up with increasing interface speeds, we added an ifHighSpeed object 🔥.
This object reports the interface speed in 1,000,000 (1 million) bits/second units. So the true speed of the interface is the value this object reports, plus or minus 500,000 bits/second 🎯.
Here are the other options we considered 🧐:
- Making the interface speed a 64-bit gauge. This got rejected because the current SMI doesn't allow that syntax 🙅♀️.
Even if 64-bit gauges were available, using them would make agents more complex, because they'd need more 64-bit operations 😵💫.
- We also thought about making "high-32 bit" and "low-32-bit" objects that, when combined, would form a 64-bit value. That just seemed overly complicated for what we're trying to do 🙃.
Plus, full 64-bit precision doesn't seem necessary 🤷♀️. The value of ifHighSpeed will be the only speed report for interfaces faster than 4,294,967,295 bits per second. At that speed, the granularity of ifHighSpeed is 1,000,000 bits per second, so the error is 1/4294, or about 0.02%. That seems reasonable to us 💖.
- Adding a "scale" object that would define the units
ifSpeed's value is in 📏.
This would need two extra objects: one for the scaling and one to replace the current ifSpeed. The later object is required because the semantics of ifSpeed would change a lot, and manager stations that don't understand the new semantics would get confused 😵.
3.2.8. Multicast/Broadcast Counters 📣
To avoid the redundancy of counting all non-unicast packets and also having separate multicast and broadcast packet counters, we deprecate the non-unicast counters 🗑️. Their values can be derived from the others anyway ✨.
The output broadcast and multicast counters defined in RFC 1229 were a little different from the packet counters in the ifTable, since they didn't count errors or discarded packets 🤔. To line the definitions up better, the old counters are deprecated and replaced with new definitions 🔄. Counters with 64 bits of range are needed too, as explained above 💜.
3.2.9. Trap Enable 🚨
In the multi-layer interface model, each sub-layer with an entry in the ifTable can generate linkUp/Down Traps 🔔. Interface state changes tend to spread through the interface (from top to bottom, or bottom to top), so one linkUp/Down event could generate several traps 😩.
It's helpful to give manager stations a way to control generating these traps 🎛️. That's why the ifLinkUpDownTrapEnable object was added 🫶. It lets managers limit trap generation to just the sub-layers they care about 🎀.
The default setting should limit trap generation to one per interface per linkUp/Down event 🙌. Also, the conditions that cause the state changes network managers care about most usually happen at the lowest level of an interface stack 🧱. So by default, only the lowest sub-layer of the interface generates traps 🌟.
3.2.10. Addition of New ifType values 💅
Okay bestie, the ifType syntax got a glow-up 🌸 It's now a textual convention, so the enumerated integer values live in IANAifType, and that one can be re-specified with new values without issuing a whole new version of this document. Super smart! The Internet Assigned Number Authority (IANA) handles all Internet numbers, including the SNMP-related ones and specifically new ifType values. So this document defines two MIB modules: one for the interfaces group, and a second that defines the first version of the IANAifType textual convention. IANA will keep re-issuing that second one over time 🦋
3.2.11. InterfaceIndex Textual Convention ✨
A brand-new textual convention called InterfaceIndex has entered the chat 🎀 It "contains" all of the semantics of the ifIndex object, which means other MIB modules can easily import that meaning without any fuss. Very convenient, very iconic 💖
3.2.12. IfAdminStatus and IfOperStatus 🦋
Okay, this section is the tea ☕ A new state called dormant has been added to ifOperStatus. It means the interface is not actually in a condition to pass packets (so it's not up), but it's in a "pending" state, just chilling and waiting for some external event to happen. For "on-demand" interfaces, dormant is the situation where the interface is waiting for events that will bring it up. Some examples of those events:
- Having packets to transmit before a connection to a remote system is established.
- Having a remote system establish a connection to the interface (for example, dialing up to a slip-server).
The down state now has two meanings, and which one you're looking at depends on the value of ifAdminStatus:
- If
ifAdminStatusis notdownandifOperStatusisdown, then a fault condition is presumed to exist on the interface. Yikes 😭 - If
ifAdminStatusisdown, thenifOperStatuswill normally also bedown. In this case there is not (necessarily) a fault condition on the interface, so no panic 🫶
Heads up: when ifAdminStatus transitions to down, ifOperStatus will normally also transition to down. But that ifOperStatus transition might not happen right away. It could take a small time lag so the interface can finish certain operations before it goes "down." For example, it might need to finish transmitting a packet 📦 If a manager station finds that ifAdminStatus is down and ifOperStatus is not down for a particular interface, the manager station should wait a short while and check again. Only if the condition still exists should it raise an error indication. And naturally, it should also make sure that ifLastChange has not changed during that interval 🕰️
Whenever an interface table entry is created (usually during system initialization), the relevant instance of ifAdminStatus is set to down, and presumably ifOperStatus will also be down 💤
An interface can be enabled in two ways: either through explicit management action (for example, setting ifAdminStatus to up), or as a result of the managed system's initialization process. When ifAdminStatus changes to the up state, the related ifOperStatus should do one of the following:
- Change to the
upstate if and only if the interface is able to send and receive packets. - Change to the
dormantstate if and only if the interface is found to be operable, but it's waiting for other, external, events to occur before it can transmit or receive packets. Presumably, once those expected events happen, the interface will then transition toup. Patience is a virtue 🌈 - Remain in the
downstate if an error or other fault condition is detected on the interface. - Change to the
unknownstate if, for some reason, the state of the interface cannot be ascertained 🤷♀️ - Change to the
testingstate if some test(s) must be performed on the interface. Presumably, after the test is done, the interface's state will change toup,dormant, ordown, as appropriate.
3.2.13. Traps 🔔
The exact definition of when linkUp and linkDown traps get generated has been updated to match the changes to ifAdminStatus and ifOperStatus. Main character update 👑
linkUp and linkDown traps are generated just after ifOperStatus leaves the down state, or just before it enters the down state, respectively. The wording of the conditions for generating a linkDown trap was explicitly chosen so that a node with only one interface can still transmit the linkDown trap before that interface goes down. Clever, right? 🧠
Operational experience suggests that manager stations care most about an interface being in the down state, because that state may indicate a failure. So it made the most sense to instrument either the transitions into/out of the up state, or the transitions into/out of the down state. Let's compare:
Instrumenting transitions into or out of the up state has a drawback 🙃 An on-demand interface might bounce between up and dormant many times, which leads to lots of linkUp traps and zero linkDown traps. Plus, if a node's only interface is that on-demand interface, then a transition to dormant would entail generating a trap, which would mean bringing the link to the up state (and sending a linkUp trap)!! Major spiral 😵💫
On the other hand, instrumenting transitions into or out of the down state has some serious advantages:
- A transition into the
downstate will occur when an error is detected on an interface. Error conditions are presumably of great interest to network managers, so this is the good stuff 🚨 - Departing the
downstate generally indicates the interface is going to eitherupordormant, and both of those are considered "healthy" states 💚
Also, it is believed that generating traps on transitions into or out of the down state is generally consistent with current usage and interpretation of these traps by manager stations.
So, this memo defines that it is the transitions into/out of the down state that generate traps. Period 💅
Obviously, if a failure condition is present on a node with a single interface, the linkDown trap will probably not be successfully transmitted, since the interface it would need to go out through has failed. Rip, but that's just physics 🥀
3.2.14. ifSpecific 🌸
The current definition of ifSpecific isn't explicit enough 😬 The only definition that can be made explicit and cover all the useful situations (see section 3.1.9) is to have ifSpecific be the most general value for the media-specific MIB module (the first example given in section 3.1.9). That effectively makes it redundant, because it contains no more information than what ifType already provides. For this reason, ifSpecific has been deprecated. Bye bye, ifSpecific 👋
3.3. Media-Specific MIB Applicability 🧚
The exact use and semantics of many objects in this MIB are open to some interpretation. That's because the MIB is so generic. It's not always possible to come up with specific, unambiguous text that covers every case while still keeping that generic nature intact 🌈
So it's on the media-specific MIB designer to clarify, wherever necessary, how the objects in this MIB are used with respect to their media-specific MIB. Here are the specific areas that need clarification:
- Layering Model: The media-specific MIB designer MUST completely and unambiguously specify the layering model used. Each individual sub-layer must be identified 🍰
- Virtual Circuits: The media-specific MIB designer MUST specify whether virtual circuits are assigned entries in the
ifTableor not. If they are, compelling rationale must be presented 💜 - ifTestTable: The media-specific MIB designer MUST specify the applicability of the
ifTestTable🧪 - ifRcvAddressTable: The media-specific MIB designer MUST specify the applicability of the
ifRcvAddressTable📬 - ifType: For each of the
ifTypevalues that the media-specific MIB applies to, it must specify the mapping ofifTypevalues to media-specific MIB module(s) and instances of MIB objects within those modules 🗺️
Now for the important catch 🚫 Wherever this interface MIB is specific about the semantics, DESCRIPTION, or applicability of objects, the media-specific MIB designer MUST NOT change said semantics, DESCRIPTION, or applicability. No rewriting the rules, bestie 🙅♀️
4. Overview 👑
This MIB consists of 5 tables. Let's meet them:
ifTable: This table is theifTablefrom MIB-II.ifXTable: This table contains objects that were added to the Interface MIB as a result of the Interface Evolution effort. It also contains replacements for objects of the original MIB-IIifTablethat were deprecated because their semantics have significantly changed. And it holds objects that were previously in theifExtnsTable🎀ifStackTable: This table contains objects that define the relationships among the sub-layers of an interface 🥞ifTestTable: This table contains objects used to perform tests on interfaces. It's a generic table, so designers of media-specific MIBs must define exactly how it applies to their specific MIB 🧪
This table replaces the interface test table defined in RFC1229 [7]. The big change is that the ifExtnsTestCommunity (and ifExtnsTestContext, which would also have been required for SNMPv2) and ifExtnsTestRequestId objects are replaced by the new ifTestId, ifTestStatus, and ifTestOwner objects. Glow-up energy ✨
ifRcvAddressTable: This table contains objects used to define the media-level addresses that this interface will receive. It's also a generic table, so designers of media-specific MIBs must define exactly how it applies to their specific MIB 📬
5. IANAifType Definition ✨
okay so this section is basically the official guest list for ifType 💅 It's a MIB module called IANAifType-MIB, and it defines the IANAifType textual convention, which is the set of enumerated values the ifType object in MIB-II's ifTable can take. main character energy for IANA 🦋
The text explains that the list gets published now and then by IANA, either in the Assigned Numbers RFC or in a derivative of it for Internet Network Management number assignments. New values get requested by emailing iana@isi.edu 📧 It also says the link between ifType values and media-specific MIB OIDs is entirely IANA's business and can change without notice. Implementors are told not to pre-assume any relationship between ifType values and transmission subtree OIDs, even though they often match 🙈
IANAifType-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
ianaifType MODULE-IDENTITY
LAST-UPDATED "9311082155Z"
ORGANIZATION "IANA"
CONTACT-INFO
" Internet Assigned Numbers Authority
Postal: USC/Information Sciences Institute
4676 Admiralty Way, Marina del Rey, CA 90292
Tel: +1 310 822 1511
E-Mail: iana@isi.edu"
DESCRIPTION
"The MIB module which defines the IANAifType textual
convention, and thus the enumerated values of the
ifType object defined in MIB-II's ifTable."
::= { mib-2 30 }
IANAifType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used as the syntax of the ifType
object in the (updated) definition of MIB-II's
ifTable.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values should be made to IANA via
email (iana@isi.edu).
The relationship between the assignment of ifType
values and of OIDs to particular media-specific MIBs
is solely the purview of IANA and is subject to change
without notice. Quite often, a media-specific MIB's
OID-subtree assignment within MIB-II's 'transmission'
subtree will be the same as its ifType value.
However, in some circumstances this will not be the
case, and implementors must not pre-assume any
specific relationship between ifType values and
transmission subtree OIDs."
SYNTAX INTEGER {
other(1), -- none of the following
regular1822(2),
hdh1822(3),
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6),
iso88023Csmacd(7),
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
starLan(11),
proteon10Mbit(12),
proteon80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18), -- DS1/E1 (RFC 1406)
e1(19), -- obsolete
basicISDN(20),
primaryISDN(21),
propPointToPointSerial(22), -- proprietary serial
ppp(23),
softwareLoopback(24),
eon(25), -- CLNP over IP (RFC 1070)
ethernet3Mbit(26),
nsip(27), -- XNS over IP
slip(28), -- generic SLIP
ultra(29), -- ULTRA technologies
ds3(30), -- T-3
sip(31), -- SMDS
frameRelay(32), -- DTE only
rs232(33),
para(34), -- parallel-port
arcnet(35), -- arcnet
arcnetPlus(36), -- arcnet plus
atm(37), -- ATM cells
miox25(38),
sonet(39), -- SONET or SDH
x25ple(40),
iso88022llc(41),
localTalk(42),
smdsDxi(43),
frameRelayService(44), -- Frame relay DCE
v35(45),
hssi(46),
hippi(47),
modem(48), -- Generic modem
aal5(49), -- AAL5 over ATM
sonetPath(50),
sonetVT(51),
smdsIcip(52), -- SMDS InterCarrier Interface
propVirtual(53), -- proprietary virtual/internal
propMultiplexor(54) -- proprietary multiplexing
}
END6. Interfaces Group Definitions ✨
this is the big one, the IF-MIB module 🎀 It's the generic object set for network interface sub-layers, and it's an updated version of MIB-II's ifTable that folds in the extensions from RFC 1229. The contact info lists Keith McCloghrie and Frank Kastenholz from the IETF Interfaces MIB Working Group 🫶
Before anything else, the module sets up OwnerString, a textual convention for an administratively assigned owner name. The text suggests it can hold things like a manager station's transport address, a management station name, personnel names, a location, or a phone number, and an agent that owns an entry sets the string to something starting with 'agent' 🌸
Next comes InterfaceIndex, which carries the semantics of ifIndex. Anything defined in other MIB modules that needs those semantics should use it. Each value is a unique number greater than zero, the text recommends contiguous values starting from 1, and each sub-layer's value must stay constant from one re-initialization of the management system to the next ✨
Then we get ifNumber, the count of network interfaces on the system no matter their current state, followed by ifTable, ifEntry, and the columns. Each sub-layer below the internetwork-layer counts as an interface, and the ifTable has one entry per interface 🦋
IF-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
Integer32, TimeTicks,
NOTIFICATION-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString,
PhysAddress, TruthValue, RowStatus,
AutonomousType, TestAndIncr FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
IANAifType FROM IANAifType-MIB
interfaces FROM RFC-1213;
ifMIB MODULE-IDENTITY
LAST-UPDATED "9311082155Z"
ORGANIZATION "IETF Interfaces MIB Working Group"
CONTACT-INFO
" Keith McCloghrie
Postal: Hughes LAN Systems
1225 Charleston Road, Mountain View, CA 94043
Tel: +1 415 966 7934
E-Mail: kzm@hls.com
Frank Kastenholz
Postal: FTP Software
2 High Street, North Andover, MA 01845
Tel: +1 508 685 4000
E-Mail: kasten@ftp.com"
DESCRIPTION
"The MIB module to describe generic objects for
network interface sub-layers. This MIB is an updated
version of MIB-II's ifTable, and incorporates the
extensions defined in RFC 1229."
::= { mib-2 31 }
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
-- OwnerString has the same semantics as used in RFC 1271
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"This data type is used to model an administratively
assigned name of the owner of a resource. This
information is taken from the NVT ASCII character set.
It is suggested that this name contain one or more of
the following: ASCII form of the manager station's
transport address, management station name (e.g.,
domain name), network management personnel's name,
location, or phone number. In some cases the agent
itself will be the owner of an entry. In these cases,
this string shall be set to a string starting with
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
-- InterfaceIndex contains the semantics of ifIndex and
-- should be used for any objects defined on other mib
-- modules that need these semantics.
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface
or interface sub-layer in the managed system. It is
recommended that values are assigned contiguously
starting from 1. The value for each interface sub-
layer must remain constant at least from one re-
initialization of the entity's network management
system to the next re-initialization."
SYNTAX Integer32
ifNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their
current state) present on this system."
::= { interfaces 1 }
-- the Interfaces table
-- The Interfaces table contains information on the entity's
-- interfaces. Each sub-layer below the internetwork-layer
-- of a network interface is considered to be an interface.
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries
is given by the value of ifNumber."
::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable
to a particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex,
ifDescr DisplayString,
ifType IANAifType,
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, -- deprecated
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, -- deprecated
ifSpecific OBJECT IDENTIFIER -- deprecated
}
ifIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each
interface. It is recommended that values are assigned
contiguously starting from 1. The value for each
interface sub-layer must remain constant at least from
one re-initialization of the entity's network
management system to the next re-initialization."
::= { ifEntry 1 }
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of the
manufacturer, the product name and the version of the
interface hardware/software."
::= { ifEntry 2 }
ifType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of interface. Additional values for ifType
are assigned by the Internet Assigned Numbers
Authority (IANA), through updating the syntax of the
IANAifType textual convention."
::= { ifEntry 3 }
ifMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The size of the largest packet which can be
sent/received on the interface, specified in octets.
For interfaces that are used for transmitting network
datagrams, this is the size of the largest network
datagram that can be sent on the interface."
::= { ifEntry 4 }Okay bestie, we're picking up right where the interface stuff gets spicy 🌸✨ These are the counters, status flags, and speed readings that tell you what an interface is actually doing.
ifSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in
bits per second. For interfaces which do not vary in
bandwidth or for those where no accurate estimation
can be made, this object should contain the nominal
bandwidth. If the bandwidth of the interface is
greater than the maximum value reportable by this
object then this object should report its maximum
value (4,294,967,295) and ifHighSpeed must be used to
report the interace's speed. For a sub-layer which
has no concept of bandwidth, this object should be
zero."
::= { ifEntry 5 }Okay so ifSpeed is basically the speedometer 🏎️💨 It's the interface's bandwidth in bits per second, and if the real speed is too big for this Gauge32, it maxes out at 4,294,967,295 and you go check ifHighSpeed instead. Iconic handoff, honestly 💅
ifPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface's address at its protocol sub-layer.
The interface's media-specific MIB must define the bit
and byte ordering and format of the value contained by
this object. For interfaces which do not have such an
address (e.g., a serial line), this object should
contain an octet string of zero length."
::= { ifEntry 6 }ifPhysAddress is the interface's address at its sub-layer 🦋 The media-specific MIB is the one that decides how the bits and bytes are ordered and formatted, so go there for the details. A serial line doesn't really have an address, so it gets a zero-length octet string. Lowkey relatable 🫶
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3)
state indicates that no operational packets can be
passed. When a managed system initializes, all
interfaces start with ifAdminStatus in the down(2)
state. As a result of either explicit management
action or per configuration information retained by
the managed system, ifAdminStatus is then changed to
either the up(1) or testing(3) states (or remains in
the down(2) state)."
::= { ifEntry 7 }ifAdminStatus is what you want the interface to be 🎀 Everything starts out down(2) when the system boots up, and then management actions or saved config can flip it to up(1) or testing(3), or leave it right where it is. testing(3) means no operational packets get through, so it's basically a "do not disturb" mode 🙈
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3), -- in some test mode
unknown(4), -- status can not be determined
-- for some reason.
dormant(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets
can be passed. If ifAdminStatus is down(2) then
ifOperStatus should be down(2). If ifAdminStatus is
changed to up(1) then ifOperStatus should change to
up(1) if the interface is ready to transmit and
receive network traffic; it should change to
dormant(5) if the interface is waiting for external
actions (such as a serial line waiting for an
incomming connection); it should remain in the down(2)
state if and only if there is a fault that prevents if
from going to the up(1) state."
::= { ifEntry 8 }Now ifOperStatus is the vibe check 🔥 It's the actual current state, which might not match what was requested. If ifAdminStatus is down(2), ifOperStatus should also be down(2). When it's asked to go up(1), it'll be up(1) if it's ready to move traffic, dormant(5) if it's waiting on something outside the box (like a serial line waiting for a connection), and it stays down(2) only when a fault is blocking it. unknown(4) is for when the status just can't be figured out 💀
ifLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the interface
entered its current operational state. If the current
state was entered prior to the last re-initialization
of the local network management subsystem, then this
object contains a zero value."
::= { ifEntry 9 }ifLastChange is the "when did this happen?" object ⏰ It gives you the sysUpTime from when the interface entered its current operational state. If that happened before the local network management subsystem last re-initialized, the value is zero, so don't panic when you see that 🌈
ifInOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
including framing characters."
::= { ifEntry 10 }ifInOctets counts every octet received on the interface, framing characters included 📦 Counting the whole envelope, not just what's inside.
ifInUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were not addressed to a
multicast or broadcast address at this sub-layer."
::= { ifEntry 11 }ifInUcastPkts counts the packets handed up to a higher layer that were not addressed to a multicast or broadcast address 🎯 Just the one-on-one messages, thank you very much.
ifInNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
multicast or broadcast address at this sub-layer.
This object is deprecated in favour of
ifInMulticastPkts and ifInBroadcastPkts."
::= { ifEntry 12 }ifInNUcastPkts is the old-school version of the multicast and broadcast count, and it's been marked deprecated 🪦 The newer objects you want are ifInMulticastPkts and ifInBroadcastPkts, so switch over, bestie 💖
ifInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of inbound packets which were chosen to be
discarded even though no errors had been detected to
prevent their being deliverable to a higher-layer
protocol. One possible reason for discarding such a
packet could be to free up buffer space."
::= { ifEntry 13 }ifInDiscards counts inbound packets that got tossed even though nothing was actually wrong with them 🗑️ The spec mentions one possible reason: freeing up buffer space. Not an error, just a choice. Main character energy for buffers, honestly ✨
ifInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from
being deliverable to a higher-layer protocol. For
character-oriented or fixed-length interfaces, the
number of inbound transmission units that contained
errors preventing them from being deliverable to a
higher-layer protocol."
::= { ifEntry 14 }ifInErrors is the "this packet was broken and couldn't be delivered" counter 💔 For packet-oriented interfaces it counts packets, and for character-oriented or fixed-length ones it counts transmission units. Same idea, different unit, no drama 🫠
ifInUnknownProtos OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of packets
received via the interface which were discarded
because of an unknown or unsupported protocol. For
character-oriented or fixed-length interfaces which
support protocol multiplexing the number of
transmission units received via the interface which
were discarded because of an unknown or unsupported
protocol. For any interface which does not support
protocol multiplexing, this counter will always be 0."
::= { ifEntry 15 }ifInUnknownProtos counts the stuff that got dropped because the protocol was unknown or unsupported 🤷♀️ If the interface doesn't do protocol multiplexing at all, this counter just stays at 0, which is honestly kind of peaceful 🌸
ifOutOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters."
::= { ifEntry 16 }ifOutOctets is the outbound mirror of ifInOctets 🚀 Every octet sent out of the interface, framing characters and all.
ifOutUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were not
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent."
::= { ifEntry 17 }ifOutUcastPkts counts the packets higher-level protocols asked to send that weren't multicast or broadcast 📤 It includes the ones that got discarded or never sent, so it's counting the requests, not just the successes 🙃
ifOutNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent.
This object is deprecated in favour of
ifOutMulticastPkts and ifOutBroadcastPkts."
::= { ifEntry 18 }ifOutNUcastPkts is the deprecated outbound multicast and broadcast count 🪦 Same energy as before: use ifOutMulticastPkts and ifOutBroadcastPkts instead 💅
ifOutDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of outbound packets which were chosen to
be discarded even though no errors had been detected
to prevent their being transmitted. One possible
reason for discarding such a packet could be to free
up buffer space."
::= { ifEntry 19 }ifOutDiscards is the outbound version of the discard drama 🧹 Packets dropped on purpose, with no errors involved, and freeing up buffer space is again the example given.
ifOutErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of
outbound packets that could not be transmitted because
of errors. For character-oriented or fixed-length
interfaces, the number of outbound transmission units
that could not be transmitted because of errors."
::= { ifEntry 20 }ifOutErrors counts the outbound stuff that couldn't go out because something went wrong 😭 Packets for packet-oriented interfaces, transmission units for character-oriented or fixed-length ones.
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }ifOutQLen is the length of the output packet queue in packets, and it's deprecated too 🪦 Retired, but we remember it fondly 🥹
ifSpecific OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"A reference to MIB definitions specific to the
particular media being used to realize the interface.
It is recommended that this value point to an instance
of a MIB object in the media-specific MIB, i.e., that
this object have the semantics associated with the
InstancePointer textual convention defined in RFC
1443. In fact, it is recommended that the media-
specific MIB specify what value ifSpecific should/can
take for values of ifType. If no MIB definitions
specific to the particular media are available, the
value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }ifSpecific points at the media-specific MIB definitions for whatever physical medium the interface is using 🧚 The spec recommends pointing at an instance of a MIB object in that media-specific MIB, using the InstancePointer textual convention from RFC 1443. If there's no media-specific MIB, the value should be { 0 0 }. And yes, this one's also deprecated 🙈
Next up, we get the extension table. It's the newer home for the extra interface info, and it replaces the old ifExtnsTable 🌟
--
-- Extension to the interface table
--
-- This table replaces the ifExtnsTable table.
--
ifXTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries
is given by the value of ifNumber. This table
contains additional objects for the interface table."
::= { ifMIBObjects 1 }
ifXEntry OBJECT-TYPE
SYNTAX IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional management information
applicable to a particular interface."
AUGMENTS { ifEntry }
::= { ifXTable 1 }
IfXEntry ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
ifHCInBroadcastPkts Counter64,
ifHCOutOctets Counter64,
ifHCOutUcastPkts Counter64,
ifHCOutMulticastPkts Counter64,
ifHCOutBroadcastPkts Counter64,
ifLinkUpDownTrapEnable INTEGER,
ifHighSpeed Gauge32,
ifPromiscuousMode TruthValue,
ifConnectorPresent TruthValue
}ifXTable is the list of interface entries, and its row count matches ifNumber 📋 ifXEntry augments each ifEntry, so every interface gets its own extra info row 🎀 The IfXEntry sequence is the full menu: names, multicast and broadcast counters in both 32-bit and 64-bit flavours, the trap enable flag, ifHighSpeed, promiscuous mode, and connector presence. The HC (high-capacity) counters are the ones that won't wrap around as quickly as the Counter32 versions, which is a whole mood 💜✨
okay bestie, so ifName is literally the interface's nickname 🎀 It's the name the device itself gives it, the one you'd type into the console, so it can be a text name like le0 or just a plain port number like 1. If a few ifTable rows are secretly one interface, they all share the same ifName, which is so iconic ✨
ifName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The textual name of the interface. The value of this
object should be the name of the interface as assigned
by the local device and should be suitable for use in
commands entered at the device's `console'. This
might be a text name, such as `le0' or a simple port
number, such as `1', depending on the interface naming
syntax of the device. If several entries in the
ifTable together represent a single interface as named
by the device, then each will have the same value of
ifName. If there is no local name, or this object is
otherwise not applicable, then this object contains a
0-length string."
::= { ifXEntry 1 }
ifInMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
multicast address at this sub-layer. For a MAC layer
protocol, this includes both Group and Functional
addresses."
::= { ifXEntry 2 }
ifInBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
broadcast address at this sub-layer."
::= { ifXEntry 3 }
ifOutMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast address at this sub-layer,
including those that were discarded or not sent. For
a MAC layer protocol, this includes both Group and
Functional addresses."
::= { ifXEntry 4 }
ifOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a broadcast address at this sub-layer,
including those that were discarded or not sent."
::= { ifXEntry 5 }These four are the basic 32-bit packet counters, and they're the ones with the little ✨ moments where you count multicast and broadcast separately from regular unicast traffic 💅
Next up is the high capacity crew 🚀 Counter64 is the 64-bit upgrade of the classic counters, so the numbers can get SO big before they roll over. Same vibes, just way more room to flex 💜
--
-- High Capacity Counter objects. These objects are all
-- 64 bit versions of the "basic" ifTable counters. These
-- objects all have the same basic semantics as their 32-bit
-- counterparts, however, their syntax has been extended
-- to 64 bits.
--
ifHCInOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
including framing characters. This object is a 64-bit
version of ifInOctets."
::= { ifXEntry 6 }
ifHCInUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were not addressed to a
multicast or broadcast address at this sub-layer.
This object is a 64-bit version of ifInUcastPkts."
::= { ifXEntry 7 }
ifHCInMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
multicast address at this sub-layer. For a MAC layer
protocol, this includes both Group and Functional
addresses. This object is a 64-bit version of
ifInMulticastPkts."
::= { ifXEntry 8 }
ifHCInBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
broadcast address at this sub-layer. This object is a
64-bit version of ifInBroadcastPkts."
::= { ifXEntry 9 }
ifHCOutOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters. This object
is a 64-bit version of ifOutOctets."
::= { ifXEntry 10 }
ifHCOutUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were not
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent. This object is a 64-bit version of
ifOutUcastPkts."
::= { ifXEntry 11 }
ifHCOutMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast address at this sub-layer,
including those that were discarded or not sent. For
a MAC layer protocol, this includes both Group and
Functional addresses. This object is a 64-bit version
of ifOutMulticastPkts."
::= { ifXEntry 12 }
ifHCOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a broadcast address at this sub-layer,
including those that were discarded or not sent. This
object is a 64-bit version of ifOutBroadcastPkts."
::= { ifXEntry 13 }Now the trap switch 🔔 ifLinkUpDownTrapEnable decides whether linkUp and linkDown traps get sent for an interface. By default it's enabled for the interfaces that sit on top of nothing (checked against ifStackTable), and disabled for the ones that do sit on top of something else. Main character energy for the bottom layer, honestly 👑
ifHighSpeed is the bandwidth estimate, measured in units of 1,000,000 bits per second 🏎️ If it says n, the real speed is somewhere between n-500,000 and n+499,999. Sub-layers with no concept of bandwidth just report zero 🍓
ifPromiscuousMode is the "accept everything on the wire" setting 👀 It's false(2) when the interface only takes frames addressed to this station, and true(1) when it takes everything transmitted on the media. Only certain media types allow true(1), and turning it on may need a reset before it kicks in. Also, it has no effect on broadcast or multicast reception, so don't get confused 🙈
ifConnectorPresent is just a yes-or-no on whether the sub-layer has a physical connector 🔌
ifLinkUpDownTrapEnable OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether linkUp/linkDown traps should be
generated for this interface.
By default, this object should have the value
enabled(1) for interfaces which do not operate on
'top' of any other interface (as defined in the
ifStackTable), and disabled(2) otherwise."
::= { ifXEntry 14 }
ifHighSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in
units of 1,000,000 bits per second. If this object
reports a value of `n' then the speed of the interface
is somewhere in the range of `n-500,000' to
`n+499,999'. For interfaces which do not vary in
bandwidth or for those where no accurate estimation
can be made, this object should contain the nominal
bandwidth. For a sub-layer which has no concept of
bandwidth, this object should be zero."
::= { ifXEntry 15 }
ifPromiscuousMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object has a value of false(2) if this interface
only accepts packets/frames that are addressed to this
station. This object has a value of true(1) when the
station accepts all packets/frames transmitted on the
media. The value true(1) is only legal on certain
types of media. If legal, setting this object to a
value of true(1) may require the interface to be reset
before becoming effective.
The value of ifPromiscuousMode does not affect the
reception of broadcast and multicast packets/frames by
the interface."
::= { ifXEntry 16 }
ifConnectorPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object has the value 'true(1)' if the interface
sublayer has a physical connector and the value
'false(2)' otherwise."
::= { ifXEntry 17 }Last stop for this part is the interface stack group 🥞 It's the family tree of sub-layers, showing which ones run on top of which others. Every sub-layer is a row in the ifTable, and this group is mandatory for all systems, so nobody gets to skip it 💀
ifStackTable is the whole table, and each entry is a relationship between two sub-layers, indexed by the higher one and the lower one. ifStackHigherLayer is the ifIndex of the layer on top, and it's 0 if there's no higher sub-layer below the internetwork layer. ifStackLowerLayer is the ifIndex of the layer underneath, and it's 0 if there's nothing below 🧚 ifStackStatus is the RowStatus for that relationship, and the description for it is where this part leaves off 🌸
-- The Interface Stack Group
--
-- Implementation of this group is mandatory for all systems
--
ifStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table containing information on the relationships
between the multiple sub-layers of network interfaces.
In particular, it contains information on which sub-
layers run 'on top of' which other sub-layers. Each
sub-layer corresponds to a conceptual row in the
ifTable."
::= { ifMIBObjects 2 }
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer runs on
'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer Integer32,
ifStackLowerLayer Integer32,
ifStackStatus RowStatus
}
ifStackHigherLayer OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher
sub-layer of the relationship, i.e., the sub-layer
which runs on 'top' of the sub-layer identified by the
corresponding instance of ifStackLowerLayer. If there
is no higher sub-layer (below the internetwork layer),
then this object has the value 0."
::= { ifStackEntry 1 }
ifStackLowerLayer OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-
layer of the relationship, i.e., the sub-layer which
runs 'below' the sub-layer identified by the
corresponding instance of ifStackHigherLayer. If
there is no lower sub-layer, then this object has the
value 0."
::= { ifStackEntry 2 }
ifStackStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The status of the relationship between two sub-
layers.okay the ifStackStatus tea is still going, and then we get the whole ifTestTable 💅✨
Changing the value of this object from 'active' to
'notInService' or 'destroy' will likely have
consequences up and down the interface stack. Thus,
write access to this object is likely to be
inappropriate for some types of interfaces, and many
implementations will choose not to support write-
access for any type of interface."
::= { ifStackEntry 3 }
--
-- The Interface Test Table
--
-- This group of objects is optional. However, a media-specific
-- MIB may make implementation of this group mandatory.
--
-- This table replaces the ifExtnsTestTable
--
ifTestTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfTestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one entry per interface. It
defines objects which allow a network manager to
instruct an agent to test an interface for various
faults. Tests for an interface are defined in the
media-specific MIB for that interface. After invoking
a test, the object ifTestResult can be read to
determine the outcome. If an agent can not perform
the test, ifTestResult is set to so indicate. The
object ifTestCode can be used to provide further
test-specific or interface-specific (or even
enterprise-specific) information concerning the
outcome of the test. Only one test can be in progress
on each interface at any one time. If one test is in
progress when another test is invoked, the second test
is rejected. Some agents may reject a test when a
prior test is active on another interface.
Before starting a test, a manager-station must first
obtain 'ownership' of the entry in the ifTestTable for
the interface to be tested. This is accomplished with
the ifTestId and ifTestStatus objects as follows:
try_again:
get (ifTestId, ifTestStatus)
while (ifTestStatus != notInUse)
/*
* Loop while a test is running or some other
* manager is configuring a test.
*/
short delay
get (ifTestId, ifTestStatus)
}
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
if ( set(ifTestId = lock_value, ifTestStatus = inUse,
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
/*
* I have the lock
*/
set up any test parameters.
/*
* This starts the test
*/
set(ifTestType = test_to_run);
wait for test completion by polling ifTestResult
when test completes, agent sets ifTestResult
agent also sets ifTestStatus = 'notInUse'
retrieve any additional test results, and ifTestId
if (ifTestId == lock_value+1) results are valid
A manager station first retrieves the value of the
appropriate ifTestId and ifTestStatus objects,
periodically repeating the retrieval if necessary,
until the value of ifTestStatus is 'notInUse'. The
manager station then tries to set the same ifTestId
object to the value it just retrieved, the same
ifTestStatus object to 'inUse', and the corresponding
ifTestOwner object to a value indicating itself. If
the set operation succeeds then the manager has
obtained ownership of the ifTestEntry, and the value of
the ifTestId object is incremented by the agent (per
the semantics of TestAndIncr). Failure of the set
operation indicates that some other manager has
obtained ownership of the ifTestEntry.
Once ownership is obtained, any test parameters can be
setup, and then the test is initiated by setting
ifTestType. On completion of the test, the agent sets
ifTestStatus to 'notInUse'. Once this occurs, the
manager can retrieve the results. In the (rare) event
that the invocation of tests by two network managers
were to overlap, then there would be a possibility that
the first test's results might be overwritten by the
second test's results prior to the first results being
read. This unlikely circumstance can be detected by a
network manager retrieving ifTestId at the same time as
retrieving the test results, and ensuring that the
results are for the desired request.
If ifTestType is not set within an abnormally long
period of time after ownership is obtained, the agent
should time-out the manager, and reset the value of the
ifTestStatus object back to 'notInUse'. It is
suggested that this time-out period be 5 minutes.
In general, a management station must not retransmit a
request to invoke a test for which it does not receive
a response; instead, it properly inspects an agent's
MIB to determine if the invocation was successful.
Only if the invocation was unsuccessful, is the
invocation request retransmitted.
Some tests may require the interface to be taken off-
line in order to execute them, or may even require the
agent to reboot after completion of the test. In these
circumstances, communication with the management
station invoking the test may be lost until after
completion of the test. An agent is not required to
support such tests. However, if such tests are
supported, then the agent should make every effort to
transmit a response to the request which invoked the
test prior to losing communication. When the agent is
restored to normal service, the results of the test are
properly made available in the appropriate objects.
Note that this requires that the ifIndex value assigned
to an interface must be unchanged even if the test
causes a reboot. An agent must reject any test for
which it cannot, perhaps due to resource constraints,
make available at least the minimum amount of
information after that test completes."
::= { ifMIBObjects 3 }
ifTestEntry OBJECT-TYPE
SYNTAX IfTestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing objects for invoking tests on an
interface."
AUGMENTS { ifEntry }
::= { ifTestTable 1 }
IfTestEntry ::=
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
ifTestOwner OwnerString
}
ifTestId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the current invocation of the
interface's test."
::= { ifTestEntry 1 }
ifTestStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates whether or not some manager
currently has the necessary 'ownership' required to
invoke a test on this interface. A write to this
object is only successful when it changes its value
from 'notInUse(1)' to 'inUse(2)'. After completion of
a test, the agent resets the value back to
'notInUse(1)'."
::= { ifTestEntry 2 }
ifTestType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control variable used to start and stop operator-
initiated interface tests. Most OBJECT IDENTIFIER
values assigned to tests are defined elsewhere, in
association with specific types of interface.
However, this document assigns a value for a full-
duplex loopback test, and defines the special meanings
of the subject identifier:
noTest OBJECT IDENTIFIER ::= { 0 0 }
When the value noTest is written to this object, no
action is taken unless a test is in progress, in which
case the test is aborted. Writing any other value to
this object is only valid when no test is currently in
progress, in which case the indicated test is
initiated.
When read, this object always returns the most recent
value that ifTestType was set to. If it has not been
set since the last initialization of the network
management subsystem on the agent, a value of noTest
is returned."
::= { ifTestEntry 3 }
ifTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the result of the most recently
requested test, or the value none(1) if no tests have
been requested since the last reset. Note that this
facility provides no provision for saving the results
of one test when starting another, as could be
required if used by multiple managers concurrently."
::= { ifTestEntry 4 }
ifTestCode OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains a code which contains more
specific information on the test result, for example
an error-code after a failed test. Error codes and
other values this object may take are specific to the
type of interface and/or test. The value may have the
semantics of either the AutonomousType or
InstancePointer textual conventions as defined in RFC
1443. The identifier:
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }the ifTestTable is basically a lock-and-key situation 🔐🦋 a manager has to claim ownership with ifTestId and ifTestStatus before it can run anything, and the whole thing is set up so two managers don't step on each other's toes 🫶
okay so we're still in the test-and-receive zone 💅 ifTestOwner is literally the entity that holds the 'ownership' needed to kick off a test on an interface 🎀
ifTestOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The entity which currently has the 'ownership'
required to invoke a test on this interface."
::= { ifTestEntry 6 }
-- Generic Receive Address Table
--
-- This group of objects is mandatory for all types of
-- interfaces which can receive packets/frames addressed to
-- more than one address.
--
-- This table replaces the ifExtnsRcvAddr table. The main
-- difference is that this table makes use of the RowStatus
-- textual convention, while ifExtnsRcvAddr did not.
ifRcvAddressTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains an entry for each address
(broadcast, multicast, or uni-cast) for which the
system will receive packets/frames on a particular
interface, except as follows:
- for an interface operating in promiscuous mode,
entries are only required for those addresses for
which the system would receive frames were it not
operating in promiscuous mode.
- for 802.5 functional addresses, only one entry is
required, for the address which has the functional
address bit ANDed with the bit mask of all functional
addresses for which the interface will accept frames."
::= { ifMIBObjects 4 }
ifRcvAddressEntry OBJECT-TYPE
SYNTAX IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of objects identifying an address for which
the system will accept packets/frames on the
particular interface identified by the index value
ifIndex."
INDEX { ifIndex, ifRcvAddressAddress }
::= { ifRcvAddressTable 1 }
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
ifRcvAddressAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An address for which the system will accept
packets/frames on this entry's interface."
::= { ifRcvAddressEntry 1 }
ifRcvAddressStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to create and delete rows in the
ifRcvAddressTable."
::= { ifRcvAddressEntry 2 }
ifRcvAddressType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
volatile(2),
nonVolatile(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object has the value nonVolatile(3) for those
entries in the table which are valid and will not be
deleted by the next restart of the managed system.
Entries having the value volatile(2) are valid and
exist, but have not been saved, so that will not exist
after the next restart of the managed system. Entries
having the value other(1) are valid and exist but are
not classified as to whether they will continue to
exist after the next restart."
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }ngl the receive address table is so cute 🦋 it's basically a guest list of every address an interface is willing to accept packets for, and there are two special carve-outs: promiscuous mode and 802.5 functional addresses 🌸 the table also swapped the old ifExtnsRcvAddr setup for RowStatus, which is giving main character energy ✨
-- definition of interface-related traps.
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication links
is about to transition into the down state."
::= { snmpTraps 3 }
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication links
has transitioned out of the down state."
::= { snmpTraps 4 }🔥 the linkDown and linkUp traps are the drama queens of this whole MIB 😭 they both carry ifIndex, ifAdminStatus and ifOperStatus, and they're fired by an SNMPv2 entity acting as an agent 🫶
-- conformance information
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
-- compliance statements
ifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
have network interfaces."
MODULE -- this module
MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
GROUP ifFixedLengthGroup
DESCRIPTION
"This group is mandatory for all network interfaces
which are character-oriented or transmit data in
fixed-length transmission units."
GROUP ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces which are character-oriented or transmit
data in fixed-length transmission units, and for which
the value of the corresponding instance of ifSpeed is
greater than 20,000,000 bits/second."
GROUP ifPacketGroup
DESCRIPTION
"This group is mandatory for all network interfaces
which are packet-oriented."
GROUP ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces which are packet-oriented and for which the
value of the corresponding instance of ifSpeed is
greater than 650,000,000 bits/second."
GROUP ifTestGroup
DESCRIPTION
"This group is optional. Media-specific MIBs which
require interface tests are strongly encouraged to use
this group for invoking tests and reporting results.
A medium specific MIB which has mandatory tests may
make implementation of this group mandatory."
GROUP ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by
the media-specific MIBs. Media-specific MIBs must
define the exact meaning, use, and semantics of the
addresses in this group."
OBJECT ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifStackStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the
value testing(3)."
::= { ifCompliances 1 }okay the compliance statement is where the rules get real 💅 the MANDATORY-GROUPS are ifGeneralGroup and ifStackGroup, and then a bunch of groups depend on whether the interface is character-oriented or packet-oriented, plus how fast it is 🚀 ifTestGroup is optional but strongly encouraged for anyone running tests 🧚 and ifRcvAddressGroup's applicability has to be defined by the media-specific MIBs, which is giving "not my problem, it's the media MIB's job" 🙈
-- units of conformance
ifGeneralGroup OBJECT-GROUP
OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName }
STATUS current
DESCRIPTION
"A collection of objects providing information
applicable to all network interfaces."
::= { ifGroups 1 }
-- the following five groups are mutually exclusive; at most
-- one of these groups is implemented for any interface
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to non-high speed, character-oriented or
fixed-length-transmission network interfaces. (Non-
high speed interfaces transmit and receive at speeds
less than or equal to 20,000,000 bits/second.)"
::= { ifGroups 2 }
ifHCFixedLengthGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to high speed (greater than 20,000,000
bits/second) character-oriented or fixed-length-
transmission network interfaces."
::= { ifGroups 3 }
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to non-high speed, packet-oriented network
interfaces. (Non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second.)"
::= { ifGroups 4 }
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to high speed (greater than 20,000,000
bits/second but less than or equal to 650,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 5 }
ifVHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
ifHCInBroadcastPkts, ifHCOutUcastPkts,
ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to higher speed (greater than 650,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 6 }the speed tiers in this section are everything 🌈 the five groups marked as mutually exclusive are sorted by two things: whether the interface is character-oriented or packet-oriented, and whether it's non-high speed (up to 20,000,000 bits/second), high speed (up to 650,000,000), or higher speed 💖 the HC ones are the 64-bit counter crew, and ifVHCPacketGroup is the VIP for anything above 650,000,000 bits/second 👑
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
ifTestGroup OBJECT-GROUP
OBJECTS { ifTestId, ifTestStatus, ifTestType,
ifTestResult, ifTestCode, ifTestOwner }
STATUS current
DESCRIPTION
"A collection of objects providing the ability to
invoke tests on an interface."
::= { ifGroups 8 }
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 9 }
END7. Acknowledgements ✨
okay so this memo was cooked up by the IETF's Interfaces MIB Working Group 🫶
the initial proposal to the working group came out of conversations and discussions with lots of people, including at least the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop 💜
8. References 📚
- [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
- [2] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993.
- [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
- [4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991.
- [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
- [6] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
- [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, May 1991.
- [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
9. Security Considerations 💀
no cap, security issues are not discussed in this memo 😭
10. Authors' Addresses 🧚
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Rd,
Mountain View, Ca 94043
Phone: 415-966-7934
EMail: kzm@hls.comFrank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
Phone: (508)685-4000
EMail: kasten@ftp.com📦 where this page comes from
- ietf: rfc1573 1994-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms