|
|
This chapter is an overview of the Network-Based Application Recognition (NBAR) feature in Cisco IOS. It helps you decide in which situations NBAR is the appropriate mechanism for accounting and performance management. Based on concrete examples, you will be able to identify the appropriate CLI commands and MIB functions and quickly get NBAR setups operational.
NBAR provides network traffic classification. NBAR recognizes a wide variety of applications by inspecting the IP packet's payload up to OSI Layer 7. It can identify web-based and other difficult-to-classify applications, which can be static (using fixed TCP or UDP port numbers) or stateful (dynamically assigning TCP or UDP port numbers). Figure 10-1 illustrates the parts of the data packet inspected by NBAR.
When NBAR recognizes an application, it classifies the traffic for performance and accounting purposes. This enables an operator to invoke services for that specific application, such as offering more or less bandwidth, low- or high-latency queuing, or blocking certain packets. It also enables the operator to define different accounting types for each service. Accounting can use different QoS mechanisms to separate and condition the traffic differently, according to its relative priority. NBAR ensures that network bandwidth is used efficiently by supporting the following QoS features:
Guaranteed bandwidth with Class-Based Weighted Fair Queuing (CBWFQ). For converged services, you can use Low-Latency Queuing (LLQ), also called Priority Queuing Class-Based Weighted Fair Queuing (PQCBWFQ).
Policing and limiting bandwidth (ingress function).
Marking (ToS or IP DSCP).
Increasing or reducing bandwidth.
Drop policy with Weighted Random Early Detection (WRED).
These additional services are outside the scope of accounting and performance management and therefore are not covered in this book.
NBAR provides a special Protocol Discovery feature that determines which applications and protocols are traversing the network element at any given time by capturing key statistics that are associated with each protocol. The application protocol specifications are defined in a Packet Description Language Module (PDLM). The existing modules can be extended to support emerging application protocols by using the extensible Packet Description Language (PDL). Right now, the use of PDL and the development of PDLMs are limited to Cisco; however, this restriction might be lifted in the future. PDLMs are discussed more thoroughly later in this chapter.
Note
NBAR Protocol Discovery can be used independently of or in conjunction with NBAR traffic classification!
The following principles apply for NBAR:
Network-based application recognition classifies traffic by protocol (Layers 4 through 7). Here are some examples:
- NBAR extended inspection for HTTP traffic identifies traffic on ports beyond "well known" TCP ports.
- NBAR Real-time Transport Protocol (RTP) payload classification allows for stateful identification of real-time audio and video bearer traffic. It can also differentiate based on audio and video codecs.
- Real-Time Streaming Protocol (RTSP)-based applications can work in NAT's PAT configuration mode.
User-defined custom application classification lets you identify TCP- or UDP-based applications using a string or value to match the type of application within the packet payload.
Accounting functionality is enabled via the NBAR feature Protocol Discovery. It analyzes application traffic patterns in real time and discovers which traffic is running on the network. Furthermore, it provides bidirectional (input and output) traffic statistics per interface and per application: bit rate (bps), packet counts, and byte counts.
A maximum of 24 concurrent URLs, hosts, or MIME type matches are supported.
Note
Previously, Cisco Express Forwarding (CEF or dCEF) was a prerequisite for NBAR. This limitation has been removed in Cisco IOS Software Release 12.4T. However, turning off CEF has a negative performance impact on the router, so you should enable CEF whenever possible.
Originally, NBAR was not supported on distributed platforms, such as the VIP-enabled Cisco 7500 series routers and the Catalyst 6000 family of switches with a FlexWAN module. The Distributed Network-Based Application Recognition (DNBAR) feature was introduced in IOS releases 12.1(6)E, 12.2(4)T3, and 12.2(14)S. On these distributed platforms, DNBAR implements NBAR functionality on a VIP or FlexWAN module. Packets entering an interface on the VIP or FlexWAN are classified by NBAR, and separate reports are available on these modules. It is important to note that the DNBAR feature is identical to NBAR. Therefore, the term NBAR is used to describe both the NBAR and DNBAR features.
NBAR can classify applications based on the following characteristics:
Statically assigned TCP and UDP port numbers.
TCP and UDP protocols that assign port numbers dynamically and therefore require stateful inspection. This includes packets that require subport classification and classification based on deep packet inspection. This is further explained later in this chapter.
Non-UDP and non-TCP IP protocols (EGP, EIGRP, GRE, ICMP, IPINIP, IPsec).
HTTP traffic classified by URL, host, or Multipurpose Internet Mail Extension (MIME) type. NBAR also classifies application traffic using subport information, which combines matching of HTTP traffic and the hostname in addition to classification by MIME type or URL.
Identifying worms in the packet payload, which is very useful for security mitigation. After you have identified unique match values signatures for a specific attack, use NBAR to block this traffic immediately while establishing a defense plan against the attack. For example, Code Red was identified by an "*.ida" URL in the HTTP GET request.
Peer-to-peer traffic, such as Napster, Kazaa, Morpheus, Gnutella, Grokster, WinMX, eDonkey, eMule, BitTorrent, and so on.
Heuristic and holistic classification. NBAR classifies an application based on the information of the whole packet and makes a determination based on the behavior of the whole packet. The RTP Payload Classification feature is based on this algorithm; the packet is classified as RTP based on multiple attributes in the UDP and RTP headers. Note that heuristic and holistic classification functions are limited to the PDLMs and cannot be used to customize applications!
Citrix Independent Computing Architecture (ICA) traffic classification by application name.
NBAR offers additional capabilities that help classify applications:
User-defined protocols. Operators can define names for their custom protocol applications. The user-named protocol can then be used by the Protocol Discovery CLI and MIB, and CLI commands such as match protocol or ip nbar port-map as an NBAR-supported protocol.
Ten custom applications can be assigned using NBAR. Each customer application can have up to 16 TCP and 16 UDP ports, each mapped to the individual custom protocol. The real-time statistics per custom protocol can be monitored using the Protocol Discovery function.
Matching the use of multiple ports to one application is a unique benefit of NBAR. A simple example demonstrates this: FTP uses TCP ports 20 and 21. NBAR consolidates traffic from both ports into one record. In comparison with NetFlow, FTP creates two separate flows, which need to be aggregated at a NetFlow collector afterward.
Payload inspection matching string patterns at a specific offset.
Inspection for custom protocols by traffic direction, such as traffic heading toward a source or destination instead of collection traffic in both directions.
The following sections explain some of the features in this list in more detail. They describe features that are advanced or not intuitive, compared to evident features such as identifying applications by port number.
NBAR can classify application traffic by looking beyond a packet's TCP/UDP port numbers. This ability is called subport classification. NBAR looks at the TCP/UDP payload and classifies packets based 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 does not classify packets that are part of a pipelined request. With pipelined requests, multiple requests are pipelined at the server before previous requests are serviced. For HTTP requests, in-depth analysis can be performed.
For request messages (client to server), the following HTTP header fields can be identified:
User-Agent— A value in the HTTP header field, also known as "Browser ID," such as "Mozilla/4.0"
Referrer— The reference to the previous visited website
From— Indicates the initiator of the request, such as the e-mail address
For response messages (server to client), the following header fields can be identified:
Server contains information about the software used by the origin server that handled the request, such as "Server: CERN/3.0 libwww/2.17."
Location is used to redirect the recipient to another location.
Content-Encoding is used as a modifier to the media type, such as "gzip."
NBAR can classify Citrix Independent Computing Architecture (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 for 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. 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.
Even though NBAR supports a long list of static and stateful protocols, new transport protocols will always be developed, and they will require extensions to the existing definitions. Recent examples are new peer-to-peer applications as well as new voice applications and others. NBAR PDLMs, which can be downloaded from the Cisco website, let you add support for new protocols without requiring an IOS release upgrade or a router reload. A PDLM can be loaded at runtime.
NBAR does not support certain scenarios:
MPLS-labeled packets, because NBAR classifies only IP packets. As a workaround, you can use NBAR to classify IP traffic before the traffic is handed over to MPLS. Use the Modular QoS CLI (MQC) to set the IP DSCP field on the NBAR-classified packets and map the IP DSCP settings to the MPLS EXP settings.
Pipelined persistent HTTP requests.
URL/host/MIME classification with secure HTTP.
Asymmetric flows with stateful protocols.
Packets originating from or destined for the network element running NBAR.
Custom protocol traffic can be inspected for only the first 255 bytes of the payload.
IPv6.
Egress WAN links where tunneling or encryption is configured. As a workaround, NBAR should be configured on ingress interfaces to perform input classification before the traffic is switched to the WAN link for output. Even though NBAR is not supported in these environments, the NBAR Protocol Discovery function is supported on interfaces where tunneling or encryption is used. You can enable 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/tunneled packets received in addition to the per-protocol breakdowns.
|
|