Drag the timeline cursor along the timeline to see how routes change over the selected time range.

The Center Time and Range elements are used to specify the window of time to review. By default, the time range is 10 minutes and the center time is the current time.

To view all routes that pass through a given hop on the Route Visualization:

1. Select Hops.
2. Click the hop you are interested in.
3. Click the filter icon ().
   • Only routes that pass through the selected hop are shown.
   • The filter is displayed at the top left of the pane.

To view all routes that pass through a given network on the Route Visualization:

1. Select Networks.
2. Click the network you are interested in.
3. Click the filter icon ().
   • Only routes that pass through the selected network are shown.
   • The filter is displayed at the top left of the pane.

To view routes taken by packets of a specific protocol:

1. Select either Hops or Networks.
2. In the Protocol field, select the protocol to filter on.
   • Auto shows the protocol used by Continuous Path Analysis (CPA) for each path. For single-ended paths this is ICMP. For dual-ended paths this is UDP.

You can see all the hops within a network by expanding the network and dismiss them by collapsing it.

To expand or collapse a network:

1. Select Networks.
2. Click to the left of a network name to expand the network.
3. Click to the left of a network name to collapse the network.

Click or hover over a hop to see information about a hop and all traceroutes that pass through it. This can include:

• Hop hostname.
• Hop IP address.
• Network the hop belongs to.
• Traceroutes passing through the hop including protocol, number, and percentage of all traceroutes sent during the selected time range.
• Average Round-trip time (RTT) over the selected time range.

Click or hover over a link to see information about a link and all traceroutes that pass through it. This includes:

• The hostname or IP address of the hops on either side of the link.
• Traceroutes passing across the link including protocol, number, and percentage of all traceroutes sent during the selected time range.

Click or hover over a link or hop to view traceroutes with a common link or hop. All traceroutes that pass through the selected link or hop become blue.

To call out points of interest on the diagram when sharing it (for example, via a screenshot), you can label a hop with up to two labels from data in the Route Visualization data bar.

To label a hop:

1. Select Hops.
2. Click the hop you want to label.
3. In the data bar, select the hop data you want to show on the diagram.

You can export a text file of hop data for all active (black) traceroutes for a given point in time.

To export route information:

1. Click Export.
   • A dialog showing the data to be exported appears.
2. Click Export.
   • A text file containing the hop data is downloaded to your computer.

Symptom

Several users at two sites (one on the west coast of North America, the other on the east coast) complained of a highly variable browsing experience. Sometimes pages loaded quickly and other times the load times were quite slow.

Investigation

It was determined that when the problem occurred, it seemed to happen when accessing the same set of web sites. As these sites were not normally monitored, web paths were configured to monitor them from both sites. Network Admins then reviewed the corresponding network path performance data and noticed highly variable round-trip times (RTT) for the network paths in question.

The End-user Experience chart confirmed the issue on the web paths during the same time period (script completion varied from about 8 seconds to over 30 seconds).

The Route Visualization was then used to explore the issue further. One of the network paths exhibiting the problem was selected and the time range being reviewed was specified. The first thing Network Admins noticed was that a single target hostname was shared by multiple hosts. This is typical for Content Delivery Networks (CDNs) where the same content is distributed from a variety of locations. The idea is that clients can access content at the host closest to them in order to reduce network delays.

By hovering over each of the target hosts, the Network Admins could see that three of the four hosts showed relatively high average RTT. For example, this one showed an average RTT of 90.03ms:

One host showed a relatively low average RTT of 1.83ms:

Using Networks view, it was clear that the “fast” host was closer to the source than the “slower” hosts. Packets had fewer networks/hops when traveling between the source and the “fast” host than they did traveling between the source and the “slower” hosts.


So why wasn’t content always being delivered by the host closest to the client? Network Admins knew that the CDN would provide the address of the host closest to the DNS resolver requesting it, and they had one resolver on the west coast and one on the east coast. As long as clients made their requests to their local resolver, all should work as expected.

Discovery

After reviewing the DNS configuration on client PCs it was determined that all were configured for both west coast and east coast DNS resolvers. Clients would sometimes be using a west coast resolver and at other times they’d use an east coast resolver. The DNS resolvers would respond properly with the IP addresses of the hosts closest to them, but this meant that west coast users could access content housed on the east coast and east coast users could access content housed on the west coast, causing longer round-trip times and longer script completion times.

Resolution

To resolve the issue, Network Admins updated the DNS configurations on the clients at each site so that they all used local DNS resolvers. Content was then delivered from the closest/fastest target host to the client, resolving the slowness issue.

Note: When remote offices use a central corporate DNS service, the same issue can occur. Browsing experience may not be optimal when accessing sites serviced by a CDN as remote office clients will access the target host closest to the DNS service, not necessarily the one closest to the client.

Symptom

Users were suddenly unable to connect to a major SaaS service.

Investigation

Network Administrators reviewed network paths to the service and noticed that all showed connectivity violations (). They then reviewed the Route Visualization to see if the problem was at the service or somewhere in the network.

Discovery

Network paths were filtered by the target service with the connectivity violations. In the Hops view it was clear that traceroutes on all paths were unable to make it to the service for approximately 45 minutes starting at about 1:17pm (black lines stopped part way to target).

But it wasn’t clear what all these routes had in common. They all seemed to be ending at seemingly unrelated hops. Changing from Hops view to Networks view it became clear that all routes ended at networks immediately prior to the target network.

By expanding the service’s network to see the hops inside it, it was clear that the traceroutes were being stopped at the edge of their network.

The issue was clearly located at the service provider’s network.

Resolution

After 45 minutes, connectivity was restored. The service provider had resolved the issue in their network.

Symptom

Problems were noticed when uploading data to a specific site.

Investigation

Network Administrators reviewed the network path performance data and could see significant and ongoing Data Loss on the path.

They checked out other paths from the same source and to the same target. They found some from the same source that had a similar Data Loss pattern occurring at the same time …

… and others that didn’t.

They then reviewed the paths on Route Visualization to find the hops common to all problem paths and not on any non-problem paths.

Discovery

By selecting the network paths that had the problem (labelled 2 and 3 in the diagram) as well as one that did not have the problem (labelled 1 in the diagram), it was clear that there were two hops in common (identified by the red box in the diagram) on the “problem” paths that weren’t shared with the “non-problem” path. Using the Networks view on the Route Visualization, they could see the network provider that was responsible for the offending routers.

Resolution

After a call to the network provider explaining the issue, they were able to investigate further and fix the problem.