Network Based Application Recognition

Although the majority of applications can be identified using Layer 3 or Layer 4 criteria (such as discrete IP addresses or well-known TCP/UDP ports), there are applications that cannot be identified by such criteria alone. This might be due to legacy limitations but more likely is due to deliberate design. For example, peer-to-peer media-sharing applications deliberately negotiate ports dynamically with the objective of penetrating firewalls.

When Layer 3 or Layer 4 parameters are insufficient to positively identify an application, NBAR might be a viable alternative solution. NBAR is the most sophisticated classifier in the IOS tool suite. NBAR can recognize packets on a complex combination of fields and attributes; however, you need to recognize that NBAR is merely a classifier, nothing more. NBAR can identify flows by performing deep-packet inspection, but it is the job of the policy map to determine what needs to be done with these flows when identified (that is, whether they should be marked, policed, dropped, and so on).

The NBAR deep-packet classification engine examines the data payload of stateless protocols and identifies application-layer protocols by matching them against a Protocol Description Language Module (PDLM), which is essentially an application signature. There are more than 80 PDLMs embedded into Cisco IOS; furthermore, because PDLMs are modular, they can be downloaded from http://www.cisco.com/pcgi-bin/tablebuild.pl/pdlm and added to a system without requiring an IOS upgrade.

NBAR is dependent on Cisco Express Forwarding (CEF) and performs deep-packet classification only on the first packet of a flow. The remainder of the packets belonging to the flow is then CEF-switched.

The NBAR classifier is triggered by the match protocol command within a class map definition and is a more CPU-intensive classifier than classifiers that match traffic by DSCPs or access control lists (ACL).

NBAR can classify packets based on Layer 4 through Layer 7 protocols, which dynamically assign TCP/UDP ports. By looking beyond the TCP/UDP port numbers of a packet (known as subport classification), NBAR examines the packet payload and classifies packets on the payload content, such as transaction identifiers, message types, or other similar data. For example, HTTP traffic can be classified by Universal Resource Locators (URL) or Multipurpose Internet Mail Extension (MIME) types using regular expressions within the CLI. NBAR uses the UNIX filename specification as the basis for the URL specification format, which it converts into a regular expression.

Example 1 demonstrates classifying traffic by L2, L3, L4, and L7 parameters.

Example 1: Classifying Traffic by Layer 2, 3, 4, and 7 Parameters

---

Router(config)# class-map match-all L2-CLASSIFIER
Router(config-cmap)# match cos 3
Router(config-cmap)#!
Router(config-cmap)# class-map match-all L3-CLASSIFIER
Router(config-cmap)# match access-group name STANDARD-ACL
Router(config-cmap)# !
Router(config-cmap)# class-map match-all L4-CLASSIFIER
Router(config-cmap)# match access-group name EXTENDED-ACL
Router(config-cmap)# !
Router(config-cmap)# class-map match-any L7-CLASSIFIER
Router(config-cmap)# match protocol exchange
Router(config-cmap)# match protocol citrix
Router(config-cmap)# !
Router(config-cmap)#
Router(config-cmap)# ip access-list standard STANDARD-ACL
Router(config-std-nacl)# permit 10.200.200.0 0.0.0.255
Router(config-std-nacl)#
Router(config-std-nacl)# ip access-list extended EXTENDED-ACL
Router(config-ext-nacl)# permit tcp any any eq ftp
Router(config-ext-nacl)# permit tcp any any eq ftp-data

---

In this example, the class maps classify traffic as follows:

• class-map match-all L2-CLASSIFIER: Traffic is classified by matching on (Layer 2) 802.1p class of service (CoS) values (discussed in more detail in the next section).
• class-map match-all L3-CLASSIFIER: Traffic is classified, through a standard ACL, by (Layer 3) source IP address.
• class-map match-all L4-CLASSIFIER: Traffic is classified, through an extended ACL, by (Layer 4) TCP ports identifying FTP traffic.
• class-map match-any L7-CLASSIFIER: Traffic is classified, with the match-any operator, by NBAR PDLMs that identify SQLNET or Citrix traffic types.

Class Maps | Classification Tools

The primary classification tool within MQC is the class map. Each class map contains one or more match statements, which specify criteria that must be met for traffic identification

Because classmaps can contain multiple match statements, when a class map is defined, a logical operator for the discrete match statements also needs to be defined. Two options exist as follows:

• match-all (a logical AND operator), meaning that all match statements must be true at the same time for the class map condition to be true; match-all is the default operator; it is important not to use mutually exclusive match criteria when a match-all operator is defined within the class map, as this combination can never yield a positive match.
• match-any (a logical OR operator), meaning that any of the match statements might be true for the class map condition to be true.

These match statements specify the criteria for traffic identification. These can include the following:

• Layer 1 parameters: Physical interface, subinterface, PVC, or port
• Layer 2 parameters: MAC address, 802.1Q/p class of service (CoS) bits, Multiprotocol Label Switching (MPLS) Experimental (EXP) bits
• Layer 3 parameters: Differentiated Services Code Points (DSCP), source/destination IP address
• Layer 4 parameters: TCP or UDP ports
• Layer 7 parameters: Application signatures and URLs in packet headers or payload through Network Based Application Recognition (NBAR)

Figure 1 illustrates the Layer 2 to Layer 7 packet classification criteria; however, due to space limitations, the diagram is not to scale, nor are all fields indicated.

 
Figure 1: Layer 2 to Layer 7 packet classification criteria

Classification Tools | Network Quality of Service Technologies

Classification tools serve to identify traffic flows so that specific QoS policies can be applied to specific flows, such as TelePresence media and control flows. Often the termsclassification and marking are used interchangeably (yet incorrectly so); therefore, you need to understand the distinction between classification and marking operations:

• Classification refers to the inspection of one or more fields in a packet (the term packet is used loosely here to include all Layer 2 to Layer 7 fields, not just Layer 3 fields) to identify the type of traffic that the packet is carrying. When identified, the traffic is directed to the applicable policy-enforcement mechanism for that traffic type, where it receives predefined treatment (either preferential or deferential). Such treatment can include marking/remarking, queuing, policing, shaping, or any combination of these (and other) actions.
• Marking, on the other hand, refers to changing a field within the packet to preserve the classification decision that was reached. When a packet has been marked, a trust boundary is established, upon which other QoS tools later depend. Marking is only necessary at the trust boundaries of the network and (as with all other QoS policy actions) cannot be performed without classification. By marking traffic at the trust boundary edge, subsequent nodes do not have to perform the same in-depth classification and analyses to determine how to treat the packet.

MQC performs classification based on the logic defined within the class map structure. Such logic can include matching criteria at the data link, network, or transport Layer (Layers 2 to 4) or even at the application layer (Layer 7)