A switch's average-rate graph can look perfectly flat while a port is quietly dropping packets to a burst that lasted a single millisecond. This is how to recognize the symptom, capture and read the actual burst, walk through a real case where the fault log pointed at the wrong cause, and the mitigation measures that hold up once you know what you're dealing with.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
I've watched a five-minute average-utilization graph sit under 30% while the same port was quietly dropping packets — the tool just wasn't looking at the right timescale.
Network management platforms and performance-monitoring tools typically compute utilization over several seconds to a few minutes. At that resolution, a port's traffic curve looks smooth and unremarkable. But a second is an enormous span of time for an interface moving packets at multi-gigabit line rate — zoom into millisecond granularity and the same traffic routinely turns out to be sawtoothed, spiking to speeds many times its own average. When the spike is severe enough to overrun the switch's buffer, that's a microburst, and it produces discards that never show up as a sustained utilization problem.
What follows is what a microburst actually looks like, the order to check for one without guessing, a real field case where the fault-classification logs pointed straight at the wrong cause, and the mitigation measures that hold up once you've confirmed what you're dealing with.
Microbursts run 1 to 100 milliseconds and can spike to tens or hundreds of times the average rate — sometimes past the port's own bandwidth.
A microburst is a very short, very dense burst of traffic on a port — typically 1–100 ms — that reaches an instantaneous rate far above the measured average, and in the worst case, above the physical bandwidth of the port itself. It isn't a monitoring failure to miss one at a 5-minute resolution; it's a resolution mismatch. The traffic underneath a flat-looking macro curve is routinely a jagged micro curve, and when the teeth get big enough, that's the burst.
Diagram labels are kept in English for engineering clarity.
Three conditions combine to create most microbursts: bursty application behavior (request/response patterns, latency-sensitive traffic trying to send as fast as possible), more ingress bandwidth than egress bandwidth on the same forwarding path (a big pipe feeding a small one, or several equal-speed ports converging on one), and classic TCP's slow-start-then-halve sawtooth under congestion avoidance. None of the three requires anything to be misconfigured — they're normal traffic behavior colliding with a buffer that's too small for the instant.
Discard counters and QoS alarms tell you a microburst probably happened; mirrored capture and the switch's own detection features tell you how big and how often.
Either symptom below means “a microburst probably happened here,” not confirmation — the checks that follow are what actually confirm it.
<HUAWEI>display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 8)
Line protocol current state : UP
Last 300 seconds input rate: 225 bits/sec, 0 packets/sec
Last 300 seconds output rate: 2075 bits/sec, 1 packets/sec
Input peak rate 2387819 bits/sec, Record time: 2025-11-26 16:11:22+08:00
Output peak rate 1277476 bits/sec, Record time: 2025-11-26 15:51:14+08:00
Input:
Discard: 0, Frames: --
Output:
Discard: 89, Buffers Purged: 0
// average rate looks trivial -- but 89 egress discards already happenedDiscards on the egress side, not the ingress side, are the defining signature of a microburst rather than a CRC or physical-layer problem.
<HUAWEI>display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR Passed Pass Rate Dropped Drop Rate Drop Time
(% or kbps) (Packets/Bytes) (pps/bps) (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------------------------------
6 0 21 0 0 0 -
10000000 6930 88 0 0
----------------------------------------------------------------------------------------------
7 0 255 0 0 0 -
10000000 31365 492 0 0A 1-millisecond I/O graph is the granularity a microburst actually needs to become visible — the default multi-second interval just shows the same flat curve the monitoring platform already gave you.
Two built-in features do this without a mirrored capture at all — neither is available on every switch model, so check your hardware's support before assuming it's there.
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos buffer-monitoring percent low 60 high 90
<HUAWEI> display qos buffer-monitoring result interface 100GE 1/0/1
Queue Time BufferUsage(Bytes) Percent(%)
----------------------------------------------------------------
0 2015-11-11 14:36:15.208 1602016 100
// a saved record here confirms a microburst occurred, and precisely when
[HUAWEI] qos micro-burst detection enhanced enable
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos micro-burst detection enableA campus-network client on an S12700E-8 stack reported clients timing out through the core switch every so often — long pings never dropped, big-packet pings never dropped, only real application traffic did. The logs showed an output-rate-change-ratio alarm on one GigabitEthernet port, paired with a “Packets are discarded for congestion” log that read, on this software version, exactly like inter-board congestion. Removing a large stack of port-mirroring configuration eased the symptom but didn't fix it. display qos micro-burst statistics on the lossy interface showed traffic nowhere near the platform's actual forwarding ceiling — so it shouldn't have been inter-board congestion at all. Mirroring that same interface showed a sawtoothed capture with one one-millisecond window hitting roughly 8–9 megabits — around 8Gb/s — on a Gigabit-rate port; a further packet capture on the same interface caught one specific end host sending several oversized packets within that same millisecond. The lesson: on this platform and version, ordinary port-level congestion gets logged with the same wording as inter-board congestion, which misdirects the diagnosis toward “the fabric can't forward this much” when the real cause is a single port taking an instantaneous hit far above its own bandwidth. Judge by combining signals — interface bandwidth utilization, qos micro-burst statistics, and mirrored capture — never by the log wording alone.
Once you've confirmed a burst is really happening, these are the misreadings that send people looking in the wrong place.
SYMPTOMDiscards are climbing, but the device never raised any alarm about buffer usage — so the assumption is that buffers are fine and the discard count must be measuring something else.
CAUSEReading buffer occupancy requires CPU polling, the same constraint that limits how often utilization itself can be sampled. Polling aggressively enough to catch a millisecond-scale event would push CPU usage high enough to slow the whole device down, so the switch deliberately doesn't try to alarm on buffer state at that resolution.
FIXTreat discard counters, mirrored capture and the dedicated microburst-detection feature as the intended substitutes for a buffer alarm that will never come — don't wait for one.
SYMPTOMThe port's utilization graph never goes above 20–30%, so a burst-related packet loss theory gets dismissed outright.
CAUSEAverage utilization and instantaneous burst rate aren't the same measurement, the same way speed and acceleration aren't the same thing. A NIC transmits at its full physical rate or not at all — never at a fractional rate — so a port idling at 20–30% average can still be running at 100% line rate for a few milliseconds at a time, then sitting idle.
FIXNever rule out a microburst on average utilization alone — go straight to a mirrored, millisecond-scale capture or the built-in detection feature instead.
SYMPTOMThe switch is the device logging the discards, so the switch gets treated as the thing that's broken.
CAUSEAside from a small amount of protocol traffic, switches don't generate the traffic that overruns their own buffers — end hosts do. What the switch can do is amplify a burst: several ports at equal speed sending to one, or an unfavorable convergence ratio, stacks multiple bursts' peaks on top of each other at the exact moment they collide on the shared egress port.
FIXTrace the traffic source and the convergence ratio in the network design, not just the interface that happened to log the drop.
SYMPTOMThe application is described as having unpredictable, low-intensity traffic, so a serious burst seems implausible.
CAUSEA server's network card sends at its full physical link rate whenever it has something queued, then goes idle waiting on the application layer. Averaged over time that can look like 20–30% utilization, but at the microsecond level it's actually 100% or 0%, never in between — which is precisely what a microburst is made of.
FIXDon't use “the application isn't that busy” as a reason to skip a millisecond-scale capture — it's exactly the traffic pattern most likely to produce one.
SYMPTOMA mirrored capture on a busy 10Gbps-plus interface shows drops or looks inconsistent from run to run, even though the capture setup itself looks correct.
CAUSEA PC-based capture is only reliable up to roughly 1Gbps of interface rate, and a server-based one up to roughly 10Gbps; past that, the capture tool itself becomes the bottleneck and starts dropping or misrepresenting packets — the very thing you're trying to observe.
FIXAbove roughly 10Gbps, or for any sustained monitoring window, use a dedicated third-party capture-and-analysis appliance rather than a general-purpose PC or server running Wireshark.
In roughly the order they're worth trying — cheapest and lowest side-effect first.
[HUAWEI-GigabitEthernet0/0/1] qos burst-mode enhanced
[HUAWEI] traffic classifier c_latency
[HUAWEI-classifier-c_latency] if-match dscp af41
[HUAWEI] traffic behavior b_latency
[HUAWEI-behavior-b_latency] remark local-precedence 6
[HUAWEI] traffic policy p_edge
[HUAWEI-trafficpolicy-p_edge] classifier c_latency behavior b_latency
[HUAWEI-GigabitEthernet0/0/2] traffic-policy p_edge inbound
[HUAWEI-GigabitEthernet0/0/1] qos queue 3 shaping cir 500 mbps pir 800 mbps
// shaping adds latency -- reach for it after the other options, not beforePulled straight from the field — the ones worth having an answer ready for.
No. Ordinary sustained congestion shows up on the average-rate graph too — that's exactly what routine monitoring, including the checks in our datacenter switch health check note, is built to catch. A microburst is specifically a burst so short — 1 to 100 milliseconds — that it's invisible at normal monitoring resolution while it still overruns the port's buffer for that instant.
Because reading buffer occupancy needs CPU polling, and polling aggressively enough to catch a millisecond-scale event would push CPU utilization high enough to slow the whole device down. That's exactly why discard counters, mirrored capture, and the dedicated microburst-detection feature exist as substitutes for an alarm that isn't coming.
If you just need confirmation that a burst happened and roughly when, congestion monitoring's buffer-monitoring is lighter-weight and supported on more models. If you need the actual rate and duration for capacity planning, microburst detection's enhanced mode gives you real per-interface numbers at 1ms resolution — at the cost of only running on one interface at a time.
Yes, and this is the single most common misreading of the data. Average utilization and instantaneous burst rate aren't the same measurement, any more than speed and acceleration are the same thing. A port idling at 20–30% average can still be running at 100% line rate for a few milliseconds at a time, because that's literally how a network card transmits — at full physical rate or not at all.
In roughly the order they help without side effects: add egress bandwidth on the bottleneck link; avoid many-to-one traffic patterns in the design; enable qos burst-mode enhanced so busy ports can borrow more of the shared dynamic buffer; separate latency-sensitive traffic into a higher-priority queue so it isn't the traffic that gets dropped; and reach for output shaping only last, since it fixes the drop by adding forwarding latency, which is its own tradeoff.
This note is built around the Huawei S-series campus and framed-switch buffer/QoS model — display interface, display qos queue statistics, qos buffer-monitoring, qos micro-burst detection — and the field case behind it. If your platform is a different vendor, the exact commands change, but the underlying concept carries over directly: average-rate monitoring misses millisecond bursts by design, and confirming one needs either mirrored capture or a purpose-built detection feature. It doesn't cover data-center leaf-spine lossless-fabric burst absorption (PFC, ECN) in depth — that's the subject of the linked lossless storage solution instead.
Tell us the interface, the discard count, and whether you've already tried a mirrored capture, and we'll help you read it.