Home / Notes / Ethernet Port Physically Down

NOTES · INTERFACE / OPTICS TROUBLESHOOTING

Ethernet Port Physically Down: Cable, Optics and Hardware Diagnosis

current state : DOWN tells you nothing about why. It could be a human shutdown, a hardware fault, a bad cable or fiber, a mismatched optic, or the room the switch is sitting in — six different root causes, each with its own check and its own fix. This is the order that separates them fast, with the exact display commands and real light-power numbers.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Physical DOWN Has Six Different Root Causes, Not One

The temptation is to reach for the same fix every time — reseat the cable, swap the module. That works often enough to be dangerous, because it also hides which of six causes was actually at play.

An Ethernet interface stays Up under the most basic condition a switch has to meet: it can send and receive frames. When it can't, the indicator light goes dark, current state reads DOWN, and a log entry like linkDown_active fires. From there the possible causes split cleanly into six branches — someone shut it down or triggered a protection mechanism, the device's own hardware failed, the cable or fiber itself is faulty, the optic and the fiber it's paired with don't match, the connection method was wrong, or the environment around the equipment is the problem. Each branch has its own diagnostic command, and guessing which one applies wastes exactly the kind of time this note is meant to save.

What follows is the check for each of the six branches with the exact commands to run, four real field cases pulled from actual maintenance records, and the FAQ answers that come up whenever a port refuses to come Up.

Six Branches, One Decision Tree

Start with display interface and let the current state field and any ERROR DOWN reason send you down the right branch — not a hunch.

Diagram labels are kept in English for engineering clarity.

In practice, branches 3 (medium), 4 (usage) and 6 (the optic itself) overlap heavily — a light-power reading outside its threshold can mean a bad fiber, a mismatched module, or a failing transceiver, and display interface transceiver verbose is the one command that helps you tell them apart. That's why the optics check gets its own detailed walkthrough below.

Working Through Each Branch

Five checks, five different commands — and the ERROR DOWN reason table that saves you from guessing at branch 1.

Branch 1 — Human Factors: Shutdown and Protection Mechanisms

If current state reads Administratively down, someone (or something) told the port to stop — the question is who, and undo shutdown may not even be the right answer.

Run display interface and read current state literally. Administratively down means a shutdown command is active — run undo shutdown if that's genuinely not intended.
If current state instead reads ERROR DOWN (down-cause), the device shut the port down itself in response to a specific triggering event — the down-cause value names exactly which one: bpdu-protection (a BPDU arrived on an edge port with BPDU protection enabled), storm-control (broadcast/multicast/unknown-unicast rate exceeded the configured high threshold with the error-down action), loopback-detect (the port received its own loopback-detection frame back), mac-address-flapping, link-flap (repeated Up/Down oscillation tripped the flap-protection threshold), crc-statistics, and several stack/M-LAG-specific causes.
In the diagnose view, display system internal device port interface-name shows a Port enable related check table — any row where IsPass isn't YES is why the port genuinely can't come Up, down to whether shutdown is configured, whether the device is mid-upgrade, or whether the forwarding engine instance is up.
Recover manually with shutdown then undo shutdown, or restart the interface — or configure error-down auto-recovery cause down-cause interval interval-value so the specific cause clears itself after the fault condition passes.

<HUAWEI> display logbuffer | include DOWN
Sep 19 2022 08:51:53 HUAWEI %%01IFNET/2/linkDown_active(l):CID=0x807a0427-
alarmID=0x08520003;The interface status changes. (ifName=10GE1/0/1, AdminStatus=UP,
OperStatus=DOWN, Reason=Interface physical link is down, mainIfname=10GE1/0/1)

<HUAWEI> display interface 10GE 1/0/1
10GE1/0/1 current state : DOWN (ifindex: 11)
Line protocol current state : DOWN

[HUAWEI-diagnose] display system internal device port 10ge1/0/1
Port enable related check:
--------------------------------------------------------------------------------
DevType     AttrName        AttrValue    ExpectValue    IsPass
--------------------------------------------------------------------------------
port        isshut          0x1          == 1           YES
port        portlfeisup     0x1          == 1           YES
port        triggerShut     0x1          == 1           YES
port        phyportisshut   0x1          == 1           YES
--------------------------------------------------------------------------------
// any row where IsPass is not YES tells you exactly why the port won't come Up

[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] error-down auto-recovery cause link-flap interval 300

Branch 2 — Device Hardware Faults

