Go Rapidly detecting large flows, sFlow vs. Netflow/ipfix

Figure 1: Low latency software defined networking control loop

The articles SDN and delay and delay and stability describe the critical importance of low measurement delay in CONSTRUCTI Ng stable and effective controls. This article would examine the difference in measurement latency between SFlow and Netflow/ipfix and their relative Suitabi Lity for driving control decisions.

Figure 2: sFlow and NetFlow agent architectures

Figure 2 illustrates shows the architectural differences between the SFlow and ipfix/netflow instrumentation in a switch:

1. Netflow/ipfixCisco NetFlow and IPFIX (the IETF standard based in NetFlow) define a protocol for exporting flow records. A flow record summarizes a set of packets that share common attributes-for example, a typical flow record includes Ingre SS interface, source IP address, destination IP address, IP protocol, source TCP/UDP port, Destination tcp/udp port, IP to S, start time, end time, packet count and byte count. Figure 2 shows the steps performed by the switch in order to construct flow records. First the stream ofPacketsis likelysampled(particularly in high-speed switches). Next, the sampled packet header isDecodedTo extract key fields. AHashfunction is computed over the keys on order to look up the flow record in theFlow Cache. If an existing record was found, its values were updated, otherwise a record is created for the new flow. Records flushed from the cache based on protocol information (e.g. if a FIN flag is seen in a TCP packet), a timeout, Inactivity, or when the cache was full. The flushed Records is finallysentTo the traffic analysis application.
3. SFlow With SFlow monitoring, the decode, hash, flow cache and flush functionality is no Lon GER implemented on the switch. Instead, sampled packet headers is immediately sent to the traffic analysis application which decodes the packet S and analyzes the data. In addition, SFlow provides a polling function, periodically sending standard interface counters to the traffic a Nalysis applications, eliminating the need for SNMP polling, see Link utilization.

The Flow CacheIntroduces significant measurement delay for netflow/ipfix based monitoring since the measurements is only accessible to Management applications once they is FlushedFrom the cache and sentto a traffic analyzer. In contrast, SFlow have no cache-measurement are immediately sentAnd can be quickly acted upon, resulting in extremely low measurement delay.
Open VSwitch is a useful testbed for demonstrating the impact of the Flow CacheOn measurement delay since it can simultaneously export both NetFlow and SFlow, allowing a side-by-side comparison. The article, comparing SFlow and NetFlow in a vSwitch, describes how to configure SFlow and NetFlow on the Open vSwitch an D demonstrates some of the differences between the measurement technologies. However, this article focusses on the specific issue of measurement delay.
Figure 3 shows the experimental setup, with SFlow directed to Inmon Sflow-rt and NetFlow directed to SolarWinds real-time NetFlow Analyzer.
Note:Both Tools is available at no charge, making it easy for anyone to reproduce these results.

Figure 3: Latency of large flow detection using SFlow and NetFlow

The charts in Figure 3 show how each technology reports on a large data transfer. The charts has been aligned to having the same time axis so can easily compare them. The vertical Blue Line Indicates the start of the data transfer.

1. SFlow By analyzing the continuous stream of sFlow messages from the switch, Sflow-rt immediately detects and continuously tracks The data transfer from the moment, the data transfer starts to its completions just over the minutes later.
2. NetFlow The real-time NetFlow Analyzer doesn ' t report on the transfer until it receives the first NetFlow record, seconds after The data transfer started, indicated by the first vertical redline. The delay corresponds to the active timeout used to flush records from the flow cache. A second NetFlow record, indicated by the second RedLine, was responsible for the second spike, seconds later, And a final NetFlow record, received after the transfer completes and indicated by the third Redline, is respons Ible for the third spike in the chart.

Note:A One minute active timeout is the lowest configurable value in many Cisco switches (the default is. minutes), see CONFI Guring NetFlow and NetFlow Data Export.
The large measurement delay imposed by the Netflow/ipfix Flow CacheMakes the technology unsuitable for SDN control applications. The measurement delay can leads to instability since the controller was never sure of the current traffic levels and could be Taking action based on stale data reported for flows that is no longer active.
In contrast, the SFlow measurement system quickly detects and continuously tracks large flows, allowing a SDN traffic man Agement application to reconfigure switches and balance the paths, the active flows take across the network.