Conference Room B Drops Every Video Call
A 60-person office runs a single /24 DHCP scope (254 usable addresses) with 8-day leases and about 90 devices: laptops, VoIP handsets, and a guest network that sees heavy visitor churn. In Conference B, video calls break up every 10 to 15 minutes, but only when more than six people join. Wired connections in the same room are fine. The room's access point is six years old, 2.4 GHz only, 802.11n, set to channel 6; a site walk shows two neighboring APs also on channel 6. Pings to the gateway from affected laptops spike to 300 to 900 ms with about 15 percent loss, only during calls. There is no budget for new hardware until next quarter and the company all-hands is in three days.
1. Is DHCP scope exhaustion a plausible primary cause? Show your reasoning with the numbers given, and identify the more likely cause.
Read the worked answer
Check it, but the numbers do not support it as the primary cause.
- Roughly 90 devices holding addresses against 254 usable addresses leaves about 164 free.
- With 8-day leases, addresses are held for a long time, but guests do not consume them at a rate that would exhaust a /24 in a 60-person office. Even 40 unique guests per day would need six days of zero reuse to fill the pool.
- Exhaustion would also fail at association time, not selectively during calls. A device that cannot get a lease usually gets a 169.254 address and fails entirely, rather than showing 300 to 900 ms latency with 15 percent loss.
More likely cause: airtime contention on a saturated 2.4 GHz cell. One 802.11n AP on channel 6, overlapping two other APs on channel 6, has both co-channel interference and a shared medium. Six or more clients running real-time video consume airtime and force retransmissions; latency spikes and loss appear only under load, which matches the symptom exactly. Wired traffic is unaffected because it never touches the wireless medium.
Discipline: verify pool utilization from the DHCP server anyway so you can rule it out with a number rather than an argument.
2. Give your first three diagnostic actions in priority order and state what result would change your hypothesis.
Read the worked answer
- Pull AP client count, retry rate, and channel utilization during a call. Look for utilization above roughly 60 percent and high retry counts. If utilization is low and retries are low while latency is high, look elsewhere, such as upstream switching or the internet circuit.
- Run a channel scan from the room and confirm the neighboring APs' channels and signal strength. If two nearby APs are on channel 6 at strong signal, co-channel interference is confirmed. If the neighbors are actually on 1 and 11 and signal is weak, the interference story weakens.
- Check the AP's switch port for errors, duplex mismatches, or power issues, and check DHCP pool utilization. CRC errors or a flapping link would explain loss that has nothing to do with radio.
Results that would overturn my hypothesis: low channel utilization during the fault, errors concentrated on the wired uplink, or the problem following specific laptops rather than the room. Any of those points away from airtime contention and toward the client, the switch port, or the upstream path.
3. With no hardware budget, what do you deploy before the all-hands, and what do you document for next quarter?
Read the worked answer
Before the all-hands, in order of impact per effort:
- Move the three APs to a non-overlapping 2.4 GHz plan (1, 6, 11) and set 20 MHz channel width.
- Disable low data rates so distant clients stop dragging airtime for everyone.
- Cap or rate-limit the guest SSID, and if guests do not need it in Conference B, remove the guest SSID from that AP.
- Run the all-hands presentation from a wired connection and ask remote participants to join with video off where possible.
- If the room has a wired drop, put the presenter and any shared screen on it and treat wireless as backup.
Document for the budget request: measured channel utilization and retry rates before and after the channel change, the number of failed or degraded calls, the headcount affected, and the fact that the AP is 802.11n 2.4 GHz only with no 5 GHz radio. A refresh request with before-and-after data wins; 'the Wi-Fi is bad' does not.
What not to do: do not add another 2.4 GHz AP on channel 6 as a quick fix. That adds a co-channel neighbor and typically makes contention worse.