Classifying Network Traffic Using NBAR

Network-Based Application Recognition (NBAR) is a classification engine that recognizes and classifies a wide variety of protocols and applications. When NBAR recognizes and classifies a protocol or application, the network can be configured to apply the appropriate quality of service (QoS) for that application or traffic with that protocol.

This module contains overview information about classifying network traffic in NBAR. The processes for configuring NBAR are documented in separate modules.


Note

This module includes information for both NBAR and Distributed Network-Based Application Recognition (dNBAR). dNBAR is NBAR used on the Cisco 7500 router with a Versatile Interface Processor (VIP) and on the Catalyst 6500 family of switches with a FlexWAN module or serial interface processor (SIP). The implementation of NBAR and dNBAR is identical. Therefore, unless otherwise noted, the term NBAR is used throughout this module to describe both NBAR and dNBAR. The term dNBAR is used only when applicable.

Prerequisites for Using NBAR

Cisco Express Forwarding

Before you configure NBAR, you must enable Cisco Express Forwarding.


Note

This prerequisite does not apply if you are using Cisco IOS Release 12.2(18)ZYA.

Stateful Switchover Support

NBAR is not supported with stateful switchover (SSO). This restriction applies to the Catalyst 6500 switches and to the Cisco 7500 and Cisco 7600 series routers.

Memory Requirements for dNBAR

To use dNBAR on a Cisco 7500 series router, you must be using a slot controller (or VIP processor) that has at least 64 MB of DRAM. Therefore, before configuring dNBAR on your Cisco 7500 series router, review the DRAM specifications for your particular slot controller or VIP processor.

Restrictions for Using NBAR

NBAR does not support the following:

  • More than 24 concurrent URLs, hosts, or Multipurpose Internet Mail Extension (MIME) type matches.


Note

For Cisco IOS Release 12.2(18)ZYA and Cisco IOS Release 15.1(2)T, the maximum number of concurrent URLs, hosts, or MIME type matches is 56.

  • Matching beyond the first 400 bytes in a packet payload in Cisco IOS releases before Cisco IOS Release 12.3(7)T. In Cisco IOS Release 12.3(7)T, this restriction was removed, and NBAR now supports full payload inspection. The only exception is that NBAR can inspect custom protocol traffic for only 255 bytes into the payload.

  • Non-IP traffic.

  • Multiprotocol Label Switching (MPLS)-labeled packets. NBAR classifies IP packets only. You can, however, use NBAR to classify IP traffic before the traffic is handed over to MPLS. Use the modular quality of service (QoS) CLI (MQC) to set the IP differentiated services code point (DSCP) field on the NBAR-classified packets and make MPLS map the DSCP setting to the MPLS experimental (EXP) setting inside the MPLS header.

  • Multicast and other non-Cisco Express Forwarding switching modes.

  • Fragmented packets.

  • Pipelined persistent HTTP requests.

  • URL/host/MIME classification with secure HTTP.

  • Asymmetric flows with stateful protocols.

  • Packets that originate from or that are destined to the router running NBAR.

NBAR is not supported on the following logical interfaces:

  • Fast Etherchannels


Note

Fast Etherchannels are supported in Cisco IOS Release 12.2(18)ZYA.

  • Dialer interfaces until Cisco IOS Release 12.2(4)T

  • Interfaces where tunneling or encryption is used


Note

You cannot use NBAR to classify output traffic on a WAN link where tunneling or encryption is used. Therefore, you should configure NBAR on other interfaces of the router (such as a LAN link) to perform input classification before the traffic is switched to the WAN link.


Note

A Network Address Translation (NAT)-enabled Cisco device may experience an increase in CPU usage when upgrading the software from a previous release. Real Time Streaming Protocol (RTSP) and Media Gateway Control Protocol (MGCP) NAT Application Layer Gateway (ALG) support was added in Cisco IOS Release 12.3(7)T, which requires NBAR. Use the no ip nat service nbar command to disable NBAR processing, which can decrease the CPU utilization rate.


Warning

If the no ip nat service nbar command is not specified during the startup of the router, results in the crashing of the router, when loading the configuration from the TFTP during the booting process.

Layer 2 NBAR Restrictions

The phrase "Layer 2 NBAR" refers to NBAR functionality used with Layer 2 interfaces (such as switchports, trunks, or Etherchannels).

Layer 2 NBAR functionality can be used with service modules such as a Firewall Service Module (FWSM) and an Intrusion Detection Service Module (IDSM) with the following restriction: Layer 2 NBAR is not supported on Layer 2 interfaces that are configured as part of a service module (such as FWSM and IDSM) when those service modules are configured in inline mode (that is, network traffic is in a direct path through the service module).


Note

This restriction does not apply to NBAR functionality that is used with Layer 3 interfaces.

However, Layer 2 NBAR is supported in noninline mode with service modules even when Switched Port Analyzer (SPAN), Remote SPAN (RSPAN), or VLAN Access Control List (VACL) Capture functionality is used to send traffic to a service module.

For more information about the FWSM and its connection features, see the "Configuring Advanced Connection Features" module of the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide.

For more information about the IDSM, see the "Configuring IDSM-2" module of the Configuring the Cisco Intrusion Prevention System Sensor Using the Command Line Interface.

For more information about SPAN or RSPAN, see the "Configuring SPAN and RSPAN" module of the Catalyst 6500 Series Software Configuration Guide .

For more information about VACL Capture, see the "VACL Capture for Granular Traffic Analysis with Cisco Catalyst 6000/6500 Running Cisco IOS Software" module.

Information About Classifying Network Traffic Using NBAR

NBAR Functionality

NBAR is a classification engine that recognizes and classifies a wide variety of protocols and applications, including web-based and other difficult-to-classify applications and protocols that use dynamic TCP/UDP port assignments.

When NBAR recognizes and classifies a protocol or application, the network can be configured to apply the appropriate QoS for that application or traffic with that protocol. The QoS is applied using the modular quality of service CLI (MQC).


Note

