skip to content

In IPv4, which single prefix summarises 10.1.4.0/24, 10.1.5.0/24, 10.1.6.0/24 and 10.1.7.0/24, and how do you derive it?

level: middleimportance: must knowfreq 42%

answer

  1. only one octet varies
  2. write it in binary
  3. count the shared leading bits
  4. check the range is exact

basics

~10 s

The summary is 10.1.4.0/22. The third octets 4 to 7 share their first six bits (000001), so 16 + 6 = 22 bits are common, covering exactly 10.1.4.0 to 10.1.7.255.

solid answer

~40 s

Write the varying octet in binary: 4, 5, 6 and 7 are `00000100` to `00000111`, so they share the first six bits. Adding the 16 bits of `10.1` gives a `/22`, and zeroing the bits after it gives `10.1.4.0/22`, mask `255.255.252.0`. Then verify: a /22 has 10 host bits, 1,024 addresses, `10.1.4.0` to `10.1.7.255`, which is exactly four /24s. The quick check agrees: four blocks is 2^2, so the prefix is two bits shorter than /24, and the first third octet, 4, is a multiple of 4. The verification matters because common bits alone can produce a prefix that also covers blocks you do not have.

code

pseudocode · 15 lines
pseudocode
# prefixes: list of (network, length); network is a 32-bit integer
function summarise(prefixes):
    lo = min(network for each prefix)
    hi = max(network + 2^(32 - length) - 1 for each prefix)
    common = 32 - bit_length(lo XOR hi)       # leading bits lo and hi share
    size = 2^(32 - common)
    summary_net = lo - (lo MOD size)           # clear the host bits
    summary_end = summary_net + size - 1
    covered = sum of 2^(32 - length) for each prefix   # assumes no overlaps
    if summary_net == lo and summary_end == hi and covered == hi - lo + 1:
        return (summary_net, common), "exact"
    return (summary_net, common), "over-summarised"

# 10.1.4.0/24 .. 10.1.7.0/24: lo XOR hi = 0.0.3.255, bit_length 10
# common = 22 -> (10.1.4.0, 22), "exact"

go deeper

for a junior

Recall the steps: find the varying octet, write it in binary, count shared leading bits, zero the rest. Practise on four adjacent /24s until it takes under a minute.

for a middle

Show the binary table, derive /22 and its mask, then prove exactness from the range: 1,024 addresses, first to last, nothing extra. Mention the count-and-alignment shortcut.

for a senior

Point out that common bits can hide a missing block and produce an over-summary, and say what that costs: traffic for space you do not route, which the summariser must discard.

for a principal

Connect the arithmetic to planning: blocks only summarise cleanly if they were allocated on the boundary of their future summary, which is a decision made long before anyone configures a router.

