In order to simplify administration for bridging, I plan to make the
"allowed VLAN" set for a link connected to a bridge match the set of
VLANs configured by way of "dladm create-vlan".
While it would be possible to create a separate configuration table
for the "allowed VLANs" on a given bridge port[1], it seems a lot more
natural and simple to have the same command that says "create this
VLAN" also mean "I'd like to use this VLAN." (A separate "linkprop"
flag on the VLAN could be created, if desired, to exclude the VLAN
from the allowed VLAN set, but allowing use should be the default
because non-operational links are at least confusing, if not just
user-hostile.)
The problem this leads to is that with PPA-hack VLANs, there's no
command that can be taken as explicit authorization of the use of that
VLAN ID number. It might just be an errant snoop user who conjured up
this VLAN on a whim, and having that VLAN magically enter the "allowed
VLAN" list as a side-effect of running snoop would be at least
surprising.
I'd like to propose that, for the purpose of bridging, PPA-hack VLANs
are different. They default to "forwarding off," which means that
they're not part of the bridge's "allowed VLAN" set for the underlying
link.
Is there any problem with making PPA-hack VLANs different from
explicitly configured VLANs in this way?
1. What Clearview calls a "link" in this context is called a "port"
by IEEE documents.
--
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
