New and Changed Features in CML 2.1

New Installation Options

As with CML 2.0, you may deploy CML 2.1 as a virtual machine (VM). Deploying CML as a VM on a supported VMware hypervisor provides additional flexibility in managing your CML instance, such as snapshotting the VM for backups and managing how your hardware resources are divided between CML and other VMs in your infrastructure. This deployment option also enables you to run CML on your existing workstation or laptop instead of on a dedicated system.

New in CML 2.1, you may instead perform a bare metal installation. Choosing a bare metal installation eliminates the requirement to use a VMware hypervisor, but it requires a dedicated server for CML. This deployment option also eliminates the overhead of running the lab simulations using nested virtualization. On the other hand, bare metal installations can be more difficult to install and manage than a CML VM.

If you already have a CML 2.0 instance, you have a third option for installing CML 2.1. You can preform an in-place upgrade of your existing instance using the CML RPM file.

UI Updates

We have worked to make the HTML5 browser-based user interface (UI) more consistent and easier to use in CML 2.1. The new release uses a new framework for the UI, which provides a more modern look and feel and a richer set of UI components. The user interface is detailed in the CML User’s Guide, but here are some of the most noticeable changes since CML 2.0:

  • All pages now have a consistent navigation bar.

  • A new dark mode provides a UI color scheme with a dark background. You can toggle the Dark Mode setting on your user menu in the navigation bar.

  • The user menu also has a new Settings item. The user settings page currently just permits users to change their own password.

  • The Lab Manager is now called the Dashboard.

  • The Dashboard page now provides a field to filter the list of labs based on the lab title. The Dashboard also incorporates various improvements for the list view.

  • The system health information is shown in the status bar, which is now shown in both the Dashboard and the Workbench for all labs. To view more detailed system health information, click on the status bar.

  • To provide a more consistent location for actions, we reorganized the menus and some of the buttons. Lab actions are all in the lower pane of the Workbench. For example, the Download Lab button is now in the Simulation pane for the lab, not in the navigation bar.

Administrator Access

CML 2.1 has new features for multi-user systems. In the Dashboard, application administrators now have a Show All toggle switch that displays the labs of all users on the system. An admin can view and control other users’ labs. For example, an admin could stop another user’s lab.

In CML 2.1, non-admin user accounts cannot access or view admin-only pages, such as the System Administration or the Licensing pages. In the previous release, non-admin users could access these pages, but the admin-only pages were largely not usable. Admin-only pages are no longer shown in the menus when you are logged into the UI as a non-admin user. Attempting to directly access an admin-only page as a non-admin user will simply result in a Page not found error.

Enhanced Packet Capture

We have enhanced the packet capture feature in CML 2.1. The new functionality is available in both the UI and the APIs. This release adds or changes the following capabilities:

  • Captured packets are displayed in a summary table, which makes the key packet details easier to read and also permits you to sort by a selected field.

  • A Search field permits you to filter the packets shown in the summary table.

  • Packet decode is now available directly in the UI. The packet detail pane shows the selected packet with expandable details.

  • PCAP download permits you to download the captured packets as a PCAP file so that you can inspect the packets in greater detail with a local tool, such as Wireshark.

  • There are new API endpoints for downloading the PCAP file or even individual packets from the current packet capture.

Configuration Generation

CML 2.1 incorporates a few important improvements to the configuration generation feature. When you use Build Initial Bootstrap Configurations in the lab’s Design pane in the Workbench to generate configurations for the supported node types in your lab, CML generates a hostname for each node based on the node’s label. Because the node label can contain spaces and arbitrary Unicode characters, the node label itself may not comply with RFC 925. CML 2.1 replaces spaces with dashes and deletes non-ASCII characters from the node label to create a compliant hostname.

To prevent you from accidentally overwriting your custom bootstrap configuration for a node, CML 2.1 will no longer overwrite a non-empty configuration on a node. That is, you can safely click Build Initial Bootstrap Configurations to generate configurations for nodes that you have added to a lab without fear that any custom bootstrap configurations on other nodes will be lost. If you want to replace a node’s existing bootstrap configuration with a new one generated by CML, first clear the configuration for the node in the node’s Edit Config pane and click Save.

