Why Can't I See Packet Loss in Path Visualization?
When a user reports an issue like "choppy audio" or "lag/delay," you might check the Network > Overview view and see packet loss on the timeline. However, when you switch to the Network > Path Visualization view to find exactly where the loss is happening, the path might look completely clean.
This leads to the common question: "Why can you not show me the exact place where packet loss shown in the table data is on the path visualization?"
The short answer is that Network Overview and Path Visualization use two different methods to collect data.
Network Overview (End-to-End): Sends a continuous stream of packets directly to the target to check overall connection health. It is highly sensitive and quickly detects if the user is experiencing a poor connection.
Path Visualization (Hop-by-Hop): Sends fewer packets specifically to map the route step-by-step. Because it sends fewer packets, it might miss sporadic or short-lived loss events.
This is not a bug; it is two standalone tests that each collect their own data.
The two methods are documented in Network Tests Explained.
Troubleshooting Decision Tree
When you see packet loss in the Network Overview but not in Path Visualization, use this flowchart to isolate the fault domain (device vs. network vs. app) and determine your next steps.
Common Reasons for Missing Loss in Path Visualization
If the path looks clean but the user is experiencing issues, consider these common reasons:
Timing and Packet Count Differences
End-to-end measurement (Overview) sends a steady stream of packets, while path discovery sends only a few packets per step. If the network drop is very brief, the continuous stream will catch it, but the path discovery might miss it.
Packet Loss on the Target (the App Server)
Sometimes the network path is perfectly fine, but the destination server (the application) is dropping traffic. This can happen if:
The server is overwhelmed and cannot accept new connections.
The server is rate-limiting incoming traffic to protect itself.
The server's CPU or memory resources are exhausted.
Agent Count and Limited Visibility
If the packet loss is occurring in a specific network segment that only one user (or one agent) is traversing, it might be harder for Path Visualization to pinpoint. When multiple users from different locations test the same target, Path Visualization has more data points and can more easily highlight the problematic hop.
Actionable Remediation Steps
Here is how you can adjust your testing strategy to pinpoint the network issue and help resolve the user's ticket:
Review Multiple Test Rounds
Do not just look at a single snapshot in time. If a user is experiencing consistent "lag," review multiple rounds of Path Visualization data. Eventually, the path discovery process will likely catch the forwarding loss.
Increase the Number of Agents
If possible, add more agents to the test. More agents in different locations give a broader perspective and increase the chances of pinpointing where the loss is occurring, especially as paths converge closer to the target.
Run More Parallel Path Traces
You can increase the sensitivity of Path Visualization. In the test configuration, under the Advanced Configuration tab, change the No. of Path Traces from the default of 3 up to 10. This makes it much more likely to detect even minor packet loss along the path.
Check the Return Path (Agent-to-Agent)
Traffic often takes a different route back from the server to the user. If the forward path looks clean, the issue might be on the return path. Setting up an agent-to-agent test allows you to measure traffic in both directions independently, helping you isolate return path issues.
Technical Reference
For deeper root cause analysis and isolating fault domains, review the underlying measurement mechanics distinguishing transit anomalies from terminal node drops.
Probing Physics: End-to-End vs. Path Trace
End-to-End Measurement
50 packets per test round
Direct stream to target. Measures arrival timings or acknowledgment responses to calculate loss, latency, and jitter.
Data payload ACKs or ICMP Echo Replies.
Path Discovery
3 packets per TTL
Paris Traceroute-based. Probes sent with sequentially increasing TTL. Nodes return ICMP Type 11 (Time Exceeded).
TCP SYN, ACK / RST, ICMP Type 0, or custom UDP (agent-to-agent).
Isolating Terminal Loss Signatures
When end-to-end measurements report loss but Path Visualization shows a clean transit path, the target (terminal node) is likely discarding traffic. Compare the test protocol against these common firewall or OS stack behaviors:
TCP SYN
Target SYN backlog is full. Target ignores new SYN packets.
Intermittent connection failures; established sessions remain healthy.
TCP SACK
Outdated TCP/IP stack with buggy Selective Acknowledgment (SACK) implementation.
Constant, low-percentage packet loss specifically in SACK-based tests.
ICMP
Target ICMP rate limit threshold exceeded.
Drops occurring consistently after a specific probe volume.
Rate Limiting (Any)
Target or upstream firewall actively policing traffic.
Alternates between 0% loss and high loss in a periodic pattern.
Last updated