21 hands-on CML scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. CML configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
Harden the monitoring plane by replacing cleartext SNMPv2c with authenticated and encrypted SNMPv3 (authPriv) on R1. You will create a v3 group that requires privacy and a user with SHA authentication and AES-128 encryption, then verify the configuration. The flat management LAN avoids routing complexity so you can focus on the security mechanics of SNMPv3.
In this advanced CCNP BGP lab, you will steer a single router's outbound path choice using Cisco's Weight attribute, the very first BGP best-path tiebreaker. R1 (AS 65001) peers eBGP with two ISPs (R2 in AS 65002 and R3 in AS 65003). Both ISPs advertise the same prefix 172.16.50.0/24. Your job is to make R1 prefer the R3 path using the neighbor weight command and verify the outcome using IOS and Linux tools.
Build your first external BGP (eBGP) peering between two routers in different autonomous systems over a /30 point-to-point link and exchange one /24 prefix from each side using Loopback0. The topology is intentionally small yet realistic, with two edge routers (AS 65001 and AS 65002) and three Alpine hosts for basic reachability checks and operator context. You will configure deterministic BGP neighbors, originate prefixes with exact-match network statements, and validate reachability and route installation using standard IOS and Linux tools. This is Lab 1 of 10 in the CCNP-aligned BGP Fundamentals series and sets the foundation for later labs on iBGP, route filtering, and path selection.
Free with an account
Implement classic EIGRP manual summarization on R1 to collapse four contiguous /24 loopback routes into a single /22 summary toward R2, reducing R2’s routing table entries while preserving reachability.
Configure a classic hub-and-spoke EIGRP domain where the single-homed branch (R2) is made an EIGRP stub, limiting query scope while still advertising its LAN. Validate that R1 flags R2 as a stub neighbor, routes still exchange, and query behavior is scoped appropriately.
Bring up EIGRP in AS 100 between two routers over a /30 transit and advertise a single LAN. Verify the first adjacency forms and that R2 learns R1's LAN via EIGRP. Includes realistic end hosts on a shared LAN for path testing.
Free with an account
Advanced EtherChannel capstone, run as a fault hunt. The uplink bundle between two access switches is not passing traffic and the hosts either side cannot reach each other. Some members are up, the bundle is not, and nothing was recorded. You get symptoms and the required end state — no fault list. Both ends of a bundle have to agree about several things at once, and only one end was touched during the change — so comparing them is the exercise.
Build a two-link LACP EtherChannel between SW1 and SW2 and convert the Port-channel into an 802.1Q trunk that explicitly carries VLANs 40 and 41. Validate end-to-end host reachability across VLAN 40 and confirm the trunk’s allowed VLAN list and switchport mode on the logical port-channel. Emphasis: deterministic EtherChannel configuration on member interfaces, correct trunking on the Port-channel, and verification with IOS show commands.
Advanced Rapid-PVST+ and Root Guard implementation on a three-switch triangle with a real loop. SW1 is the intentional root for VLAN 90 and protects its designated ports with Root Guard to prevent root re-parenting. Two Alpine hosts on VLAN 90 verify end-to-end forwarding remains stable even if a superior BPDU appears downstream.
Configure an IOS-XE router as a DHCP server delivering a complete, production-grade option set (gateway, DNS servers, domain suffix, explicit 8-hour lease) to two Alpine Linux clients over a pure L2 access switch. Validate that clients obtain dynamic addresses in-scope and that /etc/resolv.conf reflects the delivered DNS and domain options. The graded outcome is the deterministic router DHCP configuration — not the clients’ dynamic addresses.
Advanced CCNA troubleshooting capstone for centralized DHCP across a relay. A centralized IOS-XE router (DHCP-SRV) serves the branch LAN behind BR-RTR via ip helper-address. The lab imports in a deliberately broken state: the DHCP pool scope and gateway are misconfigured on the server, and the relay configuration is missing on BR-RTR. Learners must diagnose using show outputs and Linux tools, fix all three discrepancies, and verify that two Alpine clients dynamically receive usable leases and can reach DHCP-SRV.
Build a small but realistic edge topology and configure static one-to-one NAT on R1 so the inside host PC-A (192.168.10.10) always translates to 203.0.113.3. Validate bidirectional reachability with an upstream ISP router and a public server one hop further. Verify translation state and counters on R1 and connectivity from both ends.
Free with an account
Implement Port Address Translation (PAT) using a one-address NAT pool so multiple inside hosts share a single public IP. Reuse the same 5-node topology and addressing as the prior lab; convert the pool to a single address and enable overload. Verify simultaneous connectivity from two inside hosts, observe translations and counters, and contrast with prior pool-exhaustion behavior.
Build an Internet-edge NAT design that reaches beyond the ISP to a real external network. You will configure dynamic PAT (overload) from a private LAN to a public /29 using a NAT pool on the edge router, with the router’s default route already pointing to the ISP. Verify that an inside host can reach a public server across the ISP and that translations, counters, and default routing reflect the expected state.
Implement and verify interface-based PAT (overload) on a single-edge SOHO router. Inside hosts on 192.168.10.0/24 share the router’s lone public IP (203.0.113.1) on its outside interface. Validate NAT translations, ACL matches, and simultaneous host access, and practice troubleshooting common misconfigurations (inside/outside role reversal, ACL selection errors).
Advanced NAT capstone, run as a fault hunt. Inside hosts cannot reach the internet, the translation table stays empty, and one host cannot even reach its own gateway. The lab is called NAT, which is the trap: not every fault here is a NAT fault. You get symptoms and the required end state — no fault list. Faults span the router, the switch and the path beyond, and fixing the translation alone will not restore service.
Configure static one-to-one NAT for two inside hosts on R1, mark inside/outside interfaces correctly, and read the four-column NAT translation table (inside local/global, outside local/global). Verify from both sides and relate observed traffic to table entries.
Deploy and verify port security maximum settings on host-facing access ports in a pure Layer-2 campus with two access switches uplinked to a distribution switch. You will raise the allowed secure MAC count to 2 on each user port to support a PC and a potential downstream device (e.g., a dock), then verify with show commands. No Layer-3, SVIs, or routing are used; focus purely on access VLANs, trunks, and the port-security maximum behavior.
Hands-on CCNA L2 switching lab: build a small campus with a distribution switch and two access switches carrying a shared user VLAN over 802.1Q trunks. Harden access ports with sticky port-security in violation shutdown mode. Intentionally seed and diagnose broken trunks/host VLANs, restore end-to-end host reachability, then trigger a port-security violation to observe err-disabled behavior and perform manual recovery.
Build a two-router, one-access-switch lab with a client and a server. Establish basic IP connectivity with static routing, then implement an extended IPv4 ACL inbound on the client-facing interface to permit SSH and HTTP to the server while denying Telnet and ICMP echo. Validate from the client and review ACL hit counters for proof.
Deploy primary static routes between two branch LANs via a hub router and add a higher-AD floating static for a direct inter-branch backup. Verify end-to-end reachability, simulate a hub outage to trigger automatic failover, then restore the primary path. Includes realistic addressing, unique /30 transits, and host-based verification.
Cisco Modeling Labs is Cisco own network simulation platform: you import or draw a topology and CML boots real Cisco software as virtual nodes, so command output, timing, and edge cases match production gear instead of a simulator approximation. CML-Free is the no-cost edition, and the honest version of what it gives you is this: no license subscription, nothing to buy, and no expiry, since Cisco documentation states the instance keeps working after the days-remaining counter reaches zero. The constraint is a node count rather than a clock, capped at five nodes running at once, though unmanaged switches and external connectors are unlimited and do not count toward it. Two practical requirements catch most people. CML is a virtual appliance, so it runs inside a hypervisor, with VMware Workstation or Fusion on a personal machine and VirtualBox not supported. And the reference-platform images are a separate download from the installer.
Every lab here ships as a single self-contained YAML topology that imports in one click, and each is built to fit inside the free tier: no lab exceeds five counted nodes, and all of them use only reference-platform node definitions included in CML-Free, namely the IOL router, the IOL Layer 2 switch, and Alpine hosts. Import the file, start the nodes, and console straight onto real IOS. It is worth sanity-checking the underlay before you configure anything: show ip interface brief confirms the expected interfaces exist, with administratively down being the normal starting state, and show cdp neighbors confirms you are wired to the devices the diagram promised. When you finish, save on the device with copy running-config startup-config, run Extract Configurations from the lab menu so your running configs are written back into the lab definition, then download the lab and upload that export, where it is graded requirement by requirement against the answer key.
It is not a trial. There is no license subscription and nothing to buy, and the instance keeps operating after the days-remaining counter hits zero, so the limit is node count rather than time. Five nodes may run simultaneously, and routers, switches, and host nodes all count. Unmanaged switches and external connectors are the exception, since they are unlimited, which is why an unmanaged switch is the right way to put several devices on a shared segment without spending one of your five.
Almost always because the reference-platform images are not installed. The installer and the reference-platform ISO are separate downloads, and without the images a node definition has nothing to boot, so the topology imports perfectly and then the devices refuse to start. Copy the ISO onto the appliance and confirm each definition has an image under the node and image definitions screen. The other cause is the free-tier node limit, so stop and wipe any other running labs first, because a sixth node simply will not start.
Not directly. These are CML-native YAML topologies, and the formats are not interchangeable, since GNS3 uses its own project format and Packet Tracer simulates a subset of IOS rather than running the real images. There is also a grading difference worth knowing: Packet Tracer can auto-grade only inside pre-authored activity files, and neither tool checks a configuration you wrote yourself against an answer key. You need a CML instance, and the free tier is enough for every lab here.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.