DHCP Scope Exhaustion — Why 50 IoT Devices Killed a Network

Every time you join a coffee shop Wi-Fi, plug into your home router, or spin up a cloud server, DHCP quietly hands your device an IP address without a single manual step. That automatic handoff is the Dynamic Host Configuration Protocol, and it's one of the most critical protocols on the internet. Without it, every device would need manual network config before browsing.

Before DHCP (standardised in 1993), admins manually assigned IPs to every device. In a company with 500 computers, that meant 500 trips, 500 config screens, and 500 chances for a typo that broke someone's connection. Worse, two admins could accidentally give the same IP to two machines — an IP conflict that killed both. DHCP eliminated all that pain with a central server handling address assignment automatically.

Here's what you'll walk away with: exactly how DORA works under the hood, what info DHCP pushes beyond just an IP, how to troubleshoot a failed lease, and what breaks when things go wrong. You'll be able to explain it in an interview, fix a real DHCP outage, and finally understand what your router means by 'obtaining IP address'.

What is DHCP Explained?

DHCP solves one problem: manual IP configuration. When a device joins a network, it needs a unique IP, subnet mask, default gateway, and DNS servers. Without DHCP, you'd configure each device by hand — and track assignments to avoid conflicts. DHCP automates this by leasing IPs for a limited time.

Think about scale: an enterprise with 10,000 devices would need an entire team just for static IP management. DHCP handles that in milliseconds per request, with zero human error. The trade-off? You now depend on a server. If it's down, new devices can't join. That's why redundancy matters.

Here's the thing: DHCP doesn't just hand out IPs. It also pushes options like DNS servers and gateway. One wrong option value can silently break connectivity. We'll cover that later.

# Check if DHCP server is reachable (TheCodeForge style)
sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1

The DORA Process: How DHCP Works Step by Step

DORA stands for Discover, Offer, Request, Acknowledge. When a device boots, it broadcasts a DHCP Discover on the local network. The server hears it and responds with an Offer that includes a potential IP, subnet mask, lease duration, and options. The client then sends a Request explicitly asking for that offered address. Finally, the server sends an Acknowledge, confirming the lease.

This whole exchange happens in under a second — usually. The Discover uses UDP broadcast to port 67, so it reaches all DHCP servers on the same Layer 2 segment. If the server is on a different subnet, a DHCP relay agent forwards the broadcast as a unicast. That's a detail that'll trip you up if you ever set up DHCP across VLANs.

One nuance: after the Acknowledge, the client may send a DHCP Decline if it detects the offered IP is already in use (via gratuitous ARP). This rare step prevents duplicate addresses, but if it happens often, you've got a network misconfiguration.

# Capture DHCP traffic to see DORA in action
sudo tcpdump -i eth0 -n port 67 or port 68 -e -v
# Look for: DISCOVER, OFFER, REQUEST, ACK

DHCP Options: Beyond IP Addresses

DHCP doesn't just hand out an IP. The server sends a set of configuration parameters called options. Here are the critical ones: • Option 1: Subnet Mask • Option 3: Router (Default Gateway) • Option 6: Domain Name Servers • Option 15: Domain Name • Option 51: Lease Time • Option 53: Message Type • Option 54: Server Identifier • Option 121: Classless Static Routes

These options are defined by IANA and are extensible. Enterprise deployments often use vendor-specific options to push proxy PAC URLs or certificate server locations. A misconfigured option can silently break an entire subnet — for instance, giving out a wrong DNS server makes 'google.com' unreachable, but everything else works.

Watch out for Option 82 (Relay Agent Information) — used in DHCP snooping to identify which switch port a request came from. If your switch strips or modifies this option, the server may reject requests or assign wrong scopes.

DHCP in Production: Scopes, Leases, and Relay Agents

In a corporate network, DHCP uses scopes — ranges of addresses for each subnet. Each scope has its own lease time, options, and exclusion ranges (e.g., reserving .1-.10 for servers). When a device moves between subnets, it must get a new lease from the new scope. That's where DHCP relay agents come in.

