Network-Based Application Recognition

**Feature History**
Cisco IOS Release	Modification
12.0(5)XE2	The NBAR feature was introduced. The first implementation of the NBAR feature was available on Cisco 7100 and Cisco 7200 series routers.
12.1(1)E	Subport classification of HTTP traffic by host name for NBAR was introduced. The variable-field-name value options were also added to the match protocol command.
12.1(2)E	Support for the Citrix, Novadigm, and Printer protocols for NBAR was introduced.
12.1(5)T	This feature was introduced for the Cisco IOS Release 12.1 T train. NBAR became available on Cisco 2600 and 3600 series routers.
12.1(6)E	The dNBAR feature, which introduced NBAR functionality on the Cisco 7500 series router with a VIP and the Catalyst 6000 family switch with a FlexWAN module, was introduced.
12.1(10)EC	NBAR was introduced for Cisco 7100 uBR and Cisco 7200 uBR routers.
12.1(11b)E	The match protocol rtp command was introduced on the Cisco IOS Release 12.1 E train.
12.1(12c)E	The match protocol gnutella and match protocol fasttrack commands were added because Gnutella and FastTrack became available as NBAR-supported protocols.
12.1(13)E	NBAR was released on the Catalyst 6000 family switch without a FlexWAN module.
12.2(2)T	This feature was introduced on Cisco 1700 series routers.
12.2(4)T3	The dNBAR feature introduced NBAR functionality on the Cisco IOS Release 12.2 T train. This feature was introduced for the Cisco 7500 series router with a VIP only.
12.2(8)T	The match protocol rtp command was introduced, allowing NBAR to classify Real-Time Transport Protocol (RTP) traffic. The Cisco 3700 also became available. The initial release of the Cisco 3700 supported NBAR.
12.2(14)S	NBAR and dNBAR were introduced in Cisco IOS Release 12.2 S. The 12.2 S version of NBAR includes everything available on the 12.1 E and 12.2 T implementations of NBAR with the exception of platform support for platforms not supported by 12.2 S.
12.3(4)T	NBAR PDLM Versioning was introduced. This feature introduced versioning of PDLM protocols and the show ip nbar version command. See the "IP NBAR PDLM Module Versioning" section for additional information regarding this feature. The NBAR User-Defined Custom Application Classification feature was introduced. See the "Classification of Custom Applications" section for additional information on the enhancements to the custom protocol that were introduced as part of this feature. The NBAR Extended Inspection for HTTP Traffic feature was introduced. This feature allows NBAR to scan TCP ports that are not well-known and identify HTTP traffic traversing these ports.
12.3(2)XE	NBAR was introduced on Cisco 800 series routers. To see if NBAR is supported in other platforms, see the "Supported Platforms" section of this document.
12.3(7)T	Restrictions on the number of bytes of payload that could be inspected by NBAR were removed. NBAR can now inspect the full packet payload.
12.3(8)T	NBAR was introduced on Cisco 800 series routers running Cisco IOS Release 12.3 T.

This document provides information for the Network-Based Application Recognition (NBAR) and the Distributed Network-Based Application Recognition (dNBAR) features. This document contains all of the updates made to the NBAR and dNBAR features.

Before proceeding, it is important to note that the dNBAR feature, which introduced NBAR on the Cisco 7500 with a Versatile Interface Processor (VIP) and the Catalyst 6000 family switch with a FlexWAN module, is identical in implementation to NBAR. Therefore, unless otherwise noted, the term NBAR is used throughout this document to describe both the NBAR and dNBAR feature. The term dNBAR is used only when appropriate.

This document includes information on the benefits of NBAR, supported platforms, restrictions, definitions, and new and revised command syntax.

Feature Overview

The purpose of IP Quality of Service (QoS) is to provide appropriate network resources (bandwidth, delay, jitter, and packet loss) to applications. QoS maximizes the return on investments on network infrastructure by ensuring that mission critical applications get the required performance and noncritical applications do not hamper the performance of critical applications.

IP QoS can be deployed by defining classes or categories of applications. These classes are defined by using various classification techniques available in Cisco IOS software. After these classes are defined and attached to an interface, the desired QoS features, such as Marking, Congestion Management, Congestion Avoidance, Link Efficiency mechanisms, or Policing and Shaping can then be applied to the classified traffic to provide the appropriate network resources amongst the defined classes.

