How to Use an IP Subnet Calculator for CIDR Planning and VLSM
Use an IP subnet calculator to turn an IPv4 address and prefix into network, broadcast, usable range, host count and mask — and plan address space with VLSM.
How to Use an IP Subnet Calculator for CIDR Planning and VLSM
Most subnetting mistakes I have seen at work were not arithmetic errors. They were off-by-one boundary slips: a DHCP pool that ran one address into the broadcast, a firewall rule that matched the network address as if it were a host, a VLAN plan where two /25s overlapped because someone counted the second block from the wrong offset. The math is simple once you write it down, but doing it in your head at 5pm before a maintenance window is how outages happen. A subnet calculator removes that whole class of error: you type an IP and a prefix, and it hands back every derived value at once.
This post is about the workflow — how to read what the calculator gives you, how the prefix length controls block size, and how to lay out address space cleanly with VLSM. If you just want the numbers, open the IP Subnet Calculator and paste a CIDR like 192.168.1.10/24.
What the calculator derives from an IP and a prefix
Give the tool two things — an address and a prefix length — and it returns the full picture for that block:
- Network address (all host bits zero): names the subnet in routing tables.
- Broadcast address (all host bits one): reaches every host on the segment.
- First and last usable host: the assignable range between those two.
- Usable host count and total address count.
- Subnet mask in dotted-decimal and binary.
- Wildcard mask: the bitwise inverse of the mask, for Cisco ACLs and OSPF.
- Class and scope: A–E, and whether the block is private RFC 1918, reserved, or public.
The key relationship to internalize is that the prefix length alone sets how many addresses a block holds. Each bit you give to the network half is a bit you take from the host half, so the size halves every time the prefix grows by one. A /24 holds 256 addresses (254 usable); a /25 holds 128, a /26 holds 64, a /27 holds 32. Two addresses in each block are always spoken for — the network and the broadcast — except at the two edges: a /31 reclaims both for a point-to-point link under RFC 3021, and a /32 is a single host route.
A worked example: 10.0.0.0/26
Say you need a subnet for a rack of servers and you want roughly 60 usable addresses. Type 10.0.0.0/26 into the calculator and it returns:
- Network address: 10.0.0.0
- Broadcast address: 10.0.0.63
- First usable host: 10.0.0.1
- Last usable host: 10.0.0.62
- Usable hosts: 62
- Total addresses: 64
- Subnet mask: 255.255.255.192
- Wildcard mask: 0.0.0.63
Walk through why. A /26 means 26 network bits and 6 host bits. Six host bits give 2^6 = 64 total addresses, numbered 0 through 63 within the block. Address 0 (10.0.0.0) is the network, address 63 (10.0.0.63) is the broadcast, and everything between — 10.0.0.1 to 10.0.0.62 — is yours, which is 62 usable hosts. The mask 255.255.255.192 comes from those 26 one-bits; that last 192 is 11000000, the two network bits inside the final octet. The wildcard 0.0.0.63 is simply the mask inverted. If your rack will not exceed 62 machines, a /26 fits with a little headroom and wastes nothing larger.
Sizing a block from a host count instead of a prefix
You do not always start from a prefix. Often you start from "I have 50 devices" and need the calculator to pick the prefix. Switch the tool to hosts per subnet, type 50, and it chooses the smallest block that fits: a /26, since /27 (30 usable) is too small and /26 (62 usable) is the next step up. This is the right instinct in practice — round up to the prefix that covers your count, then leave the spare addresses for growth rather than splitting hairs.
The trade-off is worth stating plainly, because it trips people up: a longer prefix gives you more subnets but fewer hosts each. Splitting a /24 into /26s gives you four subnets of 62 hosts; splitting into /27s gives you eight subnets of 30. The host bits are exactly what you spend to buy more subnets. There is no free lunch — decide whether you are short on subnets or short on hosts before you pick a prefix.
Planning address space with VLSM
Variable Length Subnet Masking (VLSM) is what lets you size each subnet to its actual need instead of cutting a parent into equal slices. A point-to-point link between two routers needs exactly two addresses, so it gets a /31 (or /30 if your gear predates RFC 3021). A user VLAN with 200 hosts needs a /24. Giving the router link a /24 would waste 252 addresses; giving the user VLAN a /30 would not fit. VLSM mixes prefixes inside one parent block.
The trick that keeps VLSM plans clean is to allocate largest-first. Carve out your big subnets at the start of the parent range, then fit the small ones into the gaps. If you allocate small blocks first, you fragment the space and end up unable to place a large subnet on a valid boundary later. Take a parent of 10.0.0.0/22 (1,024 addresses): place a /24 for the user VLAN at 10.0.0.0, another /24 at 10.0.1.0, a /26 for servers at 10.0.2.0, and /30s for router links starting at 10.0.3.0. The calculator's split-by-prefix view lists each child's network, range, and host count in a table, so you can read the boundaries instead of hand-counting offsets — which is precisely where the overlap bugs come from.
When I plan a new environment, I keep the calculator open in one tab and a plain text file of allocations in another. I paste each parent, split it, copy the child ranges I want, and record them with a one-line note about what they are for. It takes a few minutes and it has caught more than one boundary collision before it reached a config file. A side benefit: the inputs encode into the URL, so I can drop a share link into the ticket and a teammate sees the exact split I planned.
Verifying the boundaries before you commit
Before a subnet plan turns into config, two quick checks save grief. First, confirm your DHCP pool sits strictly inside the usable range — for a /24 that is .1 to .254 — and does not reach the gateway or the broadcast. Second, when you write a Cisco ACL or OSPF network statement, copy the wildcard mask, not the subnet mask; they are inverses, and pasting 255.255.255.0 where 0.0.0.255 belongs fails quietly rather than loudly.
If you are working from raw input — a config dump, a log file, a spreadsheet of addresses — it helps to clean the data first. The IPv4 Address Extractor pulls every address out of pasted text, and the IPv4 Address List Validator flags malformed or out-of-range entries before you feed them into a subnet plan. Pair those with the subnet calculator and the path from messy input to a verified address scheme is short.
Subnetting rewards a tool that shows its work. Type the IP and prefix, read the network and broadcast, trust the usable range, and spend your attention on the design instead of the arithmetic.
Made by Toolora · Updated 2026-06-13