Generating NetFlow Data Without a Business-Grade Router

Get router-grade network visibility on a homelab budget.

You don’t need a $10,000 router to see what’s happening on your network. You just need the right lens.

Most people discover NetFlow (or IPFIX) the same way: they want visibility, they google “NetFlow,” and immediately run into a wall of “you need an enterprise router / switch that exports flows.”

That’s true if you’re trying to do router-exported NetFlow.

It’s not true if what you actually want is the end result: flow records you can slice, dice, ship to a data lake, correlate to alerts, and use for hunting.

This post covers the exact workflow I use to generate NetFlow-style data on a plain Linux box — no business-grade router required.

What NetFlow is (and why you should care)

NetFlow is not packet capture. It’s summarized metadata about network conversations (“flows”).

A flow is typically defined by the 5‑tuple:

• Source IP
• Destination IP
• Source port
• Destination port
• Protocol

…and then you get useful counters and timing:

• Bytes and packets
• Start/end timestamps
• TCP flags (for TCP)
• (Sometimes) interfaces, VLANs, ASNs, etc.

Why it matters:

• Retention: storing flows for weeks/months is realistic; storing PCAP for that long usually isn’t.
• Triage speed: flows answer “who talked to what, how much, and when” fast.
• Detection & hunting: beaconing, exfil, lateral movement patterns, weird egress, noisy hosts.
• Cost: flows are cheap to store, cheap to query, and map nicely into most analytics stacks.

If you’ve ever wished you could do “router-grade visibility” but you’re operating in a homelab, a small shop, a lab environment, or a tight budget… flows are the leverage.

The core idea

Instead of relying on a router to export flows, you:

1. Observe traffic on an interface (ideally a SPAN/mirror port or the gateway interface).
2. Convert packets to flow records using nfpcapd (from the nfdump toolset).
3. Process/export those flow files with nfdump into something easy to ingest, like CSV.

This gives you NetFlow-like telemetry even if your “router” is a consumer device that knows nothing about NetFlow.

Where to capture traffic

You only get flow visibility for traffic your Linux box can actually see. That means you need one of these capture points:

• Best: a switch mirror/SPAN port feeding a dedicated collector NIC
• Good: the Linux box is your gateway/router (so the WAN/LAN interface sees everything)
• Okay: host-level collection (you’ll only see flows for that host)

If you’re doing mirror/SPAN:

• Disable any “helpful” switch features that re-write or drop mirrored traffic.
• Make sure the collector interface is up and actually receiving frames.

Install the tooling

You need the nfdump toolset (because it includes both nfpcapd and nfdump).

On many distros this is as simple as installing a package named nfdump. If your distro package is ancient, build from source instead (especially if you want newer output formats like ndjson).

My workflow (verbatim)

This is the exact methodology I use:

# Capture data
sudo nfpcapd -i enp6s18 -D -w ~/netflow/raw -S 2 -t 300 -P /tmp/nfpcapd.pid

# Cleanly stop the collection process
if [ -f /tmp/nfpcapd.pid ]; then
  sudo kill "$(cat /tmp/nfpcapd.pid)" 2>/dev/null || true
  sudo rm -f /tmp/nfpcapd.pid
fi
rm -f ~/netflow/raw/nfcapd.current.*

# Create the CSV
nfdump -R ~/netflow/raw -o csv > ~/netflow/csv/all_flows.csv

A quick note: How to find the right interface

In the command above, I used -i enp6s18. Do not just copy-paste that. You need to specify the physical interface that is actually receiving the traffic you want to monitor.

If you are monitoring the host itself or acting as a gateway, the easiest way to find your primary interface is to ask “which interface connects me to the world?”:

# Find the interface used for the default route
ip route | awk ‘/^default/ {print $5; exit}’

If you are using a dedicated capture port (like a SPAN/mirror port on a switch), that interface likely won’t have an IP address or a default route. In that case, look for interfaces that are physically “UP” but exclude virtual stuff like Docker or bridges:

# List physical-looking interfaces that are UP
ip -o link show | grep ‘state UP’ | awk -F’: ‘ ‘{print $2}’ | grep -vE ‘^(lo|docker|veth|br-|virbr|vnet)’

