RFC 1158

Management Information Base for network management of TCP/IP-based internets: MIB-II

📅 published May 1990, from ietf

RFC 1158 🎀

This one is Management Information Base for Network Management of TCP/IP-based internets: MIB-II 💜 It's from the Network Working Group, written by M. Rose, Editor, at Performance Systems International, dated May 1990. It's a Proposed Standard 🌸 The text doesn't state an obsoletes or updates line. What it does say is that MIB-II builds on and extends RFC 1156 (MIB-I) without loss of compatibility, so it's basically MIB-I's glow-up ✨

1. Status of this Memo ✨

Okay so this memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets 🦋 It works together with its companion memos: RFC 1155 describes the structure of management information, and RFC 1157 is the network management protocol for TCP/IP-based internets. Bestie, these three together give you a simple, workable architecture for managing TCP/IP-based internets, and especially the Internet community 💖

MIB-II includes everything technical from RFC 1156 on MIB-I and extends it without loss of compatibility 🫶 But here's the tea: MIB-I as described in RFC 1156 is a full Standard Protocol of the Internet, while the MIB-II described here is a Proposed Standard Protocol of the Internet 👑

This memo defines a mandatory extension to the base MIB (RFC 1156) and is a Proposed Standard for the Internet community 💅 The extensions here are currently Elective, but once they become a standard they'll have the same status as RFC 1156, which is Recommended 🌈 The Internet Activities Board (IAB) recommends that all IP and TCP implementations be network manageable. That means implementing the Internet MIB (RFC 1156 plus the extensions in RFC 1158) and at least one of the two recommended management protocols, SNMP (RFC 1157) or CMOT (RFC 1095) 🍓

This version, MIB-II, is an incremental refinement of MIB-I 🧚 It was designed around two criteria. First, changes were made in response to new operational requirements in the Internet. Second, the changes are entirely upwards compatible, so the network's managed nodes can move from MIB-I to MIB-II without a big disruption 🌸

More MIB groups and variables are expected to be defined over time, so the monitoring and control needs of new or changing parts of the Internet can be covered ⭐

Please check the latest edition of the "IAB Official Protocol Standards" RFC for the current state and status of standard Internet protocols 🔥

Distribution of this memo is unlimited 🦋

Table of Contents ✨

   1. Status of this Memo ..................................    1
   2. Introduction .........................................    3
   3. Changes from MIB-I ...................................    4
   3.1 Deprecated Objects ..................................    4
   3.2 Display Strings .....................................    5
   3.3 The System Group ....................................    5
   3.4 The Interfaces Group ................................    5
   3.5 The Address Translation Group .......................    6
   3.6 The IP Group ........................................    7
   3.7 The ICMP Group ......................................    7
   3.8 The TCP Group .......................................    7
   3.9 The UDP Group .......................................    7
   3.10 The EGP Group ......................................    8
   3.11 The Transmission Group .............................    8
   3.12 The SNMP Group .....................................    8
   4. Objects ..............................................    8
   4.1 Object Groups .......................................    9
   4.2 Format of Definitions ...............................   10
   5. Object Definitions ...................................   10
   5.1 The System Group ....................................   11
   5.2 The Interfaces Group ................................   14
   5.2.1 The Interfaces table ..............................   15
   5.3 The Address Translation Group .......................   27
   5.4 The IP Group ........................................   30
   5.4.1 The IP Address table ..............................   38
   5.4.2 The IP Routing table ..............................   41
   5.4.3 The IP Address Translation table ..................   48
   5.5 The ICMP Group ......................................   51
   5.6 The TCP Group .......................................   61
   5.6.1 The TCP Connection table ..........................   66
   5.6.2 Additional TCP Objects ............................   69
   5.7 The UDP Group .......................................   70
   5.7.1 The UDP Listener table ............................   72
   5.8 The EGP Group .......................................   73
   5.8.1 The EGP Neighbor table ............................   75
   5.8.2 Additional EGP variables ..........................   83
   5.9 The Transmission Group ..............................   83
   5.10 The SNMP Group .....................................   83
   6. Definitions ..........................................   95
   7. Identification of OBJECT instances for use with  the
      SNMP .................................................  126
   7.1 ifTable Object Type Names ...........................  127
   7.2 atTable Object Type Names ...........................  127
   7.3 ipAddrTable Object Type Names .......................  128
   7.4 ipRoutingTable Object Type Names ....................  128
   7.5 ipNetToMediaTable Object Type Names .................  129
   7.6 tcpConnTable Object Type Names ......................  129
   7.7 udpTable Object Type Names ..........................  130
   7.8 egpNeighTable Object Type Names .....................  130
   8.  Acknowledgements ....................................  130
   9.  References ..........................................  131
   10. Security Considerations..............................  133
   11. Author's Address.....................................  133