Whether it's a batch of ports or a single one tells you whether to suspect the board or just that one port.

Run display interface brief to see all interfaces at once. Multiple ports going DOWN together, all connecting to different remote devices, points toward a local board fault or the remote devices' own instability (a peer mid-failover, sleep, or reboot); a single port going DOWN points at that port specifically.
For a suspect single port, check the physical slot for bent or misaligned metal contacts first, then run loopback internal on that interface. If current state comes back UP under internal loopback, the port's internal path is fine and there's no hardware fault; if it stays DOWN, there's a genuine internal hardware problem.
For a batch fault on one board with otherwise-healthy remote peers, reset slot slot-id to reset the board; if the fault persists, the board needs replacing. For a batch fault where the peer devices are themselves flapping (failover, reboot), that's often normal transient behavior that clears once the peer stabilizes — but confirm the peer isn't rebooting because of its own loop or attack problem first.

<HUAWEI> display interface brief
Interface         PHY     Protocol InUti OutUti inErrors outErrors
10GE1/0/1          up     down      0.01% 0.01%        0      0
10GE1/0/3          down     down        0%   0%        0      0

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] loopback internal
Info: Ensure that the port is not in default VLAN 1 to prevent traffic loops.
[HUAWEI-10GE1/0/1] display this interface
10GE1/0/1 current state : UP (ifindex: 23)
// came UP under internal loopback -- no hardware fault, problem is external

Branch 3 — Transmission Medium: Copper Cable or Fiber

Copper and fiber fail in different ways and need different tools — virtual-cable-test for one, light-power thresholds for the other.

For copper: confirm both ends use the same cable, that patch-panel jumpers are correct, and that cable length is under the 100m Ethernet standard limit — GE ports need Cat5e or better to negotiate to 1000M at all.
Run virtual-cable-test on the interface. Pair state Ok on all four pairs means the cabling itself is sound; Open or Short on any pair means it's time to swap the cable.
For fiber: confirm the transceiver is Huawei-certified first — a non-certified optic's alarm shows directly in the log, and its reliability under warranty isn't guaranteed.
Run display interface transceiver verbose and compare Current RX Power / Current TX Power against the module's own Default RX/TX Power High/Low Threshold fields. A reading inside both thresholds and non-zero Voltage/Bias Current rules the optic itself out as the fault.

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] virtual-cable-test
Warning: The command will stop service for a while, Continue?[Y/N] y
Pair A state: Ok
Pair B state: Ok
Pair C state: Ok
Pair D state: Ok
// any pair reporting Open or Short instead of Ok -> replace the cable

<HUAWEI> display interface 10ge1/0/2 transceiver verbose
Diagnostic information:
   Voltage (V)                    :3.27
   Bias Current (mA)              :89.76
   Bias High Threshold (mA)       :130.00
   Bias Low Threshold (mA)        :1.00
   Current RX Power (dBm)         :-3.26
   Default RX Power High Threshold (dBm) :-0.50
   Default RX Power Low Threshold (dBm)  :-23.98
   Current TX Power (dBm)         :0.71
   Default TX Power High Threshold (dBm) :5.90
   Default TX Power Low Threshold (dBm)  :-5.90
// current Rx/Tx readings sitting inside their thresholds -> the optic is not the fault

Branch 4 — Connection Method: Mismatched Optic, Fiber Type or Wiring

A perfectly good transceiver and a perfectly good fiber can still refuse to link up if they're the wrong pair for each other.

Run display device to confirm the exact board/slot in question, then cross-check the transceiver type against the interface and against the fiber it's paired with — single-mode optics need single-mode fiber, multimode needs multimode; mixing them is a common install-time mistake.
Run display interface transceiver on both ends and compare Transceiver Type, Wavelength and Transfer Distance side by side — these have to be compatible on both ends, not just individually valid.
Confirm the fiber pair is actually crossed: one end's TX has to connect to the other end's RX and vice versa. This sounds obvious until a jumper panel is involved and the physical run is longer than the whiteboard diagram.
For single-fiber bidirectional (BiDi) optics specifically, the two ends must use complementary wavelengths — one end TX1310/RX1490, the other TX1490/RX1310 — not the same wavelength pair on both sides.

<HUAWEI> display interface 10ge1/0/2 transceiver
10GE1/0/2 transceiver information:
Common information:
 Transceiver Type          :10GBASE_USR
 Connector Type            :LC
 Wavelength (nm)           :850
 Transfer Distance (m)     :20(62.5um/125um OM1) 50(50um/125um OM2)
