Avoiding a Common Mistake in Configuring a Flow Collection

In the first post of this series I discussed the use of flow collection and NetFlow analyzer tools to meet challenges of bandwidth management. In the second post I addressed the need to filter flow data at collection time so that your traffic monitoring dashboard efficiently receives and displays the most important information.

In this third post, using a Cisco device as a point of reference, I call your attention to a common mistake in setting up a flow export and collection. The sequence of commands to configure a Cisco device to export flow data looks like this:

ip flow-export source <interface><interface_num>

ip flow-export version 5

ip flow-export destination <collector_IP_address> <port>

ip flow-cache timeout active 1

ip flow-cache timeout inactive 15

snmp-server ifindex persist

While all of these commands are important, the one that seems to trip up IT teams is the first one, with which you give the device an specific interface to use for exporting flow data--identifying the interface both by name and by index number.

So far there would seem to be little ambiguity; and in fact that is true. The ambiguity and source of error comes when the member of the team--who may not be the same one who assigned the flow export interface--readies the collector to receive the exported data.

Since, besides receiving flow data, a collector also monitors the network devices from which it collects data, the collector facilitates monitoring by performing automatic discovery of network devices within a specified IP address range; and the interface on the device that replies to ping is the one that the collector associates with the device, which often is not the interface that has been assigned for exports of flow data. And in such cases you have a setup error: though the network device is correctly setup to send flow data to the collector (ip flow-export destination <collector_ip_address><port>), the collector itself is monitoring the wrong interface on the network device. As a result, the collector does not display the traffic information contained in the flow data received from the device.

Trouble-shooting Flow Collection

An intelligent collector, when it receives flow data from an unknown device, posts an alert somewhere on the console. This is your best indication that a network device is not being properly monitored within the collector.

For example, see how the flow collector SolarWinds Network Traffic Analyzer (NTA) is an effective network traffic monitor that provides information in its console about flow data received from an unmonitored interfaces, and also makes it very easy to start monitoring the interface; resolving exactly the misconfiguration that many IT engineers encounter in managing different parts of a flow setup workflow. In fact, some IT engineers use the Unknown Traffic Events resource in NTA as a method for adding flow sources to NTA. After you configure NTA as an export target for the network device, and enter the device's SNMP community string in NTA node settings, then the device's interface IP address shows up either in NetFlow Sources or on the Unknown Traffic Events resource--where it can be added as a flow source with a simple click.