On 9/15/06, Ann Sunhachawee <ann.sunhachawee at sun.com> wrote:
> Hi all -
>
> Short summary: Please give me feedback on mockups for network
> configuration of enterprise class systems. See link below.
My comments are based on having used link aggregation (err.. Sun
Trunking), VLAN tagging, and IPMP in various combinations with each
other.
General comments:
At least as useful as the MAC address would be an indication of
physical location of the interface. This is very important when
configuring machines to avoid single points of failure or ensuring
that a server is configured to stay connected during dynamic
reconfiguration. In white-box x86 environments, this may not be
possible. However, it should be relatively easy on common Sun and
other Tier-1 vendors' hardware to say whether a physical is built into
the mother/system board, in PCI-E slot 3, or in PCI slot 2 in IO board
17. Translating physical paths to human descriptions would be of HUGE
value for non-trivial server configurations.
Would it be reasonable to allow the user to specify other columns to
include? Other GUI tools commonly allow a right-click on the existing
headers to allow the user to select other columns. This feature could
be helpful to allow system adminstrators to customize the views of
various tabs according to the things that are most important in their
environments.
Some sort of a hierarchical view would be nice (aka killer feature,
when combined with physical location). The hierarchical view would
also be a very handy place to give physical location. For example,
consider the following on a 25k domain.
Interface Name Type Physical Location Comment
----------------- ------------ --------------------- -----------------
intranet Multipath
intra-aggr0 Aggregation Uses switch0
ce8 10/100/1000 IOB4,PCI1,QGE Port 0
ce12 10/100/1000 IOB5,PCI1,QGE Port 0
intra-aggr1 Aggregation Uses switch1
ce9 10/100/1000 IOB4,PCI1,QGE Port 2
ce13 10/100/1000 IOB5,PCI1,QGE Port 2
A view like this (notice my ability to store a comment) can tell me
that I have no single points of failure for my IPMP intranet
connection. A key feature of this view is that I don't have to flip
between tabs to understand the configuration. Perhaps hovering over
the various interfaces could give status information - or perhaps not.
:)
Consider you have a cluster that uses a mixture of VLAN tagging, IPMP,
and link aggregations to make up various networks on a machine. For
example - intranet, cluster volume manager heartbeat, and application
coherency. These are spread across somewhere between 10 and 20
physical interfaces per cluster node. You have three nodes in your
cluster. You have another cluster for development. And another for
load testing. And another for ... Being able to use the GUI to
configure this once then export the config to be imported on the other
nodes would be extremely helpful. Presumably the exported config
could be used by jumpstart finishing scripts to get things as close as
possible to right.
http://www.opensolaris.org/os/project/nwam/UIDesign/ConfigUI/#3.1.1
Shouldn't this tab be called "IP" rather than "TCP/IP"? There is
nothing specific to the use of TCP that is being configured here.
Will this tab also display IPv6 addresses? If not the tab should
probably be called "IPv4" rather than "IP" or "TCP/IP".
Strictly speaking the ethernet address is no more relevant to the
configuration of IP than the physical location. To many people, the
physical location is more important to know.
http://www.opensolaris.org/os/project/nwam/UIDesign/ConfigUI/#3.1.2
Not sure how repeating the same value for the hostname will be
helpful. Resolving to the hostname would be much more useful.
There are lots of other flags that are available on interfaces.
Perhaps it would be possible to provide a means for displaying them.
For example, interfaces other than IPMP test interfaces can have the
deprecated flag set.
http://www.opensolaris.org/os/project/nwam/UIDesign/ConfigUI/#3.1.2.2
Specifying the policy as L2, L3, or L4 is not as helpful as it could
be. I really wish that all sysadmins knew what the various network
layers were. Frankly, however, those that are using a GUI to
configure it probably won't. Also, dladm(1M) says that multiple
policies can be applied, but the GUI doesn't seem as though it will
cope with that.
An advanced settings tab should be available to expose the other
options available through dladm(1M).
http://www.opensolaris.org/os/project/nwam/UIDesign/ConfigUI/#3.1.2.3
Again, advanced settings would be good. Outbound load balancing?
Failback? Failure detection time?
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/