For more information about NBAR and its relationship with the MQC, see the "Configuring NBAR Using the MQC" module.

Examples of the QoS features that can be applied to the network traffic (using the MQC) after NBAR has recognized and classified the application or protocol include the following:

  • Class-Based Marking

  • Class-Based Weighted Fair Queuing (CBWFQ)

  • Low Latency Queuing (LLQ)

  • Traffic Policing

  • Traffic Shaping


Note

For Cisco IOS Release 12.2(18)ZYA on the Catalyst 6500 series switch (that is equipped with a Supervisor 32/programmable intelligent services accelerator [PISA]), only the following QoS features can be configured. These features can be configured (using the MQC) after NBAR has recognized and classified the application or protocol.

  • Traffic Classification

  • Traffic Marking

  • Traffic Policing


Note

For more information about the QoS features, see the "Quality of Service Overview" module. For more information about the Catalyst 6500 series switch and QoS, see the "Configuring QoS" module of the Catalyst 6500 Series Software Configuration Guide.

NBAR introduces several classification features that identify applications and protocols from Layer 4 through Layer 7. These classification features are as follows:

  • Statically assigned TCP and UDP port numbers.

  • Non-TCP and non-UDP IP protocols.

  • Dynamically assigned TCP and UDP port numbers. This kind of classification requires stateful inspection; that is, the ability to inspect a protocol across multiple packets during packet classification.

  • Subport classification or classification based on deep-packet inspection.

Deep-packet classification is classification performed at a finer level of granularity. For instance, if a packet is already classified as HTTP traffic, it may be further classified by HTTP traffic with a specific URL.


Note

Access Control Lists (ACLs) can also be used for classifying static port protocols. However, NBAR is easier to configure and can provide classification statistics that are not available when ACLs are used.

NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are operating on an interface. For more information about Protocol Discovery, see the "Enabling Protocol Discovery" module.


Note

NBAR classifies network traffic by application or protocol. Network traffic can be classified without using NBAR. For information about classifying network traffic without using NBAR, see the "Classifying Network Traffic" module.

NBAR Benefits

Identifying and classifying network traffic is an important first step in implementing QoS. A network administrator can more effectively implement QoS in a networking environment after identifying the number and types of applications and protocols that are running on a network.

NBAR gives network administrators the ability to see the different types of protocols and the amount of traffic generated by each protocol. After NBAR gathers this information, users can organize traffic into classes. These classes can then be used to provide different levels of service for network traffic, thereby allowing better network management by providing the appropriate level of the network resources for network traffic.

NBAR and Classification of HTTP Traffic

Classification of HTTP Traffic by URL Host or MIME

NBAR can classify application traffic by looking beyond the TCP/UDP port numbers of a packet. This is subport classification. NBAR looks into the TCP/UDP payload itself and classifies packets based on content within the payload such as that transaction identifier, message type, or other similar data.

Classification of HTTP traffic by URL, host, or Multipurpose Internet Mail Extension (MIME) type is an example of subport classification. NBAR classifies HTTP traffic by text within the URL or host fields of a request using regular expression matching. HTTP client request matching in NBAR supports most HTTP request methods such as GET, PUT, HEAD, POST, DELETE, OPTIONS, CONNECT, and TRACE. The NBAR engine then converts the specified match string into a regular expression.

The figure below illustrates a network topology with NBAR in which Router Y is the NBAR-enabled router.

When specifying a URL for classification, include only the portion of the URL that follows the www.hostname .domain in the match statement. For example, for the URL www.cisco.com/latest/whatsnew.html, include only /latest/whatsnew.html with the match statement (for instance, match protocol http url /latest/whatsnew.html ).


Note

For Cisco IOS Release 12.2(18)ZY2 and later releases on the Cisco Catalyst 6500 series switch that is equipped with a Supervisor 32/PISA, and for Cisco IOS Release 15.1(2)T and later releases, up to 56 parameters or subclassifications per protocol per router can be specified with the match protocol http command. These parameters or subclassifications can be a combination of any of the available match choices, such as host matches, MIME matches, server matches, and URL matches. For other Cisco IOS releases and platforms, the maximum is 24 parameters or subclassifications per protocol per router.

Host specifications are identical to URL specifications. NBAR performs a regular expression match on the host field contents inside an HTTP packet and classifies all packets from that host. For example, for the URL www.cisco.com/latest/whatsnew.html, include only www.cisco.com.

For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA) supported MIME types can be found at the following URL:

http://www.iana.org/assignments/media-types/

When matching by MIME type, NBAR matches a packet containing the MIME type and all subsequent packets until the next HTTP transaction.

NBAR supports URL and host classification in the presence of persistent HTTP. NBAR does not classify packets that are part of a pipelined request. With pipelined requests, multiple requests are pipelined to the server before previous requests are serviced. Pipelined requests are a less commonly used type of persistent HTTP request.

In Cisco IOS Release 12.3(4)T, the NBAR Extended Inspection for HTTP Traffic feature was introduced. This feature allows NBAR to scan TCP ports that are not well known and to identify HTTP traffic that traverses these ports. HTTP traffic classification is no longer limited to the well known and defined TCP ports.

Classification of HTTP Traffic Using HTTP Header Fields

In Cisco IOS Release 12.3(11)T, NBAR introduced expanded ability for users to classify HTTP traffic using information in the HTTP header fields.

HTTP works using a client/server model. HTTP clients open connections by sending a request message to an HTTP server. The HTTP server then returns a response message to the HTTP client (this response message is typically the resource requested in the request message from the HTTP client). After delivering the response, the HTTP server closes the connection and the transaction is complete.

HTTP header fields are used to provide information about HTTP request and response messages. HTTP has numerous header fields. For additional information on HTTP headers, see section 14 of RFC 2616: Hypertext Transfer Protocol--HTTP/1.1. This RFC can be found at the following URL:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

