New Features in CML 2.0

HTML5 User Interface

CML 2.0 includes a brand new HTML5 web-based user interface. CML 2.0 no longer uses the VM Maestro / CML GUI application from the 1.x releases, and users will no longer need to install a GUI application on their local machines. The HTML5 UI is much simpler to use and no longer enforces a separation between design and simulation activities. The HTML5 UI provides a graphical canvas where you can create network topologies. It uses the same Canvas Network Topology component as the Cisco DNA-C product, providing high-performance rendering in a clean interface in your web browser.

You also use the same UI to interact with the running simulation for your lab. You can access the consoles of the nodes in the simulation directly in the web interface. If the node type provides a VNC server for a graphical desktop, the UI will also provide access to the VNC connection. You can use the UI to start a packet capture in your lab and even view the captured packets in a simple view without leaving the browser. The UI also leverages capabilities provided by the new simulation engine to enable you to modify a lab while the simulation is running. You can, with some restrictions, add and remove nodes in a lab or rewire their connections without restarting the simulation.

New Simulation Engine

The simulation engine in CML 2.0 is a purpose-built middleware component and no longer uses OpenStack. While the new simulation engine still uses KVM and the same virtual machine images for the network devices, the rest of the code is brand new. The new simulation engine enables many new features in CML 2.0, including the ability to modify the topology of a running simulation. This capability enables dynamic scripting for Network DevOps tests. It can also save you time when you need to modify a lab that would take a long time to restart, such as labs that consist of hundreds of nodes, use the larger VMs, or are running on a resource-constrained system.

In CML 2.0, all labs are persistent by default. That is, when you stop a node in the network simulation, the disk image for its VM is preserved for the next boot. Therefore, the startup configuration, generated cryptography keys, and licensing information that you apply to your lab will be preserved and available the next time you restart the node or lab simulation. When you stopped a simulation in CML 1.x, all of the disk state was discarded, and each time a simulation started, nodes were booting a pristine, unconfigured VM image and applying the node’s bootstrap config. In CML 2.0, the persistent state for the nodes in the lab is not discarded unless you explicitly wipe the state. The simulation engine only applies the bootstrap configuration when a node has no associated state, which only happens the first time the node is booted or after you have wiped its persistent state.

The new simulation engine implements intelligent launch sequencing, which controls how node VMs are booted based on your hardware capacity and load. This feature should eliminate the need to stagger the launch of individual nodes manually. When you click the Start button to launch a lab simulation, the simulation engine will automatically sequence the launch of the nodes’ VMs, resulting in a more stable system. Virtual machines should no longer come up in a failed state due to resource contention during boot-up.

Improved Resource Utilization

With the new simulation engine and the elimination of the Open Stack dependencies, CML 2.0 provides new capabilities while reducing the overall resource requirements. The memory footprint of an idle CML server, when not running a simulation, has been reduced from nearly 5 GB in the 1.x releases to approximately 600 MB. The Kernel Samepage Merging (KSM) module is enabled on the CML server by default, reducing the amount of memory used by simulations that have many nodes that use the same node type and VM image. The reduced memory footprint gives you additional capacity to run larger simulations when CML is installed on a smaller system, such as a laptop.

The elimination of the Open Stack dependencies reduces complexity in the installation, upgrade, and runtime operation of the CML server. The size of the OVA has been reduced to approximately 700 MB. Virtual machine images for the bundled node types are now delivered in a separate ISO file. CML 2.0 also requires only a single network interface, reduced from the 5 interfaces required by the 1.x releases. All of these changes create a lighter and more stable system, which is important for installation, day-to-day use, and integration into a Network DevOps pipeline.

Console Multiplexing

Starting with CML 2.0, all connections to the consoles of simulated nodes pass through a multiplexer, which permits multiple simultaneous connections to the same console. Abandoned connections won’t block the console, and multiple users can view the console simultaneously. Viewing the same console simultaneously can be useful in a training, teaching, or troubleshooting environment, permitting you to view the console session of another user, assuming that you have permission to see that user’s lab. Because console multiplexing prevents console connections from being blocked, CML 2.0 no longer reserves the first network interface of each virtual machine for out-of-band management access.

There are multiple ways to access console connections, and they all use the same multiplexer. You can access the console in the HTML5 UI in your web browser, via SSH to the terminal server running on the CML server, or via a connection to the Breakout Tool. Some node types, such as Linux desktop VMs, provide a VNC server for access to the graphical desktop. The VNC connections are multiplexed in the same manner as console connections, providing concurrent access over secure, authenticated connections via the HTML5 UI or via the Breakout Tool and a VNC client application on the local machine.

