CIDR

IP addressing introduced the idea that an address splits into a network portion and a host portion, and mentioned the /24 suffix without fully explaining it. That suffix is CIDR notation, and it's the mechanism that actually defines where that split happens.

What the slash actually means

CIDR stands for Classless Inter-Domain Routing, and the "classless" part is the point — it replaced the rigid Class A/B/C scheme mentioned in the previous article with something far more flexible: any prefix length from /0 to /32 (for IPv4), letting a network be sized to whatever it actually needs instead of forced into one of three fixed sizes.

The number after the slash is the prefix length — how many of the address's leading bits belong to the network portion. 192.168.1.10/24 means the first 24 bits identify the network; the remaining 8 bits (32 − 24) identify the host within it.

192.168.1.10/24
|----- network ----|-- host --|
 192  . 168 .  1    |    10
      (24 bits)      (8 bits)

Because the prefix length is just "how many bits," you can calculate the size of any CIDR block directly: a network with a prefix length of n has 32 − n host bits, which allows 2^(32−n) total addresses.

A smaller prefix number means a larger network. This trips almost everyone up at first, so it's worth internalizing before going further: /8 reserves only 8 bits for the network, leaving 24 bits for hosts — a huge network. /30 reserves 30 bits for the network, leaving only 2 bits for hosts — a network of exactly 4 addresses.

Usable hosts vs. total addresses

Not every address in a CIDR block is assignable to a host. Two are always reserved: the network address (all host bits set to 0, identifying the network itself rather than any host on it) and the broadcast address (all host bits set to 1, used to reach every host on that network at once). So a /24 network has 256 total addresses but only 254 usable host addresses — the first and last are spoken for.

Take 192.168.1.0/24 as a concrete case: 192.168.1.0 is the network address, 192.168.1.255 is the broadcast address, and the 254 addresses in between — 192.168.1.1 through 192.168.1.254 — are the ones you can actually assign to a host. That "total minus 2" pattern is the one to memorize; everything else in this section is a variation on it.

Why CIDR exists: solving two problems at once

Classful addressing wasted addresses on a massive scale — an organization needing 300 hosts had no option between a /24 (254 usable, not quite enough) and a /16 (65,534 usable, wildly excessive) under the old class system. CIDR, introduced in 1993, fixed that by letting a network be exactly the size it needs — a /23 block, for instance, gives exactly 510 usable addresses, comfortably covering that 300-host requirement without the waste of a full Class B.

The second, less obvious problem CIDR solved was routing table growth. Every network an ISP knows how to reach needs an entry in a router's routing table. Under classful addressing, an ISP with a hundred small customer networks had a hundred separate routing entries. CIDR allows route aggregation — advertising one larger prefix that covers many smaller ones, sometimes called supernetting because it's the reverse of subnetting: instead of splitting a block into pieces, you describe many contiguous pieces with a single larger block. If those hundred customer networks all fall inside one contiguous range, the ISP's router can announce one prefix covering all of them rather than a hundred entries. This matters enormously at internet backbone scale, where the number of distinct routes a core router has to track directly affects memory usage and lookup speed.

CIDR and subnet masks are two notations for the same thing

CIDR notation (/24) and a dotted-decimal subnet mask (255.255.255.0) express identical information — which bits are network bits — just written differently. /24 means 24 leading 1-bits followed by 8 zero-bits, which written in dotted decimal is 255.255.255.0. You'll see both notations depending on the tool: cloud consoles and modern Linux tools favor CIDR slash notation, while some older router configuration interfaces still expect a dotted-decimal mask. Converting between the two by hand is covered step by step in the next article, Subnet mask calculation.

Reading CIDR in real configuration

CIDR notation shows up constantly outside of just labeling one host's address — it's how entire network ranges get referenced. A cloud provider's network configuration, a firewall rule, or a routing table all describe ranges this way:

ip route show

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

The second line reads as "the entire 192.168.1.0/24 network (all 256 addresses in that range) is reachable directly through the eth0 interface, no router needed" — this machine's own IP address (192.168.1.10) falls inside that range, so anything else in 192.168.1.0/24 is on the same local network and doesn't need to be routed anywhere. The exact interface name and addresses will differ on your own machine.

Two edge cases: /31 and /32

