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.
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.
# netstat -a -p
# netstat -a -o -bwill, if run with admin permissions, show which processes have bound which ports.
If a process other than IMFlows has bound the required UDP ports, you will need to shut down that process or reconfigure both InterMapper Flows and your NetFlow exporter to use a different port.
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.
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.
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.
InterMapper Flows currently supports IPFIX over UDP; it does not recognize IPFIX over TCP.
Still have questions? We can help. Submit a case to Technical Support.