DHCP Configuration

Addressing & Scopes: Designing DHCP That Works

Scopes are where DHCP stops being “magic IP giver” and becomes intentional network design. A well-built scope matches a subnet, hands out a safe address pool, and provides the minimum settings clients need to function.

After this page, you should be able to:

  • Explain what a DHCP scope is (and what it contains at a high level)
  • Apply the “one subnet = one scope” rule to real VLAN/L3 designs
  • Design an address pool that avoids conflicts and leaves room for infrastructure
  • Choose a reasonable lease duration for stable vs high-churn networks
  • Troubleshoot scope-related failures using a “what you observe → what it means” lens
  • Verify what DHCP actually delivered using basic Windows client commands

What a DHCP Scope Is

A DHCP scope is a “rule set” for one subnet. It tells the DHCP server what addresses it is allowed to lease, how long those leases last, and what basic network settings should be handed to clients on that network.

A scope typically contains:

  • Subnet definition (network + mask)
  • Address pool (start/end range to lease)
  • Lease duration (how long a client “owns” an address)
  • Options (gateway, DNS, domain/search suffix, etc.)
  • Exceptions (exclusions/reservations to keep addressing predictable)

If clients can’t get a lease, or get a lease that doesn’t work, it’s almost always because the scope doesn’t match reality: wrong subnet, wrong pool design, or wrong options.

The Golden Rule: One Subnet = One Scope

DHCP is subnet-aware. Each VLAN (or Layer-3 segment) should have exactly one matching scope. That’s how clients on different networks get the correct gateway, DNS, and addressing.

What “match the subnet” means

  • Scope network: 10.10.20.0
  • Mask: /24 (255.255.255.0)
  • Gateway option: 10.10.20.1 (the L3 gateway for that VLAN)
  • Pool: addresses that are valid on 10.10.20.0/24

Why this matters operationally

  • Clients only accept a configuration that fits their subnet
  • Wrong gateway/DNS makes the network “look down” even if DHCP succeeded
  • “Discover but no Offer” often means the server can’t find a matching scope
  • If the server isn’t local, you need DHCP relay on the L3 boundary

Critical Design Rule:

Your scope’s subnet and mask must match the client VLAN/subnet exactly. If they don’t, either the client won’t get an offer, or it will get an IP that can’t communicate correctly.

Designing the Address Pool (Range)

The pool is the set of addresses the server is allowed to hand out. Good pool design keeps your infrastructure predictable and prevents accidental IP conflicts.

Example pattern (10.10.20.0/24):

Gateway / Infra: 10.10.20.1 - 10.10.20.49
DHCP Pool:       10.10.20.50 - 10.10.20.199
Reserved Growth: 10.10.20.200 - 10.10.20.254

How big should the pool be?

Size for peak usage, not average. Count users/devices, add headroom, and remember that phones, tablets, and IoT add up fast.

Leave space for infrastructure

Keep routers, switches, servers, and management IPs out of the dynamic pool so they remain stable and easy to document.

Avoid conflicts by design

Conflicts happen when “static” devices use addresses inside the DHCP pool. Your pool design should make that hard to do accidentally.

Lease Duration (High Level)

Lease duration controls how long a client keeps an address before it must renew. This is a balancing act between stability and reclaiming addresses quickly.

Rule of thumb:

  • Stable office LAN: longer leases (reduces churn/renew traffic)
  • Guest Wi-Fi / high churn: shorter leases (frees addresses faster)
  • Too long: exhausted scopes linger longer when devices leave
  • Too short: more frequent renewals (usually fine, but noisy at scale)

Two Concepts You’ll Use Constantly (But We’ll Deep Dive Later)

Scopes are the container. These two ideas are the knobs you’ll turn to make DHCP predictable: options (what settings clients receive) and exceptions (which clients/addresses should behave differently).

Reservations & Exclusions (high level)

Use exclusions to keep parts of the subnet out of the dynamic pool. Use reservations when a specific device should always get the same address while still being managed by DHCP.

Examples: printers, scanners, fixed IoT, and devices that must be reachable by a known IP.

DHCP Options (high level)

Options are the “directions” clients need to use the network. The most important ones are default gateway and DNS servers.

  • Default Gateway
  • DNS Servers
  • DNS Domain / Search Suffix
  • Time/NTP (sometimes)
  • PXE/Boot options (in imaging environments)

Next up (deep dives):

  • Reservations & Exclusions: workflows, best practices, and avoiding IP conflicts at scale
  • DHCP Options: which options matter most, how bad options break networks, and how to troubleshoot them

Troubleshooting Lens: What You Observe → What It Usually Means

Most “DHCP issues” are really scope issues. Use the client symptoms to narrow down whether you’re failing to get an offer (scope match/relay/reachability) or getting an IP that doesn’t work (bad options / wrong subnet design).

Discover/renew attempts, but no Offer (or renew hangs)

What you observe: Client can’t get a lease; may fall back to 169.254.x.x.

What it usually means: No matching scope for that subnet, scope inactive, relay missing/misconfigured, or DHCP server unreachable.

Client gets an IP, but “nothing works”

What you observe: IP assigned, but can’t reach internet or internal resources; DNS fails.

What it usually means: Bad DHCP options (wrong gateway/DNS), or wrong mask causing the client to think things are “local” when they aren’t.

Only some clients get addresses (intermittent failures)

What you observe: A few devices work, others time out or get APIPA.

What it usually means: Scope exhaustion, inconsistent relay targets, multiple DHCP servers, or filtering/security rules affecting some paths.

IP conflicts / “duplicate address detected” behavior

What you observe: Random drops, ARP weirdness, conflict warnings, devices “steal” connectivity.

What it usually means: Static devices inside the dynamic pool; pool design doesn’t separate infrastructure from clients; missing exclusions/reservations strategy.

Scope “looks configured” but clients still don’t get leases

What you observe: Server is up, but no one gets an address.

What it usually means: Scope inactive, server not authorized (common in AD environments), or the scope subnet doesn’t match the client VLAN.

Hands-on: Verify What DHCP Actually Delivered (Windows)

1) Check current configuration:

ipconfig /all

Fields to check: DHCP Enabled, IPv4 Address, Subnet Mask, Default Gateway, DNS Servers, DHCP Server, and Lease Obtained/Expires.

2) Force a fresh lease (tests Offer/Ack path):

ipconfig /release
ipconfig /renew

If renew hangs or fails, you’re likely in “Discover but no Offer” territory (scope match/relay/reachability).

Key Takeaways

  • A scope is the rule set for one subnet: pool + lease duration + options (and exceptions)
  • One subnet = one scope — scopes should map cleanly to VLAN/L3 boundaries
  • Pool design prevents conflicts: keep infrastructure outside the dynamic range and leave headroom
  • Lease duration is a tradeoff: stable networks prefer longer; high-churn networks prefer shorter
  • “Got an IP but nothing works” is usually bad options (gateway/DNS/mask), not “DHCP is down”
  • “Discover but no Offer” points to scope match, scope state, relay, or reachability
  • Verify from the client first: ipconfig /all tells you exactly what DHCP delivered

If you can design a clean pool and map one scope per subnet, you’ve solved most DHCP problems before they happen. Next, we’ll go deeper on the two areas that most commonly “break” networks: DHCP options and reservations/exclusions.