Comparing SFlow and NetFlow in a VSwitch

As virtualization shifts the network edge from top of rack switches to software virtual switches running on the hypervisor S Visibility in the virtual switching layer is essential on order to provide network, server and storage management teams WI Th the information needed to coordinate resources and ensure optimal performance.
The recent release of Citrix XenServer 6.0 provides an opportunity for a side-by-side comparison of SFlow and NetFlow Moni Toring Technologies Since both protocols be supported by the Open VSwitch that's now the default XenServer network stack .
The diagram above shows the experimental setup. Traffic between the virtual machinesVM1andVM2Passes through theVirtual Switchwhere SFlow and NetFlow measurements are simultaneously generated. The SFlow is sentSFlow Analyzer(Inmon sflowtrend) and the NetFlow to aNetFlow Analyzer(SolarWinds real-time NetFlow Analyzer). Both tools running in tandem making it's easy-to-perform side by side comparisons-see differences in the Visibilit Y that NetFlow and sFlow provide into the same underlying traffic.
Note:XenServer 6.0, Sflowtrend and real-time NetFlow Analyzer is all available at no charge, making it easy for anyone to repr Oduce these tests. Configurationthe Host SFlow Supplemental Pack is installed to automate SFlow configuration of the Open VSwitch and to Exp ORT standard SFlow Host metrics. The following/etc/hsflowd.confFile sets the packet sampling rate to 1-in-400, counter polling interval-seconds and sends SFlow to Sflowtrend Runni Ng on the host 10.0.0.42 and listening on UDP Port 6343.

sflow{  DNSSD = off  polling =  sampling = collector{    ip = 10.0.0.42    udpport = 6343  }}

The following command is used to manually configure NetFlow monitoring, sending NetFlow to the real-time NetFlow Analyzer Running on host 10.0.0.42 and listening on UDP port 2055:

Ovs?vsctl?? Set Bridge xenbr0 [email protected]?? [Email protected] Create NetFlow targets=\ "10.0.0.42:2055\" active?timeout=60

Resultsthe following charts show the top protocols measured using SFlow and NetFlow:

TOP protocols in Sflowtrend

TOP protocols in real-time NetFlow Analyzer

Looking at the charts, both show similar average traffic levels. The Sflowtrend chart shows the Ingress Memcache (tcp:11211) traffic at between 0.7 and 0.9 mb/s. Looking at the real-time NetFlow Analyzer Total Traffic table, 464.41Mb were seen over the last one minutes seconds, giving an average rate of 0. $ MB/s. The sflowtrend measurements is consistently higher since they include the bandwidth consumed by layer 2 headers whereas N Etflow only reports on Layer 3 bytes. However, the layer 2 overhead can be estimated by assuming this an additional bytes per packet (Mac source, Mac Destina tion, type and CRC) and multiplying by the total packets count (492,036), resulting in an additional 0.1 mb/s which bring s the NetFlow measurement to 0.76mb/s, putting it into agreement with the sFlow measurements.
Note:The overhead associated with Ethernet headers and tunneling protocols can represent a significant fraction of overall band Width. By exporting packet headers, SFlow provides detailed information on the encapsulations and their overhead. NetFlow does not provide a direct measure of total bandwidth.
The periodic, second, spikes in traffic shown on the NetFlow Analyzer chart is an artifact of the "the" NetFlow reports On long running connections. With NetFlow, packet and byte counters is maintained for each connection in a flow cache within the switch. When the connection terminates, a flow record is generated containing the connection information and counters. TheActive-timeoutsetting in the NetFlow configuration was used to ensure visibility into long running connections, causing the switch to per Iodically export NetFlow records for active connections. In contrast, SFlow does not use a flow cache, instead sampled packet headers is continually exported, resulting in real-t IME charts that's more accurately reflect the traffic trend.
In addition, exporting packet headers allows a sFlow analyzer to monitor all types of traffic flowing across the switch; Note the ARP and IPV6 traffic displayed in Sflowtrend in addition to the tcp/udp flows. Visibility into Layer 2 traffic are particularly important in switched environments where protocols such as DHCP/BOOTP, STP , LLDP and ARP need to be closely managed. SFlow also provides visibility into networked storage, including Ethernet SAN technologies (e.g. FCoE or AoE), that Typica Lly dominates bandwidth usage in the data center. Looking forward, there is a number of tunneling protocols being developed to connect virtual switches, Including:gre, MP LS, VPLS, VXLAN and NVGRE. As new protocols is deployed on the network they is easily monitored without any change to exiting SFlow agents ensuring End-to-end visibility across the physical and virtual network.
In contrast, NetFlow relies on the switch to decode the traffic. In this case, the switch is exporting NetFlow version 5 which only exports records for IPV4 traffic. The NetFlow Analyzer is thus only able to report on IPV4 protocols, and all other traffic are invisible. This limitation was not a unique to Open VSwitch; NetFlow version 5 is the most widely supported version of NetFlow in network devices and are also the version exported by V Mware VSphere 5.0.
The next charts show top connections flowing through the virtual switch:

