VLSM for a Branch Build-Out with a Borrowed WAN Range
A regional office has been assigned the block 172.20.16.0/22. The branch router connects to two access/distribution switches and to the HQ WAN edge, so three point-to-point links are needed, each a /30. Host requirements on the new floor are: Sales 220 addresses, Engineering 110, IP telephony 60, guest Wi-Fi 40, and network management 12. The junior administrator proposes splitting the /22 into four equal /24s, one per user group, and placing all three point-to-point links inside the guest /24 'because there are plenty of free addresses there'. Two weeks later the branch intermittently loses its WAN link when the guest network is busy, and a guest laptop has been seen using 172.20.19.1. Separately, Engineering users can ping their default gateway but cannot reach the HQ DNS server at 10.8.4.53, even by IP address. The branch router holds connected routes plus a static default route pointing at 172.20.19.253.
1. Produce a working VLSM allocation from 172.20.16.0/22 that satisfies every stated requirement, and explain the ordering rule you applied.
Read the worked answer
Allocate largest block first, on its own boundary, from the bottom of the range (172.20.16.0 – 172.20.19.255, 1,024 addresses):
- Sales, 220 hosts → 172.20.16.0/24 (254 usable, 34 spare)
- Engineering, 110 hosts → 172.20.17.0/25 (126 usable)
- Voice, 60 hosts → 172.20.17.128/26 (62 usable)
- Guest, 40 hosts → 172.20.17.192/26 (62 usable)
- Management, 12 hosts → 172.20.18.0/28 (14 usable)
- WAN links → 172.20.18.16/30, 172.20.18.20/30, 172.20.18.24/30
Free: 172.20.18.28 – 172.20.19.255.
Reasoning: a /24 must start on a .0 octet boundary, a /25 on .0 or .128, a /26 on 64-address steps, so descending order guarantees each block lands on its own boundary and leaves no unusable holes. Keeping the three /30s adjacent lets them be summarized in one ACL or static route. The ~480 spare addresses allow Sales to be re-cut as a /23 if it outgrows 254 hosts.
2. The administrator placed the three /30 links inside the guest /24. Explain concretely why this breaks forwarding, using the symptoms described.
Read the worked answer
It gives the router two connected routes covering the same addresses: the guest 172.20.19.0/24 and, say, the /30 172.20.19.0/30 on the WAN interface.
- Longest-prefix match means .0–.3 resolve out of the /30, but every other address in that /24 - including anything an ACL, NAT rule or static route references as 172.20.19.0/24 - is treated as local guest LAN.
- The guest DHCP pool can hand out the router's own address or the WAN peer's address; that is exactly the 172.20.19.1 laptop that was observed.
- When the router needs to ARP for its WAN next hop 172.20.19.253, the overlapping more-specific/less-specific pair can send the request out the wrong interface, so the link stalls under load.
- Guest broadcast traffic and the WAN link now share an addressing plan, so troubleshooting and summarization both become ambiguous.
Point-to-point links must come from their own block, as in the allocation above.
3. Engineering can ping its gateway but not 10.8.4.53 by IP. Walk through how you would isolate the fault and state the most likely cause.
Read the worked answer
Pinging the gateway proves the PC's IP, mask, cabling and VLAN are correct, and testing by IP removes DNS from the picture - so this is a forwarding problem between branch and HQ.
- On the branch router,
show ip route 10.8.4.53: is the default route present and is 172.20.19.253 ARP-resolvable? - Traceroute from Engineering toward 10.8.4.53, then from an HQ host back to a 172.20.17.x address.
- If the forward path works but the return fails, HQ has no route for 172.20.17.0/25 - the classic case where HQ still carries a stale static route for 172.20.16.0/24 only, so replies to the /25 fall out to the Internet.
- Check ACLs and any NAT exemption on the WAN edge for private addressing, and the host firewall as a last step.
Most likely cause: missing or stale return route on the HQ side; fix is a route for 172.20.16.0/22 (or the individual /25) pointing at the branch.