← Back to all articles

CIDR and Subnets: Reading 192.168.1.0/24

IPNetworkBeginner

What the slash number means

In 192.168.1.0/24, 24 means the first 24 bits are the network and the last 8 are the host, so 256 addresses (254 usable). A smaller number means a larger network.

Private ranges

BlockRange
10.0.0.0/810.0.0.0 – 10.255.255.255
172.16.0.0/12172.16.0.0 – 172.31.255.255
192.168.0.0/16192.168.0.0 – 192.168.255.255

Same network or not

Bitwise-AND the IP with the mask; equal results mean same subnet, otherwise it goes through a gateway. Common bug: two hosts with wrong masks look reachable but aren't.

Real-world cases: three times "reachable" was false

  1. Mismatched masks: A is 10.0.1.5/24, B is 10.0.1.200/25. B only treats 10.0.1.0/25 as local, so it sends traffic to A via the gateway; with no return route, nothing flows either way.
  2. Container range overlapping the office LAN: Docker defaults to 172.17.0.0/16. If the office also uses 172.17.x.x, container access to office services is treated as "directly local" and fails. Change default-address-pools to another range.
  3. Treating /32 as a subnet: a cloud security group entry 203.0.113.7/32 allows a single address; to allow a block, write /24. Getting this wrong looks like "the allowlist entry does nothing".

FAQ

Why two unusable addresses? The first is the network address and the last is broadcast, both unavailable to hosts (/31 and /32 are exceptions, used for point-to-point links and single hosts). Is /24 always 256 addresses? Yes — 8 host bits, 2⁸; likewise /16 is 65,536. Does IPv6 use CIDR? Yes, just 128 bits wide, with /64 the common subnet. How do I compute a subnet fast? AND the IP with the mask bit by bit, or use tables/scripts in practice rather than hand-converting bases.

Subnetting in practice: derive the mask from requirements

Do not start by picking a mask — start by counting hosts. Say a facility needs 500 hosts with 100% headroom:

  1. Work out host bits: about 1000 addresses, and 2^10 = 1024 fits, so leave 10 host bits — a /22 mask.
  2. Align the boundary: a /22 block starts on a multiple of 4, e.g. 10.10.0.0/22 covers 10.10.0.0–10.10.3.255. Writing 10.10.2.0/22 gets aligned to 10.10.0.0, which surprises people.
  3. Reserve transit links: carve a separate /30 or /31 for routing between blocks so they never collide with business ranges.
  4. Keep a mask gradient: access /24, aggregation /22, core /16 — consistent sizes make route aggregation easy and keep routing tables small.

How IPv6 differs

IPv6 convention is a /64 per segment even when few hosts exist, because SLAAC requires /64 and the extra host bits leave room to grow; /127 is only for point-to-point links. A common split is 48 bits for the site, 16 for the subnet number and 64 for the interface ID.

Common misconceptions

  • Judging "same subnet" by ping: ICMP may be permitted while TCP is not — always compute with the mask;
  • Calling /24 a "class C": classful addressing is history; use CIDR prefixes;
  • Forgetting reserved ranges: 127.0.0.0/8 loopback, 169.254.0.0/16 link-local and 224.0.0.0/4 multicast belong nowhere in a business plan;
  • Treating /31 as normal: two addresses, no network or broadcast address — designed for point-to-point links.

Broadcast domains and VLSM in brief

  • Broadcast domain equals subnet boundary: broadcasts reach every host inside it, so very large subnets (a /16, say) carry heavy noise — keep production subnets between /24 and /22;
  • VLSM means variable-length masks: slice one large block into differently sized subnets, giving transit links only /30 or /31 to avoid waste;
  • Quick table: /24=256, /25=128, /26=64, /27=32, /28=16, /29=8, /30=4, /31=2;
  • Aggregate deliberately: plan adjacent blocks so they summarise into one route instead of accumulating specifics.

Working with cloud networks

The classic cloud VPC mistake is overlapping ranges: if the VPC, office network, container network and peer VPC share even one block, peering or a dedicated link cannot be established. Keep a global range table from the planning stage and reserve contiguous blocks per environment so they can be joined later.

Planning for dual stack

When running IPv4 and IPv6 together, plan the two address spaces independently rather than assuming "v4 is the last 32 bits of v6". Also decide which protocol a service listens on: listening only on IPv6 can make some clients unreachable depending on the stack, so listen on both and state the preference explicitly.