NetFlow and IPFIX Explained: Flow Records, Collectors and Privacy

NetFlow and IPFIX are protocols that summarise network traffic as flow records instead of copying packets. A router, switch, firewall or Linux host (the exporter) groups packets that share the same addresses, ports and protocol into a flow, counts their bytes and packets, timestamps the start and end, and sends that record to a collector that stores and queries it. IPFIX, defined in RFC 7011, is the IETF standard that grew out of NetFlow version 9.

A flow record does not contain what was said, but it records who talked to whom, when, for how long and how much. That makes it one of the most useful data sources in network security and one of the most sensitive. This guide goes through the record format, the jump from fixed NetFlow v5 records to IPFIX templates, sampling and its error bars, where flows come from, how collectors store them, what security teams do with them, the privacy and legal side, how to lock down the export path, and a full open source walkthrough you can run on two Linux machines.

It extends our earlier posts on how attackers intercept network traffic and SNMP. SNMP tells you how busy an interface is; flow export tells you which conversations made it busy.

Key takeaways

• A flow is a set of packets that share common properties (usually the 5-tuple: source and destination address, source and destination port, protocol) seen at one observation point during a time window. A flow record carries those keys plus counters (bytes, packets), timestamps, TCP flags seen, and interface and routing context.
• NetFlow v5 used one fixed record layout for IPv4. NetFlow v9 (RFC 3954, October 2004) introduced templates, so the exporter describes its own record layout. IPFIX (RFC 7011, September 2013, Internet Standard STD 77) standardised that idea as message version 10, with a public registry of information elements kept by IANA.
• sFlow (RFC 3176 and the sFlow version 5 specification) works differently: it samples individual packet headers and interface counters and leaves flow building to the collector. Sampling of any kind gives estimates with error bars that depend on the number of samples, not the traffic rate.
• Collectors such as nfdump (nfcapd) and pmacct (nfacctd, sfacctd) receive the records, write them to time binned files or databases, and answer questions such as top talkers, traffic to a given address, or flows with only a SYN flag.
• RFC 7011 says flow data "may be personally identifiable and privacy-sensitive". Treat collectors as systems holding personal data: limit retention, restrict access, and apply the anonymisation techniques in RFC 6235 before sharing.
• The export path is often plain UDP with no authentication. RFC 7011 requires TLS or DTLS support with mutual authentication, and when that is not possible recommends a dedicated network, source address filtering and never running an open collector.

What is a flow, and what does a flow record contain?

RFC 7011 defines a flow as a set of packets passing an observation point during a certain time interval, where all packets belonging to the flow share a set of common properties. Those common properties are called flow keys. The classic key set is the 5-tuple:

1. Source IP address
2. Destination IP address
3. Source transport port
4. Destination transport port
5. IP protocol number (6 for TCP, 17 for UDP, 1 for ICMP)

Many exporters add the input interface and the type of service byte to the key, which is why the same TCP connection can appear as two flows if it enters a router on two different interfaces. Flows are unidirectional by default: a web request from a laptop to a server and the response from the server to the laptop are two flow records with mirrored addresses and ports. RFC 5103 (January 2008) defines bidirectional flows, called biflows, for exporters that want to pair the two directions into one record.

The non key fields are what make a flow record useful. The IANA IPFIX information element registry gives each one an ID, a name and a data type. These are the fields you will see in almost every deployment:

Two details trip people up.

The TCP flags field is a union. The IANA definition says a bit is set to 1 "if any observed packet of this Flow has the corresponding TCP control bit set". A flow with flags showing SYN, ACK, FIN and PSH looks like a complete conversation; a flow whose only flag is SYN and which carries one or two packets is a connection attempt that got no answer or was refused. That single field is the basis of most flow based scan detection.

The counters are deltas. A long lived flow, such as a backup job or a video call, is reported several times. Each record covers only the packets seen since the previous one, so to get the total for that conversation you add the records up. The exporter decides when to emit a record using timeouts:

• Idle (inactive) timeout. No packet for this flow key for a set time, typically seconds to a minute depending on the platform and configuration. The flow is assumed finished.
• Active timeout. The flow has been open for a set time, configured in minutes on most platforms, so the exporter reports what it has and starts a new record. Without this, a week long connection would not appear in your data until it ended.
• End of flow detected. A TCP FIN or RST closes the record early.
• Resource pressure. The flow cache is full, so the oldest entries are pushed out.

The open source exporter softflowd exposes these directly. Its manual lists timeouts named general, tcp, tcp.rst, tcp.fin, udp, maxlife and expint, and notes that flows are also expired "if their traffic exceeds 2 Gib in either direction". The flowEndReason element lets the exporter tell the collector which of these happened.

