sFlow vs netFlow/IPFIX

Peter Phaal peter.phaal at gmail.com
Thu Mar 3 18:23:24 UTC 2016


On Thu, Mar 3, 2016 at 9:16 AM, Nick Hilliard <nick at foobar.org> wrote:
> 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.

I completely agree that you don't want to maintain two sets of
configurations (switch and collector) that need to be updated.
However, it's much better to focus on minimizing switch configuration
complexity than it is to focus on reducing analyzer software
configuration complexity.

If you push the problem of de-duplication to the switch configurations
then you end up with VxT sets of switch configuration in a
multi-vendor network (where T is the number of topologically different
wiring configurations used for the switches and V is the number of
vendors - actually it can be even worse, since each vendor product
line might have different configuration options, CatOS vs NX-OS for
example). Adopting a standard sFlow agent configuration in which
monitoring is enabled on all switch ports with policy based default
sampling rates (a good default sampling rate = port speed in gigabits
per second x 1000. e.g. 1-in-10,000 on a 10G port) greatly simplifies
large scale sFlow deployments. Now instead of maintaining and updating
VxT configurations in thousands of switches, there are only V switch
configurations that are installed when the switches are initially
provisioned and remain static over the lifetime of the network.

Updating the single, central configuration of the sFlow analyzer
software is much simpler and easily automated. It also makes it much
easier to roll out new analytics capabilities since they are simply
configuration and software updates to the central collector and don't
require building, testing and deploying configurations to all the
devices.



More information about the NANOG mailing list