The security appliance supports two kinds of priority queuing – standard priority queuing and hierarchical priority queuing. Let’s configure each in this third part of our blog.
Standard Priority Queuing
This queuing approach allows you to place your priority traffic in a priority queue, while all other traffic is placed in a best effort queue. You can police all other traffic if needed.
Step 1: Create the priority queue on the interface where you want to configure the standard priority queuing. This is done in global configuration mode with the priority-queue interface_name command. Notice this will place you in priority queue configuration mode where you can optionally manipulate the size of the queue with the queue-limit number_of_packets command. You can also optionally set the depth of the hardware queue with the tx-ring-limit number_of_packets command. Remember that the hardware queue forwards packets until full, and then queuing is handled by the software queue (composed of the priority and best effort queues).
pixfirewall(config)# priority-queue outside pixfirewall(config-priority-queue)#
Step 2: Use the Modular Policy Framework (covered in Part 2 of these blogs) to configure the prioritized traffic.
pixfirewall(config-priority-queue)# exit pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# service-policy PM-VOICE-TRAFFIC interface outside pixfirewall(config)# end
Hierarchical Priority Queuing
This queuing approach allows you to shape traffic and allow a subset of the shaped traffic to be prioritized. I have cleared the configuration from the security appliance in preparation for this new configuration. Notice with this approach, you do not configure a priority queue on the interface. Also notice with this approach the nesting of the Policy Maps.
pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# policy-map PM-ALL-TRAFFIC-SHAPE pixfirewall(config-pmap)# class class-default pixfirewall(config-pmap-c)# shape average 2000000 16000 pixfirewall(config-pmap-c)# service-policy PM-VOICE-TRAFFIC pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# service-policy PM-ALL-TRAFFIC-SHAPE interface outside pixfirewall(config)# end
Verifications for Priority Queuing
These verification commands can be used for both forms of priority queuing. Obviously, you can examine portions of the running configuration to confirm your Modular Policy Framework components. For example:
pixfirewall# show run policy-map ! policy-map PM-VOICE-TRAFFIC class CM-VOICE priority class CM-VOICE-SIGNAL priority class class-default policy-map PM-ALL-TRAFFIC-SHAPE class class-default shape average 2000000 16000 service-policy PM-VOICE-TRAFFIC !
Another example:
pixfirewall# show run class-map ! class-map CM-VOICE-SIGNAL match dscp af31 class-map CM-VOICE match dscp ef !
To verify the statistics of the standard priority queuing configuration, use the following:
pixfirewall# show service-policy priority Interface outside: Service-policy: PM-VOICE-TRAFFIC Class-map: CM-VOICE Priority: Interface outside: aggregate drop 0, aggregate transmit 0 Class-map: CM-VOICE-SIGNAL Priority: Interface outside: aggregate drop 0, aggregate transmit 0
You can also view the priority queue statistics for an interface using the following:
pixfirewall# show priority-queue statistics outside Priority-Queue Statistics interface outside Queue Type = BE Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0 Queue Type = LLQ |Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0
To verify the statistics on the shaping you have done with the hierarchical priority queuing, use the following:
pixfirewall# show service-policy shape Interface outside: Service-policy: PM-ALL-TRAFFIC-SHAPE Class-map: class-default shape (average) cir 2000000, bc 16000, be 16000 (pkts output/bytes output) 0/0 (total drops/no-buffer drops) 0/0 Service-policy: PM-VOICE-TRAFFIC
The next blog entry on this subject will focus on the shape tool available on the PIX/ASA.
Thanks so much for reading!
About INE Instructor:
You can leave a response, or trackback from your own site.
10 Responses to “QoS on the PIX/ASA – Part 3:Priority Queuing”
Leave a Reply


Hi, I found your blog on this new directory of WordPress Blogs at blackhatbootcamp.com/listofwordpressblogs. I dont know how your blog came up, must have been a typo, i duno. Anyways, I just clicked it and here I am. Your blog looks good. Have a nice day. James.
I would like to see the inscription “to be continied”:-D
Note that this requires ASA code 8.0(4) or higher. A few weeks ago I went to add this to an 8.0(3) ASA and it rejected most of the commands until I upgraded it.
Signaling should be extended with DSCP CS3. A comment to “show service-policy priority” would be that the output counters don’t really differentiate among classes, here is how it looks in production environment, it is 7.2.4 BTW and all works fine:
asa-chicago(config)# sh ver | in Ver
Cisco Adaptive Security Appliance Software Version 7.2(4)
Device Manager Version 5.2(4)
asa-chicago(config)# sh run class-map
!
class-map Voice-Signal-cs3
description CUCM voice and control traffic
match dscp cs3
class-map Voice
description CUCM voice and control traffic
match dscp ef
class-map Voice-Signal-af31
description CUCM voice and control traffic
match dscp af31
asa-chicago(config)# sh run policy-map VoicePolicy
!
policy-map VoicePolicy
class Voice
priority
class Voice-Signal-cs3
priority
class Voice-Signal-af31
priority
class class-default
!
asa-chicago(config)# show service-policy priority
Interface outside:
Service-policy: VoicePolicy
Class-map: Voice
Priority:
Interface outside: aggregate drop 0, aggregate transmit 3472296
Class-map: Voice-Signal-cs3
Priority:
Interface outside: aggregate drop 0, aggregate transmit 3472296
Class-map: Voice-Signal-af31
Priority:
Interface outside: aggregate drop 0, aggregate transmit 3472296
Hm that sounds good but I would like to know more details.
Your news is a cool stuff man, keep it going.
That’s good man, keep it going.
Can I set up priority queueing on a physical interface that has sub-interfaces and, if so, will it prioritize traffic on all sub-interfaces or just that on the physical interface?
Thanks.
This is a very good stuff man. But you can be more specific next time. See ya !
It is my understanding that your Standard Priority Queing section won’t actually do anything. LLQ only kicks in when the interface is 100% saturated, which isn’t likely to happen often on a 100Mb interface. You need to use policing or shapping in tandem with priority queing for this to actually do anything.
Please correct me if I’m wrong.