NetFlow sampling – Why bother?
Posted in NetFlow, Network Traffic Analysis, Network Traffic Monitor, sFlow on August 14th, 2009 by Ryan
If you’ve done any comparison reading regarding the differences between NetFlow and sFlow, then you understand that NetFlow provides a much broader visibility into your network traffic stream, as opposed to being limited to the sample packets that sFlow provides. 
Usually, when a person asks which I like better, I vote for NetFlow, simply because I’d rather see the whole story, as opposed to x% of it (based on sampling rate).
So if NetFlow is so great, why would a Cisco router support NetFlow sampling, when it can do so much more?
Depending on how much traffic you are working with, sometimes efficiency and performance are necessary priorities.
With more traffic, comes more NetFlow records; with more NetFlow records, comes higher CPU utilization and an over-encumbered NetFlow collector to try and sort through it all.
So if you are running into issues with your routers and switches sending more flows than a single collector can handle, NetFlow sampling might be an option in mitigating the amount of flow records being produced.
Do you have any remote sites that are considered low priority for network monitoring? Maybe you could enable NetFlow sampling for those devices.
Currently, Cisco offers three methods of NetFlow sampling at your disposal.
Option 1: Random Sampled NetFlow
This configuration will enable the router to take random samples from your packet stream.
Option 2: NetFlow Sampler
This configuration will enable the router to take a sample of every X packet (e.g. packet 101, 201, 301, 401).
This setup is good for devices with predictable traffic patterns.
Option 3: NetFlow input filters
With this option, you can create a class map for specific flow types that you wish to capture. How about capturing all flows that have a source or destination of port 80? Very cool, if you are only interested in specific traffic behaviors.
If this is something that has interested you, check out this Cisco guide to enabling NetFlow sampling on your router.
Tags: Cisco NetFlow, NetFlow Collector, NetFlow sampling, NetFlow Vs. sFlow, sFlow
Hello , we just bought scrutinizer and we are exporting sflow and netflow from both Brocade (recently installed) and Cisco router which are almost connected back to back with each other.
Brocade is sending samples 1 out of 512 and Cisco is also configured to send netflow samples at same rate 1 out of 512. Sflow also samples other than IP packets but in this scenario there is less than .5% of non-IP traffic in the network, cause we don’t allow any other traffic other than IP in the network.
Now when I compares the interface top traffic status of Brocade interface and Cisco interface…the traffic report of Brocade interface is almost useless, misleading but on the other hand Cisco interface traffic reports still looks better and accurate just like regular netflow.
Now my question is when both routers are sending at the same sampled rate how scrutinizer differentiate, analyzes and interpret the sflow sampled packets compared with netflow sampled packets?
is Scruitinizer heavily optimized and more focused just for Netflow analyzing and reporting?
Hi Samit, Scrutinizer handles all flows received similarly, whether sFlow, NetFlow, IPFIX, etc. Scrutinizer receives and then reports what is received. In your case, I would recommend contacting our Technical Support team to determine if the Brocade switch is under-reporting, and if so, why. Plixer Technical Support can be reached at 207-324-8805 x4, or by completing an online support form at: http://www.plixer.com/support/support_request.php
[...] sampling is available for NetFlow it’s not a requirement. People just don’t like sampled data. Especially security [...]