OnCallReady

Lesson 8.6 · Addressing & DNS · 15 min read

Carving an address space: alignment, overlap, and plans you cannot undo

In plain words

Imagine packing a car boot with suitcases of different sizes. If you put the small bags in first, scattered around, the big suitcase no longer fits, even though there is enough empty space in total. Pack the biggest first, in the corners, and the small ones fill the gaps.

Address space is the same. A /20 must start on a multiple of 16 in its octet, a /22 on a multiple of 4. So you place the biggest blocks first on their natural boundaries, then the small ones. And two neighbours cannot both claim the same houses: if two networks overlap, they can never be connected. The lesson's plan for 10.50.0.0/16 shows the packing, and the renumbering story shows what overlap costs.

Why this matters

A team is handed 10.50.0.0/16 and has to split it between five groups of machines. Get the split wrong and it cannot be fixed cheaply later: machines, firewall rules and routes all get built on top of those numbers. This lesson is how to carve a range so it keeps working.

What you need to know already: 8.3 - sizes of each prefix, the block-size method, subnets.

How many /x fit in a /y

count = 2^(x - y)
/26s in a /22:   2^(26-22) = 16
/24s in a /16:   2^8       = 256
/28s in a /24:   2^4       = 16
/27s in a /25:   2^2       = 4
/21s in a /16:   2^5       = 32

Or divide sizes: "a /22 is 1024 addresses, a /26 is 64, 1024 / 64 = 16". Same answer; use whichever is faster for you.

The nth subnet

The nth /x inside a range starts at start + (n - 1) x blocksize:

the 3rd /27 of 10.20.30.0/24:   block 32 -> 10.20.30.64/27  (.64 - .95)
the 5th /26 of 10.8.0.0/22:     block 64 -> 4 x 64 = 256 -> 10.8.1.0/26
the 10th /24 of 10.100.0.0/16:  9 x 256 in the 3rd octet -> 10.100.9.0/24

The second one crosses into the next octet. Four /26s fill 10.8.0.0/24, so the fifth starts at 10.8.1.0. When it gets confusing, count in addresses: 256 addresses is exactly one step in the third octet.

Alignment: a block starts on a multiple of its size

A /24 can start at 10.0.5.0 but not at 10.0.5.128. A /22 must start where the third octet is a multiple of 4. A /20 where it is a multiple of 16. A block that starts in the right place is aligned.

10.0.4.0/22     valid   (4 is a multiple of 4)
10.0.6.0/22     INVALID - 6 is not; the /22 containing 10.0.6.0 is 10.0.4.0/22
10.0.32.0/20    valid   (32 = 2 x 16)
10.0.40.0/20    INVALID - the /20 containing it is 10.0.32.0/20

This matters when you carve mixed sizes out of one range (network people call it VLSM, variable-length subnet masks): place the biggest blocks first, on their natural boundaries, then fill the gaps with smaller ones. The other way round leaves holes nothing fits in - like packing a car boot with the small bags first.

10.50.0.0/16 for one environment - biggest first:
10.50.0.0/20     app-servers     4096   (0-15 in the 3rd octet)
10.50.16.0/22    web-servers     1024   (16-19)
10.50.20.0/24    databases       256    (20)
10.50.21.0/26    admin-tools     64
10.50.21.64/27   jump-box        32

A jump box is a single hardened machine people SSH into first, and from there into the others. Tiny subnets like that come last.

Do two ranges overlap?

Two ranges overlap when they share at least one address. With CIDR blocks there are only three cases: separate, A inside B, or B inside A. They never "partly" overlap, because every block is aligned.

10.1.0.0/16  vs 10.1.5.0/24     overlap: the /24 is inside the /16
10.1.0.0/16  vs 10.2.0.0/16     separate
10.0.0.0/8   vs 10.200.0.0/16   overlap: everything in 10.x is inside /8
192.168.0.0/23 vs 192.168.1.0/24  overlap: the /23 covers .0 and .1
172.16.0.0/12 vs 172.32.0.0/16  separate - 172.32 is outside 172.16-31

The fast test: take the shorter prefix (the bigger block), apply its mask to the other network address, and see if you land on the bigger block's network.

Why overlaps are permanent

Networks get connected to each other: the office to the data centre, one team's network to another's, your network to a partner's through a VPN (an encrypted tunnel over the internet that makes two networks behave as if they were joined). If both sides use 10.0.1.5, a packet sent to 10.0.1.5 has two valid destinations. Routing needs every destination to be unique, so the two networks cannot be joined while they overlap. Cloud providers refuse the connection outright.

The workaround is NAT (network address translation: a box in the middle rewrites addresses as packets pass, so each side sees unique ones). Your Mac already does NAT for the lab VM to reach the internet. For joining two overlapping networks it works for a handful of connections and is miserable to run.

