Real world sflow vs netflow?

Peter Phaal peter.phaal at gmail.com
Sun Sep 23 04:43:01 UTC 2012


On Sat, Sep 22, 2012 at 4:41 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> You have misinterpreted what I said.  I was saying that flow telemetry of any
> variety must be exported from edge devices, which in most cases are routers
> (in some cases layer-3 switches), in response to your 'move it out of the router'
> comment.

I am sorry I misunderstood your comment, I agree that it is important
to gather telemetry directly from your edge devices. The comment "move
it out of the router" referred to the location of the flow-cache in
the following scenario.

On Thu, Sep 20, 2012 at 11:21 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so,
> and then I don't really see the fundamental difference in doing the flow
> analysis on the router itself (classic netflow) or doing the same but at the
> sFlow collector.

In both cases the router is generating the telemetry, in the netflow
case, packets are sampled on the router, the router builds flow
records based on the contents of the sampled packets, and the flow
records are exported. In the sFlow case, the raw sampled packet
headers are exported to external software which builds flow records.
In both cases the router is making the primary measurements and you
end up with the same measurements.

On Fri, Sep 21, 2012 at 10:02 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> Actually, moving it out of the router creates huge problems and destroys a lot of
> the value of the flow telemetry - it nullifies your ability to traceback where traffic is
> ingressing your network, which is key for both security as well as traffic
> engineering, peering analysis, etc.
>
> It is far, far better to get your flow telemetry from your various edge routers, if at
> all possible, rather that probes.  Scales better, too - and is less expensive in
> terms of both capex and opex.

I agree completely, probes are expensive, difficult to manage and
can't accurately tell you how the traffic passed through the router.




More information about the NANOG mailing list