Re: sFlow vs netFlow/IPFIX

[Peter Phaal <peter.phaal () gmail com>]

On Wed, Mar 2, 2016 at 2:45 PM, Nick Hilliard <nick () foobar org> wrote:
> Peter Phaal wrote:
> > Monitoring ingress and egress in the switch is wasteful of resources.
>
> It's more than a waste of resources:  it's pathologically broken and
> Cisco decline to fix it, despite the fact that enabling ingress-only or
> egress-only is fully supported via API in the Broadcom SDKs, and
> consequently the amount of configuration glue required to fix it in
> NX-OS is nearly zero.
>
> Broadcom chipsets don't support netflow, so sflow is the only game in
> town if you need data telemetry on broadcom-based ToR boxes.
>
> As I said in a previous email on this thread, refusing to support this
> properly is a harmful and short sighted approach to customers' requirements.

I think "pathologically broken" somewhat overstates the case.
Bidirectional sampling is allowed by the sFlow spec and other vendors
have made that choice. Another vendor used to implement egress only
sampling (also allowed) but unusual. I agree that ingress is the most
common and easiest to deal with, but a decent sFlow analyzer should be
able to handle all three cases without over / under counting.

More annoying is differences in how vendors report telemetry from LAG
/ MLAG topologies. The "sFlow LAG Counters Structure" extension was
published in 2012 and defines how counters and samples should be
generated on LAGs. Anyone with using LAG / MLAG topologies might want
to ask their vendor if they support / plan to support the extension.