Why Sequential PoE Testing Can Hide a Simultaneous Restart Failure

Published: October 21, 2026 | Last Technically Reviewed: October 21, 2026

Quick Summary

Here is an illustrative engineering scenario, not a customer case. During installation, every access point came online. The cameras recorded, the IP phones registered, and the PoE switch showed plenty of power to spare. A few weeks later, the building lost electricity. When power returned, the switch came back, but several access points did not.

Each device had worked during installation, and the switch looked healthy at handover. Nobody had checked how the whole group would recover from the same outage.

Quick answer

A PoE installation can pass device-by-device testing and still have trouble after a shared power interruption. During recovery, the switch has to detect connected devices, classify their power needs, and allocate its available budget. Some devices may then negotiate additional power. Others may receive power but fail later during boot or network registration. Follow the power allocation and the services that need to return, not just the current wattage reading.

Why Normal PoE Readings Do Not Tell the Whole Story

A healthy PoE dashboard is useful, but it tells you what the switch is doing now. It does not reproduce the conditions at startup. By the time an engineer checks the dashboard, an AP may have finished booting and negotiated its operating power. A camera might have its infrared LEDs off. A desk phone may already have completed registration. Those conditions may change during a full restart, although not every device necessarily draws more power while booting.

One comment in a February 2024 r/networking discussion described a client deployment in which APs worked after they were installed but several did not boot following the switch's first restart. The commenter attributed the trouble to the switch's maximum PoE output. The original post has since been deleted, and the remaining comment provides no equipment inventory, logs, or repeatable measurements. It is worth reading as a field observation, not as proof of how much power a typical AP needs at startup.

The point is that an installation test cannot establish how a site will behave after losing power.

Why Consumed Power and Allocated Power Can Tell Different Stories

When a switch reports 70W of PoE consumption, what does that actually mean? It may mean the attached devices are drawing 70W at that moment. It does not necessarily mean the switch has committed only 70W from its available budget.

A switch may reserve power according to a device's class, negotiated request, or port setting. The policy varies by platform.

Cisco's PoE detection and allocation documentation, updated September 15, 2025, explains how the switch detects and classifies a powered device, checks the budget, and allocates power. Supported devices may later negotiate their requirements through CDP or LLDP. The precise sequence and allocation policy must be checked against the platform and software in use.

Detection, Allocation and Negotiation

The recovery process is easier to follow when power delivery and service startup are viewed as separate stages. This is a simplified engineering sequence, not a universal timing or port-priority rule for every PoE switch.

Power Source Available
          |
          v
PD Detection
          |
          v
Power Classification
          |
          v
Budget Allocation
          |
          v
PD Power-On
          |
          v
Further Negotiation, if supported
          |
          v
Device Initialization
          |
          v
Network Registration
          |
          v
Application Service Ready

The last step matters as much as the first. A port can be powered while its connected device is still booting or waiting to register with a controller. Each stage calls for different evidence when recovery fails.

A simple example of reserved power

This is an illustrative calculation, not a field measurement. Suppose a switch has a usable PoE budget of 250W. Eight ports are configured to reserve 30W each in Static mode. That commits 240W, leaving only 10W unallocated. The devices might be drawing just 9W each, or 72W in total, when somebody checks the dashboard. Even so, another device asking for an initial allocation of 15.4W could be denied under this assumed policy.

The example deliberately uses Static reservations. It is not a claim that every Cisco port initially receives 30W or that this is the default behavior of other manufacturers. Cisco's PoE management modes describe how Static and Auto differ, including maximum-power preallocation behavior. Its PoE guidelines also describe an initial 15.4W allocation for Class 0, 3, and 4 devices in the documented process, followed by supported negotiations for additional power.

If you are sizing a new installation from scratch, our PoE budgeting guide covers that calculation in more detail. For a restart problem, the first job is to establish what the switch has actually allocated and what remains available.

What Changes When All the Devices Recover Together?

During installation, an engineer may wait for each AP to join the controller before connecting the next. After an outage, that orderly sequence is not guaranteed.

