Date: Tue, 18 Nov 2008 13:58:09 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: cpghost <cpghost@cordula.ws> Cc: freebsd-stable@freebsd.org, sthaug@nethelp.no Subject: Re: ifconfig(8) interface description field Message-ID: <20081118135622.L61259@maildrop.int.zabbadoz.net> In-Reply-To: <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> <20081118134228.GC958@phenom.cordula.ws>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081118135622.L61259>