2. Introduction 🌷

As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], there was a two-prong strategy for network management of TCP/IP-based internets 💅 In the short term, the Simple Network Management Protocol (SNMP) was to be used to manage nodes in the Internet community. In the long term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI) [2], and RFC 1066, which defined the Management Information Base (MIB) [3]. Both were designed to be compatible with both SNMP and the OSI network management framework 🫶

This strategy was a huge success in the short term 🔥 Internet-based network management technology was fielded by both the research and commercial communities within a few months. Because of this, parts of the Internet community became network manageable in a timely fashion 🦋

As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [4], the requirements of the SNMP and the OSI network management frameworks turned out to be more different than anyone anticipated 🙈 So the requirement for compatibility between the SMI/MIB and both frameworks was suspended. That let the operational network management framework, SNMP, respond to new operational needs in the Internet community by producing this document ✨

So the current network management framework for TCP/IP-based internets is made of three pieces 🧚 First, Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [13], which describes how managed objects in the MIB are defined. Second, this memo, Management Information Base for Network Management of TCP/IP-based internets (version 2), which describes the managed objects contained in the MIB. Third, the Simple Network Management Protocol, RFC 1157 [14], which defines the protocol used to manage these objects 💜

Consistent with the IAB directive to produce simple, workable systems in the short term, the list ofc objects (e.g., for BSD UNIX) were excluded.

It was agreed to avoid heavily instrumenting critical sections of code. The general guideline was one counter per critical section per layer.

Heads up, bestie: the source text jumps straight from that sentence to item "7)" here, so the earlier items in that list seem to be missing from the document as provided. I've kept what's there exactly as it appears.

3. Changes from MIB-I 🍓

Features of this MIB include:

incremental additions to reflect new operational requirements;
upwards compatibility with the SMI/MIB and the SNMP;
improved support for multi-protocol entities; and,
textual clean-up of the MIB to improve clarity and readability.

The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:

               mib-2      OBJECT IDENTIFIER ::= { mgmt 1 }

3.1. Deprecated Objects 🌸

To better prepare implementors for future changes to the MIB, a new term, "deprecated", may be used when describing an object 🧚 A deprecated object in the MIB is one which must be supported, but which will most likely be removed from the next version of the MIB (e.g., MIB-III).

MIB-II marks one object as being deprecated: atTable 💅

As a result of deprecating the atTable object, the entire Address Translation group is deprecated 🥀

Note that no functionality is lost with the deprecation of these objects: new objects providing equivalent or superior functionality are defined in MIB-II ✨

3.2. Display Strings 🦋

In the past there have been misinterpretations of the MIB about when a string of octets should contain printable characters meant to be displayed to a human 🙈 To fix that, a textual convention is introduced in the MIB, the datatype:

                  DisplayString ::= OCTET STRING

A DisplayString is restricted to the NVT ASCII character set, as defined on pages 10-11 of [7] 🫶

The following objects are now defined in terms of DisplayString:

sysDescr
ifDescr

It should be noted that this change has no effect on either the syntax or the semantics of these objects. Using the DisplayString notation is just an artifact of the explanatory method used in MIB-II and future MIBs 💖

Further, it should be noted that any object defined in terms of OCTET STRING may contain arbitrary binary data, in which each octet may take any value from 0 to 255 (decimal) 🌈

3.3. The System Group ⭐

Four new objects are added to this group:

                  sysContact
                  sysName
                  sysLocation
                  sysServices

These provide contact, administrative, location, and service information about the managed node 🎀

