One of my colleagues and I have gotten into a debate about netflow. He's an old Cisco hand and I've recently joined the cisco ops team after working on Juniper for a few years. The debate is whether netflow can be left on all the time or should only be used for temporary diagnostic purposes. I've reviewed the Cisco documentation and it says nothing about if being a short term only monitoring solution (or that leaving it on is in anyway problematic). Any pointers one or the other would be appreciated.
5 Answers
The new Cisco product line does netflow in hardware (and I believe the previous generation as well), but when I approach this question here are the things I typically ask myself:
- 1: Can I afford the bandwidth (i'm sure this won't be a problem most of the time)
- 2: Is netflow done in hardware on this device?
- 3: Can I afford the CPU cycles (if applicable)
- 4: how long you want to store said data on the device
- 5: how long should the data be stored on the aggregation point
I have only found benefits when leaving it on all the time, but I also keep an eye on how it's affecting the performance of my network.
To each his own!
We've got netflow running on loads of Cisco boxes 24/7 - Netflow is not a debug or traceoptions.
We've not seen any problems
Absolutely, providing that you design correctly.
Keep in mind that it may increase CPU (especially under abnormal circumstances) and that it adds traffic on the path to your collector.
If you CPU is rather idle and you don't have to worry about saturating your links, then there should be no issue.
Which models? Sampling enabled? Flow aggregation? Expected traffic mix?
All of these need to be asked- and answered- to determine the use of Netflow. In general the following observations tend to be true-
1.) The amount of actual traffic generated by NDE is very rarely an issue for enterprise networks. Thousands of flows per minute can translate to a few kilobits of actual exported data. If a given device is large enough to export a substantial volume of data, chances are excellent that this device has ample bandwidth available.
2.) CPU overhead can be a factor on some platforms, but typically only if CPU utilization is already on the high side, and moreso on older software-based platforms. If CPU is low and the box handles it in hardware, I wouldn't generally worry.
3.) On newer boxes you have the ability to define what sorts of traffic you want to observe, methods to aggregate updates and - most importantly - facilities for taking a sampling of traffic - so analyzing one in one thousand vs all packets on the box. This makes a huge difference - and, indeed, makes it even -possible- in higher volume environments.
4.) As I alluded to above, the type of traffic you're monitoring can make a tremendous difference. Hundreds of gigabits in a few long-lived flows consumes few resources while a few megabits of DoS attack from random addresses/ports can be a lot more stressful.
Ultimately, however, if you've turned on Netflow for diagnostic purposes and the CPU isn't getting hit too hard then it's more than likely fine to leave on for the duration. I'll also mention that NF was intended to be used on on ongoing basis - and that most shops who use it run it that way.
NB: Your colleague may have been using RE-based flow generation on Juniper boxes. This requires explicitly redirecting traffic to the processor on the box and is generally recommended against unless fairly heavily sampled. On newer geart (both Juniper and Cisco) most of the heavy lifting is dealt with in hardware and thus isn't as potentially service effecting.
in an all Cisco shop I've got neflow running 24/7 for a few years now. no issues at all
