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.

DHCP Packet Format: What Actually Flies Across the Wire

Before you debug a DHCP failure, you need to understand the packet format. It's not optional. Every DHCP message uses the same structure defined in RFC 2131 — a 576-byte minimum, 1500-byte typical over Ethernet. The first 240 bytes are fixed fields, then comes the options block (variable length).

The magic starts with the OP field (1 byte): 1 = BOOTREQUEST, 2 = BOOTREPLY. Then you've got HTYPE (hardware type, 1 for Ethernet), HLEN (hardware address length, 6 for MAC), and HOPS (0 unless relay involved). Transaction ID (XID) is a 4-byte random number — this is how clients match replies to requests. Don't skip XID collision issues in production; they cause silent failures.

Seconds elapsed (secs field) tells the server how long the client has been waiting. Flags field has the broadcast bit — if set, the server must broadcast the reply. Most clients set this until they have an IP. Then client IP (ciaddr), your IP (yiaddr — assigned address), server IP (siaddr), and relay/gateway IP (giaddr) follow. Finally, client hardware address (chaddr) and a 64-byte optional server hostname (sname) plus 128-byte bootfile name (file).

Options are packed after that: magic cookie (0x63825363), then type 53 (message type: 1=Discover, 2=Offer, 3=Request, 4=Decline, 5=ACK, 6=NAK, 7=Release, 8=Inform), followed by your option codes (subnet mask, routers, DNS, etc.). End with 0xFF. Capture this with tcpdump and filters like 'port 67 or port 68' — you'll see every field in action.

// io.thecodeforge — cs-fundamentals tutorial

import struct

# Minimal DHCP packet parser for debugging
# Replace raw_packet with your tcpdump capture bytes
raw_packet = bytes.fromhex(
    "01010600" +     # op=1, htype=1, hlen=6, hops=0
    "abcd1234" +     # xid (transaction ID)
    "0000" +         # secs
    "0000" +         # flags
    "00000000" * 4 + # ciaddr, yiaddr, siaddr, giaddr
    "112233445566" + # chaddr
    "00" * 202 +     # padding
    "63825363" +     # magic cookie
    "350101" +       # option 53 (DHCP Discover = 1)
    "0104ffffff00" + # option 1 (subnet mask = 255.255.255.0)
    "ff"             # end
)

def parse_dhcp_header(data):
    op = data[0]
    htype = data[1]
    hlen = data[2]
    hops = data[3]
    xid = struct.unpack(">I", data[4:8])[0]
    secs = struct.unpack(">H", data[8:10])[0]
    flags = struct.unpack(">H", data[10:12])[0]
    return op, htype, hlen, hops, xid, secs, flags

op, htype, hlen, hops, xid, secs, flags = parse_dhcp_header(raw_packet)
print(f"OP:{op} HTYPE:{htype} HLEN:{hlen} HOPS:{hops}")
print(f"XID:0x{xid:08x} SECS:{secs} FLAGS:0x{flags:04x}")

# Parse options
idx = 240  # start of options (typical fixed header length)
magic = raw_packet[idx:idx+4].hex()
print(f"Magic Cookie: 0x{magic}")
idx += 4
while idx < len(raw_packet) and raw_packet[idx] != 0xff:
    opt_type = raw_packet[idx]
    opt_len = raw_packet[idx+1]
    opt_val = raw_packet[idx+2:idx+2+opt_len]
    print(f"Option {opt_type}: len={opt_len} val={opt_val.hex()}")
    idx += 2 + opt_len

DHCP Renewal: The Lease Timeout That Will Bite You

Your DHCP server didn't forget your client's IP — it's the client that forgot to renew. Every DHCP lease has three critical timestamps: T1 (50% of lease time) triggers renewal unicast to the server that granted the lease. T2 (87.5% of lease time) triggers broadcast renewal to any DHCP server. After lease expiry (100%), the client must stop using the IP.

Clients send DHCPREQUEST at T1. If the server responds with DHCPACK, the lease refreshes with new timers. No response? The client waits until T2, then broadcasts. Still no server? The client goes back to square one: DHCPDISCOVER. In production, this is where your problems start. Misconfigured DHCP relay, firewall blocking UDP port 67/68, or a saturated server can all kill renewal silently.

