Ask a room full of network engineers what's in a flow record, and you'll get the same answer nine times out of ten: source IP, destination IP, source port, destination port, protocol. The five-tuple. Add bytes and packets and you've described the mental model most of the industry still carries around.
That model is thirty years old. It describes NetFlow v5, a fixed-format record with a fixed set of fields. That made it easy to learn and easy to remember. It's also why flow data has a lingering reputation for being thin. Fine for who talked to whom and how much. Useless for most of the questions that come after.
The reputation is out of date.
What changed
NetFlow v9 introduced templates, which let the exporter describe its own record format instead of conforming to a fixed one. IPFIX (RFC 7011) standardized the vocabulary on top of that. Every field is an Information Element with a registered ID, a data type, and defined semantics, catalogued in an IANA registry that has grown well past element ID 500. The information model also reserves space for enterprise-specific elements, so any vendor with a Private Enterprise Number can define its own.
A modern flow record isn't a fixed row of five columns. It's a schema you negotiate with your own infrastructure.
What fits in a flow record
Identity, not just addresses
Firewalls and authentication integrations can carry the username tied to a session. Switches can export source and destination MAC addresses, VLAN IDs, and VRF names. Wireless controllers attach SSID and access point identifiers. "10.14.6.203 did something odd" becomes "Dana's laptop, on the guest VLAN, through AP-3F-East."
Application identity
Elements like applicationId and applicationName, populated by NBAR2 and similar classification engines, tell you the traffic on port 443 was Salesforce, or a Windows update, or a video call. Port number stopped being a useful proxy for application years ago.
Performance, measured on the wire
Round-trip time, server response time, network delay, jitter, TCP retransmits and out-of-order counts, even MOS scores. These come from performance-monitoring exports, SD-WAN appliances, and metadata-generating probes. This is the category that surprises people, because it turns flow from an accounting record into a service-quality measurement.
Translation state
postNATSourceIPv4Address, postNAPTSourceTransportPort, natEvent, firewall action and deny reason. If you've ever been handed a public IP and a timestamp by an outside party and had to figure out which internal host was behind it, these elements are the difference between an answer and a shrug.
Path and policy
Source and destination BGP AS numbers, next-hop addresses, MPLS labels, DSCP markings, forwarding status, flowEndReason, tunnel identifiers, SD-WAN provider and policy fields. Enough to reason about why traffic took the path it took.
Layer 7 metadata
DNS query names and response codes. HTTP host, URI, user agent. TLS server name indication, cipher suites, certificate subjects. Encrypted-traffic analysis without decryption, straight from metadata that already ships inside IPFIX. Routers generally don't produce this; metadata generators and packet brokers do, and it lands in the same pipeline as everything else.
Cloud and virtual context
VXLAN VNIs, tenant and VPC identifiers, container and workload metadata. The fields you need when the "interface" a flow crossed is a software construct that existed for eleven minutes.
Three problems that get easier
- The NAT wall. An abuse report names one of your public addresses. With NAT elements exported at the edge, the translation is already in the flow record. You pivot from public address and port to internal host in one query, instead of reconciling flow records against separate firewall syslog.
- The encrypted blob. Ninety percent of your egress is TCP/443 and payload inspection isn't on the table. Application IDs, SNI values, and encrypted-traffic metadata let you separate sanctioned SaaS from shadow IT from a beacon talking to a newly registered domain, without decrypting anything.
- "The network is slow." With RTT, retransmit counts, and application identity in the same record, you can say which application, across which interface pair, degraded, at which minute, and whether the delay sat on the network side or the server side. That's a different conversation with the application team than "flows look normal."
Run one of these down and the workflow looks the same every time. An anomaly or a ticket surfaces the affected host and time window. You pull the flow records for that window. The enriched fields confirm or rule out each candidate cause. Application identity, NAT state, path, and performance data lead you to a specific interface, host, or policy change.
Flow data vs. packet capture: when you need which
The reflex answer to "flow is thin" has always been packet capture. Capture everything, keep it, search it later. That works, and the bill for it shows up later than the decision does.
A flow record is a summary of a conversation. A full packet capture is the conversation itself, byte for byte, payload included.
Storage. Flow scales to months and years of history on storage you can budget for, particularly with tiered retention where recent data sits on fast disk and older data ages down to something cheaper. Full packet capture at line rate across every segment doesn't scale that way. Teams who try it end up with short retention windows, and those windows expire the week before you need them.
Query speed. A flow record is a set of typed, named fields with defined semantics. That is a database row. You can index it, baseline it, and report against it in seconds. A packet capture is a file you open, and finding the thing you want inside it is its own project.
AI queries. Structured data with known field semantics is what agents and language models query well, and it's what IPFIX standardized. An agent can ask which application degraded on which interface pair, pivot to the hosts involved, then check what else those hosts were doing. Every one of those is a registered element with a defined meaning. Point the same agent at raw packet captures and the work gets expensive fast. Richer templates mean more questions an AI can answer without touching a payload.
Packets still matter. When you need to prove exactly what crossed the wire, nothing else does that.
Where Plixer fits
Because NetFlow v9 and IPFIX templates define what each device sends, the reporting available for any exporter depends on what that exporter's template contains. A MAC-based report appears for devices exporting MAC addresses and not for the ones that don't. Scrutinizer makes that relationship visible: a per-device view of every template you're receiving, username reporting from firewalls and authentication sources, support for standard and vendor-specific elements from SD-WAN platforms. Any NetFlow or IPFIX element can be baselined and alerted on. No probes to deploy for any of it, because it's built from the flow your infrastructure already exports and collected through software, not a sensor bolted onto every segment. Configurable multi-tier storage decides how much full-detail flow stays hot and for how long, so you decide how far back the history goes.
The packet half is FlowPro. It's a hardware appliance or a virtual appliance, deployed where you need packet-level proof rather than on every link. It captures selectively against rules you define, starts and stops those captures on its own, and hands the PCAP back through Scrutinizer straight from the alarm that triggered it. Flow everywhere, unsampled. Packets where the question demands them.
If you want that data queryable by the AI your team already runs, the Scrutinizer MCP server is how you connect it to your own network data.
The catch
Exporters ship conservative defaults. Most devices are capable of far more than they're configured to send. Richer templates are usually a configuration change, not a license or feature.
The collectors must support vendor-specific information elements. Templates are the decoder ring, and a collector that doesn't recognize an element either drops it or renders it as raw hex. RFC 5610 lets exporters describe their own elements so collectors can interpret them automatically, but support for it is inconsistent across vendors, which leaves some collectors decoding unfamiliar fields the hard way. Ask what yours does with a field it's never seen.
Volume is real. Wider records at full granularity cost storage and query time, and high-cardinality fields like URIs will surprise you. Plan it deliberately instead of enabling everything at once.
Where to start
Look at the templates you're already receiving before changing any configuration. Most environments are already being sent fields nobody has ever queried. Pick one question you currently can't answer, find the element that answers it, enable it on a single exporter, and confirm it decodes end to end. Then repeat. This is an incremental project, not a migration.
If you're troubleshooting the NAT wall specifically, see how Scrutinizer pivots from a public IP straight to the internal host: 'A practical guide to finding NAT traffic'. And if the encrypted-traffic problem is the one keeping you up, see how encrypted-traffic metadata replaces payload inspection: 'How To Investigate Encrypted Traffic Without Decrypting It' covers that in more depth.
Key Takeaways
- The five-tuple describes NetFlow v5. NetFlow v9 templates and IPFIX's IANA-registered Information Elements describe something much wider.
- A modern flow record can carry identity, application name, on-the-wire performance metrics, NAT translation state, path and policy data, Layer 7 metadata, and cloud context, if the exporter is configured to send it.
- Richer records turn three routine headaches — the NAT wall, the encrypted blob, and "the network is slow" — into single-query answers.
- What your collector can report depends on what it can decode. A template your collector drops might as well not exist.
- Flow and packet capture answer different questions. Flow gives you months to years of queryable history at a storage cost you can plan for. Packets give you byte-level proof of a specific moment.
- Structured, typed flow fields are what make the data queryable by an AI agent.
- Start by auditing what you're already receiving, not by buying anything new.
Next Steps
Pull up your own collector and check the template inventory for one exporter you'd expect to be rich. An edge firewall or an SD-WAN appliance is a good first stop. See what's arriving and what's being dropped. If you're running Scrutinizer, the per-device template view will show you this directly, one exporter at a time, without adding a sensor to see it.
See it in action: request a meeting and we can help you evaluate the current state of your NetFlow.
Book a DemoFrequently Asked Questions
NetFlow v9 introduced the template mechanism that lets an exporter describe its own record format. IPFIX (RFC 7011) standardized that idea into an open format with a registered, vendor-extensible element catalog. Most modern exporters speak one or both, and for the purposes of this article they behave the same way.
Usually not. Most of this is a configuration change on equipment you already own. The fields exist in firmware; they're not turned on by default.
Exporting more fields adds some overhead on the device and more volume at the collector. Enable templates one exporter and one question at a time. Then measure the added device load and collector volume.
No, and anyone selling you that is overstating it. Flow answers who, what, when, how much, over what path, and how well it performed, going back months or years across the whole network. Packets prove exactly what crossed the wire at a specific moment. In practice you want flow everywhere and targeted capture where the question requires it.
IPFIX elements are typed and semantically defined, which makes flow records efficient to store and query. Raw packet captures have to be parsed first, which gets slow and expensive at scale.
That field is invisible to you until the collector adds support for it. Worth asking any collector vendor, including us, what happens with elements it hasn't seen before.