Blog :: Network Operations :: Security Operations

Flow Hopper for Root Cause Analysis

We recently released an update to Scrutinizer that had many improvements to Flow Hopper. Now, for those of you that don’t know, Flow Hopper is a patent pending technology created by our engineers here at Plixer. Many utilities that display the path a flow took through the network topology rely on routing tables or SNMP information, which are fairly unreliable in a redundant architecture, especially one with several path options to get from point A to point B. Flow Hopper works with nearly all versions of NetFlow, IPFIX, and other flow technologies. It allows Scrutinizer administrators to see the path a flow took through the topology. The user can click on each hop along the way to see details on how the flow may have changed.

How to access Flow Hopper

Before I outline some of the useful aspects of Flow Hopper, let me first explain how you can access it.

To start, you need to run a report on the exporter where the data you want to see is located. Because of the nature of Flow Hopper and multi-hop network communication, there are a handful of reports that will allow you to see the hop-to-hop details that Flow Hopper can show you. As such, when you select your report, be sure to choose either a Pair Report > Connections By Bytes, or a Pair Report > Connections By Flows report (see below). You can also view Flow Hopper if you are in Flow View, although, that will contain all the flow template details reported from the exporter, and may contain more information than you need.

Pair - Conversation Reports Scrutinizer  Flow View

Now that you are in an appropriate report, make sure you have selected one minute intervals (we want to see the raw data associated with the conversations) because that is the only way for the Flow Hopper option to show up in the report.

Flow Hoper One Minute Intervales

Once you are viewing one minute intervals for your report, you will see the option for Flow Hopper within the report itself. Notice the new icon that shows up next to the report details.


Viewing Flow Hopper Details

After clicking the Flow Hopper icon, a modal will open over the report. Flow Hopper will then run through a number of checks to provide an image of the bi-directional flows for the given conversation; this includes all devices (i.e. routers, switches, etc.) that the conversation went through. If any of those devices are experiencing performance degradation (high bandwidth utilization), the report will highlight those so you can view further details specific to those devices.

Flow Hopper

A major benefit of seeing the device-specific information, is that you can quickly identify where performance issues may be, and determine if your performance routing configurations are optimized. In an network configured with performance routing, for example, we shouldn’t see any degraded routers because the traffic should have been sent through another router to optimize the network. With that in mind, if you are seeing a report like the above, it may be a good idea to check your configurations. If you don’t use performance routing but see the above, it may be a good idea to set up routing policies to help move traffic through the network to prevent degradation on two of the hops.

With that in mind, when you see a degraded device in Flow Hopper, you can click the device and view additional information. In the case of the degraded router ( we can see that it was on the return trip that (Backward B – A) that had performance issues. Specifically, we can see that there was both excessive jitter and latency compared to the Forward (A – B) traffic. This is interesting information that can provide us with some insight regarding where to look to determine root cause.


While there are a variety of different paths that you can see with Flow Hopper, any report that you will run will provide you with additional information to help you determine what is causing network performance degradation. To learn more about determining root cause delay, check out a previous article I wrote on Cisco AVC Flow Exports. I highlight our Root Cause Delay report about halfway through.