External synthetic monitoring answers one question: what do your users experience? When the problem lives inside your own infrastructure — between your data centers, across your WAN links — external probes can identify a symptom but can’t locate the cause. Three techniques change that.
This post covers probe-to-probe testing, path bandwidth discovery, and continuous traceroute — the tools for measuring the infrastructure between your own sites. Each one answers a question that external synthetic checks can’t, and together they give you visibility into the parts of your network that matter most but are hardest to see.
Start Here: What the Videos Cover
▶ Video 27 — “Probe-to-Probe Network Intelligence: Measuring Your Own Backbone”
▶ Video 28 — “Path Bandwidth Discovery in Practice: From RTT to Capacity”
▶ Video 29 — “Continuous Traceroute & Path Change Intelligence”
Probe-to-Probe Testing: Two Different Questions
External synthetic checks originate outside your infrastructure. A probe in a public cloud region sends a request to your service and measures the result. That measurement tells you what a user in that region would experience — which is valuable. But it cannot tell you whether the problem originates inside your network or outside it.
Probe-to-probe tests place probes inside your own infrastructure and measure between them: data center to data center, cloud region to edge site, hub to spoke. The question changes from what do users see? to what is my network actually doing?
| Measurement Type | Origin | What It Reveals | What It Misses |
|---|---|---|---|
| External Synthetic | Public probes outside your infrastructure | User-facing latency, availability, protocol health | Internal path behavior, backbone performance |
| Probe-to-Probe | Probes inside your own infrastructure | Backbone latency, jitter, asymmetric routing, WAN health | User-facing endpoint behavior |
Asymmetric Routing: The Problem External Probes Can’t See
One of the most diagnostically valuable things probe-to-probe measurement reveals is asymmetric routing — when traffic from A to B takes a different path than traffic from B to A. An external probe measures in one direction only. Probe-to-probe tests measure bidirectionally, and the comparison often tells a story:
Path A → B: 14 ms. Path B → A: 47 ms. That discrepancy isn’t performance degradation — it’s a routing policy difference. Traffic is traversing different hops in each direction. The fix isn’t in your application or your cloud provider. It’s in a routing configuration. And you’d never find it with unidirectional external checks.
Periodic burst patterns are another class of problem that probe-to-probe data surfaces. Brief jitter spikes and packet loss events that last only a few seconds — but occur at predictable intervals — appear as a clear repeating signature in continuous bidirectional data. The regularity points directly at a root cause: a scheduled routing protocol reconvergence, a hardware queue issue operating on a fixed cycle, or a backup process saturating a link every four hours.
Path Bandwidth Discovery: RTT Tells You a Path Is Slow. This Tells You Where.
Round-trip time is a summary statistic. When a 12-hop path has a saturated link at hop 4, the RTT will be elevated — but the number provides no indication of which hop is the problem. You have a symptom without a location.
Path bandwidth discovery resolves that. The technique — Variable Packet Size probing, or VPS — sends probe trains at different packet sizes and measures how the gaps between packets spread at the receiver. The spreading is proportional to the bandwidth of the bottleneck link. From the slope of the arrival-gap curve, the platform estimates available capacity at each segment of the path, hop by hop.
What This Looks Like in Practice
Users in Singapore report the application is slow. RTT monitoring confirms elevated end-to-end latency. Path bandwidth discovery identifies the bottleneck at hop 4: a peering exchange link with 8 Mbps of available capacity on a 100 Mbps port. The other 11 hops are healthy. You know within two minutes that the problem is at a specific peering arrangement — not at your cloud provider, not in your application, not in Singapore.
That specificity changes the escalation path entirely. Without it, you escalate to your cloud provider. With it, you call your peering partner with evidence.
Path bandwidth discovery is technically demanding and not widely implemented. Most synthetic platforms measure only RTT and packet loss. If a platform offers VPS-style probing with per-hop bandwidth estimates, that’s a meaningful capability difference — not a marketing distinction.
Continuous Traceroute: When Did the Route Change?
Traceroute as a command-line tool has been around since 1983. Run it once when something is broken, look at the output, close the terminal. That’s traceroute as a diagnostic gesture. Continuous traceroute — storing every hop result, hashing every path, detecting changes automatically — is a different instrument entirely.
Path Hashing: The Mechanism That Makes Change Detection Possible
Every traceroute result can be reduced to a hash of the hop sequence. When the hash changes — a different intermediate router appeared, or a hop was rerouted to a different carrier — the system records a path change event with a precise timestamp. Cross-referenced against latency data, that timestamp often tells the whole story: the latency increase that started at 08:45 UTC correlates exactly with a path change at 08:45 UTC. The route changed first. The latency followed.
| Question | One-Off Traceroute | Continuous Traceroute |
|---|---|---|
| What is the current path? | Yes | Yes |
| When did the path change? | No | Yes — with timestamp |
| Which carrier changed? | No | Yes — ASN-level history |
| Did the change cause the latency spike? | No | Yes — correlation across time |
| Did the carrier meet their SLA this month? | No | Yes — historical record |
Carrier Accountability
The long-term value of continuous traceroute storage is accountability. When a carrier makes a peering change that degrades your latency, you can demonstrate precisely when it happened, which hop changed, and how your performance correlated with the change. That’s not a conversation you can have without historical path data. And it’s a conversation your carrier won’t initiate voluntarily.
About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.
Probe-to-Probe Testing: Two Different Questions
External synthetic checks originate outside your infrastructure. A probe in a public cloud region sends a request to your service and measures the result. That measurement tells you what a user in that region would experience — which is valuable. But it cannot tell you whether the problem originates inside your network or outside it.
Probe-to-probe tests place probes inside your own infrastructure and measure between them: data center to data center, cloud region to edge site, hub to spoke. The question changes from what do users see? to what is my network actually doing?