IP Addresses, Subnets, and CIDR for DevOps

Almost every “why can’t these two things talk to each other?” incident eventually comes down to a subnet. A pod cannot reach a service, a VPN tunnel comes up but no traffic flows, a new Docker network refuses to start — and the root cause is an address that is on the wrong side of a boundary you did not know was there. That boundary is defined by the subnet mask, and the shorthand we write it in is called CIDR. This lesson builds the mental model and the arithmetic so you can look at an address like 192.168.10.25/24 and immediately know which other addresses are “local”, where the network starts and ends, and how many machines can live inside it.

You do not need prior networking theory beyond the networking fundamentals lesson. We will define every term, do the math by hand, then confirm it with a tool. Kali is a good place to practise this because the same commands you use to read a network are the ones you use to design one.

What You Will Learn

• What an IPv4 address really is, and the three special addresses in every subnet: network, broadcast, and usable hosts.
• How a netmask and its CIDR prefix (/24, /25, …) decide the size of a network.
• Host counts for the prefixes you will meet daily: /16, /24, /25, /26, /27.
• How to confirm your reasoning with ipcalc, and how to reason without it.
• Why the same arithmetic governs cloud VPC subnets, Kubernetes pod and service networks, Docker bridges, and OpenStack Neutron subnets — and why overlapping CIDR ranges cause real production outages.

What an IPv4 Address Actually Is

An IPv4 address is a 32-bit number, but we write it as four 8-bit chunks (called octets) separated by dots, each from 0 to 255:

192   .   168   .   10   .   25
 |         |        |       |
octet1  octet2   octet3  octet4   (8 bits each = 32 bits total)

On its own, 192.168.10.25 tells you nothing about which network it belongs to. Two addresses that look similar may be on completely different networks, and two that look different may be neighbours. What splits an address into a network part (which network am I on?) and a host part (which machine am I on that network?) is the subnet mask.

Netmask and CIDR: The Boundary Line

The netmask is another 32-bit value. Every bit set to 1 marks a bit that belongs to the network part; every 0 marks a bit that belongs to the host part. A common mask written the old way is 255.255.255.0. In binary that is twenty-four 1s followed by eight 0s:

255.255.255.0  = 11111111.11111111.11111111.00000000
                 \_________ network _________/\_ host _/
                          24 bits              8 bits

Counting those leading 1s gives us CIDR notation (Classless Inter-Domain Routing): twenty-four network bits is written /24, so 255.255.255.0 and /24 are the same statement. CIDR is just a compact way to say “how many bits from the left are the network part.” The larger the prefix number, the more bits are locked to the network and the fewer host bits remain — which means a smaller network.

🛠️ DevOps Perspective — You will almost never type a netmask like 255.255.255.192 in modern tooling. Cloud consoles, ip, Docker, and Kubernetes all speak CIDR (10.0.0.0/26). Train yourself to read the /NN and picture the size immediately; converting to dotted-decimal masks is a party trick you rarely need.

Worked Example: 192.168.10.25/24

Take the address and prefix 192.168.10.25/24. The /24 says the first 24 bits (the first three octets, 192.168.10) are the network, and the last 8 bits (the final octet) identify the host. From that single fact we can derive every important address in the subnet:

Network:   192.168.10.0
Hosts:     192.168.10.1 - 192.168.10.254
Broadcast: 192.168.10.255

Three ideas are doing all the work here:

• Network address — host bits all 0 (192.168.10.0). This names the subnet; it is not assigned to any machine.
• Broadcast address — host bits all 1 (192.168.10.255). Traffic sent here reaches every host on the subnet; it is also not assigned to a machine.
• Usable host addresses — everything in between (.1 through .254). With 8 host bits there are 2^8 = 256 total addresses, minus the network and broadcast, leaving 254 usable.

That subtraction — 2^(host bits) − 2 — is the whole game. It is why a /24 gives 254 usable addresses, not 256.

🔎 Troubleshooting Tip — When someone hands you an IP and asks “is that address on my network?”, find the network address of your subnet and of theirs. If the two network addresses differ, the packet must go through a router (the gateway) to get there. Many “connection timeout” bugs are simply two hosts that assumed they were local but are on different subnets. We cover the next hop in Linux routing.

Prefix Sizes You Will Actually Meet

Each step up in prefix borrows one host bit for the network, which halves the number of hosts. Here are the ones worth memorising:

CIDR	Netmask	Total addresses	Usable hosts
/16	255.255.0.0	65,536	65,534
/24	255.255.255.0	256	254
/25	255.255.255.128	128	126
/26	255.255.255.192	64	62
/27	255.255.255.224	32	30

Read the pattern: /24 = 254 usable, /25 = 126, /26 = 62, /27 = 30. Every additional bit halves the pool and you always subtract 2 for the network and broadcast addresses. A /16 is enormous — 65,534 hosts — which is why cloud providers often hand you a /16 for an entire VPC and expect you to carve smaller subnets out of it.

🧪 Try It — Without a tool, work out the block for 10.20.30.100/26. Host bits = 6, so blocks step every 64 in the last octet: 0, 64, 128, 192. .100 falls in the .64–.127 block, so the network is 10.20.30.64, broadcast is 10.20.30.127, and usable hosts are .65–.126 (62 of them). Check yourself with ipcalc below.

Confirming with ipcalc

Doing the arithmetic by hand builds intuition, but on a real box you verify. Kali may not ship ipcalc by default, so install it with the recommends suppressed to keep the image lean:

sudo apt-get install --no-install-recommends ipcalc

Then feed it the same address and prefix:

ipcalc 192.168.10.25/24

ipcalc prints the address and netmask in both dotted-decimal and binary, then the derived Network, HostMin, HostMax, Broadcast, and the Hosts/Net count. For our example it will confirm Network 192.168.10.0, HostMin 192.168.10.1, HostMax 192.168.10.254, Broadcast 192.168.10.255, and 254 hosts. The binary rows are the teaching moment: line up the address under the mask and you can literally see where the network bits stop and the host bits begin.

🏭 Why This Matters in Production — On a stripped-down container, a locked-down bastion, or someone else’s server, ipcalc often will not be installed and you may not be allowed to apt-get anything. This is exactly why the hand method matters: prefixes below /24 step the last octet in powers of two (/25→128, /26→64, /27→32), and the block your address lands in gives you the network and broadcast without any tool. Never let a missing utility stop a diagnosis.

If you cannot install ipcalc, you can still read the assigned prefix straight off the interface with iproute2 — ip -brief addr shows each address already in CIDR form — then apply the same math by hand.

Why Subnetting Runs Your Whole Platform

Here is the payoff: the exact same 32-bit arithmetic defines the boundaries in every environment you operate.

Cloud VPCs and subnets

A cloud VPC (AWS VPC, Azure VNet, GCP VPC) is just a CIDR block — often a /16 like 10.0.0.0/16. Inside it you carve subnets, typically a /24 per availability zone or per tier (public 10.0.1.0/24, private 10.0.2.0/24, database 10.0.3.0/24). Route tables and security groups then decide what may cross those boundaries. When you “run out of IPs” in a subnet, it is because you sized the prefix too small — a /27 gives you only 30 hosts, and a busy autoscaling group eats that fast.

Kubernetes pod and service networks

Kubernetes assigns every pod an IP from a pod CIDR (commonly a large block like 10.244.0.0/16) and every Service a virtual IP from a separate service CIDR (e.g. 10.96.0.0/12). Each node gets a slice of the pod CIDR — frequently a /24 per node, which is why a node can host roughly 250 pods before it exhausts its slice. Understanding host-count math tells you, in advance, how many pods a cluster can schedule. (A dedicated “Kali Linux + Kubernetes” path is coming; for now the Kubernetes and Helm category has related material.)

Docker bridge networks

When you create a user-defined Docker bridge, Docker allocates it a subnet — by default from the 172.16.0.0/12 and 192.168.0.0/16 ranges, one /16 or /24-ish block per network. Every container on that bridge gets a host address inside it. Sizing and, crucially, not overlapping those blocks is the whole subject of user-defined Docker networks.

OpenStack Neutron subnets

In OpenStack, a Neutron network holds one or more subnets, and each subnet is defined by a CIDR plus an allocation pool (the usable-host range Neutron will hand out via DHCP). It is the same network/broadcast/usable-host model you worked out by hand above, just exposed through an API.

The Overlapping-CIDR Trap

The single most expensive subnetting mistake is overlap — two networks that use the same or intersecting CIDR ranges and later need to talk to each other.

Site A VPC:   10.0.0.0/16
Site B VPC:   10.0.0.0/16   <-- identical range
        \___ VPN / peering ___/
              routing is ambiguous