3.4. The Interfaces Group 🔥

The definition of the ifNumber object was incorrect, because it required all interfaces to support IP. For example, devices without IP, such as MAC-layer bridges, could not be managed if this definition was strictly followed. The description of the ifNumber object has been changed accordingly 👑

The ifTable object was mistakenly marked as read-write. It has been (correctly) re-designated as read-only 💅 In addition, several new values have been added to the ifType column in the ifTable object:

                  ppp(23)
                  softwareLoopback(24)
                  eon(25)
                  ethernet-3Mbit(26)
                  nsip(27)
                  slip(28)

Finally, a new column has been added to the ifTable object:

                  ifSpecific

It provides information about the media being used to realize the interface 🧚

3.5. The Address Translation Group 🗺️

okay so in MIB-I, this group had a table that let you map network addresses (like IP addresses) to physical addresses (like MAC addresses) 🌸. Experience showed that efficient implementations of this table were quietly making two assumptions: there's only a single network protocol environment, and mappings only ever go from network address to physical address.

Those two assumptions got wrecked 💀. Multi-protocol nodes (like ones running both IP and CLNP at once) and the need for the inverse mapping (like for ES-IS) both showed up, so the atTable object is now declared deprecated 🥀.

So MIB-II and its successors will allocate up to two address translation tables inside each network protocol group 🦋. The IP group gets one table for going from IP addresses to physical addresses. Same deal for CLNP: when a document defining MIB objects for the CLNP is produced (e.g., [8]), it will contain two tables, one for each direction, because that's required for full functionality ✨.

Also, choosing two tables (one per direction of mapping) is easier to implement in many cases, and it doesn't put undue burden on implementations that handle the address translation abstraction with a single internal table 💅.

3.6. The IP Group 🌈

The access attribute of the variable ipForwarding has been changed from read-only to read-write 🔥.

There's also a new column in the ipAddrTable object:

ipAdEntReasmMaxSize

which keeps track of the largest IP datagram that can be re-assembled on a particular interface 📦. And there's a new column in the ipRoutingTable object:

ipRouteMask

which is used by IP routing subsystems that support arbitrary subnet masks 🎀.

One new object is added to the IP group:

ipNetToMediaTable

It's the address translation table for the IP group, giving you identical functionality to the now deprecated atTable in the address translation group 🫶.

3.7. The ICMP Group 🧚

There are no changes to this group 🤷‍♀️.

3.8. The TCP Group 💜

Two new variables are added:

tcpInErrs
tcpOutRsts

They keep track of the number of incoming TCP segments in error, and the number of resets generated by a TCP 🚨.

3.9. The UDP Group 🍓

A new table:

udpTable

is added ✨.

3.10. The EGP Group 🛰️

Experience has shown a need for more objects that are useful in EGP monitoring 👀. On top of several additions to the egpNeighborTable object, a new variable is added:

egpAs

which gives the autonomous system associated with this EGP entity 👑.

3.11. The Transmission Group 📡

MIB-I was lacking because it didn't distinguish between different types of transmission media 😤. So a new group, the Transmission group, is allocated for this purpose:

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

When Internet-standard definitions for managing transmission media are defined, the transmission group is used to provide a prefix for the names of those objects 💖.

Typically, those definitions live in the experimental portion of the MIB until they're "proven." Then, as part of the Internet standardization process, they get elevated and a new object identifier under the transmission group is defined. By convention, the name assigned is:

type OBJECT IDENTIFIER    ::= { transmission number }

where "type" is the symbolic value used for the media in the ifType column of the ifTable object, and "number" is the actual integer value corresponding to that symbol 🧠.

3.12. The SNMP Group 📊

The application-oriented working groups of the IETF have been tasked with being receptive to defining MIB variables specific to their respective applications 🙌.

For SNMP, statistical information is useful, so a new group, the SNMP group, is allocated for this purpose:

snmp   OBJECT IDENTIFIER ::= { mib-2 11 }

4. Objects 🧩

Managed objects are accessed via a virtual information store, called the Management Information Base, or MIB 🗂️. Objects in the MIB are defined using Abstract Syntax Notation One (ASN.1) [9].

