220 hands-on CCNA scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. CCNA configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
Engineer which trunk forwards by tuning STP path cost in a 3-switch triangle. Force SW1 as the VLAN 30 root at a deterministic priority, enable Rapid-PVST+, harden edge ports with PortFast and BPDU Guard, and raise the STP cost on SW3’s direct uplink to SW1 so SW3 prefers the longer, indirect path via SW2. Verify the resulting root port, alternate (blocked) port, and host reachability across the chosen path.
Beginner CCNA STP lab on a three-switch triangle with two hosts in VLAN 20. You will deliberately control the Spanning Tree root election using the root primary/secondary macros so SW1 is the active root and SW2 is the standby. The baseline already provides VLANs and trunks; your job is to set root priorities deterministically and verify the resulting roles and port states without introducing any Layer-3.
Configure PortFast correctly on access ports in a triangle switch loop while maintaining normal STP protection on inter-switch trunks. Force SW1 as the root for VLAN 50 and verify that only edge ports are fast-tracked. Observe the difference in host convergence with and without PortFast.
Continue the STP series on a three-switch triangle with a real loop. SW1 is the deterministic root for VLAN 60, and access ports already use PortFast. In this lab you will harden the edge by enabling BPDU Guard on the two host-facing access ports on SW2 and SW3, while leaving the inter-switch trunks untouched. Verify with show commands that BPDU Guard is active only on the edge and that hosts still communicate normally.
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.
Configure a centralized DHCP server on an IOS-XE router and relay DHCP from a remote branch LAN using ip helper-address on a branch router. Verify leases, helper configuration, and end-host reachability across a routed path.
Build a single-scope DHCP server on an IOS-XE router and verify two Alpine Linux clients lease addresses dynamically across a pure Layer-2 switch. Configure only the canonical pool (network + default-router). Verify leases from the router and from each client.
Free with an account
Configure an IOS-XE router as a DHCP server with a correctly scoped pool and an excluded-address range that protects the gateway and a reserved static server (.10). Two Alpine clients obtain addresses dynamically from the remaining range (starting at .11). Verify leases, confirm the excluded count, and ensure the reserved static never appears as a DHCP binding.
Build a central DHCP service on an IOS-XE router and service two branch departments across a routed hop via DHCP relay. Configure two DHCP pools (SALES and SUPPORT) with proper options and excluded ranges on the HQ server, and enable ip helper-address on both branch LAN interfaces so clients obtain leases from the correct pool. Verify leases and bindings using Linux and IOS show commands, and confirm return-path reachability with prebuilt static routes.
Configure a Cisco IOS router as a DHCP server with a general LAN pool and a per-host manual binding (reservation) so that CLIENT-A always receives 172.20.10.5 based on its MAC, while CLIENT-B receives a normal dynamic address from the same subnet. Verify with router show commands and Linux host tools. Focus strictly on DHCP: pool scope, excluded addresses, options, and a hardware-address-tied manual binding.
Configure an IOS router as a DHCP server and have another IOS router obtain its uplink address dynamically via DHCP on a shared LAN. Validate the lease from both the client and server perspectives and test reachability from attached hosts.
Build and verify two independent DHCP address pools on a single Cisco IOS router, each serving a different LAN. Two Alpine Linux clients obtain leases from their respective pools via directly attached access switches. You will configure the pools, excluded addresses, default gateways, DNS, and domain names, then verify with IOS show commands and Linux tools. The focus is deterministic router DHCP configuration; clients lease dynamically and are verified rather than graded.
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.
Operate, observe, and clear Cisco IOS PAT translations on an internet edge. You will configure a standard PAT overload on R1, generate multiple concurrent sessions from an inside host, read translation/state counters, and clear single and all entries to see how the table repopulates immediately under live traffic.
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.
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).
Configure dynamic one-to-one NAT using a public address pool on an IOS router between a private LAN and a simulated ISP. Two inside hosts draw from a two-address public pool on-demand. Validate that no translations exist before traffic, that each host receives a distinct global address after generating traffic, and that entries age out when idle.
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
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.
Configure static PAT (port forwarding) on a Cisco IOS edge router so an outside client can reach an inside HTTP service on TCP/8080 using a dedicated public IP that is not the router's interface. Validate using curl from the outside host and NAT show commands on the router.
Configure PAT on an edge router so only PC-A is translated using a standard ACL as the traffic selector. PC-B remains untranslated and fails to reach the ISP, illustrating that NAT occurs only for traffic explicitly matched by the ACL. Validate using host pings and IOS show commands, and interpret ACL hit counters and NAT tables.
Hands-on static routing lab in a small branch–WAN–branch triangle. You will configure recursive, directly-attached, and fully-specified static routes to enable end-to-end reachability between two hosts across three routers. You will learn how next-hop resolution works, how it appears in show ip route, and how to troubleshoot when static routes don’t resolve or forward as expected.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.