Begin with the network boundary, not an address class

An IPv4 address consists of 32 bits, usually written as four decimal octets. A subnet mask or CIDR prefix identifies how many high-order bits are the network portion. For example, 192.0.2.70/26 means the first 26 bits identify the prefix and the remaining six bits identify positions within that block. The equivalent mask is 255.255.255.192. The last octet of that mask is 11000000 in binary: the leftmost two bits contribute to the prefix, while the final six are available for address positions within the subnet.

Subnets should be calculated from the actual prefix attached to the interface. Historical class A, B and C defaults can help explain early IPv4 allocation, but modern routing uses explicit prefixes and does not assume a network boundary solely from the leading octet. A learner who sees 172.16.20.25 without a mask cannot reliably determine its local network. A /20 and a /24 on that same numeric address produce different network boundaries. The distinction is not cosmetic; two interfaces that assume different masks can disagree about which destinations are local and which require routing.

To find the network address, retain the prefix bits and set all host bits to zero. For the conventional directed-broadcast address of a subnet, retain the prefix and set the host bits to one. All the addresses between those endpoints form the block. For a typical IPv4 LAN using conventional broadcast subnetting, the network address and directed-broadcast address are not assigned to ordinary hosts. That is why a /26 block with six host bits contains 64 total addresses and normally 62 ordinary host addresses. Exceptions such as point-to-point /31 links and host-specific /32 routes deserve separate treatment, rather than forcing every prefix through the same rule.

A mask is not a property of the router alone. The client interface, neighboring clients, the gateway’s interface and any upstream route must agree about how the design is supposed to work. The gateway address must fall in the network served by the client interface under that client’s mask. Even when the number of usable addresses is sufficient, an inconsistent mask can make two adjacent systems attempt different forwarding paths.

Calculate a subnet without memorizing every possible mask

Consider dividing the documentation prefix 192.0.2.0/24 into four equal subnetworks. Borrowing two bits from the host portion lengthens the prefix to /26. Six remaining host bits yield 2^6 = 64 address positions per subnet. Those positions form contiguous blocks whose boundaries in the final octet advance by 64. The four network addresses are 192.0.2.0/26, 192.0.2.64/26, 192.0.2.128/26 and 192.0.2.192/26.

For 192.0.2.64/26, the ordinary host range runs from .65 to .126, and .127 is the conventional directed broadcast. The next network begins at .128; it is not part of the .64/26 range. A host address such as 192.0.2.110/26 belongs to the .64 network because its final-octet value is between 64 and 127. You can establish that fact from the block boundaries without converting all four octets to binary every time.

The same logic works with an awkward prefix. A /27 uses a last-octet block size of 32 in a /24 context, producing boundaries at .0, .32, .64, .96, .128, .160, .192 and .224. If the address is 192.0.2.141/27, the matching block starts at .128, ends at .159, ordinarily allows host addresses .129 through .158, and broadcasts at .159. A /28 has 16-address blocks, and a /29 has eight-address blocks. Learning the relationship between host bits and block size is more durable than memorizing every answer to a flashcard.

A good check goes in the other direction: convert the resulting prefix back into a mask and confirm that the candidate network has zeroes in all host positions. For example, 192.0.2.96/27 is aligned correctly because 96 is divisible by 32. By contrast, calling 192.0.2.100/27 a network address would be inaccurate; it is an address inside 192.0.2.96/27. This alignment check catches a surprising number of allocation errors.

Allocate different-sized networks with VLSM

Real networks do not always need equal blocks. Suppose a site needs three separate IPv4 LANs with conventional host capacities of approximately 50, 25 and 12 endpoints. Assuming each subnet also needs a gateway address from the usable pool, choose the smallest ordinary subnet that meets the total address requirement. A /26 provides 62 conventional usable addresses, a /27 provides 30, and a /28 provides 14. Those prefixes can be allocated without wasting three /26 networks.

One valid allocation within 192.0.2.0/24 is 192.0.2.0/26 for the larger LAN, 192.0.2.64/27 for the middle LAN, and 192.0.2.96/28 for the smaller LAN. Their address blocks occupy .0–.63, .64–.95 and .96–.111, respectively. They do not overlap, and the unallocated remainder can support later subnets or growth. The specific assigned gateway address can differ by design; what matters is that the gateway is a usable address in the intended prefix and that host configuration points to it.

The most reliable allocation workflow starts with the largest host requirement, reserves the corresponding aligned prefix block and proceeds to smaller requests. Write down the network address, prefix, ordinary host range, broadcast address, gateway plan and a unique VLAN or network label. Then check that no two rows overlap. This record will be valuable when you later implement DHCP scopes, SVI addresses, routing policies or monitoring rules.

Host-count shortcuts require context. If a user says a LAN has 50 devices and also needs a gateway interface, the design may require at least 51 usable addresses unless the 50 count already included the gateway. If the segment will contain management addresses or other infrastructure, account for those too. Do not treat advertised device count as perfectly equivalent to the number of addresses that must be reserved. Likewise, a spare subnet does not automatically give any existing subnet more free addresses; changing a prefix changes the host’s network boundary and can require coordinated configuration.

Recognize /31 and /32 cases instead of misusing the host formula

A /30 contains four addresses, with two ordinary usable positions under conventional subnetting, which historically made it a common size for point-to-point links. A /31 contains only two addresses and does not follow the ordinary network-plus-broadcast reservation rule when used under the point-to-point semantics standardized for IPv4. In that specific use, both addresses can be used by the two ends of the link. A /32 identifies one particular address and often appears as a host route or loopback interface assignment rather than a broadcast LAN.

