Home / Notes / Packet Loss Troubleshooting

NOTES · SWITCHING / PACKET LOSS TROUBLESHOOTING

Network Packet Loss: Optics, CRC Errors and Discards Diagnosis

Packet loss almost always comes from one of three places: a light module putting out a bad signal, an inbound physical-layer error the interface counts as CRC, Giants or Runts, or an outbound Discard from a burst of traffic the port couldn't queue in time. This is the order to judge them in, the exact display interface fields that tell them apart, and how to read the optical diagnostic thresholds without guessing at a 'normal' dBm number.

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

'It's Just Packet Loss' Isn't a Diagnosis

Packet loss on a switch is a symptom with a short, repeatable list of causes — not a single fault to chase blindly.

Packet loss shows up on the user side long before anyone touches a display command: web pages loading slowly or only partially, video calls turning to a mosaic of blocks, instant-messaging clients dropping and reconnecting, downloads crawling, a plain ping to the gateway timing out, or a management session hanging on login. Any one of these is enough to suspect packet loss is happening somewhere on the path — but 'somewhere' still has to be narrowed down to an actual interface and an actual counter before anything gets fixed.

Once it's narrowed to a specific switch interface, packet loss comes from one of exactly three places: an optical module putting out a degraded signal, an inbound physical-layer error the interface itself counts and labels, or an outbound queue that couldn't keep up with a burst of traffic. What follows is a judgment tree for telling the three apart, the exact commands and fields for each, five gotchas that turn a clean-looking counter into a wrong diagnosis, and five FAQ answers pulled from real field cases.

Three Places Packet Loss Actually Comes From

Before any of the three sources matter, the interface itself has to actually be Up — otherwise you're reading a different fault tree entirely.

Placing the symptom on this tree first tells you which section below to actually read, instead of checking all three in whatever order comes to mind.

Diagram labels are kept in English for engineering clarity.

Judging Each Source in Turn

Same interface, three independent questions — the field that answers each one is different, and none of them substitute for the others.

Source 1 — Optical Module Bit Errors

Light power looking 'roughly normal' isn't the same as light power being inside this specific module's own thresholds — the diagnostic block tells you which one you're looking at.

Run display interface transceiver on the interface first and check the Alarm information block. An LOS Alarm means the far end isn't sending a signal at all — check with display this whether either end's port is shut down before assuming the module itself is broken.
Run display interface transceiver verbose and read the Diagnostic information block: Current RX Power and Current TX Power, each against that same module's own Default RX/TX Power High/Low Threshold fields — not a memorized 'normal' dBm figure, since different module types report different thresholds.
If Current RX Power is below the module's own Low Threshold, the local end is receiving too weak a signal — check transmission distance against the module's rated reach, then check the fiber link itself for excess connector loss or too tight a bend before assuming the module is faulty.
If Current RX Power is above the module's own High Threshold, this is usually a long-reach module used over too short a run, so the signal never attenuated naturally — add an optical attenuator to protect the module rather than replacing it.
If Current TX Power is outside its own thresholds on either side, that points at the local module itself: low TX power suggests a failing transmitter that will show up as the peer's RX being low; high TX power risks burning out the peer's receiver over time and calls for a module swap.

<HUAWEI> display interface 10ge1/0/1 transceiver verbose
... ...
-------------------------------------------------------------------
Warning information:
RxPower High
-------------------------------------------------------------------
Diagnostic information:
Temperature (Celsius)                :41.41
Voltage (V)                          :3.27
Bias Current (mA)                    :89.76|59.89 (Lane0|Lane1)
                                       71.61|63.70 (Lane2|Lane3)
Bias High Threshold (mA)             :130.00
Bias Low Threshold (mA)              :1.00
Current RX Power (dBm)               :-3.23|-3.11 (Lane0|Lane1)
                                       -2.90|-1.09 (Lane2|Lane3)
Default RX Power High Threshold (dBm):-0.50
Default RX Power Low Threshold (dBm) :-23.98
Current TX Power (dBm)               :0.71|1.21 (Lane0|Lane1)
                                       0.99|0.92 (Lane2|Lane3)
Default TX Power High Threshold (dBm):5.90
Default TX Power Low Threshold (dBm) :-5.90
-------------------------------------------------------------------
// compare Current RX/TX Power against THIS module's own threshold fields,
// never against a memorized "normal" dBm number -- different modules differ

Source 2 — Inbound Physical Errors (CRC / Giants / Runts)

display interface's Input block breaks a generic 'error packet' complaint into named counters — each one points at a different fix.

