tag:blogger.com,1999:blog-1978652979840829013.post8122543915861630959..comments2024-02-13T07:05:41.069-08:00Comments on sFlow: Snowflakes, IPFIX, NetFlow and sFlowPeterhttp://www.blogger.com/profile/00856599914190257147noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-1978652979840829013.post-18737486991540731052012-09-17T11:32:25.134-07:002012-09-17T11:32:25.134-07:00The Network World article was informative, but it...The Network World article was informative, but it doesn't look as though the collector software was correctly scaling the sFlow data. For example, the factor-of-4 discrepancy in the sFlow from the Extreme switch was probably caused by the switch automatically backing off the sampling rate from 1-in-1 to 1-in-4 (which is allowed by the sFlow standard). I would have expected correctly-scaled sFlow to report slightly more traffic than NetFlow in this test. Partly because sFlow reports on the non-IP protocols, and partly because NetFlow does not usually count layer2 header bytes.<br />Neilhttps://www.blogger.com/profile/08704624958302815510noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-72365462864340380972012-09-17T06:59:08.635-07:002012-09-17T06:59:08.635-07:00You might be interested in the other articles on t...You might be interested in the other articles on this blog that discuss differences between sFlow and NetFlow, <a href="http://blog.sflow.com/search/label/NetFlow" rel="nofollow">http://blog.sflow.com/search/label/NetFlow</a>.Peterhttps://www.blogger.com/profile/00856599914190257147noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-6737192524742880942012-09-17T06:12:07.794-07:002012-09-17T06:12:07.794-07:00Somehow the URL got cut off in my last post. Here...Somehow the URL got cut off in my last post. Here is the correct URL when testing NetFlow Vs. sFlow: <br />http://www.networkworld.com/community/node/29117 <br />Jake Wilsonhttps://www.blogger.com/profile/17809477740687629419noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-7085224386795863472012-09-15T16:42:54.621-07:002012-09-15T16:42:54.621-07:00I agree that IPFIX has defines hundreds of options...I agree that IPFIX has defines hundreds of options - this article listed many of them. The challenge for device vendors is in deciding exactly which measurements they should make and how they should choose to export those measurements. The challenge for network operators is making sense of the different and often incompatible measurements each device exports. The document I referenced earlier, <a href="http://tools.ietf.org/html/draft-stephan-isp-templates-01" rel="nofollow">IPFIX templates for common ISP usages</a>, was an attempt to ensure that basic flow records would be compatible between IPFIX and NetFlow implementations across all vendors. Interoperability, standard templates are what is currently missing from IPFIX, i.e. IPFIX has no analog to SNMP's standard MIBs (like MIB2).<br /><br />You refer to the export of SNMP data using IPFIX as proposed in the draft, <a href="http://www.ietf.org/id/draft-ietf-ipfix-mib-variable-export-00.txt" rel="nofollow">Exporting MIB Variables using the IPFIX Protocol</a>. Again, this proposal provides many options, but does not require vendors to export any particular values or templates. In contrast, sFlow mandates that every vendor export the standard MIB-2 ifTable values for each interface on the device, i.e. ifIndex, ifType, ifSpeed, ifAdminStatus, ifOperStatus, ifInOctets, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifInErrors, ifInUnknownProtos, ifOutOctets, ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutDiscards, ifOutErrors.<br /><br />The Network World article you reference does demonstrate some important differences, sFlow reports on IP and non-IP traffic, NetFlow is IP only. The time smearing effect of NetFlow monitoring and its effect in delaying measurements and distorting utilization trends is also demonstrated.<br /><br />Unfortunately, problems with the experimental setup make it hard to draw any conclusions about accuracy from the results. Problems with the methodology, some of which were identified in the article, include: the lack of an accurate reference (how can you compare measurement technologies if you don't know the correct answer?), problems with the NetFlow and sFlow configuration in the switches (flow timeouts, sampling rates) and finally problems with scaling of sampled data. The comparison also ignores the MIB-2 interface counters exported by sFlow since they would provide a 100% accurate view of link traffic totals.<br /><br />Finally, IPFIX/NetFlow and sFlow are largely complementary and most enterprises will likely use both, see <a href="http://blog.sflow.com/2009/09/lan-and-wan.html" rel="nofollow">LAN and WAN</a>.<br /><br /><br />Peterhttps://www.blogger.com/profile/00856599914190257147noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-21718673670959459172012-09-15T15:17:49.755-07:002012-09-15T15:17:49.755-07:00I think you miss understood my analogy to SNMP. I...I think you miss understood my analogy to SNMP. IPFIX has options. There are currently over 300 standard IPFIX information elements. If you can't find everything you want from MIB2 in those elements there is currently a draft that seeks to leverage not just all of MIB2, but any MIB. I don't think it is as easy to do with sFlow.<br /><br />Pretty much all vendors and I know of very few exceptions, follow these same exact elements. And by the way, although Cisco is free to define information elements above the 300 the way they want, they generally keep them compatible with IPFIX. <br /><br />IP accounting based on sFlow samples is still not going to be as accurate as NetFlow or IPFIX. I challenge any consumer to run their own test as we did: http://www.networkworld.com/community/node/29117 and compare these technologies. When you step away from theory and enter the business world, sFlow OK but, not comparable to IPFIX and NetFlow.<br />Jake Wilsonhttps://www.blogger.com/profile/17809477740687629419noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-509895525982354872012-09-13T07:40:55.607-07:002012-09-13T07:40:55.607-07:00Jake, the article describes the many ways that IPF...Jake, the article describes the many ways that IPFIX can perform packet sampling (and Uniform Probalistic Sampling is similar to sFlow's mechanism). However, there is no requirement in IPFIX that vendors implement that algorithm, they are free to implement any sampling algorithm they choose with no requirement that the algorithm produce statistically valid results. <br /><br />I like your analogy to SNMP, the problem with the IPFIX standard is that it is like SNMP without MIB2. The major contribution of SNMP was not the protocol itself (I don't think many people think the SNMP protocol is great) but the huge contribution that MIB2 made in simplifying multi-vendor management by defining a standard set of measurements that every vendor was required to implement. The ifTable in particular mandates a set of interface counters that every SNMP compatible device is required to maintain (FYI sFlow defines it's counter export in terms of MIB2, ensuring compatibility between sFlow and SNMP monitoring, see <a href="http://blog.sflow.com/2009/05/link-utilization.html" rel="nofollow">Link utilization</a>). <br /><br />There was an attempt in 2005 to define a standard set of IPFIX tables and measurements (the equivalent of MIB2 for IPFIX), but this effort by service providers didn't go anywhere, however, the proposal, <a href="http://tools.ietf.org/html/draft-stephan-isp-templates-01" rel="nofollow">IPFIX templates for common ISP usages</a>, makes interesting reading. In this aspect, IPFIX is a regressive step. Cisco's NetFlow version 5 defined the flow record that everyone is familiar with and NetFlow version 5 equivalents were pretty consistently implemented by a number of other vendors.<br /><br />As to sFlow's applicability to IP accounting, the document <a href="http://www.inmon.com/pdf/sFlowBilling.pdf" rel="nofollow">sFlow accuracy and billing</a> describes strategies for accounting based on sFlow and there are many service providers using sFlow for billing. <br /><br />If your goal is to monitor specific packets or packet from a specific host, then SPAN/RSPAN is a better approach. Brocade has implemented an ACL based packet capture mechanism as an sFlow vendor extension allowing for detailed protocol following of specific hosts for troubleshooting.Peterhttps://www.blogger.com/profile/00856599914190257147noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-66110525148655370852012-09-13T05:51:29.851-07:002012-09-13T05:51:29.851-07:00IPFIX can be used to sample packets similar to sFl...IPFIX can be used to sample packets similar to sFlow. An example is NetFlow-Lite. My experience with sFlow is that when I go look for traffic from a specific host, sFlow didn't sample it. IPFIX can be used for accurate IP accounting and sFlow can't be. <br /><br />Regarding "The result is that each vendor and each product produces unique and incompatible data." This point allows IPFIX vendors to not be limited to a standard. Similar to SNMP there is MIB2 and then there are the Enterprise MIBs. Jake Wilsonhttps://www.blogger.com/profile/17809477740687629419noreply@blogger.com