When you log into your NetFlow Analyzer, it may be shocking to find one of your core devices is saying “no flows received”. I’ve seen this in support and know that it is important to have your devices sending NetFlow data to your collector at all times. I’ve found that the best way to uncover the issue is to narrow down the variables and isolate the problem. In this blog, I’d like to look at why flows are not being received by a NetFlow collector, by using a packet capture analysis tool, Wireshark.
We wrote a blog a few years ago discussing using Wireshark Filters to identify NetFlow that does a great job looking at how to use filters if you are new to Wireshark. I will be the first to admit there’s a lot I don’t know, so I often reference this page from their site that has a detailed list of Cisco’s Wireshark NetFlow/IPFIX filters.
Let’s assume you are able to ping the device and have verified that configuration for NetFlow version 9 or 10 (IPFIX) is correct. When we take a packet capture from the NetFlow server, we want to see if there are flows showing up in Wireshark. We can take the IP address of the router and apply a filter to your capture such as ‘cflow && ip.addr 10.10.10.10’ so we are just looking at the device and combine with a filter for NetFlow.
We see flows, but if we drill into the first flow set we can see that there is no template being found. Templates are used to decode the NetFlow data as it is received. Without a template, we won’t know how to decode the contents of the packets. To remedy this, we can check to see if a template timeout rate is set on our device. I have seen them set to 1800 seconds as defaults on some devices, which would mean we would be waiting for half an hour before seeing anything; we should set this to one minute.
If we have this setting already set, we should try restarting our NetFlow collector service, or the device itself, if needed. When we do receive a template we can verify the NetFlow packets by again expanding the flowset.
Now that we can see flows and their contents, we can breathe a moment of relief that we will see flows again in our browser. But when we log in, we see that we have a yellow LED saying that our device is exporting flows over one minute. What does this mean? Now this can occur if there is a long lived flow that is seen by our NetFlow analyzer. Usually this indicates that an active-timeout setting is not present on the device.
I use a nifty Wireshark filter to look at the flows with a duration longer than 60 seconds, to identify those long lived flows:
cflow.timedelta >= 60
You can combine this with the IP address filter we already used to narrow down the results to the device in question. Alternatively, if you forget this command you can find the flow duration in the packet capture and right click to apply as a selected filter.
If you find that you are seeing flows well over 60 seconds, and you have verified that the active timeout setting is entered into the device configuration, it may behoove you to call Cisco. Our packet capture analysis has uncovered that flows are being sent over one minute by using our timedelta filter in our third party tool.
If you are no longer receiving flows and are not able to identify the cause, don’t hesitate to call us in Tech Support for assistance. I would be happy to help.