NetFlow & IPFIX – Flow Monitoring and Traffic Analysis

1. What Is NetFlow?

NetFlow is a Cisco-developed protocol that collects and exports metadata about IP traffic flows as packets pass through a router or switch interface. Unlike packet capture (which records the full content of every packet), NetFlow records only the characteristics of each conversation — who talked to whom, using which protocol, for how long, and how much data was exchanged. This makes NetFlow extremely efficient: it provides powerful visibility with low overhead.

  NetFlow architecture:

  ┌──────────────────────────────────────────────────────────────────┐
  │  ROUTER / SWITCH (Exporter)                                      │
  │                                                                  │
  │  Packets arrive → Flow cache records 5-tuple + stats             │
  │  Cache entry expires → Flow record exported to Collector         │
  └──────────────────────┬───────────────────────────────────────────┘
                         │ UDP (port 2055 typical)
                         ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  COLLECTOR (e.g., SolarWinds, ntopng, Elasticsearch)             │
  │  Receives, stores, and indexes flow records                      │
  └──────────────────────┬───────────────────────────────────────────┘
                         │
                         ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  ANALYZER / DASHBOARD                                            │
  │  Top talkers, protocol breakdown, anomaly alerts, SIEM feed      │
  └──────────────────────────────────────────────────────────────────┘

2. What Is a Flow? The 5-Tuple and 7-Tuple

A flow is defined as a unidirectional sequence of IP packets that share the same set of identifying attributes. All packets that belong to the same flow are counted together — accumulating byte counts, packet counts, and timestamps until the flow expires.

5-Tuple (Basic Flow Key)

Field	Example Value	Why It Matters
Source IP Address	`192.168.1.10`	Who initiated the traffic
Destination IP Address	`8.8.8.8`	Where the traffic is going
Source Port	`52000`	Ephemeral port assigned by OS
Destination Port	`53`	Identifies the application/service (DNS=53, HTTP=80, HTTPS=443)
Layer 4 Protocol	`UDP (17)`	TCP vs UDP vs ICMP

Example flow: 192.168.1.10:52000 → 8.8.8.8:53 UDP
This represents a single DNS query from a workstation to Google's DNS server. The flow record will accumulate: 1 packet, ~64 bytes, start time, end time.

7-Tuple (Extended Flow Key)

The full NetFlow key adds two more fields to disambiguate flows arriving on different interfaces:

Additional Field	Purpose
Type of Service (ToS / DSCP)	Distinguishes flows with different QoS markings — a voice call on DSCP EF vs bulk data on DSCP CS0, even between the same IP pair
Input Interface (ifIndex)	Differentiates flows arriving from different physical interfaces, e.g., two ISP uplinks with different ToS values

Flow Directionality

Flows are always unidirectional. A TCP connection between PC and server produces two separate flow records — one for each direction:

  TCP session:
  PC (192.168.1.10:54321) ─── TCP ──▶ Server (10.0.0.5:443)  →  Flow Record A
  Server (10.0.0.5:443) ──── TCP ──▶ PC (192.168.1.10:54321) →  Flow Record B

  Both records needed to account for full session bandwidth (upload + download)

3. NetFlow Versions

Version	Year	Key Features	Limitation	Status
v1	1996	First implementation; fixed fields; IPv4 only	No BGP AS info; very limited fields	Obsolete — never use in new deployments
v5	1999	Fixed 7-tuple fields; includes BGP AS numbers, interface indexes, ToS, TCP flags; widely supported by all collectors	IPv4 only; no IPv6; no MPLS; no variable fields	Most common — still widely deployed; simple and compatible
v9	2003	Template-based — flexible field set defined per export; supports IPv6, MPLS, BGP next-hop, VLAN tags, multicast	Slightly more complex to configure; collector must support templates	Current standard — use for IPv6, MPLS, or custom field requirements
IPFIX	2013	IETF standardisation of NetFlow v9 (RFC 7011); vendor-neutral; supports variable-length fields; enterprise number for private elements	Requires IPFIX-capable collector	Recommended for multi-vendor environments; open standard

NetFlow v5 Record Fields

  NetFlow v5 record (fixed 48-byte format):
  ┌────────────────┬──────────────────────────────────────────────┐
  │ Field          │ Description                                  │
  ├────────────────┼──────────────────────────────────────────────┤
  │ srcaddr        │ Source IPv4 address                          │
  │ dstaddr        │ Destination IPv4 address                     │
  │ nexthop        │ IP address of next-hop router                │
  │ input          │ SNMP ifIndex of input interface              │
  │ output         │ SNMP ifIndex of output interface             │
  │ dPkts          │ Packet count in flow                         │
  │ dOctets        │ Total bytes in flow                          │
  │ First          │ SysUpTime of first packet (ms)               │
  │ Last           │ SysUpTime of last packet (ms)                │
  │ srcport        │ Source port number                           │
  │ dstport        │ Destination port number                      │
  │ tcp_flags      │ OR of TCP flags seen in flow                 │
  │ prot           │ IP protocol (6=TCP, 17=UDP, 1=ICMP)          │
  │ tos            │ IP Type of Service (ToS) byte                │
  │ src_as         │ BGP autonomous system of source              │
  │ dst_as         │ BGP autonomous system of destination         │
  │ src_mask       │ Prefix length of source subnet               │
  │ dst_mask       │ Prefix length of destination subnet          │
  └────────────────┴──────────────────────────────────────────────┘

