skip to content

In IPv4, why can't the contiguous blocks 10.1.5.0/24 through 10.1.8.0/24 be summarised as one /22, and what is the smallest exact set?

level: middleimportance: should knowfreq 24%

answer

  1. contiguous is not enough
  2. where do /22s start?
  3. host bits must be zero
  4. largest aligned block that fits

basics

~10 s

A /22 must start on a third octet divisible by 4, and 5 to 8 straddles the 4-7 and 8-11 boundaries. The smallest exact set is three prefixes: 10.1.5.0/24, 10.1.6.0/23 and 10.1.8.0/24.

solid answer

~40 s

Four /24s add up to a /22's 1,024 addresses, but a prefix must also be **aligned**: its network address has all host bits zero, so /22s start only at third octets 0, 4, 8, 12 and so on. The set 5 to 8 crosses the line between `10.1.4.0/22` and `10.1.8.0/22`, so neither holds it. The only single prefix covering it is `10.1.0.0/20`, sixteen /24s of which twelve are not in the set: an over-summary. Exactly, it splits into the largest aligned blocks that fit: `10.1.5.0/24`, `10.1.6.0/23`, `10.1.8.0/24`. No pair works, because two /23s would have to start on the odd octets 5 and 7.

code

pseudocode · 15 lines
pseudocode
# start, end: inclusive 32-bit integers; returns the fewest exact prefixes
function range_to_prefixes(start, end):
    result = []
    while start <= end:
        size = largest power of two dividing start   # 2^32 if start == 0
        while start + size - 1 > end:
            size = size / 2
        result.append((start, 32 - log2(size)))
        start = start + size
    return result

# 10.1.5.0 .. 10.1.8.255
#   10.1.5.0: aligned for 256 -> 10.1.5.0/24
#   10.1.6.0: aligned for 512, fits -> 10.1.6.0/23
#   10.1.8.0: aligned for 2048; 2048, 1024, 512 overrun -> 10.1.8.0/24

go deeper

for a junior

Recall that prefixes start on multiples of their own size: /23s on even third octets, /22s on multiples of four, /21s on multiples of eight.

for a middle

Explain why 5 to 8 fails alignment, show that common bits give only a /20, and split the range into the three largest aligned blocks that fit.

for a senior

Weigh the options: an exact list of three, a covering /20 only if the space is yours and backed by a discard route, or fixing the allocation so future blocks align.

for a principal

Argue that alignment problems are allocation debt: decide how blocks will be summarised before handing them out, because renumbering later is far costlier than a few extra routes.

