In this documentation, we will explore various ways to use and examine Path Analysis data in the UXI dashboard. Currently, UXI sensors run a Path Analysis test after a successful supported ICMP, TCP, or UDP test. The Path Analysis view can be used to analyze threshold violation issues identified during these tests.

In this scenario, we observe regular periods of high latency on the Aruba homepage, arubanetworks.com, from a sensor located in South Korea.
​

Let's open the 'Path Analysis' view for the same website and analyze it. We observe that during high latency periods, there are paths with high RTT and more hops than usual between UXI and the web server. In this instance, there were 11 hops between UXI and the web server at IP = 23.42.92.203. This IP is hosted on the West Coast of the USA, which explains the high RTT and latency between UXI and the web server.
​

​​During low latency periods, we see a reduced number of hops between UXI and the web server, as well as lower RTT values. In this instance, there are 7 hops between UXI and the web server at IP = 104.75.18.30. This IP is hosted in South Korea, where the sensor is located, resulting in lower latency between UXI and the web server.
​

A number of sensors located in the USA and South Africa are configured to test the HPE GreenLake Platform ('common.cloud.hpe.com'). On May 27, 2024, around 7:44 pm US Central Time (US CT), we recorded an incident where the HPE GreenLake Platform was inaccessible.

Before the incident, in the 1-hour 'Path Analysis' view, we observed 14 web servers for the HPE GreenLake Platform (19:00 - 20:00 US CT).
​

​During the incident, we observed that only 7 web servers were accessible from sensors (20:00 - 21:00 US CT).
​

​After the incident, as the HPE GreenLake Platform fix was rolled out, we observed the issues slowly resolving. During this time, 13 web servers became accessible (21:00 - 22:00 US CT).
​

The outage ended around 11:00 pm US CT.

End-to-End visibility and proactive network path analysis with underlay multi-ISP environments or Local Internet Breakouts (LIBs)
​
The 'Path Analysis' view enables us to observe paths exiting from multiple Internet Service Providers (ISPs). In the example below, we have 3 WAN connections:

After setting up route policies on your WAN connections, you can use the 'Path Analysis' view to verify if your traffic is exiting through the specified WAN interfaces. These could be WAN1, WAN2, or WAN3 on your firewall, SD-Branch, or SD-WAN gateway.

For example, if you have a route policy or group policy blocking contractor role access to a restricted site like mygamblingsite.com, you can create a mygamblingsite.com test on a UXI sensor and verify with the 'Path Analysis' view that the routing in your SD-WAN is functioning as expected. You could check, for instance, whether GUEST and IoT devices are properly passing through the SSE before reaching the internet.
​
​

'Path Analysis' can provide visibility into both underlay WAN - ISP paths and overlay SD-WAN paths. For example, in a Hub(Mesh) configuration with EdgeConnect SD-WAN sites, spokes are connected to various xyz.fivetuple.net. The diagram below illustrates "Regional Routing" in EdgeConnect.
​

In this example, we have a Cloudflare speed test hosted behind an SWG on the Atmos Web Gateway. Sensors are running the 'Path Analysis' test and discovering paths from the sensors to the Cloudflare speed test website.

​Marietta 1 and Kennesaw 2 > WAN 1 and WAN2 - 18NET1 & 11NET > Gateways > SWG > Cloudflare speed test website
​

​​Known Limitations: If you have a service hosted in the AWS cloud, 'Path Analysis' will not be able to discover the AWS routers in the path. You can see this in the example below, where the service 'ipsla' (sp-ipsla.silverpeak.cloud) is hosted in the AWS cloud, with the endpoint IP being AWS CloudFront (Amazon CDN).
​