NetFlow sFlow Traffic Monitoring FAQ: Expert Answers to Technical & Deployment Questions

Overview & Thematic Scope

NetFlow and sFlow are two dominant, protocol-level traffic monitoring technologies used by enterprise and service provider networks. NetFlow (Cisco) and sFlow (industry-standard) provide flow-based and packet-sampled visibility for capacity planning, security forensics, and QoS troubleshooting. This FAQ addresses common pre-sales procurement and post-sales configuration queries, focusing on exporter capacity, accuracy tradeoffs, hardware support, and collector compatibility.

Frequently Asked Questions

Q1: What is the exact difference between NetFlow and sFlow for hardware-based export?

NetFlow is flow-based, caching bidirectional packets into flows on the router/switch before exporting aggregated records, which consumes more CPU but reduces collector load. sFlow is packet-sampled, exporting raw packet headers and interface counters directly, imposing lower CPU on the exporter but requiring collectors to reassemble flows. NetFlow is best for long-term traffic trending; sFlow excels for real-time anomaly detection and high-speed core links (10Gbps+) where flow caching would overwhelm hardware buffers.

Q2: What is the maximum flow export rate (flows/sec) supported on typical enterprise hardware?

Most current-generation ASIC-based switches support 50,000 to 250,000 flows per second via hardware acceleration. For NetFlow v9/IPFIX, export rates depend on the forwarding engine: low-end switches manage ~20k flows/sec, while datacenter switches (e.g., with programmable pipeline) sustain over 500k flows/sec. Always check the vendor’s datasheet for “export table size” (e.g., 128k entries) and “timeout granularity” (60s active/15s inactive) to avoid export table overflows.

Q3: How much bandwidth overhead does NetFlow or sFlow generate on a 10GbE link?

Typically 0.1% to 1% of link capacity. For NetFlow with default sampling (1:1000) and 60s export intervals, a 10GbE link carrying 5 million packets/sec generates ~5,000 exports/sec, each ~100 bytes = 4 Mbps overhead (0.04%). sFlow with 1:1000 sampling adds similar overhead, but using 1:100 sampling on a busy core link can reach 80-100 Mbps. Set sampling rates based on the collector’s ingest capacity: 1:1000 is standard for WAN, 1:5000 for 40GbE+ backbone links.

Q4: Which hardware platforms support hardware-accelerated sFlow (non-CPU impacting)?

Modern ASIC-based switches from Arista (7170 series, 7280R3), Cisco Nexus 9300-EX/FX/GX, Juniper QFX5k/10k, and Mellanox Spectrum support line-rate sFlow sampling entirely in the forwarding ASIC. Avoid old modular routers (Cisco 7200/7300) and entry-level L2 switches which sample via CPU, causing 30-80% performance degradation at 1Gbps+. Check the vendor’s “sFlow hardware offload” feature flag; if absent, expect CPU-driven sampling.

Q5: How do I troubleshoot “no flow data received” on my open-source collector (nProbe, ELK, Prometheus)?

First, verify the exporter is sending UDP datagrams using tcpdump -i any udp port 2055 (NetFlow) or 6343 (sFlow). Then check: (1) Firewall rules on the collector allowing UDP inbound from exporter IP; (2) Exporter configuration – ensure destination IP, port, and source interface are correct; (3) Sampling rate not set to 0; (4) Exporter’s flow table not overflowing (check SNMP OID .1.3.6.1.4.1.9.9.166.1.15.1.1.0 for Cisco). For sFlow, confirm the agent IP matches the collector’s allowed list. Missing data often points to UDP packet drops due to high burst rate; increase collector socket buffer: sysctl -w net.core.rmem_max=33554432.

Q6: What is the recommended template refresh interval for NetFlow v9 to avoid template loss?

Cisco and Juniper default to 30 minutes; this is too long for dynamic field definitions. Set template refresh to 10-15 minutes and options template refresh to 20 minutes. For IPFIX, send templates every 30 seconds for the first minute after exporter reboot, then every 10 minutes. Mismatched templates cause collectors to drop records silently. Verify using show flow exporter statistics – “template retransmits” should be

Q7: Can I use NetFlow or sFlow for per-subscriber billing in a BNG environment?

Yes, but with caveats. NetFlow v9/IPFIX supports variable-length fields, including subscriber session ID and VLAN tags, making it suitable for wholesale billing if the exporter supports custom enterprise-specific fields (e.g., Cisco BNG flow export). sFlow does not reassemble flows by default, so it requires the collector to correlate packets, which fails under high concurrent sessions (>50k). For carrier-grade billing, use IPFIX with per-flow sequence numbers and reliable transport (TCP/SCTP) rather than UDP; CGNAT logs are generally more accurate than sampled flows for strict billing.

Q8: Which flow monitoring protocol has the lowest latency for DDoS detection?

sFlow offers the lowest detection latency (as low as 5-10 seconds) because it exports packet headers every 1-2 seconds without waiting for flow termination (NetFlow active timeout typically 60 seconds). For real-time automated mitigation, combine sFlow (1:500 sampling) with a collector running a sliding window algorithm (e.g., FastNetMon or FSos). NetFlow with inactive timeout set to 15 seconds reduces latency to ~20s but increases export load by 4x. For sub-second detection, hardware-based streaming telemetry (gRPC/OpenConfig) is superior to both.