Infrastructure & Reliability · Chapter 3 of 8
Networks, without the certification
The layer everything blames and almost nobody measures properly. Six mechanisms explain most of what you will meet.
You do not need a routing certification to be effective here. You need to know what actually produces the symptoms you will be handed, and how to measure rather than infer.
Why ‘the network is slow’ is almost never bandwidth
| Mechanism | What it looks like | How you confirm it |
|---|---|---|
| Packet loss | Throughput collapses on long paths; small transfers fine | Retransmits in a packet capture — even 0.1% is destructive over distance |
| Micro-bursts | Interface averages look idle; users see stalls | Interface discards and queue depth, not utilisation |
| MTU / fragmentation | Small requests work, large ones hang | Test with increasing payload sizes; classic with tunnels and VPNs |
| Asymmetric routing | Works one way, breaks through a stateful device | Traceroute both directions — not just outbound |
| A middlebox | Intermittent, unexplainable | Firewall, proxy or TLS inspection. Very often the actual answer |
| DNS | Slow to start, fast once running | Time the resolution separately from the transfer |
Measure like the application, not like a diagnostic
ICMP is deprioritised or rate-limited on plenty of equipment, so a clean ping proves very little and a lossy ping may mean nothing. Test with a TCP connection to the actual port, continuously, from the affected location — latency and loss over time rather than a snapshot of a moment when it happened to be fine.
The sentence that ends most arguments
“I have discards on that interface and retransmits in the capture” is a fact. “It feels like the network” is not, and neither is “bandwidth looks fine”.
Getting a packet capture at both ends before concluding anything is the habit that separates people who resolve these from people who escalate them.