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: https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/CAPTURE_BACKEN...
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).
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
If you just need to count traffic and you accept pretty long reaction time and not enough accurate traffic bandwidth data you could select netflow. 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 aggregation. On Mon, Feb 29, 2016 at 5:41 AM, <Valdis.Kletnieks@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