In the last blog I looked at NetFlow in some detail. In this blog I am going to talk about its major competitor sFlow.
sFlow is a different technology from NetFlow and is used to sample data going across network interfaces. It can sample frames between Level 2 and Level 7 of the OSI model at varying intervals and so it can be used to give an insight into network protocols other than IP.
But it doesn’t capture flows as such but samples the data instead. So, there is no caching and the sFlow exporter engine samples one of every 100 or 1000 packets, or other value that you determine. sFlow sends out datagrams to the collector rather than a flow.
This means that you generally get a much less complete picture of the conversations on your network. It is often at this point that security professionals generally say they want NetFlow rather than sFlow for a complete record for future forensic analysis.
However, for Network Performance monitoring sFlow has advantages, in certain situations.
sFlow was originally created by InMon corporation in 2001 and was handed over to sFlow.org in 2003 which made it openly accessible. sFlow is built into the hardware of network devices that support it and so in most conditions enabling it has no potential impact on performance whereas NetFlow might.
And sFlow is supported by a multitude of vendors of other networking devices including CISCO.
Typically, sFlow is very useful for network monitoring in very high speed LAN networks but not so good in very slow speed WAN links where it can lead to data link saturation. So for slow WAN links NetFlow is often a better choice.
As previously mentioned sFlow is also not great for the more forensic network security investigations as it samples and so by definition you won’t have a complete picture.
It is known for instance that sophisticated hackers may try to hide their activities with brief network conversations so that they don’t stand out. So, it’s possible that sampling may take much longer to find these, or it might miss them entirely as typical long-term sampling rates might be 1 in every 1000 packets.
It might be tempting to think that you simply need to crank up the sampling rate of sFlow to compete with NetFlow but unfortunately, it’s not that simple as under certain circumstances if you do that, sFlow can end up overwhelming a WAN link compared to data you would collect from NetFlow.
The pros are that sFlow will work on a wide variety of non CISCO network equipment as almost every major network vendor supports sFlow on their managed products.
And sFlow will work with protocols other than IP which may be of importance to you particularly if your environments are running legacy applications.
The downside with sFlow is the need to sample at a relatively low frequently which will give you an incomplete picture of what is happening from a security perspective. So, for IP based network threat detection and forensic analysis using the NetFlow protocol will give you much better visibility in most situations.
It’s useful to have a choice and advanced products like Plixer Scrutinizer or products from ntop will work with both NetFlow and sFlow and more.
Here is 5 minute video of the differences between the two protocols NetFlow an sFlow. The video shows an old version of Scrutinizer, but you’ll get the idea.
https://www.youtube.com/watch?v=YqJxSTISMt8
If you have any questions on which is better in your organisation NetFlow or sFlow then give us a call here at Info Stor and our team will provide you with free assistance in setting up a 30 day trial of Plixer Scrutinizer or ntop solutions. Info Stor have several highly qualified and experienced network performance and security experts who are always very happy to help.
Read more in my series of blogs:
1. Help! Why has my Cisco network gone slow again?