4. Flow Cache: Active and Inactive Timers

The router maintains an in-memory flow cache — a table of all currently active flows. Each entry accumulates statistics for matching packets. Flows are exported to the collector when they expire, triggered by one of three conditions:

Expiry Condition	Default Timer	Configurable?	When It Fires
Active timer	30 minutes	Yes — `ip flow-cache timeout active 1`	Long-lived flows (e.g., file transfers) — periodically exports mid-flow records so the collector gets incremental updates rather than waiting for the flow to finish
Inactive timer	15 seconds	Yes — `ip flow-cache timeout inactive 15`	Idle flows — if no new packets match a flow entry for 15 seconds, the flow is exported and removed from the cache
Cache full	N/A	Increase cache size	If the flow cache reaches capacity, the oldest flows are forcibly exported to make room for new ones
TCP FIN/RST	N/A	N/A	A TCP session teardown (FIN or RST flag) signals the end of a TCP flow — the entry is exported shortly after the teardown is detected

Timer tuning: Reduce the active timer (e.g., to 1–5 minutes) for near-real-time visibility of bandwidth hogs. Reduce the inactive timer (e.g., to 5 seconds) for faster detection of short-lived scan attempts. Lower values increase export frequency and collector load — balance based on your monitoring requirements and collector capacity.

5. Traditional NetFlow Configuration (Cisco IOS)

The traditional NetFlow configuration (available on IOS 12.x and later) uses interface-level commands to enable flow monitoring and global commands to define the collector destination.

Complete Configuration Example

! ── Step 1: Enable NetFlow on interfaces ─────────────────────────────────
interface GigabitEthernet0/0
description WAN-Uplink-ISP1
ip flow ingress ! Monitor inbound traffic
ip flow egress ! Monitor outbound traffic

interface GigabitEthernet0/1
description LAN-Core-Switch
ip flow ingress
ip flow egress

! ── Step 2: Configure flow export destination ─────────────────────────────
! Send flows to collector at 192.168.100.10, UDP port 2055
ip flow-export destination 192.168.100.10 2055

! Specify NetFlow version (v5 for broad compatibility, v9 for IPv6/MPLS)
ip flow-export version 5

! Source flows from a loopback for consistent identification
ip flow-export source Loopback0

! ── Step 3: Optional — tune cache timers ─────────────────────────────────
! Active timer: export active flows every 1 minute (default 30 min)
ip flow-cache timeout active 1

! Inactive timer: export idle flows after 15 seconds (default 15 sec)
ip flow-cache timeout inactive 15

! ── Step 4: Optional — enable flow aggregation ────────────────────────────
! Aggregate similar flows before export to reduce collector load
ip flow aggregation cache destination-prefix
enabled
ip flow aggregation cache source-prefix
enabled

! ── Step 5: Verify ────────────────────────────────────────────────────────
! Check export configuration
Router# show ip flow export

! View active flows in cache
Router# show ip cache flow

! View verbose flow output
Router# show ip cache verbose flow

show ip cache flow — Reading the Output

Router# show ip cache flow

IP packet size distribution (1M total packets):
  64  128  256  512  1024  1500
  .45 .25  .15  .08  .04   .03

IP Flow Switching Cache, 278544 bytes
  3457 active, 61079 inactive, 4982 added
  Highest flow count: 5892

Protocol   Total   Flows  Packets  Bytes  Packets Active(Sec) Idle(Sec)
--------   -----   -----  -------  -----  ------- ----------- ---------
TCP-WWW    14523   3812   789443   1.2G   207     .9          2.5
TCP-Telnet 12      3      23       2K     7       4.1         15.1
UDP-DNS    23891   8210   89123    5.6M   10      .1          .5
ICMP       2134    543    9023     0.7M   16      .2          .5

SrcIf    SrcIPaddr    DstIf    DstIPaddr    Pr SrcP DstP  Pkts
Gi0/0    10.1.1.1     Gi0/1    192.168.1.5  06 C0DB 0050  1234   ← TCP src=49371 dst=80 (HTTP)
Gi0/0    10.1.1.2     Gi0/1    8.8.8.8      11 D8A1 0035  89     ← UDP src=55457 dst=53 (DNS)

Key:
Pr = Protocol (06=TCP, 11=UDP, 01=ICMP)
SrcP/DstP = Source/Destination port in HEX (0050 hex = 80 decimal = HTTP)
C0DB hex = 49371 decimal (ephemeral port)

6. Flexible NetFlow (FNF) — Modern Cisco IOS Configuration

Flexible NetFlow (FNF) replaced traditional NetFlow on modern Cisco IOS platforms (IOS 12.4(20)T+, IOS-XE, IOS-XR). It uses a modular, policy-based approach: you define exactly which fields to monitor in a flow record, how to export in a flow exporter, and combine them in a flow monitor that is then applied to interfaces.

! ── Flexible NetFlow — full configuration ────────────────────────────────

