Re: one sample question

thanks a lot, i will start to try some pmacct stuff next week.

Much appreciated!

On Thu, Oct 29, 2009 at 3:41 PM, Paolo Lucente
<pl+list@pmacct.net<pl%2Blist@pmacct.net>
> wrote:

> 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 Fri Oct 30 14:00:54 2009