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
