A CRC error is a symptom, not a location — it can just as easily be the local port, the cable or optical module, or the far-end device. This is the three-step swap procedure that isolates which one it is by changing exactly one variable at a time, and how to read each outcome without guessing.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A CRC error only tells you a frame arrived corrupted — it says nothing about which of the three physical elements between two devices actually corrupted it.
A rising CRC counter on display interface — part of the same discard/error path this note's packet loss diagnosis companion piece covers — means frames are arriving with a checksum that doesn't match their contents. That can happen at exactly three places: the local port's own transceiver and PHY, the cable or optical module in between, or the far-end device's port. The instinct is to change all three at once — swap the cable and the transceiver and move to a different peer port in the same visit — but that only tells you the problem went away, not which change actually fixed it.
The three-step method below changes exactly one variable per step, in a fixed order, and tells you from the counter baseline and each step's outcome exactly where to stop looking.
Each step holds two of the three elements fixed and swaps only the third — the outcome of that one step tells you whether to escalate or move on.
Laid out as a decision tree, the order matters: local port first, then the physical link, then the far-end device — because each step is faster and cheaper to test than the next, and ruling out the inexpensive possibilities first saves an unnecessary hardware swap or an unnecessary call to the peer's support desk.
Diagram labels are kept in English for engineering clarity.
Before running any of the three steps, clear the interface's counters with reset counters interface so that what you read afterward reflects only this test window, not the accumulated history since the device last rebooted.
One swap, one clean read of the counter, one decision — repeated at most three times.
display interface accumulates from the last reboot or the last reset — reading it without clearing first mixes weeks of old errors into today's test.
<HUAWEI> reset counters interface GigabitEthernet 0/0/5
<HUAWEI> display interface GigabitEthernet 0/0/5
GigabitEthernet0/0/5 current state : UP
Line protocol current state : UP
Total Error: 10
CRC: 4, Giants: 0
Jabbers: 1, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 5
// CRC incrementing after a clean reset -- a real, current problem, not old historyKeep the cable and the far-end port exactly as they are — only change which local port the link plugs into.
Keep the local port and the far-end port exactly as they are — only change the cable, fiber, or optical module in between.
Keep the local port and the link exactly as they are — only change what's on the far end.
| Step | What You Swapped | If the Error Follows the Swap | Conclusion |
|---|---|---|---|
| 1 | Local port | Error stays on the original port position | Local device hardware — open a support case |
| 1 | Local port | Error clears when moved to the other port | Port is clean — continue to Step 2 |
| 2 | Cable / fiber | Error follows the cable | Link-quality issue — inspect and replace |
| 2 | Optical module | Error follows the certified module | Escalate to vendor R&D — not a simple swap |
| 2 | Cable and module | Error stays regardless of either swap | Link is clean — continue to Step 3 |
| 3 | Peer port (multi-port peer) | Error clears on a different peer port | Peer-side port issue — peer's own support team |
| 3 | Peer device (single-port peer) | Error persists on a different peer port or unit | Compatibility issue — both vendors' support together |
The method is simple; these are the ways people get a false read from it in practice.
SYMPTOMThe interface never goes admin or oper down, so a physical-layer problem gets ruled out early — surely a real fault would take the link down.
CAUSEA degrading connector, a marginal cable, or a borderline optical budget doesn't necessarily take the link down at all — it just corrupts an increasing fraction of frames while the link stays Up the whole time. The CRC counter is often the only symptom you'll ever get before it eventually does fail outright.
FIXNever use "the link is Up" as a reason to skip the swap method — a rising CRC counter on an Up interface is exactly the case this method is for.
SYMPTOMA port shows Total Error with CRC, Alignments and Symbol errors climbing, alongside a large output Discard count — and the port cycles Up/Down repeatedly in the log.
CAUSEIn a real case, a switch port auto-negotiated down to 10Mbit/s half-duplex against a peer that expected 1000Mbit/s full-duplex, because the two ends' negotiation modes weren't consistent. The mismatch itself produced the CRC/Alignment/Symbol errors and the massive discard count — no cable or optical fault was involved at all.
FIXBefore running the swap method, check display interface for the Negotiation and Duplex fields on both ends. If they disagree, force both ends to the same non-auto-negotiation speed and duplex rather than swapping any hardware.
<HUAWEI> display interface GigabitEthernet 0/0/5
Duplex: FULL, Negotiation: ENABLE // port working in auto-negotiation mode
// diagnostic log showed CurrDuplex=HALF, Speed=10M during the fault window
[HUAWEI] interface GigabitEthernet 0/0/5
[HUAWEI-GigabitEthernet0/0/5] undo negotiation auto
[HUAWEI-GigabitEthernet0/0/5] speed 1000
// confirm the peer is also forced to the same speed/duplex, non-auto-negotiationSYMPTOMYou swap the cable, wait, and check display interface — the CRC count is still nonzero, so the conclusion is that the cable wasn't the problem after all.
CAUSEdisplay interface accumulates from the last reboot or the last manual reset, not from the moment you made the swap. A nonzero count after the fix can simply be the errors that happened before you changed anything, still sitting in the counter.
FIXRun reset counters interface immediately after every swap, before generating any test traffic — read the counter only after that reset, never before it.
SYMPTOMA handful of test pings after a swap show a clean counter, so the step gets marked as resolved — then the CRC count is back a few days later.
CAUSEIntermittent causes — a cable under mechanical stress, an optical budget that's marginal only at certain temperatures, EMI that only appears under real traffic volume — don't necessarily show up in a brief, low-traffic test window right after the swap.
FIXLet each step run under real production traffic for a meaningful window — hours, not a handful of pings — before concluding that step cleared the problem.
SYMPTOMStep 3 is run, the peer port is swapped, and the same CRC errors persist — the immediate conclusion is a vendor-interoperability issue.
CAUSEPersisting errors after a peer-port swap do point toward compatibility as the leading explanation, but only if Steps 1 and 2 were actually completed cleanly first. If the local port or the link was never properly cleared as a cause, Step 3's result is ambiguous, not conclusive.
FIXOnly read Step 3's outcome as compatibility once Steps 1 and 2 have each independently cleared their element — don't skip ahead to Step 3 to save time.
Pulled straight from the field — the ones worth having an answer ready for.
Yes, if you don't already have a strong reason to suspect one specific element — the order is cheapest-and-fastest first. But if the same cable or optical module already showed a problem on a different port pair recently, it's reasonable to start at Step 2 instead of repeating Step 1 from scratch.
Any port on the same device that's currently error-free under similar traffic qualifies as the known-good reference — it doesn't need to be an identical port type, only clean after reset counters interface.
Yes. A slow, steady climb is often the early sign of a degrading connector or a cable nearing its bend-radius or length limit — exactly the kind of thing that becomes an outright physical down event later if left alone. Catching it while it's still just CRC creep is cheaper than diagnosing a hard failure after hours.
No. If the errors cleared when you changed the cable or fiber alone with the optical module untouched, the link (cable/fiber) is the confirmed cause — the optical module doesn't need to be replaced or escalated separately.
Yes — run it independently at both ends, starting with whichever end has the higher CRC count or is easier to access. If both directions clear at the same swap, that step was almost certainly the fix. If they clear at different steps, you may be looking at two separate faults stacked on the same link, not one.
This note is built around the Huawei S-series switch's CRC/error-counter model and its reset counters interface / display interface workflow, plus the field cases behind it. The underlying method — isolate one variable per swap, in a fixed order of cost — is vendor-agnostic and carries over directly to other platforms, even though the exact commands change. It doesn't cover fiber-optic power-budget or OTDR-level diagnostics in depth, and it assumes you can physically access both ends to swap things — a fully remote far end limits you to Steps 0 and 1 only, with Steps 2 and 3 needing someone on-site at the peer.
Tell us which step you're on, and what the counter did before and after, and we'll help you read it.