How to Troubleshoot Intermittent Packet Loss

Intermittent packet loss is one of those network problems that can waste an enormous amount of time.

The network works. Then it doesn’t. A Teams call becomes choppy, an RDP session freezes for a few seconds, an application times out, or someone reports that “the network is slow”. By the time you start looking, everything appears normal again.

The first mistake is assuming that every lost ping represents a lost packet affecting the application.

Before replacing cables, changing QoS or blaming the ISP, you need to establish whether you are actually seeing packet loss and, if you are, where it starts.

This is the process I would use:

1. Determine whether the apparent loss is real or simply ICMP being deprioritised.
2. Prove the problem with sustained tests.
3. Read the path correctly rather than blaming the first hop showing loss.
4. Check physical interface counters.
5. Correlate the loss with other activity.
6. Test for MTU problems.
7. Capture traffic when the problem is actually occurring.
8. Understand how NIC offloading can distort a host-side capture.
9. Escalate to the ISP with evidence.
10. Validate the fix under the same conditions that originally caused the problem.

1. Is it actually packet loss?

This is the question I would answer first.

A common troubleshooting mistake is running:

ping 10.10.1.1

seeing a few timeouts and immediately concluding that the network is dropping packets.

That isn’t necessarily what is happening.

Routers and switches commonly treat traffic destined to their own management or control plane differently from traffic they are forwarding. ICMP responses can be rate-limited or deprioritised, so a router may fail to respond to some pings while continuing to forward application traffic normally.

That is why loss to an intermediate device is not automatically evidence of loss through that device.

For example:

HOST: workstation
                                  Loss%   Snt   Last   Avg  Best  Wrst
  1. 10.10.1.1                     18.0%  1000   1.2   1.1   0.8   4.2
  2. 10.10.2.1                      0.0%  1000   2.8   2.9   2.4   6.1
  3. 172.16.20.1                    0.0%  1000   8.4   8.7   7.9  14.2
  4. 203.0.113.10                   0.0%  1000  14.1  14.3  13.6  21.5

The 18% loss at hop 1 looks alarming.

But the following hops and final destination show 0% loss.

That is very different from:

HOST: workstation
                                  Loss%   Snt   Last   Avg  Best  Wrst
  1. 10.10.1.1                      0.0%  1000   1.2   1.1   0.8   4.2
  2. 10.10.2.1                      0.0%  1000   2.8   2.9   2.4   6.1
  3. 172.16.20.1                   12.0%  1000   8.4   8.7   7.9  14.2
  4. 203.0.113.10                  12.0%  1000  14.1  14.3  13.6  21.5

Here the loss begins at hop 3 and continues to the destination.

That gives you much stronger evidence that something is happening around that point in the path.

The important lesson is simple:

Loss at an intermediate hop that does not continue to later hops is not, by itself, proof of forwarding loss.

2. Prove the problem with sustained tests

Once you know what you are looking for, generate enough data to see the pattern.

On Windows:

ping -n 5000 -l 1400 10.10.1.1

The options mean:

• -n 5000 sends 5,000 requests
• -l 1400 sends a 1,400-byte ICMP data payload

For a basic test:

ping -n 5000 10.10.1.1

The destination matters. Test something local first, then progressively further away.

For example:

Client
  |
  +-- Default gateway
  |
  +-- Local server
  |
  +-- WAN router
  |
  +-- Remote site
  |
  +-- Internet destination

If the client loses packets to its own gateway, that points in a very different direction from loss only to an Internet destination.

Use pathping on Windows

For a Windows path test:

pathping -q 50 -p 250 10.10.1.1

-q 50 sends 50 queries to each hop. The default is 100, so specifying 100 would not actually change anything.

-p 250 sets the interval between consecutive pings to 250 milliseconds, which is also the default. The full option list is in Microsoft’s pathping reference.

Also be patient with pathping.

It first discovers the route and then spends time collecting statistics. With the default interval, a longer path can take several minutes to complete.

If someone starts pathping, waits 30 seconds and kills it because they think it has hung, they haven’t actually collected the useful part of the test.

MTR on Linux and macOS

MTR is particularly useful for longer-running tests:

mtr -r -c 1000 10.10.1.1

Here:

• -r produces a report
• -c 1000 sends 1,000 probes

