Re: one sample question

From: Neil McKee <>
Date: 10/29/09
Message-Id: <>

When you send a sampled header, you can annotate it with additional
XDR-encoded structures. That's where you get to say more about the
sampled packet. If you are looking at the spec files http:// and
STRUCTS5.txt, then a typical flow_sample looks a bit like this:

struct flow_sample {
      struct sampled_header
      struct extended_switch

or if the packet was routed, you might see this:

struct flow_sample {
      struct sampled_header
      struct extended_switch
      struct extended_router

or if it was forwarded by an access-layer switch that keeps track of

struct flow_sample {
      struct sampled_header
      struct extended_switch
      struct extended_user

So the device can export a struct sampled_header, and then choose to
add whatever "struct extended_*" structs make sense. Because the
device is only doing this with randomly sampled packets, there is
enough time to dig around and add some really high-value measurements
in there. That's why you'll see the whole AS-Path from some devices
running BGP, or MPLS label-stacks and tunnel names from others.


On Oct 29, 2009, at 8:59 AM, fedora fedora wrote:

> thanks for all the replies, so all these L3 plus info must be
> included the
> 128Byte header then sflow can export them right?
> On Thu, Oct 29, 2009 at 10:51 AM, Peter Phaal
> <> wrote:
>> It's also worth pointing out that sFlow provides a mechanism for
>> the agent
>> to attach additional information to sampled packet. Typically this
>> will be
>> information about the forwarding decision (mpls tunnel, BGP
>> destination AS
>> path, subnets, VLANs etc.), but additional structures are also
>> defined to
>> allow the sFlow agent to export User ID's and URL's.
>> These application level fields are typically implemented when the
>> sFlow
>> device is a participant in the application level protocol. For
>> example, an
>> edge switch might be responsible for authenticating a user onto
>> the network
>> (possible using RADIUS). In this case it can attach User ID
>> information to
>> packet samples to or from a user's port. Similarly, a load
>> balancer might
>> be
>> aware of the URL associated with a packet stream and be in a
>> position to
>> attach the URL structure to any sampled packets from the stream.
>> Each device has its own perspective on the network traffic and
>> will only
>> contribute some of the extended information. However, sFlow is
>> intended to
>> monitor all devices and all ports in the network. By combining
>> information
>> contributed by each device, the central sFlow analyzer is able to
>> build a
>> complete picture. For example, a core switch might not know the
>> User IDs,
>> but when sFlow from the core switch is combined with sFlow from
>> the edge
>> switches, a complete picture emerges.
>> Peter
>>> -----Original Message-----
>>> From: [] On
>>> Behalf Of
>>> sujay gupta
>>> Sent: Thursday, October 29, 2009 8:30 AM
>>> To: fedora fedora
>>> Cc:
>>> Subject: Re: [sFlow] one sample question
>>> Hi,
>>> IMO, While your observation is correct, if the sampling rate is one,
>>> you should get all
>>> the packets and therefore any content in it.
>>> If it is not, the sample packet is a representation of the
>>> traffic and
>>> the assumption
>>> is if you have several samples at least of one of them will carry
>>> your
>>> required data.
>>> ( you could refer to a nice introduction to packet sampling theory,
>>> in the page)
>>> Please also note all the while that sFlow is not same as packet
>>> sniffing or port mirroring
>>> where you intent to capture every packet and parse it.
>>> It is a statistical measurement of the traffic flows happening
>>> thru your
>>> device.
>>> -Sujay
>>> On Thu, Oct 29, 2009 at 8:17 PM, fedora fedora
>>> <>
>>> wrote:
>>>> Hello, pardon me if this is too simple but i cannot find any
>>>> answer for
>>>> this.
>>>> Sflow is sample based, which means for every X number of packet,
>>>> 1 gets
>>>> picked and gets sent out to collector immediately, so in this
>>>> case, how
>>> can
>>>> this single packet includes all the fields necessary? for
>>>> example, for
>>> http
>>>> traffic, if the sampled packet does not carry URL, how can I
>>>> get URL?
>>>> similar case, for radius traffic, how can i get Username? It is
>>>> very
>>> likely
>>>> the sampled packet does not carry this information at all.
>>>> Am i wrong? Thanks
Received on Thu Oct 29 10:54:41 2009

This archive was generated by hypermail 2.1.8 : 02/17/10 PST