60 hands-on CCNA scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. Aligned to the CCNA certification track — work through them to build exam-ready configuration and troubleshooting skills.
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.
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 CCNP lab focused on diagnosing and correcting IPv4 interface addressing issues on Cisco IOS routers. The lab ships pre-broken with two independently failing faults that the learner must find and fix using show commands and directed pings. No routing protocols or static routes are used — verification is limited to directly-connected neighbor and gateway reachability.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
Advanced NTP troubleshooting on a two-router /30. R2 never synchronizes its clock. Use show commands to diagnose, then correct the design intent so R2 deterministically references R1, and R1 is an authoritative time source at the agreed stratum. The starter ships with a pre-broken NTP configuration already applied; your job is to find and fix two independent faults.
Configure a Cisco IOS router as an authoritative NTP master and restrict which clients it will serve using an NTP access-group with a standard ACL. One shared LAN (no routing) connects three routers through a Layer-2 switch. Only R2 is authorized to receive time from R1; R3 is denied. Learners deploy, verify, and troubleshoot the access-group behavior.
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 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.
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.
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.
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.
Harden the management plane of a single IOS router by throttling brute-force login attempts and presenting a legal-warning banner. You will enable SSH-based management, configure login block-for and delay to resist password-guessing, and verify behavior from an ADMIN Linux workstation.
Harden the management-plane SSH service on a single Cisco IOS router so only SSHv2 is permitted and session limits are tightened. The baseline lab already has working SSH. You will enforce SSH version 2, set a 60-second authentication timeout, and limit authentication retries to 2. You will also regenerate a 2048-bit RSA key (an exec-only step) and validate with show commands.
Looking for something else? Browse the full lab archive or see today's daily lab.