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 number and types of applications and protocols that are running on a network.

NBAR gives network administrators the ability to see the different types of protocols and the amount of traffic generated by each protocol.

After NBAR gathers this information, users can organize traffic into classes.

After NBAR gathers this information, users can organize traffic into classes.

These classes can then be used to provide different levels of service for network traffic, thereby allowing better network management by providing the appropriate level of the network resources for network traffic.

Note: When implementing QOS, Its a good idea to first setup NBAR to see what type of traffic is traversing the network.

The phrase "Layer 2 NBAR" refers to NBAR functionality used with Layer 2 interfaces (such as switchports, trunks, or Etherchannels).

Layer 2 NBAR Restrictions(cont'd)

Note: Layer 2 NBAR functionality can be used with service modules such as a Firewall Service Module (FWSM) and an Intrusion Detection Service Module (IDSM) with the following restriction:

       Layer 2 NBAR is "not supported" on Layer 2

interfaces that are configured as part of a service module (such as FWSM and IDSM) when those service modules are configured in inline mode.

Note

:This restriction does not apply to NBAR functionality that is used with Layer 3 interfaces.

Note

:Layer 2 NBAR is supported in noninline mode with service modules even when Switched Port Analyzer (SPAN), Remote SPAN (RSPAN), or VLAN Access Control List (VACL) Capture functionality is used to send traffic to a service module.

Restrictions for Using NBAR

NBAR does not support the following:

More than 24 concurrent URLs, hosts, or Multipurpose Internet Mail Extension (MIME) type matches

1. NBAR now supports full payload inspection, The only exception is that NBAR can inspect custom protocol traffic for only 255 bytes into the payload.

2. No support Non-IP traffic.

3. Multicast and other non-Cisco Express Forwarding 

    switching modes.

4. Fragmented packets.

5. Pipelined persistent HTTP requests.

6. URL/host/MIME classification with secure HTTP.

Restrictions for Using NBAR(cont'd-1)

7. Asymmetric flows with stateful protocols.

8. Packets that originate from or that are destined to the router running NBAR.

9. NBAR is not supported on the following logical  interfaces: a. Fast Etherchannels, b. Dialer interfaces  until Cisco IOS Release 12.2(4)T,

c. Interfaces where tunneling or encryption is used  input classification before the traffic is switched to the WAN link.

Classification of HTTP Traffic by URL Host or MIME

Classification of HTTP Traffic Using HTTP Header Fields

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

*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 based on content within the payload such as that transaction identifier, message type, or other similar data.

*Classification of HTTP traffic 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 using regular expression matching.

*HTTP client request matching in NBAR supports most HTTP request methods such as GET, PUT, HEAD, POST, DELETE, OPTIONS, CONNECT, and TRACE.

*The NBAR engine then converts the specified match string into a regular expression.

Note

:When specifying a URL for classification, include only the portion of the URL that follows the www.hostname .domain in the match statement.

For example, for the URL www.cisco.com/latest/whatsnew.html, include only /latest/whatsnew.html with the match statement (for instance, match protocol http url/latest/whatsnew.html).

Note

: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 following URL:

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

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

*NBAR supports URL and host classification in the presence of persistent HTTP.

*NBAR does not classify packets that are part of a pipelined request.

*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 to identify HTTP traffic that traverses these ports

*HTTP traffic classification is no longer limited to the well known and defined TCP ports.

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 header fields are used to provide information about HTTP request and response messages. HTTP has numerous header fields

Note

: For additional information on HTTP headers, see section 14 of RFC 2616: Hypertext Transfer Protocol--HTTP/1.1

NBAR can 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

Classification of HTTP Traffic Using HTTP Header Fields

NBAR can classify the following HTTP header fields:(cont'd)

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

       Server , Location , Content-Encoding, & Content-Base 　

                                             Note

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

Note

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

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

Note

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

NBAR Functionality

NBAR is a classification engine that recognizes and classifies a wide variety of protocols and applications, including web-based and other difficult-to-classify applications and protocols that use dynamic TCP/UDP port assignments.

When NBAR recognizes and classifies a protocol or application, the network can be configured to apply the appropriate QoS for that application or traffic with that protocol. The QoS is applied using the modular quality of service CLI (MQC).

_Note

:For more information about NBAR and its relationship with the MQC, see the "Configuring NBAR Using the MQC" module.

Examples of the QoS features that can be applied to the network traffic (using the MQC) after NBAR has recognized and classified the application or protocol include the following:

*Class-Based Marking

*Class-Based Weighted Fair Queuing (CBWFQ)

*Low Latency Queuing (LLQ)

*Traffic Policing

*Traffic Shaping

*Traffic Classification

*Traffic Marking

Note

:For more information about the QoS features, see the "Quality of Service Overview" module

*NBAR introduces several classification features that identify applications and protocols from Layer 4 through Layer 7. These classification features are as follows: 

             *Statically assigned TCP and UDP port numbers.

              *Non-TCP and non-UDP IP protocols.

     *Dynamically assigned TCP and UDP port numbers. This kind of 

            classification requires stateful inspection; that is, the ability to inspect a protocol across multiple packets during packet classification.

      *Subport classification or classification based on deep-packet inspection.

Note

:Deep-packet classification is classification performed at a finer level of granularity. For instance, if a packet is already classified as HTTP traffic, it may be further classified by HTTP traffic with a specific URL.

Note

:Access Control Lists (ACLs) can also be used for classifying static port protocols. However, NBAR is easier to configure and can provide classification statistics that are not available when ACLs are used. 

Note

:NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are operating on an interface. For more information about Protocol Discovery, see the "Enabling Protocol Discovery" module.

Note

: NBAR classifies network traffic by application or protocol. Network traffic can be classified without using NBAR. For information about classifying network traffic without using NBAR, see the "Classifying Network Traffic" module.

*RTP is a packet format for multimedia data streams.

*It can be used for media-on-demand and for 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.

Note

: 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

Note

: The data part of RTP is a thin protocol that provides support for applications with real-time properties such as continuous media (audio and video), which includes timing reconstruction, loss detection, and security and content identification.

*RTP is discussed in RFC-1889 (ATranspor tProtocol for Real-Time Applications)and

*RFC-1890 (RTP Profile for Audio and Video Conferences with Minimal Control).

*The RTP payload type is the data transported by RTP in a packet, for example, audio samples or compressed video data.

*The RTP payload classification takes place in the persistent mode, wherein a fully qualified RTP session NBAR does the payload sub-classification.

For example, RFC 2833 requires persistent processing for RTP payload sub-clasification within a classified flow.

The NBAR RTP Payload Type Classification feature allows:

*real-time audio and video traffic to be statefully identified.

 *can also differentiate on the basis of audio and video codecs to provide more granular QoS