A traceroute can tell you which hops responded along a network path. MTR
goes further by repeating probes and collecting latency statistics over
time.
But raw hop data is only part of the story.
When troubleshooting a network, I often want to answer several questions
quickly:
- Which network organizations do these hops belong to?
- Where does latency change along the route?
- Has the path changed since the last test?
- Can I understand the route without digging through a long list of IP addresses?
These questions inspired the latest round of improvements to Visual
MTR, a native traceroute and network path diagnostics app for iPhone
and iPad.
The goal is not to turn network troubleshooting into a pretty animation.
It is to make route information easier to explore while preserving the
underlying diagnostic evidence.
1. Preserve the original hop order
A network path should not lose its sequence simply because we want to
visualize it.
In the latest interface, the AS Route view uses a vertical timeline
ordered by the original TTL sequence rather than a row of horizontally
arranged cards.
Each entry provides a compact summary, including the ASN, network
operator, hop number, and average RTT. Expand an entry to inspect more
detailed information, such as the hop IP address, response times, and
estimated geographic location.
This creates two useful levels of detail:
- At a glance: Follow the sequence of network organizations and compare latency along the path.
- On demand: Drill down into individual hops without losing their position in the original trace.
There is an important distinction here: an ASN-oriented view derived
from observed hops is not the same as a complete BGP AS_PATH. It is a
way to organize the evidence collected by the traceroute, not a claim to
reconstruct every routing decision made by the network.
2. Separate live results from deeper analysis
A diagnostic tool becomes harder to use when every result, chart, and
saved report competes for attention.
Visual MTR now separates the workflow into three areas.
Current Test - Live Hops - Trace Report
Advanced Analysis - MTR Analysis - Globe Report - Route Diff
Test Archive - Test History
The distinction is intentional.
Live results help answer what is happening in the current test. Advanced
analysis helps investigate patterns or compare routes. The archive makes
it easier to revisit previous measurements.
Instead of treating every screen as another version of the same report,
each area has a specific job.
3. Look at latency over multiple rounds
A single traceroute is a snapshot. Network conditions can change between
measurements, and one unusually high RTT does not necessarily indicate
persistent congestion.
Multi-round MTR provides a more useful basis for comparison.
Visual MTR's Pro analysis includes independent statistics for individual
rounds, alongside aggregated results. RTT summaries, trends, and
hop-by-round heatmaps help reveal whether a delay is persistent,
intermittent, or limited to a particular measurement period.
This changes the questions we can ask.
Rather than looking only at the average, we can investigate:
- Does latency remain elevated across multiple rounds?
- Does the variation appear consistently at the same hop?
- Are individual rounds behaving differently from the overall result?
- Does a change in the route coincide with a change in observed latency?
These views do not automatically identify the root cause. They make it
easier to determine which part of the path deserves further
investigation.
4. Compare routes instead of relying on memory
Two traces to the same destination may not look identical.
A later test can reveal a different sequence of responding hops, changes
in observed network organizations, or differences in latency
measurements.
The Route Diff view helps make those changes easier to investigate.
Instead of manually comparing two long reports, you can use the
comparison workflow to focus on what changed and then return to the
relevant hop-level details.
This is especially useful when investigating intermittent connectivity,
changes after network maintenance, or differences between tests taken at
different times.
A route difference is evidence, not a diagnosis. Routing policies, load
balancing, transient conditions, and probe-response behavior can all
affect what a trace shows. The next step is to correlate the observed
change with the actual connectivity problem.
5. Explore the route on a 3D globe
The new Globe Report provides another way to inspect a route.
Rather than presenting only a list of hops, it places geographically
locatable hops on an interactive 3D globe. You can rotate and zoom the
globe, select points, and reset the view to explore the displayed route.
The visualization is designed to complement the original trace, not
replace it.
There are two important implementation details.
First, hop order must remain meaningful.
The globe uses a single selected trace round with usable geographic
information. It does not combine hops from different rounds into a
synthetic route. This avoids presenting a visually complete path that
was never observed in any individual round.
Second, geographic information has limits.
IP geolocation provides estimates, not verified physical router
coordinates. The displayed connections represent logical hop order; they
are not verified physical cable routes.
A globe view is useful for understanding the broad geographic context of
a path. Exact latency measurements and the original hop sequence remain
essential for technical analysis.
6. Network diagnostics that fit in your pocket
Visual MTR is designed for situations where opening a laptop is
inconvenient or impossible.
The app provides native IPv4 and IPv6 tracing, per-hop response
information, offline ASN lookup, and configurable DNS settings.
Pro extends the workflow with multi-round MTR, advanced visual analysis,
the 3D Globe Report, Route Diff, and PDF, JSON, and text report exports.
Saved diagnostic history also makes it easier to revisit previous tests.
The app uses a free core workflow with a one-time Pro in-app purchase
rather than a subscription.
The objective is straightforward: make it possible to start with a
simple trace and move into deeper analysis when the problem warrants it,
without forcing every user to navigate the same level of complexity.
7. Visualization should clarify evidence, not overstate it
A good network visualization should make technical information easier to
understand without suggesting more certainty than the measurements
support.
For traceroute and MTR, that means keeping a few principles in mind:
- A hop that does not respond to probes is not automatically dropping forwarded traffic.
- An ASN summary does not reveal the complete BGP routing state.
- An estimated IP location is not the physical location of a router.
- A difference between two traces does not, by itself, prove the cause of an incident.
- A visual route should remain traceable to the measurements from which it was derived.
These constraints are not limitations to hide. They are part of building
a diagnostic tool that network engineers can trust.
Try Visual MTR
Visual MTR brings native route tracing and visual network path analysis
to iPhone and iPad.
App Store:
https://apps.apple.com/app/visual-mtr-traceroute/id6821332849
The product is still evolving, but the direction is clear: preserve the
original measurements, organize the route intelligently, and give users
better ways to investigate what they see.
If you troubleshoot networks on a mobile device, which view would help
you most: an ordered hop timeline, multi-round latency analysis, route
comparison, or a 3D globe?
I'd be interested to hear how other network engineers approach route
analysis when they are away from their usual workstation.
Top comments (0)