Control your network and application flows

The Netflow and sFlow protocols are now widely implemented by the network equipment (Cisco, Extreme Networks, 3COM, HP Procurve…). Their use brings relevant information to both the understanding and operation of your infrastructure, and for the analyses and the assistance in the punctual diagnosis. The distribution protocol report, and the potential vision on the flow of each host of your network making it possible to build your matrix flow.

Flow accounting with NetFlow / sFlow protocols

In order to supplement the information given by the technical indicators specific to each device, it is useful to know precisely what use is made of the network. The accounting flows directed by SmartReport is to measure the traffic carried onto one or several points (equipment) of the network, and to spread the activity according to the level 3 and 4 criteria (IP addresses, TCP ports…). Concretely, these reports make it possible for you to answer 4 questions:

  • Who uses the network?
  • For what applications?
  • For what destination?
  • When?

In order to have this information, the Netflow protocols (for Cisco devices) and sFlow (for equipment HP, Extreme Networks, etc.) are used. These protocols provide the information of level 3 and 4 on the flow across the network, without having to deploy any probes or agents. They are most often found on routing equipment but it is also possible to have this information directly to issuelevel 2.

This information is particularly useful during the construction of protocol distribution report or of matrix flows.

Distribution protocol produced by SmartReport from sFlow data

This information greatly facilitate the progress of some projects, including safety projects (filtering and partitioning), where it is necessary to know precisely what are the legitimate flows, or the outsourcing or relocation projects, for which it is necessary to know the volume of data exchanged between each server.

Netflow / sFlow application in the QoS supervision

If your network includes a QoS policy (Quality Of Service), and more particularly of the prioritization methods of flow and bandwidth allocation, it is often useful to measure the traffic as it is regulated by the QoS. On the one hand, to validate that the QoS policy is applied in the way as it has been written, and on the other to have the vision on the evolution of flows, making it possible for you to adjust the policy implementation. Indeed, it has been observed that one category of service reaches the saturation of the bandwidth allocated at peak times, or that the category of “other” services increases due to the arrival of a new application that is not taken into account … The operation of the QoS monitoring with SmartReport is simple: the product reports give you the actual traffic distribution as it is seen by your routing and switching equipment. They therefore make it possible for you to verify that the QoS is applied as expected.

Other modes of QoS supervision with SmartReport

The use of service categories on Netflow / sFlow is one of the 4 methods available in SmartReport to oversee the consistency and usefulness of a quality service policy. SmartReport is able to rely on the ToS (Type Of Service) indicated on the IP packages to recognize the flows that the Netflow / sFlow equipment have reassembled.

Besides Netflow / sFlow, SmartReport has 3 other tools to monitor the implementation of a QoS policy on a network.

  • SNMP direct supervision of equipment dedicated to the QoS management (Packeteer, Allot …), with the adapted SmartReport equipment model.
  • The use of embedded counters in the MIB of some Level 3 equipment with several queues in their routing or switching engine. For these devices, the volume of traffic exchanged in each file is usually published in SNMP, in which case recovered by SmartReport thanks to the equipment model.

The use of configured meter on access-lists of certain equipment. When a package matches an access-list, the counter is incremented. The value of each counter is published in SNMP, and recovered by SmartReport thanks to the equipment model.