NetFlow – Traffic Monitoring Overview

1. What Is NetFlow and Why Is It Used?

NetFlow is a network protocol developed by Cisco that enables routers and switches to collect and export metadata about IP traffic flows traversing their interfaces. Rather than capturing every byte of every packet (as a packet capture does), NetFlow records a summary of each unique traffic flow — its source, destination, protocol, volume, and timing. This lightweight, scalable approach gives network engineers comprehensive visibility into who is talking to whom, what protocols are in use, and how much bandwidth each conversation is consuming — without the massive storage overhead of full packet capture.

Originally developed for Cisco IOS routers in the 1990s, NetFlow has become the industry-standard model for flow-based traffic analysis. Its concepts have been standardised as IPFIX (IP Flow Information Export) by the IETF, and vendor-neutral implementations (sFlow, jFlow, NetStream) follow the same fundamental approach.

Monitoring Method	What It Captures	Storage Requirement	Best Use Case
Full Packet Capture (PCAP)	Every byte of every packet — complete Layer 2 to Layer 7 content	Enormous — gigabytes per minute on busy links	Forensic incident response; deep protocol troubleshooting; IDS/IPS signature development
NetFlow / IPFIX	Flow metadata — src/dst IP, ports, protocol, byte count, packet count, timestamps, ToS/DSCP, interface	Very small — typically 1–2% the size of the traffic volume	Bandwidth monitoring, capacity planning, anomaly detection, security analytics, billing, compliance
SNMP (polling)	Interface counters — total bytes/packets in/out per interface, no per-flow detail	Minimal	Utilisation graphs; threshold alerting; device health
Syslog	Event-based log messages — interface events, ACL hits, routing changes	Low to moderate	Event correlation; audit trails; security event logging

2. What Is a Flow?

A flow is a sequence of packets that share the same set of characteristics — called the flow key. Every packet that matches all seven fields of the flow key is counted as part of the same flow. NetFlow collects statistics for each unique flow in a data structure called the flow cache.

2.1 The Seven-Tuple Flow Key

NetFlow v5 (and most NetFlow implementations) identifies a unique flow using these seven fields. Every packet that shares the same seven values belongs to the same flow:

#	Flow Key Field	Example Value	Notes
1	Source IP Address	192.168.1.10	Layer 3 source — the originating host
2	Destination IP Address	10.0.0.5	Layer 3 destination — the receiving host
3	Source Port	54321	Layer 4 source port (TCP/UDP); 0 for ICMP
4	Destination Port	443	Layer 4 destination port — identifies the service (HTTPS = 443, HTTP = 80, DNS = 53, etc.)
5	IP Protocol	6 (TCP)	IP protocol number: 6 = TCP, 17 = UDP, 1 = ICMP, 47 = GRE, 50 = ESP
6	ToS (Type of Service) / DSCP	0xB8 (DSCP EF)	IP header ToS byte — used to separate flows with different QoS markings; relevant for QoS verification
7	Input Interface (ifIndex)	GigabitEthernet0/1	The router interface on which the flow arrived — allows per-interface traffic accounting

2.2 Flow Record Contents

Beyond the flow key, each flow record contains statistics about the traffic observed for that flow:

Flow Record Field	Description
Packet count	Total number of packets in the flow
Byte count	Total number of bytes transferred in the flow — key metric for bandwidth accounting and billing
Flow start timestamp	System uptime or wall-clock time when the first packet of the flow was seen
Flow end timestamp	Time the last packet was seen — used to calculate flow duration
Output interface	The egress interface the flow was forwarded to
Next-hop IP address	IP address of the next-hop router for this flow
Source AS / Destination AS	BGP Autonomous System number for the source and destination (if BGP is running) — useful for ISP traffic analytics
TCP flags	Union of all TCP flags observed across the flow's packets (SYN, ACK, FIN, RST, etc.) — useful for detecting port scans and half-open connection attacks

3. Flow vs Packet Inspection

Understanding the distinction between flow-based monitoring and packet-based inspection is essential for choosing the right tool and for understanding NetFlow's place in the monitoring toolbox.

