Catchpoint's Traceroute monitor is designed to map the route from a source to a destination by dispatching probes with progressively increasing TTL (Time to Live) values in their IP headers and tracking the responses. As each probe travels through the network, its TTL is reduced by each intermediate hop. If a hop reduces the TTL to 0, the packet is discarded, and an ICMP message is sent back to the source indicating the TTL expired enroute. If the packet successfully reaches its destination, the destination may respond with a normal reply or send an ICMP message indicating that no application is listening on the specified port, which is common for UDP, QUIC, and TCP.
Catchpoint supports these three protocols for network tracing: ICMP, UDP and TCP.
Traceroute Test Use Cases
- Performance Bottleneck Detection: Pinpoint latency spikes or delays at specific hops to isolate underperforming network segments from the selected nodes.
- Destination Reachability Verification: Confirm whether the final destination is reachable and identify where failures occur if not successful.
- Network Path Visibility: Identify each hop between source and destination to detect network path changes.
- Geo-Location Validation: Trace the physical path of packets to verify geographic routing accuracy and detect misrouted traffic.
- Path MTU Discovery: Identify the maximum transmission unit along the route to prevent fragmentation and optimize packet delivery.
- DSCP Validation: Ensure Quality of Service policies are honored by verifying DSCP markings across all hops.
- MPLS Path Tracing: Reveal MPLS label-switched paths to detect hidden routing layers.
- ECN Monitoring: Detect early signs of network congestion by observing ECN bits set along the route.
- Cloud Services Visualization: Identify and label network hops within AWS, Azure, and GCP to trace cloud-specific paths and troubleshoot routing issues.
Traceroute Test Results
The Records page below displays the results of a single Traceroute test run.
Catchpoint Traceroute Options
Traceroute InSession
With a conventional traceroute probe, an issue that can sometimes occur is packets being dropped by a device along the network path, resulting in an incomplete trace. To overcome this problem, we have introduced the Traceroute InSession monitor. This monitor relies on the TCP protocol, but it first establishes a TCP connection with the destination before sending probes, ensuring a complete, traceable network path. This process includes completing the 3-way handshake and executing the traceroute by sending TCP data packets instead of SYN packets. It uses the Selective Ack (SACK) option, and defaults to using destination port 80 throughout the entire traceroute. The source port selected by the OS at the start remains constant during the traceroute.
In the event that Traceroute Insession fails, (e.g. failing to establish a TCP connection), then it will fall back to a conventional TCP traceroute, and a fallback warning message will be displayed on the Records page for that test run.
Traceroute TCP
Works by sending TCP SYN packets without any TCP session established. This can be particularly useful in scenarios where ICMP or UDP traffic is filtered by firewalls, but TCP traffic is allowed, such as in web servers listening on HTTP or HTTPS ports. The tool defaults to using destination port 80 throughout the traceroute, while the OS dynamically selects a different source port for each probe.
Traceroute ICMP
Starts by sending ICMP Echo Request packets to the destination address. While effective for diagnosing network paths, ICMP traceroute may be limited by firewall restrictions or rate limiting on certain networks.
Traceroute UDP
Use UDP for tracerouting. While useful for identifying network paths, UDP traceroute can face challenges from firewalls or network configurations that block or filter UDP traffic. The tool starts at destination port 33434 and increments the port for each probe, wrapping back to 33434 after 90 ports. If a specific port is set by the user, it starts there and increments indefinitely. The OS selects a different source port for each probe.
Traceroute QUIC
This mode uses QUIC Initial packets as probes. It leverages QUIC's UDP-based transport to measure each hop's response time and routing path. QUIC traceroute is effective for examining paths in networks that support QUIC. The tool defaults to using destination port 443 throughout the entire traceroute, while the OS selects a different source port for each probe.
Traceroute + Ping
In addition to the traceroute, the tool sends twenty extra probes to the destination, using a TTL of 128 and the same protocol as the traceroute. By default, there is a 250 ms interval between these probes. The traceroute test summary metrics, including Round-Trip Time (RTT), Packet Loss, and jitter, are derived from these destination pings.
Traceroute Test Configuration
Below are the different test settings, advanced settings and metrics supported by traceroute test.
Traceroute Test Properties | |
|---|---|
| Name | A name used to identify this test. |
| Description | Optional additional information about the test |
| Monitor | The protocol used for the Traceroute test.
|
| Test Location | The IP address or hostname of the host to be tested. (www.domain.com or 8.8.8.8. TCP/UDP can specify the port, e.g. www.domain.com:82) |
| Location | The Product/Folder location of this test (read only) |
| Status | Determines whether this test is current Active or Inactive |
Traceroute Advanced Settings | |
|---|---|
| DSCP Value | Set the DSCP value in traceroute probes IP header. |
| Enable MTU Path Discovery | Perform the path MTU discovery. |
| Enable ECN | Set the ECN value in the IP header and TCP Header. |
| Increase Failure Hop Count | The max amount of consecutive failing hops allowed while tracerouting. The default is 10, and can be increased up to 20. Only supported from Enterprise and Cloud nodes. |
| Increase Ping Count | The number of probes to be sent per TTL. The default is 3, and can be increased up to 20. Only supported from Enterprise and Cloud nodes. |
Supported Metrics | |
|---|---|
| # ASs | The total number of Autonomous Systems traversed during the test |
| # Cities | The total number of Cities traversed during the test |
| # Countries | The total number of Countries traversed during the test |
| # Hops | The total number of Hops in the route. |
| # Purged Runs | The number of test runs manually excluded from calculation for purposes of SLA accuracy. |
| # Runs | Total number of test runs for the defined time period. |
| % Adjusted Availability | Ignoring any purged runs, the percentage of test runs where the destination was reached and the test was completed (i.e. there was not an error.) |
| % Frustrated | The percentage of test runs that exceeded the Apdex “frustrated” threshold. |
| % Not Frustrated | The percentage of test runs that completed in less time than the Apdex “frustrated” threshold. This is equivalent to: % Satisfied + % Tolerating |
| % Packet Loss | The percentage of pings packets sent which did not receive a response. (# packets received / # packets sent) * 100. Note: Wi-Fi Signal Strength does effect Wi-Fi Signal Quality as the perceived available bandwidth will drop as Wi-Fi Signal Strength drops. |
| % Satisfied | The percentage of test runs that completed in less time than the Apdex “Satisfied” threshold. |
| % Tolerating | The percentage of test runs that exceeded the Apdex “Satisfied” threshold but completed in less time than the “Frustrated” threshold. |
| Apdex | A scoring mechanism that translates performance metrics of diverse applications into generic “User Satisfaction” levels using predefined response time thresholds. You can use default Apdex thresholds or configure your own on a per basis. For more details about Apdex, visit http://www.apdex.org/ |
| Experience Score | A composite metric that captures the overall experience of a user on a scale of 0-100. |
| Jitter (ms) | A measure of the variance in latency of packet transmission across the network |
| Ping Round Trip (ms) | Average time between sending a ping packet and receiving a response. |
| Test Time (ms) | One cohesive metric that applies to all test types and indicates the total duration of the test run. Test Time is equivalent to Response, Test Response (Transaction and web tests) and ping RTT (Trace Route tests), and is used when calculating Apdex. Test Time is not available for Request, Host, or Zone charting. |
In addition to running as a stand-alone test, the Traceroute Monitor it is also supported for the Node-to-Node test and as an Additional Monitor with other test types.