Kais Belgaied writes:
> 4.3 EOF of the VLAN PPA Hack
> Although the committee members and reviewers agreed on the benefit of
> obsoleting the VLAN PPA hack, they debated the proper timing of the
> removal of the hack from OpenSolaris.
> A member noted the possible disruption to users of this visible
> feature, even though the release binding is minor. He suggested
> considering a phased approach, with an announcement of the EOF as part
> of this project, followed by another fast-track to finish the actual
> removal of the feature. The project team, while open to the idea of a
> two-step approach, argued that the co-existence of the old hack with
> the new architecture was problematic. The project re-designed the
> VLANs to be created as VNICS, which are MAC level datalinks, so that
> obeservability features and resource controls can be applied to them.
> Keeping the old hack will perpetuate the ambiguous behavior when
> plumbing a non existing interface, result in a duplication of code in
> the MAC and DLS layers. The answer was satisfactory to the committee.
I wasn't available for the review, and this is obviously a late time
to bring this up, but the answers above sound insufficient to me.
Removal of support for the VLAN PPA hack in the kernel itself sounds
feasible, but I don't agree that this should be taken as license to be
deliberately incompatible on upgrade. Doing so will break machines
like jurassic.sfbay and many of our internal boot servers unless the
administrators of those systems take deliberate -- and, per the
opinion, apparently undocumented -- action prior to upgrade.
Alternative plans that would allow removal of the kernel components
and still preserve compatibility include at least these two
approaches:
a) Running a one-time conversion that checks for /etc/hostname.* and
/etc/hostname6.* names that specify a VLAN, and automatically
running the necessary dladm command to create the VLAN first.
The scripting work in the net-physical script to accomplish this
is trivial, and looks something like:
while [ $# -gt 0 ]; do
case $1 in
*[0-9][0-9][0-9][0-9])
base=`expr $1 : '\(.*[^0-9]\)'`
ppa=`expr $1 : '.*\([0-9][0-9][0-9]\)$' + 0`
vid=`expr $1 : '.*[^0-9]\([0-9]*\)[0-9][0-9][0-9]$'`
dladm show-link $1 >/dev/null 2>&1 || \
dladm create-vlan -l $base$ppa -v $vid $1
esac
/sbin/ifconfig $1 plumb
(There are other places this could be done, and it's unclear to
me how this interacts with exclusive IP stack zones.)
b) Modify ifconfig itself to recognize the VLAN naming pattern and,
if the device named doesn't exist, use libdladm to create it
first.
These are cheap, easy to specify, implement, and test, and would avoid
breaking most running systems using VLANs today. It would leave out
only ad-hoc snooping on unplumbed VLANs and non-IP protocols run over
VLANs.
Is there any reason to avoid at least that level of compatibility?
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