! Step 1: Define the flow record (what fields to collect)
flow record MY-RECORD
description "IPv4 traffic analysis"
match ipv4 source address ! Src IP as a flow key field
match ipv4 destination address ! Dst IP as a flow key field
match transport source-port ! Src port as a flow key field
match transport destination-port ! Dst port as a flow key field
match ipv4 protocol ! Protocol as a flow key field
match interface input ! Input interface as a flow key field
collect transport tcp flags ! Non-key: collect TCP flags
collect counter bytes ! Non-key: count bytes
collect counter packets ! Non-key: count packets
collect timestamp sys-uptime first ! Non-key: flow start time
collect timestamp sys-uptime last ! Non-key: flow last seen time

! Step 2: Define the flow exporter (where to send data)
flow exporter MY-EXPORTER
destination 192.168.100.10
transport udp 2055
source Loopback0
export-protocol netflow-v9 ! Use v9 (template-based)
template data timeout 60 ! Send templates every 60 seconds

! Step 3: Define the flow monitor (links record + exporter)
flow monitor MY-MONITOR
record MY-RECORD
exporter MY-EXPORTER
cache timeout active 60 ! Export active flows every 60 seconds
cache timeout inactive 15 ! Export idle flows after 15 seconds

! Step 4: Apply to interfaces
interface GigabitEthernet0/0
ip flow monitor MY-MONITOR input
ip flow monitor MY-MONITOR output

! Step 5: Verify
Router# show flow monitor MY-MONITOR cache
Router# show flow exporter MY-EXPORTER statistics
Router# show flow record MY-RECORD

FNF key vs non-key fields: Fields under match are key fields — they define the flow identity (different values = different flows). Fields under collect are non-key fields — they accumulate statistics within a flow but do not split flows. For example, if you put collect transport tcp flags, all packets in the same flow contribute their flags to the collection but a FIN flag does not create a new flow; it just gets OR'd into the collected TCP flags value.

7. Traffic Analysis — Reading NetFlow Data

Top Talkers — Bandwidth Identification

The most immediate use of NetFlow is identifying which hosts, applications, or destinations consume the most bandwidth. This is called the Top Talkers report.

  Example Top Talkers output (from NetFlow collector):

  Rank  Source IP        Bytes       % Total  Protocol   Destination
  ───────────────────────────────────────────────────────────────────
  1     192.168.1.20     8.2 GB      42%      TCP/443    151.101.x.x (YouTube CDN)
  2     10.0.0.5         5.1 GB      26%      TCP/445    10.0.0.100  (File server backup)
  3     192.168.1.30     2.3 GB      12%      TCP/443    52.x.x.x    (Microsoft OneDrive)
  4     192.168.1.10     0.8 GB       4%      UDP/53     8.8.8.8     (High DNS query rate)
  5     10.0.0.99        0.5 GB       3%      TCP/6881   Various     (BitTorrent P2P — ALERT)

  Action items:
  • 192.168.1.20: Apply QoS to limit streaming — see ports.html for port reference
  • 10.0.0.5: Expected backup traffic — confirm schedule aligns with off-peak hours
  • 10.0.0.99: Investigate BitTorrent — potential policy violation; apply ACL

Protocol Breakdown

  Protocol distribution (last 24 hours):
  TCP/443 (HTTPS)  ████████████████████ 62%
  TCP/80  (HTTP)   ████████             24%
  UDP/53  (DNS)    ███                   8%
  UDP/123 (NTP)    █                     2%
  TCP/22  (SSH)    █                     2%
  Unknown 4444    ▌                      0.5%  ← Investigate! (common malware port)
  Other           ▌                      1.5%

Anomaly Detection

Sudden deviations from the flow baseline are the primary security signal NetFlow provides. Common patterns:

Anomaly Pattern	What NetFlow Shows	Likely Cause	Response
DDoS / Flood	Sudden spike to 10,000+ flows/sec from many sources to one destination IP; high packet rate with small packet sizes (UDP/ICMP)	Volumetric DDoS attack targeting your IP	Activate RTBH (Remotely Triggered Black Hole); contact upstream ISP; apply rate-limiting ACL
Port Scan	One source IP generates flows to the same destination IP across hundreds of different destination ports in rapid succession; each flow = 1 packet	Attacker or scanner mapping open services on a host	Block scanning IP; alert security team; review firewall rules for exposed services (see Firewall)
Botnet C2	Internal host makes repeated small flows to same external IP on unusual ports (e.g., port 8080, 4444, 6667); flows appear at regular intervals (beaconing)	Infected host checking in with Command & Control server	Isolate infected host; block C2 IP on firewall; incident response
Data Exfiltration	Large outbound flows from a database server to an unexpected external IP; high byte count; unusual destination (unknown cloud/hosting provider)	Attacker or malicious insider exfiltrating data	Block destination; alert security; investigate source host
Lateral Movement	Internal-to-internal flows; a workstation suddenly generating flows to many other internal hosts on ports like 445 (SMB), 135 (RPC), 22 (SSH)	Compromised host scanning or spreading to other internal systems	Isolate source host; check for worm/ransomware; review ACL for internal segmentation

8. NetFlow Sampling

