An IPv4 VLSM plan gives 10.40.4.0/23 to one LAN and 10.40.5.128/26 to another; what breaks, and how would you catch such overlaps before deployment?
answer
- where does the /23 end?
- nested, never partly overlapping
- longest match versus on-link guess
- sort, then track the furthest end
basics
~20 sThe /26 is nested in the /23: routers send 10.40.5.128 to .191 to the /26 by longest match, while /23 hosts treat those addresses as on-link. Sort the plan by start and flag any start at or below an earlier end.
solid answer
~50 s`10.40.4.0/23` spans `10.40.4.0` to `10.40.5.255`, so `10.40.5.128/26` (`.128` to `.191`) is nested inside it - someone read the `/23` as ending at `10.40.4.255`. Routers choose the longest matching prefix, so every packet for `10.40.5.128` to `.191` goes toward the `/26`; a host numbered in that range on the `/23` LAN can send but never gets replies from other subnets. In the other direction, hosts on the `/23` mask a destination such as `10.40.5.140` with their own mask, conclude it is on-link, and ARP for it on the wrong link. Many router implementations refuse an interface subnet that overlaps another interface's, but when the prefixes sit on different routers nothing complains. Two CIDR prefixes are either disjoint or nested, so the check is mechanical: verify each network is aligned, sort by start, and flag any block starting at or before the furthest end seen so far.
code
pseudocode · 19 lines# entries: list of (net, len); addresses as 32-bit integers
function size(len): return 2 ^ (32 - len)
function lastAddr(e): return e.net + size(e.len) - 1
function checkPlan(parent, entries):
for e in entries:
if e.net mod size(e.len) != 0:
report("not aligned", e)
if e.net < parent.net or lastAddr(e) > lastAddr(parent):
report("outside parent", e)
sort entries by net ascending
furthest = -1
owner = none
for e in entries:
if e.net <= furthest:
report("overlap", owner, e)
if lastAddr(e) > furthest:
furthest = lastAddr(e)
owner = ego deeper
Recall where a block ends: a /23 from 10.40.4.0 runs to 10.40.5.255, so anything inside that range already belongs to it.
Explain why CIDR blocks nest rather than partly overlap, and how to test whether a longer prefix lies inside a shorter one by masking.
Diagnose the half-working symptoms from both sides, longest match at the router and the on-link decision at the host, and put an aligned, sorted, furthest-end check into plan review.
Treat overlap as a process risk: plans drift as people add segments by hand, so a single source of truth with an automated check beats careful reviewers.
## What the two prefixes actually cover | Prefix | First address | Last address | Size | |---|---|---|---| | `10.40.4.0/23` | 10.40.4.0 | 10.40.5.255 | 512 | | `10.40.5.128/26` | 10.40.5.128 | 10.40.5.191 | 64 | The `/26` lies entirely inside the `/23`. The usual cause is reading a `/23` as if it ended where a `/24` would, at `10.40.4.255`, and then treating `10.40.5.0` onward as free. ## CIDR blocks nest; they never partly overlap - Every prefix is an aligned block whose size is a power of two. - The larger block's boundaries fall on multiples of its size, which are also multiples of the smaller block's size, so a smaller block can never straddle a boundary of a larger one. - Two prefixes are therefore either **disjoint** or **nested** - one contains the other. Partial overlap cannot happen. - That makes the pairwise test simple: a longer prefix lies inside a shorter one exactly when its network address, masked with the shorter prefix's mask, equals the shorter prefix's network address. Here `10.40.5.128` masked to `/23` is `10.40.4.0`, so the `/26` is nested. ## What breaks on the wire 1. **Routers choose the longest match.** A router that holds both prefixes, connected or learned, forwards every packet for `10.40.5.128` to `10.40.5.191` toward the `/26`; RFC 1812 section 5.2.4.3 makes the longest matching prefix win. A host on the `/23` LAN numbered in that range can send outward, but replies from other subnets are delivered to the `/26` LAN, where it does not exist. 2. **Hosts decide on-link with their own mask.** RFC 1122 section 3.3.1.1 has a host compare the destination with its own address under its own mask. A host at `10.40.4.20/23` sending to `10.40.5.140` finds both inside `10.40.4.0/23`, so it ARPs for `10.40.5.140` on its own link instead of using the router. If that address belongs to a host on the `/26` LAN, nobody answers. 3. **The `/26` hosts fail in mirror image.** They treat their own `10.40.5.128` to `.191` as on-link, so any `/23` host numbered in that range is unreachable to them. 4. **Traffic within each LAN still works.** Hosts reach their own neighbours and most remote subnets and fail only for particular address pairs, which is what makes the fault slow to diagnose. | Sender | Destination | What happens | |---|---|---| | Host on another subnet | `/23` host at `10.40.5.150` | router picks the `/26`; the packet goes to the wrong LAN | | `/23` host at `10.40.4.20` | `/26` host at `10.40.5.140` | sender ARPs on its own link; no answer | | `/26` host at `10.40.5.140` | `/23` host at `10.40.5.150` | sender ARPs on its own link; no answer | | `/23` host at `10.40.4.20` | `/23` host at `10.40.4.30` | delivered normally | The pattern - some pairs fail, everything else works, and the failing addresses all fall in one aligned range - is the signature of a nested prefix. Reading the two prefixes as ranges, first and last address side by side, usually ends the investigation. ## Why nothing warns you - Many router implementations refuse to configure an interface address whose subnet overlaps another interface's on the same router - an implementation safeguard, not a protocol rule. - When the two prefixes sit on different routers, each configuration is valid on its own. Routing carries both prefixes everywhere, and longest match quietly prefers the `/26`. - Neither IPv4 nor a routing protocol has any notion of a plan; the check belongs in the planning step. ## Checking a plan mechanically 1. **Alignment.** Each network address must be a multiple of its block size. An entry like `10.40.5.0/23` is not a network address; masked, it becomes `10.40.4.0/23` and collides with whatever was meant to start there. 2. **Containment.** Every subnet must lie inside the parent block the plan is carving. 3. **Overlap.** Sort entries by network address and walk the list, tracking the **furthest end address seen so far** and the block it belongs to. Any entry that starts at or before that end is nested inside that block. 4. **Why not compare neighbours only:** sorted as `10.40.4.0/23`, `10.40.5.128/26`, `10.40.5.200/29`, the `/29` starts after the `/26` ends, so a neighbour-only comparison passes it - yet it lies inside the `/23`. Tracking the furthest end catches it. The same test applies to every prefix the plan must coexist with - another site's ranges, routes learned over a tunnel, address pools that other software picks by default - though those collisions are resolved where those systems are configured, not in the subnet plan itself.
- Why can a host numbered 10.40.5.150 on the /23 LAN reach its own LAN but not other subnets?Traffic within its LAN is delivered directly after ARP on the shared link, with no router involved. Traffic from other subnets reaches a router holding both prefixes, and longest match picks the `/26`, so packets for `10.40.5.150` leave on the `/26` LAN, where no such host exists. Replies to its own outbound packets meet the same fate.
- Why is comparing each prefix only with its predecessor in sorted order not enough to find overlaps?Because a large block can contain several later blocks that do not overlap each other. Sorted as `10.40.4.0/23`, `10.40.5.128/26`, `10.40.5.200/29`, the `/29` starts after the `/26` ends, so a neighbour comparison passes it, yet it lies inside the `/23`. Tracking the furthest end seen so far catches every nested block.
saying these in an interview costs you the question
- Two CIDR prefixes can partially overlap, sharing only some addresses.
- Overlapping subnets are always rejected when the router is configured.
- A router sends traffic for an overlap to whichever subnet was configured first.
- Comparing each prefix with the next one in sorted order finds every overlap.
- A /23 starting at 10.40.4.0 ends at 10.40.4.255.