James Carlson wrote:
> 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.
I agree it would be good to have an automatic compatibility story on
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.)
FWIW if you have an exclusive-IP zone which uses bge1003 there wouldn't
be a /etc/hostname.bge1003 in the global zone; the zonecfg xml file is
the only place the global zone knows about the VLAN. (The non-global
zone is likely to have a /etc/hostname.bge1003, but the ngz doesn't have
the privileges to create the vlan.)
> b) Modify ifconfig itself to recognize the VLAN naming pattern and,
> if the device named doesn't exist, use libdladm to create it
> first.
That one also has issues with exclusive-IP zones since the ifconfig
plumb is run in the ngz which doesn't have the privilege to create the vlan.
For exclusive-IP zones zoneadm(d) does issue an ioctl to tell the kernel
that a datalink name will be used by a zone, but I don't know exactly
what gld does with the ioctl and whether than can be extended to create
the vlan.
Erik
> 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?
>
