Network+ DHCP Troubleshooting Questions

DHCP troubleshooting is a core topic on the Network+ exam. Questions test whether you can identify the cause of IP address assignment failures, recognise APIPA addresses, and understand the DORA process.

The DHCP DORA Process

DHCP uses four messages to assign an IP address:

1. Discover — Client broadcasts to find DHCP servers (source: 0.0.0.0, dest: 255.255.255.255)
2. Offer — DHCP server offers an IP address
3. Request — Client requests the offered IP (still a broadcast — in case multiple servers offered)
4. Acknowledgment — Server confirms the lease

All four messages use broadcast because the client has no IP address yet and cannot send unicast traffic.

APIPA (Automatic Private IP Addressing)

If a Windows client cannot reach a DHCP server, it automatically assigns itself an APIPA address: 169.254.x.x with subnet mask 255.255.0.0.

APIPA allows local network communication between devices that are also using APIPA, but provides no default gateway — so there is no internet or routed access.

Exam recognition: any IP address in the 169.254.x.x range means the client could not reach the DHCP server. Do not confuse this with a static IP misconfiguration.

Diagnostic steps when you see 169.254.x.x:

1. Verify the client has a working physical connection (link light, cable, switch port)
2. Verify the DHCP server is running
3. Verify no firewall is blocking DHCP traffic (UDP ports 67 and 68)
4. On the client: ipconfig /release then ipconfig /renew

Scope Exhaustion

A DHCP scope is the range of IP addresses the server is configured to hand out. If all addresses in the scope are leased, new clients cannot get an IP address.

Symptom: new devices cannot connect. Existing devices maintain their leases.

Fix options:

• Increase the scope size (expand the address range)
• Reduce the lease duration (shorter leases free up addresses faster for dynamic environments)
• Add exclusions review — are there addresses excluded that should not be?
• Identify and remove stale leases from devices no longer on the network

Exam scenario: "50 new devices were added to the network. Some receive IP addresses but many cannot connect. The DHCP server is reachable. What is the most likely cause?" — DHCP scope exhaustion.

Rogue DHCP Server

A rogue DHCP server is an unauthorised DHCP server on the network. It responds to client DISCOVER messages and assigns incorrect IP addresses — wrong gateway, wrong DNS server, or even a gateway pointing to an attacker's machine.

Symptoms: users get IP addresses but cannot reach the internet or internal resources. Running ipconfig /all shows an unexpected DHCP server address.

Prevention: DHCP snooping on managed switches — this feature blocks DHCP responses from untrusted ports. Only the designated DHCP server port is trusted.

Exam scenario: "Users report they can connect to the network but cannot browse the internet. Their IP configurations show the correct IP range but an unexpected default gateway." — Rogue DHCP server assigning incorrect gateway.

DHCP Relay Agent

DHCP relies on broadcasts, which routers do not forward between subnets. A DHCP relay agent (also called ip helper-address in Cisco IOS) forwards DHCP broadcasts from one subnet to the DHCP server on another subnet.

Exam scenario: "A new VLAN was created. Devices in that VLAN cannot get DHCP addresses. The DHCP server is on a different VLAN. What must be configured?"

Answer: Configure a DHCP relay agent (ip helper-address) on the router or layer-3 switch interface for the new VLAN, pointing to the DHCP server's IP address.

DHCP Ports

• DHCP server listens on UDP port 67
• DHCP client communicates from UDP port 68

Firewall rules must allow UDP 67 and 68 for DHCP to function across firewalled network segments.

Practice Network+ DHCP troubleshooting questions to build recognition of each failure scenario.

DORA in Detail — What Each Packet Contains

The four-step DHCP process is tested at a level of detail that catches candidates who only memorised the acronym without understanding what's in each packet.

Discover — Client broadcasts to find any DHCP server. Source IP: 0.0.0.0 (client has no IP yet). Destination IP: 255.255.255.255 (limited broadcast). Source MAC: client's MAC. The packet includes the client's MAC address in the DHCP payload so the server knows where to respond. Also includes parameters the client is requesting (subnet mask, gateway, DNS, domain name — specified in the Parameter Request List option).

Offer — Server responds with a proposed IP address, lease duration, subnet mask, default gateway, DNS servers. If the client has no IP, the offer can be sent as a broadcast (to 255.255.255.255) so the client receives it, or as a unicast to the client's MAC via ARP. Includes the DHCP server's own IP so the client knows which server made the offer.

Request — Client broadcasts its acceptance of the offered IP. Key detail: this is still a broadcast, not a unicast to the offering server. This is intentional — if multiple DHCP servers sent offers, this broadcast tells all of them which offer was accepted (and implicitly tells the others to release their offered IPs back to their pool). The Request includes the server's IP (Server Identifier option) to identify which offer is accepted.

Acknowledge — Server confirms the lease. Includes the final IP, lease duration, and all network parameters. After this point, the client configures its IP stack and starts using the address.

