Dell SmartFabric OS10 sFlow: Configuration and Analysis

sFlow is the cheapest useful visibility you can add to a switch: no licensing, minimal CPU, and it covers every port including the ones you would never mirror. On Dell SmartFabric OS10 it is a small configuration - a collector, a source interface, and the decision of whether to sample globally or on selected interfaces. The interesting part is not the configuration, it is the sample rate and the analysis, because a badly sized sFlow deployment produces either unusable data or measurable CPU load for no benefit.

What sFlow Gives You That Mirroring Cannot

• Fabric-wide coverage. A SPAN session mirrors a port or a VLAN and consumes a destination port. sFlow samples across every interface on the switch simultaneously.
• Flow detail at line rate. Each sample carries the packet header, so you get source, destination, protocol, ports and VLAN without a full copy of the traffic.
• Interface counters alongside flows. sFlow datagrams include counter samples for the interface, which is why a single collector can give you both traffic detail and utilisation.

The trade-off is statistical: you see a sample, not every packet. That is fine for top-talkers, capacity planning, and detecting a scanning host. It is not suitable when you need to prove that a specific single packet was dropped - that is a job for SPAN or ERSPAN, and the equivalent OS10 configuration for port mirroring is covered in this OS10 port monitoring guide. The differences between sFlow, NetFlow and IPFIX, including which one is sampled and which is flow-cached, are set out in this comparison guide.

Configuration

sFlow can be enabled globally on all interfaces or on a specific set, and the system rejects the configuration if you try to apply it where it cannot run - for example on interfaces that do not support sampling on that platform. Start with the source interface and collector, then choose the scope.

OS10# configure terminal

! 1. which interface the datagrams leave from, and where they go
OS10(config)# sflow source-interface vlan 100
OS10(config)# sflow collector 10.20.30.40 agent-addr 10.20.30.9

! 2. global sampling and polling parameters
OS10(config)# sflow max-header-size 128
OS10(config)# sflow polling-interval 30
OS10(config)# sflow sample-rate 2048

! 3. enable globally on all interfaces
OS10(config)# sflow enable

! -- or scope it to the interfaces that matter --
OS10(config)# no sflow enable
OS10(config)# interface ethernet 1/1/49-1/1/54
OS10(conf-if-range-eth1/1/49-1/1/54)# sflow enable
OS10(conf-if-range-eth1/1/49-1/1/54)# sflow sample-rate 1024
OS10(conf-if-range-eth1/1/49-1/1/54)# exit
OS10(config)# end
OS10# write memory

The three parameters that decide whether the data is useful:

Uplinks usually deserve a lower sample rate than access ports, because they carry more traffic - the number you are really choosing is samples per second, not the ratio. 1:2048 at 10 Gbps on a saturated port produces a lot of datagrams; 1:2048 on an idle access port produces almost none.

Verification

OS10# show sflow
OS10# show sflow interface ethernet 1/1/49
OS10# show sflow statistics
OS10# show running-configuration | grep sflow

! the collector side - confirm datagrams actually arrive and decode them
tcpdump -i eth0 -n udp port 6343 -c 5
sflowtool -l -p 6343
sflowtool -p 6343 | head -40

sflowtool is the fastest sanity check on the receiving end. If the collector host sees datagrams but the switch statistics show no packets sent, the problem is the export path (source interface reachability, VRF, ACL). If the switch counts exports and the host sees nothing, look at the path between them.

Export Path Problems

1. Source interface must be reachable from the collector's perspective. If the source interface is a loopback or a management VLAN that the collector cannot route to, datagrams are sent and lost. Use an interface in the same address family and reachability domain as the collector.
2. Management VRF. On OS10 the out-of-band management interface lives in its own VRF. An sFlow source interface in the default VRF may not be able to reach a collector on the management network, and vice versa. Decide which network the collector is on and match it.
3. ACLs and firewalls. sFlow uses UDP 6343. It is common to find an ACL on the management segment that permits SNMP and SSH and silently drops sFlow.
4. Datagram loss under CPU pressure. sFlow export is best-effort. On a switch with a high control-plane load, exports are dropped preferentially. If your data has gaps that correlate with busy periods, the collector is not the problem.

Analysis That Produces Answers

sFlow is only worth the configuration if someone reads it. The four questions it answers well:

• Who is using the bandwidth? Top source-destination pairs over an hour, which identifies both the legitimate backup job and the unexpected file transfer.
• Where is the multicast coming from? Sample data with group and source addresses pinpoints a misconfigured sender faster than walking every switch.
• Is traffic leaving the VLAN it should? Sampled VLAN tags expose a trunk misconfiguration at the boundary between two teams' responsibilities.
• Is something scanning? Many short flows to many destinations from one source is the classic signature, and it is visible at a low sample rate because the flow count is high.

Start with uplinks. A 1:8192 sample rate on six uplinks will tell you more about your network than 1:4096 on all forty-eight access ports, at a fraction of the datagram volume - and it keeps the sample history meaningful for capacity planning.

Practical Defaults

! a defensible starting configuration for a S4148/S5248 access switch
sflow collector 10.20.30.40 agent-addr 10.20.30.9
sflow source-interface vlan 100
sflow polling-interval 30
sflow max-header-size 128
interface ethernet 1/1/49-1/1/54
  sflow enable
  sflow sample-rate 8192
interface range ethernet 1/1/1-1/1/48
  sflow enable
  sflow sample-rate 8192

Two things worth doing alongside sFlow: keep SNMPv3 based device polling for the counters you need at high resolution, since the polling-interval in sFlow is deliberately coarse - the configuration approach is in this OS10 SNMPv3 guide - and ensure the collector host is not also the one you rely on for configuration backups. Visibility and recovery should not share a single point of failure. The same protocol choices and sampling trade-offs apply on other platforms, and the Arista equivalent is a useful cross-check when you are standardising across a mixed estate, as described in this Arista EOS sFlow guide.

原文链接：https://www.dell.com/support/manuals/en-us/smartfabric-os10-emp-partner/smartfabric-os-user-guide-10-5-6/enable-sflow%C2%AE?guid=guid-51d7b51d-b135-4759-83ad-a2d40db5e997&lang=en-us