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.

The model

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, plus switch_config_copy and switch_config_restore_via_probe for single-switch restores.

The workflow

1. Capture — testbed_capture records the current state of the lab as a test bed you can return to.
2. Plan — testbed_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. Apply — testbed_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.

Export and import

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.

Config restore

Two restore paths exist for switches, and which one applies depends on whether R1 still holds the switch’s captured backup. R1 retains only a bounded number of backups per switch, so an old one ages out.

• In-place restore to startup config — switch_config_copy, the normal path while the captured backup is still retained. It reports the switch as restorable, and apply: true issues the R1 restore, which overwrites the startup config and reloads the switch — roughly ten minutes offline.
• Probe TFTP restore — switch_config_restore_via_probe, for a switch whose backup has aged out of R1. That state is reported as evicted, and once it happens the in-place restore is gone: R1 has no API to re-inject a config. This path carries the durable copy back onto the box over a TFTP download served by an on-LAN probe, then reboots the switch onto it. It needs a linked Probe MCP account and a probe on the same LAN as the switch.

Both default to a preview: without apply: true they report what would happen and change nothing.

Working with test plans

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.

A caution

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.