Classification, therefore, is an important first-step in configuring QoS in a network infrastructure.

NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other difficult-to-classify protocols that utilize dynamic TCP/UDP port assignments. When an application is recognized and classified by NBAR, a network can invoke services for that specific application. NBAR ensures that network bandwidth is used efficiently by classifying packets and then applying Quality of Service (QoS) to the classified traffic. Some examples of class-based QoS features that can be used on traffic after the traffic is classified by NBAR include:

•

Class-Based Weighted Fair Queueing (the bandwidth and queue-limit commands)

Note For an animated example of NBAR being used with other QoS features to solve a network problem, click here.

Note The NBAR feature is used for classifying traffic by protocol. The other class-based QoS features determine how the classified traffic is forwarded and are documented separately from NBAR. Furthermore, NBAR is not the only method of classifying network traffic so that QoS features can be applied to classified traffic.

For information on the class-based features that can be used to forward NBAR-classified traffic, see the individual feature modules for the particular class-based feature as well as the Cisco IOS Quality of Service Solutions Guide.

Many of the non-NBAR classification options for QoS are documented in the "Modular Quality of Service Command-Line Interface" section of the Cisco IOS Quality of Service Solutions Guide. These commands are configured using the match command in class map configuration mode.

NBAR introduces several new classification features that identify applications and protocols from Layer 4 through Layer 7:

•

Dynamically assigned TCP and UDP port numbers. Classification of such applications requires stateful inspection; that is, the ability to discover the data connections to be classified by parsing the connections where the port assignments are made.

•

Sub-port classification or classification based on deep packet inspection; that is, classification by looking deeper into the packet.

NBAR can classify static port protocols. Although access control lists (ACLs) can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when using ACLs.

NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are transversing an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol Discovery maintains the following per-protocol statistics for enabled interfaces: total number of input and output packets and bytes, and input and output bit rates. The Protocol Discovery feature captures key statistics associated with each protocol in a network that can be used to define traffic classes and QoS policies for each traffic class.

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 amount and the variety of applications and protocols running on a network.

NBAR gives network administrators the ability to see the variety of protocols and the amount of traffic generated by each protocol. After gathering this information, NBAR allows users to implement classes of traffic. These classes of traffic can then be used to provide different levels of service for network traffic, therefore allowing better network management by providing the right level of network resources for network traffic.

NBAR Application Notes

The following section provides information on several topics that could be useful to individuals configuring NBAR in their networks. The following topics are covered in this section:

Catalyst 6000 Family Switches without FlexWAN Modules Application Notes

When NBAR is enabled on a Catalyst 6000 without a FlexWAN module interface, all traffic flows entering or leaving the NBAR-enabled interface will be processed in software on the Multilayer Swich Feature Card 2 (MSFC2).

•

NBAR can only be implemented on an MSFC2 with Supervisor Engine 1 or Supervisor Engine 2.

•

NBAR Protocol Discovery or QoS service policies using NBAR to match protocols cannot co-exist on an interface that contains Catalyst 6000-specific QoS actions. Refer to the Catalyst 6000 QoS Guide for Catalyst 6000-specific QoS actions (at the time of this publication, the current Catalyst 6000-specific QoS actions were police and trust, but please refer to the Catalyst 6000 QoS Guide for additional information).

The following table provides configuration results when NBAR is added to an interface. The results vary depending on the current configuration of the policy map on the interface.


