ifconfig(8) interface description field

cpghost cpghost at cordula.ws
Tue Nov 18 05:21:32 PST 2008

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 at 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).

> Just my 0.02CAD
> /bz
> -- 
> Bjoern A. Zeeb              Stop bit received. Insert coin for new game.


Cordula's Web. http://www.cordula.ws/

More information about the freebsd-stable mailing list