Filtering on traffic between subnets

When looking at sFlowTrend traffic graphs and reports, sometimes you will want to focus on specific traffic of interest, for example understanding traffic patterns between subnets. To do this you can use a filter in a network traffic Top N chart or report. The help includes a section on filtering which outlines how to build filters. The UI for both network traffic TopN charts and report query sections includes a filter builder. The filter builder has a dropdown menu that lists the traffic database keys that can be used as filter terms. You can also use filter functions in a filter and these filter functions can be typed directly into the filter bar. One such filter function is the inSubnet function. There are two forms of the inSubnet filter function:

inSubnet(address, subnet, maskBits)

In this form address is the database address key field that you would like to test (for example ipServer), subnet and maskBits define the subnet to test against for inclusion. For example inSubnet(ipServer, "10.1.5.0", 24) will return true for any IP server address that is in subnet 10.1.5.0/24. Note the quotes "" around the subnet address. 

This form of the filter function can also be used for testing IPv6 addresses for subnet inclusion. For example the inSubnet(ipSource, "2001:db8:a::", 64), can be used to show traffic sourced by any address in the subnet 2001:db8:a::/64.

This example shows the top connections for server addresses in the 10.1.5.0 subnet. It also uses a custom Top N chart that includes serverAddress, serverPort, clientAddress as key fields, so that the connections are not broken out by ephemeral client port. See the help for more information on configuring Custom Top N charts.

inSubnet(address, subnetName) 

In this form, address is the database address key field that you would like to test (for example ipSource) and subnetName has previously been defined as a subnet in the sFlowTrend configuration (see the help section on configuring subnets). For example inSubnet(ipSource, "East Bay") will return true for any IP source address that is in the predefined subnet named East Bay.

Running sFlowTrend in a Docker container

sFlowTrend is now available as a Docker image. Docker makes it really easy to try out sFlowTrend, and you can also use it as a convenient way to run it in production. It will work for both the free sFlowTrend, or for sFlowTrend-Pro - just select the free option, or enter your license number in the System Configuration>License dialog.

To run sFlowTrend in Docker, use the command

docker run -v /var/local/sflowtrend-pro:/var/local/sflowtrend-pro -p 6343:6343/udp -p 8087:8087 -p 8443:8443 -h sflowtrend-pro -e TZ=Europe/London -d --restart unless-stopped sflow/sflowtrend

This will run the latest version of sFlowTrend. You can select a specific version using the appropriate tag, e.g. sflow/sflowtrend:6.5.04. See the docker hub repository at https://hub.docker.com/r/sflow/sflowtrend/ for more information on the versions available. Some explanation of the command line options used is worthwhile:

• -v /var/local/sflowtrend-pro:/var/local/sflowtrend-pro mounts the specified directory on the host at /var/local/sflowtrend-pro in the container. This means that the data and configuration will be persistent, and available in this location. Instead of this, you could optionally use a Docker volume, in which case the persistent data would be in the volume. If you don't specify the volume, the data will be lost from one container to the next - this might be OK for evaluation purposes.
• -p 6343:6343/udp -p 8087:8087 -p 8443:8443 publishes the required network ports. You can map the ports used in the container to something different on the host if you like. UDP port 6343 is the sFlow port, and if you use something else then your network infrastructure would need to be configured to send sFlow on the new port. Port 8087 is used for the http connection for the sFlowTrend web client, and port 8443 for the https connection; if you change these, then the new port would need to specified in the web browser you are using to connect to sFlowTrend.
• -h sflowtrend-pro sets the hostname of the container. This is important if you are using sFlowTrend-Pro: you would need to use the hostname that matches your license. The hostname is also shown on the dashboard.
• -e TZ=Europe/London sets the timezone of the container. All data in sFlowTrend is shown in this timezone, so it is important that you set it correctly for your location. You can use a standard Linux timezone identifier here.
• -d runs the container in the background.
• --restart unless-stopped automatically starts the container when the Docker engine starts.

When you first run sFlowTrend in Docker, the latest version will be pulled from the Docker hub. After this, because it is cached locally, on future runs it will run the same version. If a new version of sFlowTrend has been released, you can force this to be downloaded using the command

docker pull sflow/sflowtrend

Configuring sFlow using SNMP in a container

sFlowTrend has the ability to configure sFlow on some switches using SNMP. This works with only a few vendors devices, but can be easier than using the CLI on the switch to set up sFlow. If you are using SNMP to configure sFlow with sFlowTrend in a Docker container, then you have to ensure that sFlowTrend knows the correct address to use for sFlow data. This is because, using the default Docker network (bridge), the container is effectively run behind a logical NAT device. The easiest way to set this up is to first run the container as above, and then stop it after 10 seconds or so; this will create the file structure and empty configuration file in /var/local/sflowtrend-pro. Then follow the instructions for the configuration option sflowtrend.natReceiverAddress at http://inmon.com/products/sFlowTrend/help/html/advanced.html#advanced.configuration.server.

