Interactive Troubleshooter

Published: Sep 1, 2026

Network Latency and Packet Loss: Diagnose with Tools

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to systematically isolate and resolve network latency spikes and packet loss. Isolate bottlenecks across physical Layer 1 interfaces, WAN/ISP transit routes, TCP windowing, and Path MTU discovery issues using standard diagnostic tools.

Full Diagnostic Tree & Step-by-Step Overview

Where in the network path is packet loss or latency degradation occurring?

First-hop local network (Wi-Fi access point, local gateway, or physical Ethernet interface)
Wide Area Network (WAN), ISP transit, or intermediate hops along the routing path
End-to-end transport layer (TCP retransmissions, MTU fragmentation, or server-side socket exhaustion under load)

What specific local interface or local area network (LAN) symptom are you observing?

Physical layer errors (CRC/alignment errors), Ethernet duplex mismatch, or wireless RF channel interference
First-hop gateway queue latency (Bufferbloat) or local network switch CPU exhaustion during traffic spikes

Remediate Physical Layer Ethernet Errors and Wireless RF Interference

Solution:

Root Cause: Physical Layer Frame Corruption (CRC Errors, Duplex Mismatch, or RF Interference)

Packet drops occurring on the local network link are usually caused by physical layer failures. Damaged cabling, improper auto-negotiation resulting in Half-Duplex state, or dense RF co-channel interference on Wi-Fi cause frame corruptions (Cyclic Redundancy Check / CRC failures) at the Network Interface Card (NIC).

# Step-by-Step Fix:

Inspect NIC Statistics for Hardware Errors (Linux/Windows):

On Linux, query the physical interface stats using ethtool or netstat:

bash
   sudo ethtool -S eth0 | grep -E "crc|drop|frame|error"
   netstat -i

On Windows PowerShell, check interface error counters:

powershell
   Get-NetAdapterStatistics | Select-Object Name, ReceivedDiscardedPackets, ReceivedPacketErrors, OutboundDiscardedPackets, OutboundPacketErrors

Verify Speed and Duplex Settings:

Ensure interface is auto-negotiated to Full Duplex:

bash
   sudo ethtool eth0 | grep -i Speed

If locked in Half-Duplex, force auto-negotiation:

bash
   sudo ethtool -s eth0 autoneg on

Diagnose Wi-Fi Signal Degradation and RF Congestion:

Scan local 2.4GHz/5GHz/6GHz channel utilization (Linux):

bash
   sudo iw dev wlan0 scan | grep -E "SSID|DS Parameter set|signal"

Switch the Wireless Access Point to an non-overlapping, low-utilization channel (e.g., Channels 1, 6, 11 on 2.4GHz or 80MHz blocks on 5GHz).

Replace Cabling:

Swap patch cables with Cat6/Cat6A shielded twisted pair (STP) if CRC errors continuously increment.

Mitigate Local Gateway Bufferbloat using Smart Queue Management (SQM)

Solution:

Root Cause: Egress Router Bufferbloat (Excessive Network Buffer Queuing)

Bufferbloat occurs when network routers configure excessively large FIFO buffers to prevent packet loss during traffic bursts. When upload or download bandwidth saturates, packets sit in deep queues for hundreds of milliseconds before transmission, creating massive latency spikes despite 0% static packet loss.

# Step-by-Step Fix:

Identify Bufferbloat via Ping Under Load Test:

Start a continuous ping to your local default gateway while running an internet speed test:

cmd
   ping -t 192.168.1.1

If latency jumps from ~2ms to >100ms during upload/download phases, Bufferbloat is confirmed.

Measure Bandwidth Saturation Thresholds using iperf3:

Run an iperf3 client-server test to find maximum throughput before latency degrades:

bash
   iperf3 -c 192.168.1.1 -P 4 -t 30

Enable Smart Queue Management (SQM) on Router:

Access your router configuration interface (e.g., OpenWrt, pfSense, Ubiquiti, or Enterprise Firewall).

Enable SQM and select FQ-CoDel or CAKE queuing algorithms.

Set SQM Bandwidth Limits:

Set ingress and egress rate limits to 85-95% of your maximum provisioned ISP speed to force queues to handle buffering at the router level without filling physical hardware buffers.

What behavior is observed across intermediate traceroute or MTR diagnostic hops?

Packet loss appears on an intermediate hop but does NOT persist through to the final destination
Packet loss or high latency starts at an intermediate hop and continues through to the final destination

Differentiate ICMP Control-Plane Rate Limiting from True WAN Packet Loss

Solution:

Root Cause: Control-Plane ICMP Rate Limiting on Intermediate Transit Routers

Intermediate internet routers deprioritize ICMP Time Exceeded generation to protect their Control Plane CPUs. When an MTR or traceroute shows 20% loss at Hop 4, but 0% loss at Hops 5 through 10 (and 0% at the destination), the loss is artificial and represents benign router rate-limiting, not network degradation.

# Step-by-Step Fix:

Run High-Count MTR Test:

Run an MTR report sending at least 100-200 probe cycles:

bash
   mtr -4 -c 100 --report target-domain.com

Analyze the Loss Profile across Hop Sequence:

Inspect the Loss% column from top to bottom.

Rule of Evaluation: If Hop N shows 15% loss, but Hop N+1 shows 0% loss, ignore the reported loss on Hop N entirely.