## The task Four /24 blocks, `10.1.4.0/24`, `10.1.5.0/24`, `10.1.6.0/24` and `10.1.7.0/24`, sit side by side in private (RFC 1918) space. The task is to find one shorter IPv4 prefix that covers all four and nothing else, so a router can advertise one route upstream instead of four. The answer is `10.1.4.0/22`, and the method works for any set of blocks. ## Method: find the common leading bits An IPv4 prefix `/n` means "the first n bits are fixed and the rest number addresses". A summary may fix only the bits that every component block shares, so: 1. **Find the octet that varies.** The first two octets, `10.1`, are identical in all four blocks, so those 16 bits are common; only the third octet differs. 2. **Write that octet in binary** for every block and line the values up. 3. **Read left to right** until the bits disagree. The number of agreeing bits, plus the 16 already common, is the summary's prefix length. 4. **Zero everything after them**: the result is the summary's network address. 5. **Check the summary covers exactly your blocks**, no more and no less. | Block | Third octet | Binary | |---|---|---| | 10.1.4.0/24 | 4 | `000001 00` | | 10.1.5.0/24 | 5 | `000001 01` | | 10.1.6.0/24 | 6 | `000001 10` | | 10.1.7.0/24 | 7 | `000001 11` | All four share `000001`, six bits, in the third octet. With the 16 bits of `10.1` the summary is **/22**. Zeroing the last two bits of the third octet and all of the fourth leaves `10.1.4.0`, so the summary is `10.1.4.0/22`, written as a mask `255.255.252.0`. ## Verify it is exact A /22 has 32 - 22 = 10 host bits, so it spans 2^10 = 1,024 addresses: `10.1.4.0` to `10.1.7.255`. That is 4 x 256, the four /24s, with nothing extra. The verification step is not ceremony. The common-bit method looks only at the bits the blocks agree on, so it will happily produce a prefix that also covers blocks you do not have: - With `10.1.4.0`, `10.1.5.0` and `10.1.7.0` but no `10.1.6.0`, the common bits are still `000001`, and `10.1.4.0/22` would also claim `10.1.6.0/24`, which is an **over-summary**. - With `10.1.5.0` to `10.1.8.0`, the common bits shrink to `0000`, and the only covering prefix becomes `10.1.0.0/20`: sixteen /24s to describe four. ## A shortcut that agrees with the method For blocks of equal size the arithmetic needs no binary: - **Count the blocks.** Four is 2^2, so the summary is two bits shorter than the blocks: /24 becomes /22. - **Check alignment.** A /22 holds four /24s, so its third octet must be a multiple of 4. The first block's third octet is 4, which is. - **Both pass, so the summary is exact.** If the count is not a power of two, or the first block is off the boundary, no single exact summary exists. Blocks of different sizes work the same way on address ranges. `10.1.4.0/23` (third octets 4 and 5) plus `10.1.6.0/24` plus `10.1.7.0/24` span `10.1.4.0` to `10.1.7.255` without a gap or overlap: 1,024 addresses starting on a /22 boundary, so they too summarise to `10.1.4.0/22`. ## Common mistakes - **Taking one bit per block.** Four blocks cost two bits, not four, and eight cost three: the summary shortens by one bit for every doubling. - **Trusting the first block's address.** The summary's network address is the common bits followed by zeros; `10.1.5.0` can never head a /22. - **Skipping the exactness check.** Common bits bound the set but do not prove it has no gaps. - **Assuming shared octets mean a short summary.** Blocks that share `10.1` can still need a /22, a /20 or several prefixes; only the bit pattern decides. ## What the summary does on a router The summary replaces four entries in every routing table that receives it. A packet for `10.1.6.20` matches `10.1.4.0/22` upstream and is forwarded toward the summarising router, which still holds the four /24s and picks the right one by **longest prefix match**. RFC 4632, the current CIDR specification (it obsoletes RFC 1519), also requires the summarising router to discard packets that match the summary but none of its components, so traffic for a subnet that is down is dropped there instead of looping back along a default route. The same method applies to IPv6 prefixes, on 128 bits instead of 32, and to any number of blocks: the more blocks, the more bits the summary gives up, one bit for every doubling.

  • How do you summarise blocks of different sizes, such as 10.1.4.0/23 with 10.1.6.0/24 and 10.1.7.0/24?
    Work on address ranges instead of counting blocks. `10.1.4.0/23` covers `10.1.4.0` to `10.1.5.255`; with the two /24s the set spans `10.1.4.0` to `10.1.7.255` with no gap or overlap. That is 1,024 addresses, a power of two, starting on a /22 boundary, so the exact summary is `10.1.4.0/22`. Sizes never need to match; coverage does.
  • Does the same method work for IPv6 prefixes?
    Yes, on 128 bits. `2001:db8:0:4::/64` to `2001:db8:0:7::/64` differ only in the fourth 16-bit group, values 4 to 7, which share all but their last two bits. That leaves 48 + 14 = 62 common bits, so the summary is `2001:db8:0:4::/62`, and four /64s is 2^2, two bits shorter, as expected.

saying these in an interview costs you the question

  • Four /24s always summarise to a /22, wherever they start.
  • Taking the common leading bits always yields an exact summary.
  • Summarising four blocks needs a prefix four bits shorter.
  • If the blocks share their first two octets, the summary is always a /16.
  • The summary's address is simply the first block's address, whatever its bits.