Don’t just look at the percentage. Look at where the loss begins and whether it continues to the destination.

3. Read MTR output properly

MTR becomes particularly valuable when the problem is intermittent because it gives you a view of loss and latency across the path.

For example:

HOST: PC01
                                    Loss%   Snt   Last   Avg  Best  Wrst
  1. 192.168.1.1                      0.0%  1000   1.0   1.1   0.7   4.5
  2. 10.20.0.1                       35.0%  1000   4.2   4.1   3.8   8.9
  3. 10.20.10.1                       0.0%  1000   6.2   6.3   5.7  11.2
  4. 203.0.113.1                      0.0%  1000  18.4  18.5  17.9  25.1

It is very easy to look at hop 2 and say:

“There is 35% packet loss at that router.”

But that conclusion isn’t justified by this output alone.

If hop 2 is simply limiting its ICMP responses while forwarded traffic continues normally, the apparent loss can disappear at the following hop.

Compare that with:

Hop 1     0%
Hop 2    35%
Hop 3    35%
Hop 4    35%

Now you have much stronger evidence that the problem starts around hop 2 or the link beyond it.

MTR isn’t a magic tool that tells you which router is broken. It gives you evidence that needs to be interpreted alongside the rest of the path.

4. Check the physical layer

Once you have established that the loss is real, look at the interfaces.

On a Cisco switch:

Switch# show interfaces GigabitEthernet1/0/10

For a quick check:

Switch# show interfaces GigabitEthernet1/0/10 | include error|drops|CRC

And across the switch:

Switch# show interfaces counters errors

You might see:

Port        Align-Err  FCS-Err  Xmit-Err  Rcv-Err  UnderSize  OutDiscards
Gi1/0/10           0      127         0      127          0            0
Gi1/0/11           0        0         0        0          0          842
Gi1/0/12           0        0         0        0          0            0

These counters don’t all mean the same thing.

CRC and FCS errors

Increasing CRC or FCS errors should send you towards the physical path.

Investigate:

• Patch leads
• Structured cabling
• Patch panels
• SFPs and transceivers
• NICs
• Interface hardware
• Duplex problems on older equipment

The important word is increasing.

A port having 127 CRC errors in its lifetime is different from a port accumulating another 127 errors while the user is experiencing packet loss.

Input errors

Input errors are a broader category and can represent several different conditions.

Don’t look at one input errors number and immediately conclude that the interface is receiving damaged packets. Drill into the individual counters.

Output drops

Output drops point in a different direction.

For example:

GigabitEthernet1/0/10 is up, line protocol is up
  Input queue: 0/2000/0/0
  Total output drops: 18472

Output drops can occur when traffic is competing for an interface and available output buffering is exhausted.

A faster interface feeding a slower interface, or several sources converging on one link, can create this condition.

So:

CRC/FCS errors
        ↓
Investigate physical layer

whereas:

Output drops
        ↓
Investigate congestion, utilisation and traffic patterns

Those are very different troubleshooting paths.

5. Correlate the loss with what else is happening

Intermittent problems often become much easier once you stop looking only at the network.

Suppose the loss occurs every night between 11pm and midnight.

What happens at 11pm?

Look at:

• Backup jobs
• Cloud synchronisation
• Replication
• Large file transfers
• Security scans
• Software deployment
• Virtual machine backups
• WAN replication
• Scheduled updates

Record the exact time of the loss and compare it against your monitoring systems.

For example:

22:55   Normal traffic
23:00   Backup starts
23:04   WAN utilisation reaches 95%
23:06   Packet loss begins
23:21   Packet loss peaks
23:42   Backup finishes
23:43   Packet loss disappears

That is much stronger evidence than saying:

“The network seems to get worse at night.”

If the WAN interface also starts accumulating output drops at exactly the same time, you now have multiple pieces of evidence pointing towards congestion.

6. Test for MTU problems

MTU problems can produce some particularly strange symptoms.

You might find that:

• Small pings work
• Large packets fail
• Some websites work while others don’t
• VPN traffic behaves differently
• A particular application consistently times out

On Windows, test an IPv4 path with:

ping -f -l 1472 8.8.8.8

-f sets the IPv4 Don’t Fragment flag.

-l sets the ICMP data size. Windows then adds an 8-byte ICMP header and a 20-byte IPv4 header:

