Approving a VLSM Plan Inside a /22
You are asked to approve a junior engineer's addressing plan for a new site that was assigned 172.20.16.0/22. Requirements: VLAN 10 needs 400 hosts, VLAN 20 needs 120, VLAN 30 needs 60, VLAN 40 needs 25, plus three point-to-point links to WAN routers, each a /30. The proposal is: VLAN 10 = 172.20.16.0/24 plus 172.20.17.0/24; VLAN 20 = 172.20.18.0/25; VLAN 30 = 172.20.18.128/26; VLAN 40 = 172.20.19.0/27; WAN links = 172.20.19.32/30, 172.20.19.36/30, 172.20.19.40/30. The junior notes that no addresses overlap and that every host fits. The site's core switch will run an SVI for all four VLANs and advertise the site into OSPF.
1. Where does the plan break, and what allocation would you approve instead? Show the arithmetic.
Read the worked answer
The break: VLAN 10 is given two separate subnets.
172.20.16.0/22 spans 172.20.16.0 through 172.20.19.255 (1024 addresses). One VLAN is one broadcast domain is one IPv4 subnet. Splitting 400 hosts across 172.20.16.0/24 and 172.20.17.0/24 puts two different subnets on the same segment: hosts in the same VLAN cannot reach each other without hairpinning through the SVI, DHCP relay needs two scopes and two helper addresses, and every ACL and summary now has to treat one user group as two networks. It "fits" only in the sense that no addresses overlap, which is not the design test.
Approved allocation:
| Purpose | Subnet | Usable | Need |
|---|---|---|---|
| VLAN 10 | 172.20.16.0/23 (16.0-17.255) | 510 | 400 |
| VLAN 20 | 172.20.18.0/25 | 126 | 120 |
| VLAN 30 | 172.20.18.128/26 | 62 | 60 |
| VLAN 40 | 172.20.19.0/27 | 30 | 25 |
| WAN 1-3 | 172.20.19.32/30, .36/30, .40/30 | 2 each | 2 each |
Remaining free space: 172.20.19.44 - 172.20.19.255 (212 addresses). Two notes for the approval: VLAN 30 has only two spare addresses, so it has no growth room, and the leftover 212 addresses are not a single aligned /24.
2. Six months later the site needs a VLAN for 250 hosts. Can you serve it from the /22? What do you request, and what would you have done differently on day one?
Read the worked answer
No, the /22 cannot serve it.
250 hosts needs 254 usable addresses, which is exactly a /24. The free space is 172.20.19.44 through 172.20.19.255: only 212 addresses, and a /24 must start on a .0 boundary, so it is not aligned inside the block either. You cannot carve a /24 out of what is left.
Request 172.20.20.0/24 from the addressing authority. It is contiguous with the existing block, so the two together are still summarizable as 172.20.16.0/21, or ask for the whole /21 now that growth is proven.
Better day-one design with the same /22:
- VLAN 10: 172.20.16.0/23 (deliberately 110 spare addresses)
- VLAN 20: 172.20.18.0/25
- VLAN 30: 172.20.18.128/26
- VLAN 40: 172.20.18.192/27
- WAN: 172.20.18.224/30, .228/30, .232/30
- Reserve all of 172.20.19.0/24 for future VLANs
That keeps one clean /24 in reserve and still wastes nothing. General rule: size to the requirement plus growth, and never fill the last aligned block in a summary with point-to-point links.
3. What single summary route should the site advertise, and when does that summary become dangerous?
Read the worked answer
Advertise 172.20.16.0/22 while the site is confined to that block; move to 172.20.16.0/21 once the extra 172.20.20.0/24 is added. All four VLANs and the three WAN /30s sit inside the /22, so one statement replaces seven. If the site is in a non-backbone OSPF area, do it with area <x> range 172.20.16.0 255.255.252.0 on the ABR rather than by redistributing specifics.
When it becomes dangerous:
- Overlap. A summary is only safe if every address inside the range is actually reachable through this site. Before leaking it, check the domain for any 172.20.16.0/22 sub-prefix used elsewhere (a legacy site, a VPN pool, a lab). Routers that receive both the /22 and a more-specific route prefer the specific one, but a router that hears only your /22 will send that traffic to you and it will black-hole.
- It stops covering the site. The moment the new /24 exists outside the /22, the single summary silently omits it; advertise the /21 (or both prefixes) in the same change, not later.
- Transit links. The WAN /30s inside the summary are fine here, since they belong to the site; do not summarise a range that also contains links you would rather advertise separately for traffic engineering.