Dropped VoIP Calls on a Flat 120-User Network
A 120-person logistics office runs everything on one flat subnet, 10.10.5.0/24. Eight unmanaged 24-port switches are daisy-chained to a single router port, six wireless access points run in bridge mode, and the DHCP scope covers 10.10.5.20-10.10.5.220 with an eight-day lease. About 260 devices are connected, including personal phones. Desk phones and softphones use a hosted VoIP provider; there is no voice VLAN and no QoS marking anywhere in the switch chain. Users report two to four dropped calls a day, occasional one-way audio, and a handful of "cannot obtain an IP address" failures each week. At 10:00 and 14:00, latency to the SIP provider rises from about 18 ms to 140 ms with 1-3% packet loss; those times coincide with shift handover and with a 200 GB offsite backup of the file server that often overruns its window and is re-run manually by an administrator. The internet link is 300/300 Mbps.
1. Rank the likely causes of the voice problems and the DHCP failures, citing the evidence in the scenario.
Read the worked answer
DHCP first, because the arithmetic is decisive: a 200-address pool against roughly 260 devices means the scope can be exhausted whenever phones, laptops and guest handsets are all present, and an eight-day lease keeps abandoned addresses out of circulation for days. That explains the address failures directly. Voice is next: a flat /24 with no QoS means RTP shares queues with everything else, and one-way audio usually points to NAT or a router SIP ALG rewriting SDP rather than to the LAN. Third, the 10:00 and 14:00 spikes: 200 GB is about 1,600 Gb, so roughly 90 minutes of saturated upstream at 300 Mbps even at line rate, and a manual re-run starting at handover will queue voice behind bulk TCP. The daisy-chained unmanaged switches remove any ability to see traffic or prioritise it, and offer no loop protection.
2. Give a phased remediation plan separating changes you can make this week from structural work.
Read the worked answer
This week: move the DHCP scope to a /23 (10.10.4.0/23) or add a second scope, cut the lease to eight hours for wireless and guest, and reserve a static range for desk phones; move the backup to 01:00 and cap it with a shaper or QoS policy so it cannot exceed about 150 Mbps; check the router for a SIP ALG and disable it if one-way audio persists; verify no switch is looped by comparing port LEDs and MAC counts. Next 30 days: replace the daisy chain with a star topology around a managed core switch, create voice and data VLANs, mark RTP EF and SIP CS3 at the phone and trust it on the access port, and apply a priority queue on the WAN uplink. Beyond that, a second WAN or dedicated voice circuit if the provider offers it, plus monitoring. Sequence matters: segmentation is a maintenance-window change and should follow, not precede, the free DHCP and backup fixes.
3. What would you measure to prove the fix, and how would you report it to the business?
Read the worked answer
Baseline, then weekly: DHCP scope utilisation and counts of NAKs and DECLINEs; latency and jitter to the provider's media gateway from a probe every 60 seconds; packet loss; and the provider's call detail records and MOS scores. Correlate drops with the backup window before and after the change - if drops stop at 10:00 and 14:00 but continue at random, the cause was multiple and the VLAN and QoS work is still required. Report in business terms: dropped calls per 100 calls and users unable to get on the network per week, not 'QoS has been enabled'. Agree targets up front, for example under 1% packet loss and zero DHCP failures, so the report has a pass or fail rather than a narrative.