RE: VLAN tags in sampled packet headers

From: Peter Phaal (
Date: 07/01/03

  • Next message: Marc Lavine: "Re: Encoding unknown addresses in sFlow datagrams"


    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

       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.


      -----Original Message-----
      From: []On Behalf Of
    Marc Lavine
      Sent: Tuesday, July 01, 2003 4:01 AM
      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

      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).)



    This archive was generated by hypermail 2.1.4 : 07/01/03 PDT