what is the story on if_index allocation ?

Petri Helenius pete at he.iki.fi
Tue Apr 20 23:53:42 PDT 2004

Luigi Rizzo wrote:

>I do not think the current code supports this, as any free
>index at the top of the array is reused. So if you had 'vlan12' there
>and it went away, the next interface that comes in will grab that
>index and vlan12 will get a new one. On top of this you can rename
>interfaces without changing the index, you can change MAC and IP
>addresses, in the already mentioned case of a tunnel server
>there is basically no relation between successive creations on
>the same interface.
>My feeling is that there is not even a sensible way to specify
>how one would like to retain the mapping of indexes, let alone
>the fact that the specification changes depending on whom you
>ask. When this happens, it is a good hint to move the issue
>outside the kernel.
Relevant quote from the RFC:

   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.  The exact meaning of a
   "different" interface is hard to define, and there will be gray
   areas.  Any firm definition in this document would likely turn out to
   be inadequate.  Instead, implementors must choose what it means in
   their particular situation, subject to the following rules:

McCloghrie & Kastenholz     Standards Track                    [Page 11]
RFC 2863                The Interfaces Group MIB               June 2000

   (1)   a previously-unused value of ifIndex must be assigned to a
         dynamically added interface if an agent has no knowledge of
         whether the interface is the "same" or "different" to a
         previously incarnated interface.

   (2)   a management station, not noticing that an interface has gone
         away and another has come into existence, must not be confused
         when calculating the difference between the counter values
         retrieved on successive polls for a particular ifIndex value.

   When the new interface is the same as an old interface, but a
   discontinuity in the value of the interface's counters cannot be
   avoided, the ifTable has (until now) required that a new ifIndex
   value be assigned to the returning interface.  That is, either all
   counter values have had to be retained during the absence of an
   interface in order to use the same ifIndex value on that interface's
   return, or else a new ifIndex value has had to be assigned to the
   returning interface.  Both alternatives have proved to be burdensome
   to some implementations:

   (1)   maintaining the counter values may not be possible (e.g., if
         they are maintained on removable hardware),

   (2)   using a new ifIndex value presents extra work for management
         applications.  While the potential need for such extra work is
         unavoidable on agent re-initializations, it is desirable to
         avoid it between re-initializations.


More information about the freebsd-net mailing list