Path Discovery

Summary

Hawkeye Path discovery is a methodology to provide visibility into network topology from a location with Hawkeye endpoint to any remote location.

The discovery relies on standard protocols packets being sent to the network to find out about nodes being traversed. There is therefore no need for specific software or hardware being deployed on the path nor at remote location.

Path discovery allows to discover application specific paths by way of configuring the protocol and ports used by an application to discover the route taken by packets to reach destination.

Path discovery leverages Hawkeye test execution framework to allow historical data collection and perform analysis in real time or with retrospective views.

Path Discovery Methodology

The path discovery relies on the following steps for path analysis:

  1. Path discovery: packets are sent using TCP, UDP or ICMP protocols with different TTL tags and responses from network elements are captured to indicate information about traversed nodes. This sequence is repeated several times (configurable) so that potential different paths are discovered and displayed in a graph.
  2. Nodes network performance analysis: 100 ICMP packets are sent to each identified nodes to find out about basic IP performance metrics using ICMP protocol and report on packet loss rate and round trip times (RTT) to the traversed nodes.

  3. Fail criteria is determined if the last two nodes are unknown nodes. If the configured number of hops is more than the count of nodes to the destination, it is not uncommon for the nodes beyond the destination node to be marked as unknown nodes. This will result in the test being flagged as fail.

Setting up the Path Discovery from an Endpoint

Path discovery is available from Hardware endpoints and XR2000 VM as a real service.

To set it up, go to test execution-real service screen and select your endpoint and Path discovery test type.

The following options are available:

Destination server: is IP or URL of the remote server that needs to be reached to discover path. It can be hosted in private network, private or public cloud, public internet etc.

Traceroute counts: number of path discovery attempts executed to find out about path. This number must be into 1-20 range.

Maximum number of hops: the traceroute are attempted until destination is reached or for a maximum number of hops between source and destination.

Protocol: protocol used for path discovery. The default is TCP which is recommended as it is the most likely to provide accurate results. Other options available are UDP and ICMP. UDP would function similar to TCP but using a different destination port and without SSL, while ICMP is going to issue pings with TTL. It is important to know that some nodes on the path may react differently to these protocols: some routers/switches are blocked for ICMP responses for example and allow TCP or UDP, so the discovery may provide more information with one protocol or the other.

Destination port: this is used if protocol is TCP or UDP. The discovery messages will be sent with destination port set to this value and using a random source port. This can again be important when determining routing/COS management details on the path for specific protocol/port. Using the protocol and destination port a specific application would use allows finding about how the associated packets would be handled by the network.

Timeout (sec): this is the maximum time the path discovery will be allowed to run – in case the overall process exceeds this maximum allowed time the test will error out and free the test execution queue.

Interpreting Test Execution Results

Path discovery display is highly visual allowing quick understanding of the traversed nodes for an endpoint.

The picture below shows an output of the function:

The different nodes detected in the path discovery are shown with squares.

When messages are sent and there is no responses from the network, an unknown square is shown.

This typically happens when packets are dropped on their way back or forth, or when the node that is on the path is configured so that it does not advertise the drop to source.

The links between the nodes are shown with different thickness levels to illustrate the distribution between paths.

As shown in the example below, it is also possible to investigate the packet drops or Round Trip Time (RTT) detected in the path by configuring a threshold.

The RTT and packet loss are displayed based on ICMP messages being sent to the nodes. The metric is displayed only if at least one ICMP answer is received. The assumption if 100% packets are dropped is that the node is blocked for ICMP responses and therefore no data is displayed.

The ICMP packets are 100 bytes long and 100 of them are sent with 20ms interval for collecting the information. The base ICMP sequence is the starting ICMP sequence number that gets incremented with each packet.

During the path discovery, the information about Autonomous System (AS) to which the node belongs is collected. This information is belonging to an organization having routers on the public internet. It will identify service providers or autonomous entities being traversed to reach destination.

Routes can be displayed with only showing Autonomous System (AS).

When the Hawkeye server has access to internet it can collect information to what AS code is registered.

Next figure illustrates a path discovery shown with AS grouping.

The next figure illustrates a path discovery showing the changes in QOS. When the Path discovery test was configured the required QOS (DSCP) value was selected. As the packets pass through each network node the specific node can change the QOS setting for each packet. The figure below shows when the QOS changes box is selected that the user has the ability to select a node to view its details which will include the QOS value assigned to all packets being forwarded to the next network node.

By clicking on any nodes on the graph, full information about the results collected will be displayed:

  • Hop defines the path # it was detected at.
  • IP if the IP detected or unknown if node does not respond to traceroute packet.
  • Network is detected through AS.
  • If available the full registered address for AS will be displayed.
  • Frequency shows how many times this was detected using this node.
  • Loss and RTT (round trip time) are gathered through ICMP messages.

  • DSCP is not available for the last node.

  • The DSCP information for a node will not be displayed if the TCP/ICMP messages are not responded to by the node.

The traceroute button will display in a table all the information collected for all steps in the path – see example below:

This will show the User the different steps and what nodes were involved. The ICMP extensions contain feedback on MPLS network labelling and protocol information.

Path Discovery Failures

If a Path Discovery test has an error message indicating a timeout, follow the following steps in order:

  1. Reduce tracecount in configuration of Path Discovery test. This will reduce amount of scans and may potentially reduce number of available routes identified to destination.
  2. Reduce maximum number of hops in configuration of Path Discovery test.
  3. Increase test timeout in configuration of Path Discovery test. If this is increased above 3 minutes, refer to Parameters Effecting Performance for information on how to increase overall timeouts for Real Service tests.

Some nodes will respond to the first ICMP message then not respond to any other ICMP messages from the same source for a certain time period, this does not reflect a problem.

If you use an IP for a well-known web site, such as Google, the test may be flagged as a fail although the Path Discovery test was able to successfully reach and map the organization.

If the web site supports IETF defined “anycast routing”, IPv4 or IPv6 address will be routed to the nearest operational server, which would have a different IP address to the entered destination IP defined for the test. Thus, this would be marked as a Fail but the traceroute and network map to the destination will be correct.