When power returns, the switch must handle a group of connected devices seeking power and attempting to start. Detection, classification, allocation, further negotiation, and device startup do not happen in exactly the same way on every platform. Ports need not receive power at the same instant, and switches do not all use the same priority rules. Cisco describes particular allocation and denial orders for certain PSU replacement conditions, but those rules should not be presented as the universal order for a cold start.

An AP can receive power and still need to boot, reach its controller, and register. Cameras and phones have similar recovery steps. A failure later in that process may have nothing to do with the PoE budget.

What Cisco's Fast PoE and Perpetual PoE actually do

On supported Cisco C9350 platforms, Perpetual PoE maintains power during a supported switch reload or reboot. Fast PoE brings port power back sooner after the switch loses power. Neither feature guarantees an AP has rejoined its controller.

Cisco's feature history, updated September 15, 2025, identifies IOS XE 17.18.1 as the introduction release. The separate supported-model list names C9350-24P, C9350-48P, C9350-24U, C9350-48U, and C9350-48HX. That support list does not apply to every Catalyst 9000 switch.

There are configuration conditions as well. Cisco's example makes clear that Fast PoE will not take effect unless Perpetual PoE is also configured on the interface. The configuration procedure covers the required commands, while the guidelines advise preparing the ports before connecting endpoints and recommend shutting down and re-enabling the interfaces after configuration.

That same guidelines page explains a less obvious limitation. If an endpoint normally uses an LLDP-negotiated custom power level, Fast PoE initially restores power using detection and classification. The custom LLDP arrangement is re-established only after IOS and LLDP are operational again. Cisco also warns that insufficient power in a power stack may prevent these features from operating as expected. These conditions are specific to the documented platforms. We have not assigned a fixed recovery time because Cisco's pages give different indicative figures.

For acceptance testing, there are three checkpoints worth keeping separate: did the port receive power, did the device finish starting, and did its service return? A green link light answers only part of that question.

Why a Larger PSU May Still Leave You With a Small Budget

Before ordering a higher-capacity switch, check whether the installed power source is recognized and configured correctly. Adapter rating, recognized input mode, usable PoE output, and remaining available power are not interchangeable figures.

Two separate September 2026 Ubiquiti discussions illustrate the point. In one thread, the owner of a UniFi Flex 2.5G 8 PoE switch reported using a 210W adapter while seeing only a 46W PoE budget. After changing the external power adapter setting in the desktop web interface, the owner confirmed a 196W budget and said the relevant option had not appeared in their mobile app.

A different owner described a similar experience in another thread. That person also said that selecting the adapter option on a laptop resolved the issue. A separate commenter in the second discussion mentioned 196W. They are separate reports and do not establish a firmware-wide defect.

The manufacturer supplies the firmer reference point. Ubiquiti's specification lists up to 196W of PoE output when powered by the 210W AC adapter, and 46W when powered through the stated PoE++ input option. The 210W adapter rating is not the available PoE output.

For a switch showing an unexpectedly small budget, check the PSU part number, supported input modes, what the switch reports as its recognized source, the firmware version, any power-related alerts, and the current port allocations. Those checks can save a needless hardware purchase.

When an AP Has Power but Still Will Not Come Online

An AP that never lights up is a different problem from an AP that receives power but keeps restarting. An AP that has fully booted but cannot reach its controller is different again. They can look similar to somebody standing beneath the ceiling, but they require different checks.

A September 2026 r/networking discussion provides a good example of why the distinction matters. An engineer was moving from Aruba 200-series to 600-series APs. At one location, APs would not finish starting when connected to several tested 60W injectors, while an older 30W injector let the new AP operate in a reduced-power mode. The engineer said that both a short patch cable and the longer run had been checked with a Fluke tester. In a follow-up, the author clarified that the AP did receive power from the 60W injector but kept blinking and did not finish booting.

The root cause was never established. The case cannot prove excessive startup draw, a defective injector, or faulty cabling.

The meaning of restricted power also depends on the AP. In a July 2025 HPE community discussion, an AP-635 user reported that the Power Restricted flag cleared after enabling Intelligent Power Management. An HPE Aruba product management representative explained that, for the particular Class 4 setup with IPM disabled, the restriction was the USB port being unavailable. The representative did not attribute the reported Wi-Fi performance problem to that status.

