By utilizing Flexible Netflow infrastructure, users have complete control of what information to collect and how the a is aggregated into what is called <u>FNF&nbsp;record</u>.&nbsp;A FNF&nbsp;record is defined by specifying&nbsp;appropriate keyed fields and non-keyed fields. Keyed fields define&nbsp;a set of&nbsp;field(s) which need to be unique in order for a new FNF&nbsp;record to be created. Examples of how keyed fields are chosen depend on what information is of interest to users:

By utilizing Flexible Netflow infrastructure, users have complete control of what information to collect and how the a is aggregated into what is called <u>FNF&nbsp;record</u>.&nbsp;A FNF&nbsp;record is defined by specifying&nbsp;appropriate keyed fields and non-keyed fields. Keyed fields define&nbsp;a set of&nbsp;field(s) which need to be unique in order for a new FNF&nbsp;record to be created. Examples of how keyed fields are chosen depend on what information is of interest to users:

-

*Collect application usage: Keyed field is NBAR2 application

+

*'''Collect application usage: '''Keyed field is NBAR2 application

-

*Collect traffic between two end-points: Keyed fields are source and destination IP addresses

+

*'''Collect traffic between two end-points: '''Keyed fields are source and destination IP addresses

Cisco Application Visibility and Control (AVC) Technical Overview

Cisco Application Visibility and Control (AVC) is a solution which leverages multiple core technologies found in the Cisco Aggregation Services Routers (ASR) 1000 Series and the Cisco Integrated Service Routers Generation 2 (ISR G2). Coupled with network management tools, Cisco AVC provides a powerful and pervasive integrated solution for discovering and controlling applications within the network. Empowered with these tools, network administrators can gain a much deeper insight into applications running in their networks and their performance characteristics, while applying policies to further improve performance and control of network resource usage.

What you will learn from this whitepaper is the technical overview of Cisco AVC, all the components that are part of Cisco AVC solution, how they work together, and the benefits they provide.

Today Challenges

There are several trends in the today enterprises that drive requirements to build application awareness within the network. Cloud services and cloud applications such as WebEx, SalesForce.com, and Office 365 are delivered over HTTP and HTTPS which are the same ports used by typical recreational web traffic such as Netflix, Hulu, Pandora, and iTunes. In addition, consolidation of the data center in order to reduce overhead and operating expenses requires the network to carry much greater volume of both business and recreational traffic. Network admins need to gain visibility into different types of traffic their performance in greater detail to be able to quickly isolate and troubleshoot application performance issues. They need the ability to granularly define policy to control and tune the performance of these different applications.

Introduce Cisco’s Application Visibility and Control (AVC)

Cisco AVC solution offers truly innovative approach to enable application awareness in the network. AVC incorporates application recognition and performance monitoring capabilities that were traditionally only available as dedicated appliances into the WAN router platform. This integrated approach greatly reduces the network footprint, simplifies network operations, and reduces total cost of ownership. The information collected by Cisco AVC is exported in an open standard format such as Netflow Version 9 and IPFIX, which allows both Cisco and third-party network management to support Cisco AVC solution.

Figure 2. What is Cisco Application Visibility and Control (AVC)

In addition to providing visibility into applications running on the network and their performance, Cisco AVC enables per-application policy for granular control of application bandwidth use which results in better end user experiences. Cisco AVC is enabled in Cisco IOS and IOS XE software.

How does Cisco AVC Solution Work?

AVC uses a number of technologies and consists of four functional components

Application Recognition: With Cisco AVC, Cisco ASR 1000 and ISR-G2 can identify over 1000 applications within the traffic flow using NBAR2, Cisco’s innovative Deep Packet Inspection (DPI) technology. In order to address the evolving nature of applications, NBAR2’s application signature can be updated through Protocol Pack while the router is in-service.

Performance Collection and Exporting: Cisco AVC utilizes embedded monitoring agent to collect Application Response Time (ART) metrics such as transaction time and latency for TCP applications, and packet loss and jitter for voice and video applications. These metrics are aggregated and exported using standard flow export format such Netflow Version 9 and IPFIX.

Management Tool: With open flow export format such as Netflow Version 9 and IPFIX, data exported by AVC can be consumed by Cisco Prime Infrastructure and other third-party network management tools. This gives customers flexibility to utilize Cisco management tool or to leverage management tool of their choices.

Control: By utilizing common DPI technology, NBAR2, these routers can reprioritize critical applications or enforce application bandwidth use using Cisco’s industry-leading Quality of Service (QoS) capabilities. In addition, intelligent application path selection based on real-time performance is provided through Cisco Performance Routing (PfR)

Technologies Used by Cisco AVC

The following picture shows technologies and features that support each of Cisco AVC component

Figure 4. Cisco AVC Technology Blocks

AVC Component – Application Recognition

