PoE budget over-subscription on a camera rollout (FortiLink-managed FS-148F-POE)
A warehouse refresh is being cut over with a FortiGate 80F managing three FortiSwitches over FortiLink: two FS-148F-POE units (A and B) in the rack, each with a 370 W PoE budget, plus an FS-108F-POE in the loading dock. Switch A was chosen for the camera rollout: 6 PTZ cameras that negotiate 802.3at (25.5 W at the PD), 2 Wi-Fi 6 access points, also 802.3at, and 12 fixed bullet cameras that negotiate 802.3af Class 3 (12.95 W at the PD). All 20 devices are patched into switch A. Daytime operation looks fine, but every night between 01:00 and 03:00 three to five cameras reboot repeatedly and the access points drop clients for 30-60 seconds. The UPS log is clean and there is no spanning-tree or uplink event in the logs. Switch B already carries 12 PoE IP phones (802.3af Class 3) and has spare capacity. The site manager will not buy new hardware and wants the rollout fixed before the weekend.
1. Show with numbers why switch A is failing, and explain why the failures cluster at night and hit cameras harder than access points.
Read the worked answer
1. Do the reservation math first, not the wattage math. A PoE PSE reserves power per class at detection/classification time: 802.3af Class 3 reserves 15.4 W, 802.3at Class 4 reserves 30 W.
- 8 x 802.3at devices (6 PTZ + 2 APs) x 30 W = 240 W
- 12 x 802.3af bullets x 15.4 W = 184.8 W
- Reserved total = 424.8 W against a 370 W budget
That is 54.8 W (about 15%) over budget before a single camera is switched on, so switch A is already running in an over-subscribed state where ports are only kept alive as long as nobody re-requests power.
2. Then look at real draw and why night matters. Bullets negotiating af draw near 12.95 W by day, but IR illuminators switch on at dusk and push each camera to roughly 16-18 W. Real draw goes from about 315-330 W by day to roughly 400-410 W at night - above the 370 W budget. When the PSE cannot fund a request it denies power or sheds the lowest-priority ports, so the camera power-cycles, boots, re-requests power, and loops.
3. Why cameras and not the APs. The APs are the same class as the PTZs but are usually the first devices the PSE granted power to and typically sit on lower port numbers/priority; the bullets are the devices whose consumption actually changes at night and the ones that get denied. AP client drops of 30-60 seconds are the same event seen from the wireless side: the AP is not rebooted, but a neighbouring switch port power event and re-convergence interrupts forwarding.
Do not chase this as a cabling, STP, or UPS problem: the clean UPS log and the absence of STP events are consistent with a PSE power-granting problem, and the 01:00-03:00 window tracks IR load, not user traffic.
2. Design a fix that uses only the existing hardware, and list how you would verify it holds through a full night cycle.
Read the worked answer
Rebalance across the two 370 W switches and control who wins when budget is tight.
Move load, don't add hardware. Move 6 bullets to switch B:
- Switch A: 8 x 30 W (240 W) + 6 x 15.4 W (92.4 W) = 332.4 W of 370 W (~90%, 37.6 W free).
- Switch B: 12 phones x 15.4 W (184.8 W) + 6 x 15.4 W (92.4 W) = 277.2 W of 370 W (~75%, ~93 W free). This keeps every device powered under the class-reservation model, which is the conservative model the PSE actually uses.
Make priority explicit. Set PoE priority high/critical on the AP ports and the PTZ ports, and low on the bullets. If the site ever over-subscribes again, the PSE sheds fixed cameras, not the APs and not the PTZs.
Reclaim wasted budget. Disable PoE on every unused port and on copper ports patched to non-PoE devices (servers, printers). Confirm LLDP power negotiation is enabled so 802.3at devices are allocated closer to their negotiated draw rather than a flat 30 W - this recovers roughly 30-40 W on switch A.
Leave headroom. Do not run a switch above about 80-85% reserved; inrush current on a cold morning and IR load at night are exactly the conditions that broke this design.
Verification over a night cycle:
- Read per-port delivered power on both switches after the move and again at 02:00; every port should show a stable draw and no port should report power denied or a PoE fault.
- Check the FortiGate/FortiSwitch event log for PoE power-deny and port-down events across the 01:00-03:00 window for two consecutive nights.
- Confirm the APs show no client deauth bursts at the same timestamps.
- Finally, unplug one bullet and re-plug it to prove a new power request is granted while the night load is present - that is the failure mode you are actually testing.