Packet Loss occurs when one or more packets of data traveling across a computer network fail to reach their destination. It is one of the most destructive network conditions, often causing massive performance degradation even at very low percentages.
Why Packets Drop
Routers and switches are designed to forward packets as fast as possible. However, they will deliberately drop a packet if:
- Congestion: A 1 Gbps link tries to send 1.5 Gbps of traffic into a 100 Mbps link. The router's hardware queues fill up, and it is forced to drop the excess packets (tail drop).
- Physical Errors: A damaged copper cable, a failing fiber optic transceiver, or heavy wireless interference corrupts the packet in transit. The receiving device sees a failed CRC checksum and discards the damaged packet.
- Policing and Limits: The ISP enforces a strict 500 Mbps rate limit. If you burst to 505 Mbps, the ISP immediately drops the extra 5 Mbps of traffic.
- Overloaded Devices: The router's CPU is sitting at 100%, meaning it cannot process software-switched packets fast enough.
Symptoms of Packet Loss
Unlike Latency, which just delays traffic, packet loss destroys it. The symptom depends on the protocol:
- TCP Applications (Web, File Transfers): TCP guarantees delivery. If a packet is lost, the sender waits, realizes it was dropped, and retransmits it. A mere 1% packet loss can absolutely devastate TCP throughput, causing a 100 Mbps transfer to plummet to 5 Mbps.
- UDP Applications (Voice, Video Calls): UDP does not retransmit. If a packet is lost during a VoIP call, the user hears a robotic glitch or a missing syllable. A 2% loss makes a voice call completely unintelligible.
The Troubleshooting Workflow
When users complain that "the network is terrible," follow this methodology to isolate the exact location of the packet loss:
- Establish a Baseline: Are you dropping 1% continuously, or dropping 20% for exactly 3 seconds every hour (intermittent)?
- Compare Wired vs Wireless: Always test from a hardwired Ethernet connection. If wired works perfectly but Wi-Fi drops packets, the network is fine; you have a local RF interference problem.
- Ping the Local Gateway: Open a command prompt and ping your local router. If you see loss here, the problem is inside your building (bad switch, bad cable).
- Ping the Remote Destination: Ping the external server. If the local gateway is clean but the external server drops packets, the issue is on the WAN or the Internet.
- Check Interface Counters (SNMP): Log into your switches and firewall. Look at the interface statistics for "Errors" (bad cable) or "Discards/Drops" (congestion).
- Check Utilization: Is your ISP link currently sitting at 100% capacity? If so, the drops are expected. You need more bandwidth or QoS.
Interpreting Traceroute (A Critical Warning)
Engineers often run a traceroute to find where packet loss begins. Be incredibly careful: ICMP packet loss at a single intermediate hop does NOT automatically indicate forwarding loss.
Core internet routers prioritize forwarding customer traffic in hardware. They intentionally rate-limit or drop ICMP (ping) traffic destined to their own CPU to protect themselves. If hop 4 shows 50% loss, but hop 5, 6, and 7 show 0% loss, the route is perfectly healthy. Hop 4 is simply rate-limiting your pings.
Useful Diagnostic Commands
Windows:
tracert 8.8.8.8 # Trace the path to the destination
pathping 8.8.8.8 # Combines ping and tracert to calculate loss per hop
Linux / macOS:
traceroute 8.8.8.8 # Trace the path
mtr 8.8.8.8 # My Traceroute (excellent real-time loss tracking tool)