NetBeez Releases Path Analysis

NetBeez Releases Path Analysis

I am super excited to announce the release of Path Analysis as part of NetBeez version 8.0. This new functionality will be officially presented during the Path Analysis Webinar that we’ll host next Tuesday, May 18. I encourage you to register and attend the webinar as our fellow co-founder Panos Vouzis will give a live demonstration and share details about it.

Why is this feature important, and why am I so excited about it? Path analysis is a key requirement to monitor the Internet and understand how its performance impacts the overall digital experience of remote users; it helps network engineers and operators to discover the underlying network topology and quickly pinpoint where performance degradation is occurring.

What’s Path Analysis?

I generally introduce path analysis as traceroute on steroids. This feature comes with a graphic user interface that shows all the discovered paths between a source agent and a destination host or service. Like in traceroute, the user can review hop by hop the routers discovered between the two points. The following screenshot shows an example of a network topology discovered by path analysis between a NetBeez network monitoring agent and an Internet website.

path analysis

For each hop path analysis provides extensive information that is valuable for network analysis and troubleshooting, such as:

  • IP address and reverse DNS (if available)
  • Round-trip time (RTT) real-time and historical
  • Color coding of the RTT value (orange if above 100 ms. and red if above 150 ms.)
  • Autonomous System Number (ASN), and AS Name
  • Geo-IP location with coordinates

The path analysis plot also enables the user to highlight hops based on RTT, IP, DNS, and ASN, making it easier to troubleshoot performance issues with specific nodes.

Path analysis is not just a different, cooler way to display a network topology. Path analysis is very innovative from a tracing capability, overcoming limits of traditional traceroute. Let me explain this a bit more …

Traditional Traceroute and Equal Cost Multi Path Networks

When a host runs traceroute, it generates a series of packets aimed at triggering a Time Exceeded ICMP message from each router along the way to the destination. This is simply done by manipulating the TTL field of UDP probes. With this method, the source host discovers the IP addresses and round-trip time of all intermediate hops that trigger the ICMP message “Time Exceeded”. Hosts that don’t reply are marked with the notorious asterisk *.

One problem with traceroute is that it doesn’t work well with Equal Cost Multi-Path (ECMP) networks where routers load balance traffic on a per-flow basis. This behavior was reported by the paris traceroute team at the University Pierre et Marie Curie Sorbonne Universités in Paris. What the team at the Sorbonne noticed was that for most routers ICMP Time Exceeded packets generated by traceroute don’t look as if they belong to the same flow. They discovered that routers don’t just use the packets’ five-tuples (source and destination IP, source and destination TCP/UDP port, and protocol) to group them in flows and do load balancing. Through experiments, they discovered that routers also use the TOS, the ICMP code and the ICMP header checksum fields. As a result, traceroute can report an incorrect network topology, reducing its efficacy in troubleshooting network performance issues. Let’s illustrate this with a quick example.

The following network topology represents router L with two ECMP links to reach the destination. Router L may forward one traceroute probe packet to router A and one to router B.

 

The topology described by traceroute may look as if routers A and D are directly connected like on the above diagram. In reality, the two routers are not directly connected, and reside on a different path. Network engineers troubleshooting a performance issue between the source and the destination may mistakenly point the problem to be with router A, while in reality the problem is with router B, for instance. The same is true for router C and D.

Traceroute from Paris to Dublin

To overcome this limit, paris traceroute crafts UDP packets so that the return ICMP Time Exceeded messages appear to belong to the same flow, thus avoiding the issue described. This is done by manipulating the UDP checksum of the traceroute probe packets crafted.

To implement path analysis in NetBeez we adopted the dublin-traceroute command, which is a derivative of paris-traceroute. We picked this variant also because it reports the presence of NAT devices along the path, broken NATs, and MPLS labels if available. The adoption of dublin-traceroute enables NetBeez users to be more accurate when discovering the real topology of ECMP networks. Path analysis simplifies the troubleshooting of Internet performance issues that remote users are experiencing.

Path Analysis and Flows

In path analysis we introduce the concept of flow. As explained earlier, a flow is a sequence of packets that belong to the same connection. ECMP routers configured with per-flow load balancing will forward packets of the same flow along the same path. The aggregation of multiple flows run in parallel enables NetBeez to take a screenshot of the network topology at a specific time. By default, at each path analysis run NetBeez generates twenty concurrent flows. This number, which can be overridden by the user, is estimated to be optimal to discover as many Internet paths as possible between the source agent and destination.

flow ID path analysis

With NetBeez, the user can review individual flows, as well as aggregate them together to see if some specific paths are more common than others. This will help the troubleshooting process to see what are the most used routes.

What else is included in NetBeez Version 8.0

Version 8.0 will also include two other very important features, specific to NetBeez Wi-Fi sensors. The first one is ad-hoc packet capture, which will enable users to troubleshoot client connectivity issues by listening to the air. The second feature permits NetBeez Wi-Fi sensors to run tests also on the Ethernet interface, something not possible before. I can’t be more proud of the incredible work that the team has done. Seeing three high value features in one release is a real testament of the team’s commitment to our user base.

Watch the Path Analysis webinar recording