The mechanisms for describing these objects are specified in the companion memo, the SMI. Each object has a name, a syntax, and an encoding 🔍. The name is an object identifier, an administratively assigned name that specifies an object type. The object type together with an object instance uniquely identifies a specific instantiation of the object. For human convenience, we often use a textual string, called the OBJECT DESCRIPTOR, to also refer to the object type 🫶.

The syntax of an object type defines the abstract data structure for that object type, and ASN.1 is used for this purpose. However, the companion memo purposely restricts which ASN.1 constructs may be used, and those restrictions are made explicitly for simplicity 💅.

The encoding of an object type is simply how that object type is represented using its syntax. Implicitly tied to the syntax and encoding is how the object type is represented when it's transmitted on the network. This memo specifies the use of the basic encoding rules (BER) of ASN.1 [10], subject to the additional requirements imposed by the SNMP [14] 🔐.

4.1. Object Groups 🗃️

Since this list of managed objects contains only the essential elements, there's no need to allow individual objects to be optional. Instead, the objects are arranged into the following groups:

System
Interfaces
Address Translation (deprecated)
IP
ICMP
TCP
UDP
EGP
Transmission
SNMP

There are two reasons for defining these groups. One is to provide a means of assigning object identifiers. The other is to give implementations of managed agents a method for knowing which objects they must implement 🎯. That method works like this: if the semantics of a group are applicable to an implementation, then it must implement all objects in that group. For example, an implementation must implement the EGP group if and only if it implements the EGP 🙈.

4.2. Format of Definitions 📝

The next section contains the specification of all object types in the MIB. Following the conventions of the companion memo, the object types are defined using the following fields 🪄:

OBJECT: A textual name, called the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER.

Syntax: The abstract syntax for the object type, presented using ASN.1. This must resolve to an instance of the ASN.1 type ObjectSyntax defined in the SMI.

Definition: A textual description of the semantics of the object type. Implementations should ensure that their interpretation of the object type fulfills this definition, since this MIB is intended for use in multi-vendor environments. So it's vital that object types have consistent meaning across all machines 🌍.

Access: A keyword, one of read-only, read-write, write-only, or not-accessible. This designation specifies the minimum level of support required. As a local matter, implementations may support other access types (e.g., an implementation may elect to permit writing a variable marked herein as read-only). Further, protocol-specific "views" (e.g., those implied by an SNMP community) may make further restrictions on access to a variable 🔒.

Status: A keyword, one of mandatory, optional, obsolete, or deprecated. Use of deprecated implies mandatory status 🥹.

5. Object Definitions 📜

               RFC1158-MIB

               DEFINITIONS ::= BEGIN
               IMPORTS
                       mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,
                       Counter, Gauge, TimeTicks
                           FROM RFC1155-SMI;

               DisplayString ::=
                           OCTET STRING


               mib-2      OBJECT IDENTIFIER ::= { mgmt 1 }    -- MIB-II

               system     OBJECT IDENTIFIER ::= { mib-2 1 }
               interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
               at         OBJECT IDENTIFIER ::= { mib-2 3 }
               ip         OBJECT IDENTIFIER ::= { mib-2 4 }
               icmp       OBJECT IDENTIFIER ::= { mib-2 5 }
               tcp        OBJECT IDENTIFIER ::= { mib-2 6 }
               udp        OBJECT IDENTIFIER ::= { mib-2 7 }
               egp        OBJECT IDENTIFIER ::= { mib-2 8 }
               -- cmot    OBJECT IDENTIFIER ::= { mib-2 9 }
               transmission OBJECT IDENTIFIER ::= { mib-2 10 }
               snmp       OBJECT IDENTIFIER ::= { mib-2 11 }
               END

5.1. The System Group

Okay bestie, the System group is mandatory for all systems 💅 so every box needs this one. 🎀

OBJECT:
-------
     sysDescr { system 1 }

Syntax:
     DisplayString (SIZE (0..255))

sysDescr is basically the box's bio ✨ It's a textual description of the entity, and it should spill the full name and version of the system's hardware type, operating system, and networking software. It is mandatory that this only contains printable ASCII characters 🙈

Access: read-only Status: mandatory

