NetFlow and Network Telemetry: Seeing What Your Network Is Actually Doing

By Taylor Thomas · 2026-08-29

Every detection strategy stands on a visibility layer, and the uncomfortable audit question — if something got in, would we know? — is answered or not answered there. Firewalls can log what they block and what they permit, but only at the points where traffic crosses them; the interior of the network is where the question goes quiet. NetFlow, and the broader family of network telemetry that grew out of it, answers by making the network describe its own conversations: the routers and switches that support flow export become sensors reporting who talked to whom, when, and how much — conversation metadata rather than payload.

What a Flow Record Carries

A flow record summarizes a unidirectional stream of packets that share common properties. Classic NetFlow keys a flow on seven fields — source and destination IP address, source and destination port, Layer 3 protocol, type-of-service byte, and input interface — and accumulates counters against each record: timestamps, byte and packet counts, TCP flags. No payload rides in the record. That restraint is the design, not a limitation: a flow record is a tiny fraction of the traffic it describes, which makes broad coverage and long retention realistic capacity-planning goals rather than the storage problem full capture poses — and shape is where much attacker behavior shows itself. A workstation that begins moving gigabytes at 03:00 to an address range the business has no relationship with has already told you where to start asking questions, payload unseen. A packet capture answers deeper questions about shorter windows; flow data answers broad questions about long ones, and the two work best together, the flow record deciding where a capture is worth taking.

From Fixed Fields to Templates: v5, v9, IPFIX

NetFlow v5 shipped with a fixed record format: a v5 exporter can say exactly one kind of thing, about IPv4 only, and the format cannot grow without a new protocol version. Version 9 solved that with templates — the exporter first sends a template describing the layout of the records that follow, so new fields ride the existing protocol — and the IETF took v9 as the starting point for IPFIX, the vendor-neutral flow-export standard whose messages carry version number 10 in their headers. The practical reading of the lineage: v5 still surfaces on legacy gear and in old collector configurations, v9 is the widely deployed Cisco format, and IPFIX is the IETF standard modern collectors commonly support.

Flexible NetFlow: Records You Define

On Cisco IOS and IOS-XE, Flexible NetFlow hands the template machinery to the engineer. The common export design composes three objects: a flow record naming the key fields that define a flow and the non-key fields collected about it, a flow exporter pointing at the collector, and a flow monitor binding record to exporters — a monitor can reference more than one — applied to an interface in the input or output direction, as the platform and release support. Choosing key fields tunes the record to the question being asked — a capacity-planning record and a lateral-movement-hunting record need not look alike. Where full accounting costs more than the platform can afford, a sampler can be added to process a subset of packets; the trade is visibility, because sampling can miss exactly the short, low-volume flows an investigation cares about most.

Telemetry as a Security Sensor

Exported flows become a security instrument at the collector. Fed into an analytics platform or a SIEM/XDR pipeline, flow data supports behavioral detection: baselines of who normally talks to whom, an alarm when a badge server begins talking to the finance database, and an evidence trail for incident response that typically reaches back further than a capture archive kept under comparable storage constraints. How that telemetry tier divides its labor is its own design question — SIEM vs XDR — and flow records are among the richest network-side inputs any division of it can consume. Because basic flow analysis operates on metadata rather than payload, it kept working as the internet encrypted: outer addresses, timing, sizes, and durations remain observable, though tunnels and privacy technologies can hide the sessions running inside them. Enriched flow telemetry extends the reach further by exporting observable characteristics of encrypted sessions — metadata visible without decryption — which is the foundation of encrypted traffic analysis. None of it breaks the encryption; all of it narrows where the expensive tools need to look.

Where the Exam Meets the Job

On the SCOR 350-701 v2.0 blueprint this topic surfaces twice. Objective 2.2, in the Network Security domain (25%), asks candidates to describe security monitoring and telemetry technologies — the flow-export machinery this article covers. Objective 6.6, under Network Access, Visibility, and Enforcement (15%), frames the operational side: network visibility and enforcement using telemetry with XDR and SIEM/SOAR platforms. Detection, response, and forensics all inherit the quality of the telemetry beneath them, which makes Flexible NetFlow a compact skill with outsized reach. The SCOR course configures and reads it on live lab gear.

Frequently Asked Questions

What is the difference between NetFlow and a packet capture?

A full packet capture retains complete observed packets, payload bytes included — though captures are routinely filtered or truncated, and encrypted payloads stay encrypted — at high cost in storage and processing. NetFlow records metadata about conversations: who talked to whom, when, on which ports, and how much. Flow data is compact enough to cover whole networks and long retention windows; captures answer deep questions about short ones.

What is the difference between NetFlow v9 and IPFIX?

NetFlow v9 is Cisco's template-based export format; IPFIX is the IETF standard derived from it, and IPFIX messages carry version number 10 in their headers. The template idea is the same in both: the exporter describes its record layout before sending records, so a collector can decode layouts the original protocol version never defined — with field meanings drawn from standard or enterprise-specific information element definitions.

Can flow data help with encrypted traffic?

Yes, because basic flow analysis operates on metadata rather than payload. Addresses, timing, sizes, durations, and peer patterns generally remain observable under encryption — though tunnels and privacy technologies can hide the sessions inside them — and enriched flow telemetry adds observable characteristics of encrypted sessions. That combination is the basis of encrypted traffic analysis, which can surface threats without decrypting anything.