Alarm information:
 Non-Huawei-certified transceiver
// compare Transceiver Type / Wavelength / Transfer Distance against the far end,
// not just against the local interface spec

Branch 5 — Environmental Factors

Only worth checking once the first four branches come back clean — but when they do, this is usually the answer.

Check machine-room temperature and humidity against the equipment's rated operating range — typically 0-45°C and 5%-95% relative humidity, non-condensing. Persistent readings outside that range point at HVAC or dehumidification, not the port itself.
Check cable routing: power cabling and data cabling run in parallel with no separation is a common source of interference, and can also mean physical wear where cable trays flex or rub over time.

Four Field Cases

Each one looked identical at first glance — a port stuck DOWN — and each one turned out to be a different branch of the tree above.

1. A Non-Certified Transceiver Survives a Reboot in the Wrong Mode

SYMPTOMAfter an unplanned power loss and reboot, several interfaces stayed physically DOWN with no configuration changes anywhere in the recent history, and the peer devices showed no reboot or failover of their own.

CAUSEdisplay interface showed the port still in Port Mode: COMMON FIBER even though the on-site engineer confirmed this interface actually used a Combo port wired for copper. display interface transceiver verbose confirmed the installed optic had no HUAWEI vendor identification — a non-certified transceiver. After the reboot, the port failed to correctly detect which physical medium was actually present and got stuck reporting fiber mode instead of switching to copper mode, so it never came Up.

FIXReseating the optic didn't resolve it. Replacing it with a Huawei-certified transceiver did — Port Mode correctly read COMMON COPPER afterward and the interface came Up immediately. Non-certified optics aren't validated against the device's own firmware behavior, and this kind of edge-case mode-detection failure is exactly the risk that certification is meant to rule out.

<HUAWEI> display interface 10ge1/0/2
10GE1/0/2 current state : DOWN
Port Mode: COMMON FIBER//should have been COMMON COPPER for this build

<HUAWEI> display interface 10ge1/0/2 transceiver verbose
Vendor Name                     :*********
Alarm information: Non-Huawei-certified transceiver

// after replacing with a certified transceiver:
<HUAWEI> display interface 10ge1/0/2
10GE1/0/2 current state : UP
Port Mode: COMMON COPPER//correct mode, port came Up

2. Multimode Fiber Distance Exceeds What OM3 Can Reliably Carry

SYMPTOMA 10GE optical link running 210 meters on multimode fiber and multimode optics flapped physically Up and Down repeatedly, with matching link-state log entries on both ends and no configuration mismatch anywhere.

CAUSEdisplay interface transceiver verbose confirmed the transceiver was Huawei-certified with receive and transmit power both sitting inside their thresholds — the optic itself wasn't at fault. The Transfer Distance field on the transceiver showed multimode support ratings that vary by fiber grade: roughly 300m on OM3 fiber but 400m on OM4. At 210 meters the link was within OM4's range but pushing the edge of what the fiber actually installed (non-OM4 multimode) could reliably carry, and chromatic dispersion at that distance was enough to cause intermittent link loss.

FIXMatch multimode optics with OM4-grade fiber specifically when the run approaches 300m-plus, rather than assuming any multimode-to-multimode pairing is automatically fine — the match rule (single-mode optic with single-mode fiber, multimode with multimode) is necessary but not sufficient once distance gets long. Replacing the fiber with OM4 resolved the flapping.

<HUAWEI> display interface 10ge1/0/1 transceiver verbose
Transceiver Type:10GBASE_SR_SFP
Transfer Distance(m):300(50um/125um OM3),400(50um/125um OM4)//OM4 carries furthest
Vendor Name:HUAWEI// certified optic, ruled out as the fault
Current RX Power (dBm)  :-2.45//within threshold
Current TX Power (dBm)  :-1.86//within threshold
// optic and power both clean -> look at fiber grade vs. the 210m run length

3. Cross-Vendor Auto-Negotiation Fails on Copper

SYMPTOMA copper link to a different vendor's equipment wouldn't come Up, while the same physical cabling and port worked correctly when temporarily reconnected to a different, same-vendor device.

CAUSEdisplay interface showed the port itself healthy — physically UP internally, correct speed and duplex, Negotiation: ENABLE — with nothing in the configuration or cabling that explained the failure against this specific peer. Auto-negotiation implementations aren't identical across every vendor, and this pairing simply didn't agree on parameters during negotiation, even though each side's configuration was individually valid.

