Build the idea first, then use the next activity to check it.
Scopes, options and exclusions
What a DHCP server is actually configured with - the range it hands out, the addresses it must never hand out, and the settings that travel with every lease.
What you will be able to do
- Size a DHCP scope against a subnet and its fixed addresses
- Explain why exclusions exist and what breaks without them
- Identify which lease option is wrong from the symptom a host reports
Before this: You need "DHCP - addresses without configuring them" for the four-message exchange, and subnet masks for sizing a scope.
Why it matters: Most DHCP faults in production are not the server being down - a dead server is obvious within minutes. They are a scope that overlaps something static, or an option carrying the wrong value, and both hand out addresses happily while leaving hosts unable to reach anything.
A DHCP server is not simply "on". It is configured with a scope - the range of addresses it may hand out - plus a set of options that ride along with every lease. Get the range wrong and two devices end up fighting over one address. Get an option wrong and every host on the subnet is misconfigured at once, identically, which is a fault that looks nothing like a DHCP problem.
A scope is a range inside a subnet
The scope always sits inside one subnet, and it is almost never the whole subnet. The network and broadcast addresses are unusable, the router holds at least one address, and anything with a fixed address - switches, printers, servers - occupies more.
Sizing a scope
A /24 at 10.20.30.0 has 254 usable addresses. The router takes 10.20.30.1. Two switches and a printer take .2, .3 and .10. A scope of 10.20.30.100 - 10.20.30.200 leaves all of those alone and still serves 101 clients.
Exclusions
An exclusion is a hole punched in a scope: a range the server owns but must never lease. You want one whenever the static addresses are scattered through the range rather than tidily below it, which is the normal state of a network that has been running for a few years.
- A reservation ties one address to one client's MAC - the client still uses DHCP, it just always gets the same answer.
- An exclusion removes an address from the pool entirely - nothing is leased there, and whatever holds it is configured by hand.
- Getting these the wrong way round is common - a reservation for a device configured statically achieves nothing at all.
The options are the part that breaks quietly
| Option | What it sets | Symptom when wrong |
|---|---|---|
| Router (3) | Default gateway | Local traffic works, everything off-subnet fails |
| DNS servers (6) | Resolvers the client uses | Addresses work, names do not |
| Domain name (15) | Search suffix | Short names fail, fully-qualified ones work |
| Lease time (51) | How long before renewal | Addresses churn, or stale ones linger |
Every one of these is handed to every client on the subnet. That is what makes a wrong option so misleading: the fault appears on every host at once, which looks far more like a routing or a DNS outage than a client-configuration problem.
Lease time is a trade
A short lease reclaims addresses quickly, which matters on a guest network where devices come and go. A long lease means less traffic and more stability, which matters on a floor of desktops that never move. The cost of a long lease is that a change to an option takes until renewal to reach every client.
Key takeaways
- A scope is a range inside a subnet, and never the whole subnet.
- Exclusions remove addresses from the pool; reservations pin one address to one client that still uses DHCP.
- A wrong option misconfigures every client at once, which disguises itself as a routing or DNS fault.
- Lease time trades address reclamation against how fast an option change propagates.
Ready to keep going?
Create a free account to save your progress and take the knowledge check.