Re: one sample question

but how about the collector side? The collectors have to be able to see and
collect the additional info, i am going to try pmacct, and i don't see any
document mentioned this type of thing

On Thu, Oct 29, 2009 at 12:54 PM, Neil McKee <neil.mckee@inmon.com> wrote:

> 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 12:56:55 2009