The real fix is renumbering one side: new ranges, move every machine, touch every firewall rule, route, allow-list and DNS name that mentioned the old range. That is why address space is planned once, on paper, for the whole organisation, before anything is built - and why "just use 10.0.0.0/16, it's the default" is a decision someone regrets two years later, when the company buys another company that did the same.

Summarisation

Neighbouring aligned blocks can be written as one shorter prefix. Four /24s from 10.8.0.0 to 10.8.3.0 are exactly 10.8.0.0/22. One route instead of four - this is summarisation.

10.8.0.0/24 + 10.8.1.0/24                 = 10.8.0.0/23
10.8.0.0/24 + 10.8.1.0/24 + 10.8.2.0/24 + 10.8.3.0/24 = 10.8.0.0/22
10.8.1.0/24 + 10.8.2.0/24                 = NOT a /23 (10.8.1.0 is not aligned)

That is why good plans give each site or environment one power-of-two block: the routers in the middle need one route per site, not twenty.

A plan you could defend in a review

10.0.0.0/8 is too big to reason about. Split it by purpose:

10.0.0.0/16      shared services (firewall, VPN, DNS servers)
10.10.0.0/16     production, first region
10.11.0.0/16     production, second region (disaster recovery)
10.20.0.0/16     test
10.30.0.0/16     dev
10.200.0.0/14    reserved for companies we buy / future regions

Write it down, get it reviewed by whoever runs the office and data-centre network (people call that on-prem, short for on-premises: machines in your own buildings, as opposed to rented from a cloud provider), and keep it in a git repo like your lab. The address plan is infrastructure too.

Later (Ch 16): clusters add two more internal ranges (for apps and for services) that must not overlap anything in this plan either.

What you can now do

Why it helps

Address plans are one of the few network decisions you cannot undo cheaply. If two networks overlap, they cannot be joined by a VPN or a cloud link, and the fix is renumbering: every machine, firewall rule, route, allow-list and DNS name that mentioned the old range. Teams lose months to this after a company is bought or when a new network was built with the default 10.0.0.0/16.

So this knowledge pays off in reviews: you spot a misaligned block (10.0.6.0/22), an overlap with the office network, or a subnet too small for its job before anything is built. It also helps you read a routing table: summarised blocks explain why one route covers a whole site.

FAQ

Can two CIDR blocks partly overlap?

No. Because every block is aligned to its own size, two blocks are either separate or one contains the other. That gives a fast test: take the shorter prefix (the bigger block), apply its mask to the other network address, and see if you get the bigger block's network. 10.1.0.0/16 vs 10.1.5.0/24: masking 10.1.5.0 with /16 gives 10.1.0.0, so the /24 is inside.

Why is 10.0.6.0/22 invalid?

A /22 is four /24s long in the third octet, so it must start where the third octet is a multiple of 4: 0, 4, 8 and so on. 6 is not. The /22 that contains 10.0.6.0 is 10.0.4.0/22 (4 to 7). Some tools silently correct this, others reject it. Either way, if someone wrote .6.0/22, they probably meant something different, so ask.

Can NAT fix overlapping networks instead of renumbering?

For a handful of connections, sometimes: a box in the middle translates one side into an unused range so each end sees unique addresses. But every new service needs a new mapping, logs show translated addresses, DNS has to hand out the translated ones, and troubleshooting doubles in difficulty. Cloud providers refuse to link overlapping networks at all. It is a temporary patch while you renumber, not a design.

What is summarisation and why should I care?

Neighbouring, aligned blocks can be written as one shorter prefix: four /24s from 10.8.0.0 to 10.8.3.0 are exactly 10.8.0.0/22. One route instead of four. If each environment or site gets one power-of-two block, the routers in the middle need one route per site. 10.8.1.0/24 plus 10.8.2.0/24 do not summarise, because 10.8.1.0 is not aligned for a /23.

Why plan ranges for networks that do not exist yet?

Because they will exist, and they will need to reach yours. A new region, a company you buy, a partner connected by VPN: if they already use your range, you cannot join them without renumbering someone. Keeping a reserved block in the plan, and checking every new range against every existing one, is cheap on paper and very expensive to skip.

In an interview Junior

Two networks you need to connect use overlapping address ranges. Why is that a problem, and what can you do?

Routing needs every destination to be unique. If both sides use 10.0.1.5, a packet to 10.0.1.5 has two valid destinations, so the two networks cannot be joined while they overlap (cloud providers refuse the connection outright).

Options:

That is why the address space is planned once, for the whole organisation, before anything is built, with each site or environment getting one aligned, power-of-two block (so it can be summarised in one route).

Also asked: How many /26 subnets fit in a /22? · Is 10.0.6.0/22 a valid network? Why or why not? · How would you split 10.0.0.0/16 into four equal subnets?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.