skip to content

In IPv4 VLSM planning, why do you allocate the largest subnets first, and what does a subnet's bit boundary have to do with it?

level: middleimportance: should knowfreq 42%

answer

  1. blocks are powers of two
  2. start on a multiple of the size
  3. big blocks keep small ones aligned
  4. padding holes, blocked /23 slots

basics

~20 s

Every IPv4 subnet must start on a multiple of its own size. Allocating largest first keeps each next start aligned, so blocks pack without gaps; other orders leave alignment holes or can occupy a large subnet's only valid starts.

solid answer

~50 s

A prefix of length n covers `2^(32-n)` addresses and must start on a multiple of that size - a `/26` on a multiple of 64 in the last octet, a `/23` on an even third octet. Write `10.40.5.0/23` and the mask quietly turns it into `10.40.4.0/23`. When you allocate in descending size, every block before the current one is a multiple of the current size, so the next free address is already a valid start: no padding, no overlap, and the free space ends up as one contiguous run at the top. Allocate small blocks first and you pad to reach each boundary - three `/30`s at `10.40.4.0` leave `.12` to `.31` stranded before a `/27` can start at `.32`. Worse, small subnets scattered by hand can occupy both possible `/23` starts in a `/22`, so the large LAN no longer fits although the total does.

go deeper

for a junior

Recall that a subnet starts on a multiple of its own size: a /26 at 0, 64, 128 or 192 in the last octet.

for a middle

Explain why descending order never pads: earlier blocks are multiples of later ones, so the next free address is always aligned, and show the hole that ascending order leaves.

for a senior

Spot the plan that ran out of aligned space rather than addresses, catch misaligned prefixes in review, and justify any deliberate departure from largest first, such as reserving a buddy block for growth.

for a principal

Weigh packing efficiency against future flexibility: tight largest-first packing maximises today's free space, while reserved aligned blocks trade some of it for growth without renumbering.

## The alignment rule An IPv4 prefix of length `n` covers a block of `2^(32-n)` addresses, and the block must begin at an address whose host bits are all zero - in arithmetic terms, a **multiple of the block size**. That is all "on a bit boundary" means. | Prefix | Block size | Valid starts | |---|---|---| | `/30` | 4 | last octet 0, 4, 8 ... 252 | | `/27` | 32 | last octet 0, 32, 64 ... 224 | | `/26` | 64 | last octet 0, 64, 128, 192 | | `/25` | 128 | last octet 0 or 128 | | `/24` | 256 | last octet 0 | | `/23` | 512 | third octet even, last octet 0 | | `/22` | 1,024 | third octet a multiple of 4, last octet 0 | An address that is not on its boundary does not create a new block. Applying the mask clears the host bits, so `10.40.5.0/23` is simply a host address inside `10.40.4.0/23`, and `10.40.6.160/26` is a host inside `10.40.6.128/26`. Writing such a prefix in a plan quietly describes a block you did not mean. ## Why largest first never leaves a gap Block sizes are powers of two, and every larger power of two is a multiple of every smaller one. Allocate in descending size from the start of an aligned parent block: 1. The first block starts at the parent's start, which is aligned for every smaller size. 2. After it, the next free address is the parent's start plus a sum of block sizes that are all at least as large as the next block - so that offset is a multiple of the next block's size. 3. The next block can therefore start exactly at the next free address. No padding is needed. 4. The argument repeats for every block, so the allocation is gap-free, and everything fits whenever the sizes add up to no more than the parent block. 5. The unused space ends up as one contiguous run at the top of the parent. ## Smallest first: the same brief, with a hole Take `10.40.4.0/22` for LANs of 300, 120, 50 and 20 hosts plus three links, and allocate smallest first: | Order | Subnet | Why it starts there | |---|---|---| | 1-3 | `10.40.4.0/30`, `10.40.4.4/30`, `10.40.4.8/30` | next free address, a multiple of 4 | | 4 | `10.40.4.32/27` | 12 is not a multiple of 32, so `.12` to `.31` is skipped | | 5 | `10.40.4.64/26` | a multiple of 64 | | 6 | `10.40.4.128/25` | a multiple of 128 | | 7 | `10.40.6.0/23` | `10.40.4.0/23` is occupied; the next even third octet is 6 | Everything still fits, but the 276 free addresses are now split into two separate runs: `10.40.4.12` to `10.40.4.31` (20 addresses, usable only as a `/30` and a `/28`) and `10.40.5.0/24`. Largest first leaves the same 276 as one run, from `10.40.6.236` to `10.40.7.255`. An arbitrary order does worse. Place the 20-host `/27` at `10.40.4.0` first, and the `/23` can no longer start at `10.40.4.0`; its next boundary is `10.40.6.0/23`, which runs to the very end of the `/22`. Append the `/25` after it and it falls outside the block. The plan only fits if someone goes back and fills the 480-address hole from `10.40.4.32` to `10.40.5.255` by hand - exactly the kind of manual bookkeeping that produces overlaps. ## Hand placement: when the big subnet stops fitting A `/22` has exactly two places a `/23` can go: `10.40.4.0/23` and `10.40.6.0/23`. Suppose someone places the 50-host LAN at `10.40.5.0/26` "to leave room" and the 120-host LAN at `10.40.6.0/25`. Each is perfectly aligned, nothing overlaps, and only 192 of 1,024 addresses are used - yet the 300-host LAN can no longer be placed, because each possible `/23` now contains an allocated block. The plan did not run out of addresses; it ran out of **aligned space**. ## Practical checks - Divide the network address by the block size; any remainder means it is not a network address. - For prefixes `/24` and longer, look only at the last octet; for `/17` to `/23`, look at the third octet, with a last octet of 0. - Sort the sizes before placing anything, and write each start as the previous end plus one. - When you deliberately break the order - for example, to keep the aligned block next to a subnet free so it can double later without renumbering - record why, because the next person will assume largest first.

  • If largest first always packs without gaps, why would anyone deliberately break the order?
    For growth. A subnet that will probably double can be placed so the aligned block of the same size next to it stays free; later the two merge into one prefix twice the size without renumbering. That costs some packing efficiency now, so it should be a recorded decision rather than an accident of ordering.
  • How can you tell quickly whether 10.40.6.160/26 is a valid IPv4 /26?
    A `/26` block holds 64 addresses, so it must start where the last octet is 0, 64, 128 or 192. 160 is none of these - it is only a multiple of 32 - so `10.40.6.160` is a host address inside `10.40.6.128/26`, which runs from `.128` to `.191`.

Think of a shelf with marks every 4 cm, every 32 cm, every 64 cm and so on, where a box may only sit with its left edge on a mark matching its width. Shelve the widest boxes first and every narrower box finds a valid mark right where the last one ended; shelve the narrow ones first and you leave slivers only small boxes can use, and placing boxes by eye can block the only marks the widest box could sit on.

saying these in an interview costs you the question

  • Any address can start a subnet as long as the ranges do not overlap.
  • Allocation order is just neatness; any order packs equally tightly.
  • 10.40.5.0/23 and 10.40.4.0/23 are two different subnets.
  • A /27 can start at any multiple of 8 in the last octet.
  • If the total size fits, every placement of the subnets will fit.