Exam Objective 1.7: Troubleshoot DHCPv4 client, server, and relay on IOS devices.
DHCP is how the vast majority of end devices receive their IP configuration automatically, and Cisco IOS devices can play three different roles in that process: the client requesting an address, the server assigning addresses, or the relay agent forwarding requests between a client and a remote server. This objective ties directly back to objective 1.3 (APIPA, address assignment) but goes deeper into the actual IOS configuration and the specific commands used to verify and troubleshoot each role.
Before troubleshooting DHCP, you need the underlying exchange memorized. DHCP uses a four-step process commonly abbreviated DORA:
Discover — the client broadcasts a DHCPDISCOVER message (destination 255.255.255.255) looking for any available DHCP server on the local segment.
Offer — one or more DHCP servers respond with a DHCPOFFER, proposing an IP address, subnet mask, lease time, and other options.
Request — the client broadcasts a DHCPREQUEST, formally requesting the offered address (broadcast again so that any other servers who made offers know their offer was not accepted).
Acknowledge — the chosen server responds with a DHCPACK, finalizing the lease and confirming the configuration.
Exam Alert: DORA (Discover, Offer, Request, Acknowledge) is fundamental and frequently tested by name or by being asked to sequence the four messages correctly.
Because DHCP relies on broadcasts, and routers do not forward broadcasts between subnets by default, a DHCP client and DHCP server that are not on the same subnet cannot complete this exchange without help — this is exactly the problem DHCP relay solves.
A router interface (commonly used on the WAN-facing interface of a small branch router, or a switch's management/SVI interface) can be configured to obtain its own IP address dynamically rather than statically.
Configuration:
ip address dhcp (applied under the interface)
Verification:
show ip interface brief — confirms whether the interface received an address and is up/up
show dhcp lease — displays the details of the lease the interface obtained, including the assigned address, DHCP server address, and lease duration
show interface [interface] — confirming the interface itself is not administratively down or experiencing a Layer 1 problem, which would prevent DHCP from working regardless of configuration
Common client-side problems:
The interface is down/down at Layer 1, so no DHCP exchange can even begin
No DHCP server is reachable on the local segment and no relay is configured, so the interface never receives an offer and may show no address or an incomplete configuration
The interface configuration was left as ip address dhcp but a static address was actually intended, or vice versa
A Cisco router (or Layer 3 switch) can act as the DHCP server itself for one or more subnets, useful in small branch offices without a dedicated DHCP server.
Basic DHCP server configuration:
ip dhcp excluded-address 192.168.10.1 192.168.10.10
ip dhcp pool LAN-POOL
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
dns-server 8.8.8.8
lease 7
Key configuration elements:
ip dhcp excluded-address — reserves a range of addresses (typically including the router's own interface address and any statically-assigned devices like servers/printers) that the DHCP server should never hand out; this must be configured before the pool, or addresses in that range may be leased before the exclusion takes effect
ip dhcp pool [name] — creates a named pool defining the scope of addresses to lease
network — defines the subnet and mask this pool serves
default-router — specifies the gateway address handed out to clients (this should match the actual router interface address on that subnet)
dns-server — specifies the DNS server address(es) handed out to clients
lease — sets the lease duration (in days, or with hours/minutes options); default is one day if not specified
Verification commands:
show ip dhcp binding — shows every address currently leased out, along with the associated client's MAC address (hardware address) and lease expiration
show ip dhcp pool [name] — displays statistics on a specific pool, including total addresses, addresses leased, and addresses still available
show ip dhcp conflict — displays any addresses the server detected as already in use (via ping or gratuitous ARP) before offering them, which the server then avoids handing out
show ip dhcp server statistics — displays counters for each DHCP message type sent/received (Discovers, Offers, Requests, Acks), useful for spotting whether requests are arriving but not being answered
Common DHCP server-side problems:
Scope exhaustion — the pool has run out of available addresses; new clients requesting a lease will not receive one and typically fall back to APIPA. Fixed by expanding the pool's network range, shortening the lease time so addresses recycle faster, or creating an additional pool.
Excluded-address range too small or missing — statically assigned devices (like the router's own interface, or a server) accidentally get leased out to a DHCP client, causing an IP conflict.
Wrong network/mask configured in the pool — clients receive an address that doesn't actually match the real subnet in use on that segment, breaking connectivity even though a lease was technically successful.
default-router address incorrect — clients receive a valid address but the wrong (or no) gateway, so they can reach the local subnet but nothing beyond it.
Overlapping pools — two pools inadvertently cover the same address range, risking duplicate address assignment.
Exam Alert: Order of operations matters: configure ip dhcp excluded-address before creating the pool that covers those same addresses, since IOS processes the exclusion as a global rule checked at lease time, but best practice and exam scenarios expect the exclusion to already be in place to avoid a race condition where an address gets leased before you remember to exclude it.
When a DHCP client and DHCP server sit on different subnets — the far more common real-world scenario in any network larger than a single flat LAN — a relay agent is required, since the client's DHCP broadcast will not cross the router boundary on its own.
Configuration:
Applied on the client-facing router interface (the interface on the subnet where the DHCP clients actually live, not on the server's subnet):
interface GigabitEthernet0/1
ip helper-address 10.1.1.5
This command tells the router: "Take any DHCP broadcast received on this interface, and forward it as a unicast to 10.1.1.5" (the DHCP server's address). The router also relays the return traffic (offer, ack) back to the client appropriately.
Important relay details:
ip helper-address actually forwards several well-known UDP broadcast services by default, not just DHCP (including TFTP, DNS, Time, NetBIOS Name Server, and a few others) — DHCP is simply the most commonly relevant one for this exam objective.
Multiple ip helper-address commands can be configured on the same interface if there are multiple DHCP servers (for redundancy), and the router will forward the request to all of them.
The relay agent inserts its own interface address into the DHCP packet as the gateway address (giaddr field) so the DHCP server knows which subnet/pool to allocate an address from — this is precisely why a DHCP server configuration with the wrong network/mask, or a missing pool for that subnet altogether, causes relayed clients to fail even though the relay itself is working correctly.
Common relay-related problems:
ip helper-address missing entirely on the client-facing interface, so DHCP broadcasts are simply dropped by the router with nowhere to go — clients fall back to APIPA
ip helper-address configured with the wrong DHCP server IP address, so requests are forwarded but never reach a real DHCP server
ip helper-address configured on the wrong interface (e.g., on the server's subnet rather than the client's subnet)
No matching DHCP pool exists on the server for the relayed subnet (identified by the giaddr the relay inserted), so the server has no addresses to offer even though the request successfully arrived
An ACL on the router blocking UDP port 67/68 traffic, preventing the relayed DHCP packets from actually passing through
Exam Alert: ip helper-address is configured on the interface closest to the DHCP clients (the interface that receives the broadcast), pointing at the DHCP server's IP address. This is a very frequently tested configuration command — know exactly where it goes and what it does.
Confirm the affected interface is up/up at Layer 1/2 — no DHCP exchange can complete if the physical link itself is down.
Check the client for an APIPA address (169.254.x.x) — confirms the client never completed the DORA exchange.
Determine whether the DHCP server is local (same subnet) or remote (different subnet than the client).
If local, verify the server's pool configuration: correct network/mask, default-router, dns-server, and that the pool has not been exhausted (show ip dhcp pool).
If remote, verify ip helper-address is configured on the client-facing interface and points to the correct DHCP server address.
Check show ip dhcp binding on the server to see whether the client's request actually arrived and was processed, or never showed up at all.
Check show ip dhcp conflict for any addresses the server has flagged as already in use, which could explain why a specific address is unexpectedly unavailable.
Verify no ACL is blocking UDP ports 67 (server) and 68 (client) along the path, especially on the relay router or any intermediate device.
If everything above checks out, use debug ip dhcp server events (on the server) to watch the exchange happen in real time, keeping in mind the CPU impact of debug commands in a production environment.
Q1. What is the correct order of messages in the DHCP DORA process?
A. Offer, Discover, Acknowledge, Request
B. Discover, Offer, Request, Acknowledge
C. Request, Discover, Offer, Acknowledge
D. Discover, Request, Offer, Acknowledge
Answer: B. The DHCP process begins with the client broadcasting a Discover message, the server responding with an Offer, the client broadcasting a Request to formally accept that offer, and the server finalizing the lease with an Acknowledge (DORA).
Q2. On a Cisco router configured as a DHCP server, which command should be configured before creating the DHCP pool to prevent statically assigned addresses (such as the router's own interface) from being leased to clients?
A. ip dhcp pool
B. ip helper-address
C. ip dhcp excluded-address
D. default-router
Answer: C. ip dhcp excluded-address reserves a range of addresses that the DHCP server should never hand out to clients, and should be configured before (or otherwise well ahead of) creating the pool to prevent a race condition where an address is leased before the exclusion takes effect.
Q3. A DHCP client sits on VLAN 20, while the DHCP server sits on a different subnet, VLAN 10. Where should the ip helper-address command be configured?
A. On the DHCP server itself
B. On the router or Layer 3 switch interface serving VLAN 10 (the server's subnet)
C. On the router or Layer 3 switch interface serving VLAN 20 (the client's subnet)
D. On every switch in the network regardless of VLAN
Answer: C. The ip helper-address command is configured on the interface closest to the DHCP clients — the interface that actually receives the client's DHCP broadcast — which in this scenario is the VLAN 20 interface. The command forwards the broadcast as a unicast to the DHCP server's address on VLAN 10.
Q4. An administrator runs show ip dhcp pool and finds that a pool has 0 addresses remaining, while show ip dhcp binding confirms many active leases. New clients on that subnet are receiving APIPA addresses. What is the most likely cause?
A. The ip helper-address command is misconfigured
B. DHCP scope exhaustion — the pool has run out of available addresses to lease
C. The DNS server address in the pool is incorrect
D. An ACL is blocking UDP port 67
Answer: B. A pool showing 0 addresses remaining, combined with many active bindings, directly indicates scope exhaustion — every address in the defined network range has already been leased out. New clients requesting an address will fail to receive one and fall back to an APIPA address until the pool is expanded, the lease time is shortened, or unused leases expire.
Q5. Besides DHCP, which other type of broadcast traffic does the ip helper-address command forward by default?
A. OSPF hello packets
B. Spanning Tree BPDUs
C. Several well-known UDP broadcast services such as TFTP, DNS, and NetBIOS Name Server
D. ARP requests
Answer: C. ip helper-address is not exclusively a DHCP-relay command — by default it relays several well-known UDP broadcast services, including TFTP, DNS, Time service, and NetBIOS Name Server, in addition to DHCP/BOOTP, though DHCP relay is by far its most commonly tested and used purpose.
Q6. A router interface is configured with ip address dhcp, but show ip interface brief shows the interface as up/up with no IP address assigned. What should be checked next?
A. Whether the interface has an excluded-address range configured
B. Whether a DHCP server is reachable on that segment, or whether a relay (ip helper-address) is needed if the server is remote
C. Whether the interface is configured with the wrong VLAN
D. Whether the lease time is set too short
Answer: B. Since the interface is already up/up at Layer 1/2 but never received an address, the problem lies in the DHCP exchange itself — either no DHCP server is reachable on the local segment, or the client is on a different subnet than the server and requires a relay (ip helper-address) configured on the appropriate upstream interface to forward the broadcast.