Guest

Cisco IOS Software Releases 12.1 E

Network-Based Application Recognition

Table Of Contents

Network-Based Application Recognition and Distributed Network-Based Application Recognition

Content

Prerequisites for NBAR

Restrictions

Information About NBAR

Feature Overview

Benefits

Configuring NBAR in a Network

Catalyst 6000 Family Switches Without FlexWAN Modules Application Notes

Packet Description Language Module

Classification of HTTP Traffic

Classification of Citrix ICA Traffic

RTP Payload Type Classification

Classification of Custom Applications

Classification of Peer-to-Peer File-Sharing Applications

Classification of Streaming Protocols

IP NBAR PDLM Module Versioning

Supported Protocols

Memory Management

How to Configure NBAR

Enabling Protocol Discovery

Configuring a Traffic Class

Configuring a Traffic Policy

Attaching a Traffic Policy to an Interface

Downloading PDLMs

Verifying the Configuration

Troubleshooting Tips

Monitoring and Maintaining NBAR

Configuration Examples

Configuring a Traffic Policy with NBAR

Adding a PDLM

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Command Reference

ip nbar custom

match protocol (NBAR)

match protocol citrix

match protocol http

Glossary

Appendix

Sample Configuration


Network-Based Application Recognition and Distributed Network-Based Application Recognition


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 revised command syntax.

History for the NBAR and dNBAR Features1  

Cisco IOS Release
Modification

12.0(5)XE2

This 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 (NBAR) command.

12.1(5)T

This feature was integrated into Cisco IOS Release 12.1(5) T.

12.1(6)E
12.2(4)T3

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.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.2(15)T

The Protocol Discovery MIB was introduced.

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(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(11)T

The ability to classify traffic using HTTP header fields was introduced. The c-header-field and s-header-field options were added to the match protocol http command.

12.4(1)

The variable keyword, the field-name argument, and the field-length arguments were added to the ip nbar custom command. This new keyword and additional arguments allow sub-classification of custom traffic in NBAR.

12.4(4)T

Support was added for Direct Connect and Skype protocols.

1 This feature history table only contains enhancements to the overall NBAR feature. It does not include the introduction of new NBAR-supported protocols or the introduction of NBAR on new platforms. For information relating to when protocols were introduced on NBAR, see the "Supported Protocols" section. For information about when NBAR was introduced on a platform, see the Access Cisco Feature Navigator at http://www.cisco.com/go/f.

1 Finding Support Information for Platforms and Cisco IOS Software Images

1 Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.


Content

Prerequisites for NBAR

Feature Overview

How to Configure NBAR

Monitoring and Maintaining NBAR

Configuration Examples

Technical Assistance

Command Reference

Glossary

Appendix

Prerequisites for NBAR

CEF

You must enable Cisco Express Forwarding (CEF) before you configure NBAR. For more information on CEF, refer to the Cisco IOS Release 12.2 Cisco IOS Switching Services Configuration Guide.

Restrictions

NBAR is currently not supported with Stateful Switchover (SSO). This applies to the Catalyst 6500, Cisco 7600 and Cisco 7500.

Also, the NBAR feature does not support the following:

More than 24 concurrent URLs, hosts, or MIME type matches.

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 only inspect custom protocol traffic for 255 bytes into the payload.

Non-IP traffic.

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.

Multicast and other non-CEF switching modes.

Fragmented packets.

Pipelined persistent HTTP requests.

URL/host/MIME classification with secure HTTP.

Asymmetric flows with stateful protocols.

Packets originating from or destined to the router running NBAR.

NBAR is not supported on the following logical interfaces:

For VLAN setups, NBAR only works on interfaces setup as VLAN 1. NBAR does not work with any other VLAN number.

Fast EtherChannel.

Interfaces where tunneling or encryption is used.

NBAR was not supported on Dialer interfaces until Cisco IOS Release 12.2(4)T.


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:

VIP2-50, VIP4-50, VIP4-80, and VIP6-80

GEIP and GEIP+

SRPIP

Information About NBAR

The following sections provide information about NBAR.

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 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 Marking (the set command)

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

Low Latency Queueing (the priority command)

Traffic Policing (the police command)

Traffic Shaping (the shape command)


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:

Statically assigned TCP and UDP port numbers.

Non-UDP and non-TCP IP protocols.

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

Ability to Identify and Classify Network Traffic by Protocol

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.

Configuring NBAR in a Network

This 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

Packet Description Language Module

Classification of HTTP Traffic

Classification of Citrix ICA Traffic

RTP Payload Type Classification

Classification of Custom Applications

Classification of Peer-to-Peer File-Sharing Applications

Classification of Streaming Protocols

IP NBAR PDLM Module Versioning

Supported Protocols

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 Switch Feature Card 2 (MSFC2).

The following other restrictions should also be noted when running NBAR:

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.

Table 1 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.

Table 1 NBAR Behavior Descriptions  

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. 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:

http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm

Classification of HTTP Traffic

This section covers the following topics:

Classification of HTTP Traffic by URL, Host, or MIME

Classification of HTTP Traffic Using the HTTP Header Fields

Combining Classification of HTTP Headers and URL, Host, or MIME Type to Identify 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 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 by 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.

Figure 1 Network Topology with NBAR

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:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

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 HTTP Traffic Using the 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 back 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. This document can be read at the following URL:

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

NBAR is able to 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 header fields can be identified using NBAR:

Server

Location

Content-Base

Content-Encoding

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).

Examples

In the following example, any request message that contains "somebody@cisco.com" in the User-Agent, Referer, or From fields 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:

match protocol http c-header-field *somebody@cisco.com*

In the following example, any request message that contains "http://www.cisco.com/routers" in the User-Agent, Referer, or From fields 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:

match protocol http c-header-field *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 fields 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:

match protocol http c-header-field *CERN-LineMode/2.15*

In the following example, any response message that contains "CERN/3.0" in the Content-Base, Content-Encoding, Location, or Server header fields 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:

match protocol http s-header-field *CERN/3.0*

In the following example, any response message that contains "http://www.cisco.com/routers" in the Content-Base, Content-Encoding, Location, or Server header fields 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 or Location header field of the response message:

match protocol http s-header-field *http://www.cisco.com/routers*

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

match protocol http s-header-field *gzip*

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

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

Examples

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

class-map match-all c-http
match protocol http c-header-field *CERN-LineMode/3.0*
match protocol http s-header-field *CERN/3.0*
match protocol http url *www.cisco.com*

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, see the match protocol citrix command in the "Command Reference" section of this document.)

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 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 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 on 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.

Session sharing can be turned off using the following steps:


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):

[HKLM]\SYSTEM\CurrentControlSet\Control\Citrix\WFSHELL\TWI