Dimension	NetFlow (Flow-Based)	Packet Capture (Packet-Based)
Granularity	Per-flow summary — one record per conversation; not per packet	Per-packet — every single packet captured with full headers and payload
Payload visibility	None — NetFlow captures only metadata, never payload content	Full — complete Layer 2 through Layer 7 content visible in Wireshark or tcpdump
Impact on router CPU	Low — flow cache lookup is fast; most routers handle it in hardware	High if captured on the device itself; typically done on a dedicated capture point (SPAN port)
Storage requirement	Very low — 1–2% of actual traffic volume	Matches actual traffic volume — 1 Gbps link = ~450 GB/hour of capture data
Long-term retention	Practical — flow records for months or years	Impractical at line rate — typically only short rolling windows are stored
Privacy	Flow metadata only — no user data content exposed	Captures passwords, session content, and all user data in cleartext protocols
Security incident use	Who talked to whom, when, how much — ideal for anomaly detection and forensic timeline reconstruction	What they said — full packet replay; required for malware signature extraction
Encrypted traffic	Still records flow metadata — src/dst, volume, timing are visible even for TLS/IPsec traffic	Can capture but cannot read encrypted payload without the decryption key

4. NetFlow Architecture – Exporter, Collector, Analyser

A complete NetFlow deployment has three components. Understanding how they work together is essential for both CCNA exam and real-world deployment.

Component	Role	Location	Example Devices / Tools
Flow Exporter	The network device (router, switch, or firewall) that monitors traffic on its interfaces, builds flow records in its flow cache, and exports them to the collector at regular intervals or when the flow expires	Network infrastructure	Cisco ISR, ASR, Catalyst switches, Nexus; any device with IOS NetFlow or Flexible NetFlow support
Flow Collector	A server that receives and stores flow records exported by one or more devices. The collector normalises and indexes records for efficient querying.	Central server or cloud service	Cisco Prime Infrastructure; ntopng; PRTG; Elastic SIEM; SolarWinds NTA; open-source: nfcapd/nfdump
Flow Analyser	Software that queries the collector database and presents traffic data as dashboards, reports, and alerts — top talkers, top protocols, bandwidth trends, anomalies	Management workstation or web UI	Often bundled with the collector; separate tools include Grafana, Kibana, Cisco Stealthwatch

4.1 Flow Export Transport

Flow records are exported from the router to the collector using UDP (unreliable, but low overhead). The standard port is:

NetFlow Version	Default Export Port	Transport
NetFlow v5	UDP 2055 (commonly used; configurable)	UDP — no acknowledgement; records may be lost during congestion
NetFlow v9	UDP 2055 (commonly used; configurable)	UDP
IPFIX	UDP 4739 (IANA standard); TCP 4739 also supported	UDP or TCP (TCP provides reliability for IPFIX)

5. NetFlow Cache – How Flow Records Are Created and Expired

The flow cache is a memory table on the exporting device that stores active flow entries. When a packet arrives, the router looks up its seven-tuple key in the cache — if a matching entry exists, the packet count and byte count are updated. If no match is found, a new flow entry is created. Entries are exported to the collector and removed from the cache when the flow expires.

5.1 Flow Expiry Conditions

Expiry Reason	Default Timer	Description
Active flow timeout	30 minutes (1800 seconds)	Long-lived flows (e.g., a sustained file transfer or streaming session) are exported at this interval even if the flow is still active — prevents stale cache entries
Inactive flow timeout	15 seconds	A flow that has seen no new packets for this duration is assumed to have ended — the entry is exported and removed
TCP FIN or RST	Immediate (on flag detection)	TCP flows are expired immediately when a FIN or RST is seen — the flow has cleanly terminated
Cache full	When cache reaches capacity	Oldest or least recently used entries are evicted and exported to make room for new flows

5.2 Export Timing Implications

Because flows are exported on expiry — not in real time — there is an inherent delay between when traffic occurs and when the flow record appears in the collector. For a long-lived flow, the final record may not arrive at the collector until up to 30 minutes after the flow started (active timeout). For security use cases requiring near-real-time visibility, the active timeout can be reduced (e.g., to 60 seconds).

6. NetFlow Versions

NetFlow has evolved through several versions. The three versions relevant to CCNA and enterprise networks are v5, v9, and IPFIX.

