CIDR to IP Range & Subnet Calculator

From Classful Addressing to RFC 1519

Before CIDR, IPv4 address allocation followed rigid class boundaries defined in the original IP specification: Class A, B, and C networks came in only three fixed sizes, so an organization needing 300 addresses had no choice but to take an entire Class B block of 65,536. RFC 1519, published in 1993, replaced this scheme with Classless Inter-Domain Routing — variable-length subnet masking that lets a network of almost any size be carved from the available address space using notation like 10.0.0.0/24. The change wasn't just a convenience; without it, the internet's finite pool of IPv4 addresses and global routing table capacity would have been exhausted years earlier than they eventually were.

CIDR notation itself is simple by design: the number after the slash states how many leading bits are fixed as the network portion, with the remaining bits available for host addresses. RFC 1918 layered a second convention on top of this — reserving 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 as private ranges that public-internet routers will never forward, which is why every VPC, home network, and Kubernetes cluster today builds its internal addressing from one of these three blocks.

Subnetting Decisions at Fleet Scale

Getting a CIDR block's size wrong matters far more once a network is provisioned than it does on a whiteboard. A VPC's CIDR range is difficult to resize after subnets, route tables, and peering connections are attached to it — under-provisioning early forces a disruptive re-architecture later, while over-provisioning carries no runtime cost but occasionally collides with other blocks during a VPC peering or VPN setup. Kubernetes pod networking makes the stakes concrete: many CNI plugins allocate a fixed-size slice — commonly a /24, providing 254 pod IPs — to each node from the cluster's overall pod CIDR, so a cluster's maximum node count is effectively capped by how many /24s fit inside the configured pod CIDR. A /16 pod range yields up to 256 such /24 allocations, which is why clusters expecting to scale into the hundreds of nodes are usually given a /16 or larger from day one rather than resized under pressure once nodes start failing to join.

Where Engineers Reach for This Calculator

• Sizing a new VPC or VNet: confirming a candidate CIDR block provides enough headroom for every subnet, availability zone, and future service before the network is provisioned.
• Writing firewall and security group rules: checking whether a specific IP address falls inside an existing CIDR block before adding or auditing an ingress rule.
• Planning Kubernetes cluster networking: verifying that pod CIDR, service CIDR, and node network ranges don't overlap with each other or with peered corporate networks.
• Splitting a block across environments: dividing one large allocation into per-availability-zone or per-tier (public/private/database) subnets and confirming the resulting host counts before deployment.

The Overlapping-CIDR Incident

A common and entirely avoidable outage pattern involves two networks provisioned independently — say, a company's original AWS VPC and a newly acquired subsidiary's VPC — both defaulting to the same popular 10.0.0.0/16 or 192.168.0.0/16 range. Everything works fine until the two networks need to talk to each other through a VPC peering connection or site-to-site VPN, at which point the peering request fails outright: overlapping CIDR ranges cannot be routed between each other, because neither side has a way to know which 10.0.1.5 traffic is meant for which network.

Untangling this after the fact means re-addressing an entire live network, migrating every resource's IP, and updating every hardcoded reference to the old range — a project that can take months. Teams that get burned by this once typically start maintaining a documented, non-overlapping CIDR allocation plan across every account and environment before any new VPC is created, checking every new block against that master plan with a calculator like this one rather than accepting whatever range a cloud console suggests by default.

Frequently Asked Questions