Segmenting a Flat /22 After Rogue Access Points
NorthPort Logistics has 480 staff across three floors of one building. Everything sits on a single flat VLAN using 10.20.0.0/22; the same range serves workstations, servers, printers and a guest Wi-Fi. Since the guest SSID was added, the helpdesk sees several broadcast storms a month, and staff have plugged personal travel routers into wall ports to "improve" Wi-Fi, which has caused at least two switching loops. Management wants finance printers reachable only from finance workstations, and the auditor asked why the guest network can reach the file server. The company has one L3 core switch with VLAN support, 24-port access switches with 802.1Q trunks, port security and storm control, but no NAC and no 802.1X. Two-year headcount plan: Sales 150 growing to about 225, Warehouse 100 to 150, Finance 40 to 60, Guests up to 90, Servers 30 to 45, network management 10 to 15. Budget for new hardware is nearly zero.
1. Produce an addressing plan from 10.20.0.0/22 that supports each group at its planned two-year size with growth headroom, showing prefix, usable hosts and justification for each choice. Note what remains unused.
Read the worked answer
Start from the block size: 10.20.0.0/22 spans 10.20.0.0 to 10.20.3.255, which is 1,024 addresses. Work largest-first and size each subnet to the planned figure, not today's.
| Group | Planned | Prefix | Usable | Why |
|---|---|---|---|---|
| Sales | 225 | 10.20.0.0/24 | 254 | A /25 gives 126 and fails immediately; /24 fits with modest headroom |
| Warehouse | 150 | 10.20.1.0/24 | 254 | /25 (126) is below plan, so /24 is the smallest passing option |
| Finance | 60 | 10.20.2.0/25 | 126 | /26 gives 62 usable - only two spare addresses, which is not headroom |
| Guest | 90 | 10.20.2.128/25 | 126 | /26 (62) cannot hold 90 devices |
| Servers | 45 | 10.20.3.0/26 | 62 | Comfortable for 45 with a few service addresses |
| Network management | 15 | 10.20.3.64/27 | 30 | Small loopback/SVI block |
Unused: 10.20.3.96 to 10.20.3.255, roughly 160 addresses, which should be reserved for point-to-point links, a future voice VLAN or a second guest SSID rather than handed out casually.
The judgement being tested is that 50% headroom cannot be applied uniformly: 225 sales addresses will not fit a /24-with-a-/25-spare mindset, and 60 finance hosts should not be squeezed into a /26 just because the arithmetic barely passes. Also note that the guest and finance subnets split one /24 at the /25 boundary, which keeps the plan inside the existing /22 with no renumbering of the core.
2. With no NAC and no 802.1X budget, rank the controls you would apply against rogue access points and loops, and explain what else must be configured before moving guests to their own VLAN answers the auditor.
Read the worked answer
Ranking by risk reduced per unit of effort.
- BPDU guard and storm control on every access port. A travel router creates a loop; BPDU guard err-disables the port the moment it sees a BPDU, and storm control caps broadcast before the CPU of the access switch saturates. Zero hardware cost, already supported, and it addresses the failure that actually took the network down. This is first because availability loss outranks the confidentiality risk.
- Port security with a sticky MAC limit of one or two per access port. A consumer router performing NAT presents multiple MACs and gets shut down. It is defeatable by MAC cloning, so treat it as raising cost rather than preventing the act. Pair it with disabling unused wall ports, which is free and removes the easiest insertion point.
- Detection and policy. A quarterly wireless survey with a cheap analyzer, plus a written prohibition and an amnesty process for staff who self-installed equipment, finds what the switch cannot see. 802.1X with RADIUS is the real fix but needs a server, certificates and an administrator, so it belongs in next year's budget request, not this quarter.
Why a guest VLAN alone is not compliance. Putting guests on 10.20.2.128/25 only changes the broadcast domain. Unless the L3 core has no route between the guest SVI and the server SVI, or an explicit ACL denies guest-to-RFC1918 and permits only DHCP, DNS and internet, the auditor's finding stands. The plan therefore needs: no inter-VLAN routing for guest, a deny-by-default ACL on the guest SVI, client isolation on the SSID so guests cannot reach each other, and a rule preventing the guest subnet from reaching the management VLAN.