Feature	NetFlow v5	NetFlow v9	IPFIX (v10)
Year introduced	~1996	2004	2008 (RFC 5101/7011)
Record format	Fixed — always the same 7-tuple + statistics fields; no flexibility	Template-based — exporter sends a template describing field layout before sending data; collector adapts accordingly	Template-based (same concept as v9 but standardised by IETF)
IPv6 support	✘ No — IPv4 only	✔ Yes — IPv6 fields added via templates	✔ Yes
MPLS support	✘ No	✔ Yes	✔ Yes
Variable-length fields	✘ No	✘ No	✔ Yes — supports variable-length information elements (e.g., application name strings)
Transport	UDP only	UDP only	UDP or TCP (reliable export option)
Vendor-specific extensions	✘ No — fixed format	✔ Yes — enterprise-specific fields via custom templates	✔ Yes — standardised enterprise private information elements
Standardisation	Cisco proprietary	Cisco proprietary (RFC 3954 informational)	IETF standard (RFC 7011) — vendor-neutral
Current status	Widely supported; still common; being superseded	Widely deployed in enterprise; foundation for IPFIX	The modern standard — recommended for new deployments

6.1 NetFlow v5 Fixed Record Format

NetFlow v5 exports fixed-size 48-byte records. Each UDP datagram can carry up to 30 flow records. The fixed fields are:

Field	Size	Description
Source IP address	4 bytes	IPv4 source address
Destination IP address	4 bytes	IPv4 destination address
Next-hop IP address	4 bytes	IP address of next-hop router
Input interface (ifIndex)	2 bytes	SNMP index of the ingress interface
Output interface (ifIndex)	2 bytes	SNMP index of the egress interface
Packet count	4 bytes	Total packets in the flow
Byte count	4 bytes	Total bytes in the flow (L3 header + payload)
Flow start SysUptime	4 bytes	System uptime (ms) at flow start
Flow end SysUptime	4 bytes	System uptime (ms) at flow end
Source port	2 bytes	TCP/UDP source port
Destination port	2 bytes	TCP/UDP destination port
TCP flags	1 byte	Cumulative OR of TCP flags
IP protocol	1 byte	IP protocol number (6=TCP, 17=UDP, 1=ICMP)
ToS byte	1 byte	IP Type of Service / DSCP value
Source AS	2 bytes	BGP AS of source (0 if BGP not running)
Destination AS	2 bytes	BGP AS of destination
Source prefix mask	1 byte	Prefix length of source address in routing table
Destination prefix mask	1 byte	Prefix length of destination address in routing table

7. Flexible NetFlow (FNF)

Flexible NetFlow (FNF) is Cisco's implementation of the template-based approach introduced in NetFlow v9 and formalised in IPFIX. FNF gives the network administrator full control over which fields constitute the flow key and which fields are collected as non-key fields — allowing customised flow records tailored to specific monitoring requirements.

FNF Concept	Description	Cisco IOS Object
Flow Record	Defines the flow key (match fields) and collected statistics (collect fields) — the blueprint for what each flow entry contains	`flow record <name>`
Flow Exporter	Defines where to send flow data — collector IP, UDP port, and NetFlow version/template	`flow exporter <name>`
Flow Monitor	Combines a Flow Record and Flow Exporter into an active monitoring policy; also configures the cache size and timeout values	`flow monitor <name>`
Interface application	Applies the Flow Monitor to a specific interface in the ingress and/or egress direction	`ip flow monitor <name> input/output` on the interface

8. NetFlow Configuration on Cisco IOS

The following examples show both traditional NetFlow v5/v9 (legacy command) and Flexible NetFlow configuration. For the full step-by-step lab, see NetFlow Configuration Lab.

8.1 Traditional NetFlow v5 Configuration (Legacy)

! Enable NetFlow export on the router
Router(config)# ip flow-export version 5
Router(config)# ip flow-export destination 192.168.100.10 2055   ! Collector IP and port
Router(config)# ip flow-export source GigabitEthernet0/0         ! Source interface for export
Router(config)# ip flow-cache timeout active 30                  ! Active flow timeout (min)
Router(config)# ip flow-cache timeout inactive 15                ! Inactive flow timeout (sec)

