One Uplink, Four Subnets, and a 3 P.M. Backup
A client is consolidating three small offices into one three-floor building: 140 desk employees, 60 VoIP handsets, 30 wireless access points, 20 networked printers, and a guest network serving roughly 200 visitors per week. The previous tenant left a flat 192.168.1.0/24 with a single DHCP scope, unmanaged 24-port switches, and one Cat5e uplink daisy-chaining each floor's IDF to the MDF. All cabling home-runs to a single telecom room on floor 1. The ISP delivers a /29 with five usable addresses. Finance approved new switches and a firewall but no new cabling. At 3 p.m. daily, users report choppy voice calls and slow file access; that is also when an admin manually starts the cloud backup before leaving for the day.
1. Produce the VLAN and subnet plan. Show the host math, justify each size, and explain what you do with the existing 192.168.1.0/24.
Read the worked answer
Host math: a /24 gives 254 usable, a /25 gives 126, a /26 gives 62.
| VLAN | Purpose | Devices now | Size | Range |
|---|---|---|---|---|
| 10 | Data (workstations) | 140 | /24 (254) | 10.20.0.0/24 |
| 20 | Voice | 60 handsets | /25 (126) | 10.20.1.0/25 |
| 30 | Management, APs, printers | 30 + 20 = 50 | /25 (126) | 10.20.2.0/25 |
| 40 | Guest | ~60-80 concurrent | /25 (126) | 10.20.3.0/25 |
Justification: data cannot be a /25 - 140 hosts exceeds 126 on day one, and shrinking later means re-addressing every workstation. Voice at /25 runs 48% utilized with room for handsets and softphones. A /26 for management/printers would sit at 50 of 62 addresses, which is too tight for a set that grows every time someone adds an AP or a label printer. Guest must be sized to concurrent visitors, not the 200 weekly total; a /25 plus client isolation is right.
Renumber, do not reuse. 192.168.1.0/24 collides with the default range of most home routers, so every VPN user and every consultant on site will have a routing conflict. The move to a new building is the cheapest moment you will ever get to renumber.
Configuration: L3 switch or router-on-a-stick with an 802.1Q trunk over the single existing uplink per floor, DHCP scope per VLAN with an IP helper, LLDP-MED to place handsets on VLAN 20 automatically, DHCP option 66/150 for phone provisioning, and reservations or static addressing for printers and APs.
2. How do you allocate the five usable public addresses, and what do you refuse to do with them?
Read the worked answer
Allocation:
- Firewall WAN primary - all corporate traffic leaves via NAT overload.
- Secondary WAN for the future second ISP / failover path (reserve it now; procuring it later without an address is a nuisance).
- SIP trunk or session border controller, only if the voice provider requires a fixed registered public address. Confirm this before spending it.
- Guest egress on its own address, so that guest abuse does not damage the reputation of the address the company's mail and VPN depend on.
- Spare - hold it.
What I refuse: no one-to-one NAT for servers, no inbound port forwards for RDP/HTTP to internal hosts, and no public addressing of printers or APs. Remote access goes through a VPN or a brokered zero-trust service, not published ports. The point of NAT overload here is not security by obscurity - it is that publishing services is a decision you make deliberately, with a firewall policy, not a default.
Also verify: whether the voice provider allows registration from a dynamic or shared address. If it does, address 3 is reclaimed and the /29 gets more headroom than expected.
3. Diagnose the 3 p.m. symptom and specify the fix with enough specificity to verify it afterward.
Read the worked answer
The trigger is a human, but the cause is arithmetic. Take a 200 GB backup over a 100/20 Mbps circuit: 200 GB is 1,600 Gb, so at a full 20 Mbps upload it takes about 22 hours. Even a 20 GB job takes over two hours. So the manual 3 p.m. start does not "run overnight" - it saturates the upload for the entire rest of the day and into the night, which is exactly when calls degrade and cloud-hosted file access stalls.
Confirm before changing anything: pull interface utilization graphs from the firewall and switch port for the WAN and the backup host. If upload sits at 95%+ from 3 p.m. onward, the diagnosis is closed without speculation about the ISP.
Fix, in order:
- Move the backup window to 01:00 and remove the manual trigger.
- Rate-limit the backup job to roughly 40% of upload capacity so it can never starve interactive traffic even if it runs long.
- Implement QoS: DSCP EF (46) marking on handsets via LLDP-MED, a priority queue for voice, and a reservation of about 15% of the 20 Mbps upload. Sixty G.711 calls at roughly 87 kbps each way means roughly ten concurrent calls use under 2 Mbps - cheap to protect.
- Verify with measured latency, jitter, and loss during the busy hour: targets under 150 ms latency, under 30 ms jitter, under 1% loss. "Calls sound better" is not verification.