Network Path Analysis: Tools, Traceroute Variants, and Continuous Path Monitoring
Reviewed for technical accuracy by: Eric Hian-Cheong, Senior Product Marketing Manager at Kentik, who leads go-to-market strategy for Kentik AI, NMS, and flow solutions.
Network Path Analysis at a Glance
- Network path analysis maps the route packets take across a network and measures latency and loss at each hop, so teams can locate where performance degrades.
- Traceroute discovers hops by sending packets with increasing TTL values and reading the ICMP responses each router returns; MTR and PathPing extend it with per-hop loss and latency over time.
- Classic traceroute falls short on modern networks because per-flow load balancing (ECMP) makes successive probes take different paths, return paths are invisible, and a single run is only a snapshot.
- Paris traceroute solves the load-balancing problem by holding the flow identifier constant, producing an accurate map of one consistent path.
- Continuous, agent-based path monitoring is the enterprise approach: scheduled tests from multiple vantage points, historical baselining, and correlation with BGP routing and flow telemetry.
What is network path analysis?
Network path analysis is the practice of determining the route that traffic takes between two points and characterizing the quality of that route at every step. A path is the ordered list of Layer 3 devices — routers and gateways — a packet passes through on its way to a destination, and each device on that path is called a hop. Path analysis answers three operational questions at once: which hops are involved, how much latency each one adds, and where packets are being lost or delayed.
That information matters because most performance problems live in the network between systems rather than at either end. An application team may see elevated response times with no obvious cause on the server; a path analysis reveals that traffic is now traversing a congested transit provider or has been rerouted after a peering change. For teams running services across the internet, multiple clouds, and their own infrastructure, path visibility is the difference between guessing at a root cause and pinpointing it.
Kentik in brief: Kentik is the network intelligence platform that turns network path analysis from an ad hoc command into a continuously monitored signal. Kentik Synthetics runs scheduled, Paris-traceroute-based path tests from a global fleet of agents — plus private agents deployed in your own data centers, branches, and VPCs — so every critical path is measured around the clock from the vantage points that matter, and mapped accurately even across ECMP load-balanced networks where classic traceroute fails. Because Kentik correlates hop-by-hop path data with BGP routing events and flow telemetry (NetFlow, sFlow, IPFIX, and cloud flow logs), a degraded path is tied directly to the routing change that caused it and the traffic it affected — turning “the path changed” into “here’s why, here’s who’s impacted.”
Learn how AI-powered insights help you predict issues, optimize performance, reduce costs, and enhance security.
How does traceroute work?
Traceroute discovers each hop on a path by exploiting the Time to Live (TTL) field in the IP header. Every packet carries a TTL value, and every router that forwards it decrements that value by one. When the TTL reaches zero, the router discards the packet and sends back an ICMP “Time Exceeded” message (Type 11) that identifies itself.
Traceroute uses this behavior deliberately. It sends a first probe with a TTL of 1, which expires at the first router and produces a Time Exceeded reply — revealing hop one. It then sends a probe with a TTL of 2, which expires at the second router, and continues incrementing the TTL until the probe reaches the destination. The destination responds differently depending on the probe type, which signals that the trace is complete. The result is an ordered list of hops, each with a round-trip time measurement.
A typical traceroute output looks like this:
traceroute to www.example.com (93.184.216.34), 30 hops max, 60 byte packets
1 router.local (192.168.1.1) 1.234 ms 1.110 ms 1.087 ms
2 100.64.0.1 (100.64.0.1) 9.512 ms 9.480 ms 9.701 ms
3 ae-1.border.isp.net (203.0.113.5) 11.234 ms 10.998 ms 11.401 ms
4 * * *
5 ae-3.core.transit.net (198.51.100.17) 24.556 ms 24.301 ms 24.880 ms
6 93.184.216.34 (93.184.216.34) 25.110 ms 24.998 ms 25.203 msEach numbered line is one hop. After the hop number comes the responding device’s hostname and IP address, followed by three round-trip times, because traceroute sends three probes per hop by default. Hop 4 shows * * *, meaning no probe received a reply at that TTL — most often because the router is configured not to answer, not because anything is broken. Latency generally rises as the trace moves further from the source. The pattern worth watching for is the opposite of what most people assume: a single hop showing high latency that does not carry through to later hops is almost always a router deprioritizing its own ICMP responses, not real congestion on the path.
What are the main traceroute variants?
The core mechanism is the same across implementations, but the probe type and platform differ, and those differences matter when firewalls or operating systems get in the way. Classic Unix traceroute sends UDP packets to high-numbered ports and expects an ICMP “Port Unreachable” from the destination to mark the end of the trace. Windows tracert instead uses ICMP Echo Request probes, the same packets ping uses.
The most useful variant in firewalled environments is TCP traceroute, which sends TCP SYN packets to a specific port — usually 80 or 443. Because that traffic looks like a normal connection attempt, it often passes through firewalls and access lists that silently drop UDP and ICMP probes, making it the most reliable choice for tracing a path to a web service. On Linux and macOS, traceroute -T performs a TCP trace; on Windows, the built-in tracert does not support TCP, so engineers use a tool such as Nmap (nmap --traceroute), tcping, or a dedicated path-monitoring application.
Two tools extend traceroute by combining it with continuous pinging. MTR (My Traceroute), common on Linux and macOS, repeatedly probes every hop and displays a live table of per-hop loss and latency, which makes intermittent problems far easier to spot than a single traceroute run. PathPing, built into Windows, does something similar: it traces the route, then pings each hop over a period and reports the loss percentage at each one. Both are the natural next step when a single traceroute is too coarse to find an intermittent fault.
Why does classic traceroute fall short on modern networks?
Classic traceroute was designed for a simpler internet, and several characteristics of modern networks undermine its accuracy. The most significant is per-flow load balancing. Routers using Equal-Cost Multi-Path (ECMP) spread traffic across several equivalent links, and they decide which link to use by hashing fields in each packet’s header — including the port numbers that classic traceroute changes on every probe. As a result, successive probes can take different physical paths, and traceroute stitches them into a single route that no real packet ever followed. This produces phantom links, missing hops, and impossible topologies. Paris traceroute was developed specifically to fix this by keeping the flow identifier constant across probes, so every probe follows the same path and the resulting map is real.
Several other limitations apply even when load balancing is not a factor. Traceroute measures only the forward path, while the return path can be completely different — and the round-trip times it reports include both, so a latency spike may live on a return route the trace never shows. A single traceroute is also a point-in-time snapshot, useless for catching the intermittent loss and brief reroutes that cause real-world performance complaints. Routers commonly rate-limit or deprioritize the ICMP responses traceroute depends on, which manufactures latency that looks alarming but does not affect forwarded traffic. And MPLS tunnels, firewalls, and ACLs can hide hops entirely or drop probes, leaving gaps in the picture. None of these are reasons to abandon traceroute — they are reasons to treat one trace as a clue rather than a conclusion.
What are the main approaches to network path analysis?
Path analysis tools fall into a few categories, ordered roughly from simplest to most capable. Choosing among them is mostly a question of scale: how many paths you need to watch, how often, and from how many vantage points.
The starting point is command-line utilities — traceroute, tracert, and tracepath. They are free, available everywhere, and ideal for a quick, ad hoc check from one machine. Their limits are the limits described above: a single vantage point, a single moment, and the load-balancing and return-path blind spots of classic traceroute.
Enhanced command-line tools such as MTR and PathPing add continuous sampling over a short window, surfacing per-hop loss and latency that a one-shot trace misses. They are the right tool for diagnosing an intermittent problem from a workstation, but they still run locally and on demand.
Visual desktop tools — PingPlotter, NeoTrace, and VisualRoute among them — wrap traceroute and ping in a graphical interface, plotting hop-by-hop latency over time and sometimes mapping hops geographically. They make a path easy to read and are popular for SMB troubleshooting, but they typically run from a single host and are not built to monitor many production paths at scale.
Online and web-based traceroute services, including provider looking glasses, run a trace from a remote server rather than from your own machine. They are useful for an outside-in view — checking how a path looks from somewhere else on the internet — but you do not control the vantage point, the results are still point-in-time, and they cannot monitor continuously.
The most capable category is continuous synthetic path monitoring, delivered by SaaS platforms that run scheduled path tests from globally distributed agents. Instead of a manual trace from one place, these platforms test paths around the clock from many vantage points, baseline normal behavior, alert on path changes and loss, and correlate path data with routing and traffic telemetry. This is the approach built for business and large-scale networks, where the goal is not to run a trace when something breaks but to know the moment a path degrades.
How do you choose path analysis tools for business and large networks?
For an individual troubleshooting session, the command-line and visual tools are enough. For a production environment, the selection criteria change, because the job shifts from running a trace to operating a monitoring system. A few capabilities separate enterprise-grade path analysis from a desktop utility.
The first is multiple vantage points. A path looks different from a branch office, a data center, and a cloud region, and monitoring from only one of them hides the problems users actually hit. The second is continuous measurement with historical baselining — the ability to compare today’s path and latency against last week’s, so a reroute or a slow creep in latency is obvious rather than invisible. The third is accurate path mapping on load-balanced networks, which in practice means a Paris-traceroute-style approach rather than classic traceroute. The fourth is correlation with routing and traffic data: a path change is far more actionable when you can see the BGP routing event that caused it and the flow data that shows who was affected. Finally, alerting and scale matter — a platform that can watch hundreds or thousands of paths and notify the right team when one degrades is a different class of tool than one an engineer runs by hand.
When evaluating tools for diagnosing problems like packet loss on a business network, the practical test is whether the tool can catch an intermittent issue you are not actively watching for. A traceroute or PingPlotter session will show loss while you run it; a monitoring platform will have already recorded it, told you when it started, and shown you which path and which routing change is responsible.
Continuous network path monitoring with Kentik
Kentik is the network intelligence platform for modern infrastructure teams, and network path analysis is one of the problems it is built to solve continuously rather than on demand. Kentik Synthetics runs scheduled path and traceroute tests from a global fleet of agents, so a path is measured from many vantage points around the clock instead of from a single laptop at a single moment. Because those tests use a Paris-traceroute approach, the paths Kentik maps stay accurate across the load-balanced, ECMP-heavy networks that confound classic traceroute.
What makes path data actionable on the platform is the context around it. Kentik correlates path and latency measurements with BGP routing data and with flow telemetry such as NetFlow, sFlow, and VPC Flow Logs, so a degraded path is not just a longer list of hops — it is tied to the routing event that changed it and the traffic that crossed it. Path visualizations show hop-by-hop behavior across your own network, the clouds you run in, and the public internet in between, and alerting surfaces path changes and loss as they happen. For teams that have outgrown running traceroute by hand, that combination turns path analysis from a reactive command into a monitored signal.
Related Reading on Network Path Analysis
- The Power of Paris Traceroute for Modern Load-Balanced Networks — a deep technical explainer on why classic traceroute fails on load-balanced paths and how Paris traceroute fixes it.
- Network Monitoring Protocols: 6 Essential Network Technologies — overview of the protocol-level context, including how ICMP underpins traceroute.
- Synthetic Monitoring — learn more about Kentik’s synthetic monitoring solution.
- Best Network Monitoring Tools for 2026 — our roundup and reviews of the best network monitoring tools across enterprise, cloud, MSP, and open-source categories.
- BGP Monitoring — learn more about Kentik’s BGP monitoring solution.
FAQs about Network Path Analysis
What are good alternatives to traceroute for network path analysis?
The most common alternatives extend traceroute rather than replace it. MTR (My Traceroute) and PathPing combine traceroute with continuous pinging to show per-hop loss and latency over time, Paris traceroute fixes classic traceroute’s inaccuracy on load-balanced paths, and visual tools like PingPlotter present the same data graphically. For ongoing visibility across production networks, continuous synthetic path monitoring is the alternative to running any of these by hand. Kentik supports this by running scheduled, Paris-traceroute-based path tests from globally distributed agents and correlating the results with routing and flow data.
Which two tools function similarly to traceroute?
PathPing and MTR are the two tools most often described as functioning like traceroute, because both combine the path discovery of traceroute with the continuous measurement of ping. PathPing is built into Windows; MTR is standard on Linux and macOS, with WinMTR available for Windows. Both report per-hop latency and packet loss, which makes them better than a single traceroute at finding intermittent problems.
How do you run a TCP traceroute on Windows?
The built-in Windows tracert command only performs ICMP traces and does not support TCP, so a TCP traceroute on Windows requires a separate tool. Common options include Nmap with nmap --traceroute, the tcping utility, or a graphical tool that supports TCP probes. TCP traceroute is worth using when firewalls block the ICMP or UDP probes that other traceroute variants rely on, since SYN packets to port 80 or 443 often pass through.
What tools provide hop-by-hop path analysis from a user to a service?
Hop-by-hop analysis from a user’s location to a service requires testing from where the user actually sits, not from the data center. Command-line tools like traceroute and MTR work when an engineer can run them on the affected machine, but at scale this is done with synthetic monitoring agents deployed at branch offices, in clouds, and across the public internet that continuously trace the path to each critical service. Kentik supports this by running hop-by-hop path tests from both its global agent fleet and private agents you place at user locations, with per-hop latency, loss, and jitter recorded for every test.
How can you visualize path changes during an outage in real time?
Visualizing a path change as it happens requires a baseline of what the path looked like before — which is exactly what a one-off traceroute lacks. Continuous path monitoring platforms test paths on a schedule, store the history, and render the current path against prior runs, so a reroute during an outage appears as a visible divergence the moment a test detects it. Kentik supports this with path visualizations that update as scheduled tests run, alerting on path changes and loss, and correlation with BGP data so you can see whether a routing event such as a route withdrawal or leak triggered the change.
How do you detect asymmetric routing and its impact on performance?
Asymmetric routing — where traffic takes one path forward and a different path back — is invisible to a single traceroute, which only maps the forward direction even though its round-trip times include both. Detecting it requires tracing from both ends (running a trace from each side toward the other) or comparing path tests from agents on each side of the conversation, then checking whether latency or loss attributed to the forward path actually lives on the return route. Routing data adds confirmation: BGP path differences between the two directions explain why the asymmetry exists and whether a policy or peering change introduced it.
What’s the best approach to troubleshoot intermittent packet loss in a cloud WAN?
Intermittent loss is rarely happening while you watch, so the effective approach is continuous measurement rather than reactive tracing: scheduled path tests across the WAN that record per-hop loss over time, so the event is captured with its timing and location when it occurs. From there, correlate the loss window with routing changes and traffic levels to distinguish congestion from a reroute or a failing device. Kentik supports this by recording path, loss, and latency data around the clock from agents across cloud regions and on-prem sites, and by correlating loss events with BGP changes and flow telemetry so the cause is visible alongside the symptom.
What’s the best practice for continuous path testing to critical services?
The accepted practice is to test each critical path from every vantage point that matters — each branch, data center, and cloud region that depends on the service — on a frequent schedule, using flow-aware probing (a Paris-traceroute approach) so load-balanced paths are mapped accurately. Baselines and alerting should be configured so the system flags path changes, latency regressions, and loss without anyone watching dashboards. Kentik supports this model with scheduled tests from global and private agents, automatic baselining, and alert policies tied to path change, loss, latency, and jitter thresholds.
Which features should you look for in network path analysis tools?
For production use, look for measurement from multiple vantage points, continuous testing with historical baselines, accurate path mapping on load-balanced networks (a Paris-traceroute approach rather than classic traceroute), correlation with BGP routing and traffic data, and alerting that scales to many paths. These capabilities are what separate an enterprise monitoring platform from a desktop utility. Kentik provides them as part of a broader network intelligence platform that ties path data to routing and flow telemetry.
What are the best visual traceroute tools for mapping network routes?
Visual traceroute tools such as PingPlotter, NeoTrace, and VisualRoute plot hop-by-hop latency over time and often map hops geographically, which makes a path easier to interpret than raw command-line output. They work well for single-host troubleshooting on desktops. For mapping and monitoring many paths across a production environment, platforms that visualize paths continuously from multiple agents — Kentik among them — are better suited to scale than single-machine tools.
Ready to see your network paths?
Kentik is the network intelligence platform for modern infrastructure teams — and continuous path monitoring means you find the degraded hop before your users do.
- Request a demo — see continuous path monitoring and correlated routing and flow data in Kentik.
- Start a free trial — run synthetic path tests against your own network.
- Explore Kentik Synthetics — learn how agent-based testing maps and monitors paths at scale.