! Apply NetFlow to interfaces (ingress monitoring)
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip flow ingress                              ! Monitor inbound traffic
Router(config-if)# exit

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip flow ingress
Router(config-if)# exit

8.2 Flexible NetFlow Configuration (Modern)

! Step 1: Define the Flow Record (what to collect)
Router(config)# flow record MY-RECORD
Router(config-flow-record)# match ipv4 source address
Router(config-flow-record)# match ipv4 destination address
Router(config-flow-record)# match transport source-port
Router(config-flow-record)# match transport destination-port
Router(config-flow-record)# match ipv4 protocol
Router(config-flow-record)# match ipv4 tos
Router(config-flow-record)# match interface input
Router(config-flow-record)# collect counter bytes
Router(config-flow-record)# collect counter packets
Router(config-flow-record)# collect timestamp sys-uptime first
Router(config-flow-record)# collect timestamp sys-uptime last
Router(config-flow-record)# exit

! Step 2: Define the Flow Exporter (where to send data)
Router(config)# flow exporter MY-EXPORTER
Router(config-flow-exporter)# destination 192.168.100.10         ! Collector IP
Router(config-flow-exporter)# transport udp 2055                 ! Collector port
Router(config-flow-exporter)# export-protocol netflow-v9         ! or ipfix
Router(config-flow-exporter)# exit

! Step 3: Define the Flow Monitor (tie record + exporter together)
Router(config)# flow monitor MY-MONITOR
Router(config-flow-monitor)# record MY-RECORD
Router(config-flow-monitor)# exporter MY-EXPORTER
Router(config-flow-monitor)# cache timeout active 60
Router(config-flow-monitor)# cache timeout inactive 15
Router(config-flow-monitor)# exit

! Step 4: Apply Flow Monitor to interface(s)
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip flow monitor MY-MONITOR input
Router(config-if)# ip flow monitor MY-MONITOR output
Router(config-if)# exit

9. NetFlow Use Cases

NetFlow data is powerful precisely because it is lightweight, persistent, and available from every router and switch in the network. The following are the primary use cases encountered in enterprise and service provider environments:

Use Case	How NetFlow Helps	Example Query
Bandwidth monitoring & capacity planning	Identifies which hosts, applications, and protocols are consuming the most bandwidth — top-N talkers and top-N applications by byte count	"Which 10 hosts generated the most traffic in the last 24 hours?" / "What is the bandwidth consumed by HTTPS vs FTP?"
Network baseline establishment	Establishes normal traffic patterns — typical bandwidth by hour, typical protocol mix, typical source/destination pairs	"What does normal Monday morning traffic look like on this WAN link?"
Security anomaly detection	Identifies abnormal patterns — sudden traffic spikes, unexpected protocols, connections to known malicious IPs, port scanning (TCP SYN without ACK), data exfiltration (large outbound transfers to unusual destinations)	"Which hosts have established connections to IP ranges in unusual countries?" / "Is any host sending data to port 6667 (IRC/botnet C2)?"
DDoS detection	Detects volumetric attacks — sudden spike in byte or packet count from many sources to one destination (inbound DDoS) or from one source to many destinations (scanning)	"Is any single destination receiving traffic from more than 1000 unique source IPs per minute?"
QoS verification	Verifies that DSCP/ToS markings are being applied correctly — confirms VoIP traffic is marked EF (DSCP 46) across all hops	"What ToS values are on UDP flows to/from the VoIP server?"
Billing and chargeback	Tracks traffic volume per source AS, destination AS, or per-customer IP range — ISPs use this for peering analytics and customer billing	"How many GB did customer subnet 10.5.0.0/24 consume this month?"
Application performance monitoring	Identifies latency and throughput issues per application — flow duration combined with byte count indicates throughput; TCP flags reveal connection problems (RSTs, retransmits)	"Are TCP RST flags appearing on flows to the ERP server?"
Compliance and forensics	Provides an audit trail of all network communications — "who connected to which server at what time and transferred how much data" — useful for regulatory compliance (PCI-DSS, HIPAA) and post-incident forensics	"Show all connections from the compromised workstation (10.1.1.50) in the 48 hours before the incident was detected"

10. NetFlow Verification Commands

