Overview
NetFlow records what talked to what, on which port, for how long, and how many bytes. SNMP tells you an interface is at 95% utilization — NetFlow tells you it's one specific host doing a backup to S3 at 08:00 every morning. That level of visibility is essential for capacity planning, security investigation, and billing in multi-tenant environments.
NetFlow Architecture
NetFlow vs IPFIX vs sFlow
Part 1 — Flexible NetFlow on Cisco IOS-XE
Flexible NetFlow (FNF) lets you define exactly which fields to capture per flow record — reduce overhead by only collecting what you need.
Define Flow Record, Exporter, Monitor
cisco
! Step 1 — Flow Record (what fields to collect)flow record CORP-FLOW-RECORD match ipv4 protocol match ipv4 source address match ipv4 destination address match transport source-port match transport destination-port match interface input collect transport tcp flags collect interface output collect counter bytes long collect counter packets long collect timestamp sys-uptime first collect timestamp sys-uptime last collect ipv4 dscp collect ipv4 ttl minimum! Step 2 — Flow Exporter (where to send)flow exporter NETFLOW-COLLECTOR destination 192.0.2.50 source GigabitEthernet0/0 transport udp 2055 export-protocol netflow-v9 template data timeout 300 ! Resend templates every 5 minutes so collector can recover from restarts! Step 3 — Flow Monitor (ties record to exporter)flow monitor CORP-FLOW-MONITOR exporter NETFLOW-COLLECTOR record CORP-FLOW-RECORD cache timeout active 60 cache timeout inactive 15 cache entries 16384! Step 4 — Apply to interfacesinterface GigabitEthernet0/0 ip flow monitor CORP-FLOW-MONITOR input ip flow monitor CORP-FLOW-MONITOR output ! Apply both input and output for full bidirectional visibilitySampled NetFlow for High-Traffic Interfaces
cisco
! On 10Gbps+ interfaces, unsampled NetFlow can overwhelm the CPU! Sample 1 in every 1000 packets — reduces load by 99.9%sampler NETFLOW-SAMPLER mode random 1 out-of 1000interface TenGigabitEthernet1/0/1 ip flow monitor CORP-FLOW-MONITOR sampler NETFLOW-SAMPLER inputNote: Sampled NetFlow misses low-volume flows (e.g., a slow scan at 5 pps may never be sampled). Use unsampled on edge/border routers for security visibility, sampled on core links for capacity data.
Part 2 — Collector Setup (nfdump + nfcapd)
bash
# Install nfdump on Ubuntu/Debianapt install nfdump# Start nfcapd collector — listens on UDP 2055, writes 5-minute filesnfcapd -w -D -l /var/netflow/data -p 2055 -t 300 -x 'nfreplay -v9 -d 192.0.2.51 -p 9996 %f'# -w = write files, -D = daemon, -l = directory, -t = file rotation interval (seconds)# Create directory structure per routermkdir -p /var/netflow/data/{edge-rtr-01,core-sw-01}nfcapd -w -D -l /var/netflow/data/edge-rtr-01 -p 2055Query Flows with nfdump
bash
# Top 20 talkers by bytes in the last hournfdump -R /var/netflow/data/edge-rtr-01 -t 2026-03-13/08:00:2026-03-13/09:00 \ -s srcip/bytes -n 20# All flows to/from a specific IPnfdump -R /var/netflow/data/edge-rtr-01 -t 2026-03-13/08:00:2026-03-13/09:00 \ "host 10.10.10.55"# DNS traffic by source (detect DNS exfiltration)nfdump -R /var/netflow/data/edge-rtr-01 \ "proto UDP and dst port 53" -s srcip/packets -n 20# Show all TCP SYN-only flows (port scan detection)nfdump -R /var/netflow/data/ "flags S and not flags ARPUF" \ -s dstip/flows -n 20 -o extended| # | Source IP | Destination | Proto/Port | Bytes | Pkts | App | 5-min trend |
|---|---|---|---|---|---|---|---|
| 1 | 10.10.20.45 ⚠ | 52.216.104.61 | TCP/443 | 4.2 GB | 3.1M | HTTPS/S3 | |
| 2 | 10.10.20.89 ⚠ | 52.217.33.142 | TCP/443 | 3.8 GB | 2.8M | HTTPS/S3 | |
| 3 | 10.10.20.102 ⚠ | 52.216.18.205 | TCP/443 | 3.1 GB | 2.3M | HTTPS/S3 | |
| 4 | 10.10.10.15 | 8.8.8.8 | UDP/53 | 82 MB | 420K | DNS | |
| 5 | 10.10.10.88 | 172.217.25.46 | TCP/443 | 420 MB | 312K | YouTube |
⚠
Hosts 10.10.20.45, .89, .102 are saturating the ISP link simultaneously — all sending to AWS S3 (/52.216.x.x, /52.217.x.x). Run:
nfdump -R /var/netflow/data/edge-rtr-01 -t last5min -s srcip/bytes to confirm. Root cause: overlapping scheduled backup jobs at 08:25.
Part 3 — DDoS Detection with NetFlow
bash
# Detect UDP flood — high pps to single destinationnfdump -R /var/netflow/data/edge-rtr-01 -t last5min \ "proto UDP" -s dstip/packets -n 10# If a single destination shows >10x normal baseline, investigate# Detect SYN flood — many sources to single portnfdump -R /var/netflow/data/ -t last5min \ "flags S and not flags A and dst port 80" \ -s srcip/flows -n 20# Many distinct sources with SYN-only = SYN flood in progress# Detect DNS amplification — small queries, large responsesnfdump -R /var/netflow/data/ -t last5min \ "proto UDP and src port 53" -s srcip/bytes -n 10# High bytes from UDP/53 = reflection/amplification attack using your resolversReal-World Scenario
The situation: The ISP uplink at a corporate headquarters is intermittently saturating at 08:30 every weekday morning. SNMP shows the interface at 98% for 12 minutes then drops back to 30%. The helpdesk gets calls about "slow internet" every morning.
Investigation with NetFlow:
bash
# Query flows during the 08:30 windownfdump -R /var/netflow/data/edge-rtr-01 -t 2026-03-13/08:25:2026-03-13/08:45 \ -s srcip/bytes -n 10# Output:# Src IP Bytes Flows# 10.10.20.45 4.2 GB 12# 10.10.20.89 3.8 GB 8# 10.10.20.102 3.1 GB 9# Investigate destinationnfdump -R /var/netflow/data/edge-rtr-01 -t 2026-03-13/08:25:2026-03-13/08:45 \ "host 10.10.20.45" -s dstip/bytes -n 5# Result: all traffic destined to 52.x.x.x (AWS S3 range) on TCP 443# Root cause: 3 servers running backup jobs to S3 simultaneously at 08:30# Fix: stagger backup schedules — 08:30, 09:00, 09:30Troubleshooting
Collector receiving no flows
Symptom: nfcapd is running but no flow files are created.
Cause: Firewall blocking UDP 2055, wrong destination IP in exporter config, or missing ip flow monitor on interfaces.
Fix:
cisco
! Verify exporter configR1# show flow exporter NETFLOW-COLLECTOR! Check: "Transport: UDP, Destination: 192.0.2.50, Port: 2055"! Check: "Status: Active"! Verify monitor applied to interfaceR1# show flow interface GigabitEthernet0/0! Should show: "Input: CORP-FLOW-MONITOR, Output: CORP-FLOW-MONITOR"Flow cache full — high CPU on router
Symptom: Router CPU spikes during high traffic. show flow monitor CORP-FLOW-MONITOR cache shows cache at 100%.
Cause: Cache entries exhausted — flows not expiring fast enough for the traffic volume.
Fix:
cisco
flow monitor CORP-FLOW-MONITOR cache timeout active 30 ! Reduce active timeout from 60 to 30 seconds — export faster cache timeout inactive 10 cache entries 65536 ! Increase cache size if platform supports it ! Or enable sampling (see sampler config above)Templates not received by collector — flow data shows unknown fields
Symptom: nfdump shows flows but field values are all zero or unknown.
Cause: Template packet was lost and never re-sent. Collector doesn't know how to interpret fields.
Fix:
cisco
! Force immediate template resendflow exporter NETFLOW-COLLECTOR template data timeout 60 ! Resend template every 60 seconds instead of 300! Manually trigger resendR1# clear flow exporter NETFLOW-COLLECTORNetFlow Deployment Checklist
- Apply NetFlow monitor to both input AND output on border/edge interfaces — unidirectional gives incomplete visibility
- Use Flexible NetFlow (FNF) not legacy
ip flow ingress— FNF is configurable and supported on modern IOS-XE - Enable sampling (
sampler mode random 1 out-of 1000) on 10G+ interfaces to protect CPU - Set
template data timeout 60-300— ensures collector recovers after restart without manual intervention - Collector host has enough disk: 5-minute files, 1Gbps monitored link ≈ 50–200MB/hr of flow data
- UDP transport means flow packets can be lost — use SCTP or TCP export for critical security audit trails
- Baseline normal traffic volumes per time-of-day before setting anomaly thresholds
- Store flow data for minimum 30 days for security investigation — 90 days for compliance environments
- Test nfdump queries against a known event to validate data accuracy before relying on it for security