What is CIDR? Classless routing and slash notation explained

What is CIDR? CIDR stands for Classless Inter-Domain Routing, the set of rules the internet has used since 1993 to allocate IP addresses and route traffic. It changed two things. First, it removed the fixed network sizes of Class A, B and C: the network part of an address can be any length from 0 to 32 bits, written after a slash, as in 172.18.20.0/22. Second, it allowed contiguous blocks to be aggregated into a single route. When people say “CIDR notation” or “a CIDR block”, they mean this start-address/prefix-length format, which tells you in one string where a block begins and how big it is.

Why CIDR replaced classful addressing

Before CIDR, IPv4 addresses were classified by their first octet, and the network part came in only three lengths:

Class	First octet	Network bits	Networks in the class	Usable hosts per network
A	1–126	8	126	16,777,214
B	128–191	16	16,384	65,534
C	192–223	24	2,097,152	254

The trouble was how coarse those steps were. An organization that needed 2,000 hosts could not fit into a Class C with its 254 hosts, so it got a Class B and used about 3% of the 65,534 addresses. With only 16,384 Class B networks in existence, that could not last. The alternative, handing the same organization eight Class C networks, saved addresses but put eight separate routes into every backbone router, and routing tables swelled.

RFC 1519, published in September 1993, summed up the crisis in three points: Class B space was close to exhaustion; routing tables on internet routers were growing beyond what the software and the people running it could manage effectively; and the 32-bit address space itself would eventually run out. CIDR tackled the first two:

• Any prefix length. A site that needs 2,000 addresses gets a /21 (2,048 addresses, 2,046 usable) instead of choosing between 254 and 65,534.
• Hierarchical allocation and aggregation. Addresses flow from the registries to ISPs and from ISPs to their customers. An ISP holding hundreds of small customer blocks advertises one aggregated prefix to the rest of the internet.

RFC 4632 replaced RFC 1519 in 2006 and the rules have not changed since. Classful subnetting could only cut a classful network into smaller pieces; CIDR lets a block be larger or smaller than /8, /16 or /24, and both allocation and routing look only at the prefix length, never at the first octet. The third problem, the 32-bit space running out, is the one IPv6 was designed to solve.

How to read /n: the first n bits are fixed

In address/n, the first n of the 32 bits are the network prefix, and every address in the block shares them. The remaining 32 − n bits are free to vary. Three numbers follow directly:

• Block size: 2^(32 − n). A /22 holds 2^10 = 1,024 addresses.
• Subnet mask: n ones followed by zeros. A /22 is 255.255.252.0.
• Start address: the last 32 − n bits must all be zero, so the start is always a multiple of the block size.

When n is 8, 16 or 24, the boundaries line up with the dots: a /24 fixes the first three octets and the fourth runs from 0 to 255. When n is not a multiple of 8, the prefix cuts one octet in two, and that octet decides where blocks begin and end. For prefixes from /17 to /24 it is the third octet:

Prefix	Third-octet step	Blocks per /16	Valid third-octet starts	Addresses per block
/17	128	2	0, 128	32,768
/18	64	4	0, 64, 128, 192	16,384
/19	32	8	0, 32, 64 … 224	8,192
/20	16	16	0, 16, 32 … 240	4,096
/21	8	32	0, 8, 16 … 248	2,048
/22	4	64	0, 4, 8 … 252	1,024
/23	2	128	Any even number	512
/24	1	256	Any value 0–255	256

Prefixes /25 through /32 follow exactly the same pattern in the fourth octet: a /25 steps by 128, a /26 by 64, and so on down to a /30 stepping by 4. You can work out the step for any prefix in your head. Take r = n mod 8; the step in the split octet is 2^(8 − r). A /22 has r = 6, so the step is 2^2 = 4; a /27 has r = 3, so the fourth octet steps by 2^5 = 32. If r is 0, the prefix is octet-aligned and you do not need the formula at all.

Prefixes that split an octet: /22 and /23 examples

Example 1: which addresses are in 172.18.20.0/22? Since 22 − 16 = 6, the first 6 bits of the third octet belong to the prefix, and its last 2 bits plus the 8 bits of the fourth octet are free:

172.18.20.0/22
third octet 20 = 000101|00   first 6 bits are fixed (16 + 6 = 22)
                        ^^   these 2 bits plus the 8 bits of the fourth octet vary: 10 bits
third octet can be 000101 followed by 00, 01, 10 or 11, i.e. 20, 21, 22, 23
range: 172.18.20.0 to 172.18.23.255, 2^10 = 1,024 addresses

So a /22 is four consecutive /24s, with the third octet running from 20 to 23. Used as a single subnet, its network address is 172.18.20.0, its broadcast address is 172.18.23.255, and all 1,022 addresses in between can be assigned.

Example 2: which /22 contains 172.18.27.130? Look at the third octet. The /22 step is 4, and 27 divided by 4 is 6 remainder 3, so the block starts at 6 × 4 = 24. The address belongs to 172.18.24.0/22, which runs from 172.18.24.0 to 172.18.27.255.

Example 3: 172.18.26.0/23. The step is 2 and 26 is even, so it is a valid start. The block runs from 172.18.26.0 to 172.18.27.255, 512 addresses in total. Inside it, 172.18.26.255 and 172.18.27.0 are ordinary host addresses you can give to servers; the only broadcast address is the last one, 172.18.27.255.