Everything works fine while the two networks are isolated. The pain arrives the day you connect them:

• VPN and VPC peering conflicts — when both sides advertise 10.0.0.0/16, a router cannot decide whether 10.0.5.9 is local or remote. Cloud providers flatly refuse to peer VPCs with overlapping CIDRs, and site-to-site VPN routes become ambiguous or silently blackholed.
• Docker network clashes — if a host’s default 172.17.0.0/16 bridge overlaps a corporate subnet reachable over the VPN, containers try to reach that corporate host locally and the traffic never leaves the box. The fix is to assign Docker a non-conflicting block, which requires knowing what is already in use.

🏭 Why This Matters in Production — Overlaps do not fail loudly at creation time; they fail weeks later when someone builds a tunnel. The defence is boring and effective: keep an IP address plan. Reserve non-overlapping blocks up front — for example 10.0.0.0/16 for prod, 10.1.0.0/16 for staging, 10.2.0.0/16 for dev — so any two environments can be connected later without renumbering. Renumbering a live network is one of the most disruptive changes there is.

DevOps Perspective: Sizing a Subnet Is Capacity Planning

Choosing a prefix is a capacity decision, not a formality. Too small and you throttle growth (a /27’s 30 hosts will not survive one enthusiastic autoscaler); too large and you waste address space and make overlaps more likely across a fleet of environments. A widely used default is a /24 per environment or tier — 254 usable addresses is comfortable for most application subnets, the math is trivial (the whole last octet is the host part), and /24s tile neatly inside a /16 VPC (10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24, …). Start there, and only reach for a /25–/27 when you are deliberately partitioning a small tier, or a /16 when you need a big flat pod network.

Try It Yourself

1. Install the tool: sudo apt-get install --no-install-recommends ipcalc.
2. Predict, then verify: run ipcalc 192.168.10.25/24 and confirm Network .0, hosts .1–.254, broadcast .255.
3. Do /26 by hand for 10.20.30.100/26 (network, broadcast, usable count), then check with ipcalc 10.20.30.100/26.
4. Read your own machine’s prefix with ip -brief addr and compute your subnet’s network and broadcast addresses from the CIDR shown.
5. Inspect a Docker bridge’s subnet with docker network inspect bridge and note its CIDR — is it inside 172.16.0.0/12? Would it overlap anything on your corporate network?

Common Problems

• “It works locally but times out over the VPN.” Suspect overlapping CIDRs. Compare the network addresses on both ends; if the ranges intersect, routing is ambiguous. Renumber one side onto a non-overlapping block.
• “Docker network create failed: pool overlaps.” Docker refuses to allocate a subnet that collides with an existing network or route. Pick an explicit --subnet in a free range, or prune the conflicting network.
• “We ran out of IPs in the subnet.” The prefix was sized too small — a /27 (30 hosts) behind an autoscaling group is a classic. Plan for a /24 unless you have a reason not to.
• “Two hosts on the ‘same’ network can’t reach each other.” A /26 splits x.x.x.0/24 into four separate subnets (.0, .64, .128, .192); .50 and .100 are not neighbours under a /26. Recompute the network address for each.

What You Learned

• An IPv4 address is 32 bits split into a network part and a host part; the split is set by the netmask, written compactly as a CIDR prefix like /24.
• Every subnet has a network address (host bits all 0), a broadcast address (host bits all 1), and the usable hosts in between; usable count is 2^(host bits) − 2.
• The prefixes you will meet daily: /16 = 65,534 usable, /24 = 254, /25 = 126, /26 = 62, /27 = 30 — each extra bit halves the pool.
• ipcalc 192.168.10.25/24 confirms the network/host/broadcast breakdown; install it with apt-get install --no-install-recommends ipcalc, but be ready to do the math by hand when the tool is not present.
• The same arithmetic governs cloud VPC subnets, Kubernetes pod/service CIDRs, Docker bridge networks, and OpenStack Neutron subnets — and overlapping CIDRs are a leading cause of VPN/peering and Docker connectivity failures, so plan non-overlapping ranges up front.

Now that you can tell which addresses are local and which are remote, the natural next question is how does traffic actually get to the remote ones? Continue with Part 4 — Linux Routing to see how the routing table and default gateway move packets between the subnets you just learned to read. You may also want to revisit which services are reachable on those hosts in ports and listening services.