OBJECT:
-------
     sysObjectID { system 2 }

Syntax:
     OBJECT IDENTIFIER

sysObjectID is the vendor's official ID for the network management subsystem inside the entity, and it's giving "what kind of box is this" 🦋 It's allocated within the SMI enterprises subtree (1.3.6.1.4.1), which makes it easy and unambiguous to tell what you're managing. For example, if the vendor "Flintstones, Inc." was assigned the subtree 1.3.6.1.4.1.4242, it could give its "Fred Router" the identifier 1.3.6.1.4.1.4242.1.1 🪨

Access: read-only Status: mandatory

OBJECT:
-------
     sysUpTime { system 3 }

Syntax:
     TimeTicks

sysUpTime counts the time, in hundredths of a second, since the network management portion of the system was last re-initialized ⏱️ Main character timer energy 👑

Access: read-only Status: mandatory

OBJECT:
-------
     sysContact { system 4 }

Syntax:
     DisplayString (SIZE (0..255))

sysContact is the textual identification of the contact person for this managed node, plus info on how to reach them 📞 Basically the "who do I text when this breaks" slot 🫶

Access: read-write Status: mandatory

OBJECT:
-------
     sysName { system 5 }

Syntax:
     DisplayString (SIZE (0..255))

sysName is an administratively-assigned name for this managed node. By convention, it's the node's fully-qualified domain name 🌈 Very organised, very iconic.

Access: read-write Status: mandatory

OBJECT:
-------
     sysLocation { system 6 }

Syntax:
     DisplayString (SIZE (0..255))

sysLocation is the physical location of the node, like "telephone closet, 3rd floor" 🧚 Honestly the most relatable one on this list.

Access: read-only Status: mandatory

OBJECT:
-------
     sysServices { system 7 }

Syntax:
     INTEGER (0..127)

okay this one is a little math, but I promise it's cute 🧮 sysServices is a value that shows the set of services this entity potentially offers. It's a sum! It starts at zero, and then for each layer, L, from 1 through 7 that the node does transactions for, you add 2 raised to (L - 1) 💖 For example, a node that only does routing would be 4 (2^(3-1)), and a host offering application services would be 72 (2^(4-1) + 2^(7-1)) 😭 That's the kind of math I'm obsessed with.

When it comes to the Internet suite of protocols, you should calculate the values like this 🌸

    layer  functionality
    1      physical (e.g., repeaters)
    2      datalink/subnetwork (e.g., bridges)
    3      internet (e.g., supports the IP)
    4      end-to-end  (e.g., supports the TCP)
    7      applications (e.g., supports the SMTP)

And if the system includes OSI protocols, layers 5 and 6 may also be counted ✨

Access: read-only Status: mandatory

5.2. The Interfaces Group

Implementation of the Interfaces group is mandatory for all systems, so no skipping this one 🫶

OBJECT:
-------
     ifNumber { interfaces 1 }

Syntax:
     INTEGER

ifNumber is the number of network interfaces on this system, and it counts them regardless of their current state 🔢

Access: read-only Status: mandatory

5.2.1. The Interfaces table

Okay so the Interfaces table holds info on the entity's interfaces 🎀 Each interface is thought of as being attached to a "subnetwork". Quick heads up, don't mix this up with "subnet", which is an addressing partitioning scheme used in the Internet suite of protocols 🙈 Two very different vibes.

OBJECT:
-------
     ifTable { interfaces 2 }

Syntax:
     SEQUENCE OF IfEntry

ifTable is the list of interface entries. The number of entries is given by the value of ifNumber 📋

Access: read-only Status: mandatory

OBJECT:
-------
     ifEntry { ifTable 1 }

Syntax:
     IfEntry ::= SEQUENCE {
          ifIndex
              INTEGER,
          ifDescr
              DisplayString,
          ifType
              INTEGER,
          ifMtu
              INTEGER,
          ifSpeed
              Gauge,
          ifPhysAddress
              OCTET STRING,
          ifAdminStatus
              INTEGER,
          ifOperStatus
              INTEGER,
          ifLastChange
              TimeTicks,
          ifInOctets
              Counter,
          ifInUcastPkts
              Counter,
          ifInNUcastPkts
              Counter,
          ifInDiscards
              Counter,
          ifInErrors
              Counter,
          ifInUnknownProtos
              Counter,
          ifOutOctets
              Counter,
          ifOutUcastPkts
              Counter,
          ifOutNUcastPkts
              Counter,
          ifOutDiscards
              Counter,
          ifOutErrors
              Counter,
          ifOutQLen
              Gauge,
          ifSpecific
              OBJECT IDENTIFIER
     }

