CIDR and subnet planning: summarisation, alignment and overlap
Address count from the prefix length, when two networks can be summarised into one block, overlap checking and common mistakes in the address plan when building a VPN or cloud network.
The address plan is one of the most expensive decisions to change once the network is built. A block that looks ample on day one runs out when you add a second branch, a VPN or a cloud network. The basics below (for IPv4) are enough to build the plan soundly from the start.
Address count from the prefix
A /n prefix says that the first n of the 32 bits identify the network. The block holds 2^(32-n) addresses:
- /24: 256 addresses (usually 254 usable for clients)
- /23: 512 addresses
- /22: 1,024 addresses
In classic networks the first address is the network address and the last is the broadcast address, so the usable count is two fewer (2 of the 4 addresses in a /30; /31 is a special exception for point-to-point links). Cloud providers reserve addresses of their own as well; the number varies by provider, so plan according to its documentation.
Alignment: a block starts at a multiple of its own size
A /24 block starts at an address that is a multiple of 256, a /23 at a multiple of 512. That is why 10.0.0.0/24 and 10.0.1.0/24 merge into 10.0.0.0/23: third byte 0 and 1 exactly fill a 512-address block. By contrast 10.0.1.0/24 and 10.0.2.0/24 look adjacent, but because 10.0.1.0 does not start at an even third byte they do not fit into a single /23; if you try to summarise them as one block you include addresses in between and around them. Four consecutive /24s (10.0.0.0 to 10.0.3.0) can be summarised as 10.0.0.0/22.
Why summarisation matters
Keeping a single line in the routing table instead of dozens of branch networks shrinks the table and hides faults. But if the summary block also covers addresses that are not yours, traffic can go to the wrong place. Summarisation is safe only for blocks that are truly contiguous and aligned; plan by splitting into large, aligned blocks from the start (a /24 per branch, a /20 per region, for example).
Overlap checking
Two blocks overlap if the address range of one intersects the other; they also overlap if one block lies inside the other. Example: 10.20.0.0/16 and 10.20.8.0/21 overlap, because the /21 covers addresses with third byte 8-15, which are inside the /16. Overlap appears most often when:
- The company network and a home or guest network use the same default block, so routes get mixed up over the VPN.
- Two companies merge and both use 10.0.0.0/16.
- A cloud virtual network and the local network were built in the same block and are to be connected.
A planning pattern
- Place the largest requirement first, then work down to the small ones (VLSM).
- Leave growth room in every block: twice today's need is a common yardstick.
- Avoid common blocks such as the default 192.168.0.0/24 and 10.0.0.0/24 so as not to overlap with networks that may connect in future (partners, cloud).
- Write the usage in a table: block, purpose, owner, date.
Try it with the tools
For an address and prefix, see the network, broadcast, first-last address and host count with the IP subnet and CIDR calculator. To summarise several blocks into one or to check overlap, use CIDR summarisation and merging; for IPv6 there is the IPv6 subnet calculator. To review your network and cloud address plan together, get in touch.
Let's discuss this for your plant
More notes
All notes →- 3 min readSix common mistakes on medical device UDI labelsPackaging levels, changes that require a new UDI-DI, confusing Basic UDI-DI with UDI-DI, missing production identifiers, labels that don't match the barcode and unmeasured print quality: the most common UDI mistakes for medical devices.
- 3 min readSix ways the case–pallet relationship breaks in aggregationRejected packs, partial cases, sampling, manual handling, double assignment and pallet breakdown: the most common situations in which aggregation records drift from physical content, and how to prevent them on the line.
- 2 min readGaps and bad records in SCADA data: what to do before modellingTimestamps, gaps, frozen sensors, physically impossible values, curtailment and maintenance periods, sensor replacement: what to check in SCADA data before building a predictive maintenance or power forecasting model.