Value name: "SeamlessFlags", type DWORD, possible value` 0 or 1

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.


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 people would prefer that printing be handled as a background process and not have printing 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 then 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. Byte1 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 "Command Reference" section of this document.

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). 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 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 initial custom NBAR application had the following features that were later enhanced in Cisco IOS Release 12.3(4)T:

The custom protocol had to be named custom-xx, with xx being a number.

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 custom protocols introduced in Cisco IOS Release 12.3(4)T, see the ip nbar custom command in the "Command Reference" section of this document.

Beginning in Cisco IOS Release 12.4(1), the variable keyword, the field-name argument, and the field-length argument were added to the ip nbar custom command. This additional keyword and two additional arguments allow for NBAR classification and identification on a specific value within a custom payload. After creating a variable when creating a custom protocol, you can use the match protocol command to classify traffic based on a specific value in the custom protocol. For more information about the ip nbar custom command, see the "Command Reference" section of this document. For more information about the match protocol command, see the Cisco IOS Quality of Service Solutions Command Reference.

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:

Router(config)# ip nbar port-map custom-01 tcp 8877

It is important to note that this configuration is also supported on Cisco IOS releases later than 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:

ip nbar custom app_sales1 5 ascii SALES source tcp 4567

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:

ip nbar custom virus_home 7 hex 0x56 dest udp 3000

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:

ip nbar custom media_new 6 decimal 90 tcp 4500

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

ip nbar custom msn1 tcp 6700

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

ip nbar custom mail_x destination udp 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:

ip nbar custom mail_y destination udp range 3000 4000 5500

In the following example, the variable keyword is used while creating a custom protocol, and class maps are configured to classify different values within the variable field into different traffic classes. Specifically, in the example below, variable scid values 0x15, 0x21, and 0x27 will be classified into class map active-craft while scid values 0x11, 0x22, and 0x25 will be classified into class map passive-craft.


ip nbar custom ftdd field scid 125 variable 1 tcp range 5001 5005

class-map active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21
match protocol ftdd scid 0x27

class-map passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22
match protocol ftdd scid 0x25

Classification of Peer-to-Peer File-Sharing Applications

Gnutella and FastTrack are examples of peer-to-peer file-sharing protocols that became classifiable using NBAR in Cisco IOS Release 12.1(12c)E. The following is a complete list of peer-to-peer file-sharing applications that use these protocols and are supported by NBAR.

Applications that use the Gnutella protocol:

Bearshare

Gnewtellium

Gnucleus

Gtk-Gnutella

Limewire

Mutella

Phex

Qtella

Swapper

Xolo

Applications that use RTSP:

Real Player

Quicktime

Kazaa, eDonkey, eMule, FastTrack, Grokster, JTella, Morpheus, WinMX, XCache, and Direct Connect are other peer-to-peer file-sharing applications supported by NBAR.

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:

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

Similarly, all Gnutella traffic is classified into class map nbar in this 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 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.

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 same examples 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*"

Classification of Streaming Protocols

In Cisco IOS Release 12.3(7)T, NBAR introduced support for RTSP, which is the protocol used for the following applications that use streaming audio:

RealAudio (RealSystems G2)

Apple QuickTime

Windows Media Services

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.

The following version numbers are kept by the Cisco IOS software:

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

Resident Module Version—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 Cisco IOS software.

The following version number is kept by the PDLM:

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

For additional information on IP NBAR PDLM Module Versioning, see the show ip nbar version command in the "Command Reference" of this document.

Supported Protocols

The easiest method of seeing which protocols can be classified using NBAR on your Cisco IOS release is to enter the match protocol ? and to view the options that appear. Not all protocols listed in this section are supported for NBAR on all Cisco IOS releases.

Before reviewing the list of protocols that are supported in your Cisco IOS release, it is also important to note that support for some protocols can be added to NBAR using PDLMs. For information on PDLMs and seeing which protocols can be added using PDLMs, see the "Downloading PDLMs" section. Note that protocols introduced via PDLM are eventually added to the Cisco IOS at some point and may already be available in your Cisco IOS release.

Table 2 lists all of the NBAR-supported protocols available in Cisco IOS. The table also provides information about the protocol type, well-known port numbers, the syntax for entering the protocol in NBAR, and the Cisco IOS release where the protocol was initially supported.


Note Many peer-to-peer file sharing applications aren't listed in this table but can be classified using FastTrack or Gnutella. See the "Classification of Peer-to-Peer File-Sharing Applications" section for additional information.



Note RTSP can be used to classify various types of applications that use streaming audio. See the "Classification of Streaming Protocols" section for additional information.


Table 2 NBAR-Supported Protocols  

Protocol
Category
Type
Well-Known Port Number
Description
Syntax
Cisco IOS Release1

Citrix ICA

Enterprise Application

TCP/
UDP

Stateful Protocol

Citrix ICA traffic by application name

citrix
citrix app

12.1(2)E
12.1(5)T

PCAnywhere

Enterprise Application

TCP

5631, 65301

Symantic pcAnywhere

pcanywhere

12.0(5)XE2
12.1(1)E
12.1(5)T

PCAnywhere

Enterprise Application

UDP

22, 5632

Symantic pcAnywhere

pcanywhere

12.0(5)XE2
12.1(1)E
12.1(5)T

Novadigm

Enterprise Application

TCP/ UDP

3460- 3465

Novadigm Enterprise Desktop Manager  (EDM)

novadigm

12.1(2)E
12.1(5)T

SAP

Enterprise Application

TCP

3300-3315 (sap-pgm. pdlm)
3200-3215 (sap-app. pdlm)
3600-3615 (sap-msg. pdlm)

Application server to application server traffic (sap-pgm.pdlm)

Client to application server traffic (sap-app.pdlm)

Client to message server traffic (sap-msg.pdlm)

sap

12.3
12.3 T
12.2 T
12.1 E

BGP

Routing Protocol

TCP/ UDP

179

Border Gateway Protocol

bgp

12.0(5)XE2
12.1(1)E
12.1(5)T

EGP

Routing Protocol

IP

8

Exterior Gateway Protocol

egp

12.0(5)XE2
12.1(1)E
12.1(5)T

EIGRP

Routing Protocol

IP

88

Enhanced Interior Gateway Routing Protocol

eigrp

12.0(5)XE2
12.1(1)E
12.1(5)T

OSPF

Routing Protocol

TCP

Stateful Protocol

Open Shortest Path First

ospf

12.3(8)T

RIP

Routing Protocol

UDP

520

Routing Information Protocol

rip

12.0(5)XE2
12.1(1)E
12.1(5)T

SQL*NET

Database

TCP/ UDP

Stateful Protocol

SQL*NET for Oracle

sqlnet

12.0(5)XE2
12.1(1)E
12.1(5)T

MS- SQLServer

Database

TCP

1433

Microsoft SQL Server Desktop Videoconferencing

sqlserver

12.0(5)XE2
12.1(1)E
12.1(5)T

GRE

Security and Tunneling

IP

47

Generic Routing Encapsulation

gre

12.0(5)XE2
12.1(1)E
12.1(5)T

IPINIP

Security and Tunneling

IP

4

IP in IP

ipinip

12.0(5)XE2
12.1(1)E
12.1(5)T

IPSec

Security and Tunneling

IP

50, 51

IP Encapsulating Security Payload/Authentication Header

ipsec

12.0(5)XE2
12.1(1)E
12.1(5)T

L2TP

Security and Tunneling

UDP

1701

L2F/L2TP tunnel

l2tp

12.0(5)XE2
12.1(1)E
12.1(5)T

MS-PPTP

Security and Tunneling

TCP

1723

Microsoft Point-to-Point Tunneling Protocol for VPN

pptp

12.0(5)XE2
12.1(1)E
12.1(5)T

SFTP

Security and Tunneling

TCP

990

Secure FTP

secure-ftp

12.0(5)XE2
12.1(1)E
12.1(5)T

SHTTP

Security and Tunneling

TCP

443

Secure HTTP

secure-http

12.0(5)XE2
12.1(1)E
12.1(5)T

SIMAP

Security and Tunneling

TCP/
UDP

585, 993

Secure IMAP

secure-imap

12.0(5)XE2
12.1(1)E
12.1(5)T

SIRC

Security and Tunneling

TCP/
UDP

994

Secure IRC

secure-irc

12.0(5)XE2
12.1(1)E
12.1(5)T

SLDAP

Security and Tunneling

TCP/
UDP

636

Secure LDAP

secure-ldap

12.0(5)XE2
12.1(1)E
12.1(5)T

SNNTP

Security and Tunneling

TCP/
UDP

563

Secure NNTP

secure-nntp

12.0(5)XE2
12.1(1)E
12.1(5)T

SPOP3

Security and Tunneling

TCP/
UDP

995

Secure POP3

secure-pop3

12.0(5)XE2
12.1(1)E
12.1(5)T

STELNET

Security and Tunneling

TCP

992

Secure Telnet

secure-telnet

12.0(5)XE2
12.1(1)E
12.1(5)T

SOCKS

Security and Tunneling

TCP

1080

Firewall security protocol

socks

12.0(5)XE2
12.1(1)E
12.1(5)T

SSH

Security and Tunneling

TCP

22

Secured Shell

ssh

12.0(5)XE2
12.1(1)E
12.1(5)T

ICMP

Network Management

IP

1

Internet Control Message Protocol

icmp

12.0(5)XE2
12.1(1)E
12.1(5)T

SNMP

Network Management

TCP/
UDP

161, 162

Simple Network Management Protocol

snmp

12.0(5)XE2
12.1(1)E
12.1(5)T

Syslog

Network Management

UDP

514

System Logging Utility

syslog

12.0(5)XE2
12.1(1)E
12.1(5)T

IMAP

Network Mail Services

TCP/
UDP

143, 220

Internet Message Access Protocol

imap

12.0(5)XE2
12.1(1)E
12.1(5)T

POP3

Network Mail Services

TCP/
UDP

110

Post Office Protocol

pop3

12.0(5)XE2
12.1(1)E
12.1(5)T

Exchange

Network Mail Services

TCP

MS-RPC for Exchange

exchange

TCP

12.0(5)XE2
12.1(1)E
12.1(5)T

Notes

Network Mail Services

TCP/
UDP

1352

Lotus Notes

notes

12.0(5)XE2
12.1(1)E
12.1(5)T

SMTP

Network Mail Services

TCP

25

Simple Mail Transfer Protocol

smtp

12.0(5)XE2
12.1(1)E
12.1(5)T

DHCP/
BOOTP

Directory

UDP

67, 68

Dynamic Host Configuration Protocol/ Bootstrap Protocol

dhcp

12.0(5)XE2
12.1(1)E
12.1(5)T

Finger

Directory

TCP

79

Finger user information protocol

finger

12.0(5)XE2
12.1(1)E
12.1(5)T

DNS

Directory

TCP/
UDP

53

Domain Name System

dns

12.0(5)XE2
12.1(1)E
12.1(5)T

Kerberos

Directory

TCP/
UDP

88, 749

Kerberos Network Authentication Service

kerberos

12.0(5)XE2
12.1(1)E
12.1(5)T

LDAP

Directory

TCP/
UDP

389

Lightweight Directory Access Protocol

ldap

12.0(5)XE2
12.1(1)E
12.1(5)T

CU-SeeMe

Streaming Media

TCP/
UDP

7648, 7649

Desktop video conferencing

cuseeme

12.0(5)XE2
12.1(1)E
12.1(5)T

CU-SeeMe

Streaming Media

UDP

24032

Desktop video conferencing

cuseeme

12.0(5)XE2
12.1(1)E
12.1(5)T

Netshow

Streaming Media

TCP/ UDP

Stateful Protocol

Microsoft Netshow

netshow

12.0(5)XE2
12.1(1)E
12.1(5)T

RealAudio

Streaming Media

TCP/ UDP

Stateful Protocol

RealAudio Streaming Protocol

realaudio

12.0(5)XE2
12.1(1)E
12.1(5)T

StreamWorks

Streaming Media

UDP

Stateful Protocol

Xing Technology Stream Works audio and video

streamwork

12.0(5)XE2
12.1(1)E
12.1(5)T

VDOLive

Streaming Media

TCP/ UDP

Stateful Protocol

VDOLive Streaming Video

vdolive

12.0(5)XE2
12.1(1)E
12.1(5)T

RTSP

Streaming Media/ Multimedia

TCP/ UDP

Stateful Protocol

Real-time Streaming Protocol

rtsp

12.3(11)T

MGCP

Streaming Media/ Multimedia

TCP/ UDP

2427, 2428, 2727

Media Gateway Control Protocol

mgcp

12.3(7)T

FTP

Internet

TCP

Stateful Protocol

File Transfer Protocol

ftp

12.0(5)XE2
12.1(1)E
12.1(5)T

Gopher

Internet

TCP/ UDP

70

Internet Gopher Protocol

gopher

12.0(5)XE2
12.1(1)E
12.1(5)T

HTTP

Internet

TCP

802

Hypertext Transfer Protocol

http

12.0(5)XE2
12.1(1)E
12.1(5)T

IRC

Internet

TCP/ UDP

194

Internet Relay Chat

irc

12.0(5)XE2
12.1(1)E
12.1(5)T

Telnet

Internet

TCP

23

Telnet Protocol

telnet

12.0(5)XE2
12.1(1)E
12.1(5)T

TFTP

Internet

UDP

Stateful Protocol

Trivial File Transfer Protocol

tftp

12.0(5)XE2
12.1(1)E
12.1(5)T

NNTP

Internet

TCP/ UDP

119

Network News Transfer Protocol

nntp

12.0(5)XE2
12.1(1)E
12.1(5)T

RSVP

Signaling

UDP

1698, 1699

Resource Reservation Protocol

rsvp

12.0(5)XE2
12.1(1)E
12.1(5)T

NFS

RPC

TCP/ UDP

2049

Network File System

nfs

12.0(5)XE2
12.1(1)E
12.1(5)T

Sunrpc

RPC

TCP/ UDP

Stateful Protocol

Sun Remote Procedure Call

sunrpc

12.0(5)XE2
12.1(1)E
12.1(5)T

NetBIOS

nonIP and LAN/
Legacy

TCP/ UDP

137, 138, 139

NetBIOS over IP (MS Windows)

netbios

12.0(5)XE2
12.1(1)E
12.1(5)T

NTP

Misc.

TCP/ UDP

123

Network Time Protocol

ntp

12.0(5)XE2
12.1(1)E
12.1(5)T

Printer

Misc.

TCP/ UDP

515

Printer

printer

12.1(2)E
12.1(5)T

X Windows

Misc.

TCP

6000-6003

X11, X Windows

xwindows

12.0(5)XE2
12.1(1)E
12.1(5)T

r-commands

Misc.

TCP

Stateful Protocol

rsh, rlogin, rexec

rcmd

12.0(5)XE2
12.1(1)E
12.1(5)T

H.323

Voice

TCP

Stateful Protocol

H.323 Teleconferencing protocol

h323

12.3.(7)T

RTCP

Voice

TCP/ UDP

Stateful Protocol

Real-time Control Protocol

rtcp

12.1E
12.2T
12.3
12.3T
12.3(7)T

RTP

Voice

TCP/ UDP

Stateful Protocol

Real-Time Transport Protocol Payload Classification

rtp

12.2(8)T

SIP

Voice

TCP/UPD

5060

Session Initiation Protocol

sip

12.3(7)T

SCCP/ Skinny

Voice

TCP

2000, 2001, 2002

Skinny Client Control Protocol

skinny

12.3(7)T

Skype

Voice

TCP/ UPD

Stateful Protocol

peer-to-peer VoIP client software

Note Cisco currently supports Skype version 1 only.

skype

12.4(4)T

BitTorrent

Peer-to-Peer file sharing applications

TCP

Stateful Protocol, or
6881-6889

BitTorrent file transfer traffic

bittorrent

12.4(2)T

Direct Connect

Peer-to-Peer file sharing applications

TCP/ UDP

411

Direct Connect file transfer traffic

directconnect

12.4(4)T

eDonkey/ eMule

Peer-to-Peer file sharing applications

TCP

4662

eDonkey file sharing application

eMule traffic is also classified as eDonkey traffic in NBAR

edonkey

12.3(11)T

FastTrack

Peer-to-Peer file sharing applications

N/A

Stateful Protocol

FastTrack

fasttrack

12.1(12c)E

Gnutella

Peer-to-Peer file sharing applications

TCP

Stateful Protocol

Gnutella

gnutella

12.1(12c)E

KaZaA

Peer-to-Peer file sharing applications

TCP/ UPD

Stateful Protocol

KaZaA

Note that earlier KaZaA version 1 traffic can be classified using FastTrack.

kazaa2

12.2(8)T

WinMX

Peer-to-Peer file sharing applications

TCP

6699

WinMX traffic

winmx

12.3(7)T

1 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.

2 In Release 12.3(4)T, the NBAR Extended Inspection for Hypertext Transfer Protocol (HTTP) Traffic feature was introduced. This feature allows NBAR to scan TCP ports that are not well-known and that identify HTTP traffic traversing these ports.


Memory Management

NBAR uses approximately 150 bytes of DRAM for each flow that requires stateful inspection. (See Table 2 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.

How to Configure NBAR

The NBAR feature has two components: one component monitors applications traversing a network, and the other classifies traffic by protocol.

In order to monitor applications traversing a network, Protocol Discovery needs to be enabled.

The ability to classify traffic by protocol using NBAR and then applying QoS to the classified traffic is configured by using the Modular QoS CLI.

The Modular QoS CLI structure allows users to create traffic policies and attach these policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to classify traffic, while the QoS features in the traffic policy determine how to treat the classified traffic.

Modular QoS CLI configuration includes the following three steps:


Step 1 Define a traffic class with the class-map command.

Step 2 Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command).

Step 3 Attach the traffic policy to the interface with the service-policy command.


NBAR traffic classification occurs as part of the traffic class configuration.

For additional information on the Modular Quality of Service Command-Line Interface, see the "Configuring the Modular Quality of Service Command-Line Interface" section of the Cisco IOS Quality of Service Solution Guide on Cisco.com.

This section contains the following procedures:

Enabling Protocol Discovery (optional)

Configuring a Traffic Class (required)

Configuring a Traffic Policy (required)

Attaching a Traffic Policy to an Interface (required)

Downloading PDLMs (optional)

Enabling Protocol Discovery

Enable protocol discovery to monitor selected protocols on an interface. Use the ip nbar protocol-discovery command in order to enable monitoring of applications on a particular interface

SUMMARY STEPS

1. enable

2. configure terminal

3. interface

4. ip nbar protocol-discovery

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

Router> enable
Example:
Router> enable

Enables privileged EXEC mode.

Enter your password if prompted

Step 2 

Router# configure terminal
Example:
Router> enable

Enters global configuration mode.

Step 3 

Router(config)# interface interface-name
Example:
Router# configure terminal

Specifies the interface to configure and enters interface configuration mode.

Step 4 

Router(config-if)# ip nbar protocol-discovery
Example:
Router# ip nbar protocol-discovery

Enables monitoring by application on a particular interface.

Configuring a Traffic Class

Configure the interface to define a traffic class and the match criteria that will be used to classify network traffic when attached to an interface. When using NBAR to classify traffic, the match protocol command will be entered in class map configuration mode. Use the class-map configuration command to configure the interface.

SUMMARY STEPS

1. enable

2. configure terminal

3. class-map[match-all | match-any] class-name

4. match protocol protocol-name

DETAILED STEPSS

 
Command or Action
Purpose

Step 1 

Router> enable
Example:
Router> enable

Enables privileged EXEC mode.

Enter your password if prompted

Step 2 

Router# configure terminal
Example:
Router# configure terminal

Enters global configuration mode.

Step 3 

Router(config)# class-map[match-all | match-any] 
class-name
Example:
Router(config)# class-map[match-all | match-any] 
ex-name

Specifies the user-defined name of the traffic class.

The match-all option specifies that all match criteria in the class map must be matched.

The match-any option specifies that one or more match criteria must match.

Step 4 

Router(config-cmap)# match protocol 
protocol-name
Example:
Router(config-cmap)# match protocol ip

Specifies a protocol supported by NBAR as a matching criteria.

Configuring a Traffic Policy

Use the policy-map configuration command to specify the QoS policies, such as Traffic Policing, Traffic Shaping, Low Latency Queueing, Class-Based Marking, Class-Based Weighted Fair Queueing or others, to apply to traffic classes defined by a traffic class. A traffic policy does not classify and forward traffic until being attached to an interface.

SUMMARY STEPS

SUMMARY STEPS

1. enable

2. configure terminal

3. policy-map policy-map-name

4. class {class-name | class-default}

5. bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}

6. end


Note Note The bandwidth command configures the QoS feature class-based weighted fair queuin (CBWFQ). CBWFQ is just an example of a QoS feature that can be configured. Use the appropriate command for the QoS feature you want to use.


DETAILED STEPS

 
Command or Action
Purpose

Step 1 

Router> enable
Example:
Router> enable

Enables privileged EXEC mode.

Enter your password if prompted

Step 2 

Router# configure terminal
Example:
Router# configure terminal

Enters global configuration mode.

Step 3 

Router(config)# policy-map policy-name
Example:
Router(config)# policy-map ex-name

User-specified policy map name.

Step 4 

Router(config-pmap)# class class-name
Example:
Router(config-pmap)# class ex-name

Specifies the name of a previously defined class map.

Step 5 

bandwidth {bandwidth-kbps | remaining percent 
percentage | percent percentage}

Example:
Router(config-pmap-c)# bandwidth percent 50

(Optional) Specifies or modifies the bandwidth allocated for a class belonging to a policy map.

Enter the amount of bandwidth as a number of kbps, a relative percentage of bandwidth, or an absolute amount of bandwidth.

Note The bandwidth command configures the QoS feature class-based weighted fair queuing (CBWFQ). CBWFQ is just an example of a QoS feature that can be configured. Use the appropriate command for the QoS feature you want to use.

For additional information on policy map options in the Modular Quality of Service Command-Line Interface, see the Modular Quality of Service Command-Line Interface document on Cisco.com.

Attaching a Traffic Policy to an Interface

A traffic policy is not active until it has been attached to an interface. Perform this task to attach a traffic policy to an interface and to specify the direction in which the policy should be applied (on either packets coming into the interface or packets leaving the interface).

SUMMARY STEPS

1. enable

2. configure terminal

3. interface interface-name

4. service-policy output policy-map-name

5. service policy input policy-map-name

DETAILED STEPS

.

 
Command or Action
Purpose

Step 1 

Router> enable
Example:
Router> enable

Enables privileged EXEC mode.

Enter your password if prompted

Step 2 

Router# configure terminal
Example:
Router# configure terminal

Enters global configuration mode.

Step 3 

Router(config)# interface interface-name
Example:
Router(config)# interface ex-name

Specifies the interface to configure and enter the interface configuration mode.

Step 4 

Router(config-if)# service-policy output 
policy-map-name
Example:
Router(config-if)# service-policy output 
ex-map-name

Attaches the previously configured traffic policy in the outbound direction of the interface. When this command is entered, all traffic leaving the interface will be classified and forwarded based on the traffic policy configuration.

Step 5 

Router(config-if)# service-policy input 
policy-map-name
Example:
Router(config-if)# service-policy input 
ex-map-name

Attaches the previously configured traffic policy in the input direction of the interface. When this command is entered, all traffic entering the interface will be classified and forwarded based on the traffic policy configuration.

Use the no service-policy [input | output] policy-map-name command to detach a policy map from an interface.

Downloading PDLMs

PDLMs are separate files that are used to add support for a protocol in NBAR that is currently not available as part of the Cisco IOS software. PDLMs do have minimum IOS release and other restrictions that should be considered before being downloaded. The PDLM readmes provide information regarding restrictions for the specific PDLM and other information helpful for installing that particular PDLM.

Before loading PDLMs, note that protocols introduced via PDLM are added to a future Cisco IOS release. Therefore, support for the protocol you would like to add via PDLM may already be in your Cisco IOS release. To check the protocols supported by NBAR in your Cisco IOS release, enter the match protocol ? command and view the options that appear.

To download a PDLM, view a list of currently available PDLMs, or to view the readme files for each PDLM, go to the following URL (Cisco login required): http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm

The PDLM readmes at this site explain how to download the PDLM onto your Cisco IOS release. For all PDLM downloads, the ip nbar pdlm command needs to be entered to complete the addition of the protocol to your Cisco IOS release. To complete the PDLM download process, enter the following command:

Command or Action
Purpose
Router(config)# ip nbar pdlm pdlm-name

Specifies the PDLM used to extend or enhance the NBAR list of protocols.


Verifying the Configuration

Use the show policy-map interface-spec [input | output] class class-name command to display the configuration of a policy map and its associated class maps. Forms of this command are listed below.

SUMMARY STEPS

1. enable

2. show class-map [class-map-name]

3. show policy-map [policy-map]

4. show policy-map interface interface-name [vc [vpi/] vci] [dlci dlci] [input | output]

5. show ip nbar port-map [protocol-name]

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable
Example:

Router> enable


Enables privileged EXEC mode.

Enter your password if prompted.Router# show class-map

Step 2 

Router# show class-map class-name
Example:

Router> show class-map ex-name


(Optional) Displays all class maps and their matching criteria.

(Optional) Enter the name of a specific class map.

Step 3 

Router# show policy-map
Example:

Router> show policy-map


(Optional) Displays the configuration of all classes for a specified service policy map or all classes for all existing policy maps;

·(Optional) Enter the name of specific policy map.

Step 4 

show policy-map interface interface-name 
Example:
Router> show policy-map interface ex-interface

(Optional) Displays the packet and class statistics for all policy maps on the specified interface.

Enter the interface name.

Step 5 

show ip nbar port-map [protocol-name]
Example:
Router# show ip nbar port-map ip

(Optional) Displays the current protocol-to-port mappings in use by NBAR.

(Optional) Enter a specific protocol name.

Troubleshooting Tips

In order for the NBAR feature to function, you must enable Cisco Express Forwarding (CEF) on the router prior to configuring the NBAR feature.

Some error messages use the term "heuristic" to refer to a set of NBAR-supported protocols, and some error message documentation recommends actions to these heuristic protocols.

RTP is the only currently available heuristic protocol. If the error message or the error message documentation recommends an action to a heuristic protocol, take the recommended action on RTP.

Monitoring and Maintaining NBAR

NBAR can determine which protocols and applications are currently running on a network. NBAR includes the Protocol Discovery feature that provides an easy way of discovering application protocols operating on an interface so that appropriate QoS policies can be developed and applied. With Protocol Discovery, you can discover any protocol traffic supported by NBAR and obtain statistics associated with that protocol. Perform this task to monitor and maintain the NBAR feature.

 
Command or Action
Purpose

Step 1 

Router# show ip nbar port-map [protocol-name]

Displays the TCP/UDP port numbers used by NBAR to classify a given protocol.

Step 2 

Router# show ip nbar protocol-discovery

Displays the statistics for all interfaces on which Protocol Discovery is enabled.

Configuration Examples

This section provides the following configuration examples:

Configuring a Traffic Policy with NBAR

Adding a PDLM

Configuring a Traffic Policy with NBAR

In the following example, all SQL*Net traffic leaving fastethernet interface 0/1 is marked with the IP precedence value of 4. In the example, NBAR is used to identify SQL*Net traffic, while the treatment of SQL*Net traffic (in this case, it is forwarded with the IP precedence bit set as 4) is determined by the traffic policy configuration (the set ip precedence 4 command in policy-map class configuration mode).

Router(config)# class-map sqlnettraffic
Router(config-cmap)# match protocol sqlnet

Router(config)# policy-map sqlsetipprec1
Router(config-pmap)# class sqlnettraffic
Router(config-pmap-c)# set ip precedence 4

Router(config)# interface fastethernet 0/1
Router(config-if)# service-policy output sqlsetipprec1

Adding a PDLM

In the following example, the FastTrack PDLM, which has already been downloaded to the Flash drive, is added as an NBAR-supported protocol:

Router(config)# ip nbar pdlm flash://fasttrack.pdlm

Additional References

The following sections provide references related to NBAR.

Related Documents

Related Topic
Document Title

Access control lists (ACLs)

Access Control Lists: Overview and Guidelines

Traffic Policing (the police command)

Cisco IOS Quality of Service Solutions Command Reference, Release 12.4

Traffic Shaping (the shape command)

Cisco IOS Quality of Service Solutions Command Reference, Release 12.4

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

Cisco IOS Quality of Service Solutions Command Reference, Release 12.4

Class-Based Marking (the set commands)

Cisco IOS Quality of Service Solutions Command Reference, Release 12.4

Low Latency Queueing (the priority command)

Cisco IOS Quality of Service Solutions Command Reference, Release 12.4

Modular Quality of Service Command-Line Interface (CLI) (MQC)

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4


Standards

Standard
Title

ISO 0009

File Transfer Protocol (FTP)

ISO 0013

Domain Names - Concepts and Facilities

ISO 0033

The TFTP Protocol (Revision 2)

ISO 0034

Routing Information Protocol

ISO 0053

Post Office Protocol - Version 3

ISO 0056

RIP Version 2


MIBs

MIB
MIBs Link

CISCO-NBAR-PROTOCOL-DISCOVERY MIB

For information on the CISCO-NBAR-PROTOCOL-DISCOVERY MIB, see the Network-Based Application Recognition Management Information Base document.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs


RFCs

RFC
Title

RFC 742

NAME/FINGER Protocol

RFC 759

Internet Message Protocol

RFC 792

Internet Control Message Protocol

RFC 793

Transmission Control Protocol

RFC 821

Simple Mail Transfer Protocol

RFC 827

Exterior Gateway Protocol

RFC 854

Telnet Protocol Specification

RFC 888

"STUB" Exterior Gateway Protocol

RFC 904

Exterior Gateway Protocol formal specification

RFC 951

Bootstrap Protocol

RFC 959

File Transfer Protocol

RFC 977

Network News Transfer Protocol

RFC 1001

Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods

RFC 1002

Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications

RFC 1057

RPC: Remote Procedure Call

RFC 1094

NFS: Network File System Protocol Specification

RFC 1112

Host Extensions for IP Multicasting

RFC 1157

Simple Network Management Protocol

RFC 1282

BSD Rlogin

RFC 1288

The Finger User Information Protocol

RFC 1305

Network Time Protocol

RFC 1350

The TFTP Protocol (Revision 2)

RFC 1436

The Internet Gopher Protocol

RFC 1459

Internet Relay Chat Protocol

RFC 1510

The Kerberos Network Authentication Service

RFC 1542

Clarifications and Extensions for the Bootstrap Protocol

RFC 1579

Firewall-Friendly FTP

RFC 1583

OSPF Version 2

RFC 1657

Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol

RFC 1701

Generic Routing Encapsulation

RFC 1730

Internet Message Access Protocol - Version 4

RFC 1771

A Border Gateway Protocol 4 (BGP-4)

RFC 1777

Lightweight Directory Access Protocol

RFC 1831

RPC: Remote Procedure Call Protocol Specification Version 2

RFC 1889

A Transport Protocol for Real-Time Applications

RFC 1890

RTP Profile for Audio and Video Conferences with Minimal Control

RFC 1928

SOCKS Protocol Version 5

RFC 1939

Post Office Protocol - Version 3

RFC 1945

Hypertext Transfer Protocol -- HTTP/1.0

RFC 1964

The Kerberos Version 5 GSS-API Mechanism

RFC 2060

Internet Message Access Protocol - Version 4rev1

RFC 2068

Hypertext Transfer Protocol -- HTTP/1.1

RFC 2131

Dynamic Host Configuration Protocol

RFC 2205

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

RFC 2236

Internet Group Management Protocol, Version 2

RFC 2251

Lightweight Directory Access Protocol (v3)

RFC 2252

Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

RFC 2253

Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names

RFC 2326

Real Time Streaming Protocol (RTSP)

RFC 2401

Security Architecture for the Internet Protocol

RFC 2406

IP Encapsulating Security Payload

RFC 2453

RIP Version 2

RFC 2616

Hypertext Transfer Protocol -- HTTP/1.1


Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport


Command Reference

This section documents modified commands only.

ip nbar custom

match protocol (NBAR)

match protocol citrix

match protocol http

ip nbar custom

To extend the capability of network-based application recognition (NBAR) Protocol Discovery to classify and monitor additional static port applications or to allow NBAR to classify nonsupported static port traffic, use the ip nbar custom command in global configuration mode. To disable NBAR from classifying and monitoring addtional static port application or classifying nonsupported static port traffic, use the no form of this command.

ip nbar custom name [offset [format value]] [variable field-name field-length] [source|destination] [tcp | udp] [range start end | port-number]

no ip nbar custom name [offset [format value]] [variable field-name field-length] [source|destination] [tcp | udp] [range start end | port-number]

Syntax Description

name

The name given to the custom protocol. This name is reflected wherever the name is used, including NBAR Protocol Discovery, the match protocol command, the ip nbar port-map command, and the NBAR Protocol Discovery MIB.

The name must be no longer than 24 characters and can only contain uppercase and lowercase letters, digits, and the underscore (_) character.

offset

(Optional) A digit representing the byte location for payload inspection. The offset function is based on the beginning of the payload directly after the TCP or User Datagram Protocol (UDP) header.

format value

(Optional) Defines the format of the value and the length of the value that is being inspected in the packet payload. Current format options are ascii, hex, and decimal. The length of the value is dependent on the chosen format. The length restrictions for each format are listed below:

ascii—Up to 16 characters can be searched. Regular expressions are not supported.

hex—Up to 4 bytes.

decimal—Up to 4 bytes.

variable field-name field-length

(Optional) When the variable keyword is entered, a specific portion of the custom protocol can be treated as an NBAR-supported protocol (for example, a specific portion of the custom protocol can be tracked using class-map statistics and can be matched using the class-map command). If the variable keyword is entered, the following fields must be defined:

field-name—Provides a name for the field to search in the payload. After a custom protocol is configured using a variable, this field-name can be used with up to 24 different values per router configuration.

field-length—Enters the field length in bytes. The field length can be up to 4 bytes, so the field-length value can be entered as 1, 2, 3, or 4.

source | destination

(Optional) Specifies the direction in which packets are inspected. If source or destination is not specified, all packets traveling in either direction are monitored by NBAR.

tcp | udp

(Optional) Specifies the TCP or the UDP implemented by the application.

range start end

(Optional) Specifies a range of ports that the custom application monitors. The start is the first port in the range, and the end is the last port in the range. One range of up to 1000 ports can be specified for each custom protocol.

port-number

(Optional) The port that the custom application monitors. Up to 16 individual ports can be specified as a single custom protocol.


Defaults

If source or destination is not specified, traffic flowing in both directions is inspected if the custom protocol is enabled in NBAR.

Command Modes

Global configuration

Command History

Release
Modification

12.3(4)T

This command was introduced.

12.3(11)T

The variable field-name field-length keyword-argument group was introduced.


Usage Guidelines

More than 30 custom applications can be created on the router.

NBAR can support up to 128 protocols total.

If the variable keyword is entered while you configure the custom protocol, traffic statistics for the variable appear in some NBAR class map show outputs.

Up to 24 variable values per custom protocol can be expressed in class maps. For instance, in the following configuration, 4 variables are used and 20 more "scid" values could be used.

ip nbar custom ftdd 125 variable scid 1 tcp range 5001 5005

class-map match-any active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21

class-map match-any passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22

Examples

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

ip nbar custom app_sales1 5 ascii SALES source tcp 4567

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

ip nbar custom virus_home 7 hex 0x56 dest udp 3000

In the following example, custom protocol "media_new" identifies TCP packets with a destination or source port of 4500 and have a value of 90 in the sixth byte of the payload:

ip nbar custom media_new 6 decimal 90 tcp 4500

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

ip nbar custom msn1 tcp 6700

In the following example, custom protocol "mail_x" looks for UDP packets with a destination port of 8202.

ip nbar custom mail_x destination udp 8202

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

ip nbar custom mail_y destination udp range 3000 4000 5500

In the following example, custom protocol "ftdd" is created by using a variable. A class map matching this custom protocol based on the variable is also created. In this example, class map "matchscidinftdd" matches all traffic that has the value "804" at byte 125 entering or leaving TCP ports 5001 to 5005. The variable scid is 2 bytes in length.

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd 
match protocol ftdd scid 804

The same example above can also be done using hexadecimal values in the class map as follows:

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd
match protocol ftdd scid 0x324

In the following example, the variable keyword is used while you create a custom protocol, and class maps are configured to classify different values within the variable field into different traffic classes. Specifically, in the example below, variable scid values 0x15, 0x21, and 0x27 are classified into class map "active-craft" while scid values 0x11, 0x22, and 0x25 are classified into class map "passive-craft."


ip nbar custom ftdd 125 variable scid 1 tcp range 5001 5005

class-map match-any active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21
match protocol ftdd scid 0x27

class-map match-any passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22
match protocol ftdd scid 0x25

match protocol (NBAR)

To configure network-based application recognition (NBAR) to match traffic by a protocol type known to NBAR, use the match protocol command in class-map configuration mode. To disable NBAR from matching traffic by a known protocol type, use the no form of this command.

match protocol protocol-name [variable-field-name value]

no match protocol protocol-name [variable-field-name value]

Syntax Description

protocol-name

Identifies a particular protocol type known to NBAR. These known protocol types can be used to match traffic. For a list of protocol types known to NBAR, see Table 3 in "Usage Guidelines."

variable-field-name

(Optional and only usable with custom protocols) Used for specifying a predefined variable that was created when you created a custom protocol. The variable-field-name will match the field-name variable entered when you created the custom protocol.

value

(Optional and only usable with custom protocols) A specific value in the custom payload to match. A value can only be entered along with a variable-field-name. The value can be expressed in decimal or hexadecimal format.


Defaults

No default behavior or values.

Command Modes

Class-map configuration

Command History

Release
Modification

12.0(5)XE2

This command was introduced.

12.1(1)E

This command was integrated into Cisco IOS Release 12.1(1)E. The variable-field-name value option was added.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.1(13)T

This command was integrated into Cisco IOS Release 12.1(13)T. This command became available on Catalyst 6000 family switches without FlexWAN modules.

12.2(8)T

This command was integrated into Cisco IOS Release 12.2(8)T.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.4(2)T

Documentation for this command was updated for Cisco IOS Release 12.4(2)T.


Usage Guidelines

Use the match protocol (NBAR) command to match protocol types that are known to NBAR. NBAR is capable of classifying the following types of protocols:

Non-User Datagram Protocol (UDP) and non-Transmission Control Protocol (TCP) IP protocols

TCP and UDP protocols that use statically assigned port numbers

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

Table 1 lists the protocols NBAR can classify.

Table 3 NBAR Supported Protocols 

Protocol
Category
Type
Well-Known Port Number
Description
Syntax
Cisco IOS Release1

Citrix ICA

Enterprise Application

TCP/
UDP

Stateful Protocol

Citrix ICA traffic by application name

citrix
citrix app

12.1(2)E
12.1(5)T

PCAnywhere

Enterprise Application

TCP

5631, 65301

Symantic pcAnywhere

pcanywhere

12.0(5)XE2
12.1(1)E
12.1(5)T

PCAnywhere

Enterprise Application

UDP

22, 5632

Symantic pcAnywhere

pcanywhere

12.0(5)XE2
12.1(1)E
12.1(5)T

Novadigm

Enterprise Application

TCP/ UDP

3460- 3465

Novadigm Enterprise Desktop Manager  (EDM)

novadigm

12.1(2)E
12.1(5)T

SAP

Enterprise Application

TCP

3300-3315 (sap-pgm. pdlm)
3200-3215 (sap-app. pdlm)
3600-3615 (sap-msg. pdlm)

Application server to application server traffic (sap-pgm.pdlm)

Client to application server traffic (sap-app.pdlm)

Client to message server traffic (sap-msg.pdlm)

sap

12.3
12.3 T
12.2 T
12.1 E

BGP

Routing Protocol

TCP/ UDP

179

Border Gateway Protocol

bgp

12.0(5)XE2
12.1(1)E
12.1(5)T

EGP

Routing Protocol

IP

8

Exterior Gateway Protocol

egp

12.0(5)XE2
12.1(1)E
12.1(5)T

EIGRP

Routing Protocol

IP

88

Enhanced Interior Gateway Routing Protocol

eigrp

12.0(5)XE2
12.1(1)E
12.1(5)T

OSPF

Routing Protocol

TCP

Stateful Protocol

Open Shortest Path First

ospf

12.3(8)T

RIP

Routing Protocol

UDP

520

Routing Information Protocol

rip

12.0(5)XE2
12.1(1)E
12.1(5)T

SQL*NET

Database

TCP/ UDP

Stateful Protocol

SQL*NET for Oracle

sqlnet

12.0(5)XE2
12.1(1)E
12.1(5)T

MS- SQLServer

Database

TCP

1433

Microsoft SQL Server Desktop Videoconferencing

sqlserver

12.0(5)XE2
12.1(1)E
12.1(5)T

GRE

Security and Tunneling

IP

47

Generic Routing Encapsulation

gre

12.0(5)XE2
12.1(1)E
12.1(5)T

IPINIP

Security and Tunneling

IP

4

IP in IP

ipinip

12.0(5)XE2
12.1(1)E
12.1(5)T

IPSec

Security and Tunneling

IP

50, 51

IP Encapsulating Security Payload/Authentication Header

ipsec

12.0(5)XE2
12.1(1)E
12.1(5)T

L2TP

Security and Tunneling

UDP

1701

L2F/L2TP tunnel

l2tp

12.0(5)XE2
12.1(1)E
12.1(5)T

MS-PPTP

Security and Tunneling

TCP

1723

Microsoft Point-to-Point Tunneling Protocol for VPN

pptp

12.0(5)XE2
12.1(1)E
12.1(5)T

SFTP

Security and Tunneling

TCP

990

Secure FTP

secure-ftp

12.0(5)XE2
12.1(1)E
12.1(5)T

SHTTP

Security and Tunneling

TCP

443

Secure HTTP

secure-http

12.0(5)XE2
12.1(1)E
12.1(5)T

SIMAP

Security and Tunneling

TCP/
UDP

585, 993

Secure IMAP

secure-imap

12.0(5)XE2
12.1(1)E
12.1(5)T

SIRC

Security and Tunneling

TCP/
UDP

994

Secure IRC

secure-irc

12.0(5)XE2
12.1(1)E
12.1(5)T

SLDAP

Security and Tunneling

TCP/
UDP

636

Secure LDAP

secure-ldap

12.0(5)XE2
12.1(1)E
12.1(5)T

SNNTP

Security and Tunneling

TCP/
UDP

563

Secure NNTP

secure-nntp

12.0(5)XE2
12.1(1)E
12.1(5)T

SPOP3

Security and Tunneling

TCP/
UDP

995

Secure POP3

secure-pop3

12.0(5)XE2
12.1(1)E
12.1(5)T

STELNET

Security and Tunneling

TCP

992

Secure Telnet

secure-telnet

12.0(5)XE2
12.1(1)E
12.1(5)T

SOCKS

Security and Tunneling

TCP

1080

Firewall security protocol

socks

12.0(5)XE2
12.1(1)E
12.1(5)T

SSH

Security and Tunneling

TCP

22

Secured Shell

ssh

12.0(5)XE2
12.1(1)E
12.1(5)T

ICMP

Network Management

IP

1

Internet Control Message Protocol

icmp

12.0(5)XE2
12.1(1)E
12.1(5)T

SNMP

Network Management

TCP/
UDP

161, 162

Simple Network Management Protocol

snmp

12.0(5)XE2
12.1(1)E
12.1(5)T

Syslog

Network Management

UDP

514

System Logging Utility

syslog

12.0(5)XE2
12.1(1)E
12.1(5)T

IMAP

Network Mail Services

TCP/
UDP

143, 220

Internet Message Access Protocol

imap

12.0(5)XE2
12.1(1)E
12.1(5)T

POP3

Network Mail Services

TCP/
UDP

110

Post Office Protocol

pop3

12.0(5)XE2
12.1(1)E
12.1(5)T

Exchange

Network Mail Services

TCP

 

MS-RPC for Exchange

exchange

12.0(5)XE2
12.1(1)E
12.1(5)T

Notes

Network Mail Services

TCP/
UDP

1352

Lotus Notes

notes

12.0(5)XE2
12.1(1)E
12.1(5)T

SMTP

Network Mail Services

TCP

25

Simple Mail Transfer Protocol

smtp

12.0(5)XE2
12.1(1)E
12.1(5)T

DHCP/
BOOTP

Directory

UDP

67, 68

Dynamic Host Configuration Protocol/ Bootstrap Protocol

dhcp

12.0(5)XE2
12.1(1)E
12.1(5)T

Finger

Directory

TCP

79

Finger user information protocol

finger

12.0(5)XE2
12.1(1)E
12.1(5)T

DNS

Directory

TCP/
UDP

53

Domain Name System

dns

12.0(5)XE2
12.1(1)E
12.1(5)T

Kerberos

Directory

TCP/
UDP

88, 749

Kerberos Network Authentication Service

kerberos

12.0(5)XE2
12.1(1)E
12.1(5)T

LDAP

Directory

TCP/
UDP

389

Lightweight Directory Access Protocol

ldap

12.0(5)XE2
12.1(1)E
12.1(5)T

CU-SeeMe

Streaming Media

TCP/
UDP

7648, 7649

Desktop video conferencing

cuseeme

12.0(5)XE2
12.1(1)E
12.1(5)T

CU-SeeMe

Streaming Media

UDP

24032

Desktop video conferencing

cuseeme

12.0(5)XE2
12.1(1)E
12.1(5)T

Netshow

Streaming Media

TCP/ UDP

Stateful Protocol

Microsoft Netshow

netshow

12.0(5)XE2
12.1(1)E
12.1(5)T

RealAudio

Streaming Media

TCP/ UDP

Stateful Protocol

RealAudio Streaming Protocol

realaudio

12.0(5)XE2
12.1(1)E
12.1(5)T

StreamWorks

Streaming Media

UDP

Stateful Protocol

Xing Technology Stream Works audio and video

streamwork

12.0(5)XE2
12.1(1)E
12.1(5)T

VDOLive

Streaming Media

TCP/ UDP

Stateful Protocol

VDOLive Streaming Video

vdolive

12.0(5)XE2
12.1(1)E
12.1(5)T

RTSP

Streaming Media/ Multimedia

TCP/ UDP

Stateful Protocol

Real-time Streaming Protocol

rtsp

12.3(11)T

MGCP

Streaming Media/ Multimedia

TCP/ UDP

2427, 2428, 2727

Media Gateway Control Protocol

mgcp

12.3(7)T

FTP

Internet

TCP

Stateful Protocol

File Transfer Protocol

ftp

12.0(5)XE2
12.1(1)E
12.1(5)T

Gopher

Internet

TCP/ UDP

70

Internet Gopher Protocol

gopher

12.0(5)XE2
12.1(1)E
12.1(5)T

HTTP

Internet

TCP

802

Hypertext Transfer Protocol

http

12.0(5)XE2
12.1(1)E
12.1(5)T

IRC

Internet

TCP/ UDP

194

Internet Relay Chat

irc

12.0(5)XE2
12.1(1)E
12.1(5)T

Telnet

Internet

TCP

23

Telnet Protocol

telnet

12.0(5)XE2
12.1(1)E
12.1(5)T

TFTP

Internet

UDP

Stateful Protocol

Trivial File Transfer Protocol

tftp

12.0(5)XE2
12.1(1)E
12.1(5)T

NNTP

Internet

TCP/ UDP

119

Network News Transfer Protocol

nntp

12.0(5)XE2
12.1(1)E
12.1(5)T

RSVP

Signaling

UDP

1698, 1699

Resource Reservation Protocol

rsvp

12.0(5)XE2
12.1(1)E
12.1(5)T

NFS

RPC

TCP/ UDP

2049

Network File System

nfs

12.0(5)XE2
12.1(1)E
12.1(5)T

Sunrpc

RPC

TCP/ UDP

Stateful Protocol

Sun Remote Procedure Call

sunrpc

12.0(5)XE2
12.1(1)E
12.1(5)T

NetBIOS

Non-IP and LAN/
Legacy

TCP/ UDP

137, 138, 139

NetBIOS over IP (MS Windows)

netbios

12.0(5)XE2
12.1(1)E
12.1(5)T

NTP

Misc.

TCP/ UDP

123

Network Time Protocol

ntp

12.0(5)XE2
12.1(1)E
12.1(5)T

Printer

Misc.

TCP/ UDP

515

Printer

printer

12.1(2)E
12.1(5)T

X Windows

Misc.

TCP

6000-6003

X11, X Windows

xwindows

12.0(5)XE2
12.1(1)E
12.1(5)T

r-commands

Misc.

TCP

Stateful Protocol

rsh, rlogin, rexec

rcmd

12.0(5)XE2
12.1(1)E
12.1(5)T

H.323

Voice

TCP

Stateful Protocol

H.323 Teleconferencing protocol

h323

12.3.(7)T

RTCP

Voice

TCP/ UDP

Stateful Protocol

Real-time Control Protocol

rtcp

12.1E
12.2T
12.3
12.3T
12.3(7)T

RTP

Voice

TCP/ UDP

Stateful Protocol

Real-Time Transport Protocol Payload Classification

rtp

12.2(8)T

SIP

Voice

TCP/UPD

5060

Session Initiation Protocol

sip

12.3(7)T

SCCP/ Skinny

Voice

TCP

2000, 2001, 2002

Skinny Client Control Protocol

skinny

12.3(7)T

BitTorrent

Peer-to-Peer file sharing applications

TCP

Stateful Protocol, or
6881-6889

BitTorrent file transfer traffic

bittorrent

12.4(2)T

Direct Connect

Peer-to-Peer file sharing applications

TCP/ UDP

411

Direct Connect file transfer traffic

directconnect

12.1E
12.2T
12.3
12.3T

eDonkey/ eMule

Peer-to-Peer file sharing applications

TCP

4662

eDonkey file sharing application

eMule traffic is also classified as eDonkey traffic in NBAR

edonkey

12.3(11)T

FastTrack

Peer-to-Peer file sharing applications

N/A

Stateful Protocol

FastTrack

fasttrack

12.1(12c)E

Gnutella

Peer-to-Peer file sharing applications

TCP

Stateful Protocol

Gnutella

gnutella

12.1(12c)E

KaZaA

Peer-to-Peer file sharing applications

TCP/ UPD

Stateful Protocol

KaZaA

Note that earlier KaZaA version 1 traffic can be classified using FastTrack.

kazaa2

12.2(8)T

Napster

Peer-to-Peer file sharing applications

TCP

Stateful Protocol

Napster traffic

napster

12.1(5)T

WinMX

Peer-to-Peer file sharing applications

TCP

6699

WinMX traffic

winmx

12.3(7)T

1 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.

2 In Release 12.3(4)T, the NBAR Extended Inspection for Hypertext Transfer Protocol (HTTP) Traffic feature was introduced. This feature allows NBAR to scan TCP ports that are not well-known and that identify HTTP traffic traversing these ports.


Custom Protocols Created with the ip nbar custom Command

The variable-field-name value is used in conjunction with the variable field-name field-length options that are entered when you create a custom protocol using the ip nbar custom command. The variable option allows NBAR to match based on a specific value of a custom protocol. For instance, if ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005 is entered to create a custom protocol, and then a class map using the match protocol ftdd scid 804 is created, the created class map will match all traffic that has the value "804" at byte 125 entering or leaving TCP ports 5001 to 5000.

Up to 24 variable values per custom protocol can be expressed in class maps. For instance, in the following configuration, 4 variables are used and 20 more "scid" values could be used.

ip nbar custom ftdd field scid 125 variable 1 tcp range 5001 5005

class-map active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21

class-map passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22

Examples

The following example configures NBAR to match FTP traffic:

match protocol ftp

In the following example, custom protocol ftdd is created by using a variable. A class map matching this custom protocol based on the variable is also created. In this example, class map matchscidinftdd will match all traffic that has the value "804" at byte 125 entering or leaving TCP ports 5001 to 5005 . The variable scid is 2 bytes in length.

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd 
match protocol ftdd scid 804

The same example above can also be done by using hexadecimal values in the class map as follows:

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd
match protocol ftdd scid 0x324

In the following example, the variable keyword is used while you create a custom protocol, and class maps are configured to classify different values within the variable field into different traffic classes. Specifically, in the example below, variable scid values 0x15, 0x21, and 0x27 will be classified into class map active-craft while scid values 0x11, 0x22, and 0x25 will be classified into class map passive-craft.


ip nbar custom ftdd field scid 125 variable 1 tcp range 5001 5005

class-map active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21
match protocol ftdd scid 0x27

class-map passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22
match protocol ftdd scid 0x25

Related Commands

Command
Description

class-map

Creates a class map to be used for matching packets to a specified class.

ip nbar custom

Extends the capability of NBAR Protocol Discovery to classify and monitor additional static port applications, or allows NBAR to classify nonsupported static port traffic.


match protocol citrix

To configure network-based application recognition (NBAR) to match Citrix traffic, use the match protocol citrix command in class-map configuration mode. To disable NBAR from matching Citrix traffic, use the no form of this command.

match protocol citrix [app application-name-string] [ica-tag ica-tag-value]

no match protocol citrix [app application-name-string] [ica-tag ica-tag-value]

Syntax Description

app

(Optional) Specifies matching of an application name string.

application-name-string

(Optional) Specifies the string to be used as the subprotocol parameter.

ica-tag

(Optional) Specifies tagging of ICA packets.

ica-tag-value

(Optional) Specifies the priority tag of ICA packets. Value: 0 to 3.


Defaults

No match criteria are specified.

Command Modes

Class-map configuration

Command History

Release
Modification

12.1(2)E

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.1(13)E

This command was implemented on Catalyst 6000 family switches without FlexWAN modules.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.4(2)T

The ica-tag keyword was introduced.


Usage Guidelines

Entering the match protocol citrix command without the app keyword establishes all Citrix traffic as successful match criteria.

Entering the match protocol citrix command with the ica-tag keyword prioritizes Citrix ICA traffic. The priority tag values can be a number from 0 to 3, with 0 having the highest priority and 3 the lowest.

Examples

The following example configures NBAR to match all Citrix traffic:

match protocol citrix

The following example configures NBAR to match Citrix traffic with the application name of packet1:

match protocol citrix app packet1

The following example configures NBAR to give Citrix ICA traffic a priority of 1:

match protocol citrix ica-tag-1

match protocol http

To configure network-based application recognition (NBAR) to match HTTP traffic by URL, host, MIME type, or fields in HTTP packet headers, use the match protocol http command in class map configuration mode. To disable NBAR from matching HTTP traffic by URL, host, or MIME type, use the no form of this command.

match protocol http [url url-string | host hostname-string | mime MIME-type | c-header-field c-header-field-string | s-header-field s-header-field-string]

no match protocol http [url url-string | host hostname-string | mime MIME-type | c-header-field c-header-field-string | s-header-field s-header-field-string]

Syntax Description

url

Specifies matching by a URL.

url-string

User-specified URL of HTTP traffic to be matched.

host

Specifies matching by a hostname.

hostname-string

User-specified host name to be matched.

mime

Specifies matching by MIME text string.

MIME-type

User-specified MIME text string to be matched.

c-header-field

Specifies matching by a string in the header field in HTTP client messages.

Note HTTP client messages are often called HTTP request messages.

c-header-field-string

User-specified text string within the HTTP client message (HTTP request message) to be matched.

s-header-field

Specifies matching by a string in the header field in the HTTP server messages

Note HTTP server messages are often called HTTP response messages.

s-header-field-string

User-specified text within the HTTP server message (HTTP response message) to be matched.


Defaults

No default behavior or values.

Command Modes

Class map configuration

Command History

Release
Modification

12.0(5)XE2

This command was introduced.

12.1(1)E

This command was introduced for the Cisco IOS Release 12.1 E train.

12.1(2)E

This command was enhanced to include the hostname-string variable.

12.1(5)T

This command was introduced for the Cisco IOS Release 12.1 T train.

12.1(13)E

This command became available on Catalyst 6000 family switches without FlexWAN modules.

12.2(14)S

This command was introduced for the Cisco IOS Release 12.2 S train.

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.

12.4(2)TT

The c-header-field c-header-field-string and s-header-field s-header-field-string options were introduced.


Usage Guidelines

Usage Guidelines Regarding Classification of HTTP Traffic by Host, URL, or MIME

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 that identify HTTP traffic traversing these ports. This feature is enabled automatically when a service policy containing the match protocol http command is attached to an interface.

When matching by MIME type, the MIME type can contain any user-specified text string. Refer to the following web page for the IANA-registered MIME types:

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

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

When matching by host, NBAR performs a regular expression match on the host field contents inside the HTTP packet and classifies all packets from that host.

HTTP URL matching supports GET, PUT, HEAD, POST, DELETE, and TRACE. When matching by URL, NBAR recognizes the HTTP packets containing the URL, and then matches all packets that are part of the HTTP request. When specifying a URL for classification, include only the portion of the URL following www.hostname.domain in the match statement. For example, in the URL www.anydomain.com/latest/whatsnew.html, include only /latest/whatsnew.html.

To match the www.anydomain.com portion, use the host name matching feature. The URL or host specification strings can take the form of a regular expression with the following options:

Option
Description

*

Match any zero or more characters in this position.

?

Match any one character in this position.

|

Match one of a choice of characters.

(|)

Match one of a choice of characters in a range. For example foo.(gif | jpg) matches either foo.gif or foo.jpg.

[ ]

Match any character in the range specified, or one of the special characters. For example, [0-9] is all of the digits. [*] is the "*" character and [[] is the "[" character.


Usage Guidelines Regarding Classification of 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 back 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. This document can be read at the following URL:

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

For request messages (client to server), the following HTTP header fields can be identified by using NBAR:

User-Agent

Referer

From

For response messages (server to client), the following header fields can be identifiedby using NBAR:

Server

Location

Content-Base

Content-Encoding

Within NBAR, the match protocol http c-header-field command is used to specify request messages (the "c" in the c-header-field portion of the command is for client). The match protcol 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).

It is important to note that combinations of URL, host, MIME type, and HTTP headers can be combined during NBAR configuration. These combinations provide customers with more flexibility to classify specific HTTP traffic based on their network requirements.

Examples

The following example classifies, within class map foo, HTTP packets based on any URL containing the string whatsnew/latest followed by zero or more characters:

class-map foo
match protocol http url whatsnew/latest*

The following example classifies, within class map foo, packets based on any host name containing the string cisco followed by zero or more characters:

class-map foo
match protocol http host cisco*

The following example classifies, within class map foo, packets based on the JPEG MIME type:

class-map foo
match protocol http mime "*jpeg"

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

match protocol http c-header-field *somebody@cisco.com*

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

match protocol http c-header-field *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 fields will be classified by NBAR. Typically, a term with a format similiar to "CERN-LineMode/2.15" would be found in the User-Agent header field of the HTTP request message.

match protocol http c-header-field *CERN-LineMode/2.15*

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

match protocol http s-header-field *CERN/3.0*

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

match protocol http s-header-field *http://www.cisco.com/routers*

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

match protocol http s-header-field *gzip*

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 URL "www.cisco.com", will be classified using NBAR.

class-map match-all c-http 
match protocol http c-header-field *CERN-LineMode/3.0* 
match protocol http s-header-field *CERN/3.0* 
match protocol http url *www.cisco.com*

Glossary

Modular QoS CLI—Modular Quality of Service Command-Line Interface. A CLI for QoS features that makes configuring and implementing packet classification and QoS policies easier than with the existing CLI.

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

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 contained in the packet payload; that is, information found beyond the TCP or UDP port number.

Appendix

Sample Configuration

Below is a sample of how NBAR can be used.

E-Express Inc.'s network administrators wish to enforce the following policies on a 64-Kb WAN link:

Reserve a minimum bandwidth of 32 Kb out of the 64 Kb available on the WAN link for all e-commerce traffic. This e-commerce traffic will be secure HTTP traffic or files being served from the http://www.eexpress.com/transact/ directory through regular HTTP on the E-Express Inc. network.

SuperNetwork Inc. is a very important partner to E-Express Inc. Reserve a minimum of 10 Kb for all traffic flowing from E-Express Inc. to SuperNetwork Inc.

Limit to a maximum of 10 Kb all audio, video, and image web traffic.

Follow the steps below to configure the above policies:


Step 1 Classify all secure HTTP and HTTP traffic for the /transact/ directory:


Router(config)# class-map match-all http_transact
Router(config-cmap)# match protocol http url "/transact/*"

Router(config)# class-map match-all http_secure
Router(config-cmap)# match protocol secure-http

Router(config)# class-map match-any ecommerce
Router(config-cmap)# match class-map http_transact
Router(config-cmap)# match class-map http_secure

Step 2 Classify all traffic to SuperNetwork Inc:

Router(config)# access-list 101 permit ip 10.0.0.1 0.0.0.0 10.0.0.3 0.0.0.0

Router(config)# class-map match-all super_network
Router(config-cmap)# match access-group 101

Step 3 Classify all audio, video, and image web traffic:

Router(config)# class-map match-any audio_video
Router(config-cmap)# match protocol http mime "audio/*"
Router(config-cmap)# match protocol http mime "video/*"

Router(config)# class-map match-any web_images
Router(config-cmap)# match protocol http url "*.gif"
Router(config-cmap)# match protocol http url "*.jpg|*.jpeg"

Router(config)# class-map match-any av_im_web
Router(config-cmap)# match class-map audio_video
Router(config-cmap)# match class-map web_images


Step 4 Create the policies:

Router(config)# policy-map e-express
Router(config-pmap)# class ecommerce
Router(config-pmap-c)# bandwidth 32
Router(config-pmap-c)# class super_network
Router(config-pmap-c)# bandwidth 10
Router(config-pmap-c)# class av_im_web
Router(config-pmap-c)# police 10000 conform transmit exceed drop

Step 5 Attach the policy to the WAN link:

Router(config)# interface hssi1/0
Router(config-if)# service-policy output e-express