In this lab I explore the use of Ansible on a networked topology simulated within Cisco Modeling Labs. By automating certain tasks we improve efficiency and reduce risk of error. Taking this approach also saves time and money by protecting against configuration drift.

What is CML?

Cisco Modeling Labs (CML) is a tool for building and testing networks in a simulated environment. In a CML topology you can test various configuration schemes for network equipment and connected edge devices like PCs and Servers. Routers and switches will run the same firmware images (albeit slightly modified) that you would find in an enterprise or datacenter environment. Additionally, the PC/servers in the topology are actually running Linux (or whatever OS you configure) virtually. This is why CML is sometimes referred to as an emulator. This being the case however, I will refer to it as a simulator from here on out for the sake of simplicity.

A network topology represented in CML

CML can be used for educational purposes, and for students, it is the next best thing to working on real hardware. In homelab scenarios where power consumption and physical real estate concerns are a reality, building out a complex topology in a virtual space can be very useful.

In real-world business use cases, a simulator like CML is perfect for testing out a topology before deploying real gear. A vigilant administrator may also create a ‘Digital Twin’ of the network already in place in order to test changes to hardware and software before applying them to the production network.

Similar products in this category worth mentioning are GNS3, EVENG, and CML’s little brother- Packet Tracer. GNS3 and EveNG are directly comparable to CML but I won’t be doing a deep dive into those offerings. Packet Tracer is a free to use simulator offered by Cisco. Since Packet Tracer is simulating and not emulating hardware, it can be less demanding on hardware but lacks professional-level features and functionality. Packet Tracer is great for educational purposes and it can also be used for building a mock-up of a real topology. This is done with less demand placed on hardware resources allowing gigantic topologies for experimenting with basic functionality.

A larger topology in Packet Tracer

Understanding Ansible

What is Ansible?

Ansible is an agentless automation tool. It can be used to automate almost anything. Ansible is a Redhat product that can be used for free or as a premium enterprise solution that incorporates Ansible Automation Platform (AAP). Although quite versatile, Ansible is probably best known for its capability to automate networking equipment, Linux, and Windows devices.

Two core concepts of Ansible are that it’s agentless (this means that no agent software needs to be installed on the devices being automated) and idempotency this ensures reliable and repeatable configurations. If you run a playbook twice it won’t break a configuration. Ansible is also great for orchestrating tasks on fleets of devices where all configurations must be uniform. Some resources for learning more about Ansible can be found here:

Jeff Geerling Ansible 101 series:

https://youtu.be/goclfp6a2IQ

Ansible Documentation:

https://docs.ansible.com/

Ansible Galaxy

https://galaxy.ansible.com/ui/

Ansible and CML in This Project

The goal of including Ansible in this project is to explore Ansible practicality with CML for simulation and digital twin scenarios. Although this is a homelab project, it certainly could be a practical business solution.

Simulation and Digital Twins

When combining Ansible automation with CML topologies we can create a virtual network running alongside an identical production network. This is a digital twin. Before pushing out new configurations or updates to the production network and possibly interrupting business operations, the virtual network can be a testing ground.

If we look at a virtual network in isolation, it would be a simulation. Simulating a network topology and configuration before production deployment can allow problems to be solved before they occur.

Ansible project that gathers information from each device in the topology

A simple playbook that checks each device for SSH connectivity

AI-Driven Log Analysis

I developed a rudimentary log analysis tool that assists the user with log and configuration parsing. It uses a local AI engine that allows the user to view and converse with log and configuration files. This is particularly useful when Ansible is gathering information from devices in this CML virtual network. It currently supports both a textual user interface TUI and a GUI interfaces running in Windows. I plan to explore this tool and concept further in future posts.

Below is the GUI interface analyzing information that was collected from the CML topology with Ansible. All LLM processing is done locally on the client’s machine.

Here you can select which device logs are to be analyzed

This is an example of conversing with log data

This project showcases the potential for leveraging Ansible automation on CML virtualized networks. While I’ve covered a few automation tasks, I’ve really only scratched the surface. Both Ansible and CML are powerful, feature-rich tools that should be explored further. As networking continues to evolve, it will become even more important to utilize emerging technologies to build resilient and self-sustaining infrastructures.

Ansible meets CML: Exploring Automation and Simulation