NBAR can classify the following HTTP header fields:

  • For request messages (client to server), the following HTTP header fields can be identified using NBAR:
    • User-Agent
    • Referer
    • From
  • For response messages (server to client), the following HTTP header fields can be identified using NBAR:
    • Server
    • Location
    • Content-Encoding
    • Content-Base

Note

Use of the Content-Base field has not been implemented by the HTTP community. (See RFC 2616 for details.) Therefore, the Content-Base field is not identified by NBAR on the Catalyst 6500 series switch that is equipped with a Supervisor 32/PISA.

Within NBAR, the match protocol http c-header-field command is used to specify that NBAR identify request messages (the "c" in the c-header-field portion of the command is for client). The match protocol http s-header-field command is used to specify response messages (the "s" in the s-header-field portion of the command is for server).


Note

For Cisco IOS Release 12.2(18)ZY2 and later releases on the Cisco Catalyst 6500 series switch that is equipped with a Supervisor 32/PISA, and for Cisco IOS Release 15.1(2)T and later releases, the c-header-field and s-header-field keywords and associated arguments in the match protocol http command are not available. The same functionality is achieved by using the individual keywords and arguments. For more information, see the syntax of the match protocol http command in the Cisco IOS Quality of Service Solutions Command Reference.


Note

The c-header-field performs subclassification based on a single value in the user agent, referrer, or from header field values and the s-header-field performs subclassification based on a single value that in the server, location, content-encoding, or content-base header field values. These header field values are not related to each other. Hence the c-header and s-header fields are replaced by user-agent, referrer, from, server, content-base, content-encoding, and location parameters as per the intent and need of HTTP subclassification.

Combinations of Classification of HTTP Headers and URL Host or MIME Type to Identify HTTP Traffic

Note that combinations of URL, Host, MIME type, and HTTP headers can be used during NBAR configuration. These combinations provide customers with more flexibility to classify specific HTTP traffic based on their network requirements.

NBAR and Classification of Citrix ICA Traffic

NBAR can classify Citrix Independent Computing Architecture (ICA) traffic and perform subport classification of Citrix traffic based on the published application name or ICA tag number.

Classification of Citrix ICA Traffic by Published Application Name

NBAR can monitor Citrix ICA client requests for a published application destined to a Citrix ICA Master browser. After the client requests the published application, the Citrix ICA Master browser directs the client to the server with the most available memory. The Citrix ICA client then connects to this Citrix ICA server for the application.


Note

For Citrix to monitor and classify traffic by the published application name, Server Browser Mode on the Master browser must be used.

In Server Browser Mode, NBAR statefully tracks and monitors traffic and performs a regular expression search on the packet contents for the published application name specified by the match protocol citrix command. The published application name is specified by using the app keyword and the application-name-string argument of the match protocol citrix command. For more information about the match protocol citrix command, see the Cisco IOS Quality of Service Solutions Command Reference.

The Citrix ICA session triggered to carry the specified application is cached, and traffic is classified appropriately for the published application name.

Citrix ICA Client Modes

Citrix ICA clients can be configured in various modes. NBAR cannot distinguish among Citrix applications in all modes of operation. Therefore, network administrators might need to collaborate with Citrix administrators to ensure that NBAR properly classifies Citrix traffic.

A Citrix administrator can configure Citrix to publish Citrix applications individually or as the entire desktop. In the Published Desktop mode of operation, all applications within the published desktop of a client use the same TCP session. Therefore, differentiation among applications is impossible, and NBAR can be used to classify Citrix applications only as aggregates (by looking at port 1494).

The Published Application mode for Citrix ICA clients is recommended when you use NBAR. In Published Application mode, a Citrix administrator can configure a Citrix client in either seamless or nonseamless (windows) modes of operation. In nonseamless mode, each Citrix application uses a separate TCP connection, and NBAR can be used to provide interapplication differentiation based on the name of the published application.

Seamless mode clients can operate in one of two submodes: session sharing or nonsession sharing. In seamless session sharing mode, all clients share the same TCP connection, and NBAR cannot differentiate among applications. Seamless sharing mode is enabled by default in some software releases. In seamless nonsession sharing mode, each application for each particular client uses a separate TCP connection. NBAR can provide interapplication differentiation in seamless nonsession sharing mode.


Note

NBAR operates properly in Citrix ICA secure mode. Pipelined Citrix ICA client requests are not supported.

Classification of Citrix ICA Traffic by ICA Tag Number

Citrix uses one TCP session each time an application is opened. In the TCP session, a variety of Citrix traffic may be intermingled in the same session. For example, print traffic may be intermingled with interactive traffic, causing interruption and delay for a particular application. Most users likely would prefer that printing be handled as a background process and that printing not interfere with the processing of higher-priority traffic.

To accommodate this preference, the Citrix ICA protocol includes the ability to identify Citrix ICA traffic based on the ICA tag number of the packet. The ability to identify, tag, and prioritize Citrix ICA traffic is referred to as ICA Priority Packet Tagging. With ICA Priority Packet Tagging, Citrix ICA traffic is categorized as high, medium, low, and background, depending on the ICA tag of the packet.

When ICA traffic priority tag numbers are used, and the priority of the traffic is determined, QoS features can be implemented to determine how the traffic will be handled. For example, QoS traffic policing can be configured to transmit or drop packets with a specific priority.

Citrix ICA Packet Tagging

The Citrix ICA tag is included in the first two bytes of the Citrix ICA packet, after the initial negotiations are completed between Citrix client and server. These bytes are not compressed or encrypted.

The first two bytes of the packet (byte 1 and byte 2) contain the byte count and the ICA priority tag number. Byte 1 contains the low-order byte count, and the first two bits of byte 2 contain the priority tags. The other six bits contain the high-order byte count.

The ICA priority tag value can be a number from 0 to 3. The number indicates the packet priority, with 0 being the highest priority and 3 being the lowest priority.

To prioritize Citrix traffic by the ICA tag number of the packet, you specify the tag number using the ica-tag keyword and the ica-tag-value argument of the match protocol citrix command. For more information about the match protocol citrix command, see the Cisco IOS Quality of Service Solutions Command Reference.