Do not assume that a restricted-power warning means reduced radio performance. Check the exact model, source, negotiated power, software version, IPM configuration, and the features actually affected. HPE's AP power documentation is a starting point, but the model's own requirements are decisive.

Where the evidence stops

This article draws on public practitioner reports, manufacturer documentation, and our own troubleshooting framework. Community observations do not by themselves establish root cause. Vendor documentation describes supported behavior, not successful testing at a particular site. The framework below is ours, not a Cisco or HPE method.

First-party lab evidence: None claimed. Network-Switch.com has not presented a controlled NSComm restart experiment, port-level logs, or measured recovery times for these scenarios. The opening is illustrative, the 250W example is an illustrative calculation, and the Aruba injector incident remains unresolved.

VLAN Separation Does Not Remove Shared PoE Failure Domains

Separate camera, AP, and voice VLANs can help with traffic control, but they do not separate electrical supplies.

Imagine that the cameras and APs connect to the same PoE switch. They depend on the same chassis and often on the same PSU, PoE power pool, and upstream UPS. One failed power source or a mismanaged shared budget can affect both groups, even though their network traffic never crosses VLAN boundaries.

Camera VLAN ----+
               |
AP VLAN --------+---- Shared PoE Switch
               |            |
Phone VLAN -----+         Shared PSU
                            |
                        Common UPS
                            |
                      Common AC Source

This simplified diagram shows a shared electrical dependency, not a claim that every network uses this arrangement. Different VLANs do not isolate the switch's power pool or its upstream supply.

Two switches connected to the same PDU can still go down together. The useful question is not how many boxes are installed. It is which failures the design can tolerate without losing the services that matter.

How to Check Recovery Before You Sign Off the Installation

The first real outage is a poor time to discover an incomplete installation test. Start by recording the equipment and expected behavior.

We use five areas to organize the investigation. Source covers AC supply, PSU, UPS, PDU, and the power mode recognized by the switch. Allocation covers detection, classification, reservations, port priorities, and denials. Delivery covers the physical link, connectors, policing, and unstable power. Device covers boot completion, firmware, and any restricted operating mode. Service covers what users and systems actually need: an AP accepting clients, a camera recording, or a phone registered to call control.

This Five-Layer PoE Recovery Check is our editorial framework, not a vendor method or a completed field test.

A practical recovery acceptance test

1. Record the baseline. Note the exact switch model and software, installed and recognized PSU, usable PoE budget, allocations and measured draw per port, PD models and classes, and the operational state of each service. Save logs before testing.
2. Watch devices start one at a time. Record whether power is granted and when each endpoint finishes booting and becomes usable. A note saying "online" is not enough unless you define what online means for that device.
3. Arrange a controlled shared recovery. Use a lab or an authorized maintenance window with a rollback plan. Restore power to the relevant failure domain and capture the sequence. Do not interrupt a live production network without approval.
4. Examine the power events. Look for denied allocations, retries, changed negotiated limits, power cycling, and warning messages. Record the time of each event rather than relying on memory afterward.
5. Confirm the services. Make sure APs are registered and serving clients, cameras have resumed recording, and IP phones can register and place calls. Record the elapsed time to each service state.
6. Compare the results. Look at sequential startup and shared recovery side by side. Identify the first point of failure before deciding whether to adjust settings, replace a PSU, or change the access-layer design.

A software reload, a PoE port reset, and the loss and return of AC input are not equivalent tests. Features such as Perpetual PoE can preserve power during some reload events. One successful cold start does not cover every PSU or UPS failure.

What to check before replacing equipment

For a Cisco, Huawei, H3C, Ruijie, or NSComm installation, start with the exact switch and PD models. Verify the available PSU options, total usable budget, per-port limits, supported classification and negotiation, and any power-priority settings. Ask what the device does after a software reload, an AC interruption, or a loss of PSU capacity. Check whether a restricted-power AP can still provide all the functions required at that site. Finally, map the UPS, PDU, and other shared electrical dependencies.

Do not apply Cisco's power-allocation behavior to another vendor without documentation. Fix an unrecognized adapter before replacing hardware. If power is stable but the AP cannot register, investigate the network path. Change the PSU or power design only when the evidence supports it.