Raoul Carag wrote:
I added another draft that describes procedures for the configuration
and maintenance of VLANs while using link names.
I revised the documentation page a bit to provide summary statements
about each drafts that is currently posted.
As usual, the new draft is found here:
http://www.opensolaris.org/os/project/clearview/docs/
Good docs. See my comments:
Chapter 2 administering a single interface
1. the introduction section
"however, use of the ifconfig command remains a valid method to configure links"
What does this mean?
2. Table 2-1
"Task Display devices"
I think it is better to change to "task display physical links", as we
explicitly obsoleted the "dladm show-dev" subcommand.
Words like this ("display devices, displaying information about devices) are
all around other sections too.
3. Section "how to configure a physical link after system installation"
3a. We usually do not include the IP interface configuration as a part of
the *link configuration*. If you think mix these two makes the configuration
tasks complete, please make sure to use several sentences to explain why we
use the term "IP interface" and "link" exchangeably: it is because we plumb
the IP interfaces using link names, therefore, the link name will be
propagated up to the IP administrative and programmatic interfaces".
3b. "step 3. if you intend to rename a data-link, then close that link"
It should be rephrased to something like "if you intend to rename a
data-link, then make sure that link is not opened by any applications. For
example, if this interface is plumbed, unplumb it:"
3c. Example 2-1
ibd0 does not look like of MEDIA ether. It should be infiniband. This error
exist in other sections too.
4. Section "how to replace a network card while using l
ink names"
4a. Step 4,5,6 are not clear to me. Do you mean to use DR to remove and
insert network card? How to perform step 5?
4b. Please emphasize that if one issue "dladm rename-link <link1> <link2>"
which link2 is a removed link, to have link1 inherit all link configuration
of link2, then one cannot have any link configuration on link1, for example,
one cannot create VLANs or aggregations over link1.
5. Section "how to display information about devices"
5.a See comment 2.
5.b Note that as a recent changes, we are able to display the /devices path
of specific physical links. For example:
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
net0 ether up 100Mb full bge0
net2 ether unknown 0Mb unknown bge2
net1 ether unknown 0Mb unknown bge1
bge3 ether unknown 0Mb unknown bge3
# dladm show-phys -v
LINK PATH
net0 /[EMAIL PROTECTED],700000/[EMAIL PROTECTED]
net2 /[EMAIL PROTECTED],700000/[EMAIL PROTECTED]
net1 /[EMAIL PROTECTED],700000/[EMAIL PROTECTED],1
bge3 /[EMAIL PROTECTED],700000/[EMAIL PROTECTED],1
6. Section "Using link names in other applications"
6a. "Dynamic Reconfiguration (DR) can only be performed on system that
support this feature, and all of these systems are servers."
This is not true. Some wireless card can support DR. We've verified on some
laptops.
7. Section "Link names and the autopush module"
I think the title better to be "Configure the autopush modules based on link
names"? Also, it is better to mention its relationship with the old autopush
support. See details in section 3.1.4 of the UV design doc.
Chapter 5 Administering VLANs
8. Section "VLAN names, VLAN tags and physical pointers of attachment"
Page 9. Before you talk about the vanity VLAN name, you might want to
consider the current VLAN name rules (pre-Clearview-project). Also, please
mention while the old VLAN PPA hack "formula" will be supported, but it is
not recommended
9. Section "Planning for VLANs on a network".
I don't quite understand step 3.c.
10. Section "Configuring VLANs"
10a. After the Clearview project, *all* interface types should support VLAN,
except some of them might have the restriction described in section 6.1.4 of
the UV design document.
10b. Note that "ifconfig <vlan ppa name> plumb" should still work to
configure a VLAN. I think it is still worth mentioning. But remember to
mention it is not recommended.
11. Section "How to configure VLANs on legacy devices"
11a. I think the title should be changed. As it only describes some issues
with the legacy VLAN configuration. But the VLAN configuration tasks over a
legacy device or a non-legacy device should mostly the same.
11b. "consequently, creating VLANs over these types of links is not allowed"
This is not true. As you mentioned afterwards, you could create VLANs over
such links using the "-f" option.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
