Articles
Subnetting Interview Questions: CIDR Calculations, VLSM, and Address-Plan Mistakes
Practice subnetting interview questions with worked CIDR calculations, a VLSM address plan, growth and overlap failures, and the limited IPv4 /31 exception.
Subnetting interview questions test more than the formula for usable hosts. You can calculate a correct /26 and still produce a broken address plan by placing it on the wrong boundary, overlapping a neighbor, or forgetting that a growth requirement changes the block size. A defensible answer checks capacity, alignment, containment and non-overlap together.
Work through the original allocation below, then change one requirement and explain why the plan no longer fits. For direct coding practice, use IPv4 CIDR Range Membership Queries to turn prefix reasoning into a lookup contract.
Official RFCs establish the addressing rules; provider documentation supplies platform-specific reservations. The address plans, counterexamples and exercises here are original preparation material.
Subnetting interview questions: what does the slash mean?
In IPv4, /p fixes the first p bits of a 32-bit address. The remaining 32-p bits span 2^(32-p) addresses. RFC 4632 defines classless prefix notation and aligned power-of-two address blocks. Use the supplied prefix, rather than guessing a mask from an address's historical class.
For an ordinary broadcast-capable IPv4 subnet, the familiar interview calculation reserves the all-zero host value for the network and the all-one value for broadcast. That gives 2^(32-p)-2 conventional host addresses. State that context before using the formula: /31 point-to-point links and cloud reservation rules require separate treatment.
An original example is host 10.64.8.173/26. Six host bits give 64 addresses per block. The last-octet boundaries are 0,64,128 and 192, so this host belongs to 10.64.8.128/26. Its conventional broadcast is .191, and its host range is .129–.190.
Explain both approaches: clear the host bits to find the network, or locate the aligned 64-address interval. The dotted mask is 255.255.255.192; its last octet has two leading one bits and six zero bits. A calculator result is more convincing when you can reconstruct it.
Can an address ending in .0 be a host?
Yes, depending on the prefix and network. The last decimal octet alone cannot identify a network or broadcast address. Test all host bits under the actual mask.
In an original 10.64.8.0/23 example, 10.64.9.0 lies inside the conventional host range: the network is 10.64.8.0, the broadcast is 10.64.9.255, and there are nine host bits. The address crosses an octet boundary without becoming the network address.
Similarly, an address ending in .255 can be an ordinary host under a sufficiently broad prefix. Do not create a validator that rejects every .0 or .255 string. Validate membership and host eligibility against the entire network definition.
Distinguish a host/interface value from a canonical network value. 10.64.8.173/26 is a meaningful interface address; the canonical network is .128/26. A request to allocate a subnet should not silently treat those two concepts as interchangeable.
How do you choose the smallest block for a demand?
First define what is counted. Does “45 hosts” mean 45 endpoints plus a gateway, or 45 total assigned addresses? Does it include management interfaces, virtual router addresses, spare appliances and near-term growth? Resolve those questions before rounding up.
For this original exercise, each LAN requirement counts all assigned addresses, including its gateway. Assume conventional IPv4 LAN reservations and no provider-specific exclusions. Find the smallest power of two whose conventional host capacity meets the requirement.
Ninety assigned addresses need a /25:128 total,126 conventional hosts. Forty-five need a /26:64 total,62 hosts. Twenty need a /27:32 total,30 hosts. A block that has enough total addresses may still have too few assignable addresses.
Keep growth explicit rather than adding an unexplained percentage. If today's45 becomes tomorrow's70, state 70 as the planning demand and choose a block accordingly. “We have spare addresses elsewhere” does not make a62-host LAN support 70 assigned addresses without a design change.
Build the original VLSM plan
You own 10.64.8.0/24, which contains 256 addresses. Allocate three LANs requiring 90,45 and 20 assigned addresses, plus two genuine point-to-point links whose endpoints support /31. The link exception is justified in the next section; this is not an AWS VPC allocation.
Variable-length subnet masking uses different prefixes for different requirements. A practical allocation method is to place the largest blocks first, then align each smaller block inside the remaining space. Largest-first simplifies this exercise; it is not proof that every operational plan must use that layout.
| Segment | Requirement | Allocation | Full address interval |
|---|---|---|---|
| LAN A | 90 assigned addresses | 10.64.8.0/25 | .0–.127 |
| LAN B | 45 assigned addresses | 10.64.8.128/26 | .128–.191 |
| LAN C | 20 assigned addresses | 10.64.8.192/27 | .192–.223 |
| Link 1 | Two supported point-to-point endpoints | 10.64.8.224/31 | .224–.225 |
| Link 2 | Two supported point-to-point endpoints | 10.64.8.226/31 | .226–.227 |
The allocated blocks consume 128+64+32+2+2=228 addresses. The remaining interval is .228–.255, containing 28 addresses. Do not call that entire free interval a /27: it starts at 228, which is not a32-address boundary, and it contains fewer than 32 addresses.
The free space can be expressed as .228/30, .232/29 and .240/28. These cover 4,8 and 16 addresses respectively, totaling 28. This is a useful connection to the minimal-range-cover coding question: exact coverage matters as much as the total.
Change LAN B from 45 to 70: why does the plan fail?
LAN B's /26 has 62 conventional host addresses, so 70 requires a /25. Its existing start .128 is aligned for a /25, but that expanded block spans .128–.255. It overlaps LAN C, both links and the free tail.
Reordering alone cannot solve this version of the exercise. The smallest blocks for the changed requirements consume 128+128+32+2+2=292 addresses, which exceeds the /24's256. This is an impossibility argument under the stated independent-LAN requirements, not merely a complaint about fragmentation.
A larger containing allocation, such as an available aligned /23, could provide room. Alternatively, change the requirements: split the group across distinct routed LANs, reduce its assigned demand, or obtain a separate non-overlapping allocation. Each option changes routing, operations or migration; none is a silent mask edit.
Describe a migration before renumbering: inventory static assignments and DHCP pools, reserve destination space, update routing and access rules, move a controlled group, and verify return traffic. This is original operational reasoning, not a universal production runbook. The important interview point is that extending a prefix changes who appears local and which addresses it claims.
Where does the /31 exception apply?
RFC 3021 permits both values of the one-bit host field to identify endpoints on an IPv4 point-to-point link. Under that contract, .224/31 provides endpoints .224 and .225; subtracting two would incorrectly claim zero usable endpoints.
Do not extend that exception to an ordinary shared LAN. Ask whether the link is truly point to point, whether both ends support the behavior, and whether the platform allows that prefix. A /32 identifies one address; it is useful in host-route or loopback discussions but is not a two-endpoint replacement.
Provider rules can differ substantially. AWS VPC subnet sizing documents ordinary IPv4 subnet sizes from /28 through /16 and reserves the first four addresses plus the last. A normal AWS /26 therefore offers 59 assignable addresses, not 62. The same documentation describes a BYOIP exception; avoid making the reservation formula universal across every arrangement.
State the environment once, then keep calculations consistent. Mixing a conventional LAN's host formula with cloud reservations midway through an answer produces a plausible-looking but unusable plan.
How do you prove alignment and non-overlap?
The Python ipaddress documentation distinguishes strict network parsing from normalization and provides containment, overlap and range-summary operations. The following original check is runnable with the standard library:
from ipaddress import ip_network
from itertools import combinations
parent = ip_network("10.64.8.0/24")
blocks = [ip_network(s) for s in (
"10.64.8.0/25", "10.64.8.128/26",
"10.64.8.192/27", "10.64.8.224/31",
"10.64.8.226/31",
)]
assert all(b.subnet_of(parent) for b in blocks)
assert all(not a.overlaps(b) for a, b in combinations(blocks, 2))
assert sum(b.num_addresses for b in blocks) == 228
Strict parsing rejects a network such as 10.64.8.70/26 because it has host bits set. Normalizing it yields .64/26, which occupies .64–.127 and overlaps LAN A. Normalization can produce a valid network object while preserving an invalid allocation intent.
These checks were executed locally using CPython 3.12; they validate the arithmetic and original examples, not device configuration or cloud deployment. A plan also needs capacity assertions under its chosen reservation policy. Disjoint, aligned blocks can still be too small.
Test boundaries: the first and last address of each full block, the addresses immediately outside it, a contained child block, an overlapping supernet and an octet-crossing range. Avoid expanding a /0 into a list of billions of addresses just to check containment.
Why can correct arithmetic still produce failed connectivity?
RFC 1122's outbound-routing rules describe the local-versus-remote decision and gateway selection. In an original failure, a host configured with /24 treats a destination as directly connected even though the intended network uses /26. It may attempt local neighbor resolution where the design expected a gateway path.
Capture the host's actual address, mask and routes, then compare the intended destination against them. A correct spreadsheet does not prove that a DHCP lease, static interface or route table has the same prefix. Also inspect the return path; reachability is not established by checking only the source.
Keep prefix membership separate from policy. A router lookup commonly selects the longest matching prefix, whereas an ordered firewall exercise may select the first matching rule. The more specific CIDR is not automatically the winning rule in every system.
For example, an original ordered policy that first allows a /24 and later denies one /32 may still allow that address if the contract is first match. Reordering the policy changes the result without changing subnet arithmetic. Ask for the matching rule before optimizing a trie or collapsing ranges.
Sources and Further Reading
- RFC 4632: CIDR notation and aggregation
- RFC 3021: IPv4 /31 point-to-point links
- RFC 1122: Host outbound-routing requirements
- Amazon VPC: Subnet CIDR blocks
- Python: ipaddress library
Sources checked October 4, 2026. Calculations assume the stated IPv4 environment; verify device support and provider reservations before applying them.