Firewall is Blocking Flows Ports
The most common cause of missing flow traffic is that a firewall is blocking the ports needed to receive flow updates.
The firewall may be somewhere on the network or on the flows collector host itself. Host-based firewalls are often configured to block inbound traffic on certain ports. On some versions of Windows, Windows Firewall blocks flow ports by default; RedHat Enterprise Linux and CentOS also ship with a firewall configured by default. Take a look at your firewall configuration to see if you might have this problem. The firewall may be somewhere on the network or on the Flows host itself. Most systems have host-based firewalls configured to block inbound traffic on certain ports. On some versions of Windows, Windows Firewall blocks flow ports by default; RedHat Enterprise Linux and CentOS also ship with a firewall configured by default. Take a look at your firewall configuration to see if you might have this problem.
Make sure that traffic on UDP/2055 (NetFlow/IPFIX), UDP/9666 and UDP/9996 (cFlow/jFlow), UDP/6343 (sFlow), and any other ports on which you have configured flow collection can reach the Intermapper Flows Server.
Intermapper Flows is unable to bind the required ports
If another flow collector is running on the same system as Intermapper Flows, it will not be able to collect any flow data because it will be unable to bind the required listen ports.
The netstat tool can tell you which process id or executable has the required ports bound.
- On UNIX hosts (including Mac OS X):
# netstat -a -p
- On Windows:
# netstat -a -o -b will, if run with admin permissions, show which processes have bound to which ports.
If another process or collector is using the same port, change the Listen port in the Flows Settings window and configure the collector to use the same port.
Significant system time skew between Client and Server
If Intermapper is running on a machine with a significantly different system clock time than the host running Intermapper Flows Server, a request for recent data can cause the server to try to fetch sessions that it considers to be in the future or far in the past. In either case, the result set might be empty.
If the cross-hatch pattern covers the entire graph, the client clock is ahead (in the future compared to the server clock).
If the cross-hatch area is not showing at all, the client clock is behind (in the past).
In either case, try moving or extending your time selection back or forward in time until you see a graph showing sessions.
Adjusting one or both system clocks is the preferred method for fixing this problem; otherwise, alerts and reports may be also misconfigured. If clocks are aligned, the cross-hatch area should occupy a thin strip at the right of the graph.
"Template Not Found" (NetFlow v9 and IPFIX only)
The NetFlow v9 and IPFIX formats use a template-based system; the flow export datagram format is described by a template. This format can differ from exporter to exporter, and each exporter publishes a template record approximately every 10 minutes.
The collector parses the NetFlow v9 datagrams from a particular exporter based on its published template. It is possible that flow records are arriving, but no template has yet been seen; in this case, Intermapper Flows must ignore the records until it receives a template in order to avoid interpreting a record incorrectly. In some cases it might take up to 20 minutes before a template is received.
Some exporters permit you to set the period between publication of a template.
Check the Exporters tab in the configuration panel. If your NetFlow v9 or IPFIX exporter is shown there, it has successfully sent traffic to Intermapper Flows. However, it may still be waiting for a template record, and until the record is received, no sessions appear.
Incorrectly Configured Exporter
It is possible that the configuration on your exporter is incorrect. For instance, you may have mistyped the destination IP or port, or enabled flow on an unused port.
To verify that your exporter is working correctly, capture some traffic on the host running Intermapper Flows and confirm that flow traffic is arriving at the expected port.
On Unix systems (including Mac OS X), you can use the following tcpdump command to capture UDP/2055 traffic on the interface called IFACE (typically, eth0 or en0):
# tcpdump -i IFACE port 2055 (You may need to use the ifconfig command to determine which interface to capture on.)
On Windows systems, we recommend the open-source packet-capture software Wireshark for this purpose. Wireshark is available at http://www.wireshark.org.
Unsupported Protocol (IPFIX only)
Intermapper Flows currently supports IPFIX over UDP; it does not recognize IPFIX over TCP.
