When a client device boots up and fails to obtain an IP address, the network grinds to a halt. In the CCNA 200-301 exam (objective 4.3), you must be able to systematically troubleshoot DHCP failures—a critical skill for any network engineer. This chapter arms you with a structured diagnostic approach, from verifying the DHCP server configuration to analyzing packet captures, so you can quickly restore connectivity in the real world.
Jump to a section
Imagine a large apartment building where new tenants (DHCP clients) need to receive a mailbox key (IP address) from the building manager (DHCP server). The process works like this: A new tenant arrives and shouts 'I need a key!' (DHCP Discover) into the lobby intercom, which broadcasts to all offices. The building manager hears the request and sets aside a specific mailbox number (IP address), then sends a courier with a temporary key (DHCP Offer) back to the tenant. The tenant accepts by signing a lease (DHCP Request) and returning it to the manager, who then finalizes the assignment and provides the permanent key and a copy of the building rules (DHCP Ack). Now, what can go wrong? First, the tenant might be in a soundproof room (client firewall blocking broadcasts). Second, the courier could get lost if the manager doesn't know the tenant's apartment number (no relay agent on a different subnet). Third, the manager might have run out of mailbox keys (exhausted DHCP pool). Fourth, another manager might mistakenly think they already gave a key to this tenant (duplicate IP conflict). Fifth, the intercom might be broken (switchport configuration issues like port security or VLAN mismatch). Each failure point in the analogy maps directly to a DHCP troubleshooting step: verify client connectivity, ensure DHCP relay is configured across subnets, check pool exhaustion, check for IP conflicts, and verify switchport settings. By thinking through the mailroom analogy, you can systematically diagnose and resolve DHCP assignment failures.
What is DHCP and Why Does It Fail?
Dynamic Host Configuration Protocol (DHCP) automates IP address assignment. When it fails, clients get Automatic Private IP Addressing (APIPA) addresses in the 169.254.0.0/16 range or no IP at all. The CCNA exam expects you to troubleshoot failures at each step of the DORA process (Discover, Offer, Request, Ack).
The DORA Process in Detail
DHCP Discover: Client sends a UDP broadcast (src 0.0.0.0:68, dst 255.255.255.255:67). The broadcast must reach the DHCP server. If the server is on a different subnet, an IP helper (ip helper-address) on the router interface is required to convert the broadcast into a unicast.
DHCP Offer: Server responds with a unicast (or broadcast) offer containing an IP address, lease time, subnet mask, default gateway, and DNS servers. The offer is sent to the client's MAC address.
DHCP Request: Client broadcasts a request (or unicasts if server address known) to formally ask for the offered IP.
DHCP Ack: Server acknowledges, binding the IP to the client's MAC. The client then configures the interface.
Common Failure Points
No DHCP Server: The server is down, unreachable, or not configured.
Broadcast Not Forwarded: On a routed network, the router lacks an ip helper-address on the client VLAN interface.
Pool Exhaustion: All addresses in the DHCP pool are leased.
IP Address Conflict: The offered IP is already in use (detected via ping or ARP).
Client Firewall: Windows firewall or other security software blocks DHCP broadcasts.
Switchport Issues: Port security, VLAN mismatch, or spanning-tree blocking.
Key Timers and Defaults
Lease Time: Default 86400 seconds (24 hours) on Cisco IOS DHCP server.
Renewal Timer (T1): 50% of lease time (12 hours by default). Client unicasts DHCP Request to server.
Rebinding Timer (T2): 87.5% of lease time (21 hours). Client broadcasts DHCP Request to any server.
Client Retry: After 4 DHCP Discover attempts with no response, client may fall back to APIPA (Windows).
IOS CLI Verification Commands
show ip dhcp bindingDisplays active leases.
show ip dhcp pool [pool-name]Shows pool statistics, including utilization.
show ip dhcp server statisticsShows number of messages sent/received, including discards.
show ip interface [interface]Verify ip helper-address is present.
debug ip dhcp server eventsReal-time troubleshooting (use with caution).
Related Protocols
ARP: DHCP server may ping the offered address before sending offer to avoid conflicts.
SLAAC: IPv6 uses Router Advertisements; DHCPv6 is optional.
DNS: DHCP often provides DNS server addresses; failure to resolve names may be misdiagnosed as DHCP issue.
Check client IP configuration
On the client, run `ipconfig /all` (Windows) or `ifconfig` (Linux/Mac). Look for an IP address. If it's 169.254.x.x, the client has an APIPA address, meaning it didn't receive a DHCP offer. If it's 0.0.0.0, the interface is not configured. Verify the client is set to obtain an IP automatically. Also check if the client has a static IP configured inadvertently. Ensure the network cable is connected and the link light is on.
Verify DHCP server reachability
From the client's subnet, try to ping the DHCP server's IP (if known). If the server is on a different subnet, ping from the router's interface facing the server. Use `show ip interface brief` to confirm the router interface is up/up. If the server is a Cisco router, use `show ip dhcp binding` to see if it has any leases. If the server is not responding, check its configuration and ensure the DHCP service is enabled (`service dhcp`).
Check IP helper configuration
If the DHCP server is on a different subnet, the client's broadcast will not cross the router without an IP helper. On the router interface facing the client, use `show running-config interface [interface]` and look for `ip helper-address <server-ip>`. If missing, configure it: `interface GigabitEthernet0/0` then `ip helper-address 192.168.1.10`. Multiple helper addresses can be added for redundancy. Verify with `show ip interface [interface]`.
Inspect DHCP pool and bindings
On the DHCP server (Cisco router), run `show ip dhcp pool` to see pool name, subnet, and utilization. If `Current index` is at the end of the range, the pool is exhausted. Use `show ip dhcp binding` to see active leases. Look for the client's MAC address. If not present, the server never received the Discover. Also check for excluded addresses: `show ip dhcp excluded-addresses`. Ensure the pool subnet matches the client's VLAN.
Look for IP address conflicts
A DHCP server may detect a conflict if it pings the offered address and gets a reply. On Cisco IOS, use `show ip dhcp conflict` to see conflicted addresses. The server will remove the address from the pool. Conflicts can arise from static IPs on other devices or overlapping scopes. To clear a conflict: `clear ip dhcp conflict <address>` or `clear ip dhcp conflict *`.
Examine switchport and VLAN issues
If the client is on a switch, verify the access VLAN: `show vlan brief` and `show interfaces status`. Ensure the port is in the correct VLAN and not err-disabled. Check port security: `show port-security interface [interface]`. If the port is secure and the client MAC is not allowed, DHCP traffic is dropped. Also check spanning-tree: `show spanning-tree vlan <vlan>` to ensure the port is in forwarding state.
Capture and analyze DHCP traffic
Use a packet analyzer like Wireshark on the client or a SPAN port on the switch. Filter for `bootp` or `dhcp`. Look for Discover packets leaving the client. If no Discover is seen, the client isn't sending. If Discover is sent but no Offer received, the server may not be reachable or the Offer is blocked. Check for Offer packets arriving. If Offer arrives but no Request, the client may have rejected the offer (e.g., address in use). This step isolates the exact failure point.
In a typical enterprise campus network, DHCP servers are often centralized in the data center, serving hundreds of VLANs. Network engineers configure IP helper addresses on the Layer 3 interfaces of Distribution switches or the SVIs (Switch Virtual Interfaces) of the Core. For example, on a Cisco Catalyst 9300 acting as a Layer 3 switch for VLAN 10, the SVI configuration would include ip helper-address 10.10.10.5 pointing to a Windows DHCP server.
Scenario 1: A new building is added with a separate subnet. The engineer configures the VLAN and SVI but forgets the IP helper. Clients in that building get APIPA addresses. The fix is to add the helper address.
Scenario 2: During a major rollout, the DHCP pool runs out of addresses because the lease time is set to 7 days and many devices have left the network. The engineer reduces the lease time to 1 day and expands the pool subnet mask from /24 to /23.
Scenario 3: A rogue DHCP server (e.g., a misconfigured wireless router) is handing out incorrect IPs. The engineer uses DHCP snooping on the switches to filter unauthorized DHCP servers. Cisco's DHCP snooping feature is configured globally and per VLAN, with trusted ports (uplinks) and untrusted ports (access ports). Commands: ip dhcp snooping, ip dhcp snooping vlan 10,20, interface GigabitEthernet1/0/1 then ip dhcp snooping trust.
Performance considerations: A single DHCP server can handle thousands of leases, but broadcast traffic in large VLANs can be heavy. Using DHCP relay and separating clients into smaller VLANs reduces broadcast domains. Misconfiguration, such as overlapping DHCP scopes, can cause IP conflicts and intermittent connectivity. Always verify with show ip dhcp conflict after changes.
The CCNA 200-301 exam objective 4.3 (Troubleshoot DHCP) focuses on your ability to identify why a client fails to obtain an IP address. Common scenarios include: client on a different subnet with no IP helper, exhausted DHCP pool, IP conflict, and misconfigured DHCP server.
Top wrong answers candidates choose: 1. 'The client's MAC address is blocked' – While possible, it's less common than missing helper address. 2. 'The DHCP server is down' – Often the server is up but unreachable due to routing or helper issues. 3. 'The client is using a static IP' – Candidates overlook the APIPA clue. 4. 'The pool is not in the same subnet as the client' – Actually, the pool subnet must match the client's subnet, but the server can be on a different subnet with relay.
Specific values: Default lease time is 86400 seconds (24 hours). T1 is 43200 (12 hours), T2 is 75600 (21 hours). The ip helper-address command forwards UDP broadcasts for DHCP (ports 67/68), TFTP, DNS, and others by default.
Calculation traps: None for DHCP, but know that the pool size is determined by the subnet mask. For example, a /24 pool has 254 usable addresses.
Decision rule: If client has 169.254.x.x, the issue is likely no DHCP server reachable (no helper, server down, or broadcast blocked). If client has 0.0.0.0, check interface configuration. If client gets an IP but no connectivity, check gateway and DNS from DHCP options.
Elimination strategy: First verify client is set to DHCP. Then check if server is reachable from client's subnet. If not, check helper. If reachable, check pool exhaustion and conflicts. Finally, check switchport and security features.
DHCP uses DORA: Discover (broadcast), Offer, Request, Ack.
Client APIPA address (169.254.x.x) indicates no DHCP response.
Default lease time on Cisco IOS DHCP server is 86400 seconds (24 hours).
Use `ip helper-address <server-ip>` on router interface facing clients to forward DHCP broadcasts.
Command `show ip dhcp binding` displays active leases; `show ip dhcp pool` shows pool utilization.
IP address conflicts are viewed with `show ip dhcp conflict`.
DHCP snooping filters unauthorized DHCP servers; configure trusted ports on uplinks.
These come up on the exam all the time. Here's how to tell them apart.
DHCP Relay (ip helper-address)
Forwards DHCP broadcasts to a remote server
Configured on Layer 3 interfaces (routers, SVIs)
Helps clients on different subnets get IPs
Does not filter DHCP messages
Default forwards multiple UDP services
DHCP Snooping
Filters DHCP messages to block rogue servers
Configured globally and per VLAN on switches
Prevents unauthorized DHCP offers
Trusts only specific ports (uplinks)
Does not forward broadcasts across subnets
Mistake
The DHCP server must be in the same subnet as the client.
Correct
The DHCP server can be on a different subnet if the router has an `ip helper-address` configured on the client-facing interface to relay broadcasts.
Candidates think broadcasts cannot cross routers, but the helper address converts broadcasts to unicasts.
Mistake
If a client gets an IP address, DHCP is working fine.
Correct
A client can get an IP from a rogue DHCP server or from a pool with wrong options (e.g., wrong gateway), causing connectivity issues.
Getting any IP does not mean correct configuration; verify options like default gateway and DNS.
Mistake
The `ip helper-address` command forwards all broadcasts.
Correct
It forwards only specific UDP broadcasts: DHCP (67/68), TFTP (69), DNS (53), NetBIOS (137/138), and TACACS (49) by default.
Cisco's documentation lists the default forwarded ports; candidates often assume it forwards everything.
Mistake
DHCP pool exhaustion causes the server to send a NAK.
Correct
When the pool is exhausted, the server simply does not respond to Discover messages; it does not send a NAK.
NAK is sent only when the client requests an IP that is not valid for the subnet or is already in use.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This is an Automatic Private IP Addressing (APIPA) address, assigned by Windows when no DHCP response is received. It means the client sent DHCP Discover broadcasts but never got an Offer. Possible causes: the DHCP server is down, unreachable (no IP helper on router), the broadcast is blocked by a firewall, or the DHCP pool is exhausted. Check the server status and the router's helper address configuration.
The default lease time is 86400 seconds (24 hours). You can change it with the `lease` command in DHCP pool configuration mode. For example, `lease 0 8 0` sets an 8-hour lease. Always consider the network's churn rate when setting lease time.
First, enable the DHCP service (it's on by default). Then create a pool: `ip dhcp pool MYPOOL`, then define the network: `network 192.168.1.0 255.255.255.0`, default gateway: `default-router 192.168.1.1`, DNS: `dns-server 8.8.8.8`, and optionally lease time. Exclude any static addresses using `ip dhcp excluded-address 192.168.1.1 192.168.1.10`.
It configures a router interface to forward incoming UDP broadcasts (specifically DHCP, TFTP, DNS, etc.) as unicasts to a specified server IP. Without it, DHCP broadcasts from clients on one subnet cannot reach a DHCP server on another subnet. The command is applied on the interface facing the clients.
Use DHCP snooping on your switches. Enable it globally (`ip dhcp snooping`), then enable per-VLAN (`ip dhcp snooping vlan 10,20`). Configure uplink ports as trusted (`ip dhcp snooping trust`) and access ports as untrusted. This allows only trusted ports to send DHCP Offer and Ack messages.
DHCP Discover is a broadcast sent by the client to find available DHCP servers. It has no offered IP. DHCP Request is sent by the client to formally accept an offer (or to renew an existing lease). It contains the requested IP and the server's identifier. The server responds with Ack if the request is valid.
This means the DHCP server never received any Discover messages. Check if the server is in the correct VLAN and reachable. If clients are on a different subnet, verify the router has an `ip helper-address` pointing to the server. Also ensure no ACL is blocking UDP port 67/68.
You've just covered Troubleshoot: DHCP Not Assigning Addresses — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?