What a flow record does not contain

A flow record has no payload. It does not contain the URL, the email subject, the SQL query or the file name. It also does not contain the TLS server name unless the exporter is configured with application aware extensions, which some platforms offer as extra information elements. Treat any claim that "flows show what users did" with care: they show that a conversation happened, its size and its timing. Often that is enough to infer a great deal, which is the privacy problem discussed below.

The IANA registry does also define elements that carry packet sections, such as ipHeaderPacketSection (313) and ipPayloadPacketSection (314), for packet sampling (PSAMP) export. If an exporter is configured to send those, the records do carry content, and RFC 7011 says such data should be protected against eavesdropping in transit.

How did NetFlow v5 and v9 evolve into IPFIX?

Flow export started as a feature of one router vendor's operating system, used for accounting, billing and capacity planning. Several versions came and went; version 5 became the one nearly every collector understood.

NetFlow v5: one fixed layout

Version 5 has a fixed header and a fixed record. Every record carries the same IPv4 fields in the same order: addresses, next hop, input and output interface index, packet and byte counts, first and last seen times (relative to the device uptime), ports, TCP flags, protocol, type of service, source and destination autonomous system and prefix masks. Collectors parse it with one hard coded structure.

The fixed layout was its strength and its limit. RFC 3954 explains the problem plainly: with fixed formats, every new field meant a new export format version and a new collector release to parse it. IPv6 addresses, MPLS labels, VLAN IDs or layer 2 addresses simply had nowhere to go in v5.

NetFlow v9: templates

RFC 3954, published as an Informational RFC in October 2004, documents version 9. Its key idea is the template. Before sending data, the exporter sends a template record that says, in effect, "records with template ID 256 contain field type 8 (4 bytes), then field type 12 (4 bytes), then field type 7 (2 bytes)" and so on. Data records then carry only values, packed back to back. The collector looks up the template ID to decode them.

The v9 export packet has a 20 byte header with these fields, per RFC 3954:

FlowSet ID 0 carries templates, FlowSet ID 1 carries options templates (metadata about the exporter itself, such as its sampling rate or interface names), and data FlowSets use IDs from 256 to 65535, matching the template that describes them. RFC 3954 says v9 export normally uses UDP but is designed to be transport independent and can run over SCTP.

IPFIX: the IETF standard

The IETF IPFIX working group took v9 as its starting point. The protocol was first published as RFC 5101 in 2008 and revised as RFC 7011 in September 2013, which obsoletes RFC 5101 and is Internet Standard 77. The companion documents are:

• RFC 7012, the information model: the abstract data types (unsigned8 to unsigned64, float64, ipv4Address, dateTimeMilliseconds, string, octetArray and others) and the rules for the IANA registry. It obsoletes RFC 5102.
• RFC 7013 (BCP 184), guidelines for anyone defining new information elements, so the registry does not fill with duplicates.
• RFC 5470, the architecture: metering process, exporting process, collecting process, observation points and observation domains.
• RFC 7014, flow selection techniques, and the PSAMP documents for packet sampling.
• RFC 6235, anonymisation support, covered in the privacy section.

The IPFIX message header is 16 bytes. Its version field is 0x000a, which RFC 7011 explains as the NetFlow v9 version number plus one. The other fields are length, export time (seconds since 1970), sequence number and observation domain ID. Note one quiet change: in v9 the sequence number counts export packets, while in IPFIX it counts data records sent, modulo 2 to the power 32. Collectors use the gap between expected and received sequence numbers to estimate loss.

Set IDs changed too. In IPFIX, Set ID 2 is a template set, Set ID 3 an options template set, and 256 and above are data sets. RFC 7011 states that Set ID values 0 and 1 are not used, which keeps an IPFIX parser from confusing itself with v9 FlowSets.

What templates and information elements look like on the wire

A template record is a template ID (256 or higher), a field count, and a list of field specifiers. Each field specifier is:

• one bit, the enterprise bit;
• a 15 bit information element ID;
• a 16 bit field length (65535 means variable length);
• if the enterprise bit is set, a 32 bit private enterprise number.

The enterprise bit is how vendors and open source projects add fields without waiting for IANA. An element with enterprise number set is interpreted against that organisation's own list. RFC 5103 uses this mechanism for biflows: reverse direction fields reuse the normal IDs under a reserved reverse information element private enterprise number. RFC 7013 asks authors to prefer the IANA registry for anything of general interest.

The IANA registry is large. The CSV export we fetched for this article lists assigned element IDs up to 533, with 534 to 32767 unassigned, and the registry page showed a last updated date of 11 September 2026. Some early elements have been deprecated in favour of the PSAMP generation; for example ID 34 samplingInterval is marked deprecated in favour of 305 samplingPacketInterval.

