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.