This all began when I got a call from our Electronic Medical Record (EMR) vendor about “slowness” in the network. Of course they were sure it was something on our end, meaning our fault, despite the fact that we, the networkers here at the Circus, do not have access to the routers and firewalls that connect our organizations. You can see where this is headed.

So we begin by hooking up a sniffer to our last hop and running a ping to their Citrix farm. When the ping slowed, we hunted through the output on the sniffer to decipher what was wrong.

Eventually it came down to a shared problem. Our Citrix client is purposely run at one of the later versions that they support and is installed through an .msi, while on the farm web page is a newer version that can be installed even if you do not have administrative rights. So users were having difficulty and clicking on the client to reinstall, which was just exacerbating the problem. Normally that does not work, but this morning with the new package it did. Almost. Because these users were downloading ~15MB file over our scrawny link and flooding the circuit. Which just made more users complain that the “system” was slow and start clicking around like their cohorts.

To make matters worse our vendor refused to remove the link to the package that we do not want installed. That was when I thought about NBAR and decided to lab this up.

Here is the diagram:

Here is a link to the configuration files and packet captures and a listing of the files included in the .tar file is below:
$ tar -tf nbar-fun.tar
NBAR-Fun/
NBAR-Fun/r1-citrix.cfg — The configuration for R1.
NBAR-Fun/r2-citrix.cfg — The configuration for R2.
NBAR-Fun/r4-citrix-ios.cfg — The configuration for R4.
NBAR-Fun/r4-citrix-tgn.cfg — The traffic generator configuration for R4.
NBAR-Fun/switch-fa-01 — Packet capture to make sure generator worked.
NBAR-Fun/switch-fa-02-before — Packet capture before NBAR applied.
NBAR-Fun/switch-fa-02-after — Packet capture after NBAR applied.

Let me explain what I did. This lab is based off of the lab wiring for the CCNP ONT Lab manual. R4 is the traffic generator, it sends traffic to R1 that is then destined for R2 and eventually back in another interface on R4. When it gets to R1 it is processed through NBAR and packets requesting citrix.msi are dropped.

Here are really the only interesting commands needed:

class-map match-any http-citrix
 match protocol http url "*citrix*"
!
policy-map mark-inbound-http-citrix
 class http-citrix
  set ip dscp 1
!
interface FastEthernet0/0
 ip address 192.168.14.1 255.255.255.0
 duplex auto
 speed auto
 service-policy input mark-inbound-http-citrix
!
interface FastEthernet1/0
 ip address 192.168.12.1 255.255.255.0
 ip access-group 105 out
 duplex auto
 speed auto
!
access-list 105 deny ip any any dscp 1
access-list 105 permit ip any any

So let’s break down the commands and explain what each does.

The first thing we do is define a traffic class called http-citrix:

class-map match-any http-citrix

A better name would have been block-citrix-msi in case we also needed a class called improve-citrix-prfrmnc.

In the class-map command I used match-any, but I could have used match-all because I am only looking for the word citrix. If on the other hand I wanted to do something like:

class-map match-any http-citrix
 match protocol http url "*citrix.msi"
 match protocol http url "*java.msi"

Then I would have to use match-any. Otherwise the chances would be slim that I would get a packet asking for citrix.msi and java.msi at the same time and in this case I would want to stop some java.msi as well as citrix.msi.

The second thing you do is define the traffic matching criteria:

match protocol http url "*citrix*"

Third, create a traffic policy, this is really for traffic class aggregation, however, in this scenario we only have one traffic class.

policy-map mark-inbound-http-citrix
 class http-citrix

Fourth, mark the class of traffic class for later use. Remember this is DiffServ so we use DSCP to mark the traffic:

set ip dscp 1 

Then we need to assign that policy to an interface:

interface FastEthernet0/0
 service-policy input mark-inbound-http-citrix

Now the traffic is marked coming into Fa0/0, but we need to do something with the marking to block traffic. So we make an ACL and assign it to an interface:

access-list 105 deny ip any any dscp 1
access-list 105 permit ip any any
!
interface FastEthernet1/0
 ip access-group 105 out

As you can see from the traffic capture switch-fa-02-after the traffic containing citrix.msi was dropped.

This lab is based on CCNP ONT Lab 4.1 and Cisco Document ID 27842.
This site was helpful as well:
http://www.opalsoft.net/qos/CDS-21.htm