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 /sFlow versus NetFlow and IPFIX

06 /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.

07 /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.