+1. Thanks for the detailed write up. (And, btw, -1 to the
applications that assume QoS is always present, and -1 to the switch
vendors that still haven't got tagged packet processing in their
products. :-)
-- Garrett
Sebastien Roy wrote:
> 802.1Q tag mode link property
>
> Release binding: Patch
> Interface Stability: Committed
> Related Case: PSARC 2006/358 VLAN Observability Enhancement
>
> Summary
> -------
>
> This case introduces a GLDv3 link property named "tagmode" to
> control the conditions in which the kernel inserts VLAN tags in
> outgoing packets.
>
> Background
> ----------
>
> The comprehensive VLAN tagging changes made by PSARC 2006/358 also
> fixed a bug that prevented Solaris from inserting a user priority
> tag (VLAN tag with NULL VLAN ID bug non-zero priority) when the
> sender specifies a priority for an outgoing packet over a physical
> Ethernet link. This bug was:
>
> 6434130 i_dls_ether_header() doesn't generate VLAN header when
> priority is non-zero
>
> As a result of this bug fix, when an application requests a user
> priority (either by using the DL_UDQOS_REQ DLPI primitive, by
> setting the dl_priority field of a DL_UNITDATA_REQ message, or by
> setting b_band on an M_DATA message) when sending a packet on a
> physical Ethernet link, the kernel will insert a VLAN header with a
> NULL VLAN ID and a priority as specified by the user.
>
> This new behavior is in-line with the 802.1Q IEEE specification.
> Bridges receiving such packets should recognize these as
> user-priority tagged packets and process the priority setting
> accordingly.
>
> Unfortunately, experience with this fix has uncovered that a number
> of widely used bridges (switches) don't handle these special
> user-priority tagged packets and simply drop them. This problem is
> documented in detail in the following CR:
>
> 6797256 GLD interfaces unexpectedly send VLAN tagged packets
>
> This issue, in combination with the fact that some widely deployed
> applications unconditionally request priority processing on all of
> their outgoing packets, means that these applications no longer work
> at all over physical Ethernet links connected to these problematic
> switches.
>
>
> Solution
> --------
>
> This case introduces a link property (see dladm(1M)) named "tagmode"
> that controls the conditions in which the kernel will insert VLAN
> tags on packets being transmitted on the link. Two mode values can
> be assigned to this property:
>
> normal Insert a VLAN tag to outgoing packets as needed
> whenever requested. This includes two cases:
>
> 1. The packet belongs to a VLAN.
> 2. The user requested priority tagging.
>
> vlanonly Only insert a VLAN tag when the outgoing packet
> belongs to a VLAN. If a tag is being inserted in this
> mode and the user has also requested a non-zero
> priority, the priority is honored and included in the
> VLAN tag.
>
> Only DL_ETHER links will support this property, and its default
> value will be "vlanonly". Setting the property to "normal"
> demonstrates deliberate understanding that the feature is functional
> on the associated datalink.
>
> Impact On IFF_COS_ENABLED Flag
> ------------------------------
>
> The IFF_COS_ENABLED flag documented as "Cos" in ifconfig(1M)
> reflects whether or not an interface supports a class of service
> marking (with 802.1D user priority marking being one example). This
> flag is currently set on all GLDv3 datalinks regardless of their
> ability to honor user priorities.
>
> One consumer of this flag is the IPQos functionality, which can be
> configured to request per-packet user priorities over CoS-capable
> interfaces (see ipqos(7ipp) and ipqosconf(1M)). It does this on IP
> interfaces that have the IFF_COS_ENABLED flag set.
>
> In order to accurately reflect the link's abilities to use
> priorities, this case changes the system such that the
> IFF_COS_ENABLED flag will only be set on VLAN links and on physical
> links that have their "tagmode" properties set to "normal". This
> will ensure that IPQos and other consumers of the IFF_COS_ENABLED
> flag do not erroneously request priorities over links that don't
> support them or have been explicitly configured to not use them.
>
> Change of System Default Behavior
> ---------------------------------
>
> The choice of "vlanonly" as the default value for the "tagmode" link
> property constitutes a change in behavior from how the system
> behaved after the fix to 6434130 was integrated. As previously
> mentioned, the fix to 6434130 caused the system to always insert a
> user-priority tag when requested. It will now only do so if the
> administrator explicitly changes the "tagmode" property to have the
> value "normal".
>
> The fix to 6434130 was included with s10u7, and prior to that, most
> drivers (including all GLDv2 and GLDv3 drivers) failed to insert
> user-priority tags. Since 6434130 has no external customer records,
> one can thus assume that no-one noticed that this was broken, and so
> reverting the system default behavior back to its prior state will
> not be disruptive.
>
> The dladm(1M) man page will be updated to document the "tagmode"
> link property, and the "CoS" section of the ifconfig(1M) man page
> will be modified to describe how to enable "CoS" using the "tagmode"
> property.
>
>
>
