The /27 That Wasn't Enough

A /27 has 32 total addresses: 30 usable host addresses after the network and broadcast addresses. The lab needs 34 hosts: 30 Chromebooks, one teacher laptop, one printer, one access point, and one server. That is four more than the subnet can support. The symptoms follow directly. The DHCP pool uses all 30 usable addresses, and the printer and server static addresses are inside that pool, so DHCP can hand out an address that is already in use, producing conflicts. The printer is reachable only from some machines because some clients have conflicting leases or are on different address assignments. The six Chromebooks that cannot connect are likely the overflow when the pool is exhausted. The core problem is not a bad cable or a browser setting; it is that the address plan was sized for 30 devices but the lab has 34, and static addresses were not excluded from DHCP. A quick fix must address capacity and documentation, not just reboot the access point.

The coordinator should not simply add the spare /27 to the same flat lab without a plan, because two subnets on one lab segment require routing and can create confusion for student devices. The cleanest fix is to request a /26, which provides 62 usable addresses, or to use the two /27 blocks on separate router interfaces with one for student devices and one for infrastructure. If the spare /27 is used, put the printer, server, access point, and teacher laptop on an infrastructure subnet or VLAN and keep student Chromebooks on the original subnet with a DHCP pool that excludes static addresses. DHCP reservations should be created for the printer and server, and the pool should be documented. Segmentation also limits broadcast traffic and makes filtering rules clearer. The coordinator should label ports, record the address plan, and test the printer from both subnets. Capacity planning should account for guest devices and future growth, not just the current 34 hosts.

DNS-over-HTTPS encrypts DNS queries to a resolver outside the district, so changing browser settings alone is not a reliable control. The coordinator should block known DoH resolver endpoints and domains at the perimeter firewall, force district devices to use the internal DNS resolver, and apply content filtering at the network gateway rather than relying on browser settings. She should also configure managed browser policies where the district controls the devices and use a captive or authenticated network for personal devices. These measures are not perfect: a determined student can use a personal hotspot or an unblocked resolver, so the district should pair technical controls with an acceptable-use policy and digital citizenship instruction. The coordinator should avoid claiming that the filter is bypass-proof. She should document what is blocked, test the rules, and define a response process for repeated violations. The goal is risk reduction and consistent enforcement, not a guarantee.