sFlow vs netFlow/IPFIX

Pavel Odintsov pavel.odintsov at gmail.com
Mon Feb 29 07:26:16 UTC 2016

Hello, folks!

I've huge experience for battle sflow vs netflow because in my free
DDoS detection toolkit fastnetmon we support both capture methods.

You could look at this comparison table:

>From my own experience sflow should be selected if you are interested
in internal packet payload (for dpi / ddos detection) or you need fast
reaction time on some actions (ddos is best example).

If you just need to count traffic and you accept pretty long reaction
time and not enough accurate traffic bandwidth data you could select

>From hardware point of view almost all brand new switches support
sflow free of charge (no additional licenses or modules). But be
aware, Cisco do not support this protocol at all (that's pretty weird,
really). Also keep in mind sflow implemented in hardware ASIC with
small help from CPU and it's pretty fast and suitable for really any
traffic bandwidth.

I have experience with sflow analytics for 1.5 Tb+ network and it's
working really well!

For netflow sometimes you need additional modules / software licenses
and sometime devices completely haven't support for it. And if you
have software devices (for example small SRX routers from Juniper)
netflow generation will be pretty expensive from CPU point of view
because netflow need pretty big amount of CPU resources for

On Mon, Feb 29, 2016 at 5:41 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said:
>> On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:
>> > Around here they are currently voting on a law that will require unsampled
>> > 1:1 netflow on all data in an ISP network with more than 100 users.
>> That's interesting, given that most larger routers don't support 1:1.
> In the war between reality and governmental paranoia, reality usually loses.

Sincerely yours, Pavel Odintsov

More information about the NANOG mailing list