Comments on: NetFlow vs. sFlow for Network Monitoring and Security: The Final Say http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/ The NetFlow & sFlow Reporting Resource Sat, 18 May 2013 18:42:11 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: mike@plixer.com http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-457098 mike@plixer.com Sat, 23 Feb 2013 12:19:48 +0000 http://www.plixer.com/blog/?p=17774#comment-457098 Another blog on NetFlow Vs. sFlow: http://www.plixer.com/blog/netflow-vs-sflow-2/netflow-vs-sflow-which-is-better/

]]> By: A Firewall Monitoring Tool You Didn’t Know Existed: NetFlow and IPFIX - NetFlow & sFlow Network Monitoring - Systrax http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-382991 A Firewall Monitoring Tool You Didn’t Know Existed: NetFlow and IPFIX - NetFlow & sFlow Network Monitoring - Systrax Fri, 07 Sep 2012 14:20:41 +0000 http://www.plixer.com/blog/?p=17774#comment-382991 [...] Don’t use sFlow. [...]

]]> By: mike@plixer.com http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-381547 mike@plixer.com Mon, 03 Sep 2012 21:34:52 +0000 http://www.plixer.com/blog/?p=17774#comment-381547 Thank you Peter for continuing to post. I agree, sFlow has tremendous value. I will make sure that I do a better job of highlighting it’s strengths. By the way, although I sometimes lift an eyebrow when reading your blogs, I appreciate the effort you put into them. I know it isn’t easy! Maybe we’ll meet some day at Cisco Live.

]]> By: Peter Phaal http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-381463 Peter Phaal Mon, 03 Sep 2012 17:20:13 +0000 http://www.plixer.com/blog/?p=17774#comment-381463 Mike, each technology has it’s strengths and weaknesses. Choosing whether to use sFlow or NetFlow in any given situation depends on customer requirements and the capabilities of the customer’s equipment. I think if anyone reads the articles you referenced, they will find that they make reasonable points that are worth considering.

Given that the tag line for Scrutinizer is “NetFlow & sFlow Analyzer” – it has been surprising to see how anti-sFlow Plixer has become. NetFlow/IPFIX and sFlow each have their place and performance analysis tools should make the most of both technologies in order to best serve customers.

I am not sure what point you are trying to make with the sPacket comment. The fact that sFlow is packet oriented is one of its strengths. Shifting the flow cache out of the switch to external sFlow analyzer software allows sFlow to report on all the new protocols (TRILL, VxLAN, GRE, FCoE etc.) being deployed in the data center
http://blog.sflow.com/search/label/SDN

Benoit, I hope that now that Cisco has an sFlow implementation it will have an open mind about sFlow and listen to customer feedback. There are good reasons for Cisco to support both sFlow and NetFlow as other network equipment vendors have done.

]]> By: mike@plixer.com http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-381354 mike@plixer.com Mon, 03 Sep 2012 09:49:36 +0000 http://www.plixer.com/blog/?p=17774#comment-381354 Peter, I’ve been reading your blog posts for years and you write with a silver tongue when it comes to NetFlow and IPFIX. In fact, you’ve consistently made claims about sFlow and NetFlow/IPFIX over the years that aren’t true or at least leave out facts.

Peter Phaal “This focus on IP flow export is consistent with the IETF’s responsibility for the TCP/IP suite of protocols and explicitly avoids addressing layer 2 monitoring (switches)” http://blog.sflow.com/2009/12/standards.html

Truth: “Explicitly avoids” is a bit strong. Several vendors including Cisco have implemented IPFIX with layer 2 details (e.g. Mac Address) including packet samples similar to sFlow. Also, NetFlow was built to export IP flows and not just TCP/IP.

Peter Phaal: “sFlow is a standard”

Truth: sFlow is no more of a standard than NetFlow. To my knowledge, you have never posted a URL to the IEEE or IETF that outlines the sFlow standard. You have frequently stated that NetFlow is proprietary to Cisco when it is no more proprietary than sFlow. J-Flow, NetStream are both basically NetFlow. IPFIX is the proposed standard for flow technology.

Peter Phaal: “It is clear that the 4948E doesn’t have hardware support for 1 in N packet sampling.” http://blog.sflow.com/2011/05/netflow-lite.html

Truth: NetFlow-Lite does support 1 in N packet sampling, I tested it with our engineers in our lab. I have never come across an sFlow switch that can sample every packet. It may exist, I just haven’t heard of it.

Peter Phaal: “NetFlow has no mechanism to compensate for lost records”
http://blog.sflow.com/2009/06/accuracy-and-packet-loss.html

Truth: NetFlow / IPFIX developed something called SCTP. I’m sure you knew this yet omitted it from your post. What is the sFlow mechanism? Wait for another sample I presume.

Peter Phaal: “NetFlow monitoring generates periodic bursts of traffic”
http://blog.sflow.com/2009/05/measurement-traffic.html

Truth: I’ve only seen sFlow implemented in 1 out of X configurations. If there is a spike in traffic, I’ve seen similar issues with sFlow and NetFlow. Why can’t you be a bit more honest with your comparisons?