A worked example: sizing an IPFIX record

Here is a minimal template for an IPv4 flow and what each record costs on the wire:

A UDP datagram on a 1,500 byte Ethernet path has 1,500 minus 20 (IPv4 header) minus 8 (UDP header) minus 16 (IPFIX message header) minus 4 (set header) = 1,452 bytes for records. That fits 26 records of 55 bytes (1,430 bytes) per message.

Now scale it. An edge router producing 20,000 flow records per second generates 20,000 times 55 = 1.1 million bytes per second of record payload, or about 95 GB per day before compression and before the collector's own indexing overhead. That is why collectors compress files and why retention is a cost decision as well as a privacy one. RFC 7011 also allows reduced size encoding (sending a 64 bit counter in fewer bytes when values are small), which exporters use to shave this down.

How does sFlow sampling differ from flow caching?

NetFlow and IPFIX exporters usually keep a flow cache: a table in memory keyed by the flow keys, updated on every packet (or every sampled packet), and flushed by the timeouts above. The record that leaves the device is already aggregated.

sFlow, described in RFC 3176 (September 2001, Informational) and in the sFlow.org version 5 specification (July 2004, which replaces version 4), takes a different route. The agent on the switch does two kinds of sampling:

• Packet sampling. On average one in N packets is selected at random and its header (typically the first bytes of the frame) is sent to the collector together with the sampling rate and interface.
• Counter sampling. At a regular interval the agent sends the interface counters, similar to what you would poll with SNMP.

There is no flow cache on the device. The collector builds flow estimates from samples. That keeps the switch hardware simple and makes sFlow common on high speed data center switches, but it means every number you see is an estimate.

What sampling does to accuracy

The sFlow.org paper "Packet Sampling Basics" gives a simple estimate: if c samples of a traffic class were seen, the percentage error at 95 percent confidence is about 196 times the square root of 1/c. Accuracy depends on the number of samples of the thing you care about, not on the link speed.

Worked example 1: a large transfer. A host copies 2 GB out of the network in packets of about 1,500 bytes. That is roughly 1.33 million packets. At 1 in 1,000 sampling you expect about 1,333 samples. The error is 196 divided by the square root of 1,333, which is 196 / 36.5, or about 5.4 percent. The estimate will land between roughly 1.9 and 2.1 GB. Sampling is fine for volume based exfiltration detection.

Worked example 2: a quiet beacon. Malware calls home with one small packet a minute. Over 24 hours that is 1,440 packets. At 1 in 1,000 you expect 1.44 samples. The probability that a given packet is not sampled is 0.999, so the probability that none of the 1,440 is sampled is 0.999 to the power 1,440, about 0.24. Roughly one day in four the beacon leaves no trace at all, and on the other days the estimate rests on one or two samples (an error near 160 percent by the formula). Sampled data is poor evidence for low and slow activity.

Worked example 3, from the sFlow paper. A voice stream at one packet per second for an hour is 3,600 packets. At 0.25 percent sampling you see about 9 samples and the error is about 65 percent. Raising the rate to 1 percent gives about 36 samples and an error of about 33 percent; keeping 0.25 percent but analysing a month gives about 6,700 samples and an error of about 2.4 percent.

The lesson for security work: unsampled flow export on the links you investigate on (internet edge, data center core, VPN concentrators) is worth paying for. Sampled export is fine for capacity and DDoS volume questions.

Two more practical points. First, sampled NetFlow and IPFIX exist too: the router samples packets before feeding the flow cache. Exporters announce the rate in options records (the PSAMP elements 302 to 311, or the older 34 and 35). The nfdump documentation says its collector recognises these and automatically multiplies the byte and packet counts of each record by the sampling rate, while the flow count is not scaled because that would not be accurate enough. Second, the same documentation warns that not all platforms export their sampling information even when sampling is on. If your collector does not know the rate, every volume figure is off by that factor.

Where are flows exported from?

For overlays, our VXLAN and EVPN guide explains why the outer headers of tunnelled traffic hide the inner conversation. A flow exporter on the underlay sees one fat UDP flow between two tunnel endpoints on port 4789; you need export from the virtual switch, or an exporter that decodes the inner headers, to see the tenant flows. On a plain layer 2 network, Ethernet switching determines which ports a host based exporter on a mirror port will actually see.

Cloud VPC flow logs

Cloud flow logs follow the same idea with different packaging. Described only from each provider's own documentation:

