CIDR Range Tool

What CIDR notation tells you

CIDR (Classless Inter-Domain Routing) replaced the old class A/B/C system. Instead of being limited to /8, /16, or /24 boundaries, CIDR lets you size subnets to fit. Each "prefix length" specifies how many bits identify the network — and the rest are available for hosts.

Block sizes by prefix

CIDR in practice: how I actually use it

CIDR notation (short for Classless Inter-Domain Routing) is one of those things that looks like arcane math the first time you see it and becomes second nature after a few months of writing firewall rules. The idea replaced the old class-based system (Class A, B, C) in 1993 because the old classes were incredibly wasteful — a small business needing 500 IP addresses would get allocated a full Class B block of 65,536 addresses, most of which sat unused. CIDR let network operators allocate exactly the size they needed, and the notation of "IP address slash prefix length" turned out to be simpler than the alternatives once you got used to it.

The prefix number after the slash tells you how many bits of the address are the network portion. Everything after that is the host portion. A /24 means the first 24 bits are network, leaving 8 bits (256 combinations) for hosts. A /16 means 16 bits are network, leaving 65,536 combinations. Every additional bit in the network portion cuts the block size in half.

The addresses at the very start and very end of any block are typically reserved: the first address (all zeros in the host portion) is the network address, used to identify the block itself, and the last address (all ones) is the broadcast address, used to send packets to every host in the block. So a /24 that theoretically has 256 addresses actually gives you 254 usable ones for actual devices. The exception is when you're carving up address space for point-to-point links between routers, in which case /30 gives you exactly 2 usable addresses — one for each end — and /31 gives you two more with no network/broadcast reservation (defined in RFC 3021).

Where I use CIDR every day

Writing firewall rules

When I want to allow SSH access from my entire office network to a server, I don't write 254 individual rules. I write one rule with a CIDR block. If the office LAN is 10.1.0.0/24, that one CIDR expression covers every device in that subnet. If I later add a second VLAN at 10.1.1.0/24 and want to include it, I can expand the rule to 10.1.0.0/23, which covers both. The prefix length shrunk by one bit, and the block size doubled.

This kind of aggregation is what makes CIDR practical. Rather than maintaining a list that grows every time you add a subnet, you write rules against blocks that summarize multiple subnets. Cloudflare's IP ranges are a good example — they publish a list of about 15 IPv4 CIDR blocks and 7 IPv6 blocks that cover every server in their global network. If you want to allow traffic from Cloudflare's edge (for real-source-IP restoration or origin protection), you can import those 22 blocks into your firewall instead of trying to enumerate the thousands of individual IPs behind them.

Route summarization

Same principle applies to routing tables. If a router needs to know how to reach ten different /24 networks that all share the same next hop, it's more efficient to advertise a single /20 that covers all ten. This keeps the internet's routing tables — which are already enormous — from growing faster than they have to. The concept has a name in the routing world (route aggregation, or route summarization) and it's one of the reasons the IPv4 internet still works despite there being millions of allocated networks.

Determining if two IPs are on the same subnet

When I'm troubleshooting a connectivity problem, one of the first things I check is whether two devices that should be talking to each other are on the same layer-2 network or need a router hop. If a device at 192.168.1.42 can't reach a device at 192.168.1.87, and both have a /24 subnet mask, they should be able to communicate directly without a router — so the problem is at layer 2 (switch, VLAN misconfiguration, cable, or the device itself). If the first device has a /25 mask, its subnet ends at .127, and traffic to .87 takes a different path than traffic to .150, even though the first three octets match.

This is a surprisingly common source of bugs. A default gateway with a wrong subnet mask can silently work fine for most traffic but fail for the small subset of hosts that fall on the wrong side of the mask boundary. The CIDR tool helps me sanity-check by expanding a network address and mask into its actual range, so I can see immediately whether a given IP is inside or outside the subnet.

Common prefix lengths and when to reach for them

A rough guide from my daily use, not an exhaustive list:

