12.4 Physical-Layer Troubleshooting
Key Takeaways
Physical-layer faults show up as links that stay down, flap, run at a lower speed than planned, log CRC/FCS errors, or deliver too little PoE.
diag cable-diagnostic test <port>runs a cable test on supported copper ports (it briefly drops the link) anddiag cable-diagnostic show <port>reports each pair's status and approximate distance.For fiber,
show interface domandshow interface <port> transceiver detailcompare receive power with alarm and warning thresholds to separate dirty or damaged fiber from configuration faults.An unsupported transceiver stays disabled unless
allow-unsupported-transceiveris configured, and a multimode optic on single-mode fiber (or the reverse) will not link reliably.PoE problems are checked with
show power-over-ethernet <port>: budget exhaustion, low priority during oversubscription, or a class limit can leave a device unpowered or restricted.
12.4 Physical-Layer Troubleshooting
Quick Summary: Layer 1 is where the bottom-up method starts and where many campus problems end: a damaged patch cord, a cable that is too long for multi-gigabit speed, a dirty fiber connector, the wrong optic, or a switch that has run out of PoE. AOS-CX gives you direct evidence for each of these: interface state and counters, transceiver diagnostics, cable tests, PoE status, and hardware health.
Symptoms That Point to Layer 1
| Symptom | Likely physical causes |
|---|---|
| Link never comes up | Unplugged or broken cable, wrong port, far-end device off, wrong or unsupported optic, fiber strands swapped |
| Link flaps up and down | Marginal cable or connector, optical power near the receiver threshold, failing NIC or optic |
| Link up at a lower speed than planned (for example 1 Gbps instead of 2.5 Gbps) | Cable category or length not good enough for the multi-gigabit rate, one bad pair, or the far end not capable |
| CRC/FCS errors increase | Damaged copper, interference, dirty or bent fiber, failing transceiver |
| Late collisions | Duplex mismatch from a hard-coded speed on one end (Section 12.2), or an over-length copper run |
| Device has no power or runs restricted | PoE budget exhausted, low PoE priority, class limit, cabling fault, or the PD needs 802.3bt but receives 802.3at |
Copper Diagnostics
Interface state and counters
Start with show interface <port>: admin state, link state, speed and duplex, and the error counters. Clear expectations help: an access port to a Wi-Fi 6E AP planned at 2.5 Gbps that shows 1 Gbps is a Layer 1 finding, even though "the link is up".
Cable test
AOS-CX includes a time-domain reflectometer (TDR) style cable test on supported copper ports (AOS-CX 10.14 CLI Guide):
switch# diag cable-diagnostic test 1/1/14
This command will cause a loss of link on the port under test and will take
several seconds to complete.
Continue (y/n)? y
switch# diag cable-diagnostic show 1/1/14
The result lists each wire pair with its status, impedance, approximate distance, and MDI mode. Use it to find an open or shorted pair or a cable much longer than the 100 m channel limit. Because the test drops the link, run it only when the port can be disrupted. Some ports, such as fiber ports, do not support it.
Speed and duplex
Leave copper ports on auto-negotiation at both ends. If one end is forced (for example speed 100-full) and the other is on auto, the auto end falls back to half duplex, and late collisions and CRC errors follow.
Fiber and Transceiver Diagnostics
- Is the optic recognized?
show interface transceiverlists the installed transceivers. AOS-CX does not enable unsupported (non-HPE) optics unlessallow-unsupported-transceiveris configured, so an unexpected "unsupported" message explains a dark port. - Is the optic right for the fiber? SR optics need multimode fiber; LR optics need single-mode. Both ends must use compatible types and wavelengths.
- Is light arriving?
show interface domorshow interface <port> transceiver detailshows transmit and receive power against alarm and warning thresholds. Very low receive power on one end usually means a dirty connector, a bad patch cord, an over-long run, or swapped transmit and receive strands. Receive power that is fine on one end and missing on the other points to a single strand. - Fix and retest: clean both connectors with proper tools, replace the patch cord with a known-good one, and check DOM again.
PoE Diagnostics
show power-over-ethernet shows the switch budget and how much is allocated and drawn; show power-over-ethernet <port> shows a port's status, class, priority, and power. Typical findings:
- Budget exhausted: total allocation has reached the available power, so new devices are not powered. Check whether the port uses
allocate-by class, which reserves full class power when a device does not negotiate through LLDP (Section 2.2). - Priority: during oversubscription, low-priority ports lose power first, and among equal priorities the higher-numbered ports go first.
- Class limit:
power-over-ethernet assigned-classmay cap the port below what the device needs. - Restricted AP: an AP that needs 802.3bt but receives 802.3at may boot with features disabled (for example its USB port). Check the AP's QuickSpecs power table.
Always-on PoE keeps devices powered through a soft reboot; quick PoE speeds power-up after a cold boot. Neither helps if the budget itself is too small.
Hardware and Environment
show environment reports fans, power supplies, and temperatures; show events shows hardware and link events with timestamps. A failing power supply in a non-redundant switch can shrink the PoE budget and drop low-priority devices.
Isolation Technique: Swap and Compare
- Compare the failing port with a working port of the same type: configuration (
show running-config interface <port>), speed, and counters. - Swap one component at a time: patch cord, then optic, then switch port, then the far-end device. If the problem moves with the component, the component is at fault. If it stays, look at the infrastructure behind it (horizontal cable or far end).
- Check both ends: many Layer 1 faults are visible only from the far side, such as missing receive light.
Record what you changed and the result, because the same evidence supports the RMA or cabling repair request.
Wireless Physical Layer
For APs, Layer 1 also includes placement and the RF path: an AP mounted above a metal duct, an external antenna pointed the wrong way, or new construction (glass, concrete, metal shelving) that changed coverage. These show up as poor signal strength and SNR at the client (Section 6.2) rather than switch-side errors.
Common Exam Traps
- "The link is up, so Layer 1 is fine." A link at the wrong speed or with climbing CRC errors is still a physical problem.
- Running a cable test during production. The test drops the link on the tested port.
- Blaming configuration for a dark fiber port. Check that the optic is supported and correct for the fiber, and that light is arriving.
A Wi-Fi 6E AP planned for 2.5 Gbps links at only 1 Gbps on its access port, with no configuration difference from working ports. Which AOS-CX action best helps identify a cabling problem on that copper run?
Raise the port's MTU to 9198 so the larger 2.5 Gbps frames can pass and the link speed rises
Enable loop-protect on the port so that the switch reports which cable pair has failed
Run diag cable-diagnostic test on the port in a maintenance window and read the pair results
Change the AP's 5 GHz channel width to 80 MHz so that it negotiates the faster uplink speed
A new 10GBASE-SR link between two buildings stays down. The switch shows the optic as recognized, and DOM shows receive power far below the low alarm threshold on one end only. What is the most likely cause?
The switch has exhausted its PoE budget and can no longer power the SFP+ optic
A problem on the fiber strand toward that end, such as a dirty connector or damaged patch cord
The two ports' native VLANs do not match, so the switches keep the optical link down
Both ends run LACP in passive mode, so neither side brings the 10 Gbps link up
Several cameras on a fully populated PoE switch lost power after a power supply failed, while the APs on ports 1/1/1-1/1/10 stayed powered. All ports use the same PoE priority. Which explanation fits AOS-CX behavior?
Cameras always lose power before APs, regardless of the PoE priority configuration
The cameras were in a different VLAN, which has a lower PoE allocation by default
Always-on PoE was disabled on the camera ports, so they lost power during the failure
The smaller budget forced shedding, and at equal priority higher-numbered ports go first
Sections you finish are checked off in the contents.