• Amazon VPC Flow Logs. The VPC user guide says each record captures an IP traffic flow "characterized by a 5-tuple on a per network interface basis" within an aggregation interval, written as a space separated string. The default format includes the version, account, interface ID, source and destination addresses and ports, protocol, packets, bytes, start and end time, the action (accept or reject) and a log status. The aggregation interval can be 10 minutes or 1 minute, and you can define a custom format with extra fields.
• Google Cloud VPC Flow Logs. The documentation says the service "samples packets" and aggregates them by 5-tuple. The aggregation interval can be 5 seconds (the default), 30 seconds, 1 minute, 5 minutes, 10 minutes or 15 minutes, and a secondary sampling rate keeps 50 percent of log entries by default for configurations created through the Compute Engine API.
• Azure virtual network flow logs. Network Watcher writes JSON records to a storage account in the same region as the virtual network. Each record groups flow tuples by the rule that allowed or denied them, and each tuple lists a timestamp, source and destination address and port, protocol and further state and volume fields.

Three practical differences from router flows: the timestamps are coarse (the aggregation window), at least one provider samples by default, and records are tied to cloud identities (account, interface, subnet) rather than router interface indexes. Correlating them with on premises IPFIX needs a mapping layer.

How do collectors receive and store flows?

A collector is a server process that listens on a UDP, TCP or SCTP port, keeps a template cache per exporter and observation domain, decodes data records, and writes them somewhere you can query.

RFC 7011 sets the defaults: the collecting process listens on port 4739 for plain IPFIX and 4740 for TLS or DTLS protected IPFIX, on SCTP, TCP or UDP. NetFlow v9 has no port in RFC 3954; deployments pick one, and the open source tools use whatever you configure.

Template handling over UDP

Over UDP the collector may receive data before it has the template. RFC 7011 requires exporters using UDP to resend every active template at regular, configurable intervals and allows collectors to discard templates not refreshed within a lifetime that should default to at least three times the observed retransmission interval. Until the template arrives, data records are undecodable. In practice, after a collector restart you lose the first few seconds or minutes of data from each exporter, and if a template changes and the old one is cached, records can be misparsed. Over SCTP and TCP, templates are sent once per session and must be withdrawn explicitly.

Storage patterns

nfdump's design writes all collected data to disk before any analysis, separating collection from processing. Its README shows one collector per exporter on busy networks, or one collector that splits data per source with -n name,ip,directory. It supports LZO, LZ4, ZSTD and bzip2 compression and recommends LZ4 for real time use.

pmacct takes a different shape. Its daemons (nfacctd for NetFlow and IPFIX, sfacctd for sFlow, pmacctd for live capture) aggregate on the way in according to an aggregate: list such as src_host, dst_host and hand results to plugins that write to files, SQL, Kafka and others. It also has a tee plugin that replicates incoming flow packets to several downstream collectors, which helps when two teams both want the same exports.

What security uses do flows serve?

Flows are the cheapest complete record of "who talked to whom" you can keep for weeks or months. Full packet capture at the same scale is orders of magnitude larger. Common uses:

DDoS detection and response. A volumetric attack shows up as a sudden rise in flows, packets or bytes toward one destination, often with many sources, a single protocol (UDP reflection from DNS, NTP, memcached or similar services) and a small set of source ports. Flow based detectors compare current rates against baselines per destination prefix and trigger mitigation such as remotely triggered blackholing or a scrubbing service. Sampled flows are adequate here because the volumes are huge.

Scanning and reconnaissance. Many flows from one source to many destinations or ports, each with one or two packets and only the SYN flag, describe a horizontal or vertical scan. The tcpControlBits field makes this a simple filter.

Lateral movement. Inside a network, flows answer questions like "which workstations opened SMB, RDP, WinRM or SSH sessions to other workstations this week?" Workstation to workstation administration traffic is rare in most organisations, so new pairs stand out. This needs east west export (from core switches, virtual switches or host exporters), not just the internet edge.

Data exfiltration volume. Flows give bytes per destination per host. A host that normally uploads a few megabytes a day and suddenly sends 30 GB to a new external address, or a database server opening outbound connections at all, is visible without any payload inspection. Pair this with DNS logs to attach names to the addresses.

Command and control beacons. Regular, small, periodic flows to the same destination produce a narrow distribution of inter flow intervals and byte counts. This works only with unsampled data (see worked example 2) and with enough timestamp precision.

Incident scoping. When an indicator arrives (an IP address from a threat report, a compromised server), flows tell you which internal hosts communicated with it, when the first contact happened and how much moved. With 90 days of flows you can often answer "how long has this been going on" in minutes. This is the use that pays for flow collection in most organisations.

