This chapter covers NetFlow and sFlow, two fundamental technologies for network traffic analysis and monitoring. For the CompTIA Network+ N10-009 exam, understanding the differences between these protocols, their components, and their use cases is critical, as approximately 5-10% of questions in the Network Operations domain (Objective 3.3) address network monitoring tools and traffic analysis. By the end of this chapter, you will be able to explain how NetFlow and sFlow collect traffic data, describe their architectures, and identify appropriate deployment scenarios.
Jump to a section
Imagine a large company with a private telephone exchange. Every call made by an employee generates a call detail record (CDR) stored by the exchange. Each CDR captures the caller's extension (source IP), the number dialed (destination IP), the time the call started and ended (timestamps), the duration (packet count/bytes), and the outcome (protocol/port). The exchange does not record the actual conversation content—only the metadata about the call. Periodically, the exchange sends batches of CDRs to a central billing system (collector) for analysis. The billing system aggregates records to see who calls whom most frequently, peak calling times, and long-distance usage. This is exactly how NetFlow works: routers and switches generate flow records containing metadata about IP conversations (flows) and export them to a collector for traffic analysis. Just as the company's phone system does not store voice recordings, NetFlow does not capture packet payloads—only flow metadata. The key difference is that NetFlow defines a flow as a unidirectional sequence of packets sharing the same 7-tuple (source IP, destination IP, source port, destination port, protocol, ToS, and input interface), whereas a phone call is bidirectional. However, modern implementations like IPFIX can model bidirectional flows. The analogy helps explain why NetFlow is efficient: storing only metadata dramatically reduces storage and processing requirements compared to full packet capture.
What Are NetFlow and sFlow and Why Do They Exist?
NetFlow and sFlow are network monitoring technologies that provide visibility into traffic flows across a network. They exist because network administrators need to answer questions like: Who is using the bandwidth? What applications are consuming resources? Are there security threats like DDoS attacks? Without flow analysis, network engineers would have to rely on SNMP counters (which only give interface-level byte/packet counts) or full packet capture (which is storage-intensive and often impractical). Flow technologies fill the gap by summarizing traffic into flows—conversations between endpoints—and exporting metadata to a central collector for analysis.
NetFlow was originally developed by Cisco Systems in 1996. The most widely deployed version is NetFlow v5, but v9 introduced a template-based, extensible format that became the basis for IPFIX (IP Flow Information Export), standardized in RFC 7011-7015. sFlow (sampled flow) was developed by InMon Corporation and is standardized in RFC 3176. The key difference is that NetFlow typically exports data for every flow (or a sampled subset), while sFlow always uses statistical packet sampling and exports packet headers along with flow counters.
How NetFlow Works Internally
NetFlow operates on a router or switch (the exporter) that inspects packets as they pass through. For each packet, the device extracts a 7-tuple: source IP address, destination IP address, source port, destination port, layer 3 protocol type, Type of Service (ToS) byte, and input interface identifier. These seven fields define a flow. The device maintains a flow cache in memory. When a new packet arrives with a 7-tuple not already in the cache, a new flow entry is created. Subsequent packets with the same 7-tuple are aggregated into that entry, incrementing packet and byte counters and updating timestamps.
A flow entry is considered expired (and ready for export) when one of these conditions is met:
The flow is idle for a configurable timeout (default 15 seconds for short-lived flows, 30 seconds for long-lived).
The flow is active for a configurable maximum lifetime (default 30 minutes).
The flow cache becomes full (early expiry).
The TCP connection is terminated via FIN or RST (for TCP flows).
When a flow expires, the device formats a flow record and sends it via UDP (typically port 2055 for NetFlow) to a configured collector. The collector receives these records, stores them in a database, and provides analysis tools.
NetFlow Versions and Key Values
NetFlow v5: Fixed format, supports only IPv4, includes fields like source/destination IP, ports, protocol, ToS, input/output interface, packet count, byte count, first/last timestamps, TCP flags, and AS numbers. Cannot be extended.
NetFlow v9: Template-based, allowing exporters to define custom flow record formats. Supports IPv6, MPLS, BGP next hop, VLAN IDs, and more. Templates are sent periodically to the collector.
IPFIX: Based on NetFlow v9 but standardized by IETF. Uses the same template mechanism but adds enterprise-specific fields and better support for bidirectional flows.
Default NetFlow export UDP port: 2055 (commonly configurable). Default flow cache size varies by platform (e.g., Cisco IOS default is 64K flows). Idle timeout: 15 seconds. Active timeout: 30 minutes.
How sFlow Works Internally
sFlow uses statistical packet sampling. The sFlow agent (embedded in the switch/router) samples packets at a configured rate (e.g., 1 out of every 1000 packets). For each sampled packet, the agent captures the entire packet header (up to a configured length, default 128 bytes) and immediately sends it as an sFlow datagram to the collector (typically UDP port 6343). In addition, the agent periodically sends interface counter samples (e.g., bytes/packets per port, CPU utilization) at intervals (default 20 seconds).
sFlow does not maintain a flow cache. Each sampled packet is reported individually. The collector reconstructs traffic statistics by scaling the sampled data. For example, if the sampling rate is 1:1000, the collector multiplies the observed byte count by 1000 to estimate total traffic.
sFlow Key Parameters
Sampling rate: Configurable per interface, typically 1:N where N is between 64 and 65536. Common default: 1:1000.
Polling interval: For counter samples, default 20 seconds.
Export UDP port: 6343 (standardized).
Maximum header size captured: Configurable, default 128 bytes.
Configuration and Verification Commands
Cisco IOS NetFlow Configuration:
! Enable NetFlow on an interface
interface GigabitEthernet0/0
ip flow ingress
ip flow egress
! Configure NetFlow exporter
export flow
destination 10.1.1.100 2055
source Loopback0
version 9
! Verify NetFlow
show ip cache flow
show flow exporter
show flow monitorsFlow Configuration (Cisco IOS-XE):
! Enable sFlow globally
sflow source-interface Loopback0
sflow collector 10.1.1.200 6343
! Enable sFlow on an interface
interface GigabitEthernet0/0
sflow sampling-rate 1000
sflow polling-interval 20
! Verify sFlow
show sflow
show sflow statisticsInteraction with Related Technologies
NetFlow and sFlow complement SNMP. While SNMP provides interface-level counters (bits per second), NetFlow/sFlow provide per-flow details (who, what, when). They can be used together: SNMP for overall utilization, NetFlow for application breakdown. NetFlow data can also be fed into security information and event management (SIEM) systems for threat detection (e.g., identifying large flows to unknown destinations). sFlow is commonly used in high-speed networks (10Gbps+) where maintaining a flow cache is too resource-intensive. NetFlow can be sampled (NetFlow with sampling) to reduce load, but sFlow is inherently sampled.
Trap Patterns
Confusing NetFlow and sFlow: Candidates often forget that NetFlow exports flow records (aggregated) while sFlow exports sampled packet headers. The exam may describe a scenario where full flow accounting is needed—choose NetFlow (unsampled). If the scenario emphasizes low CPU impact and statistical accuracy, choose sFlow.
Assuming NetFlow is always sampled: NetFlow can operate in sampled mode (e.g., NetFlow with sample command), but by default it processes every packet. sFlow is always sampled.
Remembering default ports: NetFlow default UDP 2055 (or 9996 for some vendors), sFlow UDP 6343. The exam may ask which port to open on a firewall.
Thinking NetFlow v5 supports IPv6: It does not. NetFlow v9 and IPFIX support IPv6.
Summary of Flow Export Protocols
| Feature | NetFlow v5 | NetFlow v9 | IPFIX | sFlow | |---------|------------|------------|-------|-------| | Standard | Proprietary (Cisco) | Proprietary (Cisco) | IETF RFC 7011 | RFC 3176 | | IPv6 support | No | Yes | Yes | Yes | | Template-based | No | Yes | Yes | No | | Packet sampling | Optional | Optional | Optional | Always | | Export method | UDP | UDP (or SCTP) | UDP/SCTP | UDP | | Default port | 2055 | 2055 | 4739/4740 | 6343 | | Flow direction | Unidirectional | Unidirectional | Bidirectional option | Unidirectional | | MPLS support | No | Yes | Yes | Yes |
Packet Arrival and 7-tuple Extraction
When a packet enters a router or switch interface enabled for NetFlow, the device extracts the 7-tuple: source IP, destination IP, source port, destination port, protocol, ToS byte, and input interface. This tuple uniquely identifies a flow. The device performs a lookup in the flow cache using these seven fields as a key. If no matching entry exists, a new flow record is created with initial packet and byte counts set to 1 and the packet size respectively, and the first timestamp is recorded. The cache entry also stores the output interface (if routing is already determined) and TCP flags (e.g., SYN).
Flow Aggregation and Cache Update
For subsequent packets with the same 7-tuple, the flow cache entry is updated: the packet count is incremented by 1, the byte count is increased by the packet size, and the last timestamp is refreshed. TCP flags are ORed into a cumulative flags field. The device does not re-export the flow on every packet; it waits until the flow expires. This aggregation is what makes NetFlow efficient—it reduces the volume of export data. The cache is typically stored in high-speed memory (TCAM or DRAM) to keep up with line-rate traffic.
Flow Expiration Detection
The device continuously monitors each flow entry for expiration. Two timers are used: an idle timeout (default 15 seconds for short flows, 30 seconds for long flows) and an active timeout (default 30 minutes). If no packets match a flow for the idle timeout duration, the flow is considered expired. If a flow remains active beyond the active timeout, it is forcibly expired and a new flow record is started for subsequent packets. Additionally, if the flow cache reaches its maximum capacity (e.g., 64K entries), the device may prematurely expire the least recently used flows to make room. For TCP flows, detection of FIN or RST flags triggers immediate expiration.
Flow Record Export to Collector
Once a flow expires, the device formats a flow record. In NetFlow v5, the record has a fixed 48-byte format including all key fields. In NetFlow v9/IPFIX, the exporter sends a template (a definition of the fields) periodically, and then data records use that template. The record is encapsulated in a UDP datagram (or SCTP for IPFIX) and sent to the collector IP address and port (default 2055). Multiple flow records may be packed into a single UDP datagram (up to the MTU). The collector acknowledges receipt only if using reliable transport (SCTP). The exporter does not retransmit lost UDP datagrams—this is a best-effort protocol.
Collector Processing and Storage
The collector receives the UDP datagrams, decodes the flow records using the templates (v9/IPFIX) or fixed format (v5), and stores them in a database or time-series store. The collector then aggregates flows by various dimensions (e.g., source IP, destination IP, application port) to generate reports on top talkers, application usage, traffic patterns, and security anomalies. The collector may also correlate flows with other data sources (e.g., SNMP, syslog). For sFlow, the collector receives sampled packet headers and counter samples, scales them by the sampling rate, and produces statistical estimates of traffic.
Enterprise Traffic Accounting and Billing
A large university with 50,000 students uses NetFlow v9 on its border routers to track bandwidth usage per department. Each department has a /16 subnet. The network team configured NetFlow exporters on the upstream router, sending flow records to a collector running SolarWinds NetFlow Traffic Analyzer. The collector aggregates traffic by destination subnet and application port. This allows the university to bill departments based on actual usage (e.g., $X per GB). They also identify top talkers—students using excessive P2P traffic. A common misconfiguration is setting the active timeout too low (e.g., 1 minute), which floods the collector with millions of small flow records, degrading performance. The solution is to use a 30-minute active timeout and 30-second idle timeout. The team also had to ensure the collector had sufficient storage: at 10 Gbps border traffic, they generate about 50 GB of flow data per day.
DDoS Detection with sFlow
A cloud service provider uses sFlow on all top-of-rack switches (10Gbps and 40Gbps links) to detect DDoS attacks. sFlow's low CPU overhead (due to sampling) is critical at line rate. The collector, FastNetMon, analyzes sampled packet headers in real-time. When it detects a sudden spike in packets to a single destination IP with random source ports (a characteristic of UDP amplification attacks), it triggers a BGP remote-triggered blackhole (RTBH) to drop traffic to that IP. The sampling rate is set to 1:1000 to balance accuracy and overhead. A common pitfall is setting the sampling rate too low (e.g., 1:10), which overwhelms the switch CPU and causes packet loss. Another is forgetting to enable sFlow on all interfaces—attack traffic may bypass monitoring if only ingress or egress is sampled. The provider also uses sFlow's counter polling to monitor interface utilization and detect link saturation.
Network Capacity Planning
A multinational corporation uses IPFIX (standardized NetFlow) from their core routers to plan WAN upgrades. They collect flow data over months and analyze peak traffic patterns between sites. They discovered that traffic to a specific cloud provider (Microsoft 365) was growing 40% year-over-year. This justified upgrading the MPLS link from 100 Mbps to 200 Mbps. They also used flow data to identify that a legacy backup application was using port 445 (SMB) and consuming 30% of bandwidth during business hours, leading to a policy to schedule backups off-hours. Without flow analysis, they would have only seen aggregate interface utilization and not known which application caused the growth. A key configuration detail: they used the IPFIX option template to export BGP next-hop information, allowing them to attribute traffic to specific peers.
What N10-009 Tests on NetFlow and sFlow (Objective 3.3)
The CompTIA Network+ N10-009 exam objective 3.3 states: 'Given a scenario, use network monitoring tools to analyze traffic patterns and troubleshoot issues.' Flow analysis is a key tool. The exam expects you to:
Differentiate between NetFlow and sFlow in terms of mechanism (flow cache vs. packet sampling).
Identify appropriate use cases: NetFlow for detailed per-flow accounting (e.g., billing, security forensics), sFlow for real-time monitoring on high-speed links where performance is critical.
Recall default ports: NetFlow UDP 2055, sFlow UDP 6343.
Understand that NetFlow v5 does not support IPv6; v9 and IPFIX do.
Recognize that sFlow exports packet headers (not full payload) and counter samples.
Common Wrong Answers and Why
Choosing NetFlow when the scenario mentions 'low CPU impact' – Candidates often forget that NetFlow (without sampling) processes every packet, which can be CPU-intensive on high-speed links. sFlow is the correct answer for low CPU impact.
Selecting sFlow for 'accurate byte accounting' – sFlow uses statistical sampling, so it provides estimates, not exact counts. NetFlow (unsampled) provides exact per-flow byte counts.
Stating that NetFlow uses port 6343 – This is the sFlow port. The exam may present a firewall configuration question where you must open the correct port.
Thinking sFlow maintains a flow cache – sFlow does not aggregate packets into flows; each sampled packet is exported individually. The collector may reconstruct flows, but the exporter does not.
Specific Numbers and Terms That Appear on the Exam
Default NetFlow idle timeout: 15 seconds (short), 30 seconds (long). Active timeout: 30 minutes.
Default sFlow sampling rate: 1:1000 (but configurable). Polling interval: 20 seconds.
NetFlow v5 fixed record size: 48 bytes.
sFlow datagram: Contains one or more samples (packet header or counter).
Edge Cases and Exceptions
Sampled NetFlow: Some Cisco devices support 'sampled NetFlow' using the flow-sampler command. This reduces CPU load like sFlow but still exports flow records (aggregated) rather than individual packets. The exam may ask: 'Which technology uses sampling but exports aggregated flows?' Answer: Sampled NetFlow.
Bidirectional flows: IPFIX supports bidirectional flow reporting via the flowDirection field. NetFlow v5 and v9 report unidirectional flows only.
Export over SCTP: IPFIX can use SCTP for reliable transport, but UDP is more common. The exam may test that SCTP is an option.
How to Eliminate Wrong Answers
If the question asks about 'real-time traffic analysis on a 40Gbps link with minimal overhead,' eliminate NetFlow (unsampled) because it requires a flow cache and per-packet processing. Choose sFlow. If the question asks 'which tool provides exact per-flow byte counts for billing,' eliminate sFlow because it uses sampling. Choose NetFlow. If the question mentions 'IPv6 flow monitoring,' eliminate NetFlow v5. Choose v9 or IPFIX.
NetFlow defines a flow by a 7-tuple: source IP, destination IP, source port, destination port, protocol, ToS, and input interface.
Default NetFlow idle timeout is 15 seconds (short) and 30 seconds (long); active timeout is 30 minutes.
NetFlow v5 is fixed-format and IPv4-only; v9 and IPFIX are template-based and support IPv6.
sFlow uses statistical packet sampling (default 1:1000) and exports packet headers via UDP port 6343.
sFlow does not maintain a flow cache; each sampled packet is exported individually.
NetFlow default export UDP port is 2055; sFlow default is 6343.
IPFIX is the IETF standard version of NetFlow (RFC 7011-7015).
For low CPU impact on high-speed links, choose sFlow; for accurate per-flow accounting, choose NetFlow.
Sampled NetFlow is a hybrid that uses sampling but still exports aggregated flow records.
NetFlow and sFlow are complementary to SNMP: SNMP gives interface-level data, flow analysis gives per-conversation data.
These come up on the exam all the time. Here's how to tell them apart.
NetFlow
Aggregates packets into flow records using a flow cache.
Exports exact packet and byte counts per flow (unless sampled).
Default UDP port 2055.
Higher CPU/memory overhead on exporter due to flow cache.
Ideal for per-flow billing, security forensics, and application visibility.
sFlow
Exports individual sampled packet headers and counter samples.
Provides statistical estimates of traffic, not exact counts.
Default UDP port 6343.
Very low CPU overhead; no flow cache required.
Ideal for real-time monitoring on high-speed links (10Gbps+).
Mistake
NetFlow and sFlow both capture full packet payloads.
Correct
Neither captures full payloads. NetFlow exports only flow metadata (7-tuple, counters, timestamps). sFlow captures only the packet header (default 128 bytes), not the payload. Both are designed to avoid privacy and storage issues associated with full packet capture.
Mistake
sFlow is a version of NetFlow.
Correct
sFlow is a completely different protocol developed by InMon. It uses statistical packet sampling and exports individual packet headers, whereas NetFlow aggregates packets into flows and exports flow records. They are not compatible.
Mistake
NetFlow always samples traffic.
Correct
NetFlow by default processes every packet (unsampled). However, many devices support 'sampled NetFlow' to reduce CPU load. The exam expects you to know that unsampled NetFlow is the default, but sampling is an option.
Mistake
NetFlow v5 supports IPv6.
Correct
NetFlow v5 has a fixed format that only accommodates IPv4 addresses. IPv6 support was introduced in NetFlow v9 and IPFIX.
Mistake
sFlow uses port 2055.
Correct
sFlow uses UDP port 6343 by default. Port 2055 is the default for NetFlow. This is a common trick on the exam.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
NetFlow aggregates packets into flows (based on a 7-tuple) and exports flow records containing packet/byte counts and timestamps. It requires a flow cache on the exporter. sFlow uses statistical packet sampling: it captures a fraction of packets (e.g., 1 in 1000) and exports their headers immediately. sFlow does not maintain a flow cache, so it has lower CPU overhead. NetFlow provides exact per-flow data (if unsampled), while sFlow provides statistical estimates. Default ports: NetFlow UDP 2055, sFlow UDP 6343.
NetFlow v5 does not support IPv6; it only supports IPv4. NetFlow v9 and IPFIX support IPv6. When configuring NetFlow for IPv6 traffic, ensure the exporter uses version 9 or IPFIX and that the collector can decode IPv6 fields.
The default sampling rate for sFlow is typically 1:1000 (one packet sampled out of 1000). However, it is configurable per interface. The exam may ask you to calculate estimated traffic based on sampling rate: if 10 packets are sampled at 1:1000, the estimated total is 10,000 packets.
Yes, they can coexist on the same network. For example, a router might run NetFlow for detailed accounting on low-speed links and sFlow on high-speed links to reduce CPU load. They export to different collectors or the same collector if it supports both protocols. The exam may present a scenario where both are used.
IPFIX (IP Flow Information Export) is the IETF standard version of NetFlow, based on Cisco's NetFlow v9. It uses a template-based format and supports enterprise-specific fields. IPFIX is defined in RFC 7011-7015. It is interoperable with NetFlow v9 to some extent. The exam may refer to IPFIX as 'standardized NetFlow'.
Choose sFlow when you need real-time traffic monitoring on very high-speed links (10Gbps or higher) where maintaining a flow cache would be too CPU-intensive. sFlow is also simpler to configure and has lower memory requirements. However, if you need exact byte counts for billing or detailed per-flow analysis (e.g., for security forensics), NetFlow is preferable.
A NetFlow v5 record includes: source IP, destination IP, source port, destination port, protocol, ToS, input interface, output interface, packet count, byte count, first timestamp, last timestamp, TCP flags, source AS, destination AS, and next-hop IP. The record is fixed at 48 bytes.
You've just covered NetFlow and sFlow Traffic Analysis — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?