tools

SNMP Simulator (snmpsim): Test Without Real Devices

Record a real SNMP agent's data and replay it as a simulated agent with snmpsim, for safe testing of monitoring pipelines without real hardware.

By the SNMP Monitoring team · Reviewed July 2026

You shouldn't have to point your monitoring at production hardware just to test a parser change or a new alert rule — and you often don't have the device in front of you anyway. snmpsim solves both problems: it records the SNMP responses of a real agent and replays them as a simulated agent, so you can develop and test against a faithful copy of a device that behaves consistently, costs nothing, and can't be knocked over by your experiments. This guide covers what it does, how to record and replay a device, where it fits in CI, and where the simulation stops.

Parent: tools. Siblings: Net-SNMP, snmpwalk.

What snmpsim does

At heart snmpsim is record-and-replay for SNMP agents. The capabilities that matter:

  • Records a live agent's responses into a data file you can keep and version.
  • Replays that data as a simulated agent that answers real snmpwalk/snmpget queries.
  • Serves many devices at once from one process, keyed by community or context.
  • Needs no real hardware — the simulation runs entirely on your machine.
  • Behaves deterministically, so a test gets the same answers every run.

The result is a lab you can spin up on a laptop that looks, to your monitoring, exactly like a rack of real devices. Where a simulator helps and where it doesn't, at a glance:

TaskReal devicesnmpsim
Test a parser in CISlow, needs lab accessFast, offline, repeatable
Reproduce an edge caseHard to provoke on demandHand-edit the data file
Load-test a collectorLimited by real hardwareMany simulated agents at once
Final acceptanceAuthoritativeNot a substitute

Recording a real device

The realistic way to build a simulation is to record an actual device once, then replay it forever. The classic tool captures a live agent's data into a .snmprec file:

snmprec -v2c -c public 10.0.0.20 1.3.6.1.2.1 > device.snmprec

To do this cleanly:

  1. Pick a representative real device and confirm you can walk it.
  2. Record the subtree(s) you care about into a .snmprec file.
  3. Store the file in your data directory (one file per simulated device).
  4. Version it alongside your tests, so the fixture is reproducible.
1.3.6.1.2.1.1.1.0|4|Linux app01 5.15.0-generic x86_64
1.3.6.1.2.1.1.3.0|67|45678901
1.3.6.1.2.1.1.5.0|4|app01

Each line is OID|type-tag|value — a compact, human-readable snapshot of exactly what the device returned. (Tool and binary names differ across snmpsim forks; verify the exact command for your installed version rather than assuming.)

Running the simulator

With a data directory of .snmprec files, start the responder and it serves each file as an agent. The command in current forks is snmpsim-command-responder, pointed at your data directory:

snmpsim-command-responder --data-dir=./data --agent-udpv4-endpoint=127.0.0.1:1161

Now query it exactly as you would a real device — here against the simulator's port:

snmpwalk -v2c -c device 127.0.0.1:1161 system
SNMPv2-MIB::sysDescr.0 = STRING: Linux app01 5.15.0-generic x86_64
SNMPv2-MIB::sysUpTime.0 = Timeticks: (45678901) 5 days, 6:53:09.01
SNMPv2-MIB::sysName.0 = STRING: app01

One responder can front many simulated agents, selected by the community name that maps to each data file — so a single process stands in for an entire test fleet.

Use cases

Simulation earns its keep anywhere touching real hardware is slow, risky, or impossible:

  1. CI pipelines — run your poller against a known fixture on every commit, no lab required.
  2. Parser/validation tests — feed odd values (edge cases, error states) your real devices rarely produce.
  3. Dashboard and alert development — build and demo against stable, repeatable data.
  4. Reproducing a bug — record a customer's unusual device once and debug it offline.
  5. Load testing — stand up many simulated agents to stress a collector without touching production.

Because the data is a file, you can hand-edit it to manufacture exactly the scenario a test needs — a disk at 99%, an interface flapping — which is far easier than provoking that state on real gear.

Variation modules

A static recording always returns the same value, which is fine for many tests but unrealistic for counters that should climb or gauges that should move. snmpsim's variation modules make selected OIDs dynamic — returning incrementing counters, values from a real command, or randomised readings — so a simulated interface's traffic counter actually advances between polls. That's what lets you test rate calculations, threshold crossings, and counter-wrap handling against the simulator instead of waiting for a real device to drift into the right state.

Limitations

Be clear about what a simulator is not. It replays data, not behaviour — it won't reproduce an agent's timing quirks, its exact error semantics under load, or vendor bugs you didn't record. A .snmprec file is only as complete as the walk that made it, so anything you didn't capture simply isn't there. And it's a functional stand-in, not a security or performance model of the real agent. Use snmpsim to validate your side of the conversation — parsers, thresholds, dashboards — and still do final acceptance against real hardware. Other simulators exist, but the record/replay approach is the common denominator.

Frequently asked questions

What is snmpsim?

snmpsim is an SNMP agent simulator. It replays recorded SNMP data — stored in .snmprec files — through a responder process (snmpsim-command-responder in current forks) so that snmpwalk/snmpget queries get realistic answers without any real device. One process can simulate many agents at once, which makes it ideal for testing monitoring pipelines.

How do I simulate an SNMP device?

Record a real device's responses into a .snmprec file (or write one by hand), place it in a data directory, and start snmpsim-command-responder pointed at that directory and a UDP endpoint. Then query the simulator's address/port with snmpwalk or snmpget exactly as you would a real agent. Verify the exact binary names for your installed version.

Can I record data from a real agent?

Yes — that's the recommended workflow. Capture a live agent's subtree into a .snmprec file (using snmprec or an equivalent recording of a walk), then replay it. The file is plain text, one OID|type|value line per object, so you can version it with your tests and even hand-edit it to craft edge cases.

Why simulate SNMP instead of using real devices?

Because it's safe, cheap, and repeatable. You can test parsers and alert logic in CI without a lab, reproduce a customer's device offline, and manufacture edge cases (full disks, error states) that real hardware rarely shows on demand — all without risking production or needing the physical device.

Key takeaways

  • snmpsim records a real agent's data and replays it as a simulated agent.
  • Data lives in .snmprec files (OID|type|value); one responder serves many agents.
  • Run it with snmpsim-command-responder --data-dir=… --agent-udpv4-endpoint=…, then query with snmpwalk.
  • Ideal for CI, parser tests, dashboards, bug repro, and load testing.
  • Variation modules make counters/gauges dynamic for realistic tests.
  • It replays data, not behaviour — do final acceptance on real hardware. Explore OIDs via the sensor index and the deployment checklist.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.