Verify TCP Probe Response:

If ICMP probes are blocked entirely by intermediate firewalls, execute a TCP SYN traceroute targeting the destination application port:

bash
   sudo traceroute -T -p 443 target-domain.com
   # Or using tcptraceroute:
   tcptraceroute target-domain.com 443

Document Routing Path State:

No administrative action is required if destination loss remains 0%.

Resolve WAN ISP Peering Saturation and BGP Path Congestion

Solution:

Root Cause: WAN Transit Provider Congestion or Suboptimal BGP Routing

When packet loss or latency spikes begin at a specific upstream hop (e.g., an ISP peering exchange point) and persist consistently across all subsequent hops through to the target destination, true path packet loss is occurring due to link saturation or asymmetric BGP routing.

# Step-by-Step Fix:

Execute Bidirectional MTR Diagnostics:

Run MTR from client to server AND from server back to client (reverse path) to detect asymmetric path failures:

bash
   mtr -rw -c 200 target-domain.com

Identify Autonomous System (AS) Boundary Failures:

Run MTR with AS number display enabled to pinpoint which service provider network introduces the drop:

bash
   mtr -z -c 100 target-domain.com

Perform TCP Port-Specific Path Tracing:

Ensure firewall policies aren't dropping specific traffic protocols:

bash
   traceroute -T -p 80 target-domain.com

Remediate Upstream Transit Issues:

For Enterprise Networks: Force BGP path prepend or alter Local Preference to reroute traffic away from the degraded transit provider.

For End Users: Connect to a SD-WAN or corporate VPN node to bypass congested ISP peering points.

What protocol-level or packet transmission anomaly is causing throughput degradation?

Packet fragmentation drops, PMTUD blackhole routers, or ICMP Fragmentation Needed packets blocked
High TCP Retransmission rates, TCP Window scaling drops, or bandwidth bottlenecks detected via iperf3 and Wireshark

Fix Path MTU Discovery (PMTUD) Blackholes and TCP MSS Clamping

Solution:

Root Cause: Path MTU Mismatch & ICMP Type 3 Code 4 (Fragmentation Needed) Blockade

When network packets exceed the Maximum Transmission Unit (MTU) of an intermediate link (common with IPsec/GRE tunnels or PPPoE connections), routers drop the packet and return an ICMP Destination Unreachable: Fragmentation Needed packet. If a firewall blocks this ICMP message, Path MTU Discovery (PMTUD) fails, resulting in a 'PMTUD Blackhole' where small TCP handshakes succeed, but large data transfers lock up and time out.

# Step-by-Step Fix:

Determine Maximum Unfragmented Path MTU:

Run ICMP ping tests with the Don't Fragment (DF) flag set:

Windows:

cmd
   ping -f -l 1472 target-domain.com

Linux:

bash
   ping -M do -s 1472 target-domain.com

Lower packet payload size (-l or -s) by 10-byte increments until pings succeed without fragmentation messages. Add 28 bytes (20-byte IP header + 8-byte ICMP header) to calculate actual Path MTU.

Adjust Interface MTU (If Local Interface exceeds Path MTU):

Set interface MTU to match the discovered path maximum (e.g., 1492 for PPPoE or 1400 for VPNs):

bash
   sudo ip link set dev eth0 mtu 1492

Configure TCP MSS Clamping on Router / Gateway:

Clamp maximum segment size (MSS) for TCP SYN packets to automatically fit PMTUD:

bash
   sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Isolate Bandwidth Bottlenecks and Excessive TCP Retransmissions via iperf3 & Wireshark

Solution:

Root Cause: Excessive TCP Packet Losses, Dup ACKs, and Socket Buffer Exhaustion

When packet drops occur under load, TCP reliability mechanisms trigger Fast Retransmit and TCP Congestion Control window reduction (e.g., CUBIC or BBR). Severe TCP retransmissions starve socket buffers, leading to rapid throughput collapse even on high-bandwidth links.

# Step-by-Step Fix:

Perform Parallel TCP Throughput Test with iperf3:

Run multi-stream test to evaluate network throughput and packet drops:

bash
   iperf3 -c target-server-ip -P 8 -t 30 -R

Check output for high Retr (Retransmission) counts per stream.

Capture and Analyze Packets using tshark / Wireshark:

Capture network traffic on the local interface filtering for TCP analysis flags:

bash
   sudo tshark -i eth0 -f "tcp port 443" -Y "tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.duplicate_ack" -c 500

Check Operating System TCP Memory Buffer Settings:

Optimize Linux TCP receive/send window parameters in /etc/sysctl.conf for high Bandwidth-Delay Product (BDP) links:

text
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.ipv4.tcp_rmem = 4096 87380 16777216
   net.ipv4.tcp_wmem = 4096 65536 16777216
   net.ipv4.tcp_congestion_control = bbr

Apply Sysctl Configuration:

bash
   sudo sysctl -p

Related Diagnostic Guides

Google Account Suspicious Activity? How to Check for Unknown Devices

Microsoft Account Hacked? How to Recover and Secure Your Account

Fast Charging Not Working? How to Check USB PD and Quick Charge Support

Laptop Using Integrated Graphics Instead of Dedicated GPU? Here's How to Fix It

Google Family Link Not Blocking Apps? Here's How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website