sflow vlan stats extraction

[martin....@zeetta.com]

Hi,

I am trying to extract VLAN Rx/Tx data from sFlow, but I only receive:
- Flow sample: Raw packet header
- Counter sample: Generic interface counters

sFlowTrend can show me nice graphs of Top input VLANs and Top output VLANs
(Rx/Tx, utilization), using only those data.
According the the specification there should be 'Counter sample: VLAN
Counters', but there are no such data in the sample.

Can you please explain how to extract VLAN Rx/Tx from data I've received ?


Sample:
https://drive.google.com/a/zeetta.com/file/d/0B9hBNm3SrwDtbjFUaFR6aWNHS3M/view?usp=sharing

[Peter Phaal]

On Fri, Sep 1, 2017 at 6:48 AM, <martin....@zeetta.com> wrote:

I am trying to extract VLAN Rx/Tx data from sFlow, but I only receive:
    - Flow sample: Raw packet header
    - Counter sample: Generic interface counters

sFlowTrend can show me nice graphs of Top input VLANs and Top output VLANs (Rx/Tx, utilization), using only those data.
According the the specification there should be 'Counter sample: VLAN Counters', but there are no such data in the sample.

Can you please explain how to extract VLAN Rx/Tx from data I've received ?

The vlan_counters structure is only exported by VLAN data sources. Most implementations of sFlow use interface data sources and export the if_counters  and ethernet_counters which are generally more useful (these structures include the SNMP MIB-2 ifTable counters).

The VLAN information is available in the extended switch structure that is sent as part of a flow sample:

struct extended_switch {

   unsigned int src_vlan;     /* The 802.1Q VLAN id of incoming frame */

   unsigned int src_priority; /* The 802.1p priority of incoming frame */

   unsigned int dst_vlan;     /* The 802.1Q VLAN id of outgoing frame */

   unsigned int dst_priority; /* The 802.1p priority of outgoing frame */

}

This structure is used by sFlowTrend to report on per-VLAN traffic. 

Note: If you are monitoring traffic on a tagged port, then the ingress VLAN is part of the sampled packet header.

[Bruce A. Mah]

If memory serves me right, Peter Phaal wrote:

> The VLAN information is available in the extended switch structure that
> is sent as part of a flow sample:
>
> struct extended_switch {
>    unsigned int src_vlan;     /* The 802.1Q VLAN id of incoming frame */
>    unsigned int src_priority; /* The 802.1p priority of incoming frame */
>    unsigned int dst_vlan;     /* The 802.1Q VLAN id of outgoing frame */
>    unsigned int dst_priority; /* The 802.1p priority of outgoing frame */
> }

My (slightly hazy) understanding is that whether or not the
extended_switch structure is sent for flow samples is up to the
implementation, is that right?

(Going off on a slight tangent, apologies...)

What about the sampled_ethernet, sampled_ipv4, etc. structures? Are
those optional as well? If so, how often do implementations actually
include those along with the raw sampled bytes?

I'm thinking about sFlow as a possible replacement for NetFlow v9, but
we consume parts of the NetFlow records that either 1) would require
some parsing of packet headers within the samples or 2) aren't in the
packet headers at all (but are in, say the extended_router or
extended_gateway structures). So I'm trying to get a feel for whether
these more "cooked" structures are commonly exported as well.

Thanks for any insights,

Bruce.

[Peter Phaal]

Support for the extended_switch structure is not mandatory in the sFlow standard, but most vendors do export the structure.

All sFlow implementations that I am aware of export the sampled_header when they sample packets. The sampled_header is the preferred structure and the standard only permits sampled_ethernet, sampled_ipv4, sampled_ipv6 structures if the switch hardware is incapable of supplying the packet header.

Most NetFlow collectors are also capable of collecting sFlow records (at a minimum decoding the NetFlow 5 equivalent fields from the sampled packet header). 

You should check with your switch vendor to see what other extended flow records they support (e.g. extended_router, extended_gateway, extended_mpls, etc). If you are using link aggregation, then you should ask about support for the LAG extension, http://sflow.org/sflow_lag.txt

FYI a catalog is sFlow structures is maintained on sFlow.org, http://sflow.org/developers/structures.php

You might want to take a look at sflowtool, https://github.com/sflow/sflowtool. It can decode all the sFlow records types as well as the sampled_header. It also can convert sFlow into NetFlow versions 5 and 9. sflowtool can also pass the packet headers in pcap format to tools like wireshark and tcpdump:

http://blog.sflow.com/2011/11/wireshark.html

It's important to understand the architectural differences between sFlow and NetFlow. One way to think about sFlow is as a disaggregation of NetFlow, implementing the packet sampling on the device and shifting the flow cache to external software, e.g.:

http://blog.sflow.com/2013/08/restflow.html

[Bruce A. Mah]

If memory serves me right, Peter Phaal wrote:

> Support for the extended_switch structure is not mandatory in the sFlow
> standard, but most vendors do export the structure.
>
> All sFlow implementations that I am aware of export the sampled_header
> when they sample packets. The sampled_header is the preferred structure
> and the standard only permits sampled_ethernet, sampled_ipv4,
> sampled_ipv6 structures if the switch hardware is incapable of supplying
> the packet header.
>
> Most NetFlow collectors are also capable of collecting sFlow records (at
> a minimum decoding the NetFlow 5 equivalent fields from the sampled
> packet header). 

Hi Peter--

Many thanks for the helpful reply!

I'm thinking about this from the standpoint of a service provider's
routers. In my mind, the router already did the packet decoding
(because it had to do this for routing decisions), and it'd just be
convenient to shove the cooked data into sample records in addition to
the packet header to avoid making the collector re-do the packet decode.
The mental picture I had was that an L3 router would be able to export
sampled_header, sampled_ethernet, and sampled_ipv4/sampled_ipv6...based
on the text in the bottom half of p. 33 of the sFlow version 5 standard.
Perhaps I misinterpreted your intent there?