In the past, typical network traffic could easily be identified using well known port number. HTTP, HTTPS, POP3, or IMAP were among common traffic seen in enterprise. Today, there is increasing number of applications which is delivered over HTTP – both business and recreational applications. Many applications use dynamic ports such as Exchange, and voice and video which are delivered over RTP. This makes them impossible to be identified by looking at port number. In addition, some applications disguise themselves as HTTP because they do not want to be detected. As a result, identifying applications by checking well known port is no longer sufficient.

Application accounting: This can be provided through CLI ip nbar protocol-discovery, enabling on interface(s). Through CLI show ip nbar protocol-discovery, users can get a snapshot of applications seen through the interface, along with traffic rate and volume, in both byte and packet unit. The same information is also available through NBAR MIBs.

Classification: By using NBAR2 in the class-map, routers can identify traffic by NBAR2 application signature. This allows per-application policy control such as QoS, e.g. limit traffic rate for Netflix, Pandora, and iTunes applications, or guarantee bandwidth for business applications such as WebEx, Office 365, or Sharepoint.

Reporting: By leveraging Flexible Netflow infrastructure to export application information provided by NBAR2 through opened export format such as Netflow Version 9, or IP Flow Information Export (IPFIX) protocol.

NBAR2 Protocol Pack

NBAR2 provides an ability to update and add application signatures while the routers are in service. This is done by loading a NBAR2 Protocol Pack file. NBAR2 Protocol Pack consists of all the available signatures packaged together into a single file. NBAR2 Protocol Pack is available for downloading on Cisco website in the same place where the IOS software for the particular routers is posted. NBAR2 Protocol Pack is created for every supported IOS and IOS XE releases, and is dependent on the IOS and IOS XE releases.

Figure 7. Example of NBAR2 Protocol Pack Location

Following describes steps to load protocol pack.

Step 1: Locate the NBAR2 Protocol Pack for your router platform and your running IOS image on Cisco website. Download the NBAR2 Protocol Pack to the local file system of the router

NBAR2 Custom Protocol

There may be applications that are not yet identified by NBAR2. Such applications include custom or home-grown enterprise applications which may run on specific TCP or UDP ports, or internal web-based applications. NBAR2 provides ability for users to define these applications, call custom protocol, using CLI ip nbar custom. Following describes supported methods for defining custom applications

TCP or UDP port and range of ports

ASCII or binary pattern up to the first 255 bytes of TCP or UDP payload

HTTP URL – any combination of hostname as in the HTTP message host field, and URI, e.g. http://www.cisco.com/go/avc, www.cisco.com is the host portion, while the go/avc is the URI portion.

NBAR2 Application Attributes

NBAR2 provides six pre-defined attributes for every application to group applications of similar types. This simplifies the classification rules and reporting by matching applications using attributes in class-map, or reporting based on attributes.

Table 1. List of NBAR2 attributes

NBAR2 Attribute

What it is used for

Category

First level grouping of applications with similar functionalities

Sub-category

Second level grouping of applications with similar functionalities

Application-group

Grouping of applications based on brand or application suite

P2P-technology?

Indicate application is peer-to-peer

Encrypted?

Indicate application is encrypted

Tunneled?

Indicate application uses tunneling technique

The values of these six NBAR2 attributes are pre-defined for every application recognized by NBAR2, including custom applications. Users can choose to reassign the attribute values of any NBAR2 application by using CLI ip nbar attribute-set and ip nbar attribute-map.

Below table shows all the six attributes and all the possible values.

Table 2. List of NBAR2 attributes and supported values

AVC Component – Performance Collection and Exporting

All the information collected and exported by AVC is done using Flexible Netflow infrastructure which can collect application information provided by NBAR2, traffic flow information, and application statistics such as byte and packet count. In addition, there are specific engines which collect performance metrics for voice, video, and TCP applications. All information is aggregated and then exported through open export format such as Netflow Version 9 and IP Flow Information Export (IPFIX). Classic netflow (or traditional netflow) and netflow version 5 are not suitable for AVC because they can only report layer 3 and layer 4 information.

Figure 8. Performance Collection and Exporting Components

Flexible Netflow (FNF), Netflow version 9, and IPFIX

By utilizing Flexible Netflow infrastructure, users have complete control of what information to collect and how the a is aggregated into what is called FNF record. A FNF record is defined by specifying appropriate keyed fields and non-keyed fields. Keyed fields define a set of field(s) which need to be unique in order for a new FNF record to be created. Examples of how keyed fields are chosen depend on what information is of interest to users:

Collect application usage: Keyed field is NBAR2 application

Collect traffic between two end-points: Keyed fields are source and destination IP addresses

Non-keyed fields provide other information of interest into the FNF record. Non-keyed fields typically are information such as byte count, packet count, input and output interfaces, and performance metrics such as latency or jitter.