An ifEntry is an interface entry with objects at the subnetwork layer and below, for one particular interface 🦋

Access: read-only Status: mandatory

We now consider the individual components of each interface entry 👀

OBJECT:
-------
     ifIndex { ifEntry 1 }

Syntax:
     INTEGER

ifIndex is a unique value for each interface. It ranges between 1 and the value of ifNumber 🔑 The value for each interface must stay constant, at least from one re-initialization of the entity's network management system to the next re-initialization. Stability is everything 💅

Access: read-only Status: mandatory

OBJECT:
-------
     ifDescr { ifEntry 2 }

Syntax:
     DisplayString (SIZE (0..255))

ifDescr is a textual string with info about the interface. It should include the manufacturer's name, the product name, and the version of the hardware interface 🏷️

Access: read-only Status: mandatory

OBJECT:
-------
     ifType { ifEntry 3 }

Syntax:
     INTEGER {
          other(1),          -- none of the following
          regular1822(2),
          hdh1822(3),
          ddn-x25(4),
          rfc877-x25(5),
          ethernet-csmacd(6),
          iso88023-csmacd(7),
          iso88024-tokenBus(8),
          iso88025-tokenRing(9),
          iso88026-man(10),
          starLan(11),
          proteon-10Mbit(12),
          proteon-80Mbit(13),
          hyperchannel(14),
          fddi(15),
          lapb(16),
          sdlc(17),
          t1-carrier(18),
          cept(19),          -- european equivalent of T-1
          basicISDN(20),
          primaryISDN(21),
                              -- proprietary serial
          propPointToPointSerial(22),
          ppp(23),
          softwareLoopback(24),
          eon(25),            -- CLNP over IP [12]
          ethernet-3Mbit(26)
          nsip(27),           -- XNS over IP
          slip(28)            -- generic SLIP
     }

ifType is the type of interface, sorted by the physical or link protocol(s) sitting right "below" the network layer in the stack 🧩 So many flavours, it's giving buffet 🍓

Access: read-only Status: mandatory

OBJECT:
-------
     ifMtu { ifEntry 4 }

Syntax:
     INTEGER

ifMtu is the size of the largest datagram that can be sent or received on the interface, in octets 📦 For interfaces used to transmit network datagrams, it's the size of the biggest one that can go out on that interface 🚀

Access: read-only Status: mandatory

OBJECT:
-------
     ifSpeed { ifEntry 5 }

Syntax:
     Gauge

ifSpeed is an estimate of the interface's current bandwidth in bits per second ⚡ For interfaces whose bandwidth doesn't change, or where no accurate estimate can be made, this should hold the nominal bandwidth 💜

Access: read-only Status: mandatory

OBJECT:
-------
     ifPhysAddress { ifEntry 6 }

Syntax:
     OCTET STRING

ifPhysAddress is the interface's address at the protocol layer right "below" the network layer 🪪 If the interface doesn't have an address like that (a serial line, for example), this should be an octet string of zero length 🫧

Access: read-only Status: mandatory

OBJECT:
-------
     ifAdminStatus { ifEntry 7 }

Okay so picking up right where the ifAdminStatus stuff left off 💖

Syntax:
     INTEGER {
          up(1),       -- ready to pass packets
          down(2),
          testing(3)   -- in some test mode
     }

Definition: This is the state the interface is supposed to be in ✨. Also, testing(3) means no operational packets can pass, so keep that in mind 🙈

Access: read-write. Status: mandatory. 🫶

ifOperStatus { ifEntry 8 } 🦋

Syntax:
     INTEGER {
          up(1),       -- ready to pass packets
          down(2),
          testing(3)   -- in some test mode
     }

