How to Determine Whether Packet Loss Is Local or Network Related on Linux

Packet loss troubleshooting can become difficult because the symptoms often look similar regardless of where the problem actually occurs. A slow application, unstable SSH session, failed API request, or poor storage performance may all eventually lead an administrator to suspect that packets are being dropped somewhere along the communication path.

The real challenge in packet loss troubleshooting is not simply proving that packets are being lost, but determining where the loss happens. A Linux server can lose packets because of local interface errors, overloaded queues, kernel processing limits, switch problems, upstream congestion, firewall behavior, or issues much farther away from the system being investigated.

A useful troubleshooting process therefore needs to separate the local host from the network around it. Instead of immediately blaming the switch, router, or remote server, the investigation should move progressively from the Linux interface toward the destination, collecting evidence at each layer.

Start by Confirming That Packet Loss Really Exists

The first mistake during packet-loss troubleshooting is relying only on application symptoms. A delayed web request or interrupted SSH session does not automatically mean packets are being discarded.

A simple starting point is ping:

ping -c 20 192.168.1.1

The summary shows how many packets were transmitted, received, and lost.

For example:

20 packets transmitted, 20 received, 0% packet loss

If loss is reported, repeat the test against several targets. The important detail is not only whether packets are lost, but where the loss begins.

A practical sequence might be:

ping -c 20 127.0.0.1
ping -c 20 <local_interface-IP>
ping -c 20 <default-gateway>
ping -c 20 <remote-host>

These four tests examine progressively larger parts of the communication path (from the local system to the destination system).

If the loopback test fails, the problem is clearly local to the system. This situation is uncommon, but it immediately changes the direction of the investigation.

If the local interface IP works but the default gateway shows loss, the issue is more likely associated with the interface, local cabling, VLAN, virtual switch, physical switch, or Layer 2 path.

If the gateway is completely stable while a remote destination loses packets, the investigation should move beyond the local segment.

Check the Linux Interface Counters

Before investigating routers or remote networks, inspect the network interface itself.

Use:

ip -s link

The command displays packet statistics for every interface, including received packets, transmitted packets, errors, dropped packets, overruns, and other counters.

A typical interface may display something similar to:

RX:  bytes  packets  errors  dropped  missed  mcast
     984321  10542    0       0        0       241

TX:  bytes  packets  errors  dropped  carrier  collsns
     756221  8211     0       0        0        0

For example:

💡 Do not focus only on the absolute values. A server that has been running for several months may already contain old errors that are no longer relevant. What matters during troubleshooting is whether the counters continue increasing while the problem occurs.

Run the command once (replace the eth0 with your interface, if necessary):

ip -s link show eth0

Generate or observe traffic for a few minutes and run it again. If errors or dropped increase consistently, there is strong evidence that the problem is close to the Linux host.

RX errors may indicate problems involving the physical interface, driver, cable, transceiver, switch port, or frame reception.

Dropped packets require more careful interpretation because packets can also be discarded when the kernel cannot process incoming traffic fast enough, for example.

Inspect Link Negotiation and Physical Characteristics

When interface errors are increasing, verify the negotiated connection. For Ethernet interfaces, ethtool is extremely useful:

ethtool eth0

Pay attention to values such as:

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

Example:

A mismatch between expected and negotiated speed can explain severe performance degradation.

Duplex problems are less common on modern networks using auto-negotiation, but they should still be considered when working with older devices, unusual switch configurations, or manually configured interfaces.

Driver statistics can provide additional clues:

ethtool -S eth0

The available counters depend on the network adapter and driver, but you may see statistics related to CRC errors, missed packets, queue drops, buffer exhaustion, or hardware-specific receive failures.

Repeated CRC-related errors, for example, strongly suggest investigating the physical path rather than blaming TCP or the application.

Test the Default Gateway Separately

The default gateway is one of the most useful reference points during this type of investigation.

Find it with:

ip route

A typical result may look like:

default via 192.168.10.1 dev eth0 proto static

Then test it directly:

ping -c 100 192.168.10.1

If packet loss already occurs between the server and its gateway, troubleshooting the internet or a remote data center is premature.

At that point, investigate components such as:

• The Linux network interface;
• Virtual NIC or hypervisor networking;
• Network cable or transceiver;
• Access switch;
• VLAN configuration;
• Bonding or teaming;
• Local firewall processing;
• Interface congestion.

If the gateway responds perfectly while a remote destination shows loss, the local Ethernet segment becomes less suspicious. This does not prove that the server is completely healthy, but it provides an important boundary.

Compare Multiple Destinations

A single destination can easily mislead the investigation.

Suppose this test reports 8% loss:

ping -c 100 server.example.net

That does not prove the local network is losing packets.

The destination may intentionally rate-limit ICMP, the remote firewall may deprioritize ping replies, or an intermediate router may treat ICMP differently from production traffic.

Compare several destinations instead:

ping -c 50 <gateway>
ping -c 50 <internal-server>
ping -c 50 <remote-server-A>
ping -c 50 <remote-server-B>
ping -c 50 <remote-server-C>

Patterns are much more valuable than isolated results:

• If every destination, including the gateway, shows loss, look locally.

• If local systems remain stable but several external destinations exhibit similar loss, investigate the upstream network.

• If only one specific remote host shows problems, the issue may be located near that host or somewhere along its particular route.

Use MTR to Observe the Path

mtr combines characteristics of ping and traceroute, making it useful for identifying where communication quality appears to change.

A report can be generated with:

