What Is DHCP? Scopes, Reservations and Why It Fails

What is DHCP, in one minute?

DHCP can provide an IP address and, when configured, related settings such as the subnet mask, default gateway and DNS server addresses — rather than requiring someone to configure those values by hand on every laptop, phone and printer in the building.

Picture a small office router at 192.168.1.1 running a DHCP pool of 192.168.1.100 to 192.168.1.200. A laptop joins the Wi-Fi and requests an address; on a healthy local network it typically receives one quickly — say 192.168.1.142, a gateway of 192.168.1.1 for anything leaving the local network, and one or two DNS server addresses for looking up names — though the exact timing depends on the network and configuration. The laptop didn't need any of that typed in — it asked, and DHCP answered.

In most UK organisations DHCP is not something anyone buys separately. It's a feature already running inside the Windows Server install, the office firewall, the router from the broadband provider, or the managed network platform the business already owns. The work for IT isn't procurement — it's configuration governance: getting the scope, exclusions and reservations right, and keeping the DHCP service itself trustworthy.

What information DHCP actually gives your device

An IP address on its own doesn't get a device anywhere. DHCP's scope configuration bundles the address with the other settings a client needs: the subnet mask (which addresses count as "local"), the default gateway (where to send traffic bound for anywhere else), and one or more DNS server addresses.

That DNS setting is what lets a browser turn a typed name into something it can actually connect to — DHCP supplies the DNS server address, but it's a separate lookup process that does the resolving; see what DNS does for that half of the journey. DHCP is distinct again from routing, which physically moves the traffic once it's addressed, and from network access control, which decides whether a device is allowed onto the network at all. DHCP commonly supplies the settings those other services then use, but it doesn't perform their functions itself — DHCP is an application-layer configuration protocol, not the mechanism that routes packets or grants network access.

How DHCP works: the four-step DORA exchange

A device requesting an address runs through four steps, commonly shortened to DORA: Discover, Offer, Request, Acknowledge. The client broadcasts a Discover message for any DHCP server on the segment to answer; a server replies with an Offer containing a proposed address, lease length and settings; the client broadcasts a Request accepting that specific offer (broadcast again, in case more than one server replied); and the server sends an Acknowledge confirming the lease, at which point the client configures itself and starts using the address.

The exchange runs over UDP, with the client listening on port 68 and the server on port 67. Because Discover and Request are broadcasts, they don't cross a router boundary by default. If the DHCP server sits on a different subnet to the client — the normal setup once a network is segmented with VLANs — the router or switch in between has to run a DHCP relay (also called an IP helper) to forward messages both ways. Without that relay configured on every VLAN that needs it, devices on the far side simply never see an Offer.

Scope, pool, exclusion, lease, reservation and static IP — what each term actually means

These words get used loosely, but each does a distinct job. Microsoft's documentation defines a scope as the administrative grouping of IP addresses and TCP/IP configuration parameters a DHCP server can lease to clients on a specific subnet. A DHCP scope normally corresponds to one IP subnet; clients on remote subnets can reach the server through a DHCP relay. A scope is built from an address range, subnet mask, scope name, lease-duration values and optional exclusions and reservations.

Within that scope, the pool is the set of addresses actually available for dynamic handout once exclusions are removed. An exclusion is a specific address or range withheld from dynamic allocation, typically because something outside DHCP already uses it. A lease is the time a client may keep an address before it must renew — configurable per scope, with Microsoft's documented Windows default sitting at eight days, versus a 16–24 day example Microsoft gives for larger routed networks. A reservation normally associates an address with a device's NIC identity—commonly its MAC address, or a DHCP client identifier—so it can receive the same address through DHCP — it is still a DHCP client issuing a DHCP request, just one with a predictable outcome. For the relevant interface, a static IP is configured locally rather than leased from DHCP; the device does not need DHCP to obtain that address.

Worked example: sizing a DHCP scope for a UK small office

Take a conventional /24 network, 192.168.10.0/24. In this conventional IPv4 /24 example, there are 256 addresses. Two of those are set aside by IPv4 subnetting convention: .0 (192.168.10.0) as the network address and .255 as the broadcast address, leaving 254 usable host addresses before anything else is subtracted. Use a subnet calculator to check this arithmetic for any range you're planning.

A sensible small-office split: .1–.20 (20 addresses) covers the gateway plus wired infrastructure — switches, access points, the firewall, the server — configured outside DHCP as exclusions. .21–.50 (30 addresses) is withheld specifically for reservations: the networked printer, the NAS, VoIP handset bases, meeting-room screens — devices that need a predictable address but should still be managed through DHCP. When the reserved addresses are correctly excluded from the dynamic pool or otherwise protected by the DHCP implementation, they do not compete with ordinary dynamic clients. That leaves .51–.254 — 204 addresses — as the dynamic pool, available for laptops, phones, tablets and anything else that just needs to connect. Twenty infrastructure addresses, plus 30 reservations, plus 204 dynamic addresses, adds back up to the full 254 usable host addresses in the /24.

• •Static IP: router/gateway, firewall, the DHCP server's own interface, core switch management addresses
• •Reservation: printers, NAS, VoIP handsets, access points, meeting-room screens
• •Dynamic pool lease: laptops, desktops, phones, tablets, visiting and guest devices

DHCP versus static IP: which devices should use which

The decision follows from whether a device needs to exist before DHCP does, and whether it benefits from central management if settings ever change. Infrastructure interfaces — the router, firewall, and the DHCP server's own management interface — often use static addressing or reservations, but the appropriate choice depends on the platform, interface and network design; some platforms do support dynamic uplink addressing.

