How to Use Cisco Modeling Labs

Cisco Modeling Labs (CML) is Cisco’s premier network simulation platform, delivering an authentic virtual sandbox powered by real Cisco IOS-XE, NX-OS, IOS-XR, and ASA software images. Whether you are preparing for Cisco certifications like CCNA, CCNP, or CCIE, or testing complex automation scripts against virtual network topologies, CML replaces stacks of noisy physical hardware with an agile, software-driven lab environment.

Running CML effectively requires an understanding of procurement, hypervisor sizing, deployment steps, and day-to-day topology orchestration. This end-to-end guide walks you through every stage: acquiring the proper license, verifying hardware specs, deploying the virtual appliance, crafting your first network topology, connecting virtual nodes to the live internet, evaluating CML against competing emulators, and leveraging official Cisco documentation.

Acquiring a Cisco Modeling Labs License and Software Images

Before provisioning virtual machines or assembling topologies, you must obtain an authorized license subscription and download the installation media from Cisco.

Step 1: Choose Your Subscription Tier

Cisco offers several licensing tiers tailored to individual study or enterprise teams:
* CML Personal: Designed for individual engineers and certification candidates. It supports up to 20 concurrent virtual nodes.
* CML Personal Plus: Expands concurrent capacity to 40 nodes, suitable for large CCIE enterprise infrastructure simulations.
* CML Enterprise / Education: Multi-user, role-based licensing designed for corporate teams, higher education labs, and training centers with centralized administration and flexible node scaling.

Step 2: Purchase Through the Cisco Learning Network Store

1. Navigate to the official Cisco Learning Network (CLN) Store.
2. Select Cisco Modeling Labs – Personal or Personal Plus.
3. Complete the checkout process using your Cisco.com (CCO) credentials. Subscriptions are billed annually.

Step 3: Download the Required Software Packages

After purchase confirmation, open your order history in the CLN Store or log into Cisco Software Central to download two essential files:
1. The CML Base Virtual Appliance: Download the .ova file (for VMware Workstation, Fusion, or ESXi) or the .iso file (if performing a bare-metal installation on dedicated server hardware).
2. The Reference Platforms and Images (Refplat) ISO: A large image file (often 20 GB to 30 GB) containing the virtual software images for Cisco IOSv, IOSvL2, NX-OSv, IOS-XRv, ASAv, CoreOS, and Ubuntu desktop nodes.

Step 4: Retrieve Your Smart Licensing Token

In your CLN Store account, navigate to the My Account section and open the Cisco Modeling Labs dashboard. Copy the alphanumeric registration token provided for your subscription. Keep this token accessible, as you will bind it to your installation to unlock node execution.

Key Takeaway: Securing both the base OVA appliance and the complete Reference Platform ISO during procurement ensures you have all required network operating system images ready for deployment without secondary downloads.

Hardware and System Requirements FAQ

Because CML runs genuine virtual machines inside a nested KVM hypervisor on Linux, allocating adequate host compute capacity is vital for stable simulations.

What are the minimum and recommended hardware specifications for CML?

• Minimum Specifications (Light labs up to 5–8 lightweight nodes):
• CPU: 4 physical x86_64 cores with virtualization extensions (Intel VT-x or AMD-V).
• RAM: 16 GB of physical host memory (at least 12 GB dedicated to the CML VM).
• Storage: 40 GB free disk space for the base system, plus an additional 35 GB for reference platform images.
• Recommended Specifications (15–20+ nodes, including NX-OS and XRv):
• CPU: 8+ physical cores (16 threads), such as modern Intel Core i7/i9, AMD Ryzen 7/9, or Intel Xeon/AMD EPYC.
• RAM: 32 GB to 64 GB of physical host memory (allocating 24 GB to 48 GB directly to the CML VM).
• Storage: 150+ GB of fast solid-state storage (NVMe SSD recommended) to handle concurrent disk reads during node boot storms.

Which hypervisors and host platforms are officially supported?

CML is packaged as an x86_64 appliance running Ubuntu Linux with kernel-based virtualization (KVM). Supported environments include:
* Type-2 Hypervisors (Desktop): VMware Workstation Pro / Player on Windows and Linux; VMware Fusion Pro on Intel-based macOS.
* Type-1 Hypervisors (Bare-Metal): VMware ESXi (version 6.7, 7.0, 8.0, and newer).
* Bare-Metal Installation: Direct ISO installation on dedicated x86 server hardware without an intermediate hypervisor layer.

