sFlow: Packet Sampling and Counter Polling for Switch Monitoring

01 /What sFlow is

sFlow monitors traffic in switched and routed networks by statistical sampling. It was specified in RFC 3176 in 2001 by engineers at InMon; the current wire format, sFlow version 5, is maintained by the sFlow.org consortium rather than the IETF. The goal was a monitoring function cheap enough to run in the forwarding ASIC of every port, so visibility scales with the network instead of depending on a few probes. It sits alongside SNMP and port mirroring in the monitoring toolkit: SNMP gives totals, mirroring gives every byte from one port, sFlow gives a statistically sound picture of everything.

Foundry Networks was among the first switch vendors to implement sFlow in hardware, around 2001, on the BigIron and FastIron families, and its sFlow technology page was widely cited.

02 /Packet sampling and counter polling

An sFlow agent does two things. Packet sampling: per interface, the ASIC counts packets and, on average once every N, copies the first bytes of a packet (typically 128, enough for Ethernet, IP and transport headers) with the input and output interface, the sampling rate and the running packet total. Counter polling: every polling interval (commonly 20 or 30 seconds) the agent exports the full interface counter set, the same octets, packets, errors and discards SNMP exposes.

03 /Sampling rate math

If the agent samples 1 in N and the collector receives c samples matching some class (say, traffic to one host), the estimated true packet count is c times N. The estimate is unbiased and its precision depends only on c, not on N or total traffic. The usual bound: relative error at 95 percent confidence is no worse than about 196 divided by the square root of c, in percent.

Practical rates: 1 in 512 on gigabit, 1 in 2048 to 4096 on 10 gigabit, coarser above. A busy 10 gigabit link at 1 in 2048 still yields hundreds of samples per second, plenty for top talkers within a minute.

04 /Agent, collector and datagram model

The agent is the process in the switch that packs samples and counters into sFlow datagrams. The collector listens on UDP port 6343, decodes them and stores or analyses the result. Each datagram carries the agent address and a list of flow and counter samples, packed up to the MTU. UDP is deliberate: a lost datagram costs a few samples, whereas a retransmission queue on the switch would be unacceptable. One agent can feed several collectors; one collector can serve hundreds of agents.

05 /A decoded sFlow sample, field by field

The quickest way to understand what a collector receives is to print one datagram as text. The open-source sflowtool decoder emits each field as a tag and a value, one per line, and the shape below follows its output. The datagram header names the agent and its uptime; each flow sample carries the sampling rate, the running packet count on that interface, the input and output ports and the first bytes of the frame; each counter sample carries the interface counters. Addresses are documentation ranges.

$ sflowtool -p 6343
unixSecondsUTC 1790240041
datagramVersion 5
agent 10.0.0.1
sysUpTime 993123000
packetSequenceNo 48211
samplesInPacket 7
sampleSequenceNo 1183307
sourceId 0:5
sampleType FLOWSAMPLE
meanSkipCount 2048
samplePool 2423412736
dropEvents 0
inputPort 5
outputPort 49
headerProtocol 1
sampledPacketSize 1514
headerLen 128
srcIP 203.0.113.45
dstIP 198.51.100.10
IPProtocol 6
IPTTL 54
TCPSrcPort 51844
TCPDstPort 443
TCPFlags 24

A worked estimate from the sample above: over sixty seconds the collector saw 412 samples from 203.0.113.0/24 to 198.51.100.10 port 443 at a rate of 1 in 2048. The packet estimate is 412 times 2048, about 844,000 packets, or roughly 14,000 packets a second. Multiply each sample's sampledPacketSize by 2048 and sum for bytes. The worst-case error at 95 percent confidence is 196 divided by the square root of 412, close to 10 percent, which is precise enough to say that one /24 is sending most of the traffic to that server and not precise enough to bill for it.

06 /sFlow versus NetFlow and IPFIX

07 /What you can see with sFlow

• Top talkers and conversations per interface, per VLAN or network-wide, updated within seconds.
• Protocol mix by port number, plus Layer 2 detail such as VLAN tag and MAC address, because the raw header is exported.
• Volumetric DDoS onset: a surge of samples toward one destination from many sources stands out within seconds, and the collector can trigger a null route or rate limit.

08 /Enabling sFlow on a switch

The general shape on IronWare-style switches, and on most others under different keywords: turn the agent on, point it at a collector, set a sampling rate and polling interval, then enable sample forwarding on the interfaces of interest.

sflow enable
sflow destination 10.0.0.50 6343
sflow sample 2048
sflow polling-interval 20
interface ethernet 1/1
 sflow forwarding
!
show sflow

Collectors range from open-source decoders and time-series stores to commercial analytics products; all accept standard sFlow v5 from any compliant agent. Start with one collector, one uplink and 1 in 2048, then widen. Check show sflow for incrementing sample and datagram counters, and confirm with a capture on the collector that UDP 6343 arrives from the agent. Sampled flows grouped by source prefix are also a cheap first pass at spotting AI crawler fleets in flow data, because a crawler operator shows up as many flows from a small set of published address ranges.

09 /What an sFlow sample can prove

A flow sample is a record that a frame with those headers crossed that interface on that agent at about that time. That is real evidence of presence, and a sequence of samples from one prefix is good evidence of a sustained flow. It is weak evidence of absence: at 1 in 2048 a short conversation may never be sampled, and a missing sample proves nothing. It is also unauthenticated. The datagram is plain UDP, so the agent address can be forged by anything that can reach the collector, and a lost datagram leaves a gap only the sequence number reveals. A sample under TLS shows addresses, ports and the TCP handshake, never a hostname or a user-agent.

Used with those limits stated, sFlow tells an investigator which prefix to look at and when. The identity behind the prefix comes from the bot verification checks in the provenance lane, reverse DNS with forward confirmation, published address lists and signed requests, and the request-level record that stands up to a dispute comes from edge logs kept as evidence, where each line names the client, the resource and the response. Keep the sFlow export with the same timestamps and retention as those logs, so the two can be laid side by side.

10 /Failure modes, pitfalls and expert tips

• Collector behind a stateful firewall. Agents send, collectors never reply, so idle-timeout logic sees a one-way flow and drops state; open UDP 6343 to the collector explicitly.
• Sampling on a LAG. Some platforms sample per member port, others per bundle. The rate reported in meanSkipCount is authoritative; the configured number is not.
• Rate changed mid-window. A collector that scales by the configured rate rather than the rate in each sample produces a step in every graph when someone changes N.
• Management CPU as the bottleneck. Sampling is in hardware, packing datagrams is not. On older units with 1 in 128 across 48 ports the CPU falls behind and dropEvents climbs. Coarser N on busy ports, finer on quiet ones.
• Tip: alert on the counters, drill with the samples. Counter polls give exact octet totals every 20 seconds; use them for thresholds, and use samples only to answer who and what.