DHCP Configuration

Reservations & Exclusions: Keep DHCP Predictable

DHCP works best when addressing is boring: infrastructure stays stable, clients get predictable configuration, and IP conflicts are rare. Reservations and exclusions are the tools that make that happen—without falling back to “random static IPs everywhere.”

After this page, you should be able to:

  • Define exclusions vs reservations (and how they differ from static IPs)
  • Choose the right approach for printers, servers, IoT, and special devices
  • Use exclusions to protect the dynamic pool and reduce IP conflicts
  • Diagnose common “it worked yesterday” addressing failures after swaps/reimages
  • Verify reservations/conflicts quickly from a Windows client

Definitions (High Signal)

Exclusion

Removes addresses from the dynamic pool so DHCP will never lease them.

Reservation

Assigns a specific IP to a specific device (MAC/client-id), but the device is still DHCP-managed.

Static IP

Manually configured on the device. DHCP doesn’t “own” it and won’t automatically coordinate around it.

Think of it this way: exclusions protect space, reservations protect identity, and static IPs bypass DHCP.

When to Use What (Decision Guide)

Rule of thumb:

Keep infrastructure stable, keep clients dynamic. Use DHCP to manage as much as you reasonably can.

Use a reservation when…

  • The device should always have the same IP
  • You still want DHCP to deliver gateway/DNS/options
  • You want the lease table to show ownership
  • Examples: printers, scanners, fixed IoT, special systems

Use a static IP when…

  • The device can’t use DHCP reliably (rare)
  • You have strict infrastructure standards (core routers/firewalls)
  • You’re prepared to document and maintain it manually

If you use static IPs, keep them outside the DHCP pool and document them.

Exclusions are for pool safety:

If a set of IPs should never be leased dynamically (infrastructure block, special range), exclude them. Exclusions are often the “guard rails” that prevent accidental conflicts.

Common Patterns & Best Practices

1) Keep infrastructure outside the dynamic pool

Put routers/switch management/servers in a defined “infra” block and exclude it from DHCP. This makes it hard to accidentally configure a static device inside the dynamic pool.

2) Prefer reservations over “random statics” for special devices

Reservations keep devices predictable while still allowing centralized updates (gateway/DNS changes, etc.).

3) Document ownership

IPs are a shared resource. Track why an address is reserved, who owns the device, and what should happen when the device is replaced.

Practical warning:

The fastest way to create IP conflicts is a static IP inside the dynamic pool. The second fastest is cloning VMs with duplicate MAC addresses.

Risks & Failure Modes

  • Duplicate IP conflicts: a static device (or cloned VM) uses an address DHCP also leases.
  • Reservation drift: hardware gets replaced, but the reservation still points at the old MAC.
  • Rogue DHCP vs static conflict: both can look like “random bad settings,” but the fix differs.
  • “Worked yesterday” after reimage/swap: new NIC/MAC means the reservation no longer matches.

Troubleshooting: What You Observe → What It Usually Means

IP conflict / duplicate address detected

What you observe: Random drops, “duplicate IP” warnings, ARP weirdness.

What it usually means: A static IP is inside the DHCP pool, or you have duplicate MACs (VM clones).

  • What to check next: pool boundaries/exclusions; arp -a; look for cloned MACs

Client not getting the reserved IP

What you observe: Device gets a “random” address instead of the expected one.

What it usually means: Reservation is tied to the wrong MAC/client-id, or the device is getting a lease from a different DHCP server.

  • What to check next: client MAC; DHCP Server in ipconfig /all; reservation entry

Printer/IoT replaced → the “same” device doesn’t work

What you observe: Old IP is “reserved,” but the new hardware doesn’t get it.

What it usually means: The reservation still points to the old NIC/MAC address (reservation drift).

  • What to check next: update reservation MAC; force renew; validate device NIC/MAC

Statically set gateway/DNS causes “weird” behavior

What you observe: Device has the “right” IP but can’t reach expected resources; differs from other clients.

What it usually means: Someone hardcoded gateway/DNS (static config) so the device ignores DHCP options.

  • What to check next: ensure DHCP enabled; compare options vs a working client

DHCP handed out an address that “should be static”

What you observe: A client received an IP that you expected to be reserved/infra.

What it usually means: That address range was never excluded, or exclusions were configured in the wrong scope.

  • What to check next: exclusions for the scope; pool start/end; verify scope identity

Scope exhaustion feels worse than expected

What you observe: “No free addresses” sooner than your headcount suggests.

What it usually means: Pool is smaller than intended due to exclusions/reservations, or lease duration is too long for churn.

  • What to check next: scope available count; excluded ranges; lease duration; guest churn

VM clones with identical MACs cause collisions

What you observe: Two “different” machines keep stealing each other’s connectivity.

What it usually means: Cloned VM images reused a MAC/client-id, confusing both DHCP and ARP tables.

  • What to check next: confirm unique MACs; clear leases if needed; update reservations

Multiple DHCP servers interacting badly with reservations (high level)

What you observe: Some clients respect reservations, others don’t; DHCP Server differs by device.

What it usually means: A rogue/secondary DHCP server is issuing leases without your reservation/exclusion strategy.

  • What to check next: DHCP Server field across clients; scan for unauthorized DHCP responders

Hands-on: Verify Reservations / Conflicts from Windows

Check current addressing and DHCP server:

ipconfig /all

Look at: DHCP Enabled, DHCP Server, IPv4 Address, Default Gateway, DNS Servers, and Physical Address.

Find MAC address (alternate):

getmac /v

Force a new lease (useful after changing reservations):

ipconfig /release
ipconfig /renew

Optional: inspect ARP table (conflict hunting):

arp -a

If you suspect a conflict, ARP can help show which MAC is claiming an IP right now.

Where to see DHCP client logs (Windows)

Event Viewer → Applications and Services Logs → Microsoft → Windows → DHCP-Client → Operational

Server-Side Visibility (Brief)

Reservations and exclusions live inside the scope. Leases show who currently holds what address. When you’re debugging conflicts, the lease table plus the ARP table often tells the full story.

Windows DHCP: Scopes → Address Pool (exclusions), Reservations, and Address Leases.

Next Up: Leases & Options (Why This Isn’t Instant)

A reservation still uses leases—the client may not immediately pick up changes until renewal (or until you force a release/renew). Also, reservations can include device-specific options(useful when one device needs special DNS/gateway/boot settings). Keep these relationships in mind when you troubleshoot “it still has the old settings.”

Key Takeaways

  • Exclusions protect address space so DHCP never leases infrastructure/special ranges.
  • Reservations protect identity so a specific device reliably gets a specific IP (DHCP-managed).
  • Static IPs bypass DHCP—use them intentionally and keep them out of the dynamic pool.
  • Most IP conflicts come from pool overlap (statics in the pool) or duplicate MACs (VM clones).
  • When a reservation “stops working,” suspect a changed MAC or a different DHCP server.
  • Verify from the client first: DHCP Server + MAC + IP + gateway/DNS tell you what’s really happening.

If you keep your pools clean and your special devices managed through reservations, DHCP becomes predictable—and “random networking weirdness” becomes rare.