In Support it’s common to hear, “I’ve configured my device to export NetFlow, but it’s not showing up in Scrutinizer.” There are a number of reasons that can prevent a NetFlow exporter from showing up in Scrutinizer and I would like to demonstrate, using a packet analysis tool, how to isolate the problem. It’s very likely that if you’re involved with network traffic analysis or administration that you’ve used Wireshark at one point or another and I want to go over some common ways to use Wireshark to analyze your NetFlow traffic.
Let’s start with the most common scenario; you’ve configured your Cisco Router to export NetFlow to your NetFlow analyzer server, but the device is not showing up in your NetFlow collector. This leads us to ask, are the NetFlow packets making it to the server and how can we verify? This is where starting a Wireshark packet capture on the NetFlow collector server comes into play.
How to use Wireshark filters
Once you’ve started the packet capture and begin to see the overwhelming flood of packets coming in, it’s time to isolate what you want to see by applying filters. In Wireshark, there are two types of filters Display Filters and Capture Filters. In this case we’re going to use Display filters to narrow down the packet capture. In order to display only NetFlow, sFlow, IPFIX, etc. type packets, you’ll want to apply a filter for ‘cflow’.
We can narrow the traffic down even further by applying source or destination filters with the following syntax:
ip.src == 10.1.1.251
ip.dst == 10.1.7.17
Don’t forget that you can && and || filters together (&&=AND, ||=OR).
If you applied this filter and you’re not seeing any packets show up, it’s a good indication that the NetFlow is not making it to the server and it’s time to start looking at what can be blocking the traffic. Are the flows going through a firewall and being blocked? Have you confirmed that your device is exporting NetFlow? Are you searching for packets coming from the ‘ip flow-export source interface’ IP address?
Let’s look at the other side of the problem; you’re not seeing your exporter in Scrutinizer, but you ARE seeing packets in Wireshark. Are you sending NetFlow to a port we listen on by default (2055, 2056, 4432, 4739, 9995, 9996, 6343)? Is the device set to “Inactive” in Scrutinizer? Are you over your licensed amount of NetFlow exporters? Have you verified the checksums of the packets coming in? I’ve run into this before with sending NetFlow over an ASA encrypted IPSec tunnel.
Wireshark does not verify checksums by default, so you’ll have to go to Edit, Preferences, expand the ‘Protocols’ section, find UDP, and check off “Validate the UDP checksum if possible”. This is important because the Operating System will not accept packets with bad checksums.
In order to be a best at NetFlow solution it’s important to have 1st class technical support and that’s something we pride ourselves on here at Plixer International. If you find yourself bashing your head against a wall, or just want to hear our lovely voices, call us at 1-207-324-8805 and we’re glad to help!