FlowingDev

CIDR and Subnetting: Slicing the Internet into Neighborhoods

Learn how CIDR notation and subnetting divide the vast IPv4 address space into manageable networks, defining how devices talk to each other on the internet.

Try the tool: Subnet / CIDR Calculator

In one sentence

CIDR is the internet's way of drawing property lines, turning a massive, chaotic field of IP addresses into neat, manageable neighborhoods where your data can find its home.

The problem it solves

Cast your mind back to the early internet of the 1980s. Life was simple. If you needed IP addresses, you asked for a "class" of them. You had three main choices:

  • Class A: 16,777,214 host addresses. For the giants.
  • Class B: 65,534 host addresses. For large organizations.
  • Class C: 254 host addresses. For the little guys.

This "classful" system was rigid and incredibly wasteful. Imagine you needed 300 IP addresses. A Class C was too small, so you had to get a Class B. Congratulations, you've just been given 65,534 addresses and are now wasting 65,234 of them. It was like needing a scooter and being forced to buy a 16-wheeler truck.

By the early 1990s, experts saw a digital apocalypse on the horizon: we were going to run out of IP addresses. The internet's routing tables—the global address book used by core routers—were also exploding in size, threatening to slow the whole system to a crawl.

In 1993, a group of engineers introduced RFC 1518 and 1519, which defined Classless Inter-Domain Routing, or CIDR (pronounced "cider"). CIDR threw out the rigid A/B/C classes. It introduced a new, flexible way to define a block of addresses of any size.

This was a game-changer. It allowed Internet Service Providers (ISPs) to allocate address blocks that were "just right" for their customers, dramatically slowing down the IPv4 address exhaustion. It also allowed for "route aggregation," where a single entry in a routing table could represent thousands of individual routes, saving the internet's backbone from collapsing under its own weight.

How it works under the hood

To get CIDR, you first need to accept a fundamental truth: IP addresses are for computers, not humans. The dotted-decimal format (192.168.1.10) is just a convenient lie we tell ourselves. The reality is binary.

First, a quick IP address and binary refresher

An IPv4 address is a 32-bit number. That's it. Thirty-two ones and zeros. We chop it into four 8-bit chunks (octets) and convert each to a decimal number (0-255) to make it readable.

Let's take 172.20.129.45:

   172   .    20   .    129   .    45
10101100 . 00010100 . 10000001 . 00101101

Every IP networking calculation, including CIDR, happens at this binary level.

The Subnet Mask: The Magic Decoder Ring

Every IP address lives a double life. Part of it identifies the network it belongs to (its street name), and part of it identifies the specific host on that network (its house number).

How does a computer know where one part ends and the other begins? It uses a subnet mask. A subnet mask is another 32-bit number that acts like a filter. Here's how it works:

  1. The subnet mask is a series of consecutive 1s followed by a series of 0s.
  2. The 1s correspond to the network portion of the address.
  3. The 0s correspond to the host portion of the address.

To find the network address, a computer performs a bitwise AND operation between the IP address and the subnet mask.

Let's say our IP is 172.20.129.45 and our mask is 255.255.0.0.

IP Address:  10101100.00010100.10000001.00101101  (172.20.129.45)
Subnet Mask: 11111111.11111111.00000000.00000000  (255.255.0.0)
-----------------------------------------------------------------
Network ID:  10101100.00010100.00000000.00000000  (172.20.0.0)

The result, 172.20.0.0, is the "street name" for every device in this network.

Enter CIDR: The Subnet Mask Shorthand

Writing out 255.255.255.0 is tedious. CIDR notation is a simple shorthand. It's just the IP address, a slash (/), and the number of leading 1s in the subnet mask. This number is called the prefix length.

CIDR Suffix Subnet Mask Number of 1s Binary Mask
/8 255.0.0.0 8 11111111.0000...
/16 255.255.0.0 16 11111111.11111111.0000...
/24 255.255.255.0 24 11111111.11111111.11111111.00000000
/29 255.255.255.248 29 ...11111111.11111000
/32 255.255.255.255 32 All 1s (a single host)

So, 172.20.129.45 with a mask of 255.255.0.0 is simply written as 172.20.129.45/16. Easy peasy.

Calculating the Good Stuff

Given a CIDR address like 10.50.84.111/22, we can figure out everything about its network neighborhood.

  • Prefix: /22. This means 22 bits are for the network, and the remaining 32 - 22 = 10 bits are for hosts.

  • Network Address: This is the first address in the range, where all host bits are 0. We find it with the AND operation.

    • IP: 10.50.84.111 -> 00001010.00110010.01010100.01101111
    • Mask /22: 255.255.252.0 -> 11111111.11111111.11111100.00000000
    • AND Result: 00001010.00110010.01010100.00000000 -> 10.50.84.0
    • So, the Network Address is 10.50.84.0.

  • Number of Hosts: We have 10 host bits. The number of possible addresses is 2^10 = 1024.

  • Usable Hosts: We have to subtract two addresses. Why?

    1. The very first address (all host bits 0) is the Network Address itself. It's the street name, not a house.
    2. The very last address (all host bits 1) is the Broadcast Address. Sending a packet here is like shouting "Hey everyone!" to every single device on the network.
    • So, usable hosts = (2^10) - 2 = 1024 - 2 = 1022.

  • Broadcast Address: This is the Network Address with all the host bits flipped to 1.

    • Network: 00001010.00110010.01010100.00000000
    • Broadcast: 00001010.00110010.01010111.11111111 -> 10.50.87.255

  • Host Range: The usable addresses are everything between the Network and Broadcast addresses.

    • First usable host: 10.50.84.1 (Network address + 1)
    • Last usable host: 10.50.87.254 (Broadcast address - 1)