NBAR and RTP Payload Type Classification

RTP is a packet format for multimedia data streams. It can be used for media-on-demand and for interactive services such as Internet telephony. RTP consists of a data and a control part. The control part is called Real-Time Transport Control Protocol (RTCP). RTCP is a separate protocol that is supported by NBAR. It is important to note that the NBAR RTP Payload Type Classification feature does not identify RTCP packets and that RTCP packets run on odd-numbered ports while RTP packets run on even-numbered ports.

The data part of RTP is a thin protocol that provides support for applications with real-time properties such as continuous media (audio and video), which includes timing reconstruction, loss detection, and security and content identification. RTP is discussed in RFC 1889 (A Transport Protocol for Real-Time Applications ) and RFC 1890 (RTP Profile for Audio and Video Conferences with Minimal Control ).

The RTP payload type is the data transported by RTP in a packet, for example, audio samples or compressed video data.

The RTP payload classification takes place in the persistent mode, wherein a fully qualified RTP session NBAR does the payload sub-classification. For example, RFC 2833 requires persistent processing for RTP payload sub-clasification within a classified flow.

The NBAR RTP Payload Type Classification feature not only allows real-time audio and video traffic to be statefully identified, but can also differentiate on the basis of audio and video codecs to provide more granular QoS. The RTP Payload Type Classification feature, therefore, looks deep into the RTP header to classify RTP packets.

NBAR and Classification of Custom Protocols and Applications

NBAR supports the use of custom protocols to identify custom applications. Custom protocols support static port-based protocols and applications that NBAR does not currently support. You can add to the set of protocols and application types that NBAR recognizes by creating custom protocols.

Custom protocols extend the capability of NBAR Protocol Discovery to classify and monitor additional static port applications and allows NBAR to classify nonsupported static port traffic.


Note

For more information about specifying user-defined (custom) protocols, see the "Creating a Custom Protocol" module.

NBAR and Classification of Peer-to-Peer File-Sharing Applications

The following are the most common peer-to-peer file-sharing applications supported by NBAR:

  • BitTorrent

  • DirectConnect

  • eDonkey

  • eMule

  • FastTrack

  • Grokster

  • JTella

  • Kazaa (as well as Kazaa Lite and Kazaa Lite Resurrection)

  • Morpheus

  • Win MX

Gnutella Also Supported

The Gnutella file-sharing protocol became classifiable using NBAR in Cisco IOS Release 12.1(12c)E.

Applications that use the Gnutella protocol include Bearshare, Gnewtellium, Gnucleus, Gtk-Gnutella, Limewire, Mutella, Phex, Qtella, Swapper, and Xolo.

NBAR and Classification of Streaming Protocols

In Cisco IOS Release 12.3(7)T, NBAR introduced support for Real Time Streaming Protocol (RTSP). RTSP is the protocol used for applications with steaming audio, such as the following:

  • Apple QuickTime

  • RealAudio (RealSystems G2)

  • Windows Media Services

NBAR and AutoQoS

In the earlier Cisco IOS releases the two features that allows to automate the deployment of QoS on your network: AutoQoS--Voice over IP (VoIP), and AutoQoS for the Enterprise. Both of these AutoQoS features take advantage of the traffic classification functionality of NBAR.


Note

Cisco IOS Release 12.2(18)ZY (and later releases) does not support the AutoQoS--Voice over IP (VoIP) feature on the Catalyst 6500 series switch.

AutoQoS--VoIP

This feature was available with Cisco IOS Release 12.2(15)T. The AutoQoS--VoIP feature allows you to automate the deployment of QoS on your network and provides a means for simplifying the implementation and provisioning of QoS for VoIP traffic. For more information about the AutoQoS--VoIP feature and how it uses NBAR, see the "AutoQoS--VoIP" module.

AutoQoS for the Enterprise

This feature was available with Cisco IOS Release 12.3(11)T. The AutoQoS for the Enterprise feature allows you to automate the deployment of QoS in a general business environment, particularly for midsize companies and branch offices of larger companies. It expands on the functionality available with the AutoQoS--VoIP feature. For more information about the AutoQoS for the Enterprise feature and how it uses NBAR, see the "AutoQoS for the Enterprise" module.

NBAR and FWSM Integration

With Cisco IOS Release 12.2(18)ZYA, the functionality of NBAR to recognize protocols and applications was integrated with the Firewall Service Module (FWSM) on the Catalyst 6500 series switch. Available with this release were the following commands that can be used for classifying and tagging traffic to the FWSM:

  • ip nbar protocol-tagging

  • show ip nbar protocol-tagging

For more information about the FWSM and its connection features, see the "Configuring Advanced Connection Features" module of the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide.

For more information about FWSM commands (including the two commands listed), see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Service Module Command Reference Guide.

NBAR and TelePresence PDLM

Cisco IOS Release 12.2(18)ZYA2 NBAR introduced support for the Cisco TelePresence PDLM.

Cisco TelePresence integrates advanced audio, high-definition video, and interactive elements to deliver an great meeting experience.

The Telepresence PDLM uses NBAR to identify TelePresence media and TelePresence control traffic over the network. TelePresence media traffic and TelePresence control traffic are treated differently by QoS and so must be classified separately. TelePresence media traffic must have a low latency. TelePresence control traffic does not require a low latency but should not be dropped.

NBAR-Supported Protocols

The match protocol (NBAR) command is used to classify traffic on the basis of protocols supported by NBAR. NBAR can classify the following types of protocols:

  • Non-UDP and non-TCP IP protocols

  • TCP and UDP protocols that use statically assigned port numbers

  • TCP and UDP protocols that use statically assigned port numbers but still require stateful inspection

  • TCP and UDP protocols that dynamically assign port numbers and therefore require stateful inspection

Many peer-to-peer file-sharing applications can be classified using FastTrack or Gnutella. See the NBAR and Classification of Peer-to-Peer File-Sharing Applications for additional information.

RTSP can be used to classify various types of applications that use streaming audio. See NBAR and Classification of Streaming Protocols for additional information.

