Streamlining Console Access in Cisco Modeling Labs

Cisco Modeling Labs (CML) is an on-premises network simulation tool that runs on workstations and servers. With Cisco Modeling Labs, you can quickly and easily simulate Cisco and non-Cisco networks, using real Cisco images. This gives you highly reliable models for designing, testing, and troubleshooting.

Out of the box, CML allows four methods for accessing the console of devices in a lab:

The In-Lab Console Access

Using the console access from the CML UI is slow and does not allow for quickly switching between devices. The process involves clicking on the desired device, clicking the "CONSOLE" tab from the menu below the topology, and then clicking the "OPEN CONSOLE" button. The good news is that the console tab will remain open for each subsequent device you select from the topology. You just have to click that button to open the console the first time for each.

This has gotten a lot better as of 2.6, but it is still not as versatile as a dedicated external terminal emulator.

The Breakout Tool

This is the gist of what Cisco's documentation says about the Breakout Tool:

The tool acts like a a local terminal server that embeds the various serial ports / lines into an single HTTPS connection to the control server. Console access is done via Telnet and the graphics framebuffer is accessed via the VNC protocol.

The CML 2 Breakout Tool allows for users to use their favorite external terminal emulator like Putty, Kitty, SecureCRT, etc. to devices running inside a topology on a CML 2 server.

Using this is... a process. It's not difficult to use, but more trouble than I care to deal with when doing lab work. It does allow you to use your "favorite external terminal emulator", but you must have it running in order to do so. Hopefully, you can remember to do that every time you start a lab. There are other issues with it that I won't get into here that are just annoying.

The PATty Tool

Dear God, why?

The Console Server

Cisco's description of the console server:

CML includes a built-in console or terminal server which provides CLI based access to consoles of network nodes running in a topology. The terminal server uses SSH as the transport protocol and requires authentication using the same credentials as the web user interface.

The console server is the MVP here. It is always running and you can use any SSH client to access lab devices. That means PuTTY, SecureCRT, etc. are on the table. This is, by far, the most useful feature in CML for me.

Unfortunately, out-of-the-box console access is a weak point for CML if you're a professional who's used to his terminal emulator of choice (SecureCRT, in my case). This was THE issue that put me off of using CML (which I bought) for the longest time. Something had to be done, and the console server was the key to it.

Project: SecureCRT Session Generator for Cisco Modeling Labs

Introduction

This is my solution to the console problem. The purpose of this project is to make console access to devices in CML more convenient by allowing users to automate the creation of SecureCRT session files. It's a terminal-based utility written in Python and it leverages a couple of CML's REST APIs and the built-in console server.

How it works

The CML server IP/name and user credentials are stored in a file called "config.yaml" within the working directory (this file only exists after setup)
The script (session_gen.py) looks for config.yaml
An API call is made to the server listed in the configuration file to validate the credentials and to retrieve an API authentication key for future API calls
Another API call is made to get the list and the state of all labs belonging to the user listed in the config.yaml file
The list is enumerated and displayed to the user
The user is prompted to select a lab by its corresponding number in the list
Once selected, the session files are generated for each node/device in the lab and the script ends
Close the terminal window (optional)
The new sessions will be found in the Session Manager within SecureCRT

Note: If there is a failure at any point during Step 2 or 3, the setup routine is started in order to resolve it.

Key Benefits of This Solution

Speed. Labs with 20+ nodes can have sessions generated in less than 1 second
Organization. It creates a directory structure to neatly organize sessions by setting the CML server name or IP address as the parent directory and setting the lab names as subdirectories
Proper Naming. The session files are named the same as the devices/nodes in the labs which means the tab for each device in SecureCRT will also be labeled properly (i.e. "Router1" in the lab with be labeled as "Router1" in SecureCRT)
Automatic Login. The initial setup makes it possible to save the user credentials for each device so that login is automatic
Only Run When Needed. This tool does not need to be running in order for console sessions to function within SecureCRT

Getting Started

The project can be found here on GitHub.

The README for the project has information on requirements, installation, setup, and usage. There is also an animated GIF demonstrating usage.

Bruce Does Tech