DHCP is often explained as “the thing that gives a device an IP address.” That is true, but it hides why DHCP is still operationally important. A DHCP service also tells a client which subnet it belongs to, where to send non-local traffic, which DNS resolvers to use, and how long that configuration is valid. A bad DHCP answer can therefore look like an address problem, a DNS problem, a routing problem, or all three at once.

For a small home network, the router usually does all of this quietly. For an office, lab, campus, or production network, DHCP is an address-management and policy distribution system. It deserves the same deliberate design as DNS, routing, and VLAN boundaries.

What DHCP actually provides

The IPv4 DHCP specification defines both configuration delivery and address allocation. A server can dynamically lease an address from a reusable pool, assign a permanent address automatically, or deliver an administrator-chosen address to a particular client. The important distinction is that DHCP is not synonymous with “random IP address.” A reservation is still DHCP: the server recognizes a stable client identifier and returns the address and options that belong to that device.

At a minimum, a typical client needs these values:

• An IPv4 address and subnet mask or prefix information.
• A default gateway (the router option).
• DNS resolver addresses.
• A lease duration and, usually, renewal timers.

Depending on the environment, a response can also carry a search domain, NTP servers, PXE boot information, SIP settings, vendor options, or other device-specific configuration. That breadth is why a DHCP scope should be treated as configuration code with review and change control, not a one-time wizard screen on a router.

The DHCP lease flow: Discover, Offer, Request, ACK

The familiar four-message exchange is usually abbreviated DORA. It is worth understanding because a packet capture makes the failure obvious much faster than clicking “renew lease” several times.

1. DHCPDISCOVER: A client without usable configuration broadcasts a request on its local network. It cannot assume it knows the server or even its own address yet.
2. DHCPOFFER: One or more servers may offer an address, lease, and proposed options.
3. DHCPREQUEST: The client selects an offer and broadcasts its choice. This also tells the other servers that their offers were not selected.
4. DHCPACK: The selected server commits the lease and returns the final configuration. A DHCPNAK instead tells the client that the requested or remembered configuration is not valid for this network.

DHCP uses UDP: servers listen on port 67 and clients use port 68. Initial messages are commonly broadcast because the client is not configured well enough to route a unicast packet. The DHCP specification also allows a client to receive multiple offers, which is one reason accidental second servers are so disruptive: the client may accept a perfectly reachable but completely wrong configuration.

After the ACK, the client is bound to the lease. It usually tries to renew with the original server before expiration; if that does not work, it eventually broadcasts a renewal request so another server that knows the lease can help. The practical point is simple: a client can look healthy for hours after a DHCP server or relay problem begins, then fail only when its renewal timer arrives.

Leases, reservations, and static addresses are different tools

Use dynamic leases for endpoints that move or are interchangeable: laptops, phones, guest devices, test machines, and many virtual-machine pools. They return addresses to the pool when devices go away and keep day-to-day address management sane.

Use reservations when a device needs a predictable address but should still receive centrally managed DNS, gateway, and other options. Printers, access points, appliances, and lab hardware are common examples. A reservation is usually less error-prone than hand-configuring an address on the device because the source of truth remains in the DHCP service.

Use a static address when the device genuinely cannot depend on DHCP, or when the platform and operational model require it. Do not put static addresses inside a dynamic pool and hope everybody remembers. Either reserve an excluded range or, better, use a separate infrastructure range with clear ownership.

Lease duration is a capacity and recovery decision, not a magic number. Short leases reclaim addresses quickly in a busy guest network but increase DHCP traffic and make outages surface sooner. Long leases reduce churn for stable devices but make pool exhaustion and stale configuration slower to correct. Pick a duration that matches device turnover and ensure the pool has real headroom.

DHCP relays make central services possible

DHCP broadcasts do not cross routed subnet boundaries on their own. That does not mean every VLAN needs its own DHCP server. A relay agent—often the VLAN’s default gateway—receives the client broadcast, forwards it to the central server, and identifies the originating subnet. The server then selects the correct scope and sends its response back through the relay.

This is where “the DHCP server is up” stops being a useful diagnosis. A client can fail because its VLAN interface lacks a relay configuration, the relay cannot reach the server, a firewall drops UDP 67/68, or the server does not have a matching scope for the relay’s address. Verify each hop.

For more specific policy, the DHCP Relay Agent Information Option (Option 82) can carry circuit or remote identifiers. That enables per-port or per-circuit policy and far better audit context, but it is only useful when the relay, switching configuration, and server policy agree. See What Is DHCP Option 82? before enabling it broadly.

DHCP is a security boundary, not just convenience plumbing

Classic DHCPv4 has no useful built-in answer to a rogue server on an access network. A malicious or accidental DHCP responder can hand out its own gateway or DNS resolver and redirect traffic before anyone opens a browser. DHCP pool exhaustion is another real failure mode: enough fake requests can consume every available lease.

The practical defense lives at the access switch:

• Enable DHCP snooping where the platform supports it.
• Trust only ports toward legitimate DHCP servers, relays, or controlled uplinks; leave ordinary endpoint ports untrusted.
• Rate-limit DHCP on untrusted access ports where appropriate.
• Monitor snooping bindings, lease utilization, and unexpected server replies.
• Treat Option 82 insertion and relay trust as explicit policy, not a checkbox.

These controls are vendor and topology specific. Test them on a non-critical VLAN first. A wrong trusted-port decision can stop clients from obtaining addresses just as effectively as a rogue server can. The related Cisco Catalyst Option 82 configuration guide and Cisco relay-agent article cover the older platform-specific starting points; verify exact syntax against the software release you operate.

A practical DHCP troubleshooting order

When a device has a self-assigned address, an expired lease, or the wrong DNS server, work from the client outward rather than starting with the server dashboard.

1. Confirm the client’s current state. Record its interface, VLAN or SSID, address, gateway, DNS servers, lease server, and lease expiration. “No network” is not enough detail.
2. Capture the exchange. On a directly attached test host, a command such as sudo tcpdump -ni en0 -vvv 'udp port 67 or udp port 68' can show whether DORA is happening at all. Use the actual interface name for the host.
3. Check pool health and scope selection. Is the correct scope enabled, is there capacity, and is the offered address actually valid for that VLAN?
4. Trace the relay path. Confirm the gateway relay setting, routing and firewall policy to the server, and the server’s view of the relay address.
5. Look for competing answers. Multiple offers, unexpected gateway or DNS options, and changing server identifiers point toward a rogue or duplicate DHCP service.
6. Check the enforcement layer. Snooping, port-security, NAC, and wireless controller policy can block or reshape the exchange. Review counters and logs before weakening a control.

For a router that is also acting as a DHCP server, persistent lease storage may be relevant after a reboot; Store DHCP Bindings on the Router captures that older Cisco-specific concern.

The boring design is the reliable design

Good DHCP design is intentionally unexciting: clear address ranges, documented reservations, capacity headroom, a tested relay path, controlled server ports, and enough telemetry to distinguish a bad lease from a bad network. It also means testing a scope change with a sacrificial client before a broad rollout.

DHCP is foundational infrastructure. When it is designed as a small policy system instead of an address dispenser, clients join the network predictably and the inevitable failures become diagnosable rather than mysterious.

For more networking and systems notes, visit Slaptijack.