PSARC 2009/069 802.1Q tag mode link property
A nit question: Is there the means to determine a dropped packet occurred due to the user priority tag, and automatically setting the tagmode to vlanonly? -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
PSARC 2009/069 802.1Q tag mode link property
On Wed, 2009-02-11 at 10:19 -0600, Rick Matthews wrote: A nit question: Is there the means to determine a dropped packet occurred due to the user priority tag, and automatically setting the tagmode to vlanonly? Unfortunately no. There is no way to know the reason why a down-stream bridge has dropped a packet. -Seb
PSARC 2009/069 802.1Q tag mode link property
This case was approved during today's PSARC business. -Seb
PSARC 2009/069 802.1Q tag mode link property
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. vlanonlyOnly 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
PSARC 2009/069 802.1Q tag mode link property
On Fri, 2009-02-06 at 17:32 -0500, Sebastien Roy wrote: 802.1Q tag mode link property I forgot to mention that I'm sponsoring this case for myself, and it times out on February 13th. -Seb
PSARC 2009/069 802.1Q tag mode link property
Sebastien Roy writes: On Fri, 2009-02-06 at 17:32 -0500, Sebastien Roy wrote: 802.1Q tag mode link property I forgot to mention that I'm sponsoring this case for myself, and it times out on February 13th. +1 -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
PSARC 2009/069 802.1Q tag mode link property
+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: normalInsert 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