Once the "total minus 2" rule feels automatic, it's worth knowing where it stops applying. A /31 network has only 2 addresses, and both are usable — there's no room for a separate network and broadcast address, so the standard specifically carves out an exception for point-to-point links (two routers, one on each end of a single cable) where a broadcast address would just be wasted. A /32 goes further still: it's a single specific address, with no network or broadcast concept at all — you'll see it used to name one exact address in a routing table rather than to describe an actual network of hosts.

You won't reach for either of these when sizing a normal subnet. They matter once you start reading router configuration or route tables and see a prefix that doesn't fit the pattern you just learned.

Interview trap

An interviewer asks: "How many hosts fit in a /24?" The tempting answer is 256, because that's what 2^(32-24) gives you, and it's wrong in the context of "how many hosts can I assign." The honest answer distinguishes two numbers: 256 total addresses, 254 usable host addresses — the network and broadcast addresses are still part of the block, they're just not assignable to a device. Saying "256" without qualifying it signals you memorized the exponent without understanding what a network and broadcast address actually consume. The safest phrasing in an interview is to answer with both numbers and name why they differ, rather than picking one.

A related trap: don't call /31 or /32 exceptions to "the rule that address math always works the same way." They're not exceptions to the arithmetic — 2^(32-31) = 2 is still correct. They're exceptions to the convention that the first and last address of a block are reserved. RFC 3021 explicitly repurposes both addresses of a /31 for point-to-point links precisely because there's no room to spare.

Practical scenario: planning subnets before the cloud console

Suppose you are given 10.20.0.0/24 for a small staging environment. You need separate networks for public load balancers, private application servers, and private databases. A quick plan might look like this:

Purpose          CIDR block       Total addresses  Typical use
---------------  ---------------  ---------------  --------------------------
Public edge      10.20.0.0/26     64               load balancers, jump host
Private apps     10.20.0.64/26    64               API and worker instances
Private data     10.20.0.128/27   32               databases, caches
Reserved growth  10.20.0.160/27   32               future internal services

This is not about memorizing pretty CIDR blocks. It is about making sure ranges do not overlap, leaving room for growth, and avoiding a painful migration later. A /30 might be mathematically valid, but it is useless for a subnet that needs several servers. A /16 might feel convenient, but it can collide with another network when you later connect two environments.

CIDR is the notation you use before the infrastructure exists. Once the network is live, changing it becomes much harder than drawing a better plan up front.

Common mistakes

• Reading a smaller prefix number as "smaller network." It's the opposite — fewer network bits means more host bits, which means more addresses.
• Assuming every address in a CIDR block is usable. Subtract two for the network and broadcast addresses (except on /31 and /32, which are special cases), and more than two on a cloud provider.
• Writing a prefix length without checking it makes sense for the context. A /32 describing "an entire company's network" is a common copy-paste error — it actually describes exactly one address.
• Confusing a CIDR block's size with how many hosts are currently on it. 192.168.1.0/24 can hold up to 254 hosts; it doesn't mean 254 hosts are actually connected.

Practice exercises

1. Calculate the number of usable host addresses in a /27 network, showing your work using host-bit count. Then state how many you'd actually be able to assign in an AWS VPC subnet of that size.
2. Given the network 10.0.4.0/22, state how many total addresses it contains and what the first (network) and last (broadcast) addresses are.
3. Explain, in your own words, why an ISP would prefer to advertise one /20 route instead of sixteen separate /24 routes that happen to be contiguous, referencing what a router actually has to do with each routing table entry.

A quick way to test yourself: pick prefix lengths at random between /20 and /30 and convert each to a usable host count without writing anything down. If that arithmetic is still slow, the next article will feel like guesswork rather than calculation, because everything in it — network addresses, broadcast addresses, subnet boundaries — is built on knowing how many host bits a prefix leaves behind.

Exercise 2 is where the gap shows up most clearly. Working out that 10.0.4.0/22 ends at 10.0.7.255 means knowing which octet the boundary falls in and what the mask looks like there, and doing that reliably needs a procedure rather than intuition. Subnet mask calculation is that procedure.

Sources

• IETF, RFC 4632 – Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
• IETF, RFC 1519 – Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy — the original 1993 specification, since superseded by RFC 4632.
• IETF, RFC 3021 – Using 31-Bit Prefixes on IPv4 Point-to-Point Links
• AWS, Subnet CIDR blocks — documents the five addresses reserved in every VPC subnet.