Current Policy Map State	Action	Result
At least one service policy with platform-specific QoS action in the policy map is attached to interface.	Enable Protocol Discovery on the interface.	Protocol Discovery is rejected.
No service policies on the interface have NBAR or a platform-specific QoS action in the policy map.	Enable Protocol Discovery on the interface.	Protocol Discovery is accepted, but the service policy is disabled from the interface.
A service policy on the interface contains match protocol NBAR commands.	Enable Protocol Discovery on the interface.	Protocol Discovery is accepted.
No policy map is on the interface.	Enable Protocol Discovery on the interface.	The command is accepted. Traffic is processed on the MSFC2 once the command is accepted.
No policy map is on the interface	Disable Protocol Discovery.	The command is accepted. Traffic is no longer processed on the MSFC2.
No service policies on the interface have platform-specific QoS actions or match protocol NBAR commands.	Disable Protocol Discovery.	Protocol Discovery is disabled. The service policy is removed from the interface. The service policy can be reattached.
At least one service policy on the interface is using the match protocol NBAR command.	Disable Protocol Discovery.	Protocol Discovery is disabled.
A service policy with a platform-specific QoS action and Protocol Discovery is enabled on the interface.	Attach the service policy to an interface.	Reject the service policy. Protocol Discovery and platform-specific QoS actions cannot be enabled in the same policy map.
Protocol Discovery is enabled on an interface and the service policy has a non-platform specific QoS action.	Attach the service policy to an interface.	The policy map is attached. The policy map has to be attached in IOS QoS mode.
No match protocol NBAR commands are in any service policy on the interface and Protocol Discovery is not enabled.	Attach the service policy to an interface.	The policy map is attached in Catalyst 6000 QoS mode.
Protocol Discovery is not enabled on the interface and match protocol NBAR commands are in at least one service policy on the interface.	Attach the service policy to an interface.	The service policy is attached in IOS mode and traffic is processed using the MSFC2.
A service policy that has no match protocol NBAR commands and no Protocol Discovery needs to be removed from the interface. The interface contains no other service policies that contain match protocol NBAR commands or Protocol Discovery.	Detach the service policy from an interface	The service policy is detached like any other service policy.
A service policy with match protocol NBAR commands needs to be detached from the interface. Another service policy attached in the opposite direction does not contain match protocol NBAR commands. No Protocol Discovery is enabled on the interface.	Detach the service policy with match protocol NBAR commands from the interface.	The service policy is detached and the other service policy in the opposite direction is also removed. Traffic is no longer processed using the MSFC2.
A service policy contains match protocol NBAR commands and the service policy in the other direction needs match protocol NBAR or Protocol Discovery needs to be enabled on the interface.	Detach the service policy from the interface.	The service policy is detached. Continue to process traffic on the MSFC2 so that match protocol can be enabled on the other service policy or Protocol Discovery can be enabled on the interface.
A service policy contains match protocol NBAR commands. No other service policies are on the interface and Protocol Discovery is not enabled.	Detach the service policy from the interface.	Service policy is detached. Traffic is no longer processed on the MSFC2.

Packet Description Language Module

An external Packet Description Language Module (PDLM) can be loaded at run time to extend the NBAR list of recognized protocols. PDLMs can also be used to enhance an existing protocol recognition capability. PDLMs allow NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload.

New PDLMs will only be released by Cisco and can be loaded from Flash memory. Please contact your local Cisco representative to request additions or changes to the set of protocols classified by NBAR.

To view a list of currently available PDLMs or to download a PDLM, go to the following URL:

Classification of HTTP 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 on content within the payload such as transaction identifier, message type, or other similar data.

Classification of HTTP 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 URL matching in NBAR supports most HTTP request methods such as GET, PUT, HEAD, POST, DELETE, and TRACE. NBAR uses the UNIX filename specification as the basis for the URL or host specification format. The NBAR engine then converts the specified match string into a regular expression.

NBAR recognizes HTTP packets containing the URL and classifies all packets that are sent to the source of the HTTP request. Figure 1 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 following the www.hostname.domain in the match statement. For example, for the URL www.cisco.com/latest/whatsnew.html, include only /latest/whatsnew.html.

Host specification is identical to URL specification. 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:

In MIME type matching, NBAR classifies the packet containing the MIME type and all subsequent packets, which are sent to the source of the HTTP request.

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 identify HTTP traffic traversing these ports. HTTP traffic classifications are no longer restrained to the well-known and defined TCP ports.

Classification of Citrix ICA Traffic by Application Name

NBAR can classify Citrix Independent Computing Architecture (ICA) traffic and perform subport classification of Citrix traffic based on Citrix published applications. NBAR can monitor Citrix ICA client requests for a published application destined to a Citrix ICA Master browser. After the client requests to 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.

NBAR statefully tracks Citrix ICA server client messages and classifies requests for given Citrix application names and traffic. A Citrix application is named when published on a Citrix ICA server. NBAR performs a regular expression match using a user-specified application name string on the contents of the Citrix ICA control packets carrying the published application name. Therefore, users need to specify a regular expression that will result in a match for the published application name if they want to match a specified application. See the match protocol citrix command in the " Command Reference" section for additional information.

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 only be used to classify Citrix applications 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 non-seamless (windows) modes of operation. In non-seamless 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 non-session 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 on some software releases.

