| {{ col.label }} | |||||||
|---|---|---|---|---|---|---|---|
| {{ row.hosts }} | {{ row.cidr }} | {{ row.network }} | {{ row.first }} | {{ row.last }} | {{ row.broadcast }} | {{ row.notes }} | |
| auto | auto | auto | auto | auto |
| {{ col.label }} | Copy |
|---|---|
| No allocations yet. | |
| {{ row[col.key] }} |
IPv4 subnet planning is the work of dividing one address block into smaller, contiguous ranges that can be routed and documented cleanly. The stakes are practical: if a segment is too small, it runs out of room early, and if it is too large, valuable address space disappears into padding.
This planner turns that arithmetic into an allocation plan. Starting from a parent block, it sizes each requested segment to the smallest aligned CIDR range that fits, then shows the resulting network, first usable address, last usable address, broadcast address, and remaining usable capacity.
That is useful when you already know the rough shape of a rollout but still need dependable boundaries. A small office might split a /24 into one user VLAN, one voice segment, a point-to-point link, and a few reserved pockets for later growth. The tool lets you test that layout in the order you expect to assign it, rather than doing the binary math by hand.
The result is a planning view, not a routing policy engine. A syntactically valid block can still be the wrong choice if it belongs to a special-purpose range, conflicts with an existing design, or should be summarized differently inside your network.
Order also matters. The planner always places the next request at the next valid boundary after the highest address already assigned, so it behaves like a forward allocation worksheet rather than a compactor that repacks earlier gaps.
In day-to-day work, the most reliable habit is to enter the largest segments first. Because CIDR blocks grow in powers of two, a request that is only slightly larger than the previous one can force the next boundary up to a much bigger range. Leading with the biggest demands keeps the plan easier to read and usually wastes less address space.
The planner is strongest when you already know the approximate host demand for each segment but want help turning those counts into aligned ranges. It is especially handy for branch-office rollouts, lab networks, migration worksheets, and staged cutovers where you need a clean list of first and last usable addresses for documentation.
Use the notes field for human context such as voice, transit, or printers, then filter the plan to isolate one family of subnets later. The notes are only labels. They do not affect sizing, summarization, or overlap checks.
This is less suitable for answering policy questions such as whether a range is publicly routable, whether a specific provider will accept a given prefix length, or whether an address pool should be aggregated differently for routing advertisements. Those choices still need external validation.
The package treats IPv4 addresses as unsigned 32-bit integers. It parses the parent network, applies the selected prefix mask, derives the canonical network and broadcast boundaries, and computes the first and last usable addresses from that normalized block. The parent selector exposed by the app runs from /8 through /31.
Each requested host count is converted to the smallest block that can hold it. For counts of three or more, the planner adds two addresses for the traditional network and broadcast positions, then rounds up to the next power of two. That power-of-two size determines the derived prefix length and the exact boundary the next subnet must start on.
The allocation step is sequential. The script finds the highest broadcast address already assigned, advances one address beyond it, then aligns the new request to the next legal boundary relative to the parent network. If the proposed broadcast address would extend past the parent block, the tool raises the Not enough space for that subnet error.
Two edge cases are handled explicitly. A /31 row is treated as having two usable addresses, matching point-to-point practice described in RFC 3021, while a /32 row is treated as a single usable address. Everything else uses the familiar usable-host rule of total addresses minus two.
The sizing logic can be summarized as follows.
| Requested Hosts | Derived Prefix | Usable Addresses | Why It Lands There |
|---|---|---|---|
| 1 | /32 | 1 | Single-address outcome with no separate network and broadcast positions. |
| 2 | /31 | 2 | Point-to-point style treatment, using both addresses. |
| 3 to 6 | /29 | 6 | Eight total addresses are needed after rounding up. |
| 7 to 14 | /28 | 14 | Sixteen total addresses fit the request plus two reserved positions. |
| 15 to 30 | /27 | 30 | Thirty-two total addresses are the next aligned size. |
| 31 to 62 | /26 | 62 | Crossing thirty usable hosts doubles the underlying block size. |
| Behavior | What The Package Does | Why It Matters |
|---|---|---|
| Parent normalization | The entered address is masked to the selected prefix before planning begins. | A non-boundary input such as 10.0.0.7/24 is treated as the 10.0.0.0/24 network. |
| Column-aware export | CSV, JSON, and DOCX output reflect the currently visible table columns. | Hidden fields are intentionally omitted from exported output. |
| Forward-only allocation | Removed rows do not trigger automatic repacking of later subnets. | You can leave internal gaps until you clear the plan and rebuild it. |
| Local execution | All calculations, copies, and downloads happen in the browser with no server helper. | Privacy depends mainly on what you type into notes and where you store exports afterward. |
The top summary is based on usable addresses, not raw address count. Used adds the usable capacity of every planned row, remaining is the parent block's usable capacity minus that total, and Utilisation is the rounded percentage of that usable pool consumed so far.
Read each allocation row in context. Hosts is the demand you entered, while the CIDR block reflects the next aligned size that can actually carry that demand. When Hosts and usable capacity are far apart, the difference is not a bug. It is the normal cost of binary block sizing.
The host-share chart is a quick way to spot waste. If one segment dominates the donut, or if Unallocated hosts is small but a new request still cannot fit, verify the next legal boundary before assuming the raw remainder is enough. Alignment can strand a handful of addresses even when the arithmetic remainder looks positive.
The most common false-confidence mistake is to treat a valid row as deployable just because the math works. Before acting on the plan, verify that the chosen block is appropriate for your routing policy, that it is not a special-purpose range, and that the prefix length is accepted by the devices or provider involved.
Start with 10.0.0.0/24 and enter a request for 50 hosts. The planner derives 10.0.0.0/26, which yields 62 usable addresses with first usable 10.0.0.1 and last usable 10.0.0.62. A second request for 20 hosts then begins at the next aligned boundary and becomes 10.0.0.64/27, leaving the remaining space available for later rows.
Start with 192.0.2.0/30 and request 2 hosts. The row becomes 192.0.2.0/31, and the planner reports both addresses as usable. That is a good reminder that the package follows modern /31 handling for narrow link networks rather than the older habit of discarding both addresses.
Take 192.0.2.0/29, which has six usable addresses in total, and enter a request for 3 hosts. The tool must round that demand up to a full /29 block, so the first row consumes the whole parent network. A later request for even 1 more host fails immediately. The corrective path is to begin with a larger parent block or reduce the original requirement, not to look for an extra single address inside the same /29.
Because the planner rounds to the next power-of-two block that can hold the request plus the usual network and broadcast positions. Three hosts need five total addresses, so the next valid block is eight addresses, which is a /29.
No. It validates address structure and subnet math, but it does not warn if a block is private, documentation-only, loopback, link-local, shared address space, or another special-purpose range. That check still belongs to you.
The export layer uses the currently visible column set. Hiding Broadcast or Network, for example, removes those fields from the exported table so the file matches the worksheet you are looking at.
Yes. A two-host request produces a /31 row and reports two usable addresses. That matches the point-to-point convention documented in RFC 3021.
The new row's aligned broadcast address would extend beyond the parent block. This can happen because the parent is genuinely full or because the next legal boundary is larger than the raw number of remaining addresses suggests.