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
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
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 ConnectorCML 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.
With the Breakout Tool, you can use your favorite terminal emulator app to connect to
your nodes' consoles on configurable local ports. In the 1.x release, each node's
console was normally exposed as another open port on the CML server itself. In CML 2.0, all console connections pass through the
console multiplexer. If you don't want to access consoles in the web interface or
via an SSH terminal server, you can run the Breakout Tool on your local machine to
authenticate to the CML server and create an encrypted
connection to the console multiplexer. You can configure the Breakout Tool to expose
some or all of your nodes' consoles locally. You can also configure specific ports
for each lab and node, providing a consistent set of ports for a particular lab's
nodes that does not interfere with the settings used by other users of the same CML server. The Breakout Tool provides access to
console, AUX, and even VNC connections.
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
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,
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
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.
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.
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.