From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 23:53:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C5E916A4CE for ; Tue, 20 Apr 2004 23:53:42 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A733D43D31 for ; Tue, 20 Apr 2004 23:53:41 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i3L6rgmo073202; Wed, 21 Apr 2004 09:53:42 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40861A71.1020502@he.iki.fi> Date: Wed, 21 Apr 2004 09:53:37 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> <20040420233818.B43347@xorpc.icir.org> In-Reply-To: <20040420233818.B43347@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:53:42 -0000 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