## Contiguous is not enough The four blocks `10.1.5.0/24`, `10.1.6.0/24`, `10.1.7.0/24` and `10.1.8.0/24` have no gap between them and add up to 1,024 addresses, exactly the size of a /22. It is tempting to write them as `10.1.5.0/22`. That prefix does not exist: a prefix's network address must have every bit after the prefix length set to zero, and for a /22 that happens only where the third octet is a multiple of 4. | /22 prefix | Third octets covered | |---|---| | `10.1.0.0/22` | 0 to 3 | | `10.1.4.0/22` | 4 to 7 | | `10.1.8.0/22` | 8 to 11 | | `10.1.12.0/22` | 12 to 15 | The set 5 to 8 straddles the line between `10.1.4.0/22` and `10.1.8.0/22`. Neither /22 holds it, so **no /22 summarises it exactly**. ## The three conditions for one exact summary 1. **Contiguous**: no missing block in the middle. 2. **A power-of-two total**: 2, 4, 8 ... /24s; sizes may be mixed, but must add up to one. 3. **Aligned**: the first address is a multiple of the summary's size, so its host bits are all zero. This set meets the first two and fails the third. A run of three /24s fails the second wherever it starts: `10.1.4.0` to `10.1.6.0` is at best `10.1.4.0/23` plus `10.1.6.0/24`. ## What the common-bit method produces instead Taking the leading bits that all four third octets share: | Third octet | Binary | |---|---| | 5 | `0000 0101` | | 6 | `0000 0110` | | 7 | `0000 0111` | | 8 | `0000 1000` | Going from 7 to 8 flips the fourth bit, so only `0000`, four bits, is common. With the 16 bits of `10.1`, the only single prefix covering all four is `10.1.0.0/20`: 4,096 addresses, sixteen /24s, twelve of them not in the set. Announcing it is an **over-summary**: it attracts traffic for `10.1.0.0` to `10.1.4.255` and for `10.1.9.0` to `10.1.15.255`, space this router does not route. ## A quick alignment test - A **/23** starts where the third octet is even: 0, 2, 4 ... - A **/22** starts where it is a multiple of 4, a **/21** of 8 and a **/20** of 16. - In general a block of 2^k /24s starts where the third octet is divisible by 2^k, which is the same as saying its last k bits are zero. - Below /24 the test moves to the fourth octet: a /26 starts at 0, 64, 128 or 192. ## The smallest exact set Walk the range from its start, each time taking the largest block that is aligned at the current address and still ends inside the range: 1. **Start `10.1.5.0`.** Third octet 5 is odd, so the largest aligned block is a /24: **`10.1.5.0/24`**. 2. **Start `10.1.6.0`.** 6 is a multiple of 2 but not of 4, so a /23 is aligned; it covers 6 and 7 and fits: **`10.1.6.0/23`**. 3. **Start `10.1.8.0`.** 8 is aligned for a /21, but a /21 (8 to 15), a /22 (8 to 11) and a /23 (8 to 9) all overrun the end; a /24 fits: **`10.1.8.0/24`**. That is three prefixes covering 256 + 512 + 256 = 1,024 addresses, exactly the set. No pair can do it: two prefixes totalling four /24s are either two /23s, which would start on the odd octets 5 and 7, or a one-and-three split, and three is not a power of two. ## What to do about it - **Announce the exact set.** Three routes instead of one, but nothing extra is claimed. - **Announce a covering prefix only if the space is yours.** If the whole `10.1.0.0/20` is assigned to this network, the summary is legitimate; RFC 4632 then requires the summarising router to discard traffic for the parts no more-specific route covers, so it is dropped rather than looped. - **Fix the allocation.** Blocks that will be summarised should be handed out on the boundary of their eventual summary; the stray block at `10.1.8.0` would have fitted if the site had been given `10.1.4.0` to `10.1.7.0`. Carving unequal blocks out of one range is its own planning subject. - **Accept a longer list.** A few extra routes cost little; a covering prefix over space you do not route can cost an outage. The same rule holds for IPv6: `2001:db8:0:5::/64` to `2001:db8:0:8::/64` cannot be one /62, because /62s start only where the fourth 16-bit group is a multiple of 4.

  • Is 10.1.5.0/22 a valid way to write a summary?
    No. A prefix's bits after its length must be zero, and `10.1.5.0` has bits set below the /22 boundary. The /22 that contains it is `10.1.4.0/22`, covering `10.1.4.0` to `10.1.7.255`, not the intended set. Implementations differ on such an entry, some rejecting it and some silently clearing the host bits, which here would claim `10.1.4.0/24` and miss `10.1.8.0/24`.
  • When is announcing the covering 10.1.0.0/20 acceptable?
    When the whole /20 is assigned to the announcing network and nobody else routes any part of it. Then the extra twelve /24s are unused space you own, and the summarising router holds a discard route for the /20, as RFC 4632 requires, so traffic for them is dropped once instead of looping along a default route.

saying these in an interview costs you the question

  • Any contiguous run of /24s that adds up to 1,024 addresses is a /22.
  • 10.1.5.0/22 is a valid prefix for the range 10.1.5.0 to 10.1.8.255.
  • Three contiguous /24s form one prefix if they start on an even octet.
  • If no exact summary exists, announcing the covering /20 costs nothing.
  • The smallest exact set always uses blocks of equal size.