Re: sFlow vs netFlow/IPFIX

[Phil Bedard <bedard.phil () gmail com>]

-----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