The NBAR Protocol Pack provides an easy way to update protocols supported by NBAR without replacing the base IOS image that is already present in the device. A protocol pack is a set of protocols developed and packed together. For more information about loading an NBAR protocol pack, see the NBAR Protocol Pack module. To view the list of protocols supported in a protocol pack, see NBAR Protocol Library.

NBAR Memory Management

NBAR uses approximately 150 bytes of DRAM for each traffic flow that requires stateful inspection. (See NBAR Memory Management for a list of protocols supported by NBAR that require stateful inspection.)

When NBAR is configured, it allocates 1 MB of DRAM to support up to 5000 concurrent traffic flows. NBAR checks to see if more memory is required to handle additional concurrent stateful traffic flows. If such a need is detected, NBAR expands its memory usage in increments of 200 to 400 Kb.


Note

This expansion of memory by NBAR does not apply if a PISA is in use.

NBAR Protocol Discovery

NBAR includes a feature called Protocol Discovery. Protocol discovery provides an easy way to discover the application protocols that are operating on an interface. For more information about protocol discovery, see the "Enabling Protocol Discovery" module.


Note

With Cisco IOS Release 12.2(18)ZYA, which is intended for use on the Catalyst 6500 series switch that is equipped with a Supervisor 32/PISA, Protocol Discovery supports Layer 2 Etherchannels.

Nonintrusive Protocol Discovery

Cisco IOS Release 12.2(18)ZYA1 includes the Nonintrusive Protocol Discovery feature which, enables the Catalyst 6500 series switch that is equipped with a Supervisor 32/PISA to perform protocol discovery in out-of-band (that is, offline) mode. In offline mode, a copy of the network traffic is used to discover the application protocols that are operating on an interface, leaving the network traffic undisturbed and available for other purposes.

Nonintrusive Protocol Discovery is closely associated with a feature called Intelligent Traffic Redirect (ITR). ITR allows network administrators to optimize system performance by identifying the specific traffic that needs to be redirected to the Supervisor 32/PISA for deep-packet inspection.

Nonintrusive Protocol Discovery is achieved by enabling ITR on an interface on which protocol discovery has been enabled. For more information about the commands used to enable ITR, see the Catalyst Supervisor Engine 32 PISA IOS Command Reference. For more information about protocol discovery, see the "Enabling Protocol Discovery" module.


Note

For the Nonintrusive Protocol Discovery feature to function properly, no other "intrusive" features (for example, Flexible Packet Matching [FPM]) can be in use on the interface in either the input or output direction. An intrusive feature is one that somehow manipulates the packets (such as modifying a statistic or a packet counter). If such a feature is in use, the actual traffic (and not a copy of the traffic) is redirected.

NBAR Protocol Discovery MIB

The NBAR Protocol Discovery MIB expands the capabilities of NBAR Protocol Discovery by providing the following new functionality through Simple Network Management Protocol (SNMP):

  • Enable or disable Protocol Discovery per interface.

  • Display Protocol Discovery statistics.

  • Configure and display multiple top-n tables that list protocols by bandwidth usage.

  • Configure thresholds based on traffic of particular NBAR-supported protocols or applications that report breaches and send notifications when these thresholds are crossed.

For more information about the NBAR Protocol Discovery MIB, see the "Network-Based Application Recognition Protocol Discovery Management Information Base" module.

NBAR Categorization and Attributes

The NBAR Categorization and Attributes feature provides the mechanism to match protocols or applications based on certain attributes. As there are many protocols and applications, categorizing them into different groups will help with reporting as well as performing group actions, such as applying QoS policies, on them. Attributes are statically assigned to each protocol or application, and they are not dependent on the traffic. The following attributes are available to configure the match criteria using the match protocol attribute command. They are:

  • application-group: The application-group attribute allows the configuration of applications grouped together based on the same networking application as the match criteria. For example, Yahoo-Messenger, Yahoo-VoIP-messenger, and Yahoo-VoIP-over-SIP are grouped together under the yahoo-messenger-group.
  • category: The category attribute allows you to configure applications that are grouped together based on the first level of categorization for each protocol as the match criteria. Similar applications are grouped together under one category. For example, the email category contains all email applications such as, Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), Lotus Notes, and so forth.
  • sub–category: The sub–category attribute provides the option to configure applications grouped together based on the second level of categorization for each protocol as the match criteria. For example, clearcase, dbase, rda, mysql and other database applications are grouped under the database group.
  • encrypted: The encrypted attribute provides the option to configure applications grouped together based on whether the protocol is an encrypted protocol or not as the match criteria. Applications are grouped together based on whether they are encrypted and non-encrypted status of the applications. Protocols for which the NBAR does not provide any value are categorized under the unassigned encrypted group.
  • tunnel: The tunnel attribute provides the option to configure protocols based on whether or not a protocol tunnels the traffic of other protocols. Protocols for which the NBAR does not provide any value are categorized under the unassigned tunnel group. For example, Layer 2 Tunneling Protocols (L2TP).
  • p2p-technology: The p2p(Peer-to-Peer)-technology attribute provides the option to indicate whether or not a protocol uses p2p technology.

Note

Attribute-based protocol match configuration does not impact the granularity of classification either in reporting or in the protocol discovery information.

You can create custom values for the attributes application-group, category, and sub-category. The custom values enable you to name the attributes based on grouping of protocols. Use the ip nbar attribute application-group custom application-group-name , ip nbar attribute category custom category-name , and ip nbar attribute sub-category custom sub-category-name commands to add custom values for the attributes application-group, category, and sub-category, respectively.

The dynamically created custom attribute values can be used for attribute-map creation when using the ip nbar attribute-map command, and for configuring the match criterion for a class-map when using the match protocol attribute command.

The output from the show ip nbar attribute-custom command displays the number of custom values that can be defined for attributes, and the custom values that are currently defined. The show ip nbar attribute command displays all the attributes including the custom attributes used by NBAR.

To remove the custom values, use the no ip nbar attribute command.