FIXConfigure negotiation disable on the Huawei-side interface to force non-auto-negotiation mode. The peer came Up immediately. If forcing off auto-negotiation alone isn't enough in a similar case, follow up by explicitly setting speed to match the peer, since a non-negotiated port also needs its rate configured rather than assumed.

<HUAWEI> display interface 10ge 1/0/1
10GE1/0/1 current state : UP
Duplex: FULL,Negotiation: ENABLE//auto-negotiation is on, but the peer still won't link

<HUAWEI> system-view
[HUAWEI] interface 10ge 1/0/1
[HUAWEI-10GE1/0/1] negotiation disable
// peer interface came Up immediately after switching off auto-negotiation

4. A Failing Cable Shows Up as Climbing CRC Errors, Not a Down Port

SYMPTOMThe port itself stayed physically UP the whole time, but the interface's CRC error counter kept climbing on every check — a slower-burning fault than an outright DOWN, but one that degrades throughput the same way.

CAUSEA degraded cable — internal wear, a marginal connector, or physical damage along the run — corrupts a fraction of frames in transit without taking the link down outright. Each corrupted frame fails its frame check sequence and increments the CRC counter, which is a reliable early sign of a physical-layer problem even while the port shows Up.

FIXTreat a climbing CRC counter as a physical-layer symptom first, before looking anywhere else. Replacing the cable resolved this case; virtual-cable-test is worth running on any interface with a growing CRC count even if current state still reads UP.

<HUAWEI> display this interface
10GE1/0/1 current state : UP
CRC          :4782,Giants           :0
// port shows UP, but CRC count keeps growing on repeated checks ->
// treat as a physical-layer / cable fault even without a DOWN state

Five Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

How do I actually check a light module's receive and transmit power?

Run display interface transceiver verbose for the full diagnostic block, or display interface transceiver brief for just the power figures. Current RX Power and Current TX Power are the readings that matter; compare them against that same module's own Default RX/TX Power High/Low Threshold fields, which travel with the transceiver rather than being a fixed number across all modules.

Both ends are GE ports with auto-negotiation on — why won't they negotiate to gigabit speed?

1000BASE-T requires Cat5e or better cabling with all four internal wire pairs healthy for the link to negotiate to gigabit. A degraded pair, a loose connector, or below-spec cable often still negotiates — just down to 100M instead of 1000M. Run virtual-cable-test to check pair health directly, and configure speed auto explicitly if you want to force a renegotiation attempt.

Why won't a single-fiber bidirectional (BiDi) link come up even though both ends have BiDi optics installed?

BiDi optics have to be used in complementary pairs, not identical ones — one end needs a TX1310/RX1490 module and the other needs TX1490/RX1310. Two modules with the same wavelength assignment on both ends will never link up no matter how healthy the fiber is, since they're both transmitting and listening on the same wavelength instead of opposite ones.

Can a 10GE port use a 1GE optical module, or the reverse?

A 10GE optical port can accept a 1GE module and will run at 1GE — the port itself is capable of the lower rate. The reverse doesn't work: a 1GE-rated optical interface can't be pushed to run a 10GE-rated module, since the physical interface and SerDes rate aren't built for it. Always match the module's rated speed to what the physical port is actually designed to run.

A port keeps flapping Up and Down every few minutes — is that hardware, cable, or something else?

Check the ERROR DOWN cause first if the log shows one — link-flap protection tripping repeatedly is itself diagnostic of an unstable physical layer underneath, not a separate fault. If there's no ERROR DOWN cause, check CRC and other error counters (a failing cable degrades before it fails outright), then optical power if it's a fiber link, and only treat it as a hardware fault once cabling and optics both check out clean under loopback internal.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei S-series switch's physical-interface fault-classification model and its display interface / display interface transceiver / virtual-cable-test commands, plus the field cases behind them. If your switch is a different vendor, the exact commands change, but the six-branch diagnostic order — human/protection, hardware, medium, usage/mismatch, environment, and the optic itself — carries over directly. It doesn't cover interface split/combine failures or packet-loss-while-Up scenarios in depth; those sit in a related section of the same source manual and deserve their own separate treatment.

A port that won't come Up and you've run out of obvious things to try?

Send us the display interface and display interface transceiver verbose output, and we'll help you pin down which of the six branches you're actually in.

WhatsApp an engineer →