55 hands-on Cisco IOS scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. Cisco IOS configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
Enable the open-standard LLDP on adjacent Cisco IOS routers over direct point-to-point links while also attaching the devices to a shared management LAN. Learners configure deterministic LLDP behavior (global enable plus per-interface transmit/receive) and verify neighbor discovery without adding any routing protocols or static routes.
Advanced discovery and monitoring capstone, run as a fault hunt. The NMS has stopped seeing this site: neighbours are missing from the topology map, no traps are arriving, and syslog went quiet — while every device is reachable and pingable. You get symptoms and the required end state — no fault list. Faults span both routers and the switch they all peer through, and more than one of them leaves the monitoring configuration looking complete.
Tune which syslog messages go where on Cisco IOS using severity levels: keep detailed logs locally in a 16 KB buffer, reduce console noise to warnings, and send notifications to a central server. Single management LAN, no routing. Grading focuses on three R1 commands steering severity: logging buffered 16384 debugging, logging console warnings, and logging trap notifications.
Configure Cisco IOS SNMPv2c read-only access on R1 so an NMS on a trusted management LAN can poll device status. You will add a read-only community string and device identity (location/contact), validate from IOS show commands, and confirm basic reachability from the MGMT host. No routing protocols or static routes are used; all devices share a single management subnet bridged by an L2 switch.
Configure a Cisco IOS router (R1) to proactively send SNMPv2c trap notifications to a centralized NMS host. Learners practice the difference between polling and traps, add the trap destination and enable device-initiated notifications, and verify deterministically with show commands. Flat L2-only management LAN; no routing, no VLAN/STP complexity.
Enable and verify DNS-based name resolution on Cisco IOS. R1 will use a central DNS resolver on the management LAN and also maintain a static host mapping for R2, demonstrating resolution order and operational differences between local host tables and DNS queries.
Practice deterministic VLSM planning and interface addressing on two Cisco IOS routers. Starting from a single /24, allocate three right-sized IPv4 subnets (two LANs represented by loopbacks and one router-to-router WAN) and configure exact interface addresses and masks. No routing protocols or static routes are configured; verification focuses on directly connected reachability and show commands.
Advanced IP addressing capstone, run as a fault hunt. A branch build has been handed over and nothing quite works: one LAN cannot reach its gateway, a transit link behaves as though the two ends are on different networks, one router will not accept traffic on a point-to-point link, and two devices answer to the same loopback. You get symptoms and the required end state — no fault list. Every fault is an addressing decision that looks plausible until it is checked against the mask.
Configure a Cisco IOS router to host two IPv4 /24 subnets on a single physical LAN interface using a secondary address. Verify directly-connected reachability only (no routing protocols, no static routes). This simulates a readdressing coexistence period where both old and new subnets must operate concurrently on the same segment.
Beginner CCNA lab (1 of 10) focused on configuring and verifying IPv4 interface addressing on Cisco IOS routers. Learners assign given /24 addresses to two router interfaces and validate directly-connected reachability. No routing protocols or static routes are configured in this lab.
Free with an account
Advanced IPv6 interface addressing on Cisco IOS routers. Configure explicit, predictable IPv6 link-local addresses alongside global unicast addresses on a point-to-point router-to-router link. Validate with show commands and neighbor pings using the link-local as the destination, and confirm host-to-gateway reachability on local LANs. No routing protocols or static routes are used; focus is strictly on interface IPv6 addressing mechanics.
Enable IPv6 forwarding and configure IPv6 global unicast addresses on directly connected links only. No routing protocols or static routes. Verify that each device can reach only its directly connected neighbors using IPv6.
Configure and verify dual-stack IPv4 and IPv6 addressing on Cisco IOS router interfaces. R1-R2 share a /30 IPv4 and /64 IPv6 point-to-point transit, while R1 provides a dual-stack user LAN gateway. No routing protocols or router static routes are permitted; verify only directly connected reachability.
Build confidence addressing IPv4 point-to-point WAN links on Cisco IOS using /30 and /31 masks. Two routers are connected by two parallel links: one classic /30 and one RFC 3021 /31. No routing protocols or static routes are configured — the goal is deterministic, correct interface addressing and verification of directly connected reachability. A small LAN off R1 with two hosts allows additional verification (host-to-gateway only).
Configure IPv6 global unicast on a router-to-router link using EUI-64-derived interface IDs. Enable IPv6 unicast routing, set explicit link-local addresses, and verify that each router auto-forms its 64-bit interface ID from the MAC (FFFE insertion with U/L bit flip). Validate directly-connected reachability only. No routing protocols or static routes.
Hands-on IPv4 subnetting and interface addressing on three IOS routers and one client. You will split a /24 into four equal /26s, assign the correct /26 mask to each link, and configure deterministic lowest-usable addressing on router interfaces. No routing protocols or static routes are used; verification is strictly directly-connected reachability.
Two-router /30 point-to-point lab. R1 is an authoritative UTC NTP master (stratum 3). Configure R2 as an NTP client to R1 and display local time in MST/MDT while remaining synchronized to UTC. Reinforces that NTP distributes UTC and the router applies timezone/daylight-saving only to presentation.
Build a small LAN with two IOS routers acting as NTP masters at different strata and a client that lists both as time sources, preferring one using the prefer keyword. All routers share a single broadcast domain via a Layer-2 switch, with no routing configured. You will deploy deterministic NTP, verify associations, and understand redundancy selection behavior.
Beginner CCNA NTP lab. Two IOS routers share a single /30 link with no routing. Configure R1 as an authoritative NTP master at stratum 3 and point R2 to R1 as its NTP server. Verify using show ntp associations, show ntp status, and show clock. Emphasis: deterministic config — grading checks the presence of ntp master 3 on R1 and ntp server 10.0.0.1 on R2, not live convergence.
Free with an account
Create a deterministic three-tier NTP hierarchy on a single shared LAN. R1 is the authoritative clock (ntp master 2), R2 syncs to R1, and R3 syncs to R2. No routing or additional subnets — all devices share 10.0.0.0/24 via one L2 switch. Verify with show ntp status and show ntp associations.
Configure two Cisco IOS routers as symmetric-active NTP peers over a single /30 link. R1 is an authoritative clock (ntp master 4) and both routers form a symmetric peer relationship with ntp peer. Learn how peer mode differs from client/server, and how to verify and troubleshoot associations without relying on Internet sources.
Configure a Cisco IOS router as an authoritative NTP master at a chosen stratum and point a neighbor at it as a client. Understand how NTP stratum works and verify deterministically using show commands rather than waiting for live synchronization.
Configure NTP MD5 authentication so a client (R2) synchronizes only to a trusted, authenticated master (R1). R1 is already an authoritative clock (ntp master 3). You will enable NTP authentication on both routers, define and trust key 1, and bind the key on R2's ntp server statement. Verification focuses on authenticated associations and status; actual time lock may take minutes and is not graded.
Configure a deterministic NTP broadcast design on a single shared LAN. R1 acts as an authoritative clock (ntp master 3) and broadcasts time on its LAN interface. R2 and R3 act as broadcast clients to scale time distribution without per-client server statements. Verify broadcast associations on the clients and understand the tradeoffs vs. unicast client/server.
There is a real difference between knowing what a command does and being fluent on the command line. Fluency is knowing that the config you want lives under an interface rather than globally, that a change takes effect the moment you press enter, that the running-config and the startup-config are different things, and that the fastest way to understand a device you've never seen is a handful of show commands in the right order. That only comes from time on an actual IOS prompt.
Every lab on this site runs on genuine Cisco IOS — IOL, IOL-L2 and IOSv images inside your own Cisco Modeling Labs instance — not a simulator with a subset of the syntax implemented. You get the real parser, real context-sensitive help, real error messages when a command is rejected, and the real output formats you'll be reading for the rest of your career. Labs import as YAML packages built for the CML free tier, so nothing needs buying. Build the scenario, verify it with the same show commands the exam expects, then export the config and upload it for per-requirement grading against the answer key.
Real IOS. The labs run on Cisco's own IOL, IOL-L2 and IOSv images inside Cisco Modeling Labs, so the CLI, the parser and the show output are exactly what you would see on the corresponding hardware.
The ones included with the CML free tier. Every lab is authored against those specifically, so there is no image hunting and no paid node licensing to sort out first.
Export the lab from CML once you have built it and upload that file. The grader indexes each device by its hostname and checks its running-config against the answer key requirement by requirement.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.