[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-sysadmin-discuss
Subject:    Re: [sysadmin-discuss] Fwd: NIC administration desirables..
From:       Octave Orgeron <unixconsole () yahoo ! com>
Date:       2007-03-03 23:54:51
Message-ID: 387122.6809.qm () web30801 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

Hi,

Read below;)
--- sowmini.varadhan@sun.com wrote:

> 
> Also seeking feedback from the sysadmin community for the following:
> 
> ----- Forwarded message from Sowmini.Varadhan@Sun.COM -----
> 
> > To: networking-discuss@opensolaris.org
> > From: Sowmini.Varadhan@Sun.COM
> > Date: Fri, 02 Mar 2007 09:54:45 -0500
> > Subject: NIC administration desirables..
> > X-PMX-Version: 5.2.0.264296
> > X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set
> sender to
> > 	sowmini.varadhan@sun.com using -f
> > User-Agent: Mutt/1.5.13 (2007-01-26)
> > Original-recipient: rfc822;sowmini.varadhan@sun.com
> > 
> > 
> > 
> > Has anyone noticed how there are periodic questions  of the sort
> > "how to configure property <foo> on nic <bar>?" Usually these
> > questions are related to NIC customization for features like  Jumbo
> > Frames, and the questions demonstrate how painful it is to
> administer
> > our NICs.
> > 
> > We seem to adopt any (sometimes all :-() of the methods below on
> Solaris: 
> > 
> >  (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, and the settings are not
> persistent across
> >      reboot,
> >  (c) via obp on sparc,
> >  (d) kstat (1M) can be used to read existing configuration for some
> >      parameters
> > 
> > All this makes NIC configuration a very confusing process
> > even for internal developers.
> > 

It does make NIC configuration and troubleshooting rather difficult and
time consuming. Speaking as the maintainer of the script "nicstatus"
it's a constant challenge trying to keep up with the differences
between NIC's to collect settings, even between OS releases:( I also
make use of nddconfig (from bigadmin) to set TCP/IP settings. The
script makes it easy, but there should be a built-in utility that
accomplishes the same thing, but only better:)

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

Normally, I only change or upgrade NIC's when something fails or if I
can get a server in GigE ports. I have deployed scripts and even SMF
services that configure each NIC to the correct settings for our
switches. One of the biggest challenges in this area is getting other
SysAdmins and NetAdmins to understand that modern switches and NIC's
work properly with auto-neg turned on. This is normally something that
is done once, when a data center is built, new switches are installed,
or new servers are installed. Unfortunately, it's a big pain to have to
deal with something that should "Just Work".

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

I tend to avoid modifying the conf files for drivers or sticking things
into /etc/system as patching, upgrades, etc can introduce more human
error. As such, it's better to have an SMF service with a conf file to
configure the NIC's upon boot up. Since I maintain "nicstatus", I use
that a lot for checking the configuration of NIC's. I have started to
look at dladm as a replacement for ndd and kstat for "nicstatus".

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

It's nice to see commands like dladm finally. However, I have not
tested it's ability to replace dynamic settings traditionally done by
ndd. Modifying conf files or /etc/system just introduces a lot of human
error and that's what should be avoided. It would be nice to have a CLI
and GUI utility that would display the current settings (speed, duplex,
auto-neg, link status, jumbo frames, etc.) and allow you to change them
per instance (bge0 may be 1Gb and bge2 maybe 100Mb). These changes
should be saved in a central configuration file and read by the kernel
drivers or an SMF service. This reduces the number of configuration
files to keep track of and it would be nice to see the utility be smart
enough to do sanity checks, report errors, etc. Perhaps even report if
the switch port is mis-configured:)

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

Typically, I use "nicstatus" or dladm to get settings (speed, duplex,
auto-net, link status, etc.). Then change the config file for a custom
SMF service to implement the changes.

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

Yes;) Bigadmin's nddconfig and a custom SMF service with a conf file.
> > 
> > - 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.
> >   More details are available at
> http://opensolaris.org/os/project/brussels/
> >   Please provide any input you may have on the proposal above.

No, I'm not at the point where I need to write my own drivers since
Solaris supports enough cards that it's not a big deal these days.
However, it would be nice if all the current common NIC's conformed to
one standard method of getting and setting configuration information.
GLDv3 is a huge step in the right direction, just need to keep in mind
that most customers still have hme's, qfe's, etc.


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

Link Aggr is something we're looking at. The biggest hurdle is
documentation with good examples of what needs to be done on the switch
and the server. I found bits here and there, but ultimately it should
be in a single doc on docs.sun.com:)

I do make use of WiFi on my laptop with Nevada. I like the inetmenu
util to get things working. I have noticed there is a new util in
Gnome, but have not tried it yet.

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

I have not used dladm as a configuration util. It would be nice to see
some more examples in the man page to get started.

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

While I like CLI's for doing work, I do see the value in having a GUI,
especially for the desktop. It should probably display graphics for
each NIC and allow you to click on them for details. Then have radio
buttons to select features and drop-down boxes to select settings
(think of speed 100mb, 1gb, 10gb, etc.). Creating link aggregations
should probably be as simple as linking the icons with a drag-n-drop
operation. Have it ask you if you want to create an aggregation and
join the selected NIC icons into a grouping. Something like that would
be kewl;)

I think the over-all design goal is to make sure it's powerful enough
for a sysadmin, but simple enough for a developer with a laptop to
setup and maintain. 

> > 
> 
> ----- End forwarded message -----
> _______________________________________________
> sysadmin-discuss mailing list
> sysadmin-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
> 


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems Engineer
http://www.opensolaris.org/os/community/sysadmin/
http://unixconsole.blogspot.com
unixconsole@yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
_______________________________________________
sysadmin-discuss mailing list
sysadmin-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
[prev in list] [next in list] [prev in thread] [next in thread]