Flexible NetFlow is the next generation flow export technique promoted by Cisco Systems. As the word depicts it is highly flexible based on user requirements and to monitor specific network behaviour. Traditional NetFlow used a fixed seven tupple of IP information to identify a flow most of the time. Advantages of Flexible NetFlow
1. Flexibility to choose the desired export fields.
2. Reduce the number of flows and allows CPU to perform efficient routing and switching
3. Convergence of multiple accounting technologies into one accounting mechanism
Flexible NetFlow and NetFlow V9
The export protocol of choice for Flexible NetFlow is the NetFlow Version 9 export protocol, but unfortunately and to date, NetFlow Version 5 has been a much more widely used protocol because of the legacy Cisco IOS® Software images that are still around that supported the NetFlow v5 export protocol only and worked very well. However Cisco claims the future is going to be Flexible NetFlow. And believe it this migration is going to very smooth since Flexible NetFlow can also be configured to export some predefined flow records using the NetFlow Version 5 protocol format for backward compatibility. This helps your existing collectors can work with Flexible NetFlow until you find a real requirement to use additional fields offered by Flexible NetFlow.
Flexible NetFlow Configuration
Traditional NetFlow configuration is pretty much straight forward. Flexible NetFlow consists of components that can be used together in several variations to perform traffic analysis and data export, and the new command-line interface (CLI) configuration follows the same traditional logic.In this user-defined flow records and the component structure of Flexible NetFlow make it easy to create various configurations for traffic analysis and data export on a networking device with a minimum number of configuration commands.
Flexible NetFlow consists of components that can be used together in several variations to perform traffic analysis and data export, and the new command-line interface configuration follows the same traditional logic.
Let's see this components in detail
Flow Monitor:
A Flexible NetFlow Flow Monitor describes the NetFlow cache or information stored in the cache. The Flow Monitor contains the Flow Records or key and non-key fields within the cache. Also, part of the Flow Monitor is the Flow Exporter which contains information about the export of NetFlow information including the destination address of the NetFlow collector. The Flow Monitor includes various cache characteristics including the timers for exporting, the size of the cache and if required, the packet sampling rate.
Flow Record:
A Flow Record is a set of key and non-key NetFlow field values used to characterize flows in the NetFlow cache. Flow Records may be pre-defined for ease of use or customized and user defined. A typical pre-defined record will aggregate flow data and allow users to target common applications for NetFlow. User defined records will allow selection of specific key or non-key fields in the Flow Record. The user defined field is the key to Flexible NetFlow allowing a wide range of information to be characterized and exported by NetFlow. It is expected that different network management applications will support specific user defined and pre-defined Flow Records based on what they are monitoring (ie: security detection, traffic analysis, capacity planning).
Flow Exporter:
The Flexible NetFlow Exporter allows the user to define where the export can be sent, the type of transport for the export and properties for the export. Multiple exporters can be configured per Flow Monitor or the same exporter can be used by multiple monitors.
The following figure shows the flow monitor and it components.
In our next blog we are going to use a pre-defined (defined in IOS itself) flow record to export netflow records using Flexible Netflow. In the meanwhile if you have any queries. please write to netflowanalyzer-eesupport@manageengine.com
Thanks
Raj
Download | Interactive Demo | Product overview video
Being a niche player in the SAAS market, Zoho brings an amazing level of engineering expertise to ManageEngine in building highly secure and scalable distributed applications. And hopefully you know, Adventnet has recently changed its name to Zoho Corp and formed three divisions namely ManageEngine, Zoho, and WebNMS.
The drive for QoS has become very strong in recent years because of evolving needs for enterprises to carry different types of services including voice, video, streaming music, web pages and email on a single link. One of the most complex tasks of a network architect is to design a robust network and also ensure the quality of end to end applications delivered across branch locations and data centers.
Quality of Service refers to the ability to provide better treatment for some applications over other services in the network. The primary goal of implementing QoS in business critical networks includes priority routing for critical applications through dedicated bandwidth, controlling jitter and latency. Now a day’s most of the enterprises rely on the service provider network for their day to day branch office transactions.
Typically, networks operate on the basis of best-effort delivery, in which all traffic has an equal priority and an equal chance of being delivered. When congestion results, all traffic have an equal chance of being dropped. QoS selects network traffic, prioritizes it according to its relative importance and uses congestion avoidance to provide priority-indexed treatment. Configuring QoS can also limit the bandwidth used by non critical network traffic and so makes network performance more predictable and bandwidth utilization much more effective.
Configuring and validating quality of service involve four steps.
A. Application discovery and grouping
B. Implementing Quality of Service (QoS)
C. Verification of QoS treatment for interested traffic
D. Validating QoS configuration for application performance
This blog focuses on application discovery and grouping of similar type of applications.
Application discovery and grouping:
To apply QoS policies, it is very important to identify applications that are competing for bandwidth. NetFlow and NBAR is an excellent data source to identify most of the applications. NetFlow exports consist of port and protocol information which can be mapped to a well known application conversation. Cisco embeds NBAR (Network Based Application Recognition) engine that can identify traffic up to the application layer. It is extremely useful in identifying peer-to-peer applications.
ManageEngine NetFlow Analyzer is a unique blend of NetFlow and NBAR technologies. In addition to static NetFlow based port and protocol application detection, it also supports NBAR to identify most of the peer-to-peer applications.
NetFlow port and protocol based application detection:
NetFlow Analyzer maintains the port and protocol mapping for more than 1500 applications for application classification. Additionally it is also possible to map new applications that are running on particular IP address/range or a range of ports. These applications can be grouped into single application. For example, the user can classify all the database applications like Oracle, MySql, MS-Sql in to one group called the database group.
NBAR (Network Based Application Recognition)
Intelligent application classification by examining the data payload helps ensure the network bandwidth is used efficiently by working with QoS feature. Unlike NetFlow, which relies on port & protocol for application categorization, NBAR approach is useful in dealing with malicious software using known ports to fake being “priority traffic”, as well as non-standard applications using non-determinant ports. The biggest advantage in using NetFlow Analyzer is that the user can enable NBAR on the fly from the web GUI for instant visibility and can it turn off at peak times to save CPU cycles for routing.NBAR is supported in most Cisco switches and routers and values are retrieved through SNMP. It is possible to identify applications like Kazaa, Edonkey and Skype, which use dynamic ports to transfer data. NBAR does deep packet inspection of traffic to identify these applications which normally cannot be identified with NetFlow and reports on the bandwidth they occupied.
Based on the results, we can group applications under various categories. The grouping can be done as delay sensitive applications like voice or real time video in one category, applications that use high bandwidth in another and those that are tolerant to packet loss or delay can be considered as another group. In the next blog, we will discuss about implementing QoS policies for these groups of applications based on their business criticality and priority.
Raj
ManageEngine NetFlow Analyzer