On high-speed interfaces (10 Gbps+) or routers with limited CPU, monitoring every single packet is impractical. Sampling instructs the router to examine only a statistical subset of packets — reducing CPU and memory overhead at the cost of some accuracy.

  ! Traditional sampling — 1 in every 100 packets analysed
  interface GigabitEthernet0/0
   ip route-cache flow sampled

  ip flow-sampling-mode packet-interval 100   ! Sample 1 of every 100 packets

  ! Flexible NetFlow sampler
  sampler MY-SAMPLER
   mode random 1 out-of 100    ! Random sampling — 1 packet per 100 (1%)

  flow monitor MY-MONITOR
   record MY-RECORD
   exporter MY-EXPORTER
   sampler MY-SAMPLER           ! Attach sampler to the monitor

Sampling Rate	CPU Impact	Accuracy	Typical Use
1:1 (no sampling)	Highest — every packet processed	100% — exact flow data	Low-speed interfaces (<1 Gbps); security monitoring
1:10 (10%)	Moderate reduction	High — good for security analysis	1–10 Gbps interfaces; balance accuracy and performance
1:100 (1%)	Low — suitable for high-speed links	Statistical — good for bandwidth trending	10–40 Gbps interfaces; capacity planning and top-talker reports
1:1000 (0.1%)	Very low	Coarse — misses short-lived flows	100 Gbps+ backbone links; aggregate trend analysis only

Sampling and security: Sampling reduces the ability to detect short-lived threats like port scans (which generate many 1-packet flows). If security monitoring is the priority, use unsampled NetFlow on key security choke points (internet edge, data centre access) even if it means higher CPU, and use sampled flows on internal high-speed backbone links for capacity trending.

9. NetFlow vs sFlow vs IPFIX vs J-Flow

Protocol	Standard	Vendor	Sampling	IPv6 / MPLS	Key Difference
NetFlow v5	Cisco proprietary	Cisco	Optional	No	Fixed fields; most widely understood; IPv4 only; no templates
NetFlow v9	Cisco / IETF basis	Cisco	Optional	Yes	Template-based; flexible fields; foundation for IPFIX
IPFIX	IETF RFC 7011 (open)	Multi-vendor	Optional	Yes	Vendor-neutral standardisation of v9; variable-length fields; enterprise-specific elements; preferred for new deployments
sFlow	RFC 3176 (open)	HP, Juniper, Arista	Always (required)	Yes	Samples packets AND includes a portion of the actual packet payload (up to 128 bytes) — provides some Layer 7 context but is always sampled; no exact flow records; lower CPU than NetFlow
J-Flow	Juniper proprietary	Juniper	Optional	Yes	Juniper's equivalent to NetFlow v5/v9; exports to same collectors; supports Junos-specific fields
NetStream	Huawei proprietary	Huawei	Optional	Yes	Huawei's NetFlow equivalent; compatible with most NetFlow collectors when using v9/IPFIX format

Choosing a protocol: In Cisco-only environments, NetFlow v9 or Flexible NetFlow with IPFIX export is the standard choice. In multi-vendor environments (Cisco + Juniper + Arista), use IPFIX — it is the open standard that all vendors support. If you need actual packet content for application-level visibility, combine NetFlow with selective packet capture using Wireshark or tcpdump.

10. NetFlow vs Packet Capture

Feature	NetFlow / IPFIX	Packet Capture (Wireshark / tcpdump)
Data captured	Flow metadata only — no payload content	Full packet including headers AND payload
Privacy / compliance	High — no user data captured; safe for long-term retention	Low — captures all data including credentials, emails, files
Storage requirement	Very low — ~100–300 bytes per flow regardless of traffic volume	Very high — 1 Gbps interface generates ~450 GB/hour of capture data
Router/switch impact	Low CPU overhead (especially with sampling)	High — requires SPAN/mirror port; dedicated capture appliance
Retention period	Months to years — flow data is compact enough for long retention	Hours to days at most — storage constraints
What you can answer	Who talked to whom? How much? When? Which protocol? Top talkers? DDoS? Port scan? Beaconing?	What exactly was said? What data was transferred? Protocol decode? Application-level debugging?
Typical use	Continuous network-wide monitoring; security analytics; capacity planning; compliance; billing	Targeted troubleshooting of specific issues; malware analysis; application debugging

11. SIEM Integration

NetFlow data fed into a SIEM (Security Information and Event Management) system provides the traffic context that complements log data from syslog and SNMP. Together they give a complete security picture: SIEM correlates flow anomalies with authentication events, firewall logs, and threat intelligence feeds.

  ! Splunk — NetFlow queries (Splunk indexes flow data from collector)

  ! Find top bandwidth consumers in last hour:
  index=netflow earliest=-1h
  | stats sum(bytes) as total_bytes by src_ip
  | sort -total_bytes
  | head 10

  ! Detect port scans (one source, many destinations or ports):
  index=netflow earliest=-15m
  | stats dc(dest_port) as unique_ports by src_ip dest_ip
  | where unique_ports > 50
  | sort -unique_ports

  ! Find beaconing (periodic connections to same external IP):
  index=netflow dest_ip!=RFC1918
  | bucket _time span=1m
  | stats count by src_ip dest_ip _time
  | streamstats count as connection_number by src_ip dest_ip
  | eventstats stdev(count) as variability by src_ip dest_ip
  | where variability < 2   ! Very consistent — likely automated beaconing

  ! Detect large outbound data transfers (potential exfiltration):
  index=netflow dest_ip!=RFC1918
  | stats sum(bytes) as outbound_bytes by src_ip dest_ip
  | where outbound_bytes > 100000000   ! > 100 MB outbound
  | sort -outbound_bytes

