The bytes all arrived.
Some of them twice.
A retransmission is the one failure mode that costs your users time without costing the link any noticeable throughput — which is exactly why the graphs stay green while the complaints come in.
A TCP retransmission happens when the sender does not receive an acknowledgement in time and sends the same segment again. The usual causes are packet loss from a full queue, a physical error on a port, a microburst, an overloaded firewall or middlebox, and asymmetric routing that breaks a stateful device. As a rule of thumb, under 0.1% is normal, around 1% is noticeable to users, and above 2% feels like a broken network — but the rate matters far less than the direction and the location, which is what tells you where to look.
Where retransmissions actually come from.
In rough order of how often each one turns out to be the answer. All six look identical in a byte counter and completely different in a capture.
A queue that filled for a moment
Congestion does not have to be sustained to drop packets. A buffer that fills for 40 milliseconds drops whatever arrives next, and the five-minute average that covers it reads as comfortable.
Look for: interface discards or output drops climbing while utilisation stays low. That combination is almost always a burst.
A physical error on one port
A failing transceiver, a marginal patch lead or a duplex mismatch corrupts frames. The corrupted frame is discarded, TCP notices the gap and resends. The port looks up and passes traffic the whole time.
Look for: FCS/CRC errors, late collisions or input errors on a single interface, with no traffic level that would justify them.
A middlebox under load
Firewalls, load balancers and WAN optimisers hold state per session. When the session table or the CPU is pressed, they drop rather than queue — and they rarely say so in a way that reaches your monitoring.
Look for: loss that appears only for flows crossing one device, and only at particular times of day.
Asymmetric routing
Traffic leaves by one path and returns by another. A stateful device that sees only half of a conversation drops it, because as far as it is concerned the session never opened.
Look for: a handshake visible in one direction only in the capture. That is conclusive, and nothing else produces it.
The receiver, not the network
A host that cannot drain its receive buffer advertises a smaller and smaller window until it advertises zero. Nothing was lost and nothing was resent — the sender simply has to wait. It feels identical to loss from the user's seat.
Look for: TCP Window Full and TCP ZeroWindow in the capture. These say the problem is at the far end, not on the wire.
Wi-Fi, which is a different animal
Wireless retries happen below TCP and are normal. They only become TCP retransmissions when the radio gives up entirely. A wired-network rule of thumb applied to a wireless client will mislead you.
Look for: whether the loss survives when the same client is put on a cable. If it does not, stop looking at the network core.
Five steps, in this order.
The order matters: each step removes a class of cause, so by the last one there is usually only one candidate left.
- 1
Measure the rate per direction, not in total
A combined figure hides the answer. Retransmissions inbound and outbound have different causes, and a one-sided rate immediately narrows the search to one path.
- 2
Find where the loss starts
Compare the same conversation at two capture points. The segment where the retransmissions first appear contains the cause; everything downstream is just reporting it.
- 3
Rule the receiver in or out
Check for zero-window and window-full events. If they are present, the network is delivering fine and the far host cannot keep up — a completely different fix.
- 4
Correlate against interface errors
Line up the retransmission timeline with discards, CRC errors and interface resets. A match on one port ends the investigation.
- 5
Check what changed
If it started on a date rather than growing gradually, the cause is usually a configuration change, a firmware upgrade or a new path — not a worn cable.
Retransmissions climbing. Utilisation flat.
Drag the timeline. The lower track never approaches its alert limit for the entire incident, while the experience on the wire falls apart. A tool watching counters has nothing to report here.
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.
Why this is hard without a recording
- The evidence expires. By the time someone starts a capture, the burst that caused the loss is minutes gone. Net-Monitor records continuously, so the packets are already there.
- Rate alone does not locate anything. You need the same conversation seen at more than one point, over the same minute — which means both points must have been recording.
- Thresholds do not catch a climb. A rate that walks from 0.2% to 1.4% over two days never crosses a fixed limit. A learned baseline flags the drift while it is still forming.
Short answers.
What is an acceptable TCP retransmission rate?
On a wired enterprise network, under 0.1% is unremarkable, around 1% is where users start to describe things as slow, and sustained rates above 2% feel broken. Treat these as rules of thumb rather than thresholds: a 0.3% rate concentrated on one critical path matters far more than 1% spread evenly across a busy internet link.
Do retransmissions always mean packet loss?
No, and this is the most common misreading. A spurious retransmission happens when the acknowledgement was simply slow rather than missing, and a zero-window stall involves no loss at all. Both show up in a naive count. Only the capture distinguishes them.
Can I see retransmissions in SNMP?
Not directly. SNMP gives you interface counters — bytes, errors, discards — which are correlated with loss but do not identify a retransmitted segment or tell you which conversation suffered it. The retransmission is a property of a TCP stream, so it is visible only where the streams are.
Why does the problem move when I look for it?
Usually because it is a burst, and bursts are load-dependent. Adding a capture point, changing a path or testing at a quieter time changes the conditions that produced it. Continuous recording avoids this entirely: you analyse the incident that already happened rather than trying to reproduce it.
Bring us a link that retransmits and nobody can explain.
We will point Net-Monitor at it and show you the packets behind the number — which is usually a short conversation.