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