- Overview
- Product Documentation
- CML Release Notes
- Getting Started
- CML 2.1 User Guide
- CML User's Guide
- Overview of CML 2.x
- Using CML and the HTML5 UI
- Dashboard
- Workbench
- Adding Nodes to a Lab
- Starting, Stopping, and Wiping Nodes
- Deleting Nodes
- Creating Links
- Rules for Creating Links and Interface Overprovisioning
- Adding Interfaces and Overprovisioning
- Overprovisioning Interfaces with Link Creation
- Starting Simulations
- Connecting to a Node's Console
- Setting CPU limit on node
- Launch sequencing and CPU limiting
- Stopping Simulations
- External Connectivity for Simulations
- Link Packet Capture
- Breakout Tool
- Custom VM Images
- Creating a New Node Definition
- CML 2.1 Admin Guide
- Resources
Known Issues and Caveats for CML 2.1¶
Bug Description |
Notes |
|---|---|
Deleting a CML VM without deregistering first leaves the license marked as “in use.” New instances indicate that the license authorization status is out of compliance. |
If you have deleted or otherwise destroyed a CML instance without deregistering it, then the Cisco Smart license servers will still think that instance’s licenses are in use. Workaround 1 - Before you destroy a CML instance, follow the Licensing - Deregistration instructions to deregister the instance. Properly deregistering an instance before destroying it will completely avoid this problem. Workaround 2 - If you have already destroyed the instance, see the instructions for freeing the license in the CML FAQ. |
If the image associated with a node is not available, attempting to start the node will cause it to get stuck in a Queued state. |
The node will be listed in the Nodes pane of the Workbench with a Queued state. Since the associated image is not available, it cannot successfully start, but it may fail to move to stopped state when you stop the lab. Workaround 1 - Before starting a lab, ensure that the images associated with each node are available. Workaround 2 - Once you start the lab, and the nodes are stuck in Queued state, you may need to use the Force Wipe Lab button on the Simulate pane of the lab in the Workbench. Note that using Force Wipe Lab will stop the lab, and all state associated with the nodes in the lab will be lost. |
The CML UI is no longer available, and the virl2-controller service fails to start, after installing OS updates on the CML server. |
CentOS 8.3 was released in December 2020, and it introduces some changes that could leave your CML server in an unusable state. If you apply OS Updates on your CML server, either it will install software that causes the virl2-controller service to crash immediately on restart, or it will leave your system in a state where the future updates cause this problem. Resolution - CML 2.1.2 is compatible with CentOS 8.3. To resolve this issue, upgrade to CML version 2.1.2 or later. If you cannot upgrade your CML server at this time, you can use one of the following workarounds. Workaround 1 - Refrain from running OS updates on your CML server via the System Administration Cockpit or the Workaround 2 - If you recently upgraded your system, especially if the UI is not available after restart, and the virl2-controller service fails immediately on restart, first check to see whether you have the CentOS 8.3 updates. Log into the System Administration Cockpit with your browser, and click Terminal in the navigation bar. Run this command: cat /etc/redhat-release
If it indicates CentOS release 8.3, then you already have the problematic udpates installed. Check the support channel for your product to see whether there are any recent updates or manual workarounds. Otherwise, you should roll back to the snapshot or backup of your CML server from before the OS updates were applied. |
Bug in OS X Big Sur. After upgrading to OS X Big Sur and VMware Fusion 12.x, simulations no longer start. |
Big Sur introduced changes to the way OS X handles virtualization. While VMware Fusion 12 works with the new changes in OS X Big Sur, there is a bug that impacts some Apple systems. On those systems, after you upgrade the host OS to OS X Big Sur, labs will not start, and nodes just stay in QUEUED state. While not all systems exhibit this problem, we currently recommend that all CML customers remain with OS X Catalina until Apple and VMware fix this bug. Workaround 1 - Do not upgrade to OS X Big Sur. Continue running the CML VM on OS X Catalina and Fusion version 10+. Note that CML appears to work correctly with Fusion 12 as long as the host OS is OS X Catalina. Workaround 2 - If you already upgraded to Big Sur, and you experience the specified symptoms, then you may need to roll back your entire system to the last backup before you upgraded to Big Sur. |
Stopping a node’s VM in a lab simulation through any means other than the stop node functionality in the
CML UI or APIs will cause a loss of console access to all nodes in all labs (for all users), and there is
the possibility that connections between nodes within running labs will also be lost. For example, stopping an
Ubuntu node by running |
Workaround 1 - Do not stop or suspend simulated nodes from within the node’s operating system. If you need to stop a node in the simulation, stop it from the CML UI or APIs. In particular, if you use custom Microsoft Windows nodes in your labs, the image may have a default setting to power off after 10 minutes. Check that all custom images in your CML server are _not_ configured with an automated power management setting that will cause a node’s VM to power off or hibernate after a specific period of time. Workaround 2 - If you encounter this situation, stop all impacted labs. For each lab, once it is stopped, wipe the lab and then force wipe the lab. Warning: this step is destructive. When you wipe the lab, you will lose all state associated with the lab other than the lab topology and the bootstrap configuration in the Edit Config tab in the Workbench. In the System Administration Cockpit, click CML2 in the navigation bar, expand the Restart Controller Services group, and click the Restart Services button. Once the services have resarted, you should be able to log into the CML UI and run your simulation again, and console access to the nodes will be working again. |
Vulnerabilities in nginx-1.14. |
Symptom - All versions of CML 2.x before 2.1.2 include a version of nginx that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
Conditions - Installation with default configuration. PSIRT Evaluation - The Cisco PSIRT has assigned this bug the following CVSS version 3 score. The Base CVSS score as of the time of evaluation is 7.5: https://tools.cisco.com/security/center/cvssCalculator.x?vector=CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE IDs CVE-2019-9511, CVE-2019-9513, and CVE-2019-9516 have been assigned to document this issue. Additional information on Cisco’s security vulnerability policy can be found at the following URL: https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html Resolution - To resolve this issue, upgrade to CML version 2.1.2 or later. |