These examples line up with the most common misreadings:

Notation	Common misreading	What it actually means
172.18.20.0/22	Only the 172.18.20.x range	Four /24s: third octet 20, 21, 22 and 23
172.18.22.0/22	A block starting at third octet 22	22 is not a multiple of 4, so it is not a valid start; the address sits inside 172.18.20.0/22
172.18.26.255 inside 172.18.26.0/23	Ends in .255, so it is the broadcast address	An ordinary usable address; the broadcast is 172.18.27.255
Any two adjacent /24s	Can always be merged into a /23	Only a pair starting on an even third octet: 26 and 27 merge, 27 and 28 do not

The third row is the one that causes real incidents. Form validators and old scripts that hard-code “addresses ending in .0 or .255 are invalid” will reject perfectly good addresses in the middle of a /23 or /22. Decide whether an address is usable from the block boundaries, never from its last octet.

One block, one valid way to write it

A prefix and an address block are two descriptions of the same thing: the prefix is the n bits that every address in the block shares, and the block is every address that shares them. So a valid block has exactly one correct notation, with a unique start and length. If the address before the slash is not the start of the block, meaning its host bits are not all zero, the string does not describe a block, and many tools refuse it:

# Host bits set: not a valid route destination
$ ip route add 172.18.22.0/22 via 10.0.0.1
Error: Invalid prefix for given prefix length.

# Python refuses it too; the last line of the traceback is:
$ python3 -c "import ipaddress; ipaddress.ip_network('172.18.22.0/22')"
ValueError: 172.18.22.0/22 has host bits set

# strict=False maps it to the block that contains it
$ python3 -c "import ipaddress; print(ipaddress.ip_network('172.18.22.0/22', strict=False))"
172.18.20.0/22

The same slash notation is perfectly valid on an interface, though. ip addr add 172.18.22.15/22 dev eth0 means “this host’s address is 172.18.22.15, and the block it lives in has a prefix length of 22”; the kernel works out the subnet 172.18.20.0/22 and adds the connected route by itself. The rule of thumb: routing tables, firewall rules, allocation records and IPAM entries describe blocks, so the address before the slash must be the start; interface configuration describes an address plus a prefix length, so the address before the slash is the host’s own.

The reverse holds as well: a contiguous range that does not sit on block boundaries cannot be written as a single CIDR. 172.18.21.0 to 172.18.24.255 happens to be exactly four /24s, but 21 is not a multiple of 4, so it is not a /22. It takes at least three blocks:

$ python3 -c "import ipaddress as i; print(*i.summarize_address_range(i.ip_address('172.18.21.0'), i.ip_address('172.18.24.255')))"
172.18.21.0/24 172.18.22.0/23 172.18.24.0/24

When an allocation arrives as a start-to-end range, convert it with this one-liner before you type it into a firewall or router configuration.

How routers use CIDR: longest prefix match

With prefixes of any length, one destination can fall inside several routes at once. Routers settle this with longest prefix match: among all the routes that match, the one with the longest prefix, meaning the smallest and most specific block, wins. Suppose a router holds these four routes:

Destination prefix	Next hop	Matches 172.18.22.9?
0.0.0.0/0	10.0.0.1 (upstream)	Yes, /0 matches everything
172.18.0.0/16	10.0.1.1	Yes
172.18.20.0/22	10.0.2.1	Yes, 22 is within 20–23
172.18.22.0/24	10.0.3.1	Yes

A packet for 172.18.22.9 matches all four and takes the /24 via 10.0.3.1. A packet for 172.18.21.9 misses the /24 and takes the /22 via 10.0.2.1. 172.18.40.1 matches only the /16 and the /0, so the /16 wins, and 8.8.8.8 falls through to the default route. To see which route a device actually chooses for an address, ask it:

# Linux: shows the next hop and outgoing interface actually selected
ip route get 172.18.22.9
# 172.18.22.9 via 10.0.3.1 dev eth0 src 10.0.0.10

On Cisco IOS the equivalent is show ip route 172.18.22.9, and on Huawei and H3C it is display ip routing-table 172.18.22.9; both show the route that finally matches.

This rule is what makes aggregation safe. An ISP advertises one large prefix to the internet and uses longer prefixes internally to deliver traffic to each customer, without any conflict. It also explains some everyday data center behavior. A DDoS scrubbing service can pull a customer’s traffic through its scrubbing centers during an attack by announcing a more specific prefix than the original route. And a mistyped, more specific static route on an internal router can break one small slice of a large range while every address around it keeps working.

Keeping CIDR blocks consistent in IPAM

The most common problem in a data center’s address records is not bad arithmetic but inconsistent notation: some ranges recorded as start and end addresses, some as CIDR, and some entered as non-starting strings like 172.18.22.0/22. A few years later nobody can say which blocks overlap.

IP address management in Toplink DCIM takes CIDR as its input format. Enter a block and it works out the first address, last address and netmask, with the gateway set to either the first or the last address in the block. Large blocks such as a /22 or /21 can be split into /24s and managed separately, each with its data center, VLAN and gateway device on record. IPv6 blocks are entered by CIDR too and split by prefix length. Once every range is registered as a proper block, a utilization chart shows who holds which block and how much space is left.