How Path Trace Works
Last updated
Last updated
The Path Visualization view offers a visual representation of the path trace data collected for a test round. This article describes how path trace data is collected and used by the Path Visualization view. To learn more about using the Path Visualization view, see Path Visualization.
A single path trace works similarly to how a single traceroute works. Your source - in our case, a ThousandEyes agent - sends data packets to the target. The path trace starts by sending a packet directed at the test target with a time-to-live (TTL) value set to 1. Think of the TTL value as the expiration date on a packet.
Each routing device that receives this packet decreases the value by 1 before routing it to the next hop. When the TTL value equals 0, a standard routing device drops the incoming packet and replies with an ICMP TTLx packet, indicating that the packet will be dropped at this point. The next packet in the path trace sequence will have a TTL value set to 2, followed by a packet with a TTL of 3, and so on. This process continues until the agent receives a response from the intended target, or the path is deemed unresponsive. For more information about how traceroute works, see https://en.wikipedia.org/wiki/Traceroute or the more recent version, https://paris-traceroute.net/about/.
One of the key features of path trace is the ability to detect multiple routes to the same target. By default, an agent completes 3 path traces per round, in an attempt to uncover alternate routes. For tests specifying a TCP target, the agent selects a unique and random source port for each path trace. A unique source port suggests to intermediary routing devices that each stream of data is unrelated and can be routed on different network paths.
We use the source address listed in the IP header of TTLx packets received from the path trace to identify each node. For nodes within the source agent’s local network, we run a reverse DNS lookup to discover the hostname; otherwise only the IP address is listed. All other nodes are checked against WHOIS databases and Geo-IP.
As an example, the image above shows an IP address local to the US. This IP will be searched in ARIN (American Registry), where Salesforce.com will be shown as the owner. This can be checked at the following link: http://whois.arin.net/ui/
GeoIP services provide the location of the physical device hosting the IP address is. One such service is Maxmind. To see how this works, you can check out a demo here.
When a node in the path has an IP address, a reverse DNS lookup or resolution (rDNS) lookup will be attempted for each node with an IP address.
The agent performs an rDNS lookup of private IP addresses until the first public IP address is found in the path. After the first public IP address is found, the remaining nodes are looked up in the ThousandEyes backend. This means that if the path starts in a section of network that uses private IPs, the agent will attempt to do rDNS lookups for the private IPs until the first public IP is reached.
However, if the path ends in a section of network that uses private IP addresses, these IP addresses will not have rDNS data even if it is available on the agents configured name server. After the first public IP address, the path data is sent to ThousandEyes which does not have access to the private name servers.
A common question is "If the target agent can do rDNS lookups on the private IPs, why is the data not used to populate the path visualization data going the other direction?" The answer is because private IP space is not unique. The ThousandEyes backend does not have any way of verifying that the nodes with the same private IPs are actually the same node.
The ThousandEyes path visualization displays path trace data and node metadata collected for the displayed testing round and presents it in easy-to-understand format.
To view path visualization data in a more traditional manner, you can hover over an agent's name and select Show traceroute style output from the pop-up menu.
For a complete guide on using ThousandEyes path visualization, see Path Visualization.
Additionally, BGP Route Visualization allows you to visualize how data is being routed across the internet, and troubleshoot issues that may be preventing packets from getting to their desired destination. It can be accessed from the Views List in the primary panel. See Using the BGP Route Visualization View.
Cloud Insights offers a cloud native topology view for monitoring cloud native network traffic. For more information, see Cloud Insights: Views: CEA Views.
Raw test data can be accessed via our API:
