ADAM PULSE How to troubleshoot packet loss and find where it starts
Your internet connection is online.
The firewall is responding.
The speed test looks acceptable.
But Zoom freezes.
VoIP calls sound distorted.
Cloud applications hesitate.
Users complain about intermittent connectivity.
The problem may be packet loss.
Finding packet loss is relatively easy.
Finding where the packet loss starts is the more important challenge.
Effective packet loss troubleshooting means testing different points across the network, comparing results, understanding how diagnostic tools behave, and gathering enough evidence to isolate whether the problem is occurring inside the local network, at the firewall, across the carrier circuit, or somewhere farther upstream.
This guide explains how to troubleshoot packet loss systematically and why continuous network monitoring can make intermittent packet loss significantly easier to diagnose.
What Is Packet Loss?
Networks move information in units called packets.
Packet loss occurs when one or more packets fail to reach their intended destination.
Some applications can retransmit missing information.
Real time applications often cannot wait.
That is why packet loss can be particularly disruptive to:
- Zoom
- VoIP
- Video conferencing
- Contact center applications
- Remote desktop
- VPN connections
- Cloud applications
- Interactive business systems
Cisco describes packet drops as occurring when network devices cannot forward packets, with causes that can include insufficient buffer capacity, CPU overload, congestion, configuration issues, or other network conditions.
What Does Packet Loss Look Like to a User?
Users rarely report:
"I am experiencing packet loss."
They report symptoms.
Common complaints include:
- The internet keeps freezing
- Zoom video freezes
- Audio cuts out
- Calls sound robotic
- Words disappear during conversations
- Remote desktop sessions pause
- Applications time out
- VPN sessions disconnect
- Websites occasionally fail to load
- The network works and then suddenly stops
The first troubleshooting challenge is recognizing that these symptoms may be related to inconsistent packet delivery rather than insufficient bandwidth.
What Causes Packet Loss?
There is no single cause.
Possible causes include:
- Network congestion
- Interface errors
- Buffer exhaustion
- CPU overload
- Failing network hardware
- Damaged cabling
- WiFi interference
- Firewall problems
- Routing problems
- ISP problems
- WAN congestion
- SD WAN behavior
- Configuration issues
- Traffic storms
- Application infrastructure problems
Cisco specifically identifies congestion, buffer issues, CPU utilization, physical layer problems, interface conditions, traffic storms, and configuration related issues among areas to investigate when diagnosing packet drops and latency.
How Do You Test for Packet Loss?
A simple starting point is ping.
Send a larger series of ping requests to a known destination and compare the number sent with the number received.
For example:
100 packets sent
96 packets received
4 packets lost
That indicates packet loss during that particular test.
But do not stop there.
A packet loss test tells you:
Loss exists between this source and this destination during this time period.
It does not automatically tell you:
Where is the packet loss occurring?
That requires isolation.
How Do You Find Where Packet Loss Starts?
Break the network into logical test points.
For a typical branch location, that might look like:
Device → Switch → Gateway → Firewall → ISP Gateway → Internet → Application
Then test progressively outward.
For example:
Test 1: Local gateway
Is packet loss present?
If yes, the problem may exist inside the local network.
If no, move outward.
Test 2: Firewall
Is the firewall reachable consistently?
If yes, continue.
Test 3: ISP gateway
Does loss begin here?
If yes, investigate the WAN interface, handoff, modem, ONT, cabling, or carrier path.
Test 4: External destination
If internal targets remain healthy but external targets show consistent loss, investigate the upstream network.
The objective is to identify the point where healthy performance becomes unhealthy performance.
Packet Loss Example 1: Local Network Problem
Imagine these results:
Local gateway: 7 percent loss
Firewall: 7 percent loss
ISP gateway: 7 percent loss
Internet destination: 7 percent loss
Because the loss is already visible at the local gateway, you should investigate the local network before blaming the carrier.
Possible areas include:
- WiFi
- Switching
- Cabling
- Network interface
- Local congestion
- Gateway equipment
Packet Loss Example 2: Possible WAN or Carrier Problem
Now consider:
Local gateway: 0 percent loss
Firewall: 0 percent loss
ISP gateway: 4 percent loss
Internet destination: 5 percent loss
The evidence points toward the WAN side of the network and deserves investigation.
That does not automatically prove the ISP is responsible, but it narrows the troubleshooting area considerably.
Packet Loss Example 3: Intermediate Hop Appears Bad
Suppose MTR reports:
Hop 1: 0 percent loss
Hop 2: 0 percent loss
Hop 3: 60 percent loss
Hop 4: 0 percent loss
Destination: 0 percent loss
Is Hop 3 dropping 60 percent of your production traffic?
Probably not.
If Hop 3 were truly discarding 60 percent of traffic being forwarded through it, subsequent hops would generally also reflect that degradation.
The more likely explanation is that Hop 3 is limiting or deprioritizing responses to diagnostic traffic.
This is one of the most common mistakes when interpreting traceroute and MTR.
Why Does MTR Show Packet Loss at One Hop but Not the Destination?
Routers are designed primarily to forward traffic.
Responding to diagnostic probes may receive lower priority.
Some routers:
- Rate limit ICMP responses
- Deprioritize diagnostic traffic
- Respond inconsistently
- Block certain probe types
Therefore:
Loss at an intermediate hop does not necessarily equal forwarding loss.
Examine whether the problem continues through later hops and reaches the final destination.
Can Traceroute Find Packet Loss?
Traceroute provides valuable path information.
It can help you identify:
- Network hops
- Routing changes
- Where latency appears
- Where responses stop
- Potential upstream paths
But traceroute is primarily a route diagnostic tool.
Use it together with repeated measurements, MTR, interface statistics, device logs, packet captures, and historical monitoring when appropriate.
How Does MTR Help Troubleshoot Packet Loss?
MTR repeatedly measures a network path rather than showing only one snapshot.
Cloudflare describes MTR as combining traceroute and ping to display latency and packet loss across network hops.
This can help identify:
- Persistent loss
- Intermittent loss
- Latency changes
- Route behavior
- Potential congestion points
- Differences between network paths
MTR becomes particularly useful when a connection fluctuates rather than completely failing.
Can WiFi Cause Packet Loss?
Yes.
Wireless networks introduce variables that do not exist on wired connections.
Potential causes include:
- Weak signal
- Radio interference
- Congested channels
- Too many connected devices
- Poor access point placement
- Roaming
- Building materials
- Distance
A very useful troubleshooting comparison is:
Wired device versus WiFi device
If wired connectivity remains healthy while wireless devices experience loss, investigate the wireless environment before escalating the ISP.
Can a Firewall Cause Packet Loss?
Yes.
Possible firewall related causes include:
- Resource exhaustion
- CPU spikes
- Interface errors
- Buffer problems
- Traffic inspection
- VPN processing
- SD WAN behavior
- Routing
- Configuration issues
Review firewall logs and interface statistics at the same time the packet loss occurs whenever possible.
Correlation is important.
Can the ISP Cause Packet Loss?
Yes.
Carrier related packet loss can originate from:
- Circuit problems
- Provider congestion
- Physical network faults
- Provider equipment
- Upstream routing
- Carrier peering
- Regional incidents
But telling the ISP:
"Our users are seeing packet loss"
is less effective than providing measurable evidence.
How Do You Prove Packet Loss to an ISP?
Collect objective historical data.
Useful evidence includes:
- Exact start time
- Exact end time
- Affected circuit
- Local gateway results
- Firewall results
- ISP gateway results
- External destination results
- Packet loss percentage
- Latency
- Route information
- Recurrence history
Consider the difference between these two escalation messages.
Version 1
"Our internet keeps dropping."
Version 2
"Our local gateway and firewall remained available, but external packet loss began at 2:14 PM and reached 8 percent until 2:31 PM. The same condition occurred at 1:48 PM yesterday."
The second message gives the carrier something actionable to investigate.
Why Is Intermittent Packet Loss So Difficult to Troubleshoot?
Because it disappears.
A typical incident might look like:
1:32 PM: Packet loss begins
1:35 PM: Users notice freezing
1:39 PM: Help desk ticket created
1:47 PM: Engineer starts testing
1:49 PM: Connection recovers
The engineer runs a test.
Zero packet loss.
That does not mean the original problem did not happen.
It means the diagnostic test occurred after the condition disappeared.
This is why historical network monitoring becomes so important.
What Is Continuous Packet Loss Monitoring?
Continuous monitoring repeatedly evaluates network performance instead of waiting for someone to report a problem.
Monitoring can help establish:
- When packet loss began
- How long it lasted
- How severe it became
- Whether latency increased simultaneously
- Which site was affected
- Which circuit was affected
- Whether the gateway remained reachable
- Whether the firewall remained reachable
- Whether the condition has happened before
That turns an intermittent complaint into a timeline.
Why Are Network Baselines Important for Packet Loss?
Historical baselines help establish what normal behavior looks like.
For example:
Site A normally has no measurable packet loss.
Site B occasionally shows brief periods of minor loss.
Site C experiences loss every afternoon.
Those patterns lead to very different troubleshooting decisions.
Without historical data, each event appears isolated.
With historical data, recurring patterns become visible.
How Does Packet Loss Affect Zoom?
Zoom evaluates network parameters including packet loss, latency, jitter, and codec efficiency when assessing perceived audio and video quality.
Poor network conditions can contribute to frame loss, audio interruptions, reduced video quality, and other problems.
This is why a speed test alone is not enough when troubleshooting Zoom quality.
The important question is not simply:
How much bandwidth do we have?
It is also:
How consistently is the network delivering traffic?
How Does Packet Loss Affect VoIP?
Voice traffic is especially sensitive to missing packets because conversations occur in real time.
Packet loss can contribute to:
- Missing words
- Robotic audio
- Audio distortion
- One way conversation symptoms
- Call quality complaints
- Dropped sessions in severe cases
Cisco has long emphasized delay, jitter, and packet loss as important measurements when evaluating voice networks.
What Should You Monitor Along with Packet Loss?
Packet loss should rarely be analyzed alone.
Correlate it with:
- Latency
- Jitter
- Availability
- Gateway status
- Firewall status
- Circuit availability
- Interface errors
- CPU
- Memory
- Route behavior
- Application performance
Correlated measurements tell a much stronger story than a single metric.
The ADAM Pulse Approach to Packet Loss
ADAM Pulse is designed around a simple objective:
Find where network degradation begins.
Instead of asking only:
Is the site up?
ADAM Pulse helps organizations investigate questions such as:
Is the local gateway healthy?
Is the firewall responding?
Is the carrier circuit responding?
When did packet loss begin?
Did latency increase at the same time?
How long did the condition last?
Has it happened before?
Does the evidence point toward the carrier or local network?
Do Not Just Detect Packet Loss. Build the Evidence.
Packet loss is not valuable information merely because it exists.
The real value comes from understanding:
Where
When
How much
How often
What else changed
That context turns packet loss from a user complaint into actionable network intelligence.
Stop Waiting for Users to Tell You the Network Is Having Problems
Intermittent packet loss can disappear before anyone begins troubleshooting it.
ADAM Pulse provides managed network monitoring designed to give organizations historical visibility into network availability, latency, packet loss, SLA performance, gateways, circuits, and recurring network behavior.
If your organization depends on internet circuits, Zoom, VoIP, cloud applications, remote access, or multiple business locations, understanding packet loss before and during an incident can dramatically improve troubleshooting.
Do not just ask whether packets are being lost.
Find where the loss begins and build the evidence required to fix it.
Learn more about ADAM Pulse and talk with USA Telecom about proactive network monitoring.
Frequently asked questions
What Is Packet Loss?
Networks move information in units called packets. Packet loss occurs when one or more packets fail to reach their intended destination. Some applications can retransmit missing information.
What Causes Packet Loss?
There is no single cause. Possible causes include: Cisco specifically identifies congestion, buffer issues, CPU utilization, physical layer problems, interface conditions, traffic storms, and configuration related issues among areas to investigate when diagnosing packet drops and latency.
How Do You Test for Packet Loss?
A simple starting point is ping. Send a larger series of ping requests to a known destination and compare the number sent with the number received. For example:
How Do You Find Where Packet Loss Starts?
Break the network into logical test points. For a typical branch location, that might look like: Then test progressively outward.
Why Does MTR Show Packet Loss at One Hop but Not the Destination?
Routers are designed primarily to forward traffic. Responding to diagnostic probes may receive lower priority. Some routers:
Can Traceroute Find Packet Loss?
Traceroute provides valuable path information. It can help you identify: But traceroute is primarily a route diagnostic tool.
How Does MTR Help Troubleshoot Packet Loss?
MTR repeatedly measures a network path rather than showing only one snapshot. Cloudflare describes MTR as combining traceroute and ping to display latency and packet loss across network hops. This can help identify:
Can WiFi Cause Packet Loss?
Yes. Wireless networks introduce variables that do not exist on wired connections. Potential causes include:
Can a Firewall Cause Packet Loss?
Yes. Possible firewall related causes include: Review firewall logs and interface statistics at the same time the packet loss occurs whenever possible.
How Do You Prove Packet Loss to an ISP?
Collect objective historical data. Useful evidence includes: Consider the difference between these two escalation messages.
Sources
- Cisco — Troubleshoot Packet Drops. Congestion, buffer exhaustion and interface errors as drop causes, and their effect on throughput and retransmission.
- Cisco — Understanding Jitter in Packet Voice Networks. Delay, jitter and packet loss as the determinants of voice quality.
- Zoom — Using the Zoom Dashboard. Administrator access to per-meeting latency, jitter and packet loss.
- IETF — RFC 792: Internet Control Message Protocol. The protocol underneath ping and traceroute, and why devices may deprioritise or drop ICMP.
Network symptoms should be interpreted in context. A single test from a single location at a single moment rarely proves where a fault sits — correlate against history, test from more than one point, and preserve evidence before changing configuration.
USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.