Command	Output / Purpose
`show ip flow interface`	Lists all interfaces with NetFlow enabled and the direction (ingress/egress) on each — confirms NetFlow is applied where intended
`show ip cache flow`	Displays the active NetFlow v5 flow cache — shows current flow entries with src/dst IPs, ports, protocol, byte/packet counts; critical for verifying NetFlow is capturing traffic
`show ip cache verbose flow`	More detailed version of the cache display — includes ToS, TCP flags, and timestamps
`show ip flow export`	NetFlow export statistics — collector IP and port, number of flows exported, export packets sent, and any export failures; confirms records are being sent to the collector
`show flow monitor <name> cache`	Flexible NetFlow — displays the flow cache for a specific FNF monitor; shows all active flow entries with all configured fields
`show flow monitor <name> statistics`	FNF monitor statistics — cache utilisation, flows created, flows aged, and export counts
`show flow exporter <name> statistics`	FNF exporter statistics — packets sent to collector, failed exports, and connection state to the collector
`show flow record <name>`	Displays the configured FNF flow record — match (key) and collect (non-key) fields defined
`show ip flow top-talkers`	Legacy command — shows top N flows by byte count; useful for quick bandwidth analysis without a collector
`debug ip flow export`	Real-time debug of flow export messages sent to the collector — useful for verifying UDP packets are reaching the collector; use with caution in production

11. NetFlow vs IPFIX vs sFlow

Several flow-based monitoring technologies exist. The following comparison helps clarify when each is used and how they relate:

Feature	NetFlow v5/v9	IPFIX	sFlow
Origin	Cisco proprietary	IETF standard (RFC 7011) — based on NetFlow v9	Open standard (RFC 3176) — originated from InMon/HP
Method	Flow-based — every packet of a flow is counted	Flow-based — every packet counted	Sampling-based — every Nth packet is sampled; extrapolated to estimate full traffic
Accuracy	100% — all packets counted within each flow	100%	Approximate — sampling ratio affects accuracy (1:100 = 1% of packets examined)
CPU/memory impact	Low to moderate — flow cache maintained per interface	Low to moderate	Very low — only sampled packets processed; no flow cache
Vendor support	Primarily Cisco; many vendors support v5/v9 format	All major vendors — the future standard	Broad support including Arista, Juniper, HP, Brocade; scales well to high-speed (100G+) interfaces
Best for	Cisco-centric environments; legacy deployments	New deployments; multi-vendor environments; IPv6	High-speed links where flow-based monitoring consumes too much CPU; data centre switching

12. NetFlow Quick-Reference Summary

NetFlow Concept	Key Fact
What NetFlow captures	Flow metadata — src/dst IP, src/dst port, protocol, ToS, input interface, byte count, packet count, timestamps
What NetFlow does NOT capture	Packet payload / application content — metadata only
Seven-tuple flow key	Src IP, Dst IP, Src Port, Dst Port, Protocol, ToS, Input Interface
Default active timeout	30 minutes (flows exported even if still active)
Default inactive timeout	15 seconds (flows expired after idle)
Export transport	UDP (default port 2055 for v5/v9; 4739 for IPFIX)
NetFlow v5	Fixed format; IPv4 only; 48-byte records; most widely supported
NetFlow v9	Template-based; IPv6 support; extensible; Cisco proprietary
IPFIX	IETF standard (RFC 7011); template-based; variable-length fields; UDP or TCP transport
Flexible NetFlow objects	flow record → flow exporter → flow monitor → interface (service-policy equivalent)
FNF interface command	`ip flow monitor <name> input/output`
View active flows (legacy)	`show ip cache flow`
View FNF cache	`show flow monitor <name> cache`
Verify export statistics	`show ip flow export`
Storage overhead	~1–2% of actual traffic volume

Test Your Knowledge – NetFlow Quiz

1. What is a NetFlow "flow," and what seven fields define a unique flow in NetFlow v5?

A. A flow is any single IP packet; flows are identified by source IP and destination IP only B. A flow is a sequence of packets sharing the same seven-tuple: source IP, destination IP, source port, destination port, IP protocol, ToS byte, and input interface C. A flow is a TCP session only; UDP traffic is not tracked by NetFlow D. A flow is identified by VLAN ID and MAC addresses at Layer 2

