[187935] in North American Network Operators' Group
Re: sFlow vs netFlow/IPFIX
daemon@ATHENA.MIT.EDU (Saku Ytti)
Mon Feb 29 07:12:16 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
Date: Mon, 29 Feb 2016 14:12:13 +0200
From: Saku Ytti <saku@ytti.fi>
To: Todd Crane <todd.crane@n5tech.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 28 February 2016 at 22:06, Todd Crane <todd.crane@n5tech.com> wrote:
> This maybe outside the scope of this list but I was wondering if anybody =
had advice or lessons learned on the whole sFlow vs netFlow debate. We are =
looking at using it for billing and influencing our sdn flows. It seems lik=
e everything I have found is biased (articles by companies who have commerc=
ial offerings for the "better" protocol)
I view sflow as subset of NetflowV9 V10/IPFIX. You could produce sflow
behaviour in IPFIX, by adding record of packet sample, and exporting
immediately instead of keeping state of flows.
However you couldn't produce IPFIX behaviour in sflow, inherently so.
sflow is older than IPFIX (v10) or v9 netflow, and I'm guessing no one
would invent sflow today, they'd instead specify some restricted IPFIX
with same behaviour.
I completely understand why sflow was needed netflowv5 time, but I
don't really see much point there now. It just means that collectors
need to be more complicated than they must, by having two parsers.
--=20
++ytti
