PoE Standards Explained: 802.3af, 802.3at, 802.3bt PoE++

Access points, cameras, phones and door controllers all want power over the same cable that carries their data, and the three PoE standards behind that convenience carry very different budgets. Mismatch them and you get APs that boot-loop under load, cameras that drop frames in low light, or a switch whose power supply is the quiet bottleneck for the whole floor. This guide walks through what 802.3af, 802.3at and 802.3bt actually deliver, the power classes you negotiate, and how to size a switch power budget before ordering it.

The three standards at a glance

The gap between "PSE per port" and "guaranteed at device" is cable loss, which is why the standards quote two numbers. Anything above ~60 W requires all four pairs - 4PPoE - which in turn means the cabling must be Cat 5e or better with all pairs terminated and tested.

Power classes and negotiation

! Catalyst / IOS XE: inspect what the switch negotiated
show power inline
show power inline GigabitEthernet1/0/5 detail
show power inline police
show environment power          ! chassis power supply budget

! ArubaOS-CX: per-interface PoE detail and class
show power-over-ethernet
show power-over-ethernet brief
show power-over-ethernet interface 1/1/5

There are two mechanisms. The physical layer "class" method (hardware classification) signals the class with a resistor and settles within milliseconds; LLDP power negotiation is a protocol conversation that can report actual consumption and let the PSE allocate accordingly. Modern APs use LLDP to request their real draw, which is why show power inline sometimes reports the class-based value instead of the LLDP value - read the detail view, not just the summary.

Sizing the power budget

budget_required = sum(per_port_allocation x ports_in_use) + margin
# example: 24 APs requesting 25.5 W each
#   25.5 W x 24 = 612 W of PoE demand
#   a 48-port switch with a 740 W PoE budget leaves ~128 W of headroom

Vendor "PoE budget" numbers usually describe the total across the chassis, not per port, and are often quoted for one power supply configuration. If your switches run on one PSU instead of two, or are powered by a smaller PSU, re-check the budget in the datasheet - a 48-port switch advertised at 1440 W may only offer 600 W in the configuration you are ordering. Redundancy matters too: losing one PSU in a 2-PSU switch can drop ports beyond the remaining budget, taking APs offline exactly when the network needs them.

Power priority: what to shed first

Switch(config)# interface GigabitEthernet1/0/5
Switch(config-if)# power inline auto
Switch(config-if)# power inline port priority high
Switch(config-if)# power inline police action log     ! log rather than err-disable
Switch(config-if)# power inline consumption 15400 mW  ! static allocation

Priority decides which ports keep power when demand exceeds the budget. Assign critical to the uplink switches' own management links and life-safety devices, high to core wireless and cameras, and default to desk phones and convenience devices. Also set police action log during rollout: the default err-disable behaviour punishes you for a mis-sized budget by shutting the port, which looks exactly like a broken cable.

Detection and classification: the 25 kohm handshake

Nothing gets powered until the switch has proved there is a valid powered device (PD) on the far end of the cable. A PSE first applies a low detection voltage – roughly 2.7 V to 10.1 V – and looks for the 25 kohm signature resistor that every compliant PD presents across the pairs. The accepted window is about 23.75 kohm to 26.25 kohm, which leaves margin for cable resistance and temperature drift. An open pair, a short, or a plain data-only NIC presents something well outside that window and is ignored.

Detection is followed by classification. With 802.3af and 802.3at the PSE raises the line to a class voltage (about 15.5–20.5 V) and measures the current the PD draws to map it onto class 0 to 4. 802.3at added a second classification event, so a Type 2 PSE can tell a genuine PoE+ PD (two events, class 4) from an older Type 1 device (one event) — that is the difference between reserving 30 W and reserving 15.4 W of budget. 802.3bt extends the same idea with additional class events and new classes 5 to 8, plus Autoclass: the PSE measures actual peak consumption for a short window after power-up and allocates that figure, rounded up, instead of the class ceiling. Autoclass is why two nominally identical APs can show different allocations on different ports.

Classes 0 to 4 exist in both Type 1/2 and Type 3/4 forms, but the class number alone does not tell you which standard is in play: a class 4 PD on a Type 1 PSE is still limited to 15.4 W. Read the negotiated power, not the class, when you audit a switch.

4PPoE: why anything above 30 W needs all four pairs

Power over a cable is limited by current, not by voltage. Two-pair PoE uses pairs 1-2 and 3-6 as the current path, and 802.3bt adds the spare pairs 4-5 and 7-8 so the same conductor gauge can carry roughly twice the power. Type 3 caps the current at 600 mA per pair and Type 4 raises it to 960 mA per pair, which is what makes 60 W and 90 W PSE ports possible over standard structured cabling with a real (if reduced) voltage at the PD.

The practical consequences are worth spelling out before a rollout:

• All four pairs must be terminated and tested. A run where only pairs 1-2 and 3-6 are punched down will pass basic link testing and then fail at 60 W.
• Cat 5e is the floor; Cat 6 or 6A is the sensible default for new 4PPoE runs because it has lower DC resistance and behaves better thermally in bundles.
• Bundled runs derate. A 100-cable bundle carrying 60 W each heats the middle of the bundle noticeably, and copper resistance rises with temperature — the loss you calculated on paper is optimistic.
• Connectors and patch cords matter. Cheap 28 or 30 AWG stranded patch leads add resistance and voltage drop exactly where the budget is tightest. Prefer 24 AWG solid patch leads on high-power runs.
• Plan for lightning and surge protection outdoors, and remember that surge protectors on PoE runs must be rated for the current and for 4-pair operation.