NBAR Configuration Processes

Configuring NBAR consists of the following processes:

  • Enabling Protocol Discovery (required)

When you configure NBAR, the first process is to enable Protocol Discovery.

  • Configuring NBAR using the MQC (optional)

After you enable Protocol Discovery, you have the option to configure NBAR using the functionality of the MQC.

  • Adding application recognition modules (also known as Packet Description Language Modules [PDLMs]) (optional)

Adding PDLMs extends the functionality of NBAR by enabling NBAR to recognize additional protocols on your network.

  • Creating custom protocols (optional)

Custom protocols extend the capability of NBAR Protocol Discovery to classify and monitor additional static port applications and allow NBAR to classify nonsupported static port traffic.

NBAR Support for GETVPN

NBAR supports Group Encrypted Transport VPN (GETVPN). When ingress QoS is in crypto-map mode, the ingress QoS will work on encrypted traffic.

You can go back to backward compatible mode by using the ip nbar disable classification encrypted-app command in global configuration mode.


Note
GETVPN is currently not supported by AVC and FNF.

Configuration Examples for Classifying Network Traffic Using NBAR

Example: Classification of HTTP Traffic Using the HTTP Header Fields

In the following example, any request message that contains "somebody@cisco.com" in the User-Agent, Referer, or From field will be classified by NBAR. Typically, a term with a format similar to "somebody@cisco.com" would be found in the From header field of the HTTP request message. 


class-map match-all class1
 match protocol http from "somebody@cisco.com"

In the following example, any request message that contains "http://www.cisco.com/routers" in the User-Agent, Referer, or From field will be classified by NBAR. Typically, a term with a format similar to "http://www.cisco.com/routers" would be found in the Referer header field of the HTTP request message. 


class-map match-all class2
 match protocol http referer "http://www.cisco.com/routers"

In the following example, any request message that contains "CERN-LineMode/2.15" in the User-Agent, Referer, or From header field will be classified by NBAR. Typically, a term with a format similar to "CERN-LineMode/2.15" would be found in the User-Agent header field of the HTTP request message. 


class-map match-all class3
 match protocol http user-agent "CERN-LineMode/2.15"

In the following example, any response message that contains "CERN/3.0" in the Content-Base (if available), Content-Encoding, Location, or Server header field will be classified by NBAR. Typically, a term with a format similar to "CERN/3.0" would be found in the Server header field of the response message. 


class-map match-all class4
 match protocol http server "CERN/3.0"

In the following example, any response message that contains "http://www.cisco.com/routers" in the Content-Base (if available), Content-Encoding, Location, or Server header field will be classified by NBAR. Typically, a term with a format similar to "http://www.cisco.com/routers" would be found in the Content-Base (if available) or Location header field of the response message. 


class-map match-all class5
 match protocol http location "http://www.cisco.com/routers"

In the following example, any response message that contains "gzip" in the Content-Base (if available), Content-Encoding, Location, or Server header field will be classified by NBAR. Typically, the term "gzip" would be found in the Content-Encoding header field of the response message. 


class-map match-all class6
 match protocol http content-encoding "gzip"

Example: Combinations of Classification of HTTP Headers and URL Host or MIME Type to Identify HTTP Traffic

In the following example, HTTP header fields are combined with a URL to classify traffic. In this example, traffic with a User-Agent field of “CERN-LineMode/3.0” and a Server field of “CERN/3.0”, along with host name “cisco.com” and URL “/routers”, are classified using NBAR: 


Device(config)# class-map match-all c-http
Device(config-cmap)# match protocol http user-agent “CERN-LineMode/3.0”
Device(config-cmap)# match protocol http server "CERN/3.0"
Device(config-cmap)# match protocol http host cisco* 
Device(config-cmap)# match protocol http url /routers

Example NBAR and Classification of Peer-to-Peer File-Sharing Applications

The matchprotocolgnutellafile-transfer regular-expression and matchprotocolfasttrackfile-transfer regular-expression commands are used to enable Gnutella and FastTrack classification in a traffic class. The file-transfer keyword indicates that a regular expression variable will be used to identify specific Gnutella or FastTrack traffic. The regular-expression variable can be expressed as "*" to indicate that all FastTrack or Gnutella traffic be classified by a traffic class.

In the following example, all FastTrack traffic is classified into class map nbar: 


class-map match-all nbar
 match protocol fasttrack file-transfer "*"

Similarly, all Gnutella traffic is classified into class map nbar in the following example: 


class-map match-all nbar
 match protocol gnutella file-transfer "*"

Wildcard characters in a regular expression can also be used to identify specified Gnutella and FastTrack traffic. These regular expression matches can be used to match on the basis of a filename extension or a particular string in a filename.

In the following example, all Gnutella files that have the .mpeg extension will be classified into class map nbar. 


class-map match-all nbar
 match protocol gnutella file-transfer "*.mpeg"

In the following example, only Gnutella traffic that contains the characters "cisco" is classified: 


class-map match-all nbar
 match protocol gnutella file-transfer "*cisco*"

The following commands can be used for FastTrack traffic: 


class-map match-all nbar
 match protocol fasttrack file-transfer "*.mpeg"

or 


class-map match-all nbar
 match protocol fasttrack file-transfer "*cisco*"

Example: NBAR and Classification of Custom Protocols and Applications

In the following example, the custom protocol app-sales1 will identify TCP packets that have a source port of 4567 and that contain the term "SALES" in the first payload packet: 


Router(config)# ip nbar custom app-sales1 5 ascii SALES source tcp 4567

In the following example, the custom protocol virus-home will identify UDP packets that have a destination port of 3000 and that contain "0x56" in the seventh byte of the first packet of the flow: 


Router(config)# ip nbar custom virus-home 7 hex 0x56 destination udp 3000

In the following example, the custom protocol media_new will identify TCP packets that have a destination or source port of 4500 and that have a value of 90 at the sixth byte of the payload. Only the first packet of the flow is checked for the value 90 at the offset 6. 