Can Cisco Modeling Labs run natively on Apple Silicon (M-series) Macs?

No. CML virtualizes x86_64 machine architectures through KVM. Because Apple Silicon (M1 through M4 chips) utilizes ARM64 architecture, VMware Fusion on Apple Silicon cannot provide hardware-assisted nested x86 virtualization. Mac users with Apple Silicon hardware should deploy CML to a remote bare-metal server, an ESXi host, or an x86 cloud compute instance and access the CML web dashboard through their Mac browser.

How much memory does each virtual node require?

Memory overhead varies significantly by platform:
* Cisco IOSv (Layer 3 Router): ~512 MB RAM, 1 vCPU
* Cisco IOSvL2 (Layer 2 Switch): ~1024 MB (1 GB) RAM, 1 vCPU
* Cisco ASAv (Firewall): ~2048 MB (2 GB) RAM, 1 vCPU
* Cisco CSR 1000v / Catalyst 8000v: ~3 GB to 4 GB RAM, 1–2 vCPUs
* Cisco NX-OSv 9000: ~8 GB to 10 GB RAM, 2 vCPUs
* Cisco IOS-XRv 9000: ~16 GB to 20 GB RAM, 2–4 vCPUs

Why is nested virtualization required, and how is it enabled?

CML operates as a virtual machine that itself spawns child virtual machines (the simulated routers and switches) using Linux KVM. Without nested virtualization, the host hypervisor blocks the CML virtual machine from exposing hardware virtualization CPU instructions. In VMware Workstation, this must be explicitly enabled by checking Virtualize Intel VT-x/EPT or AMD-V/RVI under the VM processor settings before initial boot.

Key Takeaway: Adequate physical RAM and enabling nested hardware virtualization in your hypervisor are absolute prerequisites for launching multi-node network simulations.

Deploying and Configuring the CML Virtual Appliance

Once your hardware meets the prerequisites, deploy the appliance, configure base networking, and initialize the underlying Linux subsystem.

Step 1: Import the CML OVA

1. Launch VMware Workstation, Fusion, or your ESXi vSphere Client.
2. Select File > Open (or Deploy OVF/OVA Template) and select the downloaded CML .ova file.
3. Assign a name to the virtual machine and choose a fast storage datastore.
4. Before powering on the VM, open its hardware settings:
5. Allocate CPU cores (minimum 4 cores, recommended 8+).
6. Ensure nested virtualization flags are enabled (Virtualize Intel VT-x/EPT or AMD-V/RVI).
7. Allocate RAM (e.g., 16 GB to 32 GB).
8. Set Network Adapter 1 to Bridged (to place CML directly on your local LAN) or NAT (to use your host machine’s IP sharing).

Step 2: Mount the Reference Platform ISO

1. In the VM settings, locate the virtual CD/DVD drive (or add a secondary virtual CD/DVD drive).
2. Point the drive to the downloaded Reference Platform .iso file.
3. Check the box to ensure Connected at power on is selected.

Step 3: Run the Initial Console Setup Wizard

1. Power on the virtual machine and open its console display.
2. The system will boot into the initial text-based configuration wizard.
3. Accept the End User License Agreement (EULA).
4. Define your administrator credentials:
5. System Administrator (sysadmin): Used for host-level Linux administration and Cockpit.
6. Initial CML User (admin): Used to log into the primary HTML5 lab interface.
7. Configure network settings: Select DHCP for automatic IP allocation or configure a Static IPv4 Address, subnet mask, default gateway, and DNS servers.
8. When prompted to copy the reference platforms, confirm the copy operation from the mounted ISO to local disk, or select to mount the ISO live.

Step 4: Verify Subsystem Status via Cockpit

CML runs the Cockpit administrative console on port 9090 for Linux system maintenance:
1. Open a browser and navigate to https://<cml-ip-address>:9090.
2. Authenticate using the sysadmin account created in Step 3.
3. Verify that CPU, RAM, and disk storage are recognized, and confirm that the cml2 system services are running without system-level errors.

Step 5: Authorize Your CML License

