Firewall – Cisco ASA active SwitchPort

OK guys, thanks for all the comments -- but I got back to the setup this morning, switched the access ports back to trunks ports (they were access just to prove the cabling worked) and MAGICALLY it started work. I have no idea what caused it to not work all of yesterday.

At least I came out of it with two things: 1) knowing my theory was correct 2) a neat diagram template for future!

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 queue-limit and 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 1.2.3.4

priority-queue outside
queue-limit 100  ! based on factors listed earlier, very important number
tx-ring-limit 5  ! based on factors listed earlier

! create class-map

class-map voip-class
 match access-list voip-traffic

! create policy-map, advise not using a global policy

policy-map outside-policy
 class voip-class
  priority

! 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 1.2.3.4 which will show you how the existing service policies on all interfaces would react to the traffic specified.