Policy verification. Flows show whether segmentation is real: if the cardholder data environment is supposed to accept only port 443 from two subnets, a query for any other flow into it is a continuous audit.

What flows cannot do: tell you what was in the conversation, detect attacks inside an allowed connection, or reliably attribute traffic behind NAT unless the NAT device exports its translations. They are also only as trustworthy as the export path, which brings us to security.

What do flow records reveal about people?

A flow record is metadata, and metadata about communication is revealing. From flows alone you can usually infer:

• which websites and services a device used, by resolving destination addresses (shared hosting and content delivery networks blur this, but not completely);
• when a person was at their desk, from the timing of their device's flows;
• which devices belong to the same person, from correlated timing;
• medical, religious, union or political associations, from destinations such as a clinic portal, a union server or a dating service;
• who communicated with whom inside the organisation.

RFC 7011 section 11.8 is direct about this: it warns that collected flow data can identify people and is privacy sensitive, and that its storage has to be protected by technical and policy means. RFC 6235 frames the core privacy goal of flow anonymisation as removing "the ability to assert that endpoint X contacted endpoint Y at time T".

How data protection law applies

This is not legal advice; check with counsel for your jurisdiction and sector.

European Union. Under the GDPR, personal data is any information relating to an identified or identifiable natural person, including by reference to an online identifier. Internal flow records keyed on addresses that map to named employees through DHCP leases, VPN logs and directory records are personal data in any practical reading, and public addresses that can be linked to a subscriber usually are too. You need a lawful basis (network and information security is commonly handled as a legitimate interest), a defined retention period, access control and, for large scale or systematic monitoring, a data protection impact assessment.

Telecommunications providers carry extra obligations on traffic data under the ePrivacy Directive (2002/58/EC), which in general requires traffic data to be erased or anonymised once it is no longer needed, with listed exceptions such as billing, and EU case law has limited general retention of traffic data by providers. The European Data Protection Board's Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive (final version dated 16 October 2024) address when gaining access to information on terminal equipment falls under that article; they are a reminder that network telemetry design choices can fall under ePrivacy rules as well as the GDPR. Have counsel confirm how both apply to your role.

United States. There is no single federal privacy law for employers monitoring their own networks, and monitoring company systems with notice is generally permitted. For providers and government access, federal law treats routing metadata separately from content: 18 U.S.C. 3127 defines a pen register as a device or process that records "dialing, routing, addressing, or signaling information", and excludes the content of communications from that definition. State consumer privacy laws can treat IP addresses as personal information in consumer contexts, and sector rules such as HIPAA apply when flows are tied to patient systems. Your acceptable use policy and employee notices should say that network metadata is collected and for what.

Retention: pick a number and enforce it

Retention is where privacy and cost meet. A practical pattern used by many security teams:

The numbers are illustrative; the point is that each tier has a purpose, an owner and a deletion job.

Anonymisation techniques from RFC 6235

RFC 6235 (May 2011, Experimental) catalogues techniques and defines how an IPFIX exporter can tell a collector which technique was applied to which field. For IP addresses it lists four schemes:

It also covers MAC address anonymisation, timestamp precision degradation, enumeration and random shifts, and counter binning and random noise for byte and packet counts. The RFC is candid that anonymisation is not absolute: substitution schemes can be attacked by matching traffic patterns to known hosts, and the more structure you preserve, the easier that is. Truncation is the safest default for sharing; prefix preserving pseudonymisation is for research partners under agreement.

How should exporters and collectors be secured?

RFC 7011 states three security requirements for IPFIX: confidentiality of flow records in transit, integrity (so nobody can inject false records or templates, or replay messages), and authentication of both ends. It also notes why attackers care: because IPFIX feeds forensics and billing, confusing, disabling or reading a collection system may be a prime objective in a sophisticated attack.

The threats

• Eavesdropping on exports. Plain UDP exports crossing a shared network give anyone with a tap or mirror port a complete map of your traffic. See our post on how attackers intercept network traffic for how that access is gained.
• Spoofed exports. UDP has no handshake, so an attacker who can send packets to the collector with a forged exporter source address can inject fake flows (to frame a host or hide a real one by flooding) or send fake templates that make later real records decode wrongly. RFC 7011 says plainly that over UDP and SCTP a collector cannot prevent fake messages from being processed, and from creating state, unless TLS or DTLS is in use.
• Sequence number games. RFC 7011 warns that a collector which simply resets its expected sequence number whenever it sees a later one can be blinded for a while by an attacker who injects messages with later sequence numbers.
• State exhaustion. Data records sent without templates, or floods of options templates, can make a collector hold state until it runs out of memory.
• Collector parsing bugs. IPFIX uses length prefixed encodings. RFC 7011 section 11.7 tells implementers to check message, set and variable length element lengths for consistency to avoid buffer sizing vulnerabilities, and to take care with ill formed UTF-8 strings. Collectors are C and C++ programs parsing untrusted binary input on a network port, which is exactly the kind of code that needs patching on time.
• Exposed collectors and dashboards. A collector web interface or flow database reachable from the internet is a data breach waiting to happen. The nfdump README says nfcapd has no built in access control and tells you to filter source addresses with host level security.
• Blinding by overload. RFC 7011 notes that over TCP, congestion control during an attack can make exports back off until they stall, leaving the collector blind exactly when it matters, while SCTP and UDP degrade more gracefully.