Definition: This is the current operational state of the interface, aka what it's actually doing right now 👑. Again, testing(3) means no operational packets can be passed.

Access: read-only. Status: mandatory. 💅

ifLastChange { ifEntry 9 } ⏱️

Syntax:
     TimeTicks

Definition: This is the value of sysUpTime at the moment the interface entered its current operational state. Tea ☕ If the current state was entered before the last re-initialization of the local network management subsystem, this object holds a zero value, so it's giving reset energy 🌸

Access: read-only. Status: mandatory. ✨

ifInOctets { ifEntry 10 } 🍓

Syntax:
     Counter

Definition: The total number of octets received on the interface, including framing characters. Literally every byte 🧚

Access: read-only. Status: mandatory. 💖

ifInUcastPkts { ifEntry 11 } 🎀

Syntax:
     Counter

Definition: The number of subnetwork-unicast packets that got delivered to a higher-layer protocol. Delivered = it made it, bestie 💌

Access: read-only. Status: mandatory. 🌈

ifInNUcastPkts { ifEntry 12 } 📣

Syntax:
     Counter

Definition: The number of non-unicast packets delivered to a higher-layer protocol. Non-unicast means (i.e., subnetwork-broadcast or subnetwork-multicast) 🔊

Access: read-only. Status: mandatory. 🦋

ifInDiscards { ifEntry 13 } 🗑️

Syntax:
     Counter

Definition: The number of inbound packets that were chosen to be discarded, even though no errors had been detected to stop them being deliverable to a higher-layer protocol. Why would you do that? One possible reason is to free up buffer space 🧹 Lowkey iconic of it 🙈

Access: read-only. Status: mandatory. 💅

ifInErrors { ifEntry 14 } 💀

Syntax:
     Counter

Definition: The number of inbound packets that had errors preventing them from being deliverable to a higher-layer protocol. Big oof 😭

Access: read-only. Status: mandatory. ✨

ifInUnknownProtos { ifEntry 15 } ❓

Syntax:
     Counter

Definition: The number of packets received via the interface that were discarded because of an unknown or unsupported protocol. Not it 🙅‍♀️

Access: read-only. Status: mandatory. 🫶

ifOutOctets { ifEntry 16 } 📤

Syntax:
     Counter

Definition: The total number of octets transmitted out of the interface, including framing characters. Every single byte going out, periodt 💅

Access: read-only. Status: mandatory. 🌸

ifOutUcastPkts { ifEntry 17 } 🎀

Syntax:
     Counter

Definition: The total number of packets that higher-level protocols asked to be transmitted to a subnetwork-unicast address, including the ones that were discarded or not sent. Asking counts, even if it didn't go through 🥺

Access: read-only. Status: mandatory. 💖

ifOutNUcastPkts { ifEntry 18 } 📢

Syntax:
     Counter

Definition: The total number of packets that higher-level protocols asked to be transmitted to a non-unicast address (i.e., a subnetwork-broadcast or subnetwork-multicast address), including the discarded or not-sent ones too 🌈

Access: read-only. Status: mandatory. ✨

ifOutDiscards { ifEntry 19 } 🗑️

Syntax:
     Counter

Definition: The number of outbound packets that were chosen to be discarded, even though no errors had been detected to stop them being transmitted. Same energy as ifInDiscards: one possible reason is to free up buffer space 🧹

Access: read-only. Status: mandatory. 👑

ifOutErrors { ifEntry 20 } 😭

Syntax:
     Counter

Definition: The number of outbound packets that could not be transmitted because of errors. Rough day 💀

Access: read-only. Status: mandatory. 🫶

ifOutQLen { ifEntry 21 } 📏

Syntax:
     Gauge

Definition: The length of the output packet queue, measured in packets. Basically how long the line is 🧚

Access: read-only. Status: mandatory. 🦋

ifSpecific { ifEntry 22 } 🔍

Syntax:
     OBJECT IDENTIFIER

Definition: This is a reference to the MIB definitions specific to whatever media is realizing the interface. For example, if the interface is realized by an ethernet, this object points to a document defining ethernet-specific objects 🧃 If an agent isn't configured with a value for any of these variables, the object identifier below gets returned:

