$ 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 › raising RLIMIT_NOFILE to 262144 (was 1024) HOSTNAME MGMT-IP MODEL IOS PID SSH STATE wan-syd-5744 10.0.160.247 cat6500 17.3.4a 47519 :22248 configuring edge-sin-5757 10.0.160.248 isr4451 17.6.3 47536 :22249 ready core-ord-5770 10.0.160.249 isr4331 15.7(3)M6 47553 :22250 ready dist-nyc-5783 10.0.160.250 cat9300 15.9(3)M4 47570 :22251 ready agg-sea-5796 10.0.160.251 nx9k 16.12.4 47587 :22252 ready spine-sfo-5809 10.0.160.252 asr1001 17.3.4a 47604 :22253 ready leaf-dfw-5822 10.0.160.253 c9200 17.6.3 47621 :22254 ready tor-lhr-5835 10.0.160.254 cat6500 15.7(3)M6 47638 :22255 ready wan-atl-5848 10.0.160.255 isr4451 15.9(3)M4 47655 :22256 ready edge-nrt-5861 10.0.161.1 isr4331 16.12.4 47672 :22257 ready core-sjc-5874 10.0.161.1 cat9300 17.3.4a 47689 :22258 ready dist-fra-5887 10.0.161.2 nx9k 17.6.3 47706 :22259 ready … 49,988 rows omitted ✓ 50,000 devices ready · avg boot 0.83ms · rss 6.4GB · fds 201,542
50,000 Cisco IOS devices·One host·Real SSH
- DEVICES
- 50,000
- MEMORY
- 6.4GB
- BOOT
- 42s
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.
Used by rConfig for load testing network configuration management platforms at scale.
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
Six engineering decisions that turn a single Linux host into a reproducible load generator for network configuration management platforms.
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 → 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
Each scenario in the repo corresponds to a real NMS failure mode we have hit in production. Pick the one that looks like the question you are trying to answer.
- Read the scenario: scenarios 5–9Scenario 01
“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: fault injectionScenario 02
“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: heavy-config skewScenario 03
“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: burst loadScenario 04
“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: reproducibilityScenario 05
“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.
How it compares to other network simulation tools
These are all good tools for different jobs. This table is about which one to reach for when the question is “how does my NMS behave at 50,000 devices?”
| 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
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 [email protected] loaded active running rconfig-sim shard (10.0.0.1) [email protected] loaded active running rconfig-sim shard (10.0.0.2) [email protected] loaded active running rconfig-sim shard (10.0.0.3) [email protected] loaded active running rconfig-sim shard (10.0.0.4) [email protected] loaded active running rconfig-sim shard (10.0.0.5) ... [email protected] 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"} 1Performance characteristics
Measured on a single Hetzner AX102 (32 vCPU / 64 GB / NVMe).
- Devices
- 50,000
- single host
- Resident memory
- 6.4 GB
- after 1 h steady-state
- Boot to ready
- 42 s
- cold start
- Average handshake
- 183 ms
- 50,000 concurrent
- Bytes per session (avg)
- 112 KB
- mixed config sizes
- Open file descriptors
- 201,542
- sustained
- Reference host
- 32 vCPU / 64 GB
- Hetzner AX102
Three commands from nothing to 50,000 devices
Each step collapses by default. Expand to see the command and what it produces.
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
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.