CML Virtual Labs

Cisco Modeling Labs (CML) lets you build a virtual replica, or digital twin, of a network topology using the same software images that run in production — IOS-XE, NX-OS, IOS-XR, and more. Because a CML topology speaks the same CLI, NETCONF, and REST APIs as the real devices, it can stand in for production wherever access to physical gear is the limiting factor.

For a Network as Code workflow, that’s useful in two distinct ways: as a place to get hands-on with Network as Code and apply configuration to virtual devices without needing your own lab hardware, and as a staging environment to validate a change before it reaches production.

Explore Network as Code with virtual devices

Getting familiar with Network as Code means seeing how a data model change actually renders into configuration and takes effect on a device — but that usually requires access to real hardware. A CML topology removes that dependency:

• Spin up the exact node types you want to learn on (a given IOS-XE version, a specific NX-OS platform) without waiting on hardware procurement or lab scheduling.
• Apply a data model change with Terraform and see it take effect on virtual devices that behave like their physical counterparts.
• Let newcomers explore Network as Code from a laptop, without needing shared or restricted lab access.
• Reset or rebuild the topology freely while learning, since nothing here is shared production infrastructure.

Staging changes before production

A Network as Code pipeline turns YAML into Terraform plans and applies them against real infrastructure. Most of that pipeline is deterministic and safe to review in a terraform plan, but some risks only show up once a change is actually applied — a routing loop, an ACL that blocks the wrong traffic, a template that behaves differently than expected on real device state. A CML topology gives you a place to take that risk before production does:

• Apply the same Terraform module and data model against a CML-hosted topology.
• Run the same validation suite (see Testing) against the virtual devices instead of, or in addition to, production.
• Confirm the change behaves as intended, then merge and let the pipeline apply it to production with confidence.
• Tear the topology down (or reset it to a snapshot) when you’re done, at no risk to production and no lingering lab hardware to manage.

Treating the topology itself as code

CML topologies don’t have to be built by hand. The CiscoDevNet/cml2 Terraform provider manages labs, nodes, links, and their lifecycle (cml2_lifecycle) as Terraform resources. That means the digital twin can be defined and versioned the same way as everything else in a Network as Code repository — spun up on demand for a pull request, torn down afterwards, and reproduced identically the next time it’s needed. CML also exposes a REST API directly, for teams that want to script topology creation outside of Terraform.

Getting started

• Cisco Modeling Labs documentation covers installation, licensing tiers (including a free Personal tier for individual use), node types, and the REST API in detail.
• Testing covers nac-test, which can point the same Robot Framework suites used in CI at devices running inside a CML topology.