As part of my work on bridging, I've been looking closely at the IEEE
specification for VLAN tagging, and it seems that our de-facto
implementation is a bit at odds. I'm considering changing this with
the RBridges project, and I'd like some feedback.
The EISS described in sections 6.6 through 6.7 is effectively required
by 5.3(g)(1), and specifies the use of a "Port VLAN Identifier"
(PVID). This value works as the default VLAN for untagged and
priority-tagged traffic[1], and has a default value of 1 (specified in
Table 9-2).
The effect of this is that applications should be seeing the
PVID-tagged traffic and untagged as the same. We should
(automatically, by default) send VLAN 1 traffic out as untagged, and
should treat untagged/priority-tagged traffic as being the same.
We're not doing that. Instead, we treat untagged traffic as
effectively being a separate (and 'illegal' per the standard) VLAN 0,
and have no way to set or use a PVID (default VLAN).
This gets worse with bridging, as I need to include a PVID to make
the entry and egress from VLANs work properly. The PVID is how we
associate the tagged traffic with untagged ports and thus give a port
access to a VLAN.
The question is whether I should introduce a PVID as a common feature
in OpenSolaris, and potentially break some backward compatibility in
the pursuit of a standard, or make the PVID feature a "bridging only"
special function. I could do the latter, but it's much less appealing
esthetically. (In particular, it would allow you to send and receive
traffic with the PVID tag on a port that should -- per the standard --
never send or receive traffic tagged that way. It's inconsistent.)
The result of having a general PVID feature for OpenSolaris would be:
- On initial install, and initial use of an otherwise previously
unused port, the PVID would be set to 1, as defined by the
standard, and the user could select any value desired.
- Setting the PVID to 0 reverts the port back to the default
OpenSolaris behavior, allowing VLAN 1 to be used, and allowing
that to be distinct from untagged/priority-tagged traffic.
- On upgrade, if there is a VLAN 1 plumbed using the "VLAN hack"
(PSARC 2000/147) or if there's a VLAN 1 configured using dladm,
then a warning is put in the upgrade log, and that port has PVID
set to 0. All other ports get PVID 1.
- After upgrade is complete, it's illegal to create a VLAN with an
ID set to the PVID on the underlying port, if the PVID is
non-zero. Such attempts in dladm will fail, and the "VLAN hack"
(through Clearview UV) will fail to attach.
The observable effect would be that there'd be no change in system
behavior, either on initial install or upgrade, but that subsequent
VLANs configured would be subject to the PVID rule as above.
1. Section 6.8 describes segregation of traffic into VLANs on from
Ethertype values -- mapping untagged packets into VLANs based on
protocol. I'm not planning to support this, but the issues are
essentially the same.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
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
_______________________________________________
networking-discuss mailing list
[email protected]
