ifconfig(8) interface description field

cpghost cpghost at cordula.ws
Tue Nov 18 09:06:57 PST 2008


On Tue, Nov 18, 2008 at 01:58:09PM +0000, Bjoern A. Zeeb wrote:
> >> 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?

This would be done remotely by the network management system (NMS) The
NMS will notice that the node rebooted, and will send to its snmpd the
description of its interfaces. snmpd runs on the node, and will call
an ifconfig ioctl to store this description in kernel memory. From
then on, you could ssh to the box, and look around by calling
ifconfig(8) manually: you'all immediately know what each interface is
intended for. If you have hundreds of nodes, you'll appreciate the
convenience!

The presistence occurs at the NMS site: it is merely mirrored onto the
nodes.

So why store this on the nodes at all, as it is redundant and already
persistently available in the NMS?

Well, in practice, NMS can and do break down every now and then for
all kinds of reasons (database problems, server problems, network
problems to the NMS server, ...). But a NOC can't afford to wait for
the NMS be available again to reconfigure some important nodes on a
backbone.

Even when the NMS is down, you'll still have to manually ifconfig(8)
some interfaces on crucial backbone nodes. When the NMS is available
again, it will poll all the snmpd of its managed hosts, and will
update its own database if things changed in the mean time on the
nodes. That's the easiest way to synchronize the NMS database back
with the manual changes at the nodes that occured while the NMS was
down.

  (Sure, there's a little time window where information can be lost:
  that's just after the manual ifconfig(8) and the polling of the
  snmpd by the NMS. But, hey, if THIS happened, you could still use
  some logfile (script(1)?) of your manual changes to catch this.
  The normal workflow is to manage at the NMS and to push the data
  to the nodes, the reverse workflow is for emergencies only.)

The point I'm trying to make, is that diskless systems, or systems
with read-only filesystems should still be configurable, remotely and
manually; and the configuration data (in this case it's the
description strings of its interfaces) will have to be stored in
memory.

For something as trivial as description strings, kernel memory seems
like a good idea. If user memory is preferred and absolutely needed,
one could always write an ifconfigd daemon and store it there; but
*that* seems like overkill for such a simple change.

> 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