-----Original Message----- From: NANOG <nanog-bounces@nanog.org> on behalf of Saku Ytti <saku@ytti.fi> Date: Monday, February 29, 2016 at 08:31 To: Nick Hilliard <nick@foobar.org> Cc: nanog list <nanog@nanog.org> Subject: Re: sFlow vs netFlow/IPFIX
On 29 February 2016 at 15:05, Nick Hilliard <nick@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. Phil