Most networks don't fail at the switch. They get quietly downgraded by it — and nobody reads the log line that says so.
Last November an integrator I've known for years sent me a screenshot instead of a question. Four access points, all online in the controller, all drawing power, all associated with clients. Underneath them, a throughput test: 91 Mbps down, 88 up, flat as a tabletop. He had already swapped two of the access points and was one purchase order away from replacing a switch that was nine months old.
I asked him one thing. What does the switch say it is allocating to each port?
Twenty-five point five watts. Every port. Identical, tidy, and completely wrong for the hardware he had bought.
That number is the ceiling of 802.3at, and the access point had done precisely what its datasheet promises when it cannot get more: it dropped a radio, cut back to two spatial streams, disabled the USB port, and negotiated its uplink down. No alarm fired. No port went red. The network simply became a slower, more expensive version of the one he thought he had installed.
I test PoE hardware for a living, most days on a bench at Newbridge in Shenzhen, where the LitaBridge switches we build get run inside a 45 °C chamber until something gives. Of all the ways a network underperforms, this is the one I meet most often in 2026 — not a dead switch, not a blown PSU, but a switch that is technically delivering power and practically starving the device at the end of the cable. It costs people whole weekends, and it almost always gets diagnosed as "the APs are bad" or "the Wi-Fi design is wrong".
A port that powers a device is not a port that feeds it
Power over Ethernet looks like a cable with voltage on it. It is really a negotiation with three separate stages, and each one can end the conversation early.
The first stage is electrical. When you plug a device in, the switch applies a low voltage and measures a signature resistor. That resistor encodes a class — 0 through 4 under 802.3af and 802.3at, 5 through 8 once 802.3bt enters the picture. Class tells the switch how much power to reserve before the device has even booted. This is why a port can look "fine" while being wrong: the resistor says 25.5 W, the switch reserves 25.5 W, the LED goes green, and everyone moves on.
The second stage is a conversation. 802.3at introduced LLDP-based power negotiation, and 802.3bt extended it with Autoclass, which measures what a device actually draws during a short window and adjusts the allocation accordingly. When both ends support it, you get a truthful number instead of a conservative guess. When one end doesn't, you fall back to the class reservation — which is fine, as long as the class is right.
The third stage happens inside the access point, and it is the one nobody reads. Every enterprise AP ships a power-mode table in its datasheet or install guide. It says, in effect: at 802.3bt Type 3 you get all radios, both Ethernet ports and USB; at 802.3at you get two radios, reduced spatial streams and no USB; below that, it may not boot at all. Vendors are not hiding this. It is on page four of a document nobody opens because the port light was green.
So when I say a switch is starving a device, I don't mean the device is off. I mean the device is running its reduced profile and reporting itself as healthy. The AP is not lying. It is doing exactly what it was designed to do with the power it was offered.
Two bottlenecks that keep getting blamed for each other
Here is where a lot of troubleshooting goes sideways.
Power and Ethernet link rate negotiate separately. A 2.5GBASE-T port stays a 2.5-gigabit port whether it is delivering 30 W or 90 W. PoE does not slow down the PHY. If an access point links at 1 Gbps, the cause is the port, the patch lead, the termination or the cable — not the wattage.
What changes with insufficient power is the AP's internal profile: how many radios run, how many spatial streams each one uses, whether the second Ethernet interface comes up, whether the USB port is enabled, sometimes whether 6 GHz is available at all. Those two failures produce almost identical complaints from users — "the Wi-Fi is slow" — and completely different fixes.
You can separate them in about ninety seconds. Ask the switch what class it allocated on the port, and ask the AP what power mode it thinks it is in. If the allocated class is lower than the AP's full-function requirement, you have a power problem. If the class matches and the link is still 1G, you have a physical-layer problem. Fixing one does nothing for the other, which is why swapping hardware at random feels like witchcraft: occasionally it works, for the wrong reason.
The sum nobody runs
Every PoE switch has two power numbers, and buyers read the wrong one. The per-port figure is a capability. The total budget is a supply. A 24-port switch rated at 30 W per port does not have 720 W to give; it typically has 370 to 450 W, and every powered device draws from that shared pool.
Wi-Fi 7 is what makes this bite. Most current enterprise APs draw somewhere between 35 and 50 W with all radios enabled, and want 802.3bt Type 3 to do it. Take a floor with 24 of them at a realistic 45 W average:
| Line item | Arithmetic | Result |
|---|---|---|
| Full-function AP load | 24 × 45 W | 1,080 W |
| Design headroom (30%) | 1,080 × 1.3 | 1,404 W |
| Switch budget, single PSU | datasheet | 720 W |
| Switch budget, dual PSU | datasheet | 1,440 W |
| Shortfall on the single-PSU unit | 1,404 − 720 | 684 W |
Read that last row again. The switch is not defective. It is doing exactly what its label says. But 684 W of demand has nowhere to go, so the switch starts refusing ports or holding them at a lower class — and the symptom arrives as "some APs on the third floor are slow", which sounds like an RF problem and isn't.
There is a second trap inside the first one. Many switches reserve power by class at the moment a device is detected, not by what it actually draws. An idle AP reserving 51 W is charged 51 W against the budget even if it is pulling 12 W at that moment. Walk into a closet where the budget reads "96% allocated" and you will find a rack of devices averaging 30% utilisation. LLDP negotiation and Autoclass are what recover that gap; without them, plan on the reservation, not the meter.
The 30% headroom is not superstition. Access points draw a burst at boot, PoE lighting and PTZ cameras spike when heaters or motors engage, and every installation eventually grows a device that wasn't in the original drawing. I have never once regretted headroom. I have regretted its absence four times, and each time it cost a second switch, a second electrician and a second outage window.
Your power supply has a temperature, too
Datasheet budgets are quoted at a comfortable ambient — usually 25 °C internal, sometimes 40 °C. A wiring closet in Shenzhen in August, with the door shut and a UPS humming next to the switch, is not a comfortable ambient. Forty-five to fifty degrees is normal. Fifty-five is common in smaller rooms with no active cooling.
Above roughly 40 °C, most internal power supplies begin to derate. A unit rated at 720 W at 25 °C may only guarantee 80% of that at 50 °C, and fanless models can fall further. The switch does not announce this. It simply behaves like a smaller power supply, and the port shedding starts earlier than the arithmetic in your workbook predicted.
802.3bt makes the thermal problem worse from both directions. Delivering 90 W to a port means the switch's own conversion losses rise, and those losses become heat inside the same enclosure that is already struggling. Stack a dozen Type 4 loads, close the door, and you have built a small oven with a management interface. I have watched a fanless 24-port unit begin shedding ports at 52 °C in our chamber, without a single fault light to show for it.
I keep a cheap infrared thermometer in my bag for exactly this. Thirty seconds at the intake vent tells you more about a PoE budget than an hour with a spreadsheet. If the inlet air is above 45 °C, derate the budget by 20% before you size anything, and put "ventilate the closet" on the action list ahead of "buy a bigger switch".
What I check, in order
When someone sends me a "slow Wi-Fi after the AP refresh" message, this is the sequence I run. It takes about twenty minutes and it has never failed to find the answer.
- Allocated power per port, not device draw. The allocation is what the switch budgeted. Device draw is what the AP is using. When those two numbers disagree by a factor of two, you are looking at a class mismatch.
- The AP's required class against what it received. Pull the power-mode table for the exact model. "Supports 802.3at" is not the same as "runs fully on 802.3at".
- Total budget in use versus nameplate. Then check whether a second power supply is fitted, seated, and actually alive. I have found more than one redundant PSU that had never been switched on.
- Inlet temperature. Not the room. The air going into the switch.
- Link negotiation per port. 2.5G, 1G, or 100M. A 100M link on a new run means a pair is open or a termination is bad, and no cable category claim survives that.
- Uplink utilisation and oversubscription. Twenty-four 2.5G ports behind a single 10G uplink is a 6:1 ratio. Fine for office traffic, not fine for a floor of Wi-Fi 7 clients doing local transfers to a NAS.
- The AP's own log. Most controllers will tell you when an AP has entered a reduced power mode. It is usually a single line, timestamped months ago, that nobody read.
Nine times out of ten the answer is in steps one, two and three. The tenth is a cable.
Five rules I would defend in a design review
Size the budget at 1.3× the nameplate sum, then check the derating. Two multiplications, five minutes, and it eliminates the single most expensive mistake in access-layer procurement.
Buy 802.3bt on every port, not just the uplink-adjacent ones. Ports move. Projects re-purpose. A closet that was cameras last year is access points this year, and the incremental cost of bt across a 24-port unit is small next to a mid-life replacement.
Prefer 2.5G access ports even where 1G would do today. You are buying a switch for the next seven years, and Wi-Fi 7 has already made 1G access ports the default bottleneck. If the cabling is Cat5e, 2.5GBASE-T will almost always train over it at 100 m.
Insist on LLDP power negotiation and per-port priority. Negotiation keeps you from paying for phantom reservations. Priority keeps the cameras and APs powered when the budget does run short, instead of whichever device happened to boot first.
Aggregate uplinks deliberately. Add up what the floor can actually generate, not what the old gigabit APs used to. Two 10G links in a LAG, or 25G at the aggregation layer, is the difference between a fast floor and a fast floor with a queue at the door.
Three configurations, and the numbers that make them work
A twelve-AP clinic. Twelve APs at 45 W is 540 W, plus four cameras at 12 W and a door controller. Round to 620 W, add headroom, and you want roughly 800 W of budget — which means a 24-port bt switch with dual supplies, not the 370 W PoE+ unit that the price list makes so tempting. Two 10G uplinks, one to each core switch, and the job is done for a decade.
A forty-camera warehouse with six APs. Cameras at 8 to 12 W are undemanding; the APs are not. Total load lands near 700 W, but the distribution is the point: put cameras on 802.3at ports with generous budget, put the APs on bt ports with priority, and put the switch in a cabinet with a filtered fan rather than on a wall above a loading bay where the ambient hits 50 °C by noon.
An eight-AP office refit on existing Cat5e. This is where people overspend. 2.5G ports, bt on all eight, a 240 W budget, one 10G uplink. The Cat5e stays. The APs get their full profile. The bill stays sane.
Questions I get asked every week
Does every Wi-Fi 7 access point need 90 W?
No, and the assumption costs people a lot of money. Most current APs run their full profile on 802.3bt Type 3 at around 51 W available. Type 4 exists for high-power PTZ cameras, video endpoints, heaters and the small number of APs with dual radios in every band plus a second Ethernet port. Check the model, not the generation.
Can a 30 W port damage a 90 W access point?
No. The AP negotiates down and runs a reduced profile. The risk is not damage, it is a silent performance ceiling that nobody attributes to the switch.
Why does the switch refuse to power a new device when the budget shows free watts?
Class reservation. The switch has committed power to idle devices based on their class, even though actual draw is lower. LLDP negotiation or per-port scheduling is how you reclaim it.
Will a bigger PoE budget make the closet hotter?
Usually yes, and it is worth planning for. Higher delivered power means higher conversion losses. Budget for airflow the same way you budget for watts, or the extra capacity derates away in July.
Is my existing Cat5e really good enough for 2.5G and 802.3bt?
For 2.5GBASE-T at 100 m, generally yes. For 802.3bt Type 4 at full length inside a dense bundle, not comfortably — loop resistance and bundle heating are the limits, not the category printed on the jacket. I wrote a separate piece on cable heat and resistance limits if you want the arithmetic.
What if the run is longer than 100 m?
Then you have a distance problem, not a power problem, and no switch fixes it. Extenders, fibre with media converters, or a closer power source — the options are compared in this breakdown of long PoE runs.
The number worth memorising
If you take one thing from this, take the habit of reading allocated power per port on the switch and the power-mode table for the device, and comparing them before you blame anything else. That single comparison explains most of the "slow Wi-Fi after the upgrade" tickets I see, and it takes less time than opening a support case.
The hardware side of this industry is genuinely better than it was five years ago. Switches negotiate more honestly, APs report their power state more clearly, and the standards finally cover the wattages people actually deploy. What hasn't improved is the paperwork — the gap between what a port can deliver, what a device needs, and what anybody wrote down at the design stage. That gap is where projects quietly lose performance, and it is closed with arithmetic, not equipment.
If you are sizing an access layer right now and the numbers aren't landing cleanly, send me the device list with their power classes, the switch model, and a photo of the cabinet with the door open. I'll tell you where I think the shortfall is. It is the same conversation I have most weeks, and it is usually over in one reply.