Technically reviewed · September 2026
NetFlow and sFlow are two different approaches to network traffic telemetry. Both help answer who communicated with whom, when and at what volume, but they create data differently and offer different levels of detail and scalability. This guide explains NetFlow, IPFIX, sFlow and Port Mirroring accurately, then provides a practical framework for choosing among them.
NetFlow turns observed packets with common properties into flow records. sFlow statistically samples packet headers and periodically exports interface counters. NetFlow is strong for detailed flow history; sFlow is well suited to broad visibility across high-speed switched environments. When complete packet content is required, use SPAN, a network TAP or another packet-capture method.
What is NetFlow?
NetFlow is a flow-based traffic telemetry technology originally developed by Cisco. A router, switch or security device acting as an exporter observes packets at an observation point and groups packets that share properties such as source and destination IP address, source and destination port, and IP protocol. This commonly referenced field set is known as the 5-tuple. The exporter sends the resulting records to a NetFlow collector.
A NetFlow record can contain much more than two IP addresses. Depending on the exporter and format, it may include input/output interfaces, packet and byte counters, first and last timestamps, TCP flags, Type of Service, next hop, autonomous system information and routing context. These dimensions support realtime traffic analysis, capacity planning, top-talker investigations, incident response and DDoS analysis.
NetFlow and IPFIX generally export traffic metadata rather than complete payloads. They can show that a conversation occurred, its direction, timing and volume. Inspecting an email body, HTTP content or complete protocol exchange requires SPAN, a TAP or another packet-capture method.
Exporter, collector and analyzer architecture
The telemetry pipeline has three logical roles. The exporter observes traffic and creates records. The collector receives records from multiple devices, tracks templates and stores data. The analyzer makes that data searchable by IP, subnet, port, protocol, interface, ASN, throughput and packet rate. The Flowtrion network intelligence platform combines this pipeline with security and routing context.
NetFlow v5, NetFlow v9 and IPFIX
The word NetFlow does not always refer to one record format. Production networks commonly contain NetFlow v5, NetFlow v9 and the IETF-standardized IPFIX protocol. Collector design should begin with an inventory of the formats, information elements and template refresh behavior supported by each exporter.
| Capability | NetFlow v5 | NetFlow v9 | IPFIX |
|---|---|---|---|
| Record model | Fixed fields | Template based | Template based and extensible |
| IPv6/MPLS flexibility | Limited | Depends on templates | Broad information-element model |
| Status | Cisco format | Cisco format documented by RFC 3954 | IETF standard defined by RFC 7011 |
| Collector behavior | Parse a known fixed format | Know the template before data records | Track templates and observation domains |
NetFlow v9 uses templates so exporters can describe different record layouts. IPFIX standardizes this approach and provides a broader interoperability model built around registered information elements. Lost templates, confused observation domains and unsuitable active/inactive timeouts can all produce gaps or misleading results at the collector.
What is sFlow?
sFlow is a sampling technology designed to monitor high-speed switched and routed networks. An sFlow agent statistically selects packets, exports a portion of the selected packet header as a flow sample, and periodically reports interface statistics as a counter sample. New implementations should follow the sFlow Version 5 specifications.
Despite “flow” in its name, sFlow does not normally build a stateful cache for every conversation in the way a flow exporter may. Its sampling model is well suited to environments with many switch ports and high link speeds. The tradeoff is that measurements are statistical: a low-volume or short-lived conversation may not be selected.
How does sFlow sampling work?
A sampling rate of 1:1000 expresses a statistical target rather than a promise to select exactly every thousandth packet. Reducing sampling density lowers telemetry volume but also reduces the probability that small conversations appear in the sample set. The right setting depends on line rate, packets per second, number of monitored ports, detection objectives and collector capacity.
sFlow datagrams are commonly sent to UDP port 6343. Because UDP does not guarantee delivery, teams should monitor the path between agent and collector, including ACLs, routing, MTU, packet loss and collector queues. Counter polling is configured separately from packet sampling and controls how frequently interface utilization, errors and related counters are reported.
NetFlow vs sFlow: key differences
| Criterion | NetFlow / IPFIX | sFlow |
|---|---|---|
| Core data model | Records describing observed traffic flows | Statistical packet-header samples and interface counters |
| State on device | Implementation may maintain flow cache and counters | Sampling-oriented; no per-conversation flow cache |
| Detail | Strong history of flow timing, volume and dimensions | Protocol visibility from selected packet headers |
| Scale | Depends on exporter capacity and sampling | Designed for broad, high-speed environments |
| Small conversations | More consistently represented when unsampled | May not be selected |
| Long-term retention | Well suited through compact records | Well suited with appropriate sampling and polling |
| Payload | Generally not exported | Usually a truncated header, not a complete payload |
| Typical focus | Accounting, historical analysis and investigations | Broad visibility, trends and traffic changes |
Statements such as “NetFlow is always more accurate,” “sFlow uses no CPU,” or “sFlow sees every packet” are misleading. Results depend on device architecture, exporter implementation, sampling rate, active/inactive timeout values, template refresh behavior and the collector's ability to process incoming records without loss.
How Port Mirroring, SPAN and TAP differ
Port Mirroring or SPAN copies packets from selected ports or VLANs to an analysis destination. RSPAN transports the copy in a Layer 2 domain; ERSPAN encapsulates mirrored traffic for delivery across an IP network. A physical or virtual network TAP is another mechanism for supplying packet copies.
The key difference from NetFlow and sFlow is access to packet-level content when capacity and configuration permit. DPI, IDS/IPS, protocol troubleshooting and forensic analysis may require this detail. Full packet copies, however, create much more traffic and storage. Oversubscribed mirror destinations or hardware replication limits can silently drop packets and weaken the evidence.
Should you choose NetFlow or sFlow?
Choose NetFlow/IPFIX
When conversations must be searched and retained with timing, volume, address, port and interface context.
Choose sFlow
When broad statistical visibility is required across many switch ports and high-speed links.
Choose SPAN/TAP
When payload, packet reconstruction, deep protocol analysis or packet-level evidence is required.
Use a hybrid model
When continuous NetFlow/sFlow visibility should trigger targeted packet capture during an investigation.
Start with the operational question rather than the protocol name: are you planning capacity, locating an anomaly, reconstructing a conversation or inspecting payload? Large networks often combine the native telemetry capabilities of different devices in one analytics layer instead of enforcing one protocol everywhere.
Operational use cases
DDoS and anomaly investigation
Throughput alone is not enough during a volumetric event. Packet rate, destination distribution, source diversity, protocol and port mix, and deviation from normal behavior should be evaluated together. NetFlow or sFlow can identify scope and likely participants; anomaly detection can then lead to routing or packet-level evidence.
Top talkers and capacity planning
Top-talker analysis is more than a ranking of IP addresses. Source/destination pairs, subnets, application ports, interfaces and time windows reveal where additional capacity may be needed and whether traffic matches business expectations.
ISP and data-center visibility
In multi-tenant or multi-site networks, exporter identity, observation domain, interface mapping, ASN and routing context become critical. Normalizing NetFlow v5, v9, IPFIX and sFlow into consistent dimensions lets teams query mixed telemetry without losing the origin and sampling context of each record.
Historical incident reconstruction
Retaining full packet capture continuously can be expensive. Flow telemetry can preserve answers to “which system communicated with which service, when and at what volume?” for longer periods. The evidentiary limits still depend on collection coverage, sampling and the organization's data-integrity controls.
Common NetFlow and sFlow deployment mistakes
- Ignoring time synchronization: correlation fails when exporters, collectors and related log sources disagree on time.
- Not monitoring templates: NetFlow v9/IPFIX data records cannot be decoded correctly when the relevant template is unavailable.
- Losing sampling context: volume estimates can be misread and exporters become impossible to compare.
- Confusing ingress and egress: incorrect interface mapping can reverse or double-count traffic.
- Counting one path repeatedly: totals inflate when observation points at edge and core are not modeled.
- Sizing only by Mbps: records per second, templates, disk IOPS, indexing and retention all matter.
- Ignoring telemetry packet loss: paths, ACLs and collector queues should be monitored.
- Forgetting NAT and asymmetric routing: one conversation may legitimately appear differently at multiple observation points.
How Flowtrion analyzes NetFlow and sFlow
Flowtrion analyzes NetFlow v5/v9, IPFIX and sFlow telemetry through common traffic dimensions, supporting both realtime and historical visibility. IP addresses, subnets, ports, protocols, interfaces, throughput and packet rate can be investigated in one workflow and connected to realtime traffic, top talker, anomaly, spoofing, SMTP, DNS and controlled BGP operations.
The objective is not merely to draw charts. A useful workflow detects an unexpected change, narrows down the sources and destinations behind it, compares the event with historical behavior and moves to packet-level or routing evidence when needed. To design exporter, sampling, timeout and retention settings for your environment, schedule a technical consultation with Flowtrion.
Frequently asked questions about NetFlow and sFlow
What is the main difference between NetFlow and sFlow?
NetFlow exports records describing observed traffic flows. sFlow statistically samples packet headers and periodically exports interface counters. The right choice depends on detail, scale and device support.
Does NetFlow capture packet payloads?
Typically no. NetFlow and IPFIX carry traffic metadata. Use SPAN, a TAP or packet capture when payload inspection is required.
Which port does sFlow use?
sFlow commonly sends datagrams to UDP port 6343. Always verify the actual collector port and ACL configuration on the exporter.
Can NetFlow and sFlow use the same collector?
Yes, when the collector supports both formats. The analytics layer should preserve sampling context, distinguish exporters and normalize fields without hiding their meaning.
Can sFlow miss small conversations?
Yes. A low-volume or short-lived conversation may not enter the statistical sample. Sampling should match detection objectives and critical use cases should use complementary telemetry.
Is NetFlow or sFlow always better?
No. Device support, line rate, required detail, retention and operational objectives determine the answer. Mixed networks can use both.
Authoritative technical sources
- RFC 3954 — Cisco Systems NetFlow Services Export Version 9
- RFC 7011 — IP Flow Information Export (IPFIX) Protocol
- sFlow.org — sFlow Version 5 specifications
- IANA — IPFIX Information Elements registry
Conclusion
NetFlow, sFlow and Port Mirroring are not interchangeable names for the same visibility method. NetFlow/IPFIX is strong for flow history and traffic metadata; sFlow provides scalable statistical sampling and interface visibility in high-speed networks; SPAN/TAP provides packet-level detail when content matters. A sound architecture begins with the operational question and combines these data sources when one method cannot answer it alone.