Top Connections in Sflowtrend

Top Connections in real-time NetFlow Analyzer

The Top Connections charts further demonstrate the limitation in NetFlow visibility where only IPv4 flows is shown. The SFlow Analyzer is able to report in detail on all types of traffic flowing through the switch, in this case showing de Tails of IPV6 Traffic in addition to IPv4 flows.
The next charts show interface utilization and packet counts from Sflowtrend:

Link Utilization in Sflowtrend

Link Counters in Sflowtrend

This type of interface trending was a staple of the network management, but obtaining the information was challenging in virtual Environments. While SNMP was typically used to obtain this information from network equipment, servers was much less likely to be managed The using SNMP and so SNMP polling are often not a option. In addition, there is large numbers of virtual ports associated with each physical switch port. In a virtual environment with physical switch ports you might need to monitor as many as 200,000 virtual ports. Even if SNMP agents were installed on all the servers, SNMP polling does is not a scale well to large numbers of interfaces. The integrated counter polling mechanism built into SFlow provides scalable monitoring of the utilization of every switch Port in the network, both physical and virtual, quickly identifying problems wherever they could occur in the network.
In contrast, NetFlow only reports on traffic flows so neither of these charts was available in the NetFlow Analyzer. The remaining charts is based on SFlow counter data so there is no corresponding NetFlow Analyzer charts.
The next Sflowtrend chart shows the CPU load on the hypervisor:

Hypervisor CPU in Sflowtrend

The virtual switch is a software component running on the hypervisor, thus if the hypervisor are overloaded, then network p Erformance would degrade. The SFlow counter polling mechanism extends to system performance counters in addition to the interface counters shown ear Lier, allowing the SFlow Analyzer to display hypervisor CPU utilization. In this case, the chart shows a small spike in system CPU utilization corresponds to the spike on traffic at 9:52am.
The next Sflowtrend chart shows a trend in disk IO on the virtual machine:

Virtual machine Disk IO in Sflowtrend

This chart shows, the burst in ISCSI traffic shown in the TOP protocols chart corresponds to a spike in read activity On the virtual machine. Again, SFlow ' s counter push mechanism efficiently exports information about the performance of virtual machines, allowing The interaction between network and system activity to is understood. Commentsnetflow provides limited visibility, focusing on Layer 3 network connections. The NetFlow architecture relies on complex functionality within the switches and the complexity of configuring and Maintai Ning NetFlow adds to operational costs and limits scalability. For example, gaining visibility into IPV6 traffic requires firmware (and often hardware) upgrades to the network Infrastru Cture that can is challenging in large scale, always-on, cloud environments.
In contrast, adding support for additional protocols on SFlow requires no change to the network infrastructure, and is SIM Ply a matter of upgrading the SFlow Analyzer. The SFlow architecture eliminates complexity from the agents, increasing scalability and reducing the operational costs as sociated with configuration and maintenance. SFlow provides comprehensive visibility into network and system resources needed to manage performance in virtualized and Cloud environments.