The controls

On network devices, the same hygiene applies as for SNMP: management plane access lists, authentication for the management protocol you configure exports with, and a configuration backup that you can diff. Our SNMP guide covers that side in depth.

Step by step: export IPFIX from a Linux host, collect it and query top talkers

This walkthrough uses two Ubuntu or Debian machines. The exporter runs softflowd, which captures packets with libpcap, keeps a flow cache and exports NetFlow v5, v9 or IPFIX (its manual lists version 10, which is IPFIX). The collector runs nfdump's nfcapd. Replace 192.0.2.10 (collector) and 192.0.2.20 (exporter) with your own addresses, and eth0 with your interface. Only monitor networks you are authorised to monitor, and tell users that network metadata is collected.

1. Install the collector

On the collector:

sudo apt update
sudo apt install nfdump
nfdump -V        # print the installed version

Create a storage directory owned by an unprivileged user:

sudo useradd --system --home /var/lib/flows --shell /usr/sbin/nologin flows
sudo mkdir -p /var/lib/flows/host1
sudo chown -R flows:flows /var/lib/flows

2. Restrict who can send to it

Allow the IPFIX port only from the exporter. With nftables:

sudo nft add table inet flowcol
sudo nft add chain inet flowcol input '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet flowcol input udp dport 4739 ip saddr != 192.0.2.20 drop
sudo nft list ruleset

This is the source address fallback described in RFC 7011 section 11.5. It does not stop a spoofed source on the same segment, so keep the export path on a management network.

3. Start nfcapd

Run it in the foreground first to see templates arrive, then as a daemon:

sudo -u flows nfcapd -w /var/lib/flows/host1 -p 4739 -S 2 -z=lz4

