ArubaOS-CX PoE Configuration and Power Budget

PoE failures are rarely cable problems. They are budget problems: the switch promised more power than the power supplies can deliver, and the moment a second access point comes online the ports that were powered on first stay up while the newest one never gets power. ArubaOS-CX has a well-defined priority and allocation model, and understanding it lets you decide which devices are shed and when. This article covers the allocation methods, the priority hierarchy, and how to verify the budget before and after deployment.

How AOS-CX allocates power

Two allocation methods are available, and the switch defaults to allocation by usage:

• By device usage (default) — the PSE allocates the LLDP-negotiated power when LLDP exchange occurs, otherwise the actual instantaneous draw. Unused allocation is re-purposed back into the budget, so a device drawing less than its class allows frees headroom for other ports.
• By class — the PSE reserves the full class allocation. A Class 6 device reserves at least 60 W, a Class 4 device at least 30 W, whether or not it draws that much. Predictable, and conservative on capacity.

The recommendation follows directly: use allocation by usage where the devices implement LLDP power negotiation, and by class where you need a guaranteed, deterministic budget for every port because you cannot rely on negotiation.

switch(config-if)# power-over-ethernet allocate-by usage
switch(config-if)# power-over-ethernet allocate-by class
switch(config-if)# power-over-ethernet assigned-class 6

Priority: what gets shed first

When demand exceeds the budget, ports are powered in order of priority. Ports with equal PoE priority are ranked by module power-priority, and where those are also equal, lower numbered ports win.

switch(config-if)# interface 1/1/5
switch(config-if)# power-over-ethernet priority critical
switch(config-if)# power-over-ethernet priority high
switch(config-if)# power-over-ethernet priority low      ! default

! Chassis: set module power-priority so a module's ports win ties
switch(config)# power-over-ethernet module 1 priority 50
switch(config)# power-over-ethernet module 4 priority 254

Assign priority by consequence rather than by port number. Critical goes to life-safety devices and the access switches' own management paths; high to core wireless and cameras; low to desk phones and convenience devices. A useful convention on chassis switches is to give line modules in the building with the most critical services a higher module priority, so ties resolve in the right direction.

Global controls

switch(config)# power-over-ethernet threshold 80
switch(config)# power-over-ethernet trap
switch(config-slot)# power-over-ethernet always-on
switch(config-if)# power-over-ethernet quick-poe 5
switch(config-if)# power-over-ethernet pre-std-detect
switch(config-if)# power-over-ethernet assigned-class 4

Note the configuration context, which the documentation is explicit about: all PoE commands except quick-poe, threshold configuration and always-on are entered in the interface context. Threshold and power-over-ethernet always-on are global or slot level, and misplaced commands fail silently. The threshold command is worth setting: it generates a trap when consumption crosses a percentage, giving you warning before a switch starts refusing to power ports.

Verification

switch# show power-over-ethernet
switch# show power-over-ethernet brief
switch# show power-over-ethernet interface 1/1/5
switch# show power-over-ethernet 1/1/5
switch# show lldp info remote-device 1/1/5
switch# show interface 1/1/5

show power-over-ethernet gives the chassis view: total budget, allocated power, and remaining headroom. The per-interface view shows the negotiated class, the priority, and the actual allocation, which is where you catch the mismatch between what the device requested and what the switch granted. Where the summary reports the class-based value rather than the LLDP-negotiated value, read the detail view for that interface — the summary rounds in ways that hide the real number.

Sizing the budget properly

budget_required = sum(per_port_allocation x ports_in_use) + margin

# 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

Two warnings about vendor datasheets. The "PoE budget" figure usually describes the total across the chassis and is often quoted for one specific power supply configuration — a 48-port switch advertised at 1440 W may deliver far less with the smaller PSU option. And PSU redundancy interacts with PoE: losing one power supply in a two-PSU switch can drop ports beyond the remaining budget, taking access points offline at exactly the moment the network is needed most. Size for the single-PSU case if you want the redundancy to mean anything.

The other side of the PoE budget is the standards question — which class a device may legally request and what the PD is guaranteed to receive. That arithmetic is covered in ArubaOS-CX access vs trunk port templates for the general case and 华为交换机 PoE 供电管理 for Huawei platforms, both useful when an estate spans vendors.

原文链接：https://arubanetworking.hpe.com/techdocs/hardware/accessories/Power_Over_Ethernet_Guide-AOS-CX.pdf