When you run the container a second time, the address you entered will be available in the System Configuration option for the sFlow receiver address. Select this, and the sFlow data should be directed to that address.

Using sFlowTrend to analyse IEEE 802.1ah (PBB or MAC-in-MAC) traffic

The Provider Backbone Bridges (PBB or MAC-in-MAC) standard IEEE 802.1ah defines an architecture and protocol that allows service providers to build large, scalable ethernet bridged networks, interconnecting multiple Provider Bridge networks without losing each customer's individually defined VLANs. It operates using a MAC tunnelling scheme in which a customer packet, including MAC addresses, is encapsulated in a new ethernet frame with new MAC addresses (the backbone bridge MAC addresses). This eliminates the need for backbone core bridges to learn all MAC addresses of every customer and provides complete separation of provider and customer domains. However, visibility of both the backbone traffic and the encapsulated customer traffic is important for troubleshooting configuration problems and managing performance. sFlowTrend (version 6.5 onwards) understands the IEEE 802.1ah frame format, decoding the outer backbone header and the inner customer frame. Here is an example of using sFlowTrend-Pro to gain full visibility of traffic in a PBBN.

The diagram below illustrates a typical IEEE 802.1ah PBB frame and shows the key fields used by sFlowTrend-Pro to represent the header fields. The sFlowTrend-Pro help gives a full list of the MAC, VLAN, priority, and IEEE 802.1ah key fields.

One way to view the details of traffic in a PBBN, is to use the Network > Top N tab and create a custom top N chart.

In this example we have build a custom top N chart showing the backbone header fields and the MAC and IP addresses and VLAN in the customer frame. Selecting this custom top N chart from the Chart selection list, generates a chart showing the details of the PBB traffic.

Using sFlowTrend to analyse tunnelled and encapsulated traffic

Layer 3/4 tunnels (Geneve, GRE, NVGRE, VXLAN) are often used to virtualise network services so that communication between virtual machines can be provisioned and controlled without dependencies on the underlying network. Hiding the physical network topology is a useful abstraction which offers a significant benefit of operational flexibility, however lack of visibility into the physical and virtual network can result in poorly placed workloads, inefficient use of resources and as a consequence, performance problems. sFlowTrend-Pro v6.5 provides the comprehensive visibility into tunnelled traffic which is essential for effective management of these more complex environments. Here is an example of how you can use sFlowTrend-Pro to understand and analyse tunnelled traffic.

sFlowTrend-Pro recognises VXLAN tunnelled traffic using the well known port UDP 4789. It then decodes the encapsulated packet in the UDP payload and stores the encapsulated packet header fields using key fields such as sourceAddress.1, destinationAddress.1 etc. It also records the VXLAN Network Identifier (VNI). The sFlowTrend-Pro help includes a section on L3/4 encapsulations which lists the key fields available for tunnelled traffic. One way to view a VXLAN tunnel is to Network > Top N tab and select the Top source-destination flows chart and then add a filter isVXLAN:

If you click on the source and destination address in the legend, you can also add the tunnel end points to the filter:

To see the traffic inside the tunnel, you can build a custom top N chart (click on the edit button next to the Chart selection list):

In this example we have built a custom Top N chart with fields vni, sourceAddress.1, sourcePort.1, destinationAddress.1, destinationPort.1. Selecting this custom top  N chart from the Chart selection list, generates a chart showing the details of the traffic flows carried by the tunnel that we are filtering on:

You can use a similar technique to look at traffic flows carried by other tunnelling protocols (Geneve, GRE, NVGRE).

You can also create reports using the Reports tab and creating a query section using Advanced settings to select key fields for encapsulated packets.

Upgrading sFlowTrend

sFlowTrend will tell you when a new version is available, if it has internet access. You can also check using Configuration>Check for updates in the web client.

To upgrade sFlowTrend, you just need to install the new software on top of the old. There's no need to uninstall first, that is all taken care of by the installer. The one thing that is important to remember is to use the same version of installer as you did for the initial install:

• If you used the 32-bit Windows installer, update using the 32-bit installer. Just run the new installer, and it will uninstall the old version and install the new one.
• If you used the 64-bit Windows installer, update using the 64-bit installer. Again, just run the new installer.
• If you used the interactive Linux installer, use this to upgrade, again by running the new installer.
• If you used a Linux rpm package to install, then upgrade using the command
# rpm -Uvh sFlowTrend-linux-version.rpm
• If you used a Linux deb package to install, then upgrade using the command
# dpkg -i sFlowTrend-linux-version.deb

