A few times a week I'll get emails from PRTG stating one of my netflow sensors has dropped data (Code: PE082). I have my Cisco router configured with an active timeout of 5 minutes and the sensor configured for 6, as recommended. Something to note about this setup is that the router is sending the netflow packets over the WAN to the PRTG server. From my research that didn't seem to be discouraged, but who knows?
This remote router was recently setup to export flows and ever since I have been getting these messages. For the last year or so I've had another router local to the PRTG server exporting flows without issue. Each of these routers has 2 netflow sensors, so 4 in total. I don't think this is a matter of the server not being able to keep up. Processor is generally below 10%.
The second part of this issue is on the remote router I'm seeing erratic results in the form of bandwidth numbers being far too high. It will report 17 Mbps usage when that router only has 3 Mbps via 2 bonded T1s. A few erratic results like this completely skew the scaling of the graphs and make them unusable. Any idea why this is happening?
Thanks, Todd
Article Comments
The router is a 3640 with IOS 12.4(3g). The time on the router is exactly matching the PRTG server, the router is configured to use a NTP server and I confirmed the times are the same using "show clock" on the router. I tried using your netflow tester but it would not collect any data. My method was to shutdown the PRTG services on the server and launch the tester with the same port info PRTG was using for netflow, but no data has shown after 10 minutes of waiting. Keep in mind PRTG itself was successfully gathering data from one router and gathering erratic data from another (the one start started this thread), but I'm not seeing anything from either of those with the tester. So I do not believe it's a configuration problem on the routers.
Is there any reason I shouldn't be sending netflow data from 2 different routers to the same port on the PRTG server?
Thanks, Todd
Nov, 2012 - Permalink
Please check if you have a "Long Aging Timer" entry for the device. The command in case would be "mls aging long". By default this value would be set to 1920 seconds. If you do have this value entry, please reduce the same and try again.
Nov, 2012 - Permalink
I do not have an MLS entry on this router, nor does this router even seem capable of adding such an entry as it doesn't recognize the mls command in global configuration mode.
Todd
Nov, 2012 - Permalink
Please turn on the raw data logging option within the sensor, then let the same run for a while. After a couple of minutes, check the time the error message ensues, as well as the time of the peak you are discerning.
Actually, it might be better if we handle this issue directly as a support case. As such, please forward us an email to support@paessler.com refering to this thread, including the raw data file mentioned above.
Nov, 2012 - Permalink
I set "Log Stream Data to Disk" to All Stream Data, is that the same thing as raw data logging?
I'll email the results to support and take it from there.
Thanks, Todd
Nov, 2012 - Permalink
PE082 with a correct active timeout configuration is odd.
With our NetFlow Tester check on the incoming flows (check the flow details option) and compare this to the local time.
Beyond that, what precise Cisco router are you wanting to monitor?
The peaks you discern could be a further symptom of problematice time data. If you check on the overall volume over a longer period of time (hours), does the same seem realistic? Is the router's system time set the same as that on the PRTG server?
In case you are wanting to monitor an ASA, please have a look at How to monitor Cisco ASA Firewalls using NetFlow 9 and PRTG?
Nov, 2012 - Permalink