Cisco Discovery Protocol (CDP) to discover whether any devices plugged into its ports can be trusted. If the device can be trusted (such as a Cisco IP phone), the switch extends trust to the device dynamically. If CDP determines that the device cannot be trusted (such as a PC), the switch does not extend the trust boundary to the device. The sequence is as follows:

1. Switch and IP phone exchange CDP; trust boundary is extended to the IP phone.
2. IP phone sets CoS to 5 for VoIP and to 3 for call signaling traffic.
3. IP phone rewrites CoS from PC to 0.
4. Switch trusts CoS from IP phone and maps CoS to DSCP for output queuing.

It is generally recommended that end-user PC traffic not be trusted. However, some PCs may be running critical applications that require QoS treatment. A classic example is a PC running Cisco IP Communicator. In such a case, the critical application needs to be identified using access control lists (ACLs) and marked or remarked at the access edge. If the access layer switch is incapable of marking or re-marking the traffic, then marking or re-marking needs to take place at the distribution layer switch or router.

---

Content 4.2 Using NBAR for Classification 4.2.1 Network-Based Application Recognition Network-Based Application Recognition (NBAR) is a classification and protocol discovery feature of Cisco IOS software that recognizes a wide variety of applications, including web-based applications and client/server applications that dynamically assign TCP or UDP port numbers. After NBAR recognizes an application, the network can invoke specific services for that particular application. These features include the ability to guarantee bandwidth to critical applications, limit bandwidth to other applications, drop selective packets to avoid congestion, and mark packets appropriately so that the network and the service provider's network can provide QoS from end to end. NBAR works with QoS features. 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)

NBAR performs the following two functions:

• Identification of applications and protocols (Layer 4 to Layer 7)
• Protocol discovery

Classification Features
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. Protocol Discovery
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
• 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. Adding New Applications
New applications can be added to NBAR using an external Packet Description Language Module (PDLM) that 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. Restrictions
You must enable Cisco Express Forwarding (CEF) before you configure NBAR. NBAR cannot support the following:

• More than 24 concurrent URLs, hosts, or Multipurpose Internet Mail Extension (MIME)-type matches
• Matching beyond the first 400 bytes in a packet payload
• Multicast and switching modes other than CEF
• Fragmented packets
• URL, host, or MIME classification with secure HTTP
• Packets originating from or destined to the router running NBAR

NBAR is not supported on Fast EtherChannel, but is supported on Gigabit Ethernet interfaces. Interfaces configured to use tunneling or encryption do not support NBAR; that is, you cannot use NBAR 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 NBAR 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 or tunneled packets received in addition to the per-protocol breakdowns. These points are summarized in Figure , and Figure provides another example of an NBAR application.

---

Content 4.2 Using NBAR for Classification 4.2.2 NBAR Application Support 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 packets belonging to different types of applications:

• Static applications establish sessions to well-known TCP or UDP destination port numbers. Such applications, such as Simple Mail Transfer Protocol (SMTP), could also be classified by using access control lists (ACLs).
• Dynamic applications use multiple sessions that use dynamic TCP or UDP port numbers. Typically, there is a control session to a well-known port number, and the other sessions are established to destination port numbers negotiated through the control sessions, such as those used with FTP. NBAR inspects the port number exchange through the control session.
• Some non-IP protocols, such as Novell Internetwork Packet Exchange (IPX), can also be recognized by NBAR.
• NBAR also has the capability to inspect some applications for other information and to classify based on that information. For example, NBAR can classify HTTP sessions based on the requested URL, including MIME type or host name.

Although ACLs can also be used to classify