From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 14:00:07 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 B4289106567A for ; Tue, 18 Nov 2008 14:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 575EE8FC1B for ; Tue, 18 Nov 2008 14:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 17FCD41C65F; Tue, 18 Nov 2008 15:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id JWqjRJ8+Epeh; Tue, 18 Nov 2008 15:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 7D63941C65E; Tue, 18 Nov 2008 15:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0954D444888; Tue, 18 Nov 2008 13:58:10 +0000 (UTC) Date: Tue, 18 Nov 2008 13:58:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: cpghost In-Reply-To: <20081118134228.GC958@phenom.cordula.ws> Message-ID: <20081118135622.L61259@maildrop.int.zabbadoz.net> 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> <20081118134228.GC958@phenom.cordula.ws> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, sthaug@nethelp.no 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 14:00:07 -0000 On Tue, 18 Nov 2008, cpghost wrote: Hi, > 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? So how would you make it persistent across a reboot if you cannot write it anywhere? Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game.