For every FNF record, a FNF cache table is created to track and store the information, so call FNF cache entry. The whole FNF cache table is exported at regular interval or when an event is triggered, e.g. transaction ends. Flexible Netflow infrastructure allows multiple FNF records, each one aggregating or collecting different information. For example, there may be one FNF record which collects application statistics, and another FNF record which collects conversation between two end-points.

Netflow version 9 and IPFIX are the export protocols of choices for AVC, because they can accomodate flexible record format and multiple records required by Flexible Netflow infrastructure.

Implementing the visibilty in AVC is simply defining various FNF records to collect the following information,

Application Statistics

AVC provides the ability to discover applications statistics. Application information such as Sharepoint, Netflix, provided by NBAR2 is exported in FNF field, Application ID. Extracted information such as URI or Hostname is exported in another FNF field, Extracted Field. By exporting these application fields along with other information from traffic flow such as IP address, port, byte count, packet count, or DSCP, collectors can use these fields to produce various application statistics reports which include, but are not limited to, top talkers, top applications, visited website, or top clients. .

Media Monitoring (MMON) engine collects performance information such as jitter and packet loss, in addition to per-stream byte count and packet count, at the granularity of RTP SSRC level. This is done by inspecting the timestamp and sequence number information in RTP header, and comparing the expected received packets with received packets, in order to provide loss packets and loss rate. RTP payload type in the RTP header provides information about the clock rate.

Application Response Time (ART) engine inspects TCP headers and performs internal timestamping of packets. By inspecting the TCP header sent by client or server, it is able to differentiate request and response messages which are part of each transaction within a TCP connection. It also uses the internal timestamp information and TCP sequence number to calculate various latency metrics such as response time, transaction time, network delay, and application delay. Users can use these metrics to proactively monitor the performance of critical TCP applications and to troubleshoot and isolate problems between network and application.

Figure 10. Application Response Time metrics break down

Total Delay corresponds the total response time experienced by the end users. This includes the time to deliver the request to the application servers, the time to deliver the response back to the clients, and time for application servers to process the transaction. By providing these latency metrics broken down into Network Delay and Application Delay, users can determine if the impact to application performance, as an increase to Total Delay, is due to the increase in Network Delay or Application Delay. In addition, since the ART engine inspects traffic between client and server, it can also further separate the Network Delay into the Client Network Delay (CND) and Server Network Delay (SND). This allows further isolation of potential network problem into the client or server side. If the ART engine is enabled on the branch router such as ISR G2, CND approximates LAN delay while the SND approximates WAN delay, and vice versa if ART engine is enabled on the headend router.

AVC Component – Network Management

All the information exported by AVC is opened standard, Netflow Version 9 and IPFIX. This allows both Cisco and 3rd party network management tool products to support AVC. For the current list of 3rd party products which support AVC, please visit http://developer.cisco.com/web/avc

Figure 11. Network management for AVC

Cisco Prime Infrastructure can also configure AVC monitoring for both the ISR G2 and ASR1000. With its one-click configuration, AVC can be enabled on a device within minutes. For bulk deployment, an AVC configuration template is also provided.

Figure 12. AVC configuration in Cisco Prime Infrastructure

The data provided by AVC can be used for multiple purposes, proactive monitoring, capacity planning, and troubleshooting both infrastructure and application performance issues. The types of reports which can be generated by AVC include, but are not limited to:

AVC Component – Control

AVC utilizes two technologies to provide application-level control to provide application bandwidth and path control.

Figure 14. Control technologies used in AVC

By using Cisco QoS technology in conjunction with application identification provided by NBAR2, AVC can provide per-application bandwidth control such as guaranteeing bandwidth, limiting maximum bandwidth, and prioritizing latency-sensitive application. QoS classification (class-map) has been enhanced to support classification based on NBAR2 application and attributes. These classification criteria can work in conjunction with existing QoS classification criteria such as ACL or DSCP. For more information on QoS, please visit http://www.cisco.com/go/qos

AVC can also provide intelligent path selection through Cisco Performance Routing (PfR) technology. When there are multiple links, PfR can monitor the traffic path in real time and select the path which can satisfy the performance requirement for the application. For example, network administrator can define a policy for real time voice traffic with performance threshold such as delay or jitter, PfR will constantly monitor all the available paths and only send traffic over the paths which can meet the performance requirement. For more information on PfR, please visit http://www.cisco.com/go/pfr

Conclusion

In today's environment, network has critical roles to deliver optimal application experience to the end users, and at the same time provide network admin visibility into the applications and their performance in the network. Cisco AVC addresses these challenges by providing the capabilities which are integrated into the network infrastructure to identify, monitor, and control applications. This integrated approach simplifies the operation, yet provides pervasive application visibility and control to address the increasing challenges of delivering applications with high quality of experiences.