A school refreshes 48-port access switches for classrooms with VoIP phones, 30W pan-tilt cameras, and PCs needing after-hours Wake-on-LAN from a management VLAN. Power circuits are limited and night power-save is desired. Which PoE budget and Wake-on-LAN switch design fits the constraints?
Select an answer to reveal the explanation.
Short Explanation
You need to plan for phones and cameras drawing power at the same time, while keeping critical ports prioritized. Forwarding Wake-on-LAN to sleeping PCs lets you save power overnight without losing control—smart scheduling for power.
Full Explanation
Sizing for concurrent loads with priority ports fits the limited circuits: VoIP phones and 30W pan-tilt cameras can receive power during peak demand without relying on every device drawing less than its maximum. Forwarding Wake-on-LAN to sleeping PCs from the management VLAN lets after-hours magic packets reach them across VLANs while the PCs sleep, supporting night power savings. Restricting Wake-on-LAN to the local client VLAN fails the required cross-VLAN workflow: without forwarding across the Layer 3 boundary, the management VLAN packet does not reach the sleeping PC. Oversubscribing the PoE budget based on assumed load diversity is unsafe because simultaneous high-draw events, such as cameras moving together, can cause power denial, flapping, or brownouts. Disabling night power-save while forwarding Wake-on-LAN may preserve wake capability, but it conflicts with the explicit goal of reducing overnight consumption on constrained circuits. An exam caveat: a powered-off switchport cannot sense a magic packet, whereas a sleeping PC with Wake-on-LAN enabled can remain reachable. As a practical check, verify port priorities with show power inline, send a test magic packet from the management VLAN to a sleeping host, and measure overnight draw while confirming phones and cameras remain powered.