Port stays dead after you fixed it
common
“Sorted the short, put a good camera on it, and the port still won't power. It's like the switch is holding a grudge.”
Likely causes
-
Port held in a PoE error or fault state that an interface bounce does not clear
35%Link comes up fine and inline power still shows fault, denied or error. A shutdown and no-shutdown changes nothing, because the PoE state machine is separate from the link state, which is exactly why this reads as unfixable.
-
Stale class reservation held after a PD was removed or swapped
20%Reserved power still counted against a port with nothing plugged into it, or a new lower-class PD still allocated the old PD's class. The budget looks full with fewer devices than it should hold.
-
Error-disable from an overload, short or detection fault with no recovery configured
20%The log shows the original overload or short, the port went err-disabled, and automatic recovery for that cause is disabled, so it will sit there indefinitely waiting for a human to clear it.
-
Per-port maximum or protection policy applied automatically after the fault
10%A static maximum or policy appears on that port and no other, and nobody set it. The platform's own protection behaviour applied it and it outlives the fault that triggered it.
-
Platform needs a PoE-specific controller reset or a reload
10%Inline power on that port, or on a whole block of ports, ignores every config change while ports on another block behave normally.
-
The original fault was never actually fixed
10%The port re-enters the same state within seconds of every clear, and the log shows a fresh overload or detection failure each time rather than a stale one. Clearing the state is what proves which of the two you have.
What to bring
- Switch CLI for inline power state, logs and error-disable status
- Vendor inline power reference for that exact model
- Known-good PD and cords
- A maintenance window if a reload becomes necessary
Steps
-
Step 1: Read the port's inline power state and the log entry that put it there
Fault, denied, err-disabled and admin-off are four different states with four different clears. Note the original cause from the log before you clear anything, because clearing destroys the evidence you will want if it comes back.
If that doesn’t do it
Cycle inline power on the port, not the interface
-
Step 2: Cycle inline power on the port specifically, not shutdown and no-shutdown
On most platforms PoE has its own per-port off and on, and that is what resets the PoE state machine. A link bounce leaves the power fault exactly where it was. Command varies by platform; look up the vendor's inline power reference for that model.
If that doesn’t do it
Clear the error-disable and check recovery
-
Step 3: Clear the error-disable state and check whether automatic recovery is configured for that cause
Many platforms ship with recovery disabled for PoE causes, so the port waits for a manual clear forever. Enabling recovery with a sensible timer turns the next occurrence into a self-healing event instead of a truck roll.
If that doesn’t do it
Check for a stale reservation
-
Step 4: Compare reserved power against what is actually connected, port by port
Reserved power on an empty port, or an old class held against a newly swapped PD, is a stale reservation. Cycling inline power on that port usually releases it and hands the budget back, which is often the real reason a budget looks exhausted (Switch out of PoE budget).
If that doesn’t do it
Remove any protection policy or static maximum applied by the fault
-
Step 5: Remove any per-port maximum or protection policy that appeared with the fault
Check the port config against what it had before the event, or against a known-good port beside it. A limit the platform applied to protect itself does not go away when the fault does.
If that doesn’t do it
Reset the PoE controller as the platform allows
-
Step 6: If nothing clears it, follow the vendor's PoE controller reset procedure; and if the port re-faults immediately, stop clearing and go find the live fault
A reload is the blunt instrument and needs a window on a live system, so exhaust the per-port options first. A port that re-faults within seconds of every clear is not latched; it is telling you the short, overload or signature problem is still out there.
If that doesn’t do it
Go to PD will not power up on the port: the port is reporting a live fault, not a stale one
References
- IEEE 802.3-2022 Clause 33
- IEEE 802.3-2022 Clause 145