sFlow vs netFlow/IPFIX

Nick Hilliard nick at foobar.org
Thu Mar 3 17:16:25 UTC 2016


Peter Phaal wrote:
> sampled packet. A simple filter along the lines:
> 
> if ( sourceId.split(':')[1] != inputPort) return;

It's not a one-liner in practice.  It involves maintaining an array of
source ip + egressPorts with sflow enabled and (depending on how you
implement it) e.g. ensuring that all flow samples with a destination
port of one of the entries on the list is excluded from the flow
processing.  Alternatively, you can set up a full accounting perimeter
and lop off 50% of the packet and byte counts.

The beauty of sflow is that you can do anything in the collector, but
most people aren't going to do this because it means maintaining two
sets of data about your flow configuration: one set on the switch and
one set in your collector code which you've now diverged from the
mainstream distribution, thereby creating a requirement for future
maintenance, with associated costs.

Cisco could just fix the problem rather than lalala-ing about how it's
now a feature because it's been documented.  Broadcom's SDK makes it
simple to implement this and there is no technical reason for Cisco to
continue to decline to fix the problem.

Nick



More information about the NANOG mailing list