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.
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.
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 class VPNQOS_CM 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 asa#
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 126.96.36.199 and 188.8.131.52 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 184.108.40.206 match dscp ef class-map ExPart_CM description “match on External Partner Tunnel Group based on flows” match tunnel-group 220.127.116.11 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 18.104.22.168, followed by our EF (DSCP 46) marked Voice traffic. In comparison the ExPart class first matches on the tunnel group 22.214.171.124, 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 priority 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 asa#
show service-policy priority
asa# show service-policy priority Interface outside: Service-policy: VPNQOS_PM Class-map: Branch_CM Priority: Interface outside: aggregate drop 0, aggregate transmit 25 asa#
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.