A relay agent (router or Layer 3 switch) listens for DHCP broadcasts on a subnet, then unicasts them to the DHCP server. Without it, each subnet would need its own DHCP server. The relay agent adds the gateway IP (giaddr field) so the server knows which scope to offer from. A wrong giaddr is a common source of confusion — clients get IPs from the wrong scope or no response at all.

Lease management matters. The server tracks each lease's state: available, allocated, renewed, released, expired. At 50% of lease time, the client tries to renew with the same server. At 87.5%, it broadcasts to any server. If the server is down during renewal, the lease expires and the client loses its IP. In production, set lease times based on device mobility: 8 hours for workstations, 15 minutes for guest Wi-Fi, days for servers.

A lesser-known detail: the server also detects conflicts via gratuitous ARP. If a conflict is detected, the client sends a DHCP Decline, and the server marks that IP as bad. This can cause rapid exhaustion if misconfigured.

# Check DHCP pool utilization on ISC server
sudo cat /var/lib/dhcp/dhcpd.leases | grep -c '^lease'
# Total pool size - count available? (approximate: parse pool config)
sudo grep -A5 'subnet' /etc/dhcp/dhcpd.conf | grep 'range'

DHCP Security: Rogue Servers and Spoofing

DHCP was designed for a trusted network — no authentication built in. That opens the door for rogue DHCP servers: an attacker sets up a fake server on the same subnet, offering malicious IPs and gateways. Clients that accept the rogue's offer route all traffic through the attacker, enabling man-in-the-middle attacks.

Mitigation: DHCP snooping on switches monitors UDP port 67 and blocks DHCP server messages on untrusted ports. Trusted ports are where legitimate servers connect. Any DHCPOFFER on an untrusted port is dropped. Also use 802.1X authentication to ensure authorized devices only.

Another attack is DHCP starvation: an attacker floods the network with Discover messages from fake MAC addresses, exhausting the lease pool. Countermeasure: rate limiting on DHCP traffic and port security to limit MAC addresses per port.

Real story: a disgruntled employee plugged a consumer router into the network, enabling its DHCP server. Within minutes, half the floor lost connectivity because clients received a different gateway that couldn't route. Fix: enable DHCP snooping on all edge switches and configure trusted ports for the known DHCP server IP only.

Troubleshooting DHCP: Common Failures and Debug Commands

When DHCP fails, the symptom is often 'no network' or 'limited connectivity'. Debug systematically: start at Layer 2 (link up?), then Layer 3 (has IP? APIPA means no DHCP). Use tcpdump to see if messages are exchanged. If no Discover goes out, check the client's DHCP service. If Discover goes out but no Offer returns, the server may be unreachable or relay agent not forwarding. If Offer is seen but Request is missing, the device may have rejected the offer. If Request goes out but no ACK, the server may have allocated the IP elsewhere.

Here's a methodical checklist: 1. Verify client network cable/connection 2. 'ipconfig /release && ipconfig /renew' (Windows) or 'sudo dhclient -v' (Linux) 3. Capture traffic: 'tcpdump -i eth0 port 67 or port 68' 4. Check DHCP server logs: /var/log/syslog or /var/log/messages 5. For cross-subnet, verify relay agent configuration 6. Check scope utilization on the server 7. Check for rogue DHCP servers with a broadcast ping or scanning tools

Pro tip: for intermittent failures, set up a continuous capture with a rotating file. You'll see the pattern only when the failure occurs.

#!/bin/bash
# DHCP diagnostic script for Linux (TheCodeForge)
INTERFACE="eth0"
echo "--- Releasing and renewing on $INTERFACE ---"
sudo dhclient -r $INTERFACE && sudo dhclient -v $INTERFACE
echo "--- Capturing DHCP traffic for 10 seconds ---"
sudo timeout 10 tcpdump -i $INTERFACE -n port 67 or port 68 -e -v
echo "--- Checking DHCP server logs (last 20 lines) ---"
sudo tail -20 /var/log/syslog | grep -i dhcp

DHCPv6 and Stateful vs Stateless Configuration

