sFlow vs netFlow/IPFIX

Wed Mar 2 22:37:19 UTC 2016

On Wed, Mar 2, 2016 at 9:30 AM, Nick Hilliard <nick at foobar.org> wrote:
> Peter Phaal wrote:
>> The Nexus 3200 should work well with 100G flows - I believe it's
>> based on the latest Broadcom Tomahawk ASIC. The older Trident II
>> ASICs in the Nexus 9k are 40g parts
>
> does nx-os still force ingress-and-egress sflow?  sflow is pretty
> useless you can define an accounting perimeter, which means that you
> need either ingress across the board, or egress.  ingress-and-egress is
> basically useless because you end up double counting everything.

Monitoring ingress and egress in the switch is wasteful of resources.
In most use switch  use cases (a leaf / spine fabric for example) the
next hop switch will also be reporting ingress sFlow and so when you
combine sFlow streams from both switches you get bi-directional
visibility into every link. Enabling ingress only sFlow on all switch
ports catches all packet paths and halves the overhead of
bi-directional sampling.

The sFlow architecture shifts intelligence from the devices to
external software. The goal is to have a general purpose telemetry
stream that can be used for a variety of purposes. Rather than having
the complexity of configuring sFlow selectively at the sender, the
receiver is responsible for de-duplicate the sFlow stream for
accounting (the packet stream selection and elimination you are doing
in the switch configuration can equally be applied on receipt).
Shifting the decision to the collector means you can also use the
stream to diagnose performance problems (for example identifying top
flows on a busy link), traffic engineering of large flows, etc. If the
sender is configured to suite one application, you limit the value of
the measurements for other applications.

An often overlooked feature of sFlow is that the agent also
periodically sends interface counters (reducing or eliminating the
need for SNMP polling in many use cases). The counters and packet
samples are tied together in the sFlow data model - for example you
can use the interface speed information from the counter samples to
compute utilizations based on the packet sample stream etc). Broadcom
also defined sFlow metrics to provide additional visibility into the
ASIC forwarding pipeline (layer 2 / layer 3 / ACL table utilization,
buffer utilization, microburst detection) and the inclusion of these
metrics with the samples packet data in the sFlow telemetry stream
provides a way to identify the traffic that is consuming the hardware
resources.