15 hands-on DHCP scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. DHCP configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
A branch LAN’s clients can’t obtain IP addresses even though the DHCP server at the hub is up and reachable. Diagnose where the broadcast-to-unicast relay path breaks and restore end-to-end DHCP lease delivery while preserving the rest of the clean, working design.
One-branch edge capstone that unifies DHCP for the LAN, PAT overload to an Internet server, an extended ACL that permits HTTP but denies SSH, and SSH-only management. The starting lab intentionally contains multiple faults across DHCP, NAT, and SSH so you must diagnose and repair the edge to achieve full end-to-end verification from the client.
Harden the access layer against rogue DHCP servers by enabling DHCP snooping on an L2 access switch and trusting only the legitimate server-facing port. You will validate that client access ports remain untrusted and that rogue DHCP offers are dropped while legitimate offers are permitted.
Deploy a centralized DHCP service across subnets using DHCP relay (ip helper-address). A branch client on a switched LAN requests an address from a DHCP server that resides at HQ. You will configure the relay on the branch gateway, create a DHCP pool for the remote subnet on the HQ router, verify the client lease and default gateway, and test end-to-end connectivity.
Turn a branch router into a DHCP server for a user LAN. You'll design a clean pool with exclusions, set the default gateway and DNS server, and verify a host lease and end-to-end reachability across a small routed core.
Hands-on IOS DHCP server practice focused on validating pool state, inspecting conflicts, and fixing a real address conflict caused by a legacy static host on the LAN. You will verify server-side leases and exclusions, observe a conflict entry, then permanently exclude the static IP and clear the stale conflict so a client can obtain a clean address.
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.
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.
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 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 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.
Almost every client address on a real network comes from DHCP, which makes it the first thing anyone suspects when a floor of users cannot get online and the last thing most study guides actually make you build. The message exchange is easy to recite, DISCOVER, OFFER, REQUEST, ACK, but the exam and the job test the configuration wrapped around it, and that configuration fails in ways that still look correct on screen. A pool that was never told to exclude the gateway will eventually lease it to a client and cause a duplicate-address conflict. A default-router that names an address from the wrong subnet hands out leases that cannot leave the segment. A relay configured perfectly still leases nothing if the DHCP server has no route back to the client subnet. None of those throw an error, which is why you have to build them and watch them break.
These DHCP labs run on real Cisco IOS in Cisco Modeling Labs. You reserve the static range with ip dhcp excluded-address, build a scope with ip dhcp pool and its network, default-router, dns-server, and lease statements, then confirm clients are actually leasing with show ip dhcp binding and show ip dhcp pool. From there the labs follow the same path the exam does: relaying a remote subnet broadcasts with ip helper-address on the client-facing interface and adding the return route the server needs, pinning one device to a fixed address with a manual binding, and configuring a router own interface as a DHCP client with ip address dhcp. Break/fix scenarios inject the classic faults, including an unexcluded gateway turning up in show ip dhcp conflict, a default-router from the wrong subnet, and a helper-address aimed at the local gateway instead of the server. Upload your export and the config is graded requirement by requirement against the answer key.
DHCP clients find a server by broadcasting to 255.255.255.255, and routers drop broadcasts rather than forward them, so the request never reaches a server on another subnet. The ip helper-address command on the client-facing interface converts those broadcasts into unicasts aimed at the server and stamps the giaddr field so the server knows which scope to lease from. Put it on the interface nearest the clients, and make sure the server has a route back to that subnet, because the reply is unicast and without a return path the relay still leases nothing.
Create a pool for that single client and define it as a manual binding: a host statement with the exact address and mask, plus the client identity, using client-identifier for a DHCP client identifier or hardware-address for a MAC. It shows up in show ip dhcp binding as a manual rather than automatic entry. Several labs have you build one alongside a dynamic pool, which is also how you would reserve an address for a printer or an access point in production.
Yes. These labs use the DHCP service built into Cisco IOS, so the router is both the device you configure and the server you test against, and a lightweight host node stands in for the client. You run the whole thing in your own Cisco Modeling Labs instance; each lab is a YAML package built on free-tier images, so there is no physical gear and no paid node licenses involved.
Study the theory behind these labs — the concept explainer and step-by-step guides.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.