12. Practical Use Cases

Use Case	What NetFlow Provides	Action Taken
WAN link saturation	Top Talkers report shows 192.168.1.20 using 60% of WAN bandwidth on TCP/443 (streaming video)	Apply QoS policy to rate-limit streaming traffic; inform user; consider SD-WAN for application-aware routing
Security incident response	Internal host 10.0.0.55 making 500 flows/minute to 50 different external IPs on TCP/4444	Isolate host from network; trigger incident response; forensic analysis; block C2 IPs on firewall
Capacity planning	NetFlow trend data shows WAN utilisation growing 15% per month; current 100 Mbps link will saturate in 4 months	Initiate upgrade procurement; justify with flow trend data
Billing / chargeback	Aggregated flow data by department VLAN shows IT consumed 8 TB, Finance 2 TB, Sales 1 TB last month	Internal chargeback billing; identify departments for cost conversations
DDoS mitigation	Spike to 50,000 flows/sec targeting one public IP; all flows have small packet sizes and come from thousands of source IPs	Activate RTBH to drop traffic to victim IP upstream; engage DDoS scrubbing service; notify ISP
Application visibility	Unknown flows on port 6881 (BitTorrent) from multiple workstations; confirmed policy violation	Apply ACL to block P2P ports; notify HR; document in security policy

13. Troubleshooting NetFlow

Symptom	Likely Cause	Diagnostic & Fix
No flows appearing in collector	Export destination not configured; UDP 2055 blocked by firewall; wrong collector IP	`show ip flow export` — verify destination IP and port; verify UDP 2055 is not blocked between router and collector; check collector is listening on correct port
Partial flows only — some traffic missing	`ip flow ingress` applied to some interfaces but not all; only inbound or outbound flows captured	Apply both `ip flow ingress` and `ip flow egress` on all relevant interfaces; check all WAN and LAN interfaces
High router CPU from NetFlow	Unsampled NetFlow on very high-speed interfaces; flow cache full	Enable sampling (`ip flow-sampling-mode packet-interval 100`); increase flow cache size; reduce active timer to export flows sooner
Flows missing IPv6 traffic	Using NetFlow v5 — does not support IPv6	Upgrade to NetFlow v9 or IPFIX; use Flexible NetFlow with IPv6 match fields
Collector receiving templates but no data	Using NetFlow v9/IPFIX — templates sent first; data records only sent after cache expiry	Wait for active timer expiry (default 30 min); reduce `cache timeout active` to 1 minute to receive data sooner
Flow byte counts much lower than interface counters	Sampling enabled — byte count represents sampled subset, not total	Multiply by sampling rate (e.g., 1:100 sample = multiply bytes by 100 to estimate actual total); disable sampling if exact counts needed

14. Key Points & Exam Tips

NetFlow collects flow metadata — not packet payload. A flow = unidirectional sequence of packets sharing the same 5-tuple: Src IP, Dst IP, Src Port, Dst Port, Protocol.
7-tuple extends the key with ToS and Input Interface.
Flow architecture: Exporter (router) → Collector (server) → Analyzer (dashboard).
NetFlow export uses UDP port 2055 by default (configurable).
v5: Fixed fields, IPv4 only, most compatible. v9: Template-based, IPv6/MPLS support. IPFIX: Open standard (RFC 7011), vendor-neutral, based on v9.
Flows expire via active timer (default 30 min — long-lived flows), inactive timer (default 15 sec — idle flows), or TCP FIN/RST.
Flexible NetFlow (FNF): flow record (fields to collect) + flow exporter (destination) + flow monitor (links them) applied to interface.
Sampling reduces CPU by only processing 1 in N packets (mode random 1 out-of 100). Reduces security detection capability for short-lived flows.
Security uses: top talkers (bandwidth hogs), port scan detection (many ports, single source), botnet beaconing (regular intervals to same external IP), DDoS detection (sudden flow rate spike), data exfiltration (large unexpected outbound flows).
show ip cache flow — view active flows and statistics. show ip flow export — verify collector configuration. show flow monitor <name> cache — FNF flows.
IPFIX = IP Flow Information Export (RFC 7011) — the IETF standardisation of NetFlow v9.

15. NetFlow Traffic Analysis Quiz

1. A network engineer configures NetFlow on a router's WAN interface but the security team reports they can only see traffic leaving the network, not traffic entering. What single command resolves this?

A. ip flow egress — this monitors both directions simultaneously B. ip flow-export version 9 — version 9 captures bidirectional traffic C. ip flow ingress applied to the interface — ip flow egress only captures outbound flows; ip flow ingress must be added separately to capture inbound traffic entering the interface D. ip flow-export destination with a second collector IP for inbound traffic

