quality of service, QoS on a VPN tunnel, running through a Cisco ASA

quality of service, QoS on a VPN tunnel, running through a Cisco ASA

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


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.


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.

access-list VPNQOS permit udp any any eq 500
access-list VPNQOS permit esp any any
access-list VPNQOS permit udp any any eq 4500
class-map VPNQOS_CM
 description “Match ACL classifying any vpn traffic”
 match access-list VPNQOS

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

policy-map VPNQOS_PM
police output 1000000 37500

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:

service-policy VPNQOS_PM interface outside

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

show service-policy police

asa# show service-policy police
Interface outside:
Service-policy: VPNQOS_PM
Class-map: VPNQOS_CM
Output police Interface outside:
cir 1000000 bps, bc 37500 bytes
conformed 2462 packets, 2005204 bytes; actions:  drop
exceeded 53 packets, 42926 bytes; actions:  drop
conformed 235616 bps, exceed 5048 bps

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 and 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:

class-map Branch_CM
 description “match on Branch Tunnel Group based on flows”
 match tunnel-group
 match dscp ef
class-map ExPart_CM
 description “match on External Partner Tunnel Group based on flows”
 match tunnel-group
 match flow ip destination-address

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, followed by our EF (DSCP 46) marked Voice traffic. In comparison the ExPart class first matches on the tunnel group, 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:

priority-queue outside
 queue-limit 512
 tx-ring-limit 64

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:

policy-map VPNQOS_PM
 class Branch_CM
 class ExPart_PM
 police output 2000000 25000

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

asa# show service-policy police
Interface outside:
Service-policy: VPNQOS_PM
Class-map: ExPart_CM
Output police Interface outside:
cir 2000000 bps, bc 25000 bytes
conformed 25 packets, 4550 bytes; actions:  drop
exceeded 0 packets, 0 bytes; actions:  drop
conformed 0 bps, exceed 0 bps

show service-policy priority

asa# show service-policy priority
Interface outside:
Service-policy: VPNQOS_PM
Class-map: Branch_CM
Interface outside: aggregate drop 0, aggregate transmit 25

show priority-queue statistics

asa# show priority-queue statistics
Priority-Queue Statistics interface outside
Queue Type         = BE
Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 252
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0
Queue Type         = LLQ
Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 25
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

eleven − 5 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.