1. Open a web browser and navigate to the main CML interface at https://<cml-ip-address>.
2. Log in with the admin credentials.
3. From the top navigation menu, go to Tools > Licensing.
4. Click Register or Change Token.
5. Paste the Smart Licensing token retrieved from your Cisco Learning Network Store profile.
6. Click Register. After a short synchronization period with Cisco’s licensing servers, the status will shift to Authorized / In Compliance, unlocking full node execution.

Key Takeaway: Proper initial configuration via the text console paired with licensing verification in the web interface establishes a stable management foundation for running labs.

Building Your First Network Topology: A Step-by-Step Guide

With licensing active and the appliance running, you can create, link, boot, and configure simulated devices within the HTML5 workbench.

       +-----------------------+
       |   CML Web Interface   |
       | (Workbench Dashboard) |
       +-----------+-----------+
                   |
            [ Add New Lab ]
                   |
                   v
       +-----------------------+
       |   Drag & Drop Nodes   |
       |  (IOSv, IOSvL2, PC)   |
       +-----------+-----------+
                   |
                   v
       +-----------------------+
       | Connect Interfaces    |
       | (Gi0/0 <----> Gi0/0)  |
       +-----------+-----------+
                   |
                   v
       +-----------------------+
       |   Start Simulation    |
       |  (Boot Selected/All)  |
       +-----------+-----------+
                   |
                   v
       +-----------------------+
       | Open Device Consoles  |
       | (HTML5 or Breakout)   |
       +-----------------------+

Step 1: Create a New Lab Workbench

1. From the CML Dashboard, click the Add Lab button.
2. Click the newly created lab tile to open the canvas.
3. In the lower-left settings pane, assign a descriptive lab title (e.g., Branch-Routing-Validation) and click Save.

Step 2: Populate the Canvas with Nodes

1. Expand the Node Palette on the right side of the screen.
2. Locate the Cisco IOSv (Layer 3 router) icon. Drag and drop two instances onto the canvas (named node-0 and node-1 by default).
3. Drag an IOSvL2 (Layer 2 switch) icon between the routers.
4. Select each node to view its properties in the bottom pane, where you can modify names, labels, and CPU/memory allocations.

Step 3: Interconnect Device Interfaces

1. Hover your cursor over the first IOSv router until the light blue interface halo appears.
2. Click and hold the interface handle, then drag the connecting wire to the IOSvL2 switch.
3. In the interface assignment pop-up dialog, select the physical port bindings:
4. Source interface: GigabitEthernet0/0
5. Target interface: GigabitEthernet0/0
6. Repeat this operation between the switch’s GigabitEthernet0/1 interface and the second router’s GigabitEthernet0/0 interface.

Step 4: Boot the Simulation

1. To power on the entire topology simultaneously, click the green Start Lab button on the left sidebar.
2. Alternatively, right-click an individual node and select Start.
3. Observe the node icons: they will transition from a queued state (yellow) to active execution (solid green).

Step 5: Access Device Consoles

1. Click on the first router (node-0) to select it.
2. In the lower panel, switch to the Console tab.
3. Press Enter to open the interactive Cisco IOS CLI session.
4. Verify interface status and assign IP configurations:

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 10.0.0.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end
R1#

1. Repeat on node-1 (assigning 10.0.0.2/24), and execute a ping 10.0.0.1 to confirm bidirectional Layer 3 transit across the virtual switch.

Key Takeaway: The CML workbench combines visual drag-and-drop wiring with direct CLI console integration, enabling rapid testing without physical cabling overhead.

Connecting Virtual Topologies to External Networks and the Internet

Simulating closed network loops is effective for basic CLI testing, but real-world engineering often requires routing traffic to the internet, downloading software updates to simulated Linux hosts, or managing lab nodes using external tools (e.g., Ansible, Terraform, or SecureCRT) on your local computer.

Step 1: Understand External Connector Modes

CML uses a dedicated node type called the External Connector (ext-conn) to link virtual topologies to host interfaces:
* NAT Mode (Default): Masquerades outgoing traffic behind the primary IP address of the CML virtual appliance. Virtual nodes receive an address via internal DHCP and can initiate outbound connections to the internet.
* Bridge Mode (bridge0): Transparently connects virtual nodes directly to the host network interface at Layer 2. Nodes reside on the same broadcast domain as your physical workstation and can receive IP addresses from your local home or office router.

Step 2: Add and Configure the External Connector Node

