The port that loses power is almost never the port you would have picked. It is whichever port the switch ranked last — sometimes because somebody typed "low" into it two years ago and forgot, sometimes because nobody typed anything at all and the tie-breaker came down to port index. I have watched a loading-bay camera go dark so that a lobby menu board could keep running, and nobody on that site could explain the trade. The switch knew exactly why. It just had no way to say it out loud.
A cold snap two winters ago gave me the cleanest version of this. Twenty devices on a 24-port switch with a 370 W budget, commissioned in June, every port green. In January: cameras dropping between 03:00 and 04:00, back by 04:30, no pattern anyone could name. I clamped the feed and read 347 W where my June note said 290 W. Nothing had failed. Heaters had come on, illuminators were running fourteen hours a night, and the reserve was gone. The switch did precisely what it was configured to do — shed whatever sat at the bottom of a list nobody had written down.
Load shedding is not a failure mode. It is a design decision, and on most projects it gets made by accident.
The Budget Doesn't Drain. It Disappears One Port at a Time
A switch commits power the moment a port comes up and holds the commitment until the port goes down. The budget is a stack of reservations, not a pool, and the interesting question is what each reservation is worth.
Take the site above. Twelve fixed cameras, six access points, two pan-tilt units with heaters. Cameras and APs negotiate as Class 4; the PTZs land in Class 6. Run the numbers the way a default configuration sees them: 12 × 30 + 6 × 30 + 2 × 60 = 660 W. Against a 370 W budget, that switch powers up twelve ports and refuses the other eight. Which twelve? The first twelve to finish detection, which in practice means the first twelve in port order. Nobody chose them. The port numbering chose them.
Same site on measured draw: 12 × 7.1 W, 6 × 20.5 W, 2 × 41 W — 290 W. The hardware was never the problem. The reservation model was, burning 370 W of capacity to carry 290 W of load while telling the installer half the ports were unusable. And once you fix the accounting and pack twenty devices into 290 W, you have 80 W of headroom and a warm feeling. Eighteen months later the seasonal load arrives and eats it. That is where shedding comes back in.
Four Accounting Modes, Four Different Failure Shapes
Every platform picks from the same short menu, and the menu decides not just how much you can power but what happens when you can't.
| Accounting mode | What the port reserves | What it does to a 370 W budget | Where it bites |
|---|---|---|---|
| Class-based (static) | The class ceiling: 15.4, 30, 60 or 90 W | 20 devices demand 660 W; 12 ports come up, 8 are refused | Capacity you paid for sits idle, and port order picks the winners |
| LLDP negotiated | What the PD asks for, 0.1 W resolution | 20 devices fit in roughly 300 W with margin | Only works if the PD answers properly; plenty of cameras do not |
| Manual per-port max | The number you type into the port | You decide the stack; a 9 W cap on a 7.1 W camera is honest | Cap it too tight and the PD refuses to boot or silently drops its heater |
| Actual / dynamic | Measured draw, revised as load moves | Packs hardest of the four, sometimes to 95% | A 20 W heater step at 03:00 puts you over and triggers shedding |
I default to per-port max with a measured baseline underneath it, because it is the only one of the four where the number on the port matches something I measured. LLDP is better when it works, and it frequently doesn't — a camera that reports Class 4 over hardware classification will sometimes answer an LLDP power request with nothing at all. Most PoE switches ship with class-based reservation enabled, so this is an active decision, not a setting you inherit.
Whatever the mode, reservation happens at the PSE, not at the device. The standards show the size of that gap: 802.3at allocates 30 W at the PSE for 25.5 W at the PD, and the 4.5 W difference is 600 mA across a 12.5 Ω channel. Divide, and you get a planning factor near 1.18 for a Class 4 load on a full-length run. A camera measured at 7.1 W needs about 8.4 W reserved. Multiply that error across twenty ports and you have invented 26 W of headroom that does not exist.
Priority Is Three Tiers, and Most Sites Use Them Badly
The mechanism is older than most of the gear it runs on. RFC 3621 defined the POWER-ETHERNET-MIB with a per-port priority of critical, high or low, and that is still the shape of it. Vendors wrap their own numbering around the same three ideas: on Cisco Catalyst the scale runs 0 to 7 where 7 is least important and sheds first, so a higher number means a lower right to power.
Two details catch people out. Within a tier the tie-breaker is physical position — slot, then port index — so the last port of the last stack member is the default sacrifice whether or not your entrance camera lives there. And on at least one major platform, a port in static power mode runs at the highest priority regardless of what you set administratively: a sensible rule that quietly ignores your configuration.
My opinion, offered with the confidence of somebody it has backfired on: two tiers used deliberately beat three used decoratively. Mark everything critical and you have not created a priority scheme, you have deleted one and handed the decision to port index. Tiers should encode consequence, not device category — a camera over a fire exit is not the same as a camera watching a car park, though both are cameras and both are Class 4. That is what a managed switch is for, and most sites leave it at the factory default.
| Device on the port | Tier I assign | Why |
|---|---|---|
| Camera at a controlled exit or cash desk | Critical | Loss is an incident with a report attached, not a gap in a timeline |
| Access point carrying voice or the site's only coverage | Critical | Losing it takes down calls, and roaming neighbours will not absorb the load |
| General surveillance cameras | High | Recoverable: a 40-second gap is a nuisance, not an event |
| Electronic access control, fail-safe strike | Critical, plus a separate supply | Priority cannot fix a lock that releases when it loses power — that is physics |
| Displays, signage, spare ports, test gear | Low | This is what a shed list is for; keep it populated so the switch never has to guess |
Two mistakes I have made with this. The first was marking every port high on a 24-port switch because high sounded safer than low. I told the client the site was protected. What I had done was collapse the tiers into one and hand the decision to port index — the camera on port 24, covering the goods entrance, went first when the budget tightened. The setting looked like diligence. It was the absence of a decision wearing its costume.
The second was arithmetic on the wrong number. I built a shed order from nameplate watts, concluded the site sat at 82% of budget, and felt good about it. The switch, reserving class ceilings, was refusing ports. Both figures were true; only one was the figure the switch used. Shedding is decided on reservation, and I had spent an hour modelling draw.
What Actually Happens in the Millisecond It Sheds
Nothing graceful. The PSE removes the port voltage; the PD gets no notice, no LLDP goodbye, no chance to park its state. From the device's point of view the mains just failed.
A fixed camera comes back in thirty to forty-five seconds and, depending on model, forgets its home position, its focus and whether the illuminator was on. An AP reboots, clients scatter to neighbours, and those neighbours now carry more traffic and, on a shared budget, draw more power — a feedback loop that turns one shed port into three. An NVR records a gap somebody notices six months later.
Then the case that made me rewrite my checklist: a fail-safe electric strike on a door controller powered from the switch. The port was shed at 03:40 and the door released. Nobody walked through it. That time. A priority setting is not a safety argument — if a lock must stay locked when power fails, it needs its own supply, and no amount of configuration changes that.
Two more behaviours worth knowing. Shedding happens in whole ports, not in watts: 11.7 W over budget does not trim 11.7 W, it drops a port, and if that port was reserved at 7.1 W it drops a second. Two cameras gone to recover 14.2 W. And on some platforms a high-priority device arriving later is not refused — it takes power from a low-priority port already running. The camera dies at 14:00, the moment somebody plugged in a PTZ two floors away, and the log shows a normal power-up for the newcomer and nothing for the victim. Startup timing is a separate budget altogether, which I worked through in the inrush article.
Building a Shed Order You Can Defend
If I got one page in a handover pack, this would be it. An afternoon of work that turns an accident into a decision.
- Measure each device at its worst case, not idle. Illuminator forced on, heater engaged, PTZ mid-self-test. Idle draw proves the cable is continuous; it says nothing about the number you are about to reserve. If the switch cannot report per-port watts, clamp the run at the device — that telemetry gap is why I stopped trusting unmanaged units for this job.
- Convert device watts into PSE reservation. For a Class 4 load on a full 100 m run, multiply by about 1.18 — the 30 W to 25.5 W ratio from the standard. A 7.1 W camera becomes 8.4 W reserved. Shorter runs and 23 AWG let you use a smaller factor — if you know the run length.
- Add the seasonal delta you know is coming. Illuminators at 2.9 W across twelve cameras is 34.8 W; two heaters at 11 W is 22 W. That is 56.8 W of load that exists in January and not in June: 290.2 + 56.8 = 347.0 W.
- Add next year's devices now. Two cameras at 7.1 W and one more AP at 20.5 W take the switch to 381.7 W — eleven point seven watts over budget, which is the kind of margin a project manager calls "fine".
- Compare against the budget at your real inlet temperature. A 370 W figure is usually quoted at 25 °C. Put that chassis in a sealed wall box at 45 °C and the usable number falls, often to 85% or lower. The 381.7 W above is against a number the site may not have.
- Write the order down and test it. Lower the global PoE budget, or overcommit one port's max, and watch which ports drop, in what sequence. Ten minutes. Log the port numbers, restore the budget, and file the list with the six handover measurements.
The list itself should read like a sentence, not a principle. "Port 24 first, then 23 and 22, then 19 through 21, then nothing below 19 unless I am on site." If it says "low priority ports shed first", you have written a wish, not a shed order.
Questions That Come Up at the Cabinet
Does priority decide what powers up, or only what gets dropped later?
Both, and the split matters. When a new device asks for power the budget cannot cover, some platforms refuse the request outright and keep everything running. Others take power from a lower-priority port to feed the newcomer. Same setting, opposite outcome, depending on firmware — so test it with a deliberate overcommit before the site goes live.
What happens if every port is set to high?
The tier stops carrying information and the platform falls back to its tie-breaker, which is physical port order or slot order. Same arbitrary result as having no configuration at all, plus a false sense of control. Keep a populated low tier — even for ports you never intend to use.
Can I just lower each port's maximum to fit more devices?
Yes, and it is the most useful lever on the switch. But the cap is enforced, not advisory: a camera capped below its boot draw will not come up, and one capped just above boot may disable its illuminator when it needs it most. Cap at measured worst case plus a margin, never at the nameplate, and never below it.
Does any of this help when a power supply fails?
Partly. Losing a supply drops the available budget, and priority then decides who keeps running — exactly when the tier list earns its keep. But some platforms drop the whole PoE domain for a second or two while they re-evaluate, so everything reboots regardless of tier. If a site cannot tolerate that, split the load across two switches rather than tuning priorities.
Closing the Loop
The number I keep coming back to is 11.7 W. A site can be correct on paper, correct in June, correct at every checkpoint in the commissioning document, and still be 11.7 W from shedding a camera in January. The difference between failing gracefully and failing stupidly is whether somebody spent an afternoon writing down which device they were willing to lose, in what order, and then watched the switch prove it.
If you have run a real budget shortfall on a live switch — an actual 03:00 event, not a lab — I am curious what your platform did with the port that was already running when the high-priority device arrived. The docs disagree with each other on that one, and field behaviour has disagreed with the docs more than once.