Finally, after weeks of waiting, I could test the successor of the famous VIRL – the Cisco Modeling Labs 2.0. Earlier, the product was known under the working name VIRL2, but it was finally renamed as CML 2.0. Yes, I know. There are already a lot of reviews on the web, both written or in the form of video. Unfortunately, I am not a Cisco employee to have access to internal versions for a long time, or user of the Enterprise version that was released a month earlier and due to the price probably not available for many companies. Fortunately, CML 2.0 Personal is out, and I had the opportunity to take a look at it. This is my first impression. There are a few things that I think deserve attention (this is not a complete list for sure).

This article has been originally posted on my polish blog Szkoła DevNet (DevNet School)

CML 2.0 installation

The first thing that catches the eye is how you install CML 2.0. First of all, it is not possible to install the Personal version as a native operating system (bare metal). In the package, we only get a virtual machine image in OVA format and an ISO file containing images of virtual network devices that we need to connect to the created virtual machine. A bit unusual, but it doesn’t bother me, it only hinders the potential of moving a virtual machine between servers. Moving, because at the moment neither Personal nor Enterprise versions support clustering. VMware products are the only supported hypervisor. Home users don’t have to worry – Player, Workstation or Fusion versions are enough. Installation and commissioning take only a few minutes.

Of course, CML 2.0 does not work without a license – we need to download the token from our account on cisco.com, enter it in the appropriate field, and activate it.

The GUI

The entire CML 2.0 interface has been rewritten. To manage the system itself, we get a graphic System Maintenance Controls console that listens on port 9090. The simulation GUI is available on port 443. The VM Maestro application has been completely withdrawn, and we manage the simulation through a browser using a transparent HTML5 interface. We can see the level of resource consumption assigned to the virtual machine on an ongoing basis, managing simulations is straightforward, adding devices also. And unfortunately, the positive impressions end here.

In my opinion, the person responsible for interface design should be sent to the course about how to create graphical application interfaces. Here are the major mistakes made when creating the interface:

• The mouse on each device has at least two buttons. It is a mystery to me why the context menu is not implemented in the GUI. Clicking with the right mouse button on an object or workspace is a natural reflex of every person working at the computer. Many actions that now require a few clicks, for example, opening a connection to the console, could close in two. No context menu is hugely frustrating.
• Creating a connection between devices is extremely unintuitive. You need to select the device, click the small icon above it and hold to drag the connection, and finally choose the ports. It is so unintuitive and inconsistent with the entire interface that I had to look into the documentation on how to perform this essential task.
• All device parameters or connections are entered in a dedicated window at the bottom of the simulation. You could be a pop-up context window, instead yo you have to move your mouse a lot.
• Contextual hints are poorly designed, and it is often impossible to read their contents.

API in CML 2.0

Luckily, CML 2.0 also has an API. It allows you to do all the work bypassing the GUI. Well-structured API documentation built using Swagger is available. Thus, directly from the documentation, we can check the operation of specific methods. A Python library is also available. We can install it both from the .whl file available in the CML 2.0 installation and from the PyPi repository. Let’s always pay attention to the version – currently, in PyPi we will find an older edition of the library.

In Ansible Galaxy we will find modules for Ansible, which will allow us to create playbooks. I hope that now after separating the modules from the main part of the Ansible project, which I wrote about recently, Cisco will submit the modules to the official collection.

Where is the configuration generator?

He’s not here. And this is next to the little functional GUI my biggest surprise. At Cisco VIRL, one of the biggest advantages was that you could quickly generate a working topology. We set up devices, connected them, set parameters such as AS number, routing protocol, VRFs individually or for groups and clicked one button. Interface IP addresses and many parameters were generated automatically. All you had to do was run the simulation and you had a fully functioning test network.

In CML 2.0, the automatic building of the initial configuration is limited to giving descriptions to the interfaces, their activation, and cisco/cisco user settings. And that’s it.

I don’t know what the idea was for the creators. One of the best features of VIRL has been removed from the product. Of course, you can write the configuration, you can write scripts, you can use the provisioning tools thanks to the API, only this takes time, and not everyone has such knowledge.

Summary

Maybe I will change my mind, but after 4 hours of work with the CML 2.0 I am … maybe not totally disappointed, but very disappointed. I expected a step forward, and I did not know exactly what. A bit like a product that was developed without any customer satisfaction survey. I do not suspect that I would be any special and unusual customer.

There are still some functionalities that I haven’t thoroughly checked out and looked promising. Among other things, better integration of external solutions, or just the use of API. I will write about them soon. However, so far, my rating is 5/10.

CML 2.0 costs just like VIRL $ 199 for an annual subscription that can be purchased here.