CODEWITHSUNDEEP
snmpmibnetwork-interface
U. Windl
U. Windl

Reputation: 4325

What is the meaning of SNMP's IF-MIB::ifIndex in IF-MIB::ifTable?

I wonder: I have a device that has following SNMP MIB entries:

IF-MIB::ifNumber.0 = INTEGER: 46
IF-MIB::ifIndex.805306369 = INTEGER: 805306369
IF-MIB::ifIndex.805306370 = INTEGER: 805306370
....
IF-MIB::ifIndex.1073741861 = INTEGER: 1073741861
IF-MIB::ifIndex.1073741862 = INTEGER: 1073741862
IF-MIB::ifIndex.1073741863 = INTEGER: 1073741863

snmptranslate -IR -Td ifIndex says:

IF-MIB::ifIndex
ifIndex OBJECT-TYPE
  -- FROM   IF-MIB
  -- TEXTUAL CONVENTION InterfaceIndex
  SYNTAX    Integer32 (1..2147483647) 
  DISPLAY-HINT  "d"
  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."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) interfaces(2) ifTable(2) ifEntry(1) 1 }

But I really fail to understand what the meaning of F-MIB::ifIndex.805306369 = INTEGER: 805306369 is. My expectation is that the first number should be starting from one, mapping a logical number to some physical number.

My guess is that some implementers also didn't understand what it should do ;-)

Reading RFC 2863 (or RFC 2233), the situation becomes confusing even more: "Its value ranges between 1 and the value of ifNumber. (...)"

"The solution adopted in this memo is just to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition."

"This solution also results in the possibility of "holes" in the ifTable, i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous, but SNMP's GetNext (and GetBulk) operation easily deals with such holes."

"The requirement for constancy (between re-initializations) of an interface's ifIndex value 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 for assignment (in advance) of ifIndex values for all possible interfaces that might be added dynamically."

I think part of the confusion arises from "value of ifIndex", where it's unclear whether it refers to the left side or the right side (IMHO it's the right side). Is the left side an unique primary key to the index table and the right side just an arbitrary dummy value, or what? Maybe the major design flaw is that interface data should be accessed by a unique interface name, and not by an index that may change from time to time (the index could still be used to enumerate the available names).

Upvotes: 0

Views: 4603

Answers (2)

Michael Kirkham
Michael Kirkham

Reputation: 1070

ifIndex is just an arbitrary but unique number differentiating one interface from another in any table that identifies interfaces by (has an INDEX of) ifIndex. How they are assigned is up to the implementation.

It is always the case that when you have an INDEX object that is readable (MAX-ACCESS is a value other than not-accessible), the value of the object (the "right side" as you put it in your question) is equal to the value encoded into the instance identifiers (the left side). That is, ifIndex.X = X, always, because ifIndex is the INDEX for ifIndex, itself (X = value of ifIndex). This is true for any object X where X is an INDEX for X. For this reason, SMIv2 states that INDEX objects are to have MAX-ACCESS not-accessible unless there are no other readable (accessible) columns in the table: their value can always be obtained from the instance identifiers, so having the column be readable is superfluous.

SMIv1 did not have this rule, which is why you will see readable indexes sometimes in SMIv1 modules or, as in ifIndex's case, SMIv2 modules that were originally written as SMIv1 modules, where changing the INDEX to not-accessible would have broken compatibility and broken the IETF's rules for allowable modifications to standard MIBs.

Upvotes: 1

Gambit Support
Gambit Support

Reputation: 1463

There are no limitations to the semantics of the ifIndex, especially that it should make sense to a human, else they would be explicitely spelled out in the RFC. Notice it says "recommended", not "required".

Some SNMP agents directly map logical network interfaces (VLANs, tunnels, etc) with instance numbers that make no sense to humans. It just means your management software has to deal with non-contiguous indices.

Upvotes: 1

Related Questions