• /8 through /15: usually large ISP or cloud provider allocations. You rarely deal with these directly except when writing rules against major networks (like the RFC 1918 10.0.0.0/8 private range).
• /16: the size of a decent-sized corporate network. RFC 1918 gives you 172.16.0.0/12 and 192.168.0.0/16 in this territory.
• /20 through /23: mid-sized business networks or aggregations of smaller subnets. Common in ISP allocations to business customers.
• /24: the classic office LAN size. 254 usable hosts, easy to fit on paper, easy to reason about. Most home networks are also /24, though the user isn't usually aware of it.
• /25 through /28: subdivisions of /24 for smaller networks — a VLAN with 30 devices, a DMZ, a wireless guest network. VLSM (Variable Length Subnet Masking, essentially just CIDR applied to internal networks) uses these regularly.
• /29 and /30: point-to-point links. /30 gives you exactly 2 usable IPs, one for each end of the link. /29 gives you 6 usable, enough for a small router cluster with an interconnect.
• /31: also point-to-point but skips the network/broadcast reservation per RFC 3021. Widely supported by modern routers, still not universal.
• /32: exactly one IP. Used in access control lists to allow or deny a single host.

IPv6 works the same way, just longer

Everything above applies to IPv6, but the numbers are much bigger. An IPv6 address is 128 bits versus IPv4's 32, so you have a lot more room to work with. Common IPv6 prefix lengths include /48 for a customer allocation (a small business gets a /48 by default, which contains 65,536 /64 subnets), /64 for individual subnets (Autoconfiguration and SLAAC rely on this size), and /128 for a single IPv6 host.

The internet has largely settled on /64 as the smallest routable IPv6 subnet, which sometimes surprises people coming from IPv4 where sizes down to /30 are common. There's plenty of room in the IPv6 address space, so wasting a full /64 on a point-to-point link between two routers is considered fine.

Related tools on this site

If you need to convert between prefix length and dotted-decimal subnet mask (255.255.255.0 versus /24), use the Subnet Calculator. It shows the mask, the wildcard mask (useful for Cisco ACLs), the network address, the broadcast address, the usable host range, and the total host count in one view.

If you're trying to figure out whether your ISP has put you behind Carrier-Grade NAT (which uses 100.64.0.0/10), the CGNAT Detection tool will tell you by comparing your public IP against known CGNAT ranges. This matters for anyone trying to self-host services, since CGNAT breaks inbound port forwarding.

If you want to see the reference table of every CIDR prefix from /0 through /32 with mask, hosts, and block size, the Subnet Mask Table has the full grid on one page.

Common mistakes I've made and seen

Off-by-one on host counts

A /24 has 256 addresses but only 254 usable ones. This mistake shows up in DHCP scope configuration all the time — someone sets a scope from .0 to .255 and the DHCP server complains because .0 and .255 are reserved. Or a network engineer plans for exactly 254 devices, forgets about the reservation, and runs out of addresses at device 253 (because .0 was assigned as the router gateway).

Mask mismatches across interfaces

Two devices on the same physical network configured with different subnet masks can produce mysterious failures. Device A thinks its network is /24 and sees Device B (also on the same wire) as local. Device B thinks its network is /25 and sees Device A as remote, so it sends traffic to its default gateway, which either drops it or hairpins it back and adds latency. If pings work one way but not the other, this is worth checking.

Confusing subnet mask with wildcard mask

Cisco ACLs use wildcard masks, which are the bit-inverse of subnet masks. A /24 subnet uses subnet mask 255.255.255.0 but wildcard mask 0.0.0.255. Getting these backwards produces rules that either match nothing or match everything, depending on which direction you're wrong. The CIDR and Subnet tools on this site show both notations so you don't have to invert them by hand.

Assuming CIDR blocks always start on a "nice" boundary

A /24 like 10.5.7.0/24 makes sense; the block starts at .0 and ends at .255. But a /28 has to start on a multiple of 16 (0, 16, 32, 48...) and covers 16 addresses. If you write "10.5.7.10/28" in a rule, most tools will normalize it to 10.5.7.0/28 (because .10 falls inside that block), but some tools will error and complain that the address isn't a valid network address. Knowing which tools normalize and which don't saves you from confusing error messages.