Split the address space by hand

Goal

Dividing up address ranges is one of the hardest decisions to reverse. The range of a VPC cannot be reduced after it is created, and a subnet cannot be deleted if it has resources in it. What you decide in the first 30 minutes lasts for years.

Here you work out the answers not with a calculator but by boundaries and lengths.

Materials

/opt/lab/netplan/allocations.txt   사내 대역 배정표
/opt/lab/netplan/routes.txt        어느 라우터의 표

First copy them to a working directory.

mkdir -p /root/netplan && cp /opt/lab/netplan/* /root/netplan/ && cd /root/netplan

What to leave

01-here.txt     내 주소·프리픽스·기본 경로
02-split.txt    /16 을 나눈 계획
03-overlap.txt  겹치는 짝
04-longest.txt  세 목적지가 가는 길
05-usable.txt   크기별로 실제 쓸 수 있는 수

Where am I now

Save this Pod's IPv4 address and prefix, and the default route, to 01-here.txt, and write one line on what that prefix means.

Use ip -4 -o addr show and ip route.

If the prefix is /32, it means there is not a single neighbor in the same range. Even so, it can get out because there is a separate scope link route.

Divide along the boundaries

Divide 10.20.0.0/16 into four /18s and assign the first three to three AZs. In each AZ, take the first /24 as the public subnet. Leave the fourth /18 unused, and write why you leave it. Save the result in 02-split.txt.

python3 -c "import ipaddress as ip; print([str(n) for n in ip.ip_network('10.20.0.0/16').subnets(new_prefix=18)])"

For each /18, its first /24 is that /18's starting address with /24 attached.

Write why you leave the fourth one. A VPC range is cumbersome to expand later, and if there is no room to attach when an AZ is added or a new purpose arises, you have to pull in another range.

Find the overlapping pairs

Find all the pairs of ranges that overlap each other in allocations.txt and write them in 03-overlap.txt, and add one line on what is blocked when they overlap.

Check every pair with ipaddress.ip_network(a).overlaps(ip_network(b)).

There are two overlapping pairs. You must not include ones that do not overlap: if you report an overlap where there is none, you end up re-planning perfectly good ranges.

Length decides, not order

Look at routes.txt and write in 04-longest.txt which route each of 10.20.4.200 · 10.20.9.5 · 172.20.1.1 goes out by. Include the next hop address as well.

The kernel does not look at the order of the table. If several routes match, it picks the one with the longest prefix.

10.20.4.200 matches both /24 and /25. 10.20.9.5 matches a scope link route, which means it does not go through a gateway.

How many you can actually use

For each of /24 · /25 · /26 · /28, write in 05-usable.txt, as a table, the total number of addresses and the number actually usable after the cloud reserves five, and add one line on where those five go.

The total is 2^(32-프리픽스) (where the Korean word means "prefix"). Most clouds take five per subnet: the network address, the gateway, DNS, a spare, and the broadcast.

The smaller the subnet, the larger the proportion of this loss. In a /28, five of the 16 disappear.

How far the usable space extends

Write all the ranges usable as private in 06-private.txt, and mark which private range each range in allocations.txt falls into. Then add one line on which places to avoid.

RFC 1918 defines three, and in addition there is one more range defined by RFC 6598. It is not private, but it is not routed over the Internet, so you can use it internally.

Also write down the places to avoid. 10.0.0.0/16 and 192.168.0.0/24 are ranges that everyone picks first, so they have the highest probability of overlapping with a peer you will someday need to connect.

Leave a rule, not a table

Write in 07-decide.md a rule that lets the next person choose a range on their own without looking at a document. Write together what size to use for each of the three units, region, AZ, and purpose, and why you allocate generously.

A table of "which team uses which range" soon becomes stale. Instead, if you write a rule such as "a /16 per region, a /20 per AZ, a /24 per purpose", there are no collisions even if you do not look at the table.

Also write why you allocate large. IPs are free and running short is expensive: the moment you attach a container network in which every Pod uses an IP, a /24 runs out.