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.

Interoperability with Out-of-Band Collaboration Applications

Another aspect of supporting audio-only participants is providing a method for all participants to collaborate on shared documents and presentations. Cisco TelePresence provides for auxiliary video inputs and outputs so that users can attach their PCs to the system, and how that signal is encoded and multiplexed over RTP so that all the other TelePresence participants can see it. But how do the audio-only participants get to view it, and can the audio-only participants share a document or presentation with the TelePresence participants?

The predominant method of sharing documents and presentations on an audio conference is through the use of web-based collaboration tools such as Cisco MeetingPlace or Cisco Webex. There have been other methods in the past, such as the infamous T.120 protocol, but those are pretty much defunct. Therefore, the way forward is to engineer a method whereby the auxiliary video channel can automatically convert into a format viewable by the web conference participants and vice versa. At the time this book was written, this functionality was in the process of being developed.

In the meantime, there is a method for achieving the desired results, but it requires steps on the part of the user to enable it. It’s relatively simple but requires a three-step process:

Step 1	The user attaches his or her PC to the auxiliary (VGA) video input of the TelePresence system. This allows whatever he or she is sharing to be instantly viewed by all the other TelePresence participants.
Step 2	The user dials into the audio conferencing server and enters the appropriate DTMF tones to bridge the TelePresence meeting into the audio conference (as described in the previous sections).
Step 3	The user also fires up the web browser on his or her PC and logs onto the web conferencing server for that audio conference and joins the meeting as a web-participant as well and then activates the sharing feature within that web conference.

Now whatever the user shares on her PC is sent simultaneously by his or her PC over VGA to the Cisco TelePresence Primary codec and over HTTP to the web conference. Although this adds a degree of complexity to the ease-of-use of TelePresence, the good news is that it works with virtually any audio and web conferencing product on the planet.