RE: sampling of incoming/outgoing traffic

The section that Jay refers to in RFC 3176 is a little vague. However, this
was clarified in the specifications for sFlow v5 section 3.1, see
http://www.sflow.org/sflow_version_5.txt (In common with most new sFlow
implementations, Force10 implements sFlow v5).

The scope of the description of flow sampling is a single data source. A
single data source may not sample the same packet multiple times, but other
data sources on the same device or on other devices may observe and sample
the same packet. This restriction allows for the accurate scaling of
measurements from a single data source. It is up to the sFlow collector to
decide how to combine data from multiple data sources and how to avoid over
counting. sFlow records provide sufficient information for the collector to
perform the duplicate removal function.

The sFlow specification allows for inbound, outbound or inbound and outbound
sampling. The specific choice is made by the implementor and will normally
depend on the switching architecture.

In general we suggest that you enable sFlow on all interfaces. In the case
of the switches that monitor inbound (or outbound) only traffic, this is
especially important since this will enable outbound (or inbound) traffic to
be inferred by the sFlow collector.
  

> -----Original Message-----
> From: owner-sflow@sflow.org [mailto:owner-sflow@sflow.org] On
> Behalf Of Jay A. Kreibich
> Sent: Thursday, November 17, 2005 1:03 PM
> To: Juraj Sucik
> Cc: sflow@sflow.org
> Subject: Re: [sFlow] sampling of incoming/outgoing traffic
>
> On Thu, Nov 17, 2005 at 12:17:54PM +0100, Juraj Sucik
> scratched on the wall:
> > Hello,
> >
> > I've read a specification of Sflow (RFC 3176), but it is
> not clear if
> > the inbound, outbound or both direction traffic is sampled.
>
> For any given system, traffic should only be sampled once as
> defined by the sFlow concept of a "flow." The RFC is not specific
> about if this is inbound or outbound for a given interface-- I think
> the authors assumed sFlow was on for all interfaces or it wasn't.
> That kind of leaves per-interface semantics up to the
> implementation.
> Force 10 is nice enough to keep all their manuals behind closed
> doors, so I wasn't able to do any additional research.
>
> In general, however, the RFC seems to indicate this sampling
> should happen in the forwarding engine before the traffic is passed
> to the outbound interfaces. In other words, we need to know that A)
> the traffic WILL be forwarded (or at least attempted), and B) what
> interface we are going to forward it to, but we don't actually have
> to outbound queue the traffic before the sample is taken:
>
> RFC 3176, Section 2.1, PP 2:
>
> Sampling flows is accomplished as follows: When a packet
> arrives on an interface, a filtering decision is made that
> determines whether the packet should be dropped. If the
> packet is not filtered a destination interface is assigned
> by the switching/routing function. At this point a
> decision is made on whether or not to sample the packet.
>
> In fact, the paragraph before this warns that outbound
> interfaces are
> likely a bad place to do sampling, because broadcast and multicast
> traffic may have multiple outbound interfaces, which would
> statistically increase the likelihood of broad/multi-cast traffic
> being sampled (and that's a no-no, according to the spec).
>
> This isn't to say that Force10's system is wrong-- they might define
> per-interface semantics as outbound, but still do the (correct)
> sampling within their forwarding engine. To be honest, I'd have my
> doubts, however. If you need specific information on the flow
> selection system, I suggest you contact a sales engineer.
>
> > I have enabled sflow on one of interfaces (lets' call it
> interface A)
> > in Force10 E1200 router, but it seems router samples only outgoing
> > traffic from that interface. Do I need to enable sflow on the other
> > interfaces as well if I want to have packets incoming to
> interface A
> > sampled (although sampled on a different interface)?
>
> It would appear so, in this case. The sFlow concept of a flow and
> how they are sampled doesn't force an inbound/outbound
> situation (you
> could, in theory, build an sFlow engine that sampled every flow that
> "involved" interface A, rather than was inbound OR outbound
> for it), but
> most hardware systems are likely to attach a direction to enabling
> sFlow on specific interfaces.
>
> -j
>
> --
> Jay A. Kreibich | CommTech, Emrg Net Tech Svcs
> jak@uiuc.edu | Campus IT & Edu Svcs
> <http://www.uiuc.edu/~jak> | University of Illinois at U/C
Received on Fri Nov 18 09:19:12 2005