Best Network Traffic Generators for Lab Testing 2026: iperf3 vs TRex vs Ostinato vs OTG

A lab without traffic is a diagram that boots. Until real packets cross the links, you haven't tested QoS classification, failover behavior, convergence under load, or whether the backup path actually carries what the design says it carries. The question every lab builder hits — on Reddit's r/networking it comes up as "best traffic generator for a lab/demo environment" — is which traffic generator to use, and the answer depends less on raw speed than on what you're trying to prove.

This post compares the five realistic options for generating test traffic in a virtual network lab in 2026 — iperf3, Cisco TRex, Ostinato, the Open Traffic Generator ecosystem (Keysight's ixia-c), and hardware chassis — plus the option that changes the workflow: an AI agent that runs the traffic tests for you.

Quick Comparison

Bottom line: iperf3 + tc/netem covers most functional lab testing free; TRex when you need serious rates; Ostinato when you need to craft specific frames; OTG when tests live in CI; hardware only for line-rate certification. For the workflow itself, NetPilot is the agent-run option — describe the objective in plain English and the agent builds the multi-vendor lab, places the endpoints, runs the iperf3/tc tests, and hands you the measured report in one session.

What "traffic generation" actually means in a lab

Three distinct jobs hide under one term, and picking the wrong tool for the job is the most common mistake:

1. Flow measurement — push TCP/UDP between two points and measure throughput, retransmits, loss, jitter, RTT. This is iperf3's home turf, and it's what most functional tests need: does the backup path sustain 500 Mbps? What's the jitter over the impaired WAN link?
2. Traffic profiles at rate — replay realistic mixes (IMIX), many flows, high packets-per-second, to stress queues, CAM tables, and control planes. TRex and hardware chassis live here.
3. Packet crafting — build specific frames (malformed headers, exotic protocols, precise DSCP/VLAN tag combinations) to poke at edge cases. Ostinato and Scapy live here.

A fourth job is often confused with generation: impairment. tc/netem doesn't generate traffic — it degrades a link (delay, jitter, loss, reordering, rate limits) so the traffic you are generating experiences WAN-like conditions. Nearly every serious lab test pairs a generator with netem.

iperf3 — the default, for good reason

iperf3 is maintained by ESnet, ships in every Linux distro, and does one thing precisely: measure what a path actually delivers between two endpoints.

Strengths

• Real TCP and UDP — actual congestion control, actual retransmits, so the numbers reflect what applications would see.
• Measures the full set — throughput, retransmissions, UDP loss, jitter, and (with --bidir) both directions at once.
• DSCP marking built in (--dscp) — send flows in different classes and see which one the QoS policy protects.
• JSON output (-J) — trivially scriptable, which also makes it the tool AI agents drive best.

Limitations

• Host-to-host flows only — it will not synthesize a thousand-flow IMIX mix or exercise a switch's full forwarding table.
• Single-stream rates depend on the endpoint's CPU and the virtual NIC; in containerized labs expect single-digit Gbps per stream pair, which is plenty for functional tests and useless for line-rate claims.

Verdict: start here. If your question is "does this path/policy/failover behave correctly under load?" rather than "what does this ASIC do at 400G?", iperf3 answers it.

Cisco TRex — high rates without hardware money

TRex is Cisco's open-source, DPDK-based generator. On decent NICs it pushes tens of gigabits and millions of packets per second, and its ASTF mode generates stateful TCP at rates iperf3 can't touch. Cisco's own docs cover running TRex as a VM inside emulated labs.

Strengths: field-replay realism (it can amplify captured pcaps into full-rate profiles), stateless and stateful modes, serious rates on commodity hardware, genuinely free.

Limitations: the learning curve is real — DPDK NIC binding, YAML traffic profiles, a Python API you'll end up scripting. In fully-virtual topologies (no DPDK passthrough) its rate advantage shrinks toward the software tier. It's a tool you adopt, not one you casually run once.

Verdict: the right choice when the rate itself is the test — stress a queueing policy at millions of pps, load a firewall's session table — and you're willing to invest setup time.

Ostinato — craft the exact packet

Ostinato is a GUI-first packet crafter and generator: build a frame field by field (any header stack, any tag combination), then stream it at a configured rate per port. In 2026 it ships a containerlab-native edition — its lab tier is priced from $8/month — which says something about where lab traffic-gen demand lives now.

Strengths: unmatched control over frame contents; a GUI that makes one-off protocol experiments fast; drone agents let one controller drive ports across multiple hosts.

Limitations: stateless only — it streams the frames you built and does not run a TCP state machine, so it can't answer "what throughput does the application get." Binaries are paid (the core is open source but you're realistically buying the builds).

Verdict: reach for it when the test is about specific packets — does the ACL match this exact header combination, how does the switch treat this malformed frame — not about flows.

OTG / ixia-c — traffic tests as code

The Open Traffic Generator API is Keysight's open standard, with ixia-c as the free containerized implementation and snappi as the Python/Go client. Tests are declarative configs — ports, flows, expected metrics — which makes them repeatable and CI-native, and it deploys directly inside containerlab topologies.