If you want to change how sFlowTrend is installed (eg, from the Linux interactive installer to a package), then you must first uninstall sFlowTrend using the original method. This will not remove any configuration or data. Then install using the new method. If sFlowTrend was originally installed using the interactive installer, you can use the uninstall program located in the main installation directory to uninstall it.

The data and configuration should not be affected when upgrading, but you can of course back this up to be sure. The best way is to stop the sFlowTrend-Pro service, then just copy all of the contents of the sFlowTrend-Pro data directory (this is called the home directory in the user interface, you can see it using options dialog in the Java client or the system config dialog in the web client). Once you have copied it (or zipped or tared it up as appropriate), then restart the service.

Migrating to a new server

Sometimes you need to move your sFlowTrend installation to a new server. This is quite easy to do without losing any data, but you have to be careful to make sure it goes smoothly. All of the data is in the sFlowTrend home directory. For free sFlowTrend, this contains the configuration and user preferences (when using the web client). For sFlowTrend-Pro, it also includes all of your traffic data contained in the database.

First, find the location of the home directory on the old system. If you installed sFlowTrend using an interactive installer, then you would have selected the directory during installation. If you used a package installer on Linux, then you can't change the location. In any case, you can find the name of the directory using Configuration>System Configuration in the web client:

Next, stop the sFlowTrend service on the old system. It is essential that you do this step, otherwise data is likely to be corrupted.

On Windows, use Windows Administrative Tools>Services, find sFlowTrend-Pro server, and stop it.
On Linux, depending on which distribution you are using, one of the following commands will work:
# systemctl stop sflowtrend-server
# service sflowtrend-server stop
# /etc/init.d/sflowtrend-server stop

Once you have stopped the service on the old system, move to the new one. Go ahead and install sFlowTrend on this system, again taking note of the home directory. Then, stop the sFlowTrend service on the new system - again, it is critical that you do this step. After this, copy the entire home directory from the old system to the new system, ensuring that the ownership and file permissions stay the same. Start the service on the new system.

At this stage, sFlowTrend should be running on the new system. There may be a couple of other tasks that need to be done. First, if you are using sFlowTrend-Pro and the new system has a different hostname from the old, then you will need to update the license to have the new hostname. To do this, go to www.myinmon.com, log in, and click the Request New Key link to the license. The license will be updated shortly. Next, if the IP address of the new system is different, then you will need to update the sFlow configuration on your infrastructure to forward sFlow data to the new system, rather than the old. There's more information on configuring sFlow in this blog post, and in the on-line help.

Now you have sFlowTrend running on the new system, you can uninstall it on the old. To recover some space, you can also delete the home directory on the old system, as this isn't automatically deleted when uninstalling.

Diagnosing abnormal network traffic levels

A common question that network managers handle is "Why is the network slow?". In many cases, poor network performance can be caused by a localised overload. This may be caused by mistakes in the network configuration, equipment malfunctions, inadvertent mis-use, or because capacity is insufficient for the normal load. Since an sFlow enabled network and sFlowTrend provide complete visibility of network usage, it is easy to pinpoint overload conditions and take appropriate action. It is even possible to receive alerts so that proactive controls can be implemented to prevent poor performance occurring. Here is an example of how sFlowTrend helps you identify and diagnose network overload conditions.

Dashboard, Thresholds indicates an abnormally high level of unicast traffic. Click on the unicast indicator to view the Thresholds tab and find out why.

The Thresholds tab indicates the switch 10.1.4.253 is experiencing the abnormally high level of unicast traffic. Click on the unicast indicator to see which interfaces are affected.

The interface with ifIndex 23 is most affected by the unicast traffic. Click on the unicast indicator to bring up the menu and select Root cause to see who and what is contributing to the unicast traffic.

100% of unicast frames are sent from hosts in the External subnet to hosts in the External subnet. Looking at the fourth row, 58% of the unicast frames are sent from 208.65.153.251 TCP:80 to 64.151.76.36. From this we can conclude that the major factor causing the abnormally high unicast traffic is web traffic from server 208.65.153.251 (which is in the External subnet). To see for how long abnormal levels of unicast traffic have affected this interface, click on the Network > Counters tab (or choose View chart from the Root cause tab menu).

The Network > Top N tab displays the details of the top connections.

In this example we have created a custom top connections chart that allows us to focus on the server port and ignore the ephemeral client port.

The Network > Circles tab allows you to visualise the traffic flows between groups of addresses to help understand the communication patterns across the network.