This past weekend I wrote an article that demonstrated the use of hierarchical priority queuing with the ASA. The last example in that article showed that this qos method properly with the IPSec encapsulated traffic as well. Today’s article started out as an attempt at demonstrating several different classification examples that could be used with hierarchical priority queuing. What I found was that there were more restrictions than I expected when this qos method is used with IPSec encapsulated traffic.
After a couple of hours of not getting the discrimination between packets I thought I should with IPSec and this type of priority queuing, I started doing additional research. I found a lot of contradictory information and many examples that did not seem to work correctly. Then I went to the ASA configuration guide and read the QoS section. The following excerpt explains why my various attempts at classification were not working properly.
Per the Cisco ASA Configuration Guide:
Hierarchical priority queuing—Hierarchical priority queuing is used on interfaces on which you enable a traffic shaping queue. A subset of the shaped traffic can be prioritized. The standard priority queue is not used. See the following guidelines about hierarchical priority queuing:
–Priority packets are always queued at the head of the shape queue so they are always transmitted ahead of other non-priority queued packets.
–Priority packets are never dropped from the shape queue unless the sustained rate of priority traffic exceeds the shape rate.
–For IPsec-encrypted packets, you can only match traffic based on the DSCP or precedence setting.
–IPsec-over-TCP is not supported for priority traffic classification.
The fact that IPSec encrypted packets can only be matched based on DSCP explains why the example in my last post worked as expected. However depending on the circumstance, it might be really nice to prioritize a VPN tunnel over other internet destined traffic. I experimented a bit and found that classification by ACL will work, but it requires the identification of the outer layer packets, not the tunnelled packets. With the configuration below, priority is given to an IPSec tunnel from 192.0.2.2 to destination 192.0.2.1. All traffic going through the tunnel will be prioritized over other other traffic. There is no granularity between packets inside the tunnel.
access-list PRIORITY extended permit udp host 192.0.2.2 host 192.0.2.1 eq isakmp access-list PRIORITY extended permit esp host 192.0.2.2 host 192.0.2.1 ! class-map PRIORITY match access-list PRIORITY ! policy-map PRIORITY class PRIORITY priority ! policy-map HPQ class class-default shape average 992000 service-policy PRIORITY ! service-policy HPQ interface outside
I think there is a lot of work that needs to be done to fully document the configuration examples and restrictions of the QoS features of the ASA. I hope to have time to experiment further and document my findings.