What is Path Analysis?
Path Analysis is a visualization tool that displays Layer-3 (L3) hops from UXI sensors and Android agents, providing an end-to-end observability platform on the UXI dashboard. Users can view L3 hops and paths from the source (UXI sensors) to the destination (application). It serves as a comprehensive network and application observability platform for end users.
How does Path Analysis work?
For Sensors:
Path Analysis tests are executed after the application test is successfully completed in the test cycle, following a round-robin approach. Sensors use their own mechanisms to craft and send ICMP/TCP/UDP packets based on the test type. This process discovers the path to the destination, which is then visualized on the UXI dashboard.
Note that Path Analysis tests currently run only after a successful parent test, meaning you will only see paths for successful test results. As a result, you will not see paths when issues such as HTTP timeouts or external service unavailability occur.
However, a classic traceroute runs as part of the triage process to support troubleshooting workflows. Additionally, we plan to include a Path Analysis test for failed tests as part of the triage, where you will see paths for issues identified by UXI. UXI sensors perform IP resolution each time the parent test and Path Analysis test are run.
For Android Agents:
The Path Analysis test is not yet available on the Android agent but will be included in future Android app versions.
How to set up the Path Analysis test?
Create a Path Analysis test for a new or existing predefined or custom service:
You can easily configure Path Analysis per application by following these steps:
Navigate to Service & App Tests.
Select any test.
Enable the Path Analysis toggle for the application or for each protocol test.
There is also a global toggle available to apply the Path Analysis test across all underlying sub-tests, such as HTTP, HTTPS, and ICMP ping.
You also have the option to apply Path Analysis selectively to specific sub-tests like HTTP, HTTPS, or ICMP by selecting Configure.
Note:
It can take upto 90 mins for the config changes to reflect.
If your network is configured for a proxy, please review the "Proxies and Network Testing" support article for the correct configuration. If a proxy is configured on a network, then by default the Path Analysis traceroutes will not be executed.
Interacting with Path Analysis View
Once you enable Path Analysis for the app test, you can navigate to the Path Analysis option at the top left of the main Circles page. Here, you can view the paths that sensors are producing for the test.
Dataset Section
In the Dataset section, the user can select a sensor or sensor group as the Source and an application or service as the Destination, as well as define the time period.
Groups: Select hierarchical groups from the list of available groups.
Sensors & Agents: Search for or select the sensor or agent for which you want to view the path.
Destinations: Search for or select the application name or URL/IP for which you want to see the path from the sensor.
Note: Ensure the Path Analysis toggle is enabled for the relevant application or service in Service & App Tests.Period: Select a time period of your choice for up to the last 30 days. The default time period is 1 hour.
Interval: View paths from specific time intervals within the selected time range. Options include 5 minutes, 10 minutes, and 1 hour.
Sort and Filter
Sort the path using the dropdown in ascending (low to high) or descending (high to low) order based on various metrics such as RTT, loss, jitter, number of hops, sensor, or destination.
Filter results by:
Metrics: Use sliders to set the range for metrics like RTT, jitter, and loss.
Networks: Filter by SSIDs or Ethernet.
Protocols: Filter by protocols such as ICMP or TCP.
Ports: Filter by specific ports, e.g., 80 or 443.
AS Numbers: Filter by AS numbers, e.g., filtering on ASN 15169 will show all paths that belong to Google.
IP Prefix: Filter by IP Prefix.
You can hover over the sensor to view the paths from that specific sensor, or hover over the end application to see the various paths associated with that application. If you have multiple wireless and wired networks configured to be tested on the sensor, you can use the network filter to distinguish between wireless and wired paths for applications.
Grouping Section
The user can group the paths based on:
Number of hops/nodes in the path. You can adjust the slider to specify the number of hops from the sensor and from the destination node. For example, setting the slider to (2 <-> 2) means the user wants to view 2 hops from the sensor and 2 hops from the destination node, with the rest of the hops grouped together. You can move the slider left or right to change the selection based on your desired view.
Characteristics of different nodes:
Source nodes can be grouped based on the hierarchical group (with the lead node shown as the start of the path) or on a per-sensor basis.
Intermediate nodes can be grouped based on AS number, prefix, or IP address of the node.
Destination nodes can be grouped based on IP & service (e.g., 108.156.224.51 & GreenLake, 108.156.224.53 & GreenLake), service (e.g., GreenLake), or target host (e.g., common.cloud.hpe.com).
Search Bar
You can now quickly search for nodes based on various criteria, including AS number, IP address, hierarchy group, hostname, network, prefix, sensor, and target URLs. The selected item's path will be highlighted, allowing you to easily isolate that specific path by opening the Info Panel.
Isolate Paths
When you select any item using Find and Select, it will highlight that node and its path, and open the Info Panel. If you click anywhere in the blank space on the Path Analysis canvas after making a selection, it will reset the selection you made in Find and Select. However, you can keep the selection intact by either dragging the node or clicking on the Info Panel.
When you hover over a single node or a group of nodes, a node info panel will appear, providing details such as the IP address, RTT (round-trip time in ms), max RTT (in ms), hostname, IP prefix, Autonomous System (AS) name and number, and DSCP class (number), Location, Cloud Provider (only Google Cloud and Amazon AWS is supported right now).
The reported Round-Trip-Time (RTT) is measured based on the ICMP echo request or TCP/UDP packet sent to the target node during the Path Analysis operation. This metric differs from the latency reported when executing the actual service test.
Note: Node info is provided on a best-effort basis and depends on the availability of public IP lookup globally.
Info Panel
You should be able to see the info panel on the right side, indicated by a book symbol. This panel provides a second level of information beyond the node info. For example, you can view the selected node name or IP address and information about paths going through the node, such as counts of sources, destinations, and unique routes.
You can select one or multiple nodes in the path to get detailed info in the panel. Additionally, you can now "Isolate Paths" selected from the entire view. You can hide the panel by clicking the same info panel symbol.
Undo & Reset
Once you isolate paths, if you want to revert the view or go one step back, you can simply use the Undo button to return to the previous view. Alternatively, you can use the Reset button to go back to the default view.
Legends
We now provide a guide to what all the icons mean in the Path Analysis view. You can simply click on Legends (?) in the right-hand corner to access it. Additionally, there is documentation on Path Analysis linked at the bottom of the page for more information.
Destination Node Unreachable
If the traceroute path is not completed to the end application, you will see a “dotted red line with an X,” indicating that the path did not complete from the sensor to the end application and failed at a specific link within the network. The nodes beyond the broken line may be online but they did not respond to the traceroute packets emitted by the sensor. When you hover over the link, you will see a message stating “destination node unreachable.”
Reasons Why Parent Tests Sometimes Pass, but Path Analysis Shows Unreachable Targets for TCP Ping Tests
How UXI TCP Ping Parent Tests Work
TCP tests conducted by the UXI sensor, which determine the service status shown on the dashboard, involve establishing a TCP connection to the target and transmitting TCP SYN/ACK packets to the target.
The UXI sensor emits traceroute packets in parallel, irrespective of the protocol configured. Each packet will have an incrementing TTL with appropriately structured headers, certain pieces of network infrastructure can at times block ICMP echo requests (ICMP flooding) or spurious TCP connections. This doesn’t necessarily indicate a complete failure or that the destination is unreachable. Instead, it suggests that intermediate nodes or specific network configurations may be causing discrepancies in the results.
Possible Reasons Why Path Analysis Shows Destination as Unreachable
A common reason for TCP tests showing the destination as unreachable in Path Analysis relates to how the TCP packet train is emitted from the device, the target ports used are not incremented in order to maintain the same 5-tupple flow, however this can lead to certain firewalls marking the traffic is conspicous.
Routing Loop
If the path traverses through the same node twice, it will be marked as a loop and represented as follows: (A > B > B > C).
You can also verify this by performing a simple traceroute from your computer, which would look like the example below:
Traceroute example:
1 10.1.3.2 (10.1.3.2) 7.596 ms 3.082 ms 3.328 ms
2 d-23-244-193-253.nh.cpe.atlanticbb.net (23.244.193.253) 5.323 ms 4.234 ms 5.989 ms
3 d-23-244-193-253.nh.cpe.atlanticbb.net (23.244.193.253) 4.387 ms 26.186 ms 4.437 ms
4 static-209-196-168-178.nh.cpe.atlanticbb.net (209.196.168.178) 7.481 ms 6.855 ms 7.700 ms
Focus on nodes 2 and 3 — 23.244.193.253 is a repeating IP address for two consecutive nodes, indicating a routing loop in the traceroute. In the screenshot above, you can see this loop where the link is initiated and terminated on the same node.
All consecutive unknown or unidentifiable nodes that do not provide any information about their IP address or other node details will be grouped together (as shown above as 12 nodes) and displayed with a count in a box, indicating that there are nodes along the path that do not provide any information.
Currently, we only only support Google cloud and Amazon AWS for cloud providers but we plan add support for Azure as well.
How to use Path analysis?
We encourage you to incorporate Path Analysis into your daily troubleshooting methodologies or Standard Operating Procedures (SOPs). This tool provides complete visibility, helping you identify exactly where a packet is being dropped along the path or pinpointing which node in the route is experiencing issues that contribute to service unavailability.
Current Known Behavior
Path Analysis Test is currently not supported for the following test types:
Predefined: Meraki AP, throughput tests such as YouTube, Netflix, and Dropbox.
Custom: Voice Analysis, LibreSpeed.
To enable the Path Analysis Test, you must first enable the parent test, such as TCP 80 or ICMP ping. At this time, you cannot enable the Path Analysis Test independently.
What are the use cases?
Sensors perform approximately 30,000 tests per day, per sensor. Imagine you're on a video call with your family or participating in a video conference while working from home, and the sensor is testing the same video conferencing app. The traffic may traverse various geographical locations, and with Path Analysis, you can visualize all possible paths from the sensor to the video conferencing app.
Sensors are deployed in various locations. For example, consider a scenario where users face issues executing POS or banking transactions from stores or buildings. If the sensors are already testing the POS app, and those transactions are failing due to an issue with the regional local Internet service provider, having end-to-end path visibility from the sensors to the POS app becomes critical. This visibility helps define the scope of the problem and assess the impact.
For more use cases please refer to this help article: https://help.capenetworks.com/en/articles/9426925-how-to-use-path-analysis-in-daily-workflows
Meanings of Different Keywords
Destinations: A destination is the service or app for which Path Analysis is configured under the Service & App Test page.
Groups: A group is a hierarchical collection of sensors or agents.
Node/Hop: A node or hop is a device discovered while tracing the path from the sensor to the application.
Link/Path: The link or path is the connection between two nodes.
Period: The time selection option allows you to select a time range and view a historical perspective on the dashboard.
Autonomous System Number (AS Number or ASN): An ASN is a unique identifier assigned to an Autonomous System (AS), which is a collection of IP networks and routers under the control of a single organization that presents a common routing policy to the internet. ASNs are used for routing internet traffic between different autonomous systems.