> You should check with your switch vendor to see what other extended flow
> records they support (e.g. extended_router, extended_gateway,
> extended_mpls, etc). If you are using link aggregation, then you should
> ask about support for the LAG extension, http://sflow.org/sflow_lag.txt
>
> FYI a catalog is sFlow structures is maintained on
> sFlow.org, http://sflow.org/developers/structures.php
>
> You might want to take a look at
> sflowtool, https://github.com/sflow/sflowtool. It can decode all the
> sFlow records types as well as the sampled_header. It also can convert
> sFlow into NetFlow versions 5 and 9. sflowtool can also pass the packet
> headers in pcap format to tools like wireshark and tcpdump:
>
> http://blog.sflow.com/2011/11/wireshark.html

Many thanks for the pointers! Some of these were new to me, so much
appreciated.

> It's important to understand the architectural differences between sFlow
> and NetFlow. One way to think about sFlow is as a disaggregation of
> NetFlow, implementing the packet sampling on the device and shifting the
> flow cache to external software, e.g.:
>
> http://blog.sflow.com/2013/08/restflow.html

Got it (I've worked on NetFlow collectors before).

I looked through sflowtool. From a casual read of the code it looks
like if it's configured to emit NetFlow records, it generates one
NetFlow record for every sFlow packet sample, in other words it's not
doing any of the flow cache functionality that a NetFlow exporter would
normally do. So as with the sFlow architecture in general, it's
accepting the cost of a higher data rate between the exporter and the
collector in favor of exporting more detail on individual packet samples
(not aggregated in time) and potentially simpler logic on the collection
device. Is that correct?

Thanks!

Bruce.

[Peter Phaal]

On Tuesday, September 5, 2017 at 12:28:14 PM UTC-7, Bruce A. Mah wrote:

If memory serves me right, Peter Phaal wrote:

> Support for the extended_switch structure is not mandatory in the sFlow
> standard, but most vendors do export the structure.
>
> All sFlow implementations that I am aware of export the sampled_header
> when they sample packets. The sampled_header is the preferred structure
> and the standard only permits sampled_ethernet, sampled_ipv4,
> sampled_ipv6 structures if the switch hardware is incapable of supplying
> the packet header.
>
> Most NetFlow collectors are also capable of collecting sFlow records (at
> a minimum decoding the NetFlow 5 equivalent fields from the sampled
> packet header). 

I'm thinking about this from the standpoint of a service provider's
routers.  In my mind, the router already did the packet decoding
(because it had to do this for routing decisions), and it'd just be
convenient to shove the cooked data into sample records in addition to
the packet header to avoid making the collector re-do the packet decode.
 The mental picture I had was that an L3 router would be able to export
sampled_header, sampled_ethernet, and sampled_ipv4/sampled_ipv6...based
on the text in the bottom half of p. 33 of the sFlow version 5 standard.
 Perhaps I misinterpreted your intent there?

The bottom of page 34 describes the use of the header structures:

/* Flow Data Types

   A flow_sample must contain packet header information. The
   prefered format for reporting packet header information is
   the sampled_header. However, if the packet header is not
   available to the sampling process then one or more of
   sampled_ethernet, sampled_ipv4, sampled_ipv6 may be used. */

 A few reasons for the decision:

1. Avoiding ambiguity. What happens if the fields in the decoded header don't match the fields in the packet header? Why trust the vendor supplied decoder when you can decode the headers yourself? In a hardware based router the fields aren't readily available. The sFlow agent would need to have code that mimicked the hardware packet parser. It's much easier to fix bugs in the sFlow analyzer than it is to change the firmware in the sFlow agent.

2. Network traffic is often deeply layered with multiple layer 2/3 tunnels. The packet header unambiguously provides a view of the layers and their attributes that allows the sFlow analyzer to properly report on traffic even though the device that captured the header may only be aware of and operating at one of the layers.

3. The general design sensibility with sFlow is to keep the sFlow agent as simple as possible and shift as many functions to the collector as possible. This decision helps future proof the standard. For example, all sFlow agents can report on VxLAN traffic, even those that pre-date the VxLAN standard.

I looked through sflowtool.  From a casual read of the code it looks
like if it's configured to emit NetFlow records, it generates one
NetFlow record for every sFlow packet sample, in other words it's not
doing any of the flow cache functionality that a NetFlow exporter would
normally do.  

Your understanding is correct. However, given typical sFlow sampling rates (1-in-1000, 1-in-10,000, ...) the hit ratio for a NetFlow cache would be very low when exporting the 5-tuple NetFlow records that sflowtool generates and so the complexity of maintaining a cache (and the resulting delay in sending the NetFlow record) doesn't seem like a win.

So as with the sFlow architecture in general, it's
accepting the cost of a higher data rate between the exporter and the
collector in favor of exporting more detail on individual packet samples
(not aggregated in time) and potentially simpler logic on the collection
device.  Is that correct?

Given typical configurations for sFlow and NetFlow, it is not clear that sFlow has the higher data rate. There are a number of factors that come into play when comparing the scaleability of the two monitoring approaches, including: data rate, operational complexity, linearity, robustness, measurement latency, resource usage (both in the agent and on the collector), etc. 

[Bruce A. Mah]

If memory serves me right, Peter Phaal wrote:

> The bottom of page 34 describes the use of the header structures:

[snip]

Hi Peter--

Many thanks for the detailed explanation and rationale! I might have
some other questions later but for now I'm going to go away and digest
this for awhile.

Best,

Bruce.