nullSpecific OBJECT IDENTIFIER ::= { 0 0 }

Note that "nullSpecific" is syntactically valid (it's a legit OID, no cap). Any conformant implementation of ASN.1 and BER must be able to generate and recognize this value 🎀

Access: read-only. Status: mandatory. 💅

5.3. The Address Translation Group ✨

Implementation of the Address Translation group is mandatory for all systems. Note however that this group is deprecated by MIB-II. That is, it's only being included for compatibility with MIB-I nodes, and will most likely be excluded from MIB-III nodes. From MIB-II onward, each network protocol group has its own address translation tables 🌸

The Address Translation group contains one table, which is the union across all interfaces of the translation tables for converting a NetworkAddress (e.g., an IP address) into a subnetwork-specific address. For lack of a better term, this document calls such a subnetwork-specific address a "physical" address 🫶

Examples of these translation tables: for broadcast media where ARP is in use, the translation table is equivalent to the ARP cache. Or, on an X.25 network where non-algorithmic translation to X.121 addresses is required, the translation table holds the NetworkAddress to X.121 address equivalences 🦋

atTable { at 1 } 🗺️

Syntax:
     SEQUENCE OF AtEntry

Definition: The Address Translation tables hold the NetworkAddress to "physical" address equivalences. Some interfaces don't use translation tables to determine address equivalences (e.g., DDN-X.25 has an algorithmic method). If all interfaces are this type, the Address Translation table is empty, i.e., has zero entries 🙈

Access: read-write. Status: deprecated. 💀

atEntry { atTable 1 } 🧩

Syntax:
     AtEntry ::= SEQUENCE {
          atIfIndex
              INTEGER,
          atPhysAddress
              OCTET STRING,
          atNetAddress
              NetworkAddress
     }

Definition: Each entry holds one NetworkAddress to "physical" address equivalence 💖

Access: read-write. Status: deprecated. ✨

Now let's look at the individual pieces of each Address Translation table entry 👀

atIfIndex { atEntry 1 } 🔢

Syntax:
     INTEGER

Definition: The interface where this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface identified by the same value of ifIndex 🎀

Access: read-write. Status: deprecated. 🌈

atPhysAddress { atEntry 2 } 🔌

Syntax:
     OCTET STRING

Definition: The media-dependent "physical" address.

Setting this object to a null string (one of zero length) has the effect of invalidating the corresponding entry in the atTable object. Basically it disassociates the interface from that entry's mapping 💀 Whether the agent actually removes an invalidated entry from the table is an implementation-specific matter. So management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. To properly interpret such entries, you have to check the relevant atPhysAddress object 🕵️‍♀️

Access: read-write. Status: deprecated. 😭

atNetAddress { atEntry 3 } 🌐

Syntax:
     NetworkAddress

Definition: The NetworkAddress (e.g., the IP address) corresponding to the media-dependent "physical" address 💜

Access: read-write. Status: deprecated. 🫶

5.4. The IP Group ✨

bestie, the IP group is mandatory for all systems 💅 no exceptions, so every single box has to have it 🫶

ipForwarding 🦋

OBJECT:
-------
     ipForwarding { ip 1 }

Syntax:
     INTEGER {
          forwarding(1),    -- i.e., acting as a gateway
          not-forwarding(2) -- i.e., NOT acting as a gateway
     }

okay so this one tells you whether the entity is acting as an IP gateway, meaning whether it forwards the datagrams it receives that aren't addressed to it. gateways forward 🚀 hosts don't, except for the ones that get source-routed through the host 👀

Access: read-write. Status: mandatory.

ipDefaultTTL 🌸

OBJECT:
-------
     ipDefaultTTL { ip 2 }

Syntax:
     INTEGER

this is the default value that goes into the Time-To-Live field of the IP header for datagrams this entity starts itself 💖 it only kicks in when the transport layer protocol doesn't hand over a TTL value of its own 🧚

Access: read-write. Status: mandatory.

ipInReceives 💜

OBJECT:
-------
     ipInReceives { ip 3 }

Syntax:
     Counter

the total count of input datagrams that came in from the interfaces ✨ this includes the ones that showed up with errors too, so nothing gets quietly left out 😭