68. Flow telemetry: NetFlow, IPFIX, and sFlow

68.1 What a flow record is

A flow is a unidirectional sequence of packets sharing a key — classically the 5-tuple (src IP, dst IP, src port, dst port, protocol) plus input interface and ToS.

The device summarises each flow and exports a record:

start=10:00:01.204  end=10:00:04.881  duration=3.677s
src=192.168.1.50:51000  ->  dst=93.184.216.34:443   proto=TCP
packets=48  bytes=52104  tcp_flags=0x1b  tos=0  in_if=3  out_if=1
src_as=64512  dst_as=15133  next_hop=10.0.0.1

This is the answer to "who is using my bandwidth?" — a question metrics cannot answer and packet capture answers too expensively.

68.2 The three technologies

Rule of thumb: IPFIX/NetFlow v9 when you need accurate accounting (billing, security forensics); sFlow when you need cheap, real-time, high-speed visibility across many devices. Many networks run both.

68.3 The timers that confuse everyone

Flow records don't appear when the flow starts:

active timeout   (default often 60 s or 1-5 min)
    a long-lived flow is exported PERIODICALLY, in pieces
inactive/idle timeout  (default ~15-30 s)
    a finished flow is exported this long after the last packet

So a 10-minute download appears as several records, and a short flow appears ~15 s late. Never build a real-time alert on flow data expecting sub-minute freshness, and always sum the pieces when accounting.

68.4 Sampling maths

At 1-in-1000 sampling, a 5,000-packet flow yields ~5 samples. Scale back up by the sampling rate to estimate bytes. Implications:

• Aggregate totals are accurate; individual small flows are invisible.
• Security use (finding one connection to a C2 server) needs unsampled flow or packet data.
• Always record the sampling rate with the data — mixing rates silently corrupts totals.

68.5 Where to collect flows when you don't own routers

VPC flow logs are the cloud-native equivalent and answer exactly the same questions — including the crucial ACCEPT/REJECT field, which tells you whether a security group dropped the traffic.

68.6 What flow data is actually good for

1. Top talkers / bandwidth attribution — which host, app, or customer.
2. Capacity planning — traffic matrices between sites over months.
3. Peering and transit decisions — traffic per destination AS, which is why src_as/dst_as fields exist.
4. DDoS detection — sudden explosion in flows-per-second with tiny packet counts is a scan or SYN flood signature.
5. Security forensics — "did anything talk to this IP in the last 90 days?" Cheap to retain for months; packet capture is not.
6. Verifying firewall rules — cloud flow logs' REJECT records show what's being blocked and whether that's intended.

68.7 Real-world example

A university's 10 Gbit/s uplink saturated every evening. Interface metrics showed only "100% utilised". IPFIX records showed 62% of traffic was a handful of hosts talking to a single destination AS on high ports — unauthorised media servers in a residence hall. Without flow data the only options were guesswork or a full packet capture at line rate. With it: fifteen minutes to the answer, and a QoS policy (Ch. 51) rather than an uplink upgrade.

Try it yourself

# software flow export/collection on a Linux box
sudo apt install nfdump softflowd
sudo softflowd -i eth0 -n 127.0.0.1:9995 -v 9
nfcapd -w -D -l /tmp/flows -p 9995 &
sleep 120
nfdump -R /tmp/flows -s srcip/bytes -n 10      # top talkers
nfdump -R /tmp/flows -s dstport/bytes -n 10    # top destination ports

# cloud equivalent
aws ec2 describe-flow-logs
# then query the logs in Athena/CloudWatch Insights, grouping by srcaddr/dstaddr/bytes