From: Peter Phaal (peter.phaal@inmon.com)
Date: 07/01/03
Marc,
Thanks for the description of VLAN tunneling. I agree with your suggestion
about adding new extended type data to properly capture the additional
information associated with the tunnels. Here is a suggestion:
/* Extended VLAN tunnel information
Record outer VLAN encapsulations that have
been stripped. extended_vlantunnel information
should only be reported if all the following conditions are satisfied:
1. The packet has nested vlan tags, AND
2. The reporting device is VLAN aware, AND
3. One or more VLAN tags have been stripped, either
because they represent proprietary encapsulations, or
because switch hardware automatically strips the outer VLAN
encapsulation.
Reporting extended_vlantunnel information is not a substitute for
reporting extended_switch information. extended_switch data must
always be reported to describe the ingress/egress VLAN information
for the packet. The extended_vlantunnel information only applies to
nested VLAN tags, and then only when one or more tags has been
stripped. */
/* opaque = sflow_data; enterprise = 0; format = 1008 */
extended_vlantunnel {
unsigned int stack<>; /* List of stripped 802.1Q TPID/TCI layers. Each
TPID,TCI pair is represented as a
single 32 bit
integer. Layers listed from outermost
to innermost. */
}
The current extended_switch structure will always be present if a device is
switching/routing VLAN traffic. The new extended_vlantunnel structure will
only be present if VLAN tunnels are in use and the device hardware
automatically strips layers, or the outer encapsulation is proprietary and
must be stripped. The new structure simply captures the data associated with
the stripped layers.
Comments?
Peter
-----Original Message-----
From: owner-sflow@inmon.com [mailto:owner-sflow@inmon.com]On Behalf Of
Marc Lavine
Sent: Tuesday, July 01, 2003 4:01 AM
To: sflow@sflow.org
Subject: [sFlow] VLAN tags in sampled packet headers
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