IPv4 subnets and CIDR in everyday operations

An IPv4 address describes one location in a 32-bit address space. A prefix describes a set of addresses within that space. Confusing those two ideas can produce an overly broad firewall rule, an incorrect gateway assumption, or a network plan that overlaps an existing VPN. Understanding a few binary relationships makes the familiar slash notation considerably easier to use safely.

Read the prefix as a boundary

In 192.0.2.64/26, the first 26 bits identify the prefix and six bits remain for addresses inside it. The block therefore contains 2^(32-26), or 64 addresses. Its dotted mask is 255.255.255.192. This notation avoids the old assumption that the first octet determines a fixed address class. RFC 4632 describes classless addressing and route aggregation.

For this example, the block runs from 192.0.2.64 through 192.0.2.127. The next equally sized block begins at .128, not .65. The addresses used here belong to a documentation range rather than a real deployment. RFC 5737 reserves three such IPv4 blocks for examples, helping technical material avoid accidentally naming somebody else's production system.

Calculate the range before using it

A /24 contains 256 total addresses, a /28 contains 16, and a /32 identifies one address. These are counts of addresses in the mathematical block. They are not universal promises about assignable hosts. On a conventional IPv4 broadcast subnet, the all-zero host portion identifies the network and the all-one host portion is the broadcast address.

Use a parser instead of mental arithmetic when a rule will affect access:

import ipaddress

network = ipaddress.ip_network("192.0.2.64/26")
print(network.network_address)
print(network.broadcast_address)
print(network.num_addresses)
print(ipaddress.ip_address("192.0.2.90") in network)

Python's ipaddress documentation describes address membership, prefix parsing, and strict network validation. The default strict mode rejects a network string whose host bits are set. That rejection can catch a typo before it becomes a broader rule. If normalizing a supplied address with strict=False, display the normalized prefix and review it before applying the result.

Keep the small-prefix exceptions visible

For an ordinary /26 broadcast subnet, removing the network and broadcast addresses leaves 62 conventional host addresses. Applying that same subtraction mechanically to every prefix produces mistakes. A /31 can use both addresses on an appropriate point-to-point link; RFC 3021 defines that usage. A /32 can represent a host route or a single firewall match.

A provider may also reserve addresses for its gateway or management system. Its routed allocation can behave differently from a traditional directly attached LAN. Read the provider's interface instructions before assigning additional addresses. The existence of a mathematically valid host address does not establish that the provider routes it to your machine.

Distinguish private space from public reachability

The private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as specified in RFC 1918. Private addresses can be routed within an organization or VPN, but they are not globally unique public endpoints. NAT may translate them when traffic leaves that network.

The second range is frequently misread: it includes 172.16 through 172.31, not every address beginning with 172. Conversely, an address outside the private ranges is not automatically a usable public destination. Documentation, loopback, link-local, multicast, and other special-use allocations exist. Classification and actual reachability are separate checks.

When joining networks, list their prefixes first. Two sites using the same private block can create ambiguous destinations. A remote address might match the local LAN instead of the intended tunnel. Renumbering or carefully designed translation may be needed; choosing a larger prefix does not resolve an overlap.

Read routing decisions instead of assuming them

Inspect the kernel's selected route with a read-only lookup:

ip -4 address show
ip -4 route show
ip -4 route get 192.0.2.90

Do not infer the gateway from the first usable-looking address. A more specific route can select a tunnel or another interface even when a default route exists. Policy routing can add further conditions. Record the source address and interface returned by the lookup when investigating unexpected traffic paths.

Apply the narrowest justified rule

For temporary access from one verified public source, a /32 match expresses that intent precisely. Allowing its entire /24 admits 256 addresses and requires a separate justification. Recheck the source when NAT or roaming changes it, and maintain a recovery path before changing administrative access rules.

Good CIDR practice is less about memorizing a table than about making the target set explicit. Calculate the block, check special cases, inspect the actual route, and compare the resulting scope with the operational intent. Those steps prevent small notation errors from becoming unexpectedly large changes.