Correct answer is C. NetFlow on Cisco IOS applies separately to inbound and outbound traffic per interface. If only ip flow egress is configured, only packets leaving the interface (outbound from the router's perspective on that interface) are monitored. To also capture packets arriving on the interface (inbound), ip flow ingress must be explicitly added. On a WAN interface: ip flow ingress captures traffic arriving from the internet (inbound to router);

ip flow
                  egress

captures traffic leaving toward the internet (outbound from router). Both commands should be applied on all monitored interfaces for complete bidirectional visibility.

2. A NetFlow collector report shows host 10.0.0.44 generated 8,432 unique flow records in 60 seconds, each with exactly 1 packet to a different destination port on host 10.0.0.100. All flows used TCP. What is this traffic pattern and what is the likely explanation?

A. Normal behaviour — high-performance applications generate many short TCP sessions B. A DDoS attack — 10.0.0.44 is being flooded by many sources C. Bandwidth saturation — 8,432 flows indicate high throughput from this host D. A TCP port scan — one source (10.0.0.44), one target (10.0.0.100), thousands of unique destination ports, each flow = 1 SYN packet. The scanner is probing for open ports by sending SYN packets to sequential or random port numbers

Correct answer is D. This is the classic NetFlow signature of a TCP port scan. The distinctive characteristics: (1) One source IP to one target IP. (2) Each flow has a unique destination port. (3) Each flow contains exactly 1 packet — SYN is sent but no response received (closed/filtered port) or SYN-ACK received but ignored (the scanner doesn't complete the handshake). (4) Very high flow count in a short time. A port scanner like nmap in SYN scan mode (-sS) sends one SYN per port and never completes the TCP handshake, resulting in exactly this pattern: thousands of 1-packet flows. The response: block 10.0.0.44 on the firewall, investigate what tool was run and by whom, determine if this is an authorised security audit or an attacker who has compromised an internal host.

3. Why does NetFlow v5 become inadequate when an organisation upgrades to IPv6 and MPLS, and what is the correct replacement?

A. v5 does not support UDP — MPLS uses UDP exclusively B. NetFlow v5 has a fixed 48-byte record format designed exclusively for IPv4 — it has no fields for 128-bit IPv6 addresses or MPLS label stacks. Use NetFlow v9 (template-based, supports IPv6 and MPLS fields) or IPFIX (the open-standard equivalent of v9) C. v5 cannot export to UDP port 2055 — MPLS requires a different export port D. v5 supports IPv6 but not MPLS — upgrade to v7 for MPLS support

Correct answer is B. NetFlow v5's fundamental limitation is its fixed record format. Each v5 record is exactly 48 bytes with predefined fields — source IPv4 address (4 bytes), destination IPv4 address (4 bytes), and so on. IPv6 addresses are 128 bits (16 bytes), more than triple the size of IPv4's 32-bit (4-byte) addresses. The v5 format simply has no space for IPv6 addresses. MPLS label information (label values, experimental bits, stack depth) also has no corresponding fields in the v5 format. NetFlow v9 solved this with template-based records — a template message defines which fields will be included in subsequent data records. This allows v9 to include IPv6 source and destination addresses, MPLS label stack values, and any other required fields. IPFIX (RFC 7011) is the IETF standardisation of v9, adding vendor-specific enterprise fields and variable-length elements. There is no NetFlow v7 in standard deployment.

4. A NetFlow active timer is set to 30 minutes (default). A network engineer wants near-real-time visibility of a long-lived file transfer that has been running for 25 minutes but has not yet appeared in the collector. What should be changed and why?

A. Reduce the active timer to 1–5 minutes — the active timer controls how often mid-flow exports are sent for flows that are still active; a 30-minute timer means the collector won't see this flow until it has been active for 30 minutes or terminates B. Reduce the inactive timer — the inactive timer controls idle flow expiry C. Increase the active timer to 60 minutes — longer timers give more complete flow data D. Enable sampling — sampled flows are exported more frequently than unsampled flows

Correct answer is A. The active timer controls how often the router exports incremental records for flows that are still ongoing. With the default 30-minute active timer, a file transfer that starts and is still running at the 25-minute mark will not have sent any export yet — the first export won't happen until the 30-minute mark. Reducing the active timer to 1 minute (ip flow-cache timeout active 1 or cache timeout active 60 in Flexible NetFlow) means every active flow is exported to the collector every minute, providing near-real-time visibility. This increases export frequency and collector load but is necessary for real-time monitoring. The inactive timer (option B) applies to idle flows — a file transfer is not idle, so the inactive timer would not trigger for this scenario.

5. In a Flexible NetFlow configuration, what is the difference between a "match" field and a "collect" field in a flow record, and why does this distinction matter?

A. "match" fields are collected for security analysis; "collect" fields are used for routing decisions B. "match" fields are optional; "collect" fields are mandatory in every flow record C. "match" fields are key fields that define flow identity — two packets with different match values are in different flows. "collect" fields are non-key fields that accumulate statistics within a flow without splitting it — they provide additional data about the flow without increasing its granularity D. "match" filters which traffic to monitor; "collect" determines which interfaces to monitor

Correct answer is C. This is a fundamental FNF concept. Match (key) fields define what makes two packets belong to the same flow. If any match field differs, the packets are in different flows and create separate cache entries. Example: match ipv4 source address means every unique source IP gets its own flow entry. Collect (non-key) fields accumulate data about packets that already belong to the same flow. Example: collect counter bytes simply adds the byte count of each new packet to the running total for the flow — it doesn't create new flows based on byte count. Practical implication: adding more match fields increases the number of distinct flows (and cache entries, memory usage, export volume). Adding collect fields increases the size of each export record but not the number of records. Design flow records to have enough match fields for your use case but not so many that every packet becomes its own flow.

6. NetFlow monitoring shows that internal host 10.1.1.55 makes 5–8 short TCP connections every 10 minutes to the same external IP (203.0.113.99) on port 8080. The pattern has continued for 3 days. No user is actively using this host during off-hours when the pattern is most prominent. What security threat does this represent and what should be done?

A. Normal — applications frequently check for updates on schedule B. Botnet C2 beaconing — the host is infected with malware that regularly checks in with a Command & Control server at predictable intervals. The regularity, off-hours activity, and non-standard port (8080) are strong indicators. Isolate the host, collect forensic image, block 203.0.113.99 on the firewall C. The host is backing up data to a cloud service every 10 minutes D. The host's NTP synchronisation is creating excessive connections

Correct answer is B. This is a textbook botnet C2 beaconing pattern. The key indicators: (1) Regularity — 5–8 connections every 10 minutes is machine-generated behaviour, not human. (2) Same external destination — a specific IP, not CDN or cloud range. (3) Off-hours activity — malware doesn't know or care about business hours. (4) Non-standard port — port 8080 is sometimes used to bypass firewall rules that allow "web traffic" but the traffic is actually C2. (5) Small payloads — C2 beacons are typically small (just checking in). Modern malware often adds jitter (random variation) to the interval to avoid detection. Response: immediately isolate 10.1.1.55 from the network, create a forensic disk image before powering off, block 203.0.113.99 on the firewall, check other hosts for the same pattern (the malware may have spread), and investigate how the initial infection occurred.

7. An organisation has a Cisco router, a Juniper EX series switch, and an Arista data-centre switch all feeding flow data to the same collector. The engineer wants a single standardised protocol that all three devices support without proprietary extensions. Which protocol should be used?

A. NetFlow v5 — the most universally recognised format B. J-Flow — Juniper's implementation is compatible with all vendors C. sFlow — the most widely implemented open protocol D. IPFIX (RFC 7011) — the IETF open standard for flow export that Cisco (via IOS Flexible NetFlow), Juniper (via J-Flow in IPFIX mode), and Arista all support natively, ensuring consistent multi-vendor flow data to the same collector without proprietary format differences

Correct answer is D. IPFIX (IP Flow Information Export, RFC 7011) is the correct answer for multi-vendor environments. It is an IETF open standard derived from NetFlow v9's template-based model but without Cisco-proprietary elements. All major network vendors support IPFIX export: Cisco IOS/IOS-XE supports it natively via Flexible NetFlow with export-protocol ipfix; Juniper JunOS supports IPFIX as a cflowd export format; Arista EOS supports IPFIX directly. This means the collector receives data in the same format regardless of vendor, simplifying parsing and correlation. NetFlow v5 (option A) is IPv4-only and Cisco-specific, not suitable for Juniper or Arista. J-Flow (option B) is Juniper-proprietary. sFlow (option C) is open but uses sampling and captures partial packet content rather than full flow records — appropriate for different use cases than flow-based analysis.

8. A network engineer uses `show ip cache flow` and sees the following entry: `Gi0/0 10.0.0.5 Gi0/1 192.168.1.1 06 0050 C0A8 1234`. Which of the following correctly interprets this flow entry?

A. TCP flow from 10.0.0.5 entering Gi0/0, destined for 192.168.1.1 exiting Gi0/1; source port 80 (0x0050 = 80 decimal = HTTP); destination port 49320 (0xC0A8 = 49320 decimal) — this is a web server responding to a client B. UDP flow from a client to a DNS server on port 53 C. ICMP ping from 10.0.0.5 to 192.168.1.1 D. A BGP session between two routers on port 179

Correct answer is A. This tests the ability to read the show ip cache flow output format. Breaking down the entry: Gi0/0 = input interface; 10.0.0.5 = source IP; Gi0/1 = output interface; 192.168.1.1 = destination IP; 06 = protocol (decimal 6 = TCP); 0050 = source port in hex (0x0050 = 80 decimal = HTTP); C0A8 = destination port in hex (0xC0A8 = 49320 decimal — an ephemeral/high port). The source is port 80 (a server); the destination is an ephemeral port (a client). This is therefore a web server (10.0.0.5:80) responding to a client (192.168.1.1:49320). Note: in show ip cache flow, ports are displayed in hexadecimal — you must convert to decimal to identify well-known ports. 0x0050 = 80 (HTTP), 0x0035 = 53 (DNS), 0x01BB = 443 (HTTPS).

9. A security analyst configures NetFlow sampling at 1:1000 (1 in 1000 packets sampled) on a 100 Gbps backbone link. The next day they use this data to investigate a reported port scan that generated 5,000 short flows. How many of these flows would likely be captured in the sampled data?

A. All 5,000 — sampling applies to bytes, not flows B. 5,000 — sampled NetFlow still captures all flows but with reduced detail C. Approximately 5 flows — at 1:1000 sampling, only 1 in 1000 packets is examined. Port scan flows have exactly 1 packet each; at 1:1000 sampling, statistically only ~5 of the 5,000 single-packet flows would have their SYN packet sampled and recorded D. 500 flows — sampling reduces flow count by 10×

Correct answer is C. This illustrates the critical limitation of aggressive sampling for security monitoring. Sampling at 1:1000 means only 1 in every 1000 packets is examined — the other 999 are ignored and create no flow records. A port scan generates flows with exactly 1 packet each (the SYN). For each of those 5,000 single-packet flows, the probability that its one packet is the sampled packet = 1/1000. So statistically, only 5,000 × (1/1000) = 5 flows would be captured. The remaining 4,995 scan flows would be completely invisible. This is why sampling rate choice is critical: 1:1000 is appropriate for bandwidth trending on backbone links (large flows have many packets and will be sampled multiple times) but completely inadequate for security monitoring of scan activity. Security-focused NetFlow should use 1:1 (unsampled) or at most 1:10 sampling at internet edge and DMZ interfaces.

10. An engineer wants to implement Flexible NetFlow on a Cisco IOS-XE router to export IPv6 flow data to a collector at 10.10.10.50:9996 using IPFIX. The configuration must capture source/destination IPv6 addresses, transport ports, and byte counts. Place the following configuration steps in the correct sequence: (1) Apply flow monitor to interface, (2) Create flow record with IPv6 match fields, (3) Create flow exporter with IPFIX, (4) Create flow monitor linking record and exporter.

A. 1 → 2 → 3 → 4 B. 2 → 3 → 4 → 1 — create the record and exporter first (they are independent), then create the monitor that references both, then apply the monitor to the interface C. 3 → 2 → 1 → 4 D. 4 → 3 → 2 → 1

Correct answer is B. Flexible NetFlow has a dependency hierarchy that determines configuration order. The flow record and flow exporter are independent components — they do not reference each other and can be created in either order (2 and 3 are interchangeable). The flow monitor (step 4) references both the flow record and flow exporter — therefore both must exist before the monitor can be created. The interface application (step 1) references the flow monitor — therefore the monitor must exist before it can be applied. The correct sequence: (2) flow record MY-RECORD with match ipv6 source address, match ipv6 destination address, match transport source-port, etc. (3) flow exporter MY-EXPORTER with destination 10.10.10.50, transport udp 9996, export-protocol ipfix. (4) flow monitor MY-MONITOR with record MY-RECORD and exporter MY-EXPORTER. (1) interface Gi0/0 → ipv6 flow monitor MY-MONITOR input.

← Back to Home

NetFlow & IPFIX – Flow Monitoring and Traffic Analysis

1. What Is NetFlow?

2. What Is a Flow? The 5-Tuple and 7-Tuple

5-Tuple (Basic Flow Key)

7-Tuple (Extended Flow Key)

Flow Directionality

3. NetFlow Versions

NetFlow v5 Record Fields

4. Flow Cache: Active and Inactive Timers

5. Traditional NetFlow Configuration (Cisco IOS)

Complete Configuration Example

show ip cache flow — Reading the Output

6. Flexible NetFlow (FNF) — Modern Cisco IOS Configuration

7. Traffic Analysis — Reading NetFlow Data

Top Talkers — Bandwidth Identification

Protocol Breakdown

Anomaly Detection

8. NetFlow Sampling

9. NetFlow vs sFlow vs IPFIX vs J-Flow

10. NetFlow vs Packet Capture

11. SIEM Integration

12. Practical Use Cases

13. Troubleshooting NetFlow

14. Key Points & Exam Tips

15. NetFlow Traffic Analysis Quiz

1. A network engineer configures NetFlow on a router's WAN interface but the security team reports they can only see traffic leaving the network, not traffic entering. What single command resolves this?

2. A NetFlow collector report shows host 10.0.0.44 generated 8,432 unique flow records in 60 seconds, each with exactly 1 packet to a different destination port on host 10.0.0.100. All flows used TCP. What is this traffic pattern and what is the likely explanation?

3. Why does NetFlow v5 become inadequate when an organisation upgrades to IPv6 and MPLS, and what is the correct replacement?

4. A NetFlow active timer is set to 30 minutes (default). A network engineer wants near-real-time visibility of a long-lived file transfer that has been running for 25 minutes but has not yet appeared in the collector. What should be changed and why?

5. In a Flexible NetFlow configuration, what is the difference between a "match" field and a "collect" field in a flow record, and why does this distinction matter?

7. An organisation has a Cisco router, a Juniper EX series switch, and an Arista data-centre switch all feeding flow data to the same collector. The engineer wants a single standardised protocol that all three devices support without proprietary extensions. Which protocol should be used?

8. A network engineer uses show ip cache flow and sees the following entry: Gi0/0 10.0.0.5 Gi0/1 192.168.1.1 06 0050 C0A8 1234. Which of the following correctly interprets this flow entry?

9. A security analyst configures NetFlow sampling at 1:1000 (1 in 1000 packets sampled) on a 100 Gbps backbone link. The next day they use this data to investigate a reported port scan that generated 5,000 short flows. How many of these flows would likely be captured in the sampled data?

8. A network engineer uses `show ip cache flow` and sees the following entry: `Gi0/0 10.0.0.5 Gi0/1 192.168.1.1 06 0050 C0A8 1234`. Which of the following correctly interprets this flow entry?