Reservations are usually the better fit for printers, NAS devices, VoIP handsets and access points. Microsoft recommends reservations rather than infinite lease durations for devices needing a consistent address; because a reservation is still delivered via a renewing DHCP lease, it can also pick up centrally changed settings like gateway or DNS at the next renewal, unlike a manually typed static IP. Laptops, desktops, phones, tablets and guest devices belong in the ordinary dynamic pool — they have no need for a fixed address at all.

One caveat: reservations are tied to a device's NIC MAC address, so replacing that network adapter — or configuring more than one DHCP server able to answer the same client — can mean the reservation stops applying unless it's re-created or, per Microsoft's guidance for multi-server setups, duplicated on every DHCP server that could serve that client.

DHCP in UK deployments: home routers, small offices, Windows Server and Linux

A UK home broadband router typically runs its own small built-in DHCP scope out of the box, handing addresses to whatever connects to the home network without any configuration. UK small and mid-size offices usually run DHCP from one of a small number of existing platforms rather than a standalone purchase: Windows Server's DHCP role, where scopes, exclusions and reservations are set up through the console described in Microsoft's documentation; a firewall or managed router with a built-in DHCP service; or a Linux-based network appliance running its own DHCP service.

For UK IT buyers, the real decision isn't which product to buy — DHCP comes bundled with infrastructure already owned — it's resilient design. That means correctly sized per-subnet scopes, documented reservations rather than ad hoc static IPs scattered across the estate, DHCP relay configured on every VLAN that needs it, switch-level controls against rogue servers, and failover between DHCP servers. It also means testing renewal behaviour during a planned maintenance window, rather than discovering a misconfiguration only when the default lease period quietly runs out and devices start failing one at a time. See network security for the broader segmentation and access-control context this sits inside.

Hybrid estates add another layer: cloud virtual networks typically include their own built-in DHCP-equivalent address assignment for instances — Azure Virtual Network, AWS VPC and VMware environments each handle this through the cloud platform itself, separately from the on-prem scopes described above. For IT buyers managing a mix of on-prem and cloud infrastructure, that means addressing and scope planning has to account for both sides of the hybrid boundary, not just the physical office network.

Troubleshooting DHCP failures, 169.254.x.x and rogue servers

If the authorised DHCP service becomes unreachable, devices don't fail in unison. Each one keeps using its existing lease until that specific lease comes up for renewal, then fails to get a reply. Because leases were obtained at different times, the timing is staggered — the classic DHCP incident looks like one device at a time losing connectivity over hours, not a single outage moment, which is exactly what makes it confusing to diagnose from the first few help-desk calls.

A 169.254.x.x address commonly indicates that IPv4 configuration via DHCP was unavailable or unusable; check the interface, DHCP reachability and any other active configuration before identifying the cause. An address from the wrong subnet, or intermittent duplicate-address warnings, can point to a rogue or misconfigured DHCP server answering ahead of the legitimate one, but check VLAN, relay and scope configuration first before assuming a second server is to blame. When a scope's dynamic pool is exhausted, new clients simply can't get an address from it, while existing clients may carry on until their own renewal falls due.

Where supported and correctly configured, DHCP snooping can help block unauthorised DHCP servers and validate DHCP traffic at the switch: Cisco describes it as acting like a firewall between untrusted hosts and trusted DHCP servers, validating DHCP messages from untrusted ports and building a binding database of leased addresses to check future requests against. In the cited Cisco implementation, the binding is removed when the lease expires or the switch receives DHCPRELEASE; behaviour varies by platform, so binding tables should be treated as a recent record rather than a live, second-by-second one. For resilience rather than security, Windows DHCP failover in hot-standby mode reserves 5% of the active server's addresses for the standby by default, and if the standby loses contact with the active server it can still renew a client's existing address, granting a new lease for the shorter maximum client lead time rather than the scope's full lease duration — enough to keep devices online without silently extending a failed primary indefinitely.

• •DHCP server failure: existing clients keep working until their lease comes up for renewal; new and renewing clients then fail across the affected scope
• •Relay/VLAN failure: clients on a remote subnet never see an Offer at all, because Discover and Request broadcasts don't cross a router without a configured relay
• •Exhausted scope: new clients get no address from the pool, while already-leased clients continue working until their own renewal
• •Rogue DHCP: clients get addresses from the wrong subnet, duplicate-address warnings appear, or gateway/DNS settings don't match the legitimate scope
• •Client-side fault: a single device shows a 169.254.x.x address or can't renew while others on the same segment work normally, pointing at that device's interface rather than the service

The practical verdict

The practical verdict for a UK office: document every subnet and scope rather than trusting memory; use reservations, not infinite leases, for anything that needs a stable address; configure relay on every VLAN that needs it; mark only the legitimate server or relay ports as trusted for DHCP snooping; and if uptime matters, test failover and renewal behaviour deliberately in a maintenance window rather than finding out what the lease period actually does the hard way.

Sources

Every figure in this article traces to the sources below.

• •Microsoft Learn — defines a DHCP scope and its administrative grouping of addresses
• •Microsoft Learn — scope components: address range, exclusions, subnet mask, lease values
• •Microsoft Learn — DHCP overview, address pool and the staggered-lease failure pattern
• •Microsoft Learn — eight-day default lease duration and infinite-lease stranded-address risk
• •Microsoft Learn — 16–24 day lease example for larger routed networks
• •Microsoft Learn — reservation defined as server-side MAC binding, distinct from static IP
• •Microsoft Learn — hot-standby failover's 5% default address reserve and MCLT renewal
• •Cisco — DHCP snooping as a firewall between untrusted hosts and trusted servers
• •Cisco — DHCP snooping binding removal at lease expiry or DHCPRELEASE