Reading LLDP power negotiation

Physical-layer classification is a blunt instrument: it tells the PSE a ceiling, not the truth. LLDP power negotiation (the 802.3at Power Via MDI TLV, extended by 802.3bt) lets the PD advertise how much it wants and how much it is drawing, and lets the PSE reply with the amount it has granted. A modern access point typically negotiates several watts below its class number, which is often the difference between fitting 24 APs on a 740 W switch and not fitting them. The mechanics of the TLV exchange are covered in PoE and LLDP.

! Catalyst / IOS XE: see both the class value and the negotiated value
show power inline
show power inline GigabitEthernet1/0/5 detail
show lldp neighbors GigabitEthernet1/0/5 detail   ! PD requested / allocated power

! Make sure the switch actually transmits the power TLVs
lldp tlv-select power-management
interface GigabitEthernet1/0/5
 lldp transmit
 lldp receive

If show power inline reports a flat 15.4 W or 30 W on every port regardless of device type, LLDP is not negotiating and you are budgeting against class ceilings. That is not a fault, but it wastes budget and hides the real consumption figures you need for capacity planning.

Fast PoE and Perpetual PoE: surviving a switch reload

Two related features cut the downtime caused by a switch reload. Fast PoE stores port power state and allocation in persistent storage and restores it during boot, so an AP returns in seconds instead of waiting for the switch to finish booting, run detection and renegotiate. Perpetual PoE keeps power flowing to the PD while the switch itself is reloading, holding the previous allocation for as long as the PoE controller is alive. Both are typical on modern campus switches, usually on by default or enabled with a global command — check your platform guide for the exact syntax, then prove it in a lab by reloading a switch and timing the AP's return to service. For phones on a voice VLAN the same feature turns a five-minute outage into a 30-second one; see the voice VLAN configuration guide for the phone-side half of that design.

Verifying PoE on non-Cisco platforms

! Juniper Junos
show poe interface
show poe interface ge-0/0/0.0 detail
show poe controller

! Huawei VRP
display poe power
display poe interface
display poe interface power

! Aruba AOS-CX
show power-over-ethernet brief
show power-over-ethernet interface 1/1/5

! Dell OS10
show power inline
show power inline interface ethernet 1/1/5

Field names differ, but the information you need is the same everywhere: negotiated class, allocated watts, measured milliamps and port state. Where a platform reports only the class, note it in the build documentation and add at least 10 percent manual margin when sizing the budget.

Troubleshooting a PD that will not power up

Work through this list in order — most "dead" PoE ports are budget or cable problems, not failed hardware.

1. Read the port state. off with no class means no valid signature: cable, patch lead or the device. deny means the PSE refused because of budget or priority. faulty or err-disable means the port was shut after an overload or a police action.
2. Compare the detected class with the device specification. A class 0 reading on a device that should be class 4 points at the cable or the PD's front end.
3. Check the budget. The summary view shows total and used power per module; if it is at the limit, the port stays in deny and no amount of cable work will help.
4. Swap the patch lead and try a port on a different line card — this isolates port, cable and device in a single step.
5. Test the device on a standalone injector or a known-good port. If it powers up there, the problem is on your side.
6. Check length and termination, especially on 4PPoE. Beyond 90 m of copper plus patch leads, the voltage at the PD can fall below the minimum and the device browns out under load — which looks like a boot loop rather than a power failure.
7. Watch the log while the PD is connected. PoE events are syslogged and normally name the reason a port was denied or shut.

Monitoring and alerting on PoE

PoE is invisible until it breaks, so put it into monitoring on day one. The POWER-ETHERNET-MIB exposes per-port detection status, class, priority and allocated power in pethPsePortTable (OID 1.3.6.1.2.1.105.1.1.1), and chassis consumption and budget in pethMainPseTable. Export those with an SNMP exporter and alert on three things: chassis consumption above 80 percent of budget, any port in deny or fault state, and a step change in consumption on a port that should be static. The SNMP exporter setup guide covers the plumbing.

Budgeting PoE per floor, not per switch

A single datasheet number is not a design. Wi-Fi 7 access points are the biggest consumer in most campus racks: tri-band models with several radios routinely negotiate 25 W to 35 W, and consumption climbs when the radios are busy — the Wi-Fi 7 MLO deployment guide covers what those radios do with the power. Add PTZ cameras with heaters (up to 60 W in cold weather), PoE door controllers, PoE lighting and 6 W to 13 W desk phones, and a 48-port switch with a 740 W budget can run dry with only 24 ports in use. Budget per floor, sum the floors against the closet's switch capacity, and keep a documented 20 percent reserve for the next AP refresh.

Deployment checklist

Terminate all four pairs on every run above 30 W, test the cable after termination, verify the class in the switch detail output for each AP/camera type, and record the actual consumption per port for a week before declaring the budget safe. Then monitor it - a new AP model with a bigger radio can silently push a floor over its budget months after the rollout. Related reading: Aruba AOS-CX initial configuration, voice VLAN for IP phones, transceiver types and compatibility and switch selection criteria.

原文链接：https://en.wikipedia.org/wiki/Power_over_Ethernet