To begin -- simple is not a word that should be used to describe Quality of Service. The entire word itself is a loaded term.
Instead of rehashing a lot of details about ASA QoS here, reference this answer.
Below is the ASA 8.4 CLI necessary to create a priority queue and handle a specific volume of calls based on a certain bitrate.
- Understand that policing only happens in the out direction on the ASA interface on which it is configured.
- Based on G.711 voice codec @ 87.5 kilobits per second Ethernet layer 2 data rate (includes all overheads)
- Based on a 218 byte average complete Ethernet frame size per voice payload interval. For more see this.
- Based on a need to handle 10 calls at a time (87.5 Kilobits per second * 10 = 875 Kilobits per second). Note that this is only in the out direction. We can't "prioritize" incoming traffic unless you control that path as well.
- Based on a maximum delay of 200 milliseconds between the VoIP endpoints.
- Using an extended access-list with source and destination IP for matching VoIP traffic. Another option is to use IP DSCP if the phones are marking. By using a simple ACL we can verify the service-policy later on with
show service-policy flow.
Numbers used for
tx-ring-limit determined using the worksheet in the configuration guide and then massaged. The numbers used here could be drastically different depending on your requirements.
access-list voip-traffic remark [[ match inside to Call Manager ]]
access-list voip-traffic extended permit ip 10.0.0.0 255.255.255.0 host 220.127.116.11
queue-limit 100 ! based on factors listed earlier, very important number
tx-ring-limit 5 ! based on factors listed earlier
! create class-map
match access-list voip-traffic
! create policy-map, advise not using a global policy
! assign policy to interface, in this case outside
service-policy outside-policy interface outside
- In this case the
outside-policy can be assigned to the
outside interface and you can still implement a
global-policy that is by its nature assigned to the
outside interface as well -- as long as there are not QoS actions on any of the class's listed in the
global-policy. The QoS actions of the
outside-policy will be in effect and the non-QoS actions (inspects, etc.) of the
global-policy will stay effect.
You can view priority-queue statistics with
show priority-queue statistics outside.
You can verify that the traffic itself will hit the priority queue with a command like
show service-policy flow host 10.0.0.100 host 18.104.22.168 which will show you how the existing service policies on all interfaces would react to the traffic specified.