Subnetting and prefix hierarchy: a practical guide

Subnetting looks like bit-shuffling until you notice the shape underneath it: a tree. Every address you manage lives somewhere in a hierarchy of prefixes, and once that tree is clean, questions like "is this range free?" and "who owns this space?" start answering themselves.

A quick CIDR refresher

An IP prefix is an address plus a prefix length — the number of leading bits that are fixed. In 10.0.0.0/24, the first 24 bits are the network and the remaining 8 are for hosts, which gives 256 addresses (254 usable once you subtract the network and broadcast addresses).

The one rule worth memorizing: each bit you add to the prefix length halves the block; each bit you remove doubles it.

• /24 = 256 addresses — the classic "a subnet"
• /23 = 512 addresses — two /24s merged
• /25 = 128 addresses — half a /24
• /16 = 65,536 addresses — a large aggregate

The same logic applies to IPv6, just with far more room: a /64 is the standard host subnet, and you carve site and region aggregates out of shorter prefixes like /48 or /56.

From aggregate to host

A useful network is not a flat list of /24s. It is a hierarchy with three conceptual layers:

1. Aggregates (supernets) — the big blocks you were allocated or reserved, such as 10.0.0.0/16 for a region or an RFC 1918 range for the whole org.
2. Child prefixes — subnets carved from an aggregate: a per-site /20, then a per-VLAN /24 inside it.
3. Hosts — the individual addresses assigned to interfaces, VIPs, and gateways.

Prefixes nest cleanly because CIDR boundaries are powers of two. A /20 contains exactly sixteen /24s; a /24 contains 256 addresses. Nothing overlaps as long as you split on real boundaries and never let two children claim the same bits.

Container vs. active prefixes

Not every prefix is a place where hosts live. It helps to give each prefix a role:

• A container (or "aggregate") prefix exists to be subdivided. 10.0.0.0/16 and a site's 10.0.0.0/20 are containers — you would never assign a host directly into them.
• An active prefix is a real, in-use subnet where addresses get handed out. 10.0.0.0/24 (the Servers VLAN) is active.

Marking this distinction matters because utilization means different things at each layer. For an active /24, utilization is "how many of my 254 hosts are assigned." For a container, utilization is "how much of my child space has been carved out" — a rollup of the prefixes beneath it, not a host count.

Worked example: carving a /16 into sites

Say you have 10.0.0.0/16 for a region. Split it into per-site /20s (4,096 addresses, sixteen /24s each), then split each site into per-VLAN /24s:

10.0.0.0/16      Region EU        container   65,536 addr
├─ 10.0.0.0/20   Site: Aarhus     container    4,096 addr  (10.0.0.0–10.0.15.255)
│   ├─ 10.0.0.0/24  Servers VLAN   active        254 hosts
│   ├─ 10.0.1.0/24  Users VLAN     active        254 hosts
│   └─ 10.0.2.0/24  Mgmt  VLAN     active        254 hosts
├─ 10.0.16.0/20  Site: Berlin     container    4,096 addr  (10.0.16.0–10.0.31.255)
│   └─ 10.0.16.0/24 Servers VLAN   active        254 hosts
└─ 10.0.32.0/20  Site: reserved   container    4,096 addr  (spare for growth)

A /16 gives you sixteen /20s (10.0.0.0/20, 10.0.16.0/20, 10.0.32.0/20, … 10.0.240.0/20), which is a natural fit for up to sixteen sites — and reserving a couple of empty /20s upfront means a new site slots in without renumbering anything.

Why the hierarchy earns its keep

A clean tree is not tidiness for its own sake. It pays off in four concrete ways:

• Route aggregation. Because Aarhus is one contiguous /20, it advertises as a single route instead of three loose /24s. Summarizable address plans keep routing tables and firewall rules small.
• Utilization rollup. You can ask "how full is Region EU?" and get a real answer, because each container's usage is the sum of its children. Sparse /20s jump out as reclaim candidates.
• Overlap prevention. Allocating from the top down makes double-booking a range structurally hard: a child must fit inside its parent, and siblings cannot collide.
• Delegation. A site team can own its /20 and self-serve /24s inside it, without the authority (or the ability) to touch another site's space.

How an IPAM keeps it consistent

Spreadsheets can represent this hierarchy, but they cannot enforce it — nothing stops two rows from claiming 10.0.1.0/24, and nobody recomputes utilization when a subnet fills up. A purpose-built IPAM treats the prefix tree as the source of truth:

• It automatically nests a new prefix under its correct parent based on the CIDR math, so the tree stays accurate as you add subnets.
• It rejects overlaps and out-of-bounds children at creation time, before they become a routing incident.
• It shows live utilization at every level — hosts within an active subnet, and child coverage within a container — so capacity planning is a glance, not a quarterly audit.
• It lets you find the next available /24 (or /26, or /64) inside a chosen parent instead of eyeballing gaps.

Danbyte models exactly this — aggregates, containers, active prefixes, and host assignments in one tree, and every bit of it ships in the free, open-source release. Whether you self-host on your own hardware or run the identical software on Danbyte Cloud, the prefix features behave the same, and the REST API means your automation can ask for "the next free /24 in Berlin" and get a real answer.

Get the hierarchy right once and most day-to-day addressing decisions stop being decisions at all — the tree already knows where things go.