sFlow packet format : need more explanation

[alain.BCR]

Hi,

I try to find a document that can tell me what is a valid sFlow
packet.
When I look at this kind of packet using WireShark, I see that the UDP
packet contains the following:
1- a small sFlow header
2 - a set of Expanded flow sample (sometime 1, more often 3 or 4).

Each Expanded flow sample contains :
1 - another header (specific to this sample ?)
2- different subset like 'Extended switch data', 'IPV4 data', Ethernet
frame data' or 'Raw packet data'.

I cannot find a document that explain what are valid informations that
can be contained inside a sFlow packet. Is there any rule to follow ?
Is there any groups of data that we cannot mix inside the same
packet ?

If somebody can help me, it will be great !

Regards

[Peter Phaal]

On Wed, Aug 24, 2011 at 3:29 AM, alain.BCR <alai...@gmail.com> wrote:
> Hi,
>
> I try to find a document that can tell me what is a valid sFlow
> packet.

The best place to start is the sFlow specifications page - under
Developer Information on sFlow.org:

http://www.sflow.org/developers/specifications.php

> When I look at this kind of packet using WireShark, I see that the UDP
> packet contains the following:
> 1- a small sFlow header
> 2 - a set of Expanded flow sample (sometime 1, more often 3 or 4).
>
> Each Expanded flow sample contains :
> 1 - another header (specific to this sample ?)
> 2- different subset like 'Extended switch data', 'IPV4 data', Ethernet
> frame data' or 'Raw packet data'.

From the sFlow version 5 spec:

/* 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. */

In practice, all current implementations of sFlow that I am aware of
have access to packet headers
and so report the sampled_header structure. The sampled_ethernet,
sampled_ipv4 and sampled_ipv6 aren't used (the information is all in
the sampled header).

>
> I cannot find a document that explain what are valid informations that
> can be contained inside a sFlow packet. Is there any rule to follow ?
> Is there any groups of data that we cannot mix inside the same
> packet ?

There extended_* structures are optionally included with each sampled packet:

/* Extended Flow Data

Extended data types provide supplementary information about the
sampled packet. All applicable extended flow records should be
included with each flow sample. */

The extended structures contain information that isn't in the packet
header but is known to the
network device (e.g. port VLAN/priority, subnet masks, BGP AS-path,
MPLS tunnel etc.)

In addition to packet headers and related information, sFlow also
exports network interface
counters. Similar to packet samples, there is a generic set of
counters that is supplemented by
additional media specific counters.

/* Counter Data Types

Wherever possible, the if_counters block should be included. Media
specific counters can be included as well. */

[alain.BCR]

Hi Peter,

thank you for your help !
As I understand, an Expanded Flow Sample (enterprise = 0, format = 3)
can include any kind of Flow Record like 'Raw Packet Header',
'Ethernet frame Data', 'IPV4 data' or all of them !
Is there any rule that prevent two Flow Record be be inside the same
Flow Sample ?

I ask this question because I feel that is unecessary to get, for
example, the Raw Packet Header and the IPV4 data in the same sample :
the Raw Packet Header is enough, it is not ?

Regards

On 24 août, 16:01, Peter Phaal <peter.ph...@gmail.com> wrote:

[Peter Phaal]

On Mon, Aug 29, 2011 at 7:29 AM, alain.BCR <alai...@gmail.com> wrote:
> Hi Peter,
>
> thank you for your help !
> As I understand, an Expanded Flow Sample (enterprise = 0, format = 3)
> can include any kind of Flow Record like 'Raw Packet Header',
> 'Ethernet frame Data', 'IPV4 data' or all of them !
> Is there any rule that prevent two Flow Record be be inside the same
> Flow Sample ?

The section of the sFlow version 5 specification that I included in my
previous reply addresses this topic. The standard requires that the
sampled_header structure be used if the packet headers are available
to the sFlow agent and only allows the sampled_ethernet, sampled_ipv4,
and sampled_ipv6 structures to be used when packet headers are not
available.

If a packet header is included, then you will have one flow record and
any applicable extended flow records. If the packet header is not
available, then you would typically have two flow record structures,
sampled_ethernet + (sampled_ipv4 or sampled_v6) along with any
applicable extended flow records.

>
> I ask this question because I feel that is unecessary to get, for
> example, the Raw Packet Header and the IPV4 data in the same sample :
> the Raw Packet Header is enough, it is not ?

I is unnecessary, can result in ambiguity, and the specification
doesn't allow it.

[Peter Phaal]

Please see my reply to the previous thread, the problem appears to be the unknown headerProtocol.

On Friday, March 7, 2014 11:11:07 AM UTC-8, Mandakini Nayak wrote:

I have another question here.

I have a set up where i have a switch on which sflow is configured and it is connected with the server and client which generates traffic that passes through the switch.

But when i try to see the sflow packets through any tool , say Wireshark for example then i only see ,

datagram header version: V5 IP address: agent (IP_V4) 10.10.99.-50 subagent ID: 0 datagram sequence number: 80 switch up time: 794000 samples in datagram: 1

  

counter sample: sequence: 18580 source id type: source id type: IFINDEXindex: 13 number counter records: 1 Generic Interface Counters: ifInOctets: 0 ifInUcastPkts: 8 ifInMulticastPkts: 0 ifInBroadcastPkts: 4294967295 ifInDiscards: 0 ifInErrors: 0 ifInUnknownProtos: 4294967295 ifOutOctets: 0 ifOutUcastPkts: 3316055206 ifOutMulticastPkts: 4294967295 ifOutBroadcastPkts: 4294967295 ifOutDiscards: 0 ifOutErrors: 0ifPromiscuousMode: 0

flow sample: sequence: 5167 source id type: source id type: ENT_PHSICAL_ENTRYindex: 1000 number flow records: 2 sampleRate: 64 samplePool: 330688 drops: 0 input: 7 output: -2147483644 ExtendedSwitchdata:  srcVlan: 0 srcPriority: 0 dstVlan: 0 dstPriority: 0 Raw packet header: headerProtocol: UNDEFINED (0) frameLength: 443 stripped: 4 headerData: 3333000000FB001CC448992C86DD60000000018111FFFE80000000000000021CC4FFFE48992CFF0200000000000000000000000000FB14E914E9018135AC0000000000040000000700001A7465737465722D50726F4C69616E742D444C3336302D47352D320B5F756469736B732D737368045F746370056C6F63616C0000FF00

Why i donot see any IPV4 packet data, vlan data, process information data, or other flowsample data in the packets?

Am i missing any configuration?

Do i need to enable something through some command?

Is there anything missing in the switch or kernel side?

Thanks in advance.

[Peter Phaal]

The sFlow specification requires that the packet header be exported
whenever possible - the Ethernet / IPv4 / IPv6 records are only
exported if hardware limitations make it impossible for the sFlow
agent to export the packet header.

The sflowtool source code provides an example demonstrating decoding
Ethernet / IPv4 / IPv6 fields from the packet header.

On Thu, Mar 13, 2014 at 5:04 PM, nini <nayak.m...@gmail.com> wrote:
> Is there a way to receive the IPV4/IPV6 record other than getting it
> embedded in the packet header.
> I mean, is there a way we can simulate it, because i see it as part of the
> header all the time.
>
> What is the scenario when it does not come as part of the header and comes
> in as separate record?

>
>
> On Wednesday, 24 August 2011 03:29:04 UTC-7, alain.BCR wrote:
>>

> --
> You received this message because you are subscribed to the Google Groups
> "sFlow" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sflow+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.