-
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2
-
About Cisco IOS Software Documentation
-
Using Cisco IOS Software
-
Quality of Service Overview
- Part 1: Classification
- Part 2: Congestion Management
- Part 3: Congestion Avoidance
- Part 4: Policing and Shaping
- Part 5: Signalling
- Part 6: Link Efficiency Mechanisms
- Part 7: Quality of Service Solutions
- Part 8: Modular Quality of Service Command-Line Interface
- Part 9: Security Device Manager
-
Index
-
Feedback
Table Of Contents
How the IP Precedence Bits Are Used to Classify Packets
Setting or Changing the IP Precedence Value
When Should You Use Policy-Based Routing?
QoS Policy Propagation via Border Gateway Protocol
IP Precedence and IP DSCP Marking
Support for ATM Virtual Circuits
Packet Marking Through IP Precedence, QoS Group, CoS Value, and IP DSCP Value Setting
Improved Bandwidth Management on ATM Networks
QoS for Virtual Private Networks
Network-Based Application Recognition
Classification of HTTP by URL, HOST, or MIME
Classification of Citrix ICA Traffic by Application Name
Packet Description Language Module
Classification Overview
Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. When traffic descriptors are used to classify traffic, the source agrees to adhere to the contracted terms and the network promises a quality of service. Traffic policers, such as the Traffic Policing feature and the rate-limiting feature of committed access rate (CAR), and traffic shapers, such as Generic Traffic Shaping (GTS), Distributed Traffic Shaping (DTS) and Frame Relay Traffic Shaping (FRTS), use traffic descriptor of a packet—that is, its classification—to ensure adherence to the contract.
Packet classification is pivotal to policy techniques that select packets traversing a network element or a particular interface for different types of QoS service. For example, you can use classification to mark certain packets for IP Precedence and you can identify others as belonging to a Resource Reservation Protocol (RSVP) flow.
Methods of classification were once limited to use of the contents of the packet header. Current methods of marking a packet with its classification allow you to set information in the Layer 2, 3, or 4 headers, or even by setting information within the payload of a packet. Criteria for classification of a group might be as broad as "traffic destined for subnetwork X" or as narrow as a single flow.
This chapter explains IP Precedence, then it gives a brief description of the kinds of traffic classification provided by the Cisco IOS QoS features. It discusses features described in the following sections:
•
QoS Policy Propagation via Border Gateway Protocol
•
•
About IP Precedence
Use of IP Precedence allows you to specify the class of service (CoS) for a packet. You use the three precedence bits in the type of service (ToS) field of the IP version 4 (IPv4) header for this purpose. Figure 2 shows the ToS field.
Figure 2 IPv4 Packet Type of Service Field
Using the ToS bits, you can define up to six classes of service. Other features configured throughout the network can then use these bits to determine how to treat the packet in regard to the ToS to grant it. These other QoS features can assign appropriate traffic-handling policies including congestion management strategy and bandwidth allocation. For example, although IP Precedence is not a queueing method, queueing methods such as weighted fair queueing (WFQ) and Weighted Random Early Detection (WRED) can use the IP Precedence setting of the packet to prioritize traffic.
By setting precedence levels on incoming traffic and using them in combination with the Cisco IOS QoS queueing features, you can create differentiated service. You can use features such as policy-based routing (PBR) and CAR to set precedence based on extended access list classification. These features afford considerable flexibility for precedence assignment. For example, you can assign precedence based on application or user, or by destination and source subnetwork.
So that each subsequent network element can provide service based on the determined policy, IP Precedence is usually deployed as close to the edge of the network or the administrative domain as possible. You can think of IP Precedence as an edge function that allows core, or backbone, QoS features such as WRED to forward traffic based on CoS. IP Precedence can also be set in the host or network client, but this setting can be overridden by policy within the network.
The following QoS features can use the IP Precedence field to determine how traffic is treated:
•
•
•
How the IP Precedence Bits Are Used to Classify Packets
You use the three IP Precedence bits in the ToS field of the IP header to specify CoS assignment for each packet. You can partition traffic into up to six classes—the remaining two are reserved for internal network use—and then use policy maps and extended access lists to define network policies in terms of congestion handling and bandwidth allocation for each class.
For historical reasons, each precedence corresponds to a name. These names, which continue to evolve, are defined in the RFC 791 document. Table 3 lists the numbers and their corresponding names, from least to most important.
Table 3 IP Precedence Values
0
routine
1
priority
2
immediate
3
flash
4
flash-override
5
critical
6
internet
7
network
However, the IP Precedence feature allows you considerable flexibility for precedence assignment. That is, you can define your own classification mechanism. For example, you might want to assign precedence based on application or access router.
Note
Setting or Changing the IP Precedence Value
By default, the Cisco IOS software leaves the IP Precedence value untouched, preserving the precedence value set in the header, allowing all internal network devices to provide service based on the IP Precedence setting. This policy follows the standard approach stipulating that network traffic should be sorted into various types of service at the basic perimeter of the network and that those types of service should be implemented in the core of the network. Routers in the core of the network can then use the precedence bits, for example, to determine the order of transmission, the likelihood of packet drop, and so on.
Because traffic coming into your network can have precedence set by outside devices, we recommend you reset the precedence for all traffic entering your network. By controlling IP Precedence settings, you prohibit users that have already set the IP precedence from acquiring better service for their traffic simply by setting a high precedence for all of their packets.
You can use any of the features described in the following sections to set the IP precedence in packets:
•
As mentioned previously, after a packet has been classified, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model.
Policy-Based Routing
PBR gives you a flexible means of routing packets by allowing you to configure a defined policy for traffic flows, lessening reliance on routes derived from routing protocols. To this end, PBR gives you more control over routing by extending and complementing the existing mechanisms provided by routing protocols. PBR allows you to set the IP precedence. It also allows you to specify a path for certain traffic, such as priority traffic over a high-cost link.
You can set up PBR as a way to route packets based on configured policies. For example, you can implement routing policies to allow or deny paths based on the identity of a particular end system, an application protocol, or the size of packets.
PBR allows you to perform the following tasks:
•
•
•
Policies can be based on IP address, port numbers, protocols, or size of packets. For a simple policy, you can use any one of these descriptors; for a complicated policy, you can use all of them.
For example, classification of traffic through PBR allows you to identify traffic for different classes of service at the edge of the network and then implement QoS defined for each CoS in the core of the network using priority queueing (PQ), custom queueing (CQ), or WFQ techniques. This process obviates the need to classify traffic explicitly at each WAN interface in the core-backbone network.
For information on how to configure policy-based routing, see the chapter "Configuring Policy-Based Routing" in this book.
How It Works
All packets received on an interface with PBR enabled are passed through enhanced packet filters known as route maps. The route maps used by PBR dictate the policy, determining to where the packets are forwarded.
Route maps are composed of statements. The route map statements can be marked as permit or deny, and they are interpreted in the following ways:
•
•
•
You specify PBR on the interface that receives the packet, not on the interface from which the packet is sent.
When Should You Use Policy-Based Routing?
You might enable PBR if you want certain packets to be routed some way other than the obvious shortest path. For example, PBR can be used to provide the following functionality:
•
•
•
•
•
Some applications or traffic can benefit from QoS-specific routing; for example, you could transfer stock records to a corporate office on a higher-bandwidth, higher-cost link for a short time while sending routine application data such as e-mail over a lower-bandwidth, lower-cost link.
QoS Policy Propagation via Border Gateway Protocol
The Border Gateway Protocol (BGP) is an interdomain routing protocol that exchanges reachability information with other BGP systems. It is defined by RFC 1163.
The Policy Propagation via BGP feature allows you to classify packets based on the following:
•
•
•
•
•
After a packet has been classified using BGP, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model.
BGP Policy Propagation leverages BGP to distribute QoS policy to remote routers in your network. It allows ingress routers to prioritize incoming traffic.
Restrictions
For the Policy Propagation via BGP feature to work, you must enable BGP and Cisco Express Forwarding (CEF)/distributed CEF (dCEF) on the router.
Subinterfaces on an ATM interface that has the bgp-policy command enabled must use CEF mode because dCEF is not supported. (Note that dCEF uses the Versatile Interface Processor (VIP) rather than the Route Switch Processor (RSP) to perform forwarding functions.)
For information on how to configure Policy Propagation via BGP, see the chapter "Configuring QoS Policy Propagation via Border Gateway Protocol" in this book.
Committed Access Rate
CAR is a multifaceted feature that implements both classification services and policing through rate limiting. This section describes its classification capability. For information on its rate limiting features, see the chapter "Policing and Shaping Overview" in this book.
You can use the classification services of CAR to set the IP precedence for packets entering the network. This capability of CAR allows you to partition your network into multiple priority levels or classes of service. Networking devices within your network can then use the adjusted IP precedence to determine how to treat the traffic. For example, VIP-distributed WRED uses the IP precedence to determine the probability of whether a packet will be dropped.
As discussed in the section "About IP Precedence," you can use the three precedence bits in the ToS field of the IP header to define up to six classes of service.
You can classify packets using policies based on physical port, source or destination IP or MAC address, application port, IP protocol type, or other criteria specifiable by access lists or extended access lists. You can classify packets by categories external to the network, for example, by a customer. After a packet has been classified, a network can either accept or override and reclassify the packet according to a specified policy. CAR includes commands you can use to classify and reclassify packets.
CAR is supported on the majority of Cisco routers. Additionally, distributed CAR is supported on Cisco 7000 series routers with an RSP7000 interface processor or Cisco 7500 series routers with a VIP-based VIP2-40 or greater interface processor. A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates.
For information on how to configure CAR, see the chapter "Configuring Committed Access Rate" in this book.
Class-Based Packet Marking
The Class-Based Packet Marking feature provides users with a means for efficient packet marking by which users can differentiate packets based on the designated markings.
The Class-Based Packet Marking feature allows users to perform the following tasks:
•
•
•
•
The Class-Based Packet Marking feature supports the following RFCs:
•
•
•
•
For information on how to configure Class-Based Packet Marking, see the chapter "Configuring Class-Based Packet Marking" in this book.
IP Precedence and IP DSCP Marking
Associating a packet with an IP Precedence or IP DSCP marking allows users to classify traffic based on IP Precedence and IP DSCP value, depending on which value is marked. These markings can be used to identify traffic within the network, and other interfaces can match traffic based on the IP Precedence or DSCP markings.
IP Precedence and DSCP markings are used to decide how packets should be treated in Weighted Random Early Detection (WRED).
The IP DSCP value is the first 6 bits in the ToS byte, while the IP Precedence value is the first 3 bits in the ToS value. The IP Precedence value is actually part of the IP DSCP value. Therefore, both values cannot be set simultaneously. If both values are set simultaneously, the packet is marked with the IP DSCP value.
If you need to mark packets in your network and all of your devices support IP DSCP marking, use the IP DSCP marking to mark your packets, since the IP DSCP markings provide more packet marking options. If marking by IP DSCP is undesirable, however, or if you are unsure if the devices in your network support IP DSCP values, use the IP precedence value to mark your packets. The IP precedence value is likely supported by all devices in the network.
A user can set up to 8 different IP precedence markings and 64 different IP DSCP markings.
CoS Value Marking
Associating a packet with a local CoS value allows users to associate a Layer 2 CoS value with a packet. The value can then be used to classify packets based on user-defined requirements. Layer 2 to Layer 3 mapping can also be configured by matching on the CoS value, because switches already have the capability to match and set CoS values. If a packet that needs to be marked to differentiate user-defined QoS services is leaving a router and entering a switch, the router should set the CoS value of the packet, because the switch can process the Layer 2 CoS header marking.
A user can set up to 8 different CoS markings.
QoS Group Value Marking
Associating a packet with a local QoS group allows users to associate a group ID with a packet. The group ID can be used to classify packets into QoS groups based on prefix, autonomous system, or community string. This QoS group marking can only be used to classify traffic within a router, and cannot be used to mark packets leaving the router.
A user can set up to 100 different QoS group markings.
ATM CLP Bit Setting
Changing the CLP bit setting in the ATM header of a cell provides a method of controlling the discarding of cells in congested ATM environments. A CLP bit contains two settings: 0 or 1. Cells with a CLP bit setting of 1 are discarded before cells with a CLP bit setting of 0 when congestion occurs.
Support for ATM Virtual Circuits
With the Class-Based Packet Marking feature, packet marking is supported on ATM virtual circuits (VCs). Users can configure the marking action in the same policy map where they configure the queueing actions, on a per-VC basis. Previously, packet marking was supported on the main interface or subinterface configuration level.
Additional Statistics
With the Class-Based Packet Marking feature, output from the show policy-map interface command is enhanced to provide additional statistics such as the incoming traffic rate, the dropped packet rate, the number of matched packets, and the number of matched bytes for traffic classes that are attached to the specified interface.
The Class-Based Packet Marking feature is configured with the Modular QoS CLI. For additional information on the Modular QoS CLI, see the chapter "Modular Quality of Service Command-Line Interface Overview" in this book.
Benefits
Packet Marking Through IP Precedence, QoS Group, CoS Value, and IP DSCP Value Setting
Packet marking allows you to partition your network into multiple priority levels or classes of service, as follows:
•
•
•
Improved Bandwidth Management on ATM Networks
The ability to set the ATM CLP bit allows users to extend their IP QoS policies into an ATM network. As congestion occurs in the ATM network, cells with the CLP bit set are more likely to be dropped, resulting in improved network performance for higher priority traffic and applications.
Restrictions
The following restrictions apply to the Class-Based Packet Marking feature:
•
•
–
–
–
–
–
–
•
•
•
Prerequisites
CEF must be configured on the interface before the Class-Based Packet Marking feature can be used.
For additional information on CEF, refer to the Cisco IOS Switching Services Configuration Guide.
QoS for Virtual Private Networks
The QoS for Virtual Private Networks (VPNs) feature is designed for tunnel interfaces. When the feature is enabled, the QoS features on the output interface classify packets before encryption, allowing traffic flows to be adjusted in congested environments. The result is more effective packet tunneling.
The QoS for VPNs feature provides a solution for making Cisco IOS QoS services operate in conjunction with tunneling and encryption on an interface. Cisco IOS software can classify packets and apply the appropriate QoS service before the data is encrypted and tunneled. The QoS for VPN feature allows users to look inside the packet so that packet classification can be done based on original port numbers and based on source and destination IP addresses. This allows the service provider to treat mission-critical or multiservice traffic with higher priority across its network.
To use this feature, the system must be able to configure QoS features.
Restrictions
Interfaces running cascading QoS features, such as Generic Traffic Shaping (GTS) or CQ, are required to have QoS for VPNs enabled or disabled on all cascading features. If the QoS for VPNs feature is enabled on one cascading feature, the QoS for VPNs feature must be enabled on all cascading features. Similarly, if the QoS for VPNs feature is disabled on one cascading feature, the QoS for VPNs feature must be disabled on all cascading features.
For information on how to configure the QoS for VPNs feature, see the chapter "Configuring QoS for Virtual Private Networks" in this book.
Network-Based Application Recognition
The Network-Based Application Recognition (NBAR) feature adds intelligent network classification to network infrastructures. 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/User Datagram Ports (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 working with QoS features to provide the following features:
•
•
•
•
NBAR introduces the following new classification features:
•
•
•
•
NBAR can also 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 ACLs are used.
NBAR provides a special Protocol Discovery feature that determines which application protocols are traversing a network at any given time. The Protocol Discovery feature captures key statistics associated with each protocol in a network. These statistics can be used to define traffic classes and QoS policies for each traffic class.
NBAR addresses IP QoS classification requirements by classifying application-level protocols so that QoS policies can be applied to the classified traffic. NBAR addresses the ongoing need to extend the classification engine for the many existing and emerging application protocols by providing an extensible Packet Description Language (PDL). NBAR can determine which protocols and applications are currently running on a network so that an appropriate QoS policy can be created based upon the current traffic mix and application requirements.
NBAR can now perform subport classification of HTTP traffic by host name in addition to classification by MIME-type or URL. This ability enables users to classify HTTP traffic by web server names. With URL matching, only the portion of the URL following the host name can be specified for a match. To perform a match on the host name portion of the URL, use the new HOST matching criterion. For example, a HOST match on http://www.cisco.com/latest/whatsnew.html will classify all traffic from the web server www.cisco.com, whereas a URL match can be performed on the /latest/whatsnew.html portion of the URL.
NBAR supports the following RFCs:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
NBAR supports the following RFCs:
•
•
•
•
•
•
For information on how to configure NBAR, see the chapter "Configuring Network-Based Application Recognition" in this book.
You must enable CEF before you configure NBAR. For more information on CEF, refer to the Cisco IOS Switching Services Configuration Guide.
Classification of HTTP by URL, HOST, or MIME
NBAR can classify application traffic by looking beyond the TCP/UDP port numbers of a packet. This ability is called 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 MIME type is an example of subport classification. NBAR classifies HTTP traffic by text within the URL or HOST fields of a GET request using regular expression matching. 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 GET packets containing the URL and classifies all packets that are sent to the source of the HTTP GET request. Figure 3 illustrates a network topology with NBAR in which Router Y is the NBAR-enabled router.
Figure 3 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 GET packet and classifies all packets from that host. For example, for the URL www.cisco.com/latest/whatsnew.html, include only www.cisco.com.
For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA)-supported MIME types can be found at the IANA web site.
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 GET 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.
Classification of Citrix ICA Traffic by Application Name
NBAR can classify ICA traffic and perform subport classification of Citrix traffic based on Citrix published applications. NBAR can monitor Citrix ICA client requests for a published application destined to a Citrix ICA Master browser. After the client makes a request to the published application, the Citrix ICA Master browser directs the client to the server with the most available memory. The Citrix ICA client then connects to this Citrix ICA server for the application.
NBAR statefully tracks Citrix ICA client/server messages and classifies requests for given Citrix application names and traffic. A Citrix application is named when published on a Citrix ICA server. NBAR performs a regular expression match using a user-specified application name string on the contents of the Citrix ICA control packets carrying the published application name. Therefore, users need to specify a regular expression that will result in a match for the published application name if they wish to match a specified application. Refer to the match protocol citrix command in the Cisco IOS Quality of Service Solution Command Reference for additional information.
Citrix ICA clients can be configured in various modes. NBAR cannot distinguish among Citrix applications in all modes of operation. Therefore, network administrators might need to collaborate with Citrix administrators to ensure that NBAR properly classifies Citrix traffic.
A Citrix administrator can configure Citrix to publish Citrix applications individually or as the entire desktop. In the Published Desktop mode of operation, all applications within the published desktop of a client use the same TCP session. Therefore, differentiation among applications is impossible, and NBAR can only be used to classify Citrix applications as aggregates (by looking at port 1494).
The Published Application mode for Citrix ICA clients is recommended when you use NBAR. In Published Application mode, a Citrix administrator can configure a Citrix client in either seamless or 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:
•
•
To turn off session sharing, perform the following steps:
Step 1
Step 2
[HKLM]\SYSTEM\CurrentControlSet\Control\Citrix\WFSHELL\TWI
Value name: "SeamlessFlags", type DWORD, possible values :0 or 1Setting this registry value to 1 overrides session sharing. Note that this flag is SERVER GLOBAL.
Note
Protocol Discovery
So that QoS policies can be developed and applied, NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are transiting an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol Discovery can be applied to interfaces and can be used to monitor both input and output traffic. 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.
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 be released only by Cisco and can be loaded from Flash memory. Please contact your local Cisco representative to request additions or changes to the set of protocols classified by NBAR.
Memory Management
NBAR uses approximately 150 bytes of DRAM for each flow that requires stateful inspection. Table 4 lists the 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 determine 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.
Table 4 TCP and UDP Stateful Protocols
12.0(5)XE2
12.1(1)E
12.1(5)TFTP
TCP
File Transfer Protocol
ftp
12.0(5)XE2
12.1(1)E
12.1(5)TExchange
TCP
MS-RPC for Exchange
exchange
12.0(5)XE2
12.1(1)E
12.1(5)T
(HTTP Host classification is not available on the 12.0 XE train)HTTP
TCP
HTTP with URL, MIME, or HOST classification
http
12.0(5)XE2
12.1(1)E
12.1(5)TNetshow
TCP/UDP
Microsoft Netshow
netshow
12.0(5)XE2
12.1(1)E
12.1(5)TRealAudio
TCP/UDP
RealAudio Streaming Protocol
realaudio
12.0(5)XE2
12.1(1)E
12.1(5)Tr-commands
TCP
rsh, rlogin, rexec
rcmd
12.0(5)XE2
12.1(1)E
12.1(5)TStreamWorks
UDP
Xing Technology Stream Works audio and video
streamwork
12.0(5)XE2
12.1(1)E
12.1(5)TSQL*NET
TCP/UDP
SQL*NET for Oracle
sqlnet
12.0(5)XE2
12.1(1)E
12.1(5)TSunRPC
TCP/UDP
Sun Remote Procedure Call
sunrpc
12.0(5)XE2
12.1(1)E
12.1(5)TTFTP
UDP
Trivial File Transfer Protocol
tftp
12.0(5)XE2
12.1(1)E
12.1(5)TVDOLive
TCP/UDP
VDOLive Streaming Video
vdolive
1 Indicates the Cisco IOS maintenance release that first supported the protocol.
Supported Protocols
NBAR can classify the following three types of protocols:
•
•
•
Table 5 lists all of the non-UDP and non-TCP protocols than NBAR can classify. Table 6 lists the TCP and UDP static port protocols.
Table 5 Non-UDP and Non-TCP Protocols
12.0(5)XE2
12.1(1)E
12.1(5)TEGP
IP
8
Exterior Gateway Protocol
egp
12.0(5)XE2
12.1(1)E
12.1(5)TGRE
IP
47
Generic Routing Encapsulation
gre
12.0(5)XE2
12.1(1)E
12.1(5)TICMP
IP
1
Internet Control Message Protocol
icmp
12.0(5)XE2
12.1(1)E
12.1(5)TIPINIP
IP
4
IP in IP
ipinip
12.0(5)XE2
12.1(1)E
12.1(5)TIPSec
IP
50, 51
IP Encapsulating Security Payload/Authentication Header
ipsec
12.0(5)XE2
12.1(1)E
12.1(5)TEIGRP
IP
88
Enhanced Interior Gateway Routing Protocol
eigrp
1 Indicates the Cisco IOS maintenance release that first supported the protocol.
Table 6 TCP and UDP Static Port Protocols
12.0(5)XE2
12.1(1)E
12.1(5)TBGP
TCP/UDP
179
Border Gateway Protocol
bgp
12.0(5)XE2
12.1(1)E
12.1(5)TCU-SeeMe
TCP/UDP
7648, 7649
Desktop video conferencing
cuseeme
12.0(5)XE2
12.1(1)E
12.1(5)TCU-SeeMe
UDP
24032
Desktop video conferencing
cuseeme
12.0(5)XE2
12.1(1)E
12.1(5)TDHCP/
BOOTPUDP
67, 68
Dynamic Host Configuration Protocol/ Bootstrap Protocol
dhcp
12.0(5)XE2
12.1(1)E
12.1(5)TDNS
TCP/UDP
53
Domain Name System
dns
12.0(5)XE2
12.1(1)E
12.1(5)TFinger
TCP
79
Finger user information protocol
finger
12.0(5)XE2
12.1(1)E
12.1(5)TGopher
TCP/UDP
70
Internet Gopher Protocol
gopher
12.0(5)XE2
12.1(1)E
12.1(5)THTTP
TCP
80
Hypertext Transfer Protocol
http
12.0(5)XE2
12.1(1)E
12.1(5)THTTPS
TCP
443
Secured HTTP
secure-http
12.0(5)XE2
12.1(1)E
12.1(5)TIMAP
TCP/UDP
143, 220
Internet Message Access Protocol
imap
12.0(5)XE2
12.1(1)E
12.1(5)TIRC
TCP/UDP
194
Internet Relay Chat
irc
12.0(5)XE2
12.1(1)E
12.1(5)TKerberos
TCP/UDP
88, 749
Kerberos Network Authentication Service
kerberos
12.0(5)XE2
12.1(1)E
12.1(5)TL2TP
UDP
1701
L2F/L2TP tunnel
l2tp
12.0(5)XE2
12.1(1)E
12.1(5)TLDAP
TCP/UDP
389
Lightweight Directory Access Protocol
ldap
12.0(5)XE2
12.1(1)E
12.1(5)TMS-PPTP
TCP
1723
Microsoft Point-to-Point Tunneling Protocol for Virtual Private Networks (VPNs)
pptp
12.0(5)XE2
12.1(1)E
12.1(5)TMS-
SQLServerTCP
1433
Microsoft SQL Server Desktop Videoconferencing
sqlserver
12.0(5)XE2
12.1(1)E
12.1(5)TNetBIOS
TCP
137, 139
NetBIOS over IP (MS Windows)
netbios
12.0(5)XE2
12.1(1)E
12.1(5)TNetBIOS
UDP
137, 138
NetBIOS over IP (MS Windows)
netbios
12.0(5)XE2
12.1(1)E
12.1(5)TNFS
TCP/UDP
2049
Network File System
nfs
12.0(5)XE2
12.1(1)E
12.1(5)TNNTP
TCP/UDP
119
Network News Transfer Protocol
nntp
12.0(5)XE2
12.1(1)E
12.1(5)TNotes
TCP/UDP
1352
Lotus Notes
notes
12.1(2)E
12.1(5)TNovadigm
TCP/UDP
3460 to 3465
Novadigm Enterprise Desktop Manager (EDM)
novadigm
12.0(5)XE2
12.1(1)E
12.1(5)TNTP
TCP/UDP
123
Network Time Protocol
ntp
12.0(5)XE2
12.1(1)E
12.1(5)TPCAnywhere
TCP
5631, 65301
Symantec PCAnywhere
pcanywhere
12.0(5)XE2
12.1(1)E
12.1(5)TPCAnywhere
UDP
22, 5632
Symantec PCAnywhere
pcanywhere
12.0(5)XE2
12.1(1)E
12.1(5)TPOP3
TCP/UDP
110
Post Office Protocol
pop3
12.1(2)E
12.1(5)TPrinter
TCP/UDP
515
Printer
printer
12.0(5)XE2
12.1(1)E
12.1(5)TRIP
UDP
520
Routing Information Protocol
rip
12.0(5)XE2
12.1(1)E
12.1(5)TRSVP
UDP
1698,1699
Resource Reservation Protocol
rsvp
12.0(5)XE2
12.1(1)E
12.1(5)TSFTP
TCP
990
Secure FTP
secure-ftp
12.0(5)XE2
12.1(1)E
12.1(5)TSHTTP
TCP
443
Secure HTTP
secure-http
12.0(5)XE2
12.1(1)E
12.1(5)TSIMAP
TCP/UDP
585, 993
Secure IMAP
secure-imap
12.0(5)XE2
12.1(1)E
12.1(5)TSIRC
TCP/UDP
994
Secure IRC
secure-irc
12.0(5)XE2
12.1(1)E
12.1(5)TSLDAP
TCP/UDP
636
Secure LDAP
secure-ldap
12.0(5)XE2
12.1(1)E
12.1(5)TSNNTP
TCP/UDP
563
Secure NNTP
secure-nntp
12.0(5)XE2
12.1(1)E
12.1(5)TSMTP
TCP
25
Simple Mail Transfer Protocol
smtp
12.0(5)XE2
12.1(1)E
12.1(5)TSNMP
TCP/UDP
161, 162
Simple Network Management Protocol
snmp
12.0(5)XE2
12.1(1)E
12.1(5)TSOCKS
TCP
1080
Firewall security protocol
socks
12.0(5)XE2
12.1(1)E
12.1(5)TSPOP3
TCP/UDP
995
Secure POP3
secure-pop3
12.0(5)XE2
12.1(1)E
12.1(5)TSSH
TCP
22
Secured Shell
ssh
12.0(5)XE2
12.1(1)E
12.1(5)TSTELNET
TCP
992
Secure Telnet
secure-telnet
12.0(5)XE2
12.1(1)E
12.1(5)TSyslog
UDP
514
System Logging Utility
syslog
12.0(5)XE2
12.1(1)E
12.1(5)TTelnet
TCP
23
Telnet Protocol
telnet
12.0(5)XE2
12.1(1)E
12.1(5)TX Window System
TCP
6000-6003
X11, X Window System
xwindows
1 Indicates the Cisco IOS maintenance release that first supported the protocol.
Restrictions
The NBAR feature does not support the following:
•
•
•
•
•
•
•
•
•
NBAR is not configurable on the following logical interfaces:
•
•
•
Note
•
•
Note
