sFlow vs netFlow/IPFIX

Mon Feb 29 15:40:59 UTC 2016

-----Original Message-----

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.   

Phil 