Netflow/IPFIX

What NetFlow and IPFIX tell you about network traffic

NetFlow and IPFIX are flow telemetry formats, not packet payload capture. They turn conversations into records that show who talked to whom, when, over which protocol and how much data moved, which makes them useful for understanding network behaviour at scale, especially when full packet capture is impractical.

That design choice matters because flow records preserve useful context while reducing storage and collection overhead. They are common in routers, switches and collectors, and they are often the first layer of visibility for traffic baselining, anomaly hunting and capacity analysis.

How flow records are structured and exported

Both formats describe traffic as a series of fields rather than a packet-by-packet transcript. Typical records include source and destination addresses, ports, protocol identifiers, timestamps and byte or packet counters. IPFIX extends the model through templates, which lets exporters define richer and more flexible field sets than older fixed-format approaches.

That flexibility is one reason IPFIX is widely used in modern environments. It can carry vendor-specific information elements and adapt to different network devices or telemetry needs, while still preserving the core idea of summarising conversations into exportable flow records.

In practical terms, the value of the data depends on collector design, export reliability and the consistency of the fields you retain. The NetFlow and IPFIX Flow Telemetry Guide covers templates, key fields, collector design and export security in one place.

Where NetFlow and IPFIX are used in security operations

Flow telemetry is especially useful when defenders need visibility without collecting every packet. It supports traffic analysis, baseline development, east-west visibility, service dependency mapping and suspicion-based triage when encrypted traffic limits payload inspection. It can also help identify beaconing, unusual connection patterns and exfiltration-shaped movement even when content is hidden.

That is why flow data usually sits alongside other network telemetry rather than replacing it. A flow record can show the shape of communications, but it rarely explains intent by itself, so analysts often correlate it with DNS, endpoint, proxy, firewall or packet evidence.

The Network Monitoring and Packet Capture Guide explains how flow data fits with pcap, retention and privacy decisions, while the NDR Guide shows how flow logs support detections and SOC response.

What NetFlow and IPFIX can and cannot prove

Flow data is powerful for pattern recognition, but it is not a forensic substitute for packet capture. It usually cannot reveal payload content, decrypted application data or the full sequence of application-layer behaviour. It may also miss short-lived connections, be affected by sampling, or be less useful if collectors, templates or export paths are misconfigured.

That limitation means defenders should treat flow records as high-value metadata, not complete evidence. They are best used to establish scope, identify suspicious paths and guide deeper inspection, then validated with richer sources when the case requires it.

The Network Forensics Guide is a useful companion when flow records need to be correlated with packet capture, Zeek, Suricata or retention considerations.

Why NetFlow and IPFIX matter for defenders and operators

For defenders, these protocols help answer a basic but important question: what was talking to what, and how much? For operators, they help with capacity planning, application dependency mapping and spotting abnormal traffic growth before it becomes a service issue. The same records can serve both reliability and security goals if collection is consistently engineered.

Definitions still vary a little across vendors and deployments, especially around extended fields, template handling and what additional metadata is exported. The safest operational assumption is to document exactly which exporter, collector and field set you are using so analysts understand the limits of the records they receive.

The Networking Fundamentals for Defenders Guide gives the routing, switching and visibility context that makes flow telemetry easier to interpret.

Related resources from NHI Mgmt Group

• How should security teams normalise NetFlow and IPFIX without losing meaning?
• Why do mixed NetFlow and IPFIX environments need exporter-aware normalisation?
• How does NetFlow work?
• What are the key NetFlow best practices?