Run display interface on the affected interface while the business traffic is actually flowing, and read Total Error alongside the individual CRC, Giants, Jabbers, Fragments, Runts, DropEvents, Alignments and Symbols counters — these are all inbound counters, meaning the fault is on the sending side or the physical medium bringing traffic in, not this port's own egress queue.
If the error type is CRC and the count is small relative to total traffic, check whether the connector at either end is loose or the transmission medium — fiber, copper, module — is physically damaged; reseat or replace what's damaged, then run restart on the interface.
If the error type is Runts, check the frame length the peer is actually sending. If it's genuinely under 64 bytes, the peer's own configuration needs correcting; if the frame length is normal, restart the local interface instead.
If the error type is Giants, compare the received frame length against this interface's own The Maximum Frame Length field from display interface. If the peer is sending frames longer than that value, raise it locally with jumboframe enable value1; if the local limit is already at its ceiling, have the peer reduce its own MTU with mtu mtu instead.

<HUAWEI> system-view
[HUAWEI] display interface 10GE1/0/1
... ...
Total Error: 0
CRC: 0, Giants: 0
Jabbers: --, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 0
Output:
Unicast: 0, Multicast: 1438
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0

<HUAWEI> display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 45)
Line protocol current state : UP
Description:
Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216
// compare received frame length against The Maximum Frame Length above

[HUAWEI] interface 10GE1/0/1
[HUAWEI-10GE1/0/1] jumboframe enable 9600
// or, on the sending peer instead:
[peer] mtu 1500

Source 3 — Outbound Discard (Congestion)

Discard lives in the Output block, not the Input block — it means this port's own egress queue couldn't keep up, not that anything upstream is damaged.

Run display interface (or display this from inside the interface view) and check whether Discard is growing during the actual window the business impact was reported in — a non-zero Discard from weeks ago doesn't explain a complaint happening right now.
On boards that support it, run display qos queue statistics interface for the affected interface and read the per-queue Passed / Dropped / Drop Rate columns — congestion in a QoS-scheduled port is per-queue, so one queue can be dropping heavily while another passes cleanly.
Enable the enhanced burst mode for interface buffer management and watch whether Discard still climbs — this specifically targets microbursts, traffic spikes lasting milliseconds that a multi-second polling average never shows as a bandwidth problem.
If Discard is still climbing, shape or rate-limit the traffic actually causing the burst at its source queue, move latency-sensitive traffic into a higher-priority queue, or increase available bandwidth — a faster interface speed, or link aggregation across more than one physical port.
If it's still unclear whether an intermittent slowdown is really congestion, capture the traffic and read it in Wireshark's IO Graph with the X-axis set to milliseconds and the Y-axis set to bits — this shows the instantaneous rate spike that a 300-second device counter average completely hides.

<HUAWEI> display interface 10GE1/0/1
... ...
Output:
Unicast: 0, Multicast: 2033
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0
Input bandwidth utilization threshold : 90.00%
Output bandwidth utilization threshold: 90.00%
Last 300 seconds input utility rate: 0.01%
Last 300 seconds output utility rate: 0.01%

<HUAWEI> display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR   Passed          Pass Rate   Dropped         Drop Rate
      (kbps)     (Packets/Bytes) (pps/bps)  (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------
0     0/200000000  0              0          0               0
----------------------------------------------------------------------
7     0/200000000  1751           0          208369          507
----------------------------------------------------------------------

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] qos burst-mode enhanced
[HUAWEI-10GE1/0/1] qos queue 0 shaping cir 200 mbps pir 200 mbps

5 Things That Turn a Normal-Looking Counter Into a Wrong Diagnosis

Every counter above is real and accurate — these are the ways it still gets misread.

1. In-Range Optical Power Still Throws Alarms — There's No Universal 'Normal' dBm Number

SYMPTOMdisplay interface transceiver verbose shows an RxPower High or RxPower Low warning even though the raw reading looks like an unremarkable small number.

CAUSEThe thresholds are reported by the module itself — Default RX/TX Power High/Low Threshold — and differ by module type and rated distance, not a fixed value you can memorize across models. A long-reach module carrying a short link reads 'too high' against its own threshold even though the same number would be unremarkable on a different module.

FIXAlways compare Current RX/TX Power against that exact module's own threshold fields in the same output block, never against a remembered dBm figure; add an optical attenuator when a long-reach module is deployed on a short run.

2. CRC and Discard Can Look Identical on a Dashboard — They're Opposite Directions

SYMPTOMA traffic dashboard shows a flat loss percentage, and nobody has actually checked which direction the count is on.

