Chapter 6. Application Recognition
This chapter covers the following topics:
Network Based Application Recognition version 2 (NBAR2)
NBAR2 operations and functions
NBAR2 auto-learning and customization
Validation and troubleshooting of NBAR2
“Application” in the context of this book refers to a network application, which is the network traffic between two or more computers that exchange data for a particular service or use. Network applications have various uses, such as client access to a server service (web, mail, database), a client that talks with other clients (media, file transfer, peer-to-peer), network control (BGP, IKE), signaling protocols (SIP, H.323), and operation services (SNMP, syslog).
This chapter explains how network applications can be identified so that the classified applications can be used later for Quality of Service (QoS), Performance Routing (PfR), and application visibility.
What Is Application Recognition?
Application recognition is a system that classifies a wide variety of protocols and applications that are sent over a network. In most cases, application recognition associates an application with a particular TCP or UDP connection, which represents the data exchange for a specific service. In some cases, the application is associated with other types of data transactions, such as multiple media sessions multiplexed within a single TCP or UDP connection or non-TCP/UDP traffic.
In addition to identifying the application itself, application recognition can also provide additional metadata about the application. Such metadata can include categorization or attributes of applications, Layer 7 information extracted from the traffic, and other such information.
A particular type of traffic can run as a hierarchy of applications or protocols, for example:
A web service (such as mail, video, storage) that runs on top of HTTP or HTTPS
Application traffic tunneled in HTTP as a method for transmission through firewalls
When multiple applications use the same HTTP protocol, it is difficult to differentiate an application that the organization/business needs from a non-business-critical application. Application recognition can identify all protocol and application layers.
Some network services create multiple separate connections associated as one service, for example, FTP control and data, or Session Initiation Protocol (SIP) signaling and Real-Time Transport Protocol (RTP). Application recognition can bundle and associate these connections together and derive attributes from one connection to its associated sessions.
What Are the Benefits of Application Recognition?
Identifying and classifying network traffic is a basic step in implementing network policies such as QoS, application-based routing, monitoring, and security.
Knowledge of the applications and application attributes shifts the policy language from the networking level to a simple and intuitive application-based terminology that can be directly aligned with business goals.
Administrators can implement policies more effectively after identifying the types of applications and protocols that are running on a network. These policies do not change when a new server is brought up or moved to a different location because the application classification remains the same.
Application recognition provides network administrators with the ability to understand the types of applications and protocols operating on the network, the amount of traffic generated by each application, and how each application performs. With this knowledge an administrator can understand how the network is used, identify problems, operate the network better overall, and plan for the future.
NBAR2 Application Recognition
Cisco Network Based Application Recognition version 2 (NBAR2) is an application recognition system integrated into various Cisco network devices (such as routers, switches, access points, converged access) and virtual services (such as CSR 1000V and Cisco Virtual Network Analysis Module [vNAM]).
NBAR2 provides the necessary application recognition capability to support services such as QoS, PfR, and visibility. It interoperates with most types of interfaces and services that are applied together on devices. NBAR2 is enabled automatically whenever a service requests application-based policies; there is no need to enable it explicitly. Configuration options for NBAR2 are described later in this chapter.
NBAR2 delivers the best possible application recognition, providing results as early as is achievable and with performance optimized. NBAR2 accomplishes this using a combination of complementary techniques. No single technique can classify every type of network traffic. Each technique addresses different types and granularities of applications and improves the overall application recognition results across a variety of scenarios.
NBAR2 application recognition techniques are based on
Deep packet inspection (DPI)
Domain Name System (DNS) queries and snooping
Statistical and behavioral traffic patterns
Signaling from authoritative sources and databases
Auto-learning of local specific applications
User customization of specific known applications
In addition to application classification, NBAR2 provides a set of categories and attributes, Layer 7 extracted fields, and an application hierarchy to simplify policy configuration and improve the user experience.
NBAR2 Application ID, Attributes, and Extracted Fields
NBAR2 provides an application ID, application attributes, and Layer 7 extracted fields per flow. These are used to simplify application policies (PfR, QoS, and so on) or visibility.
NBAR2 Application ID
The NBAR2 application ID is based on RFC 6759 and uniquely defines an application by the engine ID and selector ID. The application ID remains consistent across most Cisco DPI engines that exist on multiple devices (IOS, IOS XE, NAM, and so on).
The show ip nbar protocol-id command displays the applications detected by NBAR2 and associated application IDs, as shown in Example 6-1. In the output, id represents the selector ID and type represents the engine ID.
Example 6-1 List of Applications and IDs
R31-Spoke# show ip nbar protocol-id
! Output omitted for brevity
Protocol Name id type
----------------------------------------------
3com-amp3 629 L4 IANA
3com-tsmux 106 L4 IANA
3pc 34 L3 IANA
4chan 763 L7 STANDARD
58-city 704 L7 STANDARD
.
sip 5060 L4 IANA
skinny 63 L7 STANDARD
skype 83 L7 STANDARD
smtp 25 L4 IANA
snmp 161 L4 IANA
NBAR2 Application Attributes
Each application has a set of attributes such as business relevance, category, subcategory, traffic class, application group, peer-to-peer (P2P), encrypted, or tunnel technology. It is recommended to use attributes when applying application-based policies such as QoS or PfR. For example, to apply a policy for business-relevant applications, use the business-relevance attribute, or to apply a policy for voice and video traffic, use the voice-and-video category. The attributes associated with each application are defined in the NBAR2 Protocol Pack and can be customized according to specific deployment needs.
Note
An NBAR2 Protocol Pack contains information on applications officially supported by NBAR2 that are compiled and packed together. Protocol Packs are covered in depth later in this chapter.
Table 6-1 shows the NBAR2 attributes that are available with Protocol Pack version 21 (released in June 2016), subject to change in future releases.
The application attributes are displayed with the command show ip nbar protocol-attribute application-name.
Example 6-2 shows attributes for the cisco-phone application.
Example 6-2 List of Application Attributes
R31-Spoke# show ip nbar protocol-attribute cisco-phone
Protocol Name : cisco-phone
encrypted : encrypted-no
tunnel : tunnel-no
category : voice-and-video
sub-category : enterprise-voice-collaboration
application-group : cisco-phone-group
p2p-technology : p2p-tech-no
traffic-class : voip-telephony
business-relevance : business-relevant
Note
Chapter 14, “Intelligent WAN Quality of Service (QoS),” explains a QoS policy that is based on the traffic-class and business-relevance attributes to simplify the identification of network traffic.
Business relevance directly refers to applications that are identified as relevant (supporting business objectives), default (applications that may or may not support a business or are just unknown), or irrelevant (not supporting business objectives).
Every application attribute has a set of possible values and a few custom values. Example 6-3 shows the possible values supported for the category attribute.
Example 6-3 List of Options per Attribute
R31-Spoke# show ip nbar attribute category
! Output omitted for brevity
Name : category
Help : Category attribute
Type : group
Groups : anonymizers
: backup-and-storage
: browsing
: business-and-productivity-tools
: consumer-file-sharing
: consumer-internet
: consumer-messaging
: consumer-streaming
: custom-category
: custom1-category
: custom2-category
: database
: email
NBAR2 Layer 7 Extracted Fields
NBAR2 supports extraction of Layer 7 information such as HTTP URL, host name, SIP domains, and so on. These can be exported over NetFlow for visibility into the traffic data. Table 6-2 lists the NBAR2 Layer 7 extracted information that is available with Protocol Pack version 21, subject to change in future releases.
NBAR2 Operation and Functions
This section provides background on how NBAR2 works in order to better understand how to deploy it. NBAR2 uses multiple mechanisms and multiple layers of application recognition, which are selected based on the traffic, the learning of the network, and the level of granularity required.
Figure 6-1 shows a high-level diagram of NBAR2 operation. Application recognition is determined by the NBAR2 software engine on each device. The NBAR2 controller logic can assist with cross-network learning, integration, and propagation of application information across the network but is not a mandatory component of the solution. The NBAR2 engine analyzes network traffic using application signatures stored in the Protocol Pack to identify specific application traffic. The signatures for each application include regular expressions and traffic pattern information to identify application traffic. Cisco provides a standard, wide-ranging set of applications in the form of a Protocol Pack, updated periodically.
The NBAR2 engine uses a flow table to track and store states on each TCP or UDP flow. The engine analyzes the traffic to learn patterns (for example, known servers or clients) and stores the pattern information on local cache tables. This information is used by the local device to improve the classification and, optionally, is also fed to the controller logic. The controller logic collects this information from multiple network devices, analyzes it together with additional controller information, and pushes the combined processed information back to the network devices.
The application recognition results are consumed by services running on the device such as PfR, QoS, and visibility.
Note
A flow is a tuple that contains the source IPv4/IPv6 address, destination IPv4/IPv6 address, source port, destination port, TCP/UDP protocol, and VRF.
When using NBAR2 controller logic, the ip nbar classification cache sync {export | import} command enables the controller and device integration. The export keyword enables exporting application information from the device to the controller. The import keyword enables the controller to program application information to the device.
Phases of Application Recognition
NBAR2 attempts to provide the best possible classification as early as possible in the flow. Figure 6-2 shows the phases of application recognition along the flow.
First Packet Classification
In some cases, NBAR2 can provide classification based on the first packet of the flow. First packet classification is mainly based on the flow tuple. NBAR2 stores the flow mapping, socket mapping (server IP and port), or IP mapping to its cache. NBAR2 learns the mapping by traffic aggregation, DNS snooping, or controller logic.
Some services, such as PfR, use application-based policies to select the traffic path. Classifying on the first packet of the flow also causes path selection on the first packet of the flow. If the application is not determined on the first packet, PfR may modify the path later in the flow when the application is determined.
Services such as firewalls, NAT, and WAAS optimization are sensitive to path changes in the middle of the flow. Such services track the state of the flow and, when applied in the path, can close the flow when the path changes, so a good first packet classification is essential in such cases.
Multistage Classification
After attempting to classify a flow based on the first packet, NBAR2 analyzes additional packets of the flow to improve the classification if possible. Additional packets or additional flows contain more information that NBAR2 uses to fine-tune the application. For example, NBAR2 may initially provide a generic application classification such as Cisco-Collaboration based on traffic going to a known destination server. After analyzing additional packets, NBAR2 may detect the SIP protocol and refine the classification from Cisco-Collaboration to TelePresence. When additional packets are observed, NBAR2 may apply statistical classification to further fine-tune the application classification to audio or video streams. At each stage of refining the classification, NBAR2 provides the best available classification result so that application-based policies (such as QoS or PfR) can operate as accurately as possible.
Final Classification
In this phase, NBAR2 stops the classification and reaches the final resolution of the application. The final application classification is stored in the flow table. NBAR2 continues to provide the final application classification without running through the NBAR2 engine. Depending on the traffic and the application mapping, the final classification may occur after a few packets of a flow.
Further Tracking
In some cases, when NBAR2 is required to extract Layer 7 information for subsequent packets, NBAR2 continues to process the packets of the flow. This does not change the classification but can be used to generate additional information on the flow.
Table 6-3 provides examples of the refinement of application classification that can occur in the various phases of a flow and includes an example of a flow whose final classification is available from the first packet analysis.
NBAR2 Engine and Best-Practice Configuration
NBAR2 uses multiple techniques to provide the best classification. Each technique fits different traffic types and use cases. This section describes the components and layers of the NBAR2 engine and how to configure them. The configurations listed in this section are best practices. For more configuration options, refer to the documentation “Network Based Application Recognition (NBAR)” on the cisco.com website.
Note
For full application recognition capability, NBAR2 requires network traffic to pass symmetrically through the device.
Multipacket Engine
One of the most basic elements of NBAR2 is the capability to inspect multiple packets within a flow and apply cross-packet signatures. NBAR2 tracks and store states for different packets along the flow in a flow table and simultaneously searches many multipacket signatures. Multipacket signatures are applied for many protocols and provide improved classification and accuracy.
DNS Engine
NBAR2 analyzes DNS traffic, checking for known or customized domain names. By inspecting the DNS replies, NBAR2 associates the domain name IP address with the related application. This association is used to map traffic flows sent to this IP address to the related application. To prevent the DNS engine from learning from any response, NBAR2 applies a DNS guard that must see both directions of DNS traffic and checks the validity of the DNS request and reply.
The DNS classification guard is enabled by default. It can be disabled using no ip nbar classification dns learning guard.
DNS Authoritative Source (DNS-AS) Engine
DNS-AS provides centralized control of custom application classification information. It leverages the universally available DNS query/response infrastructure to enable local DNS servers within an organization to propagate application classification metadata to devices in an enterprise network.
By centralizing the custom application metadata, a DNS server functioning as a DNS-AS server is an authoritative source for organizational internally hosted application classification information.
The local DNS server may be the organization’s main DNS server or a separate dedicated server provisioned with TXT records that contain the application information. The DNS-AS server can be any standard DNS server, and the TXT records should be provisioned to the server using standard DNS configuration files.
Note
When using a centralized controller such as Cisco APIC-EM, it is simpler and more efficient to provision local applications using the command ip nbar custom custom-app-name composite server-name server-name-regex from the controller or allow auto-learning of local applications.
Figure 6-3 shows a typical DNS-AS operation. For simplicity, the DNS and DNS-AS servers are drawn as the same DNS server, but the solution allows the use of separate servers for DNS and DNS-AS.
Network clients initiate a DNS request (1) normally and receive a response from the DNS server (2). The original DNS request and response are snooped by NBAR2 running on the router. For specific provisioned trusted domains, NBAR2 initiates another DNS A and TXT request (3), requesting metadata provisioned for the domain of the original DNS query. After receiving a reply from DNS-AS (4), NBAR2 associates the server IP address with the application metadata to classify the applications going to that domain and customize the application in the device (5). NBAR2 checks the validity of the DNS-AS queries, rate-limits the number of requests, and maintains the time to live (TTL) of provisioned entries based on the time-to-live value of the DNS response.
The following steps provision DNS-AS on the devices:
Step 1. Enable DNS on the router performing the lookups.
Use the command ip name-server [vrf vrf-name] dns-server-ip-address. Multiple DNS server addresses may be specified, separated by spaces.
Step 2. Configure the trusted domains that DNS-AS will query.
The command avc dns-as client trusted-domains places the router in trusted domains submode. Domains are then added with the command domain regular-expression. DNS-AS sends a TXT query only for the domains defined in the trusted domains submode.
Step 3. Enable the DNS-AS client.
This is accomplished with the command avc dns-as client enable.
Step 4. Enable NBAR2 to snoop DNS traffic on the interface that is facing the source of the network traffic (LAN) and the destination network (WAN—DMVPN tunnels) per device.
The command interface interface-id places the configuration into interface parameter configuration submode. Then use avc dns-as learning to enable NBAR2 learning.
Example 6-4 shows a DNS-AS configuration example.
Example 6-4 DNS-AS Configuration
R31-Spoke# configure terminal
R31-Spoke(config)# ip name-server vrf VFR1 10.1.30.40
R31-Spoke(config)# avc dns-as client trusted-domains
R31-Spoke(config-trusted-domains)# domain *mydomain.com
R31-Spoke(config-trusted-domains)# exit
R31-Spoke(config)# avc dns-as client enable
R31-Spoke(config)# interface GigabitEthernet 0/0
R31-Spoke(config-if)# avc dns-as learning
R31-Spoke(config-if)# interface Tunnel 100
R31-Spoke(config-if)# avc dns-as learning
R31-Spoke(config-if)# interface Tunnel 200
R31-Spoke(config-if)# avc dns-as learning
The application information TXT resource record entries are provisioned into the DNS-AS server. The DNS-AS TXT records are provisioned in a standard DNS configuration. For information about adding new TXT entries, refer to the documentation for the specific DNS server type. Use the following syntax for adding a TXT record for a given domain: CISCO-CLS=app-name:application-name | business:{YES | NO | DEFAULT} | app-class:traffic-class | app-category:application-category | app-sub-category:application-sub-category | app-id:application-id.
Table 6-4 provides a description of each attribute in the TXT entry. Refer to Table 6-1 for the possible values for each attribute.
Example 6-5 shows a DNS-AS TXT entry for the MYDOMAIN application provisioned as an entry for the mydomain.org.com domain. The traffic class is set to multimedia streaming.
"CISCO-CLS=app-name:MYDOMAIN|app-class:MULTIMEDIA-STREAMING"
The DNS-AS server must also include the IP address of the domain for the device A query. Multiple IP addresses for a given domain are all associated to the application specified for that domain.
Note
The format is provided based on the guidelines at the time of publication of this book. The website www.dns-as.org provides the latest information on structure.
DNS Classification by Domain
DNS traffic can affect application performance. For example, if the DNS query for a site is delayed or routed to a different path, the overall application experience may be delayed. NBAR2 attempts to classify DNS traffic for an application in the same way as the application traffic itself. This ensures that both the DNS traffic and the application traffic are treated with the same traffic policy. This way DNS does not introduce unnecessary delay and affect the overall application experience.
DNS classification by domain is enabled by default but can be disabled using no ip nbar classification dns classify-by-domain.
Control and Data Bundling Engine
When NBAR2 detects a control protocol such as SIP or FTP control, it also determines the data flow parameters it initiates. Using these parameters, NBAR2 associates the classification result with the data flow even before the data flow has been sent.
Behavioral and Statistical Engine
NBAR2 uses behavioral and statistical mechanisms to recognize network applications from their traffic patterns. NBAR2 characterizes traffic based on parameters such as packet sizes and inter-packet gaps. When these parameters match predefined patterns, NBAR2 uses the result to improve classification results. For example, NBAR2 uses patterns of different packet sizes to distinguish between audio and video of encrypted traffic.
Layer 3, Layer 4, and Sockets Engine
NBAR2 uses Layer 3 IP addresses and Layer 4 port information to classify traffic. In most cases the IP addresses and ports are learned and stored in the internal NBAR2 cache or by specific Layer 3/Layer 4 application customization. This is the main mechanism used to provide classification based on the first packet of a flow.
A socket is the server IP and server port that NBAR2 learns and associates with a particular application. NBAR2 stores the socket-to-application association and uses it for classification of traffic that matches this association rule. The Layer 3/Layer 4 learning may be populated by
Customized Layer 3/Layer 4 applications
NBAR2 controller logic
DNS/DNS-AS, which associates a given server IP with a specific application
Socket caching, which associates a given socket with a specific application
Bundles, which consist of data flow learned from control flows
NBAR2 manages the correctness and lifetime of the associations. When necessary, it removes the entry from the internal cache.
Transport Hierarchy
NBAR2 transport hierarchy (TPH) provides a method for classifying underlying protocols or applications in addition to the final application classification. For example, when applications such as email, video, and so on are running over HTTP, NBAR2 provides HTTP as the transport hierarchy. In this case, the final classification would be email or video, but the transport hierarchy would be HTTP.
Modular Quality of Service Command-Line Interface (MQC) supports matching on the transport hierarchy using the class map command match protocol protocol-name in-app-hierarchy.
Subclassification
For some protocols, NBAR2 allows creating policies and exporting detailed Layer 7 information. To create an MQC policy based on subclassification, use the command match protocol protocol-name sub-classification value. The sub-classification keyword depends on the specified protocol name.
The HTTP protocol supports wildcard matching similar to regex. Matching is case insensitive, so, for example, there is no difference between cisco and CISCO. Here are some of the available wildcards:
* (Asterisk): Matches any pattern. To match the substring identified in the beginning of a string, end the pattern with the asterisk. To match the substring at the end, use the asterisk at the beginning of the pattern. To match the pattern anywhere in the string, use an asterisk at the beginning and end.
For example, the pattern *.cisco.com matches any site that ends with .cisco.com.
? (Question mark): Matches any single character. For example, the pattern www.?isco.com matches websites such as www.cisco.com or www.disco.com but not www.mycisco.com.
The escape sequence (Ctrl+V) must be pressed before the ? can be entered.
[ ] (Brackets): Matches any character in the pattern using the set of characters provided within the brackets. For example, the pattern [abc]isco.com matches websites that contain aisco.com, bisco.com, or cisco.com.
( ) (Parentheses): Matches a group of characters in the identified pattern. For example, the pattern (ftp).cisco.com matches ftp.cisco.com. Commonly the pipe is used with the parentheses.
| (Pipe): Allows for a Boolean OR when matching in a grouping of characters. For example, the pattern www.(cisco|webex).com matches either www.cisco.com or www.webex.com.
Example 6-6 shows a subclassification based on HTTP host name.
Example 6-6 HTTP Host Name Subclassification MQC Configuration
R31-Spoke# configure terminal
R31-Spoke(config)# class-map match-any MY-CLASS
R31-Spoke(config-cmap)# match protocol http host www.myhost*
Advanced customization allows creating a class map that specifies a particular file type. This may be used, for example, to create a policy for specific types of files being downloaded in a network. For example, the pattern *.mp4 can be used to control HTTP downloads of MP4 streams in a QoS policy.
Custom Applications and Attributes
In every deployment, there are local and specific applications that are not covered by the NBAR2 Protocol Pack provided by Cisco. Local applications are mainly categorized as
Applications specific to an organization
Applications specific to one geographic location but not others
NBAR2 provides ways to customize such local applications:
Auto-customization: NBAR2 can customize applications automatically.
Single-device customization can be done via the device command-line interface (CLI).
Multidevice customization can be done via the NBAR2 controller logic.
Manual customization: Manually customize NBAR2 for local applications.
In both cases, NBAR2 provides a way to learn the applications in the network before setting up any customization.
Auto-learn Traffic Analysis Engine
Local applications that are not identified specifically by a protocol in the NBAR2 Protocol Pack are typically classified by NBAR2 simply as generic applications, such as HTTP, SSL, or unknown applications. NBAR2 learns details from the traffic and attempts to provide more information on the host names, ports, or sockets of the network traffic. Using this data, NBAR2 can automatically create custom protocols for local applications to improve the identification of traffic. NBAR2’s auto-learn feature compiles multiple lists (host name, destination port, and other details) by sampling traffic flows for analysis. The lists are sorted by traffic volume.
To see the auto-learned tables, use the command show ip nbar classification auto-learn list-type number-of-entries.
Example 6-7 shows the top generic hosts collected by the auto-learn feature.
Example 6-7 Top Generic Hosts Collected by the Auto-learn Feature
R31-Spoke# show ip nbar classification auto-learn top-hosts 5
Total bytes: 2.117 G
Total packets: 2.112 M
Total flows: 30.096 K
Sample rate last: 1
Sample rate average: 1
Sample rate min: 1
Sample rate max: 1
-------------------------------------------------------------------------------
#|Host |Byte%|Flow%|Pkt% |Type |Field
-------------------------------------------------------------------------------
1|backup.mydomain.com | 77% | <1% | 79% |http |host
2|10.56.129.50 | 11% | 99% | 12% |http |host
3|mail.mydomain.com | 10% | <1% | 7% |http |host
4|10.56.111.6 | <1% | <1% | <1% |http |host
5|10.210.20.18 | <1% | <1% | <1% |http |host
Example 6-8 shows the top sockets (server IP plus server port).
Example 6-8 Top Sockets Collected by the Auto-learn Feature
R31-Spoke# show ip nbar classification auto-learn top-sockets 5
Total bytes: 1.898 G
Total packets: 1.480 M
Total flows: 18.112 K
Sample rate last: 1
Sample rate average: 1
Sample rate min: 1
Sample rate max: 1
------------------------------------------------------------------------------
#|Port |IP |Byte%|Flow%|Pkt% |Traffic Type
------------------------------------------------------------------------------
1|53695 |10.210.20.24 | 33% | <1% | 29% |UDP
2|51509 |10.210.20.24 | 32% | <1% | 28% |UDP
3|50997 |10.210.20.19 | 31% | <1% | 27% |UDP
4|23 |10.210.20.23 | 1% | <1% | 5% |TCP
5|23 |10.210.20.17 | 1% | <1% | 5% |TCP
Using the auto-learn results, high-volume local hosts, ports, and sockets can be customized as new local applications.
Traffic Auto-customization
The output in Example 6-7 shows that NBAR2 has learned that backup.mydomain.com consumes 77 percent of the generic traffic bandwidth. This is a potential candidate for a local application customization. To enable auto-customization, use the command ip nbar auto-custom list [max-protocols number].
When NBAR2 automatically creates a custom protocol, the new custom protocol inherits the attribute values of the generic application previously classified for that traffic. The attributes can be customized manually as described later in this chapter.
Note
It is recommended to auto-customize traffic using the NBAR2 controller logic to make sure all network devices have a consistent application customization.
Manual Application Customization
In some cases, operators may know the local application information, or they may use the auto-learn feature to discover applications but customize the applications manually. This allows further control of the application names and IDs. Manual application customization is done using the command ip nbar custom myname.
There are various types of application customization:
Generic protocol customization: Customization based on generic protocol identifiers such as
HTTP
SSL
DNS
Composite: Customization based on multiple underlying protocols
Layer 3/Layer 4: Customization based on network or transport-based characteristics such as
IPv4/IPv6 address
DSCP values
TCP/UDP ports
Flow source or destination direction
Byte offset: Customization based on specific byte values in the payload
cookie: HTTP cookie
host: Host name of the origin server containing the resource
method: HTTP method
referer: Address from which the resource request was obtained
url: Uniform Resource Locator path
user-agent: Software used by the agent sending the request
version: HTTP version
via: HTTP via field
Example 6-9 shows a customization for an application called MYHTTP using the HTTP host mydomain.com with selector ID 10.
Example 6-9 HTTP Host Name Customization
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar custom MYHTTP http host *mydomain.com id 10
Note
The engine ID and selector ID represent the application ID as described earlier in this chapter. For customized applications, the engine ID used is USER-DEFINED (6) and the selector ID is specified by the custom application CLI. It is recommended to assign the same selector ID for a given application across all routers to maintain consistency.
SSL Customization
Additional customization can be done for SSL-encrypted traffic using information extracted from the SSL server name indication (SNI) or common name (CN). The keyword unique-name is used for SSL customization.
Example 6-10 shows a customization for an application named MYSSL, using the SSL unique name mydomain.com with selector ID 11.
Example 6-10 SSL Unique Name Customization
R31-Spokeconfigure terminal
R31-Spoke(config)# ip nbar custom MYSSL ssl unique-name *mydomain.com id 11
Creating a customized application based on information observed in the DNS request/response
Extending the scope of an existing application by adding local DNS domains to match
NBAR2 examines DNS request/response traffic and can correlate the DNS response to an application. The IP address returned from the DNS response is cached and used for later packet flows associated with that specific application. The command ip nbar custom application-name dns domain-name domain-name id application-id is used for DNS customization.
Example 6-11 shows a customization for an application named MYDNS using the DNS domain name mydomain.com with selector ID 12.
Example 6-11 DNS Customization
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar custom MYDNS dns domain-name *mydomain.com id 12
Extending an existing application adds local DNS domain names as criteria to the existing application signatures. To extend an existing application, use the command ip nbar custom application-name dns domain-name domain-name extends existing-application. The existing application is used for application-based policies, and the application name is used to specify the name by which the traffic is reported.
Composite Customization
NBAR2 provides a way to customize applications based on domain names appearing in HTTP, SSL, or DNS. This is done using composite customization. Example 6-12 shows a composite application customization for the application named MYDOMAIN using the HTTP, SSL, or DNS domain name mydomain.com with selector ID 13.
Example 6-12 Composite Customization
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar custom MYDOMAIN composite server-name *mydomain.com id 13
Similar to DNS customization, a composite customization extends an existing application using the command ip nbar custom application-name composite server-name server-name extends existing-application.
Layer 3/Layer 4 Customization
Layer 3/Layer 4 customization is based on the packet tuple and is always matched on the first packet of a flow. The classification of IP address is refined with the command direction {source | destination | any}.
Example 6-13 shows a TCP application customization for an application called LAYER4CUSTOM using a set of IP addresses, 10.56.1.10 and 10.56.1.11, matched in any direction, and DSCP EF with selector ID 14.
Example 6-13 TCP Customization
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar custom LAYER4CUSTOM transport tcp id 14
R31-Spoke(config-custom)# ip address 10.56.1.10 10.56.1.11
R31-Spoke(config-custom)# direction any
R31-Spoke(config-custom)# dscp ef
Byte Offset Customization
Byte offset customization enables defining an application based on specific payload content.
Example 6-14 shows a byte offset customization for an application called MYHOME with the ASCII string HOME in the fifth byte of the first packet of the flow with TCP port 4500 and selector ID 15.
Example 6-14 Byte Offset Customization
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar custom MYHOME 5 ascii HOME tcp 4500 id 15
Manual Application Attributes Customization
As described in earlier sections, NBAR2 protocols provide a set of application attributes for the network application that they identify. The attribute options are predefined in the Protocol Pack. NBAR2 allows setting attributes associated to a given application from the set of available values. To customize the NBAR2 application attributes:
Step 1. Create an attribute map profile.
This is done with the command ip nbar attribute-map profile-name.
Step 2. Set the attribute values for each attribute type.
Use the command attribute attribute-type attribute-value.
Step 3. Apply the attribute map to an application.
The command for this is ip nbar attribute-set application-name attribute-map.
Not every attribute must be modified when an application attribute is changed. Assume that Skype is used to support business communication and therefore needs to have the business relevance changed from business-irrelevant to business-relevant.
Example 6-15 shows how the NBAR2 attribute business-relevance is identified and modified for the Skype protocol, and then how the change is verified.
Example 6-15 Modifying an Application’s NBAR2 Attributes
R31-Spoke# show ip nbar protocol-attribute skype
Protocol Name : skype
encrypted : encrypted-yes
tunnel : tunnel-no
category : consumer-messaging
sub-category : consumer-multimedia-messaging
application-group : skype-group
p2p-technology : p2p-tech-yes
traffic-class : multimedia-conferencing
business-relevance : business-irrelevant
R31-Spoke(config)# ip nbar attribute-map SKYPE-RELEVANT
R31-Spoke(config-attribute-map)# attribute business-relevance business-relevant
R31-Spoke(config-attribute-map)# exit
R31-Spoke(config)# ip nbar attribute-set skype SKYPE-RELEVANT
R31-Spoke# show ip nbar protocol-attribute skype
Protocol Name : skype
encrypted : encrypted-yes
tunnel : tunnel-no
category : consumer-messaging
sub-category : consumer-multimedia-messaging
application-group : skype-group
p2p-technology : p2p-tech-yes
traffic-class : multimedia-conferencing
business-relevance : business-relevant
NBAR2 State with Regard to Device High Availability
In highly available environments, after a switchover event, NBAR2 running on the device does not maintain the flow classification and restarts the classification process. Application information propagated by the NBAR2 controller logic is updated on the next controller update when the device becomes available.
Encrypted Traffic
In today’s networks, a high percentage of network traffic is encrypted. NBAR2 provides multiple mechanisms to classify encrypted traffic, described in this section:
Authoritative sources: NBAR2 integrates with authoritative sources to use a specific, known flow tuple to accurately classify the traffic of a particular application. This is the best encrypted traffic classification mechanism.
DNS mechanisms: NBAR2 uses DNS request/response traffic to classify applications destined for a given domain.
SSL certificates: NBAR2 uses SSL certificate signatures to classify applications destined for a given domain.
Statistical and behavioral mechanisms: NBAR2 uses a set of statistical and behavioral mechanisms to identify certain applications based on the traffic patterns.
NBAR2 Interoperability with Other Services
NBAR2 is required to run together with various routing technologies such as QoS, WAAS, NAT, firewalls, monitoring, PfR, and so on. It provides interoperability with various configuration services used by various use cases. To support this, NBAR2 and other services run in a specific order within the device to provide the best application recognition results:
NBAR2 processes packets as early as possible after encrypted VPN decapsulation (clear traffic).
NBAR2 processes traffic in both directions to inspect packets between devices.
When NBAR2 is applied on multiple interfaces, it attempts to process each packet once and carry the classification results as metadata across the device.
Special methods are applied when running in combination with application optimization (WAAS) where the application is stored and derived per flow for both unoptimized and optimized traffic, and with NAT where the application is provided in both inside and outside traffic.
NBAR2 Protocol Discovery
NBAR2 protocol discovery provides a simple method for discovering applications passing through an interface.
Protocol discovery can provide the following statistics, per application, for any protocol traffic supported by NBAR2, for each enabled interface:
Total number of input packets and bytes
Total number of output packets and bytes
Input bit rates
Output bit rates
NBAR2 protocol discovery supports statistics collection for up to 32 interfaces in parallel.
Note
NBAR2 protocol discovery is used primarily for discovering applications and for troubleshooting. It is not necessary to enable it for a standard deployment. NBAR2 is enabled automatically whenever a service requests application-based policies.
Enabling NBAR2 Protocol Discovery
NBAR2 protocol discovery is enabled for a specific interface using the following command in interface configuration mode for the desired interface: ip nbar protocol-discovery [ipv4 | ipv6].
Example 6-16 shows how to enable NBAR2 protocol discovery for both IPv4 and IPv6 for interface GigabitEthernet0/0.
Example 6-16 Enabling NBAR2 Protocol Discovery
R31-Spoke(config)# interface GigabitEthernet 0/0
R31-Spoke(config-if)# ip nbar protocol-discovery
Displaying NBAR2 Protocol Discovery Statistics
To display protocol discovery results, use the command show ip nbar protocol-discovery [interface type number] [stats {byte-count | bit-rate | packet-count | max-bit-rate}] [protocol protocol-name | top-n number].
Example 6-17 shows the NBAR2 protocol discovery statistics results for the four most active protocols and for interface GigabitEthernet0/0.
Example 6-17 NBAR2 Protocol Discovery Statistics
R31-Spoke# show ip nbar protocol-discovery interface GigabitEthernet 0/0 top-n 4
GigabitEthernet0/0
Last clearing of "show ip nbar protocol-discovery" counters 1d06h
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
cifs 19923531 39002528
6473455995 37313113039
0 0
21464000 53795000
vmware-vsphere 31607442 16812217
32654628841 1706705556
0 0
54040000 1477000
vnc 9600398 4794044
9345917474 286538197
0 0
16384000 446000
webex-meeting 8784096 5950890
8142257441 1578210867
0 0
11582000 1761000
Total 116902145 114366234
82846046737 58445765327
97000 209000
150433000 84222000
Clearing NBAR2 Protocol Discovery Statistics
The NBAR2 protocol discovery statistics are cleared using the command clear ip nbar protocol-discovery [interface interface-id].
Example 6-18 shows how to clear NBAR2 protocol discovery statistics for interface GigabitEthernet0/0.
Example 6-18 Clearing NBAR2 Protocol Discovery Statistics
R31-Spoke# clear ip nbar protocol-discovery interface GigabitEthernet 0/0
NBAR2 Visibility Dashboard
NBAR2 provides an on-device traffic visibility dashboard for IOS XE software releases from release 16.3.1. The visibility dashboard includes interactive charts and graphics to provide better traffic visibility, as shown in Figure 6-4.
After the NBAR2 visibility dashboard is enabled, a periodic task is created, which collects the NBAR2 discovery data per minute and stores the data in a local database. The visibility dashboard enables viewing application statistics over time. It is possible to view the statistics according to a specified time window, direction, and interface.
To use the NBAR2 visibility dashboard, perform the following steps:
Step 1. Enable the HTTP server on the device.
This is done with the command ip http server.
Step 2. Enable the NBAR2 visibility dashboard.
Use the command ip nbar http-services.
Step 3. Access the visibility dashboard.
From a web browser go to the following address: http://router-ip-or-hostname/webui/#/applicationVisibility. For example, R31’s (loopback IP address of 10.3.0.31) dashboard can be reached at http://10.3.0.31/webui/#/applicationVisibility.
Example 6-19 demonstrates how to enable the NBAR2 visibility dashboard.
Example 6-19 Enabling the NBAR2 Visibility Dashboard
R31-Spoke(config)# ip http server
R31-Spoke(config)# ip nbar http-services
NBAR2 Protocol Packs
An NBAR2 Protocol Pack contains information on applications officially supported by NBAR2 that are compiled and packed together. For each application the Protocol Pack includes information on
The application signatures that enable NBAR2 to identify specific network applications.
Preconfigured application attributes that describe important aspects of the network application. This information is helpful for reporting and for determining traffic policy for the network application and for network visibility.
Release and Download of NBAR2 Protocol Packs
Each software release supports the latest NBAR2 Protocol Pack available at the time of the main software release. NBAR2 provides a hitless way to update the Protocol Pack and supported applications without any traffic or function interruption and without the need to modify the software image on the devices.
The NBAR2 Protocol Pack is released periodically and contains over a thousand applications (and continues to grow) for the most commonly used applications. The list of NBAR2 Protocol Packs is called the NBAR2 Protocol Library. The Protocol Library lists the content of each Protocol Pack, the set of attributes, and release notes. Cisco continues to add applications to Protocol Packs which can be downloaded from the Cisco website at “NBAR Protocol Library.” The URL for the Protocol Library web page is provided at the end of this chapter.
NBAR2 Protocol Packs are available for download on the Cisco “Download Software” web page. Specify a device model for which to display the available software, then select “NBAR2 Protocol Packs” in the software type. For each Protocol Pack version, there is a list of software releases for which the Protocol Pack has been released and tested. Long-lived software releases support multiple Protocol Pack versions, whereas short-lived software releases support only the built-in Protocol Pack within the software image.
NBAR2 Protocol Pack License
To enable the full set of NBAR2 applications, an advanced feature set license is required. The Application Experience software license is used for router devices; check the specific device license requirements on the Cisco website.
Application Customization
The applications included in the NBAR2 Protocol Pack from Cisco provide a foundation for NBAR2 application recognition. To supplement this, NBAR2 includes functions to create custom protocols for localized applications and to learn from local traffic patterns. Localized applications are applications specific to an organization or specific to a geographical location. Learning and customization of protocols are discussed earlier in this chapter.
NBAR2 Protocol Pack Types
NBAR2 provides two ways to load and use Protocol Packs:
Built-in: Each software release has a built-in Protocol Pack bundled with it. The built-in Protocol Pack is the latest one available at the time of the main software release.
Loaded: In addition to the built-in Protocol Pack, multiple additional Protocol Packs can be loaded. NBAR2 uses the most up-to-date loaded Protocol Pack as the active Protocol Pack; the other loaded Protocol Packs are inactive.
NBAR2 Protocol Pack States
An NBAR2 Protocol Pack may be in one of the following states:
Active: The running Protocol Pack that is currently used by the device for application recognition signatures and metadata.
Inactive: A Protocol Pack loaded to the device but not currently running. Inactive Protocol Packs are usually older than the active Protocol Pack or are not compatible with the currently running software.
Identifying the NBAR2 Software Version
Each Protocol Pack release is compatible with specific IOS software versions, described in the Protocol Pack release notes. Compatibility is determined in part by the NBAR2 software engine. The command show ip nbar version displays the NBAR2 engine software version.
Example 6-20 shows that the NBAR2 engine software version is 26. The minimum backward-compatible version indicates that Protocol Packs compatible with NBAR2 software engine version 25 are also supported.
Example 6-20 Displaying the NBAR2 Engine Software Version
R31-Spoke# show ip nbar version
NBAR software version: 26
NBAR minimum backward compatible version: 25
Loaded Protocol Pack(s):
Name: Advanced Protocol Pack
Version: 20.0
Publisher: Cisco Systems Inc.
NBAR Engine Version: 26
State: Active
Verifying the Active NBAR2 Protocol Pack
The command show ip nbar protocol-pack active displays the active NBAR2 Protocol Pack.
Example 6-21 shows an active Protocol Pack version 20.0, built for NBAR2 software engine version 26.
Example 6-21 Verifying the Active NBAR2 Protocol Pack
R31-Spoke# show ip nbar protocol-pack active
Active Protocol Pack:
Name: Advanced Protocol Pack
Version: 20.0
Publisher: Cisco Systems Inc.
NBAR Engine Version: 26
State: Active
Loading an NBAR2 Protocol Pack
At any given time, only one Protocol Pack can be active. Before loading a new Protocol Pack, it is recommended to copy the Protocol Pack to a local disk to avoid any errors after rebooting. To load a Protocol Pack onto a device, use ip nbar protocol-pack protocol-pack [force].
The optional force option activates a Protocol Pack of a lower version, even if more up-to-date Protocol Packs are loaded on the system. The force option also removes configuration lines used by the active Protocol Pack that are not supported by the loaded Protocol Pack. It is usually used when downgrading a Protocol Pack.
Note
An NBAR2 Protocol Pack may be downgraded to a lower version as a part of troubleshooting behavior or to ensure that the Protocol Pack is consistently deployed across all platforms regardless of the OS version on the router.
Example 6-22 shows how to load a new Protocol Pack, newProtocolPack, from the hard disk.
Example 6-22 Loading a New NBAR2 Protocol Pack
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar protocol-pack harddisk:newProtocolPack
Example 6-23 shows how to revert to the built-in NBAR2 Protocol Pack by using the default command.
Example 6-23 Reverting to the Built-In NBAR2 Protocol Pack
R31-Spoke# configure terminal
R31-Spoke(config)# default ip nbar protocol-pack
Example 6-24 shows how to load a lower Protocol Pack version, oldProtocolPack, using the force option.
Example 6-24 Loading an Older Protocol Pack
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar protocol-pack harddisk:oldProtocolPack force
R31-Spoke(config)# exit
Protocol Packs that match a newer software release can be loaded to a device but are not activated. The new Protocol Pack is stored in the running configuration. After the software image is upgraded, NBAR2 chooses the running configuration Protocol Pack at boot time, activating the new Protocol Pack.
NBAR2 Taxonomy File
The NBAR2 taxonomy is an XML-based file that contains information such as the name, description, attributes, global application ID, and other information for every application available in the Protocol Pack. The taxonomy file is mainly used to provide the application details to external servers or to display more details about each application.
The command show ip nbar protocol-pack {active | inactive | loaded} taxonomy displays the taxonomy for the Protocol Pack selected.
The NBAR2 taxonomy file generally contains the information for thousands of protocols. It is recommended to redirect the output to a file by using the redirect output modifier, as shown in Example 6-25.
Example 6-25 Redirecting the NBAR2 XML Taxonomy File to the Hard Disk
R31-Spoke# show ip nbar protocol-pack active taxonomy | redirect
harddisk:taxonomy.xml
Protocol Pack Auto Update
The Protocol Pack Auto Update feature assists in updating a large number of devices with the latest compatible Protocol Pack. When a new Protocol Pack becomes available, download the file to a server that is reachable by every device. Platforms with Auto Update enabled check the server periodically. If a newer Protocol Pack is available and compatible, the device downloads the Protocol Pack file and installs it automatically. This procedure centralizes the protocol update, making it unnecessary to update the Protocol Pack on every device manually. It also helps to ensure that all network devices operate consistently with the same Protocol Pack version.
Protocol Pack Configuration Server
Devices with Protocol Pack Auto Update enabled check a configuration file stored on a configuration server. This configuration file provides instructions for the device on the location of the Protocol Pack and the update schedule.
Protocol Pack Source Server
The Protocol Pack source server stores the Protocol Packs themselves. The Protocol Pack configuration server and Protocol Pack source server can be the same server or separate servers.
The following steps are used to enable the Protocol Pack Auto Update function:
Step 1. Enter Protocol Pack Auto Update configuration mode.
Use the command ip nbar protocol-pack-auto-update.
Step 2. Configure the source server IP and configuration file location.
This is done with the command source-server server+location.
Example 6-26 shows a configuration of source TFTP server address 10.130.1.80 where the configuration file is located in the AutoUpdateConfigDir directory.
Example 6-26 Protocol Pack Auto Update Configuration
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar protocol-pack-auto-update
R31-Spoke(config-pp-auto-update)# source-server tftp://10.130.1.80/AutoUpdateConfig-
Dir
The source server configuration provides the instructions for how to load the Protocol Packs. The configuration file is a JSON format file named NBAR_PROTOCOL_PACK_DETAILS.json. Table 6-5 describes the parameters in the JSON file.
Example 6-27 shows a typical NBAR_PROTOCOL_PACK_DETAILS.json configuration file. It schedules a daily update at 2:30 a.m. and indicates the directories for Protocol Packs for NBAR2 software engine versions 22 and 23 for ISR devices, and version 23 for ASR and CSR devices.
Example 6-27 NBAR_PROTOCOL_PACK_DETAILS.json Configuration
{
"nbar_auto_update_config": {
"protocol-pack-server": "tftp://10.130.1.200/NbarAutoUpdate/",
"update-window":30,
"force-upgrade":true,
"clear-previous":true,
"schedule": {
"weekly": 6,
"hh": 02,
"mm": 30
},
},
"nbar_pp_files": {
"ISR": {
"22":"isr_protocolpack_dir/pp22",
"23":"isr_protocolpack_dir/pp23"
},
"ASR": {
"23":"asr_protocolpack_dir/pp23"
},
"CSR": {
"23":["csr_protocolpack_dir/pp23"]
}
}
}
It is possible to initiate a manual ad hoc Protocol Pack update from a given device using ip nbar protocol-pack-auto-update now as shown in Example 6-28.
Example 6-28 Immediate Protocol Pack Auto Update
R31-Spoke# configure terminal
R31-Spoke(config)# ip nbar protocol-pack-auto-update now
R31-Spoke# show ip nbar protocol-pack-auto-update
NBAR Auto-Update:
=================
Configuration:
=============
force-upgrade : (Default) Enabled
clear-previous : (Default) Enabled
update-window : (Default) 30
source-server : tftp://10.130.1.80/AutoUpdateConfigDir
protocol-pack-directory : (Default) harddisk:
schedule : (Default) 02:30
Copied files:
==========
File : harddisk:/NbarAutoUpdate/AsrNbarPP
Copied : *11:29:11.000 UTC Mon Jan 5 2016
Last run result: SUCCESS
Last auto-update run : *11:29:12.000 UTC Mon Jan 5 2016
Last auto-update success : *11:29:12.000 UTC Mon Jan 5 2016
Last auto-update successful update : *11:29:12.000 UTC Mon Jan 5 2016
Last auto-update server-config update : *16:15:13.000 UTC Mon Jan 5 2016
Success count : 3
Failure count : 0
Success rate : 100 percent
Next AU maintenance estimated to run at : *17:15:13.000 UTC Mon Jan 5 2016
Next AU update estimated to run at : *02:41:00.000 UTC Tue Jan 6 2016
Validation and Troubleshooting
The health of the NBAR2 system should be checked to ensure that packets are being properly classified. This section describes the most common NBAR2 troubleshooting scenarios and shows how to verify proper operation of the system.
Verify the Software Version
NBAR2 works best with “long-lived” IOS releases, which support Protocol Pack upgrades and bug fixes for the longest possible support period. To check the IOS software version, use show version.
Check the Device License
Advanced application recognition by NBAR2 requires the Application Experience license that enables the application visibility and control (AVC) feature. To check the device license, use show license feature.
Example 6-29 shows how to verify that AVC is enabled.
Example 6-29 Verifying That the AVC Feature Is Enabled
R31-Spokeshow license feature
Feature name Enforcement Evaluation Subscription Enabled RightToUse
adventerprise yes yes no yes yes
advipservices yes yes no no yes
ipbase no no no no no
avc yes yes no yes yes
broadband no no no no no
Verifying That NBAR2 Is Enabled
NBAR2 is enabled automatically when an application-based service is created. To verify that the application-based policy is attached on the correct interfaces, use the command show running-configuration. Then the NBAR statistics should show as activated with the command show platform software nbar statistics as shown in Example 6-30.
Example 6-30 Verifying That NBAR2 Is Enabled
R31-Spoke# show platform software nbar statistics | include NBAR
NBAR state is ACTIVATED
NBAR config send mode is ASYNC
NBAR config state is READY
NBAR update ID 73
NBAR batch ID ACK 73
NBAR max protocol ID ever 1933
NBAR Control-Plane Version: 26
Verifying the Active NBAR2 Protocol Pack
For best classification results, verify that the latest NBAR2 Protocol Pack is activated on the system. NBAR2 activates Protocol Packs only if they match the NBAR2 engine software version.
Example 6-31 shows how to check the NBAR2 active Protocol Pack and the NBAR2 engine software version. In the example, the NBAR2 engine on the system is version 26, which matches the version required by the Protocol Pack.
Example 6-31 Verifying the Active NBAR2 Protocol Pack and Software Engine
R31-Spoke# show ip nbar protocol-pack active
Active Protocol Pack:
Name: Advanced Protocol Pack
Version: 20.0
Publisher: Cisco Systems Inc.
NBAR Engine Version: 26
State: Active
R31-Spoke# show ip nbar version
NBAR software version: 26
NBAR minimum backward compatible version: 25
Loaded Protocol Pack(s):
Name: Advanced Protocol Pack
Version: 20.0
Publisher: Cisco Systems Inc.
NBAR Engine Version: 26
State: Active
Checking That Policies Are Applied Correctly
To match a given type of traffic, verify that the policy includes all relevant applications. It is recommended to use NBAR2 attributes as much as possible to simplify the configuration and allow dynamically created applications to better fit the policy. For example, to match Microsoft cloud applications, use the application group attribute ms-cloud-group, which provisions several related applications as shown in Example 6-32.
For QoS policies, it is recommended to use the NBAR2 traffic-class attribute.
Verify that control and data protocols or DNS requests related to a given application are treated properly.
Example 6-32 Use of Application Attributes
R31-Spoke# show ip nbar attribute application-group ms-cloud-group
ms-live-accounts Windows Live Services Authentication
ms-office-365 Microsoft Office 365
ms-office-web-apps Web-based versions of Microsoft Word, Excel,
PowerPoint and OneNote
ms-services Microsoft Services
outlook-web-service Microsoft Web-Based email services under Outlook brand,
part of Off
skydrive SkyDrive Cloud Storage Server From Microsoft
Reading Protocol Discovery Statistics
Protocol discovery can be used to view the amount of traffic running through each interface, per application. Use protocol discovery to discover the applications, and to verify that the application-based policies are handling the applications correctly.
Refer to the “NBAR2 Protocol Discovery” section for details on how to enable and show protocol discovery statistics.
Granular Traffic Statistics
A NetFlow per-flow policy can be enabled on specific traffic to view granular per-flow statistics. Refer to Chapter 10, “Application Visibility,” for details on how to define NetFlow monitors that contain higher-granularity information. The section “View Raw Data Directly on the Router” explains how to define a monitor that shows raw data on the router without exporting it to an external collector.
Using granular per-flow data can help in verifying that traffic is symmetric and that both directions of the traffic are running through the NBAR2-enabled interfaces.
Discovering Generic and Unknown Traffic
NBAR2 provides the capability to list Layer 7 information of generic HTTP or SSL traffic, using the host name in the HTTP header or the SSL certificate. It can also display the most commonly occurring sockets or ports (top sockets, top ports) for unclassified (unknown) traffic.
Refer to the “Auto-learn Traffic Analysis Engine” section in this chapter for further information on how to view auto-learn results for generic and unknown traffic, and how to customize protocols using the results.
Verifying the Number of Flows
NBAR2 relies on a flow table to track states for each flow. To verify that the number of flows has not reached the maximum allowed, use the command show ip nbar resources flow.
Example 6-33 shows how to use the command. Verify that the peak and active sessions and memory have not exceeded the maximum allowed values.
Example 6-33 Checking NBAR2 Flow Usage
R31-Spoke# show ip nbar resources flow
NBAR flow statistics
Maximum no of sessions allowed : 5000000
Maximum memory usage allowed : 2936012 KBytes
Active sessions : 44
Active memory usage : 10523 KBytes
Peak session : 1816
Peak memory usage : 11169 Kbytes
Summary
Network engineers must understand the network traffic that flows across their devices to provide an optimal user experience. More and more applications are sharing network protocols (for example, HTTP) or encrypting the network traffic, making it more difficult to classify the applications that are being used. NBAR2 provides the best available tools and techniques for classifying network applications and provides a wide-ranging set of attributes that are useful for defining and visualizing the network policies.
This chapter provided network engineers with numerous techniques to use when deploying NBAR2 in order to provide application visibility for proper application-based deployment of QoS or Performance Routing policies.
Further Reading
Cisco. Cisco IOS Software Configuration Guides. www.cisco.com.
Cisco. “NBAR2 Protocol Library.” www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_nbar/prot_lib/config_library/nbar-prot-pack-library.html.
Claise, B, P. Aitken, and N. Ben-Dvora. RFC 6759, “Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX).” IETF, November 2012. https://tools.ietf.org/html/rfc6759.