So, 10.50.84.111/22 is a host on the 10.50.84.0 network, which supports 1022 devices from 10.50.84.1 to 10.50.87.254.

Real-world stories

### The Cloud Cost Calamity

A hot new startup spun up their infrastructure in a public cloud. Eager to get coding, they accepted the default network settings for their Virtual Private Cloud (VPC), which grabbed a massive /16 block (65,534 IPs). A few months later, they landed a huge client who needed a direct, secure connection between their cloud environments. The problem? The client had also used the exact same default /16 block. Their address spaces, 10.10.0.0/16 and 10.10.0.0/16, were identical. You can't route between two places that both claim to be the same address. The startup had to spend a frantic week rebuilding their entire network from scratch on a new, non-overlapping CIDR range.

Lesson: Plan your network address space like you're planning a city. Even if you only need a small village now, leave room for highways to connect to other cities later. Don't just accept the defaults.

### The Mysterious Offline Device

A junior network admin was tasked with setting up a new monitoring server. He was given the IP range 192.168.100.0/24. He configured the server with the IP 192.168.100.255. The server's network interface came up, but it was a ghost. It couldn't ping the gateway, and nothing on the network could ping it. After an hour of checking cables and reinstalling drivers, a senior engineer walked by, glanced at the screen for two seconds, and said, "That's your broadcast address." They changed the IP to 192.168.100.254, and it instantly came online.

Lesson: The first and last addresses in any subnet are special and cannot be assigned to a host. They are the network's identity and its megaphone, respectively.

### The Home Wi-Fi Wizard

A developer's home network was a mess. With laptops, phones, smart TVs, speakers, light bulbs, and a "smart" toaster, devices were constantly dropping off the Wi-Fi. Looking at her router's admin page, she saw the DHCP server was configured for the range 192.168.1.0/28. A quick calculation showed a /28 only provides (2^(32-28)) - 2 = 14 usable IP addresses. Her family had over 30 devices! She changed the subnet mask for her LAN from 255.255.255.240 (/28) to 255.255.255.0 (/24), expanding the available IPs to 254. The Wi-Fi instability vanished instantly.

Lesson: Subnetting isn't just for data centers. It dictates how many devices can join your local network, and a poorly configured subnet is a common cause of "bad Wi-Fi."

Common mistakes and traps

  • Forgetting the reserved two. A classic off-by-two error. You calculate 2^h and tell someone they have that many addresses, but you forget to subtract the network and broadcast addresses. This leads to configuration errors and networks that are just slightly too small.
  • Overlapping subnets. As seen in the cloud story, if two networks that need to communicate have overlapping IP ranges, you're in for a world of pain. Routing becomes ambiguous and often impossible without complex and ugly Network Address Translation (NAT) hacks. Plan ahead!
  • Thinking in decimal. You cannot properly understand subnetting by looking at the decimal numbers. 192.168.0.255 and 192.168.1.0 look like they're right next to each other. If you're in a /24, they're in different networks. If you're in a /23, they are in the same network. It all depends on where the binary boundary lies.
  • Misusing a /31. A /31 has 2^(32-31) = 2 addresses. The old rules said that after reserving the network and broadcast, this left zero usable hosts. However, RFC 3021 updated this for special point-to-point links (e.g., connecting two routers), where no broadcast is needed. For a regular network with clients, it's useless.
  • Fat-fingering the prefix. It's easy to type /23 when you meant /24. A one-digit difference can be the difference between a network of 254 hosts and one with 510 hosts, completely changing the network's boundaries and potentially causing conflicts. Double-check your prefix.

Why it belongs on your radar

You might think this is just for hardcore network engineers. You'd be wrong.

  • Cloud & DevOps Engineers: This is your life. Designing VPCs/VNETs in AWS, Azure, or GCP is an exercise in CIDR planning. Getting it wrong at the start leads to costly, complex migrations later.
  • Backend Developers: Can't connect to your database? Maybe the app server is on 10.0.1.0/24 and the DB is on 10.0.2.0/24. If there's no router configured between them, they might as well be on different planets. Understanding subnets is a fundamental debugging step.
  • Security Professionals: Firewall rules are often based on CIDR blocks. To allow access from an entire office, you don't add 200 individual IPs; you add one rule for 10.5.0.0/22. To block a known bad actor, you block their CIDR range.
  • Anyone who runs code: Even if you just work on localhost, you're using a network. Knowing that 127.0.0.1 is just one host in the giant 127.0.0.0/8 loopback block helps demystify a core part of local development.

In a world of interconnected services, containers, and cloud infrastructure, the network is no longer someone else's problem. Understanding its address book is a modern developer superpower.

Go deeper

Theory done. Time to get your hands dirty — 100% in your browser.

Try the tool: Subnet / CIDR Calculator