mtr -rwzbc 10 example.com

For example:

Depending on the installed version, options may differ slightly, but the objective is to collect repeated measurements across the route rather than relying on a single traceroute.

The output may show something similar to:

HOST: linux01
  1. 192.168.10.1       0.0%
  2. 10.20.0.1          0.0%
  3. 172.18.50.1        8.0%
  4. 203.0.113.10       0.0%
  5. destination        0.0%

This example demonstrates an important troubleshooting rule:

• Loss shown at one intermediate hop does not necessarily mean that router is actually dropping forwarding traffic.

• Routers frequently rate-limit or deprioritize ICMP responses directed at themselves. If subsequent hops return normally, the apparent loss at that intermediate hop is usually not relevant.

Real path loss becomes more convincing when packet loss begins at one hop and continues through every following hop, including the final destination.

For example:

1. gateway             0.0%
2. router-a            0.0%
3. router-b           12.0%
4. router-c           11.0%
5. destination        12.0%

That pattern deserves investigation around hop 3 or the link immediately before it.

Do Not Trust ICMP Alone

Ping is useful, but production applications normally use TCP or UDP. A firewall or router may handle ICMP differently from HTTPS, SSH, database, or storage traffic.

For TCP-based testing, tools such as mtr may support TCP mode:

mtr --tcp --port 443 example.com

You can also use traceroute with TCP when supported:

traceroute -T -p 443 example.com

Testing the actual application port reduces the chance of drawing conclusions from ICMP-specific behavior.

For example, if ICMP appears unstable but TCP connections to port 443 remain completely healthy, the apparent packet loss may simply reflect ICMP filtering or rate limiting.

Look for Packet Drops Inside the Kernel

Not all locally dropped packets appear as physical interface errors. Linux maintains additional network statistics that can expose problems inside the networking stack.

A useful command is:

netstat -s

or, on modern systems:

nstat

Linux maintains additional statistics that can reveal packets dropped while they are being processed by the kernel network stack.

If the sysstat package is installed, softnet activity can be monitored with:

sar -n SOFT 1 10

This is particularly useful when investigating whether the system is struggling to process incoming packets because of CPU pressure or high packet rates.

If sar is not available, first verify whether the sysstat package is installed:

rpm -q sysstat

On RHEL-compatible systems, it can normally be installed with:

dnf install sysstat

Linux also exposes the underlying softnet counters directly through:

cat /proc/net/softnet_stat

Because these values are presented in a relatively low-level format, sar -n SOFT is usually easier to interpret during routine troubleshooting.

For interface throughput and packet rates, you can separately use:

sar -n DEV 1 10

High packet rates combined with increasing softnet drops and CPU saturation can indicate that packet loss is occurring locally because the server cannot process network traffic quickly enough. High traffic combined with CPU saturation may cause the system to struggle with packet processing even when the interface itself is physically healthy.

Check CPU pressure with:

top

or:

mpstat -P ALL 1

If one or more CPUs are saturated while network drops increase, the issue may be local processing capacity rather than the external network.

This is particularly relevant on high-throughput servers, firewalls, virtualization hosts, storage nodes, and systems receiving large numbers of small packets.

Capture Traffic with tcpdump

When the available counters are not enough, packet capture can help determine whether packets actually reach the server.

For example:

tcpdump -ni eth0 host 192.168.20.50

For TCP traffic, look for:

• retransmissions;
• repeated SYN packets;
• duplicate acknowledgments, or;
• unusual resets.

Imagine a client repeatedly sends TCP SYN packets but the Linux server never captures them.

That strongly suggests the packets are being lost before reaching the host. If the SYN packets appear in the capture and the server sends SYN-ACK responses, but the client never receives them, the problem may exist on the return path.

This distinction is important because network routes can be asymmetric. The path from client to server may be completely different from the path used for the response.

Packet capture on both endpoints is even more valuable when possible.

If a packet appears in the sending host capture but never appears on the receiving host, the network between them becomes the primary suspect.

Check for MTU Problems

Not every apparent packet-loss problem affects small packets. MTU mismatches can allow simple ping tests to succeed while larger application packets fail.

A practical test is:

ping -M do -s 1472 <destination>

For a standard Ethernet MTU of 1500 bytes, a 1472-byte ICMP payload plus IP and ICMP headers reaches the expected frame size.

If smaller packets succeed but larger packets consistently fail, investigate MTU settings across the route.

Check the local interface with:

ip link show eth0

In environments using tunnels, VPNs, VXLAN, virtualization overlays, or jumbo frames, MTU inconsistencies deserve particular attention.

Build Evidence Before Escalating

A strong packet-loss investigation should eventually produce a clear boundary. Instead of reporting only that “the network is dropping packets,” collect evidence such as:

Loopback:            0% loss
Local interface IP:  0% loss
Default gateway:     0% loss
Internal server:     0% loss
Remote destination:  9% loss

Combine that with interface counters, MTR results, packet captures, and timestamps.

This information gives the network team something actionable and prevents unnecessary troubleshooting on components that are already behaving correctly.

The same approach is useful in the opposite direction. If interface drops increase while the default gateway is losing packets, there is little reason to begin with the WAN provider.

Packet loss becomes much easier to investigate when the path is divided into small sections. Start at the Linux host, verify the interface, establish whether the local gateway is stable, and then move outward only when the evidence supports it. In many cases, a few carefully chosen tests are enough to show whether the problem belongs to the server, the local network, or somewhere farther along the route.