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