ENA SurePath: Tracing a path across your network and beyond – Part 2
In the second part of the ENA SurePath series, we will look at how SurePath can visualize your network paths within and without the network. For the first part introducing SurePath and how it works, please click here.
The movement of many (but not necessarily all) applications to the cloud increases the complexity of your network management. For example, your London office might be experiencing difficulties in accessing Office365. Or you might be having trouble sending Neo into the Matrix. In both cases, youre unsure if the issue lies within your network or beyond. Its essential that you discover where the problem lies so that you can pursue the appropriate method of troubleshooting, request the ISP provide a fix if the issue is beyond your firewall, or send a team to deal with the Machine Sentinels blocking those routes. The first step in this process is to visualize your network paths.
Having selected an agent and created a path between London and the Office 365 servers (or the Nebuchadnezzar and the appropriate phone booth), ENA will trace and visualize that path, using aggregated traceroute batches to ensure accuracy. A batch is a specified number of traceroutes performed and paths discovered over a scheduled period. Each individual batch produces a single path visualization for that time, which displays all the discovered routes taken by the path.
The Path Summary dashlet in ENA will then display every route and every node (hop) that a packet could have taken from source to destination in the selected batch. The IP address of each node will be displayed, as will the node name when known, so you can immediately identify the location of each hop. If the node is not within your local London network, but is instead in the public network, it will be shown as a globe. Click on any node to open a popup, providing a history of the node.
Once youve discovered your path from London to the Office 365 servers, there are many ways to customize how the path appears to best suit your needs. Although each path through the cloud differs, one common theme is you are likely to see a large number of hops over the public internet. As is the case with the Architect and the Oracles dialogue, sometimes this level of detail might be superfluous or overwhelming. It might not always be useful for you to see every single node that the path might have taken through the cloud. In these instances, you have the option to collapse internet nodes down to a single node (simply called Internet) that represents all the cloud hops taken prior to the path reaching its end destination. This can help keep the path clean and uncluttered, so you can focus on nodes that might matter more to you.
Because the path taken from source to destination is not always fixed, you might want to keep an eye on the changes over time. ENA keeps a historical timeline of path discoveries for each traceroute batch that was run, going back to a maximum of 8 days. This can be found at the bottom of the dashlet. You can retrieve the discovered path for each batch by clicking on a discovery bar, which then displays the path for that time and date on the screen. The full data is retained for each batch, allowing you to investigate to the depth and extent that you would with the very latest discovery.
There might also be a number of unknown nodes in the path, which by default ENA does not show. These are nodes that might not respond to the SurePath traceroute request, in which case the traceroute path continues through to the next node. In this case, ENA returns no data for the IP address nor latency of the unknown node. However, the next time the traceroute runs along this path, it might go through a different node on the same hop which does return data for the IP address and latency time. If needs be, however, you can specify ENA to show you both known and unknown nodes.
In part 3 of this series, we will discuss how you can use SurePath to spot the issues in and beyond your network.