FAQ's - Path Analysis

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.

It can take up to 90 mins for the config changes to reflect.

From the sensor to that target, there are 5 unique routes. Of those routes, only 2 path was completely reached the target and 3 didn't.

Please note: even though the Path Analysis was not completed destination target might still be available.

If the 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 node in between. When you hover over the link, you will see a message stating “destination node unreachable.”

This does not imply a failure at the node itself or the target, but rather that the path analysis could not be fully completed.

Let's first understand how TCP test works for sensors.

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 conspicuous.

Why there are number of unidentifiable/unknown nodes in the path, and what are the best practices to avoid this?

Unknown or unidentifiable nodes are the ones from which the UXI sensor does not get any information, like node info - IP address, hostname, etc.

This is because a router or a node is configured not to respond to a type of packet, like ICMP packets, which could be due to a number of reasons:

Best Practices to get more discoverable nodes on L3 infrastructure, make sure these packets are allowed:

For IPv4:

For IPv6: