Testing network infrastructure changes directly in production is a gamble that rarely pays off. New Relic's 2025 Observability Forecast puts the median cost of a high-impact IT outage at $2 million per hour, and lists network failure and deploying software changes among the top three causes, alongside third-party provider failures. Those numbers describe what is at stake when a change goes wrong, and a virtual network lab gives you somewhere else to find out whether a change does what you intended: an environment running real network operating system images where you can rehearse the change, watch it fail, and fix it before the maintenance window. Seven steps take a change from a written objective to a deployment backed by evidence, and they work the same on any competent lab platform.
Emulation is faithful to configuration syntax, routing protocol behavior, and path selection. It does not reproduce ASIC forwarding, line-rate throughput, or hardware timing. A rehearsal therefore validates a change's logic and sequence; timing numbers, capacity limits, and forwarding performance still need hardware evidence. Every step below respects that line.
Rehearsing one change in a lab is one piece of a larger discipline. If your team's change process itself is the problem (untracked changes, no auditable procedure, no CI/CD for network operations), start with why network changes keep breaking production. If you do not have a lab yet and are weighing self-hosting against a managed platform, the platform selection guide covers that decision. Everything below assumes you have a lab and a change to rehearse: you will scope the test, build the topology, run the change, break it on purpose, and write down what happened.
Write down exactly what you need to validate before you build anything. "Test the BGP change" is not an objective; "confirm that outbound traffic prefers the new transit path, and that it returns to the primary when the link recovers" is. Each change type implies different criteria:
| Change type | Verify in the lab | Leave for hardware or the change window |
| Routing policy update | Traffic takes the intended path; no unexpected route leaks; failover selects the backup path and recovers | Convergence times under real load |
| Firewall policy change | Existing rules still pass and block as before; rule evaluation order and NAT behavior | Session capacity limits; HA state-sync timing |
| VLAN or segmentation restructure | Hosts land in the right segments; inter-VLAN routing works as designed; trunks carry the intended VLAN lists | Spanning-tree reconvergence and timer behavior on trunk failure, which emulation does not reproduce faithfully |
| Automation rollout | Playbook produces the intended config on every target; partial-failure handling: what state devices are left in if the run dies halfway | Anything the playbook reads from hardware state (optics, ASIC counters) |
The split in the last column is not optional fine print. Objectives written as timing numbers or capacity figures cannot be signed off in emulation, so write them as separate hardware-stage checks from the start rather than discovering the gap during review.
Document your rollback plan at the same time. If the rehearsal reveals problems, you want a known-good state to return to in the lab, and the production rollback procedure deserves the same rehearsal as the change itself.
The environment needs to run the same network operating systems as your production devices — or, more precisely, their virtual equivalents, since a virtual image can differ from the hardware platform in build, feature set, and license tier — at a scale large enough to carry the whole slice of topology the change touches. This is where a laptop installation usually gives out first. Enterprise topologies with multiple heavyweight images consume more memory and CPU than local machines have to give, and a lab that cannot hold the full slice forces you to cut segments the change actually interacts with.
| Option | What it gives you | What it costs you |
| Emulator on a workstation | Free to start; fine for one engineer and small topologies | Memory and CPU limits arrive early; sharing it means hosting it yourself |
| Self-hosted (your servers or cloud VMs) | Real capacity; full control over the stack | Your team patches, sizes, and maintains the lab platform on top of its day job |
| Managed platform | Provisioned capacity (virtual machines or bare metal servers), maintained by the provider | Subscription cost; you are trusting an external operator |
Emulation fidelity is the same in every row; the table is about capacity, upkeep, and sharing, not about how faithful the lab is. CloudMyLab sits in the managed row: hosted EVE-NG, GNS3, and CML 2.0 managed by certified engineers with 24/7/365 priority support, the ability to upload your own device images, and licensing assistance when you need images purchased. Your team keeps the lab content (images, topologies, reservations) and sheds the platform administration. Which emulator fits which job is its own question; EVE-NG vs GNS3 covers the trade-offs.
One boundary to respect regardless of option: image licensing stays your responsibility. Vendor operating system images come with their own entitlement terms, and a provider can purchase licenses on your behalf, but it does not own the obligation for you.
You do not need every device. You need the segments the change touches, plus every device that interacts with the change: the core routers whose policy you are editing, enough of the distribution layer to carry test traffic, and the firewall or load balancer that sits in the affected path. Slice by scope, not by fidelity: include fewer segments, not thinner versions of the segments that matter. Mapping that slice is easier when your topology documentation is current; when it is not, building the lab is often what exposes the gap.
Start from configuration exports pulled from the production devices themselves, not from your documentation, and sanitize them before they leave your environment. Replace production secrets (SNMP communities, TACACS and RADIUS keys, VPN keys, local credentials) with lab-only ones rather than deleting them, since a device with no credentials is a device you cannot log into. Then retarget or disable every management-plane destination that points at production: AAA servers, syslog and SNMP receivers, NetFlow exporters, NTP sources. The point of both moves is the same: the lab must hold no production secrets and have no path to production systems, because an externally hosted lab with either is an incident of its own. The reason to start from exports rather than documentation is drift: ad-hoc fixes accumulate, and the documented config quietly stops matching reality. A lab built from documentation rehearses the configuration you think you run; a lab built from device exports rehearses the one you actually run, and that difference is where changes break. Expect translation work either way. Virtual images use different interface names than your hardware, hardware-specific commands will not paste across, and routing metrics need deliberate alignment: virtual images default to different interface bandwidths than your 10G, 25G, or 100G hardware, so OSPF costs and EIGRP metrics computed from them will point traffic down different paths unless reference-bandwidth and interface bandwidth values are set to match production. Record every adaptation you make, because each one is a place where the rehearsal diverges from the real change.
Large infrastructure changes involve architects, automation engineers, and operations staff at the same time, and a shared lab without ground rules produces its own outages — the classic being an engineer who resets a topology mid-test because nothing said it was in use.
The practices are unglamorous and effective: per-engineer copies of the topology where the platform supports cloning, naming conventions that make ownership obvious, a reservation note for shared topologies, and a shared document tracking who is testing what. On the platform side, multi-user separation is an edition question: EVE-NG, for example, offers per-user lab instances in its Professional edition (license-dependent), not in the free Freemium mode. For teams that want the environment run for them, CloudMyLab's Lab as a Service comes with a dedicated account manager and secures remote access with Cisco AnyConnect VPN and DUO multi-factor authentication, giving a distributed team one secured entry point to the same lab.
Apply the change to the lab as close to the production procedure as the images allow: the same sequence, the same scripts, the same automation playbooks. Where the lab forces a difference, such as a virtual image's interface naming or a hardware-only command, adapt deliberately and note it, because an adaptation you made silently is a divergence nobody will remember during the maintenance window. Rehearsing a quietly cleaned-up version of the change validates the cleaned-up version, and the syntax error you removed for the rehearsal will still be waiting in the real one.
Then break things on purpose. Pull the primary link and watch whether path selection shifts the way step 1 said it should. Fail the HA pair and verify the configuration sync and failover sequence. Kill the automation run halfway and inspect what state the devices are left in. In the lab these drills cost engineer time; in production they cost the outage. A change that only works when everything goes right has not been tested.
Generate test traffic to confirm reachability and path selection, with the boundary from the introduction in mind: path selection is production-representative in emulation once routing metrics are aligned as in step 3, while forwarding performance and behavior under real load are not.
Compare what happened against the objectives from step 1, line by line. Did traffic follow the intended path? Did the failover sequence behave as the objective described? Did anything unexpected appear in the device logs — a flapping adjacency, an error counter, a log message you cannot explain? An unexplained anomaly in the lab is a finding, not a footnote, though it deserves one diagnostic question first: is this the change misbehaving, or an emulation artifact? Reproduce it twice before rewriting the change over it.
Capture the evidence while the lab is still up: command outputs, log excerpts, before-and-after routing tables. The record serves three audiences at once: the change advisory board that wants proof the change was rehearsed, the on-call engineer who wants a known-good reference if production misbehaves, and the colleague who runs a similar change next quarter. This is also the artifact that plugs the rehearsal into the wider change management process rather than leaving it as a private exercise.
If the rehearsal surfaced problems, fix the change in the lab and run the scenarios again. Iterating is the point: every real defect found here is one that does not ambush you in the maintenance window. When the results match the objectives, deploy to production using the procedure you rehearsed, with the noted lab-to-production adaptations applied in reverse. The rehearsal does not make production risk-free (hardware behavior, scale, and live traffic remain untested by design), but you are now executing a procedure you have watched work, with evidence attached, instead of improvising one.
Keep the lab topology available for a while after the production change lands. If something surfaces days later, you can reproduce it in the lab, test the fix, and rehearse the correction the same way you rehearsed the original change, instead of debugging live.
Everything above works on any competent lab platform, including one you host yourself. A managed platform changes who carries the infrastructure: CloudMyLab runs the hosted emulators with 24/7/365 priority support and no long-term contract, and its automation environment comes pre-built with Ansible, a GitLab Community Edition server, and ready-made playbooks for teams rehearsing automation rollouts. For enterprise context beyond change rehearsal (use cases, procurement framing, team training), see cloud network labs for enterprises.
If you want to try the workflow against one of your own upcoming changes, a free trial is the shortest path to finding out whether the rehearsal habit fits your team.
There is no hardware procurement: the provider already runs the compute, and your environment is provisioned on existing infrastructure. The realistic timeline depends on your topology's complexity and on image licensing, where sourcing vendor entitlements can take as long as any procurement cycle, so treat set-up time as a question to ask a provider about your specific topology, not a given.
Yes, through the emulators themselves. EVE-NG and GNS3 are vendor-agnostic and run images from multiple network vendors in one topology, where licensing allows, so you can rehearse a change across your actual vendor mix rather than a single-vendor approximation. The images come from your own entitlements. Bring your own images is the standard model, with purchasing assistance available.
It removes the single-workstation bottleneck: the lab lives on shared infrastructure that every engineer reaches remotely, instead of on one person's machine. Per-user separation depends on the platform edition (EVE-NG offers per-user lab instances in its Professional edition) and on working practices like per-engineer topology copies and reservation notes. Managed Lab as a Service engagements add secured access through Cisco AnyConnect VPN with DUO multi-factor authentication.
Resources, upkeep, and multi-user support. A local installation is limited by your machine's memory and CPU, and EVE-NG's free Freemium mode allows 7 nodes with admin-only access, and the admin-only part is what rules out real team use. A managed platform provisions capacity for you on virtual machines or bare metal servers, handles patching and platform maintenance, and offers EVE-NG Professional hosting for per-user lab instances. The hosting model and the edition are separate choices — a team can also license Professional on its own hardware. What does not change is the image licensing model: your device images, your entitlements, in both cases.
By moving failure discovery somewhere it costs engineer time instead of downtime. New Relic's 2025 Observability Forecast puts the median cost of a high-impact IT outage at $2 million per hour, with network failure and software changes both among the top three causes. Not every production defect becomes that outage, but the ones that do are why rehearsal discipline exists. A change rehearsed in a virtual network lab has had its logic exercised against link loss, failover sequences, and partial automation runs before the maintenance window, which shrinks the class of surprises left for production, even though hardware-dependent behavior still needs its own validation.