Configuration Extraction

We have made changes to configuration extraction to address problems observed with CML 2.0. The configuration extraction code in CML uses pyATS, and the 2.1 release incorporates a newer version of that library. There is no longer a 60-second timeout, which permits extraction of large configurations to complete successfully in the new release. Config extraction will no longer fail in the 2.1 release if an IOSv device is in config mode (conf t). In a related change, the username, password, and configuration commands are now editable fields in the node definition editor. These properties can enable config extraction when you’re using non-default credentials or trying to enable config extraction for a custom node definition. These properties are also used in the pyATS testbed creation via the API or Client Library.

Node and Image Definitions

We reworked the Node Definition and Image Definition pages to improve usability and to incorporate the changes from other features mentioned below, such as the CPU limit. The restriction against modifying built-in image definitions has also been removed, and you may now modify those image definitions.

CML 2.1 also changes the default image selection when you add a node to the lab. In CML 2.0, if you did not select a specific image for a node in your lab, CML would select an image for the node’s type when you first started the lab and the first time you start a node after wiping it. CML uses the latest image based on alphabetical sorting of images for the associated node definition. In the 2.1 release, CML will automatically set the image ID for the node as soon as you add the node to the lab in the Workbench.

Setting a specific image version for each node ensures that your lab will only boot a node if the specified image is available. You will generally only notice this change in the image specification if you export your lab and import it to another CML instance. If the other CML instance does not have the required image version available for a node, the node will fail to start. If you prefer the behavior of CML 2.0 and would like the image versions to be selected when the lab is started, you can select the node in the Workbench and set the Image Definition field to Automatic in the node’s Simulate pane. When you download the lab, the Automatic image definition is equivalent to an empty string for the node’s image_definition in the exported YAML file.

CPU Limit

You can now limit CPU resources of node VMs in your lab simulations. This property is especially useful if your CML server is resource constrained. The CPU limit restricts the amount of CPU resources a node’s VM can use. You may configure the CPU limit for an individual node or set a default limit on an image definition or even on a node definition. The CPU limit is particularly effective with node types, like IOSv, that behave well with CPU restrictions and that use a polling loop that shows a high CPU usage even when the VM isn’t processing any packets. For nodes like that, setting a CPU limit may permit you to run larger topologies on the same hardware without sacrificing much performance or stability for your lab.

Improved Launch Sequencing

CML no longer uses the average load of the system to determine whether a new node VM can be permitted to launch. In the CML 2.0 release, the launch scheduler was conservative, resulting in some cases where the CML server would not start any more nodes despite an apparent CPU capacity to run additional VMs. In the 2.1 release, CML now compares the nominal amount of CPU capacity needed to launch the next VM with the system’s CPU capacity. CML will permit the next node VM to be launched when there is sufficient CPU capacity based on this calculation. This calculation takes the CPU limits into account. For more details about the launch sequencing, see Launch Sequencing and CPU Limiting.

Device Console Access

In CML 2.0, some users observed problems with the console connection to a node becoming “hung” and not responding. We have made a few changes in CML 2.1 to address those bugs. For example, we enhanced the component responsible for accessing node consoles so that it recovers automatically in case the connection to the hypervisor disconnects unexpectedly. If you are still seeing “hung consoles” in CML 2.1, please report the problem to support. We have added additonal dynamic logging information to that component, which will help us identify any other causes of this type of problem.

APIs and Client Library

CML 2.1 provides new API endpoints and parameters to expose new functionality, such as packet capture, link conditioning, and the administrative user’s access to other users’ labs. We also added support for licensing to the Client Library to simplify the automation of CML licensing. We overhauled the Client Library documentation, including new sample code for features like licensing.

To make it easier to use the Swagger UI documentation page for the CML APIs, when you click Tools ‣ API Documentation in CML UI, the JWT token from your authenticated UI session is now automatically inserted into the API Documentation page. The page’s Authorize button will show a closed lock, indicating that the authorization has already been provided. Therefore, you should not need to use the Copy JWT item in the user menu in the CML UI just to try the APIs in the API Documentation page.