Quick answer
A PoE access point, phone, or camera can appear to have a “network speed problem” when the real fault is power delivery. The reverse also happens: a device may stay powered on while its Ethernet link negotiates at 100 Mbps, accumulates CRC errors, or repeatedly flaps. These symptoms overlap in the field because the same cable carries both data and power, but they belong to different diagnostic branches.
The practical sequence is therefore link state → interface errors and physical path → PoE negotiation and power budget. This guide shows how to separate a 1 Gbps Ethernet link problem from a PoE power problem without replacing several variables at once.
Start by classifying the symptom
Do not begin with the question “Is the PoE device powered?” Begin by asking which layer is failing. If the switch reports 100 Mbps instead of 1 Gbps, or the link is down, inspect negotiation and the physical path first. If the link is stable at 1 Gbps but the endpoint reboots, is denied power, or loses service when its load changes, inspect the PoE branch separately.
| Observed symptom | First branch to inspect | Do not assume |
|---|---|---|
| 100 Mbps instead of 1 Gbps, or link down | Both port states, cable and connector path, and error counters | That the PoE budget is the cause |
| Stable 1 Gbps link but endpoint reboots | PD request, PSE allocation, consumed power, and total budget | That the Ethernet link is slow |
| CRC or input errors keep increasing | Physical path isolation with controlled substitutions | That a power shortage directly explains the CRC errors |
| PoE is refused on one port | Provisioning, class or type, budget, and port condition | That the whole switch has failed |
Step 1: Record the negotiated link state
Record the current speed, duplex, link-up and link-down events, and the time of the last change on the affected port. Check the corresponding port on the other device as well. A mismatch between the two views, inconsistent auto-negotiation settings, or repeated link flaps can point to a different problem than a link that has been stable at the wrong speed since installation.
Capture a known-good port as a reference instead of changing the cable immediately. The earlier guide to a 100 Mbps Ethernet link is useful for the initial cable, termination, port, and link-quality checks. This article adds the decision point needed when the same endpoint also uses PoE.
A 1 Gbps display means that a link has negotiated at that moment. It does not prove that the physical path will remain error-free under traffic. Likewise, a powered endpoint does not prove that its data link is healthy.
Step 2: Check whether interface errors are increasing
CRC and input-error counters are cumulative, so a nonzero value alone is not enough to diagnose the current fault. Read the counters, generate or observe traffic for a defined interval, and read them again. The important observation is whether the counters increase during the same period in which the symptom occurs.
Cisco Meraki’s CRC troubleshooting sequence recommends confirming that counters are incrementing and then isolating the switch port, patch-panel or cabling path, and speed or duplex conditions by controlled substitutions. Cisco’s interface guidance likewise treats incrementing CRC errors as a reason to investigate physical-layer elements such as cables, connectors, and transceivers, while correlating the conclusion with interface statistics.
- Save the negotiated state and counters on both ends.
- Connect the devices with a short, tested patch cable when the test setup allows it.
- Compare the original port with a known-good port, changing one condition at a time.
- Inspect the patch panel, connectors, terminations, transceiver, and installed cable route.
- Repeat the counter observation after each controlled change.
If the error counter follows the cable route, the physical path becomes more likely. If it follows the switch port, the port or its configuration becomes more likely. If it follows the endpoint, inspect the endpoint interface and its transceiver. These are working hypotheses, not proof from a single swap.
Step 3: Inspect PoE only after the link branch is recorded
When the link is stable at 1 Gbps, move to the power-delivery branch. In PoE terminology, the PSE (Power Sourcing Equipment) supplies power and the PD (Powered Device) receives it. During PoE operation, the PD requests power and the PSE applies policy and available budget when allocating it. This is a different state from Ethernet speed negotiation.
On the switch or controller, record the port’s requested power, allocated power, actual consumption, remaining available budget, PoE state, and any rejection or renegotiation message. “The device is on” is not a sufficient conclusion: an endpoint can boot and later restart when its load changes, or a port can show a power state that does not explain the event timing.
The standards anchor for Ethernet operation is the IEEE 802.3 Working Group. For a plain-language explanation of PSE, PD, Type/Class, and total PoE budget, see the existing PoE fundamentals article. The diagnostic distinction here is intentional: use those concepts to interpret measurements after the link state has been separated.
Divide the PoE branch into four checks
| PoE check | Question | Limit of the observation |
|---|---|---|
| PD detection and provisioning | Was the PD detected and was its power request accepted? | A detection failure can involve configuration or physical contact |
| Type, class, and policy | Do the endpoint requirement and port policy match? | A displayed class alone does not establish actual consumption |
| Port and switch budget | Are requested, allocated, consumed, and available power values compatible? | Total switch budget and per-port limits are separate constraints |
| Cable, contact, and heat | Could the cable route, connector, bundle, or environment affect delivery? | Measurements and site conditions are needed before assigning cause |
A port-specific PoE refusal suggests a narrower investigation than a switch-wide budget shortage. Conversely, several endpoints failing as the total load rises makes the available switch budget and allocation policy more important. Do not turn either pattern into a conclusion until the event log and power values are correlated with the failure time.
Run an experiment that does not change both problems at once
Because one PoE cable carries data and power, replacing it can make both symptoms disappear. That is useful evidence, but it does not identify which branch was fixed. Use a controlled matrix whenever possible:
- Test the same PD with separate power or a non-PoE setup, if the equipment supports it, and record link speed and error growth.
- Use a verified cable and compare the original port with a known-good port.
- With the link stable, enable or test PoE and record requested, allocated, and consumed power.
- Connect a known-good PD to the suspect port, then connect the suspect PD to a known-good port.
- After each change, record link speed, duplex, counter increase, PoE state, and event time separately.
The goal is not to replace many parts. It is to make the symptom follow one variable, or to show that two independent symptoms remain attached to different variables.
Use this field sequence from observation to decision
- Freeze the symptom: note link speed, duplex, flaps, and endpoint reboot times.
- Capture link statistics: compare CRC and input errors before and after a defined interval.
- Isolate the physical path: reduce variables with a tested cable and known-good port.
- Compare PoE values: check PD request, PSE allocation, consumption, available budget, and rejection reason.
- Cross-test: use another PD on the port and another port with the affected PD.
- Write separate conclusions: identify a link cause, a PoE cause, both causes, and anything still unverified.
Choose the next action without overclaiming
If the link negotiates at 100 Mbps and CRC counters increase, prioritize the physical route, terminations, connectors, transceiver, and port configuration. If the link remains stable at 1 Gbps but PoE is denied or the endpoint repeatedly restarts, prioritize PD compatibility, port policy, per-port limits, total switch budget, consumption changes, contact quality, and thermal conditions.
If both branches look normal, move upward to DHCP, authentication, application behavior, wireless settings, or endpoint firmware. If both branches are unstable, keep the data and power observations as separate timelines rather than replacing the switch and cable together.
A useful handoff record might say: “Port Gi1/0/8 negotiated at 100 Mbps; auto-negotiation enabled; CRC increased from 0 to 37 in ten minutes with the original patch-panel path; PD requested 15 W and PSE allocated 15 W.” That is more actionable than “the PoE network is slow.” Values that were not measured should be marked unknown, not normal.
Common mistakes to avoid
First, do not treat a 1 Gbps display as proof of perfect data quality. Continue watching the counters during the relevant traffic window. Second, do not treat visible PoE values as proof that every power problem is resolved; compare them with event timing, actual consumption, and the endpoint’s behavior. Third, do not replace the port, cable, and endpoint simultaneously. A successful bulk replacement is difficult to reproduce and difficult to hand off.
Finally, do not make a universal conclusion from cable length or category alone. The installed path includes patch cords, patch panels, connectors, terminations, and the environment. When a specific module, cable system, or deployment limit matters, consult the applicable technical documentation rather than inserting a generic number into this diagnostic sequence.
FAQ
If a PoE device is powered on, is its 1 Gbps link healthy?
No. Power delivery and Ethernet link state are separate. Verify the negotiated speed, stability, and error-counter trend.
Do CRC errors mean the PoE budget is too small?
Usually, increasing CRC errors should send you to the physical-layer branch first. Check PoE request, allocation, consumption, and available budget separately.
If changing the cable fixes the problem, is the cause confirmed?
Not necessarily. The cable change altered both data and power conditions. Repeat with a known-good port or endpoint and document which metric changed.
What should be escalated to another team?
Send link negotiation and error-counter evidence to the switching or cabling owner, and send request, allocation, consumption, budget, and PoE-event evidence to the power-delivery owner. Include test conditions and timestamps for both.
No comments:
Post a Comment