Strengths: the declarative model is exactly right for regression suites (the same test file runs on the free container today and a hardware chassis later); vendor-backed; containerlab-native.

Limitations: code-first — there's no casual mode; you're writing snappi programs. The free community edition caps features/ports vs the commercial tiers. Stateful TCP support is narrower than TRex's ASTF.

Verdict: the NetDevOps choice — if your team already gates merges in CI and wants traffic tests versioned next to configs, OTG is the standard to bet on.

Hardware chassis — the lane that stays hardware

Keysight IxNetwork (which absorbed Ixia) and VIAVI TestCenter (formerly Spirent TestCenter) own line-rate 100/400G characterization, RFC 2544/conformance certification, and port-dense chassis testing. If you're certifying an ASIC, benchmarking at line rate, or handing a compliance report to a carrier, this is the tier — and nothing in this post replaces it. Our Keysight/Spirent alternative deep-dive covers where a virtual lab genuinely substitutes (roughly the functional 80%) and where it honestly doesn't (line rate).

The agent-run option: nobody scripts, the tests still run

Every tool above shares one assumption: you design the test, you drive the tool, you collect the numbers. That assumption is why so many labs get deployed and never actually tested — the topology comes up, a couple of pings succeed, and the "test plan" stays in a spreadsheet.

The AI-agent workflow inverts it. In a NetPilot network testing lab, you state the objective:

"Fail the primary WAN link and prove the backup path sustains 500 Mbps of TCP with under 50 ms added latency and under 1% loss. Report per-flow numbers."

The agent builds the multi-vendor topology (FRR neighbors for real BGP/OSPF/IS-IS peering where needed), places Linux endpoints, and runs the same tools this post covers — iperf3 for the flows, tc/netem for the impairments, DSCP-marked streams for QoS checks — in parallel across devices, then returns a consolidated pass/fail report with the measured throughput, loss, jitter, and RTT per flow.

Direct CLI is always available too. SSH into any endpoint and run iperf3 -c 10.0.2.1 -u -b 500M --dscp 46 yourself, or tc qdisc add dev eth1 root netem delay 30ms 5ms loss 1% to reproduce the impairment by hand. The agent is the fast path; the CLI is the verification layer — every number in the report is reproducible from a shell.

The honest scope note: the agent drives the software tier (iperf3-class rates). It does not claim TRex-scale pps or hardware line rate — for those, run TRex or book the chassis, and use the agent-built lab as the topology around them.

FAQ

What is the best free traffic generator for a network lab?

iperf3, for most purposes — real TCP/UDP flows, throughput/loss/jitter/RTT measurement, DSCP marking, JSON output, zero cost, and it's preinstalled or one package away on any Linux node. Pair it with tc/netem for impairments. Move to Cisco TRex (also free) only when you need rates or flow-counts iperf3 can't generate.

How do I generate traffic in containerlab or a virtual lab?

Add Linux containers as traffic endpoints and run iperf3 between them across the topology under test — this is the pattern NetPilot automates from a plain-English request. For higher rates, TRex runs as a VM or container with appropriate NIC access; Ostinato ships a containerlab-native edition; and OTG/ixia-c deploys as containers driven by snappi test scripts.

Can iperf3 test QoS and DSCP marking?

Yes. iperf3's --dscp flag sets the DiffServ codepoint per flow, so you can send EF-marked and best-effort flows simultaneously, congest the link, and verify from the device's policy counters which class kept its throughput and delay targets. An agent-run lab automates the full loop — marked flows, congestion, per-class counter reads, verdict.

What's the difference between a traffic generator and tc/netem?

A traffic generator creates packets (iperf3, TRex, Ostinato); tc/netem impairs a link that traffic crosses — adding delay, jitter, loss, or reordering. Real lab tests usually combine them: generate flows with iperf3, degrade the path with netem, and measure whether the design still meets its targets.

Do virtual-lab traffic tests replace hardware traffic generators?

For functional and behavioral testing — QoS policy, failover, convergence under load, path verification — largely yes, at a fraction of the cost. For line-rate 100/400G characterization and conformance certification, no: Keysight and VIAVI hardware remains the right tool, and honest test plans use both tiers.

Best tool for each test

Which should you choose?

• Testing a path, policy, or failover behaves correctly → iperf3 + tc/netem.
• Stressing queues, session tables, or control planes at rate → TRex.
• Crafting exact frames for edge cases → Ostinato (or Scapy if you prefer code).
• Traffic tests versioned in CI → OTG/ixia-c with snappi.
• Certifying at line rate → Keysight / VIAVI hardware.
• You want the lab built and the tests run for you, from plain English → NetPilot — the agent runs the software tier end to end and reports the numbers, with SSH access to verify any of them by hand.

Copy-paste ready: the traffic generation & impairment testing prompt builds the lab, runs the iperf3/netem battery, and produces the report — paste it into app.netpilot.io as-is.

Related: AI-native network testing lab · Network change validation · Test plans & NRFU, generated and executed by AI