Re: one sample question

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://
www.sflow.org/SFLOW-DATAGRAM5.txt and http://www.sflow.org/SFLOW-
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
user-authentication:

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.

Regards,
Neil

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
> <peter.phaal@inmon.com> 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: owner-sflow@sflow.org [mailto:owner-sflow@sflow.org] On
>>> Behalf Of
>>> sujay gupta
>>> Sent: Thursday, October 29, 2009 8:30 AM
>>> To: fedora fedora
>>> Cc: sflow@sflow.org
>>> 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 slow.org 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
>>> <fedorafans@gmail.com>
>>> 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