CAUSECRC, Giants and Runts are inbound counters — the fault is on the sending side or the physical medium bringing traffic in. Discard is an outbound counter — the fault is this port's own egress queue being oversubscribed. Chasing a cable replacement for a Discard problem, or a queue-shaping change for a CRC problem, fixes nothing.

FIXRead display interface's Input and Output blocks as two separate questions before deciding which source above actually applies.

3. A Discard Count From Weeks Ago Doesn't Explain Today's Complaint

SYMPTOMDiscard is non-zero, so congestion gets blamed by default, even though the user's problem is happening right now.

CAUSEDiscard is cumulative since the counter was last cleared; a single burst that happened once, weeks earlier, leaves a permanent non-zero count that has nothing to do with the current ticket.

FIXWatch whether Discard is still climbing during the actual business-impact window, or check display qos queue statistics interface for a live per-queue Drop Rate instead of trusting the cumulative total alone.

4. A Loop or an Attack Produces the Exact Same Symptom as Ordinary Congestion

SYMPTOMDiscard and CPU usage climb together, and no amount of shaping or queue tuning brings Discard back down.

CAUSEA Layer-2 loop causing MAC flapping, or an active attack — ARP, ICMP, broadcast storm — floods the port with traffic that legitimate shaping was never meant to absorb, because that traffic shouldn't be on the port in the first place.

FIXCheck display trapbuffer for a loop trap and display mac-address flapping before assuming congestion; check display cpu-defend statistics all and display cpu-usage before spending time optimizing queues that were never the actual bottleneck.

5. Giants Only Shows Up Once Someone Changes the MTU on the Other End

SYMPTOMA Giants counter appears after months of clean operation, with no configuration change on the local switch at all.

CAUSEThis interface's own The Maximum Frame Length didn't change — but the peer device's MTU did, and it's now sending frames longer than this port accepts, which register here as inbound Giants and get dropped.

FIXCompare the received frame length against The Maximum Frame Length from display interface; raise it locally with jumboframe enable value1, or have the peer reduce its MTU with mtu mtu — whichever side is actually supposed to change.

Five Questions That Come Up Constantly

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

CRC or Discard — which one should I check first?

Neither, technically — check display interface brief first, because a port that's Down or in ERROR DOWN makes CRC and Discard beside the point; see our Ethernet port physically down note for that separate fault tree. Once the port is confirmed Up, treat inbound errors and outbound Discard as two independent questions, not one — a port can have either, both, or neither.

The optical module shows no Alarm information at all — can I rule out optics completely?

Not quite. Alarm information only flags conditions the module itself treats as abnormal, like LOS or RX LOL. It's still worth reading the full Diagnostic information block and comparing Current RX/TX Power against that module's own threshold fields — a reading close to, but not past, a threshold can still correlate with intermittent errors, especially as temperature shifts through the day.

Why does display qos queue statistics interface show drops on some queues and not others?

Because congestion on a QoS-scheduled port is per-queue, not per-port. A low-priority queue can be dropping heavily while a high-priority queue carrying voice or control traffic passes cleanly — that's what the priority scheduling was configured to do. Check which queue the affected traffic is actually classified into before concluding the whole port is oversubscribed.

I fixed the cable and CRC dropped to zero, but users still report slowness — what's left?

Recheck Discard on the same interface; a physical-layer problem and a congestion problem can coexist on the same busy uplink, and fixing one doesn't touch the other. If both come back clean, move on to the loop and attack checks — display trapbuffer for MAC flapping, display cpu-defend statistics all for attack traffic — before assuming the problem has moved somewhere else in the path.

Is there a way to prove an intermittent slowdown is congestion when Discard never seems to move?

Yes. Device-side counters average over multi-second polling intervals, so a genuine microburst can spike a queue and drop packets between polls without ever registering as Discard. Capturing the traffic and reading it in Wireshark's IO Graph, with the X-axis in milliseconds and the Y-axis in bits, shows the instantaneous rate spike that a 300-second average completely hides.

Honest Limits of This Note

Honest Limits of This Note

This note is built around Huawei's S-series switch fault-classification model for network packet loss and the display interface / display interface transceiver verbose / display qos queue statistics commands behind it, plus the field cases documented alongside them. If your switch is a different vendor, the commands change but the three-source logic — optics, inbound errors, outbound congestion — carries over directly. It deliberately keeps loop detection, attack tracing and CPCAR rate-limiting brief, since each of those is a large enough topic to deserve its own note; treat the gotcha above as the pointer to check them, not the full procedure.

Not sure which of the three it is yet?

Send us the display interface output for the affected port — Input and Output blocks both — and we'll help you read which source it's actually coming from.

WhatsApp an engineer →