DEV Community

Cover image for Stop testing your flow collector with random NetFlow tuples
Stefan Sabolowitsch
Stefan Sabolowitsch

Posted on

Stop testing your flow collector with random NetFlow tuples

If you have ever built or operated a flow collector, you know the problem: the
usual test generators emit random tuples. Random source IP, random destination,
random ports, random counters. That is fine for a parser smoke test — and
useless for everything after the parser. Dashboards look like noise, enrichment
has nothing meaningful to enrich, and "does my Top-Talkers panel actually make
sense?" is a question random data cannot answer.

I ran into this while building my own collector stack (flow collector →
VictoriaLogs → Grafana) and converting ElastiFlow dashboards to LogsQL. I
needed traffic that behaves like an enterprise network — repeatably, at a
controlled rate, without pointing test tooling at production. So I built one.

flowsimulator-go
is an open-source enterprise flow simulation platform written in Go. MIT
licensed, single static binary, one dependency.

The core idea: simulate sessions, not tuples

Instead of rolling dice per record, flowsimulator-go models an enterprise
network in YAML — sites, VLANs, address pools, endpoint personas
(windows_client, domain_controller, firewall, …), applications, and
services — and then plays ordered session chains on top of it.

The built-in windows-login template is a good example. One session produces
six flow records, in order:

windows-login session template: dns_query and dns_response to the DNS server, kerberos and ldap to the domain controller, smb_read and tcp_disconnect to the file server — each event emits one flow record

DNS before Kerberos, Kerberos before LDAP, LDAP before SMB — the way a real
Windows logon looks on the wire. Web browsing resolves DNS before opening TLS.
Backups authenticate before they transfer. A behaviour profile
(interactive-tcp, bulk-transfer, asymmetric-download, …) shapes bytes,
packets, duration, and TCP flags per event.

There are ~30 built-in templates, including security patterns: port scans,
SSH/RDP brute force, SMB enumeration, beaconing, DNS tunneling, exfiltration,
and lateral movement. Crucially, these run as low-weight scenarios blended
into dominant normal traffic — because a detection dashboard tested against
100% attack traffic tells you nothing.

One neutral core, four wire protocols

Architecturally, everything funnels through a protocol-neutral FlowRecord:

Architecture: YAML config feeds the scenario engine, which produces protocol-neutral FlowRecords that per-exporter encoders serialize as NetFlow v5, NetFlow v9, IPFIX, or sFlow v5 and send over UDP to a flow collector

The scenario engine knows nothing about wire formats; the encoders (NetFlow v5,
NetFlow v9, IPFIX, sFlow v5) know nothing about scenarios. Each exporter keeps
its own encoder state — sequence numbers, NetFlow v9/IPFIX template
refresh/cache, sFlow sample pools — so a mixed-protocol simulation behaves like
a fleet of independent devices. Templates are derived from a central,
source-backed IANA/IPFIX information element registry; custom enterprise IEs
can be added via registry files.

Runs are deterministic: same seed + same config = same dataset. That makes
regression testing across collector versions actually meaningful.

Quickstart

git clone https://forgejo.sabolowitsch.org/StefanSA/flowsimulator-go.git
cd flowsimulator-go
go run ./cmd/flowsimulator-go run -c configs/examples/minimal-netflow5.yaml --duration 5s
Enter fullscreen mode Exit fullscreen mode

That sends five seconds of NetFlow v5 to 127.0.0.1:2055. Minimal configs
exist for all four protocols, enterprise examples model HQ/campus/datacenter/
hybrid-cloud topologies, and a continuous lab config runs all four protocols
until SIGTERM — useful as a permanent telemetry source for an observability
lab or collector burn-in. A JSON status endpoint reports records, packets,
bytes, per-protocol counters, and current rate while it runs.

What it deliberately does NOT do

A few honest boundaries, because I think tooling should state them up front:

  • No invented vendor fields. Cisco/Palo Alto/Fortinet enterprise IEs only enter the registry with a documented source. No made-up field numbers.
  • No payloads, no PCAP replay, no fuzzing. It serializes flow records, nothing else. The security scenarios are synthetic flow patterns for testing detection pipelines — they do not perform attacks.
  • IPv4 only for now. IPv6, IPFIX Options Templates, and richer NAT/MPLS/VXLAN/SD-WAN records are on the roadmap.

Try it

If you build or operate flow collectors — or you just want realistic NetFlow/
IPFIX/sFlow data for a Grafana lab — I would genuinely like to hear what breaks
and what is missing. Issues and feedback welcome.

Top comments (0)