Open source · MIT · v0.4
The Open-Source Network Device Simulator for NMS Load Testing
Stand up 50,000 simulated Cisco IOS devices on one Linux host. Real SSH, realistic running-configs, zero-copy delivery, built for network configuration management testing.
- MIT licensed
- Real SSH
- Cisco IOS
- One Linux host
$ rconfig-sim start --devices=50000 --model=cisco-ios --ssh-port-base=22000 --config=./fleet.yaml › reading fleet.yaml ............. ok (1,284 templates) › preallocating vnet0 namespace pool ok › binding sshd listeners 22000-72000 ok
You cannot scale-test an NMS against fifty devices and call it done.
Network automation load testing has always been bottlenecked by the thing being tested. You can poll fifty devices and learn something about correctness; you cannot learn anything about what happens when your collector, diff engine, or scheduler hits a realistic fleet.
Virtual labs, GNS3, EVE-NG, Containerlab, are excellent for protocol work and small topologies, but they were never built to simulate network devices at scale on commodity hardware. Renting a 50,000-device lab is absurd.
rConfig-sim fills that gap. It exposes 50,000 concurrent SSH listeners on a single Linux host, each answering real Cisco IOS commands and serving realistic running-configs via mmap. It is the only thing we have found that lets you ask a meaningful question about how to load test network configuration management platforms at scale.
Built for fleet-scale NMS testing
50,000 concurrent SSH listeners
A single systemd unit template fans out across loopback IPs. One host, no orchestration layer, no container runtime. Handshake latency stays under 200 ms at full fleet.
Real Cisco IOS emulation
Enable mode, abbreviated command matching (sh run, sh ver), user EXEC to privileged EXEC transitions, realistic prompts. It answers the same commands your collector already sends.
Zero-copy config delivery via mmap
Running-configs sit on disk as memory-mapped files and stream straight to SSH channels. No per-session allocation, no copy. This is how it fits 50,000 devices in 6.4 GB RSS.
Fault injection, deterministic
Four failure modes, auth_fail, disconnect_mid, slow_response, malformed, seeded per-device. Your retry logic, timeout handling, and diff engine get tested against the failures they will actually see.
Prometheus metrics, bounded cardinality
Session counts, bytes served, handshake timings, per-fault-mode counters. Cardinality caps enforced so the metrics endpoint does not itself become the load test.
Systemd-native, per-IP isolation
Every simulator instance is a rcfg-sim@<ip>.service unit. Journal logs per device, resource limits per device, and single-unit restarts when you want to watch your NMS recover one node.
What you can actually test
“I want to load test my NMS against a realistic fleet.”
Scenarios 5-9 walk through steady-state polling, diff-ingest sustained load, and concurrent operator fan-out. Fleet size up to 50,000 devices, config sizes from 4 KB to 6 MB.
Read the scenario: scenarios 5-9“I want to validate retry logic against intermittent device failures.”
Fault injection seeds 2-5% of the fleet with disconnect_mid and auth_fail on a deterministic rotation. Your collector's retry, backoff, and circuit-breaker code runs against real failures, not mocks.
Read the scenario: fault injection“I want to stress test my diff engine with huge configs.”
The heavy-config skew scenario configures 5% of the fleet to serve 4-6 MB running-configs (think core routers with thousands of interfaces). Find out where your differ actually breaks.
Read the scenario: heavy-config skew“I want to test NMS burst handling when an operator clicks Refresh All.”
Burst-load scenario drives 50,000 concurrent poll requests inside a 30-second window. Most collectors are fine at steady state. Very few are fine when the operator gets impatient.
Read the scenario: burst load“I want to benchmark competing NCM platforms on identical load.”
Deterministic device identity, deterministic config content, deterministic failure seeding. Runs are reproducible across platforms, so the comparison is on the collector, not the input.
Read the scenario: reproducibility
How it compares to other network simulation tools
| Capability | rConfig-sim | GNS3 / EVE-NG | Containerlab | SSH mocks | Real hardware lab |
|---|---|---|---|---|---|
| Max devices per host | 50,000+ | ~30 | ~200 | unbounded | physical |
| Real SSH | yes | yes | yes | partial | yes |
| Real config output | yes | yes | yes | stubbed | yes |
| Deterministic fleet | yes | no | partial | yes | no |
| Setup time | minutes | hours, days | hours | minutes | weeks |
| Cost | free (MIT) | free + licences | free | free | six figures |
| Built for NMS load testing | yes | no | no | no | no |
| Protocol accuracy | IOS surface | full | full | surface | full |
If you need full-stack protocol realism, use GNS3 or Containerlab. If you need to know how your collector handles 50,000 SSH sessions at once, a question about network management platform testing, use this.
What it looks like running
Reference host: 32 vCPU / 64 GB, Hetzner AX102
- Devices
- 50,000single host
- Resident memory
- 6.4 GBafter 1 h steady-state
- Boot to ready
- 42 scold start
- Average handshake
- 183 ms50,000 concurrent
- Bytes per session (avg)
- 112 KBmixed config sizes
- Open file descriptors
- 201,542sustained
Ten minutes of output on a reference host. No marketing gloss, if the numbers don't match yours, tell us in an issue.
$ systemctl list-units 'rcfg-sim@*' --type=service --no-pager --plain UNIT LOAD ACTIVE SUB DESCRIPTION rcfg-sim@10.0.0.1.service loaded active running rconfig-sim shard (10.0.0.1) rcfg-sim@10.0.0.2.service loaded active running rconfig-sim shard (10.0.0.2) rcfg-sim@10.0.0.3.service loaded active running rconfig-sim shard (10.0.0.3) rcfg-sim@10.0.0.4.service loaded active running rconfig-sim shard (10.0.0.4) rcfg-sim@10.0.0.5.service loaded active running rconfig-sim shard (10.0.0.5) ... rcfg-sim@10.0.0.20.service loaded active running rconfig-sim shard (10.0.0.20) 20 loaded units listed · 50,000 devices served
$ curl -s localhost:9394/metrics | grep -E '^rcfg_sim_'
rcfg_sim_sessions_active 49982
rcfg_sim_sessions_total{state="ok"} 2.184e+06
rcfg_sim_sessions_total{state="auth_fail"} 2.31e+04
rcfg_sim_sessions_total{state="disconnect_mid"} 1.08e+04
rcfg_sim_handshake_ms_p50 142
rcfg_sim_handshake_ms_p99 311
rcfg_sim_bytes_served_total 6.12e+11
rcfg_sim_rlimit_nofile_pct 0.77
rcfg_sim_fault_injection_ratio 0.032
rcfg_sim_build_info{version="0.4.0",goos="linux",goarch="amd64"} 1Three commands from nothing to 50,000 devices
Generate the fleet
Emits 50,000 running-configs, a
manifest.json, and the systemd drop-in. Typical runtime: 8 minutes on a modern 16-core host.$ rcfg-sim-gen --count 50000 --out ./fleetStart the simulators
Each unit owns an IP and serves 200 devices. Twenty-five such units for the full 50,000. Deterministic port assignment via systemd template expansion.
$ systemctl start rcfg-sim@10.0.0.{1..250}.servicePoint your NMS at the manifest
Import
manifest.json, it contains hostname, IP, port, model, and credentials for every simulated device. Your collector sees a fleet of Cisco IOS devices. Your collector cannot tell the difference.$ rconfig import-manifest ./fleet/manifest.json imported 50,000 devices · 0 errors $ rconfig backup --all --parallel 256
Built for rConfig, works against any SSH-polling NMS
We built rConfig-sim to load-test rConfig, the open-source network configuration management platform. Every performance claim rConfig makes, 50,000-device fleets, sub-minute backup cycles, bounded memory under burst, was validated with this simulator before it left the build pipeline.
The same harness works against any NMS that polls devices over SSH: NetBrain, SolarWinds NCM, Oxidized, BackBox, RANCID, or your internally-built tooling. If it speaks SSH to Cisco IOS, it can be load-tested against rconfig-sim, no vendor lock-in, no fake network devices for testing behind a paywall.
Frequently asked questions
Quick answers for network automation engineers, NMS platform teams, and contributors.
What is rConfig-sim?
rConfig-sim is an open-source network device simulator that runs up to 50,000 fake Cisco IOS devices on a single Linux host. Each simulated device answers real SSH connections and serves realistic running-configs. It exists to let you load test network configuration management platforms at scale without a hardware lab.
How does rConfig-sim compare to GNS3 or EVE-NG?
GNS3 and EVE-NG run full Cisco IOS images inside virtual machines, they are protocol-accurate to the last byte. They also top out around 30 devices per host and need real Cisco software licences. rConfig-sim is surface-accurate to IOS commands your NMS actually sends, but fits 50,000 devices in 6.4 GB of RAM. Different tools for different jobs, use GNS3 for protocol work, use rConfig-sim for NMS scalability testing.
Can I use rConfig-sim to test NMS platforms other than rConfig?
Yes. Any NMS that polls devices over SSH, NetBrain, SolarWinds NCM, Auvik, BackBox, Oxidized, RANCID, or an internal tool, can point at a rConfig-sim fleet. The simulator answers standard Cisco IOS commands over SSH; whatever your collector sends is what it responds to.
What Cisco IOS commands does it support?
Login, enable, show version, show running-config, show startup-config, show interfaces, terminal length 0, command abbreviation, enable secret handling, and the EXEC to privileged EXEC transition. It covers the command surface that network configuration management tools actually hit, not the full IOS CLI.
How many devices can it simulate on one server?
50,000 concurrent Cisco IOS devices on a 32 vCPU / 64 GB reference host, sitting at 6.4 GB resident memory. The practical ceiling on commodity hardware is file-descriptor limits, not CPU or RAM.
Is rConfig-sim production-ready?
It is production-ready for what it is, a load-testing tool. It is not a device substitute for production traffic. We run it in CI against every rConfig release, and we ship the same binary externally. The project is MIT-licensed; use it, fork it, break it.
How much does it cost?
Zero. rConfig-sim is MIT-licensed and free to use, modify, and redistribute. There is no paid tier and no enterprise fork.
Can it simulate Juniper, Arista, or other vendors?
Not currently. The v0.4 release covers Cisco IOS only. Juniper Junos and Arista EOS are tracked as future work, a pluggable dialect layer exists in the codebase, but the other dialects are not implemented. Contributions welcome.
Does it support SSH key authentication?
Yes. Password auth and public-key auth both work, configurable per fleet. The manifest carries credentials for every simulated device so your NMS can authenticate the same way it would against real hardware.
How do I contribute?
The repo lives at github.com/rConfig/rConfig-sim. Issues, PRs, and protocol-dialect contributions are all welcome. The codebase is Go, the test suite runs the simulator against a real SSH client, and the CI gate is strict about zero-copy invariants in the hot path.
Load test your NMS against 50,000 real SSH sessions
rConfig-sim is MIT-licensed, single-host, and production-ready for load testing. The repo has the quickstart, the scenarios, and the full deployment guide.