Router(config)# ip nbar custom media_new 6 decimal 90 tcp 4500

In the following example, the custom protocol msn1 will look for TCP packets that have a destination or source port of 6700: 


Router(config)# ip nbar custom msn1 tcp 6700

In the following example, the custom protocol mail_x will look for UDP packets that have a destination port of 8202: 


Router(config)# ip nbar custom mail_x destination udp 8202

In the following example, the custom protocol mail_y will look for UDP packets that have destination ports between 3000 and 4000 inclusive: 


Router(config)# ip nbar custom mail_y destination udp range 3000 4000

Example: Configuring Attribute-Based Protocol Match

The match protocol attributes command is used to configure different attributes as the match criteria for application recognition.

In the following example, the email-related applications category is configured as the match criterion: 

Router# configure terminal
Router(config)# class-map mygroup
Router(config-cmap)# match protocol attribute category email

In the following example, skype-group applications are configured as the match criterion: 

Router# configure terminal
Router(config)# class-map apps
Router(config-cmap)# match protocol attribute application-group skype-group

In the following example, encrypted applications are configured as the match criterion: 

Router# configure terminal
Router(config)# class-map my-class
Router(config-cmap)# match protocol encrypted encrypted-yes

In the following example, Client-server sub-category applications are configured as the match criterion: 

Router# configure terminal
RRouter(config)# class-map newmap
Router(config-cmap)# match protocol attribute sub-category client-server

In the following example, tunneled applications are configured as the match criterion: 

Router# configure terminal
Router(config)# class-map mygroup
Router(config-cmap)# match protocol attribute tunnel tunnel-yes

The following sample output from the show ip nbar attribute command displays the details of all the attributes: 

Router# show ip nbar attribute 
      Name :  category
      Help :  category attribute
      Type :  group
    Groups :  email, newsgroup, location-based-services, instant-messaging, netg
      Need :  Mandatory
   Default :  other

      Name :  sub-category
      Help :  sub-category attribute
      Type :  group
    Groups :  routing-protocol, terminal, epayement, remote-access-terminal, nen
      Need :  Mandatory
   Default :  other

      Name :  application-group
      Help :  application-group attribute
      Type :  group
    Groups :  skype-group, wap-group, pop3-group, kerberos-group, tftp-group, bp
      Need :  Mandatory
   Default :  other

      Name :  tunnel
      Help :  Tunnelled applications
      Type :  group
    Groups :  tunnel-no, tunnel-yes, tunnel-unassigned
      Need :  Mandatory
   Default :  tunnel-unassigned

      Name :  encrypted
      Help :  Encrypted applications
      Type :  group
    Groups :  encrypted-yes, encrypted-no, encrypted-unassigned
      Need :  Mandatory
   Default :  encrypted-unassigned

The following sample output from the show ip nbar protocol-attribute command displays the details of the protocols: 

Router# show ip nbar protocol-attribute 

           Protocol Name :  ftp
                category :  file-sharing
            sub-category :  client-server
       application-group :  ftp-group
                  tunnel :  tunnel-no
               encrypted :  encrypted-no

           Protocol Name :  http
                category :  browsing
            sub-category :  other
       application-group :  other
                  tunnel :  tunnel-no
               encrypted :  encrypted-no

           Protocol Name :  egp
                category :  net-admin
            sub-category :  routing-protocol
       application-group :  other
                  tunnel :  tunnel-no
               encrypted :  encrypted-no

           Protocol Name :  gre
                category :  net-admin
            sub-category :  tunneling-protocols
       application-group :  other
                  tunnel :  tunnel-yes
               encrypted :  encrypted-no
!
!
!

Example: Adding Custom Values for Attributes

The following example shows how to add custom values for the attributes application-group, category, and sub-category: 


Device> enable
Device# configure terminal
Device(config)# ip nbar attribute application-group custom Home_grown_finance_group "our finance tools network traffic"
Device(config)# ip nbar attribute category custom dc_backup_category "Data center backup traffic"
Device(config)# ip nbar attribute sub-category custom hr_sub_category "HR custom applications traffic"
Device(config)# exit

Examples: Viewing the Information About Custom Values for Attributes

The following sample output from the show ip nbar attribute-custom command displays the number of custom values that can be defined, and the custom values that are currently defined for the attributes: 


Device# show ip nbar attribute-custom

																		Name :  category
                  Help :  category attribute
   Custom Groups Limit :  1
 Custom Groups Created :  dc_backup_category

                  Name :  sub-category
                  Help :  sub-category attribute
   Custom Groups Limit :  1
 Custom Groups Created :  hr_sub_category

                  Name :  application-group
                  Help :  application-group attribute
   Custom Groups Limit :  1
 Custom Groups Created :  Home_grown_finance_group

The following sample output from the show ip nbar attribute category command displays the details about the Category attribute: 


Device# show ip nbar attribute category

						Name :  category
      Help :  category attribute
      Type :  group
    Groups :  newsgroup
           :  instant-messaging
           :  net-admin
           :  trojan
           :  email
           :  file-sharing
           :  industrial-protocols
           :  business-and-productivity-tools
           :  internet-privacy
           :  social-networking
           :  layer3-over-ip
           :  obsolete
           :  streaming
           :  location-based-services
           :  voice-and-video
           :  other
           :  gaming
           :  browsing
           :  dc_backup_category
   Need :  Mandatory
   Default :  other

Where to Go Next

Begin configuring NBAR by first enabling Protocol Discovery. To enable Protocol Discovery, see the "Enabling Protocol Discovery" module.

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco IOS Quality of Service Solutions Command Reference

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for Classifying Network Traffic Using NBAR

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature Information for Classifying Network Traffic Using NBAR

Feature Name

Releases

Feature Information

Additional PDL Support for NBAR

15.1(2)T

The Additional PDL Support for NBAR feature provides addtional PDLs as part of feature parity between Cisco IOS Release 12.2(18)ZY and Cisco IOS Release 15.1(2)T.