-w sets the directory, -p the port (nfcapd's own default is 9995, so set 4739 explicitly for IPFIX), -S 2 a date based subdirectory layout, and -z=lz4 compresses files as they are written. The manual gives a default rotation interval of 300 seconds, changeable with -t. Add -D to daemonise once you are happy, or better, run it from a systemd unit with User=flows, ProtectSystem=strict and ReadWritePaths=/var/lib/flows.

4. Install and start the exporter

On the host whose traffic you want to see:

sudo apt install softflowd
sudo softflowd -i eth0 -v 10 -n 192.0.2.10:4739 -t maxlife=5m -d

-i is the interface, -v 10 selects IPFIX, -n the collector, -t maxlife=5m forces long flows to be reported at least every five minutes (an active timeout), and -d keeps it in the foreground so you can watch it. Other useful options from the manual: -b for bidirectional IPFIX records (RFC 5103 style, only with -v 10), -s for a periodic sampling rate, -m for the maximum number of tracked flows, and a trailing BPF expression to exclude traffic, for example the export traffic itself:

sudo softflowd -i eth0 -v 10 -n 192.0.2.10:4739 -t maxlife=5m 'not (udp and port 4739)'

For a persistent setup, use the service unit your distribution package ships (check its configuration file for the interface and options) or write a small systemd unit that runs the same command line. The control tool softflowctl talks to the running daemon over its control socket and can print statistics, including the reasons flows expired.

Generate some traffic on the exporter (curl https://example.com, an apt update) and wait for the active or idle timeout.

5. Confirm records arrive

On the collector:

ls -R /var/lib/flows/host1 | tail
nfdump -r /var/lib/flows/host1 -c 20

-r accepts a single file or a directory, and -c 20 stops after 20 records. You should see start time, duration, protocol, source and destination address and port, packets and bytes. If nothing arrives, check sudo tcpdump -ni any udp port 4739 on the collector, then the firewall rule, then the exporter's interface name.

6. Query top talkers

Top source addresses by bytes:

nfdump -r /var/lib/flows/host1 -s srcip/bytes -n 10

Top destination addresses by bytes for HTTPS only, using nfdump's filter syntax:

nfdump -r /var/lib/flows/host1 -s dstip/bytes -n 10 'proto tcp and dst port 443'

The heaviest conversations, aggregated by source and destination address:

nfdump -r /var/lib/flows/host1 -s record/bytes -A srcip,dstip -n 20

A time window using the first seen and last seen filter primitives (the older -t option is now marked legacy in the manual):

nfdump -r /var/lib/flows/host1 -s dstip/flows -n 10 \
  'first seen >= 2026-10-23T09:00:00 and last seen <= 2026-10-23T10:00:00'

Flows that carried only a SYN, a simple scan or failed connection indicator:

nfdump -r /var/lib/flows/host1 -o long 'proto tcp and flags S and not flags AFRPU' -c 50

JSON output for a pipeline or a notebook:

nfdump -r /var/lib/flows/host1 -o json -c 100 > sample.json

The manual also offers -o ndjson (one object per line, convenient for log shippers) and user defined CSV formats.

7. Set retention

nfdump ships nfexpire to age out files by lifetime or total size. Its manual accepts lifetimes such as 31d or 240H. To expire everything older than 30 days:

sudo -u flows nfexpire -e /var/lib/flows/host1 -t 30d

Run it from a systemd timer so the limit you agreed in the retention table is enforced every day, and check it with nfexpire -l /var/lib/flows/host1.

8. Alternative: pmacct for SQL or Kafka

If you want aggregated tables instead of raw files, pmacct's nfacctd listens for NetFlow and IPFIX and hands aggregates to plugins. A minimal configuration, following the pattern in its QUICKSTART:

! /etc/pmacct/nfacctd.conf
daemonize: false
nfacctd_port: 4739
plugins: print
print_refresh_time: 60
print_output: csv
print_output_file: /var/lib/flows/pmacct-%s.csv
aggregate: src_host, dst_host, dst_port, proto

Run nfacctd -f /etc/pmacct/nfacctd.conf. Swap the print plugin for the PostgreSQL or Kafka plugins once the aggregation keys look right. The same firewall rule applies, since nfacctd also accepts whatever reaches its port.

NetFlow v5, v9, IPFIX, sFlow and cloud flow logs compared

Common mistakes

• Not knowing the sampling rate. A collector that does not receive or apply the sampling rate underreports volumes by that factor. Confirm the options template arrives and that your collector scales counters.
• Treating sampled flows as complete evidence. Absence of a flow in sampled data is not evidence that a connection did not happen. Say so in incident reports.
• Exporting only at the internet edge. Lateral movement never crosses the edge. Add export from core, data center and virtual switching layers.
• Long active timeouts. A 30 minute active timeout means a long exfiltration session is invisible for half an hour. One to five minutes is a common compromise.
• Forgetting NAT. Edge flows after NAT show only the public address. Export NAT events or flows from the inside interface too.
• Clock drift. Flow timestamps come from the exporter's clock. Without NTP on every exporter, correlating flows with logs fails at exactly the moment you need it.
• Running an open collector. A collector that accepts exports from anywhere, on a reachable interface, invites injected data and denial of service.
• Exports across user networks in clear text. Anyone who can mirror a port on that path can read the whole traffic map.
• No retention limit. Keeping raw flows forever turns a monitoring system into a long term surveillance archive, with matching legal and breach risk.
• Unpatched collector software. Collectors parse untrusted binary input. Track their versions and their container images like any exposed service.
• Sharing data without anonymising. Sending raw flows to a vendor or research partner without truncation or pseudonymisation shares personal data.

FAQ

What is the difference between NetFlow and IPFIX?

NetFlow is the family of flow export formats that started on one vendor's routers; version 9 introduced templates. IPFIX is the IETF standard based on version 9, defined in RFC 7011 with message version number 10. IPFIX adds variable length fields, enterprise specific elements, a public IANA registry, SCTP as a mandatory transport and TLS or DTLS security.

Is IPFIX the same as NetFlow v10?

In practice, yes. The IPFIX header's version field is 10, which RFC 7011 describes as incrementing the NetFlow v9 version by one. Many tools, including softflowd, label IPFIX as version 10.

What port does IPFIX use?

RFC 7011 sets 4739 as the default for plain IPFIX and 4740 for TLS or DTLS protected IPFIX, on SCTP, TCP or UDP. Both exporter and collector must let you change the port. NetFlow v9 has no standard port; each deployment picks one.

Is sFlow better than NetFlow?

They answer different needs. sFlow samples packets and counters with no flow cache, which suits very fast switches and traffic engineering. NetFlow and IPFIX keep a flow cache and can export every flow, which suits security investigations. Many networks use sFlow in the data center and IPFIX at the edge.

Can NetFlow see HTTPS traffic content or URLs?

No. Standard flow records carry addresses, ports, protocol, counters, timestamps and flags, not payload. Some platforms add application identification elements, and packet sampling elements can carry header or payload bytes, but a normal IPFIX record shows only that a host talked to an address on port 443, how much and for how long.

Are flow logs personal data under GDPR?

Usually, yes, when the addresses can be linked to a person, for example through DHCP leases, VPN logs or directory records. The GDPR covers information that identifies a person directly or indirectly, including through online identifiers. You need a lawful basis, a retention period, access control and often a data protection impact assessment. Ask counsel how this applies to your organisation.

How long should I keep NetFlow data?

Long enough to investigate incidents you might find late, short enough to limit privacy and breach exposure. Many teams keep raw flows for 30 to 90 days and aggregated, less identifying data for a year. Write the number down, tie it to a purpose and automate deletion.

How do I export NetFlow from a Linux server?

Install an open source exporter such as softflowd, point it at an interface and a collector, and pick a version: softflowd -i eth0 -v 10 -n 192.0.2.10:4739 exports IPFIX. nfdump's nfpcapd and pmacct's pmacctd are alternatives that capture and convert traffic too.

Can someone fake NetFlow or IPFIX data?

Over plain UDP, yes, if they can send packets that appear to come from an exporter. RFC 7011 says there is no way to prevent fake message processing over UDP or SCTP without TLS or DTLS. Use mutual authentication where your exporters support it, otherwise a dedicated network, source address filtering and sequence number monitoring.

Do cloud VPC flow logs use IPFIX?

No. The major cloud providers publish their own record formats (space separated text or JSON) and deliver them to their logging or storage services. The concepts match: records are keyed on the 5-tuple and aggregated over a time window. You map their fields to your IPFIX schema at ingestion.

Fix it without waiting for upstream

Flow collection runs on software you build or deploy yourself: open source collectors written in C, packet capture libraries, exporters on Linux hosts, container images for the collector stack and Python or Go pipelines that parse and enrich records. RFC 7011 tells collector authors to guard against buffer sizing bugs in length prefixed parsing, so keeping those components and their dependencies current matters as much as hardening the export path.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not collect or analyse flow records, detect network attacks or monitor traffic. Where it fits is the software around your flow pipeline: the repositories and container images for collectors, enrichment scripts and dashboards, and the open source components inside them. Router and switch firmware that exports flows is outside its scope; those fixes come from the device vendor.

The first demo is a real Safeguard CLI session. You ask it to fix a vulnerable dependency, it reads the finding and the advisory, asks before each command, edits the manifest, runs the install and the tests with your approval, and pushes nothing on its own. The same flow applies to a flow enrichment service or a top talkers reporting script that pins an outdated library.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, and scans from the terminal. Flow collectors usually live on management networks with no inbound internet access; running the scan locally lets you check a collector's source tree or container image where it already sits.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A network engineer could then ask which projects in the monitoring estate contain a given component and version, from the same assistant used to review collector configuration.

Click through it at your own pace, or open it full screen.

To try it on your own monitoring repositories and images, download Safeguard and follow the CLI documentation.

Quick check

Sources

• RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol
• RFC 7012, Information Model for IP Flow Information Export (IPFIX)
• RFC 7013, Guidelines for Authors and Reviewers of IPFIX Information Elements
• RFC 3954, NetFlow Services Export Version 9
• RFC 6235, IP Flow Anonymization Support
• RFC 5103, Bidirectional Flow Export Using IPFIX
• RFC 5470, Architecture for IP Flow Information Export
• RFC 7014, Flow Selection Techniques
• RFC 3176, InMon Corporation's sFlow
• IANA IP Flow Information Export (IPFIX) Entities registry
• IANA IPFIX Information Elements (CSV)
• sFlow Version 5 specification, sFlow.org
• Packet Sampling Basics, sFlow.org
• nfdump README, GitHub
• nfdump manual page, GitHub
• pmacct README and QUICKSTART, GitHub
• softflowd README, GitHub
• softflowd manual page, GitHub
• Flow log records, Amazon VPC User Guide
• VPC Flow Logs, Google Cloud documentation
• Virtual network flow logs overview, Azure Network Watcher documentation
• 18 U.S.C. 3127, Definitions for chapter (pen registers and trap and trace devices), Legal Information Institute
• nfcapd manual page, GitHub
• nfexpire manual page, GitHub
• pmacct CONFIG-KEYS, GitHub
• EDPB Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive

Last reviewed: 23 October 2026. IANA adds information elements over time and collector options change between releases; check the registry and your installed tool's manual before relying on a specific field ID or flag.