sFlow achieves network-wide visibility by shifting complexity away from the switches to the sFlow analysis application. Simplifying the monitoring task for the switch makes it possible to implement sFlow in hardware, providing wire-speed performance, without increasing the cost of the switch. However, the shift of complexity to the sFlow analysis application makes the selection of the sFlow analyzer a critical factor in realizing the full benefits of sFlow monitoring.
To illustrate some of the features that you should look for in an sFlow analyzer, consider the following basic question, "Which hosts are generating the most traffic on the network?" The chart provides information that answers the question, displaying the top traffic sources and the amount of traffic that they generate. In order to generate this chart, the sFlow analyzer needs to support the following features:
To illustrate some of the features that you should look for in an sFlow analyzer, consider the following basic question, "Which hosts are generating the most traffic on the network?" The chart provides information that answers the question, displaying the top traffic sources and the amount of traffic that they generate. In order to generate this chart, the sFlow analyzer needs to support the following features:
- Since the busiest hosts in the network could be anywhere, the sFlow analyzer needs to monitor every link in the network to accurately generate the chart.
- Traffic may traverse a number of monitored switch ports, in the example above, traffic between hosts A and B is monitored by 10 switch ports. In order to correctly report on the amount of traffic by host, the sFlow analyzer needs to combine data from the different switch ports in a way that correctly calculates the traffic totals and avoids under or over counting.
- The sFlow analyzer must fully support sFlow's packet sampling mechanism in order to accurately calculate traffic volumes.
- Notice that the chart contains IPv4, IPv6 and MAC addresses. The sFlow analyzer needs to be able to decode packet headers and report on all the protocols in use on the network, including layer 2 and layer 3 traffic. Traffic on local area networks (LANs) is much more diverse than routed wide area network (WAN) traffic. In addition to the normal TCP/IP traffic seen on the WAN, LAN traffic can include multicast, broadcast, service discovery (Bonjour), host configuration (DHCP), printing, backup and storage traffic not typically seen on the WAN.
When selecting an sFlow analyzer, try to arrange an evaluation and test the product on a full scale production network. Evaluating scalability and accuracy is not something that is easily performed in a test lab.
Can you provide the best sflow analyser for ubuntu or CentOS. [ Open source version]
ReplyDeleteA list of sFlow analyzers is maintained at sFlow.org. Which one is best depends on your requirements. Do you really mean open source, or just free? Some of the closed source solutions are free (e.g. sFlowTrend).
DeleteIf you are looking for a starting point to develop your own sFlow analyzer, then you might want to take a look at Developer resources.
can you provide an open source analyzer that fully support sFlow's packet sampling mechanism. ganglia doesn't and i think (and i'm not sure )that graphite gape this feature too. tanks for this interesting article !!
ReplyDeleteTake a look at the sFlow Collectors list on sFlow.org. There are open source analyzers on the list: ntop, pmacct, and sflowtool.
DeleteIf you have fairly simple requirements, it isn't hard to write a script to create summary statistics based on packet samples and send them to Graphite or Ganglia. Developer tools lists sFlow decoder libraries.