1472 + 8 + 20 = 1500

So 1,472 bytes tests whether a normal 1,500-byte IPv4 packet can traverse the path without fragmentation.

On Linux:

ping -M do -s 1472 8.8.8.8

If the larger packet fails, reduce the payload:

ping -f -l 1464 8.8.8.8
ping -f -l 1452 8.8.8.8
ping -f -l 1400 8.8.8.8

If smaller packets succeed while larger packets fail, investigate the path MTU.

This is particularly relevant across:

• IPsec VPNs
• GRE tunnels
• MPLS
• SD-WAN
• Cloud connectivity
• Other encapsulated links

Path MTU Discovery also relies on ICMP messages that tell the sender when fragmentation is required. Filtering those messages can create the classic situation where small packets work but larger application traffic does not.

7. Capture traffic when the problem is happening

When the basic tests don’t explain the problem, take a packet capture.

Wireshark is particularly useful for TCP-based applications. The full list of fields is in the Wireshark TCP display filter reference.

Filters that indicate loss

tcp.analysis.retransmission

A segment was retransmitted after the retransmission timer expired.

tcp.analysis.fast_retransmission

A segment was retransmitted after three duplicate ACKs, without waiting for the timeout. This is the faster recovery path and is worth distinguishing from a timeout-based retransmission.

tcp.analysis.duplicate_ack

The receiver is re-acknowledging the last in-order byte, which signals a gap in the stream.

tcp.analysis.out_of_order

A segment arrived when earlier segments are still missing. This can indicate reordering rather than loss.

Filters that often indicate a capture problem, not network loss

This distinction catches people out, and getting it wrong sends you chasing a fault that doesn’t exist.

tcp.analysis.lost_segment

Wireshark describes this as previous segments not captured, and specifically notes that it is common at the start of a capture. It means Wireshark didn’t see the segment. That is not the same as the network dropping it.

tcp.analysis.ack_lost_segment

Likewise, this flags a segment that was acknowledged but never appeared in the capture. Again, common at capture start, and often a sign that the capture device couldn’t keep up with the traffic rate rather than evidence of a network fault.

tcp.analysis.spurious_retransmission

The sender retransmitted a segment that had already been received. That usually points to an aggressive retransmission timeout rather than actual loss.

So a capture full of lost_segment entries isn’t automatically a network problem. Check whether your capture point could physically keep up before drawing conclusions.

Capture at more than one point

A large number of retransmissions is useful evidence, but it doesn’t tell you where the packet was lost.

If possible, capture at more than one point:

Client
  |
  | Capture 1
  |
Switch
  |
Firewall
  |
WAN
  |
  | Capture 2
  |
Server

If a segment appears at the first capture point but doesn’t appear at the second, you have narrowed down where to investigate.

8. Why your capture shows a 12,000-byte TCP segment on a 1500-MTU link

This catches people out when they first start analysing traffic on a server itself.

You may see something like:

Frame length: 12000 bytes

even though the network interface has a 1500-byte MTU.

That does not necessarily mean someone is sending 12,000-byte Ethernet frames across the network.

Features such as:

• TCP Segmentation Offload (TSO)
• Large Send Offload (LSO)
• Generic Segmentation Offload (GSO)
• Generic Receive Offload (GRO)

can allow the operating system or NIC to work with larger buffers before traffic is segmented into packets suitable for transmission.

A host-side capture can therefore show traffic that doesn’t correspond directly to individual packets on the wire.

This is important when troubleshooting packet loss because the capture can otherwise look completely wrong.

If you suspect an offload-related capture issue, temporarily disabling the relevant feature can be a useful diagnostic test.

It is not automatically the permanent fix.

Offloading exists to reduce CPU overhead and improve network performance. If disabling it makes the capture look normal, investigate the NIC driver, operating-system version and hardware compatibility rather than simply leaving every offload feature disabled in production.

If you need to know exactly what went onto the wire, a capture taken from another system, SPAN port or network tap is more representative than a capture taken from the endpoint itself.

9. Escalate to the ISP with evidence

If your testing points outside your network, don’t send the ISP a ticket saying:

“We’re getting packet loss.”

Give them something they can investigate.

Include:

