The interface is dropping.
The graph says 8%.
Both numbers are correct. They are measuring different things — and the one your monitoring shows you is the one that cannot see the problem.
A microburst is a spike of traffic lasting milliseconds that fills a switch's output buffer and causes it to drop packets, without moving a utilisation average enough to notice. A port sampled every five minutes can read 8% while having been at line rate — and dropping — for 40 milliseconds inside that window. The giveaway is the combination that looks contradictory: a rising discard counter on an interface with low reported utilisation. Averaging is the cause of the blind spot, so no amount of polling more often fixes it; you have to look at the traffic instead of a summary of it.
The arithmetic of the blind spot.
This is not a limitation of any particular product. It follows from what an average is.
A 1 Gbps port, for 40 milliseconds
At line rate for 40 ms, a port moves about 5 MB. Spread across a 300-second polling interval, that is roughly 0.13 Mbps of apparent throughput — around 0.01% utilisation. The buffer overflowed; the graph did not move.
Buffers are smaller than people assume
Many access switches carry a few megabytes shared across all ports. A single burst can exhaust the share available to one port well before the burst is over, which is why drops start early rather than at the end.
Speed mismatches manufacture them
Anywhere traffic moves from a faster link to a slower one — 10G into 1G, a trunk into an access port — the switch must buffer the difference. That is the classic location, and it is structural rather than a fault.
Some workloads burst by design
Storage replication, backup windows, VM migration, distributed database sync and market data feeds all emit tightly grouped traffic. Nothing is misconfigured; the shape of the traffic is simply not what the averaging assumes.
Incast makes it worse
Many senders answering one requester at the same instant — a distributed query, a parallel backup — converge on one port simultaneously. The aggregate is brief and enormous.
The symptom is downstream
What users report is not "a burst". It is retransmissions, a stalled transfer, a jittery call or a slow application. The burst is the cause; those are the effects that reach the helpdesk.
Detecting something an average cannot show.
- 1
Trust the discard counter over the utilisation graph
Discards and output drops are event counts, not averages. They do not get smoothed. If they are climbing while utilisation reads low, believe the discards.
- 2
Find where the speed changes
Walk the path and mark every step down in link speed and every many-to-one convergence point. Microbursts are found at those places far more often than anywhere else.
- 3
Look at the traffic at millisecond resolution
Only a capture can show a 40 ms event. If you are reading a graph whose finest granularity is a minute, the event is not in the data at all — it is not a matter of looking harder.
- 4
Line it up with what runs on a schedule
If the drops cluster at the same times, compare against backup jobs, replication windows and batch runs. Recurring bursts almost always have an owner.
The average that hides the incident.
Drag the timeline. Utilisation stays inside its normal band for the entire event while conditions on the wire degrade — which is the microburst signature at the resolution most tools work in.
Net-Monitor has learned what this part of your network normally does at this time of day. Traffic is comfortable, the wire is clean, and nobody needs to be told anything.
- Link utilisation
- 39%
- Response time
- 24ms
- Sniffer packet errors
- 0.2%
- Risk score
- 2/100
Utilisation is comfortable and the wire is clean.
What it takes to actually catch one
- Millisecond resolution, not faster polling. Polling every 30 seconds instead of every 5 minutes still averages away a 40 ms event. Only the packets have the resolution.
- Recording before the fact. Bursts are not reproducible on demand. If the capture starts after the drops are noticed, it records a quiet network.
- Correlation with the discard counters. The proof is the burst and the drop lined up on the same timestamp — which needs both sources in one engine.
Short answers.
What is a microburst in networking?
A microburst is a very short spike of traffic — typically milliseconds — that exceeds an interface's capacity and overruns its buffer, causing drops. Because it is far shorter than any normal polling interval, it barely registers in utilisation statistics, which is what makes it so persistently confusing to diagnose.
Why does my interface show discards at low utilisation?
That combination is close to a definition of a microburst. Utilisation is an average over the polling interval; a discard is a single event with a timestamp. A port can average 8% and still have been saturated, and dropping, for a fraction of that window.
Will more bandwidth fix a microburst?
Sometimes, and it is an expensive way to find out. A faster link raises the ceiling the burst has to reach, which helps if the burst is close to it. If the cause is many-to-one convergence or a shallow buffer, more bandwidth changes very little — the traffic still arrives at one port at the same instant.
Can QoS help?
Yes, more often than extra bandwidth does. QoS decides what gets dropped when the buffer is under pressure, so it protects the traffic that matters even when a burst is unavoidable. It is worth verifying that the policy is actually being applied rather than merely configured.
Have a port that drops for no reason you can find?
That is the case continuous recording was built for. We will show you the burst and the drop on the same timestamp.