From: Marc Lavine (mlavine@foundrynet.com)
Date: 07/01/03
Hello all,
In responding to the recent discussion regarding the frame_length value for sampled packets, some issues arose regarding the handling of VLAN tags in the sampled packet headers. One issue relates to the fact that in some switch architectures, if there's an 802.1Q VLAN tag in an incoming packet, hardware may strip off the tag before the packet is handed to a management CPU for sFlow exporting. It is presumed that the information that was present in the VLAN tag will still be provided in the extended_switch structure. Leaving the tag out of the sampled header presents a discrepancy with respect to the frame_length value, however the new "stripped" count that was proposed can rectify that.
Another issue is that if a tagged packet is sampled and the VLAN tag is omitted from the sampled header, then a collector cannot directly tell that the packet was a tagged packet. The reason for this is that whether the packet was tagged or not, the extended_switch data will include the VLAN information (provided that the packet is traversing a VLAN). This issue may not seem too serious, however, there are situations where it becomes more problematic.
To support tunneling customer VLAN configurations through a metro service provider's network, many switch vendors support VLAN tag stacking schemes. Various names are used to describe these, including "Q-in-Q". With this kind of tag stacking, a packet can contain more than one 802.1Q tag, each appearing directly after the other. Typically, only two such tags would be used (though theoretically, more are possible). The use of tag stacking pushes the Ethernet maximum frame length beyond the 1518 bytes allowed by the 802.3 standard. Its use is not standardized yet, but there appears to be some work underway in the IEEE to move in that direction.
Different vendors have different approaches with regard to specifying the outer VLAN tag. Some vendors require the use of a non-standard VLAN tag Ethernet type code (i.e. the first two bytes of the tag), such as 0x9100 (a value which a number of vendors use), while others may allow the outer and inner VLAN tags to use the standard 0x8100 Ethernet type. For sFlow, these configurations bring up two problems:
First, in a VLAN tag stacking configuration where the inner and outer tags are allowed to the same, if an sFlow agent strips off the outer tag from the sampled packet header, then a collector might not be able to tell if the packet was a non-tunneled packet within the service provider's VLAN, or a tunneled packet from a customer's VLAN. In some cases, a collector might be able to infer that a packet had been tunneled, if the VLAN id in the extended_switch data is different from the one in the VLAN tag remaining in the sampled packet header, however, those ids could be the same. It seems desirable to have sFlow collectors be able to deal with configurations using VLAN tag stacking, and to be able to classify traffic within both levels of VLANs, so this ambiguity would need to be addressed.
A second problem results from the use of non-standard Ethernet type codes to specify the outer VLAN tag in a stacked configuration. For an sFlow collector that wishes to track both levels of VLANs in a stacked configuration, if the agent strips off the outer VLAN tag, then the information about the Ethernet type that was used to indicate the outer tag is lost. If the outer VLAN tag is not stripped off by the agent, this may present an additional challenge to sFlow collectors, since the outer VLAN tag might be using a non-standard Ethernet type. Without additional configuration, or access to the proprietary configuration of the switch, a collector might not be able to decode the remainder of the packet following the non-standard VLAN tag.
Here are some possible solutions to these problems:
To remove the ambiguities that arise from not knowing whether an sFlow agent has stripped off the outermost and possibly only) VLAN tag, one could include a flag in the extended_switch structure to indicate whether that has taken place or not.
To avoid the loss of the information about a stripped-off VLAN tag's Ethernet type, this information could be included in one of the extended data structures. One could add the data to the extended_switch structure, however, since many networks would not be using tag stacking, this would add unnecessary overhead. As an alternative, a separate extended data structure could be defined, which would hold the VLAN tag type information for the VLAN ids contained in the extended_switch structure, if at least one of the tag types is not the default 0x8100 value.
To reduce the configuration burden for sFlow collectors/decoders to be able to understand non-standard VLAN tag types, the specification could either require, or perhaps at least encourage, sFlow agents to strip off the outermost VLAN tag, at least in cases where the tag type is non-standard, and to do so even if this stripping is not performed by the switch hardware. If the specification were to require that the outermost VLAN tag always be stripped off, then the extra flag proposed above to indicate whether VLAN tag stripping had taken place or not, could be eliminated.
(Note that I have been oversimplifying a little in talking about stripping off the outermost VLAN tag. That description applies well to a service provider's core switches, where a packet would be received with two levels of VLAN tags. As packets are received from a customer network into the edge of a service provider's network, however, only one tag would be present in the packets, and the outer level VLAN id would be associated in the same way as when an untagged packet is received in a simple VLAN configuration. The port's VLAN id would be associated with the packet and the VLAN id would be placed in the extended_switch structure, but would not typically appear in the sampled header (at least with sampling done on ingress).)
Comments?
Marc
This archive was generated by hypermail 2.1.4 : 07/01/03 PDT