Skip to content
R1-MCP
▦ All products
StrandCalls R1-MCP ARRF Docs coming soon CP-MCP Docs coming soon CP Word List Docs coming soon ICX Setup Docs coming soon Probe MCP Docs coming soon SZ-MCP Docs coming soon Tangent MCP Docs coming soon NeuralRepo docs.neuralrepo.com
Get Support

Test beds

The Test Bed feature is for labs where the same physical hardware has to become a different setup on demand — a demo rig on Monday, a customer reproduction on Tuesday.

Enable it under Features in the dashboard.

A test bed is a saved set of device configurations. Swapping to one means moving the hardware you have into that state — which is more than restoring a file, because serials, ports, and stack members don’t line up between setups.

Tools: testbed_save, testbed_list, testbed_get, testbed_delete, testbed_capture, testbed_plan, testbed_apply, testbed_export, testbed_import.

  1. Capturetestbed_capture records the current state of the lab as a test bed you can return to.
  2. Plantestbed_plan works out what has to change to get from where you are to the target test bed. Read the plan before applying it; this is where a mismatch between the saved bed and the hardware actually present shows up.
  3. Applytestbed_apply executes the plan.

The Swap lab hardware to a saved test bed prompt runs this end to end and asks you for the target bed and mode.

testbed_export and testbed_import move a test bed between accounts or environments — useful for handing a reproduction setup to someone else, or keeping a bed in version control alongside the test plan that runs against it.

Two restore paths exist for switches:

  • In-place restore to startup config — the normal path for a switch that’s reachable.
  • Probe TFTP restore — for a switch that has been evicted and is no longer reachable through the controller. This uses an on-LAN probe to serve the configuration over TFTP, which is the only way back for a device that can’t be reached any other way.

Test beds pair naturally with test plans: the bed puts the hardware in a known state, and the test plan verifies behavior against it with gated expectations and 90 days of regression history.

testbed_apply changes real hardware. Run it against a lab, read the plan first, and consider enabling Write Guard so nothing mutating goes through unreviewed.