Mental model
SNMP tells you “interface Gi0/1 sent 4.2 TB this month.” True but useless — you don’t know who sent what, which app, or what direction.
NetFlow answers: “of that 4.2 TB, 1.8 TB was YouTube to user X, 900 GB was backup traffic to the DC, 300 GB was Microsoft 365…”
The difference: SNMP counts at the interface; NetFlow tracks flows — unique conversations defined by a tuple of:
( src IP, dst IP, src port, dst port, protocol, ingress interface, ToS )
(7-tuple in v5; configurable in v9/IPFIX.)
Every packet matching the same 7-tuple is one flow. The router maintains a flow table in memory, increments byte/packet counters per flow, and exports the flow record to a collector when the flow ends (or periodically).
A single device exports millions of flows per day. The collector stores them. You query them.
Three NetFlow variants worth knowing
| Standard | Vendor | Sampling | Notable |
|---|---|---|---|
| NetFlow v5 | Cisco | None (1:1 in software) | Legacy fixed format, IPv4 only |
| NetFlow v9 | Cisco | None (or 1:N) | Template-based, IPv6 + custom fields |
| IPFIX (NetFlow v10) | IETF standard | None or sampled | v9 cleaned up + standardized — multi-vendor |
| sFlow | Foundry/InMon | Always sampled (e.g., 1:1000) | Lower CPU, less precise per-flow |
| Cisco Flexible NetFlow | Cisco | Configurable | Define your own flow keys — modern Cisco default |
In 2026: IPFIX is the multi-vendor target. Flexible NetFlow is the Cisco-native way. sFlow is common on Arista, HP, Juniper.
Sampled vs unsampled
Unsampled — every packet hits the flow table. Most accurate. But on high-speed interfaces (10G+), the table updates per packet can overwhelm CPU.
Sampled — every Nth packet is examined; the rest are ignored. Lower CPU, less precise per-flow but statistically OK for aggregate.
Common sample rates:
- 1:1 — every packet (small / mid network).
- 1:1000 — high-speed enterprise.
- 1:5000 — service-provider backbones.
sFlow always samples. NetFlow v5 is unsampled. v9/IPFIX can be either.
The export and collection model
┌──────────────┐
│ Router / │ maintains flow cache (RAM table)
│ Switch │ counts bytes/packets per flow
└──────┬───────┘
│
│ UDP export every "active timeout" / "inactive timeout"
│ destination = NetFlow collector
▼
┌──────────────┐
│ Collector │ stores in time-series DB (often InfluxDB/Elastic)
│ (PRTG, ELK, │ indexes for queries
│ Splunk, │ exposes dashboards / SIEM
│ Plixer, …) │
└──────────────┘
The collector is where the value is. NetFlow without a good collector is just CPU overhead — you need queryable storage + visualization to actually use the data.
Flow timeouts — when does export happen?
A flow gets exported on any of these events:
- TCP FIN/RST — explicit end-of-flow.
- Inactive timeout — no new packets for N seconds (default 15s). Long flows split into shorter chunks.
- Active timeout — flow has lasted N seconds total (default 1800s/30min). Even if active, force an export to keep records current.
- Cache full — least-recently-used flow gets evicted and exported.
Effect: a long download might appear as multiple flow records (one per active-timeout boundary) but the collector reconstructs them by 5-tuple matching.
Configuration — Cisco Flexible NetFlow
The modern Cisco way uses Flexible NetFlow with three building blocks: flow record, flow exporter, flow monitor.
! 1. Flow record — what fields to track
R1(config)# flow record FLOW-REC
R1(config-flow-record)# match ipv4 source address
R1(config-flow-record)# match ipv4 destination address
R1(config-flow-record)# match transport source-port
R1(config-flow-record)# match transport destination-port
R1(config-flow-record)# match ipv4 protocol
R1(config-flow-record)# collect counter bytes
R1(config-flow-record)# collect counter packets
R1(config-flow-record)# collect timestamp absolute first
R1(config-flow-record)# collect timestamp absolute last
! 2. Flow exporter — where to send records
R1(config)# flow exporter FLOW-EXP
R1(config-flow-exporter)# destination 10.99.99.20
R1(config-flow-exporter)# transport udp 2055
R1(config-flow-exporter)# template data timeout 60
! 3. Flow monitor — combines record + exporter
R1(config)# flow monitor FLOW-MON
R1(config-flow-monitor)# record FLOW-REC
R1(config-flow-monitor)# exporter FLOW-EXP
! 4. Apply to interface (ingress / egress)
R1(config)# interface Gi0/1
R1(config-if)# ip flow monitor FLOW-MON input
R1(config-if)# ip flow monitor FLOW-MON output
Default port for the exporter is UDP 2055 (some collectors use 9995, 9996, or 4739 for IPFIX — check your collector’s docs).
Use cases — why bother
1. Capacity planning
“WAN link looks 60% utilized — what’s eating it?” NetFlow answers in 30 seconds:
- 40% YouTube (call your security team about acceptable-use policy)
- 25% Microsoft 365 (real productivity traffic)
- 20% generic HTTPS (unattributed)
- 15% backup to DR site (could be QoS-deprioritized)
2. Anomaly / security detection
Unusual flow patterns flag attacks:
- 10,000 short flows from one internal host to many external IPs → likely scanning (compromised host).
- One internal IP suddenly sending 50 GB/hour to an unfamiliar Russia IP → potential exfiltration.
- A normally-quiet IoT device now talking to an unknown C2 server → compromise.
NetFlow is the standard data source for many SIEM correlation rules.
3. Forensics
Six weeks after an incident, the security team asks: “Who did this server talk to on June 12 between 03:00 and 03:20?” NetFlow has the answer if collection includes that time range. Packet capture would be impossibly large; NetFlow records take 1/100 the space.
4. Billing / chargeback
Multi-tenant network bills departments by traffic. NetFlow per-source-IP × time × bytes = a usable bill.
5. Application visibility
“What apps do we even run on this network?” Sort flows by destination port + protocol. Quickly find unauthorized apps (P2P, file sharing, unauthorized SaaS).
Verification
R1# show flow exporter FLOW-EXP
R1# show flow monitor FLOW-MON
R1# show flow monitor FLOW-MON cache ! current flows in memory
R1# show flow record FLOW-REC
R1# show flow exporter statistics
R1# show flow monitor FLOW-MON statistics
cache is the most useful — gives you live current flows. Filter by destination IP or protocol to confirm a specific session is being tracked.
NetFlow vs sFlow — when to pick which
| NetFlow | sFlow | |
|---|---|---|
| Sampling | Optional (often unsampled at lower speeds) | Always sampled |
| Precision | Higher (per-flow exact bytes) | Statistical |
| CPU cost | Higher | Lower |
| High-speed (40G+) suitable | Sampled mode | Yes (natively designed for it) |
| Vendor | Cisco-led; IPFIX standardizes | Multi-vendor |
| Use case | Forensics, billing, fine-grained | Capacity, anomaly, high-speed |
For most CCNA-level enterprises: Flexible NetFlow on Cisco switches, sFlow on non-Cisco. Modern collectors (Plixer, Kentik, ntopng, Elastiflow) handle both.
Storage realities
NetFlow records average ~50–100 bytes per record. A typical mid-enterprise gateway might export 50k flows/sec → ~5 MB/s → ~430 GB/day. Plan storage accordingly:
- Active queries — 7-14 days hot in fast storage.
- Forensics — 30-90 days in compressed warm storage.
- Compliance — 1 year+ in cold (cloud) storage.
Aggregation tools shrink this significantly — group flows by app/host/time, store the rollup, drop the raw.
Common mistakes
NetFlow without a collector. Configured the exporter, no one’s receiving it. Records vanish into UDP void. Always verify reception on the collector side.
Sample rate too aggressive. 1:10000 sampling on a low-throughput link = you miss most of the traffic. Match sample rate to expected flow volume.
Forgetting both directions. Apply NetFlow
inputandoutputon the same interface to capture both directions, or apply once and let the collector infer bidirectionality from 5-tuple.No timestamps in the flow record. Forensics is useless without time. Always include
timestamp absolute first / last.CPU surprise on high-volume routers. Enabling NetFlow on a busy edge router can spike CPU 20-40%. Test on a maintenance window; consider sampling.
Trusting NetFlow for “encryption analysis.” NetFlow sees IPs and ports, not content. A TLS-encrypted session looks the same as plaintext at the flow level.
Using NetFlow on a switch where it requires hardware. Some lower-end switches process NetFlow in CPU instead of ASIC — adds latency. Verify your platform.
Confusing IPFIX with packet capture. IPFIX is metadata about flows. Packet capture is the raw bytes. They serve different forensic purposes.
Lab to try tonight
- Install ntopng (free) on a Linux VM, or use Plixer’s free trial collector.
- In CML/EVE-NG, set up Flexible NetFlow on a router’s WAN interface with the config above. Exporter → collector’s IP.
- Generate some traffic —
ping,iperf3, browse to YouTube from a host through the router. - In the collector, observe flows appearing in real time. Look at top talkers, top apps, top destinations.
- Adjust active/inactive timeouts; observe how long flows split.
- Try sFlow on a non-Cisco emulator (if available). Compare data fidelity at 1:100 vs 1:1000 sample rates.
- Bonus: deliberately cause an anomaly — generate a port scan from one of your hosts. Watch the collector’s anomaly dashboard light up.
Cheat strip
| Concept | Plain English |
|---|---|
| NetFlow | Per-flow traffic accounting — far richer than SNMP byte counters |
| Flow | A unique conversation: 5-7 tuple of src IP/port + dst IP/port + protocol |
| NetFlow v5 | Legacy fixed format, IPv4 only |
| NetFlow v9 / IPFIX | Template-based, IPv6 + custom fields. IPFIX = standardized v9 |
| sFlow | Multi-vendor, always sampled, lower CPU |
| Flexible NetFlow | Modern Cisco — define your own flow keys |
| Flow record / exporter / monitor | What to collect / where to send / glue them together |
| Default exporter port | UDP 2055 (or 9995/9996/4739) |
| Sample rate | 1:N. Higher N = less precise but lower CPU |
| Use cases | Capacity, security forensics, billing, app visibility |
| Storage cost | 50-100 bytes per record. Plan retention tiers |
| CCNA depth | Recognize NetFlow + IPFIX + sFlow + the use case categories |