In seamless non-session sharing mode, each application for each particular client uses a separate TCP connection. NBAR can provide interapplication differentiation in seamless non-session sharing mode.

Step 1

At the command prompt of the Citrix server, open the registry editor by entering the regedit command.

Step 2

Create the following registry entry (which overrides session sharing):

Setting this registry value to 1 overrides session sharing. Note that this flag is SERVER GLOBAL.

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

RTP Payload Type Classification

RTP is a packet format for multimedia data streams. It can be used for media-on-demand as well as 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). 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 providing support for applications with real-time properties such as continuous media (such as audio and video), which includes timing reconstruction, loss detection, and security and content identification. RTP is discussed in RFC 1889 and RFC 1890.

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

NBAR RTP Payload Type Classification not only allows one to statefully identify real-time audio and video traffic, but it also can differentiate on the basis of audio and video CODECs to provide more granular Quality of Service. The RTP Payload Type Classification feature, therefore, looks deep into the RTP header to classify RTP packets.

NBAR RTP Payload Type Classification was first introduced in Cisco IOS Release 12.2(8)T and is also available in Cisco IOS Release 12.1(11b)E.

Classification of Custom Applications

The custom protocol supports static port-based protocols and applications that are not currently supported in NBAR. This functionality allows mapping of static TCP and UDP port numbers to custom protocol within NBAR. The custom protocol is also available as a PDLM if your version of Cisco IOS supports NBAR but not the custom protocol.

The initial custom NBAR application had the following features that were later enhanced in Cisco IOS Release 12.3(4)T:

•

10 custom applications can be assigned using NBAR, and each customer application can have up to 16 TCP and 16 UDP ports each mapped to the individual custom protocol. The real-time statistics of each custom protocol can be monitored using Protocol Discovery.

In Cisco IOS Release 12.3(4)T, the User-Defined Custom Application Classification feature was introduced and the following enhancements to custom protocols were introduced:

•

The ability to inspect the payload for certain matching string patterns at a specific offset.

•

The ability to allow users to define the names of their custom protocol applications. The user-named protocol can then be used by Protocol Discovery, the Protocol Discovery MIB, match protocol, or ip nbar port-map as an NBAR-supported protocol.

•

The ability to allow NBAR inspection for custom protocols to be specified by direction of traffic (traffic heading toward a source or destination rather than defaulting to traffic in both directions) if desired by user.

•

Provides CLI support that allows a user configuring a custom application to specify a range of ports rather than have to enter each port individually.

For additional information on the enhancements to the custom protocol that were introduced in Cisco IOS Release 12.3(4)T, see the ip nbar custom command reference in this document.

Pre-12.3(4)T Custom Application Example

In the following example, a gaming application that runs on TCP port 8877 needs to be classified using NBAR. You can use custom-01 to map TCP port 8877 by entering the following command:

It is important to note that this configuration is also supported on Cisco IOS releases released after Release 12.3(4)T but is required on all prior releases.

12.3(4)T and Later Custom Application Examples

In the following example, the custom protocol app_sales1 will identify TCP packets with a source port of 4567 and contain the term "SALES" in the fifth byte of the payload:

In the following example, the custom protocol virus_home will identify UDP packets with a destination port of 3000 and contain "0x56" in the seventh byte of the payload:

In the following example, custom protocol media_new will identify TCP packets with a destination or source port of 4500 and that have a value of 90 at the sixth byte of the payload:

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

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

In the following example, custom protocol mail_y will look for UDP packets with destination ports between 3000 and 4000 including 3000 and 4000 as well as port 5500:

Classification of Peer-to-Peer File-Sharing Applications

Gnutella and FastTrack are peer-to-peer file-sharing protocols that became classifiable using NBAR in Cisco IOS Release 12.1(12c)E.

The match protocol gnutella file-transfer "regular-expression" and match protocol fasttrack file-transfer "regular-expression" commands are used to enable Gnutella and FastTrack classification in a traffic class. 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:

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

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 based on a filename extension or on 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.

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

Applications that use FastTrack include KaZaA, Grokster, and Morpheus (although newer versions of Morpheus use Gnutella).

