From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 13:40:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242A8106564A for ; Tue, 18 Nov 2008 13:40:55 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1871F8FC14 for ; Tue, 18 Nov 2008 13:40:55 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id A740A35F35; Tue, 18 Nov 2008 14:37:43 +0100 (CET) Date: Tue, 18 Nov 2008 14:42:28 +0100 From: cpghost To: "Bjoern A. Zeeb" , freebsd-stable@freebsd.org, sthaug@nethelp.no Message-ID: <20081118134228.GC958@phenom.cordula.ws> References: <5FD58BCD6B4C409DA7E7C30150FB10C7@multiplay.co.uk> <20081117.233619.85395429.sthaug@nethelp.no> <20081118081153.GQ51761@server.vk2pj.dyndns.org> <20081118.103424.74710091.sthaug@nethelp.no> <20081118113811.GB1136@phenom.cordula.ws> <20081118120244.U61259@maildrop.int.zabbadoz.net> <20081118132305.GB958@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081118132305.GB958@phenom.cordula.ws> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: ifconfig(8) interface description field X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 13:40:56 -0000 On Tue, Nov 18, 2008 at 02:23:05PM +0100, cpghost wrote: > On Tue, Nov 18, 2008 at 12:07:32PM +0000, Bjoern A. Zeeb wrote: > > On Tue, 18 Nov 2008, cpghost wrote: > > > > > On Tue, Nov 18, 2008 at 10:34:24AM +0100, sthaug@nethelp.no wrote: > > >>>> Oh yeah, since we're in wishful thinking mode, I want interface > > >>>> descriptions too... > > >>> > > >>> Have you looked at the 'name' and 'group' keywords in ifconfig(8)? > > >>> If this isn't what you want, please expand on your wish. > > >> > > >> It is not what I want. > > >> > > >> On routers, switches and lots of other boxes from most vendors you can > > >> associate a description string with each interface - where interface > > >> can be a physical port, or for instance a VLAN based interface. This > > >> description string is useful to document things like > > >> > > >> - what is the box at the other end of the cable connected to this port > > >> - what is the port at the other end of the cable connected to this port > > >> - what is the circuit id for the circuit this port is connected to > > >> - what is this port used for > > >> > > >> etc. Typical example, from one of our switches (Cisco syntax): > > >> > > >> interface GigabitEthernet0/12 > > >> description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps > > >> switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 > > >> > > >> showing the first three points I mentioned above. > > >> > > >> Such a description string is can normally be retrieved using SNMP. > > > > > > Yes, that's a very useful addition. I'm administering a lot of Cisco > > > boxes, and this desc field has been extremely useful over the years. > > > > > > Maybe an ifi_desc field could be added to: > > > > > > /usr/src/sys/net/if.h:struct if_data > > > > > > and some glue so that ifconfig(8) can read and write to it? > > > How long should this field be at most? > > > > This is nothing the really belongs in the kernel. > > > > Add an "interface" to set/get the information per interface (index, > > name, ...) and store the actual data in a file maybe. > > Make the format extensible to store other meta data that > > people may want to think along with it in the future. > > > > After all you want the information to be peristent over a reboot so > > you have to write it out somehow anyway. > > Yes, but some interfaces are created on-the-fly, and you never > know in advance which name they'll get (think of tunN, ngN etc...). > > If those interfaces are meant to be queried frequently (every few > minutes or so) by an snmpd, wouldn't it be more inefficient to check > an external file than get the meta data from the kernel? > > Some network management apps could also decide to use the description > field as a repository for more dynamic data; data that could be queried > by applications running on the hosts. Here too, would'nt it be more > efficient if descr. were in-kernel? > > For persistence, an /etc/rc.d script could always set the static > interface descriptions via ifconfig calls any way it likes, including > reading those definitions from a config file. Everything else will > probably be set remotely via the network management software, which > itself has its own persistence store (usually a database). Another reason you want to avoid using a file for this: what about appliances that run as dedicated routers and boot from a flash-based read-only filesystem? How would you change the interface description (remotely or on the console) if you can't write to a file? > > Bjoern A. Zeeb Stop bit received. Insert coin for new game. -cpghost. -- Cordula's Web. http://www.cordula.ws/