Date: Tue, 20 Apr 2004 09:48:46 +0200 (CEST) From: Harti Brandt <novo@cs.tu-berlin.de> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: net@FreeBSD.ORG Subject: Re: what is the story on if_index allocation ? Message-ID: <20040420093254.V613@130-149-145-114.dialup.cs.tu-berlin.de> In-Reply-To: <20040419183316.GE8967@Odin.AC.HMC.Edu> References: <20040419110912.A71274@xorpc.icir.org> <20040419183316.GE8967@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Apr 2004, Brooks Davis wrote: > On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote: > > > > I am a bit unclear -- how do we allocate if_index values for > > network interfaces ? > > I thought the strategy was allocate them sequentially, and > > only reuse numbers at the top of the allocated range. > > But then i see if_findindex() is quite complicated, and > > seems to look for hints using resource_string_value() and > > resource_find_dev() to possibly recycle old indexes below > > if_index. > > > > Can someone explain what is the goal ? Reuse a number if an > > interface has the same name of a previously existing one and > > the index is free ? And does it make sense, anyways, or > > we could just simplify that code and just reuse the first > > available entry in ifindex_table[] ? > > Even the current allocation strategy does not guarantee that > > indexes reflect the order of creation of interfaces, if that > > is what we care about. > > harti recently mentioned that the SNMP RFC requires that interfaces > keep the same index across various events including loading and > unloading the driver. I suspect this code is an attempt to handle that > case. Keying off of lladdrs is probably as close as you're going to get > to obeying that requirement in the kernel. I'm not convinced we should > worry about it in the kernel. The whole concept of the "same interface" > is rather dependent on the particular application context. For > instance, when dealing with virtual interfaces on a tunnel server, > interfaces could be created and destroyed on demand and if you wanted to > do accounting via SNMP indexs should be consistant for each account. > I'm tempted to push the whole problem off to userland where appropriate > application dependent policies can be implemented. After some thinking about the issue I think that the concept of 'the same interface' isn't valid anymore - it comes from times, where you had only hardware interfaces that you could change only by opening the computer. Nowadays with hot-plugable and several kinds of virtual interfaces that becomes very moot. Even with normal interfaces the whole thing is questionable. If you have, for example, a router that has xl0 to the outer world and xl1 to you local network and you swap these two interfaces, then you probably want (from the management point of view) xl0 now to become the 'same' as xl1 was - just the connection to the local network. It would be extremly hard to implement this in the kernel or even in a general purpose SNMP daemon. Given the complexity of that stuff, I think I throw it out of the SNMP daemon in the next release. harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040420093254.V613>