On Wed, Mar 2, 2016 at 9:30 AM, Nick Hilliard <nick@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.