Advantages and limitations of using sFlow for Network monitoring

This article is about the advantages and disadvantages of using sFlow technology for network monitoring and enabling basic level network security. We discuss about the multi-vendor support for sFlow, its hardware implementation, how it provides a 30,000 foot view of the whole network and many more advantages and limitations as well.

If you are new to sFlow, you may want to read this article – What is sFlow and what are its applications before proceeding.

Advantages of using sFlow technology as Network monitor:

¤ If the network equipments support sFlow, a lot of network applications like voice, data, video etc can be monitored with a single application (like a network analyzer) without having to employ multiple applications for that purpose.

¤ sFlow can be used by software tools like a network analyzer to continuously monitor tens of thousands of switch/ router ports simultaneously. Links of up to 10 Gbps can be monitored through sFlow.

¤ sFlow is a multi-vendor technology and is supported by various vendors.

¤ Certain network analyzers allow traffic data provided by sFlow to be accessed from a standard web-browser.

¤ sFlow is implemented in hardware (Network switches/routers – ASIC) and hence it can operate at line speeds without impacting the switch performance considerably.

¤ Since sFlow uses network sampling (forwarding one packet from ‘n’ number of total packets) for analysis, it is not resource intensive (processing, memory etc). The sampling is done at the hardware ASIC’s and hence it is simple and more accurate.

¤ sFlow is a ‘Push’ technology. The sFlow agents in the switches/routers keep pushing the sampled data frequently to the sFlow collectors and there is no sudden burst of traffic – this avoids congestion.

¤ sFlow monitors not just network links and switch ports, but it also gives visibility into every server/ PC in the network without having to install any separate software agents on them.

¤ sFlow is highly expandable and can monitor a network of even 1,00,000 switch ports.

¤ sFlow is more efficient than SNMP for counter polling as it pushes its own counters to the central collector along with the sample packets. XDR, used by sFlow to encode/decode the counters is simpler than ASN1 used by SNMP. So, CPU load on the switches and collectors is reduced.

¤ Since sFlow uses a central traffic collector/analyzer, it is easier to add new protocol decoders (If any) there, instead of deploying them in the firmware releases of all the network switches.

¤ As the switches and routers keep ‘pushing’ sflow information to the collector frequently, it would have up to the minute details of network, enabling real time monitoring of network using sFlow.

¤ Amount of memory (required in the switch) to construct traffic measurements is very less for sFlow. Hence the cost of incorporating a special RAM for doing these processes is reduced.

¤ Since sFlow does not analyse all the packets, the CPU resources required for the server containing the software collector (for performing the network analysis) is also minimised.

Limitations of sFlow:

¤ sFlow does not provide the packet level details required for complete analysis of the network as they don’t have the access to every packet in the conversation to perform application expert analysis (like application response time analysis etc).

¤ sFlow sends multiple streams of clear text (without encryption) which can be a security issue in a multi-location network.

¤ The accuracy of sFlow analysis depends a lot on the sample rate selected. The higher the sample rate, more accurate the analysis. The type of sampling (uni-directional or bi-directional sampling) also plays an important factor in the accuracy of sFlow results. The supported sample rates are dependant on (or limited to) the network infrastructure vendors.

¤ All the switches/routers in the network need to support sFlow for a comprehensive and complete network analysis. Monitoring network edge (or) core switch (or) inter-switch communications (or) links alone may not give full details.

¤ When working with a large number of sFlow enabled devices, the overhead (bandwidth) incurred for sFlow processes will have a considerable impact (Around 0.5% of extra traffic is introduced due to this).

¤ For monitoring trunks, a lower sampling rate may be needed due to equipment limitations.

¤ For signature based threat identification, limited signature capability can be used to to identify the worms and other well known events, provided the correct packet is sampled (the signature must fall within the fraction of the packet that is sampled) and the signature must exist. Due to the small sample size, identification of DOS attacks etc can be a challenge and it depends on the accuracy of the algorithms used.

excITingIP.com

In case you have any questions, you can contact us using the contact form or leave a comment below. You can also subscribe with your email address (on the right side of this site) to get intimated when a new article is published on this site.