IP NBAR PDLM Module Versioning

A Packet Description Language Module (PDLM) is used to add a new protocol to the list of supported NBAR protocols. Before downloading PDLMs, users should understand some of the interdependencies between the versioning of NBAR in the Cisco IOS code and the PDLM file itself. The following definitions help define some of the aspects of NBAR and PDLM versioning and the interdependencies required between the two before a new protocol can be supported in NBAR via a PDLM download.

•

NBAR Software Version—This is the version of NBAR software running on the current version of Cisco IOS.

•

Resident Module Version—This is the version of the NBAR-supported PDLM protocol. The Resident Module Version must be less than the NBAR PDLM Interdependency Version of the PDLM for a PDLM file to be downloaded from cisco.com and accepted within NBAR in the IOS software.

•

NBAR Software Version—The minimum version of the NBAR software required to load this PDLM.

See the show ip nbar version command reference in this document for additional information on IP NBAR PDLM Module Versioning.

Supported Protocols

•

TCP and UDP protocols that dynamically assign port numbers and therefore require stateful inspection. This table includes packets that require sub-port classification and classification based on deep packet inspection.

Table 2 Non-UDP and Non-TCP Protocols
Protocol	Type	Well-Known Port Number	Description	Syntax	Cisco IOS Release¹
EGP	IP	8	Exterior Gateway Protocol	egp	12.0(5)XE2 12.1(1)E 12.1(5)T
EIGRP	IP	88	Enhanced Interior Gateway Routing Protocol	eigrp	12.0(5)XE2 12.1(1)E 12.1(5)T
GRE	IP	47	Generic Routing Encapsulation	gre	12.0(5)XE2 12.1(1)E 12.1(5)T
ICMP	IP	1	Internet Control Message Protocol	icmp	12.0(5)XE2 12.1(1)E 12.1(5)T
IPINIP	IP	4	IP in IP	ipinip	12.0(5)XE2 12.1(1)E 12.1(5)T
IPSec	IP	50, 51	IP Encapsulating Security Payload/Authentication Header	ipsec	12.0(5)XE2 12.1(1)E 12.1(5)T

