SEO

Has anyone noticed how there are periodic questions of the sort
"how to configure property <foo> on nic <bar>?" from Solaris
users on the various forums/newsgroups? Usually these
questions are related to Jumbo Frames, and the questions
demonstrate how painful it is to administer Solaris NICs.

Solaris seems to adopt any (sometimes all :-() of the methods below:

(a) driver.conf(4) with the additional problem that the syntax
for each driver is not standardized or documented
(b) ndd(1M) with the drawback that ndd can only be used to set/get
a subset of scalar parameters,
(c) via obp on sparc,
(d) kstat (1M) can be used to read existing configuration for some
parameters

All this makes NIC configuration on Solaris a very confusing process.

The Brussels project (http://opensolaris.org/os/project/brussels/)
is trying to come up with a user-friendly solution for this problem
using some of the newer tools like dladm (which is being used for WiFi
and Trunking configuration), and we are seeking feedback from
customers.

Any input you may have, including answers to the questions below, are
welcome.

- Please provide a short (1-2 line) overview of your networking
environment.

- do you frequently change or upgrade your network interface cards? Do
you otherwise modify existing NIC configuration and/or tweak the
tunables?
If yes, how frequently do you do these tasks?

- What tools/commands do you use to administer NICs?
Are you currently satisfied with the existing tools?

- What do you like/dislike about existing methods? Please be as
specific as possible.

- What are the typical NIC tunables/properties that you examine most
of
the time? Please indicate whether you merely 'get' (i.e., read-only
info) existing values for the property, or tune it (i.e., read/
write).

- Do you have custom scripts executed at boot time that set ndd
parameters?

- Do you write custom device drivers? If yes, do you use the GLDv3
framework?
Note that the Brussels project proposes the following:
provide a simpler cleaner interface for GLDv3 drivers via dladm.
The
GLDv3 drivers will provide function pointers for setting/getting
properties when they register with the GLDv3 framework.
Subsequently,
dladm can be used to send the appropriate system calls to trigger
the
registered set/get functions.
Please provide any input you may have on the proposal above.

- Do you use Link Aggregation ("Trunking") or WiFi?

- Do you use dladm as a configuration tool, i.e., have you ever used
the "dladm set-linkprop" feature? If yes, what do you
like/dislike about this interface?

- Would you be interested in a GUI for dladm? What sort of features
would
you like to see in a GUI?