ifconfig(8) interface description field

cpghost cpghost at cordula.ws
Tue Nov 18 05:40:56 PST 2008


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

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/


More information about the freebsd-stable mailing list