IPv6 changes DHCP significantly. DHCPv6 still exists but competes with SLAAC (Stateless Address Autoconfiguration). In SLAAC, a router advertises a prefix and clients generate their own IP using EUI-64 or privacy extensions. DHCPv6 provides additional info like DNS servers. Two modes: stateless DHCPv6 (used with SLAAC to supply DNS) and stateful DHCPv6 (server assigns and tracks IPs like IPv4). Production networks often use SLAAC for IP assignment and DHCPv6 for options. A common mistake is enabling both without coordination, leading to duplicate addresses or missing DNS.

DHCPv6 uses different ports (UDP 546 client, 547 server) and a slightly different message flow: Solicit, Advertise, Request, Reply. But the concept is the same. Also, the Identity Association (IA) allows multiple addresses per interface, which complicates state tracking.

DHCP in Cloud Environments: AWS, Azure, GCP

Cloud providers abstract DHCP away. In AWS VPC, every instance gets an IP from the VPC's CIDR via a built-in DHCP service. You can configure DHCP option sets (domain name, DNS servers) but can't control lease times. Azure VNets use Azure DHCP with custom DNS servers. GCP VPCs assign IPs via internal DHCP with options for Google-managed DNS or custom. Key insight: cloud DHCP is reliable but limited — you can't set lease times, isolate scopes, or run relay agents. Need granular control? Use static IPs or bring your own DHCP server on a VM, but that adds complexity.

A production trap: in AWS, when you add a secondary CIDR to a VPC, the DHCP service automatically expands the pool — but existing instances won't get IPs from the new range until you release and renew. Plan for that during maintenance windows.

Advanced DHCP Troubleshooting: Packet Analysis and Server Logs

When basic commands fail, dig deeper. Wireshark filters like 'bootp' or 'dhcp' show every message. Capture on client and server simultaneously to see what the server sends vs what the client receives. Server logs are critical: ISC DHCP server logs to syslog with entries like 'DHCPDISCOVER from xx:xx:xx:xx:xx:xx via eth0'. Look for 'no free leases' or 'dynamic and static leases conflict'. On Linux, 'dhcpdump' gives real-time view. For Windows, 'netsh dhcp server show scope' shows utilization.

A common advanced issue: the DHCP server's database corrupts, causing it to forget active leases. Rebuilding from backups or restarting with a clean lease file often fixes it. Also check NTP: if server and client clocks drift significantly, lease renewal timers become misaligned. A client might think its lease expired when it hasn't, causing pointless renewals or disconnects.

#!/bin/bash
# Advanced DHCP debugging - TheCodeForge
# Capture only DHCP offers and acknowledgements
sudo tcpdump -i eth0 -n -l 'port 67 and (udp[8] & 0x01 != 0)' 2>/dev/null | tee dhcp_capture.txt
# Monitor ISC DHCP server logs for real-time events
sudo tail -f /var/log/syslog | grep -E 'dhcpd|DHCP'

DHCP Failover and Redundancy: Keeping IPs When the Server Goes Down

Single DHCP server = single point of failure. Two common redundancy designs:

1. Split scopes (80/20 rule): two servers each manage part of the address pool. If one fails, the other still has addresses. Downside: administrative overhead and potential conflicts.
2. Failover protocol (ISC DHCP or Windows DHCP failover): two servers synchronize lease databases in real-time. If primary fails, secondary takes over seamlessly. Requires careful network design to avoid split-brain scenarios.

In production, failover protocol is preferred for critical subnets. But even with failover, you must test — many teams discover during an outage that the failover relationship wasn't correctly configured or the secondary server was down for maintenance.

DHCP and Dynamic DNS (DDNS): Automatic Host Registration

In many enterprises, DHCP integration with DNS is a game-changer. When a device gets a lease, the DHCP server can automatically update DNS with the device's hostname and IP. This eliminates manual DNS records for every workstation.

The setup requires: DHCP server must have authority to update DNS, DNS server must accept secure updates, and the zone must be configured for dynamic updates. Common pitfalls: if the DHCP server IP changes, you need to update DNS delegation. Also, when a lease expires or is released, the DHCP server must remove the DNS record — but many deployments forget this, leaving stale DNS entries that cause name resolution errors.

Security note: DDNS updates should be authenticated (TSIG or GSS-TSIG). Unauthenticated updates allow any client to register arbitrary hostnames, enabling DNS poisoning.