Table 3 TCP and UDP Static Port Protocols
Protocol	Type	Well-Known Port Number	Description	Syntax	Cisco IOS Release¹
BGP	TCP/UDP	179	Border Gateway Protocol	bgp	12.0(5)XE2 12.1(1)E 12.1(5)T
CU-SeeMe	TCP/UDP	7648, 7649	Desktop videoconferencing	cuseeme	12.0(5)XE2 12.1(1)E 12.1(5)T
CU-SeeMe	UDP	24032	Desktop video conferencing	cuseeme	12.0(5)XE2 12.1(1)E 12.1(5)T
DHCP/ BOOTP	UDP	67, 68	Dynamic Host Configuration Protocol/ Bootstrap Protocol	dhcp	12.0(5)XE2 12.1(1)E 12.1(5)T
DNS	TCP/UDP	53	Domain Name System	dns	12.0(5)XE2 12.1(1)E 12.1(5)T
Finger	TCP	79	Finger user information protocol	finger	12.0(5)XE2 12.1(1)E 12.1(5)T
Gopher	TCP/UDP	70	Internet Gopher Protocol	gopher	12.0(5)XE2 12.1(1)E 12.1(5)T
HTTP	TCP	80²	Hypertext Transfer Protocol	http	12.0(5)XE2 12.1(1)E 12.1(5)T
HTTPS	TCP	443	Secured HTTP	secure-http	12.0(5)XE2 12.1(1)E 12.1(5)T
IMAP	TCP/UDP	143, 220	Internet Message Access Protocol	imap	12.0(5)XE2 12.1(1)E 12.1(5)T
IRC	TCP/UDP	194	Internet Relay Chat	irc	12.0(5)XE2 12.1(1)E 12.1(5)T
Kerberos	TCP/UDP	88, 749	Kerberos Network Authentication Service	kerberos	12.0(5)XE2 12.1(1)E 12.1(5)T
L2TP	UDP	1701	L2F/L2TP tunnel	l2tp	12.0(5)XE2 12.1(1)E 12.1(5)T
LDAP	TCP/UDP	389	Lightweight Directory Access Protocol	ldap	12.0(5)XE2 12.1(1)E 12.1(5)T
MS-PPTP	TCP	1723	Microsoft Point-to-Point Tunneling Protocol for VPN	pptp	12.0(5)XE2 12.1(1)E 12.1(5)T
MS- SQLServer	TCP	1433	Microsoft SQL Server Desktop Videoconferencing	sqlserver	12.0(5)XE2 12.1(1)E 12.1(5)T
NetBIOS	TCP	137, 139	NetBIOS over IP (MS Windows)	netbios	12.0(5)XE2 12.1(1)E 12.1(5)T
NetBIOS	UDP	137, 138	NetBIOS over IP (MS Windows)	netbios	12.0(5)XE2 12.1(1)E 12.1(5)T
NFS	TCP/UDP	2049	Network File System	nfs	12.0(5)XE2 12.1(1)E 12.1(5)T
NNTP	TCP/UDP	119	Network News Transfer Protocol	nntp	12.0(5)XE2 12.1(1)E 12.1(5)T
Notes	TCP/UDP	1352	Lotus Notes	notes	12.0(5)XE2 12.1(1)E 12.1(5)T
Novadigm	TCP/UDP	3460-3465	Novadigm Enterprise Desktop Manager (EDM)	novadigm	12.1(2)E 12.1(5)T
NTP	TCP/UDP	123	Network Time Protocol	ntp	12.0(5)XE2 12.1(1)E 12.1(5)T
PCAnywhere	TCP	5631, 65301	Symantec PCAnywhere	pcanywhere	12.0(5)XE2 12.1(1)E 12.1(5)T
PCAnywhere	UDP	22, 5632	Symantec PCAnywhere	pcanywhere	12.0(5)XE2 12.1(1)E 12.1(5)T
POP3	TCP/UDP	110	Post Office Protocol	pop3	12.0(5)XE2 12.1(1)E 12.1(5)T
Printer	TCP/UDP	515	Printer	printer	12.1(2)E 12.1(5)T
RIP	UDP	520	Routing Information Protocol	rip	12.0(5)XE2 12.1(1)E 12.1(5)T
RSVP	UDP	1698, 1699	Resource Reservation Protocol	rsvp	12.0(5)XE2 12.1(1)E 12.1(5)T
SFTP	TCP	990	Secure FTP	secure-ftp	12.0(5)XE2 12.1(1)E 12.1(5)T
SHTTP	TCP	443	Secure HTTP	secure-http	12.0(5)XE2 12.1(1)E 12.1(5)T
SIMAP	TCP/UDP	585, 993	Secure IMAP	secure-imap	12.0(5)XE2 12.1(1)E 12.1(5)T
SIRC	TCP/UDP	994	Secure IRC	secure-irc	12.0(5)XE2 12.1(1)E 12.1(5)T
SLDAP	TCP/UDP	636	Secure LDAP	secure-ldap	12.0(5)XE2 12.1(1)E 12.1(5)T
SMTP	TCP	25	Simple Mail Transfer Protocol	smtp	12.0(5)XE2 12.1(1)E 12.1(5)T
SNMP	TCP/UDP	161, 162	Simple Network Management Protocol	snmp	12.0(5)XE2 12.1(1)E 12.1(5)T
SNNTP	TCP/UDP	563	Secure NNTP	secure-nntp	12.0(5)XE2 12.1(1)E 12.1(5)T
SOCKS	TCP	1080	Firewall security protocol	socks	12.0(5)XE2 12.1(1)E 12.1(5)T
SPOP3	TCP/UDP	995	Secure POP3	secure-pop3	12.0(5)XE2 12.1(1)E 12.1(5)T
SSH	TCP	22	Secured Shell	ssh	12.0(5)XE2 12.1(1)E 12.1(5)T
STELNET	TCP	992	Secure Telnet	secure-telnet	12.0(5)XE2 12.1(1)E 12.1(5)T
Syslog	UDP	514	System Logging Utility	syslog	12.0(5)XE2 12.1(1)E 12.1(5)T
Telnet	TCP	23	Telnet Protocol	telnet	12.0(5)XE2 12.1(1)E 12.1(5)T
X Windows	TCP	6000-6003	X11, X Windows	xwindows	12.0(5)XE2 12.1(1)E 12.1(5)T

¹Indicates the Cisco IOS maintenance release that first supported the protocol. This table is updated when a protocol is added to a new Cisco IOS release train.