Exam trap: "Why does the DHCP Request use broadcast instead of unicast?" The answer is to notify all DHCP servers that made offers, not just the chosen one, so they can release their reserved IPs back to the pool.

DHCP Starvation Attack and Snooping

DHCP starvation is a denial-of-service attack where the attacker sends thousands of DHCP Discover packets with spoofed (fake) source MAC addresses. The DHCP server allocates an IP for each unique MAC address, exhausting the pool. Legitimate clients then cannot get an IP address because the pool is empty.

DHCP snooping is the switch-level defense:

• Ports are designated as trusted (connected to legitimate DHCP servers or uplinks) or untrusted (connected to end clients)
• DHCP Offer and Acknowledge packets arriving on untrusted ports are dropped — this prevents rogue DHCP servers from responding
• DHCP Discover packets on untrusted ports can be rate-limited to prevent starvation attacks
• The switch builds a DHCP snooping binding table (IP-to-MAC-to-port mapping) that other features (Dynamic ARP Inspection, IP Source Guard) use

Enabling DHCP snooping (Cisco switch syntax):

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10
Switch(config-if)# ip dhcp snooping trust    (on uplink port only)

Exam scenario: "A user connected a home router to the office network. Other users started getting wrong IP addresses and losing internet connectivity." → Rogue DHCP server. The fix is DHCP snooping (designate the port the router is plugged into as untrusted so DHCP offers are blocked).

DHCP Lease Time Tuning — The Trade-offs

Lease time is a policy decision with real operational trade-offs:

Short lease time (e.g., 1 hour):

• Pros: IPs are reclaimed quickly when devices leave the network; useful in environments with many transient clients (conference rooms, guest wifi)
• Cons: more DHCP traffic as clients renew frequently; if DHCP server is down during renewal, clients lose connectivity sooner

Long lease time (e.g., 8 days):

• Pros: less DHCP traffic; clients keep their IP even through brief DHCP server outages (they renew at 50% of lease time, then again at 87.5%)
• Cons: IPs remain assigned to devices long after they leave; pool exhaustion risk in environments with high device turnover

Exam scenario: "A hotel conference center hosts hundreds of attendees who connect briefly and leave. The DHCP pool is frequently exhausted. What should be changed?" → Reduce lease time so IPs are reclaimed faster from departed devices.

Renewal behavior: DHCP clients attempt renewal at 50% of lease time (T1, via unicast to the original server). If no response by 87.5% of lease time (T2), they broadcast to any DHCP server. If no response by lease expiry, they must stop using the IP and start the DORA process over.

Superscopes and Split Scopes — Multi-Subnet Configurations

Superscope — A Windows DHCP Server feature that groups multiple scopes into a single administrative unit. Used when a single physical subnet spans multiple IP ranges (multinetting). The server can offer addresses from any scope in the superscope based on the client's subnet or relay agent information. This is relatively uncommon in practice but shows up on the exam.

Split scope — A redundancy strategy where two DHCP servers both hold overlapping scopes for the same subnet, but non-overlapping address ranges. The classic split is 80/20: Server A owns the first 80% of the pool, Server B owns the remaining 20%. Normally, Server A services all requests. If Server A fails, Server B's smaller pool can handle all clients temporarily.

Windows DHCP split scope is configured via the Split Scope Configuration Wizard in Server Manager. The wizard handles creating the scope on both servers and setting the appropriate exclusion ranges automatically.

Exam: "A network administrator wants DHCP redundancy so that clients can still get addresses if the primary DHCP server fails. They don't want to configure DHCP failover." → Split scope (80/20).

Note: Windows Server 2012 and later support DHCP failover (active-active or hot standby) which is more sophisticated than split scope. The exam tests both — split scope for older or simpler environments, failover for modern Windows deployments.

Troubleshooting Checklist — In Order

When a client can't get a DHCP address:

1. Check the client — Does the client show an APIPA address (169.254.x.x)? If yes, it's not hearing a DHCP Offer at all (not receiving or not sending Discover successfully). If it shows 0.0.0.0, it may not have attempted DHCP.

2. Release and renew — Windows: ipconfig /release then ipconfig /renew. Linux: dhclient -r then dhclient. Watch for error messages.

3. Ping the DHCP server by IP directly — If the client has no IP, use a static IP temporarily to test reachability. If you can't reach the DHCP server IP, it's a routing or connectivity problem, not a DHCP configuration problem.

4. Check relay agent for cross-subnet clients — If the DHCP server is on a different subnet, a relay agent (ip helper-address on the router) must be configured. Without it, the broadcast Discover never reaches the server. Verify the relay agent is configured with the correct DHCP server IP.

5. Check scope availability — Log into the DHCP server and verify the scope is active (not paused), has available addresses (not 100% utilised), and the subnet mask and gateway settings are correct.

6. Check for IP conflicts — If a client gets an address but loses it immediately, another device may have a static IP in the same range causing a conflict. The DHCP server pings the address before assigning it — if the ping succeeds, it skips that address. But static IP devices don't respond to pre-assignment pings from all servers.

Practice Question Sets