Hotel Wi-Fi dies at eighteen hundred
A 42-room boutique hotel in Sliema offers free Wi-Fi. Guests connect to a single SSID on 192.168.10.0/24; DHCP leases last 12 hours; the same router also serves the front-desk PC and two card-payment terminals on the same subnet. On a busy Saturday about 300 distinct devices associate over the day, though no more than 120 are present at once. From about 18:00 guests report 'connected, no internet', and the front desk says card payments occasionally time out. Logs show the DHCP pool exhausted by 17:30 and roughly 40% of traffic being broadcast or ARP. The hotel has a 100 Mbps fibre uplink and one managed switch that supports VLANs, but no separate firewall.
1. Explain why the guest network fails in the late afternoon even though only 120 devices are active at once.
Read the worked answer
The lease lifetime, not the headcount, exhausts the pool. A /24 gives 254 host addresses; after router, switch and printer reservations, roughly 240 are usable. With 12-hour leases, a guest who connects for ten minutes at 10:00 keeps an address until 22:00. By 17:30 the hotel has handed out about 300 leases over the day, so the pool is exhausted while only ~120 devices are actually transmitting. New arrivals are associated at layer 2 but cannot obtain an IP address, which produces exactly the 'connected, no internet' report.
Broadcast load compounds it. A flat /24 with 120 active devices and heavy ARP and mDNS traffic can reach 40% broadcast, consuming airtime and CPU on the router. The same subnet also carries the POS terminals, so broadcast storms and DHCP churn delay card authorisations. The POS timeouts are therefore a symptom of flat network design and shared broadcast domain, not proof of an uplink fault.
A correct diagnosis separates address exhaustion from broadcast contention and notices that the POS problem is a consequence of the flat design.
2. Propose a redesigned network for the hotel, justifying each change against the observed numbers.
Read the worked answer
1. Segment by VLAN. Put guests on VLAN 20 and staff/POS on VLAN 30, with an access control list blocking guest-to-POS and guest-to-management traffic. Client isolation on the guest SSID prevents guest-to-guest attacks. This directly addresses the POS timeouts by removing them from the guest broadcast domain.
2. Enlarge the guest address space. Move guests to 192.168.20.0/23 (510 usable addresses) or keep a /24 but add a second guest SSID/subnet. With 300 devices per day and peak concurrency of 120, a /23 gives roughly four times the headroom.
3. Cut lease time to 2 hours. A device that leaves at noon releases its address by 14:00, so the daily churn no longer accumulates. Two hours is long enough to survive a guest's nap or dinner without reconnecting.
4. Add QoS and per-client rate limiting. Cap each guest at, say, 8 Mbps so one streamer cannot saturate the 100 Mbps uplink; give the POS VLAN priority.
5. Replace the single router with a firewall/router that supports inter-VLAN routing and logging. One managed switch alone cannot enforce policy.
Verification: monitor DHCP pool utilisation across a weekend, confirm broadcast below 10%, and test a payment during peak guest load.