Date: Wed, 21 Apr 2004 09:53:37 +0300 From: Petri Helenius <pete@he.iki.fi> To: Luigi Rizzo <rizzo@icir.org> Cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? Message-ID: <40861A71.1020502@he.iki.fi> In-Reply-To: <20040420233818.B43347@xorpc.icir.org> References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> <20040420233818.B43347@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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]
^L
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.
Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40861A71.1020502>