To enhance the list of protocols that NBAR recognizes through a PDLM, download the PDLM from CCO and copy it into the flash or on a TFTP server. Next, enter the following command, which refers to the PDLM name in URL format:
The URL, for example, can be flash://citrix.pdlm, referring to the citrix.pdlm file in flash memory. The URL can also refer to a file on a TFTP server, such as tftp://192.168.19.66/citrix.pdlm.
To modify the port number that NBAR associates to a protocol name or to add a port to the list of ports associated to a protocol name, use this command:
The preceding command configures NBAR to search for a protocol or protocol name using a port number other than the well-known one. You can specify up to 16 additional port numbers.
To see the current NBAR protocol-to-port mapping, use the following show command:
Example 3-1 displays partial sample output of the preceding command.
Example 3-1 Displaying NBAR Protocol-to-Port Mapping
To enable NBAR protocol discovery on a router interface, first ensure that CEF is enabled on that interface. CEF is turned on using the IP CEF command from Cisco IOS global configuration mode. Next, enter the following command in the interface configuration mode:
To display the discovered protocols and the statistics gathered for each discovered protocol, enter the following show command. Note that unless you specify an interface, the output will include the statistics gathered for all interfaces (back to back):
Sample output of the preceding command is shown in Example 3-2.
Example 3-2 Displaying NBAR protocol-discovery Results
You can use NBAR to recognize and classify protocols that use static port numbers; NBAR can do the same for protocols that dynamically negotiate port numbers. If you want NBAR to classify network traffic based on protocol and subsequently apply certain QoS policies to each traffic class, use MQC class map and refer to the desired NBAR protocol with a match statement. The following is the syntax for the match statement within a class map:
The protocol-name that is referred by the class map match protocol statement is an NBAR-supported protocol such as ip, arp, compressed tcp, cdp, dlsw, ipx, and so on. Do not forget that you can specify additional ports (besides the well-known ports) for each protocol by configuring the previously introduced ip nbar port-map command. Also, to expand the list of NBAR-supported protocols, you can load new PDLMs in your device, as discussed earlier in this section. To use NBAR for classification and marking of traffic belonging to static-port protocols and to apply the policy to an interface, you have to perform the following tasks:
■ Enable NBAR protocol discovery.
■ Configure a traffic class using the MQC class map.
■ Configure a QOS policy using the MQC policy map.
■ Apply the policy to the interface(s).
■ Expand the NBAR protocol ports or PDLM protocols if needed.
Example 3-3 shows partial configuration of a router with a policy called www-ltd-bw (implying limited bandwidth for web browsing or HTTP protocol) applied to its serial 1/1 interface. The first line shows that TCP ports 80 and 8080 are defined for HTTP. The configured class map defines a traffic class called www, which includes all traffic classified by NBAR as http. The policy map called www-ltd-bw is applied to the outgoing traffic of the serial 1/1 interface using the service-policy output command. The policy map www-ltd-bw specifies that the traffic classified as www is assigned to a queue with a 512-Kbps bandwidth reservation.
Example 3-3 Implementing QoS Policy Using NBAR for Static Protocols
In Example 3-3, the command ip nbar protocol-discovery is applied to the serial 1/1 interface. In the past (earlier Cisco IOS releases), you had to apply this command to the interface before you could apply a service policy that used NBAR (through the match protocol name command); however, as of Cisco IOS 12.2T, this is no longer necessary. The ONT course does not mention this fact in its initial release, so for examination purposes, you might want to do it the old-fashioned way and apply the ip nbar protocol-discovery command to the interface.
You can also use NBAR to do traffic classification for stateful protocols, those that negotiate the data session port numbers during the initial control session. You still need to take three steps:
1. Configure a traffic class using MQC class map.
(Within the class map, the match statement references the stateful protocol such as TFTP).
2. Configure a QOS policy using MQC policy map.
3. Apply the policy to the interface(s).
One of the most attractive and powerful NBAR features is its ability to do deep packet inspection. Four popular uses of NBAR deep packet inspection are as follows:
■ Classifying traffic based on the hostname or the URL after the hostname in the HTTP GET requests
■ Classifying traffic based on the MIME type
■ Classifying traffic belonging to fast-track protocols file transfers using regular expressions that match strings
■ Classifying traffic based on the RTP payload type or CODEC
The match protocol commands required within MQC class map, to classify traffic according to the preceding criteria, are as follows:
Example 3-4 shows three class maps: from-cisco, whats-up, and cool-jpegs. The class map from-cisco matches any HTTP GET request from hosts whose names begin with cisco. cisco* is a regular expression that matches any string that begins with characters cisco (followed by zero or more characters). Special characters such as *, which means zero or more characters (wildcard), make writing regular expressions a lot easier. The class map whats-up matches HTTP packets based on any URL containing the string /latest/whatsnew followed by zero or more characters. The last class map in Example 3-4, cool-jpegs, classifies packets based on the Joint Photographics Expert Group (JPEG) MIME type.
Example 3-4 Using NBAR to Match HTTP Hostname, URL, and MIME Type
For your reference only (not for the purpose of exam preparation), Table 3-5 presents a few useful special characters you can use within regular expressions of the class map match statement.
Table 3-5 Special Strings and Characters for Regular Expressions
|
Character or String |
Description |
 |
Match zero or more characters in this position. |
 |
Match any one character in this position. |
 |
It means OR. Match one of a choice of characters on either side of the 1 symbol. |
 |
Match one of a choice of characters inside the parentheses on either side of the 1 symbol. For example, xyz.(gifljpg) matches either xyz.gif or xyz.jpg. |
 |
