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: - Switch and IP phone exchange CDP; trust
boundary is extended to the IP phone.
- IP phone sets
CoS to 5 for VoIP and to 3 for call signaling traffic.
- IP phone rewrites CoS from PC to 0.
- 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