sFlow vs netFlow/IPFIX
bedard.phil at gmail.com
Mon Feb 29 15:40:59 UTC 2016
From: NANOG <nanog-bounces at nanog.org> on behalf of Saku Ytti <saku at ytti.fi>
Date: Monday, February 29, 2016 at 08:31
To: Nick Hilliard <nick at foobar.org>
Cc: nanog list <nanog at nanog.org>
Subject: Re: sFlow vs netFlow/IPFIX
>On 29 February 2016 at 15:05, Nick Hilliard <nick at foobar.org> wrote:
>> depends on what you define by "cheap". Netflow requires separate packet
>> forwarding lookup and ACL handling silicon.
>That's not inherently so, it depends how specialised your hardware is.
>If it's very specialised like implementing just LPM, sure. If it's
>NPU, then no, that's not given.
I don’t think anyone uses dedicated Netflow HW these days. The ASICs have functionality for other things like mirroring, etc. which are augmented for Netflow use. Usually it’s a mix of dedicated functions in the ASICs and then the LC CPU and general CPU on some platforms. Really in the end the router is doing something like SFlow internally.
>The cost is many entries in the hash table, not updating them. But if
>you'd emulate sflow behaviour in IPFIX then you don't need the hash
>tables or the counters.
It would be interesting to get some data from vendors on what the actual limitation is. I know with some new platforms like the NCS 55XX from Cisco (BRCM Jericho) it has limited space for counters, but I don’t know if that contributes to its minimum 1:8000 Netflow sampling rate. The new PTX FPC supporting Netflow has a minimum of 1:1000.
More information about the NANOG