redzilla
All tools
IP Addressing

DHCP Scope

Enter the subnet, where the gateway sits and how many addresses you reserve or exclude, and get the usable DHCP pool, the projected client demand and whether it fits (the 80 % rule). Pure subnet arithmetic, nothing is sent to any server.

Network address and prefix, e.g. 192.168.1.0/24.

The gateway takes 1 usable address and leaves the pool.

Servers, switches, APs, printers with a fixed IP outside the DHCP range.

A fixed IP handed out by DHCP to a specific MAC. Consumes pool.

Devices that will request a dynamic IP at the same time.

Headroom for growth and guests. Typical 2030 %.

Examples
redzilla.cl — dhcp
 

Usable addresses
DHCP pool size
after gateway, exclusions and reservations
Projected demand
clients + growth
Pool usage
demand / pool

DHCP pool usage

0 / 0 0 %

Rule of thumb: keep usage under 80 % for lease headroom.

How the subnet is split

ItemAddressesNote
How it is calculated · pool and demand

1. Total addresses = 2^(32 − prefix). Usable = total − 2 (network and broadcast removed). Special cases: /31 = 2 (RFC 3021) and /32 = 1.

2. DHCP pool = usable − gateway (1 if applicable) − excluded − reservations.

3. Demand = clients × (1 + growth/100), rounded up.

4. Usage = demand / pool × 100. Verdict: sufficient if the pool covers demand with headroom, tight if usage exceeds 80 % and insufficient if demand exceeds the pool.

Runs locally in your browser · no sign-up · nothing leaves your browser

How it works

The calculator takes a subnet in CIDR notation (for example 192.168.1.0/24) and works out how many addresses are actually available for the DHCP pool: it starts from the usable ones (2^(32 − prefix) − 2, with the special cases /31 = 2 per RFC 3021 and /32 = 1) and subtracts the gateway (if it takes an address), the addresses excluded for statically configured devices, and DHCP reservations by MAC, which also consume pool.

With the pool resolved, it compares against the projected demand: demand = clients × (1 + growth/100), rounded up. Pool usage is demand / pool × 100 and the verdict applies the practical 80 % rule: sufficient when there is headroom, tight when usage exceeds 80 % and insufficient when demand exceeds the pool. Keeping margin prevents lease exhaustion with guests and new devices.

Example: office with 192.168.1.0/24 and 120 clients

  1. Usable: 2^(32−24) − 2 = 254 addresses.
  2. DHCP pool: 254 − 1 (gateway) − 5 (excluded) − 10 (reservations) = 238 addresses.
  3. Demand with 20 % growth: 120 × 1.2 = 144 projected clients.
  4. Usage: 144 / 238 ≈ 60 %sufficient, under the 80 % rule.

Frequently asked questions

How many DHCP addresses does a /24 have in practice?
A /24 provides 254 usable addresses, but the real pool is smaller: you must subtract the gateway, the static IPs of servers, switches, APs and printers, and the MAC reservations. In a typical office the pool ends up between 200 and 240 addresses.
What happens if the DHCP pool runs out?
New clients get no IP address and are left off the network (in IPv4 they usually self-assign a non-routable APIPA 169.254.x.x address). That is why the calculator applies the 80 % rule: if projected usage exceeds it, consider growing the subnet (for example from /24 to /23), shortening the lease time or cleaning up exclusions.
What is the difference between a DHCP exclusion and a reservation?
An exclusion is a range the DHCP server never hands out: static IPs are configured there by hand (infrastructure). A reservation is a pool IP the server always gives to the same MAC: the device still uses DHCP but receives a fixed address. Both reduce the addresses available to dynamic clients.
Does the calculator send my subnet to any server?
No. It is pure subnet arithmetic executed in your browser: you can use it with your internal network addressing without exposing any data.
Was this tool useful?
Disclaimer We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.
Found an error? Let us know →