9.2 Flexible NetFlow (FNF) Architecture: Flow Records, Exporters, and Monitors
Key Takeaways
A network flow is defined as a unidirectional sequence of packets traversing an observation point that share a common 7-tuple: source IP, destination IP, source port, destination port, Layer 3 protocol, ingress interface, and IP Type of Service (ToS).
Traditional NetFlow uses a fixed seven-field flow key (usually exported as v5 or v9), whereas Flexible NetFlow (FNF) introduces a modular architecture that cleanly separates flow records, flow exporters, and flow monitors.
In FNF flow records, match statements define key fields that establish unique flow cache entries, whereas collect statements define non-key fields that gather metrics, timestamps, and routing telemetry without altering flow boundaries.
Flow monitors bind records to exporters and manage cache aging timers, maintaining an active timeout (default 1800 seconds) for long-lived flows and an inactive timeout (default 15 seconds) for idle connections.
Flow exporters define external telemetry destinations using UDP port 2055 (NetFlow v9) or UDP port 4739 (IPFIX RFC 7011), requiring periodic template export timeouts to allow collectors to decode variable flow formats.
Flexible NetFlow (FNF) Architecture: Flow Records, Exporters, and Monitors
Network visibility and traffic telemetry are essential requirements for modern enterprise security monitoring, capacity planning, application performance profiling, and billing accounting. While packet capture tools inspect raw frame contents, analyzing every packet traversing a multi-gigabit core network creates unsustainable processing, storage, and bandwidth burdens. NetFlow addresses this challenge by aggregating individual packets into abstract conversation summaries known as flows. Flexible NetFlow (FNF) evolves this telemetry paradigm into a highly modular, customizable architecture that empowers network engineers to tailor traffic tracking precisely to organizational monitoring requirements.
The Network Flow Definition and the Classical 7-Tuple
In IP networking, a flow is formally defined as a unidirectional sequence of packets traversing a specific network observation point that share identical attributes within a designated observation time window. If two hosts engage in a bidirectional TCP session (such as a web client accessing an HTTPS server), the conversation consists of two distinct, independent flows: one representing client-to-server traffic and the second representing server-to-client traffic.
In traditional NetFlow architectures, a flow is uniquely identified by the classical 7-tuple:
- Source IP Address: The Layer 3 IPv4 or IPv6 address originating the datagram.
- Destination IP Address: The Layer 3 IPv4 or IPv6 address receiving the datagram.
- Source Transport Layer Port: The Layer 4 port number (TCP or UDP) identifying the client socket.
- Destination Transport Layer Port: The Layer 4 port number identifying the server daemon or service.
- Layer 3 Protocol Type: The IP protocol number (e.g., protocol 6 for TCP, protocol 17 for UDP, protocol 1 for ICMP).
- Ingress Interface: The physical or logical switchport/sub-interface where the packet entered the routing device.
- IP Type of Service (ToS): The byte representing IP precedence or Differentiated Services Code Point (DSCP) markings.
Incoming Packet Stream
[Packet 1: 10.1.1.10:49152 -> 192.168.1.100:443, TCP, Ingress Gi0/1, DSCP EF] ---\
[Packet 2: 10.1.1.10:49152 -> 192.168.1.100:443, TCP, Ingress Gi0/1, DSCP EF] ----> MATCH: Updates Flow 1 Counters
[Packet 3: 10.1.1.10:49152 -> 192.168.1.100:443, TCP, Ingress Gi0/1, DSCP CS0] ---> MISMATCH (DSCP differs): Creates Flow 2
[Packet 4: 10.1.1.20:51234 -> 192.168.1.100:443, TCP, Ingress Gi0/1, DSCP EF] ----> MISMATCH (Src IP differs): Creates Flow 3
When a packet arrives at an interface configured for NetFlow, the forwarding engine extracts these seven fields. If an existing entry in the device's NetFlow cache shares the exact same 7-tuple, the device increments the packet and byte counters for that cache entry and updates the timestamp of the last observed packet. If any single value among the seven fields differs, the forwarding engine instantiates a brand new, independent flow entry in the cache.
Evolution: Traditional NetFlow vs. Flexible NetFlow
Traditional NetFlow (principally versions 5 and 9) served as the foundation of network accounting for decades. However, Traditional NetFlow exhibits substantial structural limitations in modern enterprise environments:
- Rigid Key Identification: Traditional NetFlow v5 relies on a hardcoded, immutable 7-tuple. It cannot track non-IP traffic, IPv6 headers, MPLS labels, Layer 2 MAC addresses, VLAN tags, or Next-Generation Network-Based Application Recognition (NBAR2) application signatures.
- Monolithic Architecture: In traditional implementations, flow record definitions, caching rules, and export configurations were tightly coupled. A device could not simultaneously track security anomalies using granular packet headers while running a coarse-grained aggregate flow cache for long-term capacity planning.
- Limited Extensibility: Modifying the operational parameters of traditional NetFlow often required firmware updates or vendor-specific feature sets.
Flexible NetFlow (FNF) Modular Architecture
Flexible NetFlow decomposes traffic monitoring into a decoupled, object-oriented hierarchy. Rather than forcing a single fixed inspection template, FNF allows network engineers to define multiple independent monitors running concurrently on the same interface. One monitor can track IPv6 security telemetry, a second monitor can capture Layer 2 VLAN utilization, and a third monitor can collect WAN Quality of Service statistics.
Furthermore, FNF complies with the industry-standard IP Flow Information Export (IPFIX) protocol defined in RFC 7011, which evolved directly from NetFlow Version 9. FNF supports both Cisco NetFlow v9 and IPFIX export formats, enabling seamless interoperability with multi-vendor monitoring tools.
Flexible NetFlow Component Hierarchy
The FNF architecture consists of three core building blocks—Flow Records, Flow Exporters, and Flow Monitors—with an optional fourth component, the Flow Sampler.
+-------------------------------------------------------------+
| FLOW MONITOR |
| - Manages Flow Cache in Device Memory |
| - Configures Cache Aging Timers (Active / Inactive) |
| |
| +-------------------+ +--------------------+ |
| | FLOW RECORD | | FLOW EXPORTER | |
| | - match keys | | - Destination IP | |
| | - collect fields | | - UDP Port (2055) | |
| +-------------------+ | - Version v9/IPFIX| |
| +--------------------+ |
+-------------------------------------------------------------+
|
v Applied to Interface
[Interface GigabitEthernet0/0/1]
ip flow monitor ENTERPRISE-MONITOR input
1. Flow Record: Defining Key vs. Non-Key Fields
A Flow Record defines the exact data structure of the flow cache entry. It specifies what packet attributes the router evaluates to identify a flow and what operational telemetry the router measures.
The record configuration distinguishes strictly between Key Fields (match) and Non-Key Fields (collect):
- Key Fields (
match): These parameters define the unique identity of a flow. When a packet arrives, the router inspects all configured match fields simultaneously. If the packet's attributes match an existing active flow in the cache, the router aggregates the packet into that existing record. If even one match field differs, the router creates a new flow entry. Match fields can include Layer 2 attributes (source/destination MAC, ethertype, VLAN ID), Layer 3 attributes (source/destination IPv4 or IPv6 address, protocol, DSCP, TTL), Layer 4 attributes (source/destination port, TCP flags), or input/output interfaces. - Non-Key Fields (
collect): These parameters represent operational telemetry and measurements gathered from packets that match an existing flow. Non-key fields do not create new flow cache entries; instead, they provide analytical data about the flow. Collect fields typically include packet counters, byte counters, initial packet timestamps (sys-uptime first), final packet timestamps (sys-uptime last), routing next-hop addresses, egress interfaces, and TCP control flags.
Match vs. Collect Fields Comparison
| Category | CLI Command Syntax Example | Operational Function | Impact on Flow Cache |
|---|---|---|---|
| Key Field (Match) | match ipv4 source address | Identifies flow criteria | Defines uniqueness; variations create separate cache entries |
| Key Field (Match) | match transport destination-port | Identifies target application service | Differentiates distinct destination services |
| Key Field (Match) | match interface input | Records ingress boundary | Segregates traffic entering via distinct physical/logical paths |
| Non-Key Field (Collect) | collect counter packets | Measures cumulative packet count | Updates existing flow counter; never triggers new entry |
| Non-Key Field (Collect) | collect counter bytes | Measures total transferred payload volume | Increments byte metric within active cache entry |
| Non-Key Field (Collect) | collect timestamp sys-uptime first | Records exact flow start time | Captures first observed packet timestamp for flow duration calculation |
| Non-Key Field (Collect) | collect routing next-hop address ipv4 | Captures forwarding decision | Records forwarding next-hop without splitting the flow entry |
2. Flow Exporter: Directing Telemetry Egress
The Flow Exporter specifies the network destination, transport protocol, and transmission formatting rules for offloading expired flow records from the router's local cache to an external collection platform (such as a SIEM, network analyzer, or Cisco DNA Center).
Key exporter configuration attributes include:
- Destination Address: The IPv4 or IPv6 address of the centralized NetFlow collector.
- Transport Protocol and Port: NetFlow telemetry is transmitted primarily via UDP. The de facto industry standard port for NetFlow v9 is UDP port 2055, while the IANA-assigned standard port for IPFIX is UDP port 4739.
- Source Interface: Designates the local interface (typically a resilient Loopback interface) whose IP address appears as the source in exported UDP datagrams.
- Export Protocol Version: Configures whether the router formats records using NetFlow Version 9 or IPFIX (RFC 7011).
- Template Management: Both NetFlow v9 and IPFIX employ dynamic, template-driven architectures. Because FNF user-defined flow records contain variable match and collect combinations, the collector cannot parse binary flow payloads without first receiving the template that maps field IDs to byte offsets. The router must periodically retransmit its active template definitions using the commands:
template data timeout <seconds>: Specifies how frequently (in seconds; many designs set a short value such as 60 so a restarted collector relearns templates quickly) the router resends template definitions.- Retransmission ensures that if a collector restarts or drops a template packet, it quickly re-acquires the structural schema required to decode incoming telemetry.
3. Flow Monitor: Cache Management and Aging Timers
The Flow Monitor acts as the central orchestrator that binds a Flow Record to one or more Flow Exporters. Additionally, the Flow Monitor instantiates and manages the NetFlow cache within device memory.
When packets match the flow record, entries populate the monitor's cache. However, router memory is finite, and centralized collectors require timely data. The Flow Monitor manages cache eviction using Cache Aging Timers:
- Active Timeout (
cache timeout active <seconds>): Governs how long a continuous, uninterrupted flow can reside in the local cache before its accumulated metrics are exported. The default active timeout is 1800 seconds (30 minutes). If a large file transfer or long-running database query runs continuously for hours, waiting until the session finishes would prevent the collector from seeing real-time traffic spikes. When the active timeout expires, the router exports the flow's current metrics to the exporter, resets the byte and packet counters to zero, and keeps the flow entry alive in the cache. - Inactive Timeout (
cache timeout inactive <seconds>): Governs how long an idle flow remains in the cache after traffic ceases. The default inactive timeout is 15 seconds. When a TCP session terminates (e.g., via FIN or RST flags) or a client stops transmitting UDP datagrams, no further packets match the flow entry. Once 15 seconds elapse without matching traffic, the router considers the flow closed, exports the final flow record with its closing timestamps, and purges the entry from cache memory to reclaim RAM.
4. Flow Sampler (Optional Optimization)
On high-speed aggregation and core interfaces (e.g., 40Gbps or 100Gbps links), evaluating every single packet in hardware or software can saturate lookup tables and TCAM. A Flow Sampler defines an M-out-of-N packet sampling algorithm (for example, sampling 1 out of every 1000 packets). The Flow Monitor applies the sampler to reduce CPU overhead and export bandwidth while maintaining statistically accurate traffic profiles.
Flexible NetFlow Configuration and Verification
Deploying FNF follows a strict bottom-up configuration sequence: define the record, define the exporter, create the monitor to bind them, and apply the monitor to target interfaces.
! =======================================================
! Step 1: Configure the Custom Flow Record
! =======================================================
Router(config)# flow record CUSTOM-IPV4-RECORD
Router(config-flow-record)# description Tracks IPv4 conversations with QoS and routing info
Router(config-flow-record)# match ipv4 source address
Router(config-flow-record)# match ipv4 destination address
Router(config-flow-record)# match ipv4 protocol
Router(config-flow-record)# match transport source-port
Router(config-flow-record)# match transport destination-port
Router(config-flow-record)# match ipv4 tos
Router(config-flow-record)# match interface input
Router(config-flow-record)# collect routing next-hop address ipv4
Router(config-flow-record)# collect counter packets
Router(config-flow-record)# collect counter bytes
Router(config-flow-record)# collect timestamp sys-uptime first
Router(config-flow-record)# collect timestamp sys-uptime last
Router(config-flow-record)# collect transport tcp flags
! =======================================================
! Step 2: Configure the Flow Exporter
! =======================================================
Router(config)# flow exporter SEC-COLLECTOR-EXPORTER
Router(config-flow-exporter)# description Export to SIEM Collector
Router(config-flow-exporter)# destination 10.1.100.50
Router(config-flow-exporter)# source Loopback0
Router(config-flow-exporter)# transport udp 2055
Router(config-flow-exporter)# export-protocol netflow-v9
Router(config-flow-exporter)# template data timeout 60
! =======================================================
! Step 3: Configure the Flow Monitor and Cache Timers
! =======================================================
Router(config)# flow monitor ENTERPRISE-FLOW-MONITOR
Router(config-flow-monitor)# record CUSTOM-IPV4-RECORD
Router(config-flow-monitor)# exporter SEC-COLLECTOR-EXPORTER
Router(config-flow-monitor)# cache timeout active 60
Router(config-flow-monitor)# cache timeout inactive 15
! =======================================================
! Step 4: Apply the Flow Monitor to Network Interfaces
! =======================================================
Router(config)# interface GigabitEthernet0/0/1
Router(config-if)# ip flow monitor ENTERPRISE-FLOW-MONITOR input
Router(config-if)# ip flow monitor ENTERPRISE-FLOW-MONITOR output
Verification and Operational Inspection
Engineers verify FNF performance and inspect real-time cache contents using targeted EXEC commands:
show flow record <name>: Displays the operational configuration of match keys and collect metrics.show flow exporter <name>: Shows statistics on exported packets, records transmitted, template refresh intervals, and export errors (such as UDP socket drops).show flow monitor <name> cache: Displays the contents of the live flow cache in router memory, listing active flows, source/destination IPs, ports, byte counters, and protocol identifiers.show flow monitor <name> statistics: Outlines cache utilization, total allocated entries, active flow count, and timer-driven cache purges.
Router# show flow monitor ENTERPRISE-FLOW-MONITOR cache
Cache type: Normal
Cache size: 4096
Current entries: 3
High Watermark: 5
Flows Pardoned: 0
Flows Expired: 142
- Active timeout ( 60 secs): 12
- Inactive timeout ( 15 secs): 130
IPV4 SRC ADDR IPV4 DST ADDR TRNS SRC PORT TRNS DST PORT IP PROT bytes pkts
=============== =============== ============= ============= ======= ===== ====
10.1.10.15 192.168.1.100 51240 443 6 4520 32
10.1.10.22 172.16.5.10 58912 53 17 148 2
192.168.10.5 10.2.20.100 49870 22 6 12480 85
In a Flexible NetFlow flow record, what is the fundamental difference between a match statement and a collect statement?
Match statements define non-key counter fields, whereas collect statements specify the remote destination IP address of the flow collector
Match statements apply access-list packet drops to the flow, whereas collect statements decrypt payload contents for deep packet inspection
Match statements define key fields that make a flow cache entry unique; collect statements gather data without creating new entries
Match statements are restricted to Layer 2 header fields, whereas collect statements can only inspect Layer 4 transport protocols
An enterprise network engineer notices that long-duration, high-throughput file transfers are not reported to the centralized NetFlow collector until 30 minutes after they begin. What Flow Monitor parameter should be adjusted to receive more frequent intermediate telemetry updates?
Decrease the cache timeout active interval
Increase the cache timeout inactive interval
Enable the template data timeout command on the Flow Record
Change the export protocol from NetFlow v9 to IPFIX
Why must a Cisco Flow Exporter configured with NetFlow Version 9 or IPFIX periodically retransmit template records to the centralized flow collector?
The collector requires periodic templates to renew its symmetric AES encryption keys for UDP payload decryption
Templates are used as Layer 2 keepalives; without them, the collector marks the router's physical interface as operationally down
Because UDP is connection-oriented, templates acknowledge receipt of previous flow datagram sequences
Because Flexible NetFlow uses customizable user records, the collector needs the template definition to decode incoming binary flow data fields
Sections you finish are checked off in the contents.