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+l...@pmacct.net<pl%2bl...@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.mc...@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.ph...@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-sf...@sflow.org [mailto:owner-sf...@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 < > fedoraf...@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