These exceptions matter because they expose the limits of a rote calculation. The formula 2^(32−prefix) gives the number of address positions in the block, but the number usable for interfaces depends on the network type and applicable addressing semantics. A calculation saying that /31 always has zero usable addresses can lead to incorrect operational conclusions. Similarly, treating a /32 as a LAN with a broadcast address misses its practical purpose in routing.

Private IPv4 ranges are another category that needs precise language. The RFC 1918 space is 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. An address is not private simply because it begins with 172; the correct second-octet boundary matters. Private space describes allocation and routing reachability conventions, not permission to reuse the same overlapping prefixes freely inside one connected environment. Overlap between sites, virtual networks or VPN domains can make forwarding and translation unexpectedly difficult.

Decide whether a destination is local before reading the routing table

Once you can find the network boundary, you can predict a host’s first-hop decision. Imagine a client at 10.44.18.70/26 with a gateway at 10.44.18.65. Its local prefix is 10.44.18.64/26, encompassing .64 through .127. Another client at 10.44.18.120/26 is on that same IPv4 subnet, so ordinary unicast communication can proceed through local Layer 2 delivery, subject to VLAN membership and host policy. A destination such as 10.44.18.130 is outside the client’s subnet; the client normally sends that packet toward its configured gateway rather than treating the destination as directly connected.

Now imagine that the second client was incorrectly configured with /24 rather than /26. It might attempt local neighbor discovery for addresses the first client would forward to a router. Whether traffic fails in practice depends on the surrounding topology and proxy behavior, but the masks clearly express conflicting network assumptions. This is a better diagnostic observation than saying merely that the two hosts have similar-looking addresses.

Routers also use prefixes to decide which route matches a destination. If the routing table contains 10.44.0.0/16 and a more specific 10.44.18.64/26, a packet bound for 10.44.18.100 uses the more specific route when both are installed and eligible. The router applies longest-prefix matching rules before comparing path-choice details for the same destination prefix. Administrative distance helps prefer competing route sources, and a routing protocol’s metric helps select routes within its decision process. These are distinct concepts; neither the presence of a low metric on a broad summary nor a low administrative distance makes an unrelated broad prefix more specific.

Summarization is powerful only when the underlying allocation is coherent. Advertising a broad summary without ensuring that its component destinations are reachable can create a black hole or misleading failover behavior. List the covered subnets, test the forwarding path to each one, and trace how replies return; a successful ping to one address does not establish reachability for the others. A Cisco CCNA 200-301 routing lab makes that distinction observable by comparing the advertised summary with the installed routes, next hops and actual packet paths.

Troubleshoot subnetting as a packet-path problem

A useful troubleshooting sequence begins with what is actually configured on the client. Record the address, prefix or mask, default gateway, DNS settings and interface state. Compare those values against the approved allocation. Then determine whether the intended gateway is in the correct subnet and whether the physical and VLAN boundaries match the design. Tools such as ipconfig on Windows, ip address and ip route on Linux, or an equivalent interface and route display on macOS can reveal different aspects of that state; the precise syntax depends on the host version.

If the client cannot reach an application, test nearby dependencies before diagnosing the application itself. Does the host have a valid address? Can it reach the gateway? Is the target address in the same subnet according to the host’s own mask? Does the gateway have an appropriate route and can return traffic traverse the path? Are VLAN, ACL and firewall settings consistent with that route? If numerical IP connectivity succeeds while hostname access fails, examine DNS separately; changing a subnet mask cannot correct a broken resolver record.

Write one exercise where the only change is a wrong prefix length. Use two VLANs, each with its own gateway. Confirm the initial correct state, then configure one client with a mask that is too broad. Predict which destinations it will treat as local, identify the neighbor-resolution or path symptoms, and restore the intended prefix. Record enough command output or simulator evidence to support your explanation. The goal is not to produce an impressive diagram; it is to establish that a single change caused a particular difference in forwarding behavior.

A second exercise should use a subnet allocation collision: two interfaces or DHCP scopes covering overlapping address space. The resulting symptoms depend on where the overlap exists, but the plan itself is invalid for a straightforward routed design. Detect the overlap mathematically before trying random configuration changes. In larger environments, a documented address-management process catches these errors earlier than a production troubleshooting session.

Connect subnetting to the current and upcoming CCNA exams

Cisco’s CCNA v1.1 objectives include configuring and verifying IPv4 addressing and subnetting, but the operational test goes beyond writing a prefix length. For a small point-to-point link, verify that both addresses belong to the intended network and neither conflicts with another interface. On a switched user VLAN, confirm the host’s mask and default gateway before debugging upstream routing. If the prefix or next hop is wrong, a reachable Layer 2 neighbor may still fail to access a remote service. Trace the forwarding choice from host to gateway and back before changing a route.

The published CCNA v2.0 blueprint, scheduled to take effect on February 3, 2027, emphasizes troubleshooting IPv4 address configuration, assignment and subnetting. That shift does not make the calculation less important. It makes the calculation the starting point of a diagnostic argument: which prefix should this device have, what did it receive, how does that change its forwarding decision and what evidence proves the correction? Candidates testing before the transition should use the v1.1 scope; later candidates should use the v2.0 outline and practice the additional diagnostic expectations.

Subnetting becomes easier when every prefix is attached to a network behavior you can explain. Compute an allocation, place the addresses on interfaces, verify that same-subnet traffic stays local, verify that other traffic reaches its gateway and troubleshoot one deliberately broken case. That sequence builds both the arithmetic and the practical understanding needed when a real network does not match its diagram.