²In 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 identify HTTP traffic traversing these ports.

Table 4 TCP and UDP Stateful Protocols
Protocol	Type	Description	Syntax	Cisco IOS Release¹
Citrix ICA	TCP/UDP	Citrix ICA traffic by application name	citrix citrix app	12.1(2)E 12.1(5)T
FTP	TCP	File Transfer Protocol	ftp	12.0(5)XE2 12.1(1)E 12.1(5)T
Exchange	TCP	MS-RPC for Exchange	exchange	12.0(5)XE2 12.1(1)E 12.1(5)T
FastTrack		FastTrack For a list of common FastTrack applications, see the " Classification of Peer-to-Peer File-Sharing Applications" section of this document.	fasttrack	12.1(12c)E
Gnutella	TCP	Gnutella For a list of common Gnutella applications, see the " Classification of Peer-to-Peer File-Sharing Applications" section of this document.	gnutella	12.1(12c)E
HTTP	TCP	HTTP with URL, MIME, or host classification	http	12.0(5)XE2 12.1(1)E 12.1(5)T (HTTP host classification is not available on the 12.0 XE release train)
Napster	TCP	Napster traffic	napster	12.1(5)T
Netshow	TCP/UDP	Microsoft Netshow	netshow	12.0(5)XE2 12.1(1)E 12.1(5)T
r-commands	TCP	rsh, rlogin, rexec	rcmd	12.0(5)XE2 12.1(1)E 12.1(5)T
RealAudio	TCP/UDP	RealAudio Streaming Protocol	realaudio	12.0(5)XE2 12.1(1)E 12.1(5)T
RTP	TCP/UDP	Real-Time Transport Protocol Payload Classification	rtp	12.2(8)T
SQL*NET	TCP/UDP	SQL*NET for Oracle	sqlnet	12.0(5)XE2 12.1(1)E 12.1(5)T
StreamWorks	UDP	Xing Technology Stream Works audio and video	streamwork	12.0(5)XE2 12.1(1)E 12.1(5)T
SunRPC	TCP/UDP	Sun Remote Procedure Call	sunrpc	12.0(5)XE2 12.1(1)E 12.1(5)T
TFTP	UDP	Trivial File Transfer Protocol	tftp	12.0(5)XE2 12.1(1)E 12.1(5)T
VDOLive	TCP/UDP	VDOLive Streaming Video	vdolive	12.0(5)XE2 12.1(1)E 12.1(5)T

¹Indicates the Cisco IOS maintenance release that first supported the protocol. This table is updated when a protocol is added to a new Cisco IOS release train.

Restrictions

•

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 support full payload inspection. The only exception is that NBAR can only inspect custom protocol traffic for 255 bytes into the payload.

•

MPLS-labelled packets. NBAR only classifies IP packets. You can, however, use NBAR to classify IP traffic before the traffic is handed over to MPLS. Use the Modular QoS CLI (MQC ) to set the IP DSCP field on the NBAR-classified packets and make MPLS map the DSCP setting to the MPLS EXP setting inside the MPLS header.

Note NBAR cannot be used to classify output traffic on a WAN link where tunneling or encryption is used. Therefore, NBAR should be configured on other interfaces on the router (such as a LAN link) to perform input classification before the traffic is switched to the WAN link for output.

However, NBAR Protocol Discovery is supported on interfaces where tunneling or encryption is used. You can enable Protocol Discovery directly on the tunnel or on the interface where encryption is performed to gather key statistics on the various applications that are traversing the interface. The input statistics also show the total number of encrypted/tunneled packets received in addition to the per-protocol breakdowns.

In order to run Distributed NBAR on a Cisco 7500 series router, you must be using a processor that has 64 MB of DRAM or more. At the time of this publication, the following processors met this requirement:

Memory Management

NBAR uses approximately 150 bytes of DRAM for each flow that requires stateful inspection. (See Table 4 for a list of stateful protocols supported by NBAR that require stateful inspection.) When NBAR is configured, it allocates 1 MB of DRAM to support up to 5000 concurrent flows. NBAR checks to see if it needs more memory to handle additional concurrent stateful flows. If such a need is detected, NBAR expands its memory usage in increments of 200 Kb to 400 Kb.

Related Features and Technologies

Table Of Contents