Has any thought been given to the notion of just eliminating the vlan hack altogether?
It seems like there are better ways to express vlans, and the "hack" has always been a bit unsettling to me. Now that we're on a pseudo-major-release boundary (OpenSolaris), couldn't this be a time to break that compatibility? (Actually, although everyone knows about, I'm having trouble locating any documentation that specifically refers to the PPA-based VLAN hack. So maybe its not technically interface breakage anyway.) -- Garrett James Carlson wrote: > 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. > > _______________________________________________ networking-discuss mailing list [email protected]