• Source IP
• Destination IP
• Exact timestamps
• Time zone
• Packet-loss percentage
• Latency
• Whether the problem is continuous or intermittent
• Tests from more than one source if available
• MTR or pathping results
• Interface utilisation
• WAN interface errors or drops

For example:

2026-09-22 14:05-14:17 AEST

Source:
10.20.10.50

Destination:
203.0.113.50

Observed:
8-12% loss

Normal:
0% loss

MTR:
Loss begins after the provider handoff and continues to destination.

Local WAN interface:
0 CRC errors
0 input errors
0 output drops
No local saturation observed

That gives the provider something concrete to work with.

If the problem is intermittent, timestamps are particularly important because the provider needs to correlate your evidence against its own circuit and interface statistics.

10. Validate the fix

This is where network troubleshooting often stops too early.

Someone changes something, the user says “it seems better”, and the incident gets closed.

That isn’t really validation.

If the problem originally occurred during a particular condition, reproduce or monitor that condition after the change.

For example:

Before change:
23:00-23:30
8% packet loss
WAN utilisation 95%
Output drops increasing

Change:
Backup traffic moved to another window

After change:
23:00-23:30
0% packet loss
WAN utilisation 62%
0 output drops

That is a much stronger result.

For a physical fault, record the counters before and after the test.

If you need a clean counter baseline, Cisco provides:

Switch# clear counters GigabitEthernet1/0/10

But record the existing values first.

Clearing counters destroys the historical values you may need to understand the problem. On production infrastructure, don’t clear interface counters without considering who else relies on those counters for monitoring or troubleshooting.

After establishing your baseline, monitor the interface while the problem occurs.

The objective is not simply to make the symptom disappear. It is to establish that the evidence supporting the original diagnosis has disappeared as well.

A practical troubleshooting sequence

When someone reports intermittent packet loss, I would work through the problem in this order.

1. Test the local gateway

ping -n 1000 10.10.1.1

2. Test a known local resource

ping -n 1000 10.10.1.20

3. Test across the WAN

ping -n 1000 10.20.1.1

4. Examine the path

Windows:

pathping -q 50 -p 250 10.20.1.1

Linux/macOS:

mtr -r -c 1000 10.20.1.1

5. Check switch counters

Switch# show interfaces GigabitEthernet1/0/10 | include error|drops|CRC
Switch# show interfaces counters errors

6. Check for MTU problems

Windows:

ping -f -l 1472 8.8.8.8

Linux:

ping -M do -s 1472 8.8.8.8

7. Correlate timestamps

Look at:

• WAN utilisation
• Firewall utilisation
• Interface drops
• Backup activity
• Wireless events
• Device CPU
• Application monitoring

8. Capture the affected traffic

Look for:

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order

And treat these with more caution:

tcp.analysis.lost_segment
tcp.analysis.ack_lost_segment
tcp.analysis.spurious_retransmission

9. Check whether host offloading is affecting the capture

If the capture is being taken directly from the endpoint, consider TSO, LSO, GSO, GRO and checksum offloading before interpreting unusual packet sizes or checksums.

10. Make the change and test again

Don’t close the incident until you can demonstrate that the condition causing the problem has been removed or materially changed.

The important part about intermittent packet loss

The hardest part of intermittent packet loss isn’t knowing that ping, MTR, Wireshark and switch counters exist.

It’s knowing what the results actually mean.

A percentage beside a hop in MTR isn’t automatically packet loss.

A CRC counter isn’t the same problem as an output-drop counter.

A TCP retransmission proves something went wrong with the flow, but not necessarily where it happened.

A lost_segment flag may mean your capture missed the packet rather than the network dropping it.

A large TCP segment in a host capture doesn’t necessarily mean a large packet went onto the wire.

And disabling a NIC offload feature might prove that a driver or capture interaction is involved, but that doesn’t make disabling the feature the permanent fix.

The useful troubleshooting process is therefore:

1. Prove the loss.
2. Separate ICMP behaviour from real forwarding loss.
3. Find where the loss begins.
4. Check physical and interface counters.
5. Correlate the problem with traffic and timing.
6. Test MTU where appropriate.
7. Capture the affected traffic.
8. Account for host-side offloading and capture artefacts.
9. Fix the underlying cause.
10. Validate under the same conditions.

That gives you something much more useful than a list of possible causes: evidence you can use to explain exactly what happened and why the eventual fix worked.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.