Key gotcha: Some clients will cache the lease and reuse it on reboot. That's fine if the server still has it. But if the server gave that IP to another device (e.g., you shrunk the scope), you get a DHCPNAK. The client then must release the IP and start from DISCOVER again. This causes brief network discontinuity — painful for VoIP or IoT devices.

Always log DHCPACK and DHCPNAK events. Use dhcpd.conf's 'log-facility local7' or Wireshark filter 'dhcp.msg.type == 5 || dhcp.msg.type == 6'. Set your lease times based on your environment: 24 hours for static offices, 30 minutes for high-density WiFi, 8 hours for BYOD networks. Short leases cause churn but recover faster from network changes.

// io.thecodeforge — cs-fundamentals tutorial

import datetime

# Simulate DHCP lease renewal timeline
def simulate_dhcp_lease(lease_seconds=86400):
    """
    T1 = 50% of lease time
    T2 = 87.5% of lease time
    Expiry = 100% of lease time
    """
    begin = datetime.datetime.now()
    t1 = lease_seconds * 0.5
    t2 = lease_seconds * 0.875
    
    timeline = {
        "Lease granted": begin,
        "T1 (renew unicast)": begin + datetime.timedelta(seconds=t1),
        "T2 (rebind broadcast)": begin + datetime.timedelta(seconds=t2),
        "Expiry (stop using IP)": begin + datetime.timedelta(seconds=lease_seconds),
    }
    
    for event, time in timeline.items():
        print(f"{event}: {time.strftime('%H:%M:%S')}")
    
    # Simulate client state machine
    now = begin + datetime.timedelta(seconds=t1 + 5)  # At T1 + 5 seconds
    if now < timeline["Expiry"]:
        print(f"\nState at T1+5s: Sending DHCPREQUEST...")
        # Simulate ACK or NAK
        if now.second % 2 == 0:
            print("Result: DHCPACK — lease renewed")
        else:
            print("Result: DHCPNAK — must DISCOVER again")

simulate_dhcp_lease(7200)  # 2-hour lease

DHCP Components: The Players in Address Assignment

A DHCP deployment relies on four core components, each handling a distinct role. The DHCP server manages address pools (scopes) and responds to client requests. The DHCP client, typically a host OS, broadcasts discovery messages and applies received configuration. The relay agent (often a router or switch) forwards DHCP broadcasts across subnets, enabling a single server to serve multiple networks where broadcasts don't traverse. The final component is the DHCP options, carried in packets, which deliver parameters like DNS servers, domain names, and NTP servers. Without a relay agent, each subnet needs its own server. Without options, clients get only an IP and subnet mask. Missing any component breaks the chain: no relay means clients on remote VLANs never reach the server; no options mean clients default to incomplete network stacks. Understanding these players clarifies why your DHCP server sees zero traffic when relays are misconfigured, and why clients on the same VLAN work but those on other subnets fail silently.

// io.thecodeforge — cs-fundamentals tutorial
import subprocess
import sys

def check_dhcp_relay(interface):
    result = subprocess.run(
        ["netsh", "interface", "ipv4", "show", "config", interface],
        capture_output=True, text=True
    )
    if "DHCP enabled" in result.stdout:
        return "Client mode"
    return "Static IP"

if __name__ == "__main__":
    iface = sys.argv[1] if len(sys.argv) > 1 else "Ethernet0"
    print(f"Interface {iface}: {check_dhcp_relay(iface)}")

How DHCP Works: The Full Cycle from Discovery to Renewal

DHCP follows a four-message handshake called DORA: Discover, Offer, Request, Acknowledge. The client starts by broadcasting a DHCP Discover packet to 255.255.255.255. All servers on the subnet see it and respond with an Offer containing a proposed IP, lease duration, and options. The client picks one offer and unicasts a Request to that server. The server finalizes with an Acknowledge, confirming the lease. After 50% of the lease time expires, the client attempts renewal by sending a unicast Request directly to the server. If no response, it waits until 87.5% of the lease and broadcasts a renewal to any server. If that fails, the lease expires and the client starts over with Discover. Working means understanding this timing: a short lease (e.g., 1 hour) forces frequent renewals plus broadcast traffic on failure. A long lease (e.g., 24 hours) means stale IPs persist if clients disconnect. Production systems tune this balance between network churn and availability, often leaving defaults until a renewal flood reveals misconfigurations.