Correct answer is B. A flow is all packets that share the same seven-tuple key: (1) source IP, (2) destination IP, (3) source port, (4) destination port, (5) IP protocol, (6) ToS byte, (7) input interface. Every packet matching all seven values is counted as part of the same flow. NetFlow tracks all IP traffic — TCP, UDP, ICMP, GRE, ESP, and any other IP protocol. For ICMP, ports are 0.

2. What is the fundamental difference between NetFlow and a full packet capture (PCAP)?

A. NetFlow captures Layers 1–4 only; PCAP captures Layers 5–7 B. NetFlow is more accurate than PCAP because it samples every 100th packet C. NetFlow captures flow metadata only (src/dst, ports, byte counts) — no payload. PCAP captures every byte of every packet including full application content, requiring far more storage. D. PCAP is a Cisco standard; NetFlow is the IETF standard for packet capture

Correct answer is C. NetFlow collects only flow metadata — never the packet payload. This means NetFlow records who communicated with whom, when, what protocol, and how much data, but not what was said. A full packet capture (PCAP, e.g., Wireshark) captures every byte including application data. NetFlow storage is ~1–2% of traffic volume; PCAP at 1 Gbps requires ~450 GB/hour. This trade-off makes NetFlow ideal for long-term trending and forensics, while PCAP is needed for deep protocol analysis or malware investigation.

3. In the NetFlow architecture, what is the role of the flow collector?

A. It is the network device (router) that monitors traffic and builds flow records B. It applies ACLs to filter which flows are recorded C. It generates reports and dashboards for the network administrator D. It receives and stores flow records exported by network devices (exporters), indexing them for querying by the analyser

Correct answer is D. The three NetFlow components are: the Flow Exporter (the router/switch that monitors traffic and sends flow records); the Flow Collector (a server that receives, stores, and indexes flow records via UDP); and the Flow Analyser (software that queries the collector and presents dashboards, top-talker reports, and alerts). The collector is the central repository — exporters send to it, analysers read from it.

4. What is the default active flow timeout in NetFlow, and why does it exist?

A. 30 minutes — long-lived flows are exported at this interval even if still active, preventing the flow cache from becoming stale and ensuring the collector receives periodic updates B. 15 seconds — all flows are considered inactive after this time C. 60 minutes — flows older than 1 hour are automatically discarded D. 5 minutes — the default matches TCP connection timeout

Correct answer is A. The active timeout (default 30 minutes) ensures that long-lived flows — such as a sustained file transfer or a persistent TCP connection — are periodically exported to the collector rather than sitting in the flow cache indefinitely. Without it, the collector would not receive data about ongoing flows until they end. The inactive timeout (default 15 seconds) handles flows that have gone silent — if no packets are seen for 15 seconds, the flow is assumed to have ended and is exported and removed.

5. What is the key improvement that NetFlow v9 introduced over NetFlow v5?

A. NetFlow v9 uses TCP instead of UDP for reliable export delivery B. NetFlow v9 uses a template-based format rather than a fixed record structure, allowing IPv6, MPLS, and custom fields to be added without changing the protocol C. NetFlow v9 records entire packet payloads in addition to flow metadata D. NetFlow v9 reduced the flow record size from 48 bytes to 12 bytes for efficiency

Correct answer is B. NetFlow v5 has a fixed 48-byte record format that supports only IPv4 and a predetermined set of fields. NetFlow v9 introduced a template-based format — the exporter first sends a template record that describes the layout and fields of subsequent data records. This allows v9 to support IPv6, MPLS labels, BGP next-hop, and vendor-specific custom fields without requiring changes to the protocol itself. IPFIX (v10) standardised this same template approach through the IETF.

6. In Flexible NetFlow, what is the correct order of the three configuration objects that must be created before applying NetFlow to an interface?

A. Flow Monitor → Flow Exporter → Flow Record B. Flow Exporter → Flow Monitor → Flow Record C. Flow Record → Flow Exporter → Flow Monitor (then apply to interface with ip flow monitor <name> input) D. Flow Record → Flow Monitor → Flow Exporter

