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, [EMAIL PROTECTED] 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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