1. In your active lab canvas, open the Node Palette.
2. Locate the External Connector icon and drag it onto your grid.
3. Click the External Connector node and open the Edit Config or Node Details tab in the lower pane.
4. Under the configuration mode options:
5. Select NAT if your goal is simple outbound internet access for lab routers.
6. Select System Bridge (bridge0) if you want your physical workstation to directly ping, SSH, or manage lab devices over your home subnet.

Step 3: Link the External Connector to Lab Devices

1. Drag a link from your lab edge router (e.g., interface GigabitEthernet0/1) to the External Connector node.
2. The connector uses an interface designated as port. Complete the link assignment.

Step 4: Configure Node Routing and DNS

Open the console of your edge router and configure the interface facing the External Connector.

If using NAT Mode:

R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip address dhcp
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# ip name-server 8.8.8.8
R1(config)# ip domain lookup

If using Bridge Mode with a static home subnet (e.g., 192.168.1.0/24 with gateway 192.168.1.1):

R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip address 192.168.1.250 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1
R1(config)# ip name-server 1.1.1.1

Step 5: Verify End-to-End Transit

1. Run show ip interface brief to ensure the interface has obtained an active IP address.
2. Issue a test ping to public infrastructure:

R1# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/18/24 ms

1. Test DNS name resolution using ping cisco.com.

Key Takeaway: The External Connector bridges virtual simulations with physical hardware and the internet, opening possibilities for external automation, package management, and multi-host integrations.

Comparing Cisco Modeling Labs, GNS3, and EVE-NG

While CML is Cisco’s first-party platform, many engineers compare it with popular community alternatives: GNS3 and EVE-NG. The following matrix contrasts their core operational differences.

CML stands out primarily for compliance, convenience, and automation. Because it includes licensed virtual images directly from Cisco, it eliminates the compliance and logistical challenges of sourcing firmware images. Conversely, for engineers building multi-vendor networks containing Arista, Juniper, and Fortinet platforms side by side, GNS3 and EVE-NG offer broader third-party ecosystems.

Key Takeaway: Choose CML for an authorized, compliant Cisco environment with integrated automation APIs; choose GNS3 or EVE-NG if your primary requirement is multi-vendor topology testing.

Official Cisco Modeling Labs Documentation and Reference Guides

For advanced configuration, automation scripts, and troubleshooting, consult Cisco’s official technical publications:

• CML Product Documentation and Release Notes: Cisco publishes official guides covering version compatibility, new device templates, resolved bugs, and system requirements.
• Resource: Search the Cisco Learning Network under “Cisco Modeling Labs Documentation.”
• CML Administration Guide: Detailed guidance for day-to-day operations, including Cockpit system tasks, LVM storage expansion, backup and restore routines, and Smart Software Manager (SSM) proxy settings.
• Coverage: Host maintenance, multi-interface hypervisor bridging, and licensing operations.
• CML User Guide & Workbench Reference: The definitive manual for canvas tools, packet capture (PCAP) filters, external connectivity parameters, and terminal break-out operations.
• Coverage: Interface controls, hotkeys, link impairment settings (latency/jitter/loss), and custom node definitions.
• CML REST API Reference & virl2_client Python SDK: Authoritative documentation covering OpenAPI specifications and programmability.
• Coverage: Lab lifecycle management, programmatic node provisioning, and CI/CD integration workflows using Python.
• Cisco Learning Network Community Forums: The primary community hub for interacting with Cisco engineers, exchanging node definition YAML files, and reviewing troubleshooting threads.
• Access: Visit the Cisco Learning Network and navigate to the Cisco Modeling Labs Community section.

Key Takeaway: Relying on Cisco’s release notes, administrative guides, and API documentation ensures your deployment remains secure, stable, and easily maintainable through platform upgrades.

Conclusion

Cisco Modeling Labs bridges the gap between theoretical networking and hands-on, production-grade engineering. By understanding its hardware prerequisites, completing the initial appliance deployment, and mastering the workbench UI, you can design, boot, and test complex network topologies safely inside software. Furthermore, taking advantage of external connectivity and first-party REST APIs transforms CML from a simple certification study tool into a powerful engine for NetDevOps validation and automated network testing. Equipped with the right licensing and system resources, you can run realistic network deployments entirely from your browser.

Please follow and like us: