When you carve a single /24 into department-sized chunks, the subnet length is naturally going to differ per department: a /25 for 100 hosts, a /28 for 10. That's VLSM (Variable Length Subnet Mask) — you allocate exactly the size each segment needs. The trap people new to VLSM step on is the order of allocation. Start with the smallest requirement and work up, and you will eventually hit a wall. Using 192.168.1.0/24 split across four departments of 100, 50, 20, and 10 hosts, here's why the order has to run largest to smallest.

Deriving the subnet length from the host count

To find the smallest subnet that fits a given host count, look for the smallest n satisfying 2^n - 2 ≥ required hosts. 100 hosts needs /25 (2^7-2=126), 50 needs /26 (2^6-2=62), 20 needs /27 (2^5-2=30), and 10 needs /28 (2^4-2=14).

This much shows up in plenty of tutorials. The part that actually matters is how these four blocks get placed inside 192.168.1.0/24.

Allocating largest first

Start with department A's /25. Within a /24, a /25 can only start at 192.168.1.0 or 192.168.1.128, so A gets 192.168.1.0/25. That consumes 192.168.1.0 through .127, leaving 192.168.1.128/25. Next is B's /26. Within the remaining 192.168.1.128/25, a /26 can only start at 192.168.1.128 or 192.168.1.192, so B gets 192.168.1.128/26, leaving 192.168.1.192/26. C's /27 can start at either 192.168.1.192 or 192.168.1.224 within that remainder, so C gets 192.168.1.192/27, leaving 192.168.1.224/27. Finally D's /28 can start at 192.168.1.224 or 192.168.1.240, so D gets 192.168.1.224/28. 192.168.1.240/28 stays unused, ready for a fifth department later.

192.168.1.0/25   -> A (100 hosts, /25)
192.168.1.128/26 -> B (50 hosts, /26)
192.168.1.192/27 -> C (20 hosts, /27)
192.168.1.224/28 -> D (10 hosts, /28)
192.168.1.240/28 -> unused (reserved for growth)

The four departments consume 128+64+32+16=240 addresses out of the /24's 256, leaving 16 untouched. Nothing is fragmented.

Where a subnet is allowed to start

You may have noticed that each department in the largest-first layout only had two possible starting points. That's not a coincidence — a subnet's starting address has to be a multiple of its own size. A /27 block holds 32 addresses, so it can only start at 0, 32, 64, 96, and so on — multiples of 32. This is just the AND-with-the-mask behavior that determines a network address: the host bits get forced to zero, and a subnet can only start where its host bits are already zero, which is exactly the multiples of its block size. Call this constraint alignment: a block can only sit on a boundary that's a multiple of its own size. Place the largest subnet first, and whatever space remains always starts on a boundary that's a multiple of the largest block size still in play — so the next, smaller subnet's alignment requirement is automatically satisfied. Place a small subnet first, and there's no guarantee the leftover space starts on the boundary a bigger block needs later; when it doesn't, you lose addresses skipping ahead to the next valid boundary.

What happens allocating smallest first

Try the same four departments starting from D's /28, the smallest requirement. Packing from the top of the /24, D gets 192.168.1.0/28. Next is C's /27. Right after D ends at 192.168.1.15, the next address is 192.168.1.16 — but a /27 block can only start at 192.168.1.0 or 192.168.1.32, and .16 isn't on that boundary. To land C on a valid /27 boundary you have to skip ahead to 192.168.1.32/27, stranding 192.168.1.16 through .31 — 16 addresses — as a gap wedged between D and C. B's /26 comes next, and 192.168.1.64 (right after C ends at .63) happens to be a multiple of 64, so it slots in cleanly. A's /25 follows the same luck: 192.168.1.128, right after B, is a multiple of 128, so it fits without further trouble. The final layout consumes the same total of 240 addresses as the largest-first version, but the 16 wasted addresses end up in a different place. In the largest-first layout, that slack sits as a clean 192.168.1.240/28 at the tail, ready to be handed to a fifth department. In the smallest-first layout, it's stranded as 192.168.1.16–31, sandwiched between D and C that are already assigned — reclaiming it means redesigning one of its neighbors. This particular example still fit inside the /24 only because 16, 32, 64, and 128 happen to double cleanly into each other. With a less convenient mix of sizes, the gaps created by packing small subnets first can violate the alignment a later, larger subnet needs, and the whole set simply won't fit inside the /24 no matter how you rearrange it. The more departments you add, the bigger that risk gets — which is why allocating largest first from the start is the safer default.

The 1991 original solved this with bit layout, not ordering

The concept of VLSM was first laid out in RFC 1219 (Tsuchiya, 1991). What it proposed, though, wasn't a "largest first" allocation rule — it was a different way of using the bits altogether: number subnets from the high-order bits down, and hosts from the low-order bits up. The reasoning at the time was that nobody could predict whether subnet count or host count would grow first, so the bit layout should let both grow independently toward a shared middle ground. The goal was to avoid having to renumber subnets just because host counts grew. What ended up dominating in practice isn't that bit-layout trick — it's the operational rule of allocating largest first and letting boundaries line up naturally. Once routing protocols that could carry a different mask length per route became widespread, the renumbering problem RFC 1219 was worried about became something you could sidestep with an operational rule alone, without touching bit layout at all.

If you need to work backward from a department's host count to a subnet length, or check the resulting network and broadcast addresses, the tool below handles both.