Sanity Check: Before you start the daemon, run a quick tcpdump on your chosen interface to make sure you see the packets you expect: sudo tcpdump -i <your_interface_name> -n -c 5

What those flags are doing (and why I use them)

Capture + rotate on an interval

sudo nfpcapd -i enp6s18 -D -w ~/netflow/raw -S 2 -t 300 -P /tmp/nfpcapd.pid

• -i enp6s18 — the interface you’re sniffing. Replace this with your capture NIC.
• -D — run as a daemon.
• -w ~/netflow/raw — write flow files locally in the standard nfcapd file format.
• -S 2 — create a subdirectory hierarchy under the output directory (helps prevent “one directory with a million files”).
• -t 300 — rotate files every 300 seconds (5 minutes). This keeps files reasonably sized, makes backfills easy, and aligns with how a lot of tooling expects flow data to roll.
• -P /tmp/nfpcapd.pid — write a PID file so stopping the process is deterministic.

This is not just convenience. Rotation is operational hygiene: smaller chunks are easier to copy, parse, compress, and delete on a schedule.

Cleanly stop collection

if [ -f /tmp/nfpcapd.pid ]; then
  sudo kill "$(cat /tmp/nfpcapd.pid)" 2>/dev/null || true
  sudo rm -f /tmp/nfpcapd.pid
fi
rm -f ~/netflow/raw/nfcapd.current.*

Two reasons I do this:

1. I want the process to terminate cleanly, every time, with no guessing.
2. nfcapd.current.* files represent “currently-being-written” state. If I’m about to export/ingest everything, I don’t want a partial interval file sneaking into my dataset.

(If you’re running this continuously, don’t delete nfcapd.current.* while the daemon is active.)

Export to CSV

nfdump -R ~/netflow/raw -o csv > ~/netflow/csv/all_flows.csv

• -R ~/netflow/raw — read a directory tree of nfcapd.* flow files.
• -o csv — print records in CSV format.

At this point you have a “dumb and universal” artifact: a CSV you can ingest anywhere.

Quick sanity checks

Before you go build dashboards and detection logic, confirm you’re actually collecting what you think you’re collecting:

• Check that your interface is seeing traffic: sudo tcpdump -i <iface> -c 20
• After a few minutes, run a spot query:

nfdump -R ~/netflow/raw | head

If you see nothing, the issue is almost always one of:

• Wrong interface
• No mirror/span configured
• Capture point can’t see the traffic you care about
• Permissions/capabilities (run as root to eliminate ambiguity)

Practical tips that make this usable at scale

1) Don’t treat CSV as the only output format

CSV is great for portability, but for pipelines you may prefer JSON/NDJSON if your tooling is log-centric.

2) Use filters early

If you know you only care about specific subnets, protocols, or ports, filter during export instead of shoveling everything:

nfdump -R ~/netflow/raw -o csv 'src net 10.0.0.0/8 and dst net 0.0.0.0/0'

3) Plan retention

Flows are small compared to PCAP, but they’re not free.

• Decide how long you keep raw nfcapd.* files.
• Decide whether you keep rolled-up exports.
• Automate deletion so the collector doesn’t become a surprise outage.

4) Know what you’re not getting

This method produces flow records from observed packets. That’s awesome, but there are caveats:

• You only see what hits the interface.
• NAT can collapse “who did what” depending on where you capture.
• Router-exported NetFlow sometimes includes device-specific fields you won’t have.

For most security + visibility workloads, the trade is worth it.

Where this fits in a real workflow

Once you have flow data, you can:

• Build “top talkers” views (hosts, ports, destinations)
• Detect beaconing (periodic low-byte flows)
• Detect exfil patterns (rare destinations + high byte counts)
• Correlate destinations with threat intel
• Join flows to asset inventory (hostnames/owners/environments)

Flows are the backbone dataset you wish you had before you needed it.

Closing

If you don’t have a router that exports NetFlow, you’re not blocked; you just need a box that can observe traffic and a tool that can convert packets into flow records.

That’s what nfpcapd + nfdump gives you: a practical “poor man’s NetFlow” pipeline that scales surprisingly far.

If you build on this approach (continuous collection, compression, forwarding, enrichment, pipeline ingestion), you end up with visibility that feels a lot more “enterprise” than the router that started it all.