I hope my point is clear. You have repeatedly looked for ways to belittle NetFlow/IPFIX. http://blog.sflow.com/2010/11/complexity-kills.html I hope that Cisco’s support for sFlow will encourage you to be more accurate in your posts. IMO: I think the very name sFlow which arguably should be named sPacket shows how slippery your motives can be. What is ‘flowish’ about sFlow?

sFlow Vs. NetFlow:
http://www.youtube.com/watch?v=YqJxSTISMt8
http://www.networkworld.com/community/node/29117
http://www.networkworld.com/community/node/22667
http://www.plixer.com/blog/netflow/sflow-myths-sflow-is-really-spacket/

]]> By: Benoit Claise http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-381307 Benoit Claise Mon, 03 Sep 2012 07:07:04 +0000 http://www.plixer.com/blog/?p=17774#comment-381307 I have the same request coming over and over: NetFlow/IPFIX versus Sflow.
So great article coming from someone independent. My views might appeared biased ;-)

Regarding SFlow on the nexus 3000: this was THE exception, not the Cisco strategy, and SFlow will not spread over other platforms. I don’t see any advantages…

Regards, Benoit.

]]> By: Peter Phaal http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-380672 Peter Phaal Sat, 01 Sep 2012 18:50:28 +0000 http://www.plixer.com/blog/?p=17774#comment-380672 Adam, customers should choose the mix of solutions that best meet their requirements. Which solution is “better” depends on your goals. Your perspective is of perimeter security in corporate firewalls and WAN routers and your customer comments reflect the concerns of that market.

I would argue that sFlow has significant advantages over NetFlow in monitoring 10G, 40G and 100G data center switches, particularly when you look at monitoring tunneling protocols such as TRILL/SPB, GRE, NVGRE and VxLAN.
http://blog.sflow.com/2012/05/tunnels.html

Another topical area is software defined networking (SDN), and again sFlow has significant advantages:
http://blog.sflow.com/2012/05/software-defined-networking.html

Many of the recent developments in sFlow focus on unifying network, server and application performance monitoring in cloud data center environments. Layer 7 sFlow (embedded in web servers, application servers and load balancers) provides detailed visibility into application response times, URLs etc. Host sFlow extends sFlow’s counter push mechanism to include server cpu, memory and disk IO. Most recently, NVIDIA added sFlow GPU performance metrics for GPU-based compute clusters.
http://blog.sflow.com/2010/08/sflow-host-structures.html

A final area where sFlow has significant advantages is in monitoring large scale wireless access networks:
http://blog.sflow.com/2010/08/wireless.html

As I said in my previous post, NetFlow and sFlow are complementary and a solution for most customers will involve both technologies, each used where it is most appropriate.

]]> By: Adam Powers http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-380642 Adam Powers Sat, 01 Sep 2012 17:27:50 +0000 http://www.plixer.com/blog/?p=17774#comment-380642 Hi Peter, good to hear from you. A “war” metaphor might be a bit sensationalist but the fact is that customers constantly ask which is “better”. And it’s a legit question that we feel should be addressed based on practical experience. If a customer comes to me and says “Adam I have to choose between Enterasys and Extreme. I understand that Enterasys supports NetFlow and Extreme supports sFlow. What are your thoughts on the differences? If you had to choose a vendor based on the flow technology they support which would you choose?”

Well, based on lots of past experience along with the points made in this blog, I would obviously choose Enterasys. Sure, the decision for who you choose includes many other facts but all things being equal NetFlow is a differentiator that can’t be easily overlooked.

I don’t want to come across as overly confrontational on this topic but what happens more often than not is the customer will blame the collector for problems that exist in the flows. I’ve always been focused quite sharply on security. Sampling tech – in NetFlow or sFlow – negatively impacts the reports and alerting ability of the collector, so I simply cannot recommend sFlow for anything other than simple bandwidth reporting or ISP-level DoS attacks.

Having said all that… we will continue to support sFlow and make the best of it we can. I would love to hear about any new developments on the way from any of the key sFlow vendors. The more context (usernames, app IDs, ACL info, NAT data, latency, etc) the flows can provide the better the user’s experience. To your point: everyone wins.

]]> By: Peter Phaal http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-380627 Peter Phaal Sat, 01 Sep 2012 16:36:07 +0000 http://www.plixer.com/blog/?p=17774#comment-380627 Adam, there never was a “War” between sFlow and NetFlow. The two technologies exist in distinct markets and address different requirements, http://blog.sflow.com/2009/09/lan-and-wan.html

Cisco has finally understood that sFlow and NetFlow are complementary, implementing sFlow support on the Nexus 3000 series, http://blog.sflow.com/2012/08/cisco-adds-sflow-support.html

With pervasive support of multi-vendor standards, everyone wins.

]]> By: NetFlow vs sFlow | missing idea http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/comment-page-1/#comment-378843 NetFlow vs sFlow | missing idea Wed, 29 Aug 2012 03:28:42 +0000 http://www.plixer.com/blog/?p=17774#comment-378843 [...] NetFlow vs. sFlow for Network Monitoring and Security: The Final Say [...]

]]>