Priority or Low Latency Queueing – This is the primary method used when dealing with traffic flows that do not react well to network latency, such as voice and video etc. Traffic in the Priority queue will be processed and transmitted ahead of all other traffic.

Policing – Uses a token bucket to limit the flow of traffic to the specified rate. If there are not enough tokens in the bucket, any further packets arriving are discarded.

Shaping – Uses a token bucket and data buffer to queue traffic so it can be transmitted at a specified rate, within the timing interval. Unlike Policing if the token bucket is full then the packets must wait in the queue until there is sufficient space to continue transmission.

Now we know whats available lets take a look at how to implement it for our VPN’s.

Well I guess we can go about looking at this in two different ways:

VPN traffic flowing through the ASA

OR

VPNs terminating on the ASA

Lets begin with VPN traffic through the ASA.

The above image shows a basic setup of two remote networks, separated by an ASA Firewall. In this instance imagine we have a LAN to LAN VPN terminating between routers R1 and R2. With ISAKMP & IPSEC traffic being permitted bidirectionally on the ASA.

The first step we have with any QoS deployment is to identify and classify the traffic we want to control. So with VPN traffic passing through the ASA, we potentially see three different protocols commonly in use.

ISAKMP – UDP 500

ESP – Protocol 50

NAT-T – UDP 4500

So that’s our interesting traffic identified, now we have to classify it. On the ASA, QoS is part of the Modular Policy Framework or MPF for short. In MPF we use class maps to classify the traffic we want to match against. Within the class map we have different criteria available for us to match on, for this scenario we will use an ACL which will permit any VPN traffic to be matched.

The next stage after classification is to apply an action to this traffic via the use of a policy map. In the policy map we will first call the previously configured class map and from the class sub-configuration mode we apply our desired method of QoS. For this instance we will police the outbound VPN traffic to a conform rate of 1Mb with a burst capacity of 37.5Kb

The final stage is to enable the policy. This is done by assigning the policy map to either an interface or to the global plane. As there is a global policy map by default (policy-map global_policy), if we wanted to enable this globally we could have called the class VPNQOS_CM within the global policy instead, this would enable the VPN QoS on all available interfaces. Instead we are going to assign it to the outside interface of the ASA, this is done using the following:

To verify your configuration and statistics for policing use the following show command:

show service-policy police

So there you have a QoS configuration using policing, for any VPN traffic traversing the ASA.

Now lets move on to QoS for VPN’s terminating on the ASA.

So here we extend our topology to include a branch office and an external partner. Both sites will have a VPN terminating on the ASA, using the VPN Tunnel Groups 192.1.2.2 and 192.1.2.3 respectively.

As the branch office will be using IP telephony, extending from the head office, we want to make sure that this VPN will have priority over any others. To accommodate this we will use LLQ (Priority) queue for the branch office VPN and For the External Partner VPN we will police the traffic to 2Mb.

Again as in the previous example we use the 3 stages for QoS configuration:

• Identify & Classify traffic

• Apply Action

• Assign & enable the Policy

OK, so when dealing with directly terminating VPN’s on the ASA, we have some different options to use in terms of the classification of the traffic. As we can differentiate between the two VPN’s, via the separate tunnel groups for each, we can also use this as a valid classifier in a match statement. In addition to this we can also match on flow characteristics, as well as QoS marking such as DSCP & IP Precedence.

The following defines a set of example class maps for this scenario:

Each class map has 2 statements, and works in a first match, next match approach. For the Branch class our first match is the tunnel group 192.1.2.2, followed by our EF (DSCP 46) marked Voice traffic. In comparison the ExPart class first matches on the tunnel group 192.1.2.3, with the next match then based on each flow going through the tunnel based on the destination IP address.

Next on our list is applying the action, but as we are using Priority Queuing for the branch, we have an extra step, which is creating the Priority Queue itself. This has two parts; create the queue by assigning to an interface; and an optional stage of changing the size of the queue limit and the transmit ring limit. Defaults settings being 1024 and 128 packets respectively. So lets create our queue on the outside interface, using the optional values:

Next comes the policy actions, as we can only have one policy assigned to an interface at any one time we will nest the classes into a single policy:

There we have our nested policy, first defining the Priority method for our Branches Voice traffic, and finally policing our external partners traffic.

We then finish off with assigning the policy to the outside interface as before.

service-policy VPNQOS_PM interface outside

The following show commands can be used to verify the QoS statistics for each method:

show service-policy police

show service-policy priority

show priority-queue statistics

As you can see form the output the Voice traffic is correctly place in the Low Latency Queue while all other traffic is transmitted via the Best Effort Queue.