A Field Guide to Diagnosing Slow Networks
"The network is slow" is the least actionable sentence in operations, because at least five unrelated conditions produce it and each requires a different response. Buying more bandwidth to solve a latency problem is a common and expensive mistake, and so is rewriting an application to solve what turns out to be a duplex mismatch on a single switch port. The discipline that saves time is refusing to act until you have identified which of the underlying quantities has actually degraded.
Four quantities, four symptom profiles
Bandwidth is capacity, measured in bits per second. When it is the constraint, large transfers are slow, small ones are fine, and the problem worsens predictably as more people work. Latency is delay, measured in milliseconds. When it is the constraint, everything interactive feels sticky regardless of file size, and throughput on a single connection is capped no matter how much capacity you buy. Packet loss forces retransmission and collapses throughput far out of proportion to its percentage — one per cent loss on a long path can halve effective speed. Jitter, the variation in latency, leaves averages looking healthy while destroying voice and video calls. Diagnostic material organised around this distinction, including the troubleshooting guides at the diagnostic material collected here, exists because the four are consistently confused with one another.
Measure before theorising
Start with a continuous ping to three targets: the default gateway, a device just beyond your edge, and a well-known internet host. Leave it running for several minutes rather than sending four packets. The pattern across those three tells you immediately whether the problem is local, on your access link, or somewhere upstream.
- All three degraded — likely local, at the client or the first hop
- Gateway clean, others degraded — your access circuit or provider
- Loss only at the final target — a path or destination problem, not yours
- Latency rising steadily under load, then recovering — buffering, not congestion
That last pattern deserves its own name. Bufferbloat occurs when an intermediate device holds a large queue rather than dropping packets, so a saturated uplink adds hundreds of milliseconds of delay to everything sharing it. A household video call becoming unusable the moment a backup starts is the canonical example, and the fix is queue management on the router rather than additional capacity.
Traceroute lies, usefully
Traceroute is the standard next step and it must be read carefully. Intermediate hops frequently deprioritise the packets that generate their responses, so a middle hop showing high latency or loss while later hops look fine indicates nothing at all. Only the end-to-end figures are meaningful. Paths are also asymmetric — the return route may differ entirely from the outbound one — which means a clean trace from your side does not exclude a problem on the way back. When a provider disputes your findings, a trace run in both directions usually settles the argument in a way one direction never will.
The physical layer is still the first suspect
Before investigating anything sophisticated, look at interface counters on the switch. Errors, discards, CRC failures and collisions are all recorded, and they point straight at cabling, optics or a negotiation mismatch. A port showing steadily rising CRC errors has a physical problem that no amount of protocol analysis will explain. Duplex mismatches deserve particular suspicion because they produce a distinctive signature: acceptable performance at low load, dramatic collapse under any real traffic, and error counters climbing on only one side of the link.
Wireless adds its own layer of physical causes. Channel overlap, distant clients dragging down the rate for everyone on the access point, interference from unrelated equipment, and simple client density all produce symptoms indistinguishable from a slow uplink when viewed from the application. If the complaint comes only from wireless users, resolve the wireless question before touching anything else.
Fragmentation and the invisible failures
Packet size problems produce the strangest reports: small requests succeed, large ones hang, and the connection appears fine until it is used for anything substantial. This is usually a maximum transmission unit mismatch, often introduced by a tunnel that added encapsulation overhead without adjusting for it, combined with a firewall blocking the ICMP messages that would otherwise report the problem. The result is a path that silently discards packets above a certain size, and it is one of the few faults that genuinely requires a capture to identify.
Application or network
Once transport-level measurements look clean, the problem is probably not the network. A capture will show this clearly: request sent, acknowledged promptly, then a long gap before the response begins. That gap is processing time. Establishing this early avoids the familiar cycle in which an application team and an infrastructure team each spend a week proving the fault belongs to the other.
Test throughput properly or not at all
Speed tests run from a laptop over wireless, against a distant public server, during working hours, measure a great many things at once and isolate none of them. If throughput is genuinely the question, test from a wired host directly attached to the relevant switch, against a server you control, with several parallel streams. A single stream is limited by latency and window size long before it saturates a fast circuit, which is why a gigabit link often reports a few hundred megabits on a naive test and everyone concludes the provider is at fault.
Record what normal looks like
Every method above compares current behaviour against expected behaviour, which requires knowing what expected behaviour is. Baseline your key paths while everything works — latency distributions, typical throughput, error counter rates — and store the numbers somewhere retrievable. Without a baseline, every investigation begins by arguing about whether ninety milliseconds is normal for that route. With one, most investigations end in the first ten minutes.