Match any character in the range specified, or one of the special characters. For example, [0-9] is any single digit; [*] matches the * character, and [[] matches the [ character. |
You can also use NBAR deep packet inspection to match traffic from FastTrack peer-to-peer protocols such as Kazaa and Grokster. To configure NBAR to match FastTrack peer-to-peer traffic, use the following command in class map configuration mode:
Router(config-cmap)# match protocol fasttrack file-transfer reg-exp Please note that the preceding command syntax expects a regular expression to identify a specific FastTrack traffic. Gnutella traffic can be classified similarly using NBAR, by changing the keyword FastTrack to Gnutella.
Example 3-5 shows three class maps. The class map called fasttrack1 configures NBAR to match all FastTrack traffic. In the second class map, all FastTrack files that have the .mpeg extension are classified into traffic class fasttrack2. Class map fasttrack3 specifies that all FastTrack traffic that contains the string "cisco" is part of the traffic class called fasttrack3.
Example 3-5 Using NBAR to Match FastTrack Protocol Traffic
The Real-Time Transport Protocol (RTP) is considered the transport protocol of choice for realtime audio and video. It adds a header above the UDP header to include information such as reconstruction timestamp and sequence number, plus security and content identification. RTP has a control protocol sister called Real-Time Protocol Control Protocol (RTCP). Whereas RTP uses the UDP even-numbered ports (starting with 16384 by default), RTCP uses the UDP odd-number ports. NBAR deep packet inspection allows you to do classification based on RTP payload type (audio or video) or do a deeper classification based on audio or video CODEC type. The syntax to configure NBAR to match RTP traffic in class map configuration mode is as follows:
In the preceding command syntax, the optional keyword audio specifies matching by audio payload type. (Values in the range of 0 to 23 are reserved for audio traffic.) Similarly, the optional keyword video specifies matching by video payload type. (Values in the range of 24 to 33 are reserved for video traffic.) If you use the optional keyword payload-type, you can specify (using a string) matching by a specific payload type value, providing more granularity than is available with the audio or video keywords. A payload string argument can contain commas to separate payload type values and hyphens to indicate a range of payload type values.
Example 3-6 shows two class maps. The first class map is called voice, and as the name implies, it matches the RTP audio protocol. The class map called video matches the RTP video protocol.
Example 3-6 Using NBAR to Match RTP Protocol Traffic
Foundation Summary
The "Foundation Summary" is a collection of information that provides a convenient review of many key concepts in this topic. If you are already comfortable with the topics in this topic, this summary can help you recall a few details. If you just read this topic, this review should help solidify some key facts. If you are doing your final preparation before the exam, the information in this section is a convenient way to review the day before the exam.
Table 3-6 summarizes the major topics in this topic.
Table 3-6 Summary of Classification, Marking, and NBAR
|
Topic |
Summary |
|
Purpose of packet classification |
Packet classification is a QoS mechanism that distinguishes and divides network traffic into traffic classes or behavior aggregates (BAs). |
|
Purpose of packet marking |
Packets, frames, and some other protocol data units (PDUs) have a special field designed for QoS purposes. Marking is a QoS mechanism that sets this field to a common value on packets that belong to the same traffic/service class (BA) and sets them to different values on packets that belong to different classes. |
|
Classification and marking at the data link layer |
Different data link layer protocol data units (PDUs) have different fields for QoS classification and marking purposes. On 802.1Q/P or ISL frames, the 3-bit PRI (CoS) field is used for that purpose. On Frame Relay frames, the DE bit is used for that purpose, and on AMT cells, the CLP bit is used. On the MPLS header (layer 2) the 3-bit EXP field is used for QoS purposes. |
|
PHB |
A per-hop behavior (PHB) is an externally observable forwarding behavior applied at a DiffServ-compliant node to a DiffServ BA. |
|
Class selector PHB (DSCP) |
The class-selector PHB is a set of DSCP values that make DSCP backward compatible with IPP (IP precedence). The least significant bits of the class selectors (CS1 through CS7) are 000. |
|
AF PHB |
The assured forwarding (AF) PHB provides four queues for four classes of traffic. Bandwidth reservation can be made for each AF queue. Each AF has three DSCP values associated to it so that differentiated drop policy can be applied to the packets in the same AF queue. |
|
EF PHB |
The expedited forwarding (EF) PHB provides a priority queue with guaranteed but policed bandwidth. EF PHB is ideal for delay-sensitive traffic as long as this type of traffic is not oversubscribed. |
Table 3-6 Summary of Classification, Marking, and NBAR
|
Topic |
Summary |
|
QoS service class |
QoS service class is a logical grouping of packets that, as per the administrative policy definitions, are required to receive the same QoS treatment. |
|
Trust boundary |
Marking is recommended to take place as close to the ingress edge of the network as possible. Marking, however, must be done by a trusted device. The ingress edge/perimeter of the network where the trusted devices reside and perform marking is called the trust boundary. |
|
NBAR |
NBAR is a protocol discovery and a classification tool/feature. Within a class map, you can configure a match statement that refers to an NBAR protocol. |
|
NBAR Protocol Discovery |
To discover the network traffic mix that transits through an interface (both input and output), apply the NBAR protocol discovery feature to that interface. NBAR protocol discovery also reports traffic statistics such as total number of input/output packets and bytes and input/output bit rates. |
|
NBAR PDLMs |
The NBAR Packet Description Language Modules (PDLM) are files provided by Cisco Systems that you can load into your network device to extend the NBAR list of supported protocols or enhance the NBAR existing protocol-recognition capability. Loading a new PDLM does not require a router reload. |
|
NBAR application support |
NBAR can discover and classify both types of applications: those that use static ports and those that use dynamically assigned ports. NBAR can do classification through deep packet inspection; for example, it can classify based on URL, MIME type, and RTP payload type. CEF must be enabled on device interfaces for NBAR to function. |