The following section includes information about this PDL support extended to Cisco IOS Release 15.1(2)T: NBAR-Supported Protocols.

Distributed Network-based Application Recognition (dNBAR)

12.1(6)E

12.2(4)T

12.2(18)SXF

dNBAR is NBAR used on the Cisco 7500 router with a VIP and on the Catalyst 6500 family of switches with a FlexWAN module or SIP. The implementation of NBAR and dNBAR is identical.

The following section provides information about this feature: Information About Classifying Network Traffic Using NBAR.

Enhanced NBAR

15.2(1)T

The Enhanced NBAR feature provides support for additional protocols.

The following section includes information about htis feature: NBAR-Supported Protocols.

nBAR: IANA Protocol Extensions Pack1

15.1(3)T

The nBAR: IANA Protocol Extensions Pack1 feature allows NBAR to detect and classify a set of protocols and applications standardized by IANA.

The following section provides information about this feature: NBAR-Supported Protocols.

NBAR Categorization and Attributes

15.2(2)T

The NBAR Categorization and Attributes feature provides the mechanism of matching the protocols grouped under specific categories based on the attributes. These categories are available for Class-Based Policy Language (CPL) as a match criteria for application recognition.

The following section provides information about this feature: NBAR Categorization and Attributes.

NBAR—Network-based Application Recognition

12.1(1)E

12.1(5)T

12.2(11)YT

12.2(18)ZY

NBAR is a classification engine that recognizes and classifies a wide variety of protocols and applications. When NBAR recognizes and classifies a protocol or application, the network can be configured to apply the appropriate QoS for that application or traffic with that protocol.

The following section provides information about this feature: Information About Classifying Network Traffic Using NBAR.

The following commands were introduced or modified: ip nbar protocol-tagging , match protocol citrix , match protocol fasttrack , match protocol gnutella , match protocol http , show ip nbar protocol-tagging .

NBAR2: Add/Rename Static Attributes

15.4(1)T

The custom values enable you to name the attributes based on grouping of protocols. You can create custom values for the attributes application-group, category, and sub-category.

The following section provides information about this feature: NBAR Categorization and Attributes.

The following commands were introduced or modified: ip nbar attribute , show ip nbar attribute-custom , and show ip nbar category .

NBAR2 GETVPN (Cryptomap) Support

15.4(2)T

GETVPN is supported.

The following section provides information about this feature: NBAR Support for GETVPN

Glossary

encryption --Encryption is the application of a specific algorithm to data so as to alter the appearance of the data, making it incomprehensible to those who are not authorized to see the information.

dNBAR --Distributed Network-Based Application Recognition. dNBAR is NBAR used on the Cisco 7500 router with a Versatile Interface Processor (VIP) and on the Catalyst 6500 family of switches with a FlexWAN module or serial interface processor (SIP). The implementation of NBAR and dNBAR is identical.

HTTP --Hypertext Transfer Protocol. The protocol used by web browsers and web servers to transfer files, such as text and graphic files.

IANA --Internet Assigned Numbers Authority. An organization operated under the auspices of the Internet Society (ISOC) as a part of the Internet Architecture Board (IAB). IANA delegates authority for IP address-space allocation and domain-name assignment to the InterNIC and other organizations. IANA also maintains a database of assigned protocol identifiers used in the TCP/IP stack, including autonomous system numbers.

LAN --local-area network. A high-speed, low-error data network that covers a relatively small geographic area (up to a few thousand meters). LANs connect workstations, peripherals, terminals, and other devices in a single building or other geographically limited area. LAN standards specify cabling and signaling at the physical and data link layers of the Open System Interconnection (OSI) model. Ethernet, FDDI, and Token Ring are widely used LAN technologies.

MIME --Multipurpose Internet Mail Extension. The standard for transmitting nontext data (or data that cannot be represented in plain ASCII code) in Internet mail, such as binary, foreign language text (such as Russian or Chinese), audio, and video data. MIME is defined in RFC 2045, Multipurpose Internet Mail Extension (MIME) Part One: Format of Internet Message Bodies .

MPLS --Multiprotocol Label Switching. A switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.

MQC --modular quality of service command-line interface. A CLI that allows you to define traffic classes, create and configure traffic policies (policy maps), and then attach policy maps to interfaces. Policy maps are used to apply the appropriate quality of service (QoS) to network traffic.

NBAR --Network-Based Application Recognition. A classification engine that recognizes and classifies a wide variety of protocols and applications. When NBAR recognizes and classifies a protocol or application, the network can be configured to apply the appropriate quality of service (QoS) for that application or traffic with that protocol.

PDLM --Packet Description Language Module. A file that contains Packet Description Language statements used to define the signature of one or more application protocols.

Protocol Discovery --A feature included with NBAR. Protocol Discovery provides a way to discover the application protocols that are operating on an interface.

QoS --quality of service. A measure of performance for a transmission system that reflects its transmission quality and service availability.

RTCP --RTP Control Protocol. A protocol that monitors the QoS of an IPv6 Real-Time Transport Protocol (RTP) connection and conveys information about the ongoing session.

RTSP --Real Time Streaming Protocol. A means for enabling the controlled delivery of real-time data, such as audio and video. Sources of data can include both live data feeds, such as live audio and video, and stored content, such as prerecorded events. RTSP is designed to work with established protocols, such as Real-Time Transport Protocol (RTP) and HTTP.

stateful protocol --A protocol that uses TCP and UDP port numbers that are determined at connection time.

static protocol --A protocol that uses well-defined (predetermined) TCP and UDP ports for communication.

subport classification --The classification of network traffic by information that is contained in the packet payload, that is, information found beyond the TCP or UDP port number.

TCP --Transmission Control Protocol. A connection-oriented transport layer protocol that provides reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.

tunneling --Tunneling is an architecture that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme.

UDP --User Datagram Protocol. A connectionless transport layer protocol in the TCP /IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768, User Datagram Protocol .

WAN --wide-area network. A data communications network that serves users across a broad geographic area and often uses transmission devices provided by common carriers.