I85PREP
⌘ K
CompTIA Network+ study materials
CompTIA Network+ study resources

The Subnet That Ran Out of Addresses

CompTIA Network+ · Put your knowledge to work in context.

All case studies

The Subnet That Ran Out of Addresses

An office uses 10.20.5.0/24 for a single flat user VLAN. The DHCP scope 10.20.5.100–200 is exhausted; headcount grew by 90 desks last quarter and the site now runs roughly 310 devices - laptops, 45 IP phones, 12 printers, badge readers, and 60 IoT sensors. Printers and badge readers hold static addresses inside 10.20.5.0/24, several documented only in a spreadsheet. Broadcast traffic is about 4% of utilization on the access-switch uplink. Management has approved one weekend maintenance window, no re-cabling, and wants to avoid touching end devices where possible. The core is a Layer 3 switch with 10 Gb uplinks supporting SVIs, DHCP relay, and ACLs.

1. Propose an addressing and VLAN design that resolves the exhaustion and reduces broadcast scope. Justify which devices move and which stay.

Read the worked answer

Move the populations that are DHCP-addressed first, because they cost nothing to renumber:

  • User data stays in 10.20.5.0/24. After removing phones, sensors, and printers, roughly 150–180 hosts remain, leaving ample scope room. Expanding to a /23 is not needed yet and would not shrink the broadcast domain.
  • Voice → 10.20.6.0/24. Phones are DHCP; supply option 150 (or rely on LLDP-MED) and set the QoS trust boundary at the phone, not the PC port.
  • IoT sensors + badge readers → 10.20.7.0/24. These are the least-trusted devices; keep them off the user VLAN and filter at the SVI.
  • Printers → 10.20.8.0/24 if time allows; otherwise defer, since they are static and need a coordinated re-IP. Deferring is a legitimate trade-off - the exhaustion problem is already solved by moving phones and sensors.

Enable ip helper-address on each new SVI so DHCP still works, and add ACLs so IoT cannot initiate to user data. The 4% broadcast figure is a symptom, not the driver; the driver is address space and blast radius. Expect broadcast to drop as hosts per VLAN fall, but do not promise a specific number without a post-change baseline.

2. An engineer suggests simply changing the mask to /23 on the router SVI and the DHCP scope, leaving statically configured hosts at /24. What is the failure mode?

Read the worked answer

The hosts are not the problem in the forward direction - the router has a connected /23, so it happily routes 10.20.5.x ↔ 10.20.6.x. The problem is the return path: a host still configured /24 treats 10.20.6.x as off-net and sends to its gateway, but a /23 host sees 10.20.5.x as on-link and ARPs for it directly. Traffic then flows client → router → server but server → client directly, which is asymmetric routing.

Consequences:

  • Stateful devices drop the flow. A firewall or any stateful inspection point sees one-way traffic and resets or drops it.
  • The router becomes a silent single point of failure for traffic it never sees on the return leg.
  • Duplicate-address risk: a /23 DHCP scope can hand out addresses in the 10.20.6.x range where an old /24 static device already lives, producing an intermittent conflict nobody can reproduce.
  • No reduction in broadcast scope, which was a stated goal.

Mask mismatch is the classic cause of "works from some hosts, not others." Either change every device's mask or move to real VLANs; do not mix.

3. Sequence the migration across the single maintenance window and state how you would validate success before declaring the change closed.

Read the worked answer

Pre-work (before the window): export the running config, build an inventory of every static host by ARP/neighbor sweep of 10.20.5.0/24, create the new SVIs, DHCP scopes, and helper addresses but leave them shut down, and pre-stage ACLs.

In window, in order:

  1. Change access ports for voice to the new voice VLAN (or set the voice VLAN on the port and let LLDP-MED move phones) - phones re-DHCP fastest and are most visible to users if wrong.
  2. Move IoT/badge ports; confirm devices re-register.
  3. Enable the new SVIs and helpers; confirm leases are being handed out from the correct scope by checking the DHCP server lease table.
  4. Re-IP printers last, with a printed runbook, since they need manual or scripted changes.
  5. Only then shrink the 10.20.5.100–200 pool back to a normal size.

Validation: lease counts per scope, successful ping/print from a sample of each device class, broadcast rate on the uplink re-baselined, ACL hit counters showing IoT blocked as intended, and a documented rollback point (config archive plus the port-to-VLAN map) that can be applied in under ten minutes.