Re: one sample question

Hi,

Some of the so-called additional structures are actually supported by pmacct,
ie. source or destination AS (extended gateway) or VLAN tag (extended switch).

L7-classification using the sampled header is also feasible (as the bulk of
the work is already available for the promiscuous mode daemon) but currently
not implemented.

In essence, we strive to support sFlow at our best, it's like that for some
years now. Feel free to drop me an email to say what precisely you want to
achieve (as this is not the best place to specifically discuss about pmacct)
and let's discuss about it.

Cheers,
Paolo

On Thu, Oct 29, 2009 at 02:56:52PM -0500, fedora fedora wrote:
> 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 13:41:48 2009