DHCP Allocation Logic

Because a client booting on a network has no identity (no IP, no Gateway), it must rely on Layer 2 broadcasts to find its way. This is the **DORA** handshake—a carefully choreographed sequence of UDP packets on ports 67 (Server) and 68 (Client).

Routers drop broadcasts by design. This means a DHCP server in the data center can't hear a 'Discover' packet from a branch office laptop. We use the **DHCP Relay Agent** (often called `ip helper-address`) to solve this.

In an enterprise, you can't have a single point of failure. DHCP servers operate in pairs using the DHCP Failover Protocol.

A single DHCP server rarely serves a single subnet. In a campus with 200 VLANs, every subnet needs a relay, and the way those relays are configured determines how quickly a fault surfaces. The common pattern is one `ip helper-address` per interface pointing at the primary server and a second pointing at the failover partner. The relay rewrites the packet's source address to its own interface address and inserts the **GIADDR** so the server can select the correct scope. A subtlety of RFC 3046 is that the relay must be enabled on the **client-facing** VLAN, not the server-facing trunk; misplacing it silently black-holes discovers for an entire subnet. When scopes are large, the relay becomes the scaling bottleneck, and the server side must be tuned to the request rate: a busy campus can generate 200-400 DORA cycles per second at peak, each requiring a lease-table lookup and a reply.

Design patterns reduce the blast radius of a relay failure. The **redundant relay** pattern puts two access switches on the same VLAN forwarding discovers, and the server de-duplicates identical XIDs. The **segmentation** pattern splits broadcast-heavy subnets so a DHCP storm in one department cannot consume the relay CPU of the whole building. The **security** pattern pairs every relay with DHCP snooping on the access layer, ensuring only trusted relays can inject GIADDR information. These patterns are explored in the DHCP mechanics deep-dive, and the address math behind scope sizing belongs to subnetting. Without deliberate relay design, the DORA handshake works perfectly in the lab and collapses precisely when it is needed most: during a network-wide reboot after a power event.

Pool exhaustion is the second most common DHCP failure after rogue servers, and it is almost always a subnet-math problem. A /24 scope has 256 addresses, but the network address, broadcast address, gateway, and a handful of server reservations consume the first 5-10, leaving 246-251 usable. If a building has 240 employees, 20 printers, and 15 access points all leasing from the same /24, the pool is mathematically oversubscribed before anyone plugs in a laptop. The engineering rule is to size pools against the **peak concurrent count**, not the device inventory, and to add 25% headroom for transient leases. In high-churn Wi-Fi environments, a 30-minute lease allows roughly 48 leases per address per day, so a single /24 can serve about 12,000 unique devices per day even though only 250 exist at any instant.

Subnetting decisions upstream determine how much headroom DHCP has. Aggregating scopes into a larger block—a /22 instead of four /24s—lets a dynamic pool borrow across department boundaries when a sales visit swells one VLAN. Conversely, over-tight scopes create the failure mode where the DHCP server is healthy, the relay is healthy, and the client still receives NAK after NAK because the pool is empty. Monitoring the **utilization per scope** and alerting at 80% is the minimum baseline; automated scope growth is better. The complete address-planning methodology is covered in the subnetting deep dive, and the interactive IPv4 subnetting tool lets you compute usable host counts and pool sizes before committing the plan.

DHCP exists because IPv4 addresses are scarce and hand-configuration does not scale, but the protocol only manages a slice of the lifecycle. Before the client can even send a Discover, the link must carry Ethernet frames—the MAC-to-IP relationship is the foundation examined in IPv4 mechanics. And after the client receives its lease, address resolution, routing, and DNS take over. The lease itself is a contract among the client, the server, and the network state the server recorded. When a laptop suspends for a week and returns, it renews from T1; when a device is moved between VLANs, the old lease must expire before the new scope can be used, which is why port-security and snooping bindings must be cleared on the switch, not just on the server.

The lifecycle view also explains why reservations and static IPs coexist. A printer or an IP camera needs a stable address; rather than statically configuring it (which defeats centralized management), the engineer creates a **reservation** keyed to the device MAC. The server guarantees that MAC always receives the same lease, giving the determinism of static addressing with the manageability of DHCP. The full state machine—every timer, every transition, every failure path—is dissected in DHCP mechanics, and the subnetting patterns that give the pools room to operate are covered in the subnetting deep dive. Together they form the complete allocation logic this article deconstructs.