// io.thecodeforge — cs-fundamentals tutorial
import datetime

def lease_status(lease_start, lease_duration_hours):
    expiry = lease_start + datetime.timedelta(hours=lease_duration_hours)
    now = datetime.datetime.now()
    elapsed = (now - lease_start).total_seconds()
    total = lease_duration_hours * 3600
    pct = (elapsed / total) * 100
    
    if pct < 50:
        return f"Active ({pct:.1f}% elapsed)"
    elif pct < 87.5:
        return f"Renewing ({pct:.1f}% elapsed)"
    else:
        return f"Expiring soon ({pct:.1f}% elapsed)"

start = datetime.datetime(2025, 3, 1, 10, 0, 0)
print(lease_status(start, 24))

Conclusion: DHCP as the Unseen Foundation of Network Connectivity

DHCP, often dismissed as a simple utility, is the linchpin of modern network operations. From the initial DORA handshake to the complexities of lease renewal and the subtle failures that can cascade into outages, DHCP manages a critical resource: IP addresses. Without it, every device would require manual configuration—a logistical impossibility at scale. The protocol has evolved beyond basic IPv4 assignment to support DHCPv6, integrate with Dynamic DNS, and operate in high-availability failover clusters. In cloud environments, DHCP underpins virtual network interfaces and load balancers, often abstracted but never absent. Packet-level analysis reveals that DHCP carries more than just addresses; it delivers subnet masks, gateways, DNS servers, and boot files. The real lesson is that DHCP's apparent simplicity masks a system where a single misconfigured option or exhausted scope can paralyze thousands of hosts. Understanding DHCP deeply—its packet structure, state machines, and failure modes—separates a competent engineer from one who treats network configuration as magic. The time you invest in mastering DHCP repays itself during every outage, every migration, and every cloud deployment you operate.

// io.thecodeforge — cs-fundamentals tutorial
import subprocess, re, json
def get_lease_usage(server_ip='192.168.1.1'):
    result = subprocess.run(['dhcp-lease-list', '--parsable'], capture_output=True, text=True)
    leases = []
    for line in result.stdout.strip().split('\n'):
        match = re.search(r'(\S+)\s+(\S+)\s+(\S+)\s+(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2})', line)
        if match:
            leases.append({'ip':match.group(1),'mac':match.group(2),'expires':match.group(4)})
    return json.dumps({'total': len(leases), 'leases': leases}, indent=2)
print(get_lease_usage())

Conclusion: The Hidden Failure Modes That Break DHCP

The most dangerous DHCP failures are the ones that don't trigger alarms. A DHCP server that responds but with expired leases, a relay agent that drops Option 82, or a switch that floods broadcast domains asymmetrically—these degrade the network silently. The DORA sequence can succeed partially, leaving clients with IPs that work for minutes then fail, or with addresses from the wrong subnet. In cloud environments, DHCP misconfigurations often masquerade as routing problems: instances get addresses but cannot reach the metadata service because the gateway option is wrong. The packet-level view shows that DHCP options are interpreted inconsistently across vendors. What one router treats as a prefix length, another treats as a subnet mask—a difference that can break routing. The lesson is clear: never assume DHCP is working because clients get addresses. Verify lease durations, check option sets across subnets, and test failover by physically disconnecting the primary server. The protocol's robustness has made it ubiquitous, but that same ubiquity means its failures affect every layer above it. Treat DHCP as you would DNS—a critical service deserving of monitoring, redundancy, and forensic logging.

// io.thecodeforge — cs-fundamentals tutorial
import pyshark, sys
def inspect_dhcp(pcap_file):
    cap = pyshark.FileCapture(pcap_file, display_filter='dhcp')
    for pkt in cap:
        if hasattr(pkt, 'dhcp'):
            options = {}
            for opt in pkt.dhcp.field_names:
                if 'option' in opt:
                    options[opt] = pkt.dhcp.get_field(opt)
            print(f"Client {pkt.dhcp.chaddr} requested options: {list(options.keys())}")
            if 'dhcp.option.dhcp' in options and options['dhcp.option.dhcp'] == '5':
                print("!!! DHCPACK detected — verifying options...")
    cap.close()
if __name__ == '__main__':
    inspect_dhcp(sys.argv[1])