While I am a big fan of the ASA platform, I will be the first to admit that QoS paradigms and capabilities are rather limited on ASA's. Standard IOS ISR's run circles around what the ASA is capable of in regard to QoS.
If you have not read both the ASA QoS Configuration Guide and the IOS QoS Solutions Guide please read them. They are required reading for understanding what Cisco (and many other vendors) mean by the truly loaded term of "quality of service." Note that the IOS guide contains many features that the ASA does not support -- and gives examples that will not work on an ASA. However, both contain a wealth of useful concepts, terms, and details regarding various QoS paradigms and concepts.
With IOS your case would be quite simple -- configure the appropriate bandwidth on the outside interface, use the Modular QoS CLI to create a class and shape traffic that matches the resource-centre-traffic ACL, fair-queue the rest.
However, with an ASA that is not possible because traffic shaping is performed on all traffic on an interface on an ASA. Traffic cannot be shaped on a specific class on the ASA platform.
With shaping not being terribly useful in your case you are left with policing and priority queuing, sometimes called Low Latency Queueing (LLQ).
You have the following options
- Police traffic matching the
resource-centre-traffic ACL
- Priority queue traffic matching the
office-traffic ACL
- Do both at the same, that is police and priority queue traffic matching the respective ACL's.
When it comes to QoS, the KISS principle still applies. The simpler the better. It is for this reason I would advise starting out minimally and fine tune. Start with policing first.
Policing
The following policing example will rate limit (police) traffic matching the resource-centre-traffic ACL to 1 Mb/s. Know that policing will drop packets that exceed the limit ultimately causing host network stacks to retransmit and back-off settling around the policed rate. Shaping avoids this by introducing latency and not dropping, but the ASA's shaper cannot shape based on classes.
! create class-map
class-map resource-centre-traffic-class
match access-list resource-centre-traffic
! create policy-map, advise not using a global policy
policy-map outside-policy
class resource-centre-traffic-class
police input 1000000 ! rate in bits per second, 1 Mb/s listed
police output 1000000 ! rate in bits per second, 1 Mb/s listed
! assign policy to interface, in this case outside
service-policy outside-policy interface outside
Priority Queuing/LLQ
Priority queuing is only applicable in an interface's transmit/out direction. It is important to configure Queue Limits and TX Ring Limit on the interface out which the traffic in the priority queue will be egressing. I am going to assume a 3 Mb/s transmit and create roughly 2 Mb/s priority queue based on 256 byte packet size. Size to use for the priority queue is a lot of the magic when it comes to LLQ. Note that any specified traffic that cannot fit into the priority queue is tail-dropped -- that is to say it is dropped -- likely not what you want for your office-traffic.
It is in this regard that priority queuing/LLQ is not generally used in high throughput traffic classes, but used for low-latency instead. However, I am including the priority queuing example here for the sake of covering what the ASA can do -- I would not recommend using priority queuing for any high throughput flows/traffic classes.
- It is generally advisable to keep a LLQ as small as possible -- without tail dropping, as a large LLQ can starve the normal interface queue if too large.
- Packets that qualify for the LLQ but won't fit (if it is full) are tail-dropped from the LLQ. This is shared in common with policing -- however with a LLQ traffic always "cuts to the front of the line" as the LLQ (a software queue just like the normal interface queue) is always serviced by the driver and placed in the physical interface's hardware queue (hardware ring buffer) first.
Numbers used for queue-limit and tx-ring-limit determined using the worksheet in the configuration guide and then massaged.
priority-queue outside
queue-limit 500 ! based on factors listed earlier, very important number
tx-ring-limit 20 ! based on factors listed earlier
! create class-map
class-map office-traffic-class
match access-list office-traffic
! create policy-map, advise not using a global policy
policy-map outside-policy
class office-traffic-class
priority
! assign policy to interface, in this case outside
service-policy outside-policy interface outside
- Both class-maps can be listed in the outside-policy for both policing and priority queuing at the same time.
- You can still implement a global-policy and have it set as global -- as long as there are not QoS actions on any of the class's listed in the global-policy -- then the global-policy other actions (inspects, etc.) will remain in effect on the outside interface when the outside-policy (with only QoS actions) is placed on the outside interface.
TL;DR
ASA is really limited on the QoS front. Try policing. If that doesn't work add in or try LLQ very carefully. If that doesn't work look for an IOS ISR[G2] with shaping, CBWFQ, etc.
