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