Correct answer is C. The Flexible NetFlow configuration hierarchy is: (1) Flow Record — defines what fields to match (key fields) and collect (non-key fields); (2) Flow Exporter — defines the collector IP, UDP port, and export protocol version; (3) Flow Monitor — ties together the record and exporter, and sets cache timeout values. The flow monitor is then applied to a specific interface using ip flow monitor <name> input (or output) in interface configuration mode.

7. A security analyst notices a sudden spike in NetFlow data showing thousands of flows from a single internal host to hundreds of different destination IPs on port 445 (SMB). What does this pattern most likely indicate?

A. Normal Windows file-sharing traffic — port 445 is used for everyday SMB connections B. A misconfigured DHCP server sending broadcasts to many hosts C. A software update server pushing patches to all endpoints D. A potential worm or ransomware spreading via SMB — a single host scanning/connecting to hundreds of destinations on port 445 is a classic lateral movement or worm propagation pattern (e.g., WannaCry/NotPetya)

Correct answer is D. One of NetFlow's most valuable security use cases is detecting lateral movement and malware propagation. A single internal host establishing hundreds of connections to different destination IPs on port 445 (SMB) is a textbook indicator of a worm scanning for vulnerable SMB hosts, or ransomware spreading laterally through the network. Normal SMB traffic connects to a small, known set of file servers — not to hundreds of arbitrary IPs. NetFlow detected this pattern because it sees all flows, even encrypted or internal east-west traffic that a perimeter firewall would never inspect.

8. What Cisco IOS command displays the current active NetFlow flow cache on a router using traditional (non-FNF) NetFlow?

A. show ip cache flow B. show ip flow statistics C. show netflow cache D. show ip flow monitor cache

Correct answer is A.

show ip cache
                  flow

is the primary verification command for traditional (legacy) NetFlow v5/v9 on Cisco IOS. It displays all active flow entries in the flow cache — src/dst IPs, ports, protocol, byte/packet counts — allowing you to confirm that NetFlow is capturing traffic. For Flexible NetFlow, the equivalent is show flow monitor <name> cache. show ip flow export shows export statistics (whether records are being sent to the collector).

9. What is IPFIX, and how does it relate to NetFlow?

A. IPFIX is a Cisco proprietary version of NetFlow with a fixed 128-byte record format for IPv6 B. IPFIX is a packet sampling technology that only examines 1% of all packets, reducing CPU overhead C. IPFIX (IP Flow Information Export, RFC 7011) is the IETF standardisation of NetFlow v9's template-based approach — the vendor-neutral, interoperable successor to Cisco NetFlow D. IPFIX is a Juniper-proprietary flow monitoring protocol not compatible with Cisco devices

Correct answer is C. IPFIX (IP Flow Information Export) is the IETF standard (RFC 7011) that formalises the template-based approach pioneered in Cisco's NetFlow v9. IPFIX is vendor-neutral — all major network vendors (Cisco, Juniper, Arista, Nokia, Palo Alto) support it. It adds improvements over v9: variable-length fields, TCP transport option for reliable delivery, and a formal IANA information element registry. IPFIX is the recommended standard for new deployments; it is fully backward compatible with v9 collectors.

10. A network engineer configures NetFlow on a router's WAN interface but the flow collector shows no data. `show ip flow interface` confirms NetFlow is enabled on the interface. `show ip cache flow` shows active flows. What is the most likely cause of the collector not receiving data?

A. The NetFlow version is set to v9 but the interface only supports v5 B. The flow export configuration is incorrect or the collector is unreachable — check show ip flow export for the collector IP/port, verify UDP 2055 is not blocked by an ACL or firewall, and confirm the collector is listening C. The flow cache is full and no new flows can be exported D. NetFlow requires a dedicated physical interface to send export packets — it cannot use the same interface being monitored

Correct answer is B. The symptom — flows in the cache but nothing at the collector — means the export process itself is failing. The flow cache is populated (collection is working) but export is not reaching the collector. Systematic troubleshooting: (1) Run show ip flow export — check the configured collector IP and port match what the collector expects; (2) Verify the export packet count is incrementing; if it is not, the router is not sending; (3) Check for ACLs or firewalls blocking UDP 2055 between the router and collector; (4) Confirm the collector service is running and listening on UDP 2055; (5) Ensure the source interface for export is reachable from the collector side.

← Back to Home