External Connector

CML 2.0 simplifies external connectivity, removing the concepts of FLAT and SNAT. The 2.0 release provides a single External Connector node type instead. You can toggle the configuration of the external connector to bridge mode or NAT mode. In bridge mode, the connection of the CML server itself is shared with the simulation, whereas in NAT mode the CML server will perform network address translation from a private IP range to the network to which the CML server connects.

APIs and Programmability

We have completely redesigned the product’s REST-based web service APIs for CML 2.0. The APIs are more consistent, accepting and returning JSON data structures and using a uniform approach to error handling. The entire product is built on top of the same APIs that are available to you. For example, the HTML5 UI uses the APIs to create and modify labs and to start and stop simulations. The Breakout Tool uses the APIs to list your lab simulations and their nodes and to open connections to the nodes.

You can use these APIs to create labs and drive the entire simulation lifecycle programmatically. The new APIs provide access to fine-grained operations, such as adding a node or link. You can also use the APIs to start and stop nodes or to break connections in the running simulation, which facilitates writing Network DevOps tests of failure scenarios. The APIs are documented using Swagger UI, and the documentation is included with the product itself. Login to the UI, and on the Lab Manager page, select the menu item Tools ‣ API Documentation.

We have also released a Python client library for automating CML. The client library uses the APIs but handles the details of the web service requests so that your code doesn’t have to. It provides a higher-level Python API for you to use in automating CML. For more information about the client library, visit the client library’s PyPi page.

System Administration Cockpit

CML 2.0 introduces the System Administration Cockpit, a robust web console dedicated to system administration. The System Administration Cockpit console is based on Cockpit, https://cockpit-project.org/. It allows the administrator to manage and troubleshoot the CML server in an easy-to-use and understandable web interface. The System Administration Cockpit is not part of CML’s HTML5 UI or simulation engine: it is a separate web application that runs on the CML server. This separation allows for easier integration and more flexibility. System administrators must use this admin console to make all system changes, such as CML server IP address management, hard disk capacity, and the NTP server configuration.

By default, the System Administration Cockpit runs on port 9090 on the CML server. For example, if you access the CML UI at https://nnn.nnn.nnn.nnn/, then you would find the System Administration Cockpit at https://nnn.nnn.nnn.nnn:9090.

Smart Licensing

Starting with the 2.0 release, both CML-Enterprise and CML-Personal use Cisco Smart licensing. CML-Enterprise no longer uses PAK licenses. CML-Personal no longer uses the Cisco Salt servers for licensing. If you are a CML-Personal customer, then the Cisco Learning Network (CLN) Store allocates the Smart license on your behalf and simply provides you with auth tokens for you to use when licensing your installation. If you have a Smart license management account, you will not see the CML-Personal entitlement in your Smart Account. If you are a CML-Enterprise customer, Smart licensing works the same as it does for other Cisco products. Your CML-Enterprise entitlements will show up in your Smart Account in Cisco Smart Software Manager (CSSM), and your organization’s Smart Account administrator may subdivide the node capacity entitlements to different virtual accounts, if desired.

Smart Licensing provides three deployment options. The direct deployment option requires the CML server to have access to the CSSM servers, either directly or via an HTTP proxy server, to register and authorize the license on a CML installation. The on-prem deployment option requires you to run a CSSM On-Prem server. The CML server communicates with the On-Prem server, and the On-Prem server periodically exchanges information with cisco.com either automically in connected environments or manually in disconnected environments. The offline deployment option uses copy-and-paste information between the CML server and cisco.com to manually check in and out licenses. The functionality is equivalent to node locking, but with Smart License tracking. You can deploy CML-Personal using the direct or on-prem options. CML-Enterprise supports those two deployment options and also supports offline deployments using Specific License Reservation (SLR).

If you have an active license for 1.x, you may convert it to a smart license for the 2.0 release. For Cisco VIRL Personal Edition customers, visit your account page on the CLN Store: https://learningnetworkstore.cisco.com/myaccount. If you have a 1.x license that is still active, you should also have a license token for licensing a CML-Personal 2.x installation.

For CML 1.x customers, you will need to convert your PAK licenses to Smart entitlements for CML-Enterprise 2.x. Visit the Cisco Software Central page, https://software.cisco.com/, and follow the link to the Smart Software Licensing page. If you are unfamiliar with Smart licensing, follow the link on the main Cisco Software Central page to Learn about Smart Accounts.