ifconfig(8) interface description field

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Tue Nov 18 06:00:07 PST 2008


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 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?

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.


More information about the freebsd-stable mailing list