CIDR calculate.

Why /24 replaced Class C.

Before 1993, IPv4 was carved into rigid classes by the most-significant bits of the address. Class A (first bit 0) gave 8-bit network and 24-bit host — 16 million hosts per allocation. Class B (10 prefix) gave 16+16. Class C (110 prefix) gave 24+8 — 256 hosts. Routing tables on the early internet were small enough that this rigidity was tolerable; growth made it untenable.

The problem was twofold. First, organisations needing more than 256 hosts had to take a Class B (65,536 addresses) and waste the bulk. Second, the routing table on backbone routers exploded as more Class C blocks were allocated — each block needed its own route entry. RFC 1518 and RFC 1519 (1993) introduced Classless Inter-Domain Routing, which let any prefix length serve as a route boundary. 192.168.0.0/22 covers four Class C blocks in one route entry; 10.0.0.0/8 aggregates 16 million addresses into a single line in a routing table.

CIDR notation is the suffix slash followed by the prefix length. 10.0.0.0/24 means "the first 24 bits are the network identifier; the last 8 bits address hosts within that network". The subnet mask form (255.255.255.0) and the wildcard form (0.0.0.255) are equivalent representations — the calculator above shows all three because different vendor tools accept different forms.

Modern routing ignores the class system entirely. The class label still appears in tools because it occasionally helps explain the address — 10.0.0.0 is "Class A" in the sense that its first byte is in the 1–126 range, and that fact correlates with which RFC 1918 private range it belongs to. But the prefix is what determines how routers handle the packet.

Three private ranges, 17 million addresses.

RFC 1918 (1996) reserved three ranges for private internal use: 10.0.0.0/8 (16,777,216 addresses), 172.16.0.0/12 (1,048,576 addresses), and 192.168.0.0/16 (65,536 addresses). These addresses are guaranteed never to appear on the public internet — backbone routers drop packets sourced from or destined to private ranges. Inside an organisation's own network, the ranges are reusable: every company runs 10.0.0.0/8 internally, and that's fine because the private spaces never collide externally.

Each range has a typical use. 10.0.0.0/8 is the workhorse for medium-to-large enterprises and most cloud VPCs — AWS default VPCs sit at 172.31.0.0/16 by default but most teams override to 10.x.0.0/16. 172.16.0.0/12 is less popular and most often appears as the AWS default. 192.168.0.0/16 is the home-router default.

The reason private ranges exist is IPv4 scarcity. With ~4.3 billion total IPv4 addresses and far more internet-connected devices than that, there isn't enough public space for everything. NAT (Network Address Translation) lets thousands of private clients share a single public IP. The combination — RFC 1918 private space plus NAT — has kept IPv4 viable for two decades past its theoretical exhaustion. RFC 6598 (2012) added 100.64.0.0/10 as "Carrier-Grade NAT" space for ISPs to share among customers.

IPv6 was supposed to solve all of this. The address space (2¹²⁸ vs 2³² in IPv4) is large enough that NAT becomes unnecessary; every device gets a globally unique address. Adoption has been gradual — Google's IPv6 adoption graph shows a slow, steady climb rather than a cutover — and dual-stack remains the operational reality. CIDR notation works identically in IPv6 (2001:db8::/32); only the address length differs.

Splitting a network into useful pieces.

A typical AWS VPC is 10.0.0.0/16 — 65,536 addresses. That's too many to use as one network; you carve it into subnets, one per availability zone, often one per workload tier (public, private, isolated). The conventional split is /24 subnets — 256 addresses each, of which 251 are usable after AWS reserves the network address, broadcast, and three internal-use addresses per subnet.

For three AZs with public/private subnet pairs, that's six subnets out of a /16 — 10.0.0.0/24 through 10.0.5.0/24. The remaining 250 /24 subnets are headroom for future growth. Many production VPCs run /20 subnets (4,096 addresses each) instead of /24 because Kubernetes pods consume IPs aggressively and a /24 of 251 usable addresses fills up after a few hundred pods.

For point-to-point links — typically VPN tunnels or transit-gateway peerings — /30 subnets give 4 addresses (2 usable) and /31 subnets give 2 addresses (both usable per RFC 3021). The /31 saves one address per link, which mattered when allocations were precious; today most teams use /30 out of habit and tooling familiarity.

For Kubernetes pod networks specifically, the prefix you pick determines the maximum number of pods per node. AWS VPC CNI defaults to one secondary IP per pod, and an EC2 instance can hold a fixed number of secondary IPs depending on instance type. For 100+ pods per node, you need a large VPC subnet (/20 or larger) and a high-IP-density instance type. Production capacity planning is essentially repeated CIDR math against expected pod density.

Why Cisco ACLs use the inverse.

A subnet mask has 1-bits for the network portion and 0-bits for the host portion. A wildcard mask is the bitwise inverse — 0s for "must match exactly" and 1s for "don't care". Cisco's IOS uses wildcard masks in access-control lists because it lets you specify non-contiguous matches that subnet masks can't express. access-list 10 permit 10.1.0.0 0.0.255.255 matches any host in 10.1.0.0/16; access-list 20 permit 10.0.0.0 0.255.0.255 matches every fourth /16.

In practice, most ACL rules use wildcard masks that are the inverse of a contiguous subnet mask, which means every CIDR /N has a corresponding wildcard. /24 = mask 255.255.255.0 = wildcard 0.0.0.255. /16 = mask 255.255.0.0 = wildcard 0.0.255.255. Memorising the common ones is helpful; the math is straightforward but copy-paste from a calculator is faster.

AWS Security Groups and Network ACLs use CIDR notation directly — no wildcard form — so most cloud engineers never see wildcards anymore. They appear in legacy on-prem networking, in firewall rules on Cisco/Juniper/Arista gear, in OSPF area definitions, and occasionally in Linux iptables rules. The wildcard form is a mostly-dying convention but old enough that you'll meet it in any infrastructure that predates 2010.