Arista EOS sFlow Configuration and Verification

sFlow gives you traffic visibility on switches that cannot export NetFlow-style flow records, because sampling happens in hardware and the accounting is statistical rather than per-flow. On Arista EOS it is a five-command configuration, but the two numbers inside it - sample rate and polling interval - decide whether the data is useful or misleading. This guide covers the agent parameters, per-interface control, egress sampling on supported platforms, and the verification output that confirms the agent is actually sampling rather than merely configured.

What sFlow is and is not

An sFlow agent embeds in the switch, samples packets statistically and combines those samples with periodic interface counter polls, then sends both to an sFlow collector as datagrams - UDP 6343 by default. It requires no collector software on the switch, has minimal CPU cost, and does not affect data-plane forwarding. What it cannot do is give you an exact per-flow byte count: extrapolation from samples is accurate across volume and trends, not for small numbers of packets. Anyone reconciling sFlow figures against interface counters to the byte is using the wrong tool.

The configuration

switch(config)# sflow destination 10.0.0.100 6343
switch(config)# sflow source-interface Loopback0
switch(config)# sflow sample 1024
switch(config)# sflow polling-interval 30
switch(config)# sflow run

Four parameters carry all the design weight:

• destination - collector address and port. Without a destination, the switch samples and discards the datagrams.
• source-interface - the address in the exported datagram's header. Using a loopback makes the device identity stable across uplink changes.
• sample rate - one packet out of every N. 1024 is a reasonable high-fidelity setting for a busy aggregation port; the default is far coarser (1048576 in some builds). Raise the rate on low-traffic ports and lower it on the busiest ones - sampling a 10G port busy with small packets at a coarse rate produces unusable statistics.
• polling-interval - seconds between counter samples. 30 seconds is a practical balance between resolution and datagram volume; default values as low as 2 seconds generate a lot of traffic on a large fabric.

Per-interface control

switch(config)# sflow run
switch(config)# interface Ethernet10
switch(config-if-Et10)# no sflow enable
switch(config)# interface Ethernet20/1
switch(config-if-Et20/1)# sflow enable

sflow run enables sampling globally and, by default, on every interface. sflow enable only matters on interfaces where you have previously disabled it - it has no effect while sFlow is globally off, which is why a configuration that appears correct can produce no data.

Egress sampling and BGP extension

switch(config)# sflow interface egress enable default
switch(config)# interface Ethernet1
switch(config-if-Et1)# no sflow egress enable
switch(config)# sflow extension bgp
switch(config)# sflow datagram size maximum 1500

Ingress sampling answers "who is sending this to me"; egress sampling answers "where is it going", and not all platforms support it in hardware - check before designing around it. The BGP extension attaches routing-table context to samples for BGP-destined traffic, and the datagram size setting avoids fragmentation when the path MTU is below default assumptions.

Verification

switch# show sflow
switch# show sflow interfaces
switch# show sflow interfaces detail
switch# show sflow hardware status

show sflow interfaces reports per-interface state as running, partial or inactive - partial on a port channel means some members are operational and others are not, and inactive on an egress-configured interface means egress sampling is configured but not operational on that hardware. show sflow hardware status tells you whether acceleration is active; if hardware acceleration is off, sampling still works but runs in software and the achievable rate is limited.

Collector-side sanity checks

Confirm the collector is receiving datagrams from the source address you configured, then sanity-check the extrapolation: on a link with a known sustained rate, sampled volume times the sample rate should track the interface counters within a reasonable margin. Persistent mismatch usually means the sample rate on that port does not match the actual traffic profile. For flow-based accounting rather than sampling, compare with Cisco Flexible NetFlow, and for pipeline context see Arista EOS interface error counters.

原文链接：https://www.arista.com/en/um-eos/eos-sflow