VLSM Plan for a Three-Building Branch
A branch office has been allocated 172.18.8.0/22 for a three-building campus. Current requirements are Building A: 400 hosts; Building B: 180 hosts; Building C: 90 hosts; a routed transit link between A and B: 2 addresses; and a management VLAN: 25 addresses. Each building needs 30% growth headroom. The junior administrator proposes: A 172.18.8.0/23, B 172.18.10.0/24, C 172.18.11.0/24, transit 172.18.11.0/30, and management 172.18.11.4/27. The WAN provider will accept only a single summarized /22 advertisement from the branch edge and will reject any overlapping prefixes. The branch firewall currently uses 172.18.11.254 as its inside interface. The junior plan was approved informally and is already partially configured on two access switches. The edge router summarizes 172.18.8.0/22. No NAT is used inside the branch.
1. Audit the junior plan. Which requirements does it fail, and what evidence in the addressing shows the failures?
Read the worked answer
The plan fails on capacity and overlaps. Building A's /23 has 512 addresses and 510 usable, but 400 hosts plus 30% growth requires 520 usable addresses, so it is at least 10 short and provides only about 27.5% growth. Building B's /24 has 254 usable and needs 234, so it passes. Building C's /24 passes on capacity, needing 117 of 254.
The fatal problem is that the transit /30 at 172.18.11.0/30 and the management /27 at 172.18.11.4/27 both sit inside the proposed C /24 172.18.11.0/24. The firewall's 172.18.11.254 is also inside that C subnet. That creates overlapping connected routes and makes the summary ambiguous inside the branch. The edge /22 summary itself is numerically valid, but it hides the overlaps; a packet for 172.18.11.1 could match C, transit, or management depending on the router table. The plan should not be deployed as written.
2. Propose a valid VLSM allocation within 172.18.8.0/22 that meets current plus 30% growth, keeps transit and management separate, and supports the /22 summary.
Read the worked answer
One valid allocation is: A primary 172.18.8.0/23 (510 usable) plus A secondary 172.18.11.128/26 (62 usable), giving 572 usable and meeting 520. B 172.18.10.0/24 (254 usable, needs 234). C 172.18.11.0/25 (126 usable, needs 117). Transit 172.18.11.192/30 (2 usable). Management 172.18.11.224/27 (30 usable, needs 25). All prefixes are inside 172.18.8.0/22 and do not overlap.
The tradeoff is that Building A must use two VLANs or a secondary address block; a single /23 cannot meet the stated 30% growth. The firewall's old 172.18.11.254 falls inside the management /27, so either re-address the firewall to 172.18.11.126 inside C or deliberately make it a management-zone interface and route user VLANs through the core. Document that cutover because it changes the default gateway path.
3. Does the edge 172.18.8.0/22 summary remain valid, and what caveats would you give about the transit /30 and /31 choices?
Read the worked answer
The /22 summary remains valid because every proposed prefix is inside 172.18.8.0 through 172.18.11.255. The edge can advertise 172.18.8.0/22 without leaking more-specific routes, provided the internal overlaps are removed. For the transit link, a /30 gives two usable addresses and is the safer choice if the WAN provider is conservative. A /31 also gives two usable addresses under RFC 3021 and wastes no broadcast, but it is not universally supported on older provider equipment or some firewall interfaces. Use /30 unless both ends explicitly support /31.
Also confirm that the management /27 and the C /25 do not rely on proxy ARP or secondary addressing; those would undermine the clean summary. Finally, verify that the firewall inside address after the change is reachable from all internal subnets and that the branch default route points to the WAN edge, not into the summary.