tag:blogger.com,1999:blog-1978652979840829013.post1688673039244650098..comments2024-02-13T07:05:41.069-08:00Comments on sFlow: Cisco adds sFlow supportPeterhttp://www.blogger.com/profile/00856599914190257147noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1978652979840829013.post-47907331761729988132012-09-05T10:54:23.600-07:002012-09-05T10:54:23.600-07:00Robert, it would make no sense to implement NetFlo...Robert, it would make no sense to implement NetFlow/IPFIX on the Broadcom ASICs. High port density, buffers, CAM space and low latency are higher priorities when deciding how allocate resources on a switch ASIC. The advantage of sFlow is that it provides a way to instrument high performance switches without consuming excessive resources or impacting performance. If your only choice is NetFlow, then you end up having to add expensive management cards, or with no monitoring at all on many platforms - Cisco Catalyst 3k, 4k, Nexus 5k etc. The paper, <a href="http://www.inmon.com/pdf/EmbeddedTM.pdf" rel="nofollow">Traffic Monitoring in a Switched Environment</a> is a bit dated, but describes some of the considerations when including monitoring within a high speed switch.<br /><br />RFC 3176 is deprecated and as you say, very few vendors implement sFlow version 4. The current version of the sFlow standard (version 5) is maintained by the sFlow.org industry consortium, not the IETF, or the IEEE. For some background, see <a href="http://blog.sflow.com/2009/12/standards.html" rel="nofollow">Standards</a>.<br /><br />As you point out, sFlow specifies a particular sampling algorithm that all devices must implement. When performed correctly, hardware-based, random 1-in-N sampling produces surprisingly accurate results - many service providers use sFlow data for traffic accounting. The paper, <a href="http://www.sflow.org/packetSamplingBasics/index.htm" rel="nofollow">Packet Sampling Basics</a> describes the mathematics behind sFlow's sampling algorithm. The surprising result is that accuracy depends on the number of samples generated, not the total number of packets on the network.<br /><br />In your example, you looked at a Nexus 3064 generating 11 samples per second per port (0.05% of the traffic). You ask how you can get useful results when you are missing 99.95% of the traffic. In this case, the only number that matters is the number of samples being generated - 11 per second. If your sFlow analyzer is reporting per port traffic information every minute, then the results will be based on a sample size of 660. If you are rolling up traffic for the whole switch, then you have a sample size of 31,600 and if you are monitoring all the switches in your data center you would have a considerably larger sample size. Now consider the types of question you might want to ask, for example how much storage traffic (NFS, iSCSI, FCoE) is being carried on the network. Typically storage traffic will constitute a significant portion of data center traffic, so let's assume that the actual number is 60%. On a per-port basis the sFlow analyzer would produce a result in the range 54-66%. On a per switch basis, the range would be 59.63-60.37%, and finally if you want a data center wide number you would be extremely close to the correct answer. The per-minute answers are usefully more than accurate enough for troubleshooting, congestions management, DDoS analysis etc. For accounting and capacity planning purposes you typically consider longer time period. For example, if you wanted to generate a monthly report based on the single link's data, you would have a sample size of over 28 million, giving an extremely accurate measurement of the traffic.<br /><br />The goal with sFlow is to sample as little of the traffic as possible, while still generating acceptable accuracy since this increases the scalability of the overall monitoring system.<br /><br />While it's useful to understand the underlying sampling technology, the calculations don't need to be performed manually. A good sFlow analyzer will automatically perform the calculations and present results; sFlowTrend is free, properly scales sFlow, and is a good way to familiarize yourself with sFlow.<br /><br />Not all sampling schemes produce accurate results. The sFlow standard specifies a particular scheme that is proven to work. NetFlow and IPFIX allow many types of sampling, many of which produce questionable results and give sampling a bad name.Peterhttps://www.blogger.com/profile/00856599914190257147noreply@blogger.comtag:blogger.com,1999:blog-1978652979840829013.post-70859531850649787232012-09-04T23:36:01.006-07:002012-09-04T23:36:01.006-07:00Actually Cisco supporting sFlow on a Broadcom base...Actually Cisco supporting sFlow on a Broadcom based switch is nothing to brag about, since the Broadcom ASICs do not support IPfix (IETF Standard based on NetFlow version 9) or NetFlow and have no roadmap for supporting either of these features in the future.<br /><br />The author of this article actually should do a little investigation and reading before stating that sFlow is a standard, because RFC 3176 , which is an Informational RFC (meaning not a standard or better yet, here is the disclaimer from the IETF – This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.) is based version 4 sFlow and not the current version 5 sFlow.<br /><br />Next, sFlow is about as accurate as nothing but gives some people the feeling of reality. sFlow is a sample of a sample, meaning that sFlow samples the first 128 bytes (default value for sFlow version 5) of an Ethernet frame. And just too make sure it isn't accurate, sFlow will only take samples based on a down counter of say 1 in every 2048 packets (reference sample rate and most implementation).<br /><br />You might ask, "Why 1 in every 2048 packet and not 1 in every 512?" Simple reason is that while the frame is sampled in hardware, the actual creation and export of EVERY frame sampled is generated by the CPU on the switch. Just think on that, every sampled frame is forwarded to your CPU and than crafted into a single frame with other information and forwarded by the CPU back to hardware from transmission to a destination sFlow collector. <br /><br />Just to put this in perspective, the Juniper is so concerned about CPU resources, that they have limited the sFlow samples to a maximum of 300 samples per second per switch, including the EX8200, regardless of traffic load. I guess that should send a red flag up about the impact sFlow has on the CPU. Here is a factoid to think on, even if the frame size is 512 bytes and the load on every port of a 48 port 10GE switch (Nexus 3064) is just 1%, means each port is transmitting (or receiving) 23,496 pps and based on 1:2048 you gathered a whooping 11 samples (partial frames don't count) or 0.05% of the traffic load. That means you are missing 99.95% of the traffic on every interface at that rate.<br /><br />So how’s your traffic analytical skills? Remember, you are basing you entire network analysis on the fact that you are missing 99.95% of the data? Good Luck with that number!<br />Anonymoushttps://www.blogger.com/profile/09299853180558380209noreply@blogger.com